[GLASSFISH-14808] Seam3 and weld extension applications related classloading issues with Weld 1.1.0.Beta2 Created: 19/Nov/10  Updated: 20/Feb/11  Resolved: 07/Jan/11

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

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

Operating System: All
Platform: Macintosh


Attachments: File catch-jaxrs-example.war     Zip Archive GLASSFISH-14808-fix-diff.zip     File seam-catch-example-jaxrs.war    
Issuezilla Id: 14,808
Tags: 3_1-approved

 Description   

You can see the full stack trace at http://pastebin.com/LSpmygYe This is a seam3 application that uses
Seam Catch, Seam Rest, and Weld Extensions. I was told by Pete Muir it looked like a classloader issue.



 Comments   
Comment by lightguard [ 19/Nov/10 ]

Created an attachment (id=5544)
The example application

Comment by Sivakumar Thyagarajan [ 02/Dec/10 ]

latest war I tried to reproduce this issue with.

My wksp state:
[21:30:51] [siva@spiff ../catch/examples/jaxrs] (master) $ git describe
3.0.0.Alpha1-25-g1447cfe

Comment by Sivakumar Thyagarajan [ 02/Dec/10 ]

The classloading exception(IllegalAccessError) was due to a problem with handling package-private constructors https://jira.jboss.org/browse/WELD-737. I had checked in an alternative implementation of the ProxyServices implementation on Friday commit # r42968 that fixes this problem.

After that I tried reproducing this error with the latest (3.0.0.Alpha1-25-g1447cfe) of the seam-catch sample at
https://github.com/seam/catch/tree/master/examples/jaxrs/
and GlassFish/Weld throws the following exception [1] during deployment with the latest WAR (Attached).

After investigation, it appears that the weld-extensions-1.1.0-Beta1.jar [the weld extensions jar this app depends upon] included in WEB-INF/lib of the WAR, does not have a META-INF/beans.xml and is hence not considered as a bean archive. This behaviour follows Section 12.1 of the CDI 1.0 spec which states that "A directory in the JVM classpath is a bean archive if it has a file named beans.xml in the META-INF directory". So I am closing this issue as invalid. Please raise another issue should you still a problem after fixing this. Thanks.

[1]
[#|2010-12-02T21:34:13.806+0530|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=15;_ThreadName=Thread-1;|Exception while loading the app : WELD-001408 Unsatisfied dependencies for type [ELResolver] with qualifiers [@Composite] at injection point [[field] @Inject @Composite private org.jboss.weld.extensions.el.ELContextProducer.resolver]
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [ELResolver] with qualifiers [@Composite] at injection point [[field] @Inject @Composite private org.jboss.weld.extensions.el.ELContextProducer.resolver]
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:284)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:134)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:153)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:356)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:342)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:383)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:184)

Comment by lightguard [ 02/Dec/10 ]

This is the exception I get with the SNAPSHOT that you gave me Siva, however, using the latest promoted build (b31) I get

WELD-001408 Unsatisfied dependencies for type [ResourceLoaderManager] with qualifiers [@Default] at injection point [[field] @Inject private org.jboss.weld.extensions.resourceLoader.ResourceProducer.resourceLoaderManager]
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [ResourceLoaderManager] with qualifiers [@Default] at injection point [[field] @Inject private org.jboss.weld.extensions.resourceLoader.ResourceProducer.resourceLoaderManager]

Which I think is the original exception I had with b29. weld-extensions doesn't need a beans.xml file, it loads all of it's classes and beans via the spi lifecycle events. I've verified all of these methods are called via debugging, but still getting exceptions upon deployment.

Comment by mimik789 [ 05/Dec/10 ]

I can confirm that current weld-extensions-1.0.0.Beta1 (now Seam Solder) doesn't work on glassfish v 3.1 (b30). Many of Jboss Seam 3 modules depends on this version, and thus one can't currently deploy webapp which make use of Seam 3 (eg. Seam 3 Security module, released recently).

I observed that exception thrown at deployment vary regards type enclosed in brackets
that is going to be injected to weld-extensions classes (Unsatisfied dependencies for type [...] ...)
between (weld) extensions defined in
weld-extensions-1.0.0.Beta1.jar\META-INF\services\javax.enterprise.inject.spi.Extension
so somtimes it complains about
[ELResolver]
and other time about [ResourceLoaderManager] mentioned earlier by lightguard.

I also made some experimenting - it looks like that this exception occurs always after adding just weld-extensions-1.0.0.Beta1.jar to WEB-INF/lib (so to reproduce, deploy simple JEE6 webapp from maven archetype
(eg. mvn archetype:generate -DarchetypeArtifactId=jboss-javaee6-webapp -DarchetypeGroupId=org.jboss.weld.archetypes -DarchetypeVersion=1.0.1.Beta1)

+ add weld-extensions-1.0.0.Beta1.jar).

Because of this exception we switched our development of webapp which uses Seam3 to Jboss AS 6 CR1 - weld-extensions-1.0.0.Beta1 works well on it (even without beans.xml in META-INF).

full stack trace + more description on
http://seamframework.org/Community/DeploymentExceptionWithSeamFaces300Beta1

Comment by ratking [ 22/Dec/10 ]

weld-extensions-1.0.0.Alpha2 can run in GlassFish 3.0.1/3.1-b33
weld-extensions-1.0.0.Beta1 and seam-solder-3.0.0.Beta1 can't run in GlassFish 3.0/3.1
This is a so heavy sad news

Comment by as6o [ 04/Jan/11 ]

The Seam 3 folks seem to think that this is still an issue that is known about by the Glassfish developers. If so, should this issue be reopened so that we can track the progress? Or, is there another issue we should be tracking?

Comment by Sivakumar Thyagarajan [ 06/Jan/11 ]

Reopening this issue to track seam-catch and related deployment issues.

— 3.1 change request –
Component Name: CDI
Issue: http://java.net/jira/browse/GLASSFISH-14808

> How bad is its impact? (Severity)

Major. Users who want to use seam-catch and other weld extensions face this problem.

> How often does it happen? Will many users see this problem? (Frequency)

Often

> How much effort is required to fix it? (Cost)

Fix available. Attached diff in the issue tracker.

> What is the risk of fixing it and how will the risk be mitigated? (Risk)

There are no risks with this fix. I have run CDI developer tests and QL to ensure that the fix does not bring in new regressions and also ensured that the seam-catch-jaxrs sample referred by the user deploys fine and works correctly.

Comment by Sivakumar Thyagarajan [ 06/Jan/11 ]

Recommended fix

Comment by Sivakumar Thyagarajan [ 06/Jan/11 ]

Analysis of issue: The seam-catch-example-jaxrs.war sample had multiple CDI extensions under WEB-INF/lib and GF wasn't handling WEB-INF/lib jar extensions and visibility between these extensions correctly.

Comment by Sivakumar Thyagarajan [ 06/Jan/11 ]

[Changed title to reflect the issue]

Comment by Chris Kasso [ 06/Jan/11 ]

Approved for 3.1

Comment by lightguard [ 06/Jan/11 ]

When should we expect this in a promoted build?

Comment by Sivakumar Thyagarajan [ 07/Jan/11 ]

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

Comment by Sivakumar Thyagarajan [ 07/Jan/11 ]

Resolved as part of svn commit 44294.

svn log -v -r44294

Comment by ratking [ 10/Jan/11 ]

I can't run webapp which using seam-solder-3.0.0.Beta1.jar + seam-faces-3.0.0.Beta2.jar + jboss-logging-3.0.0.Beta4.jar in GlassFish 3.1 b37(glassfish-3.1-b37-01_07_2011.zip).

When I put seam-solder-3.0.0.Beta1.jar and jboss-logging-3.0.0.Beta4.jar into WEB-INF\lib, the server.log is:

[#|2011-01-11T12:38:58.250+0800|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=35;_ThreadName=Thread-1;|Exception while loading the app : WELD-001408 Unsatisfied dependencies for type [ELContext] with qualifiers [@Default] at injection point [[parameter 1] of [constructor] @Inject public org.jboss.seam.solder.el.Expressions(ELContext, ExpressionFactory)]
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [ELContext] with qualifiers [@Default] at injection point [[parameter 1] of [constructor] @Inject public org.jboss.seam.solder.el.Expressions(ELContext, ExpressionFactory)]
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:305)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:139)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:162)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:385)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:371)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:390)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:189)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:298)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:354)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:369)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1080)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1260)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1248)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:453)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:220)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:818)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]

When I put seam-solder-3.0.0.Beta1.jar, seam-faces-3.0.0.Beta2.jar and jboss-logging-3.0.0.Beta4.jar into WEB-INF\lib, the server.log is:

[#|2011-01-11T12:32:42.484+0800|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=60;_ThreadName=Thread-1;|ViewDataStore
java.lang.ClassNotFoundException: ViewDataStore
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1518)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1368)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at org.glassfish.web.loader.WebappClassLoader.findClass(WebappClassLoader.java:925)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1485)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1368)
at org.glassfish.weld.BeanDeploymentArchiveImpl.handleEntry(BeanDeploymentArchiveImpl.java:331)
at org.glassfish.weld.BeanDeploymentArchiveImpl.collectJarInfo(BeanDeploymentArchiveImpl.java:324)
at org.glassfish.weld.BeanDeploymentArchiveImpl.populate(BeanDeploymentArchiveImpl.java:287)
at org.glassfish.weld.BeanDeploymentArchiveImpl.<init>(BeanDeploymentArchiveImpl.java:130)
at org.glassfish.weld.DeploymentImpl.<init>(DeploymentImpl.java:113)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:333)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:99)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:249)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:460)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:354)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:369)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1080)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1260)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1248)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:453)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:220)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:818)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]
Comment by ratking [ 10/Jan/11 ]

You can download the two jar files (seam-solder-3.0.0.Beta1.jar and seam-faces-3.0.0.Beta2.jar ) from http://www.seamframework.org/Seam3/DistributionDownloads

In the jar file seam-faces-3.0.0.Beta2.jar, the class file do exists: org\jboss\seam\faces\viewdata\ViewDataStore.class

Comment by janlisse [ 20/Jan/11 ]

I am facing the same error as ratking using glassfish 3.1b38:
ClassNotFoundException: ViewDataStore
Obviously there are still classloading issues there (the class ViewDataStore IS present inside seam-faces-3.0.0.Beta2.jar). Can you reopen the issue?

Comment by ratking [ 20/Feb/11 ]

Now, I have download glassfish-3.1-b43-ml.zip(i.e. RC4, 93 MB, http://dlc.sun.com.edgesuite.net/glassfish/3.1/promoted/) and seam-3.0.0.Beta2.zip(17.7 MB, http://sourceforge.net/projects/jboss/files/Seam/3/3.0.0.Beta2/).

After several test, I can run Seam Solder 3.0.0.Beta4 & Seam Faces 3.0.0.Beta3 & Seam Persistence 3.0.0.Beta4 in a Java EE 6 web project with GlassFish-3.1-b43 (and NetBeans IDE 6.9.1).

What needs to be pointed out is that slf4j-api-1.5.11.jar & logback-core-0.9.20.jar & logback-classic-0.9.20.jar must in the WEB-INF\lib directory in my case. But the slf4j-api-1.5.8.jar or slf4j-api-1.6.1.jar is incompatible.

This is a good news





[GLASSFISH-13928] Massive @RequestScoped @SessionScoped memory leak Created: 12/Oct/10  Updated: 01/Dec/10  Resolved: 01/Dec/10

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

Type: Bug Priority: Blocker
Reporter: abien Assignee: Sivakumar Thyagarajan
Resolution: Fixed Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Attachments: File reproducer_.tiff     PNG File Screenshot-2.png     Text File Testplan.jmx     Zip Archive WeldLeakReproducer.zip    
Issuezilla Id: 13,928

 Description   

Tested with: GlassFish Server Open Source Edition 3.1-b23 (23), Glassfish 3.0.1 and even JBoss 6m5

A @RequestScoped / @SessionScoped managed bean referenced from a JSF 2, causes memory leaks:

<h:body>
#

{index.message}

</h:body>

@Named
@RequestScoped //or @SessionScoped
public class Index {
public String getMessage()

{ return "Hugo " + System.currentTimeMillis(); }

}



 Comments   
Comment by abien [ 12/Oct/10 ]

Created an attachment (id=5124)
Screenshot Memory Leak

Comment by abien [ 12/Oct/10 ]

Created an attachment (id=5125)
NetBeans Reproducer Project

Comment by abien [ 12/Oct/10 ]

Created an attachment (id=5126)
JMeter Load Script

Comment by Alexis MP [ 12/Oct/10 ]

cc

Comment by rogerk [ 12/Oct/10 ]

assign

Comment by nwegner [ 12/Oct/10 ]
      • Issue 13928 has been confirmed by votes. ***
Comment by abien [ 13/Oct/10 ]

Just performed further tests. This problem is independent from the EL #{} expression. It is actually
sufficient to combine the JSF 2 and beans.xml to see the leak.

Comment by Sivakumar Thyagarajan [ 13/Oct/10 ]

Need to investigate this further. Targetting fix for MS7.

Comment by Sivakumar Thyagarajan [ 01/Dec/10 ]

Screenshot showing the heapmemory usage when the application was deploy/use/undeploy 100 times

Comment by Sivakumar Thyagarajan [ 01/Dec/10 ]

With the latest integration of Weld 1.1.0.BETA2, a corresponding fix in Javassist and other GlassFish integration side changes [see GLASSFISH-12368 for more information], most of the perm-gen and heap memory leaks are gone. We also closed two GlassFish related issues (GLASSFISH-14803 and GLASSFISH-14801) which were holding the application classloader from being GC'ed.

With latest GlassFish trunk, I was able to exercise the deploy/use/undeploy cycle on the provided application 100 times (attached screenshot shows memory usage and saw know no major leak in heap or perm-gen space. I also did an analysis on Eclipse Memory Analyzer tool and did not find the application classloader or corresponding objects being held after the run. So, I am closing this issue. Please reopen or raise a new issue should you still see the memory leaks





[GLASSFISH-12393] JMS ConnectionFactory injection using CDI does not happen Created: 28/Jun/10  Updated: 06/Sep/10  Resolved: 06/Sep/10

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

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

Operating System: All
Platform: All


Attachments: Zip Archive bug.zip    
Issuezilla Id: 12,393

 Description   

I have two projects - TestWeb that has a TestServlet that test injection of
resources that are produced by JMSResourcesProducer in a dependency jar -
TestBeanArchive.
The CDI producer produces javax.jms.Queue and javax.jms.Session, like this:

@ApplicationScoped
public class JMSResourcesProducer {

@Resource(mappedName = "jms/ConnectionFactory")
private ConnectionFactory connectionFactory;

@SuppressWarnings("unused")
@Produces
@ApplicationScoped
@Resource(mappedName = "jms/Queue")
private Queue queue;

@Produces
public Session produceSession() throws JMSException {
/*try

{ connectionFactory = (ConnectionFactory) new javax.naming.InitialContext().lookup("jms/ConnectionFactory"); }

catch (javax.naming.NamingException exc)

{ throw new RuntimeException("couldn't lookup JMS Session", exc); }

*/
// as per EJB 3.1 specs $13.3.5
return connectionFactory.createConnection().createSession(true, 0);
}
}

Note that the Queue is injected using @Resource, and is itself a producer field,
whereas the ConnectionFactory is injected using @Resource, and used in a
producer method to create queues.

The problem: the connection factory is not injected, no error during deployment,
no nothing - upon invoking the test servlet I simply get a NPE as if the
connectionFactory field is never processed. If I uncomment the JNDI lookup, it
works fine, which proves that the server resources are configured correctly.

In another web project (TestWebAll) I package the servlet and the producer
together, and then it works. This proves that there must be some problem with
CDI / JMS combo when producers are in a separate jar.

I am setting high priority as this prevents us from using JMS and having it
injected using CDI.

Tested against 3.0.1 build 22.



 Comments   
Comment by szczyp [ 28/Jun/10 ]

Created an attachment (id=4510)
test case

Comment by szczyp [ 28/Jun/10 ]

The attached bug.zip contains:

  • complete source code for TestWeb, TestWebAll and TestBeanArchive (Eclipse 3.6
    final projects)
  • war archives for TestWeb and TestWebAll
Comment by szczyp [ 28/Jun/10 ]

Please note that you need to add to resources to the server:
JMS connection factory with the name 'jms/ConnectionFactory'
and
JMS queue with the name 'jms/Queue'

Comment by rogerk [ 28/Jun/10 ]

Assign to Siva

Comment by jhasenbe [ 29/Jun/10 ]

Add me on CC

Comment by jhasenbe [ 29/Jun/10 ]
      • Issue 12393 has been confirmed by votes. ***
Comment by Sivakumar Thyagarajan [ 06/Sep/10 ]

Hi szczyp

Sorry for getting to this late. I tried reproducing this issue in latest
glassfish (3.1) promoted build [glassfish-3.1-b18.zip] and can't seem to
reproduce this. With both TestWeb.war and TestWebAll.war, I see the following
when I visit http://localhost:4848/test

Queue injected: true
Session injected: true

Could you let me know if you can still reproduce this issue with the latest build?

Thanks.

Comment by szczyp [ 06/Sep/10 ]

Unfortunately, I can't. We had to freeze the Glassfish version that we use to
build 10. This is the last one that works for us; starting with build 11 we are
experiencing this:
http://forums.java.net/jive/message.jspa?messageID=479006
and as nobody answered this topic, looks like we are the only ones. The error is
cryptic enough, I tried to look into it, but I gave up and we are are living
with build 10.
It's not good, though, as this means new fixes (like the one that you suggest,
with this issue) are unavailable to us.

Comment by Sivakumar Thyagarajan [ 06/Sep/10 ]

Thanks for the quick response. I have responded to the forum thread requesting
an issue to be filed. This might be as a result of a new Weld integration we had
done around b10.

As for this issue, I would close it then. Please feel free to open if this issue
hits you again on a fresh build.

FYI: I have also added a couple of developer tests [1] to exercise this scenario
so that we can track this. Thanks.

--Siva
[1]
https://svn.dev.java.net/svn/glassfish-svn/trunk/v2/appserv-tests/devtests/cdi/javaee-component-resources/jms-resource-producer-field-in-library-jar
and
https://svn.dev.java.net/svn/glassfish-svn/trunk/v2/appserv-tests/devtests/cdi/javaee-component-resources/jms-resource-producer-field





[GLASSFISH-10790] ConversationScope not working Created: 03/Nov/09  Updated: 05/Nov/09  Resolved: 05/Nov/09

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

Type: Bug Priority: Blocker
Reporter: mcorey Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 10,790

 Description   

I'm trying to create a simple ConversationScope example with build 70, and a
very simple example is giving me a NoClassDefFoundException on
javassist.util.proxy.ProxyObject... I have made no modifications of the server,
and the code is quite simple:

@Stateful
@Named
@ConversationScoped
public class EditUserFacade implements Serializable {
@Inject
private Conversation conversation;

@Inject
private transient UserRepository repository;

private long userId;
private User user;

public void loadUser()

{ conversation.begin(); user = repository.get(userId); }

public String editUser()

{ repository.merge(user); conversation.end(); return "viewUser?userId="+userId+"&faces-redirect=true"; }

...

The full stack trace is:

java.lang.RuntimeException: by java.lang.NoClassDefFoundError:
javassist/util/proxy/ProxyObject
at javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:344)
at javassist.util.proxy.ProxyFactory.createClass2(ProxyFactory.java:314)
at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:273)
at
org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:84)
at
org.jboss.weld.bean.proxy.ClientProxyProvider.access$000(ClientProxyProvider.java:41)
at
org.jboss.weld.bean.proxy.ClientProxyProvider$1.call(ClientProxyProvider.java:122)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
org.jboss.weld.util.collections.ConcurrentCache.putIfAbsent(ConcurrentCache.java:125)
at
org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:112)
at org.jboss.weld.BeanManagerImpl.getReference(BeanManagerImpl.java:890)
at org.jboss.weld.BeanManagerImpl.getReference(BeanManagerImpl.java:910)
at org.jboss.weld.bean.builtin.facade.InstanceImpl.get(InstanceImpl.java:68)
at org.jboss.weld.bean.builtin.facade.InstanceImpl.get(InstanceImpl.java:74)
at
org.jboss.weld.conversation.ServletConversationManager.getBeanStore(ServletConversationManager.java:60)
at
org.jboss.weld.conversation.AbstractConversationManager.cleanupConversation(AbstractConversationManager.java:150)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.jboss.weld.bean.proxy.ClientProxyMethodHandler.invoke(ClientProxyMethodHandler.java:111)
at
org.jboss.weld.conversation.ServletConversationManager_$$javassist_13.cleanupConversation(ServletConversationManager$$_javassist_13.java)
at
org.jboss.weld.jsf.WeldPhaseListener.afterRenderResponse(WeldPhaseListener.java:128)
at org.jboss.weld.jsf.WeldPhaseListener.afterPhase(WeldPhaseListener.java:99)
at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:189)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:107)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:311)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:332)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:233)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:161)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:789)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:697)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:952)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:166)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:619)
Caused by: javassist.CannotCompileException: by java.lang.NoClassDefFoundError:
javassist/util/proxy/ProxyObject
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:169)
at javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:339)
... 51 more
Caused by: java.lang.NoClassDefFoundError: javassist/util/proxy/ProxyObject
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javassist.util.proxy.FactoryHelper.toClass2(FactoryHelper.java:181)
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:163)
... 52 more
Caused by: java.lang.ClassNotFoundException: javassist.util.proxy.ProxyObject
at
org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:738)
at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:60)
at
org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1650)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
... 59 more



 Comments   
Comment by pmuir [ 04/Nov/09 ]

Some notes from a discussion between Jason Greene, Jerome Dochez, Paul Sandoz,
Roger Kitain and myself outlining the issue and possible ways forward:

  • AFAIK Javassist is not tested to run in an OSGi container (Pete)
  • Javasssit team will welcome patches for this I am sure, if you need
    introductions, please chat to me or Jason (Pete)

Jason described this workaround that GlassFish could implement, given the
current code:

The classloader that holds the proxy definition should be able to see javassist.
There are a number of ways to do that. One way would be to define proxy classes
directly in the classloader that contains jersey. Another way would be to have a
classloader which just holds proxies for that module.

More specifically what I mean in the latter approach is that the glassfish
integration code would:

1) Construct a new classloader with the module classloader as its parent, and a
an OSGi import that contains javassist (and any other deps). Although, you don't
have to use OSGi for such a loader. The base loader could be OSGi, and your
child could be some special loader, it doesn't really matter. The thing to look
out for here, is that the proxies are in a classloader that is associated with
the module. If you support any form of module isolation, then you can't put them
in one global classloader (javassist classloader).

2) This classloader is passed via classLoaderProvider as Pete recommends

3) This classloader is then tied to the module lifecycle, such that it is
properly cleaned.

Jerome commented:

It comes back to what I was suggesting. I think you need to delegate to 2
classloaders, the module (container the base class) classloader and the
javassist module. Santiago, you could look at DelegatingClassLoader in
internal-api module to help you with that.

Comment by Alexis MP [ 04/Nov/09 ]

cc

Comment by rogerk [ 05/Nov/09 ]

Hello.
Any chance you can attach a more complete test case (maybe a war)?
I created a class using your code snippet (minus the application related stuff
like UserRepository and User), included it in an existing war and was able to
deploy without exception. I don't consider this enough to make a decision as to
whether the problem has been addressed (I don't think it has).

Comment by rogerk [ 05/Nov/09 ]

We have fxed this in the glassfish integration code and will be available in the
next integration. I've verified the fix by including Conversations in a webapp.





[GLASSFISH-10192] Support jsr299 (weld) for ear files Created: 12/Oct/09  Updated: 27/Nov/10  Resolved: 27/Oct/09

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

Type: New Feature Priority: Blocker
Reporter: rogerk Assignee: Sanjeeb Sahoo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Attachments: Text File webbeans-translator.ear    
Issuezilla Id: 10,192

 Description   

I've hit another classloader issue for ear deployment in Weld application. The
gist of the problem is as follows.
The ear container two modules:

  • jar (ejb)
  • war
    Both of these are 299 enabled modules.
    Our deployer.load() method gets called for each module.
    The jar module is handled first, and at that point, GlassFish
    DeploymentContext.getContextClassloader() is: EJBClassloader
    The war module is handled next, and the GlassFish
    DeploymentContext.getContextClassloader() is: WebappClassLoader

After the deployer.load() method is called for these two modules (we listen for
APPLICATION_LOADED event),
we call WebBeansBootstrap.startContainer(). This internally adds EJBClassLoader
to the internal store (TCCLSingletonProvider).

After the application is deployed, and we attempt to visit the application
(localhost:8080....), it's expecting a WebappClassLoader
in this internal store - but only EJBClassLoader is there. We end up with the
exception:

WARNING: StandardContextValve[/webbeans-translator]: PWC1321: Error invoking
requestInitialized method on ServletRequestListener
org.jboss.webbeans.servlet.WebBeansListener
java.lang.IllegalStateException: Singleton not set for WebappClassLoader
(delegate=true; repositories=WEB-INF/classes/)
at
org.jboss.webbeans.bootstrap.api.helpers.TCCLSingletonProvider$TCCLSingleton.get(TCCLSingletonProvider.java:60)
at org.jboss.webbeans.Container.instance(Container.java:52)
at
org.jboss.webbeans.servlet.WebBeansListener.requestInitialized(WebBeansListener.java:118)

I would think that in this case, that internal store should contain two entries -
onc for EJBClassLoader and one for WebappClassLoader.



 Comments   
Comment by rogerk [ 12/Oct/09 ]

Created an attachment (id=3496)
Ear file

Comment by Sanjeeb Sahoo [ 23/Oct/09 ]

Starting.

Comment by Sanjeeb Sahoo [ 27/Oct/09 ]

Sending weld-integration/osgi.bundle
Sending weld-integration/pom.xml
Adding
weld-integration/src/main/java/org/glassfish/weld/ACLSingletonProvider.java
Sending weld-integration/src/main/java/org/glassfish/weld/WeldActivator.java
Transmitting file data ....
Committed revision 33360.





[GLASSFISH-11653] WAR packaging, CDI lookup of JPA unit fails when in separate jars Created: 08/Mar/10  Updated: 24/Oct/10  Resolved: 24/Oct/10

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

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

Operating System: All
Platform: All


Attachments: Zip Archive test.zip     Zip Archive test.zip     File TestWEB.war     Zip Archive TestWeb.zip     Text File web-descriptor-combine-patch.diff     Zip Archive weld_bug.zip    
Issuezilla Id: 11,653

 Description   

I have 3 modules:
1. JPA module
2. EJB module with META-INF/beans.xml, with 2 EJBs: one uses @Inject to inject
EntityManager to an EJB, another using @PersistentContext; there is a class with
a producer field annotated @Produces @PersistentContext to adapt 'old-style'
resource injection to CDI
3. webapp that bundles the modules in WEB-INF/lib as siblings, and contains a
servlet that uses EJBs from module #2, injected by @EJB

Invoking the bean that uses @Inject to inject EntityManager results in this at
runtime:

org.jboss.weld.NullInstanceException: WELD-000044 Unable to obtain instance from
org.jboss.weld.bean-/home/rafal/Apps/glassfishv3/glassfish/domains/domain1/applications/TestWEB/-ProducerField-com.test.ejb.EntityManagerProducer.entityManager

Sibling EJB in module #2 that uses @PersistenceContext for injection works fine,
so the JPA unit is deployed correctly and can be found.

When all classes / resources are packaged inside WEB-INF/classes, all works
fine. However, this puts big restrictions on application packaging and doesn't
support what the specs mandates (CDI and JPA modules within WEB-INF/lib of a WAR).

Setting this to P1 as this prevents us from packaging and deploying the
application using the new WAR deployment.

A post about the issue can be found here:
http://forums.java.net/jive/thread.jspa?threadID=75932&tstart=75



 Comments   
Comment by jpleed3 [ 08/Mar/10 ]

Is this a duplicate of or related to
https://glassfish.dev.java.net/issues/show_bug.cgi?id=11640?

Comment by jhasenbe [ 08/Mar/10 ]

Add me on CC

Comment by szczyp [ 08/Mar/10 ]

I am not sure, the author there writes that if the producer and the injection
point are in the same module, it works. My producer and injection points are in
the same ejb.jar, and it still doesn't work for. The class that produces the JPA
context is not an EJB though, but the specs don't require that. I would say it
is not the same, but related.
The error number and runtime behavior looks exactly the same, though.

Later I will upload my application as I don't have it handy right now, so that
it can be tested.

Comment by szczyp [ 08/Mar/10 ]

I re-read the topic by the author of
https://glassfish.dev.java.net/issues/show_bug.cgi?id=11640 and I saw this:
"If I move the producer and qualifier into the war's classes, then @Dependent
works fine."
This would imply that the EJBs / managed beans are in WEB-INF/classes. Mine are
in a separate ejb.jar. I wrote in the initial bug report that when I package
everything in WEB-INF/classes, it works. Packaging every module as a separate
jar inside WEB-INF/libs is the problem for us, as this is how our application is
structured - the webapp will only contain basic servlet(s) that use(s) beans
from other modules.

Comment by szczyp [ 08/Mar/10 ]

Created an attachment (id=4257)
test case

Comment by szczyp [ 08/Mar/10 ]

Added the test case.
Notes:

  • these are 3 Eclipse project (developed in 3.6 M5)
  • JPA unit uses the default 'jdbc/__default' DataSource, and specifies that the
    database schema be created on start, so making sure the bundled JavaDB is
    running should be enough to be able to start the app
  • when deployed and run from Eclipse, the context root is 'web' and there is a
    welcome file 'test'; also the only servlet is mapped to '/test', so going to
    'http://localhost:8080/web' should work
  • the servlet presents 2 links: 'plain' and 'cdi', and after clicking the link
    it uses the chosen @EJB; 'plain' uses @PersistentContext and 'cdi' uses @Inject
  • the producer and injection point have no qualifier by default, but I also
    created one that I commented out - using it doesn't change anything, I just
    wanted to test it
  • the 'plain' bean works fine, 'cdi' results in an error mentioned in the
    initial bug report

Hope it is helpful.

Comment by rogerk [ 08/Mar/10 ]

Can you please provide built archive(s) (war/jar/ear)?
Thanks for providing source.

Comment by szczyp [ 09/Mar/10 ]

Created an attachment (id=4260)
war file

Comment by szczyp [ 09/Mar/10 ]

I attach the war file.
As additional input, it has been tested on a Linux machine (Ubuntu 9.04 x86-64)
and multiple windows machines (one Windows Vista, 3 distinct XPs, all x86).

Comment by rogerk [ 10/May/10 ]

3.1

Comment by domdorn [ 11/May/10 ]

Created an attachment (id=4350)
Another example webapp;

Comment by rogerk [ 11/May/10 ]

Hello Siva -

Can you take a look at this issue?

Comment by szczyp [ 11/May/10 ]

Hi. I just noticed that this issue is rescheduled to 3.1; I also took a peek at
the roadmap, and I am very surprised - 3.1 has scheduled 'Go / No go' on
14.12.2010 - a long time from now.
Don't you think that providing a working version of CDI should be done sooner?
CDI seems and feels a crucial part of the new Java EE 6 ecosystem, has been
announced 'the next big thing' and is considered to be just that by many. But it
doesn't work. I am a little afraid to use such big words, and I don't want to
offend anyone, but such CDI / Weld integration related bugs make 3 Final / 3.0.1
completely unusable. This also means that CDI would start working a year and 4
days after GF 3 has been first announced final.
This issue is of utmost importance for us, that's why I would humbly like to
rise the priority to what it was in the very beginning.
Regards.

Comment by rogerk [ 11/May/10 ]

OK fair enough. We will evaluate this and see if we can get it into 3.0.1.

Comment by jhasenbe [ 11/May/10 ]

Hi,
I can only add my strong support to the opinion expressed by szczyp.
Being able to deploy a JEE 6 application with regular CDI stuff to Glassfish
seems like a natural thing and one of the big promises of JEE 6.
We have already planned for such an application to become productive by
September this year with GF 3.0 (assuming that GF acting as reference
implementation for JEE 6 is way ahead of competitors). Waiting for GF to become
available is not an option and we would be sadly forced to look for other
container providers and drop GF for the time being. I personally would love to
see GF 3.0 fulfill our requirements which are just plain simple Java EE 6 support.
For the time being, we can work around the described CDI integration bug. But if
you move the bug fix to GF 3.1, I am really sorry to say that we would need to
drop GF as deployment option.

So please do consider moving a fix to 3.0. If we can be of any help, please let
us know.

Thanks a lot and best regards,
jhasenbe

Comment by choicegh [ 11/May/10 ]

I too would like to see this issue be fixed much sooner rather than later. This
is basic JEE6 functionality. I am now having to develop in an alternate manner
to work around this when I should not have to.

Comment by Hong Zhang [ 19/May/10 ]

szczyp: you mentioned when packaging everything in WEB-INF/classes, it worked.
Can you share the application packaged that way? I was trying to repackage the
application by putting everything under WEB-INF/classes (I wanted to compare the
code paths to see why one worked and the other did not work), and the repackaged
application did not work for me either. Wondering what I did differently in the
repackaging.

Comment by Hong Zhang [ 19/May/10 ]

add myself to Cc

Comment by szczyp [ 20/May/10 ]

Created an attachment (id=4365)
working war packaging

Comment by szczyp [ 20/May/10 ]

I added the working war packaging requested. The zip contains the exported (in
Eclipse) WAR and the source code.
I didn't do much really - it is enough to simply move the source packages from
TestJPA and TestEJB to TestWEB and it works for me.

Comment by szczyp [ 21/May/10 ]

Created an attachment (id=4372)
corrected test case

Comment by szczyp [ 21/May/10 ]

Hi again. I am sorry, but the previous test case didn't work. I hasted it a
little bit. This one should do it.
The problem were the descriptor files:
persistence.xml must be in WEB-INF/classes/META-INF (strange path, but dictated
by the specs)
beans.xml must be in WEB-INF

Now this should work.
Sorry for the previous attachment.

Comment by Sivakumar Thyagarajan [ 21/May/10 ]

Thanks szczyp for reporting the issue and providing a good test-case to reproduce
the issue. While debugging this issue I found out that we successfully process
the EntityManagerReference related InjectionTarget but still miss it later. This
has been found to be due to an error while we merge
EntityManagerReferenceDescriptors in WebFragmentDescriptors and have a patch that
fixes this issue. With this change, the application in the bug report works
fine(Injection of EntityManager and the producer field for CDI are working).

This issue would now be fixed in 3.0.1 and in the trunk. Thanks again for all
your support in this issue

Comment by Sivakumar Thyagarajan [ 21/May/10 ]

Created an attachment (id=4373)
Patch to fix this issue

Comment by szczyp [ 22/May/10 ]

Hi. Thank you for looking into this.
I downloaded, however, glassgish 3.0.1.snapshot from here:
http://dlc.sun.com.edgesuite.net/glassfish/v3.0.1/nightly/glassfish-3.0.1-b19-05_21_2010.zip
dating to May 21., but this build was created after the comment about fixing the
issue (right after I read the comment I wanted to test it and the last build was
May 2., so it wasn't there yet.
Is it supposed to work in the snapshot already?

Comment by szczyp [ 22/May/10 ]

I meant to say that right after the comment the latest build was May 20., so May
21. was created after the comment. Sorry for the typo.

Comment by Sivakumar Thyagarajan [ 22/May/10 ]

szczyp: Please use Sunday's nightly for verifying the fix. I had checked in the
fix into the trunk and the 3.0.1 branch only today [commit revisions 37186 and
37185]. If you want a fix earlier than that, you can apply the patch or check
out latest workspace and build. Hope this helps.

Closing this issue as fixed as we checked in the patch as part of commit
revisions 37186 and 37185.

Comment by szczyp [ 26/May/10 ]

I tested it today and it works fine with the build from 25.05.
Thanks for the effort to fix it.

Comment by Sivakumar Thyagarajan [ 24/Oct/10 ]
      • Issue 11640 has been marked as a duplicate of this issue. ***




[GLASSFISH-15660] [Regression] Ambiguous dependencies for Session Beans Created: 23/Jan/11  Updated: 26/Jan/11  Resolved: 26/Jan/11

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

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

Ubuntu Linux 10.04, JDK 1.6.0_22


Attachments: File cdi-bug.war     File GLASSFISH-15660.diff    
Issue Links:
Duplicate
duplicates GLASSFISH-15682 Programmatically injection of Statefu... Resolved
Tags: 3_1-approved, 3_1-fishcat, 3_1-regression

 Description   

There seems to be a new bug in the latest version of Weld: Session beans from CDI-enabled EJB JARs are registered twice, both as sessions beans and as managed beans, causing exceptions of the following kind:

Caused by: org.jboss.weld.exceptions.AmbiguousResolutionException:
WELD-001318 Cannot resolve an ambiguous dependency between
[Managed Bean [class com.blogspot.hwellmann.cdi.InjectedService] with qualifiers [@Any @Default],
Session bean [class com.blogspot.hwellmann.cdi.InjectedService with qualifiers [@Any @Default]; local interfaces are [InjectedService]]

Simple example to reproduce the problem:

------------------

package com.blogspot.hwellmann.cdi;

import javax.ejb.Stateless;

@Stateless
public class InjectedService {

public void doSomething()

{ System.out.println("********* injected method *********"); }

}

----------------------

package com.blogspot.hwellmann.cdi;

import javax.annotation.PostConstruct;
import javax.ejb.Singleton;
import javax.ejb.Startup;
import javax.inject.Inject;

@Singleton
@Startup
public class ClientService {

@Inject
private InjectedService injected;

@PostConstruct
public void execute()

{ injected.doSomething(); }

}

Build a service.jar with these two classes, adding an empty META-INF/beans.xml.
Then build an almost empty WAR, containing this service.jar in WEB-INF/lib.

The WAR fails to deploy with the above exception. The problem does not occur when the two classes are directly in WEB-INF/classes and not in an embedded JAR.

This is a regression from 3.1-b33 where the same WAR can be deployed successfully.



 Comments   
Comment by Harald Wellmann [ 23/Jan/11 ]

Attached example WAR to reproduce the problem.

Comment by Sivakumar Thyagarajan [ 25/Jan/11 ]
  • 3.1 Change Control related questionnaire
  • How bad is its impact? (Severity)
    Is a regression of functionality or performance available in a prior release
  • How often does it happen? (Frequency)
    Rarely
  • How much effort is required to fix it? (Cost)
    Fix available and attached in issue
  • What is the risk of fixing it? (Risk)
    Not significant. I ran CDI devtests, TCK, other test scenarios to ensure that there are no regressions.
  • Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
    Yes, the application can be re-packaged such that the EJBs are bundled in the WAR instead of the bundled library under WEB-INF/lib
  • If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
    Yes.
Comment by Sivakumar Thyagarajan [ 25/Jan/11 ]

Analysis:

  • EJBs bundled within the bundled library in the WAR (jar in WEB-INF/lib) was represented as EJBs of the WAR BDA to Weld. The EJBs were represented as Bean classes in the WEB-INF/lib jar BDA. So, Weld understood the EJB as both a ManagedBean and an EJB, and hence deployment failed with an Ambiguous Resolution exception.

Fix involved ensuring that the WEB-INF/lib jar BDA has the EJB Class represented as EJBs and the Bean classes of that BDA.

Comment by Sivakumar Thyagarajan [ 25/Jan/11 ]

Proposed diff to fix the issue.

Comment by Chris Kasso [ 25/Jan/11 ]

Approved for 3.1

Comment by Harald Wellmann [ 25/Jan/11 ]

Thanks for fixing this so quickly! Just a small note on the patch: I don't know about official Glassfish policies, but I'd rather use log.debug() instead of System.out.println(), or simply delete these statments, if they were just intended for testing the fix.

Comment by Sivakumar Thyagarajan [ 26/Jan/11 ]

Harald: Yes the system.outs were just debug statements for testing the fix. I would convert them to property log statements prior to the commit.

Comment by Sivakumar Thyagarajan [ 26/Jan/11 ]

Fixed as part of
$ svn commit .
Sending weld-integration/src/main/java/org/glassfish/weld/BeanDeploymentArchiveImpl.java
Sending weld-integration/src/main/java/org/glassfish/weld/BeanManagerNamingProxy.java
Sending weld-integration/src/main/java/org/glassfish/weld/WeldDeployer.java
Sending weld-integration/src/main/java/org/glassfish/weld/ejb/EjbDescriptorImpl.java
Sending weld-integration/src/main/java/org/glassfish/weld/services/JCDIServiceImpl.java
Transmitting file data .....
Committed revision 44711.





[GLASSFISH-15888] CDI not working well on Glassfish v3.1 RC1 and RC2 Created: 08/Feb/11  Updated: 29/Jul/11  Resolved: 11/Feb/11

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

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

Attachments: File test-cdi-war.war     Zip Archive TestCDI.zip     Java Archive File weld-osgi-bundle.jar    
Issue Links:
Duplicate
duplicates GLASSFISH-15721 "injection points in one bean deploym... Resolved
Tags: 3_1, 3_1_1-review, CDI, Glassfish

 Description   

Up until a couple of weeks ago I worked with Glassfish 3.0. Recently, I decided to upgrade to v3.1. The first version I tried was v3.1 b35. This version seemed to work more or less OK, but there were a couple of problems in it:

1. @Resource doesn't work (I later found this: http://java.net/jira/browse/GLASSFISH-15443?page=com.atlassian.streams.streams-jira-plugin%3Aactivity-stream-issue-tab)

2. My log messages disappeared (I use SLF4J and GF was redirecting my log messages to its logger)

So then I decided to install the release candidate. I installed v3.1 b41 (RC2) and in this version it seems that CDI stopped working completely! The same code worked perfectly well on v3.1 b35. I then tried it also on v3.1 b40 and had the same results.

I experience the following problems:

1. I have a two producer methods with qualifiers which return the EntityManager (according to the qualifier). In some of the DAOs (that use @Inject) CDI manages to find the producer method and in some it doesn't. I have no idea why it finds it in one and not in the other

2. I have jars that contains EJBs that don't use CDI at all, so they don't contain beans.xml. Now, CDI throws a NullPointerException during the attempt to deploy the war that contains them. If I put beans.xml in these jars the exception is not thrown

3. If I have two jars in the same war, and one is trying to inject an EJB from the other jar (using @Inject) it doesn't work. I have to add a producer method (I didn't have to in the previous versions)

All of this is code that has been working for a long time. Now I can't even deploy the first war.

Is this a known problem/unknown bug or has CDI gone through a major "behavior" change? Is there a way to change it back?



 Comments   
Comment by Chris Kasso [ 08/Feb/11 ]

Can the submitter provide a test case that demonstrates the issues? This will help us better understand how you are using the interfaces and get to the source of the problem.

Comment by ifatgv [ 09/Feb/11 ]

War that reproduces the problem

Comment by ifatgv [ 09/Feb/11 ]

Sources

Comment by ifatgv [ 09/Feb/11 ]

I attached a war (and its sources) that reproduce the problems.
This war successfully deploys on GF V3.1 b35, but fails to deploy on GF v3.1 40 and GF v3.1 41.

In this war I managed to reproduce at least two of the problems:

1. Some of the times I got this exception:

[#|2011-02-09T19:03:30.390+0200|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=113;_ThreadName=Thread-1;|Exception while invoking class org.glassfish.ejb.startup.EjbApplication start method
javax.ejb.EJBException: javax.ejb.CreateException: Initialization failed for Singleton InitializationBean
at com.sun.ejb.containers.AbstractSingletonContainer$SingletonContextFactory.create(AbstractSingletonContainer.java:719)
at com.sun.ejb.containers.AbstractSingletonContainer.instantiateSingletonInstance(AbstractSingletonContainer.java:449)
at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:216)
at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:177)
at org.glassfish.ejb.startup.SingletonLifeCycleManager.doStartup(SingletonLifeCycleManager.java:155)
at org.glassfish.ejb.startup.EjbApplication.start(EjbApplication.java:177)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:286)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:354)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:369)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1080)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1260)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1248)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:453)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:220)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.ejb.CreateException: Initialization failed for Singleton InitializationBean
at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:545)
at com.sun.ejb.containers.AbstractSingletonContainer.access$100(AbstractSingletonContainer.java:79)
at com.sun.ejb.containers.AbstractSingletonContainer$SingletonContextFactory.create(AbstractSingletonContainer.java:717)
... 36 more
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:144)
at org.glassfish.weld.services.JCDIServiceImpl.createJCDIInjectionContext(JCDIServiceImpl.java:121)
at com.sun.ejb.containers.BaseContainer.createEjbInstanceAndContext(BaseContainer.java:1636)
at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:487)
... 38 more

#]

Initialization bean is a simple EJB that doesn't use CDI at all, so it doesn't have beans.xml.
For some reason, org.jboss.weld.manager.BeanManagerImpl tries to look for it at some point in a map of enterprise beans. Since it's not there, a NullPointerException is thrown.
Adding beans.xml to the jar solves this problem.

2. The other times I got this exception:

[#|2011-02-09T19:00:31.812+0200|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=89;_ThreadName=Thread-1;|Exception while invoking class org.glassfish.ejb.startup.EjbApplication start method
javax.ejb.EJBException: javax.ejb.CreateException: Initialization failed for Singleton ZzBean
at com.sun.ejb.containers.AbstractSingletonContainer$SingletonContextFactory.create(AbstractSingletonContainer.java:719)
at com.sun.ejb.containers.AbstractSingletonContainer.instantiateSingletonInstance(AbstractSingletonContainer.java:449)
at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:216)
at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:177)
at org.glassfish.ejb.startup.SingletonLifeCycleManager.doStartup(SingletonLifeCycleManager.java:155)
at org.glassfish.ejb.startup.EjbApplication.start(EjbApplication.java:177)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:286)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:354)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:369)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1080)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1260)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1248)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:453)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:220)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.ejb.CreateException: Initialization failed for Singleton ZzBean
at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:545)
at com.sun.ejb.containers.AbstractSingletonContainer.access$100(AbstractSingletonContainer.java:79)
at com.sun.ejb.containers.AbstractSingletonContainer$SingletonContextFactory.create(AbstractSingletonContainer.java:717)
... 36 more
Caused by: org.jboss.weld.exceptions.IllegalArgumentException: WELD-001324 Argument bean must not be null
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:744)
at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:138)
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:872)
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:884)
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1$1.proceed(ManagedBean.java:182)
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:54)
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1.work(ManagedBean.java:176)
at org.jboss.weld.bean.ManagedBean$FixInjectionPoint.run(ManagedBean.java:142)
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.inject(ManagedBean.java:170)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:339)
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:67)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:690)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:772)
at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:138)
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:872)
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:884)
at org.jboss.weld.bean.SessionBean$1$1.proceed(SessionBean.java:195)
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:54)
at org.jboss.weld.bean.SessionBean$1.inject(SessionBean.java:190)
at org.glassfish.weld.services.JCDIServiceImpl.injectEJBInstance(JCDIServiceImpl.java:198)
at com.sun.ejb.containers.BaseContainer.injectEjbInstance(BaseContainer.java:1675)
at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:504)
... 38 more

This happens because the CDI fails to inject the EntityManager to the DAO in ZzBean. I believe the injection succeeds in AaBean and BbBean (I didn't see it in this example, but I so it in our real code). Anyway, this injection worked fine in the previous versions

Comment by ifatgv [ 09/Feb/11 ]

A couple of things regarding the war:

1. You will need a datasource by the name: jdbc/ManagementDbConnectionPool
2. You will probably need to add the jars Hibernate uses to the war or to the domain's lib folder in order to deploy it

Comment by ifatgv [ 09/Feb/11 ]

Another important discovery, I replaced the following jars:

weld-integration.jar
weld-integration-fragment.jar
weld-osgi-bundle.jar

In the 40 build with the ones from the 35 build and I managed to deploy may wars

Comment by Sivakumar Thyagarajan [ 11/Feb/11 ]

The important change that happened in b37 (svn commit GLASSFISH-14808) was that bundled libraries in a WAR (WEB-INF/lib/*.jar) was represented (correctly) as separate accessible BeanDeploymentArchives(BDA) for the WAR BDA. Unfortunately Weld 1.1 Final (that was integrated into GlassFish) has an issue handling cyclic dependencies between BDAs – see https://issues.jboss.org/browse/WELD-846 for more information.

For instance in your scenario, we pass the following BDA hierarchy to Weld

[|ID: test-cdi-war, bdaType= WAR, accessibleBDAs #:21, [WEB-INF/lib/zz-use-persistence-1.0,WEB-INF/lib/persistence-1.0,WEB-INF/lib/bb-use-persistence-1.0,WEB-INF/lib/aa-use-persistence-1.0,,,,,,,,,,,,,,,,,,], Bean Classes #: 0,, ejbs=[]

---->ID: WEB-INF/lib/zz-use-persistence-1.0, bdaType= JAR, accessibleBDAs #:4, [WEB-INF/lib/persistence-1.0,WEB-INF/lib/bb-use-persistence-1.0,WEB-INF/lib/aa-use-persistence-1.0,test-cdi-war,], Bean Classes #: 3,[testcdi.bl.Zz, testcdi.bl.ZzBean, testcdi.dal.ZzDAO], ejbs=[testcdi.bl.ZzBean]
---->ID: WEB-INF/lib/persistence-1.0, bdaType= JAR, accessibleBDAs #:4, [WEB-INF/lib/zz-use-persistence-1.0,WEB-INF/lib/bb-use-persistence-1.0,WEB-INF/lib/aa-use-persistence-1.0,test-cdi-war,], Bean Classes #: 9,[testcdi.persistence.dao.BaseDAO, testcdi.persistence.dao.DAO, testcdi.persistence.dao.DataDbDAO, testcdi.persistence.dao.MngDbDAO, testcdi.persistence.exceptions.GeneralPersistenceException, testcdi.persistence.inject.DataDb, testcdi.persistence.inject.EntityManagerProducer, testcdi.persistence.inject.EntityManagerProvider, testcdi.persistence.inject.MngDb], ejbs=[]
---->ID: WEB-INF/lib/bb-use-persistence-1.0, bdaType= JAR, accessibleBDAs #:4, [WEB-INF/lib/zz-use-persistence-1.0,WEB-INF/lib/persistence-1.0,WEB-INF/lib/aa-use-persistence-1.0,test-cdi-war,], Bean Classes #: 3,[testcdi.bl.Bb, testcdi.bl.BbBean, testcdi.dal.BbDAO], ejbs=[testcdi.bl.BbBean]
---->ID: WEB-INF/lib/aa-use-persistence-1.0, bdaType= JAR, accessibleBDAs #:4, [WEB-INF/lib/zz-use-persistence-1.0,WEB-INF/lib/persistence-1.0,WEB-INF/lib/bb-use-persistence-1.0,test-cdi-war,], Bean Classes #: 3,[testcdi.bl.Aa, testcdi.bl.AaBean, testcdi.dal.AaDAO], ejbs=[testcdi.bl.AaBean]

While trying to handle the field injection point in ZZBean, the actual Bean that would satisfy the Bean though being available in the same BDA, is not considered as the cyclic dependency above prevents Weld from being able to discover the Bean to be injected correctly.

The only workaround for now in the 3.1 timeframe is to use the workaround mentioned in GLASSFISH-15721. (Extract all bean archives into WEB-INF/classes.

FWIW, Weld has fixed this issue in their trunk and this scenario would work again once we integrate the Weld 1.2.0.Beta distribution when it becomes available. I also tried your scenario against a local build of Weld trunk(attached the weld-osgi-bundle.jar that I used, place this under $INSTALL_ROOT/modules and restart the domain to reproduce this) and confirmed that the app deploys fine. So, marking this issue as a duplicate of GLASSFISH-15721.

Comment by Sivakumar Thyagarajan [ 11/Feb/11 ]

A custom build of Weld 1.1.0-SNAPSHOT trunk that contains the fix in https://github.com/stuartwdouglas/core/tree/WELD-846 that solves this issue.

Comment by Sivakumar Thyagarajan [ 11/Feb/11 ]

Duplicate of GLASSFISH-15721

Comment by ifatgv [ 14/Feb/11 ]

I'm sorry, but I don't think this issue is resolved.

The jar that was attached does not solve the prolem.

I installed a new GF v3.1 b40 (RC1) and replaced this jar. My test war still does not deploy (same exceptions). Deploying my real war makes GF get into an infinite loop! (this is new, so I know the jar made a change, but not a good one).

In order to check I did the following:

1. Stop the domain
2. Replace the jar in glassfish\glassfish\modules
3. Delete the folder glassfish\glassfish\domains\BTOA\osgi-cache
4. Start the domain
5. Deploy the war

Did I miss something?

If not, please reopen this issue.

Comment by vostok [ 15/Feb/11 ]

I'm experiencing the same problems too, using the latest promoted build found at http://dlc.sun.com.edgesuite.net/glassfish/3.1/promoted/latest-glassfish.zip

I'm using a multi-module layout in my project, just for the record, but it was being deployed w/o problems in GF 3.0.1

Comment by vrcollins [ 05/May/11 ]

I am having the same issue with version 3.1 build 43. I replaced the weld-osgi-bundle.jar included in this ticket. It did not correct the problem.

Comment by vrcollins [ 29/Jul/11 ]

This still does not seem to be working in version 3.1.1. Here is an example of my code

@Named("userSession")
@SessionScoped
public class UserSession implements Serializable {

private static final long serialVersionUID = -5357959580555377L;

@EJB(name = "VendorAccess")
private IVendorAccessLocal m_vendorAccess;

private OngVendor m_vendor = null;
private OngUser m_user = null;

/**

  • This will get the vendor name information that is associated with the
  • user.
  • @return String
    */
    public String getVendorName() { this.initialize(); return this.m_vendor.getVendorName(); }

protected void initialize()

{ HttpServletRequest request = ((HttpServletRequest) FacesContext.getCurrentInstance().getExternalContext().getRequest()); String host = request.getHeader("host"); host = host.substring(0, host.indexOf(":")); Map<String, OngVendor> v = this.m_vendorAccess.retrieveActiveVendors(); this.m_vendor = v.get(host); if (this.m_vendor == null) this.m_vendor = v.get("www"); }

m_vendor is a Singleton EJB. It shows that there is an object when stepping through the code. When the retrieveActiveVendors() method is called the following error occurs.

javax.ejb.NoSuchEJBException: Singleton VendorAccess is unavailable because its original initialization failed.
at com.sun.ejb.containers.AbstractSingletonContainer.checkInit(AbstractSingletonContainer.java:414)
at com.sun.ejb.containers.CMCSingletonContainer._getContext(CMCSingletonContainer.java:117)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2528)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1895)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy290.retrieveActiveVendors(Unknown Source)
at com.clss.base.session.UserSession.initialize(UserSession.java:122)
at com.clss.base.session.UserSession.getVendorName(UserSession.java:56)
at com.clss.base.session.org$jboss$weld$bean-ong-web-ManagedBean-class_com$clss$base$session$UserSession_$$WeldClientProxy.getVendorName(org$jboss$weld$bean-ong-web-ManagedBean-class_com$clss$base$session$UserSession$$_WeldClientProxy.java)
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 javax.el.BeanELResolver.getValue(BeanELResolver.java:302)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at com.sun.el.parser.AstValue.getValue(AstValue.java:116)
at com.sun.el.parser.AstValue.getValue(AstValue.java:163)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:219)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:55)
at com.sun.faces.facelets.el.ELText$ELTextVariable.writeText(ELText.java:224)
at com.sun.faces.facelets.compiler.TextInstruction.write(TextInstruction.java:85)
at com.sun.faces.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:82)
at com.sun.faces.facelets.compiler.UILeaf.encodeAll(UILeaf.java:184)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1759)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1759)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:401)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:134)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:290)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:290)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
at org.apache.catalina.core.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:596)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:330)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:726)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1020)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:91)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:56)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

This code works perfectly in Glassfish 3.0.1. Please fix this!





[GLASSFISH-20667] EAR deployment fails with WELD-001417: Enabled interceptor (...) is neither annotated @Interceptor nor registered through a portable extension Created: 26/Jun/13  Updated: 23/Sep/13  Resolved: 23/Sep/13

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

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

Windows 8
Glassfish 4 b89 (bundled with NetBeans 7.3.1)



 Description   

In a maven enterprise application with EJB and WEB modules, deployment fails if the EJB module declares a CDI interceptor.

Btw, implicit CDI is disabled. Not sure it matters.

The beans.xml in the EJB module:

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

Interceptor and binding:

@Interceptor @Bar
public class BarInterceptor implements Serializable {

    public BarInterceptor() {}
    
    @AroundInvoke
    public Object log(InvocationContext context) throws Exception {
        return context.proceed();
    }
    
    private static final long serialVersionUID = 1L;
}
@Inherited
@InterceptorBinding
@Retention(RUNTIME)
@Target({METHOD, TYPE})
public @interface Bar {}

Server log

[2013-06-26T20:17:10.522-0300] [glassfish 4.0] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=38 _ThreadName=admin-listener(4)] [timeMillis: 1372288630522] [levelValue: 1000] [[
  Exception during lifecycle processing
org.glassfish.deployment.common.DeploymentException: CDI deployment failure:WELD-001417 Enabled interceptor class <class>com.foo.BarInterceptor</class> in file:/E:/.../Interceptor-ear/Interceptor-ejb-1.0-SNAPSHOT_jar/META-INF/beans.xml@7 is neither annotated @Interceptor nor registered through a portable extension
	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-001417 Enabled interceptor class <class>com.foo.BarInterceptor</class> in file:/E:/.../Interceptor-ear/Interceptor-ejb-1.0-SNAPSHOT_jar/META-INF/beans.xml@7 is neither annotated @Interceptor nor registered through a portable extension
	at org.jboss.weld.bootstrap.Validator.validateEnabledInterceptorClasses(Validator.java:656)
	at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:482)
	at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:536)
	at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:216)
	... 36 more
]]
[2013-06-26T20:17:10.527-0300] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=38 _ThreadName=admin-listener(4)] [timeMillis: 1372288630527] [levelValue: 1000] [[
  Exception while loading the app]]
[2013-06-26T20:17:10.556-0300] [glassfish 4.0] [SEVERE] [AS-WEB-GLUE-00192] [javax.enterprise.web] [tid: _ThreadID=38 _ThreadName=admin-listener(4)] [timeMillis: 1372288630556] [levelValue: 1000] [[
  Undeployment failed for context /Interceptor-web]]
[2013-06-26T20:17:10.650-0300] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=38 _ThreadName=admin-listener(4)] [timeMillis: 1372288630650] [levelValue: 1000] [[
  Exception while loading the app : CDI deployment failure:WELD-001417 Enabled interceptor class <class>com.foo.BarInterceptor</class> in file:/E:/.../Interceptor-ear/Interceptor-ejb-1.0-SNAPSHOT_jar/META-INF/beans.xml@7 is neither annotated @Interceptor nor registered through a portable extension
org.jboss.weld.exceptions.DeploymentException: WELD-001417 Enabled interceptor class <class>com.foo.BarInterceptor</class> in file:/E:/.../gfdeploy/Interceptor-ear/Interceptor-ejb-1.0-SNAPSHOT_jar/META-INF/beans.xml@7 is neither annotated @Interceptor nor registered through a portable extension
	at org.jboss.weld.bootstrap.Validator.validateEnabledInterceptorClasses(Validator.java:656)
	at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:482)
	at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:536)
	at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:216)
	at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
	at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
	at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:356)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
	at 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)
]]


 Comments   
Comment by synti [ 28/Jun/13 ]

The problem is the new namespace. Both deployment and interception works fine after changing it back to:

<beans xmlns="http://java.sun.com/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
Comment by jjsnyder83 [ 03/Jul/13 ]

Please attach the app and source code (if possible) that demonstrates the failure.

Comment by synti [ 05/Jul/13 ]

Contains source and app:
https://dl.dropboxusercontent.com/u/91581899/Interceptor.zip

Comment by laurent_bauchau [ 14/Aug/13 ]

The problem is the new namespace. Both deployment and interception works fine after changing it back to:

<beans xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">

This change doesn't solve the problem for me.

I've "solved" the problem with: bean-discovery-mode="all" instead of "annotated"

Comment by synti [ 20/Aug/13 ]

Just confirming. Using the 1.1 beans.xml with bean-discovery-mode="all" also worked here.

Comment by javadon [ 22/Sep/13 ]

I too have same problem,

Environment: eclipse kepler, java-ee7, cdi 1.1, Glass Fish 4.0.1,..etc.

http://stackoverflow.com/questions/17258639/interceptor-issue-with-java-ee7

any help will be appreciated.

Comment by TangYong [ 23/Sep/13 ]

JJ
CC: All

The issue should be right behavior on current CDI Spec. I have done a confirmation on wildfly-8.0.0.Alpha4 and the same WELD-001417
exception is thrown. You can confirm with JBOSS guys.

The issue has two workarounds :

1. backing CDI 1.0
using http://java.sun.com/xml/ns/javaee/beans_1_0.xsd

2. using bean-discovery-mode="all"

So, if being the such case, the issue should be closed.

Thanks
Tang

Comment by jjsnyder83 [ 23/Sep/13 ]

I believe the deployment exception is accurate for CDI 1.1. The beans.xml for the jar with the interceptor contains:
bean-discovery-mode="annotated"

This means that only classes with bean-defining annotations will be managed by CDI. Since the interceptor does not contain a bean-defining annotation it is not managed by CDI. bean-defining annotations and implicit CDI is new with CDI 1.1.

Changing bean-discover-mode to "all" is the correct solution.





[GLASSFISH-20577] CDI broken: Seam-Solder leads to complete panic Created: 23/May/13  Updated: 07/Jun/13  Resolved: 24/May/13

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

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

JDK 1.7_21; OS X here, same on WIN/ LIN



 Description   

For Fishcat we tried to start Glassfish 4 with our main production app currently running well under Glasfish 3.1.2.2;

At startup immeadiately an CDI exception was thrown with an Wicket-Seam-Webapp using Wicket-Seam 3.0.0.Final, after upgrading to latest Seam-Solder it not only locks up but loops endlessly leading to a fial crashing gassfish instance;

Logs enclosed;

Main Exceptions:

Exception 0 :
org.jboss.weld.exceptions.IllegalStateException: WELD-001332 BeanManager method getBeans() is not available during application initialization
at org.jboss.weld.bean.builtin.BeanManagerProxy.checkContainerValidated(BeanManagerProxy.java:142)

As well as sub-exceptions:

Exception 0 :
java.lang.RuntimeException: Javassist not found on the class path, @ServiceHandler requires javassist to work. @ServiceHandler found on [BackedAnnotatedType] class de.xxxx.export.bmecat2.BmeCatDefinitions$_ARTICLE_MODE_NEW_closure3_closure17
at org.jboss.solder.serviceHandler.ServiceHandlerExtension.processAnnotatedType(ServiceHandlerExtension.java:71)
at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)



 Comments   
Comment by KBachl [ 23/May/13 ]

Follow up: I can confirm that the exact same WAR put into Glassfish 3.x works flawless. No CDI or Javasisst errors arise at all;

Comment by jjsnyder83 [ 23/May/13 ]

please email me the war (j.j.snyder@oracle.com). Also, try turning off implicit cdi:
asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=false

Comment by KBachl [ 24/May/13 ]

Hello,

the asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=false didnt work, just the error now sounds different;

I cant mail you our project as it wont run with some more work to the server (DB, noSQL store, JCR, etc) but I'm no currently mailing you the official wicket-seam-example app-war. As it is the exact same as we have in our app, the errors are identical. The code of it can be found here:

https://github.com/seam/wicket/tree/release/3.1.0.Final

This is the 3.1.0 Final and runs on any Glassfish 3., Jboss 6 etc. without problems.

Comment by jjsnyder83 [ 24/May/13 ]

CDI 1.1 made some modifications as to when BeanManager#getBeans can be called. Please see: https://issues.jboss.org/browse/CDI-274

So the solder extension won't work in cdi 1.1 (at least the one that is used by the app which appears to be 3.1.0.Final). You can try updating your app to use the latest solder (3.2.0.Final) to see if it's fixed in Solder. I did a quick scan of JBoss jiras but did not see this particular issue as a bug. You may want to enter a Solder jira.

Comment by KBachl [ 28/May/13 ]

@jjsnyder83

Solder 3.2.0.Final wont help. There is a bug in it describing it: https://issues.jboss.org/browse/SOLDER-339

Its from 15th January 2013 and nothing happend till then. You need to remember that seam solder was the outcome of the weld project (its the WELD-EXTENSIONS!) to get a cross plattform CDI access method. So, simply spoken, this "no-glassfish-bug" will break any project that uses seam solder, and this means > 90% of all CDI enabled apps out there.

So your shiny new glassfish 4.0 will not be usable for them. I dont think its clever to lock out > 90% of CDI using projects.

Comment by jjsnyder83 [ 28/May/13 ]

So it seems that Solder does not work on JBoss with Weld 2.0 either. I have sent an email to some guys I know at JBoss asking about this. I will post back as soon as I hear from them.

As for the javassist issue...javassist used to be packaged in the Weld 1.1.x bundle. It is no longer used by Weld and so is no longer packaged in the Weld 2.x bundle. I will experiment with it and create a new bundle with just the javassist classes and see if that takes care of this part of the issue. However, javassist is not something used by the rest of GlassFish so it's not likely that it will come as a bundle that ships with GF. Applications that want to use it will need to package those jars with the application (or install them as a shared library.)

I will post back soon with my findings.

Comment by KBachl [ 29/May/13 ]

The javassist lib isnt a big issue, just put the most recent one into the /domain/lib 'folder and its ok. This makes it possible to use even bundled war's from third party.

Real problem is the break in backwards compatibility by WELD 2.0 compared to 1.0/ 1.1;

Comment by jjsnyder83 [ 29/May/13 ]

According to the people I know at JBoss Solder has been discontinued with effort moved over to DeltaSpike. He did suggest that you bring this up on seam-dev mailing list. In the past there was a demand for a bugfixing release after the project had been discontinued and it was successful.

Comment by jjsnyder83 [ 07/Jun/13 ]

See https://issues.jboss.org/browse/WELD-1433

This has been fixed in Weld 2.0.2.Final.

Comment by KBachl [ 07/Jun/13 ]

Thank you for the update. The guys on the seam-dev list are also helpful and it might even get a fixed soldr; I dont expect weld 2.0.2.Final be part of inital Glassfish 4.0; How can one upgrade the weld glassfish uses to Weld 2.0.2 final?





[GLASSFISH-21027] Cannot deploy on GF 4.0.1 (nightly latest) but can deploy on GF 4.0 and GF 3.1.1 Created: 02/Apr/14  Updated: 19/Sep/14  Resolved: 09/Jul/14

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

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

4.0.1 (nightly latest), JDK 1.8.0 (32 Bit), Win 7 Pro SP1 (64 Bit)



 Description   

My rather complex EAR deploys without any problem on GF 4.0 and GF 3.1.1 but not at all on GF 4.0.1!

I am getting the following error message:

remote failure: Fehler beim Deployment: Exception while loading the app : java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.Li
fecycleException: com.google.common.util.concurrent.UncheckedExecutionException: org.jboss.weld.exceptions.IllegalStateException: WELD-001328 Unable to identify
 the correct BeanManager. The calling class org.jboss.weld.servlet.WeldInitialListener is not placed in bean archive. Weitere Informationen finden Sie unter server.log.
Command deploy failed.

(Also see attched server.log for more information!)

The strange thing is that I am not using neither CDI in common nor WELD in particular at all! The EAR is completely CDI free, moreover it actively switches CDI completely OFF thanks to bean-discovery-mode="none" in beans.xml!

This is a blocker for us as we cannot deploy anymore!

EAR file is closed source and must not get published in JIRA, so if you need it to reproduce, please provide an email address where we can send the file to.



 Comments   
Comment by mkarg [ 02/Apr/14 ]

Seems reporters are not allowed to attach files to JIRA, so please find the server.log here instead as a comment:

...

[2014-04-02T12:06:29.248+0200] [glassfish 4.0] [INFO] [AS-EJB-00036] [javax.enterprise.ejb.container] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433189248] [levelValue: 800] [[
  TopLevel AvailabilityService.getAvailabilityEnabled: [true]]]

[2014-04-02T12:06:29.263+0200] [glassfish 4.0] [INFO] [AS-EJB-00037] [javax.enterprise.ejb.container] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433189263] [levelValue: 800] [[
  TopLevel EjbAvailabilityService.getAvailabilityEnabled: [true]]]

[2014-04-02T12:06:29.263+0200] [glassfish 4.0] [INFO] [AS-EJB-00038] [javax.enterprise.ejb.container] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433189263] [levelValue: 800] [[
  Global AvailabilityEnabled: [true], application AvailabilityEnabled: [false]]]

[2014-04-02T12:06:29.263+0200] [glassfish 4.0] [INFO] [AS-EJB-00040] [javax.enterprise.ejb.container] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433189263] [levelValue: 800] [[
  StatefulContainerBuilder AvailabilityEnabled [false] for this application]]

[2014-04-02T12:06:29.263+0200] [glassfish 4.0] [INFO] [AS-EJB-00041] [javax.enterprise.ejb.container] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433189263] [levelValue: 800] [[
  StatefulContainerBuilder.buildStoreManager() storeName: [ImplementMeasureWizardBean-91516618925670443-BackingStore]]]

[2014-04-02T12:06:29.263+0200] [glassfish 4.0] [INFO] [] [org.glassfish.ha.store.adapter.file.FileBackingStore] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433189263] [levelValue: 800] [[
  [FileBackingStore::initialize] Successfully Created and initialized store. Working dir: C:\glassfish4\glassfish\domains\domain1\session-store\ImplementMeasureWizardBean-91516618925670443; Configuration: BackingStoreConfiguration{clusterName='null', instanceName='null', storeName='ImplementMeasureWizardBean-91516618925670443-BackingStore', shortUniqueName='91516618925670443', storeType='file', maxIdleTimeInSeconds=-1, relaxVersionCheck='null', maxLoadWaitTimeInSeconds=0, baseDirectoryName='C:\glassfish4\glassfish\domains\domain1\session-store\ImplementMeasureWizardBean-91516618925670443', keyClazz=interface java.io.Serializable, valueClazz=class org.glassfish.ha.store.util.SimpleMetadata, synchronousSave=false, typicalPayloadSizeInKiloBytes=0, vendorSpecificSettings={value.class.is.thread.safe=true, async.replication=true, start.gms=false, local.caching=true, broadcast.remove.expired=false, key.transformer=com.sun.ejb.base.sfsb.util.SimpleKeyGenerator@126721f}}]]

[2014-04-02T12:06:29.263+0200] [glassfish 4.0] [INFO] [AS-EJB-00043] [javax.enterprise.ejb.container] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433189263] [levelValue: 800] [[
  StatefulContainerbuilder instantiated store: org.glassfish.ha.store.adapter.file.FileBackingStore@223cdf, with ha-enabled [false], and backing store configuration: BackingStoreConfiguration{clusterName='null', instanceName='null', storeName='ImplementMeasureWizardBean-91516618925670443-BackingStore', shortUniqueName='91516618925670443', storeType='file', maxIdleTimeInSeconds=-1, relaxVersionCheck='null', maxLoadWaitTimeInSeconds=0, baseDirectoryName='C:\glassfish4\glassfish\domains\domain1\session-store\ImplementMeasureWizardBean-91516618925670443', keyClazz=interface java.io.Serializable, valueClazz=class org.glassfish.ha.store.util.SimpleMetadata, synchronousSave=false, typicalPayloadSizeInKiloBytes=0, vendorSpecificSettings={value.class.is.thread.safe=true, async.replication=true, start.gms=false, local.caching=true, broadcast.remove.expired=false, key.transformer=com.sun.ejb.base.sfsb.util.SimpleKeyGenerator@126721f}}]]

[2014-04-02T12:06:29.263+0200] [glassfish 4.0] [INFO] [AS-EJB-00054] [javax.enterprise.ejb.container] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433189263] [levelValue: 800] [[
  Portable JNDI names for EJB ImplementMeasureWizardBean: [java:global/QUIPSY/QUIPSY/ImplementMeasureWizardBean!de.quipsy.sessions.implementmeasurewizard.ImplementMeasureWizardHome, java:global/QUIPSY/QUIPSY/ImplementMeasureWizardBean]]]

[2014-04-02T12:06:29.263+0200] [glassfish 4.0] [INFO] [AS-EJB-00055] [javax.enterprise.ejb.container] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433189263] [levelValue: 800] [[
  Glassfish-specific (Non-portable) JNDI names for EJB ImplementMeasureWizardBean: [de.quipsy.sessions.implementmeasurewizard.ImplementMeasureWizardHome]]]

[2014-04-02T12:06:29.638+0200] [glassfish 4.0] [WARNING] [] [javax.enterprise.system.core.security] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433189638] [levelValue: 900] [[
  No Principals mapped to Role [APQPProjectOwner].]]

[2014-04-02T12:06:29.638+0200] [glassfish 4.0] [WARNING] [] [javax.enterprise.system.core.security] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433189638] [levelValue: 900] [[
  No Principals mapped to Role [APQPActionExecutor].]]

[2014-04-02T12:06:29.950+0200] [glassfish 4.0] [INFO] [AS-WSJSR109IMPL-00019] [javax.enterprise.webservices] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433189950] [levelValue: 800] [[
  EJB Endpoint deployed QUIPSY
  listening at address at http://MK-Development-2014:8080/ComplaintServiceBeanService/ComplaintServiceBean]]

[2014-04-02T12:06:29.950+0200] [glassfish 4.0] [INFO] [AS-WSJSR109IMPL-00019] [javax.enterprise.webservices] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433189950] [levelValue: 800] [[
  EJB Endpoint deployed QUIPSY
  listening at address at http://MK-Development-2014:8080/QUIPSYService/QUIPSY]]

[2014-04-02T12:06:30.090+0200] [glassfish 4.0] [INFO] [] [org.glassfish.jersey.servlet.init.JerseyServletContainerInitializer] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433190090] [levelValue: 800] [[
  Registering the Jersey servlet application, named de.quipsy.application.QuipsyApplication, at the servlet mapping /*, with the Application class of the same name.]]

[2014-04-02T12:06:30.121+0200] [glassfish 4.0] [SEVERE] [AS-WEB-CORE-00174] [javax.enterprise.web.core] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433190121] [levelValue: 1000] [[
  Startup of context  failed due to previous errors]]

[2014-04-02T12:06:30.121+0200] [glassfish 4.0] [SEVERE] [AS-WEB-CORE-00175] [javax.enterprise.web.core] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433190121] [levelValue: 1000] [[
  Exception during cleanup after start failed
org.apache.catalina.LifecycleException: Manager has not yet been started
	at org.apache.catalina.session.StandardManager.stop(StandardManager.java:934)
	at org.apache.catalina.core.StandardContext.stop(StandardContext.java:6133)
	at com.sun.enterprise.web.WebModule.stop(WebModule.java:720)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:5950)
	at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
	at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2286)
	at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1932)
	at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
	at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
	at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
	at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
	at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Unknown Source)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Unknown Source)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
	at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:404)
	at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:151)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:171)
	at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:104)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:406)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:350)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:106)
	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:259)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:320)
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:236)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1028)
	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:363)
	at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:173)
	at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:215)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:291)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:209)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:137)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:115)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:550)
	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(Unknown Source)
]]

[2014-04-02T12:06:30.121+0200] [glassfish 4.0] [SEVERE] [AS-WEB-CORE-00108] [javax.enterprise.web.core] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433190121] [levelValue: 1000] [[
  ContainerBase.addChild: start: 
org.apache.catalina.LifecycleException: com.google.common.util.concurrent.UncheckedExecutionException: org.jboss.weld.exceptions.IllegalStateException: WELD-001328 Unable to identify the correct BeanManager. The calling class org.jboss.weld.servlet.WeldInitialListener is not placed in bean archive
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:5954)
	at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
	at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2286)
	at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1932)
	at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
	at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
	at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
	at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
	at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Unknown Source)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Unknown Source)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
	at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:404)
	at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:151)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:171)
	at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:104)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:406)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:350)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:106)
	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:259)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:320)
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:236)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1028)
	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:363)
	at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:173)
	at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:215)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:291)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:209)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:137)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:115)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:550)
	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(Unknown Source)
Caused by: com.google.common.util.concurrent.UncheckedExecutionException: org.jboss.weld.exceptions.IllegalStateException: WELD-001328 Unable to identify the correct BeanManager. The calling class org.jboss.weld.servlet.WeldInitialListener is not placed in bean archive
	at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2258)
	at com.google.common.cache.LocalCache.get(LocalCache.java:3990)
	at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3994)
	at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4878)
	at com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4884)
	at org.jboss.weld.Weld.getBeanManager(Weld.java:115)
	at org.jboss.weld.Weld.getBeanManager(Weld.java:46)
	at org.jboss.weld.servlet.WeldInitialListener.contextInitialized(WeldInitialListener.java:65)
	at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:5394)
	at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:743)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:5932)
	... 72 more
Caused by: org.jboss.weld.exceptions.IllegalStateException: WELD-001328 Unable to identify the correct BeanManager. The calling class org.jboss.weld.servlet.WeldInitialListener is not placed in bean archive
	at org.jboss.weld.Weld.unsatisfiedBeanManager(Weld.java:99)
	at org.glassfish.weld.GlassFishWeldProvider$GlassFishEnhancedWeld.unsatisfiedBeanManager(GlassFishWeldProvider.java:95)
	at org.jboss.weld.Weld$ClassNameToBeanManager.findBeanManager(Weld.java:76)
	at org.jboss.weld.Weld$ClassNameToBeanManager.load(Weld.java:55)
	at org.jboss.weld.Weld$ClassNameToBeanManager.load(Weld.java:48)
	at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3589)
	at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2374)
	at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2337)
	at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2252)
	... 82 more
]]

[2014-04-02T12:06:30.121+0200] [glassfish 4.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433190121] [levelValue: 900] [[
  java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: com.google.common.util.concurrent.UncheckedExecutionException: org.jboss.weld.exceptions.IllegalStateException: WELD-001328 Unable to identify the correct BeanManager. The calling class org.jboss.weld.servlet.WeldInitialListener is not placed in bean archive
java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: com.google.common.util.concurrent.UncheckedExecutionException: org.jboss.weld.exceptions.IllegalStateException: WELD-001328 Unable to identify the correct BeanManager. The calling class org.jboss.weld.servlet.WeldInitialListener is not placed in bean archive
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1044)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
	at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2286)
	at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1932)
	at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
	at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
	at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
	at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
	at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Unknown Source)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Unknown Source)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
	at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:404)
	at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:151)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:171)
	at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:104)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:406)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:350)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:106)
	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:259)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:320)
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:236)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1028)
	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:363)
	at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:173)
	at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:215)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:291)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:209)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:137)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:115)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:550)
	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(Unknown Source)
]]

[2014-04-02T12:06:30.121+0200] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433190121] [levelValue: 1000] [[
  Exception while invoking class com.sun.enterprise.web.WebApplication start method
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: com.google.common.util.concurrent.UncheckedExecutionException: org.jboss.weld.exceptions.IllegalStateException: WELD-001328 Unable to identify the correct BeanManager. The calling class org.jboss.weld.servlet.WeldInitialListener is not placed in bean archive
	at com.sun.enterprise.web.WebApplication.start(WebApplication.java:168)
	at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
	at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
	at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
	at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Unknown Source)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Unknown Source)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
	at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:404)
	at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:151)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:171)
	at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:104)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:406)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:350)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:106)
	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:259)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:320)
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:236)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1028)
	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:363)
	at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:173)
	at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:215)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:291)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:209)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:137)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:115)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:550)
	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(Unknown Source)
]]

[2014-04-02T12:06:30.121+0200] [glassfish 4.0] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433190121] [levelValue: 1000] [[
  Exception during lifecycle processing
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: com.google.common.util.concurrent.UncheckedExecutionException: org.jboss.weld.exceptions.IllegalStateException: WELD-001328 Unable to identify the correct BeanManager. The calling class org.jboss.weld.servlet.WeldInitialListener is not placed in bean archive
	at com.sun.enterprise.web.WebApplication.start(WebApplication.java:168)
	at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
	at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
	at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
	at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Unknown Source)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Unknown Source)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
	at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:404)
	at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:151)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:171)
	at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:104)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:406)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:350)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:106)
	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:259)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:320)
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:236)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1028)
	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:363)
	at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:173)
	at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:215)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:291)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:209)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:137)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:115)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:550)
	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(Unknown Source)
]]

[2014-04-02T12:06:30.121+0200] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433190121] [levelValue: 1000] [[
  Exception while loading the app]]

[2014-04-02T12:06:30.558+0200] [glassfish 4.0] [SEVERE] [AS-WEB-GLUE-00192] [javax.enterprise.web] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433190558] [levelValue: 1000] [[
  Undeployment failed for context ]]

[2014-04-02T12:06:30.574+0200] [glassfish 4.0] [INFO] [ra.stop-successful] [javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433190574] [levelValue: 800] [[
  RAR7094: QUIPSY#KernelConnector shutdown successful.]]

[2014-04-02T12:06:30.574+0200] [glassfish 4.0] [INFO] [ra.stop-successful] [javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433190574] [levelValue: 800] [[
  RAR7094: QUIPSY#quipsy-legacyadapter-module-4.36.1-SNAPSHOT shutdown successful.]]

[2014-04-02T12:06:30.574+0200] [glassfish 4.0] [INFO] [] [org.eclipse.persistence.session.file:/C:/glassfish4/glassfish/domains/domain1/applications/QUIPSY/QUIPSY_jar/_QUIPSY.connection] [tid: _ThreadID=583 _ThreadName=pool-59-thread-1] [timeMillis: 1396433190574] [levelValue: 800] [[
  file:/C:/glassfish4/glassfish/domains/domain1/applications/QUIPSY/QUIPSY_jar/_QUIPSY logout successful]]

[2014-04-02T12:06:30.574+0200] [glassfish 4.0] [INFO] [] [javax.enterprise.system.container.ejb.org.glassfish.ejb.persistent.timer] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433190574] [levelValue: 800] [[
  [1] timers deleted for id: 91516618925670400]]

[2014-04-02T12:06:30.620+0200] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=50 _ThreadName=admin-listener(5)] [timeMillis: 1396433190620] [levelValue: 1000] [[
  Exception while loading the app : java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: com.google.common.util.concurrent.UncheckedExecutionException: org.jboss.weld.exceptions.IllegalStateException: WELD-001328 Unable to identify the correct BeanManager. The calling class org.jboss.weld.servlet.WeldInitialListener is not placed in bean archive]]
Comment by Hong Zhang [ 02/Apr/14 ]

As the stack trace is from web container, assign to web team for initial evaluation

Comment by Hong Zhang [ 02/Apr/14 ]

Actually reading the bug description again, cdi component seems the right component for initial evaluation.

Comment by mkarg [ 07/Apr/14 ]

Happens with nightly build of April 6 still.

Comment by jjsnyder83 [ 16/Apr/14 ]

CDI is enabled by default. You must explicitly turn it off for your application. You can set it for an individual app when it is deployed via:
asadmin deploy --property implicitCdiEnabled=false <archive>

or you can set it globally via:
asadmin create-module-config cdi-service
asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=false

See https://java.net/jira/browse/GLASSFISH-19946

Comment by mkarg [ 17/Apr/14 ]

You misunderstood this case. My application provides a beans.xml switching off CDI. So deployment must work with default settings as it did in 4.0.1. If it does not, GF 4.0.1 apparently ignores this beans.xml setting – which is a violation of the Java EE specification!

Comment by mkarg [ 22/Apr/14 ]

If there is something we can help with, like providing more detailed logs etc., please let use know. As it worked well in 4.0.0 we are pretty sure that it is a rather small bug in 4.0.1 which leads to the fact that disabling CDI per application by providing a beans.xml simply does not work anymore. We understand that CDI can be disabled per server, but this is not what we want, as we like to run several CDI-enabled EARs on the same server instance which runs the CDI-disabled EARs.

Comment by mkarg [ 22/Apr/14 ]

Still fails with nightly build of April 21.

Comment by mkarg [ 22/Apr/14 ]

The same problem happens even when using --property implicitCdiEnabled=false!

C:\>asadmin deploy --property implicitCdiEnabled=false my.ear
remote failure: Fehler beim Deployment: Exception while loading the app : java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.Li
fecycleException: com.google.common.util.concurrent.UncheckedExecutionException: org.jboss.weld.exceptions.IllegalStateException: WELD-001328 Unable to identify
 the correct BeanManager. The calling class org.jboss.weld.servlet.WeldInitialListener is not placed in bean archive. Weitere Informationen finden Sie unter ser
ver.log.
Command deploy failed.
Comment by mkarg [ 22/Apr/14 ]

The same problem even happens when globally disabling CDI, so there really is no workaround!

C:\>asadmin get configs.config.server-config.cdi-service.enable-implicit-cdi
configs.config.server-config.cdi-service.enable-implicit-cdi=false
Command get executed successfully.

C:\>asadmin deploy my.ear
remote failure: Fehler beim Deployment: Exception while loading the app : java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.Li
fecycleException: com.google.common.util.concurrent.UncheckedExecutionException: org.jboss.weld.exceptions.IllegalStateException: WELD-001328 Unable to identify
 the correct BeanManager. The calling class org.jboss.weld.servlet.WeldInitialListener is not placed in bean archive. Weitere Informationen finden Sie unter ser
ver.log.
Command deploy failed.

Again, we offer you to support debugging by sending our closed-source EAR file directly to Oracle, but we must not disclose the file in this tracker. There currently is absolutely no way to deploy on 4.0.1 while deployment on 4.0.0 works fine, so there must be a small change which produces this bug.

Comment by mkarg [ 29/Apr/14 ]

Still fails with nightly build of April 28.

Comment by mkarg [ 19/May/14 ]

Phil, is there anything you want me to check? My tests above already proof that it is currently absolutely impossible to disable CDI in GF 4.0.1. Can I do anything to speed up fixing?

Comment by mkarg [ 11/Jun/14 ]

Still fails with nightly build of June 10.

Comment by jjsnyder83 [ 02/Jul/14 ]

Please send me the test app with source code if possible. j.j.snyder@oracle.com

Comment by mkarg [ 04/Jul/14 ]

Still fails with nightly build of July 3. I will send you a download link for the closed-source EAR file to j.j.snyder@oracle.com. Please do not disclose.

Comment by mkarg [ 04/Jul/14 ]

J. j. please see my eMail sent to j.j.snyder@oracle.com - it provides instructions how to obtain the EAR.

Comment by jjsnyder83 [ 09/Jul/14 ]

Fixed with Committed revision 63454.

Comment by jjsnyder83 [ 09/Jul/14 ]

We were not taking into account the bean-discovery-mode attribute of beans in beans.xml when checking for implicit archives.

Comment by mkarg [ 22/Jul/14 ]

I hereby confirm that with GF-nightly of July 22 the problem is gone and we can deploy the same EAR again! Thanks, JJ!

Comment by jjsnyder83 [ 22/Jul/14 ]

Excellent. Thanks for your patience Markus.





[GLASSFISH-20247] WELD-001527 Managed bean declaring a passivating scope has a non-serializable interceptor for DefaultInterceptorMetadata Created: 09/Apr/13  Updated: 10/Apr/13  Resolved: 10/Apr/13

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

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


 Description   

For a bean defined as:

@Named
@SessionScoped
public class MovieClientBean implements Serializable {
...
}

b83 is throwing the following error:

SEVERE: Exception while loading the app : CDI deployment failure:WELD-001527 Managed bean declaring a passivating scope has a non-serializable interceptor. Bean: Managed Bean [class org.glassfish.movieplex7.client.MovieClientBean] with qualifiers [@Default @Any @Named] Interceptor: org.jboss.weld.interceptor.reader.DefaultInterceptorMetadata@573da625
org.jboss.weld.exceptions.DeploymentException: WELD-001527 Managed bean declaring a passivating scope has a non-serializable interceptor. Bean: Managed Bean [class org.glassfish.movieplex7.client.MovieClientBean] with qualifiers [@Default @Any @Named] Interceptor: org.jboss.weld.interceptor.reader.DefaultInterceptorMetadata@573da625

Deployment fails. This is blocking to run Java EE 7 hands-on lab using b83.

The complete application is described at http://glassfish.org/hol.



 Comments   
Comment by TangYong [ 10/Apr/13 ]

arungupta, jjsnyder83

My analyze is as following:

1 about passivating scope
Here, needing to notice that in [1], the following from 6.6.3. Passivating scopes,

"For example, the built-in session and conversation scopes defined in Section 6.7, “Context management for built-in scopes” are passivating scopes. No other built-in scopes are passivating scopes."

For @SessionScoped, it belongs to "Context management for built-in scopes", so once defining any interceptor or injecting any bean, these interceptors and dependency beans all should be serializable. Although this is from cdi 1.0, in 1.1, this can not be changed.

[1]:http://docs.jboss.org/cdi/spec/1.0/html_single/#passivatingscope

2 about @Transactional
This is an interceptor defining @InterceptorBinding.

Combining with 1 and 2, the exception happened.

In reality, previously a similar issue has been discussed in JBOSS community[2],

[2]: https://community.jboss.org/thread/179828

[About Fixing]
Because @Transactional is a part of javax.transaction api, fixing should be limited in the Movie sample, and I am still considering...

Thanks
--Tang

Comment by TangYong [ 10/Apr/13 ]

JavaEE 7 Spec group seemed missing such a scene (combining Transactional Interceptors with CDI beans with Context management for built-in scopes.

Comment by jjsnyder83 [ 10/Apr/13 ]

Made the transactional interceptors implement Serializable.
Committed revision 61342.





[GLASSFISH-20209] CDI Deployment Fails Created: 06/Apr/13  Updated: 04/Sep/13  Resolved: 09/Apr/13

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

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

Windows 7


Issue Links:
Dependency
blocks CARGOTRACKER-1 Make project work on latest GlassFish... Closed

 Description   

My application fails due to a CDI deployment error. This is an application that was working fine on build 76. The application is available here: http://java.net/projects/cargotracker/downloads/download/cargo-tracker.zip
Please advise.

Here's how to build : (requires JDK 7)
unzip the app
cd cargo-tracker
mvn install

deploy the war file to GlassFish

Here is the error I get:

SEVERE: Exception while loading the app : CDI deployment failure:1
java.lang.ArrayIndexOutOfBoundsException: 1
at org.jboss.weld.util.reflection.HierarchyDiscovery.discoverFromClass(HierarchyDiscovery.java:99)
at org.jboss.weld.util.reflection.HierarchyDiscovery.discoverTypes(HierarchyDiscovery.java:70)
at org.jboss.weld.util.reflection.HierarchyDiscovery.<init>(HierarchyDiscovery.java:51)
at org.jboss.weld.util.reflection.HierarchyDiscovery.<init>(HierarchyDiscovery.java:44)
at org.jboss.weld.annotated.enhanced.TypeClosureLazyValueHolder.computeValue(TypeClosureLazyValueHolder.java:54)
at org.jboss.weld.annotated.enhanced.TypeClosureLazyValueHolder.computeValue(TypeClosureLazyValueHolder.java:33)
at org.jboss.weld.util.LazyValueHolder.get(LazyValueHolder.java:35)
at org.jboss.weld.annotated.slim.backed.BackedAnnotated.getTypeClosure(BackedAnnotated.java:27)
at org.jboss.weld.annotated.enhanced.jlr.AbstractEnhancedAnnotated.getTypeClosure(AbstractEnhancedAnnotated.java:202)
at org.jboss.weld.util.Beans.getTypes(Beans.java:446)
at org.jboss.weld.bean.attributes.BeanAttributesFactory$BeanAttributesBuilder.<init>(BeanAttributesFactory.java:107)
at org.jboss.weld.bean.attributes.BeanAttributesFactory$BeanAttributesBuilder.<init>(BeanAttributesFactory.java:89)
at org.jboss.weld.bean.attributes.BeanAttributesFactory.forBean(BeanAttributesFactory.java:66)
at org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:268)
at org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:252)
at org.jboss.weld.bootstrap.BeanDeployer.createClassBeans(BeanDeployer.java:216)
at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:269)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:503)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:209)
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)



 Comments   
Comment by jjsnyder83 [ 06/Apr/13 ]

This is a bug in Weld. https://issues.jboss.org/browse/WELD-1397

Comment by TangYong [ 07/Apr/13 ]

Rahman,

I have tried b76, while deploying the sample, the following exception happened,

[#|2013-04-07T21:23:00.964+0900|SEVERE||javax.enterprise.system.core|_ThreadID=82;_ThreadName=admin-listener(1);_TimeMillis=1365337380964;_LevelValue=1000;|Exception while deploying the app [cargo-tracker-1.0-SNAPSHOT] : javax.jms.JMSDestinationDefinition missing element classNameat org.glassfish.apf.AnnotationInfo@1d9e5f4
javax.jms.JMSDestinationDefinition missing element classNameat org.glassfish.apf.AnnotationInfo@1d9e5f4
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:367)
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:375)
at org.glassfish.apf.impl.AnnotationProcessorImpl.processAnnotations(AnnotationProcessorImpl.java:289)
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:195)
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:134)
at com.sun.enterprise.deployment.archivist.Archivist.processAnnotations(Archivist.java:615)
at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:459)
at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:446)
at com.sun.enterprise.deployment.archivist.Archivist.readRestDeploymentDescriptors(Archivist.java:419)
at com.sun.enterprise.deployment.archivist.Archivist.openWith(Archivist.java:292)
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openWith(ApplicationFactory.java:232)
at org.glassfish.javaee.core.deployment.DolProvider.processDOL(DolProvider.java:188)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:222)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:96)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:878)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:818)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:374)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:528)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:524)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:523)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:547)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1424)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1759)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1675)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:387)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:231)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:93)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:358)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:353)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:99)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:203)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:316)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:179)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:818)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:321)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:157)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:164)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:175)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:273)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:820)
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: java.lang.annotation.IncompleteAnnotationException: javax.jms.JMSDestinationDefinition missing element className
at sun.reflect.annotation.AnnotationInvocationHandler.invoke(AnnotationInvocationHandler.java:72)
at $Proxy190.className(Unknown Source)
at com.sun.enterprise.connectors.jms.deployment.annotation.handlers.JMSDestinationDefinitionHandler.createDescriptor(JMSDestinationDefinitionHandler.java:265)
at com.sun.enterprise.connectors.jms.deployment.annotation.handlers.JMSDestinationDefinitionHandler.processAnnotation(JMSDestinationDefinitionHandler.java:93)
at com.sun.enterprise.connectors.jms.deployment.annotation.handlers.JMSDestinationDefinitionsHandler.processAnnotation(JMSDestinationDefinitionsHandler.java:91)
at com.sun.enterprise.deployment.annotation.handlers.AbstractResourceHandler.processAnnotation(AbstractResourceHandler.java:141)
at com.sun.enterprise.deployment.annotation.factory.SJSASFactory$LazyAnnotationHandler.processAnnotation(SJSASFactory.java:148)
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:344)
... 65 more

#]

So, do you confirm that the sample can be deployed on b76 successfully?

Thanks
--Tang

Comment by TangYong [ 07/Apr/13 ]

Rahman,

Your sample needs to be modified a litter because after I re-built weld 2.0.0.Beta8 by my simple fixing(in order to make some experiments to bypass the 20209 issue) and deployed the sample, the following exception happened,

[2013-04-07T22:28:15.048+0900] [glassfish 4.0] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=34 _ThreadName=admin-listener(2)] [timeMillis: 1365341295048] [levelValue: 1000] [[
Exception during lifecycle processing
org.glassfish.deployment.common.DeploymentException: CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [Ref<ContainerRequest>] with qualifiers [@Default] at injection point [[BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject org.glassfish.jersey.server.internal.routing.UriRoutingContext(Ref<ContainerRequest>, ProcessingProviders)]
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:219)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:217)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:231)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:227)
at org.glassfish.jersey.internal.Errors.process(Errors.java:275)
at org.glassfish.jersey.internal.Errors.process(Errors.java:257)
at org.glassfish.jersey.internal.Errors.process(Errors.java:227)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:191)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:819)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:161)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Ref<ContainerRequest>] with qualifiers [@Default] at injection point [[BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject org.glassfish.jersey.server.internal.routing.UriRoutingContext(Ref<ContainerRequest>, ProcessingProviders)]
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:388)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:316)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:177)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:208)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:504)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:490)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:465)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:528)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:210)
... 58 more
]]

The reason of the above exception is that the WAR contains jersey server related jars in WEB-INF/lib. So, while weld starts to make effect, it will scan jersery related jars. We only need to modify the war's pom file and make these jersey jars being "provided". And finally, the WEB-INF/lib should only contain commons-lang3-3.1.jar.

Then, While I was re-deploying the sample, a new exception happened, however, I think that this has been out of 20209. So, hoping Weld team can fix the issue as soon as possible.

[2013-04-07T22:37:53.625+0900] [glassfish 4.0] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=35 _ThreadName=admin-listener(3)] [timeMillis: 1365341873625] [levelValue: 1000] [[
Exception during lifecycle processing
javax.ejb.EJBException: javax.ejb.CreateException: Initialization failed for Singleton SampleDataGenerator
at com.sun.ejb.containers.AbstractSingletonContainer$SingletonContextFactory.create(AbstractSingletonContainer.java:641)
at com.sun.ejb.containers.AbstractSingletonContainer.instantiateSingletonInstance(AbstractSingletonContainer.java:381)
at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:219)
at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:180)
at org.glassfish.ejb.startup.SingletonLifeCycleManager.doStartup(SingletonLifeCycleManager.java:158)
at org.glassfish.ejb.startup.EjbApplication.start(EjbApplication.java:166)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:217)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:231)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:227)
at org.glassfish.jersey.internal.Errors.process(Errors.java:275)
at org.glassfish.jersey.internal.Errors.process(Errors.java:257)
at org.glassfish.jersey.internal.Errors.process(Errors.java:227)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:191)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:819)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:161)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
Caused by: javax.ejb.CreateException: Initialization failed for Singleton SampleDataGenerator
at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:468)
at com.sun.ejb.containers.AbstractSingletonContainer.access$100(AbstractSingletonContainer.java:77)
at com.sun.ejb.containers.AbstractSingletonContainer$SingletonContextFactory.create(AbstractSingletonContainer.java:639)
... 64 more
Caused by: java.lang.IllegalStateException: Attempting to execute an operation on a closed EntityManagerFactory.
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.verifyOpen(EntityManagerFactoryDelegate.java:338)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.createEntityManagerImpl(EntityManagerFactoryDelegate.java:303)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManagerImpl(EntityManagerFactoryImpl.java:336)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:317)
at com.sun.enterprise.container.common.impl.EntityManagerWrapper._getDelegate(EntityManagerWrapper.java:197)
at com.sun.enterprise.container.common.impl.EntityManagerWrapper.persist(EntityManagerWrapper.java:287)
at net.java.cargotracker.application.util.SampleDataGenerator.loadSampleLocations(SampleDataGenerator.java:77)
at net.java.cargotracker.application.util.SampleDataGenerator.loadSampleData(SampleDataGenerator.java:71)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.ejb.containers.interceptors.BeanCallbackInterceptor.intercept(InterceptorManager.java:1035)
at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72)
at com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:205)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:986)
at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72)
at com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:205)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.init(SystemInterceptorProxy.java:125)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:986)
at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:412)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:375)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:1949)
at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:460)
... 66 more
]]

Thanks
--Tang

Comment by reza_rahman [ 08/Apr/13 ]

I've made the changes you've suggested. I'm still getting the same exception.

This particular version of the application will no longer work on b76 since I've updated it. If you want a version that does, I can provide it. It definitely works on b76 as well as on Java EE 6 versions of GlassFish.

If I were to venture a guess, the JPA classes were not being scanned in those versions, while in the latest, CDI is attempting to scan the JPA classes, leading to the problem.

Comment by reza_rahman [ 08/Apr/13 ]

BTW, your suggestion on the underlying Weld issue of turning off EclipseLink weaving got around the deployment issue, but I don't think that is a long-term solution.

Comment by reza_rahman [ 09/Apr/13 ]

Note, I've had to change the contents of the referenced zip. To reproduce the issue now, just comment out the weaving part in persistence.xml, build via Maven and deploy:

<!-<property name="eclipselink.weaving" value="false"/>->

Otherwise, just use Tang's example on the Weld bug?

Comment by TangYong [ 09/Apr/13 ]

Rahman,

So far, what I did is to justify the issue related to Weld and EclipseLink apart from my first suggestion(removing jersey related bundles from demo's WEB-INF/lib).

However, It seemed that JBOSS Weld Team do not think this is a bug from weld.

>BTW, your suggestion on the underlying Weld issue of turning off EclipseLink weaving got around the deployment issue, but I don't think that is a long-term solution.

Yes, this is my experiment for investigating the issue.

Thanks
Tang

Comment by reza_rahman [ 09/Apr/13 ]

Tang,

I would be remiss not to say this - many thanks for the help on this! It is always great to have independent verification and clarification of issues.

Cheers,
Reza

Comment by jjsnyder83 [ 09/Apr/13 ]

A fix was made in EclipseLink build. Reza will test with the next EclipseLink build.

Comment by reza_rahman [ 09/Apr/13 ]

I confirmed that this now works.

Comment by TangYong [ 10/Apr/13 ]

Good news!





[GLASSFISH-20531] JSF can't find @Named beans after redeploy Created: 14/May/13  Updated: 22/May/13  Resolved: 22/May/13

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

Type: Bug Priority: Blocker
Reporter: Bruno Borges Assignee: jjsnyder83
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Playing with Arun's HOL (glassfish.org/hol).

After a redeploy from NetBeans, JSF is not able to load a @Named bean anymore.

/points/points.xhtml @16,69 value="#{sendPointsBean.message}": Target Unreachable, identifier 'sendPointsBean' resolved to null

Full stacktrace:

javax.el.PropertyNotFoundException: /points/points.xhtml @16,69 value="#{sendPointsBean.message}": Target Unreachable, identifier 'sendPointsBean' resolved to null
	at com.sun.faces.facelets.el.TagValueExpression.getType(TagValueExpression.java:100)
	at com.sun.faces.renderkit.html_basic.HtmlBasicInputRenderer.getConvertedValue(HtmlBasicInputRenderer.java:95)
	at javax.faces.component.UIInput.getConvertedValue(UIInput.java:1046)
	at javax.faces.component.UIInput.validate(UIInput.java:976)
	at javax.faces.component.UIInput.executeValidate(UIInput.java:1249)
	at javax.faces.component.UIInput.processValidators(UIInput.java:712)
	at javax.faces.component.UIForm.processValidators(UIForm.java:253)
	at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1261)
	at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1261)
	at javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:1195)
	at com.sun.faces.lifecycle.ProcessValidationsPhase.execute(ProcessValidationsPhase.java:76)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.glassfish.tyrus.servlet.TyrusServletFilter.doFilter(TyrusServletFilter.java:253)
	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 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
	at java.lang.Thread.run(Thread.java:722)
Caused by: javax.el.PropertyNotFoundException: Target Unreachable, identifier 'sendPointsBean' resolved to null
	at com.sun.el.parser.AstValue.getTarget(AstValue.java:174)
	at com.sun.el.parser.AstValue.getType(AstValue.java:86)
	at com.sun.el.ValueExpressionImpl.getType(ValueExpressionImpl.java:201)
	at com.sun.faces.facelets.el.TagValueExpression.getType(TagValueExpression.java:98)
	... 44 more


 Comments   
Comment by jjsnyder83 [ 15/May/13 ]

Please attach an application (ear/war) with source code so that we can try to reproduce the problem.

Comment by jjsnyder83 [ 22/May/13 ]

Please provide an application with source code that illustrates the problem.





[GLASSFISH-20325] SFSB passivation fails with NotSerializableException: org.jboss.weld.context.ejb.EjbRequestContextImpl Created: 16/Apr/13  Updated: 24/Aug/14  Resolved: 23/Apr/13

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

Type: Bug Priority: Blocker
Reporter: marina vatkina 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-20318 SFSB passivation fails with CDI enabled Resolved

 Description   

ejb31/full/passact fails with NotSerializableException: org.jboss.weld.context.ejb.EjbRequestContextImpl even if the rest of passivation is working.



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

Blocks passivation of a SFSB that injects other beans via @EJB and SessionContext via @Resource

Comment by jjsnyder83 [ 17/Apr/13 ]

JBoss has a fix for this. It will be available in CR3 which is due out this week.

Comment by jjsnyder83 [ 23/Apr/13 ]

Fixed with Weld 2.0.0.CR4 added to GF with revision 61592.

Comment by lprimak [ 24/Aug/14 ]

This is not completely fixed. As of GF 4.1 August 21, 2014,
when trying to access not-serializable SFSBs in Availability HA cluster configuration,
I get the exceptions below:
Related issues:
https://java.net/jira/browse/GLASSFISH-20892
https://java.net/jira/browse/GLASSFISH-20899
---------------------------
[2014-08-24T15:36:28.304-0400] [glassfish 4.1] [WARNING] [] [javax.enterprise.ejb.container] [tid: _ThreadID=99 _ThreadName=ajp-listener-1(5)] [timeMillis: 1408908988304] [levelValue: 900] [[
javax.ejb.EJBException
at com.sun.ejb.containers.EJBContainerTransactionManager.processSystemException(EJBContainerTransactionManager.java:748)
at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:698)
at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:515)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4566)
at com.sun.ejb.containers.StatefulSessionContainer.postInvokeTx(StatefulSessionContainer.java:1853)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2074)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2044)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy798.isDisableStats(Unknown Source)
at com.baw.website.beans.ui.layout.Layout.isStatsEnabled(Layout.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:363)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at com.sun.el.parser.AstValue.getValue(AstValue.java:140)
at com.sun.el.parser.AstValue.getValue(AstValue.java:204)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194)
at javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:457)
at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:852)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1854)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:456)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.CmsFilter.doFilter(CmsFilter.java:32)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.filters.EjbPingFilter.doFilter(EjbPingFilter.java:44)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.GzipResponseFilter.doFilter(GzipResponseFilter.java:149)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.FacesExceptionFilter.doFilter(FacesExceptionFilter.java:56)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.facesviews.FacesViewsForwardingFilter.doFilter(FacesViewsForwardingFilter.java:130)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.CmsFilter.doFilter(CmsFilter.java:32)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.filters.EjbPingFilter.doFilter(EjbPingFilter.java:44)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:115)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.security.WebSecurityFilter$1.call(WebSecurityFilter.java:90)
at com.flowlogix.security.WebSecurityFilter$1.call(WebSecurityFilter.java:84)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
at com.flowlogix.security.WebSecurityFilter.doFilter(WebSecurityFilter.java:83)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.ShiroInitFilter.doFilter(ShiroInitFilter.java:41)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:175)
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:745)
Caused by: java.lang.IllegalArgumentException: object is not an instance of declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1081)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1153)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4786)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:656)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at com.flowlogix.security.ShiroSecurityInterceptor.propagateShiroSecurity(ShiroSecurityInterceptor.java:64)
at sun.reflect.GeneratedMethodAccessor376.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)
at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:52)
at sun.reflect.GeneratedMethodAccessor123.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:369)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4758)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4746)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
... 107 more
]]
[2014-08-24T15:36:28.307-0400] [glassfish 4.1] [SEVERE] [] [javax.enterprise.resource.webcontainer.jsf.application] [tid: _ThreadID=99 _ThreadName=ajp-listener-1(5)] [timeMillis: 1408908988307] [levelValue: 1000] [[
Error Rendering View[/index.xhtml]
javax.el.ELException: /resources/templates/layout.xhtml @194,60 rendered="#

{layout.statsEnabled}

": javax.ejb.EJBException
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:114)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194)
at javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:457)
at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:852)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1854)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:456)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.CmsFilter.doFilter(CmsFilter.java:32)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.filters.EjbPingFilter.doFilter(EjbPingFilter.java:44)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.GzipResponseFilter.doFilter(GzipResponseFilter.java:149)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.FacesExceptionFilter.doFilter(FacesExceptionFilter.java:56)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.facesviews.FacesViewsForwardingFilter.doFilter(FacesViewsForwardingFilter.java:130)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.CmsFilter.doFilter(CmsFilter.java:32)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.filters.EjbPingFilter.doFilter(EjbPingFilter.java:44)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:115)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.security.WebSecurityFilter$1.call(WebSecurityFilter.java:90)
at com.flowlogix.security.WebSecurityFilter$1.call(WebSecurityFilter.java:84)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
at com.flowlogix.security.WebSecurityFilter.doFilter(WebSecurityFilter.java:83)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.ShiroInitFilter.doFilter(ShiroInitFilter.java:41)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:175)
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:745)
Caused by: javax.el.ELException: javax.ejb.EJBException
at javax.el.BeanELResolver.getValue(BeanELResolver.java:368)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at com.sun.el.parser.AstValue.getValue(AstValue.java:140)
at com.sun.el.parser.AstValue.getValue(AstValue.java:204)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109)
... 92 more
Caused by: javax.ejb.EJBException
at com.sun.ejb.containers.EJBContainerTransactionManager.processSystemException(EJBContainerTransactionManager.java:748)
at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:698)
at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:515)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4566)
at com.sun.ejb.containers.StatefulSessionContainer.postInvokeTx(StatefulSessionContainer.java:1853)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2074)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2044)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy798.isDisableStats(Unknown Source)
at com.baw.website.beans.ui.layout.Layout.isStatsEnabled(Layout.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:363)
... 99 more
Caused by: java.lang.IllegalArgumentException: object is not an instance of declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1081)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1153)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4786)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:656)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at com.flowlogix.security.ShiroSecurityInterceptor.propagateShiroSecurity(ShiroSecurityInterceptor.java:64)
at sun.reflect.GeneratedMethodAccessor376.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)
at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:52)
at sun.reflect.GeneratedMethodAccessor123.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:369)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4758)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4746)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
... 107 more
]]
[2014-08-24T15:36:28.338-0400] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=99 _ThreadName=ajp-listener-1(5)] [timeMillis: 1408908988338] [levelValue: 900] [[
StandardWrapperValve[Faces Servlet]: Servlet.service() for servlet Faces Servlet threw exception
java.lang.IllegalArgumentException: object is not an instance of declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1081)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1153)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4786)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:656)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at com.flowlogix.security.ShiroSecurityInterceptor.propagateShiroSecurity(ShiroSecurityInterceptor.java:64)
at sun.reflect.GeneratedMethodAccessor376.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)
at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:52)
at sun.reflect.GeneratedMethodAccessor123.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:369)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4758)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4746)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy798.isDisableStats(Unknown Source)
at com.baw.website.beans.ui.layout.Layout.isStatsEnabled(Layout.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:363)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at com.sun.el.parser.AstValue.getValue(AstValue.java:140)
at com.sun.el.parser.AstValue.getValue(AstValue.java:204)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194)
at javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:457)
at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:852)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1854)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:456)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.CmsFilter.doFilter(CmsFilter.java:32)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.filters.EjbPingFilter.doFilter(EjbPingFilter.java:44)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.GzipResponseFilter.doFilter(GzipResponseFilter.java:149)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.FacesExceptionFilter.doFilter(FacesExceptionFilter.java:56)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.facesviews.FacesViewsForwardingFilter.doFilter(FacesViewsForwardingFilter.java:130)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.CmsFilter.doFilter(CmsFilter.java:32)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.filters.EjbPingFilter.doFilter(EjbPingFilter.java:44)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:115)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.security.WebSecurityFilter$1.call(WebSecurityFilter.java:90)
at com.flowlogix.security.WebSecurityFilter$1.call(WebSecurityFilter.java:84)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
at com.flowlogix.security.WebSecurityFilter.doFilter(WebSecurityFilter.java:83)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.ShiroInitFilter.doFilter(ShiroInitFilter.java:41)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:175)
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:745)
]]
[2014-08-24T15:36:39.431-0400] [glassfish 4.1] [SEVERE] [AS-EJB-00004] [javax.enterprise.ejb.container] [tid: _ThreadID=97 _ThreadName=ajp-listener-1(3)] [timeMillis: 1408908999431] [levelValue: 1000] [[
[NRU-com.baw.website.beans.sfsb.impl.SharedWebstats]: Cannot load from BACKUPSTORE FOR Key: <[1f00900a0983b5c6-ee0001103a22bcb3-1]>]]
[2014-08-24T15:36:39.432-0400] [glassfish 4.1] [WARNING] [AS-EJB-00056] [javax.enterprise.ejb.container] [tid: _ThreadID=97 _ThreadName=ajp-listener-1(3)] [timeMillis: 1408908999432] [levelValue: 900] [[
A system exception occurred during an invocation on EJB SharedWebstats, method: public void com.baw.website.beans.sfsb.impl.SharedWebstats.ping()]]
[2014-08-24T15:36:39.432-0400] [glassfish 4.1] [WARNING] [] [javax.enterprise.ejb.container] [tid: _ThreadID=97 _ThreadName=ajp-listener-1(3)] [timeMillis: 1408908999432] [levelValue: 900] [[
javax.ejb.NoSuchObjectLocalException: The EJB does not exist. session-key: 1f00900a0983b5c6-ee0001103a22bcb3-1
at com.sun.ejb.containers.StatefulSessionContainer._getContext(StatefulSessionContainer.java:1626)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2579)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1971)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:210)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy798.ping(Unknown Source)
at com.flowlogix.ejb.StatefulUtil.pingStateful(StatefulUtil.java:68)
at com.flowlogix.web.services.EjbModule$1.service(EjbModule.java:46)
at $HttpServletRequestHandler_584822218a2dad.service(Unknown Source)
at org.got5.tapestry5.jquery.services.AjaxUploadServletRequestFilter.service(AjaxUploadServletRequestFilter.java:27)
at $HttpServletRequestHandler_584822218a2dad.service(Unknown Source)
at org.tynamo.security.services.impl.SecurityConfiguration$1.call(SecurityConfiguration.java:56)
at org.tynamo.security.services.impl.SecurityConfiguration$1.call(SecurityConfiguration.java:54)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
at org.tynamo.security.services.impl.SecurityConfiguration.service(SecurityConfiguration.java:54)
at $HttpServletRequestFilter_584822218a2dab.service(Unknown Source)
at $HttpServletRequestHandler_584822218a2dad.service(Unknown Source)
at org.apache.tapestry5.upload.internal.services.MultipartServletRequestFilter.service(MultipartServletRequestFilter.java:44)
at $HttpServletRequestHandler_584822218a2dad.service(Unknown Source)
at org.apache.tapestry5.internal.gzip.GZipFilter.service(GZipFilter.java:53)
at $HttpServletRequestHandler_584822218a2dad.service(Unknown Source)
at org.apache.tapestry5.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62)
at $HttpServletRequestFilter_584822218a2d9e.service(Unknown Source)
at $HttpServletRequestHandler_584822218a2dad.service(Unknown Source)
at org.apache.tapestry5.services.TapestryModule$1.service(TapestryModule.java:852)
at $HttpServletRequestHandler_584822218a2dad.service(Unknown Source)
at $HttpServletRequestHandler_584822218a2d9d.service(Unknown Source)
at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:171)
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:745)
]]





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

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

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

Glassfish 3.1.2 on various machines.


Attachments: Java Archive File weld-integration.jar    

 Description   

Hello,

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

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

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

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

Please verify, thank you.



 Comments   
Comment by daedalus [ 09/Jul/12 ]

Tested and confirmed!

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

Please fix this incredible bug.

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

Comment by AlexP [ 09/Jul/12 ]

Awesome it works for others as well!

Comment by AlexP [ 09/Jul/12 ]

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

Comment by AlexP [ 09/Jul/12 ]

@Daedalus

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

Comment by Hong Zhang [ 09/Jul/12 ]

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

Comment by jjsnyder83 [ 09/Jul/12 ]

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

Comment by SimY4 [ 24/Jul/12 ]

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

Comment by jjsnyder83 [ 10/Sep/12 ]

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





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

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

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

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

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

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


Tags: metro2_2_1-waived

 Description   

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

Without the empty beans.xml, no memory leak.



 Comments   
Comment by kabhal [ 30/May/12 ]

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

Comment by frank_w [ 14/Mar/13 ]

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

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

Comment by shreedhar_ganapathy [ 19/Apr/13 ]

Is the memory leak root cause identified?

Any ETA on the fix?

Comment by mtaube [ 23/Apr/13 ]

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

#!/bin/bash
for i in

{1..10000}

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

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

Can you confirm the reproduction steps?

Comment by mtaube [ 23/Apr/13 ]

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

import com.example.boot_gateway.boot_v1.*;

public class Test {

public static void testBoot() throws Exception

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

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

{ testBoot(); }

} catch (Exception ex)

{ ex.printStackTrace(); }

}
}





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

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

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

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



 Description   

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

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

This is a memory leak which leads to OutOfMemoryErrors very quickly



 Comments   
Comment by pukkaone [ 07/Dec/12 ]

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

Comment by Sivakumar Thyagarajan [ 10/Dec/12 ]

Transferring to JJ Snyder

Comment by Sivakumar Thyagarajan [ 10/Dec/12 ]

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





[GLASSFISH-21315] Ambiguous dependencies refer to the same CDI producer twice Created: 25/Feb/15  Updated: 24/Mar/15  Resolved: 24/Mar/15

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

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

Linux cps601 3.0.101-0.7.17-default #1 SMP Tue Feb 4 13:24:49 UTC 2014 (90aac76) x86_64 x86_64 x86_64 GNU/Linux
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)



 Description   

The war file that used to boot without a problem in Glassfish 4.0 is refused by Glassfish 4.1 with the following funny message (Possible dependencies show two identical @Producer methods):
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type ConfigValue<String> with qualifiers @Default
at injection point [BackedAnnotatedField] @Inject @ConfigParams private com.epnet.ese.cds.metadata.DeliveryMetadataStoreImpl.defaultMetadataPlugin
at com.epnet.ese.cds.metadata.DeliveryMetadataStoreImpl.defaultMetadataPlugin(DeliveryMetadataStoreImpl.java:0)
Possible dependencies:

  • Producer Method [ConfigValue<Object>] with qualifiers [@Any @Default] declared as [[BackedAnnotatedMethod] @Produces public com.epnet.ese.jese.config.ConfigServiceImpl.getConfigValue(InjectionPoint)],
  • Producer Method [ConfigValue<Object>] with qualifiers [@Any @Default] declared as [[BackedAnnotatedMethod] @Produces public com.epnet.ese.jese.config.ConfigServiceImpl.getConfigValue(InjectionPoint)]

at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:378)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:291)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:165)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:529)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:515)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:490)
at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:419)



 Comments   
Comment by arie_golos [ 04/Mar/15 ]

I would like to withdraw that Jira. It was caused by having two jars of the same classes but with different versions.
On the other hand, why would cdi would take into account classes that will not be loaded due to the fact that they are behind the target classes in the classpath?

Comment by jjsnyder83 [ 24/Mar/15 ]

I'm not sure where the jars are that you refer to. If they are library jars then CDI processes them as such and you would see the Ambiguous exception.

Comment by arie_golos [ 24/Mar/15 ]

Yes, they are library jars. I was referring to my mental model in which all jars in lib directory form some kind of a class path. So, when looking for a class, the CDI would search jars in the order of their appearance in that classpath and when first class is found, it stops looking any further down the path.





[GLASSFISH-13204] When CDI is enabled Web container consumes form parameters Created: 31/Aug/10  Updated: 15/Nov/10  Resolved: 15/Nov/10

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 13,204
Status Whiteboard:

weld-int-required


 Description   

When CDI is enabled and when the Web container receives a POST request with form
parameters ("application/x-www-form-urlencoded") the request entity is consumed.

Disable CDI and the request entity is not consumed. For a reproducible test case
see the Jersey issue:

https://jersey.dev.java.net/issues/show_bug.cgi?id=579



 Comments   
Comment by sandoz [ 31/Aug/10 ]

Note although this issue points to a reproducible test case using Jersey it is
possible to reproduce using just a Servlet and reading from the input stream.

Comment by jsl123 [ 09/Sep/10 ]
      • Issue 13204 has been confirmed by votes. ***
Comment by Sivakumar Thyagarajan [ 08/Oct/10 ]

Need to reproduce and analyse. Targetting for MS6

Comment by Sivakumar Thyagarajan [ 24/Oct/10 ]

Hi Paul

Whien I tried to reproduce this with latest GF, I got this NPE while exercising
the test:
curl -d x=b -b param=y http://localhost:8080/PGFormTest/formTest/

Could you please help?

[#|2010-10-
24T14:05:57.360+0530|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.g
lassfish.deployment.admin|_ThreadID=14;_ThreadName=Thread-1;|PGFormTest was
successfully deployed in 12,258 milliseconds.|#]

[#|2010-10-
24T14:06:10.222+0530|INFO|glassfish3.1|com.sun.jersey.api.core.WebAppResourceCon
fig|_ThreadID=14;_ThreadName=Thread-1;|Scanning for root resource and provider
classes in the Web app resource paths:
/WEB-INF/lib
/WEB-INF/classes|#]

[#|2010-10-
24T14:06:11.198+0530|INFO|glassfish3.1|com.sun.jersey.api.core.ScanningResourceC
onfig|_ThreadID=14;_ThreadName=Thread-1;|Root resource classes found:
class com.kickstone.test.resources.Test|#]

[#|2010-10-
24T14:06:11.199+0530|INFO|glassfish3.1|com.sun.jersey.api.core.ScanningResourceC
onfig|_ThreadID=14;_ThreadName=Thread-1;|No provider classes found.|#]

[#|2010-10-
24T14:06:11.489+0530|SEVERE|glassfish3.1|javax.enterprise.system.container.web.c
om.sun.enterprise.web|_ThreadID=121;_ThreadName=http-thread-pool-
8080(1);|WebModule[/PGFormTest]StandardWrapper.Throwable
java.lang.NullPointerException
at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactory.<init>
(CDIComponentProviderFactory.java:94)
at
com.sun.jersey.server.impl.cdi.CDIComponentProviderFactoryInitializer.initialize
(CDIComponentProviderFactoryInitializer.java:75)
at
com.sun.jersey.spi.container.servlet.WebComponent.configure(WebComponent.java:55
4)
at
com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.confi
gure(ServletContainer.java:293)
at
com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:586)
at
com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:213)
at
com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java
:355)
at
com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java
:538)
at javax.servlet.GenericServlet.init(GenericServlet.java:244)
at
org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1427)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:1059)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:1
89)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:1
75)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingS
tandardPipeline.java:91)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at
org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java
:170)
at
com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:22
5)
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:53
2)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)

Comment by jsl123 [ 24/Oct/10 ]

This is unfortunately caused by another CDI related bug in jersey. It has been
fixed in the lastest svn release.

Comment by sandoz [ 25/Oct/10 ]

You are hitting proxy bug, which can occur on re-deployments. Can you do a fresh
restart of GF and deploy?

We worked around the proxy issue for Jersey 1.5-ea03 and GF source has now been
updated to that version

Comment by Sivakumar Thyagarajan [ 29/Oct/10 ]

Marking this as weld-int-required as Paul confirmed that this issue goes away
with an integration of weld-trunk. As soon as we push a latest Weld integration,
I will test this and close it.

Comment by Sivakumar Thyagarajan [ 15/Nov/10 ]

Closing this issue as I could verify that this scenario works with the test case
provided in JERSEY-579 against latest 3.1 trunk. Integration of Weld 1.1.0.Beta2
into GlassFish 3.1 was complete a couple of days ago. The trunk (post svn commit
42731) or a nightly after saturday (b30-11_13) could be used to test this
integration.





[GLASSFISH-13132] CDI injection issue with fields on super class Created: 26/Aug/10  Updated: 20/Dec/10  Resolved: 20/Dec/10

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

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

Operating System: All
Platform: Macintosh


Attachments: File WebApplication1.tgz    
Issuezilla Id: 13,132
Status Whiteboard:

weld-int-required


 Description   

The Jersey CDI Extension implementation cannot adapt injection targets of super
classes. This problem occurs with Glassfish 3.0.1 and 3.1.

This is a place holder issue in GF as this is most likely a bug in Weld rather
than in the Weld/GlassFish integration.



 Comments   
Comment by sandoz [ 26/Aug/10 ]

Created an attachment (id=4743)
Reproducible test case

Comment by Sivakumar Thyagarajan [ 05/Oct/10 ]

Filed Weld issue https://jira.jboss.org/browse/WELD-705 to track this. Thanks to
Roberto and Paul for the testcase.

Comment by Sivakumar Thyagarajan [ 07/Oct/10 ]

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

Comment by Sivakumar Thyagarajan [ 22/Oct/10 ]

Marking as weld-int-required

Comment by Sivakumar Thyagarajan [ 19/Nov/10 ]

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

Comment by Sivakumar Thyagarajan [ 20/Dec/10 ]

The underlying issue (WELD-705) has been fixed in Weld1.1.0.CR2 and I was able to verify that the superclass injected field is not present for the subclass.

With the application at https://issues.jboss.org/secure/attachment/12337697/WebApplication3.tgz, I see this output with the latest GF3.1 with Weld 1.1.0.CR2 integrated.

[#|2010-12-20T14:06:53.184+0530|WARNING|glassfish3.1|cdiext.CDIExtension|_ThreadID=15;_ThreadName=Thread-1;|Handling BeforeBeanDiscovery event|#]

[#|2010-12-20T14:06:53.231+0530|WARNING|glassfish3.1|cdiext.CDIExtension|_ThreadID=15;_ThreadName=Thread-1;|Handling ProcessAnnotatedType event for beans.BeanTwo|#]

[#|2010-12-20T14:06:53.232+0530|WARNING|glassfish3.1|cdiext.CDIExtension|_ThreadID=15;_ThreadName=Thread-1;| type has 0 fields|#]

[#|2010-12-20T14:06:53.232+0530|WARNING|glassfish3.1|cdiext.CDIExtension|_ThreadID=15;_ThreadName=Thread-1;| replaced annotated type for class beans.BeanTwo|#]

[#|2010-12-20T14:06:53.233+0530|WARNING|glassfish3.1|cdiext.CDIExtension|_ThreadID=15;_ThreadName=Thread-1;|Handling ProcessAnnotatedType event for beans.BeanOne|#]

[#|2010-12-20T14:06:53.233+0530|WARNING|glassfish3.1|cdiext.CDIExtension|_ThreadID=15;_ThreadName=Thread-1;| type has 0 fields|#]

[#|2010-12-20T14:06:53.233+0530|WARNING|glassfish3.1|cdiext.CDIExtension|_ThreadID=15;_ThreadName=Thread-1;| replaced annotated type for class beans.BeanOne|#]

[#|2010-12-20T14:06:53.249+0530|WARNING|glassfish3.1|cdiext.CDIExtension|_ThreadID=15;_ThreadName=Thread-1;|Handling ProcessManagedBean event for beans.BeanTwo|#]

[#|2010-12-20T14:06:53.252+0530|WARNING|glassfish3.1|cdiext.CDIExtension|_ThreadID=15;_ThreadName=Thread-1;|Handling ProcessManagedBean event for beans.BeanOne|#]





[GLASSFISH-13128] java.lang.NoClassDefFoundError: org/jboss/weld/logging/messages/BeanManagerMessage Created: 26/Aug/10  Updated: 22/Oct/10  Resolved: 22/Oct/10

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

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

Operating System: All
Platform: Linux


Attachments: Text File 13128-weld-osgi-bundle-pom.diff     Zip Archive jsr88-4235311575752785530.zip    
Issuezilla Id: 13,128
Status Whiteboard:

weld-int-required


 Description   

While running arquillian tests against glassfish v3, the tests are not deployed
and I see the below in the server log:

Please find the webarchive created while running the tests.

#|2010-08-
24T09:22:07.926+0530|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.en
terprise.v3.server|_ThreadID=14;_ThreadName=Thread-1;|Exception while loading
the app|#]

[#|2010-08-
24T09:22:08.007+0530|SEVERE|glassfish3.1|com.sun.enterprise.v3.server.Applicatio
nConfigListener|_ThreadID=14;_ThreadName=Thread-1;|Error during enabling:
java.lang.Exception: Exception while loading the app :
org.glassfish.deployment.common.DeploymentException:
java.lang.NoClassDefFoundError:
org/jboss/weld/logging/messages/BeanManagerMessage
at
com.sun.enterprise.v3.server.ApplicationConfigListener.enableApplication(Applica
tionConfigListener.java:212)
at
com.sun.enterprise.v3.server.ApplicationConfigListener.handleAppEnableChange(App
licationConfigListener.java:147)
at
com.sun.enterprise.v3.server.ApplicationConfigListener.transactionCommited(Appli
cationConfigListener.java:121)
at
org.jvnet.hk2.config.Transactions$TransactionListenerJob.process(Transactions.ja
va:335)
at
org.jvnet.hk2.config.Transactions$TransactionListenerJob.process(Transactions.ja
va:326)
at
org.jvnet.hk2.config.Transactions$ListenerNotifier$1.call(Transactions.java:202)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at org.jvnet.hk2.config.Transactions$Notifier$1.run(Transactions.java:158)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:8
86)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

#]


 Comments   
Comment by Sreekanth [ 26/Aug/10 ]

Created an attachment (id=4740)
sample test application

Comment by Sreekanth [ 26/Aug/10 ]

Steps to reproduce:
==================
1)Check out the GIT workspace from http://github.com/weld/core.git
2)Add glassfish-remote-3 profile to pom.xml
3)Run mvn test -Pglassfish-remote-3
You will see the deployment problems in glassfish v3 server log.

Comment by Sivakumar Thyagarajan [ 27/Aug/10 ]

Created an attachment (id=4755)
weld-osgi-bundle pom diff to fix NoClassDefFoundError in 13128

Comment by Sivakumar Thyagarajan [ 27/Aug/10 ]

It appears that the test application uses some internal Weld artifacts such as
BeanManagerImpl and this class in turn has references to ch.qos.cal10n API and
some exception classes. These packages were not exported by the weld osgi bundle
as they are not traditionally used by normal applications. Fixing the weld osgi
bundle pom to export these packages resulted in the application deploying fine.

I have attached a diff of the weld-osgi-bundle pom.xml with the relevant
changes. Since bringing these changes to GlassFish would need an integration, I
would, for a short-term solution, provide the submitter a modified
weld-osgi-bundle.jar that could be update in the modules directory for the tests
to run.

Comment by Sivakumar Thyagarajan [ 08/Oct/10 ]

Analysis complete, need to push this to Weld bundle's OSGi headers. Targetting
for MS7

Comment by Sivakumar Thyagarajan [ 22/Oct/10 ]

Marking as weld-int-required and this is a duplicate of issue 13713

      • This issue has been marked as a duplicate of 13713 ***




[GLASSFISH-13456] OOME after multiple deployments of a sample app Created: 15/Sep/10  Updated: 08/Oct/10  Resolved: 08/Oct/10

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

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

Operating System: All
Platform: All


Attachments: File twitter-demo-1.0-SNAPSHOT.war    
Issuezilla Id: 13,456

 Description   

After multiple (5-6) deployments of a sample application, the app server throws OOME with the
following stack trace:

INFO: java.lang.OutOfMemoryError: Java heap space
INFO: at sun.nio.cs.UTF_8.newEncoder(UTF_8.java:53)
INFO: at java.lang.StringCoding$StringEncoder.<init>(StringCoding.java:215)
INFO: at java.lang.StringCoding$StringEncoder.<init>(StringCoding.java:207)
INFO: at java.lang.StringCoding.encode(StringCoding.java:266)
INFO: at java.lang.String.getBytes(String.java:946)
INFO: at java.io.UnixFileSystem.getLastModifiedTime(Native Method)
INFO: at java.io.File.lastModified(File.java:826)
INFO: at org.apache.felix.fileinstall.internal.Scanner.checksum(Scanner.java:178)
INFO: at org.apache.felix.fileinstall.internal.Scanner.checksum(Scanner.java:169)
INFO: at org.apache.felix.fileinstall.internal.Scanner.scan(Scanner.java:113)
INFO: at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:228)
SEVERE: Exception in thread "DynamicReloader"
SEVERE: java.lang.OutOfMemoryError: Java heap space
SEVERE: Exception in thread "AutoDeployer"
SEVERE: java.lang.OutOfMemoryError: Java heap space

The app server has to be killed (kill -9) and restarted.



 Comments   
Comment by Hong Zhang [ 15/Sep/10 ]

arun: can you attach the sample application which cause this?

Comment by arungupta [ 15/Sep/10 ]

Created an attachment (id=4895)
WAR attachment

Comment by arungupta [ 15/Sep/10 ]

Running the app requires to configure a database, let me know if you need steps for that.

Comment by Hong Zhang [ 15/Sep/10 ]

Does the deployment need database too? The OOM happens with the multiple
deployments, not running right?

Comment by arungupta [ 15/Sep/10 ]

Deployment should not need database.

OOME occurs during this typical cycle ...

Deploy
Access the web app a few times
Deploy
Access the web app a few times
Deploy
So on ...

And then deployment fails with OOME - typically within 6-10 times.

Am using b17.

Comment by Hong Zhang [ 15/Sep/10 ]

I see. Yes, please attach the instruction for database as well (is it using
derby?).

If you just deploy the application many times without accessing it, do you get
the OOM?

Comment by Hong Zhang [ 20/Sep/10 ]

Arun: I could not reproduce this on my box if I just deploy multiple times. So
please attach the instruction how to run the application too. And if you could
collect some memory graphs while you are doing this sequence, that will be very
helpful so we will be able to get some information about which object(s) keep
growing.

Comment by arungupta [ 20/Sep/10 ]

Thanks Hong!

You can check out the workspace from:

CVSROOT :pserver:<SUN-LDAP-ID>@sunsw.sfbay.sun.com:/sw/wpts
Module: javaone2010/javaone2010/twitter-demo

All the instructions are in readme.txt.

How can I collect memory graphs for you ?

Comment by Hong Zhang [ 20/Sep/10 ]

After some initial investigation, this seems a simiar issue as issue 12368. The
number of WebappClassLoader instances increases with redeployment and cdi was
used in the application. Assign to Siva for further investigation.

Comment by Hong Zhang [ 20/Sep/10 ]

assign to Siva and add myself to Cc

Comment by Sivakumar Thyagarajan [ 08/Oct/10 ]

The memory leak issues are tracked as part 12368 and 11668. So marking this as a
duplicate
We are waiting for a fix to WELD-570 https://jira.jboss.org/browse/WELD-570 that
would resolve this and other memory leak issues. Targetting that issue for MS7

      • This issue has been marked as a duplicate of 12368 ***




[GLASSFISH-13881] [Blocking] On Failover, Conversation-based app in cluster shows deserialization issue due to CNFE Created: 08/Oct/10  Updated: 26/Nov/10  Resolved: 19/Nov/10

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

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

Operating System: All
Platform: Macintosh


Attachments: Text File server.log     Text File server.log     File ShoppingCart.war     Text File ShoppingCartTables.sql    
Issue Links:
Dependency
depends on GLASSFISH-14179 NPE in org.glassfish.web.ha.session.m... Resolved
Issuezilla Id: 13,881

 Description   

Steps to reproduce:
1. create tables in Derby in the APP Database - see attached sql flle
2. create a cluster of 2 or more instances.
3. start cluster
4. create jdbc resource jdbc/sample using DerbyPool as the connection pool and create resource ref
under the target cluster
5. Deploy the attached ShoppingCart.war to the target cluster with availabilityenabled set to true.
6. Access one of the instance's urls say :http://localhost:28080/ShoppingCart representing inst2
7. Add some item to cart.
8. Simulate failover by hopping over to another instance's port say,
http://localhost:38080/ShoppingCart/faces/shop.xhtml?cid=1
representing inst3
9. Page does not load. Look in inst3's logs for the stack trace.

The trace I see is pasted below :

[#|2010-10-08T08:49:45.896-
0700|SEVERE|glassfish3.1|org.apache.catalina.connector.CoyoteAdapter|_ThreadID=15;_ThreadName=T
hread-1;|PWC3989: An exception or error occurred in the container during the request processing
org.jboss.weld.exceptions.WeldException: WELD-001500 Failed to deserialize proxy object
at org.jboss.weld.bean.proxy.util.SerializableProxy.readObject(SerializableProxy.java:124)
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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at org.apache.catalina.session.StandardSession.readRemainingObject(StandardSession.java:1947)
at org.apache.catalina.session.StandardSession.readObject(StandardSession.java:1855)
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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at org.apache.catalina.session.StandardSession.deserialize(StandardSession.java:1144)
at org.apache.catalina.session.StoreBase.readSession(StoreBase.java:288)
at org.glassfish.web.ha.session.management.ReplicationStore.getSession(ReplicationStore.java:527)
at org.glassfish.web.ha.session.management.ReplicationStore.getSession(ReplicationStore.java:482)
at
org.glassfish.web.ha.session.management.ReplicationStore.loadFromBackingStore(ReplicationStore.java:
392)
at org.glassfish.web.ha.session.management.ReplicationStore.load(ReplicationStore.java:376)
at org.glassfish.web.ha.session.management.ReplicationStore.load(ReplicationStore.java:371)
at org.apache.catalina.session.PersistentManagerBase.doSwapIn(PersistentManagerBase.java:1055)
at org.apache.catalina.session.PersistentManagerBase.swapIn(PersistentManagerBase.java:1016)
at org.apache.catalina.session.PersistentManagerBase.swapIn(PersistentManagerBase.java:982)
at org.apache.catalina.session.PersistentManagerBase.findSession(PersistentManagerBase.java:738)
at org.apache.catalina.session.ManagerBase.findSession(ManagerBase.java:874)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2832)
at org.apache.catalina.connector.Request.getSession(Request.java:2559)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:920)
at org.apache.catalina.core.StandardHostValve.preInvoke(StandardHostValve.java:618)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:824)

at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:721)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1014)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:220)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:530)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:511)
at java.lang.Thread.run(Thread.java:637)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.weld.bean.proxy.util.SerializableProxy.readObject(SerializableProxy.java:120)
... 62 more
Caused by: java.lang.ClassNotFoundException:
org.jboss.weld.conversation.ConversationImpl_$$_WeldProxy
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at org.apache.felix.framework.ModuleImpl.doImplicitBootDelegation(ModuleImpl.java:1499)
at org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1427)
at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:723)
at org.apache.felix.framework.ModuleImpl.access$200(ModuleImpl.java:73)
at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1690)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:604)
at com.sun.ejb.base.io.EJBObjectInputStream.resolveClass(EJBObjectInputStream.java:165)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at
org.jboss.weld.conversation.ConversationImpl_$$WeldProxy.deserializeProxy(ConversationImpl$$_Wel
dProxy.java)
... 67 more

#]


 Comments   
Comment by shreedhar_ganapathy [ 08/Oct/10 ]

Created an attachment (id=5100)
ShoppingCart App

Comment by shreedhar_ganapathy [ 08/Oct/10 ]

Created an attachment (id=5101)
Inst3 server log

Comment by shreedhar_ganapathy [ 08/Oct/10 ]

Created an attachment (id=5102)
SQL file to create tables in APP schema

Comment by shreedhar_ganapathy [ 08/Oct/10 ]

Sources shared with Siva. Issue filed for tracking purposes.

Comment by Sivakumar Thyagarajan [ 13/Oct/10 ]

Need to investigate this in light of the new proxy serialization SPIs.
Targetting this for MS7.

Comment by shreedhar_ganapathy [ 15/Oct/10 ]

This scenario is being added to HA functional testing and hence needs a fix by MS06.
Siva, could you change the target milestone to MS6 and prioritize on this issue?
This issue may be masking other issues that we would like to ferret out early.

Comment by shreedhar_ganapathy [ 15/Oct/10 ]

added cc

Comment by shreedhar_ganapathy [ 15/Oct/10 ]

cc Sudipa

Comment by sonymanuel [ 24/Oct/10 ]

Unable to try this scenario due to issue 14179.

Comment by Sreekanth [ 08/Nov/10 ]

I tried executing the same test with the patch jars provided by Siva.Now I get
the below exception.

Exception
==========

[#|2010-11-
08T15:38:23.684+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;|java.lang.RuntimeException: java.lang.NullPointerException|#]

[#|2010-11-
08T15:38:23.685+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.messaging.jmq.jmsclient.runtime.impl.BrokerInstanceImpl.start(BrokerInst
anceImpl.java:211)|#]

[#|2010-11-
08T15:38:23.685+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.messaging.jms.blc.EmbeddedBrokerRunner.start(EmbeddedBrokerRunner.java:3
31)|#]

[#|2010-11-
08T15:38:23.686+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.messaging.jms.blc.LifecycleManagedBroker.start(LifecycleManagedBroker.ja
va:454)|#]

[#|2010-11-
08T15:38:23.686+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.messaging.jms.ra.ResourceAdapter.start(ResourceAdapter.java:370)|#]

[#|2010-11-
08T15:38:23.686+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.enterprise.connectors.jms.system.ActiveJmsResourceAdapter$1.run(ActiveJm
sResourceAdapter.java:360)|#]

[#|2010-11-
08T15:38:23.687+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at java.security.AccessController.doPrivileged(Native Method)|#]

[#|2010-11-
08T15:38:23.687+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.enterprise.connectors.jms.system.ActiveJmsResourceAdapter.startResourceA
dapter(ActiveJmsResourceAdapter.java:353)|#]

[#|2010-11-
08T15:38:23.687+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.enterprise.connectors.ActiveOutboundResourceAdapter.init(ActiveOutboundR
esourceAdapter.java:129)|#]

[#|2010-11-
08T15:38:23.688+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.enterprise.connectors.inbound.ActiveInboundResourceAdapterImpl.init(Acti
veInboundResourceAdapterImpl.java:90)|#]

[#|2010-11-
08T15:38:23.688+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.enterprise.connectors.ActiveRAFactory.instantiateActiveResourceAdapter(A
ctiveRAFactory.java:135)|#]

[#|2010-11-
08T15:38:23.688+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.enterprise.connectors.ActiveRAFactory.createActiveResourceAdapter(Active
RAFactory.java:106)|#]

[#|2010-11-
08T15:38:23.688+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.createActi
veResourceAdapter(ResourceAdapterAdminServiceImpl.java:210)|#]

[#|2010-11-
08T15:38:23.689+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.createActi
veResourceAdapter(ResourceAdapterAdminServiceImpl.java:344)|#]

[#|2010-11-
08T15:38:23.689+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.enterprise.connectors.ConnectorRuntime.createActiveResourceAdapter(Conne
ctorRuntime.java:350)|#]

[#|2010-11-
08T15:38:23.689+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.enterprise.connectors.jms.system.JmsProviderLifecycle.initializeBroker(J
msProviderLifecycle.java:110)|#]

[#|2010-11-
08T15:38:23.689+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.enterprise.connectors.jms.system.JmsProviderLifecycle.postConstruct(JmsP
roviderLifecycle.java:93)|#]

[#|2010-11-
08T15:38:23.689+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:128)|#]

[#|2010-11-
08T15:38:23.690+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.hk2.component.ConstructorWomb.initialize(ConstructorWomb.java:88)|#]

[#|2010-11-
08T15:38:23.698+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.hk2.component.AbstractWombImpl.get(AbstractWombImpl.java:79)|#]

[#|2010-11-
08T15:38:23.698+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:64)|#]

[#|2010-11-
08T15:38:23.699+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.ja
va:136)|#]

[#|2010-11-
08T15:38:23.700+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:73)

#]

[#|2010-11-
08T15:38:23.700+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:326)|#]

[#|2010-11-
08T15:38:23.701+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:135)|#
]

[#|2010-11-
08T15:38:23.701+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:78
)|#]

[#|2010-11-
08T15:38:23.702+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMa
in.java:119)|#]

[#|2010-11-
08T15:38:23.702+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)|#]

[#|2010-11-
08T15:38:23.703+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)|#]

[#|2010-11-
08T15:38:23.703+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)|#]

[#|2010-11-
08T15:38:23.704+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at java.lang.reflect.Method.invoke(Method.java:597)|#]

[#|2010-11-
08T15:38:23.709+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:99)

#]

[#|2010-11-
08T15:38:23.709+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)|#]

[#|2010-11-
08T15:38:23.710+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;|Caused by: java.lang.NullPointerException|#]

[#|2010-11-
08T15:38:23.711+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at com.sun.messaging.jmq.jmsserver.data.TransactionList.<init>
(TransactionList.java:174)|#]

[#|2010-11-
08T15:38:23.711+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at com.sun.messaging.jmq.jmsserver.Broker._start(Broker.java:1166)|#]

[#|2010-11-
08T15:38:23.712+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at com.sun.messaging.jmq.jmsserver.Broker.start(Broker.java:453)|#]

[#|2010-11-
08T15:38:23.712+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.messaging.jmq.jmsserver.BrokerProcess.start(BrokerProcess.java:164)|#]

[#|2010-11-
08T15:38:23.713+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.messaging.jmq.jmsserver.DirectBrokerProcess.start(DirectBrokerProcess.ja
va:92)|#]

[#|2010-11-
08T15:38:23.713+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| at
com.sun.messaging.jmq.jmsclient.runtime.impl.BrokerInstanceImpl.start(BrokerInst
anceImpl.java:206)|#]

[#|2010-11-
08T15:38:23.714+0530|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-
1;| ... 31 more|#]

[#|2010-11-
08T15:38:23.714+0530|SEVERE|glassfish3.1|javax.enterprise.resource.resourceadapt
er.com.sun.enterprise.connectors|_ThreadID=16;_ThreadName=Thread-1;|RAR6035 :
Resource adapter start failed :

{0}

javax.resource.spi.ResourceAdapterInternalException:
java.security.PrivilegedActionException:
javax.resource.spi.ResourceAdapterInternalException: MQJMSRA_RA4001:
start:Aborting:Exception starting EMBEDDED broker=java.lang.NullPointerException
at
com.sun.enterprise.connectors.jms.system.ActiveJmsResourceAdapter.startResourceA
dapter(ActiveJmsResourceAdapter.java:369)
at
com.sun.enterprise.connectors.ActiveOutboundResourceAdapter.init(ActiveOutboundR
esourceAdapter.java:129)
at
com.sun.enterprise.connectors.inbound.ActiveInboundResourceAdapterImpl.init(Acti
veInboundResourceAdapterImpl.java:90)
at
com.sun.enterprise.connectors.ActiveRAFactory.instantiateActiveResourceAdapter(A
ctiveRAFactory.java:135)
at
com.sun.enterprise.connectors.ActiveRAFactory.createActiveResourceAdapter(Active
RAFactory.java:106)
at
com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.createActi
veResourceAdapter(ResourceAdapterAdminServiceImpl.java:210)
at
com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.createActi
veResourceAdapter(ResourceAdapterAdminServiceImpl.java:344)
at
com.sun.enterprise.connectors.ConnectorRuntime.createActiveResourceAdapter(Conne
ctorRuntime.java:350)
at
com.sun.enterprise.connectors.jms.system.JmsProviderLifecycle.initializeBroker(J
msProviderLifecycle.java:110)
at
com.sun.enterprise.connectors.jms.system.JmsProviderLifecycle.postConstruct(JmsP
roviderLifecycle.java:93)
at
com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:128)
at
com.sun.hk2.component.ConstructorWomb.initialize(ConstructorWomb.java:88)
at com.sun.hk2.component.AbstractWombImpl.get(AbstractWombImpl.java:79)
at
com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:64)
at
com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.ja
va:136)
at
com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:73)
at
com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:326)
at
com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:135)
at
com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:78
)
at
com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMa
in.java:119)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:99)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: java.security.PrivilegedActionException:
javax.resource.spi.ResourceAdapterInternalException: MQJMSRA_RA4001:
start:Aborting:Exception starting EMBEDDED broker=java.lang.NullPointerException
at java.security.AccessController.doPrivileged(Native Method)
at
com.sun.enterprise.connectors.jms.system.ActiveJmsResourceAdapter.startResourceA
dapter(ActiveJmsResourceAdapter.java:353)
... 25 more
Caused by: javax.resource.spi.ResourceAdapterInternalException: MQJMSRA_RA4001:
start:Aborting:Exception starting EMBEDDED broker=java.lang.NullPointerException
at
com.sun.messaging.jms.blc.LifecycleManagedBroker.start(LifecycleManagedBroker.ja
va:458)
at
com.sun.messaging.jms.ra.ResourceAdapter.start(ResourceAdapter.java:370)
at
com.sun.enterprise.connectors.jms.system.ActiveJmsResourceAdapter$1.run(ActiveJm
sResourceAdapter.java:360)
... 27 more
Caused by: java.lang.RuntimeException: java.lang.NullPointerException
at
com.sun.messaging.jmq.jmsclient.runtime.impl.BrokerInstanceImpl.start(BrokerInst
anceImpl.java:211)
at
com.sun.messaging.jms.blc.EmbeddedBrokerRunner.start(EmbeddedBrokerRunner.java:3
31)
at
com.sun.messaging.jms.blc.LifecycleManagedBroker.start(LifecycleManagedBroker.ja
va:454)
... 29 more
Caused by: java.lang.NullPointerException
at com.sun.messaging.jmq.jmsserver.data.TransactionList.<init>
(TransactionList.java:174)
at com.sun.messaging.jmq.jmsserver.Broker._start(Broker.java:1166)
at com.sun.messaging.jmq.jmsserver.Broker.start(Broker.java:453)
at
com.sun.messaging.jmq.jmsserver.BrokerProcess.start(BrokerProcess.java:164)
at
com.sun.messaging.jmq.jmsserver.DirectBrokerProcess.start(DirectBrokerProcess.ja
va:92)
at
com.sun.messaging.jmq.jmsclient.runtime.impl.BrokerInstanceImpl.start(BrokerInst
anceImpl.java:206)
... 31 more

Comment by Sreekanth [ 08/Nov/10 ]

Created an attachment (id=5365)
Server log after patching with jars provided by Siva

Comment by sonymanuel [ 08/Nov/10 ]

Marking as blocking. This blocks validating CDI failover cases.

The core issue is deserialization. Please ignore the NPE from MQ startup. See
log Sreekanth attached for more details.

[#|2010-11-08T15:38:14.264+0530|SEVERE|glassfish3.1|org.apache.catalina.connector.CoyoteAdapter|_ThreadID=16;_ThreadName=Thread-1;|PWC3989:
An exception or error occurred in the container during the request processing
org.jboss.weld.exceptions.WeldException: WELD-001500 Failed to deserialize proxy
object
at
org.jboss.weld.bean.proxy.util.SerializableProxy.readObject(SerializableProxy.java:123)
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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at
org.apache.catalina.session.StandardSession.readRemainingObject(StandardSession.java:1947)
at
org.apache.catalina.session.StandardSession.readObject(StandardSession.java:1855)
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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at
org.apache.catalina.session.StandardSession.deserialize(StandardSession.java:1144)
at org.apache.catalina.session.StoreBase.readSession(StoreBase.java:288)
at
org.glassfish.web.ha.session.management.ReplicationStore.getSession(ReplicationStore.java:524)
at
org.glassfish.web.ha.session.management.ReplicationStore.getSession(ReplicationStore.java:476)
at
org.glassfish.web.ha.session.management.ReplicationStore.loadFromBackingStore(ReplicationStore.java:394)
at
org.glassfish.web.ha.session.management.ReplicationStore.load(ReplicationStore.java:377)
at
org.glassfish.web.ha.session.management.ReplicationStore.load(ReplicationStore.java:372)
at
org.apache.catalina.session.PersistentManagerBase.doSwapIn(PersistentManagerBase.java:1055)
at
org.apache.catalina.session.PersistentManagerBase.swapIn(PersistentManagerBase.java:1016)
at
org.apache.catalina.session.PersistentManagerBase.swapIn(PersistentManagerBase.java:982)
at
org.apache.catalina.session.PersistentManagerBase.findSession(PersistentManagerBase.java:738)
at org.apache.catalina.session.ManagerBase.findSession(ManagerBase.java:874)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2833)
at org.apache.catalina.connector.Request.getSession(Request.java:2560)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:920)
at org.apache.catalina.core.StandardHostValve.preInvoke(StandardHostValve.java:623)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.jboss.weld.bean.proxy.util.SerializableProxy.readObject(SerializableProxy.java:119)
... 62 more
Caused by: java.lang.ClassNotFoundException:
server.org$jboss$weld$bean-$space$Sreekanth$servers$glassfish3$glassfish$nodes$agent1$instance101$applications$ShoppingCart$-ManagedBean-class_server$ShoppingCart_$$_WeldProxy
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at
org.apache.felix.framework.ModuleImpl.doImplicitBootDelegation(ModuleImpl.java:1551)
at org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1473)
at
org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:735)
at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:72)
at
org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1765)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:604)
at
com.sun.ejb.base.io.EJBObjectInputStream.resolveClass(EJBObjectInputStream.java:163)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at
server.org$jboss$weld$bean-$space$Sreekanth$servers$glassfish3$glassfish$nodes$agent1$instance101$applications$ShoppingCart$ManagedBean-class_server$ShoppingCart_$$WeldProxy.deserializeProxy(org$jboss$weld$bean$space$Sreekanth$servers$glassfish3$glassfish$nodes$agent1$instance101$applications$ShoppingCart$-ManagedBean-class_server$ShoppingCart$$_WeldProxy.java)
... 67 more

#]
Comment by Sivakumar Thyagarajan [ 10/Nov/10 ]

Analysis (thanks to Sahoo for his assistance) is complete and a workaround fix
is in progress.

Analysis:

  • Weld proxies are now loaded through a GlassFish "proxy classloader". This
    classloader search path includes the Weld bundle and the application
    classloader. The Weld bundle is included because Weld generated proxies
    reference some internal(read: not exported by the Weld osgi bundle) Weld
    implementation classes.
  • When the session is deserialized and a bean proxy is deserialized, the proxy
    Class is initially loaded through the GlassFish proxy classloader (through the
    ProxyServices SPI). During initialization of the proxy instance (readObject),
    EJBObjectInputStream while reading the class descriptor tries to resolve the
    bean proxy through the EJBObjectInputStream.resolveClass. The resolveClass
    implementation only checks the application classloader.

A temproary fix would be for resolveClass to check the proxy classloader or fix
using a fragment bundle approach. I am coming up with the fix with the latter
approach

Comment by Sivakumar Thyagarajan [ 15/Nov/10 ]

A first stab at the fix is available. Requesting SQE to run the test again and
let me know if the issue is still seen

Comment by Sivakumar Thyagarajan [ 15/Nov/10 ]
      • Issue 14179 has been marked as a duplicate of this issue. ***
Comment by Sivakumar Thyagarajan [ 16/Nov/10 ]

Fix confirmed to be solve this issue by SQE team. Getting fix reviewed and will
commit.

Comment by Sivakumar Thyagarajan [ 19/Nov/10 ]

Fixed as part of revision 42968.

Two new weld-integration related fragments are introduced:
1. weld-integration-fragment to fix issue 13881 [1]
2. weld-integration-test-fragment to handle the use of weld internal packages by
Weld arquillian tests (issue 13713).

The weld-integration-fragment is always bundled with the glassfish-jcdi package,
as we want those packages to be available for Weld generated proxies at runtime
as described at [1]. The weld-integration-test-fragment is not added to jcdi
package as that would be used only the SQE team and other developers who want to
run the arquillian tests against GlassFish.

[1]

  • detailed description of fix for 13881 -
    To fix issue 13882, the new implementation of ProxyServices SPI uses the thread
    context classloader (the application classloader) as the classloader for
    loading Weld-generated bean proxies. The classloader that loaded the Bean must
    be used to load and define the bean proxy to handle Beans with package-private
    constructor as discussed in WELD-737.

Weld proxies today have references to some internal weld implementation classes
such as javassist and org.jboss.weld.proxy.* packages. These classes are
temporarily re-exported through the weld-integration-fragment bundle so that
when the bean proxies when loaded using the application classloader will have
visibility to these internal implementation classes.

As a fix for WELD-737, Weld may use the Bean's classloader rather than asking
the ProxyServices service implementation. Weld also plans to remove the
dependencies of the bean proxy on internal implementation classes. When that
happens we can remove the weld-integration-fragment workaround and the
ProxyServices implementation.





[GLASSFISH-12599] Injected Session Bean not serializable when it should be Created: 09/Jul/10  Updated: 29/Nov/11  Resolved: 15/Nov/10

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

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

Operating System: All
Platform: All


Issuezilla Id: 12,599
Status Whiteboard:

weld-int-required


 Description   

I have a stateless session bean Foo (no-interface local view) which implements
Serializable.

When I inject this bean into a client class FooClient, in one of the following ways,

@Inject
private Foo foo;

or

@EJB
private Foo foo;

the injected member foo fails to serialize and deserialize correctly.

I tested this using writeObject(foo) to a stream followed by readObject(...)
from that stream.

In the first case (@Inject), I get a null pointer exception when calling any
method on the object returned by readObject().

In the second case (@EJB), writeObject(foo) fails because
com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate is not serializable.

In the first case, the injected instance is a javaassist proxy wrapping a
Glassfish proxy wrapping the Foo implementation. The javasssist proxy appears to
be broken as reported in https://jira.jboss.org/browse/JASSIST-97.

After patching the weld-osgi-bundle.jar with javassist-3.12.1.GA which fixes the
bug, I ran into the same problem with EJBLocalObjectInvocationHandlerDelegate as
in the second case.

To sum up:
1) Glassfish needs to ensure that any proxy it generates for a serializable EJB
is also serializable.

2) Weld needs to be upgraded to a newer version containing the Javassist bugfix.



 Comments   
Comment by Sivakumar Thyagarajan [ 13/Jul/10 ]

As part of Weld 1.1, there is work going in the Weld SPI around better handling
of serialization of dynamically created client proxies and we are handling this
as part of GF3.1.

Is FooClient a Java EE application client or a Servlet/EJB/ManagedBean where the
injection is being done? Could you explain the use-case on why you explicitly
serialize the injected bean? Could you please share the application (client) and
the NPE stack-trace?

Comment by Harald Wellmann [ 14/Jul/10 ]

My application uses Wicket for the web UI, and Wicket serializes each page to
the page store at the end of the HTTP request.

Session beans get injected into my Wicket components for communicating with the
backend.

As I said, it is completely trivial to reproduce the problem construct in a
simple test case using writeObject() on a HelloWorld SLSB, and this is
absolutely independent of Wicket.

This test also fails when using @EJB à la Java EE 5 instead of @Inject, so I
would think that Weld does not enter the scene, and this part of the problem is
entirely on the Glassfish side - assuming that
com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate is within the
Glassfish domain and not third-party code.

Comment by Harald Wellmann [ 14/Jul/10 ]

My application uses Wicket for the web UI, and Wicket serializes each page to
the page store at the end of the HTTP request.

Session beans get injected into my Wicket components for communicating with the
backend.

As I said, it is completely trivial to reproduce the problem in a simple test
case using writeObject() on a HelloWorld SLSB, and this is absolutely
independent of Wicket.

This test also fails when using @EJB à la Java EE 5 instead of @Inject, so I
would think that and this part of the problem has nothing to do with Weld and is
entirely on the Glassfish side - assuming that
com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate is within the
Glassfish domain and not third-party code.

Comment by Mahesh Kannan [ 07/Oct/10 ]

Assigning this to Marina.

Marina: Check with Linda if Local EJB references have to be Serializable

Comment by marina vatkina [ 11/Oct/10 ]

Seems like a CD issue: neither the CDI spec nor the EJB spec imposes
requirements that proxies be serializable. Latest Weld expects them to be
"passivateable". Older versions of weld maybe required it to be serializable,
but weld 1.1 doesn't.

Comment by Harald Wellmann [ 12/Oct/10 ]

Just to make the point clearer: The question is not whether EJB or CDI proxies
should be serializable IN GENERAL.

But when a user-defined class Foo implements Serializable, any proxy to Foo must
satisfy the contract of the original class Foo, so the proxy should be
serializable too.

Comment by marina vatkina [ 12/Oct/10 ]

Neither spec require ANY proxies to be serializable, whether the bean class
implements it or not. So even if Foo implements Serializable, it's proxy is not
required to do so.

Comment by Sivakumar Thyagarajan [ 13/Oct/10 ]

The weld proxy is serializable and for classes that implement serializable its
weld proxy must be serializable too. It appears that the weld de-serializable
should be fixed with an upgrade of javassist. Weld 1.1 trunk nows uses 3.13.0-GA
and once we have an integration of Weld 1.1.BETA2 with this, this issue should
be fixed. I will re-check this scenario after the integration and close this
issue for the @Inject part.

Comment by Sivakumar Thyagarajan [ 22/Oct/10 ]

Marking as weld-int-required

Comment by Sivakumar Thyagarajan [ 15/Nov/10 ]

Since Weld 1.1.BETA2 with the latest javassist release is integrated and a test-
case [1] that tries to reproduce this behaviour passes, I am closing this issue.

[1] https://svn.dev.java.net/svn/glassfish-svn/trunk/v2/appserv-
tests/devtests/cdi/javaee-integration/no-interface-local-view-proxy-serializable

Comment by buddypine [ 24/Nov/11 ]

There is an error in the tests, the SLSB is actually marked as @Stateful - but the test still passes when changed to @Stateless.

However if I directly inject the SLSB into the servlet then try to serialize the injected proxy it fails with a NotSerializableException.
Should the injected SLSB proxy not be serializable?

@WebServlet(name = "mytest", urlPatterns = { "/myurl" })
public class NoInterfaceProxySerializableEJBTestServlet extends HttpServlet {

    @Inject
    HelloNoInterfaceLocalViewSlessEJB helloNoInterfaceLocalViewSlessEJB;
.. 
[#|2011-11-24T08:45:26.535+0100|SEVERE|glassfish3.1.1|
javax.enterprise.system.std.com.sun.enterprise.server.logging
|_ThreadID=22;_ThreadName=Thread-6;|
java.io.NotSerializableException: test.ejb.__EJB31_Generated__HelloNoInterfaceLocalViewSlessEJB__Intf____Bean__
Comment by marina vatkina [ 28/Nov/11 ]

Do you have beans.xml in the your module? If not, local EJB reference is not serializable without CDI being enabled.

Comment by buddypine [ 29/Nov/11 ]

Yes I do. I'm simply modifying the Glassfish tests from here - http://java.net/projects/glassfish/sources/svn/show/trunk/v2/appserv-tests/devtests/cdi/javaee-integration/no-interface-local-view-proxy-serializable.





[GLASSFISH-12368] Memory leaks in Glassfish v3 Created: 24/Jun/10  Updated: 08/Feb/12  Resolved: 15/Nov/10

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

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

Operating System: All
Platform: Linux


Attachments: Zip Archive leak.zip    
Issuezilla Id: 12,368
Status Whiteboard:

weld-int-required


 Description   

Glassfish v3 and v3.0.1 leak memory when repeatedly redeploying the same
application.

The actual use case in our project is that we work with Eclipse and the
Glassfish plugin so that our application get redeployed automatically whenever
we save a file. After a couple of edit-save-redeploy cycles, Glassfish throws an
OutOfMemoryError (either with heap or PermGenSpace) so we have to kill the
Glassfish process and/or restart Eclipse to continue working which is rather
annoying.

This problem first occurred on Glassfish v3 (full profile). Our application uses
JPA (Hibernate), EJBs (Local Stateless Session Beans), Wicket and CDI injections
both in the EJB and web layers.

Taking heap dumps with jvisualvm after a number of redeployments, I could
observe multiple copies of our application classes loaded by different instances
of WebappClassLoader. Some of these had a GC root deep down in the Felix module
storage of the weld-osgi-bundle.

Having a look at the Glassfish and Weld sources, I noticed that the problem was
indeed caused by Weld, not by Glassfish: they registered a "singleton per
classloader" of their Container class and forgot to unregister it on undeployment.

This bug is fixed in Weld 1.0.1, so then I checked whether a more recent
Glassfish build would contain this version of Weld (and not the buggy 1.0.0.SP4
version from Glassfish v3).

At that time, Glassfish 3.0.1b21 was the most recent promoted build, and it
contained Weld 1.0.1.SP3, so I gave it a try, and the problem was gone, or at
least I could redeploy my application a much larger number of times without any
memory issues.

I was looking forward to using the official 3.0.1 release instead of the
promoted build, but unfortunately this release has even more drastic memory
leaks on repeated redeployment of our application.

So far, I have no clue what the cause might be, I don't think it is Weld this
time. Heap dumps do not give much indication either; this time I can see
multiple instances of WebAppClassLoader most of which do not have a GC root at
all, and the remaining ones have a GC root in (Timer)Thread.contextClassLoader.

I'll try to isolate the problem and hopefully attach a small web app to this
issue to make it reproducible.

We are using Sun JDK 1.6.0_20 on Ubuntu 10.04 and Windows XP.



 Comments   
Comment by Alexis MP [ 24/Jun/10 ]

cc

Comment by Hong Zhang [ 24/Jun/10 ]

Yes, a small application which could be used to reproduce the problem will be
great. Thanks!

Comment by Harald Wellmann [ 26/Jun/10 ]

Using Eclipse Memory Analyzer which provides more detailed information than
jvisualvm, I discovered the following:

1) There are multiple instances of WebappClassLoader which do not get garbage
collected since they are strongly reachable from
javassist.util.proxy.ProxyFactory.proxyCache, a static member in
weld-osgi-bundle.jar.

2) My application uses Hibernate (contained in the WAR) and CDI (implemented by
the Weld module from Glassfish). Hibernate, Weld and the Glassfish Integration
Module all use javassist. In my heap dump I can see just one copy of the
javassist.util.proxy.ProxyFactory class, but multiple copies of lots of other
javassist.* classes.

My WAR contains Hibernate with all its dependencies, including javassist, and
the Weld OSGi bundle wraps another copy of javassist which for some reason is
not fully private: Bundle org.jboss.weld.osgi-bundle exports package
javassist.util.proxy while keeping all other javassist packages private.

This means that the javassist module as seen by Hibernate is broken: the
javassist.util.proxy package comes from the global Weld bundle class loader via
parent delegation, whereas all other javassist packages come from the same
WebappClassLoader as Hibernate.

3) The static proxyCache is a WeakHashMap, mapping class loaders to maps of
proxied classes. Apparently the intention is that all proxies for classes from a
given classloader should get garbage collected when the given classloader is no
longer strongly reachable.

However, the WeakHashMap Javadoc clearly states that map entries will NOT get
cleared when the key is strongly reachable from the value. But here the proxy
map for my WebappClassLoader contains a Hibernate/javaassist proxy for one of my
entity classes which again strongly references the WebappClassLoader.

So this seems to be causing the PermGen leak.

Comment by Hong Zhang [ 26/Jun/10 ]

Thanks for the investigation. From your analysis, seems this is still mostly
related to weld. Assign to Siva for further investigation.

Comment by Harald Wellmann [ 08/Jul/10 ]

Created an attachment (id=4553)
Example project demonstrating memory leak

Comment by Harald Wellmann [ 08/Jul/10 ]

Now here is a simple example project, containing nothing but a POM, two entity
classes and a @Singleton @Startup bean creating a couple of entities on startup.

Hibernate 3.5.3 is used as persistence provider, using the default Derby data
source (jdbc/__default).

Simply run mvn package, deploy to Glassfish a couple of times, or import the
project into Eclipse and do a couple of whitespace modifications to trigger
redeployment, and you'll see PermGen space filling up.

Running on Linux amd64 with 256m heap and 96m PermSize, I get a PermGen
exception after 5 or 6 redeployments.

In a heap dump you can see most of the symptoms I noted in the analysis of my
larger web app: multiple WebappClassLoader instances, multiple copies of my
application classes and of most javassist classes, except the ones from package
javassist.util.proxy.

Hope this helps.

Comment by Harald Wellmann [ 08/Jul/10 ]

Addendum:

You need to declare the JBoss Maven repository, either in your settings.xml or
in the POM of the example:

<repository>
<id>JBoss</id>
<url>http://repository.jboss.org/nexus/content/groups/public</url>
</repository>

Comment by Harald Wellmann [ 11/Jul/10 ]

Seems they did something about this in Weld:
https://jira.jboss.org/browse/WELD-453

Comment by Harald Wellmann [ 13/Jul/10 ]

Same problem reproducible in 3.1-b09.

Comment by Sivakumar Thyagarajan [ 13/Jul/10 ]

Yes, there is another related WELD issue
https://jira.jboss.org/browse/WELD-476 that captures a similar out-of-memory
issue. NetBeans was earlier adding a beans.xml by default to all Java EE 6
applications and thus large web non-CDI application were also affected by this.
We have since fixed NetBeans to not cdi-enable web-applications by default.

A portion of the Weld changes have been made in the Weld trunk as per the latest
comment in WELD-476. We hope to integrate a latest version of Weld 1.1 (trunk)
into GlassFish v3.1 milestone 3(code freeze next Monday). I would also test the
application attached in this issue against the new integtation. Please let us
know if there are any updates on this.

Comment by Harald Wellmann [ 14/Jul/10 ]

I don't think WELD-476 is related to this problem, they are just trying to
reduce the overall memory footprint.

My problem is to do with dangling classloaders that do not get garbage
collected, so even if the Weld guys reduce their memory footprint by 90 %, the
leak I'm experiencing will still occur after a sufficient number of redeployments.

Their use of javasisst is definitely dodgy, they should not export just one
package from that bundle and keep the rest private. This is bound to cause havoc
for other components using javassist (like Hibernate in my case).

Weld trunk currently still has this javassist export in the manifest headers, so
I do not expect the problem to simply go away with the integration of Weld 1.1.0
or whatever the next release will be.

Have you been able to reproduce the leak with the test case I provided?

Comment by Harald Wellmann [ 26/Jul/10 ]

Problem still persists with upgraded version of Weld in Glassfish 3.1b12.

I filed a bug report for Weld in https://jira.jboss.org/browse/WELD-570.

Comment by Sivakumar Thyagarajan [ 06/Aug/10 ]

Thanks hwellmann for the analysis. I was able to reproduce the scenario and see
the multiple WebappClassloaders(of earlier version of the Webapp) still being
held and the VM running out of PermGen space after multiple re-deploys. I also
agree with his analysis. I am working with the Weld team on this. They are
working on integrating a latest version of Javassist (see
https://jira.jboss.org/browse/WELD-582 added as a dep of
https://jira.jboss.org/browse/WELD-570) which should remove the issues are
Javassist. With the new Weld proxy serialization SPI changes, we can also reduce
the Javassist exports in the weld-osgi-bundle.

Comment by rjdkolb [ 19/Aug/10 ]

Some interesting reading on class loaders and memory leaks :
http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java
http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded
http://blogs.sun.com/fkieviet/entry/more_on..._how_to_fix
http://blogs.sun.com/fkieviet/entry/javaone_2007

A similar issue :
https://glassfish.dev.java.net/issues/show_bug.cgi?id=11159

Comment by Sivakumar Thyagarajan [ 08/Oct/10 ]
      • Issue 13456 has been marked as a duplicate of this issue. ***
Comment by Sivakumar Thyagarajan [ 08/Oct/10 ]

We are waiting for a fix to WELD-570 https://jira.jboss.org/browse/WELD-570 that
would resolve this and other memory leak issues. Targetting this for MS7

Comment by Sivakumar Thyagarajan [ 22/Oct/10 ]

Marking as weld-int-required

Comment by Sivakumar Thyagarajan [ 15/Nov/10 ]

With the latest integration of Weld 1.1.MS2 [1] and resolution of WELD-570, I
don't see these leaks anymore. I was able to re-deploy the sample app attached
with this issue about 40-50 times and did not see a marked increase in Permgen
space and multiple webappclassloaders being held. Hence I am closing this issue.
Please let me know or update this issue, if you still see this issue.

[1] Integration of Weld 1.1.0.Beta2 into GlassFish 3.1 was complete a couple of
days ago. The trunk (post svn commit 42731) or a nightly after saturday (b30-
11_13) could be used to test this integration.

Comment by invinity [ 04/Apr/11 ]

Although I haven't dug into the exact memory behavior, I believe I am experiencing this same issue with the currently downloadable version of GF (3.1build43).

I'm using it with Eclipse 3.6 on Windows 7 64bit and after about 10 deployments of a relatively small application from Eclipse, my GF instance is using 1GB+ of memory and seems to peg one of the cores of my CPU (as it sits nearly constantly at 50% CPU usage). The application is deployed via an EAR project that has one EJB project and one web project under it. The EJBs are using JPA (EclipseLink), but no other EE services and the web project is using JSF and JAX-RS.

From what I gather looking at the past GF builds, the fix for this bug should be in the release I am using, but can someone in the know confirm this for sure? If I am running a build with the fix, then is there any advice on how to determine, for sure, where my problem is stemming from?

TIA
-matt

Comment by saboobaker [ 08/Feb/12 ]

We are facing same issue with Glassfish 3.1.1. We notice that when the application is deployed several times (4 or 5 times), glassfish reports permgen out of memory error. We have seen it on Windows as well as Linux platforms. On one of the instances, we do not have embedded eclipse.

Our project also uses Hibernate and Spring.





[GLASSFISH-10658] Cannot define a bean in a portable extension. Created: 29/Oct/09  Updated: 15/Nov/09  Resolved: 15/Nov/09

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

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

Operating System: All
Platform: All


Attachments: File ee6testframework.tar     Java Archive File frameworktest.jar     File testwar.tar    
Issuezilla Id: 10,658

 Description   

I am trying to implement a portable extension as explained in JSR 299. It is a very simple usecase.

My test httpservlet contains an @inject as follows.

<snip>
@Inject ABeanInterface bean;
</snip>

The portable extension would then define the ABeanInterface and its implementation. As defined in
the chapter 11.5.2, the portable extension would add an implementation Bean<?> interface to
the AfterBeanDiscovery event with the bean definition.

But injection to http servlet always fails with the following exception.

Caused by: javax.enterprise.inject.UnsatisfiedResolutionException: interface
org.glassfish.test299.ABeanInterface; binding types = [@Default]Unable to resolve any Managed Beans
at org.jboss.weld.BeanManagerImpl.getBean(BeanManagerImpl.java:996)
at org.jboss.weld.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:966)
at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:78)
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:683)
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:695)
at org.jboss.weld.SimpleInjectionTarget$1.proceed(SimpleInjectionTarget.java:108)
at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:123)
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:47)
at org.jboss.weld.SimpleInjectionTarget.inject(SimpleInjectionTarget.java:102)
at org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.java:174)
at
com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBe
an(ManagedBeanManagerImpl.java:456)
at
com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBe
an(ManagedBeanManagerImpl.java:423)
at
com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionM
anagerImpl.java:295)

Let me know, if you need the test to reproduce this.



 Comments   
Comment by rogerk [ 29/Oct/09 ]

Assigning to Ken (injection integration).

Comment by ksak [ 29/Oct/09 ]

Reassigning to Roger.

Comment by ksak [ 29/Oct/09 ]

Reassigning to Roger

Comment by rogerk [ 29/Oct/09 ]

Can you provide a test case?

Comment by binod [ 29/Oct/09 ]

Created an attachment (id=3687)
Portable Extension

Comment by binod [ 29/Oct/09 ]

Created an attachment (id=3688)
Test war application

Comment by binod [ 30/Oct/09 ]

Added two files. First is the test frame work. It contains bean interface, implementation. The second is the
httpservlet on which the bean need be injected to.

I just dropped the test framework jar file in the AS_HOME/lib directory, restart the server and run the http
servlet. It produces the exception.

Comment by binod [ 02/Nov/09 ]

Filed a JIRA issue.
https://jira.jboss.org/jira/browse/WELD-233

Comment by rogerk [ 05/Nov/09 ]

I;ve verified that this works with the latest build of weld (from trunk).
It should be fixed in the next integration. I'm reattaching the jar since I had
to change an import for a changed weld class (AnnotationLiteral).

Comment by rogerk [ 05/Nov/09 ]

Created an attachment (id=3786)
xtension jar containing the correct import for AnnotationLiteral

Comment by binod [ 08/Nov/09 ]

Could you please let me know, which GF build can I use to test this and continue with my further
prototyping?

Comment by binod [ 15/Nov/09 ]

I tested with 11/13 nightly.





[GLASSFISH-11329] META-INF/beans.xml in WAR classpath not sufficient to activate CDI Created: 17/Dec/09  Updated: 08/Jan/10  Resolved: 08/Jan/10

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

Type: New Feature Priority: Critical
Reporter: mojavelinux Assignee: rogerk
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 11,329

 Description   

If a WAR is deployed containing WEB-INF/classes/META-INF/beans.xml, CDI does not
get activated (no beans are detected). Activation only happens if the WAR
contains WEB-INF/beans.xml.

I'm not sure why GlassFish V3 is having a problem finding beans.xml in the
META-INF directory of the WAR classpath. I can't tell if it is a problem in Weld
or a problem in GlassFish V3 somewhere.

Related Weld issue: https://jira.jboss.org/jira/browse/WELD-347



 Comments   
Comment by rogerk [ 17/Dec/09 ]

Will take a look.

Comment by mojavelinux [ 17/Dec/09 ]

According to section 12.1 of the JSR-299 specification:

Bean classes of enabled beans must be deployed in bean archives.

  • A library jar, EJB jar, application client jar or rar archive is a bean
    archive if it has a file named beans.xml in the META-INF directory.
  • The WEB-INF/classes directory of a war is a bean archive if there is a file
    named beans.xml in the WEB-INF directory of the war.
  • A directory in the JVM classpath is a bean archive if it has a file named
    beans.xml in the META-INF directory.

It really depends on how loosely you interpret these rules. Technically,
WEB-INF/classes/META-INF is not a valid location. But that seems really
inconvenient because it is the one classpath that doesn't allow use of the
META-INF directory for declaring a bean archive.

Comment by mojavelinux [ 17/Dec/09 ]

JBoss AS 6 supports the location cited in this issue. I'm not arguing it is
correct, just that it works.

Comment by rogerk [ 08/Jan/10 ]

This is filed as : https://jira.jboss.org/jira/browse/WELD-347

Marking here as feature request (as is marked in JIRA issue).





[GLASSFISH-11135] ProcessInjectionTarget<X> doesn't work for servlets, filters and other JavaEE components Created: 22/Nov/09  Updated: 11/Nov/10  Resolved: 11/Nov/10

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

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

Operating System: All
Platform: Linux


Issuezilla Id: 11,135
Status Whiteboard:

v3_exclude


 Description   

Pete says:
--------------
a) for each injection into a non-contextual Java EE component (such as a
servlet, WS, EJBs), the EE server must cause a ProcessInjectionTarget<T> event
to be fired. Furthermore, if an observer of the event calls
processInjectionTarget.setInjectionTarget(), then the replaced injection target
must be used when injection is performed upon the EE component supporting
injection. To aid the container with doing this, I have added a method with
signature:

public <X> InjectionTarget<X> fireProcessInjectionTarget(AnnotatedType<X> type);

to

http://anonsvn.jboss.org/repos/weld/api/trunk/weld-spi/src/main/java/org/jboss/weld/manager/api/WeldManager.java

It's also important to note that

public <T> InjectionTarget<T> createInjectionTarget(EjbDescriptor<T> descriptor);

should only be used for obtaining a reference to the InjectionTarget for
contextual EJBs, the fireProcessInjectionTarget method should be used for
non-contextual EJBs.
--------------------------

I don't see any code in v3 that calls WeldManager#fireProcessInjectionTarget()
Perhaps, the following patch would fix it(but I haven't tried it)

Index:
web/weld-integration/src/main/java/org/glassfish/weld/services/JCDIServiceImpl.java
===================================================================

web/weld-integration/src/main/java/org/glassfish/weld/services/JCDIServiceImpl.java
(revision 34631)
+++
web/weld-integration/src/main/java/org/glassfish/weld/services/JCDIServiceImpl.java
(working copy)
@@ -168,11 +168,12 @@
WeldBootstrap bootstrap =
weldDeployer.getBootstrapForApp(bundle.getApplication());

BeanManager beanManager = bootstrap.getManager(bda);
+ WeldManager weldManager = bootstrap.getManager(bda);

AnnotatedType annotatedType =
beanManager.createAnnotatedType(managedClass);

  • InjectionTarget it = beanManager.createInjectionTarget(annotatedType);

+ InjectionTarget it = weldManager.fireProcessInjectionTarget(annotatedType);
+
CreationalContext cc = beanManager.createCreationalContext(null);

managedObject = it.produce(cc);



 Comments   
Comment by jitu [ 23/Nov/09 ]

Reassigning this to myself

Comment by jitu [ 01/Dec/09 ]

The above patch fires events for every instance creation and also these events
need to be fired before AfterBeansDiscovery event. So the correct patch is to
fire these events between WeldDeployer#startInitialization() and
WeldDeployer#deployBeans(). This is fixed for non-contextual EE components like
Servlet and Servlet event listener classes in v3.

TODO

  • It needs to be done some other non-contextual EE components like JSP tag handlers
  • Also, InjectionTarget<X> from the event needs to be used for instance
    creation(an observer may have set an InjectionTarget in the ProcessInjectTarget
    event). So need to store the InjectionTarget from the event and use it
    JCDIServiceImpl.java
  • Also, weld will provide a better way to do this. So need to follow-up with weld.

So targetting this for 3.1

Comment by kumara [ 01/Dec/09 ]

Excluding from v3 defect tracking.

Comment by rogerk [ 26/Jul/10 ]

assign to siva

Comment by Sivakumar Thyagarajan [ 07/Oct/10 ]

Need to work with Jitu and Pete to find out about relevant Weld SPI change

Comment by jitu [ 29/Oct/10 ]

Assigning this to myself

Comment by jitu [ 05/Nov/10 ]

will store InjectionTarget in BeanDeploymentArchiveImpl.java, and use it
JCDIServiceImpl.java

Comment by jitu [ 11/Nov/10 ]

$ svn ci web/weld-integration/src/main/java/org/glassfish/weld/WeldDeployer.java
web/weld-
integration/src/main/java/org/glassfish/weld/services/JCDIServiceImpl.java
web/weld-
integration/src/main/java/org/glassfish/weld/BeanDeploymentArchiveImpl.java
Sending web/weld-
integration/src/main/java/org/glassfish/weld/BeanDeploymentArchiveImpl.java
Sending web/weld-
integration/src/main/java/org/glassfish/weld/WeldDeployer.java
Sending web/weld-
integration/src/main/java/org/glassfish/weld/services/JCDIServiceImpl.java
Transmitting file data ...
Committed revision 42748.





[GLASSFISH-11131] Passivation of injected resources in to EJB and jsr299 beans Created: 22/Nov/09  Updated: 01/Dec/09  Resolved: 01/Dec/09

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

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

Operating System: All
Platform: Macintosh


Attachments: XML File jsr299-tck-impl-suite.xml    
Issuezilla Id: 11,131

 Description   

This bug is related to passivation of injected javaEE resources in to JSR299
Beans and EJB.

There is a SFSB EJB bean injected in to a JSR299 Bean and when this bean is tried
to be serialized/de-serialized it fails to create the original bean. Looks like the
proxy which wraps the orignal SFSB is not serializable.

Similarly, there is a jsr299 Bean injected with JavaEE resources such as
EntityManager and EntityManagerFactory. When serialization/deserialization
happens the proxy wrapping EntityManager and EntityManagerFactory does not
seem to be serializable.

Passivation of EJB and other injected EE resources is JSR 299 requirements. See
6.6.1, 6.6.2 and 7.3.6 of jsr299 spec.



 Comments   
Comment by vivekp [ 22/Nov/09 ]

The corresponding JIRA issue on weld is:
https://jira.jboss.org/jira/browse/CDITCK-69. As per Pete's evaliuation
"readResolve() method is not being called on the SerializedProxy before the
instance is assigned to the field"

To reproduce this issue:

Follow the instructions at, http://appserver.sfbay.sun.com/Wiki.jsp?
page=Jsr299TckRunning.

To run this particular test replace the jsr299-tck-impl.suite.xml inside jsr299-
tck-1.0.1-SNAPSHOT/artifact directory by the one attached.

Comment by vivekp [ 22/Nov/09 ]

Created an attachment (id=3971)
jsr299-tck-impl-suite.xml

Comment by ludo [ 23/Nov/09 ]

maybe https://glassfish.dev.java.net/issues/show_bug.cgi?id=11150 is related?

Comment by Sanjeeb Sahoo [ 25/Nov/09 ]

OK, this turned out to be yet another class loading issue. The solution for the
time being is to export these two packages from weld-osgi-bundle:

org.jboss.weld.bean.builtin; org.jboss.weld.bean.builtin.ee

I don't have the latest weld source to generate a patch, but it is as simple as
updating the pom.xml with above package names. I have tested
testPassivationOfEjbs test successfully.

More details:
---------------------
Yes, writeReplace is being called which is why SerializedProxy is written to the
stream, but this SerializedProxy has handler of type
org.jboss.weld.bean.builtin.CallableMethodHandler which in turn has a field of
type org.jboss.weld.bean.builtin.ee.AbstractEECallable. Packages for these two
classes are not exported by weld bundle, so application class loader can't load
them. Unfortunately, the tests are written such that default ObjectInputStream
is used which in turn uses something called "latest user defined class loader"
to load user defined classes. During this test execution, "latest user defined
class loader" is application class loader. More over, deserialization logic is
taking an alternate course when it is not able to load these classes and I am
quite sure that's as per Java I/O spec. So, exporting those packages makes the
test pass.

For Pete & JSR 299 folks:
-------------------------------------------------------
I am not sure why the test is using ObjectInputStream and ObjectOutputStream to
read & write managed beans. In GlassFish, we use specialized ObjectInputStream
and ObjectOutputStream to read and write container managed objects. Those
specialized streams contain extra data like OSGi bundle details for a class. I
would expect managed bean container to have an SPI which an appserver can use to
provide suitableObjectInputStream and ObjectOutputStream objects for use. I
think this is something to think about in future.

Final Thoughts:
-------------------------
Looking at the number of packages exported by weld bundle, I think we need to
look at the class loading strategy wrt javassist more closely after this release.

Comment by rogerk [ 01/Dec/09 ]

the weld osgi bundle pom.xml has the two packages exported:
org.jboss.weld.bean.builtin; org.jboss.weld.bean.builtin.ee

The test passes.





[GLASSFISH-10350] Double EE-style servlet injection in 299-enabled app Created: 16/Oct/09  Updated: 29/Oct/09  Resolved: 29/Oct/09

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 10,350

 Description   

EE dependencies within servlet instances are being injected twice for 299-enabled applications.



 Comments   
Comment by rogerk [ 29/Oct/09 ]

The original weld related code that was put into J2EEInstanceListener has been
removed - since injection is now handled by createManagedObject.





[GLASSFISH-10590] ql: failed to deploy numberguess.war on AIX Created: 26/Oct/09  Updated: 18/Apr/11  Resolved: 18/Apr/11

Status: Resolved
Project: glassfish
Component/s: cdi, web_container
Affects Version/s: V3
Fix Version/s: 3.1.1

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

Operating System: AIX
Platform: All


Issue Links:
Duplicate
duplicates GLASSFISH-16364 OSGI issue shown by Bean validator on... Resolved
Issuezilla Id: 10,590
Status Whiteboard:

v3_exclude

Tags: 3_1_1-approved

 Description   

ql: failed to deploy numberguess.war on AIX

web.zip from
http://hudson.glassfish.org/job/gf-trunk-build-continuous/
#3015, Oct. 26, 2009, 100% pass on Solaris x86.

On AIX 6.1 with JDK1.6:
deploy-v3-impl:
[echo] deploying numberguess.war
deploy-v3-impl-unix:
[exec] com.sun.enterprise.admin.cli.CommandException: remote failure:
Exception while loading the app : javax.validation.ValidationException:
Unable to find a default provider
[exec] Command deploy failed.
[exec] Result: 1

[#|2009-10-26T18:05:49.326-0500|INFO|glassfish|org.jboss.weld.bootstrap.WeldBootstrap|
_ThreadID=13;_ThreadName=Thread-3;|Weld 1.0.0-CR1-SP1|#]

[#|2009-10-26T18:05:49.371-0500|SEVERE|glassfish|javax.enterprise.system.core.org.glassfish.internal.data|
_ThreadID=13;_ThreadName=Thread-3;|
Exception while invoking class org.glassfish.weld.WeldDeployer load method
javax.validation.ValidationException: Unable to find a default provider
at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:264)
at javax.validation.Validation.buildDefaultValidatorFactory(Validation.java:111)
at
org.glassfish.weld.services.ValidationServicesImpl.<init>(ValidationServicesImpl.java:49)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:232)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:86)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:165)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:211)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:316)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:169)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:272)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:305)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:320)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1159)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunnerImpl.java:83)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1218)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1207)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:362)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:201)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:100)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:241)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:789)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:697)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:952)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:166)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:735)

#]


 Comments   
Comment by jluehe [ 26/Oct/09 ]

...

Comment by kumara [ 27/Oct/09 ]

AIX support being deferred to v3.1.

Comment by rogerk [ 18/Jun/10 ]

Can you please try the latest numberguess app?

Comment by scatari [ 05/Apr/11 ]

Targeting fix for 3.1.1.

Comment by rogerk [ 05/Apr/11 ]

This seems related to:

http://java.net/jira/browse/GLASSFISH-10568

In which case, it could be an IBM JDK issue...

Comment by scatari [ 15/Apr/11 ]

Reopening for 3.1.1 as AIX is a supported platform for this release.

Comment by Sivakumar Thyagarajan [ 18/Apr/11 ]

This issue appears to be a duplicate of GLASSFISH-16364, and is due to the non-availability of services specified through the ServiceProvider mechanism in IBM JDK. In this specific case, it is the ValidationFactory service. Marking this as a duplicate.

Comment by Sivakumar Thyagarajan [ 18/Apr/11 ]

Duplicate of GLASSFISH-16364





[GLASSFISH-10399] name change for 299 API / impl .jars Created: 19/Oct/09  Updated: 29/Oct/09  Resolved: 29/Oct/09

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 10,399

 Description   

The latest 299 integration introduces new names for the 299 api (weld-osgi-bundle.jar) and impl
(weld-integration.jar) modules. We need to update all the glassfish .jars that refer to a collection of
API/impl modules to ensure they use the new names. Listing the ones I know about below with some
potential owners but this list may not be exhaustive.

1. glassfish-embedded-static-shell.jar :
(is there another embedded .jar too? )

2. gf-client.jar / appserv-rt.jar

3. javaee.jar



 Comments   
Comment by ksak [ 19/Oct/09 ]

Added to cc-list

Comment by ludo [ 27/Oct/09 ]

Stripped API jar
(http://download.java.net/maven/2/javax/javaee-api/6.0-SNAPSHOT/) build system
has be changed to get apis from weld.

Comment by rogerk [ 29/Oct/09 ]

Kenneth Saks wrote:
>
> On Oct 27, 2009, at 3:11 PM, Roger Kitain wrote:
>
>> Hello folks -
>>
>> Has this issue been resolved w/r/t the respective jars Ken outlines:
>>
>> 1. glassfish-embedded-static-shell.jar : Marina / Siraj ?
>
> Turns out the embedded static shell .jar was already ok at the time I filed
the bug. It was a sniffer name change that caused the embeddable ejb test to fail.
>

------- Additional comments from ludo@dev.java.net Tue Oct 27 22:17:49 +0000
2009 -------
Stripped API jar
(http://download.java.net/maven/2/javax/javaee-api/6.0-SNAPSHOT/) build system
has be changed to get apis from weld.

Jane Young wrote:
> Looks like Ludo has already made the changes in
javaee-api/javax.javaee/pom.xml for javaee.jar:
>
https://glassfish-svn.dev.java.net/source/browse/glassfish-svn/trunk/v3/javaee-api/javax.javaee/pom.xml?rev=33265&r1=32245&r2=33265
>
> Thanks, Ludo!





[GLASSFISH-9880] Regression: Blocking: classes missing from webbeans-osgi-bundle.jar Created: 30/Sep/09  Updated: 02/Oct/09  Resolved: 02/Oct/09

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

Type: Bug Priority: Critical
Reporter: lidiam Assignee: rogerk
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 9,880

 Description   

build: b63 - b65

Starting with build b63 I cannot compile webbeans test application. The
following classes are not found:

[javac] Compiling 4 source files to C:\ws\svn\sqe\modules\jsf\jsf2.0\webbean
s\build\webbeans\WEB-INF\classes
[javac] C:\ws\svn\sqe\modules\jsf\jsf2.0\webbeans\src\java\webbeans\numbergu
ess\Game.java:9: cannot find symbol
[javac] symbol : class Named
[javac] location: package javax.enterprise.inject
[javac] import javax.enterprise.inject.Named;
[javac] ^
[javac] C:\ws\svn\sqe\modules\jsf\jsf2.0\webbeans\src\java\webbeans\numbergu
ess\Game.java:15: cannot find symbol
[javac] symbol: class Named
[javac] @Named
[javac] ^
[javac] C:\ws\svn\sqe\modules\jsf\jsf2.0\webbeans\src\java\webbeans\numbergu
ess\MaxNumber.java:14: cannot find symbol
[javac] symbol : class BindingType
[javac] location: package javax.enterprise.inject
[javac] import javax.enterprise.inject.BindingType;
[javac] ^
[javac] C:\ws\svn\sqe\modules\jsf\jsf2.0\webbeans\src\java\webbeans\numbergu
ess\MaxNumber.java:19: cannot find symbol
[javac] symbol: class BindingType
[javac] @BindingType
[javac] ^
[javac] C:\ws\svn\sqe\modules\jsf\jsf2.0\webbeans\src\java\webbeans\numbergu
ess\Random.java:14: cannot find symbol
[javac] symbol : class BindingType
[javac] location: package javax.enterprise.inject
[javac] import javax.enterprise.inject.BindingType;
[javac] ^
[javac] C:\ws\svn\sqe\modules\jsf\jsf2.0\webbeans\src\java\webbeans\numbergu
ess\Random.java:19: cannot find symbol
[javac] symbol: class BindingType
[javac] @BindingType
[javac] ^
[javac] 6 errors
[javac] Compile failed; see the compiler error output for details.

The package itself is found in:

webbeans-osgi-bundle.jar
0 Tue Sep 22 14:29:32 PDT 2009 javax/enterprise/
0 Tue Sep 22 14:29:32 PDT 2009 javax/enterprise/context/
(...)
0 Tue Sep 22 14:29:32 PDT 2009 javax/enterprise/inject/
464 Tue Sep 22 13:53:38 PDT 2009 javax/enterprise/inject/Alternative.class
884 Tue Sep 22 13:53:38 PDT 2009 javax/enterprise/inject/AmbiguousResolutionE
xception.class
4908 Tue Sep 22 13:53:38 PDT 2009 javax/enterprise/inject/AnnotationLiteral.cl
ass
496 Tue Sep 22 13:53:38 PDT 2009 javax/enterprise/inject/Any.class
846 Tue Sep 22 13:53:38 PDT 2009 javax/enterprise/inject/CreationException.cl
ass
504 Tue Sep 22 13:53:38 PDT 2009 javax/enterprise/inject/Default.class
436 Tue Sep 22 13:53:38 PDT 2009 javax/enterprise/inject/Disposes.class
864 Tue Sep 22 13:53:38 PDT 2009 javax/enterprise/inject/IllegalProductExcept
ion.class
837 Tue Sep 22 13:53:38 PDT 2009 javax/enterprise/inject/InjectionException.c
lass
1107 Tue Sep 22 13:53:38 PDT 2009 javax/enterprise/inject/Instance.class
632 Tue Sep 22 13:53:38 PDT 2009 javax/enterprise/inject/New.class
397 Tue Sep 22 13:53:38 PDT 2009 javax/enterprise/inject/Nonbinding.class
446 Tue Sep 22 13:53:38 PDT 2009 javax/enterprise/inject/Produces.class
852 Tue Sep 22 13:53:38 PDT 2009 javax/enterprise/inject/ResolutionException.
class

However as you can see above, javax.enterprise.inject.Named and
javax.enterprise.inject.BindingType are missing. This app compiles fine against
b61 and the classes are found in webbeans-osgi-bundle.jar:

webbeans-osgi-bundle.jar
448 Tue Jul 28 19:42:36 PDT 2009 javax/enterprise/inject/BindingType.class
515 Tue Jul 28 19:42:36 PDT 2009 javax/enterprise/inject/Named.class



 Comments   
Comment by lidiam [ 30/Sep/09 ]

Changing category to packaging

Comment by kumara [ 01/Oct/09 ]

I believe that the sample needs to be changed because the latest revision of the specification removed a
few classes. But, Roger can confirm.

Comment by rogerk [ 01/Oct/09 ]

Can you please tell me where this sample webbeans app is you are running?
It is out of date. Since 1.0.0.PREVIEW3 integration of Web Beans, Web Beans has
been using the JSR 330 annotations (such as javax.inject.Named). We are now on
1.0.0.PREVIEW4 of Web Beans.
glassfish-samples should be up to date with the latest changes, and so are the
quick look tests.

Comment by rogerk [ 02/Oct/09 ]

Please update your test app to use the latest Web Beans distribution.
You can use the app in glassfish-samples as a guide.





[GLASSFISH-11631] server works really hard to fail Created: 01/Mar/10  Updated: 20/May/10  Resolved: 20/May/10

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

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

Operating System: All
Platform: All


Attachments: Text File server.log     Text File server.log     Text File server.log     File WicketExamples.war    
Issuezilla Id: 11,631

 Description   

In some situations, v3 will fail to deploy an app after a very long time of very
high activity.

To reproduce:

start v3 on a Windows system.
use asadmin to attempt to deploy the attached war file.

The system becomes very busy and eventually the deployment fails. (Eventually is
on the order of minutes on a laptop with a 2.0 GHz Core 2 Duo CPU and 2GB of memory)

The app also fails to deploy if you try to use directory deployment.

This issue is related to http://netbeans.org/bugzilla/show_bug.cgi?id=181173



 Comments   
Comment by vince kraemer [ 01/Mar/10 ]

Created an attachment (id=4250)
the war file

Comment by vince kraemer [ 01/Mar/10 ]

Created an attachment (id=4251)
the server log (with two failed deploy attempts)

Comment by vince kraemer [ 01/Mar/10 ]

Note: if you remove the file WEB-INF\beans.xml the war will deploy (archive or
directory based)

Comment by Hong Zhang [ 01/Mar/10 ]

Assign to cdi category for initial evaluation as the problem only happens when
WEB-INF\beans.xml is present.

Comment by bht [ 01/Mar/10 ]

.

Comment by jpleed3 [ 01/Mar/10 ]

My comments on the Netbeans issue, which I think are applicable here:

When GF v3 came out, I liked CDI so much I refactored all my apps to use it.
However, when I started smoke testing them on v3 I noticed that in Windows task
manager, the mem size would grow about 30 MB whenever I redeployed an app.
Eventually when the mem size reached about 650-700MB, deployments would stall
and I would eventually get an out of heap space error. When I would restart the
server, mem usage would still be high. Only after deleting the osgi-cache and
generated folders out of the domain folder would mem usage return to a
manageable level.

Then I started running into problems with the CPU running at full throttle
during deployment and locking up the entire OS. I worked around this by setting
the JVM's process to only use one processor core.

I've been working this way for weeks, waiting until I got everything ready to
go out on my staging server before looking for answers. I have that machine set
to the server JVM with a larger heap size (1400 MB). I figured something might
change with not deploying as often, but when I have all my apps on there and
leave it run for a few hours, pages start serving sluggishly then not at all.
The same apps with mostly similar J5EE code ran fine on GF v2.1 with a MUCH
smaller memory footprint.

Last week I switched over to Weld 1.0.1-final by patching the GF Weld
integration module to use the SPI extensions instead of the implementation.
There's still no change. I'm going to guess that if this problem is Weld
related, then the problem lies in the integration module. It seems most of the
work and testing they do is on JBoss 6.0.0-M2.

One thing's for certain for me: there's no way I can take this into production.

Comment by jpleed3 [ 01/Mar/10 ]

Could this be related to: https://glassfish.dev.java.net/issues/show_bug.cgi?
id=11159 ?

Comment by rogerk [ 02/Mar/10 ]

Thanks for the information and archive to test. I will initially see if I can
do some profiling on my mac (since I don't have my windoze env set up).

Comment by vince kraemer [ 04/Mar/10 ]

mac os x, 10.6.2

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode)

http://download.java.net/glassfish/v3u1/promoted/glassfish-v3u1-b07.zip

Fail.

Comment by vince kraemer [ 04/Mar/10 ]

Created an attachment (id=4253)
attempt to deploy on Mac OS X

Comment by vince kraemer [ 04/Mar/10 ]

VBKMacBookPro:~ vkraemer$ date ; glassfishv3u1b7/glassfish/bin/asadmin deploy
Downloads/WicketExamples.war ; date
Thu Mar 4 09:28:54 PST 2010
com.sun.enterprise.admin.cli.CommandException: remote failure: Exception while loading the app :
org.glassfish.deployment.common.DeploymentException: Java heap space

Command deploy failed.
Thu Mar 4 09:35:48 PST 2010

Comment by vince kraemer [ 04/Mar/10 ]

same mac

different bits http://download.java.net/glassfish/v3.1/nightly/glassfish-v3_1-b01-02_27_2010.zip

still fail

VBKMacBookPro:~ vkraemer$ date ; glassfishv3dot1feb27/glassfish/bin/asadmin deploy
Downloads/WicketExamples.war ; date
Thu Mar 4 09:53:12 PST 2010
com.sun.enterprise.admin.cli.CommandException: remote failure: Exception while loading the app :
org.glassfish.deployment.common.DeploymentException: Java heap space

Command deploy failed.
Thu Mar 4 10:00:43 PST 2010

Comment by vince kraemer [ 04/Mar/10 ]

Created an attachment (id=4254)
failing to deploy... v3.1 on Mac OS X

Comment by vince kraemer [ 04/Mar/10 ]

it looks like this is a cross platform problem.

Comment by vince kraemer [ 10/Mar/10 ]

this appears to be resolved with the 2010-03-10 nightly build, which includes
weld 1.0.1...





[GLASSFISH-11607] CDI Injection of Stateless EJB in SessionScoped WebBean fails Created: 24/Feb/10  Updated: 08/Oct/10  Resolved: 08/Oct/10

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

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

Operating System: All
Platform: Linux


Issuezilla Id: 11,607

 Description   

Stateless EJB cannot be injected in SessionScoped WebBeans.
Deployment error is:
[SEVERE] (javax.enterprise.system.core.com.sun.enterprise.v3.server) =>
Exception while loading the app
org.glassfish.deployment.common.DeploymentException: The bean
org.jboss.weld.bean-/home/bbehrens/Java/Projekte/WebApplication5/build/web/-ManagedBean-class
test.SessionWebBean declares a passivating scope but has non-serializable
dependency:
org.jboss.weld.bean-/home/bbehrens/Java/Projekte/WebApplication5/build/web/-SessionBean-StatelessSessionBean

Source StatelessSessionBean:
package test;

import javax.ejb.Stateless;
import javax.enterprise.context.Dependent;
import javax.inject.Named;

@Named
@Stateless
@Dependent
public class StatelessSessionBean {

public StatelessSessionBean() {
}

}
Source SessionWebBean:
package test;

import java.io.Serializable;
import javax.enterprise.context.SessionScoped;
import javax.inject.Inject;
import javax.inject.Named;

@Named
@SessionScoped
public class SessionWebBean implements Serializable{

@Inject
StatelessSessionBean statelessSessionBean;

public SessionWebBean() {
}
}

This is considered to work see JSR 299 Spec 6.6
See also:
http://www.seamframework.org/Community/SerializationProblems
And:
https://jira.jboss.org/jira/browse/WELD-290



 Comments   
Comment by rogerk [ 24/Feb/10 ]

Lowerng priority to p2;
Will address after 1.0.1 Weld integration (upcoming).

Comment by mithridates [ 24/Feb/10 ]

Will there be an update via updatetool for 3.0 or do we have to wait until release of 3.1?
CDI is propagated as one of the most essential new features in EE6, so it is really important to get this
working.

Comment by rogerk [ 24/Feb/10 ]

This fix will go into the 3.0.1 release of V3 (in addition to 3.1).
Either fix should be available in the nightly builds after the fix is
checked in.

Comment by rogerk [ 26/Jul/10 ]

assign to Siva

Comment by Sivakumar Thyagarajan [ 08/Oct/10 ]

I can't seem to reproduce this with the latest GlassFish 3.1 build. The test case
that I have used that attempts to reproduce this issue is at [1].

Please reopen this issue with a testcase if you can still reproduce this issue.

[1]
https://glassfish-svn.dev.java.net/source/browse/glassfish-svn/trunk/v2/appserv-
tests/devtests/cdi/javaee-component-resources/slsb-injection-into-sessionscoped





[GLASSFISH-11450] @Inject EntityManager does not work Created: 19/Jan/10  Updated: 07/Oct/10  Resolved: 07/Oct/10

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

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

Operating System: All
Platform: All


Issuezilla Id: 11,450

 Description   

According to the CDI spec, the following should work (but doesn't):

public class MyResourceFactory {
@Producer @PersistenceContext(unitName="MyPersistenceUnit") EnityManager em;
}

@Stateless
public class MyEjbLight {
@Inject EntityManager em;

public void accessEm() 

{ em.find(CustomerOrder.class) // this fails with the exception copied bellow. }

}

It fails with: "Caused by: java.lang.IllegalStateException: Unable to retrieve EntityManagerFactory for
unitName MyPersistenceUnit"

It works if I replace "@Inject EntityManager em;" with "@PersistenceContext EntityManager em;".

More-over: as long as the top-most ejb in a call graph has @PersistenceContext EntityManager em;"
then all other CDI beans in the call graph may use "@Inject EntityManager em;" (assuming the
@Producer is declared as above).

/Johan



 Comments   
Comment by johaneltes [ 19/Jan/10 ]

I should add that I invoke the ejb3 light ejb (the topmost EJB of the call graph) from JUnit using the
following code:

container = EJBContainer.createEJBContainer();
Context ctx = container.getContext();
MyEjbLight ejb = (MyEjbLight)ctx.lookup("java:global/classes/MyEjbLight");
ejb.accessEm();

Comment by ksak [ 19/Jan/10 ]

Does the same code work when deployed to the server? Does it work in the EJB Embeddable API case if
the @PersistenceContext declaration does not specify unitName? Also, please include the complete
stack trace.

Comment by choicegh [ 28/Apr/10 ]

This should also work in non-ejbs according to the spec but doesn't also.

public class MyResourceFactory

{ @Producer @PersistenceContext(unitName="MyPersistenceUnit") EnityManager em; }

@Named
public class MyBean {
@Inject EntityManager em;

public void accessEm()

{ em.find(CustomerOrder.class) // this fails with the exception copied bellow. }

}

Comment by marina vatkina [ 08/Jun/10 ]

Doesn't seem to be ejb container issue

Comment by Mitesh Meswani [ 08/Jun/10 ]

Assigning to Siva for initial investigation..

Comment by rwappler [ 17/Jun/10 ]
      • Issue 11450 has been confirmed by votes. ***
Comment by rwappler [ 17/Jun/10 ]

The issue also occurs on the server. Details are as follows:

@Stateful public class EjbA {
@EJB EjbB;

public void persist()

{ EjbB.persit(); }

}

@Stateful public class EjbB {

@Inject @MyPU EntityManager em;

private MyEntity entity = new MyEntity();

public void persist()

{ entity = em.merge(entity); ... }

}

The qualifier for the producer field:
@Produces @MyPu @PersistenceContext(unitName="my-pu") EntityManager em;

When the servlet calls EjbA.persist(), a NPE occurs at the line, where EjbB
class em.merge(entity).

The code in the servlet utilises jakarta-cactus, thus the lookup of EjbA is done
via JNDI in a newly constructed InitialContext instead of injection.

Interestingly, the injection of the entity manager with the same code as above
works in EjbA and the entity manager is not null.

I hope that helps.

Comment by rwappler [ 17/Jun/10 ]

Arg, please forget my last comment. The reason was totally different. My beans
exposed a no-interface view and EjbB.persist() was not public. Nevertheless, the
plain NPE is not helpful and a more useful error message would help.

Comment by Sivakumar Thyagarajan [ 07/Oct/10 ]

I couldn't reproduce this scenario. Please see the developer tests (em-injection-
no-interface-ejb and em-resource-injection) that I checked in as part of revision
41488.

EntityManager injection into a Statless bean and a Servlet that was produced
through a Producer field seems to work in 3.1 latest build. If you still could
reproduce this issue, please reopen this issue with a reproducible test-case.
Thanks





[GLASSFISH-11923] Package private constructors cause CDI instantiation & injection point resolution to fail Created: 18/May/10  Updated: 08/Oct/10  Resolved: 08/Oct/10

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

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

Operating System: All
Platform: Linux


Issuezilla Id: 11,923

 Description   

While the workaround for this issue is to not use a package-private constructor,
the use-case should work, and does work on JBoss AS 6

---- Create an Extension:

/*

  • JBoss, Home of Professional Open Source
  • Copyright 2010, Red Hat, Inc., and individual contributors
  • by the @authors tag. See the copyright.txt in the distribution for a
  • full listing of individual contributors.
    *
  • Licensed under the Apache License, Version 2.0 (the "License");
  • you may not use this file except in compliance with the License.
  • You may obtain a copy of the License at
  • http://www.apache.org/licenses/LICENSE-2.0
  • Unless required by applicable law or agreed to in writing, software
  • distributed under the License is distributed on an "AS IS" BASIS,
  • WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  • See the License for the specific language governing permissions and
  • limitations under the License.
    */
    package org.jboss.weld.extensions.interceptor;

import java.util.Collection;
import java.util.Collections;
import java.util.HashSet;

import javax.enterprise.event.Observes;
import javax.enterprise.inject.spi.Extension;
import javax.enterprise.inject.spi.Interceptor;
import javax.enterprise.inject.spi.ProcessBean;

public class InterceptorExtension implements Extension
{

private final Collection<Class<?>> enabledInterceptors;

InterceptorExtension()

{ this.enabledInterceptors = Collections.synchronizedSet(new HashSet<Class<?>>()); }

@SuppressWarnings("unused")
void observeInterceptors(@Observes ProcessBean<?> pmb)
{
if (pmb.getBean() instanceof Interceptor<?>)

{ this.enabledInterceptors.add(pmb.getBean().getBeanClass()); }

}

Collection<Class<?>> getEnabledInterceptors()

{ return enabledInterceptors; }

}

----- Register it in META-INF/services/javax.enterprise.inject.spi.Extension:

org.jboss.weld.extensions.interceptor.InterceptorExtension

----- Reference it in another class within the same package:

/*

  • JBoss, Home of Professional Open Source
  • Copyright 2010, Red Hat, Inc., and individual contributors
  • by the @authors tag. See the copyright.txt in the distribution for a
  • full listing of individual contributors.
    *
  • Licensed under the Apache License, Version 2.0 (the "License");
  • you may not use this file except in compliance with the License.
  • You may obtain a copy of the License at
  • http://www.apache.org/licenses/LICENSE-2.0
  • Unless required by applicable law or agreed to in writing, software
  • distributed under the License is distributed on an "AS IS" BASIS,
  • WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  • See the License for the specific language governing permissions and
  • limitations under the License.
    */
    package org.jboss.weld.extensions.interceptor;

import javax.inject.Inject;

public class Interceptors
{

@Inject
private InterceptorExtension interceptorExtension;

private Interceptors()
{
}

public boolean isInterceptorEnabled(Class<?> clazz)

{ return interceptorExtension.getEnabledInterceptors().contains(clazz); }

}

----- Deploy a beans-enabled application containing this code to GlassFish, the
deployment will fail with:

"Unsatisfied injection point: Interceptors.interceptorExtension"



 Comments   
Comment by Alexis MP [ 18/May/10 ]

Cc

Comment by rogerk [ 18/May/10 ]

Assign to Siva

Comment by Sivakumar Thyagarajan [ 08/Oct/10 ]

I can't seem to reproduce this issue now with the latest GlassFish 3.1. The test
case I used to reproduce this is at [1].

Please feel free to re-open this issue, if you could reproduce this again.

Thanks.
[1] https://glassfish-svn.dev.java.net/source/browse/glassfish-
svn/trunk/v2/appserv-tests/devtests/cdi/portable-extensions/package-private-
extension-constructor





[GLASSFISH-11894] QuickLook weld/osgiweld test failed on b18 Created: 14/May/10  Updated: 20/May/10  Resolved: 20/May/10

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

Type: Bug Priority: Critical
Reporter: mzh777 Assignee: rogerk
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,894

 Description   

With the promoted b18, the weld/osgiweld test failed with following exceptions:
[testng] java.lang.AssertionError: Unexpected Package Exports expected:<true>
but was:<false>
[testng] at
test.weld.osgi.OsgiWeldTestNG.testOsgiModuleIntegrity(OsgiWeldTestNG.java:79)
[testng] ... Removed 26 stack frames

...

To reproduce:
1. Start GF domain.
2. IN quicklook/weld/osgiweld, run
% ant -Dglassfish.home=[GF_Home] all



 Comments   
Comment by rogerk [ 14/May/10 ]

I'll take a look.

Comment by rogerk [ 14/May/10 ]

That promoted build of Weld is still 1.0.1-SP1.
Weld 1.0.1-SP2 was integrated the evening of May 12 - so it is available in the
nightly builds. It should be available in the next promoted build.
Try your quick look test against the latest nightly.

Comment by mzh777 [ 19/May/10 ]
      • Issue 11893 has been marked as a duplicate of this issue. ***




[GLASSFISH-11888] Library JAR on CDI-enabled EJB JAR classpath causes NullPointerException Created: 13/May/10  Updated: 03/Dec/10  Resolved: 03/Dec/10

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

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

Operating System: All
Platform: All


Attachments: Zip Archive testnb69.zip    
Issuezilla Id: 11,888

 Description   

I have tried this on gf3.0.1b17, gf3.1b1, and gf 3.0.1b14 (that comes with
current NetBeans 6.9 beta).

If I have an EAR (although it happens with just a WAR as well) with a stateless
session EJB in it in an EJB JAR that depends on a POJO defined in a library
JAR, deployment succeeds but when a client (JSP page and an app client)
attempts to call the EJB, I get an exception. I moved the EJB into a WAR to try
that and it has the same problem. Stack trace:

INFO: Loading application CDIEAR#CDIEAR-war.war at CDIEAR-war
FINE: WELD-000100 Weld initialized. Validating beans
INFO: CDIEAR was successfully deployed in 58,084 milliseconds.
FINEST: WELD-000708 Initializing request
org.apache.catalina.connector.RequestFacade@119e736
FINEST: WELD-000206 Starting request /CDIEAR-war/
FINEST: New bean store created:
org.jboss.weld.servlet.HttpPassThruOnDemandSessionBeanStore
FINEST: WELD-000204 Restoring session Inactive session
FINEST: Loading bean store
org.jboss.weld.servlet.HttpPassThruOnDemandSessionBeanStore map from session
33ace4c67c93d095abe740dcd97a
SEVERE: EJB5070: Exception creating stateless session bean : [NewSessionBean]
WARNING: A system exception occurred during an invocation on EJB NewSessionBean
method public java.lang.String
org.mitre.test.newsessionbean.NewSessionBean.remoteBusinessMethod()
javax.ejb.EJBException: javax.ejb.EJBException: javax.ejb.CreateException:
Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer._getContext
(StatelessSessionContainer.java:448)
at com.sun.ejb.containers.BaseContainer.getContext
(BaseContainer.java:2418)
at com.sun.ejb.containers.BaseContainer.preInvoke
(BaseContainer.java:1811)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke
(EJBObjectInvocationHandler.java:200)
at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke
(EJBObjectInvocationHandlerDelegate.java:75)
at $Proxy155.remoteBusinessMethod(Unknown Source)
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.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke
(StubInvocationHandlerImpl.java:228)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke
(StubInvocationHandlerImpl.java:147)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke
(CodegenStubBase.java:225)
at
org.mitre.test.newsessionbean.__NewSessionBeanRemote_Remote_DynamicStub.remoteBu
sinessMethod
(org/mitre/test/newsessionbean/__NewSessionBeanRemote_Remote_DynamicStub.java)
at
org.mitre.test.newsessionbean._NewSessionBeanRemote_Wrapper.remoteBusinessMethod
(org/mitre/test/newsessionbean/_NewSessionBeanRemote_Wrapper.java)
at
org.mitre.test.newsessionbeanproxy.NewSessionBeanProxy.remoteBusinessMethod
(NewSessionBeanProxy.java:37)
at org.apache.jsp.index_jsp._jspService(index_jsp.java from :66)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.jasper.servlet.JspServletWrapper.service
(JspServletWrapper.java:406)
at org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:483)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:373)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.catalina.core.StandardWrapper.service
(StandardWrapper.java:1523)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:188)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:641)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke
(PESessionLockingStandardPipeline.java:85)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:185)
at org.apache.catalina.connector.CoyoteAdapter.doService
(CoyoteAdapter.java:332)
at org.apache.catalina.connector.CoyoteAdapter.service
(CoyoteAdapter.java:233)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service
(ContainerMapper.java:165)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter
(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at com.sun.grizzly.http.DefaultProtocolFilter.execute
(DefaultProtocolFilter.java:170)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter
(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute
(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute
(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute
(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall
(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call
(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork
(AbstractThreadPool.java:330)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run
(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.ejb.EJBException: javax.ejb.CreateException: Could not create
stateless EJB
at
com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create
(StatelessSessionContainer.java:718)
at com.sun.ejb.containers.util.pool.NonBlockingPool.getObject
(NonBlockingPool.java:200)
at com.sun.ejb.containers.StatelessSessionContainer._getContext
(StatelessSessionContainer.java:443)
... 46 more
Caused by: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB
(StatelessSessionContainer.java:526)
at com.sun.ejb.containers.StatelessSessionContainer.access$000
(StatelessSessionContainer.java:90)
at
com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create
(StatelessSessionContainer.java:716)
... 48 more
Caused by: java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.get
(ConcurrentHashMap.java:768)
at org.jboss.weld.manager.BeanManagerImpl.getBean
(BeanManagerImpl.java:1171)
at org.jboss.weld.manager.BeanManagerImpl.getBean
(BeanManagerImpl.java:132)
at org.glassfish.weld.services.JCDIServiceImpl.injectEJBInstance
(JCDIServiceImpl.java:135)
at com.sun.ejb.containers.BaseContainer.injectEjbInstance
(BaseContainer.java:1603)
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB
(StatelessSessionContainer.java:486)
... 50 more

WARNING: StandardWrapperValve[jsp]: PWC1406: Servlet.service() for servlet jsp
threw exception
javax.ejb.EJBException: javax.ejb.EJBException: javax.ejb.CreateException:
Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer._getContext
(StatelessSessionContainer.java:448)
at com.sun.ejb.containers.BaseContainer.getContext
(BaseContainer.java:2418)
at com.sun.ejb.containers.BaseContainer.preInvoke
(BaseContainer.java:1811)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke
(EJBObjectInvocationHandler.java:200)
at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke
(EJBObjectInvocationHandlerDelegate.java:75)
at $Proxy155.remoteBusinessMethod(Unknown Source)
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.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke
(StubInvocationHandlerImpl.java:228)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke
(StubInvocationHandlerImpl.java:147)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke
(CodegenStubBase.java:225)
at
org.mitre.test.newsessionbean.__NewSessionBeanRemote_Remote_DynamicStub.remoteBu
sinessMethod
(org/mitre/test/newsessionbean/__NewSessionBeanRemote_Remote_DynamicStub.java)
at
org.mitre.test.newsessionbean._NewSessionBeanRemote_Wrapper.remoteBusinessMethod
(org/mitre/test/newsessionbean/_NewSessionBeanRemote_Wrapper.java)
at
org.mitre.test.newsessionbeanproxy.NewSessionBeanProxy.remoteBusinessMethod
(NewSessionBeanProxy.java:37)
at org.apache.jsp.index_jsp._jspService(index_jsp.java from :66)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.jasper.servlet.JspServletWrapper.service
(JspServletWrapper.java:406)
at org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:483)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:373)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.catalina.core.StandardWrapper.service
(StandardWrapper.java:1523)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:188)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:641)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke
(PESessionLockingStandardPipeline.java:85)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:185)
at org.apache.catalina.connector.CoyoteAdapter.doService
(CoyoteAdapter.java:332)
at org.apache.catalina.connector.CoyoteAdapter.service
(CoyoteAdapter.java:233)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service
(ContainerMapper.java:165)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter
(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at com.sun.grizzly.http.DefaultProtocolFilter.execute
(DefaultProtocolFilter.java:170)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter
(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute
(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute
(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute
(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall
(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call
(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork
(AbstractThreadPool.java:330)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run
(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.ejb.EJBException: javax.ejb.CreateException: Could not create
stateless EJB
at
com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create
(StatelessSessionContainer.java:718)
at com.sun.ejb.containers.util.pool.NonBlockingPool.getObject
(NonBlockingPool.java:200)
at com.sun.ejb.containers.StatelessSessionContainer._getContext
(StatelessSessionContainer.java:443)
... 46 more
Caused by: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB
(StatelessSessionContainer.java:526)
at com.sun.ejb.containers.StatelessSessionContainer.access$000
(StatelessSessionContainer.java:90)
at
com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create
(StatelessSessionContainer.java:716)
... 48 more
Caused by: java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.get
(ConcurrentHashMap.java:768)
at org.jboss.weld.manager.BeanManagerImpl.getBean
(BeanManagerImpl.java:1171)
at org.jboss.weld.manager.BeanManagerImpl.getBean
(BeanManagerImpl.java:132)
at org.glassfish.weld.services.JCDIServiceImpl.injectEJBInstance
(JCDIServiceImpl.java:135)
at com.sun.ejb.containers.BaseContainer.injectEjbInstance
(BaseContainer.java:1603)
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB
(StatelessSessionContainer.java:486)
... 50 more

Tried autodeploying EAR and running from NetBeans - both exhibit same behavior.

I will attach the NetBeans 6.9 projects zipped up.



 Comments   
Comment by gregquinn2001 [ 13/May/10 ]

Created an attachment (id=4354)
2 NetBeans 6.9 projects zipped up

Comment by gregquinn2001 [ 19/May/10 ]
      • Issue 11888 has been confirmed by votes. ***
Comment by rogerk [ 19/May/10 ]

Assign

Comment by marina vatkina [ 04/Jun/10 ]
      • Issue 11769 has been marked as a duplicate of this issue. ***
Comment by jhasenbe [ 05/Jun/10 ]

put me on CC

Comment by jhasenbe [ 07/Jun/10 ]

We are struggling with the same issue (already described in GLASSFISH-11769) and I
wonder if there is a chance to get a fix in 3.0.1 release.

The 3.1 final release won't be available for quite some time (beginning of next
year!?) and the error described here will affect almost anyone who uses CDI and
the typical (and even recommended) EAR packaging approach with utility libraries
using CDI.

The work around we are using at the moment is to package everything (even EJBs)
inside a WAR file. However, I think it's critical that the recommended EAR
packaging works for the reference implementation.

Thanks for your consideration!

Comment by Sivakumar Thyagarajan [ 07/Jun/10 ]

I don't know if we still have time for making fixes for the 3.0.1 release. I am
investigating this issue and will update this issue as soon as I have more
information. Initial investigation indicates that the CDI implementation doesn't
recognize the presence of the EJBs bundled in the WAR and hence fails to create
an CDI Injection Context.

Does bundling MyPOJO along with the EJB help [either in a seperate EJB-JAR or as
part of the WAR]?

Comment by jhasenbe [ 07/Jun/10 ]

In our case (described in issue 11769, which is marked as duplicate for this
bug) things work if we put the EJB module and utility libraries (JPA stuff)
inside the WAR lib directory. This seems not to be the case for the example
provided by gregquinn2001, who reported this bug.

Please also see my notes on issue 11769.

Comment by Sivakumar Thyagarajan [ 07/Jun/10 ]

> This seems not to be the case for the example
> provided by gregquinn2001, who reported this bug.

I just tried repackaging gregquinn2001's application to bundle everything in the
war (as in the EJB classes and utility POJO class in WEB-INF/lib) and it works
for me. Do you see otherwise?

gregquinn2001: Does this workaround of packaging EJB and the libraries in
WEB-INF/lib work for you as well?

Comment by gregquinn2001 [ 08/Jun/10 ]

To answer sivakumart's question:
"Does bundling MyPOJO along with the EJB help [either in a seperate EJB-JAR or
as part of the WAR]?"

Yes, when you bundle the POJO in the same JAR or WAR as the EJB, injections
works fine and no exceptions occur; however, having to put the same code in
multiple projects makes CDI unusable for my work.

Comment by obergner [ 21/Jun/10 ]

I second jhasenbe's urge to have this fixed as soon as possible. This is a
showstopper, effectively rendering usage of CDI in Glassfish impossible in all
but the most trivial applications. I'm currently stuck: either I have to forget
about using CDI, which in my view is JEE 6's crown jewel, or switch to JBoss 6.
Which is somewhat ironic since I decided on using Glassfish specifically because
its CDI support was rumored to be the most complete and standard compliant.

Regards,
Olaf

Comment by szczyp [ 14/Jul/10 ]

It might help to make the CDI archive an ejb archive by adding an ejb-jar.xml
and a dummy ejb. Please see here for more:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=12658. It is about an
embedded EJB deployment, but the bug and stack trace seems pretty much the same,
and it helped for my case.

Comment by ljnelson [ 27/Jul/10 ]

I'm running into this issue as well, ironically enough while working around
another crippling CDI integration failure. In my case, I have an ear file
containing a .war file, an EJB module, and several library jars.

The servlet in the .war file asks for an EJB like this:

@EJB
private PersonManager pm;

This is injected properly in the sense that it is non-null. Note that at this
injection point CDI is not asked for.

The jar file that the PersonManager implementation happens to live in is not
just an EJB jar module, but also a CDI bean archive (it has a META-INF/beans.xml
file in it).

If you try to invoke a business method on this PersonManager implementation, you
get the same stack as in this error.

I hope this helps. I would urge raising this bug to the highest priority since
it impacts normal CDI-less dependency injection.

Comment by Sivakumar Thyagarajan [ 08/Oct/10 ]

Targetting for MS7

Comment by Sivakumar Thyagarajan [ 03/Dec/10 ]

With latest glassfish, I was able to test this application use-case and it works fine. I see the followng printed when I access http://spiff:8080/CDIEAR-war/
Hello World: remote: pojo inject!!

So, I am closing this issue. To track regressions, I have also added a test-case that uses this scenario at javaee-integration/bean-in-lib-dir-used-by-ejb-in-ear/ https://svn.java.net/svn/glassfish~svn/trunk/v2/appserv-tests/devtests/cdi/javaee-integration/bean-in-lib-dir-used-by-ejb-in-ear/





[GLASSFISH-11875] CDI 1.0.1 TCK Test Failures:Could Not Create Stateless EJB Created: 10/May/10  Updated: 20/May/10  Resolved: 20/May/10

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

Type: Bug Priority: Critical
Reporter: rogerk Assignee: ksak
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 11,875

 Description   

See: https://jira.jboss.org/jira/browse/CDITCK-151



 Comments   
Comment by rogerk [ 10/May/10 ]

target 3.0.1

Comment by rogerk [ 10/May/10 ]

Changing target to 3.1

Comment by ksak [ 10/May/10 ]

Duplicate of 11180

      • This issue has been marked as a duplicate of 11180 ***




[GLASSFISH-11876] CDI 1.0.1 TCK Test Failure:Assertion Error: Test For Active Request/Application Scope During EJB Timeout Created: 10/May/10  Updated: 11/May/10  Resolved: 11/May/10

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

Type: Bug Priority: Critical
Reporter: rogerk Assignee: ksak
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 11,876

 Description   

See: https://jira.jboss.org/jira/browse/CDITCK-157



 Comments   
Comment by rogerk [ 10/May/10 ]

target 3.0.1

Comment by rogerk [ 10/May/10 ]

This issue also relates to Application scope.
See: https://jira.jboss.org/jira/browse/CDITCK-157

Comment by rogerk [ 11/May/10 ]

As it turns out, SessionBeanInterceptor is registered in GF v3.0.1.
The tests CDI TCK tests were written in such a way as to cause a race condition
(the bug lies with the CDI TCK tests).
See: https://jira.jboss.org/jira/browse/CDITCK-157





[GLASSFISH-11825] CDI Interceptors Doest Work with Glassfish Created: 27/Apr/10  Updated: 03/Dec/10  Resolved: 03/Dec/10

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

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

Operating System: All
Platform: All
URL: http://www.seamframework.org/Community/ProblemsWithInterceptorsAndGlassfishV3


Attachments: File QuemSabeUmLogTest-changes.diff     File QuemSabeUmLogTeste.rar    
Issuezilla Id: 11,825

 Description   

I try to create some interceptors but :

INFO: Created HTTP listener http-listener-1 on port 8080
INFO: Created HTTP listener http-listener-2 on port 8181
INFO: Created HTTP listener admin-listener on port 4848
INFO: Created virtual server server
INFO: Created virtual server __asadmin
INFO: Virtual server server loaded system default web module
INFO: Portable JNDI names for EJB NewSessionBean :
[java:global/QuemSabeUmLogTeste/QuemSabeUmLogTeste-ejb/NewSessionBean,
java:global/QuemSabeUmLogTeste/QuemSabeUmLogTeste-ejb/NewSessionBean!teste.NewSessionBean]
INFO: WELD-000900 1.0.1 (SP1)
INFO: Instantiated an instance of
org.hibernate.validator.engine.resolver.JPATraversableResolver.
INFO: Inicializando Mojarra 2.0.2 (FCS b10) para o contexto
'/QuemSabeUmLogTeste-war'
INFO: Loading application QuemSabeUmLogTeste#QuemSabeUmLogTeste-war.war at
QuemSabeUmLogTeste-war
SEVERE: Exception while loading the app
org.glassfish.deployment.common.DeploymentException: WELD-001417 Enabled
interceptor class class teste.BasicInterceptor is neither annotated @Interceptor
nor registered through a portable extension
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:181)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:125)
at
org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:239)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:339)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:183)
at
org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:272)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:305)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:320)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1176)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunnerImpl.java:83)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1224)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:365)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:204)
at
com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
at
com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:100)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:245)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001417 Enabled
interceptor class class teste.BasicInterceptor is neither annotated @Interceptor
nor registered through a portable extension
at
org.jboss.weld.bootstrap.Validator.validateEnabledInterceptorClasses(Validator.java:449)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:319)
at
org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:399)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:178)
... 30 more

The beans.xml:

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

The BasicInterceptor.java

@Interceptor @Basic
public class BasicInterceptor {

private final static ThreadLocal<InvocationContext> context = new
ThreadLocal<InvocationContext>();

@AroundInvoke
public Object classInterceptor(InvocationContext newContext) throws Exception {}

}

The Basic.java

@InterceptorBinding
@Target(

{ElementType.METHOD, ElementType.TYPE}

)
@Retention(RetentionPolicy.RUNTIME)
public @interface Basic {

}

GlassFish V3 3.0.1 b14 and Weld 1.0.1

The IDE is NetBeans 6.8 and 6.9 Beta



 Comments   
Comment by dyegocarmo [ 27/Apr/10 ]

Created an attachment (id=4313)
Test Project with NetBeans 6.9 Beta

Comment by dyegocarmo [ 27/Apr/10 ]

The error is in beans.xml

The interceptors are declared in beans.xml on WAR MODULE... but the classes are
located in EJB MODULE...

But the interceptors doest work if the Managed Bean is on WAR MODULE , are this
correct ?

Comment by dyegocarmo [ 28/Apr/10 ]

The project proves:

If you use @Vai (the @Vai use a @Interceptorbinding) on WAR MODULE... Doest
work... because interceptors are codded on EJB module...

This is a bug... because according to spec this should work.

if you hard code a @Interceptors({}) on WAR module , the interceptors work...

Comment by rogerk [ 19/May/10 ]

Must this be a rar file? Can you attach an ear file for the app?

Comment by rogerk [ 20/May/10 ]

P2

Comment by rogerk [ 26/Jul/10 ]

assign to Siva

Comment by Sivakumar Thyagarajan [ 07/Oct/10 ]

Targetting MS7. The interceptor definition in the beans.xml in the WAR is not
considered valid as there are no Interceptor defined in the WAR. The interceptors
are defined in the EJB-JAR. Need to understand whether module visibility rules
allow interceptors to be defined in a CDI-enabled module and the interceptors
enabled in another CDI-enabled module.

Comment by Sivakumar Thyagarajan [ 03/Dec/10 ]

Diffs that I had to make to the project to run.

Description of diffs follows in the next comment.

Comment by Sivakumar Thyagarajan [ 03/Dec/10 ]

I had to make the following changes to get the attached application running. Description of changes:
1. QuemSabeUmLogTeste-ejb/src/conf/beans.xml: ejb-jar beans.xml has to have the interceptors enabled as the EJB uses the interceptor
2. QuemSabeUmLogTeste-ejb/src/java/teste/BasicInterceptor.java: Interceptor must implement Serializable as it is assigned to a Bean (MyManagedBean) that is passivation scoped. The Interceptor, since it is part of the accessible closure of MyManagedBean, must implement Serializable so that MyManagedBean is passivation capable.
3. QuemSabeUmLogTeste-ejb/src/java/teste/Vai.java: InterceptorBindingTypes must be either Target(METHOD,TYPE) or Target(TYPE) as per section 9.1 of the CDI 1.0 spec.

After these changes, the application works and I am able to access the application through http://localhost:8080/QuemSabeUmLogTeste-war/
The following application output is seen in server.log
[#|2010-12-03T15:52:24.092+0530|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=15;_ThreadName=Thread-1;|Basic Interceptor Added|#]

[#|2010-12-03T15:52:24.092+0530|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=15;_ThreadName=Thread-1;|Logger Interceptor Added|#]

[#|2010-12-03T15:52:24.093+0530|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=15;_ThreadName=Thread-1;|Basic Interceptor Added|#]

[#|2010-12-03T15:52:24.094+0530|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=15;_ThreadName=Thread-1;|Logger Interceptor Added|#]

[#|2010-12-03T15:52:24.095+0530|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=15;_ThreadName=Thread-1;|See Passou pelo Manged Bean AGORA ! teste.NewSessionBean@1e5941c|#]

[#|2010-12-03T15:52:24.095+0530|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=15;_ThreadName=Thread-1;|See Aqui passou pelo session bean !!!!|#]

I am closing this issue as the original issue discussed in the bug report is resolved.





[GLASSFISH-11672] Message Driven Bean conflicting with Managed Beans. Weld Deployer Error. Created: 11/Mar/10  Updated: 30/Nov/10  Resolved: 30/Nov/10

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

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

Operating System: Windows Vista
Platform: PC


Attachments: Java Archive File cdi-hello-mdb-ejb.jar     Zip Archive MDBTest.zip    
Issuezilla Id: 11,672

 Description   

I run tried to deploy a enterprise application (ejb, war) written in Netbeans
6.8 coming with the IDE+Glassfish V3 Bundle. Now, I added:

  • 1 entity bean
  • 1 message driven bean
  • 1 session bean

all according to the enterprise tutorial on netbeans.org.
http://wiki.netbeans.org/BeginningWithEnterpriseApplication

having those files added, i wasn't able to deploy enterprise app anymore. The
error log is saying that MDBs cannot represent a Managed Bean. Yes, I know that.
However, I did not add anything that would mark the class as a Managed Bean.

here's the head of my MDB class
-------------
import javax.annotation.Resource;
import javax.ejb.ActivationConfigProperty;
import javax.ejb.MessageDriven;
import javax.ejb.MessageDrivenContext;
import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.MessageListener;
import javax.jms.ObjectMessage;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;

@MessageDriven(mappedName = "jms/user", activationConfig = {
@ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue =
"Auto-acknowledge"),
@ActivationConfigProperty(propertyName = "destinationType", propertyValue =
"javax.jms.Queue")
})
public class NewUserMDB implements MessageListener {
//@Resource used for setRollbackOnly()

@Resource
MessageDrivenContext messageDrivenContext;
//@PersistenceContect used to save data to persistance
@PersistenceContext(unitName = "SECS-ejbPU")
private EntityManager em;

...
--------------------

here's the top of the error message
--------------------

Exception while loading the app
org.glassfish.deployment.common.DeploymentException: Message Driven Beans can't
be Managed Beans
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:169)
...
--------------------

that's a bug, ain't it?



 Comments   
Comment by seamus_sullivan [ 22/Mar/10 ]

I can reproduce this error with an even simpler ejb project consisting solely of
a message driven bean (containing no CDI annotations). Glassfish will fail to
deploy the application and generates the following stacktrace:

org.glassfish.deployment.common.DeploymentException: Message Driven Beans can't
be Managed Beans
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:169)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:125)
at
org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:224)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.ja
va:338)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.ja
va:183)
at
org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:272)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:3
05)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:3
20)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1
176)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunnerImpl.java:
83)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRu
nnerImpl.java:1235)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRu
nnerImpl.java:1224)
at
com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:365)
at
com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:204)
at
com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
at
com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:100)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java
:245)
at
com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:17
0)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.
java:135)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at
com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53
)
at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:33
0)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.jboss.weld.DefinitionException: Message Driven Beans can't be
Managed Beans
at
org.jboss.weld.bean.SessionBean.checkEJBTypeAllowed(SessionBean.java:313)
at org.jboss.weld.bean.SessionBean.initialize(SessionBean.java:122)
at
org.jboss.weld.bootstrap.AbstractBeanDeployer.deploy(AbstractBeanDeployer.java:1
11)
at
org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:151)
at
org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:367)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:167)
... 30 more

Removing or renaming the beans.xml file results in a successful deployment.

Comment by seamus_sullivan [ 20/Apr/10 ]
      • Issue 11672 has been confirmed by votes. ***
Comment by kumara [ 20/Apr/10 ]

Change to release.

Comment by rogerk [ 26/Jul/10 ]

assign to Siva

Comment by rogerk [ 26/Jul/10 ]

assign to Siva

Comment by Sivakumar Thyagarajan [ 08/Oct/10 ]

I can't seem to reproduce this issue. Could you file a test-case for this?

Targetting for MS6

Comment by seamus_sullivan [ 08/Oct/10 ]

I've attached an eclipse project that consistently results in the Weld exception below
when deployed.

It appears to properly work (deploys, and the bean responds to messages) on the
version of GlassFish I currently have installed:

GlassFish Server Open Source Edition 3.0.1 (build 22)

It never successfully deployed on the most recent build of GlassFish that was
publicly available when this bug was created. In order for deployment to work on that
build of GlassFish, the @MessageDriven annotation had to be removed from the bean.

Comment by seamus_sullivan [ 08/Oct/10 ]

Created an attachment (id=5104)
Eclipse Project file illustrating deployment failure

Comment by Sivakumar Thyagarajan [ 13/Oct/10 ]

Created an attachment (id=5138)
ejb-jar that I used to try to reproduce the issue

Comment by Sivakumar Thyagarajan [ 13/Oct/10 ]

Sorry for bothering you again.

The eclipse project doesn't include a beans.xml. Did you include a beans.xml
manually to the ejb-jar?

Is this meant to be a simple ejb-jar with just an MDB? If yes, I tried to
reproduce that with your MDB and sun-ejb-jar.xml and a beans.xml and I could
successfully deploy against latest glassfish promotion. I have attached my ejb-
jar.

$ asadmin deploy /export/work/workspaces/gfv3/appserv-
tests/build/module/archive/cdi-hello-mdb-ejb.jar
Application deployed with name cdi-hello-mdb-ejb.

Command deploy executed successfully.

Could you provide me your ejb jar to help reproduce this issue?

Comment by Sivakumar Thyagarajan [ 24/Oct/10 ]

awaiting test case. moved to MS7

Comment by Sivakumar Thyagarajan [ 30/Nov/10 ]

Cannot reproduce with the provided test-case. The provided archive successfully deploys against latest promoted 3.1 builds (b30 and above).





[GLASSFISH-11668] redeploy issue with WicketExamples and directory deployment Created: 10/Mar/10  Updated: 19/Nov/10  Resolved: 19/Nov/10

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

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

Operating System: Solaris
Platform: Sun


Attachments: Text File heap-analysis-bug-11668.zip     PNG File jconsole-heapandpermgen-unaffected.png     Text File server.log    
Issuezilla Id: 11,668
Status Whiteboard:

weld-int-required


 Description   

Build 2010-03-10 nightly of v3u1...

http://gf-hudson.sfbay/hudson/view/GF%20v3u1/job/gf-v3u1-nightly/lastSuccessfulBuild/artifact/bundles/glassfish-v3u1-b03-03_10_2010.zip

solaris

jdk 6 update 18

I am able to directory deploy the content of the WicketExamples.war file.
https://glassfish.dev.java.net/nonav/issues/showattachment.cgi/4250/WicketExamples.war

I can redeploy the directory multiple times... until I actually access a page in
the app... like the page
http://localhost:8080/WicketExamples/signin/?wicket:bookmarkablePage=:org.apache.wicket.examples.signin.SignIn

after I access that page in the sample the next redeploy appears to be the cause
of all kinds of grief in the server log....

AND

the asadmin redeploy command looks like it gets hung... I have to control C the
command. If I try a different command (like stop-domain), that also appears to
hang...

I have to use kill to force the server to stop.



 Comments   
Comment by vince kraemer [ 10/Mar/10 ]

here is the output from the command-line

bash-3.2$ glassfish/bin/asadmin start-domain
Waiting for DAS to start ....
Started domain: domain1
Domain location:
/export/home/vkraemer/glassfishv3u1nightly/glassfish/domains/domain1
Log file:
/export/home/vkraemer/glassfishv3u1nightly/glassfish/domains/domain1/logs/server.log
Admin port for the domain: 4848
Command start-domain executed successfully.
bash-3.2$
bash-3.2$
bash-3.2$ date ; glassfish/bin/asadmin deploy --name WicketExamples /tmp/WE ; date
Wed Mar 10 13:46:15 PST 2010
Application deployed successfully with name WicketExamples.

Command deploy executed successfully.
Wed Mar 10 13:46:59 PST 2010
bash-3.2$ date ; glassfish/bin/asadmin redeploy --name WicketExamples ; dateWed
Mar 10 13:48:11 PST 2010
Application deployed successfully with name WicketExamples.

Command redeploy executed successfully.
Wed Mar 10 13:48:52 PST 2010
bash-3.2$ date ; glassfish/bin/asadmin redeploy --name WicketExamples ; date
Wed Mar 10 13:49:00 PST 2010
Application deployed successfully with name WicketExamples.

Command redeploy executed successfully.
Wed Mar 10 13:49:43 PST 2010
bash-3.2$ date ; glassfish/bin/asadmin redeploy --name WicketExamples ; date
Wed Mar 10 13:50:11 PST 2010
Application deployed successfully with name WicketExamples.

Command redeploy executed successfully.
Wed Mar 10 13:50:54 PST 2010
bash-3.2$ # accessed the signin example page
bash-3.2$ date ; glassfish/bin/asadmin redeploy --name WicketExamples ; date
Wed Mar 10 13:52:38 PST 2010
^CWed Mar 10 13:56:57 PST 2010

Comment by vince kraemer [ 10/Mar/10 ]

Created an attachment (id=4264)
the server log

Comment by bht [ 10/Mar/10 ]

.

Comment by jpleed3 [ 11/Mar/10 ]

I can't confirm the exact problem that Vince has right now, since my server
doesn't crash. However, I can say that redeploying one of my CDI-enabled
applications repeatedly does eventually consume all available heap space,
according to JConsole.

Oddly enough, where it was crashing before on an OutOfMemoryError, in b08 I'm
able to keep redeploying even though the time and CPU usage involved increases
drastically once the tenured gen is full.

Comment by jpleed3 [ 11/Mar/10 ]

Adding cc

Comment by vince kraemer [ 22/Mar/10 ]

any update on this issue?

Comment by vince kraemer [ 29/Mar/10 ]

any update on this issue?

Comment by rogerk [ 29/Mar/10 ]

Evaluating

Comment by rogerk [ 29/Mar/10 ]

I'm seeing outofmemory stack trace when deploying:

Caused by: java.lang.OutOfMemoryError: Java heap space
at java.util.regex.Matcher.<init>(Matcher.java:208)
at java.util.regex.Pattern.matcher(Pattern.java:888)
at java.util.regex.Pattern.matches(Pattern.java:929)
at java.lang.String.matches(String.java:2091)
at org.jboss.weld.util.reflection.Reflections.getPropertyName(Reflections.java:101)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.<init>(WeldMethodImpl.java:156)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.of(WeldMethodImpl.java:78)
at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:284)
at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:140)
at
org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:50)
at
org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:38)
at com.google.common.collect.MapMaker$StrategyImpl.compute(MapMaker.java:592)
at com.google.common.collect.MapMaker$StrategyImpl.compute(MapMaker.java:462)
at
com.google.common.collect.CustomConcurrentHashMap$ComputingImpl.get(CustomConcurrentHashMap.java:2045)
at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:164)
at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:61)
at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:88)
at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:134)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:377)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:165)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:125)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:224)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:338)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:183)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:272)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:310)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:320)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1176)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunnerImpl.java:83)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
at org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:141)
at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:573)

Comment by rogerk [ 29/Mar/10 ]

Nothing special about the BeanDeploymentArchive passed to Weld bootstrap.
It's a single BDA with 621 classes. May have to file JIRA issue on this.

Comment by rogerk [ 29/Mar/10 ]

I've filed: https://jira.jboss.org/jira/browse/WELD-476
We'll track this issue there, since this "appears" to be a Weld issue.

Comment by rogerk [ 29/Mar/10 ]

I increased the memory footprint using the following jvm options in GlassFish
domain.xml file:

<jvm-options>-Xms1024m</jvm-options>
<jvm-options>-Xmx1024m</jvm-options>

Now the application deploys and runs fine.
How do you want to proceed with this issue?
I've already opened a Weld (JIRA) issue as well.

Comment by vince kraemer [ 30/Mar/10 ]

I will test the WA on some of my systems to see if I can reproduce your result.

If the change seems to resolve the issue, we probably need to push the change
into code/templates that create domains and the default domain... for 3.0.1 and 3.1.

That will also help resolve the NB issue, too.

I will let you know my results later today.

Comment by jpleed3 [ 30/Mar/10 ]

Those settings sound fine for a server, but you want to start out with a
minimum heap size of 1 GB for a development environment? Right now I have 3 GB
available, and I have open Outlook, Communicator, IE8, Word, Excel, and NB,
with GF, SQL Server and McAfee running in the background. I don't even like the
idea of defaulting the maximum to 1 GB for development.

"If the change seems to resolve the issue, we probably need to push the change
into code/templates that create domains and the default domain... for 3.0.1 and
3.1."

What reasonably well built application requires a 1 GB heap simply to deploy
(and possibly serve 1 user)? This is a workaround, nothing more. Something in
Weld or the Weld integration is consuming much more memory than it should be;
the solution is to find out why, and not to just give it more memory to make it
happy.

Comment by rogerk [ 30/Mar/10 ]

As I stated earlier in this issue -I've filed a weld (JIRA) issue as I could not
immediately see anything in the Weld Integration code (after doing some quick
memory profiling), and Weld is attempting to deal with 621 classes (doing
introspection... etc..). This application looks like a large demo application?
I kind of agree that increasing the memory footprint could be classified as a
workaround - although an application with 621 classes (or beans that Weld must
deal with) sounds large (I'd have to talk with the Weld folks about that.

Comment by jpleed3 [ 30/Mar/10 ]

Roger - I don't disagree with your last comment. As far as things GF can
control, increasing the heap size might well be the solution. But I don't think
that necessarily means that the default memory settings should be changed.

Comment by vince kraemer [ 30/Mar/10 ]

the proposed work-around does seem to work in my environment.

Comment by vince kraemer [ 30/Mar/10 ]

The change appears to have pushed the issue off until later.

Here is the new sequence...

deploy the example web app.

run the app's signin demo, without using the word "wicket" in either field.

touch one of the class files (like a recompile).

do a redeploy

run the signin demo again, without using the word "wicket" in either field.

touch one of the class files.

attempt to redeploy... the redeploy appears to hang again.

So... the work-around seems to delay the inevitable, and not for long.

Comment by bht [ 30/Mar/10 ]

I originally encountered the issue with an application that is much smaller than
the examples. That application does not use CDI, it just had an empty beans.xml
that the IDE generated.

While I am writing this, I find that GlassFish V3 is locking up (100% CPU) on
shutdown with a 3rd party war file:
http://www.forgerock.org/downloads/openam_release9_20100207.war

There are just too many problems with things that look easy to do at first. The
environment on any developer's installation quickly becomes complex enough that
any problems such as this become complete application development showstoppers.
It has taken vbkraemer and me more than a manweek including a whole weekend to
prepare a testcase. This testcase is a gift that the Wicket team provided.

With the openam bug, it looks like I will soon switch from developing my own
software to becoming a 3rd party software testing guinea pig. Therefore I would
prefer that this bug gets resolved without workaround, even while it does no
longer affect me as I am not using CDI at present.

Comment by rogerk [ 31/Mar/10 ]

bht - Is this shutdown problem you described a CDI issue? If not, I would
recommend filing another GlassFish issue outside of the cdi category - thanks.

Comment by rogerk [ 31/Mar/10 ]

Getting back to the memory consumption issue...
I've verified that the memory consumption issue occurs just by redeploying the
application (even without class changes). I've updated:
https://jira.jboss.org/jira/browse/WELD-476
accordingly with the additional information.

Comment by rogerk [ 31/Mar/10 ]

Just another issue. I'm in contact with a Weld engineer about this memory
consumption issue. He tells me the war itself consumes about 500 mb of heap.
He did tell me that post 1.0.1-Final release they fixed some memory leak issues.
He intends to look at the problem running against GlassFish (with my assistance).
Will keep you posted.

Comment by pjiricka [ 19/Apr/10 ]

.

Comment by rogerk [ 19/Apr/10 ]

More updates on JIRA issue:

https://jira.jboss.org/jira/browse/WELD-476

Comment by Alexis MP [ 22/Apr/10 ]

cc

Comment by rogerk [ 03/May/10 ]

Just tried latest Weld trunk (revision 6212) against up to date GlassFish 3.0.1
source and received outof memory exception upon deployment of the WicketExamples
application:

[#|2010-05-03T16:15:12.067-0400|SEVERE|glassfish3.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=23;_ThreadName=AutoDeployer;|Exception
while loading the app
org.glassfish.deployment.common.DeploymentException: java.lang.OutOfMemoryError:
Java heap space
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:167)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:125)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:224)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:338)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:183)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:272)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:310)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:320)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1176)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunnerImpl.java:83)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
at org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:141)
at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:573)
at
org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:459)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:391)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:376)
at
org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:195)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Caused by: com.google.common.collect.ComputationException:
java.lang.OutOfMemoryError: Java heap space
at com.google.common.collect.MapMaker$StrategyImpl.compute(MapMaker.java:602)
at com.google.common.collect.MapMaker$StrategyImpl.compute(MapMaker.java:462)
at
com.google.common.collect.CustomConcurrentHashMap$ComputingImpl.get(CustomConcurrentHashMap.java:2045)
at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:164)
at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:64)
at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:91)
at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:134)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:380)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:165)
... 18 more
Caused by: java.lang.OutOfMemoryError: Java heap space

Comment by rogerk [ 10/May/10 ]

3.1

Comment by David Konecny [ 10/May/10 ]

.

Comment by Sivakumar Thyagarajan [ 24/May/10 ]

Here are the results of a preliminary analysis. There are 4 images included as
part of the attached zip. Two of these[gf-simple-deploy-redeploy-heap.png and
gf-simple-deploy-redeploy-permgen.png respectively] show the effect of simply
deploying and redeploying the wicket app. This is used as a control and also to
demonstrate that there are no leaks happening during simple
deployment/redeployment in GF's or Weld's side. Notice that there is almost no
heap-space carried over from one deploy to the next and perm-gen space and the
number of loaded classes adjusts back after every redeployment.

The other two images [redeploy-with-app-use-heap.png and redeploy-with-app-use-
permgen.png] shows that happens when the app is deployed and used and then
redeployed multiple times. In gf-deploy-redeploy-with-app-use-heap.png, one can
notice that the number of classes do not go unloaded after a redeploy and there
is also a corresponding heap-space retained from the original deploy. The
growing permgen usage in redeploy-with-app-use-permgen.png (contrast this with
the corresponding simple deploy permgen graph) also proves that classes from the
earlier deploy are not being unloaded and being held.

The application is a large application and uses above 450MB of heap-space
normally. With further leak of unloaded classes(and corresponding permgen and
heap space usage) across the redeploy operation, the redeploy fails with "out of
heap"

The solution is to start using the fixes in Weld and ensuring that further
analysis on heap and permgen usage is covered in his fixes. However I see that
the first phase of his changes appearing in Weld only on May 14th as per the
final comment in the related Weld issue https://jira.jboss.org/browse/WELD-476
as part of Weld 1.0.2/Weld 1.1. Since GlassFish 3.0.1 integrates Weld 1.0.1-SP2,
the fixes aren't available yet.

The current work-around is to:

  • this application is very huge for a demo app. The application in turn seems to
    be a collection of multiple Wicket demos bundled together. If it makes sense,
    the application could be broken down into finer-grained Wicket demo
    applications.
  • tune the vm as per the needs of the app and this application requires 1024M.
    Use the java-options workaround suggested by Roger earlier in this thread.
  • Since this demo app appears to not use CDI, remove the WEB-INF/beans.xml

Target milestone for a fix is 3.1.

Comment by Sivakumar Thyagarajan [ 24/May/10 ]

Created an attachment (id=4377)
Heap analysis images

Comment by vince kraemer [ 25/May/10 ]

Thanks for the analysis. Since this sounds like a problem that any app could
encounter (demo apps, production apps, apps that climb on rocks) I think we need
to develop some guidelines about the current limitations of CDI in GlassFish 3.0.1.

It would be nice to know 'how big is too big for CDI and GlassFish' and add that
to the 3.0.1 release notes.

Comment by vince kraemer [ 12/Jul/10 ]

Any update on this issue?

Comment by vince kraemer [ 21/Jul/10 ]

I heard that I should test 3.1 build 11, which includes a recent weld drop.

I was able to get past the 'single use' issue.... but I was still able to get
redeployment to 'hang' eventually (take 10x previous redeploy operations, before
I did a control-C to exit from the redeploy attempt)

On the plus side: asadmin stop-domain after an aborted redeploy was successful.

So, things are starting to move in the right direction... but they aren't
'there' yet.

Comment by rogerk [ 26/Jul/10 ]

assign to Siva

Comment by ludo [ 07/Oct/10 ]

new info?

Comment by Sivakumar Thyagarajan [ 08/Oct/10 ]

We are waiting for a fix to WELD-570 https://jira.jboss.org/browse/WELD-570 that
would resolve this and other memory leak issues. Targetting this for MS7

Comment by Sivakumar Thyagarajan [ 22/Oct/10 ]

Marking as weld-int-required

Comment by Sivakumar Thyagarajan [ 19/Nov/10 ]

Created an attachment (id=5541)
jconsole out showing that heap and permgen are largely unaffected

Comment by Sivakumar Thyagarajan [ 19/Nov/10 ]

WELD-570 is closed with 1.1.BETA2 and we have integrated 1.1.BETA2 into GF3.1
trunk. I tried this testcase multiple times against the latest version of GF3.1
trunk and I can't reproduce the issue. Heap memory and perm-gen space(number of
classes) doesn't increase drastically across redeploys and usage of the Wicket
examples application. So, I am closing this. Please reopen should you still see
this issue.





[GLASSFISH-11666] latest weld in 3.0.1 issue with redeployment and sessions Created: 09/Mar/10  Updated: 20/May/10  Resolved: 20/May/10

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

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

Operating System: All
Platform: Macintosh


Attachments: Zip Archive WebApplicationJSF20.zip     Java Archive File weld-osgi-bundle.jar    
Issuezilla Id: 11,666

 Description   

Have a ee6 web app with simple xhtml referring to a @Named @SessionScoped
bean
Deploy with latest nightly 3.0.1 that has the new weld and first page hit is fine.

Bean:

package foo;
import java.io.Serializable;
import javax.enterprise.context.SessionScoped;
import javax.inject.Named;
@Named (value="foo")
@SessionScoped
public class ABean implements Serializable{
private static final long serialVersionUID = 1L;
int i=0;
public String getI()

{ return "bug"+i++; }

}

and index.xhtml: (and empty bean.xml to trigger CDI)

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html">
<h:head>
<title>Facelet Title</title>
</h:head>
<h:body>
Hello from Facelets #

{foo.i}

bug at redeploy
</h:body>
</html>

Change a bit the @named bean and redeploy (or use deploy on save via
NetBeans)

get this exception:
SEVERE: PWC2767: ClassNotFoundException while loading persisted sessions:
java.lang.ClassNotFoundException:
org.jboss.weld.bean.builtin.InstanceImpl$SerializationProxy
java.lang.ClassNotFoundException:
org.jboss.weld.bean.builtin.InstanceImpl$SerializationProxy
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:315)
at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
at
org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java
:1484)
at
org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(Modu
leImpl.java:695)
at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61)
at
org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleI
mpl.java:1656)
at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:398)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:604)
at
com.sun.enterprise.naming.util.ObjectInputStreamWithLoader.resolveClass(Obje
ctInputStreamWithLoader.java:117)
at
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at java.util.ArrayList.readObject(ArrayList.java:593)
at sun.reflect.GeneratedMethodAccessor58.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm
pl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at
org.apache.catalina.session.StandardSession.readRemainingObject(StandardSess
ion.java:1818)
at
org.apache.catalina.session.StandardSession.readObject(StandardSession.java:1
750)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3
9)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm
pl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at
org.apache.catalina.session.StandardSession.deserialize(StandardSession.java:10
63)
at
org.apache.catalina.session.StandardManager.readSessions(StandardManager.ja
va:511)
at com.sun.enterprise.web.WebModule.loadSessions(WebModule.java:1557)
at
com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1944)
at
com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1614)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:90)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:126)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:241)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:236)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.jav
a:339)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.jav
a:183)
at
org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.jav
a:272)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunner
Impl.java:310)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRun
nerImpl.java:320)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRun
nerImpl.java:1121)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunn
erImpl.java:83)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(
CommandRunnerImpl.java:1235)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(
CommandRunnerImpl.java:1224)
at
org.glassfish.deployment.admin.ReDeployCommand.execute(ReDeployComman
d.java:96)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunner
Impl.java:305)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRun
nerImpl.java:320)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRun
nerImpl.java:1176)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunn
erImpl.java:83)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(
CommandRunnerImpl.java:1235)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(
CommandRunnerImpl.java:1224)
at
com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:36
5)
at
com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:204)
at
com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
at
com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:100)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.j
ava:245)
at
com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170
)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChai
n.java:135)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at
com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.jav
a:53)
at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.jav
a:330)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:30
9)
at java.lang.Thread.run(Thread.java:637)



 Comments   
Comment by ludo [ 09/Mar/10 ]

Created an attachment (id=4263)
sample web app project (for NetBeans)

Comment by ludo [ 09/Mar/10 ]

With 3.0, I had this behavior:
https://jira.jboss.org/jira/browse/WELD-410

Not sure what this bug was closed from a duplicate that I am pretty sure could
be reproduced...easily.

The key step here is to change the bean and redeploy to trigger the session
reloading which does not work...

This is the type of demos I would love to do in conferences (deploy in save and
session preservation with JSF 2.0 and CDI), but this is still not working for me...

Any workaround?

Comment by pmuir [ 10/Mar/10 ]

Re WELD-410 being closed - duplicate means that there are two identical issues -
it is a bookkeeping status.

Re the underlying issue, it is fixed in Weld 1.0.1, I fixed it as part of
another issue. Please test with Weld 1.0.1

Comment by ludo [ 10/Mar/10 ]

to pmuir: this bug was filed using weld 1.0.1 in a gf 3.0.1 nightly build.

GlassFish has a special flag at deploy time to keep session state across
redeployment. NetBeans uses this flag by default.
You can also turn it on via:
http://blogs.sun.com/jluehe/entry/retain_session_data_during_redeployment

If I mention GLASSFISH-316, it is because the app attached in this bug can also
reproduce 316 at redeployment when the session is preserved on glassfish v3
using weld 1.0.
I found 316 by doing a google search of the exception, not by chance.
So 316 is there and can be reproduced as well with weld 1.0 so the GLASSFISH-316 was
closed too fast without investigation (bug comments are minimal)"
Comment is "For whatever reason, I cannot duplicate" but I am pretty sure the
flag to keep the session on was not set on, so this is why it could be be
reproduced.
Usually, instead of closing bugs with a clear exception that once cannot invent,
one must ask for more date to the bug filer

Comment by Ryan Lubke [ 10/Mar/10 ]

Passing to Roger.

Comment by sherryshen [ 10/Mar/10 ]

cc

Comment by rogerk [ 10/Mar/10 ]

Looks like it's an osgi export problem.
The package org.jboss.weld.bean.builtin;
needs to be exported in the weld osgi pom.
I've tested this fix on v3.0 and v3.0.1 using the session redeploy method for
the app.

Comment by ludo [ 10/Mar/10 ]

nice, so to confirm: you see the value of the variable "i" incremented even after a
redeploy on the index page ad not going back to 0?

Comment by rogerk [ 10/Mar/10 ]

yes.

Comment by ludo [ 14/Mar/10 ]

eta for the fix in trunk? What else is missing?
Before March 20th for EclipseCon demos?

Comment by rogerk [ 15/Mar/10 ]

Can you try the attached weld-osgi-bundle.jar to make sure it fixes your problem?
Just put it in glassfishv3/glassfish/modules and restart.
Sending attachment..

Comment by rogerk [ 15/Mar/10 ]

Created an attachment (id=4271)
weld osgi bundle

Comment by rogerk [ 16/Mar/10 ]

Fixed with latest 1.0.0-SP1 integration.





[GLASSFISH-11054] cross-module non-contextual object EE injection failure Created: 16/Nov/09  Updated: 17/Nov/09  Resolved: 17/Nov/09

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

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

Operating System: All
Platform: All


Issuezilla Id: 11,054

 Description   

EE-style injection on a non-contextual CDI object that is defined in ejb module A invoked from within the
context of some other module is not working.



 Comments   
Comment by ksak [ 16/Nov/09 ]

Need to associate defining-bundle context with each instance of InjectionServicesImpl and use that
context during EE-injection resolution.

Comment by ksak [ 17/Nov/09 ]

Fixed on trunk.





[GLASSFISH-14471] cdi-specific task for upgrade test Created: 08/Nov/10  Updated: 03/Dec/10  Due: 03/Dec/10  Resolved: 03/Dec/10

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

Type: Task Priority: Critical
Reporter: Bobby Bissett Assignee: Sivakumar Thyagarajan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: https://glassfish.dev.java.net/servlets/ReadMsg?list=dev&msgNo=19095


Issue Links:
Dependency
depends on GLASSFISH-14357 [BLOCKING] cannot access web applicat... Resolved
blocks GLASSFISH-14467 umbrella task for upgrade testing in ... Closed
Issuezilla Id: 14,471
Tags: 3_1-upgrade-task

 Description   

See parent issue 14467 for more details. To close this task, include a
description of what was tested in your area.



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

CDI is part of the EE6 platform and hence was not available as part of GF2.1.1
However I upgraded a vanilla 2.1.1 domain to 3.1 and ran CDI developer tests successfully against the upgraded domain.

Here is a description of what I did.

Comment by Sivakumar Thyagarajan [ 03/Dec/10 ]

Outlined the list of tasks that I had done in the earlier comment. Hence closing this.





[GLASSFISH-14179] NPE in org.glassfish.web.ha.session.management.HASessionStoreValve.invoke(HASessionStoreValve.java:110 Created: 24/Oct/10  Updated: 26/Nov/10  Resolved: 15/Nov/10

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

Type: Bug Priority: Critical
Reporter: sonymanuel Assignee: Sivakumar Thyagarajan
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified