Issue Details (XML | Word | Printable)

Key: GLASSFISH-14808
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Blocker Blocker
Assignee: Sivakumar Thyagarajan
Reporter: lightguard
Votes: 0
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
glassfish

Seam3 and weld extension applications related classloading issues with Weld 1.1.0.Beta2

Created: 19/Nov/10 10:30 AM   Updated: 20/Feb/11 12:25 AM   Resolved: 07/Jan/11 03:30 AM
Component/s: cdi
Affects Version/s: 3.1
Fix Version/s: 3.1_b37

Time Tracking:
Not Specified

File Attachments: 1. File catch-jaxrs-example.war (485 kB) 19/Nov/10 10:31 AM - lightguard
2. Zip Archive GLASSFISH-14808-fix-diff.zip (7 kB) 06/Jan/11 04:40 AM - Sivakumar Thyagarajan
3. File seam-catch-example-jaxrs.war (493 kB) 02/Dec/10 08:04 AM - Sivakumar Thyagarajan

Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 14,808
Tags: 3_1-approved
Participants: as6o, Chris Kasso, janlisse, lightguard, mimik789, ratking and Sivakumar Thyagarajan


 Description  « Hide

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.



lightguard added a comment - 19/Nov/10 10:31 AM

Created an attachment (id=5544)
The example application


Sivakumar Thyagarajan added a comment - 02/Dec/10 08:04 AM

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


Sivakumar Thyagarajan added a comment - 02/Dec/10 08:06 AM

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)


lightguard added a comment - 02/Dec/10 10:41 AM

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.


mimik789 added a comment - 05/Dec/10 03:14 AM - edited

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


ratking added a comment - 22/Dec/10 10:31 PM

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


as6o added a comment - 04/Jan/11 08:27 AM

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?


Sivakumar Thyagarajan added a comment - 06/Jan/11 04:38 AM

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.


Sivakumar Thyagarajan added a comment - 06/Jan/11 04:40 AM

Recommended fix


Sivakumar Thyagarajan added a comment - 06/Jan/11 04:42 AM

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.


Sivakumar Thyagarajan added a comment - 06/Jan/11 07:55 AM

[Changed title to reflect the issue]


Chris Kasso added a comment - 06/Jan/11 11:01 AM

Approved for 3.1


lightguard added a comment - 06/Jan/11 11:55 AM

When should we expect this in a promoted build?


Sivakumar Thyagarajan added a comment - 07/Jan/11 03:23 AM

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


Sivakumar Thyagarajan added a comment - 07/Jan/11 03:30 AM

Resolved as part of svn commit 44294.

svn log -v -r44294


ratking added a comment - 10/Jan/11 08:51 PM

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)

#]

ratking added a comment - 10/Jan/11 09:02 PM

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


janlisse added a comment - 20/Jan/11 08:00 AM

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?


ratking added a comment - 20/Feb/11 12:25 AM

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