[GLASSFISH-18827] Exception on app deployment if javassist bundled Created: 22/Jun/12  Updated: 19/Sep/14  Resolved: 25/Jul/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.2
Fix Version/s: 4.1

Type: Bug Priority: Blocker
Reporter: arothe Assignee: phil.zampino
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OpenSuse 12.1
Glassfish 3.1.2 local installation


Tags: exception, javassist, weld

 Description   

I try to deploy an application, which has a maven dependency to javassist 3.14.0-GA. If I bundle the lib with the application I will get
Exception while loading the app : org.jboss.weldx.transaction.UserTransaction$1279195191$Proxy$_$$_Weld$Proxy$ cannot be cast to javassist.util.proxy.ProxyObject

If I set the maven scope to "provided", I will get
java.lang.NoClassDefFoundError: javassist/bytecode/CodeAttribute$RuntimeCopyException

The application uses CDI and EclipseLink as persistence provider.
I have seen, that javassist is already part of the weld-osgi-bundle, but the jar isn't used by the application.



 Comments   
Comment by arjavdesai [ 13/Apr/13 ]

Can you please provide a test app to re-produce the issue? Have tried with latest glass fish? If not, can you please try with one built on 13-apr-13 or later from http://dlc.sun.com.edgesuite.net/glassfish/4.0/nightly/.

Comment by arothe [ 05/Jun/13 ]

I have checked the old project on SVN. In the sun-web.xml I had an entry

<class-loader delegate="false"/>

The error didn't longer occur after removing that line. I'm not sure which influence the line has...





[GLASSFISH-19786] CDI Instantiation Error - CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [InstanceManager] with qualifiers Created: 07/Mar/13  Updated: 27/Mar/13  Resolved: 27/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b78
Fix Version/s: 4.0

Type: Bug Priority: Blocker
Reporter: peter_pilgrim Assignee: phil.zampino
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All



 Description   

It would appear there is problem with the CDI Container service in Glassfish 4.0 b78 fails to be initialised.

I even tried a new WAR with just a single POJO, a dummy Java class with no methods at all, and I received the same error.

There is not an issue with GlassFish 4.0 b77 server, only since I upgraded.

[main] INFO org.jboss.weld.Version - WELD-000900 SNAPSHOT
[main] WARN org.jboss.weld.Bootstrap - WELD-001440 Scope type @javax.enterprise.context.ApplicationScoped() used on injection point [BackedAnnotatedField] @Inject @ApplicationScoped private je7hb.websocket.basic.FakeServlet.chatRoom
>>>> SampleSingleton.init() called
Mar 07, 2013 9:33:48 AM org.glassfish.tyrus.servlet.TyrusServletContainerInitializer onStartup
INFO: Registering WebSocket filter for url pattern /*
Mar 07, 2013 9:33:48 AM com.sun.enterprise.web.WebApplication start
INFO: Loading application [mywebapp] at [/mywebapp]
[weld-worker-2] WARN org.jboss.weld.Bootstrap - WELD-001440 Scope type @javax.enterprise.context.ApplicationScoped() used on injection point [BackedAnnotatedField] @Inject @ApplicationScoped private je7hb.websocket.basic.ChatServiceEndPoint.chatRoom
[weld-worker-3] WARN org.jboss.weld.Bootstrap - WELD-001440 Scope type @javax.enterprise.context.ApplicationScoped() used on injection point [BackedAnnotatedField] @Inject @ApplicationScoped private je7hb.websocket.basic.FakeServlet.chatRoom
[main] WARN org.jboss.weld.Bootstrap - WELD-001440 Scope type @javax.enterprise.context.ApplicationScoped() used on injection point [BackedAnnotatedField] @Inject @ApplicationScoped private je7hb.websocket.basic.FakeServlet.chatRoom
Mar 07, 2013 9:33:48 AM com.sun.enterprise.v3.server.ApplicationLifecycle deploy
SEVERE: Exception during lifecycle processing
org.glassfish.deployment.common.DeploymentException: CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [InstanceManager] with qualifiers [@Default] at injection point [[UnbackedAnnotatedParameter] Parameter 1 of [UnbackedAnnotatedConstructor] @Inject protected org.jboss.weld.environment.se.WeldContainer(InstanceManager, BeanManager)]
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:247)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:364)
>>>> SampleSingleton.destroy() called
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
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$1.run(CommandRunnerImpl.java:528)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:524)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:357)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:523)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:547)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1424)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1759)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1675)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at je7hb.common.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.deployWithRename(AbstractEmbeddedRunner.java:73)
at je7hb.common.weber.embedded.glassfish.EmbeddedRunner.main(EmbeddedRunner.java:19)
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [InstanceManager] with qualifiers [@Default] at injection point [[UnbackedAnnotatedParameter] Parameter 1 of [UnbackedAnnotatedConstructor] @Inject protected org.jboss.weld.environment.se.WeldContainer(InstanceManager, BeanManager)]
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:381)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:309)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:172)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:203)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:493)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:69)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:67)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)

Mar 07, 2013 9:33:48 AM org.glassfish.api.ActionReport failure
SEVERE: Exception while loading the app
Mar 07, 2013 9:33:48 AM org.glassfish.tyrus.server.TyrusServerContainer stop
INFO: Closing down : org.glassfish.tyrus.server.TyrusEndpoint@5e9b0166
Mar 07, 2013 9:33:48 AM org.glassfish.tyrus.server.TyrusServerContainer stop
INFO: Closing down : org.glassfish.tyrus.server.TyrusEndpoint@6150e9a2
Mar 07, 2013 9:33:48 AM org.glassfish.tyrus.server.TyrusServerContainer stop
INFO: Closing down : org.glassfish.tyrus.server.TyrusEndpoint@39ece0e3
Mar 07, 2013 9:33:48 AM com.sun.web.server.WebContainerListener preDestroy
SEVERE: Exception during invocation of InjectionManager.destroyManagedObject on org.glassfish.tyrus.servlet.TyrusServletFilter@24633a36 of web module StandardEngine[glassfish-web].StandardHost[server].StandardContext[/mywebapp]
java.lang.IllegalStateException: Unknown JCDI-enabled managed bean org.glassfish.tyrus.servlet.TyrusServletFilter@24633a36 of class class org.glassfish.tyrus.servlet.TyrusServletFilter
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.destroyManagedBean(ManagedBeanManagerImpl.java:628)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.destroyManagedObject(InjectionManagerImpl.java:439)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.destroyManagedObject(InjectionManagerImpl.java:414)
at com.sun.web.server.WebContainerListener.preDestroy(WebContainerListener.java:186)
at com.sun.web.server.WebContainerListener.containerEvent(WebContainerListener.java:151)
at org.apache.catalina.core.ContainerBase.fireContainerEvent(ContainerBase.java:1579)
at org.apache.catalina.core.ApplicationFilterConfig.release(ApplicationFilterConfig.java:334)
at org.apache.catalina.core.StandardContext.filterStop(StandardContext.java:5319)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:6082)
at com.sun.enterprise.web.WebModule.stop(WebModule.java:725)
at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1172)
at com.sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java:2438)
at com.sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java:2393)
at com.sun.enterprise.web.WebApplication.stop(WebApplication.java:191)
at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:161)
at com.sun.enterprise.v3.server.ApplicationLifecycle$2.actOn(ApplicationLifecycle.java:268)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:503)
at com.sun.enterprise.v3.servecationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:528)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:524)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:357)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:523)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:547)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1424)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1759)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1675)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at je7hb.common.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.deployWithRename(AbstractEmbeddedRunner.java:73)
at je7hb.common.webcontainer.embedded.glassfish.EmbeddedRunner.main(EmbeddedRunner.java:19)

Mar 07, 2013 9:33:48 AM org.glassfish.weld.WeldDeployer event
WARNING: JCDI shutdown error
java.lang.IllegalStateException: Singleton is not set. Is your Thread.currentThread().getContextClassLoader() set correctly?
at org.jboss.weld.bootstrap.api.helpers.IsolatedStaticSingletonProvider$IsolatedStaticSingleton.get(IsolatedStaticSingletonProvider.java:52)
at org.jboss.weld.Container.instance(Container.java:54)
at org.jboss.weld.bootstrap.WeldBootstrap.shutdown(WeldBootstrap.java:597)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:293)
at org.glassfish.kernel.event.EventsImpl$1.run(EventsImpl.java:123)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)

Mar 07, 2013 9:33:48 AM org.glassfish.deployment.admin.DeployCommand execute
SEVERE: Exception while loading the app : CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [InstanceManager] with qualifiers [@Default] at injection point [[UnbackedAnnotatedParameter] Parameter 1 of [UnbackedAnnotatedConstructor] @Inject protected org.jboss.weld.environment.se.WeldContainer(InstanceManager, BeanManager)]
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [InstanceManager] with qualifiers [@Default] at injection point [[UnbackedAnnotatedParameter] Parameter 1 of [UnbackedAnnotatedConstructor] @Inject protected org.jboss.weld.environment.se.WeldContainer(InstanceManager, BeanManager)]
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:381)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:309)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:172)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Valjava:203)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:493)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:69)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:67)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)

        • Press the ENTER key to stop the server ****
          > Building > :run
          Mar 07, 2013 9:33:51 AM org.glassfish.admin.mbeanserver.JMXStartupService shutdown
          INFO: JMXStartupService and JMXConnectors have been shut down.
          JdbcRuntimeExtension, getAllSystemRAResourcesAndPools = [GlassFishConfigBean.org.glassfish.jdbc.config.JdbcResource, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcResource, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcConnectionPool, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcConnectionPool]
          Mar 07, 2013 9:33:51 AM com.sun.enterprise.v3.server.AppServerStartup stop
          INFO: Shutdown procedure finished

BUILD SUCCESSFUL

Total time: 14.432 secs
peterpilgrim@Peters-MacBook-Pro-3.local [1110] >



 Comments   
Comment by phil.zampino [ 07/Mar/13 ]

A change was committed today to prevent the weld SE implementation from getting pulled into the server classpath. Please try again with the latest.

Comment by peter_pilgrim [ 07/Mar/13 ]

Thanks! I see there is 4.0-b79 in repo https://maven.java.net/content/groups/promoted/javax/javaee-api/ . I will give it a go.

PP

Comment by peter_pilgrim [ 07/Mar/13 ]

I upgraded the build to 4.0-b79. Sadly, this fix is still not working and I get the same error: session

INFO: EJB5181:Portable JNDI names for EJB SampleSingleton: [java:global/mywebapp/SampleSingleton, java:global/mywebapp/SampleSingleton!je7hb.websocket.basic.SampleSingleton]
[main] INFO org.jboss.weld.Version - WELD-000900 SNAPSHOT
[main] WARN org.jboss.weld.Bootstrap - WELD-001440 Scope type @javax.enterprise.context.ApplicationScoped() used on injection point [BackedAnnotatedField] @Inject @ApplicationScoped private je7hb.websocket.basic.FakeServlet.chatRoom
>>>> SampleSingleton.init() called
Mar 07, 2013 11:30:09 PM org.glassfish.tyrus.servlet.TyrusServletContainerInitializer onStartup
INFO: Registering WebSocket filter for url pattern /*
Mar 07, 2013 11:30:09 PM com.sun.enterprise.web.WebApplication start
INFO: Loading application [mywebapp] at [/mywebapp]
Mar 07, 2013 11:30:09 PM com.sun.enterprise.v3.server.ApplicationLifecycle deploy
SEVERE: Exception during lifecycle processing
org.glassfish.deployment.common.DeploymentException: CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [InstanceManager] with qualifiers [@Default] at injection point [[UnbackedAnnotatedParameter] Parameter 1 of [UnbackedAnnotatedConstructor] @Inject protected org.jboss.weld.environment.se.WeldContainer(InstanceManager, BeanManager)]
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:247)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:364)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
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$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:357)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
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:1761)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at je7hb.common.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.deployWithRename(AbstractEmbeddedRunner.java:73)
at je7hb.common.we>>>> SampleSingleton.destroy() called
ner.embedded.glassfish.EmbeddedRunner.main(EmbeddedRunner.java:19)
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [InstanceManager] with qualifiers [@Default] at injection point [[UnbackedAnnotatedParameter] Parameter 1 of [UnbackedAnnotatedConstructor] @Inject protected org.jboss.weld.environment.se.WeldContainer(InstanceManager, BeanManager)]
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:381)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:309)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:172)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:203)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:493)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:69)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:67)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)

Mar 07, 2013 11:30:09 PM org.glassfish.api.ActionReport failure
SEVERE: Exception while loading the app
Mar 07, 2013 11:30:09 PM org.glassfish.tyrus.server.TyrusServerContainer stop
INFO: Closing down : org.glassfish.tyrus.server.TyrusEndpoint@720c51a0
Mar 07, 2013 11:30:09 PM org.glassfish.tyrus.server.TyrusServerContainer stop
INFO: Closing down : org.glassfish.tyrus.server.TyrusEndpoint@14fdaad6
Mar 07, 2013 11:30:09 PM org.glassfish.tyrus.server.TyrusServerContainer stop
INFO: Closing down : org.glassfish.tyrus.server.TyrusEndpoint@45c8899b
Mar 07, 2013 11:30:09 PM com.sun.web.server.WebContainerListener preDestroy
SEVERE: Exception during invocation of InjectionManager.destroyManagedObject on org.glassfish.tyrus.servlet.TyrusServletFilter@23644cf3 of web module StandardEngine[glassfish-web].StandardHost[server].StandardContext[/mywebapp]
java.lang.IllegalStateException: Unknown JCDI-enabled managed bean org.glassfish.tyrus.servlet.TyrusServletFilter@23644cf3 of class class org.glassfish.tyrus.servlet.TyrusServletFilter
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.destroyManagedBean(ManagedBeanManagerImpl.java:628)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.destroyManagedObject(InjectionManagerImpl.java:439)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.destroyManagedObject(InjectionManagerImpl.java:414)
at com.sun.web.server.WebContainerListener.preDestroy(WebContainerListener.java:186)
at com.sun.web.server.WebContainerListener.containerEvent(WebContainerListener.java:151)
at org.apache.catalina.core.ContainerBase.fireContainerEvent(ContainerBase.java:1579)
at org.apache.catalina.core.ApplicationFilterConfig.release(ApplicationFilterConfig.java:334)
at org.apache.catalina.core.StandardContext.filterStop(StandardContext.java:5319)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:6082)
at com.sun.enterprise.web.WebModule.stop(WebModule.java:725)
at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1172)
at com.sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java:2447)
at com.sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java:2402)
at com.sun.enterprise.web.WebApplication.stop(WebApplication.java:191)
at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:161)
at com.sun.enterprise.v3.server.ApplicationLifecycle$2.actOn(ApplicationLifecycle.java:268)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:503)
at com.sun.enterprise.v3.servicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:357)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
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:1761)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at je7hb.common.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.deployWithRename(AbstractEmbeddedRunner.java:73)
at je7hb.common.webcontainer.embedded.glassfish.EmbeddedRunner.main(EmbeddedRunner.java:19)

Mar 07, 2013 11:30:09 PM org.glassfish.deployment.admin.DeployCommand execute
SEVERE: Exception while loading the app : CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [InstanceManager] with qualifiers [@Default] at injection point [[UnbackedAnnotatedParameter] Parameter 1 of [UnbackedAnnotatedConstructor] @Inject protected org.jboss.weld.environment.se.WeldContainer(InstanceManager, BeanManager)]
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [InstanceManager] with qualifiers [@Default] at injection point [[UnbackedAnnotatedParameter] Parameter 1 of [UnbackedAnnotatedConstructor] @Inject protected org.jboss.weld.environment.se.WeldContainer(InstanceManager, BeanManager)]
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:381)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:309)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:172)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:203)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:493)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:69)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:67)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)

Mar 07, 2013 11:30:09 PM org.glassfish.weld.WeldDeployer event
WARNING: JCDI shutdown error
java.lang.IllegalStateException: Singleton is not set. Is your Thread.currentThread().getContextClassLoader() set correctly?
at org.jboss.weld.bootstrap.api.helpers.IsolatedStaticSingletonProvider$IsolatedStaticSingleton.get(IsolatedStaticSingletonProvider.java:52)
at org.jboss.weld.Container.instance(Container.java:54)
at org.jboss.weld.bootstrap.WeldBootstrap.shutdown(WeldBootstrap.java:597)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:293)
at org.glassfish.kernel.event.EventsImpl$1.run(EventsImpl.java:123)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)

        • Press the ENTER key to stop the server ****
          > Building > :run
          Mar 07, 2013 11:32:35 PM org.glassfish.admin.mbeanserver.JMXStartupService shutdown
          INFO: JMXStartupService and JMXConnectors have been shut down.
          JdbcRuntimeExtension, getAllSystemRAResourcesAndPools = [GlassFishConfigBean.org.glassfish.jdbc.config.JdbcResource, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcResource, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcConnectionPool, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcConnectionPool]
          Mar 07, 2013 11:32:35 PM com.sun.enterprise.v3.server.AppServerStartup stop
          INFO: Shutdown procedure finished

BUILD SUCCESSFUL

Total time: 2 mins 35.427 secs

///////////

package je7hb.websocket.basic;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.ejb.Singleton;
import javax.ejb.Startup;
import java.util.concurrent.atomic.AtomicInteger;

/**

  • The type SampleSingleton
    *
  • @author Peter Pilgrim
    */
    @Singleton
    @Startup
    public class SampleSingleton {
    private AtomicInteger counter = new AtomicInteger(5000);
    @PostConstruct
    public void init() { System.out.printf(">>>> %s.init() called\n", getClass().getSimpleName()); }

@PreDestroy
public void destroy()

{ System.out.printf(">>>> %s.destroy() called\n", getClass().getSimpleName()); }

public int count()

{ return counter.getAndAdd(2); }

public String getFullName()

{ return "Peter Pilgrim"; }

}

///////////

package je7hb.websocket.basic;

import javax.ejb.EJB;
import javax.inject.Inject;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.websocket.OnClose;
import javax.websocket.OnMessage;
import javax.websocket.OnOpen;
import javax.websocket.Session;
import javax.websocket.server.ServerEndpoint;
import java.util.Date;

/**

  • The type SingletonEJBWebSocketEndpoint
    *
  • @author Peter Pilgrim
    */
    @ServerEndpoint("/singleton")
    public class SingletonEJBWebSocketEndpoint {

@Inject
private SampleSingleton sampleSingleton;

@OnOpen
public void open(Session session) {
System.out.printf("%s.open() called session=%s\n", getClass().getSimpleName(), session );

// This is a work around
System.out.printf(" sampleSingleton = %s BEFORE\n", sampleSingleton );
if ( sampleSingleton == null) {
// Look up the object
Context initialContext = null;
try

{ initialContext = new InitialContext(); Object obj = initialContext.lookup("java:global/mywebapp/SampleSingleton"); System.out.printf(" obj=%s\n", obj); sampleSingleton = (SampleSingleton)obj; }

catch (NamingException e)

{ e.printStackTrace(); }

}
System.out.printf(" sampleSingleton = %s AFTER\n", sampleSingleton );
}

@OnClose
public void close(Session session)

{ System.out.printf("%s.close() called session=%s\n", getClass().getSimpleName(), session); System.out.printf(" sampleSingleton = %s\n", sampleSingleton ); }

@OnMessage
public String generateReply( String message )

{ return String.format("%s - name: %s, counter: %d, message:%s", new Date(), sampleSingleton.getFullName(), sampleSingleton.count(), message.toUpperCase()); }

}

//////////

package je7hb.websocket.basic;

import javax.enterprise.context.ApplicationScoped;
import javax.inject.Inject;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.util.Date;

/**

  • The type FakeServlet
    *
  • @author Peter Pilgrim
    */
    @WebServlet("/fake")
    public class FakeServlet extends HttpServlet {

@Inject
@ApplicationScoped
private ChatRoom chatRoom;

@Override
public void init(ServletConfig config) throws ServletException

{ super.init(config); System.out.printf("%s.init() called with chatRoom=%s\n", getClass().getSimpleName(), chatRoom); }

@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException

{ resp.setContentType("text/plain"); resp.getWriter().printf("Date: %s Servlet %s with chatRoom=%s\n", new Date(), getClass(), chatRoom ); }

}

///////////

Comment by Tim Quinn [ 07/Mar/13 ]

I suspect the problem is that we've recently added CDI support to the app client container, so the manifest Class-Path for the gf-client-module.jar (in the GlassFish modules/ directory) refers to weld-se.jar.

I think GlassFish loads every module in the modules/ directory, so weld-se.jar ends up on the class path.

The change Phil referred to was for embedded only.

Comment by peter_pilgrim [ 07/Mar/13 ]

You say it could be a classpath issue, which is causing WELD to fail, and I am executing the embedded runner.

Here is the Gradle file, which I am using now ``gradle.build'':-

apply plugin: 'java'
apply plugin: 'maven'
apply plugin: 'war'
apply plugin: 'eclipse'
apply plugin: 'idea'

// Define equivalent Maven GAV coordinates.
group = 'com.javaeehandbook.book1'
archivesBaseName = 'ch07-websockets-basic'
version = '1.0'

repositories {
mavenCentral()
ivy

{ url "http://maven.java.net/content/groups/promoted/" }

maven

{ url 'https://maven.java.net/content/groups/promoted' }

maven

{ url 'http://repository.jboss.org/nexus/content/groups/public' }

}

dependencies

{ providedCompile 'org.glassfish.main.extras:glassfish-embedded-all:4.0-b79' providedCompile 'javax:javaee-api:7.0-b79' compile 'org.glassfish.main.extras:glassfish-embedded-all:4.0-b79' compile 'javax:javaee-api:7.0-b79' testCompile 'junit:junit:4.10' }

war

{ // webXml = file("src/main/webapp/WEB-INF/web.xml") }

task wrapper(type: Wrapper)

{ gradleVersion = '1.4' }

// Override Gradle defaults - a force an exploded JAR view
sourceSets {
main

{ output.resourcesDir = 'build/classes/main' output.classesDir = 'build/classes/main' }

test

{ output.resourcesDir = 'build/classes/test' output.classesDir = 'build/classes/test' }

}

task(run, dependsOn: 'classes', type: JavaExec)

{ description = 'Runs the main application' main = 'je7hb.common.webcontainer.embedded.glassfish.EmbeddedRunner' classpath = sourceSets.main.runtimeClasspath args 'Mary', 'Peter', 'Jane' standardInput = System.in }

See also my blog entry for an example of the sort of ``EmbeddedRunner'' that I am running for the book: http://www.xenonique.co.uk/blog/?p=980

Comment by Tim Quinn [ 07/Mar/13 ]

(blush)

OK, you are using embedded!

The change Phil referred to went in earlier today (March 7). I don't think promoted build 79 has it.

Tonight's nightly build should, though.

Comment by peter_pilgrim [ 07/Mar/13 ]

How do you grab the nightly build using Maven or Gradle?

Comment by phil.zampino [ 26/Mar/13 ]

Has this been tested with a more recent build, per Tim's suggestion?

Comment by phil.zampino [ 27/Mar/13 ]

This appears to have been resolved since 4.0-b81





[GLASSFISH-19714] Unable to deploy WAR when guava is present in WEB-INF/lib Created: 22/Feb/13  Updated: 21/Mar/13  Resolved: 21/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b77
Fix Version/s: 4.0

Type: Bug Priority: Blocker
Reporter: Michal Gajdos Assignee: phil.zampino
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks JERSEY-1745 Deployment of bookmark.war fails on G... Closed

 Description   

When I try to deploy a WAR containing guava.jar in int (WEB-INF/lib) I get the following exception:

[#|2013-02-22T10:18:36.313+0100|SEVERE|glassfish 4.0|javax.enterprise.system.core|_ThreadID=58;_ThreadName=admin-listener(1);_TimeMillis=1361524716313;_LevelValue=1000;|Exception while deploying the app [helloworld-webapp-2.0-m12-1]|#]

[#|2013-02-22T10:18:36.313+0100|SEVERE|glassfish 4.0|javax.enterprise.system.core|_ThreadID=58;_ThreadName=admin-listener(1);_TimeMillis=1361524716313;_LevelValue=1000;_MessageID=NCLS-CORE-0026;|Exception during lifecycle processing
java.lang.StackOverflowError
        at java.util.HashMap.addEntry(HashMap.java:856)
        at java.util.HashMap.put(HashMap.java:484)
        at java.util.HashSet.add(HashSet.java:217)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:248)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
        at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)

It seems that WeldUtils class has problems processing com.google.common.annotations.GwtCompatible annotation.

The WAR is available at [1] sources of the app at [2].

[1] http://repo1.maven.org/maven2/org/glassfish/jersey/examples/helloworld-webapp/2.0-m12-1/helloworld-webapp-2.0-m12-1.war
[2] https://github.com/jersey/jersey/tree/master/examples/helloworld-webapp



 Comments   
Comment by phil.zampino [ 20/Mar/13 ]

This is the result of circular annotation relationships.
This code will be removed/replaced shortly, as the requirements around CDI enablement have changed.

Comment by TangYong [ 21/Mar/13 ]

The issue has been reproduced by vaadin demo[1],

[1]: https://github.com/vaadin/dashboard-demo

Currently, a thread[2] is in discussion.
[2]: http://java.net/projects/glassfish/lists/dev/archive/2013-03/message/98

Comment by phil.zampino [ 21/Mar/13 ]

Just committed rev. 60679 of appserver/web/gf-weld-connector/src/main/java/org/glassfish/weld/connector/WeldUtils.java to resolve this issue.
Please check the next build to verify.

Comment by tlcksnyder [ 21/Mar/13 ]

Tested successfully as of Revision: 60694.





[GLASSFISH-20579] cannot deploy war with google guava lib Created: 24/May/13  Updated: 19/Jun/13  Resolved: 24/May/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b85
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: aaronjwhiteside Assignee: jjsnyder83
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

My war contains

WEB-INF/lib/guava-14.0.jar

and NO beans.xml. But it seems CDI is being enabled.. and trying to do something with a class inside the guava-14.0.jar that contains a @Singleton annotation.

Why is CDI being enabled without a beans.xml?

[2013-05-23T15:08:32.159-0700] [glassfish 4.0] [INFO] [] [org.jboss.weld.Version] [tid: _ThreadID=34 _ThreadName=admin-listener(2)] [timeMillis: 1369346912159] [levelValue: 800] [[
  WELD-000900 2.0.0 (CR2)]]

[2013-05-23T15:08:34.987-0700] [glassfish 4.0] [WARNING] [] [org.jboss.weld.interceptor.util.InterceptionTypeRegistry] [tid: _ThreadID=34 _ThreadName=admin-listener(2)] [timeMillis: 1369346914987] [levelValue: 900] [[
  Class 'javax.ejb.PostActivate' not found, interception based on it is not enabled]]

[2013-05-23T15:08:34.988-0700] [glassfish 4.0] [WARNING] [] [org.jboss.weld.interceptor.util.InterceptionTypeRegistry] [tid: _ThreadID=34 _ThreadName=admin-listener(2)] [timeMillis: 1369346914988] [levelValue: 900] [[
  Class 'javax.ejb.PrePassivate' not found, interception based on it is not enabled]]

[2013-05-23T15:08:35.617-0700] [glassfish 4.0] [WARNING] [] [org.jboss.weld.Bootstrap] [tid: _ThreadID=34 _ThreadName=admin-listener(2)] [timeMillis: 1369346915617] [levelValue: 900] [[
  WELD-001473 javax.enterprise.inject.spi.Bean implementation org.glassfish.jms.injection.JMSCDIExtension$LocalBean@626186cf declared a normal scope but does not implement javax.enterprise.inject.spi.PassivationCapable. It won't be possible to inject this bean into a bean with passivating scope (@SessionScoped, @ConversationScoped). This can be fixed by assigning the Bean implementation a unique id by implementing the PassivationCapable interface.]]

[2013-05-23T15:08:35.645-0700] [glassfish 4.0] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=34 _ThreadName=admin-listener(2)] [timeMillis: 1369346915645] [levelValue: 1000] [[
  Exception during lifecycle processing
org.glassfish.deployment.common.DeploymentException: CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [Set<Service>] with qualifiers [@Default] at injection point [[BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject com.google.common.util.concurrent.ServiceManager(Set<Service>)]
	at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:225)
	at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
	at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
	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$1.run(CommandRunnerImpl.java:527)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:356)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
	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 com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
	at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
	at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
	at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:217)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:231)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:227)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:275)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:257)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:227)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:191)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:819)
	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
	at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:161)
	at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
	at java.lang.Thread.run(Thread.java:722)
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Set<Service>] with qualifiers [@Default] at injection point [[BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject com.google.common.util.concurrent.ServiceManager(Set<Service>)]
	at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:403)
	at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:325)
	at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:177)
	at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:208)
	at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:519)
	at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:505)
	at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:480)
	at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:536)
	at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:216)
	... 58 more
]]

[2013-05-23T15:08:35.648-0700] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=34 _ThreadName=admin-listener(2)] [timeMillis: 1369346915648] [levelValue: 1000] [[
  Exception while loading the app]]

[2013-05-23T15:08:35.649-0700] [glassfish 4.0] [SEVERE] [AS-WEB-GLUE-00192] [javax.enterprise.web] [tid: _ThreadID=34 _ThreadName=admin-listener(2)] [timeMillis: 1369346915649] [levelValue: 1000] [[
  Undeployment failed for context ]]

[2013-05-23T15:08:35.664-0700] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=34 _ThreadName=admin-listener(2)] [timeMillis: 1369346915664] [levelValue: 1000] [[
  Exception while loading the app : CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [Set<Service>] with qualifiers [@Default] at injection point [[BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject com.google.common.util.concurrent.ServiceManager(Set<Service>)]
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Set<Service>] with qualifiers [@Default] at injection point [[BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject com.google.common.util.concurrent.ServiceManager(Set<Service>)]
	at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:403)
	at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:325)
	at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:177)
	at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:208)
	at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:519)
	at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:505)
	at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:480)
	at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:536)
	at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:216)
	at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
	at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
	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$1.run(CommandRunnerImpl.java:527)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:356)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
	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 com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
	at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
	at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
	at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:217)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:231)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:227)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:275)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:257)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:227)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:191)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:819)
	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
	at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:161)
	at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
	at java.lang.Thread.run(Thread.java:722)
]]



 Comments   
Comment by aaronjwhiteside [ 24/May/13 ]

Tested on the latest nightly build, the issue still appears..

Below is the class in question.
http://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/util/concurrent/ServiceManager.java?r=824719231c4358700e669014a86987dea7341e3e

Comment by jjsnyder83 [ 24/May/13 ]

As per spec implicit CDI is enabled by default. To turn it off do the following

asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=false

Comment by aaronjwhiteside [ 24/May/13 ]

That sounds almost absurd (not blaming you personally).

There must be a way to specify to CDI what to scan and what not to scan. Enabling it by default without a way to control what is decides to scan and what it doesn't is going to cause a lot of issues with a lot of libraries.

Comment by jjsnyder83 [ 24/May/13 ]

We are working on enhancing this right now for GlassFish so that you can specify exactly which archives should not be processed by CDI (as per spec.) Keep an eye on https://java.net/jira/browse/GLASSFISH-20483.

Comment by aaronjwhiteside [ 28/May/13 ]

http://docs.jboss.org/weld/reference/latest/en-US/html/configure.html this does not seem to work.

If Glassfish is using WELD shouldn't this work?

my beans.xml contains:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:weld="http://jboss.org/schema/weld/beans"
       xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd
                           http://jboss.org/schema/weld/beans http://jboss.org/schema/weld/beans_1_1.xsd">

    <weld:scan>
        <weld:exclude name="com.google.**"/>
    </weld:scan>
</beans>
Comment by phil.zampino [ 19/Jun/13 ]

If you were to add a beans.xml, with the cited exclude config, to the guava jar, then you should see the behavior you're expecting.

Assuming that you don't want to modify the guava archive, I think you'll find the following asadmin deployment property to be useful:

--property implicitCdiEnabled=false

(Example: asadmin deploy --property implicitCdiEnabled=false <archive>)

This property will force the CDI 1.0 behavior wrt implicit bean discovery for the archive being deployed, rather than the aforementioned server-wide configuration.





[GLASSFISH-13131] Weld incorrect proxying extension Created: 26/Aug/10  Updated: 08/Jul/11  Resolved: 08/Jul/11

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1
Fix Version/s: 3.1_ms08

Type: Bug Priority: Critical
Reporter: sandoz Assignee: Sivakumar Thyagarajan
Resolution: Cannot Reproduce Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 13,131
Status Whiteboard:

weld-int-required

Tags: 3_1-exclude

 Description   

Weld is incorrectly proxy the Jersey CDI Extension implementation. This is a
place holder issue in GF as this is most like a bug in Weld rather than in the
Weld/GlassFish integration.

See here for the description of how to reproduce:

https://glassfish.dev.java.net/servlets/ReadMsg?listName=dev&msgNo=18459

The Jersey team have worked around this issue by using a horrible thread local
hack. The original behavior to reproduce the problem can be enabled by setting
the following system property to true:

com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager



 Comments   
Comment by sandoz [ 05/Oct/10 ]
      • Issue 13572 has been marked as a duplicate of this issue. ***
Comment by Sivakumar Thyagarajan [ 07/Oct/10 ]

Filed Weld issue https://jira.jboss.org/browse/WELD-712 to track this. It
appears to be a Weld issue. For more analysis into this, please read the initial
report in WELD-712.

Comment by Sivakumar Thyagarajan [ 07/Oct/10 ]

Fix would be available when we do the next integration of Weld. Expect this to
happen during MS7 and so marking the target milestone as MS07

Comment by sandoz [ 12/Oct/10 ]

I have just committed a fix to Jersey that uses a different work around in
attempt to avoid the NPE in Jersey. This workaround uses JNDI.

Comment by Sivakumar Thyagarajan [ 22/Oct/10 ]

Marking as weld-int-required

Comment by Sivakumar Thyagarajan [ 19/Nov/10 ]

Marking this as 3.1_ms08, as hopefully we would have the 1.1.RC1 by then.

Comment by Sivakumar Thyagarajan [ 22/Dec/10 ]

Marking this as 3_1-exclude as we did not have time to provide a test case outside GF. Have requested the Jersey team to resolve this via a workaround for this release. We will investigate this again in the 3.2 timeframe





[GLASSFISH-17184] Interceptors enabled randomly Created: 11/Aug/11  Updated: 12/Dec/11  Resolved: 10/Dec/11

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Jozef Hartinger Assignee: kshitiz_saxena
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java version "1.6.0_24"
Apache Maven 3.0.3
GF 3.1.1
Fedora 15


Tags: 3_1_2-review

 Description   

1.) Clone the Seam Compatibility repository git://github.com/seam/compatibility.git
2.) Start GlassFish 3.1.1
3.) Run mvn clean test -Dtest=EnableInterceptorStressTest -Pglassfish-remote-3.1

The EnableInterceptorStressTest runs a simple test that verifies interceptor enablement. This test is run 20 times. In each run, the testing application is redeployed. Out of these 20 runs, there are usually 5 - 15 failures indicating that the interceptor was not enabled in the deployment.

The problem is likely to get fixed by upgrading to Weld 1.1.2.



 Comments   
Comment by Sivakumar Thyagarajan [ 14/Nov/11 ]

Requesting Kshitiz to try to reproduce this with latest 3.1.2 workspace that already has Weld 1.1.3 and close it if it is not reproducible anymore.

Comment by kshitiz_saxena [ 07/Dec/11 ]

Interceptor stress test still fails on GlassFish 3.1.2. Currently GlassFish 3.1.2 has weld core 1.1.4.Final integrated into it.

[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Seam Compatibility Module 3.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] — maven-enforcer-plugin:1.0:enforce (seam-build-req) @ seam-compatibility —
[INFO]
[INFO] — build-helper-maven-plugin:1.5:maven-version (default) @ seam-compatibility —
[INFO]
[INFO] — build-helper-maven-plugin:1.5:parse-version (default) @ seam-compatibility —
[INFO]
[INFO] — maven-remote-resources-plugin:1.1:process (attach-license) @ seam-compatibility —
[INFO] Setting property: classpath.resource.loader.class => 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO]
[INFO] — maven-resources-plugin:2.4.3:resources (default-resources) @ seam-compatibility —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /space/workspace/glassfish/trunk/issues/cdi/17184/compatibility/src/main/resources
[INFO] Copying 2 resources
[INFO]
[INFO] — maven-compiler-plugin:2.3.1:compile (default-compile) @ seam-compatibility —
[INFO] No sources to compile
[INFO]
[INFO] — maven-resources-plugin:2.4.3:testResources (default-testResources) @ seam-compatibility —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources
[INFO] Copying 2 resources
[INFO]
[INFO] — maven-compiler-plugin:2.3.1:testCompile (default-testCompile) @ seam-compatibility —
[INFO] Compiling 1 source file to /space/workspace/glassfish/trunk/issues/cdi/17184/compatibility/target/test-classes
[INFO]
[INFO] — maven-surefire-plugin:2.6:test (default-test) @ seam-compatibility —
[INFO] Concurrency config is

{parallel=none, configurableParallelComputerPresent=false}

[INFO] Surefire report directory: /space/workspace/glassfish/trunk/issues/cdi/17184/compatibility/target/surefire-reports

-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running org.jboss.seam.compat.cdi.visibility.JarToJarAlphaVisibilityTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.02 sec <<< FAILURE!
Running org.jboss.seam.compat.jaxrs.provider.ProviderInjectionTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.006 sec <<< FAILURE!
Running org.jboss.seam.compat.scanning.ExtendedClassTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.007 sec <<< FAILURE!
Running org.jboss.seam.compat.jaxrs.interceptor.InterceptedResourceTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.012 sec <<< FAILURE!
Running org.jboss.seam.compat.cdi.alternative.AlternativeTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.006 sec
Running org.jboss.seam.compat.cdi.visibility.VisibilityOfBeanInWebModuleFromBeanManagerInBeanLibraryTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.009 sec <<< FAILURE!
Running org.jboss.seam.compat.jaxrs.provider.ApplicationInjectedIntoProviderTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.008 sec <<< FAILURE!
Running org.jboss.seam.compat.cdi.registration.VisibilityOfBeanRegisteredByExtensionFromNonBeanLibraryTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.011 sec <<< FAILURE!
Running org.jboss.seam.compat.cdi.alternative.AlternativeTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.009 sec <<< FAILURE!
Running org.jboss.seam.compat.cdi.visibility.VisibilityOfAnnotatedTypesFromExtensionInAlphaBeanArchiveTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.005 sec <<< FAILURE!
Running org.jboss.seam.compat.ejb.deployment.DeploymentOrderTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.005 sec <<< FAILURE!
Running org.jboss.seam.compat.cdi.visibility.VisibilityOfAnnotatedTypesFromExtensionInBravoBeanArchiveTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.005 sec <<< FAILURE!
Running org.jboss.seam.compat.cdi.packaging.ear.MultiWebAppTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.004 sec <<< FAILURE!
Running org.jboss.seam.compat.cdi.registration.BeanRegistrationByExtensionInNonBeanArchiveTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.005 sec <<< FAILURE!
Running org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
Tests run: 42, Failures: 0, Errors: 42, Skipped: 0, Time elapsed: 0.133 sec <<< FAILURE!
Running org.jboss.seam.compat.cdi.visibility.JarToJarReverseAlphaVisibilityTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.005 sec <<< FAILURE!
Running org.jboss.seam.compat.cdi.packaging.ear.SingleWebAppTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.006 sec <<< FAILURE!
Running org.jboss.seam.compat.scanning.ImportedClassTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.009 sec <<< FAILURE!
Dec 7, 2011 4:51:23 PM org.jboss.arquillian.impl.client.container.ContainerRegistryCreator getActivatedConfiguration
INFO: Could not read active container configuration: null

Results :

Tests in error:
org.jboss.seam.compat.cdi.visibility.JarToJarAlphaVisibilityTest
org.jboss.seam.compat.cdi.visibility.JarToJarAlphaVisibilityTest
org.jboss.seam.compat.jaxrs.provider.ProviderInjectionTest
org.jboss.seam.compat.jaxrs.provider.ProviderInjectionTest
org.jboss.seam.compat.scanning.ExtendedClassTest
org.jboss.seam.compat.scanning.ExtendedClassTest
org.jboss.seam.compat.jaxrs.interceptor.InterceptedResourceTest
org.jboss.seam.compat.jaxrs.interceptor.InterceptedResourceTest
org.jboss.seam.compat.cdi.visibility.VisibilityOfBeanInWebModuleFromBeanManagerInBeanLibraryTest
org.jboss.seam.compat.cdi.visibility.VisibilityOfBeanInWebModuleFromBeanManagerInBeanLibraryTest
org.jboss.seam.compat.jaxrs.provider.ApplicationInjectedIntoProviderTest
org.jboss.seam.compat.jaxrs.provider.ApplicationInjectedIntoProviderTest
org.jboss.seam.compat.cdi.registration.VisibilityOfBeanRegisteredByExtensionFromNonBeanLibraryTest
org.jboss.seam.compat.cdi.registration.VisibilityOfBeanRegisteredByExtensionFromNonBeanLibraryTest
org.jboss.seam.compat.cdi.alternative.AlternativeTest
org.jboss.seam.compat.cdi.alternative.AlternativeTest
org.jboss.seam.compat.cdi.visibility.VisibilityOfAnnotatedTypesFromExtensionInAlphaBeanArchiveTest
org.jboss.seam.compat.cdi.visibility.VisibilityOfAnnotatedTypesFromExtensionInAlphaBeanArchiveTest
org.jboss.seam.compat.ejb.deployment.DeploymentOrderTest
org.jboss.seam.compat.ejb.deployment.DeploymentOrderTest
org.jboss.seam.compat.cdi.visibility.VisibilityOfAnnotatedTypesFromExtensionInBravoBeanArchiveTest
org.jboss.seam.compat.cdi.visibility.VisibilityOfAnnotatedTypesFromExtensionInBravoBeanArchiveTest
org.jboss.seam.compat.cdi.packaging.ear.MultiWebAppTest
org.jboss.seam.compat.cdi.packaging.ear.MultiWebAppTest
org.jboss.seam.compat.cdi.registration.BeanRegistrationByExtensionInNonBeanArchiveTest
org.jboss.seam.compat.cdi.registration.BeanRegistrationByExtensionInNonBeanArchiveTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
org.jboss.seam.compat.cdi.visibility.JarToJarReverseAlphaVisibilityTest
org.jboss.seam.compat.cdi.visibility.JarToJarReverseAlphaVisibilityTest
org.jboss.seam.compat.cdi.packaging.ear.SingleWebAppTest
org.jboss.seam.compat.cdi.packaging.ear.SingleWebAppTest
org.jboss.seam.compat.scanning.ImportedClassTest
org.jboss.seam.compat.scanning.ImportedClassTest

Tests run: 75, Failures: 0, Errors: 74, Skipped: 1

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5:02.222s
[INFO] Finished at: Wed Dec 07 16:56:15 IST 2011
[INFO] Final Memory: 16M/81M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.6:test (default-test) on project seam-compatibility: There are test failures.
[ERROR]
[ERROR] Please refer to /space/workspace/glassfish/trunk/issues/cdi/17184/compatibility/target/surefire-reports for the individual test results.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException

Comment by kshitiz_saxena [ 10/Dec/11 ]

Finally able to run this test against GF 3.1.2

This testsuite is slightly outdated. For these tests to run against GF 3.1.2, the arquillian-glassfish-remote-3.1-1.0.0.Alpha5 need to be updated to add filter com.sun.jersey.api.client.filter.CsrfProtectionFilter to jersey client. I modified it locally and made it to work. After this change, with latest GF 3.1.2 this test work fine.

[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Seam Compatibility Module 3.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] — maven-enforcer-plugin:1.0:enforce (seam-build-req) @ seam-compatibility —
[INFO]
[INFO] — build-helper-maven-plugin:1.5:maven-version (default) @ seam-compatibility —
[INFO]
[INFO] — build-helper-maven-plugin:1.5:parse-version (default) @ seam-compatibility —
[INFO]
[INFO] — maven-remote-resources-plugin:1.1:process (attach-license) @ seam-compatibility —
[INFO] Setting property: classpath.resource.loader.class => 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO]
[INFO] — maven-resources-plugin:2.4.3:resources (default-resources) @ seam-compatibility —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /space/workspace/glassfish/trunk/issues/cdi/17184/compatibility/src/main/resources
[INFO] Copying 2 resources
[INFO]
[INFO] — maven-compiler-plugin:2.3.1:compile (default-compile) @ seam-compatibility —
[INFO] No sources to compile
[INFO]
[INFO] — maven-resources-plugin:2.4.3:testResources (default-testResources) @ seam-compatibility —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 4 resources
[INFO] Copying 2 resources
[INFO]
[INFO] — maven-compiler-plugin:2.3.1:testCompile (default-testCompile) @ seam-compatibility —
[INFO] Compiling 1 source file to /space/workspace/glassfish/trunk/issues/cdi/17184/compatibility/target/test-classes
[INFO]
[INFO] — maven-surefire-plugin:2.6:test (default-test) @ seam-compatibility —
[INFO] Concurrency config is

{parallel=none, configurableParallelComputerPresent=false}

[INFO] Surefire report directory: /space/workspace/glassfish/trunk/issues/cdi/17184/compatibility/target/surefire-reports

-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
Tests run: 20, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.049 sec
Dec 10, 2011 9:05:20 PM org.jboss.arquillian.impl.client.container.ContainerRegistryCreator getActivatedConfiguration
INFO: Could not read active container configuration: null

Results :

Tests run: 20, Failures: 0, Errors: 0, Skipped: 0

[INFO]
[INFO] — maven-jar-plugin:2.3.1:jar (default-jar) @ seam-compatibility —
[INFO] Building jar: /space/workspace/glassfish/trunk/issues/cdi/17184/compatibility/target/seam-compatibility-3.0.0-SNAPSHOT.jar
[INFO]
[INFO] >>> maven-source-plugin:2.1.2:jar (attach-sources) @ seam-compatibility >>>
[INFO]
[INFO] — maven-enforcer-plugin:1.0:enforce (seam-build-req) @ seam-compatibility —
[INFO]
[INFO] — build-helper-maven-plugin:1.5:maven-version (default) @ seam-compatibility —
[INFO]
[INFO] — build-helper-maven-plugin:1.5:parse-version (default) @ seam-compatibility —
[INFO]
[INFO] <<< maven-source-plugin:2.1.2:jar (attach-sources) @ seam-compatibility <<<
[INFO]
[INFO] — maven-source-plugin:2.1.2:jar (attach-sources) @ seam-compatibility —
[INFO] META-INF already added, skipping
[INFO] META-INF/DEPENDENCIES.txt already added, skipping
[INFO] META-INF/LICENSE.txt already added, skipping
[INFO] Building jar: /space/workspace/glassfish/trunk/issues/cdi/17184/compatibility/target/seam-compatibility-3.0.0-SNAPSHOT-sources.jar
[INFO] META-INF already added, skipping
[INFO] META-INF/DEPENDENCIES.txt already added, skipping
[INFO] META-INF/LICENSE.txt already added, skipping
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1:24.648s
[INFO] Finished at: Sat Dec 10 21:06:34 IST 2011
[INFO] Final Memory: 17M/81M
[INFO] ------------------------------------------------------------------------

Closing this issue ad not reproducible.

Will update this issue later with glassfish trunk result.

Comment by kshitiz_saxena [ 12/Dec/11 ]

On GlassFish trunk, further change was needed in arquillian-glassfish-remote-3.1-1.0.0.Alpha5 to generate list-sub-components REST url to be generated in following format :
http://localhost:4848/management/domain/applications/application/test/list-sub-components

After above change done locally, this test passed.

[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Seam Compatibility Module 3.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] — maven-enforcer-plugin:1.0:enforce (seam-build-req) @ seam-compatibility —
[INFO]
[INFO] — build-helper-maven-plugin:1.5:maven-version (default) @ seam-compatibility —
[INFO]
[INFO] — build-helper-maven-plugin:1.5:parse-version (default) @ seam-compatibility —
[INFO]
[INFO] — maven-remote-resources-plugin:1.1:process (attach-license) @ seam-compatibility —
[INFO] Setting property: classpath.resource.loader.class => 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO]
[INFO] — maven-resources-plugin:2.4.3:resources (default-resources) @ seam-compatibility —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /space/workspace/glassfish/trunk/issues/cdi/17184/compatibility/src/main/resources
[INFO] Copying 2 resources
[INFO]
[INFO] — maven-compiler-plugin:2.3.1:compile (default-compile) @ seam-compatibility —
[INFO] No sources to compile
[INFO]
[INFO] — maven-resources-plugin:2.4.3:testResources (default-testResources) @ seam-compatibility —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 4 resources
[INFO] Copying 2 resources
[INFO]
[INFO] — maven-compiler-plugin:2.3.1:testCompile (default-testCompile) @ seam-compatibility —
[INFO] Compiling 1 source file to /space/workspace/glassfish/trunk/issues/cdi/17184/compatibility/target/test-classes
[INFO]
[INFO] — maven-surefire-plugin:2.6:test (default-test) @ seam-compatibility —
[INFO] Concurrency config is

{parallel=none, configurableParallelComputerPresent=false}

[INFO] Surefire report directory: /space/workspace/glassfish/trunk/issues/cdi/17184/compatibility/target/surefire-reports

-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running org.jboss.seam.compat.cdi.interceptor.EnableInterceptorTest
Tests run: 20, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.051 sec
Dec 12, 2011 8:21:09 AM org.jboss.arquillian.impl.client.container.ContainerRegistryCreator getActivatedConfiguration
INFO: Could not read active container configuration: null

Results :

Tests run: 20, Failures: 0, Errors: 0, Skipped: 0

[INFO]
[INFO] — maven-jar-plugin:2.3.1:jar (default-jar) @ seam-compatibility —
[INFO] Building jar: /space/workspace/glassfish/trunk/issues/cdi/17184/compatibility/target/seam-compatibility-3.0.0-SNAPSHOT.jar
[INFO]
[INFO] >>> maven-source-plugin:2.1.2:jar (attach-sources) @ seam-compatibility >>>
[INFO]
[INFO] — maven-enforcer-plugin:1.0:enforce (seam-build-req) @ seam-compatibility —
[INFO]
[INFO] — build-helper-maven-plugin:1.5:maven-version (default) @ seam-compatibility —
[INFO]
[INFO] — build-helper-maven-plugin:1.5:parse-version (default) @ seam-compatibility —
[INFO]
[INFO] <<< maven-source-plugin:2.1.2:jar (attach-sources) @ seam-compatibility <<<
[INFO]
[INFO] — maven-source-plugin:2.1.2:jar (attach-sources) @ seam-compatibility —
[INFO] META-INF already added, skipping
[INFO] META-INF/DEPENDENCIES.txt already added, skipping
[INFO] META-INF/LICENSE.txt already added, skipping
[INFO] Building jar: /space/workspace/glassfish/trunk/issues/cdi/17184/compatibility/target/seam-compatibility-3.0.0-SNAPSHOT-sources.jar
[INFO] META-INF already added, skipping
[INFO] META-INF/DEPENDENCIES.txt already added, skipping
[INFO] META-INF/LICENSE.txt already added, skipping
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1:03.590s
[INFO] Finished at: Mon Dec 12 08:22:04 IST 2011
[INFO] Final Memory: 17M/81M
[INFO] ------------------------------------------------------------------------





[GLASSFISH-20049] Error when containing an EJB as WAR dependency in EAR Project Created: 26/Mar/13  Updated: 25/Apr/13  Resolved: 27/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b81
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: joshie007 Assignee: phil.zampino
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days
Environment:

Windows 7, NetBeans 7.3, GlassFish 4.0_b81


Tags: ejb, java_ee_7, maven

 Description   

I got an error, when I'm trying to put an EJB project to my Web Module as a dependency.
Here's the file:

web-module/pom.xml:
<dependency>
<groupId>com.jug.joglosemar</groupId>
<artifactId>gudeg7-ejb</artifactId>
<version>1.0-SNAPSHOT</version>
<scope>provided</scope>
</dependency>

ear-module/pom.xml:
<dependency>
<groupId>com.jug.joglosemar</groupId>
<artifactId>gudeg7-web</artifactId>
<version>1.0-SNAPSHOT</version>
<type>war</type>
</dependency>
<dependency>
<groupId>com.jug.joglosemar</groupId>
<artifactId>gudeg7-ejb</artifactId>
<version>1.0-SNAPSHOT</version>
<type>ejb</type>
</dependency>

Here's the stacktrace:
SEVERE: Exception while deploying the app [gudeg7-ear]
SEVERE: Exception during lifecycle processing
java.lang.StackOverflowError
at java.util.Random.nextInt(Random.java:239)
at sun.misc.Hashing.randomHashSeed(Hashing.java:254)
at java.util.HashMap.<init>(HashMap.java:255)
at java.util.HashMap.<init>(HashMap.java:305)
at java.util.HashSet.<init>(HashSet.java:103)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:237)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:221)
at org.glassfish.weld.connector.WeldUtils.isCDIEnablingAnnotation(WeldUtils.java:250)

SEVERE: Exception while deploying the app [gudeg7-ear]



 Comments   
Comment by marina vatkina [ 26/Mar/13 ]

StackOverflowError in Weld code

Comment by phil.zampino [ 26/Mar/13 ]

This was fixed recently. Please re-test.

Comment by joshie007 [ 27/Mar/13 ]

Hi all,

Now I've done some re-test. And I think that I should add CDI-api 1.1 in my dependency.
It solved my problem, so thank you.

This issue is solved.

Comment by jjsnyder83 [ 27/Mar/13 ]

FIxed in CDI 1.1





[GLASSFISH-19581] Random regression: @Resource DataSource injection is not working when CDI is enabled Created: 24/Jan/13  Updated: 27/Mar/13  Resolved: 27/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: marina vatkina Assignee: jwells
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

See e.g. http://hudson-sca.us.oracle.com/job/ejb-devtests-trunk/1905/

The failing test is ejb31/full/jcdifull (but Hong noticed that you might need to run all tests under ejb31/full to reproduce the error condition).

From the console output:

deploy-jar-common:
[exec] asadmin --host localhost --port 60836 --user anonymous --passwordfile <http://hudson-sca.us.oracle.com/job/ejb-devtests-trunk/ws/appserv-tests/config/adminpassword.txt> --interactive=false --echo=true --terse=true deploy --force=false --precompilejsp=false --verify=false --generatermistubs=false --availabilityenabled=false --asyncreplication=true --target server --keepreposdir=false --keepfailedstubs=false --isredeploy=false --logreportederrors=true --_classicstyle=false --upload=true <http://hudson-sca.us.oracle.com/job/ejb-devtests-trunk/ws/appserv-tests/build/module/archive/ejb-ejb31-full-jcdifull-ejb.jar>
[exec] remote failure: Error occurred during deployment: Exception while loading the app : javax.ejb.CreateException: Initialization failed for Singleton SingletonBeanA. Please see server.log for more details.

And in server.log:
Caused by: org.jboss.weld.exceptions.WeldException: WELD-000049 Unable to invoke [method] @PostConstruct public com.acme.Bar.init() on Bar
at org.jboss.weld.bean.AbstractClassBean.defaultPostConstruct(AbstractClassBean.java:404)
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.postConstruct(ManagedBean.java:174)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:294)
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:68)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:608)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:674)
at org.jboss.weld.injection.ParameterInjectionPoint.getValueToInject(ParameterInjectionPoint.java:120)
at org.jboss.weld.injection.ConstructorInjectionPoint.getParameterValues(ConstructorInjectionPoint.java:170)
at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:117)
at org.jboss.weld.bean.SessionBean.createInstance(SessionBean.java:213)
at org.jboss.weld.bean.SessionBean$SessionBeanInjectionTarget.produce(SessionBean.java:202)
at org.glassfish.weld.services.JCDIServiceImpl._createJCDIInjectionContext(JCDIServiceImpl.java:182)
at org.glassfish.weld.services.JCDIServiceImpl.createJCDIInjectionContext(JCDIServiceImpl.java:150)
at com.sun.ejb.containers.BaseContainer.createEjbInstanceAndContext(BaseContainer.java:1632)
at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:418)
... 56 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:267)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:263)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invoke(WeldMethodImpl.java:174)
at org.jboss.weld.bean.AbstractClassBean.defaultPostConstruct(AbstractClassBean.java:402)
... 70 more
Caused by: javax.ejb.EJBException: ds is null
at com.acme.Bar.init(Bar.java:26)
... 80 more

The Bar.java in its @PostConstruct checks the 'ds' value injected via

@Resource(name="jdbc/__default") javax.sql.DataSource ds;



 Comments   
Comment by marina vatkina [ 24/Jan/13 ]

Note that this failure was observed on every other build starting 1/18, with the exceptions of failed builds in the last several days because of an error in embedded-static.shell.jar that had been fixed today.

Comment by Tom Mueller [ 15/Feb/13 ]

Reassigning to component lead as the assignee is no longer with the project.

Comment by guojun.shan [ 21/Feb/13 ]

find this error message in server.log:
[#|2013-02-21T16:02:16.853+0800|SEVERE|glassfish 4.0||_ThreadID=404;_ThreadName=Thread-4;_TimeMillis=1361433736853;_LevelValue=1000;|No valid EE environment for injection of com.acme.Bar|#]

Comment by guojun.shan [ 25/Feb/13 ]

in InjectionServicesImpl#aroundInject componentEnv == null
because in ComponentEnvManagerImpl#getCurrentJndiNameEnvironment invMgr.getCurrentInvocation()==null

Comment by guojun.shan [ 15/Mar/13 ]

Now I know the exact case of failure:
Both SingletonBeanA.java and SingletonBean2.java are defined @Startup, so they will both be initialized when deployed.
If SingletonBeanA is init first, it will deployed failed. Otherwise, it pass. If you remove @startup from SingletonBean2 it will always failed.

So CDI may not support this kind of case.

Comment by guojun.shan [ 15/Mar/13 ]

BTW, it seems there is no InvocationManager.preInvoke() before InjectionServicesImpl#aroundInject for the failed case.

Comment by guojun.shan [ 21/Mar/13 ]

Could you re-assign to the proper developer for this issue?thanks.

Comment by jwells [ 26/Mar/13 ]

Here is a simple set of two classes that always has this issue:

// @Singleton
// @Startup
public class JRW {

@Resource(name="jdbc/__default") javax.sql.DataSource ds;

public JRW()

{ System.out.println("Constructed::JRW " + System.identityHashCode(this)); }

@PostConstruct
public void init()

{ System.out.println("JRW ds inject = " + ds); }

public String toString()

{ return "JRW"; }

public void callMe() {
}

}

and:

@Singleton
@Startup
public class JRW2 {

private final JRW jrw;

@Inject
public JRW2(JRW jrw)

{ this.jrw = jrw; System.out.println("Constructed::JRW2 " + System.identityHashCode(this)); }

@PostConstruct
public void init()

{ jrw.callMe(); System.out.println("JRW2 jrw = " + jrw); }

public String toString()

{ return "JRW2"; }

}

In the "failing" case you will see the printout:

JRW ds inject = null

in the server.log (along with the above mentioned message in the log file).

Here are interesting observations:

1. If you instead use field injection in JRW2 (injecting JRW rather than sending it in via the constructor) then this case works
2. If you make JRW an @Singleton then this case works

So this is not random. Now that I have a consistent reproducer I'll look into why this is failing...

Comment by jwells [ 27/Mar/13 ]

Commit 60958 fixes the issue by ensuring a proper EJB context when creating EJBs in both the CDI and non-CDI cases.





[GLASSFISH-20312] com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/* cts tests are failing when running imq.xml target in CTS. Created: 15/Apr/13  Updated: 25/Apr/13  Resolved: 19/Apr/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0

Type: Bug Priority: Critical
Reporter: saradak Assignee: phil.zampino
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/ CTS tests are failing when run imq.xml target in CTS.

steps to reproduce the problem:

1. Download CTS bundle & internal bundle.
2. Follow the CTS instructions to set the variables.
3. cd $TS_HOME/bin
4. Run ant -f imq.xml smoke (this target runs all jms related tests across the CTS bundle).

Tests results are not consistent.
com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/ tests are failing in the test run. Test prints "Fail: we didnt get the expected msg back!" error.



 Comments   
Comment by marina vatkina [ 15/Apr/13 ]

Let's start with the jms container. The MDB container just reacts to the invocations

Comment by David Zhao [ 16/Apr/13 ]

Marina,

This doesn't seem to be JMS issue. The message sending/receiving is fine.

When debugging the failed CTS cases, I observed something interesting with the interceptor. If putting breakpoint in @AroundInvoke InterceptorMDB1.intercept1(InvocationContext ctx), I can see InvocationContext ctx is org.jboss.weld.interceptor.proxy.InterceptorInvocationContext@76cad8,

ctx.parameters is [EjbInvocation componentId=mdb_interceptor_listener_annotated_mdb_interceptor_listener_annotated_ejb.jar_AroundInvokeBean_MDB_QUEUE89528542497144832,isLocal=false,isRemote=false,isBusinessInterface=false,isWebService=false,isMessageDriven=true,isHome=false,clientInterface=null,method=public abstract void javax.jms.MessageListener.onMessage(javax.jms.Message),ejb=com.sun.ts.tests.ejb30.bb.mdb.interceptor.listener.annotated.AroundInvokeBean@7dc937,exception=null,exceptionFromBeanMethod=null,invId=0,wasCancelCalled=false,yetToSubmitStatus=true]

ctx.method is protected void com.sun.ts.tests.ejb30.common.interceptor.AroundInvokeTestMDBImpl.getMethodTest(javax.interceptor.InvocationContext)

But ctx.method is expected to be onMessage and ctx.parameters is expected to javax.jms.Message because the interceptor is on MDB (Refer to http://docs.oracle.com/javaee/6/api/javax/interceptor/InvocationContext.html).

ctx.target and ctx.contextData might have the same problem too.

Let's firstly make the InvocationContext carrying correct values then check the CTS cases again.

Comment by saradak [ 16/Apr/13 ]

These failures can be easily produced by just running ejb30/bb/mdb tests.

cd $TS_HOME/bin/
$TS_HOME/tools/ant/bin/ant config.vi.javadb
cd $TS_HOME/src/com/sun/ts/tests/ejb30/bb/mdb

$TS_HOME/tools/ant/bin/ant runclient

Comment by saradak [ 16/Apr/13 ]

I have run the same tests with b84-04_10_2013 build & b85-04_15_2013 nightly build.
Few observations when running with both the builds.

b84-04_10_2013
----------------

1. Following tests failed when run the tests as it is:

FAILED........com/sun/ts/tests/ejb30/bb/mdb/dest/fullpath/Client.java#test1
FAILED........com/sun/ts/tests/ejb30/bb/mdb/dest/jarwar/Client.java#test1
FAILED........com/sun/ts/tests/ejb30/bb/mdb/dest/onejar/Client.java#test1
FAILED........com/sun/ts/tests/ejb30/bb/mdb/dest/optional/Client.java#test1
FAILED........com/sun/ts/tests/ejb30/bb/mdb/dest/optional2/Client.java#test1
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/annotated/Client.java#getBeanTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/annotated/Client.java#getContextDataTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/annotated/Client.java#getMethodTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/annotated/Client.java#getParametersTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/annotated/Client.java#orderTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/annotated/Client.java#sameInvocationContextTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/annotated/Client.java#setParametersTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/descriptor/Client.java#getBeanTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/descriptor/Client.java#getContextDataTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/descriptor/Client.java#getMethodTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/descriptor/Client.java#getParametersTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/descriptor/Client.java#orderTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/descriptor/Client.java#sameInvocationContextTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/descriptor/Client.java#setParametersTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/annotated/Client.java#getBeanTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/annotated/Client.java#getContextDataTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/annotated/Client.java#getMethodTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/annotated/Client.java#getParametersTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/annotated/Client.java#sameSecContextTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/annotated/Client.java#setParametersTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/descriptor/Client.java#getBeanTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/descriptor/Client.java#getContextDataTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/descriptor/Client.java#getMethodTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/descriptor/Client.java#getParametersTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/descriptor/Client.java#sameSecContextTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/descriptor/Client.java#setParametersTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/listenerintf/implementing/externalizable/Client.java#test1
FAILED........com/sun/ts/tests/ejb30/bb/mdb/listenerintf/implementing/serializable/Client.java#test1

2. All tests passed after I put com/sun/ts/tests/ejb30/bb/mdb/customlistener/Client.java#isPostConstructCalledTest
in the CTS exclude list.

b85-04_15_2013
----------------
1. Following tests failed when run the tests as it is:

FAILED........com/sun/ts/tests/ejb30/bb/mdb/dest/fullpath/Client.java#test1
FAILED........com/sun/ts/tests/ejb30/bb/mdb/dest/jarwar/Client.java#test1
FAILED........com/sun/ts/tests/ejb30/bb/mdb/dest/onejar/Client.java#test1
FAILED........com/sun/ts/tests/ejb30/bb/mdb/dest/optional/Client.java#test1
FAILED........com/sun/ts/tests/ejb30/bb/mdb/dest/optional2/Client.java#test1
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/annotated/Client.java#getBeanTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/annotated/Client.java#getContextDataTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/annotated/Client.java#getMethodTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/annotated/Client.java#getParametersTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/annotated/Client.java#orderTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/annotated/Client.java#sameInvocationContextTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/annotated/Client.java#setParametersTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/descriptor/Client.java#getBeanTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/descriptor/Client.java#getMethodTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/descriptor/Client.java#getParametersTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/descriptor/Client.java#orderTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/descriptor/Client.java#sameInvocationContextTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/annotated/Client.java#getBeanTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/annotated/Client.java#getContextDataTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/annotated/Client.java#getMethodTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/annotated/Client.java#getParametersTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/annotated/Client.java#sameSecContextTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/annotated/Client.java#setParametersTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/descriptor/Client.java#getBeanTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/descriptor/Client.java#getContextDataTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/descriptor/Client.java#getMethodTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/descriptor/Client.java#getParametersTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/descriptor/Client.java#sameSecContextTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/method/descriptor/Client.java#setParametersTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/listenerintf/implementing/externalizable/Client.java#test1

2. Following tests failed after putting the test com/sun/ts/tests/ejb30/bb/mdb/customlistener/Client.java#isPostConstructCalledTest in exclude list.

FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/annotated/Client.java#getContextDataTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/annotated/Client.java#getMethodTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/annotated/Client.java#getParametersTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/annotated/Client.java#orderTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/annotated/Client.java#sameInvocationContextTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/annotated/Client.java#setParametersTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/descriptor/Client.java#getBeanTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/descriptor/Client.java#getContextDataTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/descriptor/Client.java#getMethodTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/descriptor/Client.java#getParametersTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/descriptor/Client.java#orderTest

Comment by marina vatkina [ 16/Apr/13 ]

Does the test pass if you disable CDI scanning?

Comment by saradak [ 16/Apr/13 ]


I have been using default glassfish settings. What should I set to disable CDI scanning?

Comment by marina vatkina [ 16/Apr/13 ]

asadmin create-module-config cdi-service
asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=false

Comment by marina vatkina [ 17/Apr/13 ]

the MDB was always receiving five messages, and those mesages arrived at the queue at right time, so the QueueReceiver.recieveNoWait() call consumed those messages, now with latest builds the messages arrive late and hence we see this problem.

Comment by saradak [ 17/Apr/13 ]

I ran the ejb30/bb/mdb tests after CTS test fixes but still seeing 6 test failures. we should address the issue that David mentioned in the bug report regarding interceptor failures.

FAILED........com/sun/ts/tests/ejb30/bb/mdb/dest/fullpath/Client.java#test1
FAILED........com/sun/ts/tests/ejb30/bb/mdb/dest/jarwar/Client.java#test1
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/annotated/Client.java#getMethodTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/annotated/Client.java#getParametersTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/descriptor/Client.java#getMethodTest
FAILED........com/sun/ts/tests/ejb30/bb/mdb/interceptor/listener/descriptor/Client.java#getParametersTest

Comment by marina vatkina [ 17/Apr/13 ]

Assigning to CDI team to investigate wrong invocation types from Weld

Comment by jjsnyder83 [ 18/Apr/13 ]

Phil is already looking into this.

Comment by phil.zampino [ 19/Apr/13 ]

I've raised this issue with Weld, since it appears that they are not propagating InvocationContext parameters correctly.

Comment by shreedhar_ganapathy [ 19/Apr/13 ]

Any chance of getting the fix before next promoted build ? i.e wed 24th?
RC testing is beginning and we need fixes to go in before that.

Comment by arjavdesai [ 19/Apr/13 ]

Most of the issues reported at the start are fixed in latest glassfish build. The reminder of issues are being tracked by http://java.net/jira/browse/GLASSFISH-20359 so resolving this one.





[GLASSFISH-15148] PostConstruct methods not handled properly for managed beans Created: 13/Dec/10  Updated: 19/Mar/13  Resolved: 19/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: V3
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: Bill Shannon Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude, req-weld-fix

 Description   

In general, handling of PostConstruct methods for managed beans isn't properly taking into
account method overriding. This works for EJBs, but the implementation needs to be generalized
to handle managed beans as well.

Here's a case that fails:

@ManagedBean
public class MBBean extends MBBase {
@PostConstruct
public void postConstruct() {
}
}

public class MBBase {
@PostConstruct
public void postConstruct() {
}
}

The postConstruct method will be called twice.

Similarly, if a method hides a PostConstruct method in a superclass,
the method will still be called.

The same issues probably apply to preDestroy methods.



 Comments   
Comment by Hong Zhang [ 13/Dec/10 ]

Will look in the future release (not sure who takes the ownership of ManagedBean now (used to be Ken), will keep the issue to me for now).

Comment by Cheng Fang [ 16/Feb/11 ]

This problem only exists for ManagedBean when CDI is enabled, e.g., when beans.xml is present. When subclass overrides PostConstruct method with PostConstruct method, it should only be invoked once, but it is currently invoked twice. When subclass overrides with non-PostConstruct method, it should not be invoked as a lifecycle method, but currently it is still invoked.

For PreDestroy, when subclass overrides with a PreDestroy method, it's incorrectly invoked twice. When subclass overrides with a non-PreDestroy method, it is not invoked as expected, but the new PreDestroy method added in subclass is also skipped.

For EJB, all of these cases work correctly, with or without beans.xml.

Comment by Hong Zhang [ 16/Feb/11 ]

Thanks Cheng for the analysis. I will let Siva take a look

Comment by jjsnyder83 [ 15/Oct/12 ]

There is a Weld issue for this bug: https://issues.jboss.org/browse/WELD-1225

Comment by phil.zampino [ 19/Mar/13 ]

This was resolved by Weld.





[GLASSFISH-14831] InterceptorBinding not working for EJB Created: 20/Nov/10  Updated: 15/Dec/10  Resolved: 13/Dec/10

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Sivakumar Thyagarajan
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: File GLASSFISH-14831.diff     Zip Archive interceptor-ejb-cdi-test-working.zip     Zip Archive interceptor-ejb-cdi-test.zip    
Issuezilla Id: 14,831

 Description   

This issue is filed subsequent to the discussion in issue 13513 . It seems CDI
interceptor bindings are not working for EJBs. I have simplified the test case
from issue 13513 to remove OSGi from the picture and converted it to a simple
web application with a Servlet calling a local EJB which has some interceptors
as shown below;

@WebServlet(urlPatterns="/*")
public class MyServlet extends HttpServlet {
@EJB UserService svc;

public void service(ServletRequest req, ServletResponse res)

{ svc.findById(0); // call the ejb }

}

@Stateless
@Secure // interceptor binding
@Local
public class UserServiceImpl implements UserService {

public User findById(long userId) throws EJBException {
...
LOG.log(Level.INFO, "Returning user

{0}", u);
}
}

@Inherited
@Target({ TYPE, METHOD })
@Retention(RUNTIME)
@InterceptorBinding
public @interface Secure
{}

@Secure
@Interceptor
public class SecurityInterceptor implements Serializable
{
@AroundInvoke
protected Object invoke(final InvocationContext ctx) throws Exception
{
...
LOG.log(Level.INFO, "EJB Method called [Full]:\"{0}

\" by Principal:

{1}",
new Object[]{getFullEJBClassName(interfaceMethod), p.toString()});
LOG.log(Level.INFO, "EJB Method called [Methodonly]:{0} by
Principal:{1}

", new Object[]

{interfaceMethod.getName(), p.toString()}

);

return ctx.proceed();
}
}

If unzip the attached interceptor-ejb-cdi-test.zip, it creates
interceptor-ejb-cdi-test directory. Try the following:
cd interceptor-ejb-cdi-test
./run.sh (this will compile, deploy and run the servlet)
See the server.log, you shall not find any message from the interceptor.

Now, open
./WEB-INF/classes/org/glassfish/cditest/user/impl/UserServiceImpl.java,
uncomment the following line:
@javax.interceptor.Interceptors(org.glassfish.cditest.security.interceptor.SecurityInterceptor.class)

and run ./run.sh again. This time in server.log, you shall see interceptor
message. As per the javadocs[1]:
"If the target class is a CDI bean, by annotating both the interceptor class and
the target class with an interceptor binding. "

and as per CDI javadoc [2]:

"Interceptors may be bound to any managed bean that is not itself an
interceptor or decorator or to any EJB session or message-driven bean. An
interceptor that is annotated @Interceptor may be identified by its interceptor
bindings."

[1]
http://download.oracle.com/javaee/6/api/javax/interceptor/package-summary.html#package_description
[2]
http://download.oracle.com/javaee/6/api/javax/enterprise/inject/package-summary.html



 Comments   
Comment by Sanjeeb Sahoo [ 20/Nov/10 ]

Created an attachment (id=5555)
Test case. Unzip, cd interceptor-ejb-cdi-test; ./run.sh

Comment by chaoslayer [ 21/Nov/10 ]

Thanks for this bug.

Is there a chance that this can be fixed for MS7?

Comment by Sivakumar Thyagarajan [ 05/Dec/10 ]

Thanks for the usecase. I have added devtests corresponding to these to track regressions at:
interceptors/interceptors-use-of-interceptors-in-ejbs-through-at-interceptors
interceptors/interceptors-use-of-interceptors-in-ejbs-through-interceptor-bindings

Resolved as commit 43464. The EJBServices implementation of GlassFish was not handling duplicate Interceptor registrations.

svn log -v -r 43464

Comment by Sivakumar Thyagarajan [ 05/Dec/10 ]

svn log -v -r 43464

Comment by Sanjeeb Sahoo [ 12/Dec/10 ]

No, I am still seeing the issue. I am using a locally built glassfish corresponding to svn rev 43731, which is very latest. I don't see the interceptor getting called unless I add the interceptors explicitly in my EJB like this:

@javax.interceptor.Interceptors(org.glassfish.cditest.security.interceptor.SecurityInterceptor.class)

Given below are the messages in my server.log with the above workaround:

[#|2010-12-13T08:53:29.810+0530|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=80;_ThreadName=admin-thread-pool-4848(2);|interceptor-ejb-cdi-test was successfully deployed in 693 milliseconds.|#]

[#|2010-12-13T08:53:29.881+0530|INFO|glassfish3.1|org.glassfish.cditest.security.interceptor.SecurityInterceptor|_ThreadID=112;_ThreadName=http-thread-pool-8080(2);|EJB Method called [Full]:"javax.ejb" by Principal:ANONYMOUS|#]

[#|2010-12-13T08:53:29.881+0530|INFO|glassfish3.1|org.glassfish.cditest.security.interceptor.SecurityInterceptor|_ThreadID=112;_ThreadName=http-thread-pool-8080(2);|EJB Method called [Methodonly]:findById by Principal:ANONYMOUS|#]

[#|2010-12-13T08:53:29.881+0530|INFO|glassfish3.1|org.glassfish.cditest.user.api.UserService|_ThreadID=112;_ThreadName=http-thread-pool-8080(2);|Returning user UserImpl [id=0, emailAddress=test@test.org, firstName=John, gender=UNISEX, lastName=Doe, username=john-123]|#]

Without the workaround, my log only contains:

[#|2010-12-13T08:49:43.122+0530|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=82;_ThreadName=admin-thread-pool-4848(4);|interceptor-ejb-cdi-test was successfully deployed in 5,726 milliseconds.|#]

[#|2010-12-13T08:50:10.275+0530|INFO|glassfish3.1|org.glassfish.cditest.user.api.UserService|_ThreadID=111;_ThreadName=http-thread-pool-8080(1);|Returning user UserImpl [id=0, emailAddress=test@test.org, firstName=John, gender=UNISEX, lastName=Doe, username=john-123]|#]

Note the missing log lines for entries "EJB Method..." in the above output.

Comment by Sivakumar Thyagarajan [ 13/Dec/10 ]

There was a problem in the attached application. I had fixed it in my local setup to get it working and forgot to include it earlier.
The application's beans.xml had the interceptors element commented out and hence no interceptors were enabled for that application. Similarly the application's beans.xml also had an older interceptor class-name.

After making both these changes and redeploying the application, the "EJB Method ..." interceptor related lines appear. Diff for these changes is attached. I am closing this issue. Please reopen should you still see the issue. Thanks.

Comment by Sivakumar Thyagarajan [ 13/Dec/10 ]

Attaching the working files and the diff to the original application

Comment by chaoslayer [ 13/Dec/10 ]

I made the changes mentioned (and understand why this was an issue) but I still get this exception when I try to separate security API, security interceptor implementation and the service EJB that should be secured into different bundles (this is with promoted b32):

SEVERE: Exception while loading the app
INFO: Deleted /tmp/osgiapp8129508894913510425
SEVERE: Failed while deploying bundle org.glassfish.cditest.user.impl [281]
WARNING: Failed to deploy bundle org.glassfish.cditest.user.impl [281]
org.glassfish.osgijavaeebase.DeploymentException: Deployment of org.glassfish.cditest.user.impl [281] failed because of following reason: Failed while deploying bundle org.glassfish.cditest.user.impl [281] : java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.cditest.user.impl [281] ], root cause: Exception while loading the app
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:125)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:147)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:132)
at org.glassfish.osgijavaeebase.JavaEEExtender.handleEvent(JavaEEExtender.java:117)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$000(JavaEEExtender.java:56)
at org.glassfish.osgijavaeebase.JavaEEExtender$1.run(JavaEEExtender.java:100)
Caused by: java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.cditest.user.impl [281] ], root cause: Exception while loading the app
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:196)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:121)
... 5 more
Caused by: org.glassfish.deployment.common.DeploymentException: WELD-001417 Enabled interceptor class <class>org.glassfish.cditest.security.impl.SecurityInterceptor</class> in bundle://281.1:1/META-INF/beans.xml@8 is neither annotated @Interceptor nor registered through a portable extension
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:187)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:302)
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.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:183)
... 7 more
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001417 Enabled interceptor class <class>org.glassfish.cditest.security.impl.SecurityInterceptor</class> in bundle://281.1:1/META-INF/beans.xml@8 is neither annotated @Interceptor nor registered through a portable extension
at org.jboss.weld.bootstrap.Validator.validateEnabledInterceptorClasses(Validator.java:471)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:344)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:383)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:184)
... 12 more

Comment by Sanjeeb Sahoo [ 14/Dec/10 ]

Let's discuss the new issue in 15119.





[GLASSFISH-13876] CDI should use the JMS natively Created: 08/Oct/10  Updated: 07/Nov/12  Resolved: 07/Nov/12

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1
Fix Version/s: 4.0

Type: Improvement Priority: Major
Reporter: casmeiron Assignee: jjsnyder83
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows 7
Platform: All


Issuezilla Id: 13,876

 Description   

All events should be dispatched through JMS natively, without any further
configuration.

I think, GF should bring a connection factory and topic to dispatch all events (or
the user can create these resources and specify the names in the sun-web.xml
file?).

So when I fire up some event, it have to go via JMS, adding this way the
persistence feature for events.



 Comments   
Comment by marina vatkina [ 08/Oct/10 ]

Requesting input from CDI

Comment by Sivakumar Thyagarajan [ 11/Oct/10 ]

Marking this as an RFE as discussed in thread
http://old.nabble.com/CDI-Events-through-JMS-to29717554.html

The current workaround is to use Seam's JMS module to achieve this.

Comment by Sivakumar Thyagarajan [ 15/Oct/12 ]

Marking fix version as "not determined".

Comment by michael.y.chen [ 06/Nov/12 ]

JJ took over CDI from Siva.

Comment by jjsnyder83 [ 07/Nov/12 ]

I spoke with Nigel Deakin...This is a matter for the JMS or EE spec.





[GLASSFISH-12623] EJB embedded handles libraries incorrectly Created: 12/Jul/10  Updated: 20/Mar/13  Resolved: 20/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: szczyp Assignee: jjsnyder83
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive test-ejb.zip    
Issuezilla Id: 12,623
Tags: 3_1-exclude

 Description   

Hi. I am trying to use EJB embedded for my tests. The scenario is this:

  • I have a maven project that uses TestNG 5.11 as the testing framework
  • I am using GlassFish 3.1 build 07 for the tests
  • there exists only one EJB in src/main/java
  • there is a single test class in src/test/java that starts the container
    (@BeforeClass), tests the EJB, and stops the container (@AfterClass)

The test run fails with the following exception:
Jul 12, 2010 4:57:56 PM com.sun.logging.LogDomains$1 log
SEVERE: Exception while deploying the app
java.lang.IllegalArgumentException: Sniffers with type [ejb] and type
[appclient] should not claim the archive at the same time. Please check the
packaging of your archive
[/home/rafal/EclipseWorkspaces/Workspace/test-ejb/gfembed8210337129653331178tmp/applications/classes]

So, the deployment fails to see that this is an EJB jar. However, I fail to see
why - I debugged and while the container starts it find modules and libraries,
and it correctly categorizes the 'classes' module as EJB, and testng-5.11.jar as
library, as can be seen below:

Jul 12, 2010 4:57:54 PM com.sun.logging.LogDomains$1 log
INFO: ... skipping... glassfish-embedded-all-3.1-b07.jar
Jul 12, 2010 4:57:54 PM com.sun.logging.LogDomains$1 log
INFO: [DeploymentElement] adding library to ScatteredArchive test-classes
Jul 12, 2010 4:57:54 PM com.sun.logging.LogDomains$1 log
INFO: [DeploymentElement] adding library to ScatteredArchive testng-5.11-jdk15.jar
Jul 12, 2010 4:57:54 PM com.sun.logging.LogDomains$1 log
INFO: [DeploymentElement] adding EJB module to ScatteredArchive classes

(this can also be seen when one debugs)

However, when it deploys, a temp Glassgish directory is created
(gfembed1341086153509304608tmp or similar), and within it
'applications/classes', where classes corresponds to my EJB archive I suppose.
Inside, I can see that not only my classes is there, but also the whole TestNG
jar is exploded and my classes and TestNG's are mangled together, thrown into
one bag. The problem is that TestNG contains Main-Class in its MANIFEST.MF file,
which makes GF confused.

Question: why are the project classes and dependency jar classes exploded and
mangled together? I added one more dependency and it is also expanded inside
classes. I think such EJB with dependencies should be packaged inside a temp EAR
within its 'lib' directory? I tested what happens if I add another dependency
that is a EJB jar, but no change. Also, when dependencies are expanded in such a
way, they can overwrite each others resources. Most of the time this might not
be a problem, but each CDI bean module is required to have META-INF/beans.xml -
and now it's starting to get scary...

Ok, so I added META-INF/ejb-jar.xml to my project so that it is treated
accordingly - I read somewhere that the sniffers might need that. Now, the test
run fails again, this time saying that testng-5.11.jar is both an EJB module and
appclient:

SEVERE: Exception while deploying the app
java.lang.IllegalArgumentException: Sniffers with type [ejb] and type
[appclient] should not claim the archive at the same time. Please check the
packaging of your archive
[/home/rafal/EclipseWorkspaces/Workspace/test-ejb/gfembed197260800230718800tmp/applications/testng-5.11-jdk15]

Note that suddenly the application changed the name from 'classes' to
'testng-5.11-jdk15'. Again, the same story - the expanded classes have
META-INF/MANIFEST.MF that comes from TestNG and it has the Main-Class entry.
Again, the same question - why a library (again, correctly classified as a
library one step before deployment) is messing the whole deployment, even change
the name of the whole application?

Finally, I went to my local maven repo and removed the Main-Class entry from
TestNG jar. It worked, but the EJB lookup failed as it requires
'java:global/testng-5.11-jdk15/TestEJB', instead of the correct
'java:global/classes/TestEJB'. The name of the application seems to be changing
if I introduce more dependencies, I don't see any rule for that, though. What is
more, with many dependencies, I noticed that the application name changes from
run to run, which makes it completely unusable.

The libraries should not be expanded like they are now as they completely
confuse GF. Many libraries (like JExcel API, the one that I used here as well to
test if it only TestNG is expanded, but also many many more) do include the
Main-Class entry, and going here and there in the repo deleting this is not a
solution. Libraries also have influence on the name of the whole temporary
deployed application, which should not be the case.

I am about to attach the test case. It is a maven 2 application, but it
shouldn't be a problem as GF 3.1-b07 is itself built using maven.



 Comments   
Comment by szczyp [ 12/Jul/10 ]

Created an attachment (id=4563)
test case

Comment by szczyp [ 12/Jul/10 ]

The attached test case is also an Eclipse project created using Eclipse 3.6
(Helios) final.

Comment by szczyp [ 12/Jul/10 ]

I found a workaround for the attached test case:

  • do NOT create the src/main/resources/META-INF/ejb-jar.xml file
  • as noted before, remove Main-Class entries from all dependent jars...

And not it works - the app name stays 'classes' and the lookup works.
Still, the libraries are handled incorrectly, and now it looks like the
existence of ejb-jar.xml (or rather its lack of existence) helps... Something
seems very wrong.

Comment by sirajg [ 12/Jul/10 ]

->P2 as it doesn't meet P1 criteria and reassigning.

Comment by szczyp [ 12/Jul/10 ]

Can you tell me where I can read about the criteria for priorities, so that I
pick the right one next time?

Comment by szczyp [ 12/Jul/10 ]

Additional bug: add the file 'src/main/resources/META-INF/beans.xml' (switching
CDI on) and here is the result:

Jul 12, 2010 6:48:13 PM com.sun.logging.LogDomains$1 log
SEVERE: ejb.embedded.exception_instantiating
java.lang.NoClassDefFoundError: com/sun/javadoc/Doclet
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 java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at
com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:165)
at java.lang.ClassLoader.loadClass(ClassLoader.java:296)
at java.lang.ClassLoader.loadClass(ClassLoader.java:296)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at
org.glassfish.weld.BeanDeploymentArchiveImpl.collectJarInfo(BeanDeploymentArchiveImpl.java:244)
at
org.glassfish.weld.BeanDeploymentArchiveImpl.populate(BeanDeploymentArchiveImpl.java:229)
at
org.glassfish.weld.BeanDeploymentArchiveImpl.<init>(BeanDeploymentArchiveImpl.java:102)
at org.glassfish.weld.DeploymentImpl.<init>(DeploymentImpl.java:118)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:315)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:99)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:176)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:229)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:359)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:203)
at
org.glassfish.kernel.embedded.EmbeddedDeployerImpl.deploy(EmbeddedDeployerImpl.java:196)
at org.glassfish.ejb.embedded.EJBContainerImpl.deploy(EJBContainerImpl.java:135)
at
org.glassfish.ejb.embedded.EJBContainerProviderImpl.createEJBContainer(EJBContainerProviderImpl.java:122)
at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:116)
at com.test.ejb.TestEJBTest.start(TestEJBTest.java:28)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:644)
at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:443)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:160)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:90)
at
org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:183)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:115)
at org.testng.TestRunner.runWorkers(TestRunner.java:909)
at org.testng.TestRunner.privateRun(TestRunner.java:618)
at org.testng.TestRunner.run(TestRunner.java:499)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:332)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:327)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:299)
at org.testng.SuiteRunner.run(SuiteRunner.java:204)
at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:915)
at org.testng.TestNG.runSuitesLocally(TestNG.java:879)
at org.testng.TestNG.run(TestNG.java:787)
at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:62)
at
org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:141)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)

My interpretation is this - the beans.xml file correctly marks the archive as a
CDI archive, and Weld tries to read and process the classes to look for CDI
stuff. However, as ALL classes of ALL dependencies are within the archive now
(as mentioned, all classes are mixed together), Weld is trying to process too
much - together with all classes from all dependencies. I don't know where the
doclet class comes from, will check later to see if it is in TestNG somewhere.
However, when I run it from within Eclipse 3.6 (Helios) final, an additional jar
is added to the classpath: eclipse-testng.jar - this comes with the TestNG
plugin for Eclipse. So, the exception is a little different:

Jul 12, 2010 6:47:34 PM com.sun.logging.LogDomains$1 log
SEVERE: ejb.embedded.exception_instantiating
java.lang.NoClassDefFoundError: org/eclipse/debug/core/ILaunchListener
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 java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at
com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:165)
at java.lang.ClassLoader.loadClass(ClassLoader.java:296)
at java.lang.ClassLoader.loadClass(ClassLoader.java:296)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at
org.glassfish.weld.BeanDeploymentArchiveImpl.collectJarInfo(BeanDeploymentArchiveImpl.java:244)
at
org.glassfish.weld.BeanDeploymentArchiveImpl.populate(BeanDeploymentArchiveImpl.java:229)
at
org.glassfish.weld.BeanDeploymentArchiveImpl.<init>(BeanDeploymentArchiveImpl.java:102)
at org.glassfish.weld.DeploymentImpl.<init>(DeploymentImpl.java:118)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:315)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:99)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:176)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:229)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:359)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:203)
at
org.glassfish.kernel.embedded.EmbeddedDeployerImpl.deploy(EmbeddedDeployerImpl.java:196)
at org.glassfish.ejb.embedded.EJBContainerImpl.deploy(EJBContainerImpl.java:135)
at
org.glassfish.ejb.embedded.EJBContainerProviderImpl.createEJBContainer(EJBContainerProviderImpl.java:122)
at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:116)
at com.test.ejb.TestEJBTest.start(TestEJBTest.java:28)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:644)
at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:443)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:160)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:90)
at
org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:183)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:115)
at org.testng.TestRunner.runWorkers(TestRunner.java:909)
at org.testng.TestRunner.privateRun(TestRunner.java:618)
at org.testng.TestRunner.run(TestRunner.java:499)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:332)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:327)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:299)
at org.testng.SuiteRunner.run(SuiteRunner.java:204)
at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:915)
at org.testng.TestNG.runSuitesLocally(TestNG.java:879)
at org.testng.TestNG.run(TestNG.java:787)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)

ILaunchListener is implemented by some class from the mentioned package, and
while it is on the classpath of the TestNG tool, it is not on the classpath of
the tested EJB application. This might as well be a TestNG / plugin bug
somewhere, but the original problem still exists, and is even made worse - we
can't use CDI / Weld in embedded tests.

The cause of all trouble is, again, the fact that all classes are expanded under
'applications/classes' and this is marked as a CDI bean archive by one of the
dependencies - and hence the whole world is processed by Weld.

Comment by szczyp [ 13/Jul/10 ]

The previous tests were done against 3.1 build 7. Today I followed the process
using build 9 and the behaviour is exactly the same.

Comment by szczyp [ 13/Jul/10 ]

The workaround for this bug is to have at least 2 EJB modules. I created a dummy
one, with a dummy EJB, and this forces GF to create a temporary EAR in /tmp (in
Linux). (I tested this before, but must have done something wrong.) Then, make
sure that EJBContainer.MODULES is specified and point to correct module names on
the classpath. Also, to be able to lookup the beans, specify EJBContainer.APP_NAME.
The test deployment contain: custom domain.xml with a PostgreSQL data source
(JDBC driver on the classpath), JPA module (separate), CDI producer for
EntityManager that corresponds to the JPA module, EJB that has has this
EntityManager injected using CDI's @Inject. It is a maven 2 project.
Tested against GF 3.1 builds 7 and 9.

Halleluyah!

Comment by szczyp [ 14/Jul/10 ]

The workaround fails as soon as you introduce another dependency that is a CDI
bean archive.

Comment by szczyp [ 14/Jul/10 ]

The workaround is: introduce a dummy ejb in the CDI archive and include
ejb-jar.xml with an overridden module name. See
https://glassfish.dev.java.net/issues/show_bug.cgi?id=12659.

Comment by marina vatkina [ 15/Jul/10 ]

I'm confused... the initial error message does mean an error in the EJB module
packaging - see Tim's explanation here:
http://forums.java.net/jive/thread.jspa?messageID=476169

What else is not working?

Comment by marina vatkina [ 16/Jul/10 ]

Waiting for the answer...

Comment by szczyp [ 19/Jul/10 ]

Please run the test case and follow the steps.
There is no problem with EJB module packaging, there is a problem that if only
one such module exists, all library jars are unpackaged and put under
'applications/classes' that results in many different kinds of errors:

  • last META-INF/MANIFEST.MF wins, and it changes from run to run, and if it
    contains Main-Class, the deployment will fail (explained earlier)
  • if it is a bean archive, Weld tries to read and process all classes; as a
    result, it reads classes that were never meant to be processed by Weld, and if
    they were compiled against some classes that are not in the classpath now, it
    will fails (the example is com.sun.javadoc.Doclet that is somewhere and somehow
    referenced by TestNG, or the mentioned eclipse-testng.jar and the
    ILaunchListener class)
  • if the libraries are bean archives they all contain beans.xml; in such case,
    during runtime, the 'last beans.xml' wins just as for the manifest file; if the
    beans.xml files are empty, no big deal, but if they switch on interceptors,
    decorators, alternatives and whatever else, the deployed application will fail

I don't know how much more detail I can give. As for the linked forum thread,
the error and description looks similar, but I would say it is not the same
issue. I saw this thread before I issued the bug. It didn't help me to hardcode
any paths, and it is not a fix anyways.

Please download the test case and follow the steps I did in the bug message.
Stop while debugging to see what the glassfish temp directory looks like,
especially the 'applications/classes' dir with all classes from libraries there.
I think it will be very clear what this bug means.

Comment by marina vatkina [ 19/Jul/10 ]

I filed a separate bug to exclude a library META-INF/MANIFEST.MF that contains
Main-Class from a classpath
https://glassfish.dev.java.net/issues/show_bug.cgi?id=12721

The rest are CDI issues

Comment by szczyp [ 19/Jul/10 ]

It is a problem with unpacking all classes from libraries into a single class
directory. I don't understand how it is a CDI issue? One of the results of such
unpacking is that Weld tries to process too much, but I don't see how you can
change this if you consider it a CDI issue?

As for the other bug: "[Embedded] Do not add a library if it manifest contains
Main-Class entry" - what does it mean "do not add a library"? Will such a jar be
completely excluded from the deployment? But the classes will be necessary at
runtime?

As much as I understand the original issue (and I did put some effort into
gathering what is going on and why), I don't see how this can be fixed this way.

Comment by marina vatkina [ 19/Jul/10 ]

A separate bug when fixed, will exclude libraries that contain Main-Class in the
manifest from being added to the deployment artifact. They will still be present
on the java classpath.

Comment by szczyp [ 19/Jul/10 ]

Why cannot all such library jars be included in the classpath, but not
unpackaged, like the ones that have the Main-Class in the manifest? What added
value does such unpacking have? This will still make CDI process too many
classes, and the problem with, for instance, TestNG and Doclet will still
remain. I obviously don't understand something, and I would like to ;d

Comment by rogerk [ 26/Jul/10 ]

assign to Siva

Comment by Sivakumar Thyagarajan [ 08/Oct/10 ]

Targetting for MS7

Comment by jitu [ 29/Oct/10 ]

Assigning this to myself

Comment by jitu [ 15/Nov/10 ]

Marina, do you have any response for the last comment from user ?

Comment by marina vatkina [ 15/Nov/10 ]

EJB embedded container doesn't unpackage anything. If there is only 1 EJB module
in the classpath (or specified via EJBContainer.MODULES), a ScatteredArchive is
created with the non-EJB jars/dirs added as refs from whatever location they are
listed in the classpath.

I did add a property, "org.glassfish.ejb.embedded.skip-client-modules" that if
set to true (or "true"), will result in skipping entries with Main-Class in
manifest file.

The rest is CDI behavior, and I don't understand what's wrong with the current
GF behavior.

Comment by jitu [ 07/Dec/10 ]

will target for 3.2

Comment by jitu [ 09/Dec/10 ]

Excluding for 3.1

Comment by tlcksnyder [ 20/Mar/13 ]

I know this bug has not been touched in a while, but the provided test.zip builds and runs cleanly.
Results : Tests run: 1, Failures: 0, Errors: 0, Skipped: 0.





[GLASSFISH-15407] Serialization of an injected Weld property fails in clustered environment Created: 03/Jan/11  Updated: 10/Jan/11  Resolved: 10/Jan/11

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1_b35
Fix Version/s: None

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

Windows 7/Windows 2008, clustered (2 local instances)


Status Whiteboard:

weld-int-required

Tags: weld-int-required

 Description   

I'm having trouble with a controller class accessed from a JSF page.
When a SLF4J Logger gets injected by Weld, the serialization fails in a clustered GF 3.1 environment. The following error lines appear in the logfile of the instance:

[#|2010-12-31T15:38:22.071+0100|INFO|glassfish3.1|org.apache.catalina.session.ManagerBase|_ThreadID=16;_ThreadName=Thread-1;|PWC2785: Cannot serialize session attribute org.jboss.weld.context.http.HttpSessionContext#org.jboss.weld.bean-/D:/glassfish-3.1-b32/glassfish/nodes/localhost/mls1/applications/myliquidsuite/myliquidsuite-web_war/-ManagedBean-class nl.asknow.liquidplatform.myliquidsuite.application.businfra.controller.VisitorController for session cd3761b77db86b3dbe76ae7b5057
java.io.NotSerializableException: java.util.logging.Logger
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
...

Some relevant code of the VisitorController:
import org.slf4j.Logger;

@Named
@SessionScoped
public class VisitorController implements Serializable

{ /** * uid */ private static final long serialVersionUID = -4647906892075275641L; @Inject protected transient Logger log; ... }

Notice that the injected org.slf4j.Logger is an slfj4 logger and not a java.util.logging.Logger (as mentioned in the error).
When I remove the log property, everything works just fine. Also when I assign a Logger using a LogFactory directly, everything seems to work fine. So for example:

protected transient Logger log = LoggerFactory.getLogger(VisitorController.class);

does work well.

This problem looks a lot like http://java.net/jira/browse/GLASSFISH-15395, which refers to https://issues.jboss.org/browse/WELD-812. I already had a little discussion about it with Pete Muir (see comments https://issues.jboss.org/browse/WELD-812).



 Comments   
Comment by Sivakumar Thyagarajan [ 04/Jan/11 ]

Could you please provide a sample application and please try against latest GF3.1 (after commit 44200) and let us know the results? We integrated a new Weld release (Weld 1.1.0.CR4) in commit 44200 which has made some changes around serialization and deserialization of Bean proxies.

Comment by Ramon Rockx [ 05/Jan/11 ]

Sivakumar, is this fix (commit 44200) part of the latest nightly build (january 3th)?

Comment by Ramon Rockx [ 10/Jan/11 ]

Tested this issue with promoted build 36, problem seems to be solved.
Thank you!

Comment by Sivakumar Thyagarajan [ 10/Jan/11 ]

Marking as weld-int-required as this issue does not appear with the SNAPSHOT version of Weld 1.1. Weld 1.1 has fixes for GLASSFISH-15278 (Conversation session serialization) and this appears to resolve this issue as well

Comment by Sivakumar Thyagarajan [ 10/Jan/11 ]

Just noticed that the bug submitter (rockxwre) indicates [1] that this issue does not appear with latest 3.1 trunk build and hence closing this issue

[1] http://java.net/jira/browse/GLASSFISH-15407?focusedCommentId=189519&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_189519





[GLASSFISH-18204] org.jboss.weld.exceptions.DeploymentException when deploying an application Created: 17/Jan/12  Updated: 29/Mar/13  Resolved: 29/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.1
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: titmus Assignee: jjsnyder83
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File cdi-ear-test-ear-1.0.0-SNAPSHOT.ear     Zip Archive cdi-ear-test.zip     Text File server.log    
Tags: 3_1_2-exclude, weld-int-required

 Description   

When deploying attached application (cdi-ear-test-ear-1.0.0-SNAPSHOT.ear) following exception is raised and the application is not deployed.
The application consists of two WAR-s which both use the same library (both WAR-s bundle it in WEB-INF directory). The Maven project used to build the application is attached as cdi-ear-test.zip

org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Bean<T>] with qualifiers [@Default] at injection point [[field] @Inject private test.war2.Servlet.bean]
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:270)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:106)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:129)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:351)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:336)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:396)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:190)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:306)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:462)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:382)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1064)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1244)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1232)
at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:202)
at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:195)
at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:148)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:288)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1469)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1400)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer._service(GrizzlyContainer.java:182)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer.service(GrizzlyContainer.java:147)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:184)
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:238)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
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)



 Comments   
Comment by Sivakumar Thyagarajan [ 19/Jan/12 ]

While debugging this issue, it appears that GF correctly passes the BDA structure for war2. Need to investigate this further as this might be a Weld issue.

— server.log snippet —
[#|2012-01-19T23:43:49.666+0530|FINE|44.0|org.glassfish.weld.DeploymentImpl|_ThreadID=12;_ThreadName=Thread-2;ClassName=org.glassfish.weld.DeploymentImpl;MethodName=getBeanDeploymentArchives;|DeploymentImpl::getBDAs. Returning
[|ID: cdi-ear-test-war1-1.0.0-SNAPSHOT_war, bdaType= WAR, accessibleBDAs #:18, [WEB-INF/lib/cdi-ear-test-lib-1.0.0-SNAPSHOT,,,,,,,,,,,,,,,,,,], Bean Classes #: 1,[test.war1.Servlet], ejbs=[]

---->ID: WEB-INF/lib/cdi-ear-test-lib-1.0.0-SNAPSHOT, bdaType= JAR, accessibleBDAs #:1, [cdi-ear-test-war1-1.0.0-SNAPSHOT_war,], Bean Classes #: 1,[test.lib.TestBean], ejbs=[]
---->ID: com.sun.jersey.server.impl.cdi.CDIExtension, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[com.sun.jersey.server.impl.cdi.CDIExtension], ejbs=[]
---->ID: org.glassfish.osgicdi.impl.OSGiServiceExtension, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[org.glassfish.osgicdi.impl.OSGiServiceExtension], ejbs=[]
---->ID: javax.ws.rs.core.Application, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[javax.ws.rs.core.Application], ejbs=[]
---->ID: javax.ws.rs.core.HttpHeaders, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[javax.ws.rs.core.HttpHeaders], ejbs=[]
---->ID: javax.ws.rs.ext.Providers, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[javax.ws.rs.ext.Providers], ejbs=[]
---->ID: javax.ws.rs.core.Request, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[javax.ws.rs.core.Request], ejbs=[]
---->ID: javax.ws.rs.core.SecurityContext, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[javax.ws.rs.core.SecurityContext], ejbs=[]
---->ID: javax.ws.rs.core.UriInfo, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[javax.ws.rs.core.UriInfo], ejbs=[]
---->ID: com.sun.jersey.spi.container.ExceptionMapperContext, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[com.sun.jersey.spi.container.ExceptionMapperContext], ejbs=[]
---->ID: com.sun.jersey.api.core.ExtendedUriInfo, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[com.sun.jersey.api.core.ExtendedUriInfo], ejbs=[]
---->ID: com.sun.jersey.core.util.FeaturesAndProperties, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[com.sun.jersey.core.util.FeaturesAndProperties], ejbs=[]
---->ID: com.sun.jersey.api.core.HttpContext, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[com.sun.jersey.api.core.HttpContext], ejbs=[]
---->ID: com.sun.jersey.api.core.HttpRequestContext, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[com.sun.jersey.api.core.HttpRequestContext], ejbs=[]
---->ID: com.sun.jersey.api.core.HttpResponseContext, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[com.sun.jersey.api.core.HttpResponseContext], ejbs=[]
---->ID: com.sun.jersey.spi.MessageBodyWorkers, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[com.sun.jersey.spi.MessageBodyWorkers], ejbs=[]
---->ID: com.sun.jersey.api.core.ResourceContext, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[com.sun.jersey.api.core.ResourceContext], ejbs=[]
---->ID: com.sun.jersey.spi.container.WebApplication, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[com.sun.jersey.spi.container.WebApplication], ejbs=[]
,
ID: cdi-ear-test-war2-1.0.0-SNAPSHOT_war, bdaType= WAR, accessibleBDAs #:18, [WEB-INF/lib/cdi-ear-test-lib-1.0.0-SNAPSHOT,,,,,,,,,,,,,,,,,,], Bean Classes #: 1,[test.war2.Servlet], ejbs=[]
---->ID: WEB-INF/lib/cdi-ear-test-lib-1.0.0-SNAPSHOT, bdaType= JAR, accessibleBDAs #:1, [cdi-ear-test-war2-1.0.0-SNAPSHOT_war,], Bean Classes #: 1,[test.lib.TestBean], ejbs=[]
---->ID: com.sun.jersey.server.impl.cdi.CDIExtension, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[com.sun.jersey.server.impl.cdi.CDIExtension], ejbs=[]
---->ID: org.glassfish.osgicdi.impl.OSGiServiceExtension, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[org.glassfish.osgicdi.impl.OSGiServiceExtension], ejbs=[]
---->ID: javax.ws.rs.core.Application, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[javax.ws.rs.core.Application], ejbs=[]
---->ID: javax.ws.rs.core.HttpHeaders, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[javax.ws.rs.core.HttpHeaders], ejbs=[]
---->ID: javax.ws.rs.ext.Providers, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[javax.ws.rs.ext.Providers], ejbs=[]
---->ID: javax.ws.rs.core.Request, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[javax.ws.rs.core.Request], ejbs=[]
---->ID: javax.ws.rs.core.SecurityContext, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[javax.ws.rs.core.SecurityContext], ejbs=[]
---->ID: javax.ws.rs.core.UriInfo, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[javax.ws.rs.core.UriInfo], ejbs=[]
---->ID: com.sun.jersey.spi.container.ExceptionMapperContext, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[com.sun.jersey.spi.container.ExceptionMapperContext], ejbs=[]
---->ID: com.sun.jersey.api.core.ExtendedUriInfo, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[com.sun.jersey.api.core.ExtendedUriInfo], ejbs=[]
---->ID: com.sun.jersey.core.util.FeaturesAndProperties, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[com.sun.jersey.core.util.FeaturesAndProperties], ejbs=[]
---->ID: com.sun.jersey.api.core.HttpContext, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[com.sun.jersey.api.core.HttpContext], ejbs=[]
---->ID: com.sun.jersey.api.core.HttpRequestContext, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[com.sun.jersey.api.core.HttpRequestContext], ejbs=[]
---->ID: com.sun.jersey.api.core.HttpResponseContext, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[com.sun.jersey.api.core.HttpResponseContext], ejbs=[]
---->ID: com.sun.jersey.spi.MessageBodyWorkers, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[com.sun.jersey.spi.MessageBodyWorkers], ejbs=[]
---->ID: com.sun.jersey.api.core.ResourceContext, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[com.sun.jersey.api.core.ResourceContext], ejbs=[]
---->ID: com.sun.jersey.spi.container.WebApplication, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[com.sun.jersey.spi.container.WebApplication], ejbs=[]
]
#]

[#|2012-01-19T23:43:49.682+0530|INFO|44.0|com.sun.enterprise.naming.impl|_ThreadID=12;_ThreadName=Thread-2;|found cached proxy [org.glassfish.weld.BeanManagerNamingProxy@3f8a94] for [java:comp/BeanManager]|#]

[#|2012-01-19T23:43:49.696+0530|INFO|44.0|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=12;_ThreadName=Thread-2;|WEB0671: Loading application cdi-ear-test-ear-1.0.0-SNAPSHOT#cdi-ear-test-war1-1.0.0-SNAPSHOT.war at [/cdi-ear-test-war1]|#]

[#|2012-01-19T23:43:49.706+0530|INFO|44.0|com.sun.enterprise.naming.impl|_ThreadID=12;_ThreadName=Thread-2;|found cached proxy [org.glassfish.weld.BeanManagerNamingProxy@3f8a94] for [java:comp/BeanManager]|#]

[#|2012-01-19T23:43:49.715+0530|INFO|44.0|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=12;_ThreadName=Thread-2;|WEB0671: Loading application cdi-ear-test-ear-1.0.0-SNAPSHOT#cdi-ear-test-war2-1.0.0-SNAPSHOT.war at [/cdi-ear-test-war2]|#]

[#|2012-01-19T23:43:49.720+0530|SEVERE|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=12;_ThreadName=Thread-2;|Exception while loading the app|#]

[#|2012-01-19T23:43:49.740+0530|SEVERE|44.0|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=12;_ThreadName=Thread-2;|Exception while loading the app : WELD-001408 Unsatisfied dependencies for type [Bean<T>] with qualifiers [@Default] at injection point [[field] @Inject private test.war2.Servlet.bean]
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Bean<T>] with qualifiers [@Default] at injection point [[field] @Inject private test.war2.Servlet.bean]
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:274)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:243)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:106)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:126)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:345)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:330)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:366)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:199)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:313)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:249)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:414)
— server.log snippet —

Comment by Sivakumar Thyagarajan [ 10/Dec/12 ]

Transferring to JJ Snyder

Comment by tlcksnyder [ 28/Mar/13 ]

Retested & app still fails with Weld 2.0.0.Beta7:

Exception while loading the app : CDI definition failure:WELD-001405 Cannot inject [BackedAnnotatedField] @Inject private test.war2.Servlet.bean in a class which isnt a bean
org.jboss.weld.exceptions.IllegalArgumentException: WELD-001405 Cannot inject [BackedAnnotatedField] @Inject private test.war2.Servlet.bean in a class which isnt a bean
at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:69)
at org.jboss.weld.manager.BeanManagerImpl.createInjectionTarget(BeanManagerImpl.java:1039)
at org.jboss.weld.manager.BeanManagerImpl.fireProcessInjectionTarget(BeanManagerImpl.java:1197)
at org.glassfish.weld.WeldDeployer.firePITEvent(WeldDeployer.java:403)
at org.glassfish.weld.WeldDeployer.fireProcessInjectionTargetEvents(WeldDeployer.java:373)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:203)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
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)
Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-001405 Cannot inject [BackedAnnotatedField] @Inject private test.war2.Servlet.bean in a class which isnt a bean
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDefinitionErrors(Validator.java:354)
at org.jboss.weld.injection.producer.InjectionTargetService.validateProducer(InjectionTargetService.java:39)
at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:66)
... 23 more
]

Comment by tlcksnyder [ 29/Mar/13 ]

App deploys after fixing @Inject of javax.enterprise.inject.spi.Bean to test.lib.TestBean in test.war2.Servlet.
The following was incorrect in test.war2.Servlet:
@Inject
private Bean bean;
Should be:
@Inject
private TestBean bean;





[GLASSFISH-18046] @Inject @New Instance<SomeClass> not working, getting WELD-001308 Unable to resolve any beans for Types Created: 19/Dec/11  Updated: 21/Mar/13  Resolved: 21/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.1_b12
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: chrikru Assignee: jjsnyder83
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64-Bit


Tags: 3_1_2-exclude, weld-int-required

 Description   

see also similar issue for JBoss7: https://issues.jboss.org/browse/WELD-975

According to spec: "...the @New qualifier may be used, allowing the application to obtain a @New qualified bean, as defined in Section 3.12, @New qualified beans" (CDI 1.0; chapter 5.6. Programmatic lookup).

However using programmatic lookup with @New qualifier like:

@Inject @New Instance<Foo> foo;

results in:

org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308 Unable to resolve any beans for Types: [class org.jboss.cditck.arquillian.instance.Foo]; Bindings: [@javax.enterprise.inject.New(value=org.jboss.cditck.arquillian.instance.Foo.class)]

after trying to obtain reference via get() method.

Following code works ok:

@Inject @New Foo foo;

Spec gives following valid example:

@Inject @New(ChequePaymentProcessor.class) Instance<PaymentProcessor> chequePaymentProcessor;


 Comments   
Comment by Sivakumar Thyagarajan [ 04/Jan/12 ]

Could you please submit a reproducible test case? I tried to reproduce this scenario in a developer test
(see http://java.net/projects/glassfish/sources/svn/revision/51888) and couldn't against GlassFish trunk.

At first glance, this appears to be a WELD issue, and hence I will track the resolution of WELD-795 for this.

Comment by chrikru [ 05/Jan/12 ]

I ran the test case locally and it worked fine for me to. So I tried to reproduce my error and succeeded. After some more analysis of the problem, I found something interesting:
If you comment lines 61-63 and lines 91-92 in NewQualifierTestServlet (revision 51900), the test fails. If you remove the comments in lines 61-63 again, it works fine.

It seems, that if the bean, which is used via "@Inject @New Instance<Bean>", was injected before via "@Inject @New Bean", the case with "Instance" is working. Otherwise it fails.

Comment by Sivakumar Thyagarajan [ 10/Dec/12 ]

Transferring to JJ Snyder

Comment by tlcksnyder [ 21/Mar/13 ]

Fixed in Weld as of 1.1.9.Final, 1.2.0.Beta1, 2.0.0.Alpha3.





[GLASSFISH-17415] CDI events is not working when fired by MDB Created: 12/Oct/11  Updated: 08/Dec/11  Resolved: 08/Dec/11

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Alexandre Verri Assignee: kshitiz_saxena
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64 bits, Java 1.6_b26.


Tags: 3_1_2-review, cdi, event, events, mdb

 Description   

An event generated by a MDB is not propagated to listeners.

The example to reproduce is bellow. Please note that the 'onEvent' listener method is never invoked.

@MessageDriven(mappedName = "jms/MyTopic", activationConfig = {
@ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"),
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Topic"),
@ActivationConfigProperty(propertyName = "subscriptionDurability", propertyValue = "Durable"),
@ActivationConfigProperty(propertyName = "clientId", propertyValue = "BackgroundEventDispatcher"),
@ActivationConfigProperty(propertyName = "subscriptionName", propertyValue = "BackgroundEventDispatcher")
})
public class BackgroundEventDispatcher implements MessageListener {

@Inject
private Event<String> eventBus;

public BackgroundEventDispatcher() {
}

@Override
public void onMessage(Message message)

{ eventBus.fire("New event"); }

}

@Named
@ApplicationScoped
public class MainRoom implements Serializable {

public void onEvent(@Observes String event)

{ System.out.println("Event: " + event); }

}



 Comments   
Comment by Sivakumar Thyagarajan [ 14/Nov/11 ]

Requesting Kshitiz to investigate

Comment by kshitiz_saxena [ 08/Dec/11 ]

This scenario is working both on GlassFish 3.1.2 and trunk.

Closing this issue as not reproducible.





[GLASSFISH-17185] CDI bean registered by extension registered twice Created: 11/Aug/11  Updated: 16/Aug/11  Resolved: 16/Aug/11

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Jozef Hartinger Assignee: Sivakumar Thyagarajan
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java version "1.6.0_24"
Apache Maven 3.0.3
GF 3.1.1
Fedora 15


Attachments: File test.war    
Issue Links:
Duplicate
duplicates GLASSFISH-17186 CDI bean registered by extension regi... Resolved

 Description   

AmbiguousDependencyException is thrown deploying the attached application. Source codes are available at https://github.com/seam/compatibility/blob/develop/src/test/java/org/jboss/seam/compat/cdi/registration/VisibilityOfBeanRegisteredByExtensionFromNonBeanLibraryTest.java

[#|2011-08-11T13:19:44.857+0200|SEVERE|glassfish3.1.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=18;_ThreadName=Thread-2;|Exception while loading the app|#]

[#|2011-08-11T13:19:44.903+0200|SEVERE|glassfish3.1.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=18;_ThreadName=Thread-2;|Exception while loading the app : WELD-001409 Ambiguous dependencies for type [BeanClassToRegister] with qualifiers [@Default] at injection point [[field] @Inject private org.jboss.seam.compat.cdi.registration.AnotherBeanClassToRegister.collaborator]. Possible dependencies [[Managed Bean [class org.jboss.seam.compat.cdi.registration.BeanClassToRegister] with qualifiers [@Any @Default], Managed Bean [class org.jboss.seam.compat.cdi.registration.BeanClassToRegister] with qualifiers [@Any @Default]]]
org.jboss.weld.exceptions.DeploymentException: WELD-001409 Ambiguous dependencies for type [BeanClassToRegister] with qualifiers [@Default] at injection point [[field] @Inject private org.jboss.seam.compat.cdi.registration.AnotherBeanClassToRegister.collaborator]. Possible dependencies [[Managed Bean [class org.jboss.seam.compat.cdi.registration.BeanClassToRegister] with qualifiers [@Any @Default], Managed Bean [class org.jboss.seam.compat.cdi.registration.BeanClassToRegister] with qualifiers [@Any @Default]]]
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:274)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:106)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:129)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:351)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:336)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:396)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:190)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:306)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:462)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:382)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1064)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1244)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1232)
at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:202)
at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:195)
at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:321)
at org.glassfish.admin.rest.resources.TemplateListOfResource.post(TemplateListOfResource.java:180)
at sun.reflect.GeneratedMethodAccessor106.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:288)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1469)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1400)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer._service(GrizzlyContainer.java:182)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer.service(GrizzlyContainer.java:147)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:184)
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:238)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
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)



 Comments   
Comment by Sivakumar Thyagarajan [ 16/Aug/11 ]

Duplicate of GLASSFISH-17186

Comment by Sivakumar Thyagarajan [ 16/Aug/11 ]

Closed as Duplicate of GLASSFISH-17186





[GLASSFISH-18435] IllegalStateException: Singleton not set for ... when invoking @PreDestroy on @SessionScoped bean Created: 01/Mar/12  Updated: 26/Apr/13  Resolved: 26/Apr/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.1
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: titmus Assignee: jwells
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File server.log     Zip Archive tests-session-bean.zip    
Tags: 4_0-approved

 Description   

I had an issue with @SessionScoped beans giving me an error during execution of @PreDestroy method.
In the server.log there were lines similar to this
[#|2012-03-01T09:16:14.799+0100|SEVERE|glassfish3.1.1|org.jboss.weld.Bean|_ThreadID=23;_ThreadName=Thread-2;|WELD-000019 Error destroying an instance Managed Bean [class test.SessionBeanProducer] with qualifiers [@Any @Default] of test.SessionBeanProducer@1c65470|#]

I investigated it a little bit and found thad when @PreDestroy method invoked @RequestScoped bean, the method org.glassfish.weld.ACLSingletonProvider.ACLSingleton#get raised IllegalStateException.
When this method was invoked TCCL was set to WebApp classloader but in the store only ear class loader was registered

The issue seems to be specific to EAR deployments. I created an arquillian test case demonstrating the issue.



 Comments   
Comment by titmus [ 01/Mar/12 ]

The expected behaviour would be that ContextNotActiveException is raised, but in the actual application I have a request context active during @PreDestroy annotated method invocation.

In my application classloader hierarchy for TCCL when org.glassfish.weld.ACLSingletonProvider.ACLSingleton#get is called is as follows:

org.glassfish.web.loader.WebappClassLoader
org.glassfish.internal.api.DelegatingClassLoader
java.net.URLClassLoader
com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader
sun.misc.Launcher$ExtClassLoader

There is no EarLibClassLoader in the classloader hierarchy.

Comment by Sivakumar Thyagarajan [ 10/Dec/12 ]

Transferring to JJ Snyder

Comment by edilmar [ 08/Feb/13 ]

I have the same problem with GF3.1.1 + JSF2 + Weld + CODI.
I use Conversation class from CODI, not Weld, and when I change from a Controller to other, after call conversation.close(), it appears the message "SEVERE: WELD-000019 Error destroying an instance Managed Bean" between any Controller changing.

Comment by shreedhar_ganapathy [ 19/Apr/13 ]

John
Can you eval this issue for inclusion into or exclusion from 4.0 ?

Comment by jwells [ 26/Apr/13 ]

This is the exception that is thrown in 4.0. I think this is the correct exception to be thrown here, but have some doubts I'm trying to resolve...

org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped
at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:667)
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:74)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79)
at com.oracle.cdi.cases.devtests.predestroy.lib.RequestBean$Proxy$_$$_WeldClientProxy.beanMethod(Unknown Source)
at com.oracle.cdi.cases.devtests.predestroy.war.SessionBeanProducer.destroy(SessionBeanProducer.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:89)
at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:82)
at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:99)
at org.jboss.weld.injection.producer.BeanInjectionTarget.preDestroy(BeanInjectionTarget.java:73)
at org.jboss.weld.bean.ManagedBean.destroy(ManagedBean.java:186)
at org.jboss.weld.context.ForwardingContextual.destroy(ForwardingContextual.java:31)
at org.jboss.weld.context.AbstractContext.destroyContextualInstance(AbstractContext.java:150)
at org.jboss.weld.context.AbstractContext.destroy(AbstractContext.java:163)
at org.jboss.weld.context.AbstractManagedContext.deactivate(AbstractManagedContext.java:41)
at org.jboss.weld.context.AbstractBoundContext.deactivate(AbstractBoundContext.java:72)
at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:157)
at org.apache.catalina.core.StandardContext.fireRequestDestroyedEvent(StandardContext.java:5261)
at org.apache.catalina.core.StandardHostValve.postInvoke(StandardHostValve.java:255)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:359)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)]]

Comment by jwells [ 26/Apr/13 ]

I believe the assumption in the code is that session.invalidate causes the session scope to be destroyed right then and there (leaving the request scope active, but the session scope destroyed). However (as can be seen from the above stack) this is not exactly correct, as the session scope is not truly removed until the request is over. This seems correct to me, so I think this is now working properly.

I would like to add a test case that verifies that this case throws ContextNotActive rather than IllegalState to make sure this does not regress again.

Comment by jwells [ 26/Apr/13 ]

What is the impact on the customer of the bug?

None. This bug has been fixed. However, I now have a specific test case for it I would like to check in so it never regresses.

What is the cost/risk of fixing the bug?

There is no risk, I would like to check my test case in (which lives under appserver/tests and is run by this hudson: http://hudson-sca.us.oracle.com/job/gf-cdi/)

Is there an impact on documentation or message strings?

No

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

CDI hudson

Which is the targeted build of 4.0 for this fix?

b88

If this an integration of a new version of a component from another project,
what are the changes that are being brought in? This might be list of
Jira issues from that project or a list of revision messages.

n/a

Comment by jwells [ 26/Apr/13 ]

Test case added with 61666





[GLASSFISH-18427] Weld: Inspect JDK 7 getMethods()/getDeclaredMethods() usage Created: 28/Feb/12  Updated: 25/Mar/13  Resolved: 25/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b25
Fix Version/s: 4.0

Type: Task Priority: Major
Reporter: Joe Di Pol Assignee: jwells
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Recent JDK 7 releases have altered the order of methods returned by the
Class.getMethods() and Class.getDeclaredMethods() calls. The order is
no longer stable and can change from one JVM run to the next.

This caused a number of sporadic bugs to appear during 3.1.2 development
when running with JDK 7. Those have been fixed, but further inspection
of the source has found a number of cases where we use getMethods() and
getDeclaredMethods().

Each of these cases should be visually inspected to see if the code is
making any assumptions on the order of methods returned by get*Methods().
In particular it should handle the case of multiple methods having the
same name.

For more details on what to look for and how to fix it see this document:

https://wikis.oracle.com/display/GlassFish/Method+Ordering+from+Class.getMethods

Please inspect the following files for their use of getMethods() /
getDeclaredMethods() to ensure the code is not making any assumptions
with respect to the order of methods returned. Create bugs for
any issues that need to be fixed and link them to this task. Once you
have completed inspection update this task with status and close it.

Weld integration for glassfish
    EjbDescriptorImpl.java
    EjbServicesImpl.java
Orchestrator
    JSONUtil.java



 Comments   
Comment by Sivakumar Thyagarajan [ 10/Dec/12 ]

Transferring to JJ Snyder

Comment by jwells [ 25/Mar/13 ]

EjbDescriptorImpl.java: looks safe (no usages)
EjbServicesImpl.java: looks safe (iterating through all doing the same to each one)
JSONUtil.java: Looks ok, but will return a different valid JSON string. Should probably be ok, as long as the string is not used for equality or something like that. I checked the only place using the javaToJSON method and it looks ok





[GLASSFISH-18909] CDI conversation not created when HTTP Chunking is enabled Created: 17/Jul/12  Updated: 20/Feb/13  Resolved: 13/Nov/12

Status: Closed
Project: glassfish
Component/s: cdi, jsf
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Puls Assignee: jjsnyder83
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.1.2, Windows 64, Java 7u4


Attachments: Zip Archive mavenproject1.zip    
Issue Links:
Related
is related to JAVASERVERFACES-2601 CDI conversation not created when HTT... Closed

 Description   

I have attached a small JSF sample application.

The application uses ClientSide State-Saving and does not create a session itself.

There is a conversation scoped bean. The conversation is first created when a link is clicked. The link executes via ajax and updates the form.

When HTTP chunking is enabled (which is default on glassfish) the JSESSION cookie is not properly appended to the response. The conversation is therefore not created and the saved values lost.

There is a second link which demonstartes that everything function correctly if the httpsession is manipulated manually in the same action listener.



 Comments   
Comment by Manfred Riem [ 13/Nov/12 ]

Closing as duplicate, see associated issue for resolution.

Comment by Manfred Riem [ 20/Feb/13 ]

Can you verify if this is still an issue on the latest 2.1 release?

Comment by Puls [ 20/Feb/13 ]

Sorry I am currently not working on JSF projects anymore. So I wont be able to test this without a lot of effort. But it should be easy to reproduce the problem using the given sample application.





Integrate CDI 1.1 (GLASSFISH-19191)

[GLASSFISH-19194] CDI - JCA Integration Created: 19/Oct/12  Updated: 05/Mar/13  Resolved: 05/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: 4.0

Type: Sub-task Priority: Major
Reporter: tlcksnyder Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ee7cdi

 Description   

Include existing WLS CDI functionality**

  • WLS Special CDI injection points:
  • ResourceAdapter bean
  • WorkManager
  • BootstrapContext and ExtendedBootstrapContext
  • XATerminator
  • TransactionSynchronizationRegistry
  • Expose adapter's BeanManager to adapter in
    ExtendedBootstrapContext.getBeanManager()
  • Support for third-party portable extensions in adapter
  • CDI Support in work thread
  • Extensive validation and checking for illegal annotations during deployment
  • This task does not rely on CDI 1.1 and can be implemented on the current version of Weld.


 Comments   
Comment by tlcksnyder [ 05/Mar/13 ]

CDI integration is checked & available as of b79-02_28_2013





Integrate CDI 1.1 (GLASSFISH-19191)

[GLASSFISH-19193] CDI - EJB Container Integration Created: 19/Oct/12  Updated: 05/Mar/13  Resolved: 05/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: 4.0

Type: Sub-task Priority: Major
Reporter: tlcksnyder Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ee7cdi

 Description   

Transactional Interceptors, Methods and Exceptions.
These topics are not complete yet.

See: http://java.net/projects/ejb-spec/lists/jsr345-experts/archive/2012-02/message/0



 Comments   
Comment by tlcksnyder [ 05/Mar/13 ]

CDI integration is checked & available as of b79-02_28_2013





[GLASSFISH-19191] Integrate CDI 1.1 Created: 19/Oct/12  Updated: 05/Mar/13  Resolved: 05/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0
Fix Version/s: 4.0_b82_EE7MS7

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-19016 Implement support for transaction scope Sub-task Resolved jjsnyder83  
GLASSFISH-19192 CDI 1.1 Web Container Integration Sub-task Closed jjsnyder83  
GLASSFISH-19193 CDI - EJB Container Integration Sub-task Closed jjsnyder83  
GLASSFISH-19194 CDI - JCA Integration Sub-task Closed jjsnyder83  
GLASSFISH-19276 Ingegrate Weld 2.0 Sub-task Closed jjsnyder83  
GLASSFISH-19305 CDI 1.1 Bean Validation Integration Sub-task Resolved jjsnyder83  
GLASSFISH-19318 support CDI in app client container Sub-task Resolved Tim Quinn  
GLASSFISH-19341 Migrate CDI logging. Sub-task Resolved jjsnyder83  
Tags: ee7cdi

 Description   

This issue covers the project for integrating CDI 1.1



 Comments   
Comment by tlcksnyder [ 05/Mar/13 ]

CDI integration is checked & available as of b79-02_28_2013





Integrate CDI 1.1 (GLASSFISH-19191)

[GLASSFISH-19192] CDI 1.1 Web Container Integration Created: 19/Oct/12  Updated: 05/Mar/13  Resolved: 05/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: 4.0_b72_EE7MS4

Type: Sub-task Priority: Major
Reporter: tlcksnyder Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ee7cdi

 Description   

Integrate CDI Interceptors with Web Container (WEB-4.4).

Add support the following built-in beans:

  • A bean with bean type javax.servlet.http.HttpServletRequest, allowing injection of a reference to the HttpServletRequest.
  • A bean with bean type javax.servlet.http.HttpSession, allowing injection of a reference to the HttpSession.
  • A bean with bean type javax.servlet.ServletContext, allowing injection of a reference to the ServletContext.

Ability to access the BeanManager from the ServletContext



 Comments   
Comment by tlcksnyder [ 05/Mar/13 ]

CDI integration is checked & available as of b79-02_28_2013





[GLASSFISH-18802] Wrong beans.xml associated with bean deployment archive Created: 13/Jun/12  Updated: 29/Mar/13  Resolved: 29/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.2
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: titmus Assignee: jwells
Resolution: Fixed Votes: 10
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64 bit
JDK 1.6.0_29


Attachments: Zip Archive beansxml.zip    

 Description   

I had an issue whith interceptor activation for CDI beans. I investigated the issue and found that GlassFish associates wrong beans.xml resource with bean deployment archives. This causes Weld to think that interceptors for BDA are not enabled because provided beans.xml has no interceptors enabled (although beans.xml in BDA has them enabled).

The cause of this is the way GlassFish constructs URL for beans.xml which is then passed to org.jboss.weld.bootstrap.WeldBootstrap.
Method handleEntry in class org.glassfish.weld.BeanDeploymentArchiveImpl constructs the URL as follows:

URL beansXmlUrl = Thread.currentThread().getContextClassLoader().getResource(entry);
wUris.add(beansXmlUrl.toURI());

In case of web application with multiple bean archives located in WEB-INF/lib it loads the same beans.xml for all bean archives (the first one found). That's beacuse there is one class loader for whole web application. There are no separate classloaders for specific archives in WEB-INF/lib. The entry in all cases is "META-INF/beans.xml", so the classloader always loads the same resource.

I attached a test case which demonstrates this bahaviour.
Commenting out the fragment

.addAsLibrary(
    ShrinkWrap.create(JavaArchive.class, "lib1.jar")
           .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml")
)

makes it pass.



 Comments   
Comment by pgliznie [ 11/Jul/12 ]

We have the same issue. Our EAR has the following structure:

app.ear
+lib
 +beans1.jar [bean archive]
 +beans2.jar [bean archive]
 +... other-libs.jar [no bean archives]
+ejb.jar [bean archive]
+web-app1.war [bean archive]
+web-app2.war [bean archive]
+web-app3.war [bean archive]
+web-app4.war [bean archive]

Our Interceptor and InterceptorBinding are in ejb.jar. The interceptor is enabled in beans.xml in web-app1.war and there is the class annotated which method calls we try to intercept. The application starts, there are no errors but the interceptor doesn't work. Changing the enabled interceptor in beans.xml to some non-existant class doesn't produce error messages. Only adding any interceptor to the beans.xml in beans1.jar works - it seems only this beans.xml is loaded.

Comment by thilian [ 08/Aug/12 ]

We experience a similar thing in 3.1.1.

app.ear
+lib
 +beans.jar
+ejb1.jar
+ejb2.jar
+ejb3.jar

All are bean archives.

We have an interceptor with binding defined in beans.jar. It is also enabled in beans.xml of beans.jar. We have interceptor binding annotations on beans in all archives, and they all work, even though they are not enabled in any other beans.xml.

We now created a new interceptor with binding defined in ejb1.jar. We enabled it in ejb1.jar's beans.xml, but it it totally ignored. Only the interceptor enabled in beans.jar in actually working, regadless of what we write in ejb1.jar's beans.xml.

Comment by Piotr Kulasek [ 07/Feb/13 ]

I have found something similar but in my case I had to enable interceptor in all bean archives under META-INF/lib.
More details on Stackoverflow

Comment by jwells [ 29/Mar/13 ]

This must have been fixed as part of other fixes.

I have a test case under:

appserver/tests/cdi/cases/multiBeansXml

that demonstrates that this is currently working. It has two EJBs in an EAR and each EJB has a different interceptor defined in beans.xml. Both interceptors work properly. If the described behavior above were still in the product then only one of the interceptors would have been seen.





[GLASSFISH-16115] WELD A Class in a Normal (proxiable) scope that extends a class with final methods is NOT caught at deployment time Created: 01/Mar/11  Updated: 11/Apr/13  Resolved: 11/Apr/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: drivera Assignee: jwells
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu Linux 10.04 x86, Sun JVM 1.6.0_24-b07


Attachments: GZip Archive server-log-inject-failed-finest.tar.gz    
Tags: 3_1_1-next, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

Using javax.enterprise.inject.Instance, my application is able to inject objects at runtime. The qualifier annotations are defined properly (runtime retention, method/field/parameter/type targets, @Qualifier), with a single member string (value). The string value is binding (i.e. no @NonBinding annotation)

The annotated, @Dependent class is also properly annotated.

In Glassfish 3.0.1, this injection model works perfectly.

In Glassfish 3.1, CDI (WELD) raises an exception that it can't satisfy the dependency.

Clearly, all jars/WARs have "beans.xml" in the right place (else it wouldn't work with 3.0.1).

All other (static) injection appears to be working normally.



 Comments   
Comment by drivera [ 01/Mar/11 ]

Here's an example of what the code is doing:

-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o
Annotation declaration:
-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o

@Qualifier
@Target(

{ ElementType.TYPE, ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER }

)
@Retention(RetentionPolicy.RUNTIME)
public @interface QualifierAnnotation

{ public String value(); }

-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o
Class declaration:
-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o

@QualifierAnnotation("qualifierSelector")
public class InjectableClass implements Injectable

{ ... /* bla bla bla ... content shouldn't matter, should it? */ /* importantly, there is NO @PostConstruct, or even an explicit constructor */ ... }

-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o
Code snippet where injection is looked up programmatically:
-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o

@Inject
Instance<Injectable> injectable;

public Injectable resolveInjectable(final String qualifierValue) {
QualifierAnnotation a = new QualifierAnnotation() {
@Override
public Class<? extends Annotation> annotationType()

{ return QualifierAnnotation.class; }

@Override
public String value()

{ return qualifierValue; }

};
Instance<Injectable> narrow = injectable.select(a);
if (narrow.isAmbiguous()) throw new RuntimeException("Ambiguity upon injection");
if (narrow.isUnsatisfied()) throw new RuntimeException("Injection unsatisfied");
return narrow.get();
}

-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o
Invocation of the injection:
-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o

Injectable i = resolveInjectable("qualifierSelector"};

-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o
End code examples
-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o

The result is that the 2nd RuntimeException described above ("Injection unsatisfied") is raised. This exact same code works in Glassfish 3.0.1 (confirmed, in production even!) and JBoss 6 (I think, unconfirmed).

Comment by drivera [ 05/Mar/11 ]

Attached are some logs I extracted in FINEST setting, ranging from a button click on the browser to the actual rendering of the error back on the browser.

The button click triggers the injection to happen, and thus all info regarding the action should be there.

Comment by drivera [ 09/Mar/11 ]

Bump.... can anyone so much as comment on the (in)validity of this issue?

Comment by drivera [ 09/Mar/11 ]

Ok...the issue has been found - this isn't a problem with NOT finding injections. The problem is with WELD not properly reporting injection spec violations.

I had 2 classes - A and B, of which B was a subclass of A. B was being injected directly, A was not. A contained final methods which were causing the CDI injection to fail.

I found the problem by creating C as a subclass of B (B and A were generic, so C was a specification of those generics), and injecting C instead of B. At that point Weld did complain rather loudly that A contained final methods and thus, CDI injection could not properly succeed.

So, in conclusion, the error is that Weld did not report the problem with final methods in the injectable class's superclass. Obviously the code was broken, but the error Weld displayed when I created C should have been displayed from the beginning.

Feel free to downgrade this, or pass this off to the weld guys. This is no longer a blocker issue.

Comment by Sivakumar Thyagarajan [ 24/May/11 ]

Marked this as 3_1_1-review. Need to ensure Weld properly reports this invalid scenario.

Comment by Sivakumar Thyagarajan [ 13/Jun/11 ]

Requires a fix in Weld and hence marking this as 3_1_1-next

Comment by Sivakumar Thyagarajan [ 11/Dec/11 ]

Marking this issue as "3_1_2_exclude", as a fix doesn't seem to be available in the 3.1.2 timeframe.

Comment by Sivakumar Thyagarajan [ 10/Dec/12 ]

Transferring to JJ Snyder

Comment by jwells [ 27/Mar/13 ]

Section 5.4.1 of the CDI specification (1.0) states that a bean in a Normal scope must not have final methods, and that such an injection point should be handled as a deployment error. Here is the exact wording:

If an injection point whose declared type cannot be proxied by the container resolves to a bean with a normal scope, the
container automatically detects the problem and treats it as a deployment problem.

If I have a class B that extends a class A, where B is in a Normal scope (@ApplicationScoped) and A has a final method the error is NOT caught (still, with the latest Weld) and is later manifested in a NullPointerException when Weld tries to proxy the class. If I add a final method to B the error IS caught at deployment time and made into a deployment failure.

This looks to me like an error in Weld, for which I can provide a simple test case.

Comment by jjsnyder83 [ 28/Mar/13 ]

I have forward the information to JBoss.

Comment by jwells [ 28/Mar/13 ]

I have submitted a test case under appserver/tests/cdi/negative/normalScopeWithFinal. The test is currently disabled (as the JAR erroneously is deployed). We should keep this bug open until the test case succeeds.

Comment by jjsnyder83 [ 29/Mar/13 ]

https://issues.jboss.org/browse/WELD-1388

Comment by jwells [ 11/Apr/13 ]

Weld has fixed this bug, and the test that catches this bug has been re-enabled with change 61362





[GLASSFISH-16102] Use generics in JCDIService.JCDIInjectionContext and related methods Created: 25/Feb/11  Updated: 21/Mar/13  Resolved: 21/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0
Fix Version/s: 4.0_b82_EE7MS7

Type: Improvement Priority: Major
Reporter: Cheng Fang Assignee: jwells
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-16086 Use Generic in InjectionManager inter... In Progress

 Description   

This issue is a continuation of issue 16086 (Use Generic in InjectionManager interface).

ManagedBeanManagerImpl calls JCDIService to get instance of managed objects, passing in Class<T>. Currently the return instance is Object. It will be nice if the return value is T.



 Comments   
Comment by jwells [ 21/Mar/13 ]

JCDIService has been converted to use Generics with change 60671





[GLASSFISH-21232] Application cannot detect custom interceptor annotation Created: 10/Oct/14  Updated: 24/Mar/15  Resolved: 24/Mar/15

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dungld Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish 4.1
java 7 update 51



 Description   

I have a customer annotation:
@Inherited
@IntereceptorBinding
@Retention(RUNTIME)
@Target(

{METHOD, TYPE}

)
public @interface WebSecured {

}

Then I map it into interceptor:
@Interceptor
@WebSecured
public class WebRoleInterceptor implements Serializable{

private static final long serialVersionUID = 1L;

@AroundInvoke
public Object checkRight(InvocationContext ctx) throws Exception

{ System.out.println("intercept here"); return ctx.proceed(); }

}

When I put it into @Named bean, it does not work for intercept, nothing happen
@Named("testBean")
@ViewScoped

public class TestBean{
@GbSecured
public void test(){
}
}

When I call testBean.test, the WebRoleInterceptor interceptor does not work.



 Comments   
Comment by dungld [ 10/Oct/14 ]

please replace GbSecured by WebSecured on my example, typing mistake

Comment by ratking [ 10/Oct/14 ]

This is not a bug.

In order for an interceptor to be invoked in a CDI application, it mus be specified in the beans.xml file. For example, the WebRoleInterceptor class is specified as follows:

<interceptors>
    <class>xxx.yyy.WebRoleInterceptor</class>
</interceptors>

see also: Using Interceptors in CDI Applications
http://docs.oracle.com/javaee/6/tutorial/doc/gkhjx.html

Comment by dungld [ 10/Oct/14 ]

I also add bean.xml to WEB-INF dir as follows, but I cannot use @WebSecured for interceptor.

Would u try my example ?

<?xml version="1.0" encoding="UTF-8"?>
<beans
xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
bean-discovery-mode="all"
>
<interceptors>
<class>xxx.yyy.WebRoleInterceptor</class>
</interceptors>
</beans>

Comment by dungld [ 10/Oct/14 ]

When I test sample billpayment of Java EE tuto for interceptor, it work ok, but when i copy those files into my project, it does not work.

I dont know what happen?

Some info about my project, it enable cluster feature, single sign on, session replicate. Maybe extra features affect to interceptor logic ?

Note: when I replace @WebSecured annotation by @Interceptors(WebRoleInterceptor.class), it work ok for intercepting. What's wrong with @WebSecured annotation?

Comment by dungld [ 18/Oct/14 ]

I fixed it! I changed @ManagedBean to @Named and everything ok. Thank you for support!





[GLASSFISH-21227] Session bean fails to deploy with bean validation Created: 08/Oct/14  Updated: 24/Mar/15  Resolved: 24/Mar/15

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: smillidge-c2b2 Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu JDK7



 Description   

Cargotracker fails to deploy with a method on a session bean includes bean validation annotations see CARGOTRACKER-51 with ClassNotFoundException org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor

This Interceptor is being added by WeldDeployer during the handling of Application_Loaded event (line 222) however the webapplication classloader does not have this Interceptor in its classloader



 Comments   
Comment by smillidge-c2b2 [ 11/Oct/14 ]

After much debugging I believe this is caused by https://java.net/jira/browse/HK2-233

Comment by smillidge-c2b2 [ 19/Oct/14 ]

I've incorporated the hk2 2.4.0-b03 into a GlassFish build which fixes HK2-233 and the problem goes away. This can be closed when latest HK2 is included in nucleus/pom.xml





[GLASSFISH-21385] Upgrade to Weld 2.2.13.Final Created: 01/Jul/15  Updated: 01/Jul/15  Resolved: 01/Jul/15

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: None

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


 Comments   
Comment by jjsnyder83 [ 01/Jul/15 ]

Completed 7/2/15.





[GLASSFISH-21301] Glassfish deployment Problem Created: 09/Feb/15  Updated: 11/Feb/15  Resolved: 11/Feb/15

Status: Closed
Project: glassfish
Component/s: cdi, jsf
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ceyhun Assignee: Manfred Riem
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

hi there, I was worked on simple JSF dynamic web project.There is no problem while running on Glassfish server. When I ran it ,
following error returned to me. But when i create same project on Netbeans , its working. I don't think there is a problem in the code side.

Error = http://i.hizliresim.com/DlR7v6.png



 Comments   
Comment by Manfred Riem [ 11/Feb/15 ]

What version of JSF are you using?

Comment by ceyhun [ 11/Feb/15 ]

I used 2.2

Comment by Manfred Riem [ 11/Feb/15 ]

You sure as the com.sun.faces.cdi.ViewProducer does not exist in 2.2?

Comment by ceyhun [ 11/Feb/15 ]

I solved this. This is not about CDI. When I use JSF which use jsf zip file(User library downloaded link= https://maven.java.net/content/repositories/releases/org/glassfish/javax.faces/2.3.0-m01/ ), glassfish has error like image which i shared. But after that i used JSF glassfish system library, well done.
Thank you for your interest Manfred.

Comment by Manfred Riem [ 11/Feb/15 ]

Closing this one as Invalid as it was pulling in an incorrect version of JSF

Comment by ceyhun [ 11/Feb/15 ]

Its not working on 2.2 too. Only work for glassfish system library.
Link = https://maven.java.net/content/repositories/releases/org/glassfish/javax.faces/2.2.8/javax.faces-2.2.8.jar





[GLASSFISH-21336] CDI Interceptor is not called in EJB Schedule Created: 24/Mar/15  Updated: 24/Mar/15  Resolved: 24/Mar/15

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: janario Assignee: jjsnyder83
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I have defined a CDI interceptor as following:

@Interceptor
@MyIntercept
public class MyInterceptor {
@AroundInvoke
public Object intercept(InvocationContext context) throws Exception {
LOG.info("Call {}.{}",
context.getMethod().getDeclaringClass().getName(), context.getMethod().getName());
return context.proceed();
}
}

@InterceptorBinding
@Retention(RetentionPolicy.RUNTIME)
@Target(

{ElementType.METHOD, ElementType.TYPE}

)
public @interface MyIntercept {}

And declared it in MyService
@Singleton
@MyIntercept
public class MyService {
@Schedule(second = "0/10", minute = "", hour = "", persistent = false)
public void schedule()

{ //... do something }

public void manualCall() { //... do something }

}

The interceptor was never called to schedule method but when call the manualCall method the interceptor was invoked.



 Comments   
Comment by jjsnyder83 [ 24/Mar/15 ]

Please provide a reproducible test caes.

Comment by janario [ 24/Mar/15 ]

You may close this as invalid.
After report it I discovered that it should be annotated with @AroundTimeout and not @AroundInvoke





[GLASSFISH-21351] Memory leak when injecting Instance<T> Created: 17/Apr/15  Updated: 15/Jun/15  Resolved: 15/Jun/15

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: baztian Assignee: Debayan_Gupta
Resolution: Works as designed Votes: 0
Labels: memory-leak
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Memory Analysis - -home-debayan-heapdump-current_oom.hprof - Eclipse _004.png    

 Description   

Injecting a Instance<T> causes a memory leak.

I'm having a few "MeasurementCollectors" in my code. Via a EJB Timer I'm iterating over all of them every second.

@Inject
private Instance<MeasurementCollector> dataCollectors;
...
for (MeasurementCollector collector : dataCollectors) {
    collectMeasure(collector, snapshot);
}

After a couple of minutes I'm getting an OutOfMemory Error.

Analysing the heap dump in MAT gives me the following "Problem Suspect"

One instance of "org.jboss.weld.context.CreationalContextImpl" loaded by "org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5 @ 0xe1bdbc08" occupies 352.836.128 (85,94%) bytes. The memory is accumulated in one instance of "java.lang.Object[]" loaded by "<system class loader>".

Keywords
java.lang.Object[]
org.jboss.weld.context.CreationalContextImpl
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5 @ 0xe1bdbc08

I've found this issue that seems to match my problem. But it is marked as fixed long ago. Looks like a regression.

Glassfish 4.0 does not suffer from this problem!

My current work around is directly inject the beans and avoid Instance<T>. In my case I need to specify a @Inject for every MeasurementCollector I have.

Unfortunately I didn't manage to set up a minimalistic example yet. I will attach my attempt to this issue.



 Comments   
Comment by baztian [ 17/Apr/15 ]

Unfortunately I can't attach files. Anyway here is the code that unfortunately does not reproduce the problem yet:


package leak;

import java.util.logging.Level;
import java.util.logging.Logger;

import javax.ejb.Schedule;
import javax.ejb.Singleton;
import javax.ejb.Startup;
import javax.enterprise.inject.Instance;
import javax.inject.Inject;

@Startup
@Singleton
public class Scheduler {

    private static final Logger logger = Logger.getLogger(Scheduler.class.getName());

    @Inject
    Instance<MyInstance> myInstances;


    @Schedule (second = "*/1", minute = "*", hour = "*", persistent = false)
    public void doItForAllInstances() {
        for (MyInstance myInstance : myInstances) {
            logger.log(Level.INFO, "doIt for instance {0}", myInstance);
            myInstance.doIt();
        }
    }
}

package leak;

public interface MyInstance {

    public void doIt();
}

package leak;

public class MyInstanceImplOne implements MyInstance {

    private final byte[] oneMegabyte = new byte[1024 * 1024];


    @Override
    public void doIt() {
        // do nothing.
    }

}
beans.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
       bean-discovery-mode="all">
</beans>
pom.xml
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>leak</groupId>
    <artifactId>weld-instance-leak</artifactId>
    <version>leak-SNAPSHOT</version>
    <packaging>war</packaging>
    <dependencies>
        <dependency>
            <groupId>javax</groupId>
            <artifactId>javaee-api</artifactId>
            <version>7.0</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>
    <properties>
        <maven.compiler.source>1.7</maven.compiler.source>
        <maven.compiler.target>1.7</maven.compiler.target>
        <failOnMissingWebXml>false</failOnMissingWebXml>
    </properties>
</project>
Comment by jjsnyder83 [ 20/Apr/15 ]

Are you able to provide a reproducible test case?

Comment by jiggster [ 04/May/15 ]

I've run into the same issue today. In our EAR application we have an @ApplicationScoped component that @Injects javax.enterprise.inject.Instance. This component is used by multiple @RequestScoped components and after couple thousands of HTTP request, the GlassFish runs out of memory. Will try to provide a test case that reproduces this bug as soon as I find some time for this.

Comment by Debayan_Gupta [ 04/Jun/15 ]

I have tried to reproduce the issue in my local lab with default glassfish heap size, but not abale to reproduce the issue. A testcase with the heap size details or the heap dump of before and after this issue reproduced would be helpful to investigate this issue.

Comment by baztian [ 05/Jun/15 ]

I have no minimalistic test case to reproduce it. But there is a guaranteed way to reproduce it.
Install Lightfish from https://github.com/AdamBien/lightfish/ (git clone the master branch) and start it. Here how I can reproduce the OOM:
Build lightfish (using Java 8).
Deploy the lightfish war file.
Open http://localhost:8080/lightfish/.
"Activate Monitoring" and press the start button (don't remember how the button is named exactly).

Initially I thought this is a lightfish bug so I created an issue https://github.com/AdamBien/lightfish/issues/27 containing some more information. But I noticed the problem in an application I've written myself which I unfortunately can't publish.

Comment by Debayan_Gupta [ 05/Jun/15 ]

Thanks for your reply. I tried to deploy the lightfish war , but deployment failed with folowing error message. Am I missing something here? I have followed the steps you mentioned.

Error occurred during deployment: Exception while deploying the app [lightfish] : Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.5.2.v20140319-9ad6abd): org.eclipse.persistence.exceptions.DatabaseException Internal Exception: java.sql.SQLException: Error in allocating a connection. Cause: Connection could not be allocated because: java.net.ConnectException : Error connecting to server localhost on port 1527 with message Connection refused. Error Code: 0.

++Some details stack trace++

Internal Exception: java.sql.SQLException: Error in allocating a connection. Cause: Connection could not be allocated because: java.net.ConnectException : Error connecting to server localhost on port 1527 with message Connection refused.
Error Code: 0
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:766)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.getAbstractSession(EntityManagerFactoryDelegate.java:204)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.createEntityManagerImpl(EntityManagerFactoryDelegate.java:304)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManagerImpl(EntityManagerFactoryImpl.java:336)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:302)
at org.glassfish.persistence.jpa.JPADeployer$2.visitPUD(JPADeployer.java:451)
at org.glassfish.persistence.jpa.JPADeployer$PersistenceUnitDescriptorIterator.iteratePUDs(JPADeployer.java:510)
at org.glassfish.persistence.jpa.JPADeployer.iterateInitializedPUsAtApplicationPrepare(JPADeployer.java:492)
at org.glassfish.persistence.jpa.JPADeployer.event(JPADeployer.java:398)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:487)
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$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:253)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:231)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:275)
at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:133)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:151)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:171)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:104)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:387)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:331)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:103)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:297)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:254)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1028)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:365)
at org.glassfish.admin.rest.adapter.RestAdapter$2.service(RestAdapter.java:316)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)

Comment by baztian [ 05/Jun/15 ]

Thanks for investigating. Lightfish uses the embedded Derby db. Did you configure it in some non default way? If I remember correctly, for GF 4.0 a asadmin start-database call was necessary. But afaik this is not required with GF 4.1.

Comment by Debayan_Gupta [ 10/Jun/15 ]

I have investigated this issue and following are the observation :

1. The scenario which is appearing as memory leak is caused by 'org.jboss.weld.context.CreationalContextImpl' instances which is the part of internal implementation of 'Instance<T>'. There are lot of dependent dependent instances which are kept in the memory as the instance which created these never gets destroyed.

2. The application uses Instance<T> in lot of places, but never destroys the instances. Since these are "managed" and "dependent" instances, they won't get garbage collected unless the parent instance gets destroyed. Weld spec clearly mentions this scenario (refer: http://weld.cdi-spec.org/documentation/#6). Although I have not visited the lightfish application thoroughly, but to me it uses continuous polling through REST , which in turn creates some timer application which starts some future task. Since in some cases ( e.g. MonitoringController.java) there is no explicit scope is defined, instances never gets GC'ed and causing OutOfMemory error.

3.Glassfish only provide the integration support for Weld, it worked well in GF 4.0 may be because of older implementation of Weld Core Implementation. The only changes since GF 4.0 to GF 4.1 is upgrade to Weld implementation (latest being Weld 2.2.10.SP1). So this issue has more to do with Weld , but again they have a suggestion for this as I mentioned in point 2. I would suggest to call Instance.destroy() and @PreDestroy in proper places in the application to clear the instances.

I'd try to upload the heap dump analysis snapshot whenever I get the attachment permission.

Comment by Debayan_Gupta [ 11/Jun/15 ]

Attached the heap dump analysis screen shot.

Comment by baztian [ 11/Jun/15 ]

Thanks @Debayan_Gupta for your resarch!
If I understand you right I have to put a myinstance.destroy() for every Instance I have in a @PreDestory method. Why can't Weld garbage collect this?

public class Foo {
 Instance<String> myInstance1;
 Instance<String> myInstance2;
 @PreDestory
 public void destroy() {
  myInstance1.destroy();
  myInstance2.destroy();
}
Comment by Debayan_Gupta [ 15/Jun/15 ]

As per CDI specification, If you use Instance<> to create an instance of a bean, then that instance becomes dependent on the creator, and therefore does not become eligible for GC until the parent instance is discarded. In lightfish case, these are created mostly by timer beans which are application scoped. So instances will be destroyed only if these beans gets destroyed. Which is not the case here and as a result it is causing OOM error. The main reason of not performing GC to me is, Weld wants to call 'destroy' life cycle methods on these instances when the context gets destroyed.

Hope it clarifies your query. For further queries related to this, I'd suggest you to raise the same in Weld community.

Comment by Debayan_Gupta [ 15/Jun/15 ]

This is a common behavior of Weld implementation where user needs to manage the instances created through Instance<> api call. For better explanation, please follow 'Comment' section.





[GLASSFISH-20984] Unable to inject JMS resources in a bean defined in a dependency jar Created: 13/Feb/14  Updated: 27/Jul/15  Resolved: 27/Jul/15

Status: Closed
Project: glassfish
Component/s: cdi, jms
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: electricsam Assignee: jjsnyder83
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux, jdk 1.7.0_45



 Description   

I have an @ApplicationScoped bean defined in a common library which I add to my projects in a dependency jar.

Injection of the connection factory and queue results in null objects when using @Resource

Example code:

In this code, I have tried both @Resource(name = "... and @Resource(mappedName = "... with the same result.

@ApplicationScoped
public class PerformanceLoggingProducer {

    private static final Logger logger = Logger.getLogger(PerformanceLoggingProducer.class.getName());

    @Resource(mappedName = "jms/ConnectionFactory")
    private ConnectionFactory connectionFactory;
    @Resource(name = "jms/PerformanceLoggingQueue")
    private Queue queue;

    public void log(final PerformanceLogTracker tracker) {

        if (tracker != null) {
      
            Thread t = new Thread(new Runnable() {

                @Override
                public void run() {
                    try (Connection connection = connectionFactory.createConnection()) {
                        Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
                        MessageProducer producer = session.createProducer(queue);
                        ObjectMessage message = session.createObjectMessage(tracker);
                        producer.send(message);
                    } catch (Exception ex) {
                        logger.log(Level.SEVERE, "An error occurred when logging message: " + tracker, ex);
                    }
                }
            });
            
            t.start();

        }
    }

}

Workaround:

Don't use @Resource for the lookup.

@ApplicationScoped
public class PerformanceLoggingProducer {

    private static final Logger logger = Logger.getLogger(PerformanceLoggingProducer.class.getName());

//    @Resource(mappedName = "jms/ConnectionFactory")
    private ConnectionFactory connectionFactory;
//    @Resource(name = "jms/PerformanceLoggingQueue")
    private Queue queue;

    public PerformanceLoggingProducer() {
        try {
            connectionFactory = (ConnectionFactory) new InitialContext().lookup("jms/ConnectionFactory");
            queue = (Queue) new InitialContext().lookup("jms/PerformanceLoggingQueue");
        } catch (NamingException ex) {
            logger.log(Level.SEVERE, null, ex);
        }
    }

    public void log(final PerformanceLogTracker tracker) {

        if (tracker != null) {
      
            Thread t = new Thread(new Runnable() {

                @Override
                public void run() {
                    try (Connection connection = connectionFactory.createConnection()) {
                        Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
                        MessageProducer producer = session.createProducer(queue);
                        ObjectMessage message = session.createObjectMessage(tracker);
                        producer.send(message);
                    } catch (Exception ex) {
                        logger.log(Level.SEVERE, "An error occurred when logging message: " + tracker, ex);
                    }
                }
            });
            
            t.start();

        }
    }

}


 Comments   
Comment by jjsnyder83 [ 20/Apr/15 ]

Can you provide a test app? I'd like to see how it's packaged.





[GLASSFISH-20996] EJB CreateException when calling a method in a retrieved local interface Created: 28/Feb/14  Updated: 24/Mar/15  Resolved: 24/Mar/15

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sicruise Assignee: jjsnyder83
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

jdk7u51 64 bit , glassfish 4 up to glassfish-4.0.1-b04-02_26_2014, ubuntu


Tags: 4_0_1-reviewed, createexception, ejb

 Description   

This application works perfectly in 3.1.2.2 and there has been no changes to the way beans are loaded when migrating to glassfish 4.

Application is building using jars under glassfish/modules directory, the same ones used for running.

EJB's effected so far are all marked with @Stateless annotation. The example here is the first bean that is executed on application startup.

EJB is being picked up and loaded into JNDI and when getting it from jndi it is an instance of the correct object. Just when you go to call a method in the bean it fails.

[2014-02-28T10:35:04.247+0000] [glassfish 4.0] [INFO] [AS-EJB-00054] [javax.enterprise.ejb.container] [tid: _ThreadID=37 _ThreadName=admin-listener(3)] [timeMillis: 1393583704247] [levelValue: 800] [[
Portable JNDI names for EJB DAOStatisticBean: [java:global/merchant/webapp/DAOStatisticBean, java:global/merchant/webapp/DAOStatisticBean!com.merchant.ejb.DAOStatisticBean]]]

but then...

[2014-02-28T10:35:08.055+0000] [glassfish 4.0] [SEVERE] [] [javax.enterprise.ejb.container] [tid: _ThreadID=37 _ThreadName=admin-listener(3)] [timeMillis: 1393583708055] [levelValue: 1000] [[
ejb.stateless_ejbcreate_exception]]

[2014-02-28T10:35:08.056+0000] [glassfish 4.0] [WARNING] [AS-EJB-00056] [javax.enterprise.ejb.container] [tid: _ThreadID=37 _ThreadName=admin-listener(3)] [timeMillis: 1393583708056] [levelValue: 900] [[
A system exception occurred during an invocation on EJB DAOStatisticBean, method: public com.merchant.dto.DAOStatisticDTO com.merchant.ejb.DAOStatisticBean.loadTodayStatistic() throws javax.ejb.EJBException]]

Root Cause of CreateException

Caused by: java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.hash(ConcurrentHashMap.java:333)
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:988)
at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:1185)
at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:185)
at org.glassfish.weld.services.JCDIServiceImpl._createJCDIInjectionContext(JCDIServiceImpl.java:198)
at org.glassfish.weld.services.JCDIServiceImpl.createJCDIInjectionContext(JCDIServiceImpl.java:179)
at com.sun.ejb.containers.BaseContainer.createEjbInstanceAndContext(BaseContainer.java:1696)
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:456)
at com.sun.ejb.containers.StatelessSessionContainer.access$000(StatelessSessionContainer.java:97)
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:698)
at com.sun.ejb.containers.util.pool.NonBlockingPool.getObject(NonBlockingPool.java:246)
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:430)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2579)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1971)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:210)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy338.loadTodayStatistic(Unknown Source)
at com.merchant.ejb._EJB31_GeneratedDAOStatisticBeanIntf__Bean_.loadTodayStatistic(Unknown Source)
at com.merchant.thread.DAOStatisticThread.<init>(DAOStatisticThread.java:84)
at com.merchant.thread.DAOStatisticThread.startThread(DAOStatisticThread.java:195)
at com.merchant.InitServlet.init(InitServlet.java:102)
at javax.servlet.GenericServlet.init(GenericServlet.java:244)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1583)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1382)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5704)



 Comments   
Comment by Hong Zhang [ 11/Apr/14 ]

As stack trace is from CDI code, assign to cdi team for initial evaluation.

Comment by jjsnyder83 [ 16/Apr/14 ]

Can you please provide a source code example of:

  • The definition of the ejb
  • How it is injected into the servlet (I assume it is injected into a servlet based on the stack trace)
  • How it is accessed that causes the exception.




[GLASSFISH-20025] Classloading needs to be optimized for the implicit CDI enablement functionality Created: 25/Mar/13  Updated: 19/Sep/14  Resolved: 24/May/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b83
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: phil.zampino Assignee: phil.zampino
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

For implicitly-enabled CDI apps, only those classes annotated with bean-defining annotations should be loaded at deployment-time, for performance reasons. Currently, there is logic to identify these bean classes, but all classes in the archive are still being loaded.



 Comments   
Comment by phil.zampino [ 24/May/13 ]

Committed revision 62100.
Updated weld-integration/src/main/java/org/glassfish/weld/BeanDeploymentArchiveImpl.java





[GLASSFISH-20020] Map the weld CDI Conversation Filter for cdi-enabled web apps. Created: 24/Mar/13  Updated: 26/Mar/13  Resolved: 26/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: None

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


 Description   

See http://docs.jboss.org/weld/reference/snapshot/en-US/html/ri-spi.html#d0e6737

This will fix cdi tck tests:
org.jboss.cdi.tck.tests.context.conversation.ClientConversationContextTest
org.jboss.cdi.tck.tests.context.conversation.InvalidatingSessionDestroysConversationTest
org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest
org.jboss.cdi.tck.tests.context.conversation.ManualCidPropagationTest



 Comments   
Comment by tlcksnyder [ 26/Mar/13 ]

Dupe of http://java.net/jira/browse/GLASSFISH-20026





[GLASSFISH-19949] Verify bean validation (bv CR3) with CDI (weld beta6) Created: 19/Mar/13  Updated: 25/Apr/13  Resolved: 26/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: phil.zampino Assignee: phil.zampino
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently, bean validation incorrectly reports a ConstraintDeclarationException because it deems the generated Weld proxy and the associated bean as having an invalid relationship wrt constraint declarations. This occurs for a simple CDI bean with parameter constraint annotations.

javax.validation.ConstraintDeclarationException: Only the root method of an overridden method in an inheritance hierarchy may be annotated with parameter constraints, but there are parameter constraints defined at all of the following overridden methods: [ConstrainedExecutable [location=TestBean$Proxy$_$$_WeldSubclass#echo(), parameterMetaData=[ParameterMetaData location=TestBean$Proxy$_$$_WeldSubclass#echo(0), name=arg0], constraints=[NotNull], isCascading=false]], hasParameterConstraints=true], ConstrainedExecutable [location=TestBean#echo(), parameterMetaData=[ParameterMetaData location=TestBean#echo(0), name=arg0], constraints=[NotNull], isCascading=false]], hasParameterConstraints=true]]
at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.checkParameterConstraints(ExecutableMetaData.java:442)
at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.build(ExecutableMetaData.java:355)
at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BuilderDelegate.build(BeanMetaDataImpl.java:601)
at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BeanMetaDataBuilder.build(BeanMetaDataImpl.java:508)
at org.hibernate.validator.internal.metadata.BeanMetaDataManager.createBeanMetaData(BeanMetaDataManager.java:182)
at org.hibernate.validator.internal.metadata.BeanMetaDataManager.getBeanMetaData(BeanMetaDataManager.java:142)
at org.hibernate.validator.internal.engine.ValidatorImpl.validateParametersInContext(ValidatorImpl.java:868)
at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:239)
at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:197)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:44)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:108)
at org.jboss.weld.proxies.ExecutableValidator$Validator$1366014919$Proxy$_$$_WeldClientProxy.validateParameters(Unknown Source)
at org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validateMethodInvocation(ValidationInterceptor.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30)
at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:95)
at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:78)
at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:50)
at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:43)
at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:52)
at test.beans.TestBean$Proxy$_$$_WeldSubclass.echo(Unknown Source)
at test.beans.TestBean$Proxy$_$$_WeldClientProxy.echo(Unknown Source)
at test.servlet.BusinessMethodInterceptorTestServlet.service(BusinessMethodInterceptorTestServlet.java:78)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:175)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
]]



 Comments   
Comment by phil.zampino [ 26/Mar/13 ]

This was fixed with BV CR3





[GLASSFISH-19946] Add ability to turn on/off global support for CDI. Created: 19/Mar/13  Updated: 11/Apr/13  Resolved: 11/Apr/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b85

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


 Comments   
Comment by jjsnyder83 [ 21/Mar/13 ]

See https://issues.jboss.org/browse/CDI-321

Comment by jjsnyder83 [ 22/Mar/13 ]

Make sure we also check the isJCDIEnabled method in the JCDI service

Comment by jjsnyder83 [ 22/Mar/13 ]

globally disabling CDI means that a beans.xml must be present for an archive to be a bda, e.g. no implicit archives. If there is a beans.xml the "bean-discovery-mode" element must still be honored.

Comment by jjsnyder83 [ 09/Apr/13 ]

The config item is there. We need to access it. WeldUtils.isEnableImplicitCDI() is the method to use. To change the value use asadmin (false is the default)

asadmin create-module-config cdi-service
asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=true

Comment by jjsnyder83 [ 09/Apr/13 ]

Revision 61270 has the changes needed for this.

Comment by tlcksnyder [ 11/Apr/13 ]

Implemented.





[GLASSFISH-19924] Verify org.jboss.cdi.tck.spi.Managers interface was completely removed from CDI 1.1.0.Beta6 TCK porting package Created: 18/Mar/13  Updated: 20/Mar/13  Resolved: 20/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: None

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


 Description   

in CDI TCK 1.1.0.Beta6 there's one minor change in CDI TCK Porting Package API - org.jboss.cdi.tck.spi.Managers interface was completely removed (it was deprecated for a long time anyways). Verify there are no issues.



 Comments   
Comment by tlcksnyder [ 20/Mar/13 ]

Mar 14, 2013: CDITCK: Porting package API cleanup - org.jboss.cdi.tck.spi.Managers removed by mkouba
Current spi no longer contains Managers.java.
https://github.com/jboss/cdi-tck/tree/master/api/src/main/java/org/jboss/cdi/tck/spi





[GLASSFISH-19916] Extend bean definining annotation to include EJBs Created: 18/Mar/13  Updated: 25/Apr/13  Resolved: 11/Apr/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: 4.0_b83

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: phil.zampino
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Processing of wars and ejb jars for bean defining annotations must include session beans. This also has to include ejbs defined by dds.



 Comments   
Comment by jjsnyder83 [ 18/Mar/13 ]

See javadoc in CDI11Bootstrap.

Comment by jjsnyder83 [ 19/Mar/13 ]

Don't skip MDBs - they are also supported for all things CDI.

Comment by phil.zampino [ 26/Mar/13 ]

Some EJB tests are failing because of a Weld issue (https://issues.jboss.org/browse/WELD-1363), which is supposed to be fixed in beta7. Cannot commit the changes for this issue until the Weld fix can be verified.

Comment by phil.zampino [ 29/Mar/13 ]

After beta7 uptake, still seeing some EJB devtest failures due to a likely Weld issue involving interceptor PostConstruct methods.

Comment by phil.zampino [ 03/Apr/13 ]

Waiting for resolution of https://issues.jboss.org/browse/WELD-1391 to address some EJB devtest failures.





[GLASSFISH-19572] Simplify exporting of com.sun.ejb.containers.interceptors from ejb-container Created: 23/Jan/13  Updated: 21/Sep/15  Resolved: 21/Sep/15

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b68_EE7MS3
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: Romain Grécourt
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

A CDI tck test was failing because ejb interceptors not visible to cdi module. I exported the entire com.sun.ejb.containers.interceptors package but it may not be necessary to export the entire package.



 Comments   
Comment by jjsnyder83 [ 23/Jan/13 ]

Committed revision 58766

Comment by jjsnyder83 [ 23/Jan/13 ]

Find the tck test that fails so that we can investigate further. We might want to add an interface or move things around. It's not the best choice to export the whole package at once.

Comment by phil.zampino [ 26/Jun/13 ]

I tried removing the export that was added via rev. 58766, but I can't reproduce any CDI TCK failures with this change.

Comment by phil.zampino [ 12/Aug/13 ]

Committed rev. 62498





[GLASSFISH-19845] WELD-001450 WARNING messages for com.sun.ejb.containers.interceptors.SystemInterceptorProxy Created: 12/Mar/13  Updated: 20/Mar/13  Resolved: 20/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: arungupta Assignee: jwells
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Starting GlassFish 4 b79 is showing the following warnings:

WARNING: Method destroy defined on class com.sun.ejb.containers.interceptors.SystemInterceptorProxy will not be used for interception, since it is not defined according to the specification. It is annotated with @javax.annotation.PreDestroy, but is defined on the target class and does not have 0 arguments
WARNING: WELD-001450 Interceptor method public java.lang.Object com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundTimeout(javax.interceptor.InvocationContext) throws java.lang.Throwable does not declare that it throws Exception.
WARNING: WELD-001450 Interceptor method public java.lang.Object com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(javax.interceptor.InvocationContext) throws java.lang.Throwable does not declare that it throws Exception.
WARNING: Method init defined on class com.sun.ejb.containers.interceptors.SystemInterceptorProxy will not be used for interception, since it is not defined according to the specification. It is annotated with @javax.annotation.PostConstruct, but is defined on the target class and does not have 0 arguments
WARNING: Method init defined on class com.sun.ejb.containers.interceptors.SystemInterceptorProxy will not be used for interception, since it is not defined according to the specification. It is annotated with @javax.annotation.PostConstruct, but is defined on the target class and does not have 0 arguments
WARNING: Method destroy defined on class com.sun.ejb.containers.interceptors.SystemInterceptorProxy will not be used for interception, since it is not defined according to the specification. It is annotated with @javax.annotation.PreDestroy, but is defined on the target class and does not have 0 arguments
WARNING: WELD-001450 Interceptor method public java.lang.Object com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(javax.interceptor.InvocationContext) throws java.lang.Throwable does not declare that it throws Exception.
WARNING: WELD-001450 Interceptor method public java.lang.Object com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundTimeout(javax.interceptor.InvocationContext) throws java.lang.Throwable does not declare that it throws Exception.

This needs to be cleaned up.



 Comments   
Comment by marina vatkina [ 12/Mar/13 ]

Assigning to CDI/JJ to investigate the following:
SystemInterceptorProxy is a special interceptor that is being used by the EJB container, but somehow Weld thinks it's a bean (" is defined on the target class"). Are they scanning GF jars for bean auto-discovery?

Comment by jwells [ 19/Mar/13 ]

How do we reproduce this? Do we just deploy an EJB that uses CDI? Or is it more complex than that?

Comment by marina vatkina [ 19/Mar/13 ]

I don't think it's there any more...

Comment by arungupta [ 19/Mar/13 ]

Build 80 is still showing this warning, might be gone in the trunk.

Comment by jwells [ 19/Mar/13 ]

The answer seems to be "yes, just deploy any EJB that uses CDI". In fact, it may print these warnings out for any EJB (even if they do not use CDI, I don't know)

Comment by marina vatkina [ 19/Mar/13 ]

Any EJB with interceptors or may be even any EJB, but CDI needs to be enabled.

Comment by jwells [ 19/Mar/13 ]

Actually you have to invoke the EJB to see the warnings. If you JUST deploy the EJB you will not see the warnings. So these warnings must come AFTER CDI has completed its validation phase...

Comment by jwells [ 19/Mar/13 ]

Very curious: If I deploy an EAR with a web-app and an EJB jar and invoke the EJB via the web-app, I do NOT see the warnings. So it seems as though I can only get the warnings on a CDI enabled EJB that is invoked on via RMI.

Comment by jwells [ 20/Mar/13 ]

This code in BaseContainer.java causes the warning messages to pop out (near line 1700):

if( (jcdiService != null) && jcdiService.isJCDIEnabled(ejbBundle)) {

jcdiService.injectEJBInstance(context.getJCDIInjectionContext());

Class[] interceptorClasses = interceptorManager.getInterceptorClasses();

interceptorInstances = new Object[interceptorClasses.length];

for(int i = 0; i < interceptorClasses.length; i++)

{ // 299 impl will instantiate and inject the instance, but PostConstruct // is still our responsibility interceptorInstances[i] = jcdiService.createManagedObject(interceptorClasses[i], ejbBundle, false).getInstance(); }

interceptorManager.initializeInterceptorInstances(interceptorInstances);

Comment by jwells [ 20/Mar/13 ]

In particular the line about "jcdiService.createManagedObject" is what does it, and it is because when the interceptor class is viewed as its own ManagedObject (as it is in this case) then the warning is absolutely correct, the @PostConstruct and @PreDestroy are on the ManagedObject itself and are NOT of the proper format.

(I can get rid of the other warning messages by fixing up the aroundInvoke and aroundTimeout to have the proper signature).

Comment by marina vatkina [ 20/Mar/13 ]

May be interceptor instances need to be created differently with the new CDI rules? The SystemInterceptorProxy is an interceptor, not a bean.

Comment by jwells [ 20/Mar/13 ]

Change 60628 removes the warnings.

I did two things to fix it:

1. I changed the system interceptor @AroundInvoke and @AroundTimeout methods to conform to the standard
2. I removed the @PostConstruct and @PreDestroy methods from the set of methods in the AnnotatedType when CDI is not going to be invoking the post-construct or pre-destroy methods.

The other changes are for tests that turned runner.jar into an executable jar that could be run with appclient so as to verify that this change works (there are no longer any warnings in the server log).





[GLASSFISH-19681] Add integration/support for AroundConstruct in CDI Created: 14/Feb/13  Updated: 19/Mar/13  Resolved: 19/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: 4.0

Type: New Feature Priority: Major
Reporter: marina vatkina Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

See Interceptors spec http://java.net/projects/interceptors-spec/downloads/download/interceptor-1-2-dr2.pdf for the description of the feature. Need to integrate support for @Interceptors interceptors and in general between the EJB container and the CDI



 Comments   
Comment by phil.zampino [ 19/Mar/13 ]

It's not clear when this was resolved, but it's working in the latest version.

Comment by tlcksnyder [ 19/Mar/13 ]

It was fixed in: https://issues.jboss.org/browse/WELD-1327, which was Weld 2.0.0Beta5.





[GLASSFISH-19747] Duplication of weld classes causes increase of distribution size by 3.5MB Created: 28/Feb/13  Updated: 12/Aug/13  Resolved: 09/May/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b78
Fix Version/s: 4.0_b89_RC5

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: phil.zampino
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved

 Description   

To support CDI in ACC, we are including weld-se.jar in distribution. Its size is 3.5MB - same as weld-osgi-bundle.jar. A quick analysis shows that the two jars mostly overlapping. See the attached files which list the jar contents as resource names. In fact, the se jar even repackages javax.annotation, javax.el, javax.interceptor inside it. I see no reason for them to be included like that in our product when we already have them in file system in separate places. The only extra set of classes are actually org.jboss.weld.environment.se and crucial META-INF/services files. Here is what we should strive for:
a) Just have all weld related classes in weld-osgi-bundle.jar and make it useable from ACC.
b) If this is not possible, then see the SE specific artifacts can be packaged in to a separate jar and used in conjunction with above jar.



 Comments   
Comment by phil.zampino [ 29/Apr/13 ]

Determining if weld-se-core.jar can be the resolution to this issue.

Comment by phil.zampino [ 09/May/13 ]

Committed revision 61908. Replaced weld-se.jar with weld-se-core.jar

Comment by Sanjeeb Sahoo [ 09/May/13 ]

If this fix was so simple, I am wondering why we didn't do it in 4.0 which is going to be downloaded by a lot of folks. It reduces the benefit of the fix.

Comment by phil.zampino [ 09/May/13 ]
  • What is the impact on the customer of the bug?
    Improved download experience; Reduces the distribution size by almost 3.5M
  • How likely is it that a customer will see the bug and how serious is the bug?
    Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
    What CTS failures are caused by this bug?

Every customer who downloads the distribution will "feel" the additional 3.5M, but there is no associated functional issue.

  • What is the cost/risk of fixing the bug?
    There is little to no risk associated with this change. The functionality is new for 4.0, and has already been in place for some time. This change merely modifies the dependencies to re-use existing copies in the distribution, rather than adding duplicates.

How risky is the fix? How much work is the fix? Is the fix complicated?

  • Is there an impact on documentation or message strings?

There is no doc or message impact.

  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

Quicklook, EJB devtests (these leverage the ACC, so they could be affected)

  • Which is the targeted build of 4.0 for this fix?

B89

  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.

This is not a new revision of the Weld dependencies, just a different packaging thereof.

Comment by michael.y.chen [ 09/May/13 ]

approved for B89.

Comment by phil.zampino [ 10/May/13 ]

Committed revision 61948 to 4.0 branch





[GLASSFISH-19626] NullPointer Exception using @Inject in glassfish build 72 Created: 03/Feb/13  Updated: 30/Mar/13  Resolved: 28/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b70
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: niveditadixitp Assignee: jwells
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish-4.0-b72 , primefaces 3.4 and JSF 2.2 Mojarra in glassfish



 Description   

I am getting Null pointer exception when I use @Inject annotation to inject a service class defined in jar into my fa?ade defined war .
I am using glassfish-4.0-b72 , primefaces 3.4 and JSF 2.2 defined in glassfish. Mojarra loads without any issues and so does primefaces.
When I use @Inject the injected bean does not get instantiated . Please let me know if I am missing something
I have beans.xml included in my .war and .jar as well.



 Comments   
Comment by Hong Zhang [ 04/Feb/13 ]

Assign to CDI team for evaluation.

Comment by tlcksnyder [ 14/Feb/13 ]

Do you have a test case you can share?

Comment by niveditadixitp [ 16/Feb/13 ]

No test case. But can explain in more detail

web layer in web project
include the service project in web project as deployment assembly dependency
1) ManagedBean has reference to the facade class
2) Facade class injects the service layer class defined in service.jar as follows
@Inject
private VendorService vendorService ;
3) included beans.xml in WEB-INF of the web project having content <beans/>

Service and persistent layer classes are in java project
4) VendorService is inerface and VendorServiceImpl is the implementation
5) included beans.xml in META-INF of the javaproject having content <beans/>

Comment by marina vatkina [ 19/Feb/13 ]

I'm wondering is it's the same problem as I reported in http://java.net/jira/browse/GLASSFISH-19581 (which I'm seeing more often in the hudson runs recently)

Comment by jwells [ 27/Mar/13 ]

I'm going to need more information (or a test case). For example, I need to see the code for the ManagedBean and the FacadeClass and I'd like to see the code for VendorService and VendorServiceImpl.

Also, it'd be nice to get service.jar and whatever.war you have to see if I can reproduce this.

Comment by tlcksnyder [ 27/Mar/13 ]

This bug will get moved to a future release without a test case.

Comment by niveditadixitp [ 30/Mar/13 ]

Please find below the code managed bean and the service class in services.jar

/**

  • */
    package net.java.adoptjsr.fcms.web.beans;

import java.io.Serializable;
import java.util.List;

import javax.annotation.PostConstruct;
import javax.faces.bean.ManagedProperty;
import javax.faces.bean.RequestScoped;
import javax.inject.Named;

import net.java.adoptjsr.fcms.facade.VendorFacade;
import net.java.adoptjsr.fcms.facade.impl.VendorFacadeImpl;
import net.java.adoptjsr.fcms.model.TrustedVendor;
import net.java.adoptjsr.fcms.model.Vendor;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

/**

  • @author Nivedita_Dixit
    *
    */
    @Named(value="vendorBean")
    @RequestScoped
    public class VendorMaintainBean implements Serializable {

/**

  • */
    private static final long serialVersionUID = -6731561541756443536L;

/**

  • Logger
    */
    Logger log = LoggerFactory.getLogger(VendorMaintainBean.class);

@ManagedProperty(value="#

{param.page}

")
private String page;

private Vendor vendor;

private List<Vendor> vendors;

private VendorFacade vendorFacade = new VendorFacadeImpl();

/**

  • @return the vendors
    */
    public List<Vendor> getVendors() { return vendors; }

/**

  • @param vendors the vendors to set
    */
    public void setVendors(List<Vendor> vendors) { this.vendors = vendors; }

/**

  • @return the vendorFacade
    */
    public VendorFacade getVendorFacade() { return vendorFacade; }

/**

  • @param vendorFacade the vendorFacade to set
    */
    public void setVendorFacade(VendorFacade vendorFacade) { this.vendorFacade = new VendorFacadeImpl(); }

/**

  • @return the page
    */
    public String getPage() { return page; }

/**

  • @param page the page to set
    */
    public void setPage(String page) { this.page = page; }

/**

  • @return the vendor
    */
    public Vendor getVendor() { return vendor; }

/**

  • @param vendor the vendor to set
    */
    public void setVendor(Vendor vendor) { this.vendor = vendor; }

/**

  • Default Constructor
    */
    public VendorMaintainBean() { super(); vendor = new TrustedVendor(); }

@PostConstruct
public void init()

{ System.out.println(page); page="vendor/search"; }

/**

  • @return
    */
    public String find() { System.out.println( "in find"); return null; }

/**

  • @return
    */
    public String save() { vendorFacade.saveVendor(vendor); vendors = vendorFacade.findVendors(vendor); return null; }

/**

  • @return
    */
    public String delete() { return null; }


    /**
    *
    * @return
    */
    public String clear(){ vendor.setVendorName(null); return null; }

    /**
    *
    * @return
    */
    public String reset(){ return null; }

}

package net.java.adoptjsr.fcms.facade.impl;

import java.util.List;

import javax.inject.Inject;

import net.java.adoptjsr.fcms.facade.VendorFacade;
import net.java.adoptjsr.fcms.model.Vendor;
import net.java.adoptjsr.fcms.service.VendorService;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

/**

  • @author Nivedita_Dixit
  • */
    public class VendorFacadeImpl implements VendorFacade {

/**

  • Logger
    */
    Logger log = LoggerFactory.getLogger(VendorFacadeImpl.class);

@Inject
private VendorService vendorService ;

@Override
public Vendor saveVendor(Vendor vendor)

{ vendor = vendorService.saveVendor(vendor); return vendor; }

@Override
public Vendor findVendor(Vendor vendor)

{ return null; }

public List<Vendor> findVendors(Vendor vendor)

{ return vendorService.findVendors(vendor); }

}

/**

  • */
    package net.java.adoptjsr.fcms.service.impl;

import java.util.List;

import javax.enterprise.inject.Default;

import net.java.adoptjsr.fcms.dao.VendorDao;
import net.java.adoptjsr.fcms.dao.impl.VendorDaoImpl;
import net.java.adoptjsr.fcms.model.Vendor;
import net.java.adoptjsr.fcms.service.VendorService;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

/**

  • @author Nivedita_Dixit
  • */
    @Default
    public class VendorServiceImpl implements VendorService {

/**

  • Logger
    */
    Logger log = LoggerFactory.getLogger(VendorServiceImpl.class);

private VendorDao vendorDao = new VendorDaoImpl();

/**

  • */
    public VendorServiceImpl()

    { super(); }

/**

  • @return the vendorDao
    */
    public VendorDao getVendorDao() { return vendorDao; }

/**

  • @param vendorDao the vendorDao to set
    */
    public void setVendorDao(VendorDao vendorDao) { this.vendorDao = vendorDao; }

/**

  • */
    public Vendor saveVendor(Vendor vendor)

    { vendor = vendorDao.saveVendor(vendor); return vendor; }

/**

  • */
    public void removeVendor(Vendor vendor)

    { vendorDao.removeVendor(vendor); }

/**

  • */
    public List<Vendor> findVendors(Vendor vendor)

    { return vendorDao.findVendors(vendor); }

}





[GLASSFISH-19668] WELD - ClassNotFoundException: BoundContextRequest Created: 12/Feb/13  Updated: 27/Mar/13  Resolved: 21/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.2.2
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: tmulle Assignee: jwells
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64Bit


Tags: cdi, glassfish-3-1-2-2, weld

 Description   

Experienceing the same issue as http://java.net/jira/browse/GLASSFISH-19226 but with the BoundContextRequest class.
We get the error if our direct class or subclass tries to "@Inject BoundContextRequest request;" and our application doesn't deploy.

Seems like that package isn't visible to the server? The classes are in the weld-osgi-bundle.jar.

I've tried the standard 1.1.8-final version and even the 1.1.10-final and same issues.



 Comments   
Comment by jwells [ 20/Mar/13 ]

So... I can't find a class called "BoundContextRequest" in Weld.

I have found these though:

import org.jboss.weld.context.bound.BoundRequestContext;
import org.jboss.weld.context.bound.BoundSessionContext;

However, when I @Inject either of these things into a previously working EJB suddenly the thing isn't even recognized as an EJB anymore:

Command deploy failed.
remote failure: Error occurred during deployment: Exception while deploying the app [ejb1] : Invalid ejb jar ejb1: it contains zero ejb. A valid ejb jar requires at least one session/entity/message driven bean.. Please see server.log for more details.

I've even tried to export the given package org.jboss.weld.context.bound to see if that would fix it, but it does not.

So I guess the questions I have are:

1. What class exactly do you mean (along with package)
2. Can you post the EAR or WAR or EJB jar containing your code that doesn't work?
3. Could you post more of your code so we can see if there is anything else of interest?

Thanks!

Comment by jwells [ 20/Mar/13 ]

I did find this in the log:

[2013-03-20T13:15:40.953-0700] [glassfish 4.0] [SEVERE] [] [global] [tid: _ThreadID=42 _ThreadName=admin-listener(1)] [timeMillis: 1363810540953] [levelValue: 1000] [[
Class [ Lorg/jboss/weld/context/bound/BoundRequestContext; ] not found. Error while loading [ class com.oracle.hk2.devtest.cdi.ejb1.EjbInjectedWithServiceLocator ]]]

So I'm assuming this is the same error you saw...

Comment by jwells [ 21/Mar/13 ]

Added in the package org.jboss.weld.context.bound to the set of exported packages. Verified by injecting org.jboss.weld.context.bound.BoundRequestContext into an EJB via CDI.

Comment by tmulle [ 22/Mar/13 ]

Awesome! Any idea which version of GF 4.0 this will be in? the nightly? or a promoted version so I can try to deploy my project.

Comment by fishcream [ 27/Mar/13 ]

I can't tell from your comment what you did to fix this issue. I have a production server that's running GF 3.1.2.2 that I really need this fixed on. I tried editing the weld-osgi-bundle.jar's MANIFEST.MF file and adding 'org.jboss.weld.context.bound' to the end of the Exported-Package list but it still had the same problem as before. Any change you can share the fix?





[GLASSFISH-20736] CLONE -@Singleton @Startup (EJB) , with an @Observes(notifyObserver = IF_EXISTS) wont Deploy, Created: 01/Aug/13  Updated: 24/Mar/15  Resolved: 24/Mar/15

Status: Closed
Project: glassfish
Component/s: cdi, ejb_container
Affects Version/s: 3.1.2_b23
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ulrichBerl Assignee: jjsnyder83
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.1.2. Windows 7, Java 1.6,


Tags: Singleton, Startup, notifyObserver

 Description   

You get this, but i think GF eat the real weld exception somewhere. This happens only with the notifyObserver parameter, without is working fine, but i want to listen to events only when all i say so!!

I don't Implement any interface or something similar,...

@Singleton
@Startup
@TransactionManagement(TransactionManagementType.BEAN)
public class SubsystemConnectionMonitor {

// stuff
public void subsystemConnectionEventFired(
@Observes(notifyObserver = IF_EXISTS) SubsystemConnectionEvent incomingEvent)

{ subsystemConnectionMonitor.subsystemConnectionEventFired(incomingEvent); }

//other stuff

}

Then you get this,...
2013-03-05 16:54:41.278 SEVERE 20 Exception while loading the app (javax.enterprise.system.core.com.sun.enterprise.v3.server)
2013-03-05 16:54:42.963 SEVERE 20 Exception while shutting down application container (javax.enterprise.system.tools.admin.org.glassfish.deployment.admin)



 Comments   
Comment by jjsnyder83 [ 16/Apr/14 ]

Can you please test this against GF 4.0?





[GLASSFISH-20273] CDI String Producer is visible to the application Created: 10/Apr/13  Updated: 10/Apr/13  Resolved: 10/Apr/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b83
Fix Version/s: None

Type: Bug Priority: Major
Reporter: abien Assignee: jjsnyder83
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: fishcat

 Description   

String injection fails:

@Inject
private String something;

Causes the following exception:

at com.ibm.jbatch.container.cdi.BatchProducerBean.produceProperty(BatchProducerBean.java:46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jboss.weld.annotated.runtime.InvokableAnnotatedMethod.invokeOnInstance(InvokableAnnotatedMethod.java:97)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:77)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstance(MethodInjectionPoint.java:71)
at org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:97)
at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:187)
at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:190)
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:711)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:769)
at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:88)
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:368)
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:377)
at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:142)
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:46)
at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:97)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:158)
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:103)
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:93)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:82)
at com.abien.stringproducerinterference.StringInjectionTarget$Proxy$_$$_WeldClientProxy.getMessage(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:363)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at com.sun.el.parser.AstValue.getValue(AstValue.java:140)
at com.sun.el.parser.AstValue.getValue(AstValue.java:204)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
at com.sun.faces.facelets.el.ELText$ELTextVariable.writeText(ELText.java:227)
at com.sun.faces.facelets.el.ELText$ELTextComposite.writeText(ELText.java:150)
at com.sun.faces.facelets.compiler.TextInstruction.write(TextInstruction.java:85)
... 37 more

The erroneously exposed @Producer also causes the introduction of application producer (ambiguous dependency error).

The problem seems to be caused by the batch component. However right now it is not possible to chooose a batch "component" from the Jira menu.



 Comments   
Comment by jjsnyder83 [ 10/Apr/13 ]

You must qualify String injections because the new Batch jar has a String producer. The batch String produce is qualified.





[GLASSFISH-20359] Weld InvocationContext Issue causing CTS failures in ejb30/bb suite Created: 19/Apr/13  Updated: 25/Apr/13  Resolved: 25/Apr/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b85
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: tlcksnyder Assignee: phil.zampino
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Weld InvocationContext issue:
ejb30/bb/session/stateless/interceptor/listener/override/Client.java#getParametersEmptyTest
ejb30/bb/session/stateless/interceptor/listener/override/Client.java#getParametersTest
ejb30/bb/session/stateless/interceptor/listener/override/Client.java#setParametersTest
ejb30/bb/session/stateful/interceptor/listener/annotated/Client.java#getParametersEmptyTest
ejb30/bb/session/stateful/interceptor/listener/annotated/Client.java#getParametersTest
ejb30/bb/session/stateful/interceptor/listener/annotated/Client.java#setParametersTest
ejb30/bb/session/stateful/interceptor/listener/override/Client.java#getParametersEmptyTest
ejb30/bb/session/stateful/interceptor/listener/override/Client.java#getParametersTest
ejb30/bb/session/stateful/interceptor/listener/override/Client.java#setParametersTest
ejb30/bb/session/stateless/interceptor/listener/annotated/Client.java#getParametersEmptyTest
ejb30/bb/session/stateless/interceptor/listener/annotated/Client.java#getParametersTest
ejb30/bb/session/stateless/interceptor/listener/annotated/Client.java#setParametersTest
ejb30/bb/mdb/interceptor/listener/annotated/Client.java#getParametersTest
ejb30/bb/mdb/interceptor/listener/descriptor/Client.java#getParametersTest



 Comments   
Comment by arjavdesai [ 19/Apr/13 ]

There are two more failures due to this issue:

ejb30/bb/mdb/interceptor/listener/annotated/Client.java#getMethodTest
ejb30/bb/mdb/interceptor/listener/descriptor/Client.java#getMethodTest

Comment by phil.zampino [ 25/Apr/13 ]

Modified the way interceptors are created via Weld





[GLASSFISH-20357] Weld Duplicate Interceptors in ejb30_bb suite: see https://issues.jboss.org/browse/WELD-1410 Created: 19/Apr/13  Updated: 25/Apr/13  Resolved: 25/Apr/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b85
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: tlcksnyder Assignee: phil.zampino
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Duplicate Interceptors (NOT fixed by Weld 2.0.0CR2) See https://issues.jboss.org/browse/WELD-1410
com/sun/ts/tests/ejb30/bb/session/stateless/interceptor/listener/mixed/Client.java#interceptorOrderingOverride: Client_interceptorOrderingOverride
com/sun/ts/tests/ejb30/bb/session/stateless/interceptor/listener/mixed/Client.java#methodLevelClassLevelInterceptorMixedTest: Client_methodLevelClassLevelInterceptorMixedTest
com/sun/ts/tests/ejb30/bb/session/stateless/interceptor/listener/mixed/Client.java#methodLevelInterceptorMixedTest: Client_methodLevelInterceptorMixedTest
com/sun/ts/tests/ejb30/bb/session/stateless/interceptor/listener/mixed/Client.java#repeatedInterceptors: Client_repeatedInterceptors
7832: Exception during lifecycle processing
7833: org.glassfish.deployment.common.DeploymentException: CDI deployment failure:Duplicate interceptor class definition when binding com.sun.ts.tests.ejb30.common.interceptor.Interceptor1 on AROUND_INVOKE
7834: at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:223)
7835: at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
7836: at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
7837: at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
7838: at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
7839: at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
7840: at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:537)
7841: at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
7842: at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
7843: at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
7844: at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
7845: at org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:164)
7846: at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:595)
7847: at org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:482)
7848: at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:410)
7849: at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:401)
7850: at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:233)
7851: at java.util.TimerThread.mainLoop(Timer.java:555)
7852: at java.util.TimerThread.run(Timer.java:505)
7853: Caused by: org.jboss.weld.interceptor.proxy.InterceptorException: Duplicate interceptor class definition when binding com.sun.ts.tests.ejb30.common.interceptor.Interceptor1 on AROUND_INVOKE
7854: at org.jboss.weld.interceptor.builder.InterceptionModelImpl.validateDuplicateInterceptors(InterceptionModelImpl.java:147)
7855: at org.jboss.weld.interceptor.builder.InterceptionModelImpl.appendInterceptorClassesToList(InterceptionModelImpl.java:139)
7856: at org.jboss.weld.interceptor.builder.InterceptionModelImpl.appendInterceptors(InterceptionModelImpl.java:120)
7857: at org.jboss.weld.interceptor.builder.InterceptionModelBuilder$MethodInterceptorDescriptor.with(InterceptionModelBuilder.java:114)
7858: at org.jboss.weld.injection.producer.InterceptionModelInitializer.initClassDeclaredEjbInterceptors(InterceptionModelInitializer.java:251)
7859: at org.jboss.weld.injection.producer.InterceptionModelInitializer.initEjbInterceptors(InterceptionModelInitializer.java:233)
7860: at org.jboss.weld.injection.producer.InterceptionModelInitializer.init(InterceptionModelInitializer.java:113)
7861: at org.jboss.weld.injection.producer.BeanInjectionTarget.initializeInterceptionModel(BeanInjectionTarget.java:91)
7862: at org.jboss.weld.injection.producer.ejb.SessionBeanInjectionTarget.initializeAfterBeanDiscovery(SessionBeanInjectionTarget.java:81)
7863: at org.jboss.weld.injection.producer.InjectionTargetInitializationContext.initialize(InjectionTargetInitializationContext.java:42)
7864: at org.jboss.weld.injection.producer.InjectionTargetService.initialize(InjectionTargetService.java:58)
7865: at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:521)
7866: at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:211)
7867: ... 18 more



 Comments   
Comment by tlcksnyder [ 25/Apr/13 ]

Fixed with Weld 2.0.0.CR4 that went into 4.0_b86_RC2





[GLASSFISH-20323] FindBugs fixes Created: 16/Apr/13  Updated: 19/Sep/14  Resolved: 12/Jun/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b83
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: phil.zampino
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by jjsnyder83 [ 18/Apr/13 ]
  • What is the impact on the customer of the bug?
    None

How likely is it that a customer will see the bug and how serious is the bug?
Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
What CTS failures are caused by this bug?
findBugs fix

  • What is the cost/risk of fixing the bug?
    None

How risky is the fix? How much work is the fix? Is the fix complicated?
very minor

  • Is there an impact on documentation or message strings?
    No
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    quicklook
  • Which is the targeted build of 4.0 for this fix?
    4.0_b85
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
    N/A




[GLASSFISH-20637] Java EE 7 CDI issues on GlassFish 4 Created: 16/Jun/13  Updated: 11/May/15  Resolved: 11/May/15

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b89_RC5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: biemond Assignee: phil.zampino
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

mac osx


Tags: 4_0_1-approved, cdi, glassfish4, jsf2_2

 Description   

Hi,

Got some CDI issues on the latest GlassFish version

First in JSF2.2 the flowDefinition of flows does not work , I needed to use the faces-config.xml and that works perfectly

my example
@Named("flow1")
public class Flow1 implements Serializable {

private static final long serialVersionUID = -1L;

@Produces @FlowDefinition
public Flow buildMyFlow(@FlowBuilderParameter FlowBuilder flowBuilder)

{ System.out.println("flowdef"); String flowId = "flow1"; flowBuilder.id("", flowId); flowBuilder.viewNode(flowId, "/flow1/" + flowId + ".xhtml").markAsStartNode(); return flowBuilder.getFlow(); }

}

Also in the websockets and do an inject of session bean and does not do anything , also listen to an CDI event inside does not work

@ServerEndpoint("/mywebsocket")
public class MyWebSocket implements Serializable {

@Inject
JmsSessionBean jmsBean;

public void onJMSMessage(@Observes @CDIJmsEvent Message msg) {
System.out.println("Got JMS Message at WebSocket!");
try {
for (Session s : sessions)

{ s.getBasicRemote().sendText("message from JMS: " + msg.getBody(String.class)); }

} catch (IOException | JMSException ex)

{ ex.printStackTrace(); }

}

Inside a managed bean Inject and the CDI events works perfectly



 Comments   
Comment by Darious3 [ 17/Jun/13 ]

Flow example with formatting:

@Named("flow1")
public class Flow1 implements Serializable {

    private static final long serialVersionUID = -1L;

    @Produces @FlowDefinition
    public Flow buildMyFlow(@FlowBuilderParameter FlowBuilder flowBuilder) { 
       
        String flowId = "flow1"; 
        flowBuilder.id("", flowId); 
        flowBuilder.viewNode(flowId, "/flow1/" + flowId + ".xhtml").markAsStartNode(); 

        return flowBuilder.getFlow();
    }
}

WebSocket with formatting

@ServerEndpoint("/mywebsocket")
public class MyWebSocket implements Serializable {

    @Inject
    JmsSessionBean jmsBean;

    public void onJMSMessage(@Observes @CDIJmsEvent Message msg) {
        try {
            for (Session session : sessions) {
                session.getBasicRemote().sendText("message from JMS: " + msg.getBody(String.class));
            }
        } catch (IOException | JMSException ex) {
            ex.printStackTrace();
        }
    }
}
Comment by jjsnyder83 [ 17/Jun/13 ]

I believe the WebSocket issue is a duplicte of : https://java.net/jira/browse/GLASSFISH-20371.

For the JSF issue can you provide more information on what the expected results are?

Comment by biemond [ 17/Jun/13 ]

Hi,

here is my netbeans projects on glassfish 4 https://github.com/biemond/JavaEE7

I defined some JSF 2.2 flows in
https://github.com/biemond/JavaEE7/tree/master/WebApp7EE/WebApp7EE-war/web/flow1

When I add this flow definition in the faces-config.xml it works fine
https://github.com/biemond/JavaEE7/blob/master/WebApp7EE/WebApp7EE-war/web/WEB-INF/faces-config.xml

but when I try to do the same in this class with the help of CDI
@Produces @FlowDefinition
public Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder)
in java class
https://github.com/biemond/JavaEE7/blob/master/WebApp7EE/WebApp7EE-war/src/java/nl/amis/web/flow/Flow1.java

It does not do anything ( don't see any CDI error ) and the page /flow1.xhtml can not be found.

Thanks

Comment by jjsnyder83 [ 20/Apr/15 ]

Is this still an issue?





[GLASSFISH-20587] Full CDI 1.1 compliance Created: 29/May/13  Updated: 19/Jun/13  Resolved: 19/Jun/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b90
Fix Version/s: None

Type: Task Priority: Major
Reporter: aaronjwhiteside Assignee: phil.zampino
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Full CDI 1.1 compliance

Currently section 12.1 and 12.4 of the CDI specification do not work in Glassfish 4.0 b90.



 Comments   
Comment by phil.zampino [ 13/Jun/13 ]

Could you please be more specific about what exactly isn't working for you? Glassfish is 100% compliant per the TCK, but it is possible that the TCK isn't complete in its coverage.

Comment by phil.zampino [ 19/Jun/13 ]

Without specific information about what is not working, there really isn't anything to do here.





[GLASSFISH-19225] Cannot inject Weld BoundSessionContext Created: 24/Oct/12  Updated: 14/Feb/13  Resolved: 14/Feb/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: JSchneider Assignee: tlcksnyder
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: weld

 Description   

According to Weld documentation, one should be able to inject the BoundSessionContext using

@Inject @Bound SessionContext sessionContext;

This results in the following error using the Weld version included with Glassfish 3.1.2.2:

org.jboss.weld.exceptions.DeploymentException: WELD-001409 Ambiguous dependencies for type [SessionContext] with qualifiers [@Default] at injection point [[field] @Inject com.smashmeter.service.ContextManager.sessionContext]. Possible dependencies [[org.jboss.weld.bean-meter-Built-in-org.jboss.weld.context.bound.BoundSessionContext, org.jboss.weld.bean-meter-Built-in-org.jboss.weld.context.http.HttpSessionContext]]

This should not be the case, as the "@Bound" qualifier is specified.

Furthermore, trying to make any reference to the interface BoundSessionContext which extends SessionContext will result in a ClassNotFoundExeption.



 Comments   
Comment by shreedhar_ganapathy [ 13/Dec/12 ]

-> CDI team

Comment by tlcksnyder [ 14/Feb/13 ]

Duplicate of GLASSFISH-19668





[GLASSFISH-19226] Weld BoundSessionContext class not found Created: 24/Oct/12  Updated: 14/Feb/13  Resolved: 14/Feb/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: JSchneider Assignee: tlcksnyder
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: weld

 Description   

The weld-osgi-bundle.jar clearly contains the org.jboss.weld.context.bound.BoundSessionContext interface. However, including reference to this interface results in the following immediately upon trying to deploy an application.

SEVERE: Class [ Lorg/jboss/weld/context/bound/BoundSessionContext; ] not found.



 Comments   
Comment by shreedhar_ganapathy [ 13/Dec/12 ]

Assigning to weld (CDI) team

Comment by tlcksnyder [ 14/Feb/13 ]

Duplicate of GLASSFISH-19668





[GLASSFISH-19288] Deploying an ear with an ejb jar with a Session bean that specializes another causes AmbiguousDependencyException Created: 05/Nov/12  Updated: 28/Mar/13  Resolved: 28/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b53
Fix Version/s: 4.0_b63

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

Tags: req-weld-fix

 Description   

Define a specializing ejb like below, place it in a jar in the root directory of an ear. This causes an AmbiguousDependencyException when the injection point is:
@Inject
SessionSpecializationService sessionSpecializationService;

@Local
public interface SessionSpecializationService {}

@Stateless
public class SessionSpecializationServiceImplementation implements SessionSpecializationService {}

@Stateless
@Specializes
public class MockSessionSpecializationService extends SessionSpecializationServiceImplementation {}



 Comments   
Comment by jjsnyder83 [ 12/Nov/12 ]

The previous change was incorrect. I have reverted the change.
Committed revision 56969.

Comment by jjsnyder83 [ 12/Nov/12 ]

There seems to be a bug in Weld causing this.

Comment by tlcksnyder [ 28/Mar/13 ]

Resolved as of Weld 2.0.0.Beta6.





Integrate CDI 1.1 (GLASSFISH-19191)

[GLASSFISH-19276] Ingegrate Weld 2.0 Created: 01/Nov/12  Updated: 05/Mar/13  Resolved: 05/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: 4.0_b72_EE7MS4

Type: Sub-task Priority: Major
Reporter: jjsnyder83 Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by jjsnyder83 [ 01/Nov/12 ]

Integrate GlassFish with Weld 2.0 Currently Weld is at Alpha 3. The 2.0 Final is scheduled for end of 2012.

The specific integration points are defined here: https://community.jboss.org/wiki/WeldIntegratorGuide-ChangesForWeld20

This will also include passing the JSR299.

Comment by tlcksnyder [ 05/Mar/13 ]

CDI integration is checked & available as of b79-02_28_2013





[GLASSFISH-19429] CDI integration does not handle properly beans.xml files from library JAR Created: 11/Dec/12  Updated: 19/Sep/14  Resolved: 05/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.2
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: win_wave Assignee: jjsnyder83
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 x64, Java Oracle jdk1.7.0_03


Tags: beans, cdi, jar

 Description   

If you enable Decorator (may be also Interceptors, Alternatives) in beans.xml in JAR, which included to WAR application package, it Glassfish does not enable them properly (at least Decorators for sure).
If uses only "first" beans.xml file from the resources, even if you have several JARs. By CDI specs, we should enable decorator at least in one bundle, to make it enabled.
Structure of WAR:

  • WEB-INF/beans.xml
  • lib1.jar
    • MEAT-INF/beans.xml <-- here we enable decorator A
    • classes...
  • lib2.jar
    • MEAT-INF/beans.xml <-- here we enable decorator B
    • classes...
      Result: Only decorator A will be loaded!!

Problem in code:
org.glassfish.weld.BeanDeploymentArchiveImpl (org.glassfish.main.web:weld-integration:jar:3.1.2)
line 503:
URL beansXmlUrl = Thread.currentThread().getContextClassLoader().getResource(entry); <-- here is entry variable, which is always "META-INF/beans.xml", that makes wUris.add(beansXmlUrl.toURI()); context loader return always the same resource file

there are exists already "proper" way of loading beans.xml, it used to load WEB-INF/beans.xml from WAR:
line 352:
URI uri = archive.getURI();
File file = new File(uri.getPath() + entry);
URI beansXmlUri = file.toURI();
wUris.add(beansXmlUri);

I think, the same way should be implemented to load META-INF/beans.xml from JARs

WORKAROUND:

I've found solution, which is not complient, but at least works for now.
I need to have such structure:

  • WEB-INF/beans.xml
  • lib1.jar
    • MEAT-INF/beans.xml <-- leave that empty
    • WEB-INF/beans.xml <-- here we enable decorator A
    • classes...
  • lib2.jar
    • MEAT-INF/beans.xml <-- leave that empty
    • WEB-INF/beans.xml <-- here we enable decorator B
    • classes...


 Comments   
Comment by win_wave [ 11/Dec/12 ]

Actually workaround does not work. It was working in Eclipse, it was deploying open projects as folders, and properly found all resources. In case of jar package it fails to properly construct path to beans.xml

Comment by win_wave [ 11/Dec/12 ]

The working workaround is: Identify library which is "first", and add to it's beans.xml all required info about registration.
How to identify "first" library: I think, it is identified by alphabetical order. In order to be sure you can add comment into beans.xml like <!-- my lib 1--> into all libraries and after see into folder <domain_folder>\generated\<WAR_APP_NAME>\loader_<SOME_NUMBER>\META-INF\beans.xml, and check what comment it contains.

Actually that bug, "enables" possibility to configure CDI interceptors independently of the libraries. So it is possible to create library like "_configure.jar" which will contain all configurations.

Also figured out, that this issue is duplicate for http://java.net/jira/browse/GLASSFISH-18802

Comment by jjsnyder83 [ 05/Mar/13 ]

Duplicate of http://java.net/jira/browse/GLASSFISH-18802





[GLASSFISH-21407] CDI Interceptors packaged in jar does are not read Created: 06/Aug/15  Updated: 28/Sep/15  Resolved: 28/Sep/15

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: fmateo Assignee: jjsnyder83
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:
  • OS : Windows 7 - 32 bits
  • Java 8_31

Tags: beans.xml, cdi, discovery

 Description   

I am developing a web application. It is deployed as a WAR file.
This application is implemented using JEE 7: CDI and REST.

I have a requirement for caching certain web service calls. To do this, I use JCache standard and the reference CDI jcache annotations implementation (cache-annotations-ri-cdi-1.0.0.jar).

cache-annotations-ri-cdi-1.0.0.jar contains a beans.xml file in the META-INF directory which should be discovered by the container automatically. But it doesn't. The beans.xml in the jar looks like this

<beans xmlns="http://java.sun.com/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="
http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
    <interceptors>
        <class>org.jsr107.ri.annotations.cdi.CacheResultInterceptor</class>
        <class>org.jsr107.ri.annotations.cdi.CachePutInterceptor</class>
        <class>org.jsr107.ri.annotations.cdi.CacheRemoveEntryInterceptor</class>
        <class>org.jsr107.ri.annotations.cdi.CacheRemoveAllInterceptor</class>
    </interceptors>
</beans>

In my application WEB-INF directory I have placed an empty beans.xml file:


<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">

</beans>

I placed an annotation @CacheResult over a business method which should be intercepted by the registered jCache interceptors.
It didn't work in my initial test.
The only way to make it works I found was to register jsr107 interceptors in the WEB-INF/beans.xml of the application.

As far as I understand CDI spec, the discovery should be done automatically.



 Comments   
Comment by jjsnyder83 [ 06/Aug/15 ]

Try adding @Priority to the interceptor.

Comment by fmateo [ 07/Aug/15 ]

The problem is that the interceptor is packaged into the Jcache cdi reference implementation (cache-annotations-ri-cdi-1.0.0.jar). I'm just a client of this RI using the jar so I can not annotate the interceptor.

If you are suggesting that there's some bug in the RI, I can download source code and try that modification.

Comment by jjsnyder83 [ 07/Aug/15 ]

No I don't think there's a bug. If the interceptor is not annotated with @Priority then you must enable it via beans.xml.

Comment by fmateo [ 07/Aug/15 ]

Looking at interceptor source code from Jcache ri :

CacheResultInterceptor.java
@CacheResult
@Interceptor
public class CacheResultInterceptor extends AbstractCacheResultInterceptor<InvocationContext> {

....
}

The interceptor is not annotated with @Priority. But it is declared into META-INF/beans.xml in the jar file.
Shouldn't the container discover it anyway?

Comment by jjsnyder83 [ 08/Aug/15 ]

Iirc you have to put it in all beans.xml of the jars in which the interceptor is used. So if a class in jar a is using an interceptor in jar b then jar a's beans.xml must have the interceptor enabled in it.

Comment by fmateo [ 08/Aug/15 ]

Thank you, you are completely right.
I checked out the Bean discovery section in CDI spec 1.2 . Interceptors and Decorators are only enabled for the bean archive which defines them. The application need to explicity enable them.





[GLASSFISH-20483] Enable and disable implicit scanning per JAR. Created: 07/May/13  Updated: 17/Dec/15  Resolved: 12/Jun/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: phil.zampino
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

beans.xml cannot be added to a third-party JAR. Disabling implicit CDI is one option but but it works at the application level.

This will not work when different third-party JARs make different assumptions about implicit beans. So it would be helpful if GlassFish (or Weld) offered a way to enable or disable implicit scanning per JAR.



 Comments   
Comment by jjsnyder83 [ 07/May/13 ]

According to 12.1 of CDI spec:
"For compatibility with Contexts and Dependency 1.0, products must contain an option to cause an archive to be ignored by the container when no beans.xml is present."

We are probably a little light in our implementation of this as we only allow entire apps to be enabled/disabled for implicit scanning.

Comment by aaronjwhiteside [ 28/May/13 ]

Related to GLASSFISH-20579. It would be good if this was part of the final 4.0.0 release. Perhaps something in glassfish-web.xml?

Comment by aaronjwhiteside [ 28/May/13 ]

http://docs.jboss.org/weld/reference/latest/en-US/html/configure.html

This doesn't work as far as I can tell.

Maybe fixing the WELD integration so that this works is the solution?

Comment by aaronjwhiteside [ 29/May/13 ]

I can add a beans.xml as per the CDI 1.1 spec, but that does not appear to work either.

CDI 1.1 Spec, Section 12.1
bean-discovery-mode="none" should disable an archives contents from being considered by CDI.

Comment by phil.zampino [ 10/Jun/13 ]

The cited beans.xml addition should work. If it is being applied correctly, and Glassfish is not honoring it, then that's a bug. Can you provide an application to reproduce this behavior?

Additionally, there is a new deployment property that will disable support for implicit bean archives at the application level. (asadmin deploy --property implicitCdiEnabled=false <archive file>)

Comment by everett_toews [ 07/Oct/14 ]

How exactly was this resolved?

bean-discovery-mode="none" does work for me but this issue is for disabling implicit scanning per JAR.

To disable scanning per JAR I tried the following beans.xml and it didn't work for me. I continue to get WELD errors.

<beans xmlns="http://java.sun.com/xml/ns/javaee" 
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
       xmlns:weld="http://jboss.org/schema/weld/beans" 
       xsi:schemaLocation="
          http://java.sun.com/xml/ns/javaee http://docs.jboss.org/cdi/beans_1_0.xsd
          http://jboss.org/schema/weld/beans http://jboss.org/schema/weld/beans_1_1.xsd">
    <weld:scan>
        <weld:exclude name="org.jclouds.**" />
    </weld:scan>
</beans>

Should this beans.xml work with Glassfish 4.1?

Can someone provide an example of a beans.xml file that excludes per JAR that does work?

Thanks.

Comment by everett_toews [ 07/Oct/14 ]

Just to be clear, I put that beans.xml file in the web app WEB-INF dir.

Comment by reipince [ 17/Dec/15 ]

This is not fixed.

I have jars that contain unimplemented interfaces, and therefore when they're scanned for CDI, they cause an error and I can't deploy my app.

I tried explicitly using an exclude rule in my beans.xml but it seems to take no effect.

My options are:

  • disable implicit cdi at the application level
  • disable cdi scanning at the beans.xml level (using "none" as the bean-discovery-mode).

Both of these options are bad since they require me to explicitly annotate everything that's being injected right now, which is quite a lot of stuff...

Comment by jjsnyder83 [ 17/Dec/15 ]

You have the following choices:
1) Disable implicit CDI for all apps. Use this command:
asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=false

2) Disable CDI for each jar you do not want to participate in CDI. To do this you must add a beans.xml to each individual jar with the following content:

<beans
xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
bean-discovery-mode="none">
</beans>

Note that for option 2 you must do this for each individual jar. The beans.xml in WEB-INF only applies to the classes in WEB-INF/classes.





[GLASSFISH-15009] Weld JSF Permalink Example : Failure Created: 06/Dec/10  Updated: 21/Mar/13  Resolved: 21/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: 4.0

Type: Bug Priority: Minor
Reporter: rogerk Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

weld-int-required


 Description   

See: http://java.net/jira/browse/GLASSFISH-13182

The application has beans.xml here:
WEB-INF/classes/META-INF/beans.xml

However, the GlassFish Weld Integration module expects beans.xml to be under WEB-INF:
WEB-NF/beans.xml

I haven't checked the Weld specification in a while, so if WEB-INF/classes/META-INF/beans.xml is a valid location,
then the GlassFish Weld Integration module will have to be modified to accommodate this location.
The workaround for now would be to just put beans.xml under WEB-INF directly:
WEB-NF/beans.xml
[ Show » ]
rogerk added a comment - 06/Dec/10 11:49 AM Ok - the problem is as follows... The application has beans.xml here: WEB-INF/classes/META-INF/beans.xml However, the GlassFish Weld Integration module expects beans.xml to be under WEB-INF: WEB-NF/beans.xml I haven't checked the Weld specification in a while, so if WEB-INF/classes/META-INF/beans.xml is a valid location, then the GlassFish Weld Integration module will have to be modified to accommodate this location. The workaround for now would be to just put beans.xml under WEB-INF directly: WEB-NF/beans.xml



 Comments   
Comment by Sivakumar Thyagarajan [ 07/Dec/10 ]

As per Section 12.1 of CDI 1.0 specification:
> • The WEB-INF/classes directory of a war is a bean archive if there is a file named beans.xml in the WEB-INF directory of the war.
> • A directory in the JVM classpath is a bean archive if it has a file named beans.xml in the META-INF directory.

So, the usage of WEB-INF/classes/META-INF/beans.xml doesn't sound right. Making this fix, solves the issue
move the file (in weld-core): from
examples/jsf/permalink/src/main/resources/META-INF/beans.xml
to
examples/jsf/permalink/src/main/webapp/WEB-INF/beans.xml

I am clarifying if this scenario is valid and will close the bug after I undestand if this is a portable usage scenario.

Comment by Sivakumar Thyagarajan [ 07/Dec/10 ]

As per Section 12.1 of CDI 1.0 specification:
> • The WEB-INF/classes directory of a war is a bean archive if there is a file named beans.xml in the WEB-INF directory of the war.
> • A directory in the JVM classpath is a bean archive if it has a file named beans.xml in the META-INF directory.

So, this is an non-portable usage scenario. I have raised https://jira.jboss.org/browse/WELD-780 to get this fixed in Weld jsf/permalink examples. I have also raised a RFE in GlassFish to support this scenario http://java.net/jira/browse/GLASSFISH-15018

Comment by Sivakumar Thyagarajan [ 07/Dec/10 ]

Marking this as Weld-int-required as we have raised https://jira.jboss.org/browse/WELD-780 to get this fixed in Weld jsf/permalink examples.

Comment by Sivakumar Thyagarajan [ 17/Dec/10 ]

Marking this issue as minor as the fix is needed in a weld sample and it is easy to make this change by the developer.

Comment by mojavelinux [ 26/Jan/11 ]

I have submitted a patch to the Weld issue.

Your understanding of the location for beans.xml is correct. The example was in error.

Despite the correction, its still necessary to put a second beans.xml on the classpath (src/main/resources/META-INF) when deploying with the embedded Jetty Maven plugin because of how it arranges the deployment.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Comment by Sivakumar Thyagarajan [ 10/Dec/12 ]

Transferring to JJ Snyder

Comment by tlcksnyder [ 21/Mar/13 ]

Issue fixed as of weld-1.1.10.Final. Successfully tested with 1.1.10 final in GF 3.1.2, and Weld 2.0.0Beta6 in GF 4.





[GLASSFISH-18227] Duplicate log lines for single CDI Injection in a single servlet Created: 19/Jan/12  Updated: 09/Feb/12  Resolved: 09/Feb/12

Status: Closed
Project: glassfish
Component/s: cdi, OSGi
Affects Version/s: 3.1.1
Fix Version/s: 4.0_b25

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


 Description   

The a war containing a single Servlet:

@WebServlet( name = "HelloServlet", urlPatterns = "/HelloServlet" )
public class HelloServlet extends HttpServlet {

    @Inject
    @OSGiService( dynamic = true )
    private ExampleService exampleService;

    @Override
    protected void doGet( final HttpServletRequest httpServletRequest, final HttpServletResponse httpServletResponse )
    throws ServletException, IOException
    {
        httpServletResponse.getWriter().write( exampleService.helloWorld() );
    }
}

Upon deployment the follow lines are printed out:

[#|2012-01-19T17:29:26.044-0500|INFO|glassfish3.1.1|org.glassfish.osgicdi.impl|_ThreadID=58;_ThreadName=Thread-2;|---- Injection requested for framework service type interface com.mm.osgiexample.spi.ExampleService and annotated with dynamic=true, serviceCriteria=|#]

[#|2012-01-19T17:29:26.131-0500|INFO|glassfish3.1.1|org.glassfish.osgicdi.impl|_ThreadID=58;_ThreadName=Thread-2;|---- Injection requested for framework service type interface com.mm.osgiexample.spi.ExampleService and annotated with dynamic=true, serviceCriteria=|#]

[#|2012-01-19T17:29:26.132-0500|INFO|glassfish3.1.1|org.glassfish.osgicdi.impl|_ThreadID=58;_ThreadName=Thread-2;|---- Injection requested for framework service type interface com.mm.osgiexample.spi.ExampleService and annotated with dynamic=true, serviceCriteria=|#]

[#|2012-01-19T17:29:26.134-0500|INFO|glassfish3.1.1|org.glassfish.osgicdi.impl|_ThreadID=58;_ThreadName=Thread-2;|---- Injection requested for framework service type interface com.mm.osgiexample.spi.ExampleService and annotated with dynamic=true, serviceCriteria=|#]

[#|2012-01-19T17:29:26.135-0500|INFO|glassfish3.1.1|org.glassfish.osgicdi.impl|_ThreadID=58;_ThreadName=Thread-2;|---- Injection requested for framework service type interface com.mm.osgiexample.spi.ExampleService and annotated with dynamic=true, serviceCriteria=|#]

Note sure if this is just a logging issue or if the implementation is parsing/instantiating/binding/whatever the ExampleService multiple times.



 Comments   
Comment by Sivakumar Thyagarajan [ 09/Feb/12 ]

Fixed as part of
Sending osgi-cdi/src/main/java/org/glassfish/osgicdi/impl/OSGiServiceExtension.java
Transmitting file data .
Committed revision 52518.

When osgi-cdi 1.0.3 is integrated into GF trunk, this would be available through GF nightly builds. As of now, I am marking this as fixed in 4.0_b25.





[GLASSFISH-19091] Method call to injected singleton hangs when called from an asynchronous task whose future is blocking Created: 20/Sep/12  Updated: 29/Mar/13  Resolved: 29/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.2.2
Fix Version/s: 4.0

Type: Bug Priority: Minor
Reporter: GarethSiret Assignee: jjsnyder83
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: GZip Archive Test-temp.tar.gz    

 Description   

If you attempt to execute a call to an @Asynchronous method in a stateless bean, and then call get on the returned future, any calls to injected singletons in the @Asynchronous method will hang unless the singleton has previously been used outside the @Asynchronous method.

The workaround is to call a method on the singleton before calling it in the @Asynchronous method so that the proxy has already resolved a concrete implementation from the glassfish server before the @Asynchronous method is called.

I have attached an example application source that replicates the issue in 3.1.2.2.



 Comments   
Comment by tlcksnyder [ 29/Mar/13 ]

Provided app fails to deploy:
Exception while deploying the app [test] : The lifecycle method [doTest] must not throw a checked exception. Related annotation information: annotation [@javax.annotation.PostConstruct()] on annotated element [public void StartupSingleton.doTest() throws java.lang.Exception] of type [METHOD]
The lifecycle method [doTest] must not throw a checked exception. Related annotation information: annotation [@javax.annotation.PostConstruct()] on annotated element [public void StartupSingleton.doTest() throws java.lang.Exception] of type [METHOD]
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:367)
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:375)
at org.glassfish.apf.impl.AnnotationProcessorImpl.processAnnotations(AnnotationProcessorImpl.java:289)
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:217)
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:134)
at com.sun.enterprise.deployment.archivist.Archivist.processAnnotations(Archivist.java:626)
at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:462)
at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:446)
at com.sun.enterprise.deployment.archivist.Archivist.readRestDeploymentDescriptors(Archivist.java:419)
at com.sun.enterprise.deployment.archivist.Archivist.readDeploymentDescriptors(Archivist.java:396)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:271)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:280)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:241)
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openArchive(ApplicationFactory.java:161)
at org.glassfish.javaee.core.deployment.DolProvider.processDOL(DolProvider.java:198)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:222)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:96)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:878)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:818)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:374)
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)
Caused by: java.lang.IllegalArgumentException: The lifecycle method [doTest] must not throw a checked exception
at com.sun.enterprise.deployment.annotation.handlers.AbstractResourceHandler.validateAnnotatedLifecycleMethod(AbstractResourceHandler.java:186)
at com.sun.enterprise.deployment.annotation.handlers.PostConstructHandler.processAnnotation(PostConstructHandler.java:72)
at com.sun.enterprise.deployment.annotation.handlers.AbstractResourceHandler.processAnnotation(AbstractResourceHandler.java:142)
at com.sun.enterprise.deployment.annotation.factory.SJSASFactory$LazyAnnotationHandler.processAnnotation(SJSASFactory.java:148)
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:344)
... 34 more

Upon fixing app, it deploys & no hang present.





[GLASSFISH-18823] Dynamic injection of custom properties Created: 22/Jun/12  Updated: 12/Aug/13  Resolved: 18/Jun/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.1_b12
Fix Version/s: future release

Type: Improvement Priority: Minor
Reporter: mkarg Assignee: phil.zampino
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GF3.1.1 Win7 Pro SP1 (64 Bit) JDK 1.6.0_26



 Description   

Sometimes there is a need to modify properties at runtime, i. e. modifying business level application behaviour changes without restarting the domain. This makes sense for example in public services where a planned outage is not wanted.

This can be done in GF3.1.1 by using custom properties which are looked up using JNDI code.

But JNDI is not as smart as CDI, so one wishes to get injection instead. While the injection works, it is static. This means, the change will not get reflected until a domain restart.

We would be really glad if this would work dynamically, i. e. a modification of a custom property would inject at once without the need to restart the domain or the need to use JNDI code.



 Comments   
Comment by jthoennes [ 04/Jul/12 ]

Hello, is this feasible to be implemented?

Comment by marina vatkina [ 05/Jul/12 ]

I'm not sure if the solution is to be in naming or CDI. Let's start with naming

Comment by Cheng Fang [ 12/Jul/12 ]

Since it works with custom resource lookup, have you tried adding an additional proxy or container custom resource, which looks up the dynamic value of the first resource?

You can inject the proxy resource into your application as usual. But this requires that class to be available to server runtime (outside your application packaging) and thus complicates application configuration.

CDI has a Provider type (http://docs.oracle.com/javaee/6/api/index.html?javax/inject/Provider.html), not sure if it can be configured for the dynamic values.

Comment by mkarg [ 13/Jul/12 ]

Maybe you misunderstood why I suggested this feature: I want to get rid of using JNDI. If I am using CDI to write a provider as you suggested, that provider in turn has to use JNDI again. So what did I win? Just even more work and a much complexer solution. But the target is to have LESS work and REDUCE complexity. So CDI certainly will remove JNDI from my bean, but it will simply move it to another bean.

Comment by Cheng Fang [ 13/Jul/12 ]

It's the spec requirement that injection happens only once for the entire life of a component,and it happens at the beginning of its lifecycle. If you want dynamic values, it will need to be implmented by your custom resource type, e.g., via lookup.

Comment by Cheng Fang [ 13/Jul/12 ]

Transfer to cdi for evaluation.

Comment by mkarg [ 16/Jul/12 ]

This might be true for completely selfdeveloped custom types, but it could be implemented into that types that GlassFish ships with already. That means, the fact that CDI forces one-time injection does not prevent the GlassFish-custom-types from working dynamically inside themselves.

Comment by jjsnyder83 [ 29/Oct/12 ]

Could you provide an example of what you want?

Comment by mkarg [ 08/Dec/12 ]

Here is an example scenario:

An EAR-packaged application might need to have a switch that enables or disabled one particular business process (like a boolean for "this feature is enabled"). For example, the process could be that data is to be synchronized between the application and an external data source or sink (like another external application). If the EAR-customer also runs that external application, he switches this sync feature on (if he likes). Otherwise, he switches this feature off (= the default).

Possibly, the EAR-packaged application is used 24x7, and he wants to switch on the sync feature, there is no time to shutdown the container to trigger a CDI-reinjection of the boolean. But to simplify coding, the EAR-vendor does not like to use JNDI (which would be "live"). So my proposal to get "live" values in CDI would be that GlassFish for this reason comes with an implementation of custom properties that are injectable, but that will update "live" under the hood.

Here is how GlassFish could do that:

A solution could be that the static instance (here: boolean value) that is getting CDI-injected is a dynamic wrapper around JNDI but not just a Java primitive. This means, PrimitivesAndStringFactory will in fact not provide a copy of primitive value (boolean), but a reference (hence, java.lang.Boolean), where the reference is always the same but simply either points to the customized value or uses DynamicProxy API, ASM API, or whatever tweak to get a dynamic resolution of the value (e. g. using JNDI internally). That reference is statically injected, but as it is not a copy but a "living" object, it will dynamically reflect any value changes "live".

Example:

@Inject Boolean myValue; // GlassFish injects an object that looks like a Boolean but actually will use JNDI to always return the latest "live" value when any of java.lang.Boolean's methods are invokes.

A different solution could be that CDI injects at the moment the EJB component is getting from the pool instead of when being constructed. That way, a GlassFish factory could simply lookup the value each time the factory is triggered, hence, every time the EJB is taken out of the pool.

Comment by jjsnyder83 [ 18/Jun/13 ]

I think what you're looking for is a portable extension that defines beans for properties. The bean implementations either use jndi, jmx, or something else to lookup the value of the property each time it's accessed. Please check DeltaSpike to see if someone has already written an extension to do this.

CDI requires a scope for objects that it manages so that it knows when to create a new instance under the covers (anything but @Dependent is proxied so that when the injected proxy is access CDI can get the correct instance based on the scope of the injected object.)





[GLASSFISH-21177] WELD Exception due to Created: 29/Aug/14  Updated: 24/Mar/15  Resolved: 24/Mar/15

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Thomas Andres Assignee: jjsnyder83
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I'm testing our application on glassfish 4.1 (build 13).

I see a new exception when processing things in the background (@Asynchronous observation of CDI event)

Caused by: org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.SessionScoped
        at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:687)
        at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:825)
        at org.jboss.weld.injection.ParameterInjectionPointImpl.getValueToInject(ParameterInjectionPointImpl.java:76)
        at org.jboss.weld.injection.MethodInjectionPoint.getParameterValues(MethodInjectionPoint.java:124)
        at org.jboss.weld.injection.MethodInjectionPoint.invokeWithSpecialValue(MethodInjectionPoint.java:69)
        at org.jboss.weld.injection.MethodInjectionPoint.invoke(MethodInjectionPoint.java:63)
        at org.jboss.weld.util.Beans.callInitializers(Beans.java:389)
        at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:377)
        at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:70)
        at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:172)
        at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:46)
        at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:65)
        at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:109)
        at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:150)
        at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69)
        at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:740)
        at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:831)
        at org.jboss.weld.injection.ParameterInjectionPointImpl.getValueToInject(ParameterInjectionPointImpl.java:76)
        at org.jboss.weld.injection.MethodInjectionPoint.getParameterValues(MethodInjectionPoint.java:124)
        at org.jboss.weld.injection.MethodInjectionPoint.invokeWithSpecialValue(MethodInjectionPoint.java:69)
        at org.jboss.weld.injection.MethodInjectionPoint.invoke(MethodInjectionPoint.java:63)
        at org.jboss.weld.util.Beans.callInitializers(Beans.java:389)
        at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:377)
        at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:70)
        at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:172)
        at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:46)
        at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:65)
        at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:109)
        at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:150)
        at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69)
        at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:740)
        at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:831)
        at org.jboss.weld.injection.ParameterInjectionPointImpl.getValueToInject(ParameterInjectionPointImpl.java:76)
        at org.jboss.weld.injection.MethodInjectionPoint.getParameterValues(MethodInjectionPoint.java:124)
        at org.jboss.weld.injection.MethodInjectionPoint.invokeWithSpecialValue(MethodInjectionPoint.java:69)
        at org.jboss.weld.injection.MethodInjectionPoint.invoke(MethodInjectionPoint.java:63)
        at org.jboss.weld.util.Beans.callInitializers(Beans.java:389)
        at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:377)
        at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:70)
        at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:172)
        at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:46)
        at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:65)
        at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:109)
        at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:150)
        at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
        at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98)
        at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78)

I don't know if this was silently ignored in glassfish 4.0 or if there was indeed a session context available in 4.0.

The component I try to inject provides some context information per request or session. In the asynchronous case, I would only access the request state anyway. I can problably work around the issue by looking up the session state only, when it's really required.

I can see that there is no more session context available. If the change is intended, it would be nice to know what exactly changed and why.
Otherwise it should probably be fixed to avoid the issue.



 Comments   
Comment by jjsnyder83 [ 29/Aug/14 ]

Please provide a simple reproducible test case.

Comment by Thomas Andres [ 29/Aug/14 ]

I'll try to build an example. Might take some time though...





[GLASSFISH-20422] multiple extensions in same bda Created: 26/Apr/13  Updated: 11/May/15  Resolved: 11/May/15

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: 4.1

Type: Bug Priority: Minor
Reporter: jjsnyder83 Assignee: phil.zamp