[GLASSFISH-3061] Lazy startup interferes with some JSR88 apis Created: 24/May/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: other
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: vince kraemer Assignee: binod
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Solaris
Platform: Sun


Issuezilla Id: 3,061

 Description   

I have two fresh installs of GF v2 b48.

One is installed with 'ant -f setup.xml' and the other with 'ant -f
setup-cluster.xml'.

I start the "PE" domain and run the code in issue 2999.

All of the system apps get listed as having no child modules.

I shutdown the PE domain and startup the cluster-enabled domain.

I rerun the code form issue 2999 and this time the only the __JWSappclients app
gets flagged as questionable.

The results for both domains should be the same.

This will be a blocker some feature development for NetBeans 6.0.



 Comments   
Comment by vince kraemer [ 24/May/07 ]

tjquinn said you were the person in touch with the lazy start-up code.

Comment by gfbugbridge [ 24/May/07 ]

<BT6562041>

Comment by binod [ 27/May/07 ]

System Apps are not loaded by default in developer profile. They are loaded
on-demand. It is by design. Hence any associated objects for those applications
will not be loaded.

addChildTargetModuleIDsToJ2EEUsingMBeans in SunDeploymentManager.java is using
runtime mbeans to add the child modules. Since the apps are not loaded, the
mbeans will not be available.

Why does NB depend on child modules of system apps?

Comment by vince kraemer [ 29/May/07 ]

NetBeans does not depend on the child modules for the system apps. I used them
to demonstrate the bug in the server without having to create a complicated set
of steps.

The bug is the fact that getChildTargetModuleID() for an EAR is returning no
children... when the EAR has child modules....

Comment by binod [ 30/May/07 ]

I changed your program to print the kids also

DeploymentManager dm = (new
SunDeploymentFactory()).getDeploymentManager("deployer:Sun:AppServer::localhost:4848",
"admin", "adminadmin");
Target[] targs = dm.getTargets();
TargetModuleID tmids[] = dm.getRunningModules(ModuleType.EAR, targs);
if (tmids == null || tmids.length < 1)

{ tmids = dm.getNonRunningModules(ModuleType.EAR, targs); }

for (TargetModuleID ear : tmids) {
TargetModuleID tmids2[] = ear.getChildTargetModuleID();
if (null == tmids2 || tmids2.length < 1)

{ System.out.println("Ear with no children: "+ear); }

else {
System.out.println("Ear with children: "+ear);

for (TargetModuleID comp : tmids2)

{ System.out.println("children: "+ comp); }

}
}

and ran it against the as built from my workspace, which was built yesterday.

I get the following output which indicate that the ear that is deployed is
having children

Ear with children: EnterpriseApplication58_localhost:4848_server
children: EnterpriseApplication58#/EnterpriseApplication58-war_localhost:4848_server
Ear with no children: MEjbApp_localhost:4848_server
Ear with children: __JWSappclients_localhost:4848_server
children: _JWSappclients#/_JWSappclients_localhost:4848_server
Ear with no children: __ejb_container_timer_app_localhost:4848_server

Sorry for asking.... Can you try once more?

Comment by vince kraemer [ 30/May/07 ]

So, your output still shows the bug that this issue was logged to track:

lazy startup interferes with getChildTargetModuleIDs()...

I will d/l a new build and test this out again... I will log the results in
issue 2999.

Comment by vince kraemer [ 01/Jun/07 ]

I have a work-around for the circumstance that prompted me to set this as a p2
issue. [Thanks Binod]

I think this is still a bug, but since I can get past it, I do not think that it
should stop the release of GF v2...

setting the priority to 4

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Generated at Mon Apr 24 09:17:10 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.