[GLASSFISH-20952] Failed to start OSGiModuleImpl running some webservices tests. Created: 14/Jan/14  Updated: 19/Sep/14  Resolved: 03/Feb/14

Status: Resolved
Project: glassfish
Component/s: build_system
Affects Version/s: future release
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Dennis MacConnell Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File server.log    
Issue Links:
Related
is related to JERSEY-2339 [GF] Failed to start OSGiModuleImpl r... Resolved

 Description   

I'm getting the following exception running some of the CTS webservices tests on the latest RI build (GlassFish 4.0 b94):

[2014-01-14T16:16:32.563-0500] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=89 _ThreadName=AutoDeployer] [timeMillis: 1389734192563] [levelValue: 1000] [[
Exception while invoking class org.glassfish.webservices.WebServicesDeployer load method
java.lang.RuntimeException: A MultiException has 2 exceptions. They are:
1. com.sun.enterprise.module.ResolveError: Failed to start OSGiModuleImpl:: Bundle = [org.glassfish.main.appclient.gf-client-module [7]], State = [NEW]
2. java.lang.IllegalStateException: Could not load descriptor SystemDescriptor(
implementation=org.glassfish.appclient.common.ACCAppClientArchivist
contracts=

{org.glassfish.appclient.common.ACCAppClientArchivist,com.sun.enterprise.deployment.archivist.Archivist}

scope=org.glassfish.hk2.api.PerLookup
qualifiers={}
descriptorType=CLASS
descriptorVisibility=NORMAL
metadata=Bundle-SymbolicName=

{org.glassfish.main.appclient.gf-client-module}

,Bundle-Version=

{4.0.0.b94}

rank=0
loader=OsgiPopulatorPostProcessor.HK2Loader(OSGiModuleImpl:: Bundle = [org.glassfish.main.appclient.gf-client-module [7]], State = [NEW],32460147)
proxiable=null
analysisName=null
id=38
locatorId=0
identityHashCode=29744355
reified=false)

at org.glassfish.webservices.WebServicesDeployer.load(WebServicesDeployer.java:814)
at org.glassfish.webservices.WebServicesDeployer.load(WebServicesDeployer.java:96)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:206)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:313)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:537)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:164)
at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:595)
at org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:482)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:410)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:401)
at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:233)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)



 Comments   
Comment by Sanjeeb Sahoo [ 15/Jan/14 ]

It's not an OSGi issue. There appears to be some issue in the module which is why a module is not getting resolved. One of the two exceptions mentioned in the log is com.sun.enterprise.module.ResolveError, but unfortunately HK2 subsystem has not printed the stack for this exception. So, I am assigning this to HK2 team to fix their code to print the stack for the first exception which is always the root cause of the problem. There after the issue can be reassigned based on the new information revealed by the stack.

Comment by Lukas Jungmann [ 15/Jan/14 ]

transferring to hk2 per last comment

Comment by Joe Di Pol [ 16/Jan/14 ]

This occurred after r63056, the Jersey 2.0 -> 2.0.1 update in the 4.0 branch.

Comment by Snjezana Sevo-Zenzerovic [ 22/Jan/14 ]

Attaching full server.log file from failed autodeployment on RI b94. Looks like HK2 is printing the whole stack after all.

Comment by Snjezana Sevo-Zenzerovic [ 22/Jan/14 ]

Relevant log snippet seems to be:

Caused by: org.osgi.framework.BundleException: Unresolved constraint in bundle org.glassfish.main.appclient.gf-client-module [67]: Unable to resolve 67.0: missing requirement [67.0] osgi.wiring.package; (osgi.wiring.package=org.jboss.weld.environment.se)
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3974)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2037)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:955)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:210)

Still a mistery since the file content of the RI did not change between b93 and b94 and I am not aware of any changes to the build process or checkins that would affect osgi bundle definitions.

Comment by Snjezana Sevo-Zenzerovic [ 03/Feb/14 ]

By the process of elimination, issue had to be caused by Hudson build environment used to produce GF 4.0 b94. Build respin using the exact same 4.0 branch revision "fixed" the issue.

Generated at Tue Jun 02 12:14:33 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.