[GLASSFISH-21166] session.invalidate causes two NPE Created: 18/Aug/14  Updated: 25/May/16

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 4.1, future release
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: dmatej Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 6
Labels: None
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours
Environment:

EAR with many WAR modules, form auth and custom realm and SSO enabled.


Tags: logout, session, weld

 Description   

The session is finally correctly invalidated, even on cluster instances, but there are these exceptions in the server.log.
I think it should throw another exception or do nothing, but it must not throw NPE.

WeldTerminalListener in current trunk is 2.2.2, current version is 2.2.4 - maybe it could be fixed, if it is really weld error.

[2014-08-18T13:42:56.479+0200] [glassfish 4.1] [INFO] [] [javax.enterprise.web.core] [tid: _ThreadID=28 _ThreadName=http-listener-1(2)] [timeMillis: 1408362176479] [levelValue: 800] [[
  Session event listener threw exception
java.lang.NullPointerException
        at org.jboss.weld.servlet.WeldTerminalListener.getSessionContext(WeldTerminalListener.java:65)
        at org.jboss.weld.servlet.WeldTerminalListener.sessionDestroyed(WeldTerminalListener.java:57)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:910)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:854)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:842)
        at org.apache.catalina.session.StandardSession.invalidate(StandardSession.java:1603)
        at org.apache.catalina.session.StandardSessionFacade.invalidate(StandardSessionFacade.java:204)
        at org.apache.jsp.logout_jsp._jspService(logout_jsp.java:58)
...
[2014-08-18T13:42:56.482+0200] [glassfish 4.1] [INFO] [] [javax.enterprise.web.core] [tid: _ThreadID=28 _ThreadName=http-listener-1(2)] [timeMillis: 1408362176482] [levelValue: 800] [[
  Session event listener threw exception
java.lang.NullPointerException
        at org.jboss.weld.servlet.WeldTerminalListener.getSessionContext(WeldTerminalListener.java:65)
        at org.jboss.weld.servlet.WeldTerminalListener.sessionDestroyed(WeldTerminalListener.java:57)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:910)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:854)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:842)
        at org.apache.catalina.authenticator.SingleSignOnEntry.expireSessions(SingleSignOnEntry.java:158)
        at com.sun.enterprise.security.web.GlassFishSingleSignOn.deregister(GlassFishSingleSignOn.java:560)
        at com.sun.enterprise.security.web.GlassFishSingleSignOn.sessionEvent(GlassFishSingleSignOn.java:337)
        at org.apache.catalina.session.StandardSession.fireSessionEvent(StandardSession.java:2318)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:984)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:854)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:842)
        at org.apache.catalina.session.StandardSession.invalidate(StandardSession.java:1603)
        at org.apache.catalina.session.StandardSessionFacade.invalidate(StandardSessionFacade.java:204)
        at org.apache.jsp.logout_jsp._jspService(logout_jsp.java:58)

Line 65 in WeldTerminalListener:

    private HttpSessionContext getSessionContext() {
        return beanManager.instance().select(HttpSessionContext.class).get();
    }


 Comments   
Comment by Shing Wai Chan [ 18/Aug/14 ]

Can you provide a test case to illustrate this?

Comment by dmatej [ 19/Aug/14 ]

I will try to create some. I tried to replace weld-osgi-bundle with the 2.2.4 version, the result is same.

Comment by dmatej [ 20/Aug/14 ]

It seems it is not so simple ...
1) In our 35MB big ear with around 20 modules it is logged after each logout.
2) In unit test I created, with or without SSO enabled and tested on ear containing two simple war modules it works without exceptions.
So I looked inside the Glassfish code ... meanwhile I tried to undeploy our application and same error occured. I suspect this issue is caused by the same thing as GLASSFISH-21147 , but I have to find out how to create some simplier example with the test.

[2014-08-20T17:09:18.952+0200] [glassfish 4.1] [INFO] [] [javax.enterprise.web.core] [tid: _ThreadID=227 _ThreadName=admin-listener(6)] [timeMillis: 1408547358952] [levelValue: 800] [[
  Session event listener threw exception
java.lang.NullPointerException
        at org.jboss.weld.servlet.WeldTerminalListener.getSessionContext(WeldTerminalListener.java:65)
        at org.jboss.weld.servlet.WeldTerminalListener.sessionDestroyed(WeldTerminalListener.java:57)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:910)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:854)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:842)
        at org.apache.catalina.session.StandardManager.stop(StandardManager.java:955)
        at org.apache.catalina.core.StandardContext.stop(StandardContext.java:6133)
        at com.sun.enterprise.web.WebModule.stop(WebModule.java:720)
Comment by dmatej [ 20/Aug/14 ]

I have downloaded weld-core sources from Github and separated that line in three.
It seems the beanManager is not injected - it is null.
Tested with weld-osgi-bundle 2.2.5-SNAPSHOT commit 81c0ee82, 2.2.4 and original 2.2.2.

public class WeldTerminalListener implements HttpSessionListener {
    @Inject
    private BeanManagerImpl beanManager;

Does someone know why and how to fix it?

I have found more messages in logs - this is in server.log file when initializing both the admingui application and our application:

[2014-08-20T23:04:43.273+0200] [glassfish 4.1] [FINE] [] [org.glassfish.naming] [tid: _ThreadID=170 _ThreadName=Thread-32] [timeMillis: 1408568683273] [levelValue: 500] [CLASSNAME: NamedNamingObjectManager] [METHODNAME: tryNamedProxies] [[
  found cached proxy [org.glassfish.weld.BeanManagerNamingProxy@7209773] for [java:comp/BeanManager]]]

[2014-08-20T23:04:43.273+0200] [glassfish 4.1] [FINE] [] [javax.enterprise.resource.webcontainer.jsf.config] [tid: _ThreadID=170 _ThreadName=Thread-32] [timeMillis: 1408568683273] [levelValue: 500] [CLASSNAME: com.sun.faces.config.WebConfiguration] [METHODNAME: processJndiEntries] [[
  javax.naming.NamingException: Lookup failed for 'java:comp/BeanManager' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NamingException: Error retrieving java:comp/BeanManager [Root exception is java.lang.IllegalStateException: Cannot resolve bean manager]]]]

[2014-08-20T23:04:43.273+0200] [glassfish 4.1] [FINE] [] [javax.enterprise.resource.webcontainer.jsf.config] [tid: _ThreadID=170 _ThreadName=Thread-32] [timeMillis: 1408568683273] [levelValue: 500] [CLASSNAME: com.sun.faces.config.WebConfiguration] [METHODNAME: processJndiEntries] [[
  javax.naming.NamingException: Lookup failed for 'java:comp/env/BeanManager' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NameNotFoundException: No object bound to name java:comp/env/BeanManager]]]

Maybe I got some idea - my test application does not contain any beans and does not need injections ... I will take a look in the morning ... now I'm dead ...
(also catching Throwable in BeanManagerNamingProxy is really ugly )

Comment by dmatej [ 21/Aug/14 ]

I got it - when I add empty beans.xml file to the WEB-INF directory, there are no NPE any more. It seems it is some problem with using SSO, EJB3 and old J2SE war applications in one EAR. CDI then works only partially: it works on EJB modules, but not in war modules which did not declare they want it. WeldTerminalListener is maybe initialized in war module and that is the reason why it's beanManager is null.

I will try to create the test case but I am not authorized to attach files. Can you do something with it?

Comment by dmatej [ 21/Aug/14 ]

The perfectly repeatable test case is prepared, how can I upload it?

Comment by reza_rahman [ 21/Aug/14 ]

Could you kindly send it to me for now?

Comment by dmatej [ 02/Sep/14 ]

Test case uploaded to GLASSFISH-21146 (I did a mistake in e-mail subject). I still cannot upload or change JIRA attachements so I cannot fix it ...

Comment by reza_rahman [ 02/Sep/14 ]

Please email it to me. As I may have explained, we can't enable attachments for now (and perhaps even in the long term) due to security policies.

Comment by dmatej [ 13/Sep/14 ]

Please only move the attachment from GLASSFISH-21146 here.

Comment by Wydrian [ 19/Sep/14 ]

I have the same problem with a simple struts2 based application: every time the HttpSession is invalidated (even manually by calling invalidate() or by the container), a NPE is thrown by WeldTerminalListener. It is since GF 4.1 upgrade, in 4.0 and before it was working fine. Everything seems to work normally: only the log is filled with this exeption.

2014-09-20T00:20:45.571+0200|Info: Session event listener threw exception
java.lang.NullPointerException
at org.jboss.weld.servlet.WeldTerminalListener.getSessionContext(WeldTerminalListener.java:65)
at org.jboss.weld.servlet.WeldTerminalListener.sessionDestroyed(WeldTerminalListener.java:57)
at org.apache.catalina.session.StandardSession.expire(StandardSession.java:910)
at org.apache.catalina.session.StandardSession.expire(StandardSession.java:854)
at org.apache.catalina.session.StandardSession.expire(StandardSession.java:842)
at org.apache.catalina.session.StandardSession.invalidate(StandardSession.java:1603)
at org.apache.catalina.session.StandardSessionFacade.invalidate(StandardSessionFacade.java:204)
at hu.tikkin.action.LogoutAction.execute(LogoutAction.java:64)
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:606)
at com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:450)
at com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:289)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:252)
at com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:265)
at org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.doIntercept(AnnotationValidationInterceptor.java:68)
at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:254)
at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at com.opensymphony.xwork2.interceptor.PrepareInterceptor.doIntercept(PrepareInterceptor.java:171)
at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at com.opensymphony.xwork2.interceptor.StaticParametersInterceptor.intercept(StaticParametersInterceptor.java:191)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at org.apache.struts2.interceptor.CheckboxInterceptor.intercept(CheckboxInterceptor.java:91)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at com.opensymphony.xwork2.interceptor.ChainingInterceptor.intercept(ChainingInterceptor.java:145)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at com.opensymphony.xwork2.interceptor.I18nInterceptor.intercept(I18nInterceptor.java:139)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at org.apache.struts2.interceptor.ServletConfigInterceptor.intercept(ServletConfigInterceptor.java:164)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at com.opensymphony.xwork2.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:189)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at com.opensymphony.xwork2.interceptor.AliasInterceptor.intercept(AliasInterceptor.java:193)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at org.apache.struts2.impl.StrutsActionProxy.execute(StrutsActionProxy.java:54)
at org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:562)
at org.apache.struts2.dispatcher.ng.ExecuteOperations.executeAction(ExecuteOperations.java:77)
at org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:99)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
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 com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:415)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:724)

Comment by cistox [ 16/Nov/15 ]

Using request.logout() as per Servlet 3.0 I have same error but different line (WeldTerminalListener.java:72):

[2015-11-16T12:21:17.108+0100] [glassfish 4.1] [INFO] [] [javax.enterprise.web.core] [tid: _ThreadID=111 _ThreadName=ContainerBackgroundProcessor[StandardEngine[glassfish-web].StandardHost[server].StandardContext[/svc]]] [timeMillis: 1447672877108] [levelValue: 800] [[
Session event listener threw exception
java.lang.NullPointerException
at org.jboss.weld.servlet.WeldTerminalListener.getSessionContext(WeldTerminalListener.java:72)
at org.jboss.weld.servlet.WeldTerminalListener.sessionDestroyed(WeldTerminalListener.java:64)
at org.apache.catalina.session.StandardSession.expire(StandardSession.java:910)
at org.apache.catalina.session.StandardSession.expire(StandardSession.java:854)
at org.apache.catalina.session.StandardSession.expire(StandardSession.java:842)
at org.apache.catalina.session.PersistentManagerBase.processExpires(PersistentManagerBase.java:785)
at org.apache.catalina.session.PersistentManagerBase.backgroundProcess(PersistentManagerBase.java:429)
at org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:6375)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1823)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1812)
at java.lang.Thread.run(Thread.java:745)

Comment by payara_steve [ 25/Feb/16 ]

If this is an old application that has no CDI beans but has EJBs try unticking Implicit CDI on deployment. This solved the issue in our test case.

Comment by lprimak [ 25/May/16 ]

This issue will be resolve in Payara with the next release





[GLASSFISH-20793] GF4 deployment error when having two web projects under one ear with equal managed bean names Created: 03/Sep/13  Updated: 06/Sep/13  Resolved: 06/Sep/13

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

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

Win 7 Pro 64Bit
GlassFish Server Open Source Edition 4.0 (build 89)
GlassFish 4.0.1 b04 09/03/2013
jdk1.7.0_21


Attachments: Zip Archive GLASSFISH-20793_demo.zip    
Tags: cdi, glassfish4, jsf, weld

 Description   

We are currently evaluating glassfish 4 for migration of our enterprise projects from glassfish 3.1.2.2. One problem we noticed is that now deployment fails with an ambiguity error message when having two web projects under one ear with equal managed bean names (see stacktrace below). In this case we created two simple jsf web projects contained in the same ear. Both wars contain a managed bean with same managed bean names ('greetingBean'). On GF3.x it works without problems.

@Named
@RequestScoped
public class GreetingBean {

public String getGreeting()

{ return "Hello from " + getClass().getName(); }

}

-------
org.glassfish.deployment.common.DeploymentException: CDI deployment failure:WELD-001414 Bean name is ambiguous. Name greetingBean resolves to beans [Managed Bean [class test.web2.GreetingBean] with qualifiers [@Default @Any @Named], Managed Bean [class test.web1.GreetingBean] with qualifiers [@Default @Any @Named]]
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:225)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001414 Bean name is ambiguous. Name greetingBean resolves to beans [Managed Bean [class test.web2.GreetingBean] with qualifiers [@Default @Any @Named], Managed Bean [class test.web1.GreetingBean] with qualifiers [@Default @Any @Named]]
at org.jboss.weld.bootstrap.Validator.validateBeanNames(Validator.java:639)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:488)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:536)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:216)
... 36 more
-------



 Comments   
Comment by TangYong [ 03/Sep/13 ]

Component/s should be CDI.

Comment by Manfred Riem [ 03/Sep/13 ]

Reassigning to JJ as this looks like a CDI specific issue.

Comment by TangYong [ 03/Sep/13 ]

Change Component/s into CDI

Comment by TangYong [ 04/Sep/13 ]

I did a demo(attachment) to re-produce the issue.

PL. JJ confirms it.

Notice that the following,

1. Bean in different wars should be allowed to have the same EL name
https://issues.jboss.org/browse/CDI-188

2. Ambiguous name validation should not cross visibility boundaries
https://issues.jboss.org/browse/WELD-1065

From JBOSS Team's reply,
"
It is not portable to have multiple classes of the same name within the deployment. Weld currently does not support this..."

It seems that this issue is not still planned to be fix.

Thanks
Tang

Comment by TangYong [ 04/Sep/13 ]

New Confirmation is as following:

1. The issue can be re-produced using GlassFish 4.0.1 b04 09/03/2013

http://dlc.sun.com.edgesuite.net/glassfish/4.0.1/nightly/latest-glassfish.zip (b04 09/03/2013)

2. The issue does not happen using wildfly-8.0.0.Alpha4
"
15:01:23,451 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016002: Processing weld deployment eartwowars-ear.ear
15:01:23,498 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-1) HV000001: Hibernate Validator 5.0.1.Final
15:01:23,576 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016002: Processing weld deployment eartwowars-war1-1.0.0.war
15:01:23,576 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016002: Processing weld deployment eartwowars-war2-1.0.0.war
15:01:23,607 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016005: Starting Services for CDI deployment: eartwowars-ear.ear
15:01:23,638 INFO [org.jboss.weld.Version] (MSC service thread 1-2) WELD-000900 2.0.3 (Final)
15:01:23,732 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016008: Starting weld service for deployment eartwowars-ear.ear
15:01:24,513 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS018210: Register web context: /eartwowars-war1
15:01:24,513 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) JBAS018210: Register web context: /eartwowars-war2
15:01:24,670 INFO [org.jboss.as.server] (XNIO-1 task-3) JBAS018559: Deployed "eartwowars-ear.ear" (runtime-name : "eartwowars-ear.ear")"

3. GlassFish 4.0.1 b04 and wildfly-8.0.0.Alpha4 all uses weld-osgi-bundle 2.0.3.Final.

So, I can make an initial conclusion that maybe the issue is caused by GlassFish Weld Integration and I raised up Priority of the issue.

Comment by replicant77 [ 04/Sep/13 ]

Interesting to notice is that switching from cdi to jsf managed bean declarations resolves the issue. As we reference these beans in jsf pages, this is a better workaround for us than renaming the bean names.

@javax.faces.bean.ManagedBean
@javax.faces.bean.RequestScoped
//@javax.inject.Named
//@javax.enterprise.context.RequestScoped
public class GreetingBean {

public String getGreeting()

{ return "Hello from " + getClass().getName(); }

}

Comment by TangYong [ 04/Sep/13 ]

Java EE 7(or Higher) recommended using backing bean(using CDI concept) with JSF rather than ManagedBean. The ManagedBean has been outdated and although the workaround is valid for your current issue, It is hard to say that in the future, once GlassFish does not support ManagedBean, whether you will come back the scene again.

Backing to the issue, I am investigating it and this should belong to Bean visibility problem while building BDAs.

Thanks
Tang

Comment by TangYong [ 04/Sep/13 ]

JJ

The reason for the issue has been found as following,

For an ear with two wars, while deploying the ear, GlassFish Weld Integration created several Bean Managers corresponding to different BDAs. Among them, there is a Bean Manager liking AppBda_XXX-YYY which corresponds to the EAR BDA, and there are also two Bean Managers which correspond to the wars. The important point is that the EAR's Bean Manager's getAccessibleManagers() contains the wars's Bean Managers.

Then, while org.jboss.weld.bootstrap.Validator calls the following,

public void validateBeanNames(BeanManagerImpl beanManager) {
...
for (Bean<?> bean : beanManager.getAccessibleBeans())

{ ... }

getAccessibleBeans() will call org.jboss.weld.manager.BeanManagers.buildAccessibleClosure(...),

The buildAccessibleClosure(...) will obtain all contained Bean Managers related to current Bean Manager by using getAccessibleManagers().

So, war1 and war2's beans with the same name will be added Validator's "namedAccessibleBeans" as following,

for (Bean<?> bean : beanManager.getAccessibleBeans()) {
if (bean.getName() != null)

{ namedAccessibleBeans.put(bean.getName(), bean); }

}

And the exception happened.

Deeply, the issue should be related to Bean Manager's visibility. I think that we should not make war1 and war2's Bean Manager visible to EAR's Bean Manager.

Thanks
Tang

Comment by jjsnyder83 [ 04/Sep/13 ]

I also spoke with the JBoss guys and this should be valid. I will look at it shortly.

Comment by TangYong [ 05/Sep/13 ]

JJ

Fixing place has been confirmed as following,

Class: org.glassfish.weld.DeploymentImpl
Method: addAppBda()
Place to need to fix:
private void addAppBda() {
...
// make all bdas visible to the app Bda. But none have visibility to App Bda
for ( BeanDeploymentArchive oneBda : beanDeploymentArchives ) {
if ( ! oneBda.equals(appBda))

{ appBda.getBeanDeploymentArchives().add(oneBda); }

}
}

Whether can remove the above logic and make appBda not contain any child bda?

Thanks
Tang

Comment by TangYong [ 05/Sep/13 ]

I have made an fixing by removing the above logic, then , replaced the weld-integration bundle using self-built version on 4.0.1-b02. While deploying demo(attachment),

E:\NanjingJUG\glassfish-4.0.1-b02\glassfish4\glassfish\bin>asadmin deploy E:\NanjingJUG\GLASSFISH-20793\ear\target\eartwowars-ear.ear
Application deployed with name eartwowars-ear.
Command deploy executed successfully.

[server.log]
...
[2013-09-05T11:19:31.304+0900] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=41 _ThreadName=admin-listener(2)] [timeMillis: 1378347571304] [levelValue: 800] [[
Loading application eartwowars-ear#eartwowars-war1-1.0.0.war at [/eartwowars-war1]]]

[2013-09-05T11:19:31.336+0900] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=41 _ThreadName=admin-listener(2)] [timeMillis: 1378347571336] [levelValue: 800] [[
Loading application eartwowars-ear#eartwowars-war2-1.0.0.war at [/eartwowars-war2]]]

[2013-09-05T11:19:31.398+0900] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=41 _ThreadName=admin-listener(2)] [timeMillis: 1378347571398] [levelValue: 800] [[
eartwowars-ear was successfully deployed in 4,171 milliseconds.]]

Pl. confirming the fix.

Thanks
Tang

Comment by jjsnyder83 [ 05/Sep/13 ]

I have been looking into the issue and tried the same change but it causes a tck failure. I have to remove the app bda completely and at the same time provide a fix for the tck failure. I should have something soon.

Comment by jjsnyder83 [ 05/Sep/13 ]

Ok, I have a fix that I will submit tomorrow.

Comment by jjsnyder83 [ 06/Sep/13 ]

Committed revision 62703





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





[GLASSFISH-19226] Weld BoundSessionContext class not found Created: 24/Oct/12  Updated: 14/Feb/13  Resolved: 14/Feb/13

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

Type: Bug Priority: Major
Reporter: JSchneider Assignee: tlcksnyder
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: weld

 Description   

The weld-osgi-bundle.jar clearly contains the org.jboss.weld.context.bound.BoundSessionContext interface. However, including reference to this interface results in the following immediately upon trying to deploy an application.

SEVERE: Class [ Lorg/jboss/weld/context/bound/BoundSessionContext; ] not found.



 Comments   
Comment by shreedhar_ganapathy [ 13/Dec/12 ]

Assigning to weld (CDI) team

Comment by tlcksnyder [ 14/Feb/13 ]

Duplicate of GLASSFISH-19668





[GLASSFISH-19225] Cannot inject Weld BoundSessionContext Created: 24/Oct/12  Updated: 14/Feb/13  Resolved: 14/Feb/13

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

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

Tags: weld

 Description   

According to Weld documentation, one should be able to inject the BoundSessionContext using

@Inject @Bound SessionContext sessionContext;

This results in the following error using the Weld version included with Glassfish 3.1.2.2:

org.jboss.weld.exceptions.DeploymentException: WELD-001409 Ambiguous dependencies for type [SessionContext] with qualifiers [@Default] at injection point [[field] @Inject com.smashmeter.service.ContextManager.sessionContext]. Possible dependencies [[org.jboss.weld.bean-meter-Built-in-org.jboss.weld.context.bound.BoundSessionContext, org.jboss.weld.bean-meter-Built-in-org.jboss.weld.context.http.HttpSessionContext]]

This should not be the case, as the "@Bound" qualifier is specified.

Furthermore, trying to make any reference to the interface BoundSessionContext which extends SessionContext will result in a ClassNotFoundExeption.



 Comments   
Comment by shreedhar_ganapathy [ 13/Dec/12 ]

-> CDI team

Comment by tlcksnyder [ 14/Feb/13 ]

Duplicate of GLASSFISH-19668





[GLASSFISH-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-18827] Exception on app deployment if javassist bundled Created: 22/Jun/12  Updated: 19/Sep/14  Resolved: 25/Jul/13

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

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

OpenSuse 12.1
Glassfish 3.1.2 local installation


Tags: exception, javassist, weld

 Description   

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

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

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



 Comments   
Comment by arjavdesai [ 13/Apr/13 ]

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

Comment by arothe [ 05/Jun/13 ]

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

<class-loader delegate="false"/>

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





[GLASSFISH-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-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-17246] SLF4J API conflicts with org.glassfish.weld.WeldDeployer Created: 26/Aug/11  Updated: 30/Aug/11  Resolved: 30/Aug/11

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

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

Ubuntu Linux 10.04 LTS, Glassfish 3.1.1, SLF4J API 1.6.1..1.6.2, logback classic 0.9.29


Issue Links:
Duplicate
duplicates GLASSFISH-16964 [OSGi] Unable to use SLF4J 1.6.x Resolved
Tags: App, EJB, Hybrid, OSGi, cdi, logback, slf4j, weld

 Description   

Described in

http://old.nabble.com/HybridApplication-WeldBootstrap-Error-td32335499.html#a32340492

The deployment of my ejb bundle (hybrid application) fails, cause org.glassfish.weld.WeldDeployer throws an error.

server.log
2011-08-26T08:28:17.139+0200   WARNING
org.glassfish.osgijavaeebase                                     
Failed to deploy bundle de.sgbs.geo.service [386]
org.glassfish.osgijavaeebase.DeploymentException: Deployment of de.sgbs.geo.service [386] failed because of following reason: Failed while deploying bundle de.sgbs.geo.service [386] : java.lang.RuntimeException: Failed to deploy bundle [ de.sgbs.geo.service [386] ], 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 [ de.sgbs.geo.service [386] ], 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.(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

I use SLF4J to route OSGi LogEntry to logback. This is not possible anymore, because after each restart of the application server the above error is thrown. Uninstalling slf4j api as bundle and it works again. Proposal: Separate slf4j with org.glassfish.weld, so other users can use slf4j.






[GLASSFISH-15682] Programmatically injection of Stateful session bean fails Created: 25/Jan/11  Updated: 25/Jan/11  Resolved: 25/Jan/11

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

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

GlassFish Server Open Source Edition 3.1-b38
Netbeans 6.9.1


Issue Links:
Duplicate
is duplicated by GLASSFISH-15660 [Regression] Ambiguous dependencies f... Resolved
Tags: Instance, cdi, injection, weld

 Description   

The following example code aims to obtain a NEW STATEFUL session bean at method each call. I use the classic CDI way as described in the WELD 1.1 documentation. (Disclaimer: This is a very simple example, no clean-up, no business value.)

JSF:

<h:head>
<title>Facelet Title</title>
</h:head>
h:body>
<h:form>
<h:commandButton action="#

{action.execute}

" value="Click Me"/>
</h:form>
</h:body>

SessionScoped Managed Bean:

@javax.inject.Named(value="action")
@javax.enterprise.context.SessionScoped
public class Action implements Serializable {

private @Inject Instance<SessionBean> sessionBeanSource;

public void execute()

{ System.out.println("Action Executed!"); SessionBean sb=sessionBeanSource.get(); System.out.println(" -> "+sb.say("hi!")); }

}

Stateful SessionBean

@Stateful
@LocalBean
public class SessionBean {

@PostConstruct public void postConstruct()

{ System.out.print("bean postconstruct"); }

public String say(String msg)

{ return "Say "+msg; }

}

This example works well on Glassfish 3.0.1 and Weld 1.0.1, but fails on Glassfish 3.1-b38 (38) with the following error:

Caused by: org.jboss.weld.exceptions.AmbiguousResolutionException: WELD-001318 Cannot resolve an ambiguous dependency between [Session bean [class domain.SessionBean with qualifiers [@Any @Default]; local interfaces are [SessionBean], Managed Bean [class domain.SessionBean] with qualifiers [@Any @Default]]
at org.jboss.weld.manager.BeanManagerImpl.resolve(BeanManagerImpl.java:1177)
at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:785)
at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:116)
at test.Action.execute(Action.java:22)
at test.org$jboss$weld$bean-web-ManagedBean-class_test$Action_$$WeldClientProxy.execute(org$jboss$weld$bean-web-ManagedBean-class_test$Action$$_WeldClientProxy.java)
:
:

NB. Output of Weld version at server start-up is corrupted: "INFO: WELD-000900 $

{parsedVersion (osgiVersion}

)"



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

Duplicate of GLASSFISH-15660

Comment by Sivakumar Thyagarajan [ 25/Jan/11 ]

Closed as duplicate





Generated at Sat Oct 01 10:14:29 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.