[GLASSFISH-20829] Beans deployed in ejb archives that implements extension are not visible to war in ear deployment Created: 28/Sep/13  Updated: 30/Sep/13  Resolved: 29/Sep/13

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

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


 Description   

If you include an extension in an ejb archive and deploy the resulting application as an ear contained beans are not made available to wars in same ear. Looking at the logs I see that the archive is processed two times

FINE|org.glassfish.weld.BeanDeploymentArchiveImpl|-JAR processing: file:/core.jee-0.0.1-SNAPSHOT_jar/ as a Bean archive jar since it has META-INF/beans.xml
FINE|org.glassfish.weld.BeanDeploymentArchiveImpl|-JAR processing: file:/core.jee-0.0.1-SNAPSHOT_jar/ as an extensions jar since it has META-INF/services extension

Looking at code (from org.glassfish.web:weld-integration:3.1.1) the second processing sets the bdaType to UNKNOWN

418 if (archive.exists(META_INF_BEANS_XML))

{ 419 logger.log(FINE, "-JAR processing: " + archive.getURI() 420 + " as a Bean archive jar since it has META-INF/beans.xml"); 421 bdaType = BDAType.JAR; 422 collectJarInfo(archive, true); 423 }

424
425 if (archive.exists(META_INF_SERVICES_EXTENSION))

{ 426 logger.log(FINE, "-JAR processing: " + archive.getURI() 427 + " as an extensions jar since it has META-INF/services extension"); 428 bdaType = BDAType.UNKNOWN; 429 collectJarInfo(archive, false); 430 }

and only JAR BDAs seem to be made available to wars (org.glassfish.weld.DeploymentImpl)

228 if (warBDAs != null) {
229 ListIterator<BeanDeploymentArchive> warIter = warBDAs.listIterator();
230 boolean modifiedArchive = false;
231 while (warIter.hasNext()) {
232 BeanDeploymentArchive warBDA = (BeanDeploymentArchive)warIter.next();
233 if (jarBDAs != null) {
234 ListIterator<BeanDeploymentArchive> jarIter = jarBDAs.listIterator();
235 while (jarIter.hasNext())

{ 236 BeanDeploymentArchive jarBDA = (BeanDeploymentArchive)jarIter.next(); 237 warBDA.getBeanDeploymentArchives().add(jarBDA); 238 modifiedArchive = true; 239 }

240 }

The result is a WELD-001408 for unsatisfied dependencies at deploy.



 Comments   
Comment by jjsnyder83 [ 29/Sep/13 ]

This was fixed several months ago with the work that was done for integrating with CDI 1.1.

Comment by dgaffuri [ 29/Sep/13 ]

Thanks for your answer. Do you have a link to the JIRA issue? What about a fix for version 3?

Comment by jjsnyder83 [ 30/Sep/13 ]

The change to BeanDeploymentArchiveImpl was done while fixing cdi 1.1 tck failures. Unfortunately there was not a Jira for it. The svn commit info for that change is:

59030 01.02.2013 21:05:12, by jjsnyder83

I'll look into your comment on DeploymentImpl next.

Comment by jjsnyder83 [ 30/Sep/13 ]

As for the changes to DeploymentImpl I cannot determine when they were made as svn compare is failing on me due to repository issues.

I do not know about fixes for version 3. Those would probably have to go through support. fyi...there were many many fixes and improvements in GlassFish with 4.0 especially in CDI. I encourage you to upgrade if that's possible.





[GLASSFISH-20516] Uptake Weld 2.0.0.SP1 Created: 13/May/13  Updated: 14/May/13  Resolved: 14/May/13

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

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: 4_0-approved

 Comments   
Comment by jjsnyder83 [ 13/May/13 ]

What is the impact on the customer of the bug?
CDI causing severe memory leak. See https://java.net/jira/browse/GLASSFISH-20474

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?
very

What is the cost/risk of fixing the bug?
low

How risky is the fix? How much work is the fix? Is the fix complicated?
low...SP1 only addresses this leak.

Is there an impact on documentation or message strings?
No

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
See https://java.net/jira/browse/GLASSFISH-20474

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

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 Tom Mueller [ 13/May/13 ]

Approved for 4.0.

Comment by jjsnyder83 [ 14/May/13 ]

Fixed by uptake of Weld 2.0.0.SP1
Committed on trunk: revision 61974.
Committed on 4.0: revision 61975.





[GLASSFISH-20474] PSR:PERF Major memory leak in EJB app when implicit CDI is enabled Created: 06/May/13  Updated: 14/May/13  Resolved: 14/May/13

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

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

Tags: 4_0-approved, PSRBUG, VIKKUMAR

 Description   

We have a micro benchmark that creates, invokes and deletes local session beans. In latest build 87 (as well as on latest nightly) we noticed old gen quickly gets filled up resulting into continuous Full GCs. This degrades throughput by almost 100%. Class histogram shows that object[] and jboss related objects are quite high in count,

num #instances #bytes class name
----------------------------------------------
1: 6948972 426066232 [Ljava.lang.Object;
2: 6890964 275638560 org.jboss.weld.context.CreationalContextImpl
3: 6890799 220505568 org.jboss.weld.context.SerializableContextualFactory$PassivationCapableSerializableContextual
4: 6943875 166653000 java.util.ArrayList
5: 6891146 165387504 java.util.Collections$SynchronizedRandomAccessList
6: 6890799 165379176 org.jboss.weld.context.SerializableContextualInstanceImpl
7: 112215 16187000 <constMethodKlass>
8: 112215 15273944 <methodKlass>
9: 164287 14696232 [C
10: 13927 13510664 [I
11: 11519 12491400 <constantPoolKlass>
12: 11519 8483480 <instanceKlassKlass>
13: 9661 6845568 <constantPoolCacheKlass>
14: 54051 4324080 java.lang.reflect.Method



 Comments   
Comment by marina vatkina [ 06/May/13 ]

This might be a CDI issue. Can you try disabling CDI scanning to see if it makes any difference?

Comment by Scott Oaks [ 06/May/13 ]

Setting cdi-server.emable-implicit-cdi=false eliminates the memory leak.

The leak is ultimately held by the eventListeners of the WebModule – the WelListener holds an httpConvesationContext, which holds a creationalContext, which holds a CreatinalContextImpl, which holds a huge ArrayList of the SerializeableContextualInstanceImpl objects.

Comment by jjsnyder83 [ 06/May/13 ]

Can you send me the app please? j.j.snyder@oracle.com

Comment by jjsnyder83 [ 07/May/13 ]

This looks like a memory leak in Weld. I have sent the application along with relevant information to JBoss asking for their opinion.

Comment by jjsnyder83 [ 09/May/13 ]

The same leak appears to happen in JBoss application server too.
See https://issues.jboss.org/browse/WELD-1425

Comment by jjsnyder83 [ 13/May/13 ]

What is the impact on the customer of the bug?
CDI causing severe memory leak.

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?
very

What is the cost/risk of fixing the bug?
low

How risky is the fix? How much work is the fix? Is the fix complicated?
low...SP1 only addresses this leak.

Is there an impact on documentation or message strings?
No

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
The application in this jira.

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

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 Tom Mueller [ 13/May/13 ]

Approved for 4.0.

Comment by jjsnyder83 [ 14/May/13 ]

Fixed by uptake of Weld 2.0.0.SP1
Committed on trunk: revision 61974.
Committed on 4.0: revision 61975.





[GLASSFISH-20421] Uptake Weld 2.0.0.Final Created: 26/Apr/13  Updated: 26/Apr/13  Resolved: 26/Apr/13

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

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: 4_0-approved

 Description   

What is the impact on the customer of the bug?
2.0.0.Final version of Weld.

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?
N/A

What is the cost/risk of fixing the bug?
N/A

How risky is the fix? How much work is the fix? Is the fix complicated?
N/A

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 TCK

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

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-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-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-20176] [SDK]Java EE 7 sample-cdi-transaction-scoped Created: 04/Apr/13  Updated: 22/Apr/13  Resolved: 22/Apr/13

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

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


 Description   

/transaction-scoped
Operations:
1 "mvn clean verify cargo:run"

Errors:
1 404 NOT FOUND
http://localhost:8080/transaction-scoped-4.0-SNAPSHOT/

Remark:
1 incorrect app name(transaction-scoped-4.0-SNAPSHOT)



 Comments   
Comment by arjavdesai [ 04/Apr/13 ]

As mentioned in the read-me, the URL to invoke is http://host:port/context-root/TransactionScopedServlet

Comment by arjavdesai [ 22/Apr/13 ]

I have added index.html as well now with revision 1131





[GLASSFISH-20175] [SDK]Java EE 7 sample-cdi Created: 04/Apr/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

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

Type: Bug Priority: Major
Reporter: Daniel Assignee: arjavdesai
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java ee 7 build 82
Maven 3.0.3
Latest build of samples



 Description   

App name should not include SNAPSHOT right?

cdi
/cdi-guess
Operations:
Errors:
Remark:
1 incorrect app name(cdi-guess-4.0-SNAPSHOT)

/cdi-servlet
Operations:
Errors:
Remark:
1 incorrect app name(cdi-servlet-4.0-SNAPSHOT)

/events
Operations:
Errors:
Remark:
1 incorrect app name(events-4.0-SNAPSHOT)

/interceptors
Operations:
Errors:
Remark:
1 incorrect app name(interceptors-4.0-SNAPSHOT)

/transactional
Operations:
Errors:
Remark:
1 incorrect app name(transactional-4.0-SNAPSHOT)



 Comments   
Comment by arjavdesai [ 04/Apr/13 ]

4.0-SNAPSHOT is version for sample as defined in pom.xml for the project. I think it will be updated to 4.0 once its released.





[GLASSFISH-20047] cdi tck test org.jboss.cdi.tck.tests.lookup.manager.provider.init.CDIProviderInitTest is failing Created: 26/Mar/13  Updated: 11/Apr/13  Resolved: 11/Apr/13

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

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   

testAccessingBeanManager(org.jboss.cdi.tck.tests.lookup.manager.provider.init.CDIProviderInitTest): org.jboss.weld.exceptions.IllegalStateException: WELD-001328 Unable to identify the correct BeanManager. The calling class org.jboss.cdi.tck.tests.lookup.manager.provider.init.MarkerObtainerNonBda is not placed in bean archive



 Comments   
Comment by jjsnyder83 [ 11/Apr/13 ]

Committed revision 61375.





[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-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... Resolved

 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-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-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-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-19532] App Deployment failure is causing weld boostrap to be shutdown twice. Created: 14/Jan/13  Updated: 27/Mar/13  Resolved: 27/Mar/13

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

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


 Description   

An Application fails deployment due to weld validation failure. In WeldDeployer.event the code that handles org.glassfish.internal.deployment.Deployment.APPLICATION_STARTED calls bootstrap.shutdown. Then the application is undeployed which causes the event org.glassfish.internal.deployment.Deployment.APPLICATION_DISABLED to be fired. In WeldDeployer.event the code that handles this event calls bootstrap.shutdown again causing a java.lang.IllegalStateException to be thrown (and ignored). Something needs to be set in TransientAppMetaData indicating that the weld bootstrap has already been shutdown.



 Comments   
Comment by jjsnyder83 [ 14/Jan/13 ]

This happens when there is an ejb jar in the ear.

Comment by arjavdesai [ 27/Mar/13 ]

revision 60957 should fix the issue.





[GLASSFISH-19493] CDI dependency injection fails for JAXWS handler classes Created: 04/Jan/13  Updated: 17/Dec/13  Resolved: 26/Mar/13

Status: Resolved
Project: glassfish
Component/s: cdi, web_services
Affects Version/s: 3.1.2.2
Fix Version/s: 4.0

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

Ubuntu 12.04.1 64bit
Oracle JDK 1.7.0.10


Tags: cdi, jaxws

 Description   

The Java EE 6 specification lists JAXWS handlers as component classes that are supporting injection (see page 69, table EE.5-1).

It seams, that within Glassfish 3.1.2.2 (build 5) @Inject is not resolved for handler classes. Is this a known bug?

I have found a forum posting (http://forums.java.net/node/873115) that has not been answered yet.

The attached sample demonstrates this issue.

  • ServerSideTicketHandler is a JAXWS handler that has dependency to TicketFactory (should be resolved via @Inject). Since DI does not work "ticketFactory is null" is logged to System.out.
  • ProductServiceEndpoint is the service implementation that itself delegates the method call to ProductRepository (here @Inject works as expected).


 Comments   
Comment by arjavdesai [ 05/Mar/13 ]

tomkri,

I don't see the attachment. Can you please upload the same?

thanks!

Comment by arjavdesai [ 26/Mar/13 ]

Revision 60836 should fix the issue.

Comment by DimitriJakov [ 17/Dec/13 ]

Unfortunately, injection still does not work for handlers attached to web service clients via @HandlerChain annotation and XML file (at least). The mechanism for their instantiation is different from that of endpoints. See com/sun/xml/ws/handler/HandlerChainsModel.java:272:

handler = (Handler) loadClass(classLoader,
    XMLStreamReaderUtil.getElementText(reader).trim()).newInstance();

Seems like handlers are simply instantiated, with no signs of injections being processed.

If needed, I can supply a MWE and a stack trace to demonstrate the issue. (GlassFish v4.0 build 89, Oracle JDK 1.7.0_45)





[GLASSFISH-19418] Memory leak with Simple Tag Handler and CDI enabled Created: 07/Dec/12  Updated: 10/Dec/12  Resolved: 10/Dec/12

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

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

Windows7 64bit with jdk7_u3, linux with jdk6, Glassifish Open Source 3.1.2



 Description   

When CDI is enabled on a web application which uses JSP tag files instances of tag files remain inside com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl in jcdiManagedBeanInstanceMap.

Instances of tag files contains references to JspContext which contains a reference to JspWriterImpl, which contains a buffer which holds response data

This is a memory leak which leads to OutOfMemoryErrors very quickly



 Comments   
Comment by pukkaone [ 07/Dec/12 ]

Sorry, this issue was cloned by mistake. Please close it.

Comment by Sivakumar Thyagarajan [ 10/Dec/12 ]

Transferring to JJ Snyder

Comment by Sivakumar Thyagarajan [ 10/Dec/12 ]

Closing this as a duplicate of GLASSFISH-18650 as requested by the bug submitter.





[GLASSFISH-19262] Deployment failure: Duplicate interceptor class definition when binding <interceptor-class-name> on AROUND_INVOKE Created: 30/Oct/12  Updated: 13/Apr/13  Resolved: 13/Apr/13

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

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

GlassFish Server Open Source Edition 3.1.2.2 (build 5)
org.jboss.weld.Version=WELD-000900 1.1.8 (Final)


Attachments: Zip Archive cdi-interceptor.zip    

 Description   

Following bean forces a deployment error in glassfish, if the ejb module containing this bean uses cdi (and therefore has a META-INF/beans.xml)

@Stateless
@Interceptors(

{Interceptor1.class, Interceptor2.class}

)
public class MyStatelessSessionBean {

public void doSomething1() {
}

public void doSomething2() {
}

@ExcludeClassInterceptors
@Interceptors(

{Interceptor1.class}

)
public void doSomething3() {

}
}

The server.log shows following errors:

[#|2012-10-30T16:43:31.128+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=121;_ThreadName=Thread-2;|Exception while loading the app|#]

[#|2012-10-30T16:43:31.133+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=121;_ThreadName=Thread-2;|Exception while loading the app : Duplicate interceptor class definition when binding com.tests.interceptors.Interceptor1 on AROUND_INVOKE
org.jboss.weld.interceptor.proxy.InterceptorException: Duplicate interceptor class definition when binding com.tests.interceptors.Interceptor1 on AROUND_INVOKE

If the the ejb-module has no beans.xml, the deployment is successful.

The attachment contains a maven project for reproducing the error.



 Comments   
Comment by tlcksnyder [ 29/Mar/13 ]

Still fails with Weld Beta7:

Exception while loading the app : CDI deployment failure:Duplicate interceptor class definition when binding com.tests.interceptors.Interceptor1 on AROUND_INVOKE
org.jboss.weld.interceptor.proxy.InterceptorException: Duplicate interceptor class definition when binding com.tests.interceptors.Interceptor1 on AROUND_INVOKE
at org.jboss.weld.interceptor.builder.InterceptionModelImpl.validateDuplicateInterceptors(InterceptionModelImpl.java:136)
at org.jboss.weld.interceptor.builder.InterceptionModelImpl.appendInterceptors(InterceptionModelImpl.java:120)
at org.jboss.weld.interceptor.builder.InterceptionModelBuilder$MethodInterceptorDescriptor.with(InterceptionModelBuilder.java:114)
at org.jboss.weld.injection.producer.InterceptionModelInitializer.initMethodDeclaredEjbInterceptors(InterceptionModelInitializer.java:285)
at org.jboss.weld.injection.producer.InterceptionModelInitializer.initEjbInterceptors(InterceptionModelInitializer.java:233)
at org.jboss.weld.injection.producer.InterceptionModelInitializer.init(InterceptionModelInitializer.java:113)
at org.jboss.weld.injection.producer.BeanInjectionTarget.initializeInterceptionModel(BeanInjectionTarget.java:91)
at org.jboss.weld.injection.producer.ejb.SessionBeanInjectionTarget.initializeAfterBeanDiscovery(SessionBeanInjectionTarget.java:81)
at org.jboss.weld.injection.producer.InjectionTargetInitializationContext.initialize(InjectionTargetInitializationContext.java:42)
at org.jboss.weld.injection.producer.InjectionTargetService.initialize(InjectionTargetService.java:57)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:529)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:204)
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)

Comment by jjsnyder83 [ 08/Apr/13 ]

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

Comment by Jeremy_Lv [ 09/Apr/13 ]

I have looked into the code and found the current weld side code has don't allow define both of the @Interceptors(

{Interceptor1.class}) define in class and the method contained in the class.
MyStatelessSessionBean.java
@Stateless
@Interceptors({Interceptor1.class, Interceptor2.class})
public class StatelessSessionBean {

  public void doSomething1() {
  }
  
  public void doSomething2() {
  }
  
  public void doSomething3() {
  }
  
  @ExcludeClassInterceptors
  @Interceptors(Interceptor1.class)
  public void doSomethingN() {
    
  }
}
Interceptor1.java
public class Interceptor1 {
  @AroundInvoke
  public Object intercept(InvocationContext ctx) throws Exception {
    return ctx.proceed();
  }  
}


From the code in the glassfish weld side, If we have already define the MyStatelessSessionBean as @Interceptors({Interceptor1.class}

), the duplicate error exception will comes out if we define the @Interceptors(

{Interceptor1.class}

) at the method contained in MyStatelessSessionBean.

I'd like to continue to look into this issue if it is the right scenario that tweier has reported.

BTW: the reason why the application can be deployed without a bean.xml because the application will not a weld application without a bean.xml and the weld side will not load the application to do some validation.

Thanks

Jeremy

Comment by marina vatkina [ 09/Apr/13 ]

Note @ExcludeClassInterceptors - it should remove the class-level binding

Comment by Jeremy_Lv [ 10/Apr/13 ]

It seems the issue has been resovled in the version of 2.0.0.CR2.
https://issues.jboss.org/browse/WELD-1400

I think the issue will be resoved when the weld side in glassfish get upgrade to the <weld.version>2.0.0.CR2</weld.version>

Comment by arjavdesai [ 13/Apr/13 ]

I just tried with latest GFS build with revisions upto 61409 which includes WELD CR2 and app is getting deployed fine as seen in server logs

[2013-04-13T07:37:05.144-0400] [glassfish 4.0] [INFO] [] [org.jboss.weld.Version] [tid: _ThreadID=33 _ThreadName=admin-listener(2)] [timeMillis: 1365853025144] [levelValue: 800] [[
WELD-000900 2.0.0 (CR2)]]

[2013-04-13T07:37:06.412-0400] [glassfish 4.0] [WARNING] [] [org.jboss.weld.interceptor.util.InterceptionTypeRegistry] [tid: _ThreadID=33 _ThreadName=admin-listener(2)] [timeMillis: 1365853026412] [levelValue: 900] [[
Class 'javax.ejb.PostActivate' not found, interception based on it is not enabled]]

[2013-04-13T07:37:06.413-0400] [glassfish 4.0] [WARNING] [] [org.jboss.weld.interceptor.util.InterceptionTypeRegistry] [tid: _ThreadID=33 _ThreadName=admin-listener(2)] [timeMillis: 1365853026413] [levelValue: 900] [[
Class 'javax.ejb.PrePassivate' not found, interception based on it is not enabled]]

[2013-04-13T07:37:07.070-0400] [glassfish 4.0] [WARNING] [] [org.jboss.weld.Bootstrap] [tid: _ThreadID=33 _ThreadName=admin-listener(2)] [timeMillis: 1365853027070] [levelValue: 900] [[
WELD-001473 javax.enterprise.inject.spi.Bean implementation org.hibernate.validator.internal.cdi.ValidatorFactoryBean@6f4a53a4 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-04-13T07:37:07.070-0400] [glassfish 4.0] [WARNING] [] [org.jboss.weld.Bootstrap] [tid: _ThreadID=33 _ThreadName=admin-listener(2)] [timeMillis: 1365853027070] [levelValue: 900] [[
WELD-001473 javax.enterprise.inject.spi.Bean implementation org.hibernate.validator.internal.cdi.ValidatorBean@42a59140 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-04-13T07:37:07.077-0400] [glassfish 4.0] [WARNING] [] [org.jboss.weld.Bootstrap] [tid: _ThreadID=33 _ThreadName=admin-listener(2)] [timeMillis: 1365853027077] [levelValue: 900] [[
WELD-001473 javax.enterprise.inject.spi.Bean implementation org.glassfish.jms.injection.JMSCDIExtension$LocalBean@40e9618a 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-04-13T07:37:07.154-0400] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=33 _ThreadName=admin-listener(2)] [timeMillis: 1365853027154] [levelValue: 800] [[
cdi-interceptor-ejb-1.0-SNAPSHOT was successfully deployed in 2,543 milliseconds.]]





[GLASSFISH-19251] SessionScoped managed bean can't be injected in to stateless session bean in EAR application with WAR (WELD-001303) Created: 26/Oct/12  Updated: 27/Nov/13  Resolved: 26/Apr/13

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

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

JDK 1.6.0_16, Windows Vista SP2 (32-bit)


Attachments: Zip Archive testcase.zip    
Tags: 4_0-approved, cdi, weld

 Description   

I have created an EAR application with following structure:

testcase-ear-1.0-SNAPSHOT.ear
  - lib/testcase-api-1.0-SNAPSHOT.jar
      - testcase/LoginEJBLocal.class    (Local business interface)
  - META-INF/application.xml
  - testcase-ejb-1.0-SNAPSHOT.jar
      - META-INF/beans.xml
      - testcase/LoginBean.class        (Managed bean with SessionScoped)
      - testcase/LoginEJBBean.class     (Stateless session bean)
  - testcase-web-1.0-SNAPSHOT.war
      - WEB-INF/classes
          - testcase/SessionServlet.class      (WebServlet)
      - WEB-INF/lib/testcase-api-1.0-SNAPSHOT.jar
          - testcase/LoginEJBLocal.class       (Local business interface)

Web servlet (SessionServlet) injects stateless session bean (LoginEJBBean) using local interface (LoginEJBLocal) and the bean should inject managed bean (LoginBean). But managed bean can't be injected because any active contexts for scope type SessionScoped can't be found. Following exception is thrown on http request:

WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=23;_ThreadName=Thread-2;|javax.ejb.EJBException
	at com.sun.ejb.containers.BaseContainer.processSystemException(BaseContainer.java:5215)
	at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:5113)
	at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4901)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2045)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1994)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:222)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:89)
	at $Proxy535.getCurrentUser(Unknown Source)
	at testcase.SessionServlet.doGet(SessionServlet.java:22)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
	at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
	at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
	at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
	at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
	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:619)
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:619)
	at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:71)
	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79)
	at testcase.LoginBean$Proxy$_$$_WeldClientProxy.getCurrentUser(LoginBean$Proxy$_$$_WeldClientProxy.java)
	at testcase.LoginEJBBean.getCurrentUser(LoginEJBBean.java:24)
	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.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
	at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
	at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5388)
	at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
	at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
	at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:49)
	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.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
	at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
	at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
	at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
	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.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
	at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370)
	at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5360)
	at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5348)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:214)
	... 29 more

In attachment your can find source code and EJB application.
Here are my classes:

LoginEJBLocal.java
@Local
public interface LoginEJBLocal {
    void login(String user);
    void logout();
    String getCurrentUser();
}
LoginEJBBean.java
@Stateless
public class LoginEJBBean implements LoginEJBLocal {
    @Inject
    private LoginBean loginBean;
    @Override
    public void login(String user) {
        loginBean.login(user);
    }
    @Override
    public void logout() {
        loginBean.logout();
    }
    @Override
    public String getCurrentUser() {
        return loginBean.getCurrentUser();
    }
}
LoginBean.java
@SessionScoped
public class LoginBean implements Serializable {
    private String user;
    public void login(String user) {
        this.user = user;
    }
    public void logout() {
        this.user = null;
    }
    public String getCurrentUser() {
        return user;
    }
}
SessionServlet.java
@WebServlet("/sesser")
public class SessionServlet extends HttpServlet {
    @EJB
    private LoginEJBLocal loginBean;
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        System.out.println("GET request");
        String user = loginBean.getCurrentUser();
        if (user != null) {
            System.out.println("Hello, " + user + "!");
        } else {
            System.out.println("Hello! Who are you?");
            loginBean.login("user-" + new Date());
        }
    }
}


 Comments   
Comment by shreedhar_ganapathy [ 19/Apr/13 ]

Any further root cause analysis on this issue?
Could you please provide the ETA for the fix?
GF 4.0 RC testing is starting and we need fixes to go in ASAP.

Comment by jjsnyder83 [ 26/Apr/13 ]

What is the impact on the customer of the bug?
CDI doesn't work for some ejb apps

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?
very

What is the cost/risk of fixing the bug?
N/A

How risky is the fix? How much work is the fix? Is the fix complicated?
N/A

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 TCK

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

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 jjsnyder83 [ 26/Apr/13 ]

Committed revision 61689.

Comment by ymajoros [ 27/Nov/13 ]

So, for anyone looking for a workaround for it for glassfish 3, the solution is as easy as activating weld in the war that calls the ejb that calls the SessionScoped bean. Just add a beans.xml and it works.

Simply found out from the patch: https://java.net/projects/glassfish/sources/svn/revision/61689





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-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-19083] org.jboss.weld.context.ContextNotActiveException is thrown when undeploying application. Created: 17/Sep/12  Updated: 03/Apr/13  Resolved: 03/Apr/13

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

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

Attachments: Zip Archive EnterpriseApplication1.zip    

 Description   

There are 2 beans A and B. A is dependent scoped and B is request scoped. B is injected into A. A is injected into an EJB.

To reproduce, please refer to the attached netbean project.

1. Build and deploy the ear.
2. Access the NewServlet via browser for initializing an EJB instance.
3. Undeploy the application to trigger bean A's preDestroy method. Then we can see the following exception.

[#|2012-09-17T15:03:12.609+0800|INFO|44.0|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=13;_ThreadName=admin-listener(2);|EnterpriseApplication1 was successfully deployed in 785 milliseconds.|#]

[#|2012-09-17T15:03:16.706+0800|INFO|44.0|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=24;_ThreadName=http-listener-1(2);|B.xyz() is called.|#]

[#|2012-09-17T15:03:36.931+0800|INFO|44.0|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=13;_ThreadName=admin-listener(2);|A is closing...|#]

[#|2012-09-17T15:03:36.933+0800|SEVERE|44.0|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=13;_ThreadName=admin-listener(2);|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:598)
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:71)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79)
at test.B$Proxy$$$_WeldClientProxy.close(B$Proxy$$$_WeldClientProxy.java)
at test.A.cleanup(A.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.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:264)
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:260)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invoke(WeldMethodImpl.java:174)
at org.jboss.weld.bean.AbstractClassBean.defaultPreDestroy(AbstractClassBean.java:493)
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.preDestroy(ManagedBean.java:182)
at org.jboss.weld.bean.ManagedBean.destroy(ManagedBean.java:302)
at org.jboss.weld.context.ForwardingContextual.destroy(ForwardingContextual.java:31)
at org.jboss.weld.context.CreationalContextImpl.destroy(CreationalContextImpl.java:100)
at org.jboss.weld.context.CreationalContextImpl.release(CreationalContextImpl.java:92)
at org.jboss.weld.context.CreationalContextImpl.release(CreationalContextImpl.java:83)
at org.glassfish.weld.services.JCDIServiceImpl$JCDIInjectionContextImpl.cleanup(JCDIServiceImpl.java:318)
at com.sun.ejb.containers.BaseContainer.cleanupInstance(BaseContainer.java:1704)
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.destroy(StatelessSessionContainer.java:779)
at com.sun.ejb.containers.util.pool.NonBlockingPool.close(NonBlockingPool.java:417)
at com.sun.ejb.containers.StatelessSessionContainer.doConcreteContainerShutdown(StatelessSessionContainer.java:709)
at com.sun.ejb.containers.BaseContainer.undeploy(BaseContainer.java:4163)
at org.glassfish.ejb.startup.EjbApplication.stop(EjbApplication.java:297)
at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:161)
at org.glassfish.internal.data.ModuleInfo.stop(ModuleInfo.java:311)
at org.glassfish.internal.data.ApplicationInfo.stop(ApplicationInfo.java:327)
at com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:1051)
at com.sun.enterprise.v3.server.ApplicationLifecycle.undeploy(ApplicationLifecycle.java:1091)
at org.glassfish.deployment.admin.UndeployCommand.execute(UndeployCommand.java:399)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:529)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:550)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1430)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1600(CommandRunnerImpl.java:114)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1734)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1683)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:467)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:255)
at sun.reflect.GeneratedMethodAccessor117.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.jersey.server.model.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:80)
at org.glassfish.jersey.server.model.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:113)
at org.glassfish.jersey.server.model.AbstractJavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(AbstractJavaResourceMethodDispatcherProvider.java:176)
at org.glassfish.jersey.server.model.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:79)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:268)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:84)
at org.glassfish.jersey.process.internal.RequestInvoker$AcceptingInvoker.apply(RequestInvoker.java:241)
at org.glassfish.jersey.process.internal.AsyncInflectorAdapter.apply(AsyncInflectorAdapter.java:157)
at org.glassfish.jersey.process.internal.RequestInvoker$2.run(RequestInvoker.java:188)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:309)
at org.glassfish.jersey.process.internal.RequestInvoker$3.run(RequestInvoker.java:201)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:262)
at com.google.common.util.concurrent.AbstractListeningExecutorService.submit(AbstractListeningExecutorService.java:43)
at com.google.common.util.concurrent.AbstractListeningExecutorService.submit(AbstractListeningExecutorService.java:40)
at org.glassfish.jersey.process.internal.RequestInvoker.apply(RequestInvoker.java:197)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:758)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:298)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:205)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:113)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:164)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:175)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:265)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
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:825)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
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:578)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:558)
at java.lang.Thread.run(Thread.java:662)

#]


 Comments   
Comment by arjavdesai [ 26/Mar/13 ]

It seem to have been fixed as destroy of context is not getting invoked twice but I am not able to pin-point exact revision which fixed it. I was able to but now can't re-produce the issue with Glassfish build with revision's upto 60839. Please re-try, if you would.

Comment by David Zhao [ 27/Mar/13 ]

I can still reproduce it with revision 60914 by the attached application.

Comment by arjavdesai [ 27/Mar/13 ]

David,

I downloaded GFS 4.0 promoted build 82 from http://dlc.sun.com.edgesuite.net/glassfish/4.0/nightly/glassfish-4.0-b82-03_26_2013.zip and deployed ear (already built in your zip file upload) without any error i.e.

[2013-03-27T11:02:49.549-0400] [glassfish 4.0] [INFO] [] [org.glassfish.admingui] [tid: _ThreadID=45 _ThreadName=admin-listener(4)] [timeMillis: 1364396569549] [levelValue: 800] [[
Admin Console: Initializing Session Attributes...]]

[2013-03-27T11:03:28.958-0400] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=44 _ThreadName=admin-listener(3)] [timeMillis: 1364396608958] [levelValue: 800] [[
Snifer org.glassfish.javaee.full.deployment.EarSniffer@188b9 set up following modules: []]]

[2013-03-27T11:03:29.100-0400] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=44 _ThreadName=admin-listener(3)] [timeMillis: 1364396609100] [levelValue: 800] [[
Snifer org.glassfish.ejb.deployment.archive.EjbSniffer@189c0 set up following modules: []]]

[2013-03-27T11:03:29.112-0400] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=44 _ThreadName=admin-listener(3)] [timeMillis: 1364396609112] [levelValue: 800] [[
Snifer org.glassfish.weld.connector.WeldSniffer@37a229 set up following modules: []]]

[2013-03-27T11:03:29.195-0400] [glassfish 4.0] [INFO] [ejb.portable_jndi_names] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=44 _ThreadName=admin-listener(3)] [timeMillis: 1364396609195] [levelValue: 800] [[
EJB5181:Portable JNDI names for EJB NewSessionBean: [java:global/EnterpriseApplication1/EnterpriseApplication1-ejb/NewSessionBean, java:global/EnterpriseApplication1/EnterpriseApplication1-ejb/NewSessionBean!test.NewSessionBean]]]

[2013-03-27T11:03:29.269-0400] [glassfish 4.0] [INFO] [] [org.jboss.weld.Version] [tid: _ThreadID=44 _ThreadName=admin-listener(3)] [timeMillis: 1364396609269] [levelValue: 800] [[
WELD-000900 2.0.0 (Beta6)]]

[2013-03-27T11:03:29.975-0400] [glassfish 4.0] [WARNING] [] [org.jboss.weld.interceptor.util.InterceptionTypeRegistry] [tid: _ThreadID=44 _ThreadName=admin-listener(3)] [timeMillis: 1364396609975] [levelValue: 900] [[
Class 'javax.ejb.PostActivate' not found, interception based on it is not enabled]]

[2013-03-27T11:03:29.976-0400] [glassfish 4.0] [WARNING] [] [org.jboss.weld.interceptor.util.InterceptionTypeRegistry] [tid: _ThreadID=44 _ThreadName=admin-listener(3)] [timeMillis: 1364396609976] [levelValue: 900] [[
Class 'javax.ejb.PrePassivate' not found, interception based on it is not enabled]]

[2013-03-27T11:03:30.273-0400] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=44 _ThreadName=admin-listener(3)] [timeMillis: 1364396610273] [levelValue: 800] [[
Loading application EnterpriseApplication1#EnterpriseApplication1-war.war at [EnterpriseApplication1-war]]]

[2013-03-27T11:03:30.346-0400] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=44 _ThreadName=admin-listener(3)] [timeMillis: 1364396610346] [levelValue: 800] [[
EnterpriseApplication1 was successfully deployed in 1,478 milliseconds.]]

Comment by David Zhao [ 28/Mar/13 ]

arjavdesai:

As what I wrote in the description, the exception doesn't occur at deployment, but happens at undeployment. Please follow the steps to reproduce.

Comment by arjavdesai [ 28/Mar/13 ]

David:

Undeploy also works fine:

[2013-03-28T09:12:29.374-0400] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=46 _ThreadName=admin-listener(4)] [timeMillis: 1364476349374] [levelValue: 800] [[
EnterpriseApplication1 was successfully deployed in 1,709 milliseconds.]]

[2013-03-28T09:12:36.196-0400] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=136 _ThreadName=Thread-3] [timeMillis: 1364476356196] [levelValue: 800] [[

    • BatchRuntimeHelper:: App Undeployed: EnterpriseApplication1]]

Did you try it out with the glassfish from the URL link?

Comment by David Zhao [ 29/Mar/13 ]

arjavdesai,

Still this can be reproduced with nightly build glassfish-4.0-b83-03_28_2013.zip.

Can you elaborate the steps you used for reproduction? Did you follow my step <2> "Access the NewServlet via browser for initializing an EJB instance" which was mentioned in the description previously before undeployment? That is essential to reproduce the problem. To be more specific, you need access the servlet by http://localhost:8080/EnterpriseApplication1-war/NewServlet to initialize an ejb instance which has bean injected, and then undeploy the ear.

Comment by arjavdesai [ 03/Apr/13 ]

As per spec and as mentioned in javadoc, http://docs.oracle.com/javaee/6/api/javax/enterprise/context/RequestScoped.html, the request context is not active during the life cycle method's of a bean i.e. PreDestroy in this case. If you need to have a business need for this, the suggested approach is to have PreDestroy method in RequestScoped bean itself rather than calling it from PreDestroy (life cycle) method if another bean.





[GLASSFISH-19082] Failed to inject JMSContext into servlet filter or servlet context listener. Created: 17/Sep/12  Updated: 13/Apr/13  Resolved: 13/Apr/13

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

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

Attachments: Zip Archive WebApplication1.zip     Zip Archive WebApplication2.zip    

 Description   

When deploying applications which have JMSContext injected into servlet filter or servlet context listener, there is WELD-001308 error in server.log and then deployment fails.

===========================
exception of servlet filter - WebApplication1
===========================
[#|2012-09-17T13:32:23.575+0800|SEVERE|44.0|javax.enterprise.web|_ThreadID=13;_ThreadName=admin-listener(2);|WebModule[/WebApplication1]PWC1270: Exception starting filter Injection Filter
java.lang.InstantiationException
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:124)
at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4871)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5505)
at com.sun.enterprise.web.WebModule.start(WebModule.java:512)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:932)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:916)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:687)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2289)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1935)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:109)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:278)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:299)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:228)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:482)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:529)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:550)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1430)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1600(CommandRunnerImpl.java:114)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1734)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1683)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:592)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:238)
at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:113)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:164)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:175)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:265)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
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:825)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
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:578)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:558)
at java.lang.Thread.run(Thread.java:662)
Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class: class test.MyFilter
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:329)
at com.sun.enterprise.web.WebContainer.createFilterInstance(WebContainer.java:1025)
at com.sun.enterprise.web.WebModule.createFilterInstance(WebModule.java:1984)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:253)
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:120)
... 42 more
Caused by: org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308 Unable to resolve any beans for Types: [interface javax.enterprise.inject.spi.InjectionPoint]; Bindings: [@javax.enterprise.inject.Default()]
at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:707)
at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:696)
at org.jboss.weld.injection.ParameterInjectionPoint.getValueToInject(ParameterInjectionPoint.java:115)
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.ManagedBean.createInstance(ManagedBean.java:333)
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.produce(ManagedBean.java:200)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:289)
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:61)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:616)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:681)
at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:118)
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:703)
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:712)
at org.jboss.weld.manager.SimpleInjectionTarget$1.proceed(SimpleInjectionTarget.java:106)
at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:134)
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:46)
at org.jboss.weld.manager.SimpleInjectionTarget.inject(SimpleInjectionTarget.java:102)
at org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.java:282)
at org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.java:231)
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:462)
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:416)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:313)
... 46 more

#]

==========================
exception of servlet context listener - WebApplication2
==========================
[#|2012-09-17T14:01:01.362+0800|SEVERE|44.0|org.apache.catalina.core.ContainerBase|_ThreadID=12;_ThreadName=admin-listener(1);|ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class: class test.MyServletContextListener
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5460)
at com.sun.enterprise.web.WebModule.start(WebModule.java:512)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:932)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:916)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:687)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2289)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1935)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:109)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:278)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:299)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:228)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:482)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:529)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:550)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1430)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1600(CommandRunnerImpl.java:114)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1734)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1683)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:592)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:238)
at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:113)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:164)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:175)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:265)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
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:825)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
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:578)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:558)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class: class test.MyServletContextListener
at org.apache.catalina.core.StandardContext.addListener(StandardContext.java:2864)
at org.apache.catalina.core.StandardContext.addApplicationListener(StandardContext.java:2062)
at com.sun.enterprise.web.TomcatDeploymentConfig.configureApplicationListener(TomcatDeploymentConfig.java:236)
at com.sun.enterprise.web.TomcatDeploymentConfig.configureWebModule(TomcatDeploymentConfig.java:95)
at com.sun.enterprise.web.WebModuleContextConfig.start(WebModuleContextConfig.java:251)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:349)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:163)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5457)
... 40 more
Caused by: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class: class test.MyServletContextListener
at org.apache.catalina.core.StandardContext.createListener(StandardContext.java:2984)
at org.apache.catalina.core.StandardContext.loadListener(StandardContext.java:4992)
at com.sun.enterprise.web.WebModule.loadListener(WebModule.java:1615)
at org.apache.catalina.core.StandardContext.addListener(StandardContext.java:2862)
... 47 more
Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class: class test.MyServletContextListener
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:329)
at com.sun.enterprise.web.WebContainer.createListenerInstance(WebContainer.java:1041)
at com.sun.enterprise.web.WebModule.createListenerInstance(WebModule.java:1999)
at org.apache.catalina.core.StandardContext.createListener(StandardContext.java:2982)
... 50 more
Caused by: org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308 Unable to resolve any beans for Types: [interface javax.enterprise.inject.spi.InjectionPoint]; Bindings: [@javax.enterprise.inject.Default()]
at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:707)
at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:696)
at org.jboss.weld.injection.ParameterInjectionPoint.getValueToInject(ParameterInjectionPoint.java:115)
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.ManagedBean.createInstance(ManagedBean.java:333)
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.produce(ManagedBean.java:200)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:289)
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:61)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:616)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:681)
at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:118)
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:703)
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:712)
at org.jboss.weld.manager.SimpleInjectionTarget$1.proceed(SimpleInjectionTarget.java:106)
at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:134)
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:46)
at org.jboss.weld.manager.SimpleInjectionTarget.inject(SimpleInjectionTarget.java:102)
at org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.java:282)
at org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.java:231)
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:462)
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:416)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:313)
... 53 more

#]

[#|2012-09-17T14:01:01.363+0800|WARNING|44.0|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=12;_ThreadName=admin-listener(1);|java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class: class test.MyServletContextListener
java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class: class test.MyServletContextListener
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:936)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:916)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:687)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2289)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1935)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:109)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:278)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:299)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:228)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:482)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:529)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:550)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1430)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1600(CommandRunnerImpl.java:114)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1734)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1683)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:592)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:238)
at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:113)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:164)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:175)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:265)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
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:825)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
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:578)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:558)
at java.lang.Thread.run(Thread.java:662)

#]

[#|2012-09-17T14:01:01.364+0800|SEVERE|44.0|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=12;_ThreadName=admin-listener(1);|Exception while invoking class com.sun.enterprise.web.WebApplication start method
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class: class test.MyServletContextListener
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:138)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:278)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:299)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:228)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:482)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:529)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:550)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1430)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1600(CommandRunnerImpl.java:114)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1734)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1683)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:592)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:238)
at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:113)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:164)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:175)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:265)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
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:825)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
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:578)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:558)
at java.lang.Thread.run(Thread.java:662)

#]

[#|2012-09-17T14:01:01.365+0800|SEVERE|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=12;_ThreadName=admin-listener(1);|java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class: class test.MyServletContextListener
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class: class test.MyServletContextListener
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:138)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:278)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:299)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:228)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:482)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:529)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:550)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1430)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1600(CommandRunnerImpl.java:114)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1734)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1683)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:592)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:238)
at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:113)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:164)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:175)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:265)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
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:825)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
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:578)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:558)
at java.lang.Thread.run(Thread.java:662)

#]


 Comments   
Comment by arjavdesai [ 13/Apr/13 ]

I just tried with latest glassfish build with revision's upto 61409. The app is getting deployed fine i.e.

2013-04-13T07:42:20.845-0400] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=35 _ThreadName=admin-listener(4)] [timeMillis: 1365853340845] [levelValue: 800] [[
Loading application [WebApplication1] at [/WebApplication1]]]

[2013-04-13T07:42:20.861-0400] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=35 _ThreadName=admin-listener(4)] [timeMillis: 1365853340861] [levelValue: 800] [[
WebApplication1 was successfully deployed in 828 milliseconds.]]

Also, when invoked as either host:port/WebApplication1 or WebApplication2, I see "Hello World". Please re-try.

Comment by arjavdesai [ 13/Apr/13 ]

For WebApplication2 deployment, it shows

[2013-04-13T07:43:23.329-0400] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=128 _ThreadName=Thread-3] [timeMillis: 1365853403329] [levelValue: 800] [[
contextInitialized...]]

[2013-04-13T07:43:23.337-0400] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=128 _ThreadName=admin-listener(6)] [timeMillis: 1365853403337] [levelValue: 800] [[
Loading application [WebApplication2] at [/WebApplication2]]]

[2013-04-13T07:43:23.352-0400] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=128 _ThreadName=admin-listener(6)] [timeMillis: 1365853403352] [levelValue: 800] [[
WebApplication2 was successfully deployed in 566 milliseconds.]]

[2013-04-13T07:45:58.288-0400] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=33 _ThreadName=Thread-3] [timeMillis: 1365853558288] [levelValue: 800] [[
com.sun.webui.jsf.component.DropDown::The current value of component propertyForm:deployTable:topActionsGroup1:filter does not match any of the selections.
Did you forget to reset the value after changing the options?]]





[GLASSFISH-19072] Instantiation of EJB module withing WAR module results in "Could not create stateless EJB" java.lang.NullPointerException Created: 13/Sep/12  Updated: 29/Sep/14  Resolved: 06/Oct/12

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.1
Fix Version/s: 3.1.2.2, 4.0

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

java version "1.6.0_34"
Java(TM) SE Runtime Environment (build 1.6.0_34-b04)
Java HotSpot(TM) 64-Bit Server VM (build 20.9-b04, mixed mode)


Attachments: Text File server.log    
Tags: cdi, weld

 Description   

I have an application constructed like below

 * WAR
 ** WEB-INF\classes\web-app-classes-are-here.class
 ** WEB-INF\lib\myejbmodule.jar
 ** WEB-INF\lib\some-other-libraries.jar
 ** WEB-INF\beans.xml (empty)
 ** WEB-INF\web.xml (some servlet declarations only)

The application deploys successfully, but when I try to invoke any action which involves EJB, I am reveiving exception like in the attached file.

javax.ejb.EJBException: javax.ejb.EJBException: javax.ejb.CreateException: Could not create stateless EJB
	at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:454)
...	
	at $Proxy161.query(Unknown Source)
	at com.XXXX.gtrs.web.testplan.TestPlanListControler.searchDataStore(TestPlanListControler.java:135)
...
Caused by: java.lang.NullPointerException
	at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
	at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:1209)
	at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:144)
	at org.glassfish.weld.services.JCDIServiceImpl._createJCDIInjectionContext(JCDIServiceImpl.java:169)
	at org.glassfish.weld.services.JCDIServiceImpl.createJCDIInjectionContext(JCDIServiceImpl.java:146)
	at com.sun.ejb.containers.BaseContainer.createEjbInstanceAndContext(BaseContainer.java:1636)

Full stack trace in the attached file.



 Comments   
Comment by jjsnyder83 [ 06/Oct/12 ]

I created a war with an ejb packaged in a jar in WEB-INF/lib. A servlet in the war injects the ejb and I am able to deploy the war and successfully execute the servlet.

Comment by dmatej [ 24/Sep/14 ]

I have stack trace on Glassfish 4.1 - I have a MessageDrivenBean in library in ear/lib - it is detected but the creation ends up with this NPE. Same when I remove annotations and declare it in ejb-jar.xml in some EJB module.

Comment by dmatej [ 29/Sep/14 ]

Workaround: Moved message driven bean implementation to the ejb module, used annotations and deleted all xml files.

This is perfectly reproducible bug and should be fixed, probably in Weld (but how?).





[GLASSFISH-18992] Bean creation is blocked across all threads until method annotated with @PostConstruct has finished Created: 10/Aug/12  Updated: 22/Oct/12  Resolved: 22/Oct/12

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

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

Glassfish 3.1.2.2


Tags: cdi, jsf, weld

 Description   

Bean creation is blocked across all threads until method annotated with @PostConstruct has finished. For more information and how to reproduce it, see WELD-1157: https://issues.jboss.org/browse/WELD-1157

The bug has been fixed in Weld 1.1.9.Final.

To fix this issue, upgrade the Weld version to 1.1.9.Final.



 Comments   
Comment by jjsnyder83 [ 22/Oct/12 ]

GlassFish integration with Weld was updated to Weld 1.1.10.Final with revision 56665. This should be fixed now.





[GLASSFISH-18981] Deployment of an ear file fails if path to GlassFish directory includes spaces Created: 07/Aug/12  Updated: 17/Oct/12  Resolved: 12/Oct/12

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

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

Windows 7 64-bit
Java 6u33 x64



 Description   

In GlassFish 3.1.2.2, deploying an ear containing a war and EJB jar fails when reading META-INF/beans.xml in the EJB jar. This seems to be a regression of GLASSFISH-17242 which is also a regression of GLASSFISH-5806.

From the log:

java.net.URISyntaxException: Illegal character in path at index 16: file:/C:/Program Files/glassfish-3.1.2.2/glassfish/domains/domain1/applications/web-portal-ear/web-portal-ejb-1.0-SNAPSHOT_jar/META-INF/beans.xml
	at java.net.URI$Parser.fail(URI.java:2810)
	at java.net.URI$Parser.checkChars(URI.java:2983)
	at java.net.URI$Parser.parseHierarchical(URI.java:3067)
	at java.net.URI$Parser.parse(URI.java:3015)
	at java.net.URI.<init>(URI.java:577)
	at java.net.URL.toURI(URL.java:918)
	at org.glassfish.weld.BeanDeploymentArchiveImpl.handleEntry(BeanDeploymentArchiveImpl.java:504)
	at org.glassfish.weld.BeanDeploymentArchiveImpl.collectJarInfo(BeanDeploymentArchiveImpl.java:482)
	at org.glassfish.weld.BeanDeploymentArchiveImpl.populate(BeanDeploymentArchiveImpl.java:422)
	at org.glassfish.weld.BeanDeploymentArchiveImpl.<init>(BeanDeploymentArchiveImpl.java:148)
	at org.glassfish.weld.BeanDeploymentArchiveImpl.<init>(BeanDeploymentArchiveImpl.java:128)
	at org.glassfish.weld.DeploymentImpl.<init>(DeploymentImpl.java:121)
	at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:386)
	at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:100)
	at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
	at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:264)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:460)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
	at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
	at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:461)
	at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212)
	at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
	at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
	at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
	at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
	at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
	at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
	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)

A workaround is to install GlassFish to a path not containing spaces.



 Comments   
Comment by steve_taylor [ 07/Aug/12 ]

I could not select 3.1.2.2 as the affected version.

Comment by Hong Zhang [ 07/Aug/12 ]

Seems CDI code needs to do similar as what was fixed in the other issue: encode the space in the path before converting a URL or a String to a URI. Assign to CDI team.

Comment by jjsnyder83 [ 12/Oct/12 ]

The conversion to URI's was not necessary so I removed it.

Comment by jjsnyder83 [ 17/Oct/12 ]

Added a findbugs error fix.





[GLASSFISH-18875] EAR Deployment slow. Hangs during EJB Deployment. Possible Fix inside. Created: 09/Jul/12  Updated: 12/Oct/12  Resolved: 10/Sep/12

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

Type: Bug Priority: Blocker
Reporter: AlexP Assignee: jjsnyder83
Resolution: Fixed Votes: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.1.2 on various machines.


Attachments: Java Archive File weld-integration.jar    

 Description   

Hello,

We are developing a big JEE Application (around 80 Meg), with around 200 EJBs, 3 Webapplications, all the good stuff.
For quite a while now our deployment took forever, around 50 Minutes for a full deployment.

Today I took the time to profile glassfish and came across something interesting. Almost all of the time was spent in DeploymentImpl Class of weld-integration, specifically the getBeanDeploymentArchives(boolean printDebug) Method.
That method by default tries to log something, using the toString() of the beanDeploymentArchives Object.

The toString() uses up a lot of time, and seems to be bugged/badly implemented.

By disabling the Debug Output our Deployment Time went from 50Min to 2 Min, of which 1 is spent decompressing the ear.

Please verify, thank you.



 Comments   
Comment by daedalus [ 09/Jul/12 ]

Tested and confirmed!

This is unbelievable. I can now deploy my application in under 3 min. Before the change it took about 60min!

Please fix this incredible bug.

EDIT: I also noticed, that glassfish uses now 800MB less!! RAM during the deployment process.

Comment by AlexP [ 09/Jul/12 ]

Awesome it works for others as well!

Comment by AlexP [ 09/Jul/12 ]

The weld-integration.jar with the patch (disabled debug output) so others can try this too.

Comment by AlexP [ 09/Jul/12 ]

@Daedalus

I believe those 800 megs were leftovers from the broken toString...have you noticed your application running faster as well?

Comment by Hong Zhang [ 09/Jul/12 ]

Wow, this sounds great and thanks for submitting the patch to make GlassFish better! I will let CDI team to follow up and take appropriate action.

Comment by jjsnyder83 [ 09/Jul/12 ]

Thanks for the information. I will look into getting this fix in asap.

Comment by SimY4 [ 24/Jul/12 ]

Patch won't work for me. Still having troubles with EJB deployment here. Is there any other possible fixes for this?

Comment by jjsnyder83 [ 10/Sep/12 ]

I have made the change to DeploymentImpl in both the 3.1.2-SUSTAINING branch and the trunk.





[GLASSFISH-18824] GF 4.0 uses Weld 1.1.4.Final, but latest release is 1.1.8.Final Created: 22/Jun/12  Updated: 22/Oct/12  Resolved: 22/Oct/12

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

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

Tags: cdi, weld

 Description   

GF 4.0 uses Weld 1.1.4.Final, but latest release is 1.1.8.Final.
Consider upgrading to newest release?



 Comments   
Comment by jjsnyder83 [ 22/Jun/12 ]

I am currently working on this. Hopefully it won't be too long before it's complete.

Comment by Vetle Leinonen-Roeim [ 22/Jun/12 ]

Great!

Comment by Vetle Leinonen-Roeim [ 16/Aug/12 ]

Should be 1.1.9.Final instead, to fix GLASSFISH-18992.

Comment by donatasc [ 19/Oct/12 ]

Are there any plans/considerations for GlassFish 4.0 to integrate Weld 1.2.x (1.2.0 beta is current release) ?

Comment by jjsnyder83 [ 19/Oct/12 ]

I am in the process of upgrading 4.0 to Weld 1.1.10.Final. My plan is to start next week working on integration with Weld 1.2.x.

Comment by jjsnyder83 [ 22/Oct/12 ]

GlassFish integration with Weld was updated to Weld 1.1.10.Final with revision 56665.





[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-18793] Cannot @Inject an EJB implementation into a JAX-RS resource Created: 10/Jun/12  Updated: 12/Apr/13  Resolved: 12/Apr/13

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

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

Attachments: GZip Archive cdi-jaxrs-bug-v2.tar.gz     GZip Archive cdi-jaxrs-bug-v3.tar.gz     GZip Archive cdi-jaxrs-bug.tar.gz    
Tags: cdi, ejb, jax-rs

 Description   

In an .ear file with JAX-RS resources in the lib directory, it is impossible to have CDI inject an EJB implementation into a JAX-RS resource.

I have an .ear file with a lib directory.

In the .ear file I have:

  • an "api" .jar in the lib directory consisting of a single interface (a business interface)
  • an EJB module (a .jar file at the root level containing a local stateless session bean implementing the business interface described above, and a META-INF/beans.xml file causing it to be a CDI bean archive
  • a "jaxrs" .jar in the lib directory containing a single JAX-RS resource class with an injection point in it declared as @Inject private Greeter greeter; (where Greeter is the business interface), and a META-INF/beans.xml file causing it to be a CDI bean archive
  • a .war file containing a single class that extends javax.ws.rs.core.Application and serves as the "mount point" for a JAX-RS application whose single resource is the resource described above

Through various permutations of this application, deployment fails with Weld claiming that it cannot satisfy the Greeter injection point.

If I get CDI out of the mix and put @ManagedBean on the resource class and change the @Inject to @EJB everything works fine. But I want to use CDI injection, not @EJB injection.

I have attached a test case. Unzip/Untar it and run mvn clean install on it. Then deploy the resulting .ear file. It will be available under (e.g.) http://localhost:8080/cdi-jaxrs-war/api/greeting.



 Comments   
Comment by Martin Matula [ 10/Jun/12 ]

FYI - I was able to make it work by removing beans.xml from the "jaxrs" jar and changing the annotation on the GreetingResource from @RequestScoped to @ManagedBean.
Apparently @RequestScoped does not work if there is no beans.xml in the jar. On the other hand, if I add beans.xml to the jar it complains in cannot satisfy the injection point.

Comment by ljnelson [ 11/Jun/12 ]

Wait, that's odd. You're saying you de-bean-archived the GreetingResource and then @Inject worked? I confess that is a whole different sort of specification violation I didn't even think to try.

Comment by ljnelson [ 11/Jun/12 ]

Martin: I tried your approach on the off chance it would work for some strange reason. I'm guessing that you got deployment to "work" (i.e. the console said that deployment completed normally)? Deployment may have completed, but injection did not. If you then actually hit the URL you should discover that the injection point is null, as you'd expect.

Comment by Martin Matula [ 11/Jun/12 ]

After I made the changes it does work including the injection. Here is what I did:

  • after downloading your sample, war was missing in the list of modules in the top-level pom (or at least it did not open in the IDE when I opened the pom), so I added it
  • I removed META-INF/beans.xml from the "jaxrs" jar - i.e. the jar that contains the JAX-RS resource (this fixes the deployment issue)
  • I changed the annotation on the resource from @RequestScoped to @ManagedBean

After I made these changes it started working (including the injection).

Before I did this, I actually created my own version of your app (based on your stackoverflow.com question) where I observed this behavior - so then I just applied the same to the project attached to the issue - both apps worked for me after I made these changes.

Comment by ljnelson [ 11/Jun/12 ]

Martin, thanks for the effort.

I've attached the latest version of the project, complete with Martin's suggested changes. It still does not work.

In case I'm doing something wrong, here are the steps I followed:

  • Made sure GlassFish 3.1.2 is running. I happen to have created a domain called (for unimportant reasons) jx with its admin port on 9048.
  • Made sure this GlassFish instance is empty of applications.
  • Downloaded the "cdi-jaxrs-bug-v2.tar.gz" tarball attached to this issue.
  • cd'ed into its root-level directory and ran mvn clean install
  • cd'ed into ear/target
  • Ran asadmin --port=9048 deploy ./cdi-jaxrs-ear-0.0.1-SNAPSHOT.ear
  • Deployment completed successfully
  • Pointed my browser at http://localhost:9080/cdi-jaxrs-war/api/greeting and observed a NullPointerException where the resource class attempts to use the injected Greeter implementation
Comment by Martin Matula [ 11/Jun/12 ]

Ah, one more thing I forgot was missing in your original project - I've added beans.xml to WEB-INF folder of your web app (war project). Do that in your v2 of the project and it'll start working.

Comment by ljnelson [ 11/Jun/12 ]

Thank you! Indeed, that works. I will see if I can write up a post-mortem here. I still think this bug is valid, although as you have helpfully pointed out there is a workaround.

Comment by ljnelson [ 11/Jun/12 ]

I've attached "version 3" of my project, complete with Martin's changes. This version works.

It is difficult to know whether this bug is a valid one or not.

Section 1.2.3 of the CDI specification says in part:

The container performs dependency injection on all managed bean instances, even those which are not contextual instances.

Because of the confusion in the specification between the term "managed bean" in the Managed Beans sense and "managed bean" in the CDI managed bean sense (see CDI specification section 3.1) it is unclear what this means. I'll capitalize the former term and leave the latter term lowercase.

It would appear that some combination of GlassFish and Jersey have interpreted this sentence to mean that CDI injection is performed on Managed Beans, whether or not those Managed Beans are managed beans. This would explain why Martin's fixes work here.

On the other hand, the CDI specification then says very explicitly in section 12.1 that "bean classes of enabled beans must be deployed in bean archives". (A bean archive is any .jar or .war file with a META-INF/bean.xml or a WEB-INF/beans.xml file (respectively).) Section 5 then goes on to describe in great detail how dependency injection in CDI works, but the thing that all scenarios share in common is that they work on bean classes, which, as we've just seen, are required to be part of bean archives.

Finally, other application server vendors recommend very strongly that all JAX-RS resources that should serve as the target for CDI injection should be annotated with @RequestScoped, which would also of course require their containing .jar or .war file to have a beans.xml.

My added wrinkle is that my JAX-RS classes are discovered "outside" of the .war file that serves as their "mount point". That is, my .war file does not (deliberately) bundle the JAX-RS resource classes it manages under either its classes or lib directory. Instead, they are located in the containing .ear file's lib directory where the JAX-RS Application class can discover them dynamically, per the JAX-RS specification. This allows me to do much more flexible .ear packaging.

So the odd thing about that is that of course technically speaking my .war file shouldn't really have to be a bean archive itself as it contains no bean classes.

For all these reasons I believe that GlassFish is in error here, at least in the following respects:

  • I should be able to put a META-INF/beans.xml file in my JAX-RS jars, annotate my JAX-RS resources with @RequestScoped and have CDI injection performed on them appropriately, whether or not they are also annotated with @ManagedBean.
  • My JAX-RS classes should not be required to have @ManagedBean on them in order for CDI injection to occur.
  • If my JAX-RS classes are divorced from the .war file that manages them, there should be no reason I should have to put a WEB-INF/beans.xml file in the .war file.
Comment by TangYong [ 12/Apr/13 ]

I have confirmed the sample(cdi-jaxrs-bug-v3.tar.gz ) on current v4, and while launching http://localhost:8080/cdi-jaxrs-war/api/greeting, accessing rest resource failed and in the server.log, the following exception happened,

[2013-04-12T16:39:34.602+0900] [glassfish 4.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=19 _ThreadName=http-listener-1(1)] [timeMillis: 1365752374602] [levelValue: 900] [[
StandardWrapperValve[com.edugility.cdi.jaxrs.Application]: Servlet.service() for servlet com.edugility.cdi.jaxrs.Application threw exception
org.glassfish.hk2.api.UnsatisfiedDependencyException: There was no object available for injection at Injectee(requiredType=Greeter,parent=GreetingResource,qualifiers={}),position=-1,optional=false,self=false,unqualified=null,23965041)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:74)
at org.jvnet.hk2.internal.Utilities.justInject(Utilities.java:771)
at org.jvnet.hk2.internal.ServiceLocatorImpl.inject(ServiceLocatorImpl.java:781)
at org.glassfish.jersey.gf.cdi.CdiComponentProvider$CdiFactory$2.getInstance(CdiComponentProvider.java:183)
at org.glassfish.jersey.gf.cdi.CdiComponentProvider$CdiFactory.provide(CdiComponentProvider.java:130)
at org.jvnet.hk2.internal.FactoryCreator.create(FactoryCreator.java:96)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:574)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:561)
at org.glassfish.jersey.internal.inject.Injections.getOrCreate(Injections.java:172)
at org.glassfish.jersey.server.model.MethodHandler$ClassBasedMethodHandler.getInstance(MethodHandler.java:185)
at org.glassfish.jersey.server.internal.routing.PushMethodHandlerRouter.apply(PushMethodHandlerRouter.java:105)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:118)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:121)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:121)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:121)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:121)
at org.glassfish.jersey.server.internal.routing.RoutingStage.apply(RoutingStage.java:102)
at org.glassfish.jersey.server.internal.routing.RoutingStage.apply(RoutingStage.java:62)
at org.glassfish.jersey.process.internal.Stages.process(Stages.java:197)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:208)
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.servlet.WebComponent.service(WebComponent.java:311)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:372)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:335)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:218)
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:174)
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: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)
]]

Noting the exception is the same as GLASSFISH-20255, so the issue has been blocked by GLASSFISH-20255

-Tang

Comment by TangYong [ 12/Apr/13 ]

BTW: even if not using @ManagedBean instead using CDI, the result should be same.
Component/s should be changed into jax-rs.

Comment by jjsnyder83 [ 12/Apr/13 ]

Duplicate of http://java.net/jira/browse/GLASSFISH-20255





[GLASSFISH-18768] Memory leak with WS + CDI (empty beans.xml) Created: 30/May/12  Updated: 23/Apr/13  Resolved: 23/Apr/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.1, 3.1.2
Fix Version/s: 4.0

Type: Bug Priority: Blocker
Reporter: kabhal Assignee: mtaube
Resolution: Fixed Votes: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

MacOSX
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3646)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode

Version = GlassFish Server Open Source Edition 3.1.1 (build 12)

Version = GlassFish Server Open Source Edition 3.1.2 (build 23)


Tags: metro2_2_1-waived

 Description   

A simple JAX-WS service with no implementation or injection + empty beans.xml in WEB-INF create a memory leak
if you call the WebService in a loop.

Without the empty beans.xml, no memory leak.



 Comments   
Comment by kabhal [ 30/May/12 ]

I used the project attached in GLASSFISH-16030 to reproduce the leak.

Comment by frank_w [ 14/Mar/13 ]

Workaround that worked for me was to annotate the Class with @Stateless
Additionally I used /WEB-INF/glassfish-ejb-jar.xml to configure the URL to the webservice and make https call possible

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE glassfish-ejb-jar PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 EJB 3.1//EN" "http://glassfish.org/dtds/glassfish-ejb-jar_3_1-1.dtd">
<glassfish-ejb-jar>
<enterprise-beans>
<ejb>
<ejb-name>EJBName</ejb-name>
<webservice-endpoint>
<port-component-name>EJBName</port-component-name>
<endpoint-address-uri>/<appliction-context>/ServiceName</endpoint-address-uri>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</webservice-endpoint>
</ejb>
</enterprise-beans>
</glassfish-ejb-jar>

Comment by shreedhar_ganapathy [ 19/Apr/13 ]

Is the memory leak root cause identified?

Any ETA on the fix?

Comment by mtaube [ 23/Apr/13 ]

Deploying the application from GLASSFISH-16030 to the latest build of glassfish and running the following loop several times:

#!/bin/bash
for i in

{1..10000}

do
curl http://localhost:8080/boot-gateway/Boot_v1 > /dev/null
done

I do not see any evidence of a memory leak while connected to the process with JProfiler.

Can you confirm the reproduction steps?

Comment by mtaube [ 23/Apr/13 ]

Also with the following test driver I cannot see any memory leaks in JProfiler:

import com.example.boot_gateway.boot_v1.*;

public class Test {

public static void testBoot() throws Exception

{ BootV1 bootV1 = new BootV1(); ObjectFactory of = new ObjectFactory(); RequestType rt = of.createRequestType(); assert "approved".equals(bootV1.getTnsBootServicePortType().process(rt).getResponseDescription()); }

public static void main(String args[]) {
try {
for (int i = 0; i < 10000; i++)

{ testBoot(); }

} catch (Exception ex)

{ ex.printStackTrace(); }

}
}





[GLASSFISH-18588] Deployment errors for exploded bean archives Created: 02/Apr/12  Updated: 08/Oct/12  Resolved: 05/Oct/12

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

Type: Bug Priority: Major
Reporter: Harald Wellmann Assignee: Sivakumar Thyagarajan
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File GLASSFISH-18588.patch    

 Description   

When a bean archive JAR is deployed in exploded form, GlassFish logs error messages of the following kind:

[#|2012-04-02T19:31:35.990+0200|WARNING|glassfish3.1.2|org.glassfish.weld.BeanDeploymentArchiveImpl|_ThreadID=17;_ThreadName=AutoDeployer;|Error while trying to load Bean ClassWEB-INF.lib.projectcore.jar.core.MyUtilityClass : java.lang.ClassNotFoundException: WEB-INF.lib.projectcore.jar.core.MyUtilityClass|#]

This problem is similar to GLASSFISH-16359 and can be reproduced easily by copying the project-exploded-jar.war attachment from that issue to .../domains/domain1/autodeploy of a running GlassFish instance.

The same error occurs both with GlassFish 3.1.1 and 3.1.2.

When working with the GlassFish Eclipse plugin, this is rather annoying, as dependent projects from the workspace are deployed as exploded JARs by default, so the console gets flooded with error messages of this kind for any non-trivial project using CDI.

Checking the option "Use Real JARs for Archive Deployment" does not help either. With this option, I'm getting another error "Deployment Error for module: myproject: File not found : /home/hwellmann/workspace/myproject/myproject.war" when launching my webapp from Eclipse.



 Comments   
Comment by Hong Zhang [ 02/Apr/12 ]

assign to cdi team for initial evaluation

Comment by Harald Wellmann [ 21/Apr/12 ]

Here's a patch for BeanDeploymentArchiveImpl from 3.1.2 which fixes the issue.

An exploded WAR with exploded libraries has entries of the form

WEB-INF/lib/foo.jar/com/example/foo/Foo.class

which are currently being passed to the class loader as candidates for managed bean classes.

Entries that end with .class must not be loaded if they start with WEB-INF/lib.





[GLASSFISH-18549] WELD-001408 with Infinispan 5.1.2 Created: 22/Mar/12  Updated: 03/Apr/13  Resolved: 02/Apr/13

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

Type: Bug Priority: Major
Reporter: kovica Assignee: jjsnyder83
Resolution: Works as designed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 11.10
uname -a returns Linux localhost 3.0.0-16-generic #29-Ubuntu SMP Tue Feb 14 12:49:42 UTC 2012 i686 i686 i386 GNU/Linux
Glassfish 3.1.2
JDK: ava version "1.7.0_03"
Java(TM) SE Runtime Environment (build 1.7.0_03-b04)
Java HotSpot(TM) Server VM (build 22.1-b02, mixed mode)


Attachments: File TestJEE-ear-1.0-SNAPSHOT.ear     Zip Archive TestJEE-src.zip    
Tags: Infinispan-5-1-2, glassfish-3-1-2

 Description   

I've attached a sample JEE 6 application that is using Infinispan 5.1.2. The application is working on JBoss 7.1.1, but not on Glassfish 3.1.2.
It uses:

  • maven as build system
  • Config class to override the default cache manager settings using CDI
  • CacheBean that uses the injected cache manager and work with it
  • Startup bean to put and get some test values from the cache
    When I deploy it to Glassfish I get:
    org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [CacheContainer] with qualifiers [@Default] at injection point [[field] @Inject private org.infinispan.cdi.AdvancedCacheProducer.defaultCacheContainer]
    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:461)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
    at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
    at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:214)
    at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:207)
    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:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    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:148)
    at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
    at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
    at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
    at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
    at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
    at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
    at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
    at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
    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:722)


 Comments   
Comment by kovica [ 22/Mar/12 ]

TestJEE-ear-1.0-SNAPSHOT.ear is a resulting EAR file you can deploy to Glassfish
TestJEE-src.zip is maven based source project

Comment by kovica [ 19/Jul/12 ]

I get the same error on Glassfish 3.1.2.2

Comment by Sivakumar Thyagarajan [ 10/Dec/12 ]

Transferring to JJ Snyder

Comment by tlcksnyder [ 26/Mar/13 ]

Retested with Weld 2.0.Beta6. App still fails, but with new exception:

[2013-03-21T17:02:39.269-0400] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=83 _ThreadName=AutoDeployer] [timeMillis: 1363899759269] [levelValue: 1000] [[
Exception while loading the app : CDI definition failure:WELD-000409 Observer method for container lifecycle event [[BackedAnnotatedMethod] org.infinispan.cdi.InfinispanExtension.registerCacheConfigurations(@Observes AfterDeploymentValidation, CacheManagerEventBridge, @Any Instance<EmbeddedCacheManager>, BeanManager)] can only inject BeanManager.
org.jboss.weld.exceptions.DefinitionException: WELD-000409 Observer method for container lifecycle event [[BackedAnnotatedMethod] org.infinispan.cdi.InfinispanExtension.registerCacheConfigurations(@Observes AfterDeploymentValidation, CacheManagerEventBridge, @Any Instance<EmbeddedCacheManager>, BeanManager)] can only inject BeanManager.
at org.jboss.weld.event.ObserverMethodImpl.checkObserverMethod(ObserverMethodImpl.java:186)
at org.jboss.weld.event.ObserverMethodImpl.initialize(ObserverMethodImpl.java:234)
at org.jboss.weld.bootstrap.ObserverInitializationContext.initialize(ObserverInitializationContext.java:37)
at org.jboss.weld.bootstrap.ExtensionBeanDeployer.deployBeans(ExtensionBeanDeployer.java:78)
at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:464)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:192)
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:1761)
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)

Comment by TangYong [ 01/Apr/13 ]

JJ, kovica,

I am confirming the status combining Infinispan 5.2.1.Final with Glassfish v4.

About the attachment sample, I need to mention an important point as following:

Because Infinispan CDI 5.1.2.FINAL does not depend on some artifacts with "<type>test-jar</type>", the process of the ear's package has not any problem. However, while using Infinispan CDI 5.2.1.Final, packaging the ear's package will failed.

You must modify TestJEE-src\TestJEE-ear\pom.xml and adding the following into maven-ear-plugin's configuration,

<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-ear-plugin</artifactId>
        <version>2.6</version>
        <configuration>
            <version>6</version>
            <defaultLibBundleDir>lib</defaultLibBundleDir>
            <artifactTypeMappings>
                <artifactTypeMapping type="test-jar" mapping="jar" />
            </artifactTypeMappings>
        </configuration>
</plugin>
Comment by TangYong [ 01/Apr/13 ]

Apart from adding the above test-jar mapping, needing to add the following dependency into TestJEE-src\TestJEE-ejb\pom.xml,

 <dependency>
            <groupId>javassist</groupId>
            <artifactId>javassist</artifactId>
            <version>3.12.1.GA</version>
 </dependency>

otherwise, you will see the following exception:

Exception 0 :
java.lang.RuntimeException: Javassist not found on the class path, @ServiceHandler requires javassist to work. @ServiceHandler found on [BackedAnnotatedType] class org.infinispan.cdi.InfinispanExtension$5
at org.jboss.solder.serviceHandler.ServiceHandlerExtension.processAnnotatedType(ServiceHandlerExtension.java:71)
at sun.reflect.GeneratedMethodAccessor45.invoke(Unknown Source)
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.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:274)
at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:124)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:261)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:240)
at org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:155)
at org.jboss.weld.event.TransactionalObserverNotifier.notifyObserver(TransactionalObserverNotifier.java:44)
at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:116)

Comment by TangYong [ 01/Apr/13 ]

while deploying the ear, v4's confirmation result(still failed) is as following,

[2013-04-01T14:41:51.387+0900] [glassfish 4.0] [WARNING] [] [org.jboss.weld.Reflection] [tid: _ThreadID=42 _ThreadName=admin-listener(1)] [timeMillis: 1364794911387] [levelValue: 900] [[
WELD-001450 Interceptor method public java.lang.Object org.jboss.solder.exception.control.ExceptionHandledInterceptor.passExceptionsToSolderCatch(javax.interceptor.InvocationContext) throws java.lang.Throwable does not declare that it throws Exception.]]

[2013-04-01T14:41:51.777+0900] [glassfish 4.0] [SEVERE] [] [org.jboss.weld.Bootstrap] [tid: _ThreadID=42 _ThreadName=admin-listener(1)] [timeMillis: 1364794911777] [levelValue: 1000] [[
Exception(s) thrown during observer of BeforeShutdown]]

[2013-04-01T14:41:51.777+0900] [glassfish 4.0] [SEVERE] [] [org.jboss.weld.Bootstrap] [tid: _ThreadID=42 _ThreadName=admin-listener(1)] [timeMillis: 1364794911777] [levelValue: 1000] [[

java.lang.NullPointerException
at org.infinispan.cdi.InfinispanExtension.cleanupBeanManager(InfinispanExtension.java:288)
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.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:274)
at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:124)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:261)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:240)
at org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:155)
at org.jboss.weld.event.TransactionalObserverNotifier.notifyObserver(TransactionalObserverNotifier.java:44)
at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:116)
at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:101)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:69)
at org.jboss.weld.bootstrap.events.BeforeShutdownImpl.fire(BeforeShutdownImpl.java:48)
at org.jboss.weld.bootstrap.events.BeforeShutdownImpl.fire(BeforeShutdownImpl.java:39)
at org.jboss.weld.bootstrap.WeldBootstrap.shutdown(WeldBootstrap.java:650)
at org.glassfish.weld.WeldDeployer.doBootstrapShutdown(WeldDeployer.java:322)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:207)
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)
]]

[2013-04-01T14:41:51.793+0900] [glassfish 4.0] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=42 _ThreadName=admin-listener(1)] [timeMillis: 1364794911793] [levelValue: 1000] [[
Exception during lifecycle processing
org.glassfish.deployment.common.DeploymentException: CDI definition failure:Exception List with 1 exceptions:
Exception 0 :
org.jboss.weld.exceptions.IllegalStateException: WELD-001332 BeanManager method getBeans() is not available during application initialization
at org.jboss.weld.bean.builtin.BeanManagerProxy.checkContainerValidated(BeanManagerProxy.java:142)
at org.jboss.weld.bean.builtin.BeanManagerProxy.getBeans(BeanManagerProxy.java:80)
at org.jboss.solder.core.CoreExtension.failIfWeldExtensionsDetected(CoreExtension.java:215)
at org.jboss.solder.core.CoreExtension.afterBeanDiscovery(CoreExtension.java:208)
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.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:274)
at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:124)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:261)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:240)
at org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:155)
at org.jboss.weld.event.TransactionalObserverNotifier.notifyObserver(TransactionalObserverNotifier.java:44)
at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:116)
at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:101)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:69)
at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:38)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:53)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:523)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:204)
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)

at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:212)
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.DefinitionException: Exception List with 1 exceptions:
Exception 0 :
org.jboss.weld.exceptions.IllegalStateException: WELD-001332 BeanManager method getBeans() is not available during application initialization
at org.jboss.weld.bean.builtin.BeanManagerProxy.checkContainerValidated(BeanManagerProxy.java:142)
at org.jboss.weld.bean.builtin.BeanManagerProxy.getBeans(BeanManagerProxy.java:80)
at org.jboss.solder.core.CoreExtension.failIfWeldExtensionsDetected(CoreExtension.java:215)
at org.jboss.solder.core.CoreExtension.afterBeanDiscovery(CoreExtension.java:208)
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.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:274)
at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:124)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:261)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:240)
at org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:155)
at org.jboss.weld.event.TransactionalObserverNotifier.notifyObserver(TransactionalObserverNotifier.java:44)
at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:116)
at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:101)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:69)
at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:38)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:53)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:523)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:204)
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)

at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:40)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:53)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:523)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:204)
... 58 more
]]

[2013-04-01T14:41:51.793+0900] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=42 _ThreadName=admin-listener(1)] [timeMillis: 1364794911793] [levelValue: 1000] [[
Exception while loading the app]]

[2013-04-01T14:41:51.809+0900] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=42 _ThreadName=admin-listener(1)] [timeMillis: 1364794911809] [levelValue: 1000] [[
Exception while loading the app : CDI definition failure:Exception List with 1 exceptions:
Exception 0 :
org.jboss.weld.exceptions.IllegalStateException: WELD-001332 BeanManager method getBeans() is not available during application initialization
at org.jboss.weld.bean.builtin.BeanManagerProxy.checkContainerValidated(BeanManagerProxy.java:142)
at org.jboss.weld.bean.builtin.BeanManagerProxy.getBeans(BeanManagerProxy.java:80)
at org.jboss.solder.core.CoreExtension.failIfWeldExtensionsDetected(CoreExtension.java:215)
at org.jboss.solder.core.CoreExtension.afterBeanDiscovery(CoreExtension.java:208)
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.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:274)
at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:124)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:261)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:240)
at org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:155)
at org.jboss.weld.event.TransactionalObserverNotifier.notifyObserver(TransactionalObserverNotifier.java:44)
at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:116)
at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:101)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:69)
at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:38)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:53)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:523)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:204)
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)

org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
Exception 0 :
org.jboss.weld.exceptions.IllegalStateException: WELD-001332 BeanManager method getBeans() is not available during application initialization
at org.jboss.weld.bean.builtin.BeanManagerProxy.checkContainerValidated(BeanManagerProxy.java:142)
at org.jboss.weld.bean.builtin.BeanManagerProxy.getBeans(BeanManagerProxy.java:80)
at org.jboss.solder.core.CoreExtension.failIfWeldExtensionsDetected(CoreExtension.java:215)
at org.jboss.solder.core.CoreExtension.afterBeanDiscovery(CoreExtension.java:208)
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.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:274)
at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:124)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:261)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:240)
at org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:155)
at org.jboss.weld.event.TransactionalObserverNotifier.notifyObserver(TransactionalObserverNotifier.java:44)
at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:116)
at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:101)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:69)
at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:38)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:53)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:523)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:204)
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)

at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:40)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:53)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:523)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:204)
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)
]]

[2013-04-01T14:41:51.902+0900] [glassfish 4.0] [WARNING] [] [org.glassfish.jersey.internal.Errors] [tid: _ThreadID=42 _ThreadName=admin-listener(1)] [timeMillis: 1364794911902] [levelValue: 900] [[
The following warnings have been detected: WARNING: Parameter 1 of type org.infinispan.Cache<K, V> from public static <K,V> void org.infinispan.cdi.ContextInputCache.set(org.infinispan.Cache<K, V>) is not resolvable to a concrete type.
WARNING: Parameter baseEvent of type javax.enterprise.event.Event<T> from private javax.enterprise.event.Event<T> org.infinispan.cdi.event.AbstractEventBridge.baseEvent is not resolvable to a concrete type.
WARNING: Parameter annotatedMember of type javax.enterprise.inject.spi.AnnotatedMember<?> from private javax.enterprise.inject.spi.AnnotatedMember<?> org.infinispan.cdi.AdvancedCacheProducer.annotatedMember is not resolvable to a concrete type.
]]

Comment by TangYong [ 01/Apr/13 ]

In Glassfish 3.1.2.2, the issue can be re-produced and the same exception happened,

org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [CacheContainer] with qualifiers [@Default] at injection point [[field] @Inject private org.infinispan.cdi.AdvancedCacheProducer.defaultCacheContainer]
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:311)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:280)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:143)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:163)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:382)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:367)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:380)
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:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:461)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
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:722)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [CacheContainer] with qualifiers [@Default] at injection point [[field] @Inject private org.infinispan.cdi.AdvancedCacheProducer.defaultCacheContainer]
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:311)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:280)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:143)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:384)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:367)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:380)
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:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:461)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
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:722)

And in JBOSS Infinispan forum, a same issue(https://community.jboss.org/thread/197204) has been existed.

Comment by TangYong [ 01/Apr/13 ]

Based on the above confirmation, although needing to investigate in depth, I suggest adjusting the fix version from 4.0 --> future version because:

1 the confirmation results are not the same on gf 4 and 3.1.2.2

2 weld itself has change between 1.x and 2.x

Comment by TangYong [ 01/Apr/13 ]

Deeply,

1 The attachment(TestJEE-ear-1.0-SNAPSHOT.ear using infinispan 5.1.2.FINAL) can be deployed and ran in JBOSS 7.1.1.Final, you can see the following result and "VALUE_1" is printed correctly.

16:34:37,452 INFO [org.jboss.as.security] (MSC service thread 1-2) JBAS013100: Current PicketBox version=4.0.7.Final
16:34:37,952 INFO [org.jboss.as.connector] (MSC service thread 1-4) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.9.Final)
16:34:40,202 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool – 27) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
16:34:43,687 INFO [org.jboss.as.naming] (MSC service thread 1-1) JBAS011802: Starting Naming Service
16:34:45,390 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-1) Coyote HTTP/1.1を http--127.0.0.1-8080 で起動します
16:34:45,468 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) JBAS015400: Bound mail session [java:jboss/mail/Default]
16:34:46,468 INFO [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-2) JBoss Web Services - Stack CXF Server 4.0.2.GA
16:34:50,562 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-4) JBAS015012: Started FileSystemDeploymentService for directory D:\20130125\jboss-as-7.1.1.Final\standalone\deployments
16:34:50,624 INFO [org.jboss.as.remoting] (MSC service thread 1-4) JBAS017100: Listening on /127.0.0.1:9999
16:34:50,624 INFO [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on /127.0.0.1:4447
16:34:51,515 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
16:34:51,749 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
16:34:51,749 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.1.1.Final "Brontes" started in 30016ms - Started 133 of 208 services (74 services are passive or on-demand)
16:44:02,060 INFO [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-1) JBossOSGi Framework Core - 1.1.8.Final
16:44:02,326 INFO [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-4) Install bundle: system.bundle:0.0.0
16:44:02,810 INFO [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-2) Install bundle: javax.transaction.api:0.0.0
16:44:03,014 INFO [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-3) Install bundle: jboss-osgi-logging:1.0.0
16:44:03,014 INFO [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-1) Install bundle: jbosgi-http-api:1.0.5
16:44:03,060 INFO [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-2) Install bundle: org.apache.felix.configadmin:1.2.8
16:44:03,076 INFO [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-3) Install bundle: jboss-as-osgi-configadmin:7.1.1.Final
16:44:03,092 INFO [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-1) Install bundle: org.apache.felix.log:1.0.0
16:44:03,295 INFO [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-4) Install bundle: osgi.enterprise:4.2.0.201003190513
16:44:03,451 INFO [org.jboss.osgi.framework.internal.StartLevelPlugin] (MSC service thread 1-2) Starting bundles for start level: 1
16:44:03,451 INFO [org.jboss.osgi.framework.internal.HostBundleState] (MSC service thread 1-2) Bundle started: jbosgi-http-api:1.0.5
16:44:03,451 INFO [org.jboss.osgi.framework.internal.HostBundleState] (MSC service thread 1-2) Bundle started: osgi.enterprise:4.2.0.201003190513
16:44:03,467 INFO [org.jboss.osgi.framework.internal.HostBundleState] (MSC service thread 1-2) Bundle started: jboss-as-osgi-configadmin:7.1.1.Final
16:44:03,467 INFO [org.jboss.osgi.framework.internal.HostBundleState] (MSC service thread 1-2) Bundle started: jboss-osgi-logging:1.0.0
16:44:03,482 INFO [org.jboss.osgi.framework.internal.HostBundleState] (MSC service thread 1-2) Bundle started: org.apache.felix.log:1.0.0
16:44:03,482 INFO [org.jboss.osgi.framework.internal.HostBundleState] (MSC service thread 1-2) Bundle started: javax.transaction.api:0.0.0
16:44:03,498 INFO [org.jboss.osgi.framework.internal.HostBundleState] (MSC service thread 1-2) Bundle started: org.apache.felix.configadmin:1.2.8
16:44:03,514 INFO [org.jboss.osgi.framework.internal.FrameworkActive] (MSC service thread 1-2) OSGi Framework started
16:46:01,501 INFO [org.jboss.as.repository] (management-handler-thread - 1) JBAS014900: Content added at location D:\20130125\jboss-as-7.1.1.Final\standalone\data\content\4e\330280f98440a69664170b46a50f3e94b5af1e\content
16:46:01,517 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "TestJEE-ear-1.0-SNAPSHOT.ear"
16:46:02,485 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "TestJEE-ejb-1.0-SNAPSHOT.jar"
16:46:03,470 INFO [org.jboss.weld.deployer] (MSC service thread 1-3) JBAS016002: Processing weld deployment TestJEE-ear-1.0-SNAPSHOT.ear
16:46:03,767 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016002: Processing weld deployment TestJEE-ejb-1.0-SNAPSHOT.jar
16:46:03,782 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named StartupBean in deployment unit subdeployment "TestJEE-ejb-1.0-SNAPSHOT.jar" of deployment "TestJEE-ear-1.0-SNAPSHOT.ear" are as follows:

java:global/TestJEE-ear-1.0-SNAPSHOT/TestJEE-ejb-1.0-SNAPSHOT/StartupBean!com.mycompany.StartupBean
java:app/TestJEE-ejb-1.0-SNAPSHOT/StartupBean!com.mycompany.StartupBean
java:module/StartupBean!com.mycompany.StartupBean
java:global/TestJEE-ear-1.0-SNAPSHOT/TestJEE-ejb-1.0-SNAPSHOT/StartupBean
java:app/TestJEE-ejb-1.0-SNAPSHOT/StartupBean
java:module/StartupBean

16:46:03,782 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named CacheBean in deployment unit subdeployment "TestJEE-ejb-1.0-SNAPSHOT.jar" of deployment "TestJEE-ear-1.0-SNAPSHOT.ear" are as follows:

java:global/TestJEE-ear-1.0-SNAPSHOT/TestJEE-ejb-1.0-SNAPSHOT/CacheBean!com.mycompany.CacheBean
java:app/TestJEE-ejb-1.0-SNAPSHOT/CacheBean!com.mycompany.CacheBean
java:module/CacheBean!com.mycompany.CacheBean
java:global/TestJEE-ear-1.0-SNAPSHOT/TestJEE-ejb-1.0-SNAPSHOT/CacheBean
java:app/TestJEE-ejb-1.0-SNAPSHOT/CacheBean
java:module/CacheBean

16:46:03,860 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016005: Starting Services for CDI deployment: TestJEE-ear-1.0-SNAPSHOT.ear
16:46:03,938 INFO [org.jboss.weld.Version] (MSC service thread 1-2) WELD-000900 1.1.5 (AS71)
16:46:03,985 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016008: Starting weld service for deployment TestJEE-ear-1.0-SNAPSHOT.ear
16:46:05,126 INFO [org.infinispan.cdi.InfinispanExtension] (MSC service thread 1-2) ISPN017001: Infinispan CDI extension version: 5.1.2.FINAL
16:46:05,126 INFO [org.jboss.solder.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-2) Solder Config XML provider starting...
16:46:05,126 INFO [org.jboss.solder.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-2) Loading XmlDocumentProvider: org.jboss.solder.config.xml.bootstrap.ResourceLoaderXmlDocumentProvider
16:46:05,142 INFO [org.jboss.solder.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-2) Reading XML file: vfs:/D:/20130125/jboss-as-7.1.1.Final/bin/content/TestJEE-ear-1.0-SNAPSHOT.ear/lib/infinispan-cdi-5.1.2.FINAL.jar/META-INF/beans.xml
16:46:05,142 INFO [org.jboss.solder.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-2) Reading XML file: vfs:/D:/20130125/jboss-as-7.1.1.Final/bin/content/TestJEE-ear-1.0-SNAPSHOT.ear/TestJEE-ejb-1.0-SNAPSHOT.jar/META-INF/beans.xml
16:46:05,157 INFO [org.jboss.solder.Version] (MSC service thread 1-2) Solder 3.1.0.Final (build id: 3.1.0.Final)
16:46:06,454 INFO [org.jboss.solder.bean.defaultbean.DefaultBeanExtension] (MSC service thread 1-2) Preventing install of default bean Producer Method [EmbeddedCacheManager] with qualifiers [@Any @Synthetic] declared as [[method] @Produces @ApplicationScoped @DefaultBean public org.infinispan.cdi.DefaultEmbeddedCacheManagerProducer.getDefaultEmbeddedCacheManager(Instance<EmbeddedCacheManager>, Configuration)]
16:46:06,767 INFO [org.infinispan.factories.GlobalComponentRegistry] (CacheStartThread,ISPN,cache1) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.2.FINAL
16:46:06,892 INFO [stdout] (MSC service thread 1-3) VALUE_1
16:46:07,173 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "TestJEE-ear-1.0-SNAPSHOT.ear"

2 The sample ear built using Infinispan 5.2.1.Final can also be deployed and ran on JBOSS 7.1.1.Final.

16:59:45,569 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016005: Starting Services for CDI deployment: TestJEE-ear-1.0-SNAPSHOT.ear
16:59:45,569 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016008: Starting weld service for deployment TestJEE-ear-1.0-SNAPSHOT.ear
16:59:45,616 INFO [org.infinispan.cdi.InfinispanExtension] (MSC service thread 1-1) ISPN017001: Infinispan CDI extension version: 5.2.1.Final
16:59:45,616 INFO [org.jboss.solder.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-1) Solder Config XML provider starting...
16:59:45,616 INFO [org.jboss.solder.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-1) Loading XmlDocumentProvider: org.jboss.solder.config.xml.bootstrap.ResourceLoaderXmlDocumentProvider
16:59:45,631 INFO [org.jboss.solder.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-1) Reading XML file: vfs:/D:/20130125/jboss-as-7.1.1.Final/bin/content/TestJEE-ear-1.0-SNAPSHOT.ear/lib/infinispan-cdi-5.2.1.Final.jar/META-INF/beans.xml
16:59:45,631 INFO [org.jboss.solder.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-1) Reading XML file: vfs:/D:/20130125/jboss-as-7.1.1.Final/bin/content/TestJEE-ear-1.0-SNAPSHOT.ear/TestJEE-ejb-1.0-SNAPSHOT.jar/META-INF/beans.xml
16:59:45,631 INFO [org.jboss.solder.Version] (MSC service thread 1-1) Solder 3.1.0.Final (build id: 3.1.0.Final)
16:59:46,194 INFO [org.jboss.solder.bean.defaultbean.DefaultBeanExtension] (MSC service thread 1-1) Preventing install of default bean Producer Method [EmbeddedCacheManager] with qualifiers [@Any @Synthetic] declared as [[method] @Produces @ApplicationScoped @DefaultBean public org.infinispan.cdi.DefaultEmbeddedCacheManagerProducer.getDefaultEmbeddedCacheManager(Instance<EmbeddedCacheManager>, Configuration)]
16:59:46,381 INFO [org.infinispan.factories.GlobalComponentRegistry] (CacheStartThread,null,cache2) ISPN000128: Infinispan version: Infinispan 'Delirium' 5.2.1.Final
16:59:46,756 INFO [org.infinispan.jmx.CacheJmxRegistration] (CacheStartThread,null,cache2) ISPN000031: MBeans were successfully registered to the platform MBean server.
16:59:46,756 INFO [org.infinispan.jmx.CacheJmxRegistration] (CacheStartThread,null,cache1) ISPN000031: MBeans were successfully registered to the platform MBean server.
16:59:46,756 INFO [stdout] (MSC service thread 1-1) VALUE_1
16:59:46,850 INFO [org.jboss.as.server] (management-handler-thread - 10) JBAS018559: Deployed "TestJEE-ear-1.0-SNAPSHOT.ear"

So, from the point of view, I guess that there must be something wrong while using gf and infinispan and should be unrelated to jboss weld version's change.

I think that deep investigation should start from gf 3.1.2.2, and once knowing the true reason, I will come back v4.

Comment by TangYong [ 01/Apr/13 ]

The WELD-001408 exception is thrown because an inject point of
AdvancedCacheProducer class has not been resolved. The
AdvancedCacheProducer class is in infinispan-core.jar.

The sample ear has the following structure,

--lib
├infinispan-core-5.2.1.Final.jar
├infinispan-cdi-5.2.1.Final.jar
...
--META-INF
├application.xml
├MANIFEST.MF
--TestJEE-ejb-1.0-SNAPSHOT.jar( beans.xml is included in the ejb jar)

I doubted that the jar contents of lib can not be
scanned by weld because of the above structure. (--> confirming with JJ)

Comment by TangYong [ 02/Apr/13 ]

(discussion between JJ and I)

> When you get back see if you can find the source code for
> > org.infinispan.cdi.AdvancedCacheProducer. I can't find it in the jar
> > with the jira nor in the location below.

AdvancedCacheProducer is in
http://repo1.maven.org/maven2/org/infinispan/infinispan-cdi/5.2.1.Final/infinispan-cdi-5.2.1.Final-sources.jar

It has an inject point called "defaultCacheContainer" as following:

@Inject
private CacheContainer defaultCacheContainer;

CacheContainer is an interface and its some implementations are
http://repo1.maven.org/maven2/org/infinispan/infinispan-core/5.2.1.Final/infinispan-core-5.2.1.Final-sources.jar,

eg. org.infinispan.manager.DefaultCacheManager is a defalt CacheManager.

OK, let us back the issue. Now, infinispan-cdi-5.2.1.Final and
infinispan-core-5.2.1.Final are all as ear lib jars and Noticing the
following,

1)infinispan-cdi-5.2.1.Final has a beans.xml file
2)infinispan-core-5.2.1.Final has not any beans.xml file

So, whether classes in infinispan-core-5.2.1.Final can not be scanned as
Beans or not?

If being such a case, we should find true reason and can feature a
general scene.

-Tang

Comment by TangYong [ 02/Apr/13 ]

NO, The above guess is not reasonable, because I made an experiment and
put beans.xml into infinispan-core-5.2.1.Final, result is that I got the
following exception:

"
WELD-001409 Ambiguous dependencies for type [EmbeddedCacheManager] with
qualifiers [@Default] at injection point [[field] @Inject private
com.mycompany.CacheBean.defaultCacheManager]. Possible dependencies
[[Producer Method [EmbeddedCacheManager] with qualifiers [@Any @Default]
declared as [[method] @Produces @ApplicationScoped public
com.mycompany.Config.defaultEmbeddedCacheManager()], Managed Bean [class
org.infinispan.manager.DefaultCacheManager] with qualifiers [@Any
@Default]]]"

My analyse is as following:
The sample has a produce method called
com.mycompany.defaultEmbeddedCacheManager() to create a
EmbeddedCacheManager which implements CacheContainer. while I added
beans.xml into infinispan-core-5.2.1.Final,
org.infinispan.manager.DefaultCacheManager is also scanned as
EmbeddedCacheManager's injectee. So, WELD-001409 Ambiguous will happen.

Based on the above experiment and analyse,

While deploying the sample ear into gf and scanning org.infinispan.cdi.AdvancedCacheProducer,
because the following injection point can not be satisfied,

@Inject
private CacheContainer defaultCacheContainer;

WELD-001408 happened.

CacheContainer's implementation comes from infinispan-core and it can not be built as bean archieve(it can not be also as bean archieve!)
Instead, The sample ear has a produce method called com.mycompany.defaultEmbeddedCacheManager() to create a EmbeddedCacheManager which implements CacheContainer.

Deeply, while deploying an app with beans.xml into gf, gf will scan and validate all artifacts with beans.xml (including CDI extensions), so, infinispan-cdi is scanned. However, while validating these cdi extensions, in this scene, WELD-001408 happened.

Comment by TangYong [ 02/Apr/13 ]

I have made an experiment(a general scene, sample has been sent into JJ) and confirmed that the same issue happened.

[Reason]
classes in ear's /lib jars with beans.xml can not resolve beans from ear's ejb jar(maybe war is the same as ejb).

[Conclusion]
This is not related to Infinispan-CDI and Infinispan-Core and should be gf weld integration issue while handling JavaEE EAR deployment.

I have asked JJ to judge whether the issue is bug. If being a bug, I think that this bug should be very important.

Thanks
--Tang Yong

Comment by jjsnyder83 [ 02/Apr/13 ]

This is a class visibility issue. Classes in a library do not have visibility into classes in ejb modules. Therefore beans that reside in ejb modules cannot be injected into beans that reside in ear libraries.

Comment by kovica [ 03/Apr/13 ]

Maybe this is "Works as designed", but why is the application working if I change the Infinispan version to 5.0.1?
What should the structure of the EAR file be then?

Comment by TangYong [ 03/Apr/13 ]

Do you confirm the app can work while changing the 5.0.1?

After I changed the app using 5.0.1.FINAL, although WELD-001408 disappeared, the following exception happened,

WELD-001409 Ambiguous dependencies for type [EmbeddedCacheManager] with qualifiers [@Default] at injection point [[field] @Inject private com.mycompany.CacheBean.defaultCacheManager]. Possible dependencies [[Producer Method [EmbeddedCacheManager] with qualifiers [@Any @Default] declared as [[method] @Produces @ApplicationScoped public com.mycompany.Config.defaultEmbeddedCacheManager()], Producer Method [EmbeddedCacheManager] with qualifiers [@Any @Default] declared as [[method] @Produces @Default @ApplicationScoped public org.infinispan.cdi.DefaultCacheManagerProducer.getDefaultCacheManager(Instance<EmbeddedCacheManager>, Configuration)]]].

However, I am also curious why WELD-001408 disappeared.

Comment by TangYong [ 03/Apr/13 ]

Kovica,

I looked infinispan cdi 5.0.1 source and WELD-001408's disappear is normal and right, because org.infinispan.cdi.DefaultCacheManagerProducer has not any inject point and only produce method, so, for DefaultCacheManagerProducer class, WELD-001408 does not happen, however, because having producing method, this will conflict with ear's sample's produce method.

Must notice that the WELD-001409 happened while ejb accessed ear's lib jar rather than lib's jar accesses ejb. This is not different from the original scene.

For glassfish, accessing ear's lib from ejb is allowed.

So, JJ's comment can be understood.

Thanks
--Tang Yong

Comment by kovica [ 03/Apr/13 ]

OK, I understand.
Since this is applciation made by NetBeans using maven based JEE project, how should I change it to make the application work?

Comment by TangYong [ 03/Apr/13 ]

In addition, I also found that maybe we will still meet WELD-001409 even if I resolved WELD-001408 by re-adjusting ear's structure. Why?

If you looked into infinispan-cdi-5.2.1.Final source, you will see DefaultEmbeddedCacheManagerProducer class is still there, thus, while injecting EmbeddedCacheManager for com.mycompany.CacheBean.defaultCacheManager, maybe conflict will happen again.

Comment by TangYong [ 03/Apr/13 ]

A way is that putting infinispan related jars including dependencies into ejb as ejb class path, then, deploying the ear into glassfish. Just as I said above, I worry about WELD-001409, and once this happened, we will discuss again, however, because WELD-001409's scene has been out of the scope of this jira issue, so , please communicate with me by my email(tangyong@cn.fujitsu.com).

BTW: fixing WELD-001409 can use a customized @Qualifier to qualify your produce method, and use the customized @Qualifier into your sample's injection point.

Thanks
--Tang





[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-18370] OSGi Services injected with CDI have their exceptions wrapped.. Created: 15/Feb/12  Updated: 22/Oct/12  Resolved: 22/Oct/12

Status: Resolved
Project: glassfish
Component/s: cdi, OSGi, OSGi-JavaEE
Affects Version/s: 3.1.2_b21
Fix Version/s: 4.0

Type: Bug Priority: Critical
Reporter: aaronjwhiteside Assignee: Sanjeeb Sahoo
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive glassfish-18370-test.zip     Java Source File OSGiServiceFactory.java     Text File OSGiServiceFactory.patch    
Tags: 3_1_2-exclude, 3_1_2-next

 Description   

When injecting an OSGi Service with methods that declare they throw exceptions.

The CDI wrapper does not unwrap them before throwing them back up.

In org.glassfish.osgicdi.impl.OSGiServiceFactory$DynamicInvocationHandler.invoke()

line 185: return method.invoke(instanceToUse, args);

should really be something like..

try { 
   return method.invoke(instanceToUse, args);
} catch ( final InvocationTargetException e ) {
   throw e.getCause();
}

Might want to check for getCause() == null too, but you get the idea..

[#|2012-02-14T18:57:23.082-0500|SEVERE|glassfish3.1.2|com.sun.jersey.spi.container.ContainerResponse|_ThreadID=174;_ThreadName=Thread-2;|Mapped exception to response: 500 (Internal Server Error)
javax.ws.rs.WebApplicationException: java.lang.reflect.UndeclaredThrowableException
	at com.mm.ws.optin.OptInResource.initiate(OptInResource.java:90)
	at com.mm.ws.optin.OptInResource$Proxy$_$$_WeldClientProxy.initiate(OptInResource$Proxy$_$$_WeldClientProxy.java)
	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 com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
	at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
	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.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.spi.container.servlet.WebComponent.service(WebComponent.java:416)
	at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:537)
	at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:708)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1542)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174)
	at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
	at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
	at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
	at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
	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:722)
Caused by: java.lang.reflect.UndeclaredThrowableException
	at $Proxy217.initiateOptIn(Unknown Source)
	at com.mm.ws.optin.OptInResource.initiate(OptInResource.java:55)
	... 44 more
Caused by: java.lang.reflect.InvocationTargetException
	at sun.reflect.GeneratedMethodAccessor614.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.glassfish.osgicdi.impl.OSGiServiceFactory$DynamicInvocationHandler.invoke(OSGiServiceFactory.java:234)
	... 46 more
Caused by: com.mm.service.optin.InvalidCampaignIdentifierException: campaignIdentifier cannot be empty or null
	at com.mm.service.optin.impl.OptInServiceImpl.initiateOptIn(OptInServiceImpl.java:63)
	at sun.reflect.GeneratedMethodAccessor614.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
	at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
	at $Proxy216.initiateOptIn(Unknown Source)
	... 50 more



 Comments   
Comment by Joe Di Pol [ 17/Feb/12 ]

Too late to fix in 3.1.2. Tagging for consideration in next release.

Comment by TangYong [ 20/Jul/12 ]

I made a revise and have request sahoo to review it.
BTW: besides OSGiServiceFactory$DynamicInvocationHandler.invoke,
OSGiServiceFactory$StaticInvocationHandler.invoke
method should be also revised when not using "dynamic = true".

Comment by TangYong [ 10/Aug/12 ]

Tang Yong said:

I have finished the investigation and made a revise which is on

https://github.com/tangyong/GLASSFISH-18370.

I modifed the stockquote-cdi-osgi-sample and can trigger the
UndeclaredThrowableException, you can get the sample from the above
github url.

Just as aaronjwhiteside said: we really need to get the cause of
InvocationTargetException, otherwise, once InvocationTargetException
happened, UndeclaredThrowableException will be thrown by a method
invocation on a proxy instance[1].

[1]: About "UndeclaredThrowableException"
http://docs.oracle.com/javase/6/docs/api/java/lang/reflect/UndeclaredThrowableException.html

In addition, besides org.glassfish.osgicdi.impl.OSGiServiceFactory$DynamicInvocationHandler.invoke method,
org.glassfish.osgicdi.impl.OSGiServiceFactory$StaticInvocationHandler.invoke method should be also revised
when not using "dynamic = true".

Comment by TangYong [ 10/Aug/12 ]

Sahoo Said:

Your change looks good to me. Let's wait for Siva to review as well.
Siva had earlier mentioned that he would get back with his review
comments by beginning of coming week, so give him time.

Comment by TangYong [ 12/Oct/12 ]

Hi siva,

I have uploaded path of the issue and want to ask you confirm it.

Comment by Sivakumar Thyagarajan [ 15/Oct/12 ]

This patch looks good to me too. I will commit this changes soon and update this issue.

Comment by Sanjeeb Sahoo [ 16/Oct/12 ]

Tang,

When you have time, please submit add a test case for this in FighterFish test suite [1]?

Thanks,
Sahoo

[1] https://wikis.oracle.com/pages/viewpage.action?pageId=36438159

Comment by TangYong [ 19/Oct/12 ]

Hi sahoo, siva,

Please see attachment and I have added a test case for the issue and ran successuflly.

Comment by Sanjeeb Sahoo [ 22/Oct/12 ]

I am applying the patch.

Comment by Sanjeeb Sahoo [ 22/Oct/12 ]

Applying patch supplied by Tang Yong.
Sending module/osgi-cdi/src/main/java/org/glassfish/osgicdi/impl/OSGiServiceFactory.java
Sending test/it/ExpectedTestResult.txt
Sending test/it/src/test/java/org/glassfish/fighterfish/test/it/T2_Test.java
Sending test/testapp/pom.xml
Adding test/testapp/test.app20
Adding test/testapp/test.app20/README.xml
Adding test/testapp/test.app20/osgi.properties
Adding test/testapp/test.app20/pom.xml
Adding test/testapp/test.app20/src
Adding test/testapp/test.app20/src/main
Adding test/testapp/test.app20/src/main/java
Adding test/testapp/test.app20/src/main/java/org
Adding test/testapp/test.app20/src/main/java/org/glassfish
Adding test/testapp/test.app20/src/main/java/org/glassfish/fighterfish
Adding test/testapp/test.app20/src/main/java/org/glassfish/fighterfish/test
Adding test/testapp/test.app20/src/main/java/org/glassfish/fighterfish/test/app20
Adding test/testapp/test.app20/src/main/java/org/glassfish/fighterfish/test/app20/SimpleServiceActivator.java
Adding test/testapp/test.app20/src/main/java/org/glassfish/fighterfish/test/app20/SimpleStockQuoteServiceImpl.java
Adding test/testapp/test.app20/src/main/java/org/glassfish/fighterfish/test/app20/StockQuoteService.java
Adding test/testapp/test.app20/src/main/java/org/glassfish/fighterfish/test/app20/StockQuoteServlet.java
Adding test/testapp/test.app20/src/main/webapp
Adding test/testapp/test.app20/src/main/webapp/WEB-INF
Adding test/testapp/test.app20/src/main/webapp/WEB-INF/beans.xml
Adding test/testapp/test.app20/src/test
Adding test/testapp/test.app20/src/test/java
Adding test/testapp/test.app20/src/test/java/org
Adding test/testapp/test.app20/src/test/java/org/glassfish
Adding test/testapp/test.app20/src/test/java/org/glassfish/fighterfish
Adding test/testapp/test.app20/src/test/java/org/glassfish/fighterfish/test
Adding test/testapp/test.app20/src/test/java/org/glassfish/fighterfish/test/app20
Transmitting file data ............
Committed revision 56653.





[GLASSFISH-18369] weld dependencies are part of distribution Created: 15/Feb/12  Updated: 01/Mar/13  Resolved: 01/Mar/13

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

Type: Bug Priority: Critical
Reporter: Sanjeeb Sahoo Assignee: jitu
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In trunk build, I am seeing various weld dependencies being part of distribution when they should not be. e.g.,
slf4-*.jar
cal10n-api.jar

and may be others?

This will cause all kinds of classloading issues as users won't be able to use different versions of these jars in their application. So, they must be removed from distribution.



 Comments   
Comment by Sivakumar Thyagarajan [ 15/Feb/12 ]

It appears that the glassfish-web packager zip brings in slf4j and cal10n, because of maven dependencies of webtier-all. This may need to be fixed.

[ ../packager/glassfish-web] $ unzip -l target/glassfish-web.zip | grep "cal10n|slf"
28866 2012-02-15 21:26 glassfish3/glassfish/modules/cal10n-api.jar
23659 2012-02-15 21:26 glassfish3/glassfish/modules/slf4j-api.jar
41626 2012-02-15 21:26 glassfish3/glassfish/modules/slf4j-ext.jar

Transferring this issue to Shingwai

Comment by Sivakumar Thyagarajan [ 15/Feb/12 ]

Shingwai, please let me know if there is anyway we can help. It appears that glassfish-web packager brings in weld osgi impl's dependencies such as cal10n, sfl4j.

Comment by Shing Wai Chan [ 07/Mar/12 ]

The slf4j-api, slf4j-ext and cal10n-api are bring it by org.jboss.weld:weld-core:jar:1.1.4.Final:compile which is bring it by org.glassfish.web:web-sse:jar:4.0-SNAPSHOT:compile

Comment by Sanjeeb Sahoo [ 02/Apr/12 ]

Jitu,

Can this bug be fixed by depending on javax.inject/javax.inject/1 instead of weld-osgi? More over, mark the dependency a provided scope dependency so that it does not get pulled in to the distribution. Could you do it ASAP?

Thanks,
Sahoo

Comment by jitu [ 02/Apr/12 ]

If I do the following changes in web-sse/pom.xml, running into an exception. May be HK2 maven plugin needs an update.

<dependency>

  • <groupId>org.jboss.weld</groupId>
  • <artifactId>weld-osgi-bundle</artifactId>
    + <groupId>javax.inject</groupId>
    + <artifactId>javax.inject</artifactId>
    + <version>1</version>
    + <scope>provided</scope>
    </dependency>

---------
java.lang.ClassCastException: com.sun.tools.apt.mirror.type.ClassTypeImpl cannot be cast to com.sun.mirror.type.AnnotationType
at com.sun.tools.apt.mirror.declaration.AnnotationMirrorImpl.getAnnotationType(AnnotationMirrorImpl.java:82)
at com.sun.tools.apt.mirror.apt.AnnotationProcessorEnvironmentImpl$CollectingAP$CollectingVisitor.visitDeclaration(AnnotationProcessorEnvironmentImpl.java:118)
at com.sun.mirror.util.SimpleDeclarationVisitor.visitParameterDeclaration(SimpleDeclarationVisitor.java:181)
at com.sun.tools.apt.mirror.declaration.ParameterDeclarationImpl.accept(ParameterDeclarationImpl.java:80)
at com.sun.mirror.util.DeclarationScanner.visitDeclaration(DeclarationScanner.java:45)
at com.sun.mirror.util.DeclarationScanner.visitParameterDeclaration(DeclarationScanner.java:233)
at com.sun.tools.apt.mirror.declaration.ParameterDeclarationImpl.accept(ParameterDeclarationImpl.java:80)
at com.sun.mirror.util.SourceOrderDeclScanner.visitExecutableDeclaration(SourceOrderDeclScanner.java:225)
at com.sun.mirror.util.DeclarationScanner.visitMethodDeclaration(DeclarationScanner.java:214)
at com.sun.tools.apt.mirror.declaration.MethodDeclarationImpl.accept(MethodDeclarationImpl.java:41)
at com.sun.mirror.util.SourceOrderDeclScanner.visitClassDeclaration(SourceOrderDeclScanner.java:207)
at com.sun.tools.apt.mirror.declaration.ClassDeclarationImpl.accept(ClassDeclarationImpl.java:95)
at com.sun.tools.apt.mirror.apt.AnnotationProcessorEnvironmentImpl$CollectingAP.process(AnnotationProcessorEnvironmentImpl.java:126)
at com.sun.tools.apt.mirror.apt.AnnotationProcessorEnvironmentImpl.getDeclarationsAnnotatedWith(AnnotationProcessorEnvironmentImpl.java:100)
at org.jvnet.hk2.config.generator.ConfigInjectorGenerator.process(ConfigInjectorGenerator.java:122)
at com.sun.mirror.apt.AnnotationProcessors$CompositeAnnotationProcessor.process(AnnotationProcessors.java:60)
at com.sun.mirror.apt.AnnotationProcessors$CompositeAnnotationProcessor.process(AnnotationProcessors.java:60)
at com.sun.tools.apt.comp.Apt.main(Apt.java:454)
at com.sun.tools.apt.main.JavaCompiler.compile(JavaCompiler.java:258)
at com.sun.tools.apt.main.Main.compile(Main.java:1102)
at com.sun.tools.apt.main.Main.compile(Main.java:964)
at com.sun.tools.apt.Main.processing(Main.java:95)
at com.sun.tools.apt.Main.process(Main.java:85)
at com.sun.enterprise.module.maven.HK2CompileMojo$1.compileInProcess(HK2CompileMojo.java:126)
at com.sun.enterprise.module.maven.AptCompiler.compile(AptCompiler.java:106)
at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:528)
at com.sun.enterprise.module.maven.CompilerMojo.execute(CompilerMojo.java:155)
at com.sun.enterprise.module.maven.HK2CompileMojo.execute(HK2CompileMojo.java:140)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

Comment by Sanjeeb Sahoo [ 03/Apr/12 ]

I think this is happening because hk2 also depends on javax.inject. This is a guess only. If you don't want to spend a lot of time, then you could try changing the existing weld-osgi-bundle dependency to a provided scope dependency so that's its transitive dependencies are not pulled in by the build.

Comment by jitu [ 03/Apr/12 ]

weld-osgi-bundle artifact is marked with provided scope
---------------
main/appserver/web/web-sse$ svn ci pom.xml
Sending pom.xml
Transmitting file data .
Committed revision 53341.
----------------

Comment by jthoennes [ 04/Apr/12 ]

In reply to comment #6:
> I think this is happening because hk2 also depends on javax.inject. This is a
> guess only. If you don't want to spend a lot of time, then you could try
> changing the existing weld-osgi-bundle dependency to a provided scope dependency
> so that's its transitive dependencies are not pulled in by the build.

Sahoo, please could you elaborate on this? We are also struck by this issue.

And: Will this be corrected for at least GF 4.0?

Thanks, Jörg

Comment by Sanjeeb Sahoo [ 07/Apr/12 ]

Jörg, pl file a separate bug for the hk2 plugin issue against HK2 project to get a faster response from the relevant developers.

Comment by Sanjeeb Sahoo [ 07/Apr/12 ]

jitu, why is this bug still open?

Comment by jitu [ 08/Apr/12 ]

Will close the issue if there aren't any comments.





[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-18152] java.lang.ClassNotFoundException when deploying CDI-enabled EAR application Created: 08/Jan/12  Updated: 06/Oct/12  Resolved: 06/Oct/12

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.1
Fix Version/s: 3.1.2, 4.0

Type: Bug Priority: Major
Reporter: titmus Assignee: jjsnyder83
Resolution: Fixed Votes: 2
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 GLASSFISH-18028.patch     Text File server.log    
Tags: 3_1_2-exclude, weld-int-required

 Description   

I've got following exception while deploying attached application:

org.jboss.weld.exceptions.WeldException: by java.lang.NoClassDefFoundError: test/war1/Ejb
at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:259)
at org.jboss.weld.bean.AbstractClassBean.createEnhancedSubclass(AbstractClassBean.java:673)
at org.jboss.weld.bean.AbstractClassBean.initEnhancedSubclass(AbstractClassBean.java:659)
at org.jboss.weld.bean.AbstractClassBean.initializeAfterBeanDiscovery(AbstractClassBean.java:354)
at org.jboss.weld.bootstrap.BeanDeployment.doAfterBeanDiscovery(BeanDeployment.java:232)
at org.jboss.weld.bootstrap.BeanDeployment.afterBeanDiscovery(BeanDeployment.java:221)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:375)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:170)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:270)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java: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)
Caused by: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: test/war1/Ejb
at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:117)
at org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:374)
at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:255)
... 60 more
Caused by: java.lang.NoClassDefFoundError: test/war1/Ejb
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:143)
at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:109)
... 62 more
Caused by: java.lang.ClassNotFoundException: test.war1.Ejb
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1519)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1369)
... 70 more

It happens when there are several CDI-enabled modules within EAR and one of them has EJB with an interceptor. When the interceptor is removed tha application deploys correctly.
I've attached sample application (EAR), server log and maven project used to create the application.



 Comments   
Comment by Hong Zhang [ 09/Jan/12 ]

assign to cdi team for initial evaluation

Comment by titmus [ 17/Jan/12 ]

The issue seems to be caused by the fact that ProxyServices used by weld to obtain a class loader for proxied classes is only passed the class which is not sufficient in applications using multiple different class loaders (like an EAR application) - it is somewhat related to https://issues.jboss.org/browse/WELD-781
The current implemetnation of ProxyServices (the class org.glassfish.weld.services.ProxyServicesImpl in weld-intergration module) always returns current thread context class loader.
The BeanDeploymentArchiveImpl class has workaround for bug WELD-781 but it is only working while calling deployBeans method on BeanDeployment. It sets TCCL to class loader correct for currently deployed archive and after that TCCL is set to class loader of whichever archive was deployed last and is used by ProxyServices when afterBeanDiscovery method is called on BeanDeployment.
In this situation TCCL is set to war2 class loader and therefore class test.war1.Ejb could not be found beacuse it is located in war1.
To correctly handle this situation weld should provide information about bean''s deployment archive to the ProxyServices.

I created a workaround for this. I register appropriate class loaders for discovered beans classess in ProxyServicesImpl which are then returned to the Weld. Because classes are matched by name it would not correctly handle situation when classes with the same package and name are located in different deployment archives (but it is not handled correctly by GlassFish anyway - see GLASSFISH-18204).
A patch implementing the workaround is attached as GLASSFISH-18028.patch

Comment by Sivakumar Thyagarajan [ 19/Jan/12 ]

Thanks for your detailed evaluation notes. As you rightly point out, the correct fix for this issue is through a fix for WELD-781 and having the Weld integration SPI provide the bean's deployment archive while trying to load a Proxy. We are working with the Weld team to get this integration SPI and hence I would like to wait for that. As you said the proposed patch is also a workaround and wouldn't for all cases. The patch also appears to use reflection to obtain the bean deployments and that may not be stable as it is not part of the Weld integration SPI. I will track WELD-781 and would request it to be included in the Weld 1.2.0 timeline.

Comment by jjsnyder83 [ 06/Oct/12 ]

I have tested this with the latest integrations with Weld and the application deploys successfully.





[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.





Clean up connector modules of various modules (GLASSFISH-17656)

[GLASSFISH-17890] separate weld sniffers to weld connector Created: 02/Dec/11  Updated: 02/Dec/11  Resolved: 02/Dec/11

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

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

Tags: 3_1_2-exclude, spo

 Description   

Currently weld sniffers are part of weld-integration-jar and when sniffers are loaded at startup, that causes resolution of a whole bunch of dependencies.



 Comments   
Comment by Sanjeeb Sahoo [ 02/Dec/11 ]

Introduced a new module called gf-weld-connector in svn rev #51256.





[GLASSFISH-17464] WELD-001508 is not handled correctly Created: 24/Oct/11  Updated: 12/Dec/11  Resolved: 12/Dec/11

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.1_b09, 3.1.1_b10, 3.1.1_b11, 3.1.1_b12, 3.1.1
Fix Version/s: 3.1.2_b14, 4.0

Type: Bug Priority: Major
Reporter: Bas van Gils Assignee: kshitiz_saxena
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 x64


Tags: 3_1_2-review, jms, weld, weld-integration

 Description   

I have an EAR that deploys without problems in GF 3.0.1. Now that we want to upgrade to GF 3.1.1 we are testing our apps on GF 3.1.1.
One specific app doesn't deploy, it fails with the messages in server.log listed below. No clue whatsoever.

SEVERE: Exception while loading the app

SEVERE: Exception while shutting down application container
SEVERE: Exception while shutting down application container
SEVERE: Exception while shutting down application container
SEVERE: Exception while shutting down application container
INFO: No timers to be deleted for id: 86444029077618688
INFO: No timers to be deleted for id: 86444029077618688
INFO: No timers to be deleted for id: 86444029077618688
SEVERE: Exception while shutting down application container : java.lang.NullPointerException</code>

After many trail and error sessions, I finally found that my EAR deploys on GF 3.1.1-b08 but not on GF 3.1.1-b09. So I looked up the differences in svn and after some testing I found that a change in class org.glassfish.weld.WeldDeployer is responsible for the failed deploy:

http://java.net/projects/glassfish/sources/svn/revision/47614

GLASSFISH-16730: The weld-integration module wasn't firing ProcessInjectionTargetEvents to MessageDriven Beans. So, reference to Beans that are injected through Portable Extensions weren't satisfied as the Extension wasn't receiving ProcessInjectionTarget Events for MDBs. Support for JMS message listeners is added

After adding a try/catch + exception log in method WeldDeployer.firePITEvent(), the following error is shown

WELD-001508 Cannot create an InjectionTarget from public abstract interface class <MyInterface> as it is an interface|#]

To my basic Weld knowledge, the error seems perfectly legal since it's trying to handle an interface class.

I have two issues:

  • this error should be logged in server.log
  • interfaces that extend javax.jms.MessageListener should not be given to Weld in this case


 Comments   
Comment by Bas van Gils [ 09/Dec/11 ]

Any idea if a fix will be included in 3.1.2?

Comment by Sivakumar Thyagarajan [ 09/Dec/11 ]

dj_canard: Yes, we are working on a fix for this issue for 3.1.2.

Comment by Sivakumar Thyagarajan [ 09/Dec/11 ]

Request Kshitiz to handle this issue in 3.1.2 and trunk.

Comment by kshitiz_saxena [ 12/Dec/11 ]

Now in firePITEvent method, it is checked whether BDA(Bean Deployment Archive) class is a interface. If it is a interface, then PIT event is not fired.

checkin logs :
Sending weld-integration/src/main/java/org/glassfish/weld/WeldDeployer.java
Transmitting file data .
Committed revision 51474.

For logging, I found following SEVERE message is logged in server logs which in my view is sufficient
[#|2011-12-12T17:15:07.707+0530|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=19;_ThreadName=Thread-2;|Exception while loading the app : WELD-001508 Cannot create an InjectionTarget from public abstract interface class com.sun.s1asdev.cdi.hello.mdb.MyMessageListener as it is an interface
org.jboss.weld.exceptions.DefinitionException: WELD-001508 Cannot create an InjectionTarget from public abstract interface class com.sun.s1asdev.cdi.hello.mdb.MyMessageListener as it is an interface
at org.jboss.weld.manager.SimpleInjectionTarget.<init>(SimpleInjectionTarget.java:65)
at org.jboss.weld.manager.BeanManagerImpl.createInjectionTarget(BeanManagerImpl.java:906)
at org.jboss.weld.manager.BeanManagerImpl.fireProcessInjectionTarget(BeanManagerImpl.java:1055)
at org.glassfish.weld.WeldDeployer.firePITEvent(WeldDeployer.java:303)
at org.glassfish.weld.WeldDeployer.fireProcessInjectionTargetEvents(WeldDeployer.java:293)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:178)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:277)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:461)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
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:849)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
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:680)

#]

Probably it is fixed in latest weld integration





[GLASSFISH-17215] "Context is already active" for jsf view with prettyfaces Created: 21/Aug/11  Updated: 28/Mar/13  Resolved: 28/Mar/13

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

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

windows java 6 every version of glashfish


Attachments: File EnterpriseTestApplication1.rar    
Tags: 3_1_2-exclude

 Description   

When calling url http://localhost:8080/WebApplication1/faces/testAdmin?testid=90 with prettyfaces

Cause the next exception:

java.lang.IllegalStateException: Context is already active
at org.jboss.weld.context.AbstractConversationContext.activate(AbstractConversationContext.java:311)
at org.jboss.weld.jsf.WeldPhaseListener.activateConversations(WeldPhaseListener.java:110)
at org.jboss.weld.jsf.WeldPhaseListener.beforePhase(WeldPhaseListener.java:84)
at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:393)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:118)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:785)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:649)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:483)
at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:454)
at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:350)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:300)
at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:110)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:785)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:649)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:483)
at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:454)
at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:350)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:300)
at com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:546)
at com.sun.faces.application.view.JspViewHandlingStrategy.executePageToBuildView(JspViewHandlingStrategy.java:364)
at com.sun.faces.application.view.JspViewHandlingStrategy.buildView(JspViewHandlingStrategy.java:154)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:393)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:118)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:330)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174)
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 meirka5 [ 21/Aug/11 ]

http://localhost:8080/WebApplication1/faces/electAdmin?testid=90

for cause the exception

Comment by rogerk [ 18/Oct/11 ]

Assigning to cdi team for investigation..

Comment by Sivakumar Thyagarajan [ 10/Dec/11 ]

I get the following erros while trying to access the above URL. Transferring to the JSF team for investigation.

meirka5: could you please provide the project's sources as well?

[#|2011-12-10T22:53:24.763+0530|INFO|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=17;_ThreadName=Thread-2;|WEB0671: Loading application EnterpriseTestApplication1#WebApplication1.war at [WebApplication1]|#]

[#|2011-12-10T22:53:25.057+0530|INFO|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=17;_ThreadName=Thread-2;|EnterpriseTestApplication1 was successfully deployed in 5,172 milliseconds.|#]

[#|2011-12-10T22:54:25.226+0530|WARNING|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=18;_ThreadName=Thread-2;|StandardWrapperValve[Faces Servlet]: PWC1406: Servlet.service() for servlet Faces Servlet threw exception
java.lang.NullPointerException
at com.sun.faces.context.flash.ELFlash.loggingGetPhaseMapForReading(ELFlash.java:793)
at com.sun.faces.context.flash.ELFlash.getPhaseMapForReading(ELFlash.java:826)
at com.sun.faces.context.flash.ELFlash.isEmpty(ELFlash.java:484)
at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:325)
at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:215)
at com.sun.faces.facelets.util.DevTools.debugHtml(DevTools.java:130)
at com.sun.faces.renderkit.RenderKitUtils.renderHtmlErrorPage(RenderKitUtils.java:1162)
at com.sun.faces.context.ExceptionHandlerImpl.throwIt(ExceptionHandlerImpl.java:276)
at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:142)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1542)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:118)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]
Comment by rogerk [ 11/Dec/11 ]

Risk factor this late in the release.

Comment by rogerk [ 27/Mar/13 ]

This is an old issue that appears to be a Weld issue. However, I will try this with GlassFish 4
and update the status accordingly.

Comment by rogerk [ 28/Mar/13 ]

Assign to cdi team. This is an older issue that I believe has to be rewritten by the reporter for Glassfish4.

Comment by rogerk [ 28/Mar/13 ]

Can you provide another app that is more recent and packaged differently?





[GLASSFISH-17157] NullPointerException in BeanDeploymentArchiveImpl if CDI beans.xml is not in a WAR's WEB-INF Created: 07/Aug/11  Updated: 05/Oct/12  Resolved: 05/Oct/12

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

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


 Description   

When someone accidently puts beans.xml into a place inside a WAR file that is not accessible to the WebappClassloader (e.g. outside of /WEB-INF), it is found in the ReadableArchive but cannot be loaded via getResource().

java.lang.NullPointerException
at org.glassfish.weld.BeanDeploymentArchiveImpl.handleEntry(BeanDeploymentArchiveImpl.java:504)
at org.glassfish.weld.BeanDeploymentArchiveImpl.collectJarInfo(BeanDeploymentArchiveImpl.java:482)
at org.glassfish.weld.BeanDeploymentArchiveImpl.populate(BeanDeploymentArchiveImpl.java:422)
at org.glassfish.weld.BeanDeploymentArchiveImpl.<init>(BeanDeploymentArchiveImpl.java:148)
at org.glassfish.weld.BeanDeploymentArchiveImpl.<init>(BeanDeploymentArchiveImpl.java:128)
at org.glassfish.weld.DeploymentImpl.<init>(DeploymentImpl.java:120)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:372)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:99)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:257)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:382)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:360)
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 org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:145)
at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:575)
at org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:461)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:389)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:380)
at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:209)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)

The relevant code is:

try {
    URL beansXmlUrl = Thread.currentThread().getContextClassLoader().getResource(entry);
    wUris.add(beansXmlUrl.toURI());
} catch (URISyntaxException use) {
    logger.log(Level.WARNING, "Error handling beans.xml at " + entry, use);
}

Please add a null check and a descriptive log message...

BTW: I am no expert, but shouldn't you use getClassLoader() here instead of Thread.currentThread().getContextClassLoader()?



 Comments   
Comment by jjsnyder83 [ 05/Oct/12 ]

Fixed in 3.1.2 and trunk





[GLASSFISH-16964] [OSGi] Unable to use SLF4J 1.6.x Created: 06/Jul/11  Updated: 07/Dec/11  Resolved: 06/Dec/11

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1, 3.1.1_b09, 3.1.2
Fix Version/s: 3.1.2_b13, 4.0

Type: Bug Priority: Critical
Reporter: ancoron Assignee: Sivakumar Thyagarajan
Resolution: Fixed Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

weld-osgi-bundle 1.1.1.Final


Attachments: File MANIFEST.MF    
Issue Links:
Dependency
blocks GLASSFISH-17460 Embedded V3 dev tests are getting fail Resolved
Duplicate
duplicates GLASSFISH-17213 conflicting versions of slf4j bundled... Resolved
duplicates GLASSFISH-17171 Glassfish 3.1.2_01 Java EE 6 RI Bug - Resolved
is duplicated by GLASSFISH-17246 SLF4J API conflicts with org.glassfis... Resolved
Tags: 3_1_1-scrubbed, 3_1_2-review, 3_1_next, weld-int-required

 Description   

Because of a slight API change in SLF4J I am unable to use version 1.6.x because the "weld-osgi-bundle" doesn't play well with it:

WARNING: Failed to deploy bundle com.something.support.web [319]
org.glassfish.osgijavaeebase.DeploymentException: Deployment of com.something.support.web [319] failed because of following reason: Failed while deploying bundle com.something.support.web [319] : \
    java.lang.RuntimeException: Failed to deploy bundle [ com.something.support.web [319] ], \
    root cause: Exception while loading the app
	at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:125)
	at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
	at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:107)
	at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
	at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:151)
	at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:148)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.RuntimeException: Failed to deploy bundle [ com.something.support.web [319] ] \
    , 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)
	... 10 more
Caused by: java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker; \
    Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
	at org.slf4j.cal10n.LocLogger.info(LocLogger.java:122)
	at org.jboss.weld.bootstrap.WeldBootstrap.<clinit>(WeldBootstrap.java:213)
	at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:345)
	at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:99)
	at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
	at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:257)
	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)
	... 12 more

So obviously weld is not compatible with SLF4J 1.6.x and hence should not be wired to such a version.

I already filed an upstream issue:

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



 Comments   
Comment by Sanjeeb Sahoo [ 08/Jul/11 ]

Assigning to CDI team. Not much can be done in GlassFish other than waiting for the bug to be fixed in Weld and integrating the same in GlassFish.

Comment by jthoennes [ 08/Jul/11 ]

Will this be fixed for GF v3.1.1?

Comment by Sivakumar Thyagarajan [ 08/Jul/11 ]

No, it will not be fixed for 3.1.1, as we have integrated Weld 1.1.1.Final in this release. The upstream Weld issue has not been fixed in 1.1.1.Final. Thanks.

Comment by Ganesh Krishnan [ 11/Aug/11 ]

I found a workaround by deleting the 1.5.x slf4j jar files from the root of glassfish and copying in 1.6.x version of slf4j jar files. Took me the whole day to debug and come to the conclusion that the method signature of the slf4j has changed in the new version. Bad logger! no cookie for you

Comment by Sanjeeb Sahoo [ 30/Aug/11 ]

A patched MANIFEST.MF which restricts the org.slf4j.* import-package version range to [1.5.0, 1.6.0). To apply, do the following:
cp glassfish/modules/weld-osgi-bundle.jar /tmp/weld-osgi-bundle.jar.orig
jar uvfm glassfish/modules/weld-osgi-bundle.jar MANIFEST.MF

You will see a few warnings as this attached MANIFEST.MF has all the attributes which are already present in the jar, but they can be ignored. Now, restart glassfish. Hope this helps until the upstream weld bug is fixed and a new version of weld is integrated in GlassFish.

Comment by cinhtau [ 30/Aug/11 ]

I can confirm this issue. I use slf4j-api-1.6.2 and logback-classic-0.9.29. Maybe this is an duplicate issue http://java.net/jira/browse/GLASSFISH-17246 then.

Comment by Sanjeeb Sahoo [ 30/Aug/11 ]

It is indeed a duplicate of GLASSFISH-17246. Have marked them as such now.

cinhtau,
I know you have worked around by using some other log api, but I will appreciate much if you can try the patched MANIFEST.MF and confirm if it works.

thanks.

Comment by cinhtau [ 30/Aug/11 ]

Confirm patch: Apply patch. It's working deployment and CDI with weld performs ok. Log routing to SLF4J and logback is working.

Comment by Cheng Fang [ 28/Oct/11 ]

Any updates? ejb devtests (ejb31/embedded/embedasync) are still failing with GlassFish 3.1.2 due to this issue.

Comment by Bhavanishankar [ 05/Nov/11 ]

This issue is very important for Embedded GlassFish

Comment by ancoron [ 12/Nov/11 ]

Upgrade to weld 1.1.3.SP1 and everything should be fine.

Comment by kshitiz_saxena [ 06/Dec/11 ]

With latest weld integration 1.1.4.Final, this issue is no longer reproducible.

Cheng verified that testcase is working on latest build.

Marking this issue as resolved.

Comment by ancoron [ 07/Dec/11 ]

Thank you very much!





[GLASSFISH-16305] Interceptor Bindings are not working with @Schedule methods Created: 01/Apr/11  Updated: 13/Apr/13  Resolved: 13/Apr/13

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

Type: Bug Priority: Minor
Reporter: Sergio Assignee: arjavdesai
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP SP2


Attachments: Zip Archive javaee6.zip    

 Description   

I try to use an interceptor Binding around an @Schedule-annotated method but the interceptor linked to the interceptor binding for this method is never invoked. (see. http://www.java.net/forum/topic/glassfish/glassfish/glassfish-31-interceptor-bindings-schedule)

The same interceptor binding and interceptor works fine with @Timeout annotated method.

The intercetor Binding and interceptor works fine when declared in ejb-jar.xml but not with annotations.

In attachment please find the code sample I use to test it under glassfish v3.1.



 Comments   
Comment by marina vatkina [ 22/May/12 ]

This seems like a CDI processing or CDI integration issue. Transferring to CDI team for further investigation.

Comment by arjavdesai [ 09/Apr/13 ]

Test EJB had a few error e.g. it was using javax.ejb.Resource instead of javax.annotation.Resource. Also, there was no Interceptor defined around, @Schedule method. So, I changed the code as

....

@Singleton
public class Test implements Serializable {

private static final long serialVersionUID = -254310325908151372L;
@javax.annotation.Resource
TimerService timerService;

@Schedule(second = "/5", minute = "", hour = "*")
@Interceptors(MetrologyBean.class)
void schedule()

{ System.out.println("schedule()"); }

....

On once the app is deployed, I can see the Interceptor being invoked and server log has:

[2013-04-09T16:44:10.001-0400] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=189 _ThreadName=Thread-3] [timeMillis: 1365540250001] [levelValue: 800] [[
aroundTimeout of method schedule]]

[2013-04-09T16:44:10.001-0400] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=189 _ThreadName=Thread-3] [timeMillis: 1365540250001] [levelValue: 800] [[
schedule()]]

[2013-04-09T16:44:15.001-0400] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=190 _ThreadName=Thread-3] [timeMillis: 1365540255001] [levelValue: 800] [[
aroundTimeout of method schedule]]

[2013-04-09T16:44:15.001-0400] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=190 _ThreadName=Thread-3] [timeMillis: 1365540255001] [levelValue: 800] [[
schedule()]]

Fwiw, I have glassfish built at revision # 61246 from reop https://svn.java.net/svn/glassfish~svn/trunk/main/appserver

Comment by marina vatkina [ 09/Apr/13 ]

The bug is not about use of interceptor binding, not @Interceptors annotation. Does it work if @Metrology is specified on the bean or @Schedule annotated method?

Comment by arjavdesai [ 10/Apr/13 ]

I don't see interceptor being called, if @Metrology is specified on the bean or @Schedule annotated method.

I do interceptor being called, if @Interceptors(MetrologyBean.class) is specified on the bean or @Schedule annotated method.

Does this mean, bug is not resolved i.e. should it work with @Metrology?

Comment by arjavdesai [ 10/Apr/13 ]

I just read-up on it and it seems @Metrology should work as well. I had not added in past but added interceptor definition in beans.xml now. This doesn't change/fix the issue either, so re-opening for further triage.

Comment by arjavdesai [ 13/Apr/13 ]

revision 61414 should fix it.





[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-16030] Memory leak is created when CDI is enabled for a simple jax-ws based application. Created: 16/Feb/11  Updated: 05/Mar/13  Resolved: 23/May/11

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: v3.0.1
Fix Version/s: 4.0

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

Attachments: XML File domain.xml     Zip Archive glassfish_301_memory_leak.zip    
Tags: 3_1-exclude

 Description   

I've attached a stripped down application that produces a memory leak. This application was built using NetBeans 6.9.1; I believed I made the app with "New Project > Maven > Maven Web Application" and then used "New > Web Services > Web Service from WSDL".

If I remove the beans.xml file from the project the memory leak goes away.

I was able to observe the leak in the stock GlassFish 3.0.1 download with default dev settings as well as with the attached domain.xml which has been modified for other purposes.

Win7 64bit
Sun JDK 1.6.0_23
GlassFish 3.0.1



 Comments   
Comment by Sivakumar Thyagarajan [ 18/Feb/11 ]

This appears to be similar to the memory leak issues filed in 3.0.1 (GLASSFISH-14419, GLASSFISH-13928 and GLASSFISH-12368). With some changes in GlassFish and an integration of Weld 1.1, these memory leaks have been removed in 3.1. So I am marking this issue as 3_1-exclude.

Comment by Sivakumar Thyagarajan [ 23/May/11 ]

Marking as fixed in 3.1





[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-15018] Support beans.xml packaging under WEB-INF/classes/META-INF Created: 07/Dec/10  Updated: 07/Oct/12  Resolved: 07/Oct/12

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

Type: New Feature Priority: Minor
Reporter: Sivakumar Thyagarajan Assignee: Sivakumar Thyagarajan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by GLASSFISH-15935 Weld in Glassfish does not find @Name... Resolved
Tags: cdi

 Description   

Some CDI-enabled web archives (such as jsf/permalink sample in Weld) have beans.xml under WEB-INF/classes/META-INF. Though the specification does not require support for this scenario, this seems to be a common scenario and it would be nice to add support for this scenario in GlassFish as an ease of use feature.

See https://jira.jboss.org/browse/WELD-780 and http://java.net/jira/browse/GLASSFISH-15009 for more context on this RFE.



 Comments   
Comment by mwessendorf [ 11/Feb/11 ]

Why is this minor?

Comment by Mark Struberg [ 11/Feb/11 ]

folks, please read the spec, this is CLEARLY allowed and valid!

Section 12.1 Bean Archives
"A directory in the JVM classpath is a bean archive if it has a file named beans.xml in the META-INF directory."

so what more do you need? This is simply just broken.

Comment by Mark Struberg [ 11/Feb/11 ]

sorry for my previous comment sounding a bit gruntly, but I nearly daily get rants that CODI is broken and it most of the time turns out that glassfish or JbossAS are to blame

Comment by jjsnyder83 [ 07/Oct/12 ]

I only fixed this on the trunk.





[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-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.





Generated at Fri Feb 27 01:18:04 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.