glassfish
  1. glassfish
  2. GLASSFISH-14808

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

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 3.1
    • Fix Version/s: 3.1_b37
    • Component/s: cdi
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: Macintosh

      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.

        Activity

        lightguard created issue -
        Hide
        lightguard added a comment -

        Created an attachment (id=5544)
        The example application

        Show
        lightguard added a comment - Created an attachment (id=5544) The example application
        kenaiadmin made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 14808 46412
        Hide
        Sivakumar Thyagarajan added a comment -

        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

        Show
        Sivakumar Thyagarajan added a comment - 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 made changes -
        Attachment seam-catch-example-jaxrs.war [ 23698 ]
        Hide
        Sivakumar Thyagarajan added a comment -

        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)

        Show
        Sivakumar Thyagarajan added a comment - 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)
        Sivakumar Thyagarajan made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Cannot Reproduce [ 5 ]
        Hide
        lightguard added a comment -

        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.

        Show
        lightguard added a comment - 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.
        Hide
        mimik789 added a comment - - 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

        Show
        mimik789 added a comment - - 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
        Hide
        ratking added a comment -

        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

        Show
        ratking added a comment - 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
        Hide
        as6o added a comment -

        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?

        Show
        as6o added a comment - 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?
        Hide
        Sivakumar Thyagarajan added a comment -

        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.

        Show
        Sivakumar Thyagarajan added a comment - 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 made changes -
        Resolution Cannot Reproduce [ 5 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Tags 3_1-review
        Hide
        Sivakumar Thyagarajan added a comment -

        Recommended fix

        Show
        Sivakumar Thyagarajan added a comment - Recommended fix
        Sivakumar Thyagarajan made changes -
        Attachment GLASSFISH-14808-fix-diff.zip [ 27243 ]
        Hide
        Sivakumar Thyagarajan added a comment -

        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.

        Show
        Sivakumar Thyagarajan added a comment - 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.
        Hide
        Sivakumar Thyagarajan added a comment -

        [Changed title to reflect the issue]

        Show
        Sivakumar Thyagarajan added a comment - [Changed title to reflect the issue]
        Sivakumar Thyagarajan made changes -
        Summary Classloading issues with Weld 1.1.0.Beta2 Seam3 and weld extension applications related classloading issues with Weld 1.1.0.Beta2
        Chris Kasso made changes -
        Fix Version/s not determined [ 11149 ]
        Hide
        Chris Kasso added a comment -

        Approved for 3.1

        Show
        Chris Kasso added a comment - Approved for 3.1
        Chris Kasso made changes -
        Tags 3_1-review 3_1-approved
        Hide
        lightguard added a comment -

        When should we expect this in a promoted build?

        Show
        lightguard added a comment - When should we expect this in a promoted build?
        Hide
        Sivakumar Thyagarajan added a comment -

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

        Show
        Sivakumar Thyagarajan added a comment - I am working on checking in a fix for this today, so this should be available in GF3.1 b37. Thanks
        Hide
        Sivakumar Thyagarajan added a comment -

        Resolved as part of svn commit 44294.

        svn log -v -r44294

        Show
        Sivakumar Thyagarajan added a comment - Resolved as part of svn commit 44294. svn log -v -r44294
        Sivakumar Thyagarajan made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Fix Version/s 3.1_b37 [ 11268 ]
        Resolution Fixed [ 1 ]
        Hide
        ratking added a comment -

        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)

        #]
        Show
        ratking added a comment - 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) #]
        Hide
        ratking added a comment -

        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

        Show
        ratking added a comment - 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
        Hide
        janlisse added a comment -

        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?

        Show
        janlisse added a comment - 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?
        Hide
        ratking added a comment -

        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

        Show
        ratking added a comment - 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

          People

          • Assignee:
            Sivakumar Thyagarajan
            Reporter:
            lightguard
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: