Closed glassfishrobot closed 13 years ago
glassfishrobot
commented
6 years ago glassfishrobot
commented
13 years ago @glassfishrobot Commented lightguard said: Created an attachment (id=5544) The example application
glassfishrobot
commented
13 years ago @glassfishrobot Commented @sivakumart said: 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
glassfishrobot
commented
13 years ago @glassfishrobot Commented @sivakumart said: 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)
glassfishrobot
commented
13 years ago @glassfishrobot Commented lightguard said: 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.
glassfishrobot
commented
13 years ago @glassfishrobot Commented mimik789 said: 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)
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
glassfishrobot
commented
13 years ago @glassfishrobot Commented
ratking said:
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 
glassfishrobot
commented
13 years ago @glassfishrobot Commented as6o said: 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?
glassfishrobot
commented
13 years ago @glassfishrobot Commented @sivakumart said: 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.
glassfishrobot
commented
13 years ago @glassfishrobot Commented @sivakumart said: Recommended fix
glassfishrobot
commented
13 years ago @glassfishrobot Commented @sivakumart said: 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.
glassfishrobot
commented
13 years ago @glassfishrobot Commented @sivakumart said: [Changed title to reflect the issue]
glassfishrobot
commented
13 years ago @glassfishrobot Commented kasso said: Approved for 3.1
glassfishrobot
commented
13 years ago @glassfishrobot Commented lightguard said: When should we expect this in a promoted build?
glassfishrobot
commented
13 years ago @glassfishrobot Commented @sivakumart said: I am working on checking in a fix for this today, so this should be available in GF3.1 b37. Thanks
glassfishrobot
commented
13 years ago @glassfishrobot Commented @sivakumart said: Resolved as part of svn commit 44294.
svn log -v -r44294
glassfishrobot
commented
13 years ago @glassfishrobot Commented ratking said: 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.
| #] |
glassfishrobot
commented
13 years ago @glassfishrobot Commented ratking said: 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
glassfishrobot
commented
13 years ago @glassfishrobot Commented janlisse said: 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?
glassfishrobot
commented
13 years ago @glassfishrobot Commented ratking said: 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 
glassfishrobot
commented
13 years ago @glassfishrobot Commented File: catch-jaxrs-example.war Attached By: lightguard
glassfishrobot
commented
13 years ago @glassfishrobot Commented File: GLASSFISH-14808-fix-diff.zip Attached By: @sivakumart
glassfishrobot
commented
13 years ago @glassfishrobot Commented File: seam-catch-example-jaxrs.war Attached By: @sivakumart
glassfishrobot
commented
7 years ago @glassfishrobot Commented This issue was imported from java.net JIRA GLASSFISH-14808
glassfishrobot
commented
13 years ago @glassfishrobot Commented Reported by lightguard
glassfishrobot
commented
13 years ago @glassfishrobot Commented Marked as fixed on Thursday, January 6th 2011, 7:30:14 pm
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.
Environment
Operating System: All Platform: Macintosh
Affected Versions
[3.1]