[GLASSFISH-14808] Seam3 and weld extension applications related classloading issues with Weld 1.1.0.Beta2 Created: 19/Nov/10  Updated: 20/Feb/11  Resolved: 07/Jan/11

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1
Fix Version/s: 3.1_b37

Type: Bug Priority: Blocker
Reporter: lightguard Assignee: Sivakumar Thyagarajan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Attachments: File catch-jaxrs-example.war     Zip Archive GLASSFISH-14808-fix-diff.zip     File seam-catch-example-jaxrs.war    
Issuezilla Id: 14,808
Tags: 3_1-approved

 Description   

You can see the full stack trace at http://pastebin.com/LSpmygYe This is a seam3 application that uses
Seam Catch, Seam Rest, and Weld Extensions. I was told by Pete Muir it looked like a classloader issue.



 Comments   
Comment by lightguard [ 19/Nov/10 ]

Created an attachment (id=5544)
The example application

Comment by Sivakumar Thyagarajan [ 02/Dec/10 ]

latest war I tried to reproduce this issue with.

My wksp state:
[21:30:51] [siva@spiff ../catch/examples/jaxrs] (master) $ git describe
3.0.0.Alpha1-25-g1447cfe

Comment by Sivakumar Thyagarajan [ 02/Dec/10 ]

The classloading exception(IllegalAccessError) was due to a problem with handling package-private constructors https://jira.jboss.org/browse/WELD-737. I had checked in an alternative implementation of the ProxyServices implementation on Friday commit # r42968 that fixes this problem.

After that I tried reproducing this error with the latest (3.0.0.Alpha1-25-g1447cfe) of the seam-catch sample at
https://github.com/seam/catch/tree/master/examples/jaxrs/
and GlassFish/Weld throws the following exception [1] during deployment with the latest WAR (Attached).

After investigation, it appears that the weld-extensions-1.1.0-Beta1.jar [the weld extensions jar this app depends upon] included in WEB-INF/lib of the WAR, does not have a META-INF/beans.xml and is hence not considered as a bean archive. This behaviour follows Section 12.1 of the CDI 1.0 spec which states that "A directory in the JVM classpath is a bean archive if it has a file named beans.xml in the META-INF directory". So I am closing this issue as invalid. Please raise another issue should you still a problem after fixing this. Thanks.

[1]
[#|2010-12-02T21:34:13.806+0530|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=15;_ThreadName=Thread-1;|Exception while loading the app : WELD-001408 Unsatisfied dependencies for type [ELResolver] with qualifiers [@Composite] at injection point [[field] @Inject @Composite private org.jboss.weld.extensions.el.ELContextProducer.resolver]
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [ELResolver] with qualifiers [@Composite] at injection point [[field] @Inject @Composite private org.jboss.weld.extensions.el.ELContextProducer.resolver]
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:284)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:134)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:153)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:356)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:342)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:383)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:184)

Comment by lightguard [ 02/Dec/10 ]

This is the exception I get with the SNAPSHOT that you gave me Siva, however, using the latest promoted build (b31) I get

WELD-001408 Unsatisfied dependencies for type [ResourceLoaderManager] with qualifiers [@Default] at injection point [[field] @Inject private org.jboss.weld.extensions.resourceLoader.ResourceProducer.resourceLoaderManager]
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [ResourceLoaderManager] with qualifiers [@Default] at injection point [[field] @Inject private org.jboss.weld.extensions.resourceLoader.ResourceProducer.resourceLoaderManager]

Which I think is the original exception I had with b29. weld-extensions doesn't need a beans.xml file, it loads all of it's classes and beans via the spi lifecycle events. I've verified all of these methods are called via debugging, but still getting exceptions upon deployment.

Comment by mimik789 [ 05/Dec/10 ]

I can confirm that current weld-extensions-1.0.0.Beta1 (now Seam Solder) doesn't work on glassfish v 3.1 (b30). Many of Jboss Seam 3 modules depends on this version, and thus one can't currently deploy webapp which make use of Seam 3 (eg. Seam 3 Security module, released recently).

I observed that exception thrown at deployment vary regards type enclosed in brackets
that is going to be injected to weld-extensions classes (Unsatisfied dependencies for type [...] ...)
between (weld) extensions defined in
weld-extensions-1.0.0.Beta1.jar\META-INF\services\javax.enterprise.inject.spi.Extension
so somtimes it complains about
[ELResolver]
and other time about [ResourceLoaderManager] mentioned earlier by lightguard.

I also made some experimenting - it looks like that this exception occurs always after adding just weld-extensions-1.0.0.Beta1.jar to WEB-INF/lib (so to reproduce, deploy simple JEE6 webapp from maven archetype
(eg. mvn archetype:generate -DarchetypeArtifactId=jboss-javaee6-webapp -DarchetypeGroupId=org.jboss.weld.archetypes -DarchetypeVersion=1.0.1.Beta1)

+ add weld-extensions-1.0.0.Beta1.jar).

Because of this exception we switched our development of webapp which uses Seam3 to Jboss AS 6 CR1 - weld-extensions-1.0.0.Beta1 works well on it (even without beans.xml in META-INF).

full stack trace + more description on
http://seamframework.org/Community/DeploymentExceptionWithSeamFaces300Beta1

Comment by ratking [ 22/Dec/10 ]

weld-extensions-1.0.0.Alpha2 can run in GlassFish 3.0.1/3.1-b33
weld-extensions-1.0.0.Beta1 and seam-solder-3.0.0.Beta1 can't run in GlassFish 3.0/3.1
This is a so heavy sad news

Comment by as6o [ 04/Jan/11 ]

The Seam 3 folks seem to think that this is still an issue that is known about by the Glassfish developers. If so, should this issue be reopened so that we can track the progress? Or, is there another issue we should be tracking?

Comment by Sivakumar Thyagarajan [ 06/Jan/11 ]

Reopening this issue to track seam-catch and related deployment issues.

— 3.1 change request –
Component Name: CDI
Issue: http://java.net/jira/browse/GLASSFISH-14808

> How bad is its impact? (Severity)

Major. Users who want to use seam-catch and other weld extensions face this problem.

> How often does it happen? Will many users see this problem? (Frequency)

Often

> How much effort is required to fix it? (Cost)

Fix available. Attached diff in the issue tracker.

> What is the risk of fixing it and how will the risk be mitigated? (Risk)

There are no risks with this fix. I have run CDI developer tests and QL to ensure that the fix does not bring in new regressions and also ensured that the seam-catch-jaxrs sample referred by the user deploys fine and works correctly.

Comment by Sivakumar Thyagarajan [ 06/Jan/11 ]

Recommended fix

Comment by Sivakumar Thyagarajan [ 06/Jan/11 ]

Analysis of issue: The seam-catch-example-jaxrs.war sample had multiple CDI extensions under WEB-INF/lib and GF wasn't handling WEB-INF/lib jar extensions and visibility between these extensions correctly.

Comment by Sivakumar Thyagarajan [ 06/Jan/11 ]

[Changed title to reflect the issue]

Comment by Chris Kasso [ 06/Jan/11 ]

Approved for 3.1

Comment by lightguard [ 06/Jan/11 ]

When should we expect this in a promoted build?

Comment by Sivakumar Thyagarajan [ 07/Jan/11 ]

I am working on checking in a fix for this today, so this should be available in GF3.1 b37. Thanks

Comment by Sivakumar Thyagarajan [ 07/Jan/11 ]

Resolved as part of svn commit 44294.

svn log -v -r44294

Comment by ratking [ 10/Jan/11 ]

I can't run webapp which using seam-solder-3.0.0.Beta1.jar + seam-faces-3.0.0.Beta2.jar + jboss-logging-3.0.0.Beta4.jar in GlassFish 3.1 b37(glassfish-3.1-b37-01_07_2011.zip).

When I put seam-solder-3.0.0.Beta1.jar and jboss-logging-3.0.0.Beta4.jar into WEB-INF\lib, the server.log is:

[#|2011-01-11T12:38:58.250+0800|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=35;_ThreadName=Thread-1;|Exception while loading the app : WELD-001408 Unsatisfied dependencies for type [ELContext] with qualifiers [@Default] at injection point [[parameter 1] of [constructor] @Inject public org.jboss.seam.solder.el.Expressions(ELContext, ExpressionFactory)]
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [ELContext] with qualifiers [@Default] at injection point [[parameter 1] of [constructor] @Inject public org.jboss.seam.solder.el.Expressions(ELContext, ExpressionFactory)]
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:305)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:139)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:162)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:385)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:371)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:390)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:189)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:298)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:354)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:369)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1080)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1260)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1248)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:453)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:220)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:818)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]

When I put seam-solder-3.0.0.Beta1.jar, seam-faces-3.0.0.Beta2.jar and jboss-logging-3.0.0.Beta4.jar into WEB-INF\lib, the server.log is:

[#|2011-01-11T12:32:42.484+0800|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=60;_ThreadName=Thread-1;|ViewDataStore
java.lang.ClassNotFoundException: ViewDataStore
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1518)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1368)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at org.glassfish.web.loader.WebappClassLoader.findClass(WebappClassLoader.java:925)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1485)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1368)
at org.glassfish.weld.BeanDeploymentArchiveImpl.handleEntry(BeanDeploymentArchiveImpl.java:331)
at org.glassfish.weld.BeanDeploymentArchiveImpl.collectJarInfo(BeanDeploymentArchiveImpl.java:324)
at org.glassfish.weld.BeanDeploymentArchiveImpl.populate(BeanDeploymentArchiveImpl.java:287)
at org.glassfish.weld.BeanDeploymentArchiveImpl.<init>(BeanDeploymentArchiveImpl.java:130)
at org.glassfish.weld.DeploymentImpl.<init>(DeploymentImpl.java:113)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:333)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:99)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:249)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:460)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:354)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:369)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1080)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1260)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1248)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:453)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:220)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:818)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]
Comment by ratking [ 10/Jan/11 ]

You can download the two jar files (seam-solder-3.0.0.Beta1.jar and seam-faces-3.0.0.Beta2.jar ) from http://www.seamframework.org/Seam3/DistributionDownloads

In the jar file seam-faces-3.0.0.Beta2.jar, the class file do exists: org\jboss\seam\faces\viewdata\ViewDataStore.class

Comment by janlisse [ 20/Jan/11 ]

I am facing the same error as ratking using glassfish 3.1b38:
ClassNotFoundException: ViewDataStore
Obviously there are still classloading issues there (the class ViewDataStore IS present inside seam-faces-3.0.0.Beta2.jar). Can you reopen the issue?

Comment by ratking [ 20/Feb/11 ]

Now, I have download glassfish-3.1-b43-ml.zip(i.e. RC4, 93 MB, http://dlc.sun.com.edgesuite.net/glassfish/3.1/promoted/) and seam-3.0.0.Beta2.zip(17.7 MB, http://sourceforge.net/projects/jboss/files/Seam/3/3.0.0.Beta2/).

After several test, I can run Seam Solder 3.0.0.Beta4 & Seam Faces 3.0.0.Beta3 & Seam Persistence 3.0.0.Beta4 in a Java EE 6 web project with GlassFish-3.1-b43 (and NetBeans IDE 6.9.1).

What needs to be pointed out is that slf4j-api-1.5.11.jar & logback-core-0.9.20.jar & logback-classic-0.9.20.jar must in the WEB-INF\lib directory in my case. But the slf4j-api-1.5.8.jar or slf4j-api-1.6.1.jar is incompatible.

This is a good news

Generated at Thu Sep 03 11:46:00 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.