[GLASSFISH-12007] lib/databases should be moved to a different directory Created: 24/May/10  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: V3
Fix Version/s: 4.1.1

Type: Improvement Priority: Critical
Reporter: Bill Shannon Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 12,007

 Description   

The only thing in the "lib" directory that shouldn't be synchronized to
an instance of a cluster is the lib/databases directory. We should move
this directory to a different location, perhaps a top level "databases"
directory.

This would involved an upgrade service to rename the directory, as well as
changes in the base configuraiton to use the directory in its new location.



 Comments   
Comment by marina vatkina [ 25/May/10 ]

...

Comment by marina vatkina [ 05/Oct/10 ]

Let's first stabilize the current upgrade of the timer service, then look at the
right place for its database files





[GLASSFISH-9856] Monitoring: methodReadyAddEvent, methodReadyRemoveEvent probe is not called for ejb SL bean Created: 29/Sep/09  Updated: 04/Jan/13

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: future release

Type: Improvement Priority: Critical
Reporter: Nazrul Assignee: marina vatkina
Resolution: Unresolved 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,856
Status Whiteboard:

v3_exclude, 3.1-exclude


 Description   

We are not firing methodReadyAddEvent and methodReadyRemoveEvent for EJB SL bean.

Refer to http://monaco.sfbay.sun.com/detail.jsf?cr=6886594 for detailed steps.



 Comments   
Comment by Nazrul [ 29/Sep/09 ]

People who are writing JavaScripts or DTrace scripts may run into this issue in
GFv3. We need to document this limitation of the probe and perhaps put it in the
release note.

Comment by marina vatkina [ 29/Sep/09 ]

SLSB in v2 provide only accumulative data, not the points where the data
changes. The probes are available in v3 for the SFSBs.





[GLASSFISH-4021] Resouce Injection does not work in HandlerChain due to EJB initialization order (non-deterministic) Created: 21/Jan/08  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container, web_services
Affects Version/s: V3
Fix Version/s: 4.1.1

Type: Bug Priority: Critical
Reporter: gfuser9999 Assignee: Lukas Jungmann
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,021
Tags: 3_1-exclude, 4_0-release-notes, 4_0-release-notes-completed, 4_0-release-notes-drafted

 Description   

--------
Problem
--------
1. Resource injections fails when using HandlerChain that have a
EJB/Resource injected that is an EJB/JNDI. And one gets
"Handler xxxxx instance injection failed : Exception attempting to inject
Resolved Ejb-Ref xxxx/bean@jndi: - > xxxxx]

The issues is that assuming we have 2 EJB and we want to have

  • EJB B exposed as Webservice and handle a HandlerChain handler
    So we have
    @Stateless
    @WebService
    @HandlerChain(file = "handle.xml")
    public void EJBBBean { ... }
  • We do not care above EJB A
  • Note that the handler is
    public class handler implements SOAPHanlder { @EJB EJBBBean bean; .... }
  • Now when one deploy this depending on the ordering
    of initialization of EJB, sometimes
    EJBA, EJBB and this works but if sometimes it is
    EJBB, EJBA then resource injection fails
  • The issues is that the following happens where it seems when
    a EJB is exposed as WebService and have a handler,
    a) The EJB is created and the handler is created
    b) The handler will be injected but then the issue is
    that THERE is IT may be possible that at the time
    the dependency is not met (since EJBA is not loaded or initialized
    nor registered to the JNDI even)

com.sun.enterprise.InjectionException: Exception attempting to inject Resolved
Ejb-Ref org.test.ws.FailInjectionHandler/bean@jndi: - > b5Bean into class
org.test.ws.FailInjectionHandler
at
com.sun.enterprise.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:391)
at
com.sun.enterprise.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:206)
at
com.sun.enterprise.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:100)
at
com.sun.enterprise.webservice.WsUtil.processConfiguredHandlers(WsUtil.java:2529)
at
com.sun.enterprise.webservice.WsUtil.configureJAXWSServiceHandlers(WsUtil.java:2570)
at
com.sun.enterprise.webservice.EjbRuntimeEndpointInfo.prepareInvocation(EjbRuntimeEndpointInfo.java:294)
at
com.sun.enterprise.webservice.EjbRuntimeEndpointInfo.initRuntimeInfo(EjbRuntimeEndpointInfo.java:342)
at
com.sun.enterprise.webservice.WebServiceEjbEndpointRegistry.registerEjbWebServiceEndpoint(WebServiceEjbEndpointRegistry.java:122)
at
com.sun.ejb.containers.StatelessSessionContainer.initializeHome(StatelessSessionContainer.java:329)
at
com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:345)
at
com.sun.enterprise.server.AbstractLoader.loadEjbs(AbstractLoader.java:550)
at
com.sun.enterprise.server.ApplicationLoader.doLoad(ApplicationLoader.java:188)

  • Now, this problem does not seems to be that the system does not resolve ordering
    Since writing more EJB seems to say that the GF system tends to order the EJB
    module
    However, there seems to be some race or data structure ordering issue since
    that the EJB module loading sequence on every stop/start is different and
    it is possible to get a EJB processing order that does not work.

--------------------
Testcase and details
--------------------
1. Get the attached NB6 ejbdeptest.zip and deploy
This testcase have many a few EJB modules to make this easier to hit this
Deploy ejbdeptest.ear

2. Stop/Start (asadmin stop-domain/start-domain)
and look for the injection failure. (REPEAT until failure is SEEN)
(grep SEVERE)

3. [Unpredictable and repeat (2) until SEVERE happens like below]

[#......|SEVERE|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=20;_ThreadName=httpSSLWorkerThread-14849-2;_RequestID=3a6b0964-02e0-419f-acc0-49c651e2916b;|Handler
org.test.ws.FailInjectionHandler instance injection failed : Exception
attempting to inject Resolved Ejb-Ref
org.test.ws.FailInjectionHandler/bean@jndi: - > b5Bean into class
org.test.ws.FailInjectionHandler|#]

3. Note some tracing does indicate that Bean processing via getEjbDescriptors()
varies sometimes and below is a failure sequence. (It is unknown
why the behaviour on the EJB processed changes sometimes)

[#.....|INFO|sun-appserver9.1|javax.enterprise.system.co
re.classloading|_ThreadID=10;_ThreadName=main;|[DEBUG] AbstractLoader org.test.s
lsb.e0Bean org.test.slsb.b6Bean org.test.slsb.b3Bean org.test.slsb.b2Bean or
g.test.slsb.b4Bean org.test.slsb.b1Bean org.test.slsb.b5Bean org.test.slsb.b0
Bean org.test.slsb.e1Bean org.test.slsb.zfailBean org.test.slsb.z0Bean org.t
est.slsb.z1Bean org.test.slsb.e2Bean |#]



 Comments   
Comment by Hong Zhang [ 22/Jan/08 ]

Assign to Mahesh for initial investigation. Also addding Bhakti to the Cc.

Attaching CWeng's suggested solutions below:
=============================================
And so i suppose plain common-sense must be used (which would then indicate the
system should be able to tell that a Handler class is used by WebserviceX and
the Handler class need Y, so Y must be initialized by X.

Even if there is no LOAD order, one may presume that creation of ALL EJB should
be done first and then on 2nd part the creation of all Webservices that those
EJB expose is done.
At this point the EJB and Webservice step for a EJB is coupled together....

Comment by Mahesh Kannan [ 14/Feb/08 ]

The problem is that the handlers are created probably way too early.

The Container calls
WebServiceEjbEndpointRegistry.registerEjbWebServiceEndpoint() during container
initialization time which causes the handlers to be instantiated (which inturn
causes injection). We need to delay the instantiation of the handlers till the
dependent EJBs are processed.

One way to do that is to provide two methods:
1. One to register the the EjbService endpoint which WILL NOT call
WsUtil.processConfiguredHandlers()

2. The other method (say createConfiguredHandlers()) can create and call
InjectionManager.injectInstance(handler)

Once the above methods are in place the StatelessContainer can call the second
method from doAfterApplicationDeployed().

I am assigning this to Bhakti to implement the above two methods.

Comment by Bhakti Mehta [ 15/Feb/08 ]

Looking into it

Comment by harpreet [ 09/Apr/08 ]

Based on input from Bhakti, assigning issue to next release

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by ramapulavarthi [ 01/Dec/10 ]

I have n't run any tests but seeing the code in v3.1, we should run into the same problem.
Can't forward port the patches CR6653050 and CR6750245 as the code in v3 is little different from v2.1.
The fix needs to go into EJB container code to change the way we intialize and load the ejb web services.

Comment by Bhakti Mehta [ 08/Dec/10 ]

Reassigning to Rama since he has already looked into this issue . My inclination is to exclude this for this release but will wait for Rama's input

Comment by ramapulavarthi [ 21/Dec/10 ]

This requires changes in EJB Container to change the way EJB ws are loaded and needs coordination with EJB team. Adding V3.1 excludes as this is risky to make this change now.

Comment by Nazrul [ 23/Dec/10 ]

This bug has been around for few releases now. Based on inputs from Bill, I am setting target for 3.2 release with P2 priority so that it gets fixed. If we do not want to fix this bug, please close it.

Comment by 8086 [ 25/Mar/12 ]

We have been waiting for a fix for three years now. As of now, our application needs to be redeployed until it works. This might take anywhere from 1 redeploy to 15 redeploys to get it working.

If you are not fixing it, is there a way to work around it in our code that can remove the pain of innumerous redeploys?

Comment by kumara [ 26/Mar/12 ]

-> Martin Grebac for evaluation.

Comment by Gail Risdal [ 31/May/13 ]

Added the following to the release notes:

Resource Injection does not work in HandlerChain due to EJB initialization order (non-deterministic) (4021)

Description
EJB module deployment may fail when an EJB that is exposed as a web service, and which has a handler, is initialized before an EJB on which it has dependencies. This is caused by the way the EJB container initializes and loads EJB web services.

Workaround
EJB initialization usually happens in alphabetical order. Rename the EJBs so that the EJB exposed as a web service is initialized after the EJB on which it has dependencies.

In the following example, B is initialized first together with handler X, which expects C to be available but it is not, and deployment fails. The workaround is to rename B to D (for example), so lexicographically it follows C, in which case C should be initialized first and be available for injection to X.

EJB module sth:

@Stateless public class C

{...}
@Stateless @WebService @HandlerChain(file = "handlers.xml") public class B {...}

handlers.xml:

<?xml version="1.0" encoding="UTF-8"?>
<jws:handler-chains ...>
<jws:handler-chain>
<jws:handler>
<jws:handler-class>X</jws:handler-class>
</jws:handler>
</jws:handler-chain>
</jws:handler-chains>

Handler:

</jws:handler-chains>
@EJB private C;
...}

Comment by Gail Risdal [ 05/Jun/13 ]

Fixed the example in the release notes (first line in the "Handler" section; release notes document has proper formatting/indentation):

EJB module sth:

@Stateless public class C

{...}
@Stateless @WebService @HandlerChain(file = "handlers.xml") public class B {...}

handlers.xml:

<?xml version="1.0" encoding="UTF-8"?>
<jws:handler-chains ...>
<jws:handler-chain>
<jws:handler>
<jws:handler-class>X</jws:handler-class>
</jws:handler>
</jws:handler-chain>
</jws:handler-chains>

Handler:

public class X implements SOAPHandler<SOAPMessageContext>

{ @EJB private C; ...}




[GLASSFISH-21412] CLONE - EJB + JAX-RS don't work with updated example Created: 11/Aug/15  Updated: 12/Aug/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: None
Fix Version/s: None

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

Issue Links:
Cloners
clones GLASSFISH-20654 EJB + JAX-RS don't work on the simple... Resolved

 Description   
/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */
package pcrl.model.services;

import javax.annotation.ManagedBean;
import javax.ejb.Stateless;
import javax.enterprise.context.RequestScoped;
import pcrl.model.entities.RepairLocation;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import javax.persistence.PersistenceUnit;
import javax.transaction.Transactional;
import javax.ws.rs.BeanParam;
import javax.ws.rs.POST;
import javax.ws.rs.Path;


/**
 *
 * @author walec51
 */
@Stateless
@Path("/api/RepairLocationRepository")
public class RepairLocationRepository {
    
    @PersistenceContext
    private EntityManager em;
    
    @POST
    @Path("add")
    public void add(@BeanParam RepairLocation rl) {
        em.persist(rl);
    }
}

SEVERE:   WebModule[/PcRepairLocations]Exception starting filter pcrl.PcrlApplication
java.lang.InstantiationException
	at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:135)
	at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:5297)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:5909)
	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:2278)
	at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1924)
	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: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.execute(CommandRunnerImpl.java:537)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
	at org.glassfish.deployment.admin.ReDeployCommand.execute(ReDeployCommand.java:131)
	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: java.lang.IllegalStateException: Error when configuring to use the EJB interceptor binding API. JAX-RS EJB integration can not be supported.
	at org.glassfish.jersey.gf.ejb.EjbComponentProvider.registerEjbInterceptor(EjbComponentProvider.java:168)
	at org.glassfish.jersey.gf.ejb.EjbComponentProvider.bind(EjbComponentProvider.java:200)
	at org.glassfish.jersey.server.ApplicationHandler.bindWithComponentProvider(ApplicationHandler.java:809)
	at org.glassfish.jersey.server.ApplicationHandler.bindProvidersAndResources(ApplicationHandler.java:741)
	at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:388)
	at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:157)
	at org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:280)
	at org.glassfish.jersey.internal.Errors$2.call(Errors.java:289)
	at org.glassfish.jersey.internal.Errors$2.call(Errors.java:286)
	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.processWithException(Errors.java:286)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:277)
	at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:262)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:167)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:379)
	at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275)
	at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:131)
	... 53 more
Caused by: java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.glassfish.jersey.gf.ejb.EjbComponentProvider.registerEjbInterceptor(EjbComponentProvider.java:163)
	... 70 more
Caused by: java.lang.NullPointerException
	at com.sun.ejb.containers.InternalInterceptorBindingImpl.registerInterceptor(InternalInterceptorBindingImpl.java:97)
	... 75 more


 Comments   
Comment by atrajano [ 12/Aug/15 ]

It didn't clone the comments as I expected... here is the text that should've gone up on the description

I am encountering the same error on GlassFish 4.1

I created a simple example

https://github.com/trajano/test/tree/local-beans

A simple @Stateless SLSB
A JAX-RS resource annotated with @Stateless
The resource has an @EJB reference
The @PostConstruct method simply does a System.out

In my example it fails the moment the resource SLSB is postconstructed

http://localhost:8080/test-war/V1/resource





[GLASSFISH-21382]  A system exception occurred during an invocation on EJB Created: 27/Jun/15  Updated: 27/Jun/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: dyego Assignee: Srini
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux Ubuntu 14 + 5GB of ram + SSD 80GB



 Description   

In my application, randomily i get :

[2015-06-26T20:53:36.645-0300] [glassfish 4.1] [WARNING] [AS-EJB-00056] [javax.enterprise.ejb.container] [tid: _ThreadID=892 _ThreadName=p: thread-pool-1; w: 796] [timeMillis: 1435362816645] [levelValue: 900] [[
A system exception occurred during an invocation on EJB PaisesNacionalidadesRepositoryRJ, method: public us.linkedby.link.selo.entities.RjPaisesnacionalidades us.linkedby.link.selo.service.referenciarj.paisesnacionalidades.PaisesNacionalidadesRepositoryRJ.getRjPaisesnacionalidadesByNomePais(java.lang.String)]]

[2015-06-26T20:53:36.645-0300] [glassfish 4.1] [WARNING] [] [javax.enterprise.ejb.container] [tid: _ThreadID=892 _ThreadName=p: thread-pool-1; w: 796] [timeMillis: 1435362816645] [levelValue: 900] [[

javax.ejb.TransactionRolledbackLocalException: Client's transaction aborted
at com.sun.ejb.containers.EJBContainerTransactionManager.useClientTx(EJBContainerTransactionManager.java:361)
at com.sun.ejb.containers.EJBContainerTransactionManager.preInvokeTx(EJBContainerTransactionManager.java:255)
at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:4524)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1986)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:210)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy337.getRjPaisesnacionalidadesByNomePais(Unknown Source)
at us.linkedby.link.selo.service.referenciarj.paisesnacionalidades._EJB31_GeneratedPaisesNacionalidadesRepositoryRJIntf__Bean_.getRjPaisesnacionalidadesByNomePais(Unknown Source)
at us.linkedby.link.selo.service.referenciarj.paisesnacionalidades.PaisesNacionalidadesServiceRJ.getRjPaisesnacionalidadesCodigoByNomePais(PaisesNacionalidadesServiceRJ.java:69)
at sun.reflect.GeneratedMethodAccessor354.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

But, this occurs if i call 15k times the EJB method... and ocurs in diferents parts of my code...



 Comments   
Comment by dyego [ 27/Jun/15 ]

only in linux, on windows doest occurs

Comment by dyego [ 27/Jun/15 ]

The transaction is maked to rollback in diferent points on execution and this error occurs after that...

If i invoce 10k times the EJB method this not occurs..

11k not occurs...

15k occurs...

help!





[GLASSFISH-21370] Periodic Deadlock in EJB Timer Service Created: 02/Jun/15  Updated: 02/Jun/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0
Fix Version/s: None

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

Red Hat Enterprise Linux 6



 Description   

Occasionally while attempting to redeploy an application the redeployment will fail due to what appears to be a deadlock situation with the EJB Timer service. This happens fairly infrequently, perhaps 6 times in the last two years. However, when it does happen the only recourse is to restart GlassFish forcefully, which is fairly invasive since the redeploy with the "--keepstate=true" option allows redeployment without downtime. The problem prevents all application deployment/redeployment/undeployment, and GlassFish starting/stopping/restarting so during one of these events I must forcefully kill the Glassfish process (kill -9 on Linux) . It appears that the EJB Timer Service uses the EclipseLink ORM library to store timer information in a Derby database and encounters a Lock timeout situation. The stack trace from the most recent incident follows:

[2015-06-02T12:32:53.965-0400] [glassfish 4.0] [WARNING] [] [org.eclipse.persistence.session.file:/opt/glassfish/4/glassfish/domains/domain1/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App] [tid: _ThreadID=5374 _ThreadName=Thread-2966] [timeMillis: 1433262773965] [levelValue: 900] [[

Local Exception Stack:
Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.5.0.v20130507-3faac2b): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLTransactionRollbackException: A lock could not be obtained within the time requested
Error Code: 30000
Call: SELECT "TIMERID" FROM "EJB_TIMER_TBL" WHERE ("CONTAINERID" = ?)
bind => [1 parameter bound]
Query: ReportQuery(name="findTimerIdsByContainer" referenceClass=TimerState sql="SELECT "TIMERID" FROM "EJB_TIMER_TBL" WHERE ("CONTAINERID" = ?)")
at org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:340)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:679)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:558)
at org.eclipse.persistence.internal.sessions.AbstractSession.basicExecuteCall(AbstractSession.java:1995)
at org.eclipse.persistence.sessions.server.ServerSession.executeCall(ServerSession.java:570)
at org.eclipse.persistence.sessions.server.ClientSession.executeCall(ClientSession.java:248)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:242)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:228)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeSelectCall(DatasourceCallQueryMechanism.java:299)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.selectAllRows(DatasourceCallQueryMechanism.java:694)
at org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.selectAllRowsFromTable(ExpressionQueryMechanism.java:2714)
at org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.selectAllReportQueryRows(ExpressionQueryMechanism.java:2651)
at org.eclipse.persistence.queries.ReportQuery.executeDatabaseQuery(ReportQuery.java:847)
at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:899)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:1114)
at org.eclipse.persistence.queries.ReadAllQuery.execute(ReadAllQuery.java:402)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:1202)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2894)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1797)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1779)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1744)
at org.eclipse.persistence.internal.jpa.QueryImpl.executeReadQuery(QueryImpl.java:258)
at org.eclipse.persistence.internal.jpa.QueryImpl.getResultList(QueryImpl.java:468)
at org.glassfish.ejb.persistent.timer.TimerBean.findTimerIdsByContainer(TimerBean.java:115)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.glassfish.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:4695)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:630)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:582)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:140)
at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
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:4667)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4655)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy307.findTimerIdsByContainer(Unknown Source)
at org.glassfish.ejb.persistent.timer.PersistentEJBTimerService.stopTimers(PersistentEJBTimerService.java:643)
at com.sun.ejb.containers.BaseContainer.stopTimers(BaseContainer.java:2422)
at com.sun.ejb.containers.BaseContainer.onShutdown(BaseContainer.java:4191)
at org.glassfish.ejb.startup.SingletonLifeCycleManager.doShutdown(SingletonLifeCycleManager.java:172)
at org.glassfish.ejb.startup.EjbApplication.stop(EjbApplication.java:293)
at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:161)
at org.glassfish.internal.data.ModuleInfo.stop(ModuleInfo.java:324)
at org.glassfish.internal.data.ApplicationInfo.stop(ApplicationInfo.java:380)
at com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:1056)
at com.sun.enterprise.v3.server.ApplicationLifecycle.disable(ApplicationLifecycle.java:2125)
at com.sun.enterprise.v3.server.ApplicationLifecycle.disable(ApplicationLifecycle.java:113)
at com.sun.enterprise.v3.server.ApplicationLoaderService.stopApplication(ApplicationLoaderService.java:497)
at com.sun.enterprise.v3.server.ApplicationLoaderService.preDestroy(ApplicationLoaderService.java:465)
at org.jvnet.hk2.internal.ClazzCreator.preDestroyMe(ClazzCreator.java:294)
at org.jvnet.hk2.internal.ClazzCreator.dispose(ClazzCreator.java:358)
at org.jvnet.hk2.internal.SystemDescriptor.dispose(SystemDescriptor.java:473)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.destroyOne(AsyncRunLevelContext.java:196)
at org.jvnet.hk2.internal.ServiceHandleImpl.destroy(ServiceHandleImpl.java:159)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$DownAllTheWay.run(CurrentTaskFuture.java:583)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture.go(CurrentTaskFuture.java:120)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.proceedTo(AsyncRunLevelContext.java:296)
at org.glassfish.hk2.runlevel.internal.RunLevelControllerImpl.proceedTo(RunLevelControllerImpl.java:66)
at com.sun.enterprise.v3.server.AppServerStartup.proceedTo(AppServerStartup.java:532)
at com.sun.enterprise.v3.server.AppServerStartup.stop(AppServerStartup.java:485)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.stop(GlassFishImpl.java:88)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.stop(GlassFishDecorator.java:68)
at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl.stop(EmbeddedOSGiGlassFishImpl.java:82)
at com.sun.enterprise.v3.admin.StopServer.doExecute(StopServer.java:79)
at com.sun.enterprise.v3.admin.StopDomainCommand.execute(StopDomainCommand.java:96)
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:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at org.glassfish.api.AsyncImpl$1$1.run(AsyncImpl.java:76)
Caused by: java.sql.SQLTransactionRollbackException: A lock could not be obtained within the time requested
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedResultSet.closeOnTransactionError(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source)
at com.sun.gjc.spi.base.ResultSetWrapper.next(ResultSetWrapper.java:103)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.processResultSet(DatabaseAccessor.java:754)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:653)
... 80 more
Caused by: java.sql.SQLException: A lock could not be obtained within the time requested
at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source)
... 92 more
Caused by: ERROR 40XL1: A lock could not be obtained within the time requested
at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
at org.apache.derby.impl.services.locks.ConcurrentLockSet.lockObject(Unknown Source)
at org.apache.derby.impl.services.locks.ConcurrentLockSet.zeroDurationLockObject(Unknown Source)
at org.apache.derby.impl.services.locks.AbstractPool.zeroDurationlockObject(Unknown Source)
at org.apache.derby.impl.services.locks.ConcurrentPool.zeroDurationlockObject(Unknown Source)
at org.apache.derby.impl.store.raw.xact.RowLocking2nohold.lockRecordForRead(Unknown Source)
at org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.lockPositionForRead(Unknown Source)
at org.apache.derby.impl.store.access.conglomerate.GenericScanController.fetchRows(Unknown Source)
at org.apache.derby.impl.store.access.heap.HeapScan.fetchNextGroup(Unknown Source)
at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.reloadArray(Unknown Source)
at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.getNextRowCore(Unknown Source)
at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(Unknown Source)
at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(Unknown Source)
... 85 more
]]

[2015-06-02T12:32:53.970-0400] [glassfish 4.0] [WARNING] [ejb.system_exception] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=5374 _ThreadName=Thread-2966] [timeMillis: 1433262773970] [levelValue: 900] [[
EJB5184:A system exception occurred during an invocation on EJB TimerBean, method: public java.util.Set org.glassfish.ejb.persistent.timer.TimerBean.findTimerIdsByContainer(long)]]



 Comments   
Comment by slominskir [ 02/Jun/15 ]

The stack trace above shows that it is impossible to cleanly shutdown GlassFish when the EJB Timer service is stuck in this unusual state. Deployment is also impossible.





[GLASSFISH-21280] Transaction attribute in subclass is ignored if a generic supertype exist Created: 29/Dec/14  Updated: 29/Dec/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: martinandersson.com Assignee: Srini
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: 1 week
Time Spent: Not Specified
Original Estimate: 1 week
Environment:

Tested on Windows 7 x64 and Windows 8 x64


Tags: annotations, ejb-container, inheritance, transactionmanager

 Description   

According to "Common Annotations" spec as well as the EJB spec, supertype transaction attribute annotations are "always ignored" if the subclass override a method. Only if the superclass has a method not overridden by the subclass do annotations put in the superclass apply.

This work as long as the supertype, whether that be a class or interface, is not generic. As soon as it is, GlassFish behave in the other way around: ignoring the most specific subclass annotations and instead use annotations declared in the supertype.

Full description, specification quotes as well as test cases is located here (the project is a working Maven project, clone + build and all tests are executed using Arquillian):

https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/ejb/transactions/AnnotationInheritanceTest.java

In a separate project my mine that first exposed this issue, I have no workaround to apply. I have to stop using GlassFish or begin a new architectural design. Given that transactions are an intrinsic part of applications, as well as inheritance is a common method for code reuse in object oriented design, I consider this bug "critical". Also note that WildFly 8.2.0 pass all the tests provided in the link.






[GLASSFISH-21108] PostgreSQL XA transactions are not supported Created: 27/Jun/14  Updated: 27/Apr/16

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: sergey.s.sazonov Assignee: Srini
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

postgresql-9.3-1101.jdbc4.jar



 Description   

We are trying to use XA transactions in PostgreSQL and facing with strange behaviour. We have many parallel EJB requests and small part of them fail due to business logic rules, exception goes up through nested EJBs and transaction rolles back. It works fine most of the time but sometimes request ends with HTTP 500 and we see these errors in log. Could you please check that. In administration guide PostgreSQL XA driver is not mentioned, so maybe it is just not supported yet.

[2014-06-26T20:53:40.677+0400] [glassfish 4.0] [WARNING] [jts.exception_on_resource_operation] [javax.enterprise.system.core.transaction.com.sun.jts.CosTransactions] [tid: _ThreadID=35 _ThreadName=http-listener-1(10)] [timeMillis: 1403801620677] [levelValue: 900] [[
  JTS5031: Exception [java.lang.RuntimeException: org.postgresql.xa.PGXAException: Error preparing transaction] on Resource [prepare] operation.]]

[2014-06-26T20:53:40.678+0400] [glassfish 4.0] [WARNING] [jts.unexpected_error_occurred_twopc_rollback] [javax.enterprise.system.core.transaction.com.sun.jts.jtsxa] [tid: _ThreadID=35 _ThreadName=http-listener-1(10)] [timeMillis: 1403801620678] [levelValue: 900] [[
  JTS5068: Unexpected error occurred in rollback
org.postgresql.xa.PGXAException: Error rolling back prepared transaction
	at org.postgresql.xa.PGXAConnection.rollback(PGXAConnection.java:418)
	at com.sun.gjc.spi.XAResourceImpl.rollback(XAResourceImpl.java:195)
	at com.sun.jts.jta.TransactionState._rollback(TransactionState.java:202)
	at com.sun.jts.jta.TransactionState.rollback(TransactionState.java:180)
	at com.sun.jts.jtsxa.OTSResourceImpl.rollback(OTSResourceImpl.java:333)
	at com.sun.jts.CosTransactions.RegisteredResources.distributeRollback(RegisteredResources.java:1040)
	at com.sun.jts.CosTransactions.TopCoordinator.rollback(TopCoordinator.java:2291)
	at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:391)
	at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:231)
	at com.sun.jts.jta.TransactionImpl.commit(TransactionImpl.java:122)
	at com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:509)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:854)
	at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:719)
	at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:503)
	at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4475)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2009)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1979)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
	at com.sun.proxy.$Proxy337.updateIssue(Unknown Source)
	at com.btf.soesg.api.__EJB31_Generated__CommandEndpoint__Intf____Bean__.updateIssue(Unknown Source)
	at com.btf.soesg.api.rest.Endpoint.updateIssue(Endpoint.java:219)
	at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	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:224)
	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:317)
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:198)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:946)
	at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:323)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:372)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:335)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:218)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
	at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:354)
	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:744)
Caused by: org.postgresql.util.PSQLException: ERROR: prepared transaction with identifier "4871251_UhsAAL/TCNl0ZXN0LmJ0Zi5sb2NhbCxzZXJ2ZXIsUDEwMA==_dGVzdC5idGYubG9jYWwsc2VydmVyLFAzNzAwLAA=" does not exist
	at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2161)
	at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1890)
	at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:559)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:403)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:331)
	at org.postgresql.xa.PGXAConnection.rollback(PGXAConnection.java:406)
	... 73 more
]]

[2014-06-26T20:53:40.693+0400] [glassfish 4.0] [WARNING] [ejb.system_exception] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=35 _ThreadName=http-listener-1(10)] [timeMillis: 1403801620693] [levelValue: 900] [[
  EJB5184:A system exception occurred during an invocation on EJB CommandEndpoint, method: public void com.btf.soesg.api.CommandEndpoint.updateIssue(java.lang.String,com.btf.soesg.api.dto.UpdateIssueParam) throws com.btf.soesg.api.APIException]]

[2014-06-26T20:53:40.694+0400] [glassfish 4.0] [WARNING] [] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=35 _ThreadName=http-listener-1(10)] [timeMillis: 1403801620694] [levelValue: 900] [[
  
javax.ejb.EJBException: Transaction aborted
	at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:725)
	at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:503)
	at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4475)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2009)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1979)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
	at com.sun.proxy.$Proxy337.updateIssue(Unknown Source)
	at com.btf.soesg.api.__EJB31_Generated__CommandEndpoint__Intf____Bean__.updateIssue(Unknown Source)
	at com.btf.soesg.api.rest.Endpoint.updateIssue(Endpoint.java:219)
	at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	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:224)
	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:317)
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:198)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:946)
	at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:323)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:372)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:335)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:218)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
	at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:354)
	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:744)
Caused by: javax.transaction.RollbackException
	at com.sun.jts.jta.TransactionImpl.commit(TransactionImpl.java:127)
	at com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:509)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:854)
	at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:719)
	... 61 more
]]

[2014-06-26T20:53:40.697+0400] [glassfish 4.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=35 _ThreadName=http-listener-1(10)] [timeMillis: 1403801620697] [levelValue: 900] [[
  StandardWrapperValve[com.btf.soesg.api.rest.App]: Servlet.service() for servlet com.btf.soesg.api.rest.App threw exception
javax.transaction.RollbackException
	at com.sun.jts.jta.TransactionImpl.commit(TransactionImpl.java:127)
	at com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:509)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:854)
	at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:719)
	at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:503)
	at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4475)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2009)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1979)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
	at com.sun.proxy.$Proxy337.updateIssue(Unknown Source)
	at com.btf.soesg.api.__EJB31_Generated__CommandEndpoint__Intf____Bean__.updateIssue(Unknown Source)
	at com.btf.soesg.api.rest.Endpoint.updateIssue(Endpoint.java:219)
	at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	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:224)
	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:317)
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:198)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:946)
	at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:323)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:372)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:335)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:218)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
	at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:354)
	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:744)
]]


 Comments   
Comment by MarioLovisi [ 27/Apr/16 ]

Hi please try to set 'max_prepared_transactions' in the local postgres.config to the max numbers of connection in the connection pool.

see doc. http://www.postgresql.org/docs/9.4/static/runtime-config-resource.html
" you will probably want max_prepared_transactions to be at least as large as max_connections, so that every session can have a prepared transaction pending."





[GLASSFISH-20970] Classloader leak in PoolResizeTimerTask Created: 04/Feb/14  Updated: 03/Jun/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: electricsam Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0_1-evangelists, 4_0_1-reviewed

 Description   

There is a classloader leak in the com.sun.ejb.containers.util.pool.NonBlockingPool and com.sun.ejb.containers.util.pool.NonBlockingPool$PoolResizeTimerTask.

When a application is re-deployed instances of these two classes are created as described in https://java.net/jira/browse/GLASSFISH-16676

This also leads to a classloader leak, which eventually prevents re-deployment of applications.



 Comments   
Comment by electricsam [ 04/Feb/14 ]

Here is the reference tree to the GC root:

this - EarClassLoader

  • parent - WebappClassLoader
    • <classloader> - GenericEJBHome_Generated
      • cls - PresentationManagerImpl$ClassDataImpl
        • value - WeakHashMapSafeReadLock$Entry
          • [] - WeakHashMapSafeReadLock$Entry[]
            • table - WeakHashMapSafeReadLock
              • map - PresentationManagerImpl$1
                • classToClassData - PresentationManagerImpl
                  • presentationMgr - POAProtocolMgr
                    • protocolMgr - StatelessSessionContainer
                      • this$0 - StatelessSessionContainer$SessionContextFactory
                        • factory - NonBlockingPool
                          • this$0 - NonBlockingPool$PoolResizeTimerTask
Comment by electricsam [ 05/Feb/14 ]

I think the actual issue is that there is a hard reference in the dictionary map in PresentationManagerImpl$ClassDataImpl

Here is some cleanup code that I've tried running in the @PreDestroy method of a singleton startup bean to try to clean up classloader leaks. This seems to get rid of many of them. This is just test code.

public abstract class ClassLoaderCleaner {

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

    private ClassLoader loader = null;

    protected void destroy() {
        try {
            loader = getClass().getClassLoader();
            cleanUp();
        } catch (Throwable e) {
            logger.log(Level.SEVERE, null, e);
        }
    }

    private Thread[] getThreads() {
        ThreadGroup rootGroup = Thread.currentThread().getThreadGroup();
        ThreadGroup parentGroup;
        while ((parentGroup = rootGroup.getParent()) != null) {
            rootGroup = parentGroup;
        }

        Thread[] threads = new Thread[rootGroup.activeCount()];
        while (rootGroup.enumerate(threads, true) == threads.length) {
            threads = new Thread[threads.length * 2];
        }
        return threads;
    }

    private boolean loaderRemovable(ClassLoader cl) {
        if (cl == null) {
            return false;
        }
        Object isDoneCalled = getObject(cl, "doneCalled");
        if (cl.getClass().getName().equals(loader.getClass().getName())
                && isDoneCalled instanceof Boolean && (Boolean) isDoneCalled) {
            return true;
        }
        return loader == cl;
    }

    private Field getField(Class clazz, String fieldName) {
        Field f = null;
        try {
            f = clazz.getDeclaredField(fieldName);
        } catch (NoSuchFieldException ex) {

        } catch (SecurityException ex) {
            logger.log(Level.WARNING, "Unable to get field " + fieldName + " on " + clazz.getName(), ex);
        }

        if (f == null) {
            Class parent = clazz.getSuperclass();
            if (parent != null) {
                f = getField(parent, fieldName);
            }
        }
        if (f != null) {
            f.setAccessible(true);
        }
        return f;
    }

    private Object getObject(Object instance, String fieldName) {
        Class clazz = instance.getClass();
        Field f = getField(clazz, fieldName);
        if (f != null) {
            try {
                return f.get(instance);
            } catch (IllegalArgumentException | IllegalAccessException ex) {
                logger.log(Level.WARNING, "Unable to get " + fieldName + " on " + clazz.getName(), ex);
            }
        }
        return null;
    }

    private void cleanUp() {
        Thread[] threads = getThreads();
        for (Thread thread : threads) {
            if (thread != null) {
                cleanContextClassLoader(thread);
                cleanOrb(thread);
                cleanThreadLocal(thread);
                cleanTimers(thread);
            }

        }
    }

    private void cleanContextClassLoader(Thread thread) {
        if (loaderRemovable(thread.getContextClassLoader())) {
            thread.setContextClassLoader(null);
            logger.log(Level.INFO, "Cleaned context classloader {0}", thread.getName());
        }
    }

    private void cleanOrb(Thread thread) {
        Object currentWork = getObject(thread, "currentWork");
        if (currentWork != null) {
            Object orb = getObject(currentWork, "orb");
            if (orb != null) {
                Object transportManager = getObject(orb, "transportManager");
                if (transportManager != null) {
                    Thread selector = (Thread) getObject(transportManager, "selector");
                    if (selector != null && loaderRemovable(selector.getContextClassLoader())) {
                        selector.setContextClassLoader(null);
                        logger.log(Level.INFO, "Cleaned orb ref {0}", thread.getName());
                    }
                }
            }
        }
    }

    private void removeThreadLocal(Object entry, Object threadLocals, Thread thread) {
        ThreadLocal threadLocal = (ThreadLocal) getObject(entry, "referent");
        if (threadLocal != null) {
            Class clazz = null;
            try {
                clazz = Class.forName("java.lang.ThreadLocal$ThreadLocalMap");
            } catch (ClassNotFoundException ex) {
                logger.log(Level.WARNING, null, ex);
            }
            if (clazz != null) {
                Method removeMethod = null;
                Method[] methods = clazz.getDeclaredMethods();
                if (methods != null) {
                    for (Method method : methods) {
                        if (method.getName().equals("remove")) {
                            removeMethod = method;
                            removeMethod.setAccessible(true);
                            break;
                        }
                    }
                }
                if (removeMethod != null) {
                    try {
                        removeMethod.invoke(threadLocals, threadLocal);
                        logger.log(Level.INFO, "Cleaned threadlocal {0}", thread.getName());
                    } catch (IllegalAccessException | IllegalArgumentException | InvocationTargetException ex) {
                        logger.log(Level.SEVERE, null, ex);
                    }
                }

            }

        }
    }

    private void cleanThreadLocal(Thread thread) {
        Object threadLocals = getObject(thread, "threadLocals");
        if (threadLocals != null) {
            Object table = getObject(threadLocals, "table");
            if (table != null) {
                int size = Array.getLength(table);
                for (int i = 0; i < size; i++) {
                    Object entry = Array.get(table, i);
                    if (entry != null) {
                        Field valueField = getField(entry.getClass(), "value");
                        if (valueField != null) {
                            try {
                                Object value = valueField.get(entry);
                                if (value != null && value instanceof ClassLoader && loaderRemovable((ClassLoader) value)) {
                                    removeThreadLocal(entry, threadLocals, thread);
                                }
                            } catch (IllegalArgumentException | IllegalAccessException ex) {
                                logger.log(Level.WARNING, "Unable to get threadlocal value", ex);
                            }

                        }
                    }

                }
            }
        }
    }

    private void cleanTimers(Thread thread) {
        Object queue = getObject(thread, "queue");
        if (queue != null) {
            Object queue2 = getObject(queue, "queue");
            if (queue2 != null) {
                Object[] taskArray = (Object[]) queue2;
                for (Object timerTask : taskArray) {
                    if (timerTask != null) {
                        Object timerService = getObject(timerTask, "timerService_");
                        if (timerService != null) {
                            Object ejbContainerUtil = getObject(timerService, "ejbContainerUtil");
                            if (ejbContainerUtil != null) {

                                Object orbHelper = getObject(ejbContainerUtil, "orbHelper");
                                if (orbHelper != null) {
                                    Object protocolManager = getObject(orbHelper, "protocolManager");
                                    if (protocolManager != null) {
                                        Object presentationMgr = getObject(protocolManager, "presentationMgr");
                                        if (presentationMgr != null) {
                                            //PresentationManagerImpl$1
                                            Object classToClassData = getObject(presentationMgr, "classToClassData");
                                            if (classToClassData != null) {
                                                Object lock = getObject(classToClassData, "lock");
                                                //WeakHashMapSafeReadLock
                                                Object map = getObject(classToClassData, "map");
                                                if (lock != null && lock instanceof ReentrantReadWriteLock && map != null && map instanceof Map) {
                                                    ReentrantReadWriteLock theLock = (ReentrantReadWriteLock) lock;
                                                    Set<Object> toBeRemoved = new HashSet<>();
                                                    synchronized (presentationMgr) {
                                                        synchronized (classToClassData) {
                                                            theLock.writeLock().lock();
                                                            try {
                                                                Map theMap = (Map) map;
                                                                for (Object key : theMap.keySet()) {
                                                                    if (key != null) {
                                                                        //PresentationManagerImpl$ClassDataImpl
                                                                        Object value = theMap.get(key);

                                                                        if (value != null) {
                                                                            Object cls = getObject(value, "cls");
                                                                            if (cls != null && cls instanceof Class) {
                                                                                ClassLoader cl = ((Class) cls).getClassLoader();
                                                                                if (cl != null) {
                                                                                    if (loaderRemovable(cl) || loaderRemovable(cl.getParent())) {
                                                                                        toBeRemoved.add(key);
                                                                                    }
                                                                                }
                                                                            }

                                                                            Object dictionary = getObject(value, "dictionary");
                                                                            if (dictionary != null && dictionary instanceof Map) {
                                                                                Iterator it = ((Map) dictionary).values().iterator();
                                                                                while (it.hasNext()) {
                                                                                    Object o = it.next();
                                                                                    if (o != null  && o instanceof Class) {
                                                                                        ClassLoader cl = ((Class) o).getClassLoader();
                                                                                        if (cl != null) {
                                                                                            if (loaderRemovable(cl) || loaderRemovable(cl.getParent())) {
                                                                                                it.remove();
                                                                                                logger.log(Level.INFO, "Cleaned dictionary: {0}", thread.getName());
                                                                                            }
                                                                                        }
                                                                                    }
                                                                                }

                                                                            }

                                                                        }
                                                                    }
                                                                }

                                                            } finally {
                                                                theLock.writeLock().unlock();
                                                            }
                                                        }
                                                    }

                                                    Method removeMethod = null;
                                                    Method[] methods = presentationMgr.getClass().getDeclaredMethods();
                                                    if (methods != null) {
                                                        for (Method method : methods) {
                                                            if (method.getName().equals("flushClass")) {
                                                                removeMethod = method;
                                                                removeMethod.setAccessible(true);
                                                                break;
                                                            }
                                                        }
                                                    }
                                                    if (removeMethod != null) {
                                                        for (Object cls : toBeRemoved) {
                                                            try {
                                                                removeMethod.invoke(presentationMgr, cls);
                                                                logger.log(Level.INFO, "Cleaned classToClassData: {0}", thread.getName());
                                                            } catch (IllegalAccessException | IllegalArgumentException | InvocationTargetException ex) {
                                                                logger.log(Level.SEVERE, null, ex);
                                                            }
                                                        }
                                                    }

                                                }

                                            }
                                        }
                                    }
                                }

                                Object timer = getObject(ejbContainerUtil, "_timer");
                                if (timer != null && timer instanceof Timer) {
                                    int purged = ((Timer) timer).purge();
                                    logger.log(Level.INFO, "Cleaned timer {0}. Purged {1} tasks.", new Object[]{thread.getName(), purged});
                                }
                            }
                        }
                    }
                }
            }
        }
    }

}

There is still a leak in a thread local with the following tree

this     - value: org.glassfish.javaee.full.deployment.EarClassLoader #6
 <- loader     - class: com.sun.ejb.containers.CMCSingletonContainer, value: org.glassfish.javaee.full.deployment.EarClassLoader #6
  <- container     - class: com.sun.ejb.containers.EJBLocalObjectInvocationHandler, value: com.sun.ejb.containers.CMCSingletonContainer #9
   <- optionalEjbLocalBusinessObjectImpl     - class: com.sun.ejb.containers.SingletonContextImpl, value: com.sun.ejb.containers.EJBLocalObjectInvocationHandler #12
    <- [0]     - class: java.lang.Object[], value: com.sun.ejb.containers.SingletonContextImpl #10
     <- elementData     - class: java.util.ArrayList, value: java.lang.Object[] #96711
      <- beans     - class: com.sun.ejb.containers.ContainerSynchronization, value: java.util.ArrayList #97409
       <- sync     - class: com.sun.ejb.containers.EjbContainerUtilImpl$TxData, value: com.sun.ejb.containers.ContainerSynchronization #2
        <- containerData     - class: com.sun.enterprise.transaction.JavaEETransactionImpl, value: com.sun.ejb.containers.EjbContainerUtilImpl$TxData #2
         <- clientTx     - class: com.sun.ejb.EjbInvocation, value: com.sun.enterprise.transaction.JavaEETransactionImpl #2
          <- inv     - class: com.sun.enterprise.security.authorize.HandlerData, value: com.sun.ejb.EjbInvocation #5
           <- value     - class: java.lang.ThreadLocal$ThreadLocalMap$Entry, value: com.sun.enterprise.security.authorize.HandlerData #6
            <- [121]     - class: java.lang.ThreadLocal$ThreadLocalMap$Entry[], value: java.lang.ThreadLocal$ThreadLocalMap$Entry #1185
             <- table     - class: java.lang.ThreadLocal$ThreadLocalMap, value: java.lang.ThreadLocal$ThreadLocalMap$Entry[] #179
              <- threadLocals (thread object)     - class: java.lang.Thread, value: java.lang.ThreadLocal$ThreadLocalMap #179




[GLASSFISH-20899] @PrePassivate / @PostActivate get called on every bean invocation when Availability is enabled Created: 14/Nov/13  Updated: 24/Aug/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0
Fix Version/s: None

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

ALL


Tags: availability, ejb, sfsb

 Description   

When running on GF 3.1, everything works fine,
but when upgraded to GF 4.0, @Stateful bean's @PrePassivate / @PostActivate
calls get invoked for every bean method invocation, which isn't good

This only happens when Availability is enabled for the application.
When it's not, everything works fine as well.



 Comments   
Comment by lprimak [ 19/Nov/13 ]

When using passivationCapable = false, the behavior is correct,
leading me to believe that this is a simple bug vs. ejb spec issue

Comment by lprimak [ 19/Nov/13 ]

Related Issue:
https://java.net/jira/browse/EJB_SPEC-116

Comment by lprimak [ 19/Nov/13 ]

Also, transient fields get lost on failover in GF 4.0:

@Stateful
public class MyBean implements Serializable
{
private String myState;
private final transient Set<String> myTransient = new HashSet<>();
}

When HA-failover happens to a copy of MyBean on another cluster node,
myTransient is null

which is a regression from GF 3.1 and is how I found this error in the first place

Comment by marina vatkina [ 19/Nov/13 ]

When passivationCapable = false the HA is not happening - see EJB 3.2 spec for the warning

Comment by lprimak [ 20/Nov/13 ]

Also, in the code above, the SFSB implements Serializable.
This is related to another issue with Glassfish.
SFSBs should not have to implement Serializable. But, in HA, if they don't another exception is thrown.

Related JIRA:
https://java.net/jira/browse/GLASSFISH-20892

Comment by lprimak [ 24/Aug/14 ]

How does this relate to this bug?
https://java.net/jira/browse/GLASSFISH-20318
According to that bug non-serializable SFSB should work,
Does this deal with transient fields correctly?

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-10876] NoSuchObjectLocalException observed during an invocation on EJB SFSB method Created: 06/Nov/09  Updated: 02/Dec/11

Status: In Progress
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: meenap Assignee: Mahesh Kannan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: Sun


Issuezilla Id: 10,876
Status Whiteboard:

3.1-exclude

Tags: 3_1-exclude

 Description   

When running longevity test using jms application, the following exception is
observed after about 5 days 2 hours into the run. The exception has appeared
once where it had caused few client errors to happen at the same. This has
happened only once during 7 days and did not affect the continuation of the run.

[#|2009-11-04T17:08:16.531-0800|INFO|glassfish|null|_ThreadID=914890;_ThreadName=Thread-1;|removing
the bean|#]

[#|2009-11-04T17:08:17.531-0800|SEVERE|glassfish|javax.enterprise.system.container.ejb.com.sun.ejb.containers.util.cache|_ThreadID=914890;_ThreadName=Thread-1;|NRU-samples.rmiiiopclient.ejb.SFSB:
Cannot load from BACKUPSTORE FOR Key: <16900a7800051f-ffffffffa78972d0-6bcd41>|#]

[#|2009-11-04T17:08:17.531-0800|WARNING|glassfish|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=914890;_ThreadName=Thread-1;|A
system exception occurred during an invocation on EJB SFSB method null
javax.ejb.NoSuchObjectLocalException: The EJB does not exist. session-key:
16900a7800051f-ffffffffa78972d0-6bcd41
at
com.sun.ejb.containers.StatefulSessionContainer._getContext(StatefulSessionContainer.java:1398)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2404)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1797)
at
com.sun.ejb.containers.StatefulSessionContainer.removeBean(StatefulSessionContainer.java:941)
at com.sun.ejb.containers.EJBObjectImpl.remove(EJBObjectImpl.java:202)
at
com.sun.ejb.containers.EJBObjectInvocationHandler.invokeEJBObjectMethod(EJBObjectInvocationHandler.java:262)
at
com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:165)
at
com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:118)
at $Proxy122.remove(Unknown Source)
at sun.reflect.GeneratedMethodAccessor73.invoke(Unknown Source)
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:225)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:144)
at
com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:84)
at $Proxy129.remove(Unknown Source)
at
com.s1as.e2e.richAccess.servlet.SendOrder.processRequest(SendOrder.java:138)
at com.s1as.e2e.richAccess.servlet.SendOrder.doPost(SendOrder.java:211)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
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: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)

#]

[#|2009-11-04T17:09:15.078-0800|INFO|glassfish|null|_ThreadID=914890;_ThreadName=Thread-1;|Exception
e java.rmi.NoSuchObjectException: CORBA OBJECT_NOT_EXIST 9998 Maybe; nested
exception is: org.omg.CORBA.OBJECT_NOT_EXIST: vmcid: 0x2000 minor
code: 1806 completed: Maybe|#]

[#|2009-11-04T17:09:15.203-0800|SEVERE|glassfish|null|_ThreadID=914890;_ThreadName=Thread-1;|java.rmi.NoSuchObjectException:
CORBA
OBJECT_NOT_EXIST 9998 Maybe; nested exception is:
org.omg.CORBA.OBJECT_NOT_EXIST: vmcid: 0x2000 minor code: 1806
completed: Maybe
at
com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:280)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.wrapException(Util.java:698)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:235)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:144)
at
com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:84)
at $Proxy129.remove(Unknown Source)
at
com.s1as.e2e.richAccess.servlet.SendOrder.processRequest(SendOrder.java:138)
at com.s1as.e2e.richAccess.servlet.SendOrder.doPost(SendOrder.java:211)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
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: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: org.omg.CORBA.OBJECT_NOT_EXIST: vmcid: 0x2000 minor code: 1806
completed: Maybe
Caused by: javax.ejb.NoSuchObjectLocalException: The EJB does not exist.
session-key: 16900a7800051f-ffffffffa78972d0-6bcd41
at
com.sun.ejb.containers.StatefulSessionContainer._getContext(StatefulSessionContainer.java:1398)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2404)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1797)
at
com.sun.ejb.containers.StatefulSessionContainer.removeBean(StatefulSessionContainer.java:941)
at com.sun.ejb.containers.EJBObjectImpl.remove(EJBObjectImpl.java:202)
at
com.sun.ejb.containers.EJBObjectInvocationHandler.invokeEJBObjectMethod(EJBObjectInvocationHandler.java:262)
at
com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:165)
at
com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:118)
at $Proxy122.remove(Unknown Source)
at sun.reflect.GeneratedMethodAccessor73.invoke(Unknown Source)
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:225)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:144)
at
com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:84)
at $Proxy129.remove(Unknown Source)
at
com.s1as.e2e.richAccess.servlet.SendOrder.processRequest(SendOrder.java:138)
at com.s1as.e2e.richAccess.servlet.SendOrder.doPost(SendOrder.java:211)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
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: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)

#]


 Comments   
Comment by meenap [ 06/Nov/09 ]

OS changed to Win XP

Comment by Mahesh Kannan [ 09/Nov/09 ]

Meena,
Is there a sun-ejb-jar.xml? If so, what is the ejb-removal-timeout-in-seconds
set to?

Also, were ther any errors related to passivation befor ethis exception?

Since, this has occured only once in this run and it is occurring on a remove
call this can be moved to a P4. I will wait for meena's reply before doing so.

Comment by Mahesh Kannan [ 09/Nov/09 ]

Meena,
Is there a sun-ejb-jar.xml? If so, what is the ejb-removal-timeout-in-seconds
set to?

Also, were ther any errors related to passivation befor ethis exception?

Since, this has occured only once in this run and it is occurring on a remove
call this can be moved to a P4. I will wait for meena's reply before doing so

Comment by Mahesh Kannan [ 12/Nov/09 ]

Since this has not affected the run, marking it as v3.1

Comment by Chris Kasso [ 08/Dec/10 ]

Clearing Fix Version (3.1_ms7) since the issue has been excluded from 3.1.





[GLASSFISH-12298] Support for java:comp/env style lookups Created: 19/Jun/10  Updated: 29/Sep/10

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: aldaris Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 12,298

 Description   

Currently it is not possible to use in testcodes the java:comp/env style JNDI
names, only the global JNDI names are working. If you're using embedded
GlassFish for testing, then this could lead to a serious problem (for example if
the production code is using these JNDI names, then the lookup will fail for
tests, but in standalone environment they are working).



 Comments   
Comment by marina vatkina [ 21/Jun/10 ]

Embeddable EJB API access

Comment by marina vatkina [ 29/Sep/10 ]

The restriction for java:global is only for the client code. EJBs can still
access java:comp namespace





[GLASSFISH-12251] Hardcoded message in Java File... Created: 15/Jun/10  Updated: 15/Feb/13

Status: In Progress
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: naman_mehta Assignee: marina vatkina
Resolution: Unresolved 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,251
Tags: 3_1-exclude

 Description   

File Location:
ejb/ejb-container/src/main/java/com/sun/ejb/containers/builder/StatefulContainerBuilder.java

this.backingStore = factory == null ? null : factory.createBackingStore(conf);
_logger.log(Level.WARNING, "StatefulContainerbuilder instantiated store: " +
backingStore.getClass().getName() + " ==> " + conf.getStoreName());

Need to use message key here and also provide diagnostic info for the same in
properties file.



 Comments   
Comment by naman_mehta [ 20/Jun/10 ]

List of files which has hardcoded messages:

ejb/ejb-container/src/main/java/com/sun/ejb/containers/BaseContainer.java:
_logger.log(Level.INFO, "Portable JNDI names for EJB " +

ejb/ejb-container/src/main/java/com/sun/ejb/containers/BaseContainer.java:
_logger.log(Level.WARNING, "A system exception occurred during an
invocation on EJB " +

ejb/ejb-container/src/main/java/com/sun/ejb/containers/StatefulSessionContainer.java:
throw new NoSuchObjectLocalException("The EJB does not exist."
ejb/ejb-container/src/main/java/com/sun/ejb/containers/StatefulSessionContainer.java:
"The EJB does not exist. key: " + sessionKey);
ejb/ejb-container/src/main/java/com/sun/ejb/containers/StatefulSessionContainer.java:
("The EJB does not exist. session-key: " +
sessionKey);

In statefulSessionContainer.java file TRACE_LEVEL is set to FINE so all messages
need to be part of LogStrings.properties file.

ejb/ejb-container/src/main/java/com/sun/ejb/containers/MessageBeanContainer.java:

_logger.log(
Level.WARNING,
"[MDBContainer] Got exception while trying "
+ "to add task to ContainerWorkPool. Will execute "
+ "cleanupResources on current thread",th);

ejb/ejb-container/src/main/java/com/sun/ejb/containers/BaseContainer.java:
_logger.log(Level.INFO, "Portable JNDI names for EJB " +
ejb/ejb-container/src/main/java/com/sun/ejb/containers/BaseContainer.java:
_logger.log(Level.INFO, "Glassfish-specific (Non-portable) JNDI names for
EJB " +
ejb/ejb-container/src/main/java/com/sun/ejb/containers/BaseContainer.java:
_logger.log(Level.FINE, "Internal container JNDI names for EJB " +

Comment by naman_mehta [ 26/Aug/10 ]

More hard coded messages found in the code. Please move it to appropriate
LogStrings.properties file. Assign message key, id and diagnostic info for the same.

ejb/ejb-container/src/main/java/com/sun/ejb/containers/builder/StatefulContainerBuilder.java:
_logger.log(Level.INFO, "StatefulContainerBuilder.buildStoreManager()
storeName: " + storeName);

Comment by marina vatkina [ 01/Oct/10 ]

->p3

Comment by marina vatkina [ 17/Nov/10 ]

Will need to wait. There was an attempt to help with this issue from the
community, but it didn't go far...

Comment by Cheng Fang [ 13/Apr/11 ]

Fixed StatefulContainerBuilder, and part of BaseContainer.

Sending ejb-container/src/main/java/com/sun/ejb/containers
Sending ejb-container/src/main/java/com/sun/ejb/containers/BaseContainer.java
Sending ejb-container/src/main/java/com/sun/ejb/containers/builder/StatefulContainerBuilder.java
Sending ejb-container/src/main/resources/com/sun/ejb/containers/LocalStrings.properties
Sending ejb-container/src/main/resources/com/sun/logging/enterprise/system/container/ejb/LogStrings.properties

Committed revision 46126.

Comment by Tom Mueller [ 15/Feb/13 ]

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





[GLASSFISH-12202] EJB-5 Full EJB 3.1 API support in Embeddable EJB API Created: 09/Jun/10  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: 4.1.1

Type: New Feature Priority: Major
Reporter: marina vatkina Assignee: marina vatkina
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issue Links:
Dependency
depends on GLASSFISH-12151 EJB-5-1 Support libraries in classpat... Resolved
depends on GLASSFISH-9950 EJB-5-5 Embedded EJB Container: need ... Open
Issuezilla Id: 12,202

 Description   

Add support for missing EJB 3.1 functionality ( Web Service endpoints, MDBs,
Timer Service ) in Embeddable EJB API



 Comments   
Comment by marina vatkina [ 09/Jun/10 ]

...

Comment by marina vatkina [ 29/Jun/10 ]

EJB Timer service is fully supported.

EJBs in a .war file (or an exploded directory) are supported as following:

  • If there is only 1 web app with EJBs, libraries are ignored.
  • If there are other EJB modules, a temp ear is created.

Note that to test EJBs in a war, the client code needs to use EJBs with
intefaces (those ejbs are not part of the classpath, and can't be loaded by the
client class loader) or a version of the EJB without annotations (so it's not
treated as another EJB module).

Webservices are supported when they are packaged in a war file with the
static-shell.jar ONLY.

Comment by marina vatkina [ 29/Jun/10 ]

One more note: To test webservices, a property
"org.glassfish.ejb.embedded.glassfish.web.http.port" must be passed to
createEJBContainer() call. For the pre-installed GlassFish, the value of the
property can be any non-empty string, but the actual value is ignored.

Comment by marina vatkina [ 01/Oct/10 ]

Postpone...





[GLASSFISH-14231] ejb cache victim-selection-policy of FIFO does not work as expected Created: 27/Oct/10  Updated: 16/Dec/10

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: anoman Assignee: Mahesh Kannan
Resolution: Unresolved 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: 14,231
Tags: 3_1-exclude

 Description   

I set the following cache settings:

ejb-container.cache-resize-quantity - 8
ejb-container.max-cache-size - 20
ejb-container.cache-idle-timeout-in-seconds - 600
ejb-container.removal-timeout-in-seconds - 5400
ejb-container.victim-selection-policy - FIFO

Restart the server for the settings to take effect.

I create 11 beans and call them in a set order (0 to 10) and watch if there are
any passivations. None take place as expected.
I then create an extra bean and call the beans again in a set order (0 to 11)
9 passivations take place, but I expect bean 0 to be passivated (due to FIFO),
but it is not.

[testng-all] Creating 11 Stateful beans...
[testng-all] Bean 0 served by EJB ejb.cache1.EjbCacheSFSB@1510b03
[testng-all] Bean 1 served by EJB ejb.cache1.EjbCacheSFSB@edf123
[testng-all] Bean 2 served by EJB ejb.cache1.EjbCacheSFSB@1581448
[testng-all] Bean 3 served by EJB ejb.cache1.EjbCacheSFSB@1e90d95
[testng-all] Bean 4 served by EJB ejb.cache1.EjbCacheSFSB@13ac592
[testng-all] Bean 5 served by EJB ejb.cache1.EjbCacheSFSB@6de78a
[testng-all] Bean 6 served by EJB ejb.cache1.EjbCacheSFSB@71729c
[testng-all] Bean 7 served by EJB ejb.cache1.EjbCacheSFSB@d5c08f
[testng-all] Bean 8 served by EJB ejb.cache1.EjbCacheSFSB@f048dc
[testng-all] Bean 9 served by EJB ejb.cache1.EjbCacheSFSB@b21710
[testng-all] Bean 10 served by EJB ejb.cache1.EjbCacheSFSB@1ad3ac1
[testng-all] done
[testng-all] Verify that so far nothing is passivated
[testng-all] Bean 0 passivate count = 0
[testng-all] Bean 1 passivate count = 0
[testng-all] Bean 2 passivate count = 0
[testng-all] Bean 3 passivate count = 0
[testng-all] Bean 4 passivate count = 0
[testng-all] Bean 5 passivate count = 0
[testng-all] Bean 6 passivate count = 0
[testng-all] Bean 7 passivate count = 0
[testng-all] Bean 8 passivate count = 0
[testng-all] Bean 9 passivate count = 0
[testng-all] Bean 10 passivate count = 0
[testng-all] Call the beans in a predicted usage pattern:
[testng-all]
[testng-all] Bean[0] is called 1st (back when it was created)
[testng-all] Bean[10] was called least recently
[testng-all] Bean[7] is not called as much as the other beans
[testng-all] client called bean 10 (server inst used was
ejb.cache1.EjbCacheSFSB@1ad3ac1)
[testng-all] client called bean 9 (server inst used was
ejb.cache1.EjbCacheSFSB@b21710)
[testng-all] client called bean 8 (server inst used was
ejb.cache1.EjbCacheSFSB@f048dc)
[testng-all] client called bean 7 (server inst used was
ejb.cache1.EjbCacheSFSB@d5c08f)
[testng-all] client called bean 6 (server inst used was
ejb.cache1.EjbCacheSFSB@71729c)
[testng-all] client called bean 5 (server inst used was
ejb.cache1.EjbCacheSFSB@6de78a)
[testng-all] client called bean 4 (server inst used was
ejb.cache1.EjbCacheSFSB@13ac592)
[testng-all] client called bean 3 (server inst used was
ejb.cache1.EjbCacheSFSB@1e90d95)
[testng-all] client called bean 2 (server inst used was
ejb.cache1.EjbCacheSFSB@1581448)
[testng-all] client called bean 1 (server inst used was
ejb.cache1.EjbCacheSFSB@edf123)
[testng-all] client called bean 0 (server inst used was
ejb.cache1.EjbCacheSFSB@1510b03)
[testng-all] client called bean 10 (server inst used was
ejb.cache1.EjbCacheSFSB@1ad3ac1)
[testng-all] client called bean 9 (server inst used was
ejb.cache1.EjbCacheSFSB@b21710)
[testng-all] client called bean 8 (server inst used was
ejb.cache1.EjbCacheSFSB@f048dc)
[testng-all] client called bean 7 (server inst used was
ejb.cache1.EjbCacheSFSB@d5c08f)
[testng-all] client called bean 6 (server inst used was
ejb.cache1.EjbCacheSFSB@71729c)
[testng-all] client called bean 5 (server inst used was
ejb.cache1.EjbCacheSFSB@6de78a)
[testng-all] client called bean 4 (server inst used was
ejb.cache1.EjbCacheSFSB@13ac592)
[testng-all] client called bean 3 (server inst used was
ejb.cache1.EjbCacheSFSB@1e90d95)
[testng-all] client called bean 2 (server inst used was
ejb.cache1.EjbCacheSFSB@1581448)
[testng-all] client called bean 1 (server inst used was
ejb.cache1.EjbCacheSFSB@edf123)
[testng-all] client called bean 0 (server inst used was
ejb.cache1.EjbCacheSFSB@1510b03)
[testng-all] client called bean 10 (server inst used was
ejb.cache1.EjbCacheSFSB@1ad3ac1)
[testng-all] client called bean 9 (server inst used was
ejb.cache1.EjbCacheSFSB@b21710)
[testng-all] client called bean 8 (server inst used was
ejb.cache1.EjbCacheSFSB@f048dc)
[testng-all] client called bean 6 (server inst used was
ejb.cache1.EjbCacheSFSB@71729c)
[testng-all] client called bean 5 (server inst used was
ejb.cache1.EjbCacheSFSB@6de78a)
[testng-all] client called bean 4 (server inst used was
ejb.cache1.EjbCacheSFSB@13ac592)
[testng-all] client called bean 3 (server inst used was
ejb.cache1.EjbCacheSFSB@1e90d95)
[testng-all] client called bean 2 (server inst used was
ejb.cache1.EjbCacheSFSB@1581448)
[testng-all] client called bean 1 (server inst used was
ejb.cache1.EjbCacheSFSB@edf123)
[testng-all] client called bean 0 (server inst used was
ejb.cache1.EjbCacheSFSB@1510b03)
[testng-all] client called bean 10 (server inst used was
ejb.cache1.EjbCacheSFSB@1ad3ac1)
[testng-all] client called bean 9 (server inst used was
ejb.cache1.EjbCacheSFSB@b21710)
[testng-all] client called bean 8 (server inst used was
ejb.cache1.EjbCacheSFSB@f048dc)
[testng-all] client called bean 6 (server inst used was
ejb.cache1.EjbCacheSFSB@71729c)
[testng-all] client called bean 5 (server inst used was
ejb.cache1.EjbCacheSFSB@6de78a)
[testng-all] client called bean 4 (server inst used was
ejb.cache1.EjbCacheSFSB@13ac592)
[testng-all] client called bean 3 (server inst used was
ejb.cache1.EjbCacheSFSB@1e90d95)
[testng-all] client called bean 2 (server inst used was
ejb.cache1.EjbCacheSFSB@1581448)
[testng-all] client called bean 1 (server inst used was
ejb.cache1.EjbCacheSFSB@edf123)
[testng-all] client called bean 0 (server inst used was
ejb.cache1.EjbCacheSFSB@1510b03)
[testng-all] client called bean 10 (server inst used was
ejb.cache1.EjbCacheSFSB@1ad3ac1)
[testng-all] client called bean 9 (server inst used was
ejb.cache1.EjbCacheSFSB@b21710)
[testng-all] client called bean 8 (server inst used was
ejb.cache1.EjbCacheSFSB@f048dc)
[testng-all] client called bean 7 (server inst used was
ejb.cache1.EjbCacheSFSB@d5c08f)
[testng-all] client called bean 6 (server inst used was
ejb.cache1.EjbCacheSFSB@71729c)
[testng-all] client called bean 5 (server inst used was
ejb.cache1.EjbCacheSFSB@6de78a)
[testng-all] client called bean 4 (server inst used was
ejb.cache1.EjbCacheSFSB@13ac592)
[testng-all] client called bean 3 (server inst used was
ejb.cache1.EjbCacheSFSB@1e90d95)
[testng-all] client called bean 2 (server inst used was
ejb.cache1.EjbCacheSFSB@1581448)
[testng-all] client called bean 1 (server inst used was
ejb.cache1.EjbCacheSFSB@edf123)
[testng-all] client called bean 0 (server inst used was
ejb.cache1.EjbCacheSFSB@1510b03)
[testng-all] Verify that STILL nothing has yet been passivated
[testng-all] Bean 10 passivate count = 0
[testng-all] Bean 9 passivate count = 0
[testng-all] Bean 8 passivate count = 0
[testng-all] Bean 7 passivate count = 0
[testng-all] Bean 6 passivate count = 0
[testng-all] Bean 5 passivate count = 0
[testng-all] Bean 4 passivate count = 0
[testng-all] Bean 3 passivate count = 0
[testng-all] Bean 2 passivate count = 0
[testng-all] Bean 1 passivate count = 0
[testng-all] Bean 0 passivate count = 0
[testng-all] Now create one more bean and call it.
[testng-all]
[testng-all] When it is returned to the cache some other bean should be pushed
out!!
[testng-all]
[testng-all] Creating 12 Stateful beans...
[testng-all] Bean 0 served by EJB ejb.cache1.EjbCacheSFSB@da431b
[testng-all] Bean 1 served by EJB ejb.cache1.EjbCacheSFSB@1cd468c
[testng-all] Bean 2 served by EJB ejb.cache1.EjbCacheSFSB@6cd243
[testng-all] Bean 3 served by EJB ejb.cache1.EjbCacheSFSB@c8d4b4
[testng-all] Bean 4 served by EJB ejb.cache1.EjbCacheSFSB@febb9
[testng-all] Bean 5 served by EJB ejb.cache1.EjbCacheSFSB@1a165ca
[testng-all] Bean 6 served by EJB ejb.cache1.EjbCacheSFSB@1e65667
[testng-all] Bean 7 served by EJB ejb.cache1.EjbCacheSFSB@1ce9aa3
[testng-all] Bean 8 served by EJB ejb.cache1.EjbCacheSFSB@e48504
[testng-all] Bean 9 served by EJB ejb.cache1.EjbCacheSFSB@3ec646
[testng-all] Bean 10 served by EJB ejb.cache1.EjbCacheSFSB@677aca
[testng-all] Bean 11 served by EJB ejb.cache1.EjbCacheSFSB@189136d
[testng-all] done
[testng-all] Check that the bean which was passivated is the expected one
[testng-all] Bean 0 passivate count = 0
[testng-all] Bean 1 passivate count = 1
[testng-all] Bean 2 passivate count = 1
[testng-all] Bean 3 passivate count = 1
[testng-all] Bean 4 passivate count = 1
[testng-all] Bean 5 passivate count = 1
[testng-all] Bean 6 passivate count = 1
[testng-all] Bean 7 passivate count = 1
[testng-all] Bean 8 passivate count = 1
[testng-all] Bean 9 passivate count = 1
[testng-all] Bean 10 passivate count = 0
[testng-all] TEST_FAILED : FIFO bean was not passivated!
[testng-all] TEST_ENDED
[testng-all] Test case ended. Cleaning up ...



 Comments   
Comment by Mahesh Kannan [ 16/Dec/10 ]

This could be a bug in the FIFOCache that extends LRUCache. However, this issue doesn't cause any perf regressions or CTS failures. But will look into the issue once we finish the 3.1 issues





[GLASSFISH-12988] Guidance on Standalone EJB Server Created: 15/Aug/10  Updated: 08/Mar/12

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: v3.0.1
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: glassfisher Assignee: Sanjeeb Sahoo
Resolution: Unresolved 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,988

 Description   

Standalone EJB Server would be beneficial to host application entirely
consituted by EJBs. Some JEE AS providers already have this capacity.

Since GlassFish server is OSGi ready,
option 1) GlassFish can supply with the guidance on how to utilize subset of
GlassFish server modules for creation of standalone EJB server - What OSGi
bundles should remain but others be waived dynamically.
option 2) GlassFish can purposefully add a subcommand to asadmin utility for
dynamic creation of standalone EJB server.
option 3) GlassFish can be chosen to create static standalone EJB Server during
installation.

Origin: http://forums.java.net/jive/message.jspa?messageID=480097#480097



 Comments   
Comment by glassfisher [ 16/Aug/10 ]

option 4) GlassFish can be packed as neo GlassFish EJB Profile for distribution.

Comment by marina vatkina [ 16/Aug/10 ]

-> Sahoo

Comment by Sanjeeb Sahoo [ 16/Aug/10 ]

Marina,

OSGi-JavaEE is not the appropriate subcat for this RFE. I am happy to extend my
support for implementation of this feature. The first and foremost requirement
for addressing this RFE is to identify the set of bundles necessary for EJB
container to run. That is something EJB team has to come up with. My guess is
the set should contain nucleus + common javaee bundles + ejb-container
dependencies. To try out, keep these bundles in modules, delete everything else
and start server.

Sahoo

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-10109] EJB Session Store Statistics are not exposed Created: 08/Oct/09  Updated: 30/Oct/12

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: v2.1.2
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: marina vatkina Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://docs.oracle.com/cd/E19316-01/820-4335/6nfqc3qpp/index.html#gelnw


Issuezilla Id: 10,109
Status Whiteboard:

v3_exclude, 3.1-exclude

Tags: 3_1-exclude

 Description   

MonitoringRegistryMediator has this line since 9.0:

//FIXME: registry.registerStatefulSessionStoreStats(statsImpl);



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

v3_exclude

Comment by marina vatkina [ 02/Nov/09 ]
      • Issue 10751 has been marked as a duplicate of this issue. ***




[GLASSFISH-9950] EJB-5-5 Embedded EJB Container: need to find available ports for remote EJBs and JMS Created: 02/Oct/09  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: V3
Fix Version/s: 4.1.1

Type: Improvement Priority: Major
Reporter: marina vatkina Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issue Links:
Dependency
blocks GLASSFISH-12202 EJB-5 Full EJB 3.1 API support in Emb... Open
Issuezilla Id: 9,950

 Description   

Remote EJBs and JMS have port conflicts in embedded mode if GF instance is running



 Comments   
Comment by ksak [ 23/Oct/09 ]
      • Issue 10527 has been marked as a duplicate of this issue. ***
Comment by marina vatkina [ 26/Oct/09 ]

rfe





[GLASSFISH-9801] Monitoring: Type attribute required for v3 runtime components Created: 28/Sep/09  Updated: 04/Jan/13

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: V3
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: rajeshwar Assignee: marina vatkina
Resolution: Unresolved 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,801
Status Whiteboard:

v3_exclude, 3.1-exclude

Tags: 3_1-exclude, 3_1_2-exclude

 Description   

In case of v3 runtime tree, there is no way to distinguish between different
components such as modules, beans. We need to provide type attributes for nodes
representing such components. Here is the list of components, the nodes of which
requires type attribute-

Module Node
Type:
Ejb Module
Standalone Ejb Module
Web Module
Standalone Web Module

Bean Node
Type:
Stateful Session Bean
Stateless Session Bean
Entity Bean
Message Driven Bean



 Comments   
Comment by rajeshwar [ 28/Sep/09 ]
      • Issue 8837 has been marked as a duplicate of this issue. ***
Comment by abbagani [ 28/Sep/09 ]

We will need the type attribute at the ejb module level and also at the bean
level. Transferring the bug to Marina.

Comment by Nazrul [ 28/Sep/09 ]

...

Comment by marina vatkina [ 29/Sep/09 ]

Need an API to use, but I can only set the bean node type, not the module type.

Comment by abbagani [ 01/Oct/09 ]

We will need the type attribute under ejb-module and bean level.

Module level
============
ear

RosterApp/RosterAppEJB\.jar/LeagueEJB/bean-methods/getCitiesOfThisLeague

We will need to define a new StatsProvider with just one attribute
(module-type). You could do this as an inner class (Would it be in
MonitoringRegistryMediator?). In the above case, we will need this attribute
under 'RosterAppEjb\.jar'. The type would say, if it is a 'standalone ejb' or an
'ejb'. Pick the constants that Deployment or ejb-container might already be using.

standalone module (jar)
------------------------------

RosterAppEJB\.jar/LeagueEJB/bean-methods/getCitiesOfThisLeague

Same as in ear. Need a type attribute under 'RosterAppEjb\.jar'

Bean level
========

RosterAppEJB\.jar/LeagueEJB/bean-methods/getCitiesOfThisLeague

We will need an attribute called type (bean-type). This should be easy, since
you already have a StatsProvider for a bean which has some existing attributes.
The bean-type should say what type of bean it is.

I think it should be in EJBStatsProvider (define type as new attribute and set
the type value when you are instantiating one of the derived classes).

Comment by marina vatkina [ 05/Oct/09 ]

monitoring is p3

Comment by marina vatkina [ 10/Nov/09 ]

-> 3.1





[GLASSFISH-15144] <post-construct> in web.xml doesn't apply to EJB classes Created: 13/Dec/10  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: V3
Fix Version/s: 4.1.1

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

Tags: 3_1-exclude

 Description   

If I add a <post-construct> entry to web.xml, it doesn't apply to any EJB classes in the war file.

Currently, all post-construct (and pre-destroy) information for an EJB is stored in the
EJBDescriptor. Because of this, these entries in web.xml aren't visible.

Storing the post-construct information in the WebBundleDescriptor caused other failures.
If a superclass and EJB subclass both have the same @PostConstruct method, it was being
called twice. It wasn't properly computing the visibility of methods and which apply;
that seems to only be done in ComponentDefinition when processing EJB annotations. I wasn't
able to figure out exactly why it was going wrong in this case, so the post-construct
information was left at the EJBDescriptor level until this could be fixed. The consequence
of that is this bug.



 Comments   
Comment by marina vatkina [ 20/Dec/10 ]

Not enough time to address it in 3.1





[GLASSFISH-4292] Support for idempotent methods Created: 28/Feb/08  Updated: 15/Apr/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: V3
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: Mahesh Kannan Assignee: Mahesh Kannan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,292
Status Whiteboard:

v3-prd-item


 Description   

This will allow ORB to retry invocations of idempotent methods



 Comments   
Comment by Mahesh Kannan [ 28/Feb/08 ]

Ref: EJB-07

Comment by ksak [ 28/Jan/09 ]

Taking ownership of Mahesh's bugs

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-7138] EJB-7 ThreadPool for TimerService & Async methods Created: 04/Feb/09  Updated: 15/Feb/13

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 9.1peur2
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: dobes Assignee: marina vatkina
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 7,138

 Description   

When scheduling a Timer, it would be ideal if I could specify, one way or
another, which ThreadPool the timer would run in.

This would allow me to schedule many timers without worrying that there could
be 200 timers firing simultaneously, all contending for locks, sockets, memory,
and other resources that could best be used elsewhere given that most of the
timers will contend for the same lock and just block waiting for each other
anyway (in my case).

Ideally this would not be specified on a per-timer or, if that is not possible,
a per-bean basis.



 Comments   
Comment by marina vatkina [ 09/Jun/10 ]

Async methods are also requested

Comment by marina vatkina [ 09/Jun/10 ]
      • Issue 11393 has been marked as a duplicate of this issue. ***
Comment by marina vatkina [ 07/Sep/10 ]

More work than expected

Comment by Cheng Fang [ 15/Nov/11 ]

A related issue http://java.net/jira/browse/GLASSFISH-16735 has been fixed in 3.1.2 and 4.0 to make ejb default thread pool configurable.

More work is needed to support assigning specific thread pool to a bean, or its timeout method.

Comment by Tom Mueller [ 15/Feb/13 ]

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





[GLASSFISH-14812] ThreadContextClassloader should be adjusted in a single location Created: 19/Nov/10  Updated: 05/Oct/11

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: marina vatkina Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 14,812
Tags: 3_1-exclude

 Description   

It is currently all over the place in the ejb-container code



 Comments   
Comment by marina vatkina [ 19/Nov/10 ]

Not for 3.1

Comment by Cheng Fang [ 05/Oct/11 ]

Related issue: http://java.net/jira/browse/GLASSFISH-1830 (Fix ContextClassLoader handling)





[GLASSFISH-14768] Config to disable automatic timer migration on instance stop/crash Created: 17/Nov/10  Updated: 13/Dec/10

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: mzh777 Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Linux


Issuezilla Id: 14,768

 Description   

Right now, there is no configuration to disable automatic timer migration on
instance stop if GMS is enabled. It would be nice to have that feature so that
user can have choice of using automatic migration of timer or migrate-timers CLI.






[GLASSFISH-11529] [spec request] The global jndi namespace should not contain local session beans if interapplication calls are not supported. Created: 06/Feb/10  Updated: 29/Sep/10

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: V3
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: chasetec Assignee: marina vatkina
Resolution: Unresolved 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,529

 Description   

This is kind of a follow up to a bug where I was asking for default JNDI names
before EJB 3.1 (https://glassfish.dev.java.net/issues/show_bug.cgi?id=577).

I love the new default JNDI names and I think the different namespaces
(global,app,module) where a great idea however I have one complaint.

The specs don't require support for inter-application calls on local session
beans. Even though some app servers allow it I'm fine with GlassFish not
allowing it. However I think it unnecessary and confusing to publish global JNDI
names for local session beans that can't be called.

I'd like to see the spec and GlassFish only require the creation of global JNDI
names for EJBs that support inter-application calling.



 Comments   
Comment by chasetec [ 06/Feb/10 ]

To clarify "I'd like to see the spec and GlassFish only require the creation of
global JNDI names for EJBs that support inter-application calling."

I mean just the global namespace. There should still be standard jndi names for
local session beans in the app and module namespaces.

Comment by marina vatkina [ 29/Sep/10 ]

The current spec says this: "The container registers a separate JNDI name entry
for each local business interface, each remote business interface, and any
no-interface view, 2.x local home interface, and 2.x remote home interface."





[GLASSFISH-13873] If TS resource had been changed, tables are not created after server restart Created: 07/Oct/10  Updated: 15/Apr/11

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: easarina Assignee: marina vatkina
Resolution: Unresolved 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     File timersession.ear    
Issuezilla Id: 13,873
Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

Build 23 10/07. Solaris 10 Sparc. Installed thid build on one machine. Created a
cluster with two instances. Then started a cluster. After that executed:
#!/usr/bin/perl
require "./conf.pl";

$out=`$S1AS_HOME/bin/asadmin start-database`;
print $out;
$out=`$S1AS_HOME/bin/asadmin stop-cluster c1`;
print $out;
$out=`$S1AS_HOME/bin/asadmin set
configs.config.c1-config.ejb-container.ejb-timer-service.timer-datasource=jdbc/__default`;
print $out;
$out=`$S1AS_HOME/bin/asadmin create-resource-ref --target c1 jdbc/__default`;
print $out;
$out=`$S1AS_HOME/bin/asadmin start-cluster c1`;
print $out;
$out=`$S1AS_HOME/bin/asadmin list-instances`;
print $out;
$out=`$S1AS_HOME/bin/asadmin deploy --target c1 --retrieve . ./timersession.ear`;
print $out;
$out=`$S1AS_HOME/bin/appclient -targetserver localhost:13700 -client
./timersessionClient.jar`;
print $out;
================================================================

The appclient was executed successfully.

Then I've reinstalled everything and executed such sequence of the commands:
===================================================
#!/usr/bin/perl
require "./conf.pl";

$out=`$S1AS_HOME/bin/asadmin start-database`;
print $out;
$out=`$S1AS_HOME/bin/asadmin deploy --target c1 --retrieve . ./timersession.ear`;
print $out;
$out=`$S1AS_HOME/bin/appclient -targetserver localhost:13700 -client
./timersessionClient.jar`;
print $out;
$out=`$S1AS_HOME/bin/asadmin undeploy --target c1 timersession`;
print $out;
$out=`$S1AS_HOME/bin/asadmin stop-cluster c1`;
print $out;
$out=`$S1AS_HOME/bin/asadmin set
configs.config.c1-config.ejb-container.ejb-timer-service.timer-datasource=jdbc/__default`;
print $out;
$out=`$S1AS_HOME/bin/asadmin create-resource-ref --target c1 jdbc/__default`;
print $out;
$out=`$S1AS_HOME/bin/asadmin start-cluster c1`;
print $out;
$out=`$S1AS_HOME/bin/asadmin list-instances`;
print $out;
$out=`$S1AS_HOME/bin/asadmin deploy --target c1 --retrieve . ./timersession.ear`;
print $out;
$out=`$S1AS_HOME/bin/appclient -targetserver localhost:13700 -client
./timersessionClient.jar`;
print $out;
================================================

In this case not only seconf execution of the appclient totally failed, but also
second deployment failed.

I believe, if once TS did not start successfully and it is not running, then
during next invoke, has be to cleaned everything and TS should be started again.
I've restarted cluster, db, domain, tried to undeploy an app and deploy it
again, but it did not help. So only a full uninstall helps to clean everything.
I've attached timersession.ear and in1 server.log.



 Comments   
Comment by easarina [ 07/Oct/10 ]

Created an attachment (id=5096)
timersession.ear

Comment by easarina [ 07/Oct/10 ]

Created an attachment (id=5097)
in1 server.log

Comment by marina vatkina [ 07/Oct/10 ]

As this would be something we didn't provide before, making it an RFE for the
next release.

Comment by easarina [ 07/Oct/10 ]

I believe, that for this release has to be provided at least a work around. I.e.
if first time TS did not start, how to clean everything and make it start next
time without reinstalling the glassfish.

Comment by marina vatkina [ 07/Oct/10 ]

You need to restart the DAS as well

Comment by easarina [ 07/Oct/10 ]

As I've wrote I've restarted DAS, cluster, DB. But it did not help.

Comment by marina vatkina [ 08/Oct/10 ]

This is what's going on:

The 1st time you started, TS was (absolutely fine) deployed to jdbc/__TimerPool,
so after restart, even though the code figured out that it's a different
resource, the file marker left behind said it's a load, not a deploy.

May be the file should contain the last (all?) resources TS was deployed to...

Comment by easarina [ 08/Oct/10 ]

When was added glassfish3/glassfish/domains/domain1/generated/ejb-timer-service-
app, the second deployment/appclient execution were OK. I.e. such sequence of
commands worked:
===================================================
#!/usr/bin/perl
require "./conf.pl";

$out=`$S1AS_HOME/bin/asadmin start-database`;
print $out;
$out=`$S1AS_HOME/bin/asadmin deploy --target c1 --retrieve .
./timersession.ear`;
print $out;
$out=`$S1AS_HOME/bin/appclient -targetserver localhost:13700 -client
./timersessionClient.jar`;
print $out;
$out=`$S1AS_HOME/bin/asadmin undeploy --target c1 timersession`;
print $out;
$out=`rm -rf $S1AS_HOME/domains/domain1/generated/ejb-timer-service-app`;
print $out;
$out=`$S1AS_HOME/bin/asadmin stop-cluster c1`;
print $out;
$out=`$S1AS_HOME/bin/asadmin stop-domain`;
print $out;
$out=`$S1AS_HOME/bin/asadmin start-domain`;
print $out;
$out=`$S1AS_HOME/bin/asadmin set
configs.config.c1-config.ejb-container.ejb-timer-service.timer-
datasource=jdbc/__default`;
print $out;
$out=`$S1AS_HOME/bin/asadmin create-resource-ref --target c1 jdbc/__default`;
print $out;
$out=`$S1AS_HOME/bin/asadmin start-cluster c1`;
print $out;
$out=`$S1AS_HOME/bin/asadmin list-instances`;
print $out;
$out=`$S1AS_HOME/bin/asadmin deploy --target c1 --retrieve .
./timersession.ear`;
print $out;
$out=`$S1AS_HOME/bin/appclient -targetserver localhost:13700 -client
./timersessionClient.jar`;
print $out;
========================================================

But it doesn't work without stop-domain/start-domain.

I believe this sequence of the commands has to work without a domain restating.

Comment by marina vatkina [ 17/Nov/10 ]

Let's RN for this release that if the EJB Timer resource was changed after the
EJB Timer Service was started on a previous resource, a) DAS needs to be
restarted if any automatic timers are to be deployed, and b) unless the EJB
Timer table is created manually, the marker file
glassfish3/glassfish/domains/domain1/generated/ejb-timer-service-app needs to be
removed as well.

Please reassign it back to ejb-container after it is documented

Comment by Paul Davies [ 17/Nov/10 ]

Added 3.1-release-notes keyword to ensure that this issue is documented in the
RN and reset the subcomponent and owner.

Comment by Scott Fordin [ 15/Apr/11 ]

Added issue to 3.1 Release Notes.





[GLASSFISH-13848] Provide CLI to restart timer service Created: 06/Oct/10  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: 4.1.1

Type: Improvement Priority: Major
Reporter: marina vatkina Assignee: marina vatkina
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 13,848

 Description   

This might be needed after database restart



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

Next release





[GLASSFISH-13839] ejb-container should not have hard runtime dependency on persistence Created: 06/Oct/10  Updated: 09/Dec/11

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Snjezana Sevo-Zenzerovic Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks GLASSFISH-11336 glassfish-ejb-lite has a runtime depe... Open
Issuezilla Id: 13,839
Status Whiteboard:

3.1-exclude

Tags: 3_1-exclude, 3_1_2-exclude

 Description   

Quoting parent issue 11336:

<quote>
The "glassfish-ejb-lite" IPS package contains ejb-container.jar which imports
org.glassfish.persistence.common;version="3.0"

The implementation for org.glassfish.persistence.common is part of the
glassfish-jpa package (persistence-common.jar in fact).
glassfish-jpa also drags along glassfish-jca...

ejb-container.jar should not need to import org.glassfish.persistence.common.
(glassfish-jpa should not need to be present to use glassfish-ejb-lite).
</quote>

Looking at ejb-container/pom.xml file, it seems that this is a regression which
was introduced in order to address timer upgrade issue 9645. Given that timer
support is not included in glassfish-ejb-lite package, is it possible to
refactor the fix and move this dependency into glassfish-ejb package which
contains EJB timer support modules?



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

EJB Lite is part of the Web profile which requires JPA to be supported.

EJB Timer Service is an integral part of the ejb-container, and factoring it out
would be an RFE that if needed will be addressed in a future release. But I can
mark the dependency as provided if it would solve the problem.

Comment by Snjezana Sevo-Zenzerovic [ 06/Oct/10 ]

No, marking dependency as "provided" will not resolve the issue since OSGi layer
will still complain at runtime if jpa library is not there, right?

My take would then be to postpone this issue to future release where we can
separate timer related content and get rid of this dependency and in the
meantime I will set IPS package level dependency of glassfish-ejb-lite to
glassfish-jpa to prevent runtime failure.

Comment by marina vatkina [ 06/Oct/10 ]

What goes into into glassfish-ejb package?

Comment by Snjezana Sevo-Zenzerovic [ 06/Oct/10 ]

This is the content of the latest glassfish-ejb package:

http://pkg.glassfish.org/v3/dev/windows/manifest/0/glassfish-ejb%403.1%2C0-23%3A20101005T101815Z

And, this is the content of glassfish-ejb-lite from the same build:

http://pkg.glassfish.org/v3/dev/windows/manifest/0/glassfish-ejb-lite%403.1%2C0-23%3A20101005T101514Z

Comment by marina vatkina [ 06/Oct/10 ]

Yes, it will require moving code to a separate sub-module unless packager can
pick up specific files for one package or the other.

Comment by Snjezana Sevo-Zenzerovic [ 06/Oct/10 ]

No, I most definitely need two separate jars

Anyway, I'll adjust package dependency in 3.1 and we'll revisit in 3.2





[GLASSFISH-13592] asadmin stop-local-instance does not stop instance with outstanding ejb invocation Created: 23/Sep/10  Updated: 08/Dec/10

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Stephen DiMilla Assignee: marina vatkina
Resolution: Unresolved 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 clientside_output.rtf     Text File pidmonitorscript_and_output.rtf     Text File shutdown_jstack.out    
Issue Links:
Dependency
depends on GLASSFISH-13593 Logging is terminated too early durin... Resolved
Issuezilla Id: 13,592
Status Whiteboard:

3.1-exclude

Tags: 3_1-exclude

 Description   

I have a distributed cluster (1 das and 3 instances) all on separate machines.
I deploy a ejb web app to the das and cluster. I then send post messages to the
das and each instance which initiates all the instances to start sending
messages between each other. After 15 seconds I issue a asadmin
stop-local-instance to the second instance. The command returns with the following:

Waiting for the instance to stop
..........................................................
Timed out (60 seconds) waiting for the domain to stop.
Command stop-local-instance failed.

I then issue asadmin list-instances clustername and get back:
ins01 running
ins02 not running
ins03 running

I then issue asadmin get-health clustername and get back:
ins01 started since Thu Sep 23 11:29:58 PDT 2010
ins02 started since Thu Sep 23 11:29:58 PDT 2010
ins03 started since Thu Sep 23 11:29:57 PDT 2010

After this I try to connect to the HTTP port of ins02 (using a browser) and get:
Unable able to connect.

The whole time while this situtation was going on I used a script to
monitor the pids of all the java processes on the machine for ins02 and what I
noticed was that I saw the process for the stop-local-instance start and end but
never did the appserver terminate.

Looking in the DAS server log, I was able to determine that the test running
on ins02 finished it's work and sent a message to the das indicating such.

From all this information it appears that the appserver (ins02) was partially
shutdown via the stop-local-instance but that the GMS process and the ejb
container were not stopped and continued to run leaving the appserver in a
inconsistent state.

Debugging this issue is currently blocked as a result of the limited information
contained in the server log. See dependency bug



 Comments   
Comment by Stephen DiMilla [ 23/Sep/10 ]

Created an attachment (id=4950)
scirpt to monitor pids and the output it generated during test

Comment by Stephen DiMilla [ 23/Sep/10 ]

Created an attachment (id=4951)
client side output with debug turned on for CLI commands

Comment by marina vatkina [ 23/Sep/10 ]

I've noticed that even when stop-local-instance succeeds, some mq processes are
not stopped (no JMS was used by the test app)

Comment by Joe Fialli [ 28/Sep/10 ]

Given that the test case is using stateless EJBs to send GMS messages in a heavy
load, there is a chance that GMS under a heavy load is interferring with asadmin
attempt to shutdown server. Until gf issue 13593, logging stopped at beginning
of shutdown, there is no easy way to investigate this. GMSAdapter has a app
server event listener registered. This listener handles SERVER_READY and
SERVER_SHUTDOWN. GMS leaves its group when the handler is invoked with
SERVER_SHUTDOWN. There is an info log message that would confirm if the
eventhandler is properly getting called.

Here is event handler in question from
v3/cluster/gms-adapter/GMSAdapterImpl.initializeGMS()

glassfishEventListener =
new org.glassfish.api.event.EventListener() {
@Override
public void event(Event event) {
...
if (event.is(EventTypes.SERVER_SHUTDOWN))

{ logger.log(Level.INFO, "gmsservice.server_shutdown.received", ...); gms.shutdown(GMSConstants.shutdownType.INSTANCE_SHUTDOWN); events.unregister(glassfishEventListener); }
Comment by Joe Fialli [ 04/Oct/10 ]

progress is being made on dependent issue 13593.
once that is fixed, we will be able to evaluate this issue.

Comment by Joe Fialli [ 12/Oct/10 ]

We moved group-management-service shutdown from being invoked during SERVER_SHUTDOWN to
PREPARE_SHUTDOWN, and GMS is now properly shutting down for this test case in question.

However, the test case uses a stateful EJB to run the test. One EJB invocation last for the duration of the
test (which is 4 -5 minutes typically). However, in this case, we were shutting down one of the clustered
instances in the middle of the test. I will attach complete jstack of process after asadmin stop-instance
has timed out.

Here are two thread traces relevant to application server being in a half shutdown state.
"GlassFish Shutdown Hook" prio=10 tid=0x0000000057ca0800 nid=0x647f waiting on condition
[0x00000000491cf000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)

  • parking to wait for <0x00002aaac3933e68> (a
    java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
    at
    java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchroni
    zer.java:1925)
    at com.sun.corba.ee.impl.oa.poa.POAImpl$DestroyThread.completeDestruction(POAImpl.java:735)
    at com.sun.corba.ee.impl.oa.poa.POAImpl$DestroyThread.performDestroy(POAImpl.java:702)
    at com.sun.corba.ee.impl.oa.poa.POAImpl$DestroyThread.run(POAImpl.java:604)
    at com.sun.corba.ee.impl.oa.poa.POAImpl$DestroyThread.doIt(POAImpl.java:583)
    at com.sun.corba.ee.impl.oa.poa.POAImpl.destroy(POAImpl.java:1003)
    at
    com.sun.corba.ee.impl.oa.rfm.ReferenceFactoryManagerImpl.destroy(ReferenceFactoryManagerImpl.java:
    499)
    at com.sun.corba.ee.impl.oa.rfm.ReferenceFactoryImpl.destroy(ReferenceFactoryImpl.java:66)
    at
    org.glassfish.enterprise.iiop.impl.POARemoteReferenceFactory.destroy(POARemoteReferenceFactory.java
    :555)
    at com.sun.ejb.containers.BaseContainer.doContainerCleanup(BaseContainer.java:4353)
    at com.sun.ejb.containers.BaseContainer.onShutdown(BaseContainer.java:4234)
    at org.glassfish.ejb.startup.EjbApplication.stop(EjbApplication.java:311)
    at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:169)
    at org.glassfish.internal.data.ModuleInfo.stop(ModuleInfo.java:267)
  • locked <0x00002aaabfd48378> (a org.glassfish.internal.data.ModuleInfo)
    at org.glassfish.internal.data.ApplicationInfo.stop(ApplicationInfo.java:277)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.disable(ApplicationLifecycle.java:1824)
    at
    com.sun.enterprise.v3.server.ApplicationLoaderService.stopApplication(ApplicationLoaderService.java:42
    7)
    at
    com.sun.enterprise.v3.server.ApplicationLoaderService.preDestroy(ApplicationLoaderService.java:395)
    at
    com.sun.hk2.component.AbstractWombInhabitantImpl.dispose(AbstractWombInhabitantImpl.java:74)
    at com.sun.hk2.component.SingletonInhabitant.release(SingletonInhabitant.java:78)
  • locked <0x00002aaabf553330> (a com.sun.hk2.component.SingletonInhabitant)
    at com.sun.hk2.component.EventPublishingInhabitant.release(EventPublishingInhabitant.java:105)
    at com.sun.hk2.component.LazyInhabitant.release(LazyInhabitant.java:130)
  • locked <0x00002aaabf5532e0> (a com.sun.hk2.component.LazyInhabitant)
    at com.sun.enterprise.v3.server.AppServerStartup.stop(AppServerStartup.java:401)
  • locked <0x00002aaabebe69a8> (a com.sun.enterprise.v3.server.AppServerStartup)
    at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.stop(GlassFishImpl.java:88)
  • locked <0x00002aaabebe6980> (a com.sun.enterprise.glassfish.bootstrap.GlassFishImpl)
    at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher$1.run(GlassFishMain.java:194)

"http-thread-pool-18080(2)" daemon prio=10 tid=0x00002aaae5374800 nid=0x6443 waiting on
condition [0x00000000483bf000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at com.sun.shoal.test.SendBean.sleep(SendBean.java:927)
at com.sun.shoal.test.SendBean.waitTillDone(SendBean.java:629)
at com.sun.shoal.test.SendBean.sendMessage(SendBean.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5363)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
at
com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:47)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:862)
at
com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:371)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5335)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5323)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:206)
at
com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate
.java:79)
at $Proxy163.sendMessage(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(StubInvocationHandle
rImpl.java:244)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.j
ava:155)
at
com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:229)
at
com.sun.shoal.test._SendIF_Remote_DynamicStub.sendMessage(com/sun/shoal/test/_SendIF_Remote
_DynamicStub.java)
at com.sun.shoal.test._SendIF_Wrapper.sendMessage(com/sun/shoal/test/_SendIF_Wrapper.java)
at org.apache.jsp.test_jsp._jspService(test_jsp.java from :133)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:401)
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:848)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1522)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.jav
a: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: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:619)

One could simply recreate this as an ejb unit test by creating a stateful EJB with one method
that sleeps for 10 minutes. The asadmin stop-instance while the method is still being invoked
will time out. Should a wedged EJB invocation being stopping server shutdown?

We realize that the test EJB question needs some work, but we did want to allow someone from ejb-
container to evaluate impact of pending EJB invocation on shutting down the server.

Comment by Joe Fialli [ 12/Oct/10 ]

Created an attachment (id=5131)
jstack of threads still running after asadmin stop-instance has timed out trying to stop an app server with an active EJB invocation





[GLASSFISH-12634] Make 'glassfish.embedded.tmpdir' available as a parameter to EJBContainer.createEJBContainer Created: 13/Jul/10  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: 4.1.1

Type: Improvement Priority: Major
Reporter: szczyp Assignee: marina vatkina
Resolution: Unresolved 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,634

 Description   

Currently the 'glassfish.embedded.tmpdir' setting is only used if it is a system
property. Please make it available as a parameter to
EJBContainer.createEJBContainer.
Using this settings helps keeping the workspace clean (for example, the temp dir
can be set to be within the 'target' directory within the maven build structure.
When it is required as a system property, it might come in the way for maven
surefire users as it requires to fork surefire or use an alternative command
line, which has its limitations. If this was a parameters to the mentioned
method, it would be much easier.



 Comments   
Comment by sirajg [ 13/Jul/10 ]

These properties are used by the createEJBContainer API.

Comment by szczyp [ 13/Jul/10 ]

When I am in the main Gf 3.1 build 09 directory and issue a command:
grep -R 'glassfish.embedded.tmpdir' *
to recursively search for any use of the property, the only thing that is found is:
common/glassfish-api/src/main/java/org/glassfish/api/embedded/Server.java:
String tmpDir = System.getProperty("glassfish.embedded.tmpdir");

I also tested this before I came up with this simple test, and it didn't work.

Comment by szczyp [ 14/Jul/10 ]

Please go to https://glassfish.dev.java.net/issues/show_bug.cgi?id=12658,
download the attachment and run it (it will fail).
It tries to set the tmpdir property to the EJBContainer.createEJBContainer, and
if you debug and stop in the middle, you will note that the property is not
used. If it is set on the cmdline in surefire, it works fine.
I also try to use another property
(org.glassfish.ejb.embedded.keep-temporary-files) which I found in
EJBContainerProviderImpl, but it also seems not to work, or I don't know how to
use it. It is package private so it might mean I am not supposed to use it at
all. My test with the 'grep' tool also shows that it is only used as a system
property.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-12633] EJBContainerProviderImpl ignores classpath entries when they are EJB modules but not specified using EJBContainer.MODULES Created: 13/Jul/10  Updated: 05/Oct/10

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: szczyp Assignee: marina vatkina
Resolution: Unresolved 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,633

 Description   

I am using GF 3.1 build 9.
The faulty code is (EJBContainerProviderImpl.getRequestedEJBModuleOrLibrary,
lines 281 - 285):

DeploymentElement result = null;
...
if (!isEJBModule || moduleNames.isEmpty() || moduleNames.contains(moduleName)) {
result = new DeploymentElement(file, isEJBModule);
}

return result;

The use case: the container is started and the EJB modules are specified:
return EJBContainer.createEJBContainer(parameters);
where parameters contains a mapping EJBContainer.MODULES -> "ejbmodules".

Still, every classpath entry is checked whether it is an EJB module or WAR or
simple lib (EJBContainerProviderImpl.getRequestedEJBModuleOrLibrary method) - I
don't think this should happen, it should first check if the classpath entry is
listed in MODULES. But that's not the real problem.

The problem is that some classpath entries can be discivered as EJB modeles, and
not listed in MODULES, so they should be probably treated as plain library
entries. However, the code quoted above fails to do so - in the described test
case, the 'if' will never return true - isEJBModule is true, so it will go on to
the last condition, which checks whether the name is within the required modules

  • and the DeploymentElement will remain null, effectively making the whole
    classpath entry excluded from deployment.

If I use a library that has an EJB for some reason, the described behaviour will
simply ignore it and the application will blow up in runtime.

I think the check whether an EJB module is listed using MODULES should be done
earlier, as if it is not listed, it doesn't really matter if there are EJBs or
not, it should be a plain library entry. If however, for some reason, the name
check is to stay as it is, the quoted 'if' should be changed, something like:

if (isEJBModule && !moduleNames.contains(moduleName)) {
isEJBModule = false; // treat entry as plain library
}
if (!isEJBModule || moduleNames.isEmpty() || moduleNames.contains(moduleName)) {
result = new DeploymentElement(file, isEJBModule);
}

or

if (!isEJBModule || moduleNames.isEmpty() || moduleNames.contains(moduleName)) {
result = new DeploymentElement(file, isEJBModule);
} else if (isEJBModule && !moduleNames.contains(moduleName)) {
result = new DeploymentElement(file, false); // treat the entry as library
}



 Comments   
Comment by sirajg [ 13/Jul/10 ]

transfer

Comment by marina vatkina [ 15/Jul/10 ]

EJB module can't become a library if EJBContainer.MODULES is not empty. But we
can look at introducing a special setting for that.

Comment by szczyp [ 19/Jul/10 ]

Why can it not? If it is not listed in modules, it is not an EJB module and
should not be treated as such. And on no account must it be ignored as it is now.

Sometimes you will not know that a third party library is an EJB jar, and then
suddenly you will get ClassNotFoundExceptions, and will start scratching your
head, as the classes are there on the classpath.

What is wrong with the code sample I included? It seemed to work for me, and you
probably have unit tests to check if this is valid?

Comment by marina vatkina [ 19/Jul/10 ]

Deployment doesn't distinguish between a library and a Java EE module. So if it
contains EJB annotation, it's an EJB module. Does it work differently for you
when you package and deploy your aplication to a regular GF instance?

Comment by szczyp [ 20/Jul/10 ]

I tested this and what I see is that if a lib jar is has an EJB that is not
included in MODULES it is not deployed as one (DeploymentResult returns null).
However, it is on the classpath. Does this mean that for an EJB module that is
in listed in MODULES, it is both included in classpath and deployed, effectively
being on the classpath twice?

"Deployment doesn't distinguish between a library and a Java EE module. So if it
contains EJB annotation, it's an EJB module. Does it work differently for you
when you package and deploy your aplication to a regular GF instance?"
But I think this is against the specs, which says that if MODULES is included,
it specifies EJB modules. When MODULES is specified, GF includes the modules,
and also scans the classpath as if MODULES was not specified. Is this correct in
terms of the specs?





[GLASSFISH-5127] stateful session beans not getting passivated Created: 10/Jun/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: rajbirb Assignee: Mahesh Kannan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Archive File Client.jar     Zip Archive Client_src.zip     Java Archive File statefulPassivation.jar     Zip Archive statefulPassivation_src.zip    
Issuezilla Id: 5,127

 Description   

Stateful session beans are not getting passivated. The bean's cache size is set
to be 1(one) in sun-ejb-jar.xml. The bean is looked up twice from a java client
and some business method invoked on it. Monitoring the application server
through console, it can be seen that the 'NumBeansInCache' keeps on increasing
on each re-run of the client. Also 'NumPassivationSuccess' is always 0(zero).

Also tried configuring the EJB container to set the 'Maximum Pool Size' and
'Maximum Pool Size' equal to 1. But the result is same.

Steps to recreate:
1. Deploy statefulPassivation.jar on the server
2. Enable monitoring for EJB Container
3. Run java -jar Client.jar with system property set for
'java.naming.factory.initial'

Check value of 'NumBeansInCache' in application server monitor and also no SOPs
given in prePassivate and postActivate callbacks appearing in logs.



 Comments   
Comment by rajbirb [ 10/Jun/08 ]

Created an attachment (id=1546)
test ejb application

Comment by rajbirb [ 10/Jun/08 ]

Created an attachment (id=1547)
sources for test ejb application

Comment by rajbirb [ 10/Jun/08 ]

Created an attachment (id=1548)
client for the test application

Comment by rajbirb [ 10/Jun/08 ]

Created an attachment (id=1549)
client sources

Comment by Mahesh Kannan [ 05/Jan/09 ]

For performance reasons the container passivates beans only if the number of
beans to be passivated is more than 8. The number 8 has was decided purely based
on performance benchmarks that were done with earlier releases.

In this case, there is only one bean that needs to be passivated and hence the
container didn't call ejbPassivate.

Also, the tunnings (max-cache-size etc.) are mainly used to controll the beans
under heavy loads.

This is not a bug at all. I am moving this as an enhancement and also reducing
the priority.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-5068] Covariant return type don't work in EJB 2.1 compatibility view Created: 27/May/08  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 9.1peur1
Fix Version/s: 4.1.1

Type: Improvement Priority: Major
Reporter: mkarg Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 5,068

 Description   

Java SE 5 has the nice feature of covariant return types. The idea is to narrow
down the actual return type of a method that was defined too wide by the super
class.

If a session bean provides an EJB 2.1 compatibility view, it is in theory
possible to inherit the EJB 2.1 compatibility home interface from a super
interface, which in turn extends EJBHome.

Imagine the case that the super interface defines the necessary create method in
this way:

public SuperRemote create() throws CreateException, RemoteException;

and the sub class re-defines it using a covariant return type:

public CovariantRemote create() throws CreateException, RemoteException;

where CovariantRemote extends SuperRemote, and SuperRemote extends EJBObject.

From the logical aspect, this should work. Also I do not see that the spec would
prohibit that.

The compiler doesn't complaint.

The verifier.bat doesn't complaint about it (0 Failures, 0 Warning, 0 Errors).

But: When deploying on GlassFish, you will find a lot of exceptions in the log
and the application is NOT loaded.

I think that is a bug and since I need covariant return types, for me it is a
showstopper.

Here is the problem from the log:

UnExpected error occured while creating ejb container
java.lang.IllegalStateException: Error : methods public abstract
de.quipsy.sessions.folder.FolderRemote
de.quipsy.sessions.folder.FolderHome.create() throws
javax.ejb.CreateException,java.rmi.RemoteException and public abstract
de.quipsy.sessions.contactpersonmanager.ContactPersonManagerRemote
de.quipsy.sessions.contactpersonmanager.ContactPersonManagerHome.create() throws
java.rmi.RemoteException,javax.ejb.CreateException both result in IDL name
'create__' at
com.sun.corba.ee.impl.presentation.rmi.IDLNameTranslatorImpl.buildNameTranslation(IDLNameTranslatorImpl.java:407)
at
com.sun.corba.ee.impl.presentation.rmi.IDLNameTranslatorImpl.<init>(IDLNameTranslatorImpl.java:221)
at
com.sun.corba.ee.impl.presentation.rmi.IDLNameTranslatorImpl.get(IDLNameTranslatorImpl.java:169)
at
com.sun.corba.ee.impl.presentation.rmi.PresentationManagerImpl$ClassDataImpl.<init>(PresentationManagerImpl.java:153)
at
com.sun.corba.ee.impl.presentation.rmi.PresentationManagerImpl.getClassData(PresentationManagerImpl.java:125)
at
com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.setTarget(ReflectiveTie.java:97)
at
com.sun.enterprise.iiop.POAProtocolMgr.validateTargetObjectInterfaces(POAProtocolMgr.java:198)
at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:916)
at
com.sun.ejb.containers.StatelessSessionContainer.initializeHome(StatelessSessionContainer.java:232)
at
com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:654)
at com.sun.enterprise.server.AbstractLoader.loadEjbs(AbstractLoader.java:536) at
com.sun.enterprise.server.ApplicationLoader.doLoad(ApplicationLoader.java:188)
at
com.sun.enterprise.server.TomcatApplicationLoader.doLoad(TomcatApplicationLoader.java:126)
at com.sun.enterprise.server.AbstractLoader.load(AbstractLoader.java:244) at
com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:336)
at
com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:210)
at
com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:645)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.invokeApplicationDeployEventListener(AdminEventMulticaster.java:928)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.handleApplicationDeployEvent(AdminEventMulticaster.java:912)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.processEvent(AdminEventMulticaster.java:461)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.multicastEvent(AdminEventMulticaster.java:176)
at
com.sun.enterprise.admin.server.core.DeploymentNotificationHelper.multicastEvent(DeploymentNotificationHelper.java:308)
at
com.sun.enterprise.deployment.phasing.DeploymentServiceUtils.multicastEvent(DeploymentServiceUtils.java:226)
at
com.sun.enterprise.deployment.phasing.ServerDeploymentTarget.sendStartEvent(ServerDeploymentTarget.java:298)
at
com.sun.enterprise.deployment.phasing.ApplicationStartPhase.runPhase(ApplicationStartPhase.java:132)
at
com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:108)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:919)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.start(PEDeploymentService.java:591)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.start(PEDeploymentService.java:635)
at
com.sun.enterprise.admin.mbeans.ApplicationsConfigMBean.start(ApplicationsConfigMBean.java:744)
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.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:375)
at
com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:358)
at
com.sun.enterprise.admin.config.BaseConfigMBean.invoke(BaseConfigMBean.java:464)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) at
sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597) at
com.sun.enterprise.admin.util.proxy.ProxyClass.invoke(ProxyClass.java:90) at
$Proxy1.invoke(Unknown Source) at
com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.invoke(SunoneInterceptor.java:304)
at
com.sun.enterprise.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:174)
at
com.sun.enterprise.deployment.client.DeploymentClientUtils.startApplication(DeploymentClientUtils.java:145)
at com.sun.enterprise.deployment.client.DeployAction.run(DeployAction.java:537)
at java.lang.Thread.run(Thread.java:619)



 Comments   
Comment by marina vatkina [ 27/May/08 ]

Making it a regular RFE according to the comment from Ken:
It's not required by the spec. The EJB 2.x view requirements were written
before support for covariant return types was added to Java SE 5.0. It's
something that would need to be explicitly added as a requirement to the EJB 3.1
spec. That's unlikely for the EJB 2.x view since that's essentially frozen.
It's a possibility for the EJB 3.x view.

Comment by mkarg [ 28/May/08 ]
      • Issue 5068 has been confirmed by votes. ***
Comment by mkarg [ 28/May/08 ]

I do not share that it is not a bug but a RFE.

The compiler allows it, also the verifier allows it. Also the server doesn't
show an error message, only a warning.

It is possible to do it in GlassFish right now, so it should work, or GlassFish
should give an error message explaining a good reason why it is not working.

I do not see the reason right now. If I see it correctly the only problem is
that the method name is not unique. So just make it unique and it will work.

The spec says that Java SE 5 is to be supported. It does not explicitely exclude
EJB 2.1 Compatibility Views. If there would be such an exclusion, the spec must
explicitely tell that for EJB 2.1 Compatibility Views only Java SE 4 is to be
supported, but not 5. Unless such an exclusion is found in the spec, it has to work.

Comment by marina vatkina [ 17/Mar/11 ]

Cheng, you were looking at similar issues...

Comment by mkarg [ 07/Jul/11 ]

V3.1 is out since months and still covariant return types are not working. Still for me this is nothing else but a BUG and should get fixed ASAP. It times of Java SE 6u26 and Java EE 6 it is just ridiculous and a shame for GFv3 that a language feature (not even a EE feature!) is not supported and leads to an error message!

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Comment by Tom Mueller [ 15/Feb/13 ]

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





[GLASSFISH-5056] Client side Callback mechanism between EJB and Clients - Swing, HTTP, WebServices Created: 22/May/08  Updated: 08/Mar/12

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 9.1peur2
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: miro Assignee: Mahesh Kannan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 5,056

 Description   

It is very important for most of the applications to have mechanism with which
the server side (EJB) to be able to notify the client for some specific events.
This is not acceptable in most of the cases to be used JMS because such events
are session specific and depends from the current business logic. For example if
we have a product assembler algorithm which works on the server side and during
the assemble process the algorithm must ask the client (JWS/JNLP Swing, HTTP,
WebServices) to clarify something then this callback is very important. In that
case some Dialog will be shown and the user must enter some data or to make some
choice.
I try to do that with JMS but this is impossible I think because JMS distribute
to many recipients by topic/queue, not by current session.



 Comments   
Comment by marina vatkina [ 27/May/08 ]

We can increase the priority if there are more requests.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4386] Request prioritization in application server Created: 05/Mar/08  Updated: 25/Nov/10

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: V3
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: Sanjeeb Sahoo Assignee: ksak
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks GLASSFISH-4147 Request prioritization in application... Open
Issuezilla Id: 4,386
Status Whiteboard:

v3-prd-item


 Description   

This feature request is part of the bigger feature specified in rfe #4147. More
details to follow.



 Comments   
Comment by Sanjeeb Sahoo [ 05/Mar/08 ]

Fixed status white board.

Comment by ksak [ 28/Jan/09 ]

Taking ownership of Mahesh's bugs





[GLASSFISH-4630] Bean cache load factor interferring with expectations Created: 06/Apr/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 9.1peur1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: dinglemouse Assignee: Mahesh Kannan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 4,630

 Description   

From what I can understand of the source code the determination of a SFSB cache
overflow takes into account some "threshold" or load factor ratio of the
maxCacheSize.

The effect of this is that when I set a max-cache-size default of 512 in
practice the container only seems to be caching something like 483 of my SFSBs!
It is not-intuitive. I expected the cache would be able to be 100% full before
overflowing.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4628] Inconsistent bean cache/pool attribute defaults Created: 06/Apr/08  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 9.1peur1
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: dinglemouse Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 4,628

 Description   

There seem to be ejb-container and mdb-container attribute default
inconsistencies between the documentation and the admin GUI for the following:

1. ejb-container
steady-pool-size: 32/0
pool-resize-quantity: 16/8
max-pool-size: 64/32

2. mdb-container
steady-pool-size: 10/0
pool-resize-quantity: 2/8
max-pool-size: 60/32

Furthermore, the MDB source code at
appserv-core\src\java\com\sun\ejb\containers\MessageBeanContainer.java has coded
defaults which are also different again in some cases:

private static final int DEFAULT_RESIZE_QUANTITY = 1;
private static final int DEFAULT_STEADY_SIZE = 10;
private static final int DEFAULT_MAX_POOL_SIZE = 60;
private static final int DEFAULT_IDLE_TIMEOUT = 600;
private static final int MIN_IDLE_TIMEOUT = 1;



 Comments   
Comment by dinglemouse [ 06/Apr/08 ]

Sorry - should have said 9.1 ur1

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by ksak [ 28/Jan/09 ]

Reassigning bugs from Mahesh

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Comment by marina vatkina [ 08/Mar/12 ]

Let's verify this





[GLASSFISH-14394] Enable EJB Timer Service to start/stop when its resource is enabled/disabled Created: 03/Nov/10  Updated: 13/Dec/10

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: marina vatkina Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 14,394

 Description   

See issues 1132, 13848, and 13127

To avoid some of the problems EJB Timer Service should subscribe to its resource
config changes for enabled=false/true using ConfigListener mechanism.






[GLASSFISH-15394] Embedded EJB Container should modify only config that is being used (server by default) Created: 30/Dec/10  Updated: 19/Dec/16

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1_dev
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: marina vatkina Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude

 Description   

The less we modify domain.xml, the less it's error-prone...






[GLASSFISH-931] annotations ignored on ejb3 business method with covariant return type Created: 14/Aug/06  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: V3
Fix Version/s: 4.1.1

Type: Improvement Priority: Major
Reporter: Cheng Fang Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 931

 Description   

When I use such a business method in a simple ejb3 stateless session bean, it
works fine

@Remote
public interface EchoRemote {
void echo();
void echo2();
Object getMessage();
}
------------------
@Stateless
public class EchoBean implements com.foo.ejb.EchoRemote {
...

public String getMessage()

{ //String, instead of Object, is returned return "A message from EchoBean"; }
}

When I apply a @TransactionAttribute(TransactionAttributeType.MANDATORY) on this
business method, the annotation is ignored.
@TransactionAttribute(TransactionAttributeType.MANDATORY)
public String getMessage() { //String, instead of Object, is returned return "A message from EchoBean"; }

I expect a TransactionRequiredException or the like, since my web client doesn't
start transaction, but no exception occurred. The generated ejb-jar.xml after
deployment contains no transaction attribute for any methods. So the default
REQUIRED is always used.

If I change the return type to Object, I got the expected exception.

I suspect all method-level annotation on such methods are ignored, though I
haven't tested other annotations.
This looks like a bug, unless ejb spec has special restrictions on covariant
return type.

The root cause is in
annotation-framework/src/java/com/sun/enterprise/deployment/annotation/impl/ComponentDefinition.java:
private void initializeMethods() {
for (Class cl: classes) {
for (Method method : cl.getDeclaredMethods()) {
MethodKey mk = new MethodKey(method);
if(methodMap.containsKey(mk))

{ methodMap.get(mk)); }

methodMap.put(mk, method);
}
}
}

For EchoBean.class, getDeclaredMethods() contains both Object getMessage(); and
String getMessage(). Although no order is guaranteed, the Object one happens to
be after the String one. So the Object one will always overwrite the existing
binding for the String one in methodMap, since their MethodKey are the same.
Therefore, any annotations on String getMessage() are ignored.

I don't know why here we need a custom equals method for Method. For this
particular issue, we could modify MethodKey.equals() to distinguish return type.
Another options is to check methodMap.contains(methodKey) before overwriting
any existing bindings, and choose the method with the most specific return type.

I'd suggest we add this feature. JBoss supports this or will support this.

I also noticed while debugging this, ComponentDefinition.initializeMethods() is
called twice in a row, doing exactly the same thing. May be of interest.



 Comments   
Comment by ksak [ 15/Aug/06 ]

In addition to the ComponentDefinition.initializeMethods() issue, the logic in
com.sun.enterprise.TypeUtil.sameMethodSignature() will need to be revisited. This method is called
during the processing of tx and security method annotations and is used to compare an interface method
with a method on an implementation class. In its current form, it expects return types to be exactly the
same, which will need to be relaxed in order to achieve the correct semantics.

Comment by gfbugbridge [ 10/Nov/06 ]

<BT6492478>

Comment by gfbugbridge [ 11/Nov/06 ]

<BT6492714>

Comment by Hong Zhang [ 30/Jan/07 ]

accepted

Comment by Hong Zhang [ 15/Feb/07 ]

Downgrade to P4 after discussing with cheng.

Comment by Cheng Fang [ 14/May/09 ]

This issue still exists in V3.

Comment by Hong Zhang [ 14/May/09 ]

ken: I vaguely remember you said something about covariant methods might not
make sense and you may clarify it in EJB3.1 spec?

Comment by Hong Zhang [ 22/Sep/09 ]

ken: any update on the spec w.r.t co-variant return type?

Comment by ksak [ 22/Sep/09 ]

It's not something we'll be able to address in EJB 3.1 so it will continue to be non-portable. Changing to
RFE to be considered in a future release.

Comment by ksak [ 22/Sep/09 ]

Changing ownership.

Comment by marina vatkina [ 25/Mar/11 ]

Cheng,

Check if it is already fixed...

Comment by Cheng Fang [ 26/Mar/11 ]

This problem still exists in 3.2 trunk.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Comment by Tom Mueller [ 15/Feb/13 ]

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





[GLASSFISH-19585] No explicit tests for thread safety of singleton session context Created: 25/Jan/13  Updated: 25/Jan/13

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: None
Fix Version/s: None

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


 Description   

Need to add tests that verify thread safety of all SessionContext methods when invoked from a singleton with all supported concurrency types.






[GLASSFISH-19546] TimerHandle can be passed through EJB's remote interface Created: 17/Jan/13  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: None
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: amy.yang Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

TimerHandle can be passed through EJB's remote interface, which is forbidden by EJB Spec.






[GLASSFISH-18420] EJB: Inspect JDK 7 getMethods()/getDeclaredMethods() usage Created: 28/Feb/12  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0_dev
Fix Version/s: None

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


 Description   

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

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

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

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

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

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

GlassFish Core EJB container implementation
    AbstractEjbHandler.java
    BaseContainer.java
    BeanMethodCalculatorImpl.java
    EJBHandler.java
    EjbOptionalIntfGenerator.java
    Generator.java
    HomeGenerator.java
    InitHandler.java
    Remote30WrapperGenerator.java
    RemoteGenerator.java
    ServiceInterfaceGenerator.java
    WrapperGenerator.java
    AccessTimeoutHandler.java
    AsynchronousHandler.java
    LockHandler.java
    SystemInterceptorProxy.java





[GLASSFISH-16282] Passivation batching is not predictable Created: 29/Mar/11  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: 4.1.1

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

Tags: 3_1_1-scrubbed, 3_1_2-exclude

 Description   

The batch scheduled for passivation is not closed for additions, so usually 1 or 2 extra instances are passivated instead of the batch size. To reproduce - increase the number of beans in ejb31/full/passact/client/Client.java






[GLASSFISH-17385] asadmin stop-domain does not end cleanly for MDB's Created: 06/Oct/11  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.1_dev
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: tchng Assignee: marina vatkina
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Archive File facelet.jar    
Tags: 3_1_x-exclude

 Description   

When trying to shut down glassfish using the command:

asadmin stop-domain --force=false

Looking at our logs, our Message Driven Beans will throw the following error when trying to finish processing by retrieving the messages that have been placed on the queue:

onMessage(): Failed to process JMS message.
javax.ejb.EJBException: Attempt to invoke when container is in STOPPED
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1995) [ejb-container.jar:3.1.1]
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1990) [ejb-container.jar:3.1.1]

When stopping our domain, we are unable to finish processing gracefully if this exception occurs.

Please advise.

Thanks!



 Comments   
Comment by tchng [ 06/Oct/11 ]

The feature we are looking for is:

"shutdown when work completes"

Comment by tchng [ 11/Oct/11 ]

This exception behavior still happens in Glassfish version 3.2-b06
15:20:17.360 [30b96561-d0d5-4cd8-a36d-dd8a5a610afb] [p: thread-pool-1; w: 17] ERROR c.b.z.s.w.SyncWorkflowMessageListener - onMessage(): Failed to process JMS message.
javax.ejb.EJBException: Attempt to invoke when container is in STOPPED
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1996) [ejb-container.jar:3.2-b06]
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1991) [ejb-container.jar:3.2-b06]
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:222) ~[ejb-container.jar:3.2-b06]
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88) ~[ejb-container.jar:3.2-b06]
il.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54) ~[na:na]
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163) ~[na:na]
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299) ~[na:na]

Comment by tchng [ 12/Oct/11 ]

We are able to simulate this problem beyond mdb's

Using a facelet page, that hits a JSF Managed bean which then iterates 40 times with a 1 second sleep hitting an EJB session bean, we then invoke:

asadmin stop-domain --force=false

The result of this creates the same exception:

[#|2011-10-12T14:58:09.808+0000|SEVERE|glassfish3.2|javax.enterprise.resource.webcontainer.jsf.application|_ThreadID=41;_ThreadName=Thread-2;|Error Rendering View[/index.xhtml]
javax.el.ELException: /index.xhtml: javax.ejb.EJBException: Attempt to invoke when container is in STOPPED
at com.sun.faces.facelets.compiler.TextInstruction.write(TextInstruction.java:88)
at com.sun.faces.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:82)
at com.sun.faces.facelets.compiler.UILeaf.encodeAll(UILeaf.java:183)
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:131)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:288)
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:410)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1562)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:286)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:345)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:172)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:162)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:160)
at org.glassfish.grizzly.filterchain.ExecutorResolver$3.execute(ExecutorResolver.java:95)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:444)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:364)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:290)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:133)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:76)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:63)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:823)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:116)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$000(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$1.run(WorkerThreadIOStrategy.java:98)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:508)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:488)
at java.lang.Thread.run(Thread.java:680)
Caused by: javax.ejb.EJBException: Attempt to invoke when container is in STOPPED
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1996)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1991)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:222)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy313.getCounterValue(Unknown Source)
at com.test.bean._EJB31_GeneratedCounterSessionBeanIntf__Bean_.getCounterValue(Unknown Source)
at com.test.MyJSFManagedBean.getCount(MyJSFManagedBean.java:32)
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.el.ELText$ELTextComposite.writeText(ELText.java:148)
at com.sun.faces.facelets.compiler.TextInstruction.write(TextInstruction.java:85)

It seems that the challenge is that when the web container invokes upon the ejb container while we are seeking to stop glassfish gracefully, this exception occurs which is not a graceful shut down.

The facelet skeleton project is an attachment.

Comment by tchng [ 12/Oct/11 ]

The facelet skeleton project that simulates this problem which occurs during the exection of:

asadmin stop-domain --force=false

That if a thread in the web-container is invoking something in the ejb-container in glassfish, we get the exception: javax.ejb.EJBException: Attempt to invoke when container is in STOPPED

Which when executing an mdb, the thread is expected to finish cleanly.

Comment by Satish Kumar [ 18/Nov/11 ]

Reassigning to Marina since this issue is related to the MDB container...

Comment by Cheng Fang [ 12/Dec/11 ]

A somewhat related issue is 17315 (cannot call EJB method from method sessionDestroyed (session listener) when web container wants undeploy enterprise application.), which has to do with the stop ordering between ejb container and web container.

Graceful shutdown of ejb container involves coordiation with other modules (JMS, JCA, etc). Also need to understand the level of gracefulness, e.g., do we still accept new method invocation belonging to the same txn, the same session, and shutdown timeout. Exclude it from 3.1.2 release.





[GLASSFISH-17350] NameNotFoundException thrown during undeployment of a WAR containing EJBs annotated with portable global JNDI names Created: 26/Sep/11  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.1_dev
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Vineet Reynolds Assignee: Srini
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive webejbexample.zip    
Tags: 3_1_x-exclude

 Description   

Original Java.net forum thread is http://www.java.net/forum/topic/glassfish/glassfish/namenotfoundexception-thrown-during-undeployment-war-containing-ejbs

The following exception stacktrace was produced during undeployment of a Web Archive containing EJBs with an explicit global and portable JNDI name:

[#|2011-09-26T17:39:47.229+0530|WARNING|glassfish3.1.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=20;_ThreadName=Thread-4;|WEB0610: [/WebEJBExample] failed to unbind namespace
javax.naming.NameNotFoundException: Cannot find name to unbind
at com.sun.enterprise.naming.impl.TransientContext.doUnbind(TransientContext.java:398)
at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:420)
at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:424)
at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:424)
at com.sun.enterprise.naming.impl.SerialContextProviderImpl.unbind(SerialContextProviderImpl.java:124)
at com.sun.enterprise.naming.impl.SerialContext.unbind(SerialContext.java:740)
at javax.naming.InitialContext.unbind(InitialContext.java:416)
at javax.naming.InitialContext.unbind(InitialContext.java:416)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.unpublishObject(GlassfishNamingManagerImpl.java:246)
at com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl.unbindFromComponentNamespace(ComponentEnvManagerImpl.java:355)
at com.sun.enterprise.web.WebModuleContextConfig.unbindFromComponentNamespace(WebModuleContextConfig.java:454)
at com.sun.enterprise.web.WebModuleContextConfig.stop(WebModuleContextConfig.java:447)
at com.sun.enterprise.web.WebModuleContextConfig.lifecycleEvent(WebModuleContextConfig.java:174)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:149)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:5603)
at com.sun.enterprise.web.WebModule.stop(WebModule.java:527)
at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1049)
at com.sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java:2211)
at com.sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java:2166)
at com.sun.enterprise.web.WebApplication.stop(WebApplication.java:159)
at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:169)
at org.glassfish.internal.data.ModuleInfo.stop(ModuleInfo.java:302)
at org.glassfish.internal.data.ApplicationInfo.stop(ApplicationInfo.java:322)
at com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:999)
at com.sun.enterprise.v3.server.ApplicationLifecycle.undeploy(ApplicationLifecycle.java:1025)
at org.glassfish.deployment.admin.UndeployCommand.execute(UndeployCommand.java:330)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1064)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1244)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1232)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:459)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:209)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:238)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]

The error appears to occur when Glassfish attempts to undeploy the web module after undeploying the EJB module. The EJB module appears to be the one that owns the portable JNDI name, and when the web module attempts to unbind the non-existent JNDI name, the afore-mentioned exception is thrown. This has grave consequences in a more complicated scenario (like the usage of Hibernate as a JPA provider within the application), as the web-module does not appear to be completely undeployed, resulting in vague exceptions being thrown on a subsequent deployment and use of the application.

Surprisingly, the exception is not thrown when the EJB module is packaged in a EAR file, as an ejb-jar file. Also, no exceptions are thrown when no portable JNDI names are specified for the EJB using the @EJB annotation.

A testcase (an Eclipse project) to reproduce this is attached.



 Comments   
Comment by Hong Zhang [ 26/Sep/11 ]

assign to cheng for initial evaluation

Comment by Cheng Fang [ 27/Sep/11 ]

I was able to reproduce it. The use case is valid and should not cause exception logging. However, a cursory look at webModuleContextConfig.unbindFromComponentNamespace(...) method shows it only logs the exception, which shouldn't affect normal application flow. Can you provide more details how other parts of your app is affected?

Re-assign to web container for further evaluation.

From the above forum post, "the exception is not thrown when the EJB module is packaged in a EAR file, as an ejb-jar file. Also, no exceptions are thrown when no portable JNDI names are specified for the EJB using the @EJB annotation."

In addition, the exception is not thrown when @EJB is on servlet class.

The exception is thrown when @EJB is on ejb bean class and the ejb is packaged inside war.

Comment by Vineet Reynolds [ 28/Sep/11 ]

I'll attempt to enhance the provided test case with the failures I'm seeing in my application, since no exceptions are being thrown when using the redeployed testcase. My application currently uses Arquillian to deploy a WAR to a Glassfish instance via the REST interface. Manual deployment of the same WAR also gives the same problem, so we could rule out the REST interface. Currently, exceptions like the one shown in the below stacktrace are thrown, when attempting to use the application after redeployment. A restart of Glassfish always resolves this issue.

[#|2011-09-28T10:54:32.943+0530|WARNING|glassfish3.1.1|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=22;_ThreadName=Thread-4;|A system exception occurred during an invocation on EJB GroupRepository method public info.galleria.domain.Group info.galleria.service.jpa.GroupRepository.create(info.galleria.domain.Group)
javax.ejb.TransactionRolledbackLocalException: Exception thrown from bean
at com.sun.ejb.containers.BaseContainer.checkExceptionClientTx(BaseContainer.java:5049)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4884)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2039)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1990)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:236)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy234.create(Unknown Source)
at info.galleria.service.jpa._EJB31_GeneratedGroupRepositoryIntf__Bean_.create(Unknown Source)
at info.galleria.service.ejb.GroupServiceImpl.createRegisteredUsersGroup(GroupServiceImpl.java:41)
at info.galleria.service.ejb.GroupServiceImpl.getOrCreateRegisteredUsersGroup(GroupServiceImpl.java:29)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5366)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5338)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5326)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:214)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy237.getOrCreateRegisteredUsersGroup(Unknown Source)
at info.galleria.service.ejb.UserServiceImpl.signupUser(UserServiceImpl.java:54)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5366)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5338)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5326)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:214)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy239.signupUser(Unknown Source)
at info.galleria.view.user.UserManager.signupUser(UserManager.java:71)
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.el.parser.AstValue.invoke(AstValue.java:234)
at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:297)
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105)
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88)
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102)
at javax.faces.component.UICommand.broadcast(UICommand.java:315)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:79)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at info.galleria.filters.UserRedirectFilter.doFilter(UserRedirectFilter.java:57)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:330)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.persistence.PersistenceException: org.hibernate.PropertyAccessException: could not get a field value by reflection getter of info.galleria.domain.Group.groupId
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1179)
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1112)
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1118)
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:618)
at com.sun.enterprise.container.common.impl.EntityManagerWrapper.persist(EntityManagerWrapper.java:269)
at info.galleria.service.jpa.GroupRepository.create(GroupRepository.java:31)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5366)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5338)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5326)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:214)
... 104 more
Caused by: org.hibernate.PropertyAccessException: could not get a field value by reflection getter of info.galleria.domain.Group.groupId
at org.hibernate.property.DirectPropertyAccessor$DirectGetter.get(DirectPropertyAccessor.java:62)
at org.hibernate.tuple.entity.AbstractEntityTuplizer.getIdentifier(AbstractEntityTuplizer.java:230)
at org.hibernate.persister.entity.AbstractEntityPersister.getIdentifier(AbstractEntityPersister.java:3852)
at org.hibernate.persister.entity.AbstractEntityPersister.isTransient(AbstractEntityPersister.java:3560)
at org.hibernate.engine.ForeignKeys.isTransient(ForeignKeys.java:204)
at org.hibernate.event.def.AbstractSaveEventListener.getEntityState(AbstractSaveEventListener.java:532)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:102)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:61)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:800)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:774)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:778)
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:612)
... 128 more
Caused by: java.lang.IllegalArgumentException: Can not set java.lang.String field info.galleria.domain.Group.groupId to info.galleria.domain.Group
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:146)
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:150)
at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:37)
at sun.reflect.UnsafeObjectFieldAccessorImpl.get(UnsafeObjectFieldAccessorImpl.java:18)
at java.lang.reflect.Field.get(Field.java:358)
at org.hibernate.property.DirectPropertyAccessor$DirectGetter.get(DirectPropertyAccessor.java:59)
... 139 more

#]
Comment by Shing Wai Chan [ 11/Oct/11 ]

From the debugger, I see that "GreetingManager" was unbind twice and hence has the exception in the second invocation. Web container only logs the exception as it wants the undeployment to continue in this case.

The following are the two calling stack:
1. at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:420)
at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:424)
at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:424)
at com.sun.enterprise.naming.impl.SerialContextProviderImpl.unbind(SerialContextProviderImpl.java:124)
at com.sun.enterprise.naming.impl.SerialContext.unbind(SerialContext.java:740)
at javax.naming.InitialContext.unbind(InitialContext.java:416)
at javax.naming.InitialContext.unbind(InitialContext.java:416)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.unpublishObject(GlassfishNamingManagerImpl.java:246)
at com.sun.ejb.containers.BaseContainer$JndiInfo.unpublish(BaseContainer.java:5636)
at com.sun.ejb.containers.BaseContainer.doContainerCleanup(BaseContainer.java:4318)
at com.sun.ejb.containers.BaseContainer.undeploy(BaseContainer.java:4222)
at org.glassfish.ejb.startup.EjbApplication.stop(EjbApplication.java:305)
at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:169)
at org.glassfish.internal.data.ModuleInfo.stop(ModuleInfo.java:302)
at org.glassfish.internal.data.ApplicationInfo.stop(ApplicationInfo.java:322)
at com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:999)
at com.sun.enterprise.v3.server.ApplicationLifecycle.undeploy(ApplicationLifecycle.java:1025)
at org.glassfish.deployment.admin.UndeployCommand.execute(UndeployCommand.java:330)

2. at com.sun.enterprise.naming.impl.TransientContext.doUnbind(TransientContext.java:398)
at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:420)
at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:424)
at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:424)
at com.sun.enterprise.naming.impl.SerialContextProviderImpl.unbind(SerialContextProviderImpl.java:124)
at com.sun.enterprise.naming.impl.SerialContext.unbind(SerialContext.java:740)
at javax.naming.InitialContext.unbind(InitialContext.java:416)
at javax.naming.InitialContext.unbind(InitialContext.java:416)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.unpublishObject(GlassfishNamingManagerImpl.java:246)
at com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl.unbindFromComponentNamespace(ComponentEnvManagerImpl.java:355)
at com.sun.enterprise.web.WebModuleContextConfig.unbindFromComponentNamespace(WebModuleContextConfig.java:454)
at com.sun.enterprise.web.WebModuleContextConfig.stop(WebModuleContextConfig.java:447)
at com.sun.enterprise.web.WebModuleContextConfig.lifecycleEvent(WebModuleContextConfig.java:174)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:149)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:5603)
at com.sun.enterprise.web.WebModule.stop(WebModule.java:527)
at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1049)
at com.sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java:2216)
at com.sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java:2171)
at com.sun.enterprise.web.WebApplication.stop(WebApplication.java:159)
at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:169)
at org.glassfish.internal.data.ModuleInfo.stop(ModuleInfo.java:302)
at org.glassfish.internal.data.ApplicationInfo.stop(ApplicationInfo.java:322)
at com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:999)
at com.sun.enterprise.v3.server.ApplicationLifecycle.undeploy(ApplicationLifecycle.java:1025)
at org.glassfish.deployment.admin.UndeployCommand.execute(UndeployCommand.java:330)

The "GreetingManager" was unbind twice as the ejb reference presents in both ejb and web bundle descriptors. Note that those descriptors are from annotation processing for ejb in war.

Comment by Cheng Fang [ 08/Nov/11 ]

Added tag 3_1_x-exclude. There are various workaround as described in previous comments. The logged stack trace is only warning message and should not affect normal app functioning.

Comment by markokanala [ 20/Mar/13 ]

I stumbled upon this issue. I can confirm this breaks the redeploy cycle as the deploy after this exception fails. This very annoying in development use.

I'm not really sure what exactly breaks but it seems that injecting EJB's on redeploy fails.

[#|2013-03-20T15:18:25.528+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=19;_ThreadName=Thread-3;|WebModule[/api]PWC1270: Exception starting filter VirtualHostingFilter
java.lang.InstantiationException
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:124)
...
Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class: class our.application.api.security.VirtualHostingFilter
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:315)
at com.sun.enterprise.web.WebContainer.createFilterInstance(WebContainer.java:745)
...
Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: Exception attempting to inject Local ejb-ref name= ... into nto class our.application.api.security.VirtualHostingFilter: Can not set our.application.core.service.CompanyService field our.application.api.security.VirtualHostingFilter.companyService to our.application.api.security.VirtualHostingFilter

and

[#|2013-03-20T15:18:25.919+0200|SEVERE|glassfish3.1.2|com.sun.jersey.server.impl.ejb.EJBComponentProviderFactoryInitilizer|_ThreadID=19;_ThreadName=Thread-3;|Error when configuring to use the EJB interceptor binding API. JAX-RS EJB support is disabled.
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 com.sun.jersey.server.impl.ejb.EJBComponentProviderFactoryInitilizer.initialize(EJBComponentProviderFactoryInitilizer.java:80)

Comment by klaasjanelzinga [ 03/Sep/13 ]

My redeployment cycle worked again after adding the messagelistener to the ejb-jar.xml:

<enterprise-beans>
<message-driven>
<ejb-name>...</ejb-name>
<ejb-class>...</ejb-class>
</message-driven>
</enterprise-beans>

Only the @MessageDriven with beans.xml caused the JAX-RS EJB support is disabled.

Comment by marina vatkina [ 03/Sep/13 ]

This seems very similar to https://java.net/jira/browse/GLASSFISH-20616





[GLASSFISH-16780] cluster wide EJB 3.1 Singleton support Created: 01/Jun/11  Updated: 13/Jun/11

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Nazrul Assignee: marina vatkina
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Provide cluster wide EJB 3.1 Singleton support.

GlassFish 3.1 release considered this feature. Refer to http://wikis.sun.com/display/GlassFish/GlassFishv3.1EJB

Also see forum thread: http://forums.java.net/node/807417



 Comments   
Comment by shreedhar_ganapathy [ 08/Jun/11 ]

Is this a request for clusterwide EJB Singleton or a generic Singleton Service. If the latter, any application object can be a singleton using a generic service that is cluster aware through GMS - a feature we have been thinking about in Shoal.
Would help to clarify what is being sought here.

Comment by jeff_trent [ 13/Jun/11 ]

The state-management JSR (being proposed now) will provide this feature. There already exists implementations including Coherence, and eventually we would like to have a Shoal provider built as well.





[GLASSFISH-16372] Not able to make toString() a final method in EJB with no-interface view Created: 17/Apr/11  Updated: 01/Apr/13

Status: Reopened
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_1-scrubbed

 Description   

EJB 3.1 spec says the following in section #4.9.8:
/All public methods of the bean class and any superclasses are exposed as business methods
through the no-interface view.

All methods of the bean class and any superclasses must not be declared final./

Nowhere do I find that methods of "java.lang.Object" are excluded from being part of no-interface view of the bean. This can't be true, because Object class has quite a few final methods in it. So, I am assuming that all methods of java.lang.Object are automatically excluded from being part of no-interface view of the EJB. But, then I am surprised to see an exception while trying to deploy the following EJB:

@Stateless
@LocalBean
public class FooBean {

public String test(String s)

{return s.toUpperCase();}

@Override public final String toString()

{return "FooBean";}

}

I got following exception:

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 com.sun.ejb.containers.EjbOptionalIntfGenerator.makeClass(EjbOptionalIntfGenerator.java:460)
... 27 more
Caused by: java.lang.VerifyError: class org.glassfish.fighterfish.test.app11.ejb._EJB31_GeneratedFooBeanIntf__Bean_ overrides final method toString.()Ljava/lang/String;
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
... 32 more

I think GlassFish is incorrectly making toString() a part of no-interface view of this bean.



 Comments   
Comment by marina vatkina [ 18/May/11 ]

We do not know if toString() will be called by the client. If it will, it should be a proxy call

Comment by Cheng Fang [ 19/Oct/11 ]

This issue was fixed as part of 17235 (Dependency Injection doesn't work for overloaded methods accepting generic-type parameter)

Comment by Mark Struberg [ 27/Mar/13 ]

Folks, I humbly recommend to reopen this issue.

final methods cannot get proxied, thus this method will always just hit the proxy instance instead of the proxied EJB instances. I think users will just not be aware what happens.

> Nowhere do I find that methods of "java.lang.Object" are excluded from being part of no-interface view of the bean.

That's true and should get fixed. I recommend to explicitly define the expected behaviour for Object.class methods and exclude them from the standard 'business methods' definition. Maybe this is already even in the spec implicitly? Not sure...

  • toString() -> should get proxied
  • equals, hashCode -> should not get proxied
  • clone -> should not get proxied
    etc
Comment by marina vatkina [ 29/Mar/13 ]

reopening...





[GLASSFISH-21516] Retrieving AppName from InitialContext behaves differently depending on the current callstack in remote ejb Created: 19/Feb/16  Updated: 19/Feb/16

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2.2, 4.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sisirhc Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I noticed changing results when requesting "java:app/AppName" in an EntityListener. The result varies depending on the call to InitialContext.lookup being in the transaction of in the transaction boundary handler when using Remote EJBs.

The scenario
The first application (TwixLeft) is an EAR archive containing a RemoteEJB to modify an entity, Country. The entity has an EntityListener that uses the AppName for other bean discovery (which is left out the example), the EntityListener only does a lookup now.

The second application (TwixRight) is a web archive containing a servlet executing a remote ejb call. The call can modify the Country Entity which forces a call to the entity listener.

Depending on the code inside the RemoteEJB the InitialContext.lookup returns different results. When being called from code executed really inside the remote EJB method the result of AppName is twixleft-ear.

The a call is made to the servlet to change an entity:

http://localhost:8080/twixright-web/right?action=update&id=1&input=hi8
Check the ConsoleLog for glassfish, the output is twixright-web

http://localhost:8080/twixright-web/right?action=updateFlush&id=1&input=hi2
Check the ConsoleLog for glassfish, the output is twixleft-ear

Question
Why does the AppName change? The RemoteEJB is proxied by Glassfish but handling the transaction belongs to the RemoteEJB call, to my opinion inside TwixLeft. If the remote EJB method code doesn't force a database write and has Glassfish taking care of this results vary.

The application can be used in both Glassfish 3 and 4 and both have the same results.

@Stateless
@Remote(value = EchoServiceRemote.class)
public class EchoService implements EchoServiceRemote {

    @PersistenceContext(name = "twixleft")
    EntityManager em;

    @Override
    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public String updateCountry(Long id, String description) {
        Country country = em.find(Country.class, id);
        country.setDescription(description);		

        return echo(description);
		
		// entity listener is called when this method is already returned by Glassfish transaction wrappers. the result of
		// InitialContext.lookup is twixright-web. This is not expected.
    }

    @Override
    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public String updateCountryWithFlush(Long id, String description) {
        Country country = em.find(Country.class, id);
        country.setDescription(description);
		
		// the em.flush forces JPA to change the entity immediatly and invokes the entity listener. the result of 
		// InitialContext.lookup is twixleft-ear. This is what I expect
        em.flush();

        return echo(description);
    }

}



 Comments   
Comment by sisirhc [ 19/Feb/16 ]

I created an example project which can be found via this link: https://github.com/cwesdorp/publicfiles/blob/master/GLASSFISH-21516-appname_context.zip





[GLASSFISH-21495] Transaction Rolled back due to timeout Created: 26/Jan/16  Updated: 19/Oct/16

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: cghislai Assignee: Srini
Resolution: Unresolved Votes: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

After upgrade from GF 4.1 to Glassfish 4.1.1, I get timed out transactions, with a warning in the log:
Warning: EJB5123:Rolling back timed out transaction [JavaEETransactionImpl: txId=51 nonXAResource=9 jtsTx=null localTxStatus=1 syncs=[com.sun.ejb.containers.SimpleEjbResourceHandlerImpl@2df56bef, com.sun.ejb.containers.ContainerSynchronization@3f02d7bb, org.eclipse.persistence.internal.jpa.transaction.JTATransactionWrapper$1@5fd05f0e, org.eclipse.persistence.transaction.JTASynchronizationListener@6a5a3c2b, com.sun.enterprise.resource.pool.PoolManagerImpl$SynchronizationListener@6cf6889c, org.eclipse.persistence.transaction.JTASynchronizationListener@456035b6]] for [PlaineService]

The method triggering this rollback imports a fair amount of data and regularly flushes the persistence context. Yet, once completed after several minutes, the warning and rollback occur.

The presence of @Asynchronous or @TransactionAttribute annotations to the method does not seem to have any impact on this issue.

Using GF 4.1, the method worked correctly.



 Comments   
Comment by napu [ 12/Feb/16 ]

I can confirm the same issue.

Comment by iordannalbantov [ 25/Feb/16 ]

We have it too. The consequent problem is that our timers are expunged afterwards which makes it critical for us. Downgrade is not an option because we will hit other critical bugs which were already fixed. Unfortunately setting Maximum Redeliveries of the EJB Timer Service to a higher number doesn't work neither.

Comment by douglasjunior [ 20/Apr/16 ]

I also have a method that persists much data.

It displays Warn, but the data is successfully persisted. Exception is not thrown. This Warn has caused problems for you?

I can ignore it?

Comment by fgonzales [ 25/May/16 ]

We are running into the same issue. I also verified that Glassfish 4.1 does not have this problem. It looks specific to 4.1.1.

Comment by lprimak [ 28/May/16 ]

I suggest you open a Payara issue for this.
It would help also if you have a ready reproducer application available.

Comment by rgrashel [ 23/Sep/16 ]

Is there any movement on this issue? if <cmt-timeout-in-seconds> can be used to extend the transaction timeout of an EJB timer, can someone please post an example of what the glassfish-ejb-jar.xml file looks like? I have tried variations and simply cannot get it to work. For long-running jobs, this is absolutely a critical issue if you cannot use an EJB Timer with a long-running job.

Comment by lprimak [ 25/Sep/16 ]

Both GlassFish and Payara are actually functioning property in this instance.
The solution for this is either to extend the tx timeout via cmt-timeout-in-seconds or via domain configuration.

Or break up the service into multiple EJBs, base with no tx that calls others that manipulate the database.

Comment by fgonzales [ 25/Sep/16 ]

In EJBContainerTransactionManager, cmtTimeoutInSeconds is hardcoded to 120 seconds. This was a change made in 4.1.1. This hard-coded value cannot be over-ridden via the domain configuration. It can only be overridden individually for each EJB, which is not very practical if you have a lot of them.

Comment by lprimak [ 25/Sep/16 ]

I'm pretty sure I configured 30 minutes and it works in Payara with the domain configuration, it I'll re-test

Comment by lprimak [ 26/Sep/16 ]

I have just re-tested Tx timeouts with the latest Payara, and they are confirmed to work as designed.
I changed Transaction Service -> Transaction Timeout from non-zero to 30 seconds, and it times out after 30 seconds,
and if it's at zero, it doesn't time out (unless you count esoteric stuff like CORBA which times out after 30 minutes)

Comment by fgonzales [ 26/Sep/16 ]

So this is already fixed in Payara? In Glassfish 4.1.1 this issue definitely exists.

Comment by rgrashel [ 26/Sep/16 ]

If this works in Payara, great. But this defect is about upstream Glassfish. My question to the Glassfish team – when is a fix for this going to be issued? It is not reasonable to ask users to declare methods as TransactionAttribute.NOT_SUPPORTED because they have long-running methods. Nor is it reasonable to ask users to break apart EJBs in strange ways simply to isolate intentionally long-running EJB methods.

Comment by dirkroets [ 19/Oct/16 ]

We've ran into this issue on GF 4.1.1 as well. I've looked through the source code and this bug was introduced with the code changes that fixed GLASSFISH-21175

Setting the default TX timeout back to 0 (disabled) is trivial, so we've compiled a new version of <gf home>/glassfish/modules/ejb-container.jar that fixes the problem for us.





[GLASSFISH-21384] Calling an @Asynchronous method in @Startup @Singleton EJB causes Classloader leak Created: 01/Jul/15  Updated: 01/Jul/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: HeinBloed Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Trying to trace down a Classloader leak in a larger project, I managed to create a minimal setup that triggers it.

Basically, I have two EJBs that look like this:

@javax.ejb.Singleton
@Startup
@DependsOn( "Singleton2" )
public class Singleton1
{
@EJB
private Singleton2 s2;

@PostConstruct
public void init()

{ s2.leakTest(); }

}

@javax.ejb.Singleton
@Startup
public class Singleton2
{
@Asynchronous
public void leakTest()

{ System.out.println( Thread.currentThread().getName() ); }

}

If I repeatedly redeploy a WAR file containing those two classes, a heap dump reveals that for each deployment, a new org.glassfish.web.loader.WebappClassLoader is retained. I analyzed the heap dump with the Eclipse Memory Analyzer and found the GC root of those leftover WebappClassLoader instances to be a Thread, namely the EJB pool thread that ran the asynchronous method (as verified by the console output), e.g. "_ejb_thread_pool1", then "_ejb_thread_pool2" etc.

There are actually two fields that have a reference chain to the retained WebappClassLoader: for one, the "inheritedAccessControlContext", for two, a ThreadLocal entry that goes through HandlerData, EjbInvocation, and finally what must be the proxied EJB.

I have uploaded screenshots of the relevant parts of the heap dump analysis here: http://i.imgur.com/gmnSXFA.png and here: http://i.imgur.com/xrRhN5j.png. This is after re-deploying 3 times, so there are 3 leaked Classloader instances. The other two have the same structure as the one shown in the second screenshot.

I did not test (yet) whether this occurs with a non-Startup/Singleton EJB too.






[GLASSFISH-21476] Resource not available in @Singleton @Predestroy method Created: 22/Dec/15  Updated: 22/Dec/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: kiranmohane Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

openjdk version "1.8.0_66
Ubuntu 15.10



 Description   

It seems like resources are not available to a Singleton's @Predestroy method.

@PreDestroy
public void cleanup() {
logger.info("*** Application shutting down. Dropping temporary tables ***");
try

{ connection = dataSource.getConnection(); Statement statement = connection.createStatement(); statement.execute("drop table TABLE1"); statement.execute("drop table TABLE2"); connection.close(); connection = null; }

catch (SQLException sqle)

{ sqle.printStackTrace(); }

}
The call to getConnection() fails with the error "No Pool Meta Data object associated with the pool". Note that the getConnection() call is successful in the @PostConstruct methods.

Is it a Bug in the application server implementation? If not, what is the most elegant way to drop temporary tables?

(Using Glassfish 4.1.1 + Derby DB. The datasource is created using glassfish-resources.xml deployed with the EAR

<resources>
<jdbc-resource pool-name="EmbeddedDerbyPool"
jndi-name="java:app/jdbc/ActionBazaarDS" />
<jdbc-connection-pool name="EmbeddedDerbyPool"
res-type="javax.sql.DataSource"
datasource-classname="org.apache.derby.jdbc.EmbeddedDataSource"
is-isolation-level-guaranteed="false">
<property name="databaseName" value="memory:action-bazaar-db"/>
<property name="createDatabase" value="create"/>
</jdbc-connection-pool>
</resources>






[GLASSFISH-21465] TimerService createCalendarTimer with dayOfWeek Created: 15/Nov/15  Updated: 15/Nov/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: rsoika Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: timer

 Description   

Can you please reopen the following bug

https://java.net/jira/browse/GLASSFISH-20673

or at least give some feedback to the comunity.

===
Ralph






[GLASSFISH-21462] adminGUI does not load the classpath from manifest.mf to the precompilejsp in Application Deploy module Created: 05/Nov/15  Updated: 05/Nov/15

Status: Open
Project: glassfish
Component/s: admin_gui, classloader, deployment, ejb_container
Affects Version/s: 4.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ccagf Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Labels: jspc, precompilejsp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: PWC6112, admin-gui, admingui, deploy, java.lang.ClassNotFoundException:, jspc, precompilejsp

 Description   

in adminGUI ==> Applications ==> Deploy Applications or Modules ==> Precompile JSPs:

if You choose the Option - Precomplier works with JARs included in the LIB
But Fails when 3rd Party Jars are refeneced in the manifest.mf file - as the Glassfish Precomplier is not reading the class path from manifest.mf.

In Glassfish Version 2.1.1 It Works - Stopped working since Glassfish v3.
Does Not work on Glassfish 4.1.1

Sugested BUG Fix - adminGUI (when precompilejsp is checked) also needs to Read the Manifest.MF's Class-Path and pass it on to the jspc compiler.

Error: PWC6112
java.lang.ClassNotFoundException:

Just FYI - When I pass the class-path part of jspc and copmile it works - so the bug surely is on the adminGUI console






[GLASSFISH-21369] MDBs with no-methods listener interface don't work with Bean-managed transactions Created: 01/Jun/15  Updated: 01/Jul/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Nigel Deakin Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In the EJB 3.2 specification, section 5.4.3 "Message-Driven Bean with No-Methods Listener Interface" states

A message-driven bean is permitted to implement a listener interface with no methods.

and that

The resource adapter determines which message listener method is invoked according to its implementation logic.

However if a resource adapter is deployed which makes use of this feature, and a MDB is deployed which is configured to use bean-managed transactions, then the following exception is thrown when the resource adapter attempts to deliver a message to the MDB proxy provided by the EJB container:

Caused by: javax.ejb.EJBException: Transaction Attribute not found for methodpublic abstract void jms.jms21.mdb.mdb3.ejb.__EJB32_Generated__MyMessageBean__Intf__.giveMeAMessage(javax.jms.Message)
  at com.sun.ejb.containers.BaseContainer.getTxAttr(BaseContainer.java:2826)
  at org.glassfish.ejb.mdb.MessageBeanContainer.containerStartsTx(MessageBeanContainer.java:416)
  at org.glassfish.ejb.mdb.MessageBeanContainer.isDeliveryTransacted(MessageBeanContainer.java:718)
  at com.sun.enterprise.connectors.inbound.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:173)
  at com.sun.proxy.$Proxy261.giveMeAMessage(Unknown Source)
  at jms.jms21.mdb.mdb3.ejb.__EJB32_Generated__MyMessageBean__Intf____Bean__.giveMeAMessage(Unknown Source)
  ... 8 more

(In this example, the listener method invoked by the resource adapter is called giveMeAMessage).

This exception only occurs if the MDB is configured with bean-managed transactions, using the annotation

@TransactionManagement(value = TransactionManagementType.BEAN)

The cause seems to be the following code in org.glassfish.ejb.mdb.MessageBeanContainer, which cannot cope with the case where the listener interface has no methods:

// Register the tx attribute for each method on MessageListener
// interface. NOTE : These method objects MUST come from the
// MessageListener interface, NOT the bean class itself. This
// is because the message bean container clients do not have
// access to the message bean class.
Method[] msgListenerMethods = 
   msgBeanDesc.getMessageListenerInterfaceMethods(loader);

for (int i = 0; i < msgListenerMethods.length; i++) {
  Method next = msgListenerMethods[i];
  addInvocationInfo(next, MethodDescriptor.EJB_BEAN, null);
}

The premise of this method seems to be wrong. With a MDB, whether or not the container needs to start a transaction is defined for the MDB class as a whole, not for individual methods. (See EJB 3.2 section 5.4.13). So there should be no need for the EJB container to know what the listener method is. All it needs to know is whether the MDB as a whole is configured to use container-manager or bean-managed transactions.



 Comments   
Comment by Debayan_Gupta [ 18/Jun/15 ]

Could you please provide a test case for this for better debugging and testing? I guess the example app will do fine. Just provide the module and usage instruction.

Comment by Debayan_Gupta [ 22/Jun/15 ]

Requesting again :
Could you please provide a test case for this for better debugging and testing? I guess the example app will do fine. Just provide the module and usage instruction. It'll be faster from our side to debug the problem with unit test.

Comment by Nigel Deakin [ 01/Jul/15 ]

I have a GlassFish devtest I can send you. However this requires an updated version of the MQ resource adapter jmsra that is built into GlassFish. This has been modified to support a no-methods listener interface. Let me know if you wish me to send you this: you will need to replace the version in your GlassFish installation with this new version. There are also some small changes to GlassFish that will be necessary to allow this to be used.

Is there an existing GlassFish test which tests support for MDBs with a non-methods listener interface? If there is such a test, then is it possible to extend it this to use bean-managed transactions?





[GLASSFISH-21368] Glassfish embedded ejb container hangs until restart. Created: 30/May/15  Updated: 30/May/15

Status: Open
Project: glassfish
Component/s: ejb_container, embedded
Affects Version/s: 4.0, 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jbreindel Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 8.1, Glassfish 4.1



 Description   

When attempting to run unit tests using the embedded ejb container, I am only able to run the tests once, then when attempting to run the tests again deploying to the EJB Container hangs. It remains frozen until I restart my computer.

Here is the stack trace of a successful run:

May 29, 2015 10:13:25 PM org.glassfish.ejb.embedded.EJBContainerImpl deploy
INFO: [EJBContainerImpl] Deploying app: org.glassfish.embeddable.archive.ScatteredArchive@470b5213
May 29, 2015 10:13:25 PM org.glassfish.ejb.embedded.EJBContainerImpl deploy
INFO: [EJBContainerImpl] GlassFish status: STARTED
May 29, 2015 10:13:25 PM org.glassfish.ejb.embedded.EJBContainerImpl deploy
INFO: [EJBContainerImpl] Deploying as a ScatteredArchive
May 29, 2015 10:13:40 PM com.sun.enterprise.security.SecurityLifecycle <init>
INFO: Java security manager is disabled.
May 29, 2015 10:13:40 PM com.sun.enterprise.security.SecurityLifecycle onInitialization
INFO: Entering Security Startup Service.
May 29, 2015 10:13:40 PM com.sun.enterprise.security.PolicyLoader loadPolicy
INFO: Loading policy provider com.sun.enterprise.security.provider.PolicyWrapper.
May 29, 2015 10:13:40 PM com.sun.enterprise.security.SecurityLifecycle onInitialization
INFO: Security Service(s) started successfully.

A hanging run would freeze as so:

May 29, 2015 10:13:25 PM org.glassfish.ejb.embedded.EJBContainerImpl deploy
INFO: [EJBContainerImpl] Deploying app: org.glassfish.embeddable.archive.ScatteredArchive@470b5213
May 29, 2015 10:13:25 PM org.glassfish.ejb.embedded.EJBContainerImpl deploy
INFO: [EJBContainerImpl] GlassFish status: STARTED
May 29, 2015 10:13:25 PM org.glassfish.ejb.embedded.EJBContainerImpl deploy
INFO: [EJBContainerImpl] Deploying as a ScatteredArchive

I was curious about the java security manager disabled portion, so I enabled the java security manager in the admin panel and the EJB container just fails when deploying. I suspect that there is something going on with the security lifecycle but I am unsure.

Any help is greatly appreciated.






[GLASSFISH-21203] Shared entity Manager on high concurrency Created: 17/Sep/14  Updated: 17/Sep/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: tama_demicheli Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP, Oracle 12c



 Description   

Hi I am using GlassFish Server Open Source Edition 3.1.2 (build 23) with Oracle Database 12c Enterprise Edition 12.1.0.1.0 64bit Production. I have in Persistence.xml only (Shared Cache is enabled to all Entities):

<shared-cache-mode>DISABLE_SELECTIVE</shared-cache-mode>
<exclude-unlisted-classes>false</exclude-unlisted-classes>
I have observed this while making a remote call to pooled Stateless EJB. can anyone tell me if this is correct or if it is a bug ? It could make sense to think that this drives to a:

[EclipseLink-2004] org.eclipse.persistence.exceptions.ConcurrencyException Exception Description: A signal was attempted before wait() on ConcurrencyManager. This normally means that an attempt was made to commit or rollback a transaction before it was started, or to rollback a transaction twice.

I was testing the PersistenceContext propagation to ApplicationScoped CDI Beans, and i have used this 2 implementations, both of them instantiate the EntityManager via @PersistenceContext :

@ApplicationScoped
public class ApplicationScoped1 {...

@Stateless
public class TestFacadeImpl implements TestFacade {
I have printed as (more or less) the following on each call on each Implementation:

JpaEntityManager delegate = (JpaEntityManager) em.getDelegate();
Session activeSession = delegate.getActiveSession();
IdentityMapAccessor identityMapAccessor = activeSession.getIdentityMapAccessor();
LOGGER.info("delegate: " + delegate);
LOGGER.info("identityMapAccessor: " + identityMapAccessor);
TestFacadeImpl is triggered in parallel remotely from a client, and log delegate and identityMapAccessor.

I divide the results in 3 chunks

First Fine, not really parallel, Propagation Fine and each thread has his EntityManagerImpl instance and UnitOfWorkIdentityMapAccessor (can say that is L1/WorkUnit Cache right)

2014-09-09 10:22:20.997 INFO 37 delegate Trigger : org.eclipse.persistence.internal.jpa.EntityManagerImpl@5b86a92d (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:20.997 INFO 37 identityMapAccessor Trigger: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@65ccf84c (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:21.003 INFO 37 delegate: org.eclipse.persistence.internal.jpa.EntityManagerImpl@5b86a92d (com.foo.blah..impl.systemtests.ApplicationScoped1)
2014-09-09 10:22:21.004 INFO 37 identityMapAccessor: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@65ccf84c (com.foo.blah..impl.systemtests.ApplicationScoped1)

2014-09-09 10:22:21.009 INFO 36 delegate Trigger : org.eclipse.persistence.internal.jpa.EntityManagerImpl@4fff8693 (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:21.009 INFO 36 identityMapAccessor Trigger: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@10dc45ed (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:21.015 INFO 36 delegate: org.eclipse.persistence.internal.jpa.EntityManagerImpl@4fff8693 (com.foo.blah..impl.systemtests.ApplicationScoped1)
2014-09-09 10:22:21.016 INFO 36 identityMapAccessor: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@10dc45ed (com.foo.blah..impl.systemtests.ApplicationScoped1)
Second Fine, In the same millisecond each Thread has his own EntityManagerImpl and UnitOfWorkIdentityMapAccessor

2014-09-09 10:22:21.051 INFO 36 delegate Trigger : org.eclipse.persistence.internal.jpa.EntityManagerImpl@2b917db5 (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:21.052 INFO 36 identityMapAccessor Trigger: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@657b7469 (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:21.051 INFO 37 delegate Trigger : org.eclipse.persistence.internal.jpa.EntityManagerImpl@5cd40c6b (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:21.052 INFO 37 identityMapAccessor Trigger: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@c17cd8c (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:21.057 INFO 36 delegate: org.eclipse.persistence.internal.jpa.EntityManagerImpl@2b917db5 (com.foo.blah..impl.systemtests.ApplicationScoped1)
2014-09-09 10:22:21.057 INFO 37 delegate: org.eclipse.persistence.internal.jpa.EntityManagerImpl@5cd40c6b (com.foo.blah..impl.systemtests.ApplicationScoped1)
2014-09-09 10:22:21.058 INFO 36 identityMapAccessor: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@657b7469 (com.foo.blah..impl.systemtests.ApplicationScoped1)
2014-09-09 10:22:21.058 INFO 37 identityMapAccessor: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@c17cd8c (com.foo.blah..impl.systemtests.ApplicationScoped1)
Third, a bit strange, 2 Threads from the EJB pool get the same EntityManagerImpl and 2 different UnitOfWorkIdentityMapAccessor

2014-09-09 10:22:21.075 INFO 36 delegate Trigger : org.eclipse.persistence.internal.jpa.EntityManagerImpl@6d198dd7 (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:21.075 INFO 37 delegate Trigger : org.eclipse.persistence.internal.jpa.EntityManagerImpl@6d198dd7 (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:21.075 INFO 36 identityMapAccessor Trigger: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@28af5636 (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:21.075 INFO 37 identityMapAccessor Trigger: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@f450818 (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:21.081 INFO 37 delegate: org.eclipse.persistence.internal.jpa.EntityManagerImpl@6d198dd7 (com.foo.blah..impl.systemtests.ApplicationScoped1)
2014-09-09 10:22:21.081 INFO 36 delegate: org.eclipse.persistence.internal.jpa.EntityManagerImpl@6d198dd7 (com.foo.blah..impl.systemtests.ApplicationScoped1)
2014-09-09 10:22:21.081 INFO 37 identityMapAccessor: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@f450818 (com.foo.blah..impl.systemtests.ApplicationScoped1)
2014-09-09 10:22:21.081 INFO 36 identityMapAccessor: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@28af5636 (com.foo.blah..impl.systemtests.ApplicationScoped1)






[GLASSFISH-21327] EJB Timer application won't deploy to a stand-alone GF server instance using Derby Created: 12/Mar/15  Updated: 12/Mar/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: andrew_m_poloni Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RHEL v6.6 (Santiago)
Java v1.8.0_40



 Description   

When trying to move the EJB Timer application to a GF stand-alone instance using the Derby database, a java.sql.SQLException is thrown because of the inability by Derby to create a(n ejbtimer) database in GF_HOME/nodes/localhost-<domainname>/<server_name>/lib/databases/ejbtimer. The top-level exception is thrown while trying to creating a resource for the __TimerPool with the inability to create the appropriate Derby database files seeming to be the culprit.






[GLASSFISH-21277] RMI/IIOP calls include the "local classpath" instead of the remote classpath, incurring in performance penalties without apparent benefits Created: 22/Dec/14  Updated: 22/Dec/14

Status: Open
Project: glassfish
Component/s: ejb_container, orb
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: moonysun Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Solaris 11, Linux 3.6+, JDK 1.7.0_62



 Description   

We've noticed (by capturing with snoop and tcpdump) that a glassfish v3.1.2.2 being called by an external client or glassfish v3.1.2.2 calling other application server via RMI/IIOP sends and/or receives CORBA messages that include gf classpath pointers.

Example:
getParametroByPeriodo.......................................NEO...................'~file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/slf4j-api-1.7.5.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-jpa-3.2.8p.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/commons-io-2.3.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/gfct-service-export-3.5.25d.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/rewrite-servlet-2.0.6.Final.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/hibernate-core-4.2.7.SP1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/logging-adapter-slf4j-1.0.2.Final.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/rewrite-config-prettyfaces-2.0.6.Final.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/shiro-cas-3.2.8p.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/gfct-layouts-3.5.25d-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/commons-fileupload-1.2.2.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/generated/ejb/fc// file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/cas-client-core-3.2.1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/IIESCommons-2.0.14.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/ehcache-2.8.1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/gfct-api-3.5.25d.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/sicc-service-export-2.0.197b.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/logback-classic-1.1.0.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/rewrite-integration-cdi-2.0.6.Final.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/gson-2.2.2.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-utilities-3.2.8p.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/joda-time-2.1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/ehcache-jgroupsreplication-1.7.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-main-3.2.8p-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-guicomponents-3.2.8p-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/commons-beanutils-1.8.3.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-cdi-3.2.8p.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/hibernate-ehcache-4.2.7.SP1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/commons-lang3-3.1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/framework-server-2.0.69c.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-primefaces-3.2.8p-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/groovy-all-2.0.0.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEGIOP............B-INF/lib/hibernate-envers-4.2.7.SP1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/jul-to-slf4j-1.7.5.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/primefaces-3.5.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/logback-core-1.1.0.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-jsf-3.2.8p-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/dom4j-1.6.1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-script-it-3.2.8p-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/guava-16.0.1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/app-service-export-3.0.19b.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/myfaces-extcdi-bundle-jsf20-1.0.6.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-grs-3.2.8p.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/shiro-core-1.2.2.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/commons-collections-3.2.1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/jcl-over-slf4j-1.7.5.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/resources-codemirror-0.7.1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/primefaces-extensions-0.7.1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/gfct-batch-3.5.25d.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/commons-codec-1.8.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/generated/fc/ file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/xmlsec-1.4.3.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/app-webapp-3.0.19b-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/jgroups-3.1.0.Final.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/resources-ckeditor-0.7.1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/cmp-service-export-2.0.20h.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/rewrite-integration-faces-2.0.6.Final.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/shiro-web-1.2.2.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/siccservicos-service-export-2.0.31a.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-accesslog-3.2.8p-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/jboss-logging-3.1.0.GA.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/idq-service-export-2.0.238b.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/micap-service-export-2.0.40d.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/httpclient-4.3.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/shiro-ehcache-1.2.2.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/jollyday-0.4.5.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/hibernate-jpa-2.0-api-1.0.1.Final.jar file:/var/opGIOP............t/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-security-3.2.8p-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/hibernate-entitymanager-4.2.7.SP1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-agenda-3.2.8p-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/gcservicos-service-export-2.0.135.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/log4j-over-slf4j-1.7.5.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/public-api-3.6.20e.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/opensaml-1.1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/app-api-3.0.19b.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/classes/ file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-api-3.2.8p.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/hibernate-commons-annotations-4.0.2.Final.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/gfct-webresources-3.5.25d-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/antlr-2.7.7.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/omnifaces-1.7.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-messaging-3.2.8p-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/ssn-service-export-2.8.49b.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/httpcore-4.3.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/commons-logging-1.1.1.jar.as...URMI:pt.segsocial.idq.service.export.vo.ParametroVO:EF7D3D9277551DC8:6EAB90E26C3A7990.r f...
...:RMI:java.util.Hashtable:86573568A211C011:13BB0F25214AE4B8.li......s/?@.........

This increases the average size of each message and doesn't provide a way for remote class loading to actually occur, since, generally, the client/server does not have access to the classpath of the gf3 container.

We've implemented a workaround/fix for this issue and saw a reduction in message size of about 75% for small requests/replies.

The workaround is basically the implementation of the following class:

package pt.segsocial.corba;

import java.net.MalformedURLException;
import java.rmi.server.RMIClassLoader;
import java.rmi.server.RMIClassLoaderSpi;

public class CodebaseSpeedupRMIClassLoaderSpi extends RMIClassLoaderSpi {

private RMIClassLoaderSpi defaultProviderInstance;

public CodebaseSpeedupRMIClassLoaderSpi()

{ defaultProviderInstance = RMIClassLoader.getDefaultProviderInstance(); }

@Override
public String getClassAnnotation(Class<?> cl)

{ return null; }

@Override
public Class<?> loadClass(String codebase, String name, ClassLoader defaultLoader) throws MalformedURLException, ClassNotFoundException

{ return defaultProviderInstance.loadClass(codebase, name, defaultLoader); }

@Override
public Class<?> loadProxyClass(String codebase, String[] interfaces, ClassLoader defaultLoader) throws MalformedURLException,
ClassNotFoundException

{ return defaultProviderInstance.loadProxyClass(codebase, interfaces, defaultLoader); }

@Override
public ClassLoader getClassLoader(String codebase) throws MalformedURLException

{ return defaultProviderInstance.getClassLoader(codebase); }

}

and providing a file META-INF/services/java.rmi.server.RMIClassLoaderSpi on the created jar with the contents

pt.segsocial.corba.CodebaseSpeedupRMIClassLoaderSpi

This implementation is based on the documentation at
http://docs.oracle.com/javase/1.5.0/docs/api/java/rmi/server/RMIClassLoader.html
and
http://docs.oracle.com/javase/1.5.0/docs/api/java/rmi/server/RMIClassLoaderSpi.html

Then we place the created jar in $GLASSFISH_HOME/glassfish/modules/endorsed and it works as expected.

Are there any potential pitfalls we should be aware of? What other tests should we account for in this scenario? Why isn't this provided by default?

We also saw that SunOne 8.2 doesn't seem to have this issue, so another question is regarding if this is a bug, a regression or caused by other glassfish corba orb improvments?






[GLASSFISH-21274] EJB container threads carry wrong transactional context Created: 18/Dec/14  Updated: 18/Dec/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0, 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pranahata Assignee: Srini
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Guys.

I sure there is an issue in the ejb container by which invocations from either batch jobs (@Schedule) or @Asynchronous that happen on threads from the ejb-thread-pool carry stale transactional information.

I have seen things like:

@TransactionAttribute(TransactionAttributeType.NEVER)
@Schedule(minute = "", second = "/10", dayOfMonth = "", month = "", year = "", hour = "", dayOfWeek = "*", persistent = false)
public void cleanupSessions(Timer timer) {

This method only gets invoked by the container and some times, mostly under a bit of load i see things like

Warning: javax.ejb.TransactionRolledbackLocalException: Client's transaction aborted
at com.sun.ejb.containers.EJBContainerTransactionManager.useClientTx(EJBContainerTransactionManager.java:357)
at com.sun.ejb.containers.EJBContainerTransactionManager.preInvokeTx(EJBContainerTransactionManager.java:251)
at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:4433)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1921)
at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:3990)
at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1199)
at com.sun.ejb.containers.EJBTimerService.access$000(EJBTimerService.java:89)
at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:1919)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

Alsoooo.......

I have seen an @Asynchronous method marked as @TransactionAttribute(TransactionAttributeType.NEVER)

calling another @Asynchronous method also marked as @TransactionAttribute(TransactionAttributeType.NEVER)

and the invocation on the second method failing with an error saying the method is marked as NEVER but there is a transasction in progress

It only seems to happen with threds from the ejb thread pool






[GLASSFISH-21290] Returned value from SLSB takes minutes to the caller Created: 18/Jan/15  Updated: 21/Jan/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: andydr Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

We moved an EAR project containing an EJB module and an ACC module from GF 4.0 to GF 4.1.

When we make a remote call from the ACC client (Java Swing App started via webstart) on GF 4.0, the duration is about 2 secs and on GF 4.1 about 120 seconds.

The EJB makes some JPA calls (Hibernate 4.3) and returns a fairly complex entity, but as we have seen very fast. The times gets lost after the EJB method return.

So what happens after the EJB return - marshalling of the returned value? Can anybody point me to a topic, where I can further look at?

Thanks, Andreas



 Comments   
Comment by anowac01 [ 21/Jan/15 ]

You may want to look at GLASSFISH-21285 and the thread linked there, which sounds like a similar issue, though I don't believe there is much in the way of solutions identified there yet.





[GLASSFISH-21129] User ID in File security realm affects role mapping Created: 14/Jul/14  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: ejb_container, security
Affects Version/s: 4.1_dev
Fix Version/s: None

Type: Bug Priority: Major
Reporter: tremes Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

using nightly build from 2014-07-14
using following param in config:
<security-service activate-default-principal-to-role-mapping="true">



 Description   

Suppose following two simple classes:

@Stateless
@RunAs("student")
@PermitAll
public class Student {

    @Resource
    private SessionContext context;

    @EJB
    Notebook notebook;

    public String getNotebookPrincipal(){
        return notebook.getCallerPrincipal();
    }

    public String getStudentPrincipal(){
        return context.getCallerPrincipal().toString();
    }
}

and:

@Stateless
@RunAs("notebook")
@RolesAllowed("student")
public class Notebook {

    @Resource
    private SessionContext context;

    public String getCallerPrincipal(){
        return context.getCallerPrincipal().toString();
    }
}

When I have following mapping then it's fine:

User ID Group
student student
notebook student:notebook

but I cannot see any reason, why it should fail with e.g.:

User ID Group
john student
notebook student:notebook

Getting:

Caused by: javax.ejb.EJBAccessException
	at com.sun.ejb.containers.BaseContainer.mapLocal3xException(BaseContainer.java:2351)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2123)
	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.$Proxy254.getCallerPrincipal(Unknown Source)
	at test.sceurity.__EJB31_Generated__Notebook__Intf____Bean__.getCallerPrincipal(Unknown Source)
	at test.sceurity.Student.getNotebookPrincipal(Student.java:29)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at 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 org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)
	at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:52)
	at sun.reflect.GeneratedMethodAccessor296.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	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 com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
	at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:140)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at com.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)
	... 103 more
Caused by: javax.ejb.AccessLocalException: Client not authorized for this invocation
	at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1960)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:210)
	... 137 more


 Comments   
Comment by tremes [ 14/Jul/14 ]

Maybe I am wrong, but I understand that @RunAs specifies role name and not user name. I would attach simple reproducer app, but looks like I cannot.





[GLASSFISH-21186] EJB Timer cannot mirgrate correctly Created: 07/Sep/14  Updated: 07/Sep/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.1
Fix Version/s: None

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

Debian 7.5 64bit
JDK 7 u51 64bit
Glassfish 4.1 b13



 Description   

I setup a cluster include 2 instances : instance1 and instance2

When I start cluster, EJB Timer run on instance2, when I stop instance2, default EJB Timer will change to instance1 automatically, but when I trace log from instance1, it show below:

[2014-09-07T12:03:20.720+0700] [glassfish 4.1] [INFO] [view.window.view.change] [ShoalLogger] [tid: _ThreadID=23 _ThreadName=GMS ViewWindowThread Group-gbcluster] [timeMillis: 1410066200720] [levelValue: 800] [[
GMS1092: GMS View Change Received for group: gbcluster : Members in view for PEER_STOP_EVENT(before change analysis) are :
1: MemberId: instance1, MemberType: CORE, Address: 10.43.3.10:10032:228.9.3.1:2048:gbcluster:instance1
2: MemberId: server, MemberType: SPECTATOR, Address: 10.43.3.16:10049:228.9.3.1:2048:gbcluster:server
]]

[2014-09-07T12:03:20.721+0700] [glassfish 4.1] [INFO] [membership.snapshot.analysis] [ShoalLogger] [tid: _ThreadID=23 _ThreadName=GMS ViewWindowThread Group-gbcluster] [timeMillis: 1410066200721] [levelValue: 800] [[
GMS1016: Analyzing new membership snapshot received as part of event: PEER_STOP_EVENT for member: instance2 of group: gbcluster]]

[2014-09-07T12:03:20.721+0700] [glassfish 4.1] [INFO] [plannedshutdownevent.announcement] [ShoalLogger] [tid: _ThreadID=23 _ThreadName=GMS ViewWindowThread Group-gbcluster] [timeMillis: 1410066200721] [levelValue: 800] [[
GMS1017: Received PlannedShutdownEvent Announcement from member: instance2 with shutdown type: INSTANCE_SHUTDOWN of group: gbcluster]]

[2014-09-07T12:03:20.723+0700] [glassfish 4.1] [INFO] [plannedshutdownsignals.send.member] [ShoalLogger] [tid: _ThreadID=22 _ThreadName=GMS SignalHandler for Group-gbcluster thread] [timeMillis: 1410066200723] [levelValue: 800] [[
GMS1008: Sending PlannedShutdownSignals to registered Actions for shutdownType INSTANCE_SHUTDOWN member: instance2 ...]]

[2014-09-07T12:03:20.725+0700] [glassfish 4.1] [INFO] [] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=60 _ThreadName=GMS-processNotify-Group-gbcluster-thread-1] [timeMillis: 1410066200725] [levelValue: 800] [[
[DistributedEJBTimerService] migrating timers from instance2]]

[2014-09-07T12:03:20.725+0700] [glassfish 4.1] [INFO] [] [ShoalLogger] [tid: _ThreadID=62 _ThreadName=GMS-processNotify-Group-gbcluster-thread-3] [timeMillis: 1410066200725] [levelValue: 800] [[
**VIEW: prevViewId: 2; curViewID: 3; signal: com.sun.enterprise.ee.cms.impl.common.PlannedShutdownSignalImpl@1e749200 [current: instance1] [previous: instance1, instance2]]]

[2014-09-07T12:03:20.725+0700] [glassfish 4.1] [INFO] [] [ShoalLogger] [tid: _ThreadID=62 _ThreadName=GMS-processNotify-Group-gbcluster-thread-3] [timeMillis: 1410066200725] [levelValue: 800] [[
**********************************************************************]]

[2014-09-07T12:03:20.726+0700] [glassfish 4.1] [INFO] [] [javax.enterprise.system.container.ejb.org.glassfish.ejb.persistent.timer] [tid: _ThreadID=60 _ThreadName=GMS-processNotify-Group-gbcluster-thread-1] [timeMillis: 1410066200726] [levelValue: 800] [[
Beginning timer migration process from owner instance2 to instance1]]

[2014-09-07T12:03:20.816+0700] [glassfish 4.1] [INFO] [] [javax.enterprise.system.container.ejb.org.glassfish.ejb.persistent.timer] [tid: _ThreadID=60 _ThreadName=GMS-processNotify-Group-gbcluster-thread-1] [timeMillis: 1410066200816] [levelValue: 800] [[
Timer migration phase 1 complete. Changed ownership of 2 timers. Now reactivating timers...]]

[2014-09-07T12:03:20.818+0700] [glassfish 4.1] [INFO] [] [javax.enterprise.system.container.ejb.org.glassfish.ejb.persistent.timer] [tid: _ThreadID=60 _ThreadName=GMS-processNotify-Group-gbcluster-thread-1] [timeMillis: 1410066200818] [levelValue: 800] [[
Rescheduling missed expiration for periodic timer '1@@1410066146328@@instance2@@instance2' 'TimedObject = IpoScheduleGbJobEJB' 'Application = gbeearipo' 'CREATED' 'PERIODIC' 'Container ID = 92405000009744396' 'Sun Sep 07 12:02:26 ICT 2014' '500' . Last timer expiration occurred at Sun Sep 07 12:03:16 ICT 2014]]


Result is EJB Timer cannot active on instance1

I also trace log on instance2:
[2014-09-07T12:03:16.779+0700] [glassfish 4.1] [INFO] [AS_ACDEPL-00104] [javax.enterprise.system.container.appclient] [tid: _ThreadID=12622 _ThreadName=RunLevelControllerThread-1410066190958] [timeMillis: 1410066196779] [levelValue: 800] [[
Java Web Start services stopped for the app client gbear/eclipselink.jar]]

[2014-09-07T12:03:17.199+0700] [glassfish 4.1] [INFO] [] [org.eclipse.persistence.session.file:/home/gbsofts/glassfish4/glassfish/nodes/srv2.gbsofts.com/instance2/applications/gbear/gbeejb_jar/_gbePU.connection] [tid: _ThreadID=12622 _ThreadName=RunLevelControllerThread-1410066190958] [timeMillis: 1410066197199] [levelValue: 800] [[
file:/home/gbsofts/glassfish4/glassfish/nodes/srv2.gbsofts.com/instance2/applications/gbear/gbeejb_jar/_gbePU logout successful]]

[2014-09-07T12:03:17.216+0700] [glassfish 4.1] [INFO] [AS_ACDEPL-00104] [javax.enterprise.system.container.appclient] [tid: _ThreadID=12622 _ThreadName=RunLevelControllerThread-1410066190958] [timeMillis: 1410066197216] [levelValue: 800] [[
Java Web Start services stopped for the app client gbeearipo/eclipselink.jar]]

[2014-09-07T12:03:17.400+0700] [glassfish 4.1] [INFO] [] [org.eclipse.persistence.session.file:/home/gbsofts/glassfish4/glassfish/nodes/srv2.gbsofts.com/instance2/applications/gbeearipo/ipoejb_jar/_gbeipoPU.connection] [tid: _ThreadID=12622 _ThreadName=RunLevelControllerThread-1410066190958] [timeMillis: 1410066197400] [levelValue: 800] [[
file:/home/gbsofts/glassfish4/glassfish/nodes/srv2.gbsofts.com/instance2/applications/gbeearipo/ipoejb_jar/_gbeipoPU logout successful]]

[2014-09-07T12:03:17.433+0700] [glassfish 4.1] [INFO] [] [org.eclipse.persistence.session.file:/home/gbsofts/glassfish4/glassfish/nodes/srv2.gbsofts.com/instance2/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App.connection] [tid: _ThreadID=12622 _ThreadName=RunLevelControllerThread-1410066190958] [timeMillis: 1410066197433] [levelValue: 800] [[
file:/home/gbsofts/glassfish4/glassfish/nodes/srv2.gbsofts.com/instance2/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App logout successful]]

[2014-09-07T12:03:17.439+0700] [glassfish 4.1] [INFO] [ejb.timer_service_shutdown_msg] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=12622 _ThreadName=RunLevelControllerThread-1410066190958] [timeMillis: 1410066197439] [levelValue: 800] [[
EJB5122:EJB Timer Service shutdown at [2014/09/07 12:03:17]]]

[2014-09-07T12:03:17.455+0700] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=12622 _ThreadName=Thread-8] [timeMillis: 1410066197455] [levelValue: 800] [[
JdbcRuntimeExtension, getAllSystemRAResourcesAndPools = [GlassFishConfigBean.org.glassfish.jdbc.config.JdbcResource, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcResource, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcConnectionPool, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcConnectionPool, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcConnectionPool, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcConnectionPool, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcResource, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcResource]]]

[2014-09-07T12:03:17.477+0700] [glassfish 4.1] [INFO] [ra.stop-successful] [javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service] [tid: _ThreadID=12694 _ThreadName=Thread-157] [timeMillis: 1410066197477] [levelValue: 800] [[
RAR7094: __xa_jdbc_ra shutdown successful.]]

[2014-09-07T12:03:17.477+0700] [glassfish 4.1] [INFO] [ra.stop-successful] [javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service] [tid: _ThreadID=12695 _ThreadName=Thread-158] [timeMillis: 1410066197477] [levelValue: 800] [[
RAR7094: __ds_jdbc_ra shutdown successful.]]

[2014-09-07T12:03:17.478+0700] [glassfish 4.1] [INFO] [] [javax.resourceadapter.mqjmsra.lifecycle] [tid: _ThreadID=12698 _ThreadName=Thread-160] [timeMillis: 1410066197478] [levelValue: 800] [[
MQJMSRA_RA1101: GlassFish MQ JMS Resource Adapter stopping...]]

[2014-09-07T12:03:20.695+0700] [glassfish 4.1] [INFO] [] [javax.resourceadapter.mqjmsra.lifecycle] [tid: _ThreadID=12698 _ThreadName=Thread-160] [timeMillis: 1410066200695] [levelValue: 800] [[
MQJMSRA_RA1101: GlassFish MQ JMS Resource Adapter stopped.]]

[2014-09-07T12:03:20.696+0700] [glassfish 4.1] [INFO] [ra.stop-successful] [javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service] [tid: _ThreadID=12693 _ThreadName=Thread-156] [timeMillis: 1410066200696] [levelValue: 800] [[
RAR7094: jmsra shutdown successful.]]

[2014-09-07T12:03:20.696+0700] [glassfish 4.1] [INFO] [NCLS-CLSTR-10108] [javax.enterprise.cluster.gms] [tid: _ThreadID=12618 _ThreadName=Thread-82] [timeMillis: 1410066200696] [levelValue: 800] [[
GMSAdapter for member: instance2 group: gbcluster received GlassfishEventType: server_shutdown]]

[2014-09-07T12:03:20.697+0700] [glassfish 4.1] [INFO] [gms.leave] [ShoalLogger] [tid: _ThreadID=12618 _ThreadName=Thread-82] [timeMillis: 1410066200697] [levelValue: 800] [[
GMS1096: member: instance2 is leaving group: gbcluster]]

[2014-09-07T12:03:20.697+0700] [glassfish 4.1] [INFO] [shutdown.instanceshutdown] [ShoalLogger] [tid: _ThreadID=12618 _ThreadName=Thread-82] [timeMillis: 1410066200697] [levelValue: 800] [[
GMS1010: Leaving GMS group: gbcluster with shutdown type set to InstanceShutdown]]

[2014-09-07T12:03:20.698+0700] [glassfish 4.1] [CONFIG] [mgmt.masternode.processmsgcompleted] [ShoalLogger] [tid: _ThreadID=55 _ThreadName=GMS MasterNode processOutstandingChangeEvents Group-gbcluster] [timeMillis: 1410066200698] [levelValue: 700] [[
GMS1065: Completed processing outstanding master node messages for member: instance2 group: gbcluster outstandingMessages to process: 0]]

[2014-09-07T12:03:20.701+0700] [glassfish 4.1] [INFO] [] [ShoalLogger.monitor] [tid: _ThreadID=12618 _ThreadName=Thread-82] [timeMillis: 1410066200701] [levelValue: 800] [[
BlockingIOMulicastSender monitoring stats: received: 256 core poolsize:10 largest pool size:10 task count:256 max queue size:0 rejected execution:0]]

[2014-09-07T12:03:20.701+0700] [glassfish 4.1] [INFO] [mgmt.blockingiomulticast.threadcomplete] [ShoalLogger] [tid: _ThreadID=53 _ThreadName=IP Multicast Listener for /228.9.3.1:2048] [timeMillis: 1410066200701] [levelValue: 800] [[
GMS1110: Thread IP Multicast Listener for /228.9.3.1:2048 has completed.]]

[2014-09-07T12:03:20.704+0700] [glassfish 4.1] [INFO] [router.stats.monitor.msgqueue.high.water] [ShoalLogger.monitor] [tid: _ThreadID=12618 _ThreadName=Thread-82] [timeMillis: 1410066200704] [levelValue: 800] [[
GMS1115: router signal queue high water mark: 0 signal queue capacity: 600]]

[2014-09-07T12:03:20.704+0700] [glassfish 4.1] [INFO] [sig.handler.thread.terminated] [ShoalLogger] [tid: _ThreadID=22 _ThreadName=GMS SignalHandler for Group-gbcluster thread] [timeMillis: 1410066200704] [levelValue: 800] [[
GMS1107: SignalHandler task named GMS SignalHandler for Group-gbcluster thread exiting]]

[2014-09-07T12:03:20.704+0700] [glassfish 4.1] [INFO] [view.window.thread.terminated] [ShoalLogger] [tid: _ThreadID=23 _ThreadName=GMS ViewWindowThread Group-gbcluster] [timeMillis: 1410066200704] [levelValue: 800] [[
GMS1091: View Window event processing thread for group: gbcluster terminated normally]]

[2014-09-07T12:03:20.704+0700] [glassfish 4.1] [INFO] [msg.wdw.thread.terminated] [ShoalLogger] [tid: _ThreadID=24 _ThreadName=GMS MessageWindowThread Group-gbcluster] [timeMillis: 1410066200704] [levelValue: 800] [[
GMS1088: MessageWindow thread for group: gbcluster terminated due to shutdown notification]]

How can I resolve this problem?






[GLASSFISH-21167] Resource injection not working when empty <absoluteOrdering> is used in web.xml, for classes packed as jars in lib folder Created: 20/Aug/14  Updated: 08/Sep/14

Status: Open
Project: glassfish
Component/s: ejb_container, web_services
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: cristim1979 Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: Windows 7 64bit. Java: 7u67 (also 7u51, 8u11).
Glassfish: 4.0, 4.1-b12 (nightly build)



 Description   

Resource injection does not work, in EJBs of an application (in war format), when these 2 conditions are both met:

1) The application uses, in web.xml file, an empty <absoluteOrdering> tag
2) The code (classes) of the application are all packed as jar archives in the [war]\WEB-INF\lib\ folder, instead of included them unpacked in the [war]\WEB-INF\classes\ folder

(purpose for doing this:

  • 1: for disabling altogether the scanning for web-fragment.xml files in all of the included library jar files, as not necessary;
  • 2: for applications with a big codebase, which is structured in separate modules, easy to pack as separate jars)

When the 2 conditions are met, resource injection does not work.
This is visible for example in EJBs marked with @Singleton @Startup, which have fields marked with @EJB or @Resource:

  • the Singleton beans are identified and constructed by the container
  • then resource injection for fields is skipped ?
  • then the methods marked with @PostConstruct are identified and called, but they may result in NullPointerException if using the fields expected to be injected by now.

If any of the 2 conditions is changed (either remove <absoluteOrdering/> tag OR include the ejb classes unpacked, in the WEB-INF\classes folder), injection works as it should.

This works well on older Glassfish 3.1.2.2 version.
Fails on 4.0 version; also tested on latest promoted nightly build, 4.1-b12, and still fails.



 Comments   
Comment by cristim1979 [ 20/Aug/14 ]

Test example:

1) Have a simple application with just 2 Singleton EJBs:
TestSingleton1.java:

package com.spmsoftware.test;

import javax.annotation.PostConstruct;
import javax.annotation.Resource;
import javax.ejb.EJB;
import javax.ejb.Singleton;
import javax.ejb.Startup;
import javax.ejb.TimerService;

@Singleton
@Startup
public class TestSingleton1 {
    @Resource
    public TimerService timerService;
    @EJB
    public TestSingleton2 testSingleton2;

    public TestSingleton1() {
        System.out.println("In TestSingleton1 constructor: injected fields state: @Resource timerService=" + timerService + "; @EJB testSingleton2=" + testSingleton2);
    }

    @PostConstruct
    public void init() {
        System.out.println("In TestSingleton1 @PostConstruct method: injected fields state: @Resource timerService=" + timerService + "; @EJB testSingleton2=" + testSingleton2);
    }
}

TestSingleton2.java:

package com.spmsoftware.test;

import javax.annotation.PostConstruct;
import javax.ejb.Singleton;

@Singleton
public class TestSingleton2 {
    public TestSingleton2() {
        System.out.println("TestSingleton2 constructor called.");
    }

    @PostConstruct
    public void init() {
        System.out.println("TestSingleton2 @PostConstruct method called.");
    }
}

2) Define also a web.xml file for the app:

<?xml version="1.0" encoding="UTF-8"?>
<web-app 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/web-app_3_1.xsd"
         version="3.1">

    <!-- Just to ignore / not scan any web-fragment.xml files from jar files -->
    <absolute-ordering/>

</web-app>

3) Compile classes and pack the application as a war with this structure:

  • [test_app.war] (exploded, as folder)
    • in WEB-INF folder: the web.xml file
    • in WEB-INF\lib\ folder: a jar archive, test_app.jar, containing the compiled singleton classes

Testing:
Deploy the test application war on GF 4.0, and check console/log output related to the test singletons:

a) Incorrect output - when run on current GF 4.0 (note the null values on last line):

  EJB5181:Portable JNDI names for EJB TestSingleton1: [java:global/test_app_war_ejb_classes_packed_in_jar/TestSingleton1!com.spmsoftware.test.TestSingleton1, java:global/test_app_war_ejb_classes_packed_in_jar/TestSingleton1]
  In TestSingleton1 constructor: injected fields state: @Resource timerService=null; @EJB testSingleton2=null
  EJB5181:Portable JNDI names for EJB TestSingleton2: [java:global/test_app_war_ejb_classes_packed_in_jar/TestSingleton2!com.spmsoftware.test.TestSingleton2, java:global/test_app_war_ejb_classes_packed_in_jar/TestSingleton2]
  TestSingleton2 constructor called.
  In TestSingleton1 constructor: injected fields state: @Resource timerService=null; @EJB testSingleton2=null
  In TestSingleton1 @PostConstruct method: injected fields state: @Resource timerService=null; @EJB testSingleton2=null

b) Correct output - when run on GF 3.1.2.2 (or on GF 4 with one of the 2 conditions changed) - similar, except for the last line:

  In TestSingleton1 @PostConstruct method: injected fields state: @Resource timerService=com.sun.ejb.containers.EJBTimerServiceWrapper@7ec0c910; @EJB testSingleton2=com.spmsoftware.test.TestSingleton2@22d07a73
Comment by cristim1979 [ 08/Sep/14 ]

Any update on this / any plans to handle it in 4.1 release ?





[GLASSFISH-21087]  ManagedExecutorService does not execute tasks submitted during application startup Created: 12/Jun/14  Updated: 01/May/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: tomdcc Assignee: Srini
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 4.0, Java 7, currently testing on Windows 7



 Description   

I'm attempting to schedule a task from inside a singleton bean which is initialised at startup:

@Singleton
@Startup
public class StartupSingleton {
      @Resource
      ManagedExecutorService executorService;

      @PostConstruct
      public void init() {
            System.out.println("init");
            Future<?> future = executorService.submit(new Runnable() {
                  public void run() {
                        System.out.println("run");
                  }
            });
            
            try {
                  Thread.sleep(1000);
                  if(future.isDone()) {
                        future.get();
                        System.out.println("ok");
                  } else {
                        System.out.println("not run");
                  }
            } catch (Exception e) {
                  e.printStackTrace();
            }
      }
}

I then get the following in the logs:

2014-06-10T15:45:07.497+0930|Info: init
2014-06-10T15:45:08.499+0930|Severe: java.util.concurrent.ExecutionException: javax.enterprise.concurrent.AbortedException: Module glassfish-executor-test is disabled
      at java.util.concurrent.FutureTask.report(FutureTask.java:122)
      at java.util.concurrent.FutureTask.get(FutureTask.java:188)
      at foo.StartupSingleton.init(StartupSingleton.java:33)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      at java.lang.reflect.Method.invoke(Method.java:606)
      at com.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.GeneratedMethodAccessor129.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      at java.lang.reflect.Method.invoke(Method.java:606)
      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.GeneratedMethodAccessor130.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      at java.lang.reflect.Method.invoke(Method.java:606)
      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:475)
      at com.sun.ejb.containers.AbstractSingletonContainer.access$000(AbstractSingletonContainer.java:81)
      at com.sun.ejb.containers.AbstractSingletonContainer$SingletonContextFactory.create(AbstractSingletonContainer.java:654)
      at com.sun.ejb.containers.AbstractSingletonContainer.instantiateSingletonInstance(AbstractSingletonContainer.java:396)
      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 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:744)
Caused by: javax.enterprise.concurrent.AbortedException: Module glassfish-executor-test is disabled
      at org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.run(ManagedFutureTask.java:146)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
      at java.lang.Thread.run(Thread.java:744)

And the submitted task is not run. (glassfish-executor-test is just the name of the standalone test case that I created).

Surely either the executor service should be initialized and available by the time @PostConstruct stuff is executed, or it should queue submitted tasks and execute them once the application is started.

This is just using the default managed executor service in a default domain.xml file.



 Comments   
Comment by kingsob [ 23/Jun/14 ]

I am seeing the same thing. Is this a bug? How else would I add a task to the executor on ejb start up?

Comment by mreichman [ 14/Jul/14 ]

Also seeing the same in 4.0.1b8, from an @Asynchronous method called from a @PostConstruct.

Was able to work around it by throwing a Thread.sleep in my @Asynchronous method, but that is certainly not a workable solution.

Comment by afcarv [ 17/Dec/14 ]

Got the same issue. Are you using module/application versioning?

Cause appears to be some mix-up at "org.glassfish.concurrent.runtime.ContextSetupProviderImpl"; method "isApplicationEnabled" checks to see if the current context application is enabled, but I think the app name contains only the base name (e.g. "my-application") while the app list contains the full name (e.g. "my-application:1.0.0"). So no match is found.

I was able to work around by deploying the app without the version but the obvious consequence is losing the versioning feature. Not sure if there's a better way.

Comment by jiggster [ 28/Apr/15 ]

You can configure the deployment order of the ManagedExecutorService resource. Set it to some low value (e.g. 0, by default it's 100), restart the server and check if that helped.

Comment by payara_steve [ 01/May/15 ]

This is a related issue with the same cause https://java.net/jira/browse/GLASSFISH-21216





[GLASSFISH-21063] Getting Exception during Junit testing of Ejb Created: 12/May/14  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2_dev
Fix Version/s: None

Type: Bug Priority: Major
Reporter: brainwash10 Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64 bit, eclipse 3.2, Junit 4, glassfish3.1.2


Status Whiteboard:

org.jvnet.hk2.component.ComponentException: injection failed on com.sun.enterprise.v3.server.ServerContextImpl.env with class caused by NullpointerException


 Description   

org.jvnet.hk2.component.ComponentException: injection failed on com.sun.enterprise.v3.server.ServerContextImpl.env with class org.glassfish.server.ServerEnvironmentImpl
at org.jvnet.hk2.component.InjectionManager.error_injectionException(InjectionManager.java:284)
at org.jvnet.hk2.component.InjectionManager.inject(InjectionManager.java:165)
at org.jvnet.hk2.component.InjectionManager.inject(InjectionManager.java:93)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:126)
at com.sun.hk2.component.ConstructorCreator$1.run(ConstructorCreator.java:86)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:83)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
at org.jvnet.hk2.component.Habitat.getByContract(Habitat.java:1050)
at com.sun.enterprise.naming.impl.SerialContext.<init>(SerialContext.java:322)
at com.sun.enterprise.naming.impl.SerialContext.<init>(SerialContext.java:334)
at com.sun.enterprise.naming.impl.SerialInitContextFactory.createInitialContext(SerialInitContextFactory.java:358)
at com.sun.enterprise.naming.impl.SerialInitContextFactory.getInitialContext(SerialInitContextFactory.java:353)
at com.sun.enterprise.naming.SerialInitContextFactory.getInitialContext(SerialInitContextFactory.java:69)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
at javax.naming.InitialContext.init(InitialContext.java:242)
at javax.naming.InitialContext.<init>(InitialContext.java:216)
at com.test.pluginlib.test.UserManagerTest.setUp(UserManagerTest.java:58)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.lang.NullPointerException
at org.glassfish.server.ServerEnvironmentImpl.postConstruct(ServerEnvironmentImpl.java:155)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator$1.run(ConstructorCreator.java:86)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:83)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
at org.jvnet.hk2.component.Habitat.getBy(Habitat.java:1056)
at org.jvnet.hk2.component.Habitat.getByType(Habitat.java:1037)
at com.sun.hk2.component.InjectInjectionResolver.getComponentInjectValue(InjectInjectionResolver.java:159)
at com.sun.hk2.component.InjectInjectionResolver.getValue(InjectInjectionResolver.java:90)
at org.jvnet.hk2.component.InjectionManager.inject(InjectionManager.java:143)
... 44 more






[GLASSFISH-21060] EntityManager injected twice into single stateless session bean method when deployment descriptor exists. Created: 05/May/14  Updated: 04/Jun/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2.2, 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Stephen Davies Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP, RHEL, Java 1.6.0_45, Postgres 9.x, EclipseLink 2.0


Tags: 4_0_1-approved

 Description   

I've inherited a fairly convoluted code base that is using separate databases for regular data and archived data (postgres 9.x). There are two connection pools and two datasources defined in GF.

The app uses JPA 2.0 (EclipseLink) over Postgres as its persistence layer and a persistence.xml file contains two persistence contexts. A stateless session bean is used to manage interactions with JPA and the 'regular' database. A second SLSB manages interactions with the 'archive' database. The archive bean inherits from the regular bean.

A single EntityManager field is declared by the parent as protected. The parent defines a setter with a @PersistenceContext annotation referencing the regular persistence unit. The child bean overrides the parents setter method and is annotated with @PersistenceContext referencing the archive persistence unit.

When the above is deployed as a .war, an EntityManager for archive is injected ONCE into the child session bean. i.e. system behaves as expected.

If a deployment descriptor declaring the session beans (ejb-jar.xml) is added to the mix then the child session bean will have TWO distinct EntityManagers injected, archive followed by regular.



 Comments   
Comment by Stephen Davies [ 05/May/14 ]

@Stateless(name = "ParentBean")
@LocalBean
public class ParentBean {

protected EntityManager em;

@PersistenceContext(unitName = "regular")
public void setEntityManager(EntityManager em)

{ this.em = em; }

public void doIt() {}

}

Comment by Stephen Davies [ 05/May/14 ]

@Stateless(name = "ChildBean")
@LocalBean
public class ChildBean extends ParentBean {

@PersistenceContext(unitName = "archive")
@Override
public void setEntityManager(EntityManager em)

{ ServerSession session = ((EntityManagerFactoryImpl)em.getEntityManagerFactory()).getServerSession(); System.out.println("### Session name ###"); System.out.println(session.getName()); this.em = em; }

}

Comment by Stephen Davies [ 05/May/14 ]

@Singleton
@LocalBean
@Startup
public class Launch {

@EJB
private ChildBean cb;

@PostConstruct
public void init()

{ cb.doIt(); }

}

Comment by Stephen Davies [ 05/May/14 ]

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar
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/ejb-jar_3_1.xsd"
version = "3.1">

<enterprise-beans>

<session>
<ejb-name>ParentBean</ejb-name>
<ejb-class>jpa.test.ParentBean</ejb-class>
<session-type>Stateless</session-type>
</session>

<session>
<ejb-name>ChildBean</ejb-name>
<ejb-class>jpa.test.ChildBean</ejb-class>
<session-type>Stateless</session-type>
</session>

</enterprise-beans>

</ejb-jar>





[GLASSFISH-21162] Future.get() Doesn't block Created: 11/Aug/14  Updated: 11/Aug/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gesker Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

NetBeans 8 and JDK 1.8.0_11 and Glassfish 4.1 promoted build 11 on Win8.1 Pro 64

&

JDK 1.8.0_11 and Glassfish 4.1 promoted build 11 on Ubuntu 14.04



 Description   

Code Snippet Below.

When I call (A) refresh from another class using @Schedule (in my ejb) the value of count in refresh is correct and statement (B.1) executes before (A.1).

However, when I call (A) refresh from an @ApplicationScoped bean (in my war) the value of count in refresh is incorrect and statement (A.1) executes before (B.1). Most of the time (B.1) doesn't execute at all. In this scenario count always has a different count.

No exception is thrown.

Method that kicks off the process
(A) public void refresh(String usr)

{ // ... count = count + processRelatedProjectData(); //... logger.log(Level.INFO, "\tExit refresh"); <-- Last statement before exit (A.1) }

Method that uses the @Asynchronous methods
(B) private Integer processRelatedProjectData() {

Future futureA = processProject.processData(Constant.COMPANY_A);
Future futureB = processProject.processData(Constant.COMPANY_B);
Future futureC = processProject.processData(Constant.COMPANY_C);
//... A bunch of these

try

{ count = count + (Integer) futureA.get(); count = count + (Integer) futureB.get(); count = count + (Integer) futureC.get(); //... A bunch of these }

catch (InterruptedException | ExecutionException | CancellationException ex)

{ throw new IllegalStateException("Cannot get the answer", ex); }

logger.log(Level.INFO, "\tEnter processRelatedProjectData"); <-- Last statement before exit (B.1)
}






[GLASSFISH-21157] RuntimeException in TimerService Created: 07/Aug/14  Updated: 07/Aug/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: regisrocha3 Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac OS X, Java EE 7



 Description   

When a system exception occurs during invocation of an EJB (Stateless / Singleton) TimerService, it is discarded and TimerService is not loaded again.

Example:

import java.util.logging.Logger;

import javax.ejb.Schedule;
import javax.ejb.Singleton;
import javax.ejb.Startup;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;

@Startup
@Singleton
public class TestTimerService {

/**

  • LOG
    */
    private static final Logger LOG = Logger.getLogger(TestTimerService.class.getName());

@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
@Schedule(minute = "/1", hour = "", persistent = false)
public void schedule()

{ LOG.info("Timer test............"); Integer.valueOf(1 / 0); // Force RuntimeException }

}

}






[GLASSFISH-21156] Allow disabling iiop-service when MDBs present Created: 06/Aug/14  Updated: 06/Aug/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2.2, 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: realityforge Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 4.0
Java 7u40



 Description   

Currently it is not possible to deploy an MDB and disable all iiop listeners.

This happens due to the following line;

http://grepcode.com/file/repo1.maven.org/maven2/org.glassfish.main.ejb/ejb-full-container/4.0/org/glassfish/ejb/mdb/MessageBeanContainer.java#167

I am not sure if iiop is deemed a hard dependency of mdbs as issues such as GLASSFISH-12669 have brought it up in the past but been closed. If this is the case feel free to close the issue.






[GLASSFISH-21154] Missing Descriptor on Redeploy Created: 04/Aug/14  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: ejb_container, entity-persistence
Affects Version/s: 4.1_dev
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gesker Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK 1.8.0_11, NetBeans 8, Windows 8.1 Pro 64, i7-2600, 16GB RAM



 Description   

After redeploy I'm getting a missing descriptor error. The error is thrown when I call methods with an EntityManager.createNativeQuery() statement.

[snip]
Caused by: javax.persistence.PersistenceException: Exception [EclipseLink-6007] (Eclipse Persistence Services - 2.5.2.v20140319-9ad6abd): org.eclipse.persistence.exceptions.QueryException
Exception Description: Missing descriptor for...
[snip]

On restart of the application server and fresh deploy of the application I do not get this message.

I did not see this behavior in Glassfish 4.0.1 build 8. I'm not sure if this item existed in Glassfish 4.0.1 build 9 but would be glad to check if it would be useful for this bug report.



 Comments   
Comment by gesker [ 11/Aug/14 ]

Issue remains in Glassfish 4.1 build 11





[GLASSFISH-21137] NullPointerException calling ejbContext.getCallerPrincipal(); Created: 20/Jul/14  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0, 4.1_dev
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gcruscoe Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux



 Description   

We have a non null (verified) ejbContext injected into an interceptor

Context is injected (and not null) using:
@Inject
private SessionContext ejbContext;

This interceptor is running as part of the ejb layer. It is intercepting the request to an ejb @Stateless @WebService.

Because it seems to be inconsistent, I want to add one thing I noticed. It seems to be fine if the web service is called directly, but the problem occurs when the web services are called from the web apps deployed on the same app server. That is we have several wars that make their calls to the business layer via web services.

This is obviously a show stopper when using this architecture.

Here is the stack trace of when we call ejbContext..getCallerPrincipal();

2014-07-19 20:17:28.066 - :: WARN [http-listener-2(9)] c.p.p.i.CurrentUserInstaller:60 - Got a NPE while trying to get caller principal from ejbContext
java.lang.NullPointerException: null
at org.apache.catalina.connector.Request.setAttribute(Request.java:2021) ~[web-core.jar:na]
at org.apache.catalina.connector.RequestFacade.setAttribute(RequestFacade.java:585) ~[web-core.jar:na]
at org.jboss.weld.context.beanstore.http.RequestBeanStore.setAttribute(RequestBeanStore.java:53) ~[na:na]
at org.jboss.weld.context.beanstore.AttributeBeanStore.put(AttributeBeanStore.java:125) ~[na:na]
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:99) ~[weld-osgi-bundle.jar:2014-06-18 10:59]
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) ~[weld-osgi-bundle.jar:2014-06-18 10:59]
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:99) [weld-osgi-bundle.jar:2014-06-18 10:59]
at org.jboss.weld.proxies.EJBContext$SessionContext$1591394485$Proxy$_$$_WeldClientProxy.getCallerPrincipal(Unknown Source) ~[weld-osgi-bundle.jar:na]



 Comments   
Comment by gcruscoe [ 30/Jul/14 ]

Wanted to add one more thing. I created a test case for 21118 and was able to use it to reproduce this issue as well. This time I am using 4.0.1 b09 (plus fix for 21118). I am using Java 8u20(ea).

This version of the exception occurs I believe when the session has timed out. It makes sense there is no user principal but it causes a NullPointerException and then the EJBException and rollback making it a big problem.

Here is the stack trace.
2014-07-30 09:48:07.800 - :: ERROR [http-listener-2(10)] com.sun.xml.ws.server.sei.TieHandler:282 - null
javax.ejb.EJBException: null
at com.sun.ejb.containers.EJBContainerTransactionManager.processSystemException(EJBContainerTransactionManager.java:748) ~[ejb-container.jar:na]
at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:698) ~[ejb-container.jar:na]
at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:503) ~[ejb-container.jar:na]
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4566) ~[ejb-container.jar:na]
at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:205) ~[ejb-container.jar:na]
at com.sun.proxy.$Proxy207.getMessage(Unknown Source) ~[na:na]
...
Caused by: java.lang.NullPointerException: null
at com.sun.ejb.containers.EJBContextImpl.getCallerPrincipal(EJBContextImpl.java:411) ~[ejb-container.jar:na]
at sun.reflect.GeneratedMethodAccessor112.invoke(Unknown Source) ~[na:na]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_20-ea]
at java.lang.reflect.Method.invoke(Method.java:483) ~[na:1.8.0_20-ea]
at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:38) ~[weld-osgi-bundle.jar:2014-06-18 10:59]
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) ~[weld-osgi-bundle.jar:2014-06-18 10:59]
at org.jboss.weld.proxies.EJBContext$SessionContext$692107405$Proxy$_$$_WeldClientProxy.getCallerPrincipal(Unknown Source) ~[weld-osgi-bundle.jar:na]
at com.test.interceptors.SystemUserInterceptor.findSystemUser(SystemUserInterceptor.java:27) ~[TestEjb-0.0.1-SNAPSHOT_jar/:na]





[GLASSFISH-21135] EJB TimerThread dies on RejectedExecutionException from EJB thread pool Created: 18/Jul/14  Updated: 18/Jul/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2.2, 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sbarlabanov Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If there are not enough threads in the EJB thread pool, EJB Timers (non persistent?) stop to be executed.
The problem is that the EJB timer thread dies when RejectedExecutionException is thrown.
This happens in com.sun.ejb.containers.EJBTimerService#taskExpired method. The call ejbContainerUtil.addWork(work); does not catch RejectedExecutionException and it kills the thread. After that no EJB timer is executed. The solution would be to surround the code with an appropriate try-catch and log a warning.
We observed this bug on 3.1.2.2. But in 4.0 the code did not change, so I assume that the problem exists in 4.0 as well.






[GLASSFISH-21132] java.lang.IllegalStateException: Unable to retrieve EntityManagerFactory in case when persistence.xml inside EJB module Created: 16/Jul/14  Updated: 18/Jul/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2.2, 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: alexander.v.morozov Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 8.1 Pro x64, JDK 7u13 x64, Maven 3.1



 Description   

I have very strange exception in out EE applications, then persistence.xml resides in EJB-jar. I use CDI+EJB in dev environment and qualifies each EntityManager with own CDI qualifer. If I make EntityManager producer bean EJB-bean (@Stateless), every works fine, but if I change it to Managed Bean (@ApplicationScoped) - got the exception below.

Sample application is attached. Have both maven profiles "glassfish3" and "glassfish4".

javax.ejb.EJBException: null
	at com.sun.ejb.containers.BaseContainer.processSystemException(BaseContainer.java:5215) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:5113) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4915) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2045) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1994) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:222) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:89) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.proxy.$Proxy178.process(Unknown Source) [na:na]
	at my.domain.application.__EJB31_Generated__TimerBean__Intf____Bean__.process(Unknown Source) [application-ejb-1.0-SNAPSHOT_jar/:na]
	at my.domain.application.TimerBean.onTimeout(TimerBean.java:42) [application-ejb-1.0-SNAPSHOT_jar/:na]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_15]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_15]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_15]
	at java.lang.reflect.Method.invoke(Method.java:601) ~[na:1.7.0_15]
	at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5388) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:49) [weld-osgi-bundle.jar:20120429-1045]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_15]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_15]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_15]
	at java.lang.reflect.Method.invoke(Method.java:601) ~[na:1.7.0_15]
	at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundTimeout(SystemInterceptorProxy.java:149) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_15]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_15]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_15]
	at java.lang.reflect.Method.invoke(Method.java:601) ~[na:1.7.0_15]
	at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5360) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5348) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:4058) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1832) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.EJBTimerService.access$100(EJBTimerService.java:108) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:2646) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [na:1.7.0_15]
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [na:1.7.0_15]
	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [na:1.7.0_15]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_15]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_15]
	at java.lang.Thread.run(Thread.java:722) [na:1.7.0_15]
Caused by: java.lang.IllegalStateException: Unable to retrieve EntityManagerFactory for unitName ModulePU
	at com.sun.enterprise.container.common.impl.EntityManagerWrapper.init(EntityManagerWrapper.java:132) ~[container-common.jar:3.1.2.1-SNAPSHOT]
	at com.sun.enterprise.container.common.impl.EntityManagerWrapper.getEntityManagerFactory(EntityManagerWrapper.java:875) ~[container-common.jar:3.1.2.1-SNAPSHOT]
	at my.mydomain.module.ModuleEntityManagerProducer.getEntityManager(ModuleEntityManagerProducer.java:21) ~[module-ejb-1.0-SNAPSHOT_jar/:na]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_15]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_15]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_15]
	at java.lang.reflect.Method.invoke(Method.java:601) ~[na:1.7.0_15]
	at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:267) ~[na:na]
	at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) ~[na:na]
	at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137) ~[na:na]
	at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:263) ~[na:na]
	at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:170) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstance(MethodInjectionPoint.java:137) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.bean.ProducerMethod$ProducerMethodProducer.produce(ProducerMethod.java:136) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.bean.AbstractProducerBean$AbstractProducer.produce(AbstractProducerBean.java:319) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:307) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:68) ~[na:na]
	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:637) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:703) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:136) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:686) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:695) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1$1.proceed(ManagedBean.java:161) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:134) ~[weld-integration.jar:3.1.2.1-SNAPSHOT]
	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:46) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1.work(ManagedBean.java:157) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.bean.ManagedBean$FixInjectionPoint.run(ManagedBean.java:131) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.inject(ManagedBean.java:153) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:293) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:107) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:90) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79) ~[weld-osgi-bundle.jar:20120429-1045]
	at my.mydomain.module.JpaDomainRepository$Proxy$_$$_WeldClientProxy.add(JpaDomainRepository$Proxy$_$$_WeldClientProxy.java) ~[module-ejb-1.0-SNAPSHOT_jar/:na]
	at my.domain.application.TimerBean.process(TimerBean.java:51) [application-ejb-1.0-SNAPSHOT_jar/:na]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_15]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_15]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_15]
	at java.lang.reflect.Method.invoke(Method.java:601) ~[na:1.7.0_15]
	at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5388) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:42) [weld-osgi-bundle.jar:20120429-1045]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_15]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_15]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_15]
	at java.lang.reflect.Method.invoke(Method.java:601) ~[na:1.7.0_15]
	at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_15]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_15]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_15]
	at java.lang.reflect.Method.invoke(Method.java:601) ~[na:1.7.0_15]
	at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5360) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5348) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:214) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	... 43 common frames omitted



 Comments   
Comment by alexander.v.morozov [ 16/Jul/14 ]

Sample application archive is here https://www.sendspace.com/file/dra7f2





[GLASSFISH-21074] Message-driven bean invocation exception: [javax.ejb.EJBException] Created: 27/May/14  Updated: 03/Jun/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: alebor Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

CentOS release 6.4 (Final), Glassfish 3.1.2.2



 Description   

Following exception occurs in GF logs when running JMS load tests for a couple of hours:

[#|2014-05-23T23:47:31.035+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.mdb.com.sun.ejb.containers|_ThreadID=714;_ThreadName=Thread-2;|MDB00037: [ht-ear-2.7.0-SNAPSHOT-PRETTY-7527:ObdMessageBean]: Message-driven bean invocation exception: [javax.ejb.EJBException]|#]

[#|2014-05-23T23:47:31.035+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.mdb.com.sun.ejb.containers|_ThreadID=714;_ThreadName=Thread-2;|javax.ejb.EJBException
javax.ejb.EJBException
at com.sun.ejb.containers.BaseContainer.processSystemException(BaseContainer.java:5215)
at com.sun.ejb.containers.BaseContainer.checkExceptionNoTx(BaseContainer.java:5044)
at com.sun.ejb.containers.BaseContainer.checkExceptionBeanMgTx(BaseContainer.java:4965)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4865)
at com.sun.ejb.containers.MessageBeanContainer.afterMessageDeliveryInternal(MessageBeanContainer.java:1211)
at com.sun.ejb.containers.MessageBeanContainer.afterMessageDelivery(MessageBeanContainer.java:1186)
at com.sun.ejb.containers.MessageBeanListenerImpl.afterMessageDelivery(MessageBeanListenerImpl.java:86)
at com.sun.enterprise.connectors.inbound.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:190)
at com.sun.proxy.$Proxy669.onMessage(Unknown Source)
at com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:260)
at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:114)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Caused by: java.lang.NullPointerException

#]

[#|2014-05-23T23:47:31.035+0200|WARNING|glassfish3.1.2|javax.resourceadapter.mqjmsra.inbound.message|_ThreadID=714;_ThreadName=Thread-2;|MQJMSRA_MR2001: run:Caught Exception from onMessage():Redelivering:
javax.ejb.EJBException: message-driven bean method public abstract void javax.jms.MessageListener.onMessage(javax.jms.Message) system exception
at com.sun.ejb.containers.MessageBeanContainer.deliverMessage(MessageBeanContainer.java:1134)
at com.sun.ejb.containers.MessageBeanListenerImpl.deliverMessage(MessageBeanListenerImpl.java:81)
at com.sun.enterprise.connectors.inbound.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:171)
at com.sun.proxy.$Proxy669.onMessage(Unknown Source)
at com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:260)
at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:114)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Caused by: java.lang.NullPointerException

#]


 Comments   
Comment by alebor [ 03/Jun/14 ]

This issue looks like a duplicate of https://java.net/jira/browse/GLASSFISH-21072 (upper part of the trace from NPE).
I cannot remove it because it do not have the rights.





[GLASSFISH-21042] Interfaces Specified by RemoteHome or LocalHome Not Resolved in SerialContext.lookup as Business Interfaces on EJB Session Beans, Resulting in NPE in JavaGlobalJndiNamingObjectProxy.create Created: 17/Apr/14  Updated: 03/Jun/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jonpasski Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0_1-reviewed, embedded, maven-glassfish-plugin

 Description   

Had the following error in a JUnit test case using the embedded Glassfish 3.1.1 container:

shouldCreateABook(com.coverity.testsuite.ejb.localhome.BookLocalHomeBeanTest):
Communication exception for SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory,
java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl,
java.naming.factory.url.pkgs=com.sun.enterprise.naming}
BookLocalHomeBeanTest.java
package com.coverity.testsuite.ejb.localhome;

import java.io.File;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

import javax.ejb.embeddable.EJBContainer;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.xml.ws.WebServiceRef;

import org.junit.After;
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;

import com.coverity.testsuite.ejb.Book;
import com.coverity.testsuite.ejb.localhome.BookLocal;

import static org.junit.Assert.*;

/**
 *
 * @author pasc
 */
public class BookLocalHomeBeanTest {

    private static EJBContainer ec=null;
    private static Context ctx=null;

    public BookLocalHomeBeanTest() {}

    @BeforeClass
    public static void initContainer() throws Exception {
        Map<String, Object> props=new HashMap<String, Object>();
        props.put(EJBContainer.MODULES, new File("target/embedded-classes"));
        props.put("org.glassfish.ejb.embedded.glassfish.instance.root","./src/test/testing-domain");
        props.put("org.glassfish.ejb.embedded.glassfish.web.http.port","");
        props.put("javax.enterprise.system.container.web", "FINE");
        ec = EJBContainer.createEJBContainer(props);
        ctx = ec.getContext();
    }

    @AfterClass
    public static void closeContainer() throws Exception {
        if(ctx!=null)
            ctx.close();
        if(ec!=null)
            ec.close();
    }

    @Test
    public void shouldCreateABook() throws Exception {
        Book book = new Book();
        book.setTitle("The Hitchhiker's Guide to the Galaxy");
        book.setPrice(12.5F);
        book.setDescription("Scifi book created by Douglas Adams");
        book.setIsbn("1-84023-742-2");
        book.setNbOfPages(354);
        book.setIllustrations(false);

        Object obj = ctx.lookup("java:global/embedded-classes/BookLocalHomeBean");
        BookLocalHome bookHome = (BookLocalHome) obj;
        BookLocal bookLocal = bookHome.createBook(book);
        book = bookLocal.findBookById(book.getId());
        assertNotNull("Book should not be null", book);
        assertNotNull("ID should not be null", book.getId());
    }
}

The application I'm using is a modified version of embedded-glassfish-example:

BookLocal.java
package com.coverity.testsuite.ejb.localhome;

import java.util.List;
import javax.ejb.EJBLocalObject;

import com.coverity.testsuite.ejb.Book;

public interface BookLocal extends EJBLocalObject {

    void deleteBook(Book book);

    Book findBookById(Long id);

    List<Book> findBooks();

    Book updateBook(Book book);
}
BookLocalHome.java
package com.coverity.testsuite.ejb.localhome;

import javax.ejb.EJBLocalHome;
import javax.ejb.CreateException;

import com.coverity.testsuite.ejb.Book;

public interface BookLocalHome extends EJBLocalHome {

    public BookLocal createBook(Book book) throws CreateException;
}
BookLocalHomeBean.java
package com.coverity.testsuite.ejb.localhome;

import java.util.List;
import javax.ejb.Stateful;
import javax.ejb.LocalHome;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import javax.annotation.Resource;
import javax.ejb.SessionContext;

import com.coverity.testsuite.ejb.Book;

/**
 *
 * @author pasc
 */
@Stateful
@LocalHome(BookLocalHome.class)
public class BookLocalHomeBean {
    @PersistenceContext(unitName = "bookstore-ejb")
    EntityManager em;

    @Resource
    private SessionContext sessionContext;

    public List<Book> findBooks() {
        return em.createNamedQuery("Book.findAllBooks", Book.class).getResultList();
    }

    public Book findBookById(Long id) {
        return em.find(Book.class, id);
    }

    public void ejbCreateBook(Book book) {
        em.persist(book);
    }

    public void deleteBook(Book book) {
        em.remove(em.merge(book));
    }

    public Book updateBook(Book book) {
        return em.merge(book);
    }
}

The above code hasn't been validated another embedded EJB container, therefore it could be incorrect. It seems correct, based on looking at the JBoss quick start EJB test cases.

I enabled logging within Glassfish by specifying the following in a .properties file:

handlers= java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.level=FINEST
com.sun.enterprise.naming.level=FINEST

com.sun.enterprise.naming is specified in LogFacade, used as SerialContext's logger. Passing it to Maven as mvn clean test -Djava.util.logging.config.file=src/test/resources/customlogging.properties results in the nice stack trace, trimmed below:

Apr 16, 2014 11:42:55 AM com.sun.enterprise.naming.impl.SerialContext <init>
FINE: SerialContext ==> SerialContext instance created : SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory,
  java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl,
  java.naming.factory.url.pkgs=com.sun.enterprise.naming}
Apr 16, 2014 11:42:55 AM com.sun.enterprise.naming.impl.SerialContext <init>
FINE: Serial Context initializing with process environment org.glassfish.api.admin.ProcessEnvironment@7a341251
Apr 16, 2014 11:42:55 AM com.sun.enterprise.naming.impl.SerialContext lookup
FINE: SerialContext ==> lookup( java:global/embedded-classes/BookLocalHomeBean)
Apr 16, 2014 11:42:55 AM com.sun.enterprise.naming.impl.SerialContext lookup
FINE: SerialContext ==> lookup relative name : java:global/embedded-classes/BookLocalHomeBean
Apr 16, 2014 11:42:55 AM com.sun.enterprise.naming.impl.SerialContextProviderImpl lookup
FINE:  SerialContextProviderImpl :: lookup java:global/embedded-classes/BookLocalHomeBean
Apr 16, 2014 11:42:55 AM com.sun.enterprise.naming.impl.SerialContext lookup
FINE: enterprise_naming.serialctx_communication_exception
Apr 16, 2014 11:42:55 AM com.sun.enterprise.naming.impl.SerialContext lookup
FINE:
java.lang.NullPointerException
        at com.sun.ejb.containers.JavaGlobalJndiNamingObjectProxy.create(JavaGlobalJndiNamingObjectProxy.java:65)
        at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
        at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)

Kicking up Eclipse and debugging the app showed the following:

com.sun.ejb.containers.JavaGlobalJndiNamingObjectProxy.create(Context)
/*    */   public Object create(Context ic) {
/* 63 */     GenericEJBLocalHome genericLocalHome = this.container.getEJBLocalBusinessHome(this.intfName);
/*    */     
/* 65 */     return genericLocalHome.create(this.intfName);
/*    */   }
  • this.intfName = com.coverity.testsuite.ejb.localhome.BookLocalHome
  • genericLocalHome = null

null is being passed into the create call, which triggers the NPE. Looking into `getEJBLocalBusinessHome`:

com.sun.ejb.containers.BaseContainer.getEJBLocalBusinessHome(String)
/*      */   public final GenericEJBLocalHome getEJBLocalBusinessHome(String clientViewClassName)
/*      */   {
/* 1016 */     return isLocalBeanClass(clientViewClassName) ? this.ejbOptionalLocalBusinessHome : this.ejbLocalBusinessHome;
/*      */   }
  • clientViewClassName = com.coverity.testsuite.ejb.localhome.BookLocalHome
  • this.ejbOptionalLocalBusinessHome = null
  • this.ejbLocalBusinessHome = null

Both are null. Let's see which one should have been picked:

com.sun.ejb.containers.BaseContainer.isLocalBeanClass(String)
/*      */   boolean isLocalBeanClass(String className)
/*      */   {
/* 1023 */     return (this.hasOptionalLocalBusinessView) && ((className.equals(this.ejbClass.getName())) || (className.equals(this.ejbGeneratedOptionalLocalBusinessIntfClass.getName())));
/*      */   }
  • this.hasOptionalLocalBusinessView = false
  • className == com.coverity.testsuite.ejb.localhome.BookLocalHome
  • this.ejbClass.getName() == com.coverity.testsuite.ejb.localhome.BookLocalHomeBean
  • this.ejbGeneratedOptionalLocalBusinessIntfClass.getName() == null

isLocalBeanClass returns false. Assuming the bug isn't lurking above, this.ejbLocalBusinessHome should not be null.

Now, BaseContainer is the abstract class. Eclipse is telling me the actual type is com.sun.ejb.containers.StatefulSessionContainer. StatefulSessionContext doesn't set the field ejbLocalBusinessHome. Grepping around ejbLocalBusinessHome is set in BaseContainer:

com.sun.ejb.containers.BaseContainer.initializeHome()
/* 1444 */       if (this.hasLocalBusinessView) {
/* 1445 */         this.ejbLocalBusinessHomeImpl = instantiateEJBLocalBusinessHomeImpl();
/*      */         
/* 1447 */         this.ejbLocalBusinessHome = ((GenericEJBLocalHome)this.ejbLocalBusinessHomeImpl.getEJBLocalHome());
/*      */       

To get to that point, isLocal} needs to be true, which it is in this run. For the field to be set, {{this.hasLocalBusinessView needs to be true, which it isn't in this run. BaseContainer sets it only in one spot. (StatefulSessionContainer does reference it; it just doesn't set it.):

com.sun.ejb.containers.BaseContainer.BaseContainer(ContainerType, EjbDescriptor, ClassLoader)
/*  650 */         if (this.ejbDescriptor.isLocalBusinessInterfacesSupported()) {
/*  651 */           this.isLocal = true;
/*  652 */           this.hasLocalBusinessView = true;
  • this.ejbDescriptor = com.sun.enterprise.deployment.EjbSessionDescriptor

And digging into isLocalBusinessInterfacesSupported:

com.sun.enterprise.deployment.EjbAbstractDescriptor.isLocalBusinessInterfacesSupported()
/*     */   public boolean isLocalBusinessInterfacesSupported()
/*     */   {
/* 278 */     return this.localBusinessClassNames.size() > 0;
/*     */   }
  • this.ejbDescriptor.localBusinessClassNames == []

Well, shucks. localBusinessClassNames is set in a ctor and also com.sun.enterprise.deployment.EjbAbstractDescriptor.addLocalBusinessClassName(String):

com.sun.enterprise.deployment.EjbAbstractDescriptor.addLocalBusinessClassName(String)
/*     */   public void addLocalBusinessClassName(String className) {
/* 185 */     this.localBusinessClassNames.add(className);
/*     */   }

Eclipse is saying it's only called by org.glassfish.ejb.deployment.annotation.handlers.AbstractEjbHandler.setBusinessAndHomeInterfaces(EjbDescriptor, AnnotationInfo), whoop. Debugging that method shows this:

org.glassfish.ejb.deployment.annotation.handlers.AbstractEjbHandler.setBusinessAndHomeInterfaces(EjbDescriptor, AnnotationInfo)
...
/* 452 */     if (localBusIntfs.size() > 0) {
/* 453 */       for (Class next : localBusIntfs) {
/* 454 */         ejbDesc.addLocalBusinessClassName(next.getName());
/*     */       }
/*     */     }

And since the EJB bean doesn't have any business interfaces implemented, (as defined by JSR), localBusIntfs is null. From JSR 318:

While it is expected that the bean class will typically implement its business inter- face(s), if the bean class uses annotations or the deployment descriptor to designate its business interface(s), it is not required that the bean class also be specified as imple- menting the interface(s).

In my test case the EJB doesn't implement the interface. But the only way the logic above would not cause the NPE is if a business interface is found. To me that seems like a bug in Glassfish. I'd think the Local interface would have been returned. I dunno what the right thing is, though. Assuming the code above is valid, then yeah, it's a bug.






[GLASSFISH-20803] Transaction is not committed when launching disable sub-command Created: 09/Sep/13  Updated: 09/Sep/13

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: xj Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Tags: licbug

 Description   

Symptom:

With EJB's CMT(Container-Managed Transactions) in Java EE 7 RI, the
following exception is thrown if "asadmin disable" command is launched
when business method is till in execution.

javax.ejb.EJBException: Attempt to invoke when container is in STOPPED

However, rollback never be executed.

It seems a bug exists in the code at com.sun.ejb.containers.BaseContainer.java#postInvoke(EjbInvocation, boolean).

REPRODUCE:

The attached test case is for OracleDB.

1) Run the attached createTable_Oracle.sql and create testtable in DB
2) Run start-domain.bat and start the domain(default domain1)
3) Run the attached create-jdbc.bat and create JDBC resources
4) Run the attached deploy.bat and deploy applications
5) Click URL.url to open a browser and show adder.html
6) Input some value in the text box and click "Send query" button

This step does:

  • Accesses to EJB from servlet
  • Update testtable (update the value of balance with id:001 )
  • Sleep 10 seconds

7) When the above step 6) is running, invoke disable.bat to stop the application

Here, javax.ejb.EJBException is thrown and the message
500 Internal Server Error
shows up.

Then, confirm the contents of testtabel in DB.
The value should be the previous value (the value before update)

8) Run the attached stop-domain.bat to stop the domain

Then, confirm the contents of testtabel in DB.
The value is updated.(value after update)

At step 7), if rollback is executed and the value in DB is the previous value,
this is what expected behavior.
However, transaction is committed at step 8) which should have happened at step 7). As a result, the value is updated incorrectly.






[GLASSFISH-20749] Glassfish expunges timer even if callback method keeps its contract Created: 07/Aug/13  Updated: 13/Sep/13

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: obfischer Assignee: marina vatkina
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: portability, timer

 Description   

Glassfish expunges the timer of a callback method if during the execution of the callback method a called services throws an application exception. The timer will be expunged even if the callback method handles the exception and finishes properly.

On the mailing list Marina Vatikna commented on my post:

GF retries once (you can change the setting to retry more times), but after all retries failed, the timer is expunged.

In my opinion the timer must not be expunged. The EJB 3.1 and 3.2 specification require only that a callback method does not throw an exception. In the scenario described above the callback method fullfils this requirement.

From my point of view this behaviour makes it impossible to write a reliable service because as the programmer of the callback method the only thing I can do is to read and to keep the requirements of the specification.

Furthermore the only possible solution to recover from this scenario is