[GLASSFISH-20324] EJB devtest ejb30/clientview/core failing with Weld 2.0.0.CR2 Created: 16/Apr/13  Updated: 17/Apr/13  Resolved: 17/Apr/13

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

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

Tags: 4_0-approved

 Comments   
Comment by jjsnyder83 [ 16/Apr/13 ]

Dev test failure

Comment by jjsnyder83 [ 16/Apr/13 ]

What is the impact on the customer of the bug?

  • It's not released to the customer yet.

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?
It is a regression in the ejb dev tests

  • 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
  • Is there an impact on documentation or message strings?
    No
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    EJB Dev tests
  • Which is the targeted build of 4.0 for this fix?
  • The next build.
  • 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.
Comment by Tom Mueller [ 16/Apr/13 ]

Approved for 4.0





[GLASSFISH-20268] org.jboss.cdi.tck.tests.deployment.packaging.rar.ResourceAdapterArchiveTest regression Created: 10/Apr/13  Updated: 10/Apr/13  Resolved: 10/Apr/13

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

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





[GLASSFISH-20221] cdi tck test failing org.jboss.cdi.tck.tests.deployment.initialization.ApplicationInitializationLifecycleTest Created: 08/Apr/13  Updated: 10/Apr/13  Resolved: 10/Apr/13

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

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


 Description   

Failing on Weld 2.0.0.CR1



 Comments   
Comment by jjsnyder83 [ 10/Apr/13 ]

Committed revision 61355





[GLASSFISH-20220] cdi tck test failing org.jboss.cdi.tck.tests.deployment.discovery.enterprise.EnterpriseBeanDiscoveryTest Created: 08/Apr/13  Updated: 11/Apr/13  Resolved: 11/Apr/13

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

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


 Description   

Failing on Weld 2.0.0.CR1

Should be fixed when Phil commits changes for session beans being bean-defining.



 Comments   
Comment by jjsnyder83 [ 11/Apr/13 ]

Committed revision 61359.

Comment by jjsnyder83 [ 11/Apr/13 ]

testImplicitBeanArchiveModeNone is failing again





[GLASSFISH-20219] cdi tck test failing org.jboss.cdi.tck.tests.deployment.discovery.BeanDiscoveryTest Created: 08/Apr/13  Updated: 10/Apr/13  Resolved: 10/Apr/13

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

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


 Description   

Failing on Weld 2.0.0.CR1



 Comments   
Comment by jjsnyder83 [ 10/Apr/13 ]

Implicit bdas are built incorrectly. Phil is fixing.

Also retest the following tests when this is fixed:
org.jboss.cdi.tck.tests.definition.bean.custom.CustomBeanImplementationTest

Comment by jjsnyder83 [ 10/Apr/13 ]

committed 61350





[GLASSFISH-20214] cdi tck test org.jboss.cdi.tck.tests.implementation.simple.resource.broken.type.ws.ResourceDefinitionWithDifferentTypeTest failing Created: 08/Apr/13  Updated: 11/Apr/13  Resolved: 11/Apr/13

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

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


 Description   

When a web service app fails deployment in cdi it's causing NPE's in various places in web service container load/unload.






[GLASSFISH-20142] Accessing an @Inject JMSContext in a @ServerEndpoint leads to org.jboss.weld.context.ContextNotActiveException Created: 03/Apr/13  Updated: 17/Apr/13  Resolved: 17/Apr/13

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

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

Java 1.7_15
Win7 x64


Tags: fishcat

 Description   

The example app is here: https://www.dropbox.com/s/n8uhy2uka8p5vo4/websockets-demo.zip

launch with button click from here: http://localhost:8080/websockets-demo/

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:662)
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:74)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:82)
at org.glassfish.jms.injection.RequestedJMSContextManager$Proxy$_$$_WeldClientProxy.getType(Unknown Source)
at org.glassfish.jms.injection.InjectableJMSContext.delegate(InjectableJMSContext.java:121)
at org.glassfish.jms.injection.ForwardingJMSContext.createProducer(ForwardingJMSContext.java:61)
at net.eisele.samples.websockets.demo.HelloEndpoint.boradcastMessage(HelloEndpoint.java:60)
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.tyrus.core.AnnotatedEndpoint.callMethod(AnnotatedEndpoint.java:431)
at org.glassfish.tyrus.core.AnnotatedEndpoint.access$100(AnnotatedEndpoint.java:83)
at org.glassfish.tyrus.core.AnnotatedEndpoint$WholeHandler$1.onMessage(AnnotatedEndpoint.java:518)
at org.glassfish.tyrus.core.SessionImpl.notifyMessageHandlers(SessionImpl.java:305)
at org.glassfish.tyrus.core.EndpointWrapper.onMessage(EndpointWrapper.java:462)
at org.glassfish.tyrus.server.TyrusEndpoint.onMessage(TyrusEndpoint.java:163)
at org.glassfish.tyrus.websockets.DefaultWebSocket.onMessage(DefaultWebSocket.java:138)
at org.glassfish.tyrus.websockets.frametypes.TextFrameType.respond(TextFrameType.java:66)
at org.glassfish.tyrus.websockets.DataFrame.respond(DataFrame.java:102)
at org.glassfish.tyrus.servlet.TyrusHttpUpgradeHandler.onDataAvailable(TyrusHttpUpgradeHandler.java:113)
at org.apache.catalina.connector.InputBuffer$ReadHandlerImpl.processDataAvailable(InputBuffer.java:472)
at org.apache.catalina.connector.InputBuffer$ReadHandlerImpl.onDataAvailable(InputBuffer.java:440)
at org.glassfish.grizzly.http.io.InputBuffer.append(InputBuffer.java:854)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:222)
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 jjsnyder83 [ 11/Apr/13 ]

Please email me the zip...I cannot open the attached zip: j.j.snyder@oracle.com

Comment by jjsnyder83 [ 17/Apr/13 ]

I could not reproduce the error. When I clicked on the link I got:

Hello World!





[GLASSFISH-19992] Tracking bug for cdi tck failure org.jboss.cdi.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest Created: 21/Mar/13  Updated: 18/Apr/13  Resolved: 18/Apr/13

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

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


 Description   

test failing is testSerializeSFSB. There is a discussion going on about the container's responsibility for serializing during passivation.



 Comments   
Comment by jjsnyder83 [ 22/Mar/13 ]

I got back some info from Marina and Mahesh which I forwarded to JBoss tck team.

Comment by jjsnyder83 [ 26/Mar/13 ]

Must fork the Weld porting package and rewrite org.jboss.weld.tck.BeansImpl to use GlassFish-specific
ObjectOutputStream/ObjectInputStream.

It should be quite straightforward (the porting package contains only three classes and one cdi-tck.properties file).

The weld porting package source:
https://github.com/weld/core/tree/2.0/porting-package/1.1

Comment by jjsnyder83 [ 18/Apr/13 ]

Fixed in GlassFish test runner.





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

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

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


 Comments   
Comment by jjsnyder83 [ 21/Mar/13 ]

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

Comment by jjsnyder83 [ 22/Mar/13 ]

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

Comment by jjsnyder83 [ 22/Mar/13 ]

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

Comment by jjsnyder83 [ 09/Apr/13 ]

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

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

Comment by jjsnyder83 [ 09/Apr/13 ]

Revision 61270 has the changes needed for this.

Comment by tlcksnyder [ 11/Apr/13 ]

Implemented.





[GLASSFISH-19850] Can't inject JMSContext when security manager is enabled Created: 13/Mar/13  Updated: 11/Apr/13  Resolved: 11/Apr/13

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

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

Issue Links:
Dependency
blocks GLASSFISH-19774 Add QuickLook test case for JMSContex... Closed
Tags: jms-2-implementation

 Description   

When I tried to add the JMS injection quicklook case, I found it failed in hudson jobs because security manager is enabled by default in hudson jobs.

It is easy to be reproduced: Enable the security manager for the domain by adding an option in the JVM Settings and then restart glassfish domain/server. We can see the following exception when accessing the EJB/Web with JMSContext injection (deployment succeeds).

[2013-03-13T14:04:01.787+0800] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=40 _ThreadName=admin-listener(1)] [timeMillis: 1363154641787] [levelValue: 800] [[
Loading application [injection] at [/injection]]]

[2013-03-13T14:04:01.849+0800] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=40 _ThreadName=admin-listener(1)] [timeMillis: 1363154641849] [levelValue: 800] [[
injection was successfully deployed in 3,416 milliseconds.]]

[2013-03-13T14:04:02.910+0800] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core.security] [tid: _ThreadID=26 _ThreadName=http-listener-1(1)] [timeMillis: 1363154642910] [levelValue: 800] [[
JACC Policy Provider: Failed Permission Check, context(injection/injection)- permission(("java.lang.reflect.ReflectPermission" "suppressAccessChecks"))]]

[2013-03-13T14:04:03.066+0800] [glassfish 4.0] [SEVERE] [ejb.stateless_ejbcreate_exception] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=26 _ThreadName=http-listener-1(1)] [timeMillis: 1363154643066] [levelValue: 1000] [[
EJB5070: Exception creating stateless session bean : [SimpleEjb]]]

[2013-03-13T14:04:03.066+0800] [glassfish 4.0] [WARNING] [ejb.system_exception] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=26 _ThreadName=http-listener-1(1)] [timeMillis: 1363154643066] [levelValue: 900] [[
EJB5184:A system exception occurred during an invocation on EJB SimpleEjb, method: public boolean org.glassfish.tests.jms.injection.SimpleEjb.testRequestScope()]]

[2013-03-13T14:04:03.066+0800] [glassfish 4.0] [WARNING] [] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=26 _ThreadName=http-listener-1(1)] [timeMillis: 1363154643066] [levelValue: 900] [[

javax.ejb.EJBException: javax.ejb.EJBException: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:435)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2534)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1924)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:210)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy310.testRequestScope(Unknown Source)
at org.glassfish.tests.jms.injection._EJB31_GeneratedSimpleEjbIntf__Bean_.testRequestScope(Unknown Source)
at org.glassfish.tests.jms.injection.TestServlet.processRequest(TestServlet.java:80)
at org.glassfish.tests.jms.injection.TestServlet.doGet(TestServlet.java:99)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
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.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:323)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:321)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:356)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:214)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1676)
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:176)
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)
Caused by: javax.ejb.EJBException: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:700)
at com.sun.ejb.containers.util.pool.NonBlockingPool.getObject(NonBlockingPool.java:246)
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:430)
... 46 more
Caused by: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:514)
at com.sun.ejb.containers.StatelessSessionContainer.access$000(StatelessSessionContainer.java:97)
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:698)
... 48 more
Caused by: com.google.common.collect.ComputationException: org.jboss.weld.exceptions.WeldException: WELD-001524 Unable to load proxy class for bean org.glassfish.jms.injection.JMSCDIExtension$LocalBean@e5472a with class class org.glassfish.jms.injection.RequestedJMSContextManager using classloader WebappClassLoader (delegate=true; repositories=WEB-INF/classes/)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:400)
at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:181)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:681)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:745)
at org.jboss.weld.injection.ParameterInjectionPointImpl.getValueToInject(ParameterInjectionPointImpl.java:76)
at org.jboss.weld.injection.ConstructorInjectionPoint.getParameterValues(ConstructorInjectionPoint.java:108)
at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:58)
at org.jboss.weld.injection.producer.AbstractInstantiator.newInstance(AbstractInstantiator.java:29)
at org.jboss.weld.injection.producer.DefaultInstantiator.newInstance(DefaultInstantiator.java:67)
at org.jboss.weld.injection.producer.BasicInjectionTarget.produce(BasicInjectionTarget.java:84)
at org.glassfish.jms.injection.JMSCDIExtension$LocalBean.create(JMSCDIExtension.java:208)
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:687)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:745)
at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:88)
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:368)
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:377)
at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
at org.jboss.weld.injection.producer.StatelessSessionBeanInjector.inject(StatelessSessionBeanInjector.java:50)
at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:133)
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:46)
at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:96)
at org.glassfish.weld.services.JCDIServiceImpl.injectEJBInstance(JCDIServiceImpl.java:251)
at com.sun.ejb.containers.BaseContainer.injectEjbInstance(BaseContainer.java:1701)
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:475)
... 50 more
Caused by: org.jboss.weld.exceptions.WeldException: WELD-001524 Unable to load proxy class for bean org.glassfish.jms.injection.JMSCDIExtension$LocalBean@e5472a with class class org.glassfish.jms.injection.RequestedJMSContextManager using classloader WebappClassLoader (delegate=true; repositories=WEB-INF/classes/)
at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:298)
at org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:253)
at org.jboss.weld.bean.proxy.ClientProxyFactory.create(ClientProxyFactory.java:100)
at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:157)
at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:147)
at org.jboss.weld.bean.proxy.ClientProxyProvider.access$000(ClientProxyProvider.java:49)
at org.jboss.weld.bean.proxy.ClientProxyProvider$1.apply(ClientProxyProvider.java:57)
at org.jboss.weld.bean.proxy.ClientProxyProvider$1.apply(ClientProxyProvider.java:53)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:358)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153)
at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:396)
... 76 more
Caused by: java.security.AccessControlException: access denied ("java.lang.reflect.ReflectPermission" "suppressAccessChecks")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:366)
at java.security.AccessController.checkPermission(AccessController.java:560)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128)
at org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:102)
at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:91)
at org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:408)
at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:291)
... 88 more
]]



 Comments   
Comment by Nigel Deakin [ 19/Mar/13 ]

Setting fix version to 4.0. This bug currently causes failure of the JMSContext injection quicklook tests

Comment by jjsnyder83 [ 19/Mar/13 ]

JBoss is aware of the issue. See https://issues.jboss.org/browse/WELD-1242

Comment by David Zhao [ 10/Apr/13 ]

JJ,

I tried latest build with revision 67218, and can't reproduce the problem. Could you please verify if/when the defect is available to be closed?

-david

Comment by jjsnyder83 [ 10/Apr/13 ]

David,
Can you try it again on the latest trunk. Before you start quicklook do the following:

1) start GF
2) use asadmin to do the following 2 commands

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

3) stop GF

4) run quicklook.

Then do it all over again except set the enable-implicit-cdi=false.

thanks,
JJ

Comment by David Zhao [ 11/Apr/13 ]

JJ,

I tried jms injection devtests and QL with both enable-implicit-cdi=true and enable-implicit-cdi=false against revision 61359, it worked fine and all passed.

-david





[GLASSFISH-16186] Unable to convert ejbRef for ejb to a business object, the container picks the wrong interface Created: 09/Mar/11  Updated: 02/Apr/13  Resolved: 02/Apr/13

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

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

Windows 7 x86, JDK 1.6.0_24, Glassfish 3.1 GA, JSF2.


Attachments: Text File GLASSFISH-16186.log     Zip Archive sources.zip     File truc-dev-autodeploy.ear    
Tags: 3_1_1-next, 3_1_1-scrubbed, 3_1_2-exclude, weld-int-required

 Description   

I've been converting a quite big site from EE5 to EE6, with CDI of course.
There's ONE sole thing that bugs me but it's quite peculiar.

I have:

  • @Named @Stateless TimeProviderImpl extends SimpleTimeProvider implements LocalTimeProvider.
  • SimpleTimeProvider implements TimeProvider (the latter defining some methods, the former implementing them. No annotations.)
  • LocalTimeProvider is @Local and also extends TimeProvider and does nothing more.

If I read the EJB 3.1 spec ยง4.9.7, I believe I'm still compliant.

Now, if I try to access this EJB from my web application with EL or through a ManagedBean where it's @Inject injected, I get the exception below.
If I try to access it through the ManagedBean where it's @EJB injected, my page displays correctly (as it used to work in EE5).

Example and logs are attached. Deploy EAR and call http://localhost:8080/TrucWeb/test.jsf

We're somewhere around these but it's slightly different.
http://java.net/jira/browse/GLASSFISH-13040
http://java.net/jira/browse/GLASSFISH-11140
https://issues.jboss.org/browse/WELD-301
https://issues.jboss.org/browse/WELD-305
https://issues.jboss.org/browse/WELD-381
https://issues.jboss.org/browse/WELD-625

If i had to take a wild guess I'd say the issue lies in the Glassfish/Weld integration.



 Comments   
Comment by Sivakumar Thyagarajan [ 13/Jun/11 ]

Transferring to the EJB container team for further evaluation and confirm if this scenario is valid. During investigation, it appears that in EJBContainerServicesImpl.getBusinessObject() for this EJBRef, the business interface com.dummy.time.TimeProvider doesn't seem to belong to the list of local business interfaces for that EJB.

Comment by marina vatkina [ 13/Jun/11 ]

For an interface to be an EJB business interface, it needs to be explicitly denoted as such on the class that is marked as @Stateless. Interfaces implemented by the superclasses, are not component interfaces.

Comment by fabmars [ 15/Jun/11 ]

Excuse me but the point never was to have com.dummy.time.TimeProvider as a business interface. Based on this assumtion, Marina's reasoning definitely makes sense.

But this is NOT the point of the issue, neither this of the attached example.

The point is that something here works with the EJB container and NOT with the CDI container. Please consider reopening this issue and reassigning.

Comment by marina vatkina [ 15/Jun/11 ]

reopening as it seems like a CDI error

Comment by marina vatkina [ 15/Jun/11 ]

Siva,

See in the description:

*Now, if I try to access this EJB from my web application with EL or through a ManagedBean where it's @Inject injected, I get the exception below.
If I try to access it through the ManagedBean where it's @EJB injected, my page displays correctly*

Comment by Sivakumar Thyagarajan [ 15/Jun/11 ]

Marina: Yes, this appears to work in the @EJB case and not in the @Inject case, as for handling the @Inject case, the weld integration code goes through the EJBContainerServices API to resolve an EJB reference, and the EJBContainerServicesImpl doesn't seem to provide com.dummy.time.TimeProvider as a business interface for that ejb-ref.

Assigning to Cheng who handles EJB and requesting him to investigate further.

Comment by marina vatkina [ 15/Jun/11 ]

Siva,

EJB container is correct - com.dummy.time.TimeProvider is not a business interface. Weld integration shouldn't ask for it.

Back to cdi.

Comment by Sivakumar Thyagarajan [ 19/Jun/11 ]

Here is the scenario. An injection of
@Inject
private LocalTimeProvider timeProvider1;
is performed in a SessionScoped Bean.

The Weld bean proxy for the SessionBean Object reference being injected(timeProvider1) tries to get [1] the BusinessObject when a method is invoked on it. Weld seems to use [2] the declaring class of the method being invoked to determine the business interface. Though the business interface of the Bean is set to com.dummy.time.LocalTimeProvider, the class that declares the method being invoked ("getThisMonth()") is com.dummy.time.TimeProvider.

Therefore, the Weld implementation calls SessionObjectReferenceImpl.getBusinessObject("com.dummy.time.TimeProvider"), which fails, as TimeProvider is not a Business interface. As per [3], the businessInterfaceType must be a type of the business interface of the bean. Weld appears to be incorrect in asking through the SPI for a Business Object for a non-Business interface. Filed a Weld issue https://issues.jboss.org/browse/WELD-921 to get this fixed.

[1] https://github.com/weld/core/blob/76c31d311cf1ff449eb2d5c80943b913651bed96/impl/src/main/java/org/jboss/weld/bean/proxy/EnterpriseBeanProxyMethodHandler.java#L123
[2]https://github.com/weld/core/blob/76c31d311cf1ff449eb2d5c80943b913651bed96/impl/src/main/java/org/jboss/weld/bean/proxy/EnterpriseBeanProxyMethodHandler.java#L146
[3] https://github.com/weld/api/blob/master/weld-spi/src/main/java/org/jboss/weld/ejb/api/SessionObjectReference.java#L31

Comment by Sivakumar Thyagarajan [ 14/Nov/11 ]

The Weld 1.1.3 release that is being integrated into 3.1.2 does not have a fix for WELD-921, and so marking this as 3_1_2-exclude

Comment by scatari [ 06/Dec/11 ]

https://issues.jboss.org/browse/WELD-921 seems to be fixed in 1.2.0 Beta1. We recently integrated 1.1.4 to GF 3.1.2. Can we selectively port fixes from 1.2.0 to 1.1.4?

Comment by Sivakumar Thyagarajan [ 11/Dec/11 ]

@scatari: Selectively including fixes from another branch, would require GlassFish to create a modified release of Weld, and so we are not doing that. The fix for WELD-921 has only been targetted for 1.2.0.Beta1 IIRC.

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 tlcksnyder [ 28/Mar/13 ]

Weld bug https://issues.jboss.org/browse/WELD-921 is targeted for Weld 2.0.0.CR1. Retest with CR1.

Comment by jjsnyder83 [ 02/Apr/13 ]

Committed revision 61099.





Generated at Tue Dec 06 01:12:02 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.