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

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

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

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


Tags: logout, session, weld

 Description   

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

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

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

Line 65 in WeldTerminalListener:

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


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

Can you provide a test case to illustrate this?

Comment by dmatej [ 19/Aug/14 ]

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

Comment by dmatej [ 20/Aug/14 ]

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

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

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

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

Does someone know why and how to fix it?

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

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

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

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

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

Comment by dmatej [ 21/Aug/14 ]

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

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

Comment by dmatej [ 21/Aug/14 ]

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

Comment by reza_rahman [ 21/Aug/14 ]

Could you kindly send it to me for now?

Comment by dmatej [ 02/Sep/14 ]

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

Comment by reza_rahman [ 02/Sep/14 ]

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

Comment by dmatej [ 13/Sep/14 ]

Please only move the attachment from GLASSFISH-21146 here.

Comment by Wydrian [ 19/Sep/14 ]

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

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

Comment by cistox [ 16/Nov/15 ]

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

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

Comment by payara_steve [ 25/Feb/16 ]

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

Comment by lprimak [ 25/May/16 ]

This issue will be resolve in Payara with the next release





[GLASSFISH-21495] Transaction Rolled back due to timeout Created: 26/Jan/16  Updated: 25/May/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: 5
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.





[GLASSFISH-17281] javax.ejb.AsyncResult in Remote interfaces with DTOs generates ClassCastException on client Created: 08/Sep/11  Updated: 23/May/16

Status: In Progress
Project: glassfish
Component/s: orb
Affects Version/s: 3.1.1_b12
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: vins4java Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows Vista SP2
JDK 1.6.0_26


Attachments: Zip Archive AsyncTestCase-src.zip     File module-a-ear.ear     File module-b-ear.ear    
Tags: 3_1_2-exclude, asynchronous, ejb31

 Description   

Scenario:

  • 2 ear apps say A and B (module-a-ear and module-b-ear)
  • each ear has contains an ejb-jar (module-a-ejb and module-b-ejb)
  • A's ejb exposes remote interface with an @Asyncronous method
  • the asyncronous method returns a serializable DTO (ADto)
  • both A and B have the same copy of A's ejbClient in their ear's root (module-a-ejbClient.jar)

when a method of B calls a remote asynch method on A, the call is perfomed but when Future<ADto> is done, on module-b-ejb side a ClassCastException is thrown when invoking:
ADto wrappedDto = futureDto.get();

EJB 3.1 specs don't make dinstinction about local or remote interface for @Asynchrouse annotation.They also don't put any limitation in Future<V>, so Data Transfer Objects (serializable) must be supported, right?

In order to have a very simple test case (didn't want to create JEE appclient..) I've annotated module-b-ejb as WebService so that you can call module-b-ejb method via glassfish admin gui webservice tester. You can find a stacktrace in the attached zip file. I also provided the 2 deployable ear files.

IMHO:
Debugging on client side (using eclipse debugger) I had a look at classloader of the ADto instance received from A: it's the A's classloader, not B's! It's strange because I tried also to change method in the "old traditional" synch fashion( public ADto doAsync() ) and on client side the returning ADto correclty comes from A's classloader. Does this help?



 Comments   
Comment by vins4java [ 14/Oct/11 ]

any update on this issue?

Comment by Cheng Fang [ 14/Oct/11 ]

I was able to reproduce it on trunk build. Stack trace is the same as in your attachment(except slightly different line numbers):

        at com.sun.ejb.containers.BaseContainer.processSystemException(BaseContainer.java:5219)
        at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:5117)
        at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4905)
        at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:207)
        at $Proxy234.testIt(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 org.glassfish.webservices.InvokerImpl.invoke(InvokerImpl.java:82)
        at org.glassfish.webservices.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82)
        at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:150)
        at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:261)
        at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:100)
        at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:641)
        at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600)
        at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585)
        at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482)
        at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:116)
        at org.glassfish.webservices.MonitoringPipe.process(MonitoringPipe.java:142)
        at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:119)
        at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:641)
        at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600)
        at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585)
        at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482)
        at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:116)
        at com.sun.enterprise.security.webservices.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:212)
        at com.sun.enterprise.security.webservices.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:144)
        at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:119)
        at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:641)
        at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600)
        at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585)
        at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482)
        at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:314)
        at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:608)
        at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:259)
        at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:162)
        at org.glassfish.webservices.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:116)
        at org.glassfish.webservices.Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:87)
        at org.glassfish.webservices.EjbWebServiceServlet.dispatchToEjbEndpoint(EjbWebServiceServlet.java:198)
        at org.glassfish.webservices.EjbWebServiceServlet.service(EjbWebServiceServlet.java:129)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
        at org.glassfish.grizzly.servlet.ServletHandler$FilterChainImpl.doFilter(ServletHandler.java:985)
        at org.glassfish.grizzly.servlet.ServletHandler$FilterChainImpl.invokeFilterChain(ServletHandler.java:928)
        at org.glassfish.grizzly.servlet.ServletHandler.doServletService(ServletHandler.java:382)
        at org.glassfish.grizzly.servlet.ServletHandler.service(ServletHandler.java:335)
        at com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:113)
        at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236)
        at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:163)
        at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:161)
        at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:286)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:223)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:155)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:134)
        at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:78)
        at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:827)
        at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:103)
        at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:111)
        at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
        at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:131)
        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: java.lang.ClassCastException: module.a.ejb.ADto cannot be cast to module.a.ejb.ADto
        at module.b.ejb.BBean.testIt(BBean.java:36)
        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:5392)
        at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:624)
        at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:790)
        at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:576)
        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:851)
        at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:790)
        at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:361)
        at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5364)
        at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5352)
        at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:195)
        ... 60 more
Comment by Cheng Fang [ 18/Oct/11 ]

If you do not call future.isDone() on the client side, I suspect it will work.

Comment by vins4java [ 18/Oct/11 ]

unfortunately your suspect seems to be wrong: I get the same error even if I comment isDone() call on client ejb.
I've tested this modification on Glassfish 3.1.1-build12 ( on ubuntu with java-6-sun-1.6.0.26 ).
Did you try it with trunk version (3.2)?

Comment by Cheng Fang [ 19/Oct/11 ]

Looks like the payload didn't go thru proper marshalling and unmarshalling when both sides are colocated. It could also be some caching problem.

Comment by vins4java [ 25/Oct/11 ]

So you tried deploying each ear in two different JVMs (on the same physical machine or two different ones) and it worked, or you are supposing so? let me know if there's a way for me to help you to solve this problem. We are going to rely on this feature in short/med term...

Comment by Cheng Fang [ 25/Oct/11 ]

If the two modules are deployed into separate JVM, either same host or different hosts, that should work.
There is total separation of classloaders and so shouldn't be any CCE. What I found now is the DAO instance
on the ejb server side is different from the DAO instance on the client side, which means the serialization and
deserialization did happen. But the wrong classloader (the server side classloader) was used to reconstruct
the DAO on the client side. The client side application classloader should've been used for that.

Another complication is it is not the Java serialization protocol that's been used here. I'm trying to find out
how classloader is picked to copy objects by GlassFish corba and its related modules (see
glassfish.home/modules/glassfish-corba-orb.jar, pfl*.jar).

Again I think this issue only happens with all of the following:
remote async ejb method invocations;
both client and server modules are colocated in the same JVM;
some application class (e.g., business interface classes) are duplicated in both client and server modules

If you package client module and ejb module inside the same EAR file, and extract all shared classes into EAR/lib/xxx.jar,
without duplicating them in client and ejb modules, that should help avoid this CCE. I just tried it and worked.

Comment by Cheng Fang [ 04/Nov/11 ]

In org/glassfish/pfl/dynamic/copyobject/impl/ClassCopierOrdinaryImpl (in modules/pfl-dynamic.jar)
obj.getClass() is called to get the Class, which is then used to create a class copier, which in turn creates the constructor. It is hence associated with the class loader of the source object, not the target.

This part of the code is executed to copy all fields of a source object.

After changing to use thread context class loader in instead of
obj.getClass(), it worked without CCE. There could be other places the kind of changes are also necessary. Also not clear about the full implication or side effects.

Comment by Cheng Fang [ 04/Nov/11 ]

re-assign to orb team for further evaluation.

Comment by Harshad Vilekar [ 15/Dec/11 ]

Cheng and I exchanged email on this - and decided to target this issue post 3.1.2

Comment by juergenschmied [ 23/Nov/12 ]

I get this problem after upgrading from 3.1.2 to 3.1.2.2. A application that was working before is now broken with this error. Would it help do use a Future<ByteArrayOutputStream> an do serialization/deserialization by myself? It looks like this bug does not affect build-in classes.

Thanks!

Comment by wfsaxton [ 23/May/16 ]

This bug is very old. Is it really still being worked on? Is there a workaround available?

This issue still exists in GF 4.1.





[GLASSFISH-21314] Cannot create JDBC Connection Pool Created: 23/Feb/15  Updated: 23/May/16  Resolved: 08/Jan/16

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.1.1
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: doobrie Assignee: Arindam Bandyopadhyay
Resolution: Fixed Votes: 12
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
is blocked by JERSEY-2861 Glassfish REST API - OPTIONS request ... Closed
Duplicate
is duplicated by GLASSFISH-21353 Cannot Create JDBC Resource or Connec... Closed
is duplicated by GLASSFISH-21524 Cannot create a JDBC Resource or a Co... Closed
Tags: javaee_ri_fix

 Description   

When attempting to create a new JDBC connection pool, GlassFish errors with the exception:

java.lang.IllegalStateException: getOutputStream() has already been called for this response

To reproduce, using the latest builds (from 23 Feb 2015):

1. Select Create New JDBCConnection Pool
2. Enter any valid information on Step 1 of 2 (New JDBC Connection Pool page)
3. Click the Next button and the error is thrown.

The full stack tace from the log files is as follows:

[2015-02-23T22:06:15.124+0000] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=178 _ThreadName=admin-listener(8)] [timeMillis: 1424729175124] [levelValue: 900] [[
StandardWrapperValve[FacesServlet]: Servlet.service() for servlet FacesServlet threw exception
java.lang.IllegalStateException: getOutputStream() has already been called for this response
at org.apache.catalina.connector.Response.getWriter(Response.java:777)
at org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:224)
at com.sun.faces.context.ExternalContextImpl.getResponseOutputWriter(ExternalContextImpl.java:846)
at com.sun.faces.context.PartialViewContextImpl.createPartialResponseWriter(PartialViewContextImpl.java:504)
at com.sun.faces.context.PartialViewContextImpl.access$300(PartialViewContextImpl.java:79)
at com.sun.faces.context.PartialViewContextImpl$DelayedInitPartialResponseWriter.getWrapped(PartialViewContextImpl.java:642)
at javax.faces.context.PartialResponseWriter.startDocument(PartialResponseWriter.java:120)
at com.sun.faces.context.AjaxExceptionHandlerImpl.handlePartialResponseError(AjaxExceptionHandlerImpl.java:201)
at com.sun.faces.context.AjaxExceptionHandlerImpl.handle(AjaxExceptionHandlerImpl.java:126)
at javax.faces.context.ExceptionHandlerWrapper.handle(ExceptionHandlerWrapper.java:100)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)
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.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
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.doChainInvoke(StandardPipeline.java:678)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
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)
]]

[2015-02-23T22:09:25.421+0000] [glassfish 4.1] [INFO] [] [org.glassfish.admingui] [tid: _ThreadID=53 _ThreadName=admin-listener(3)] [timeMillis: 1424729365421] [levelValue: 800] [[
Exception Occurred :null]]



 Comments   
Comment by nabizamani [ 24/Feb/15 ]

What DB and version are you using? What JDBC driver are you using?

Did you also try via asadmin? Here you can see how it works via asadmin and with postgres: https://www.nabisoft.com/tutorials/glassfish/using-glassfish-3-and-java-ee-6-for-longitude-latitude-calculations-to-implement-server-side-location-based-services#Step3
Probably this helps you...

A few days ago I had a similar issue when I tried to connect to the latest Postgres 9.4.1 via its latest JDBC driver. Unfortunately, it did not work at all and I thought there is a bug somewhere in Glassfish. Then I found out that the latest JDBC driver (9.4-1200-jdbc41) for Postgres has a bug, see: https://github.com/pgjdbc/pgjdbc/pull/257

However, I also get many "java.lang.IllegalStateException: getOutputStream() has already been called for this response" exceptions in my log file

Comment by tovine [ 11/Mar/15 ]

I also got this error today (running Postgresql 9.3 and the latest JDBC driver, however the error was the same before I even included the jdbc jar in the glassfish lib folder).

Tried with the latest nightly (4.1-b13 from 2015-03-09).

UPDATE: it works with the nightly build dated 2015-02-18, so it must have happened sometime during that week...

Comment by Romain Grécourt [ 11/Mar/15 ]

Can you try against the following builds?

Thanks,
Romain

Comment by Arindam Bandyopadhyay [ 15/May/15 ]

Duplicate to GLASSFISH-21353.
This is a Jersey 2.16 integration issue.The functionality is broken on 2015-02-18 due to Jersey 2.16 integration. From buildDefaultValueMap function of appserver/admingui/common/src/main/java/org/glassfish/admingui/common/util/RestUtil.java we are calling HTTP options method to populate the default value. However OPTIONS request with Accept header is giving blank response. JERSEY-2861 is created for the same.

Comment by Arindam Bandyopadhyay [ 15/May/15 ]

Please note that not only JDBC Connection Pool is broken , due to this issue we can't create any of the following resources
Concurrent Resources
--------------------
Context Services
Managed Thread Factories
Managed Executor Services
Managed Scheduled Executor Services
Connectors
-----------
Admin Object Resources
Connector Resources
Connector Connection Pools
Work Security Maps
JDBC


JDBC Resources
JDBC Connection Pools
JMS Resources
--------------
Connection Factories
Destination Resources
JNDI


Custom Resources
External Resources
JavaMail Sessions

Comment by tovine [ 22/May/15 ]

Romain Grécourt: I'm sorry for not responding earlier (been busy with school projects and final exams, plus we avoided the issue at work by using a version of Payara instead).

Isn't this issue fixed now? From the Payara release notes (http://payara.co/release_notes):
(Under Fixed issues) "269 – Nightly build 2015-04-28 does not allow creating jdbc connection pool resources through web interface"

If this is correct, then I assume the fix will be submitted back to upstream GlassFish (if it hasn't been already)...

Comment by viczai [ 19/Oct/15 ]

Checked with Oct 07 20:33 nightly build. Bug still there.

Comment by ccagf [ 29/Oct/15 ]

I have the Same Issue - Unable to Create JDBC Connection Pool through adminGUI...
Errors out: java.lang.IllegalStateException: getOutputStream() has already been called for this response

Version: GlassFish Server Open Source Edition 4.1.1 (build 1)

Stack:
[2015-10-29T10:39:21.669-0500] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=52 _ThreadName=admin-listener(2)] [timeMillis: 14461
33161669] [levelValue: 900] [[
StandardWrapperValve[FacesServlet]: Servlet.service() for servlet FacesServlet threw exception
java.lang.IllegalStateException: getOutputStream() has already been called for this response
at org.apache.catalina.connector.Response.getWriter(Response.java:777)
at org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:224)
at com.sun.faces.context.ExternalContextImpl.getResponseOutputWriter(ExternalContextImpl.java:851)
at com.sun.faces.context.PartialViewContextImpl.createPartialResponseWriter(PartialViewContextImpl.java:504)
at com.sun.faces.context.PartialViewContextImpl.access$300(PartialViewContextImpl.java:79)
at com.sun.faces.context.PartialViewContextImpl$DelayedInitPartialResponseWriter.getWrapped(PartialViewContextImpl.java:642)
at javax.faces.context.PartialResponseWriter.startDocument(PartialResponseWriter.java:120)
at com.sun.faces.context.AjaxExceptionHandlerImpl.handlePartialResponseError(AjaxExceptionHandlerImpl.java:202)
at com.sun.faces.context.AjaxExceptionHandlerImpl.handle(AjaxExceptionHandlerImpl.java:127)
at javax.faces.context.ExceptionHandlerWrapper.handle(ExceptionHandlerWrapper.java:100)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659)
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.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
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.doChainInvoke(StandardPipeline.java:678)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
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:206)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
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:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
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:591)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
at java.lang.Thread.run(Thread.java:745)
]]

Comment by randypeters [ 12/Nov/15 ]

This appears to make 4.1.1 completely unusable if the Admin GUI is needed and yet no activity in 6 months?

Comment by zebhed [ 07/Dec/15 ]

The only way to workaround this issue is to edit domain.xml by hand.
Or use Payara instead of Glassfish.

More info here: http://stackoverflow.com/a/33066856

Still, it is sad to see that GF 4.1.1 was released with such an obvious heavy bug.

Comment by frankmanzhu [ 07/Dec/15 ]

It is sad to see that GF 4.1.1 was released with such an obvious heavy bug. I did the GF 4.1.1 upgrade today and found the issue.

Comment by nabizamani [ 07/Dec/15 ]

I'm very unsatisfied as well. But at least the status is "IN PROGRESS". Let's give Oracle another 10 months, maybe they will solve it. But why do I feel that Oracle is not really interested in improving at least basic GF quality goals? Hm, maybe because they don't want to push Glassfish and they just don't have such goals...

Comment by raman777 [ 07/Jan/16 ]

As mentioned in GLASSFISH-21353:

In issue JERSEY 2861 it was proposed to be the solution to revert a previous change in annotation of the option method in the class "org.glassfish.admin.rest.resources.TemplateListOfResource"

The causing change was the following annotation change:

@OPTIONS
@Produces(

{MediaType.APPLICATION_JSON+";qs=0.5", MediaType.TEXT_HTML+";qs=0.5", MediaType.APPLICATION_XML+";qs=0.5"}

)
public Response options()

{ return Response.ok().entity(buildActionReportResult()).build(); }

According to JERSEY-2861 this needs to be reverted to

@OPTIONS
@Produces({MediaType.APPLICATION_JSON, MediaType.TEXT_HTML, MediaType.APPLICATION_XML})
public Response options() { return Response.ok().entity(buildActionReportResult()).build(); }

But when I take a look in the "rest-service.jar" bundeled with Glassfish 4.1.1 this change was not reverted:
--> Eclipse shows the following, when you open the file org/glassfish/admin/rest/resources/TemplateListOfResource.java:

@javax.ws.rs.OPTIONS
@javax.ws.rs.Produces(value=

{"application/json;qs=0.5","text/html;qs=0.5","application/xml;qs=0.5"}

)
public javax.ws.rs.core.Response options();

Is the change NOT integrated / NOT bundled within the current glassfish 4.1.1 release?

Comment by Arindam Bandyopadhyay [ 08/Jan/16 ]

The issue is fixed in trunk/main.
Sending nucleus/admin/rest/rest-service/src/main/java/org/glassfish/admin/rest/resources/TemplateListOfResource.java
Transmitting file data .
Committed revision 64238.

Comment by raman777 [ 08/Jan/16 ]

Resolved in Glassfish 5.0?
Is there any intermediate release planned - 4.1.2 for example - for the current Glassfish 4.1 server with this fix?

Comment by Arindam Bandyopadhyay [ 11/Jan/16 ]

The nightly build contains the fix. You can download the nightly build from http://download.oracle.com/glassfish/5.0/nightly/

Comment by jan_goyvaerts [ 19/May/16 ]

Can this fix really not be backported to GF 4 ? Seriously ?

IMHO an application server without data sources is not an application server.

Leaving GF 4 indefinitely broken is absurd. Twice so since it is supposed to be the reference implementation.

Comment by T-Gergely [ 19/May/16 ]

Re "Leaving GF 4 indefinitely broken is absurd." ...

Agreed. I regularly check for a fixed GF 4.x.
If you like conspiracy theories, you may wonder if Oracle wants you to drop GF in favor of Web*ogic. That wouldn't work of course. It's Open Source. There's Payara and more...

Comment by nabizamani [ 19/May/16 ]

I agree to both of you. Do you know how many open high prio issues I have opened many many months ago and I'm still waiting for a fix or at least for a response? This is ridiculous! Oracle is ridiculous! They are killing the community process, they kill Glassfish, NetBeans,... Words can't express how pissed I am about Oracle! For example, do you remember the old days when there was a weekly comments list ("tab sweep") on https://blogs.oracle.com/theaquarium/ that summed up great blogs from the community (I think it was all from alexis)? If you go to that page (aquarium) now you will see the last entry is from March 2nd, 2016 - that's 2.5 months ago! And, most of the other comments are marketing articles either for Oracle or the "one" person that likes to show off!

For Oracle it's a clash of interests and that's why Oracle does not care about the quality of Glassfish and about fixing bugs! From THE BEST quality OpenSource Java EE implementation Glassfish has changed to THE WORST quality OpenSource Java EE implementation - and it's THE reference implementation!! Oracle even tends to close discussions if they get to wild from the Oracle point of view, i.e. https://blogs.oracle.com/theaquarium/entry/java_ee_and_glassfish_server .

Enough is enough! Wanna start a campaign to free Java (EE) and Glassfish from Oracle?

Comment by jan_goyvaerts [ 19/May/16 ]

I used to advocate for GF because it looks nice and was maintained by the JEE authors. But this kind of ... flaw ... ? It's like telling HTTPS is broken. What good is this application server for serious enterprise applications ?

Btw, Isn't GF already free from Oracle ? I wonder who is maintaining GF 5. Since Oracle isn't maintaining GF anymore.

Comment by neialcantarajr [ 19/May/16 ]

Really it is absurd not release a fix in version 4.
Oracle this very disappointing.

Comment by reza_rahman [ 19/May/16 ]

I advise using the GlassFish user alias to have the discussions around Oracle commitments to Java EE and GlassFish. It would be more visible there.

You would also be welcome amongst the growing ranks of the Java EE Guardians.

Comment by jan_goyvaerts [ 19/May/16 ]

Is there an actual place to voice such opinions ? The forums for Glassfish are basically dead.

Comment by reza_rahman [ 19/May/16 ]

You'll find some kindred spirits on the Java EE Guardians Google Group: https://groups.google.com/forum/#!forum/javaee-guardians. If you look around there, I think you'll be able to figure out what we are trying to do. Our Twitter account is probably also helpful: https://twitter.com/javaee_guardian. Looking at this news entry will also prove helpful: https://adtmag.com/blogs/watersworks/2016/05/java-ee-guardians-charter-draft.aspx.

None of us are alone in this. If we can work together, we have a fighting chance of making this right.

Comment by nabizamani [ 20/May/16 ]

Have a look at these issues and for how long they are open:

I'm sure you could add yours as well. How can the reference implementation of Java EE pass the TCK/Spec when all these issues and many more exist? As a conclusion Glassfish cannot be called a "Certified" Java EE 7 implementation! Payer only exists because Glasfish has become a piece of crap under Oracle (I'm happy to have Payara)! I think for a long time that Oracle is killing Glassfish on purpose, just like they don't put efforts into Java EE, and I'm not even happy with their commitment to Java EE. Remember what happened to MySql? Remember Hudson? What about NetBeans? And JavaFX? Now Java, Java EE, and Glassfish? If Oracle would invest into these then they would help their competitors - that's why there is a clash of interests! Oracle has done its best to avoid transparency in the development of Glassfish: Why isn't Glassfish on GutHub yet? Maybe because pull requests are not appreciated? Actually, Oracle have never been considered as an "OpenSource Company" in contrast to Google, Twitter, Facebook, and many more.

All that said Oracle is NOT the right place for Java, Java EE, Glassfish, etc. All this has to set "free" from Oracle. It should be part of some other organization, a Non-Profit organization maybe. Maybe Eclipse Foundation, Apache Software Foundation, or something new which brings together many interested companies and people. What I don't like about the "Java EE Guardians", I think founded by Reza, is that they sound a little too formal and too "Oracle friendly" (Code of conduct, "with Oracle", taking over JSRs,...). And all that in spite of past the experience with Oracle.

I believe that the only way to set Java, Java EE, and Glassfish free from Oracle is by putting pressure on Oracle. A lot of pressure! That could be:

  • get out of JCP
  • stop working on JSRs
  • creating forks like Payara (maybe the Node.js way, also think of how successful Jenkins is after how Oracle behaved with Hudson)
  • create fragmentation of Java, Java EE (sorry for that)
  • creating a JCP outside of Oracle and getting commitment from other companies - big and small
  • Make those leading personalities like James Gosling, Adam Bien, and other Java Champions join all THIS and exit what ever is related with Oracle - no contributions for Oracle!
  • increase the pressure on Oracle even more!!!!!
  • Even try to get Oracle clients to pressure Oracle

Again, keep in mind what happened to Node.js. First the fork, then they merged back because the fork was successful and created pressure!

I strictly believe in order to safe Java, Java EE, and Glassfish we need to get rid of Oracle. Oracle is the problem and not the solution. And there is only one solution for this: free them all from Oracle! I'm sure Google would like this taking into account the current trials in front of court (http://fortune.com/2016/05/19/larry-page-google-android-oracle/). If Oracle wins the $9 billions then they get more back than the paid for the takeover of Sun - and Oracle will do everything to get the $9 billions! Maybe after that they will allow Java, Java EE, Glassfish to be set free.

Word can't express how pissed I am about Oracle. However, continuing with Oracle and shaking hands with Oracle is not the right way after all the experience we have with Oracle. However, that's what Reza's "Java EE Guardians" seem to look for ("including Oracle").

Comment by reza_rahman [ 20/May/16 ]

We are definitely a group of collaborative professionals trying to raise awareness and solve problems with due civility, patience and balance.

Comment by jan_goyvaerts [ 23/May/16 ]

I am a bit sceptical about pressuring Oracle really. They currently have €9b reasons to cling to Java. I'm afraid it's all futile unless you fork OpenJDK into something called differently and hope the community will follow swiftly like they did for Hudson and OpenOffice. Otherwise it's all for nothing.

Just found out Oracle is not the only company actively practicing absurdity at work - Red Hat is trying too.

Have a try to download JBoss AS 7.1.2. Even after registering you'll have no access to the software. For some obscure reason Red Hat is not publishing the binaries beyond 7.1.1. But at least the source code is available for building it.





[GLASSFISH-21440] Webservices don't work properly in 4.1.1 Created: 12/Oct/15  Updated: 23/May/16

Status: Open
Project: glassfish
Component/s: jax-rs
Affects Version/s: 4.1.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: setup Assignee: Unassigned
Resolution: Unresolved Votes: 14
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux Ubuntu 15.04



 Description   

After switching from 4.1 to 4.1.1 webservices fail with error 500
server-log

[2015-10-11T07:32:14.904+1000] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=34 _ThreadName=http-listener-1(5)] [timeMillis: 1444512734904] [levelValue: 900] [[
  StandardWrapperValve[javax.ws.rs.core.Application]: Servlet.service() for servlet javax.ws.rs.core.Application threw exception
java.lang.NoClassDefFoundError: Could not initialize class org.eclipse.persistence.jaxb.BeanValidationHelper
	at org.eclipse.persistence.jaxb.JAXBBeanValidator.isConstrainedObject(JAXBBeanValidator.java:257)
	at org.eclipse.persistence.jaxb.JAXBBeanValidator.shouldValidate(JAXBBeanValidator.java:208)
	at org.eclipse.persistence.jaxb.JAXBMarshaller.validateAndTransformIfNeeded(JAXBMarshaller.java:587)
	at org.eclipse.persistence.jaxb.JAXBMarshaller.marshal(JAXBMarshaller.java:481)
	at org.eclipse.persistence.jaxb.rs.MOXyJsonProvider.writeTo(MOXyJsonProvider.java:949)
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.invokeWriteTo(WriterInterceptorExecutor.java:265)
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo(WriterInterceptorExecutor.java:250)
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
	at org.glassfish.jersey.server.internal.JsonWithPaddingInterceptor.aroundWriteTo(JsonWithPaddingInterceptor.java:106)
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
	at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:86)
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
	at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:1130)
	at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:683)
	at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:424)
	at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:414)
	at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:312)
	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:292)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1139)
	at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:460)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:386)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:334)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:221)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.glassfish.tyrus.servlet.TyrusServletFilter.doFilter(TyrusServletFilter.java:305)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.setupit.experiment.controller.util.URLFilter.doFilter(URLFilter.java:122)
	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:416)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
	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:206)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
	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:283)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
	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:591)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
	at java.lang.Thread.run(Thread.java:745)

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

@Entity
@Table(name = "TITLE")
@XmlRootElement
@NamedQueries({
    @NamedQuery(name = "Title.findAll", query = "SELECT t FROM Title t"),
    @NamedQuery(name = "Title.findById", query = "SELECT t FROM Title t WHERE t.id = :id"),
    @NamedQuery(name = "Title.findByTitle", query = "SELECT t FROM Title t WHERE t.title = :title"),
    @NamedQuery(name = "Title.findByFullTitle", query = "SELECT t FROM Title t WHERE t.fullTitle = :fullTitle")})
public class Title implements Serializable {
    private static final long serialVersionUID = 1L;
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Basic(optional = false)
    @Column(name = "id")
    private Integer id;
    @Basic(optional = false)
    @NotNull
    @Size(min = 1, max = 45)
    @Column(name = "title")
    private String title;
    @Size(max = 1024)
    @Column(name = "full_title")
    private String fullTitle;
    @OneToMany(mappedBy = "title")
    private List<User> userList;

    public Title() {
    }

    public Title(Integer id) {
        this.id = id;
    }

    public Title(Integer id, String title) {
        this.id = id;
        this.title = title;
    }

    public Integer getId() {
        return id;
    }

    public void setId(Integer id) {
        this.id = id;
    }

    public String getTitle() {
        return title;
    }

    public void setTitle(String title) {
        this.title = title;
    }

    public String getFullTitle() {
        return fullTitle;
    }

    public void setFullTitle(String fullTitle) {
        this.fullTitle = fullTitle;
    }

    @XmlTransient
    public List<User> getUserList() {
        return userList;
    }

    public void setUserList(List<User> userList) {
        this.userList = userList;
    }

    @Override
    public int hashCode() {
        int hash = 0;
        hash += (id != null ? id.hashCode() : 0);
        return hash;
    }

    @Override
    public boolean equals(Object object) {
        // TODO: Warning - this method won't work in the case the id fields are not set
        if (!(object instanceof Title)) {
            return false;
        }
        Title other = (Title) object;
        if ((this.id == null && other.id != null) || (this.id != null && !this.id.equals(other.id))) {
            return false;
        }
        return true;
    }

    @Override
    public String toString() {
        return title + " (id=" + id + " )";
    }
    
}

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

@Stateless
@Path("title")
public class TitleService extends AbstractFacade<Title> {
    @PersistenceContext(unitName = "org.setupit_experiment_war_1.0PU")
    private EntityManager em;

    public TitleService() {
        super(Title.class);
    }

    @GET
    @Path("{id}")
    @Produces({MediaType.APPLICATION_JSON})
    public Title find(@PathParam("id") Integer id) {
        return super.find(id);
    }

    @GET
    @Override
    @Produces({MediaType.APPLICATION_JSON})
    public List<Title> findAll() {
        List<Title> lt = super.findAll();
        return lt;
    }

    @Override
    protected EntityManager getEntityManager() {
        return em;
    }
    
}

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

    <servlet>
        <servlet-name>javax.ws.rs.core.Application</servlet-name>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>javax.ws.rs.core.Application</servlet-name>
        <url-pattern>/services/*</url-pattern>
    </servlet-mapping>


 Comments   
Comment by reza_rahman [ 12/Oct/15 ]

I can confirm this happens with Cargo Tracker as well. It's a fairly serious usability problem.

Comment by Vinay Vishal [ 14/Oct/15 ]

Bean validation was introduced in Eclipselink 2.6.0 and that is where the NoClassDefFoundError is thrown.

This could be a case of missing entries in MANIFEST.MF in org.eclipse.persistence.moxy osgi bundle. Following link suggests so.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=463169
https://java.net/jira/browse/JERSEY-2888

Comment by Lukas Jungmann [ 14/Oct/15 ]

this seems to be fixed with eclipselink-2.6.1-RC2

Comment by Vinay Vishal [ 14/Oct/15 ]

Thanks Lukas, it worked when I tried locally with eclipselink-2.6.1-RC2.

Comment by setup [ 14/Oct/15 ]

I just tried to replace eclipselink-2.6.1-RC1 with eclipselink-2.6.1-RC2. it didn't resolve the problem. Any other suggestions?

Comment by Vinay Vishal [ 15/Oct/15 ]

In my case, I rebuilt Glassfish locally after bumping up eclipselink version. Its working fine for me. May be you can try stopping the domain, cleaning up your osgi-cache inside domains/<domain> directory, restart the domain and see if it works?

Comment by nicof6786 [ 15/Oct/15 ]

Hi,
I tried to get around this issue using Jackson as a media provider.
I ran into a similar issue even though it was not blocking.
On the first call and only on the first call to a Jax-Rs resource I get the following error :

java.lang.NoClassDefFoundError: com/fasterxml/jackson/module/jaxb/JaxbAnnotationIntrospector
        at com.fasterxml.jackson.jaxrs.json.JsonMapperConfigurator._resolveIntrospector(JsonMapperConfigurator.java:109)
        at com.fasterxml.jackson.jaxrs.json.JsonMapperConfigurator._resolveIntrospectors(JsonMapperConfigurator.java:84)
        at com.fasterxml.jackson.jaxrs.cfg.MapperConfiguratorBase._setAnnotations(MapperConfiguratorBase.java:120)
        at com.fasterxml.jackson.jaxrs.json.JsonMapperConfigurator.getDefaultMapper(JsonMapperConfigurator.java:45)
        at com.fasterxml.jackson.jaxrs.base.ProviderBase.locateMapper(ProviderBase.java:864)
        at com.fasterxml.jackson.jaxrs.base.ProviderBase.writeTo(ProviderBase.java:588)
        at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.invokeWriteTo(WriterInterceptorExecutor.java:265)
        at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo(WriterInterceptorExecutor.java:250)
        at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
        at org.glassfish.jersey.server.internal.JsonWithPaddingInterceptor.aroundWriteTo(JsonWithPaddingInterceptor.java:106)
        at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
        at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:86)
        at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
        at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:1130)
        at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:683)
        at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:424)
        at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:414)
        at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:312)
        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:292)
        at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1139)
        at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:460)
        at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:386)
        at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:334)
        at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:221)
        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.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
        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:206)
        at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
        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:283)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
        at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
        at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
        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:591)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
        at java.lang.Thread.run(Thread.java:745)

The subsequent calls work fine.
Should I declare another issue ?

Comment by xwibao [ 19/Oct/15 ]

That nasty JERSEY-2888 definitely crept into GlassFish 4.1.1 :-\

As a quick & dirty fix, one can find glassfish/modules/org.eclipse.persistence.moxy.jar and fix META-INF/MANIFEST.MF inside it. Simply append the following to Import-Package:

,org.xml.sax.helpers,javax.xml.parsers;resolution:=optional,javax.naming;resolution:=optional

and restart. That worked for me.

Comment by setup [ 26/Oct/15 ]

Thank you!

Editing glassfish/modules/org.eclipse.persistence.moxy.jar helps

Comment by sebastian2 [ 30/Nov/15 ]

Hi there,
this bug is also blocking us from updating to the new Glassfish version.

Comment by pdurbin [ 04/Dec/15 ]

This issue is blocking us from upgrading from Glassfish 4.1 to Glassfish 4.1.1 because bean validation isn't working in the latter. Please see the following comment for details and a stacktrace: https://github.com/IQSS/dataverse/issues/2628#issuecomment-158197478

At https://javabot.evanchooly.com/logs/%23glassfish/2015-12-04 Ed Burns mentioned that this issue (GLASSFISH-21440) is the one I should be tracking so if "bean validation" could be added to the title, I would really appreciate it. We're looking forward to a release that has the bug fix (Glassfish 4.1.2 or whatever). We'll pass on Glassfish 4.1.1. (We already do enough patching of Glassfish 4.1 per the GitHub issue above and our goal is to avoid making our users patch Glassfish.)

Thanks for Glassfish. It's great. We're looking forward to upgrading. (I kind of want to play with Ozark.

Comment by Pavel Bucek [ 04/Dec/15 ]

If you just wan't to "play", you can checkout and build glassfish trunk, I believe the issue is resolved there.

Comment by basler [ 22/Dec/15 ]

This bug is blocking my upgrade, but the moxy patch listed above worked.

Comment by nabizamani [ 23/Jan/16 ]

Hello Oracle!!!! I can confirm this bug also exists also on Mac OS.

It's such a pity that you don't care about this serious issue! I'm writing tutorials based on Glassfish and I just decided to drop Glassfish for all my future tutorials because the quality of GF is disgusting compared to the times it was managed by Sun! I will use Tomcat instead, congrats!! I'm so disappointed. It's such a shame that this obvious issue is not even assigned yet!

Comment by atiqkhaled [ 09/Apr/16 ]

Hi
Did you try it for XML. I mean replace xml on @Produces(

{MediaType.APPLICATION_JSON}

) . Hope it works then.

Comment by nabizamani [ 14/Apr/16 ]

Helloooo Oracle, anyone working on this???

Comment by andradeb.david [ 23/May/16 ]

Hi in this post is a solution .
http://ayudasdesarrollo.blogspot.com.co/2016/05/glassfish-441-falla-con-jax-rs-y-json.html





[GLASSFISH-21543] Invalid resource when using application scoped resource in EAR Created: 17/May/16  Updated: 17/May/16

Status: Open
Project: glassfish
Component/s: None
Affects Version/s: 4.1, 4.1.1, 5.0
Fix Version/s: None

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


 Description   

1) create EE7 EAR project with ejb and web
2) define jdbc resource and pool using java:module scope in glassfish-resources.xml in ejb module
3) define persistence unit in ejb using the jdbc resource in ejb
4) define stateless session bean
5) inject EnitityManager to the bean:
@PersistenceContext(unitName = "myUnit")
private EntityManager em;
6) deploy the EAR and it will fail with invalid resource

Standalone web module using java:app works fine. Moving the persistence.xml and glassfish-resources.xml to EAR and using java:app also works fine.



 Comments   
Comment by petrhejl [ 17/May/16 ]

I may attach/provide sample project.

Comment by petrhejl [ 17/May/16 ]

I've attached the test project to original NetBeans issue.
https://netbeans.org/bugzilla/attachment.cgi?id=159782





[GLASSFISH-18946] EAR with two CDI Jersey web archives will not deploy Created: 26/Jul/12  Updated: 13/May/16

Status: Reopened
Project: glassfish
Component/s: jax-rs
Affects Version/s: None
Fix Version/s: 4.0

Type: Bug Priority: Minor
Reporter: Ramon Rockx Assignee: Marek Potociar
Resolution: Unresolved Votes: 16
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Attachments: Zip Archive JerseyCDITest2.zip     File TestEAR-0.0.1-SNAPSHOT.ear     Java Archive File TestWAR1-0.0.1-SNAPSHOT-sources.jar     Java Archive File TestWAR2-0.0.1-SNAPSHOT-sources.jar    
Tags: req-weld-fix

 Description   

I already filed this issue in the Jersey JIRA (http://java.net/jira/browse/JERSEY-1232), however, after some research by Michal Gajdos, the issue is closed as "invalid", since the problem would by caused by Weld/GlassFish Weld. I also filed an issue at the Weld JIRA (http://issues.jboss.org/browse/WELD-1175), but they think it should be investigated first by the GlassFish team... (from pillar to post).
Hopefully, the GlassFish team can help solving this problem.

So here are the details:
We are experiencing the following issue with Jersey 1.12 in combination with Weld 1.1.4 and Glassfish 3.1.2:
When using an EAR with two WAR's in it, the last WAR doesn't get deployed. Both WAR's are CDI enabled and contains a REST service. When deploying both WAR's without the EAR, they deploy just fine.
I will attach a test case.

Depending on the VM property
com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager we will get another Exception:

com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=false:

java.lang.RuntimeException: javax.naming.NamingException: Lookup failed for 'com/sun/jersey/config/CDIExtension' in
SerialContext[myEnv=java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory,
 java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, 
java.naming.factory.url.pkgs=com.sun.enterprise.naming}
[Root exception is javax.naming.NameNotFoundException: CDIExtension not found]	
	at com.sun.jersey.server.impl.cdi.CDIExtension.getInitializedExtension(CDIExtension.java:177)
	at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactory.<init>(CDIComponentProviderFactory.java:92)
	at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactoryInitializer.initialize(CDIComponentProviderFactoryInitializer.java:75)
	at com.sun.jersey.spi.container.servlet.WebComponent.configure(WebComponent.java:574)
	at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.configure(ServletContainer.java:311)
	at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:606)
	at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:208)
	at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
	at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:556)
	at javax.servlet.GenericServlet.init(GenericServlet.java:244)
	...

com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=true

java.lang.NullPointerException
	at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactory.<init>(CDIComponentProviderFactory.java:94)
	at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactoryInitializer.initialize(CDIComponentProviderFactoryInitializer.java:75)
	at com.sun.jersey.spi.container.servlet.WebComponent.configure(WebComponent.java:574)
	at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.configure(ServletContainer.java:311)
	at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:606)
	at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:208)
	at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
	at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:556)
	at javax.servlet.GenericServlet.init(GenericServlet.java:244)
	...


 Comments   
Comment by jjsnyder83 [ 03/Oct/12 ]

There is a work-around...I removed the WEB-INF/lib/jersey-gf-servlet-1.12.jar from the wars and I was able to deploy the ear successfully and execute http://localhost:8080/rest1_war/service/rest/RestService1 with "Hello world" as the result. I was able to reproduce the NPE above so I'm still looking into it.

Comment by jjsnyder83 [ 05/Oct/12 ]

I have checked in a fix. The application now deploys. However this has uncovered what I believe to be a bug in Weld. See https://issues.jboss.org/browse/WELD-1175.

I have checked in the fix into 3.1.2 and trunk.

Comment by jjsnyder83 [ 05/Oct/12 ]

Reopening due to the bug in Weld

Comment by Ramon Rockx [ 08/Oct/12 ]

Great that this one is fixed!
I'm looking for a way to patch our GlassFish installation (version 3.1.2.2).
jjsnyder83, you mentioned that it is fixed on trunk and 3.1.2. I can only find commits on the trunk (GF 4.0 I assume). Can you help me out patching 3.1.2/3.1.2.2?

Comment by jjsnyder83 [ 08/Oct/12 ]

I made the change to the 3.1.2-SUSTAINING line as well as trunk (4.0).

I will get back to you on the patching.

Please note that even though the app will deploy a fix to Weld (https://issues.jboss.org/browse/WELD-1175) is still required for the app to work correctly. See the Weld issue for details.

Comment by jjsnyder83 [ 08/Oct/12 ]

The next patch due out is 3.1.2.4 (not sure of the date yet.) But until Weld fixes the issue there's no reason to include this in the patch.

Comment by Ramon Rockx [ 09/Oct/12 ]

Can we expect this fix will be included in 3.1.2.4 since WELD-1175 is fixed too?
(3.1.2.3 is skipped for release?)

Comment by jjsnyder83 [ 11/Oct/12 ]

Yes...I made the fix in the patch line and so it should be included in the next patch release. I have also requested that weld 1.1.10.Final be included as this relies on weld to work properly.

Comment by jjsnyder83 [ 22/Oct/12 ]

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

Comment by jjsnyder83 [ 20/Dec/12 ]

I just tested this on trunk with weld 1.1.10.Final and it doesn't work.

Comment by jwells [ 27/Mar/13 ]

I get this error now when I deploy the above ear in GF 4.0:

Exception while loading the app : CDI deployment failure:Error loading class com.sun.jersey.server.impl.cdi.CDIExtension
org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class com.sun.jersey.server.impl.cdi.CDIExtension
at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:179)
at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:190)
at org.jboss.weld.resources.ClassTransformer.getEnhancedAnnotatedType(ClassTransformer.java:224)
at org.jboss.weld.bootstrap.ExtensionBeanDeployer.deployBeans(ExtensionBeanDeployer.java:71)
at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:464)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:192)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)

I looked at this a little bit, the class com.sun.jersey.server.impl.cdi.CDIExtension is in the jersey-gf-servlet-1.12.jar included in the WAR files included in the EAR. My guess would be that the old CDIExtension (which no longer exists in the Jersey included in GF 4.0) cannot be loaded properly anymore...

So to me this seems like it is currently a Jersey issue, and may have to do with backwards compatibility...

Comment by Ramon Rockx [ 02/May/13 ]

I'm wondering if this bug will be fixed with the upcoming 4.0 release?
It really makes it impossible for us to use REST in a large modular EAR application properly.

Comment by dbenegiamo [ 03/May/13 ]

As the "double WARs in a EAR" is a common solution for applications that expose a FORM authentication for the web presentation and a BASIC authentication for restful web-services, priority of this bug should - in my opinion - raised.

Comment by Ramon Rockx [ 22/May/13 ]

Like jwells mentioned, the current test case results in ClassNotFoundExceptions.
I downloaded GlassFish 4.0 b88. Tweaked the test case:

  • no Jersey servlet configuration anymore (web.xml is empty)
  • no explicit dependency to Jersey 1.12 anymore (it now depends on Jersey 2.x)
  • used the javax.ws.rs.ApplicationPath annotation to configure the REST path prefix.

Now each REST service does work in both web modules.

However, GlassFish does log warnings like
"[WARNING|glassfish 4.0|javax.enterprise.web.util|_ThreadID=60;_ThreadName=AutoDeployer;_TimeMillis=1369210288543;_LevelValue=900; _MessageID=AS-WEB-UTIL-00035;| Unable to load class nl.asknow.sandbox.RestService1, reason: java.lang.ClassNotFoundException: nl.asknow.sandbox.RestService1|#]".
I'm not sure if this warning can be ignored.

I will attach my new test case.

Comment by Ramon Rockx [ 22/May/13 ]

It seems I cannot add an attachment anymore...

Comment by Jakub Podlesak [ 24/May/13 ]

Ramon, could you please send the test case to my e-mail address (jakub.podlesak at oracle.com)? I will attach it here as well once i get it. Thanks!

Comment by Jakub Podlesak [ 27/May/13 ]

Updated test case from Ramon.

Comment by sebastian2 [ 23/Jul/14 ]

Is there a plan to fix that issue? I am also struggeling with this bug....

Comment by lprimak [ 12/May/16 ]

Payara team is tracking this bug here:
https://github.com/payara/Payara/issues/374

Comment by Jakub Podlesak [ 13/May/16 ]

Re-assigning to Marek, as i am not sure who is in charge with Jersey in GF. I am no longer part of the team.





[GLASSFISH-20720] EAR deployment with multiple embedded WARs broken in 3.1.2.2 and 4.0 Created: 22/Jul/13  Updated: 12/May/16

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1, 4.0_b89_RC5
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: nabizamani Assignee: kchung
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RedHat Linux, Windows, Ubuntu Linux


Attachments: File TestApp.ear     File TestApp.ear    
Tags: 3_1-next, 3_1_1-scrubbed, 3_1_2-exclude, metro2_2-waived

 Description   

We are trying to upgrade to 3.1. Our application is packaged and deployed as an EAR file with multiple EJB and WARs embedded. Some of the WAR files have web services for deployment, and some do not. The 3.1 deployment mechanism is fundamentally broken in this case. It appears that the web service deployment piece ends up scanning all the wars in the EAR for metadata (annotations), and then trying to deploy the collected web services in every WAR in the EAR, not just the one that had the annotated web service classes.

This appears to be the same symptoms as the following bug, but for web services instead.

http://java.net/jira/browse/JAVASERVERFACES-1995

I have attached a very simple test EAR file. Trying to deploy this will demonstrate the error. You will see error messages about duplicate web service deployments and class not found exceptions.



 Comments   
Comment by nabizamani [ 22/Jul/13 ]

I created this clone of https://java.net/jira/browse/GLASSFISH-16249 because the issue reported still exists in GF 3.1.2.2.
A similar issue also exists in GF 4.0.

Below you can see the different outputs (I used an own ear which contains an ejb module and 2 war modules of which one contains restful classes):

  • Glassfish 3.1.2.2 (build 5)
    WARNING: WEB9052: Unable to load class com.demo.service.exception.RestExceptionCatcher, reason: java.lang.ClassNotFoundException: com.demo.service.exception.RestExceptionCatcher
    WARNING: WEB9052: Unable to load class com.demo.service.rss.NewsFeed, reason: java.lang.ClassNotFoundException: com.demo.service.rss.NewsFeed
  • Glassfish 4.0 (build 89).
    WARNING: Class 'javax.ejb.PostActivate' not found, interception based on it is not enabled
    WARNING: Class 'javax.ejb.PrePassivate' not found, interception based on it is not enabled
    INFO: Registering the Jersey servlet application, named com.demo.jaxrs.application.ApplicationConfig, at the servlet mapping /*, with the Application class of the same name.
    WARNING: Unable to load class com.demo.jaxrs.application.ApplicationConfig, reason: java.lang.ClassNotFoundException: com.demo.jaxrs.application.ApplicationConfig
    WARNING: Unable to load class com.demo.tutorials.mavenstruts.service.MessageService, reason: java.lang.ClassNotFoundException: com.demo.tutorials.mavenstruts.service.MessageService
    WARNING: Unable to load class com.demo.tutorials.mavenstruts.service.MessageService, reason: java.lang.ClassNotFoundException: com.demo.tutorials.mavenstruts.service.MessageService
    WARNING: Unable to load class com.demo.jaxrs.provider.MyJacksonJsonProvider, reason: java.lang.ClassNotFoundException: com.demo.jaxrs.provider.MyJacksonJsonProvider
    WARNING: Unable to load class com.demo.jaxrs.application.ApplicationConfig, reason: java.lang.ClassNotFoundException: com.demo.jaxrs.application.ApplicationConfig

Furthermore In GF 4.0 I get a lot of messages of this kind (which I really hate):
INFO: visiting unvisited references

Comment by Lukas Jungmann [ 01/Aug/13 ]

passing to jax-rs for evaluation since jar-rs seems to be involved here

Comment by Lukas Jungmann [ 01/Aug/13 ]

assign as needed, please. thx.

Comment by replicant77 [ 09/Sep/13 ]

We also get the ClassNotFoundException messages in multi-war deployments. But not only for rest service classes, but also for jsf related classes, like jsf converters and validators:

WARNING: WEB9052: Unable to load class gf4test.rest.TestService, reason: java.lang.ClassNotFoundException: gf4test.rest.TestService
WARNING: WEB9052: Unable to load class gf4test.converters.TestConverter1, reason: java.lang.ClassNotFoundException: gf4test.converters.TestConverter1

If you have a lot of such classes in your application this can get really annoying. We noticed these warning messages on GF 3.1.2 as well as GF4.

Comment by TangYong [ 10/Sep/13 ]

replicant77

Your attachment has problem and while deploying your attachment into 4.0.1-b02, the following error happened,

[2013-09-10T11:18:40.508+0900] [glassfish 4.0] [WARNING] [] [org.apache.jasper.runtime.TldScanner] [tid: _ThreadID=51 _ThreadName=admin-listener(1)] [timeMillis: 1378779520508] [levelValue: 900] [[
PWC6351: In TLD scanning, the supplied resource file:/E:/NanjingJUG/glassfish-4.0.1-b02/glassfish4/glassfish/domains/domain1/applications/TestApp/TestApp-ejbClient.jar does not exist
java.io.FileNotFoundException: E:\NanjingJUG\glassfish-4.0.1-b02\glassfish4\glassfish\domains\domain1\applications\TestApp\TestApp-ejbClient.jar (指定されたファイルが見つかりません。)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:214)
at java.util.zip.ZipFile.<init>(ZipFile.java:144)
at java.util.jar.JarFile.<init>(JarFile.java:152)
at java.util.jar.JarFile.<init>(JarFile.java:89)
at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:93)
at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69)
at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:98)
at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:89)
at org.apache.jasper.runtime.TldScanner.scanJar(TldScanner.java:442)
at org.apache.jasper.runtime.TldScanner.scanJars(TldScanner.java:694)
at org.apache.jasper.runtime.TldScanner.scanTlds(TldScanner.java:350)
at org.apache.jasper.runtime.TldScanner.onStartup(TldScanner.java:239)
at org.apache.catalina.core.StandardContext.callServletContainerInitializers(StandardContext.java:6031)
at com.sun.enterprise.web.WebModule.callServletContainerInitializers(WebModule.java:774)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5929)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2286)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1932)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java: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:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:404)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:140)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:158)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:101)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:353)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:343)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:237)
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:318)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:211)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:982)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:330)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:173)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:496)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:175)
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:187)
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:837)
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:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:722)
]]

[2013-09-10T11:18:40.867+0900] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=51 _ThreadName=admin-listener(1)] [timeMillis: 1378779520867] [levelValue: 800] [[
Loading application TestApp#TestApp-war.war at [TestApp-war]]]

[2013-09-10T11:18:40.883+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=51 _ThreadName=admin-listener(1)] [timeMillis: 1378779520883] [levelValue: 900] [[
Unable to load class com.test.web.TestWebService, reason: java.lang.ClassNotFoundException: com.test.web.TestWebService]]

[2013-09-10T11:18:40.898+0900] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=51 _ThreadName=admin-listener(1)] [timeMillis: 1378779520898] [levelValue: 800] [[
Loading application TestApp#TestApp2-war.war at [TestApp2-war]]]

[2013-09-10T11:18:40.977+0900] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=51 _ThreadName=admin-listener(1)] [timeMillis: 1378779520977] [levelValue: 800] [[
TestApp was successfully deployed in 10,876 milliseconds.]]

So, I have uploaded a new attachment.

OK, current issue should be the following:

[2013-09-10T11:18:40.883+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=51 _ThreadName=admin-listener(1)] [timeMillis: 1378779520883] [levelValue: 900] [[
Unable to load class com.test.web.TestWebService, reason: java.lang.ClassNotFoundException: com.test.web.TestWebService]]

1. the issue is not related to jax-rs comp
2. instead, firstly forwarding to web_services comp to evaluate, and I also add web_container comp to ask shing wai to evaluate it.

Comment by TangYong [ 10/Sep/13 ]

I made an initial investigation for the issue,

1) removing web_webservices comp because I have confirmed the warning info is related to web_container comp. so, pl. Shing Wai confirms

2) the warning happened in checkAgainstInterestList method from org.glassfish.web.loader.ServletContainerInitializerUtil class

In this attachment, there are two wars and TestApp2-war does not contain any class, TestApp-war contains a class with @WebService, while checkAgainstInterestList is executed, the method also scans TestApp2-war for @WebService, so, ClassNotFoundException happened.

I think this has some wrong logic because "interestList" variable in checkAgainstInterestList always saves previous result(eg. TestApp-war), for TestApp2-war, these annotations do not exist.

However, I think this issue itself should be not important and I think this should be an improvement rather than a bug.

Thanks
Tang

Comment by Shing Wai Chan [ 10/Sep/13 ]

The ClassNotFoundException warning is related to GLASSFISH-16937 .
Assign to Kinman to investigate TLDScanning FileNotFoundException.

Comment by pbelbin [ 09/Jan/14 ]

is there a fix for this issue? or, perhaps I'm having a different issue.

I have a .ear which has multiple .war contained within it that refuses to deploy.

I do see the WEB9052 warnings.

but, after that, I also see this:

[#|2014-01-09T16:29:49.206-0600|WARNING|glassfish3.1.2|javax.enterprise.webservices.org.glassfish.webservices|_ThreadID=130;_ThreadName=Thread-2;|Deployment failed
java.lang.AbstractMethodError
at org.glassfish.webservices.WsUtil.parseRelativeImports(WsUtil.java:414)
at org.glassfish.webservices.WsUtil.getWsdlsAndSchemas(WsUtil.java:1884)
at org.glassfish.webservices.WsUtil.getWsdlsAndSchemas(WsUtil.java:1858)
at org.glassfish.webservices.WSServletContextListener.registerEndpoint(WSServletContextListener.java:143)
at org.glassfish.webservices.WSServletContextListener.contextInitialized(WSServletContextListener.java:102)
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:4750)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:550)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5366)
at com.sun.enterprise.web.WebModule.start(WebModule.java:498)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:733)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2019)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1669)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:109)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:301)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:461)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:722)

#]
Comment by lprimak [ 12/May/16 ]

Payara team is tracking this bug here:
https://github.com/payara/Payara/issues/374





[GLASSFISH-16937] Having REST services in separate WARs in a single EAR prints classloading warnings Created: 01/Jul/11  Updated: 12/May/16

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

Type: Bug Priority: Minor
Reporter: mmuller Assignee: Daniel
Resolution: Unresolved Votes: 11
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows Server 2008


Attachments: File ear-1.0.ear     GZip Archive jaxrs_multimodule_test.tar.gz    
Tags: classloader, glassfish-3-1, jax-rs

 Description   

Warnings show up when an EAR is deployed, containing more than one WAR archove with REST web services. Looks like GlassFish/Jersey tries to load all the REST service classes for each of the WARs being deployed, and then shows classloader warnings:

WEB9052: Unable to load class <classname>, reason: java.lang.ClassNotFoundException: <classname>

I did a minimal project which produces an EAR with this structure:

ear-1.0.ear

  • META-INF/
`- application.xml
  • war-1-1.0.war
 
  • classes/
  `- test/war1/Service1.class
`- WEB-INF/
`- web.xml
`- war-2-1.0.war
  • classes/
`- test/war2/Service2.class
`- WEB-INF/
`- web.xml

(See the attached maven project).

test.war1.Service1 and test.war2.Service2 are POJOs with class-level @Path annotation and method-level @GET or @POST annotations.
The application.xml DD is generated by maven-ear-plugin and only contains the two webmodules and their contextroots.
Both web.xml only contain a display name and the Jersey ServletContainer loaded on startup.

When deploying to GlassFish 3.1 on Windows Server 2008, the log contains the following entries:

[#|2011-07-01T10:45:59.159+0200|WARNING|glassfish3.1|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=183;_ThreadName=Thread-1;|WEB9052: Unable to load class test.war2.Service2, reason: java.lang.ClassNotFoundException: test.war2.Service2|#]

[#|2011-07-01T10:45:59.187+0200|INFO|glassfish3.1|com.sun.jersey.api.core.WebAppResourceConfig|_ThreadID=23;_ThreadName=Thread-1;|Scanning for root resource and provider classes in the Web app resource paths:
/WEB-INF/lib
/WEB-INF/classes|#]

[#|2011-07-01T10:45:59.187+0200|INFO|glassfish3.1|com.sun.jersey.api.core.ScanningResourceConfig|_ThreadID=23;_ThreadName=Thread-1;|Root resource classes found:
class test.war1.Service1|#]

[#|2011-07-01T10:45:59.187+0200|INFO|glassfish3.1|com.sun.jersey.api.core.ScanningResourceConfig|_ThreadID=23;_ThreadName=Thread-1;|No provider classes found.|#]

[#|2011-07-01T10:45:59.187+0200|INFO|glassfish3.1|com.sun.jersey.server.impl.application.WebApplicationImpl|_ThreadID=23;_ThreadName=Thread-1;|Initiating Jersey application, version 'Jersey: 1.5 01/14/2011 12:36 PM'|#]

[#|2011-07-01T10:45:59.354+0200|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=183;_ThreadName=Thread-1;|WEB0671: Loading application ear-1.0#war-1-1.0.war at [/war1]|#]

[#|2011-07-01T10:45:59.368+0200|WARNING|glassfish3.1|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=183;_ThreadName=Thread-1;|WEB9052: Unable to load class test.war1.Service1, reason: java.lang.ClassNotFoundException: test.war1.Service1|#]

[#|2011-07-01T10:45:59.382+0200|INFO|glassfish3.1|com.sun.jersey.api.core.WebAppResourceConfig|_ThreadID=23;_ThreadName=Thread-1;|Scanning for root resource and provider classes in the Web app resource paths:
/WEB-INF/lib
/WEB-INF/classes|#]

[#|2011-07-01T10:45:59.382+0200|INFO|glassfish3.1|com.sun.jersey.api.core.ScanningResourceConfig|_ThreadID=23;_ThreadName=Thread-1;|Root resource classes found:
class test.war2.Service2|#]

[#|2011-07-01T10:45:59.382+0200|INFO|glassfish3.1|com.sun.jersey.api.core.ScanningResourceConfig|_ThreadID=23;_ThreadName=Thread-1;|No provider classes found.|#]

[#|2011-07-01T10:45:59.382+0200|INFO|glassfish3.1|com.sun.jersey.server.impl.application.WebApplicationImpl|_ThreadID=23;_ThreadName=Thread-1;|Initiating Jersey application, version 'Jersey: 1.5 01/14/2011 12:36 PM'|#]

[#|2011-07-01T10:45:59.521+0200|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=183;_ThreadName=Thread-1;|WEB0671: Loading application ear-1.0#war-2-1.0.war at [/war2]|#]

[#|2011-07-01T10:45:59.535+0200|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=183;_ThreadName=Thread-1;|ear-1.0 was successfully deployed in 543 milliseconds.|#]

So this looks like Glassfish tries to load both services for each WAR module. When loading war-1, it cannot load test.war2.Service2, and while loading war-2, it cannot load test.war1.Service1...
Although, the application is correctly deployed and all the services do work !!

I guess this is a tiny bug, and could be fixed within a handful of lines. I could try to fix it, if someone could point me to the right module producing this warning.



 Comments   
Comment by mmuller [ 01/Jul/11 ]

Oops, looks like Jira didn't like my folder-tree syntax.

So, the EAR structure is

ear-1.0.ear
  META-INF/
    application.xml
  war-1-1.0.war
    classes/
      test/war1/Service1.class
    WEB-INF/
      web.xml
  war-2-1.0.war
    classes/
      test/war2/Service2.class
    WEB-INF/
      web.xml
Comment by Shing Wai Chan [ 01/Jul/11 ]

The calling stack is as follows:
StandardContext#callServletContainerInitializer
--> ServletContainerInitializerUtil#getInitializerList
--> ServletContainerInitializerUtil#checkAgainstInterestList

and the warning is coming from calling the checkAgainstInterestList method

The issue is from argument of calling the last method as follows:
1. Types classInfo contains the classes information for the ear
which is from WebModule#getTypes
wmInfo.getDeploymentContext().getTransientAppMetaData(
Types.class.getName(), Types.class);
2. WebappClassLoader cl, for war1, say, then it cannot load classes for war2

Even though the returned value of the method is correct, there is unnecessary call for loading other classes.

Comment by geturnerlmco [ 13/Oct/11 ]

This happens if there are multiple WARs, period. I have an application with 5 WARs, two are SOAP service endpoints and 3 are REST. If I remove 2 of the 3 REST WARS, I still get the WARNINGS. If I remove the 2 SOAP WARs, the WARNINGS are gone. I have searched every forum for an answer to this annoying problem, but this is the first one that is the closest to my problem. If anyone has a workaround other than destroying my EAR structure (which doesn't work well for fielding, ha ha) I would really appreciate knowing it.

Comment by geturnerlmco [ 14/Oct/11 ]

One additional comment that I thought would be helpful. I commented out all of the additional WARs from my application.xml but still built the EAR normally. The WARNINGS occured, just because the modules existed in the EAR directory structure, but the module definitions were commented out! Is the class scanner looking for ANY .class file in the EAR directory, whether it was defined to be part of the application or not???

Comment by Dan.Daneasa [ 23/Oct/11 ]

I have more comments on this.
I have 2 wars deployed in the same ear. One is a Jersey simple west app, the other one is an empty war.
I can see the ClassNotFoundExceptions.

There may be more to this problem. If i have an ear with 2 wars, one is a simple Jersey rest app, the other a simple Mojarra faces app. I see that the ClassNotFoundException is still present, also there are Mojarra-impl ClassNotFoundException warnings.
The same happens if i try to integrate MyFaces instead of Mojarra in the faces webapp.
Mojarra/Myfaces tries to load in the Jersey app as well, and vice-versa, Jersey tries to load in the Mojarra/MyFaces app.

If I have only one of the wars in the ear in any of the above combinations then the warnings are not present.

Comment by hpgisler [ 14/Nov/11 ]

Just for the record: Same problem here.

Two WAR's in an EAR
1. WAR JSF frontend
2. WAR REST frontend

If packaging only one of them into EAR, no problem; if packaging both inside EAR, Problem.

Comment by pettymt [ 10/Apr/12 ]

Confirmed on v3.1.1 (build 12)

30 WARs(each containing a REST service) in an EAR is a lot of warnings.

Comment by phealy [ 27/Mar/13 ]

I am getting a warning for every PimesFaces class every time I deploy (because I also have a Jersey app in my EAR). This does not reflect well on Glassfish.

Comment by nabizamani [ 13/Apr/13 ]

I have the same issue with GlassFish 3.1.2.2 (build 5) when deploying an EAR containing 2 wars and 1 ejb module (one of the wars contains restful web services).

Example:
WARNING: WEB9052: Unable to load class com.demo.service.exception.RestExceptionCatcher, reason: java.lang.ClassNotFoundException: com.demo.service.exception.RestExceptionCatcher
WARNING: WEB9052: Unable to load class com.demo.service.Order, reason: java.lang.ClassNotFoundException: com.demo.service.Order

RestExceptionCatcher is a @Provider and implements ExceptionMapper<Throwable>.
Order is a very simple REST service.

These warnings are very frustrating and I really want to get rid of them! But that would means I cannot use my EAR

Comment by yonatan [ 01/May/13 ]

If everything works properly, until the issue is resolved you can raise the logging level of that specific logger by adding javax.enterprise.system.container.web.org.glassfish.web.loader.level=SEVERE to the DOMAIN_HOME/config/logging.properties file.

Comment by andrey.v.markelov [ 07/May/13 ]

I have got the same trouble. Are you going to fix that?

Comment by Shing Wai Chan [ 25/Jun/13 ]

The given test case may need to update for GlassFish 4.

Comment by Daniel [ 25/Jun/13 ]

The web.xml for GF4 should use org.glassfish.jersey.servlet.ServletContainer API instead.

Comment by obfischer [ 17/Mar/14 ]

Is there a chance to get this fixed in the near future? Our monitoring reports all log messages with a log level above INFO. It is very annoying to warnings for a non-existent problem.

Comment by Philipp91 [ 21/Dec/14 ]

This issue should be prioritized higher. It may be a minor problem for people who's logs get flooded by these messages, but it is a major problem for people who can't use the REST services, which they deployed. The classes are not available, NoClassDefFound exceptions occur as follow-ups and the REST service is not available.

I use a simple JAR included in WEB-INF/lib.

Comment by lprimak [ 12/May/16 ]

This is now worked on and tracked by Payara team.
Issue https://github.com/payara/Payara/issues/374





[GLASSFISH-6582] Passing multiple VM arguments to JMS Service via Admin Console doesn't work Created: 19/Oct/08  Updated: 12/May/16

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: v2.1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: ijuma Assignee: Anissa Lam
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 6,582

 Description   

This was reproduced with Glassfish v2.1 b54. I am not sure if it's the right
subcomponent so please reassign if necessary.

Steps to reproduce:

  • Create a standard cluster and login to the admin console.
  • If the cluster is running, stop it.
  • Go to the configuration of the cluster and then to Java Message Service.
  • Add -vmargs "-Xmx1024m -XX:MaxPermSize=128m" to Start Arguments.
  • Start cluster. It will fail to start.

The problem is the usage of quotes (which is how multiple vmargs are passed when
using the command-line). Some more information:

  • Using -vmargs -Xmx1024m works fine.
  • Using -vmargs -Xmx1024m -XX:MaxPermSize:128m does not work.

So, I could not find a workaround that would work for multiple vmargs through
the Admin Console web app.

I added some debugging output to imqbrokerd and for both cases that don't work
the vm arguments get split and the first part becomes a vm argument:

"-Xmx1024m or -Xmx1024m

and the second part becomes an application argument:

-XX:MaxPermSize=128m" or -XX:MaxPermSize=128m

For the quoted cause the command is obviously malformed, but for the case
without quotes it seems like the broker fails to start when it receives an
argument that it doesn't recognise.



 Comments   
Comment by ijuma [ 19/Oct/08 ]

"- Using -vmargs -Xmx1024m -XX:MaxPermSize:128m does not work."

Note that there's a typo here, I meant to say that:

  • Using -vmargs -Xmx1024m -XX:MaxPermSize=128m does not work.
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 kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

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 electricsam [ 22/Jan/14 ]

This happens in glassfish 4.0 as well

Comment by bbergquist [ 12/May/16 ]

I researching this I found

http://yangzb.iteye.com/blog/670387

In there I see that the "-vmarg" option is specified multiple times. This appears to work with Glassfish v2. Looking at arguments when I did -Dimq.jms.tcp.port=0 -vmargs -Xss512k -vmargs -Xms256m -vmargs -Xmx1024m

I see using pargs:

bash-3.2# pargs 29180
29180: /opt/canogaview/app/jdk/jdk1.8.0_40/bin/java -cp /opt/canogaview/glassfi sh/imq/
argv[0]: /opt/canogaview/app/jdk/jdk1.8.0_40/bin/java
argv[1]: -cp
argv[2]: /opt/canogaview/glassfish/imq/bin/../lib/imqbroker.jar:/opt/canogaview/ glassfish/imq/bin/../lib/imqutil.jar:/opt/canogaview/glassfish/imq/bin/../lib/js se.jar:/opt/canogaview/glassfish/imq/bin/../lib/jnet.jar:/opt/canogaview/glassfi sh/imq/bin/../lib/jcert.jar:/usr/lib/audit/Audit.jar:/opt/SUNWjdmk/5.1/lib/jdmkr t.jar:/opt/SUNWmfwk/lib/mfwk_instrum_tk.jar:/opt/SUNWhadb/4/lib/hadbjdbc4.jar:/o pt/SUNWjavadb/derby.jar:/usr/share/java/postgresql.jar:/opt/canogaview/glassfish /imq/bin/../lib/ext:/opt/canogaview/glassfish/imq/bin/../lib/ext
argv[3]: -Xms192m
argv[4]: -Xmx192m
argv[5]: -Xss128k
argv[6]: -XX:MaxGCPauseMillis=5000
argv[7]: -Xmx1024m
argv[8]: -Xms256m
argv[9]: -Xss512k
argv[10]: -Dimq.home=/opt/canogaview/glassfish/imq/bin/..
argv[11]: -Dimq.varhome=/opt/canogaview/glassfish/domains/domain1/imq
argv[12]: -Dimq.etchome=/opt/canogaview/glassfish/imq/bin/../etc
argv[13]: -Dimq.libhome=/opt/canogaview/glassfish/imq/bin/../lib
argv[14]: com.sun.messaging.jmq.jmsserver.Broker
argv[15]: -javahome
argv[16]: /opt/canogaview/app/jdk/jdk1.8.0_40
argv[17]: -Dimq.jms.tcp.port=0
argv[18]: -Dimq.cluster.nowaitForMasterBroker=true
argv[19]: -varhome
argv[20]: /opt/canogaview/glassfish/domains/domain1/imq
argv[21]: -startRmiRegistry
argv[22]: -rmiRegistryPort
argv[23]: 7776
argv[24]: -Dimq.imqcmd.user=admin
argv[25]: -passfile
argv[26]: /var/tmp/asmq4092636148720364648.tmp
argv[27]: -save
argv[28]: -name
argv[29]: imqbroker
argv[30]: -port
argv[31]: 7676
argv[32]: -bgnd
argv[33]: -silent
bash-3.2#

Using jvisualvm I do see that the max heap size is 1024m so it appears the later arguments override the earlier ones (ie. there are two -Xmx arguments being passed to the JVM).





[GLASSFISH-21542] Update jboss.logging Created: 11/May/16  Updated: 11/May/16

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

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


 Description   

Update jboss.logging to new 3.3 final to be consistent with latest hibernate ORM 5 requiremenet






[GLASSFISH-21541] Duplicate Class Error when Undeploying/Redeploying Web App Created: 11/May/16  Updated: 11/May/16

Status: Open
Project: glassfish
Component/s: admin_gui, jdbc
Affects Version/s: 4.1, 4.1.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: seaunicornislit Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java, Netbeans


Tags: ear, ejb, svnkit

 Description   

When I try to undeploy/redeploy my Web Application in the Glassfish Admin GUI I receive an error: java.lang.LinkageError: loader (instance of org/glassfish/web/loader/WebappClassLoader): attempted duplicate class definition for name: "org/glassfish/web/loader/JdbcLeakPrevention" (I will put the full stack trace at the very bottom). It may have something to do with SVNKit.

Exception while running a command
java.lang.LinkageError: loader (instance of org/glassfish/web/loader/WebappClassLoader): attempted duplicate class definition for name: "org/glassfish/web/loader/JdbcLeakPrevention"
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at org.glassfish.web.loader.WebappClassLoader.clearReferencesJdbc(WebappClassLoader.java:2121)
at org.glassfish.web.loader.WebappClassLoader.clearReferences(WebappClassLoader.java:2056)
at org.glassfish.web.loader.WebappClassLoader.stop(WebappClassLoader.java:1960)
at org.glassfish.web.loader.WebappClassLoader.preDestroy(WebappClassLoader.java:1929)
at org.glassfish.internal.data.ApplicationInfo.clean(ApplicationInfo.java:465)
at com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:1071)
at com.sun.enterprise.v3.server.ApplicationLifecycle.undeploy(ApplicationLifecycle.java:1099)
at org.glassfish.deployment.admin.UndeployCommand.execute(UndeployCommand.java:412)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Unknown Source)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Unknown Source)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at org.glassfish.deployment.admin.DeployCommand.handleRedeploy(DeployCommand.java:724)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:365)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Unknown Source)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Unknown Source)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:253)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:231)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:275)
at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:133)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:309)
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:292)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1139)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:375)
at org.glassfish.admin.rest.adapter.RestAdapter$2.service(RestAdapter.java:316)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
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:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
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:591)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
at java.lang.Thread.run(Unknown Source)






[GLASSFISH-17449] Redeploy memory leak Created: 20/Oct/11  Updated: 04/May/16

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

Type: Bug Priority: Critical
Reporter: jelinj14 Assignee: russgold
Resolution: Unresolved Votes: 13
Labels: None
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day
Environment:

windows 7, 64bit


Attachments: File keepalive-ref.tiff     File runtest.sh    
Tags: 3_1_2-exclude, 4_0_1-approved, 4_0_1-evangelists, memoryleak, orb-review, redeploy

 Description   

Redeployment causes memory leaks, using jmap and jhat can resolve for example: org.glassfish.javaee.full.deployment.EarClassLoader this class has instance each deploy and undeploy even if app is undeployed



 Comments   
Comment by Hong Zhang [ 21/Oct/11 ]

Assign to tim to take a look as he has done a lot of work of tracking down memory leak in 3.1.1.

Comment by Tim Quinn [ 21/Oct/11 ]

I was able to reproduce the problem.

I deployed a simple EAR (containing an EJB) 100 times, and saw 100 EarClassLoader instances remaining live, even after forcing GCs using jconsole.

(I will attach the simple shell script I used.)

Run the script, then browse to http://localhost:7000.

At least part of the problem seems to be caused by EJB monitoring retaining a reference to each StatelessSessionContainer, which in turn has a reference to EarClassLoader.

I am transferring this to the EJB team for investigation into cleaning up the references from monitoring when a container is retired.

Comment by Tim Quinn [ 21/Oct/11 ]

Attached runtest.sh for repeatedly deploying an app and monitoring memory usage.

Comment by jelinj14 [ 21/Oct/11 ]

When the application is bigger, (I have about 70 stateless session beans on EJB side) it causes big memory leak, every deploy is about 90MB leaks. But I'm not sure whether is it only EarClassLoader.
Thanks for resolve.

Comment by Tim Quinn [ 21/Oct/11 ]

There might well be other issues besides the one I found so far. Once that one is resolved we will look into this again for other leaks.

Comment by Cheng Fang [ 25/Oct/11 ]

Hi Tim, I tried your script with my test EAR on trunk build, and had different results. After finishing your script (100 deploy/undeploy), the result page shows only 3 instances of EarClassLoader.

I then tried deployed/undeploy one by one, and also shows any time after GC, the count is at most 3. The small number of left over instances could be related to annotation processing tasks.

Comment by Tim Quinn [ 25/Oct/11 ]

Cheng,

Perhaps something has changed between 3.1.1 and 4.0 (trunk) then. (I do not have a chance right now to try it myself on the trunk.)

Can whatever the change is be back-ported to 3.1.2? (I realize that requires understanding what change(s) are responsible for the better behavior in 4.0).

Comment by Cheng Fang [ 25/Oct/11 ]

Related to http://java.net/jira/browse/GLASSFISH-17468 (WebappClassLoader leak after undeployment)

Comment by Cheng Fang [ 03/Nov/11 ]

Once issue 17468 is resolved, it will help eliminate some causes of leaks.

Another source of leaks, when deploying apps with remote ejb, is from orb layer. An instance of com.sun.corba.ee.impl.javax.rmi.CORBA.KeepAlive holds a reference to the EarClassLoader after undeploy.

Comment by Cheng Fang [ 03/Nov/11 ]

Attached a screen shot of reference from com.sun.corba.ee.impl.javax.rmi.CORBA.KeepAlive

Comment by Cheng Fang [ 03/Nov/11 ]

re-assign to orb team to evaluate if we can reset the context class loader when creating the KeepAlive thread, to avoid inheriting the app class loader from the parent thread.

Comment by notabenem [ 02/Dec/13 ]

Just run into this on Glassfish 4: com.sun.corba.ee.impl.javax.rmi.CORBA.KeepAlive prevents the EAR from being garbage collected.
This pretty much eliminates the possibility of a reliable reloading mechanism (Continuous delivery)

Comment by electricsam [ 15/Jan/14 ]

I too can confirm that this is occurring in Glassfish 4.0

Comment by electricsam [ 30/Jan/14 ]

I've investigated a workaround until this is fixed. I found references to the current EarClassLoader (to be undeployed) in the following locations:

1. contextClassLoader in various threads
2. Direct references in ThreadLocals in varous threads
3. A contextClassLoader reference in the selector thread of the following field heirerchy: thread.orb.transportManager.selector
4. A contextClassLoader reference in the static resyncThread field of the com.sun.jts.CosTransactions.RecoveryManager class
5. Lots of indirect references in the ThreadLocals in the admin-listener threads

The below listed code will attempt to clean up items 1-3 when an app is undeployed (or redeployed).

For item 4, I was unable to get a reference to the RecoveryManager that had a contextClassLoader reference, but it is static and not as bad as a thread pool issue.

For item 5, the number of references and the object hierarchy depth made a workaround difficult. My best attempt was to limit the pool size for the admin-thread-pool to 5 with a min of 0 and a timeout of 0 (Although, I never see the pool shrink after it reaches capacity). There is still a leak here, but does not seem to grow past a certain point.

Hopefully this will help the GF dev that looks at this issue or any GF users with the same problem until then.

Bar.java
package test;

import java.lang.reflect.Array;
import java.lang.reflect.Field;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.annotation.PreDestroy;
import javax.ejb.Singleton;
import javax.ejb.Startup;

@Singleton
@Startup
public abstract class ClassLoaderCleaner {

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

    private ClassLoader loader = null;

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

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

            }

        }
    }
    
        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 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);
                            }

                        }
                    }

                }
            }
        }
    }

}
Comment by Ed Bratt [ 20/May/14 ]

Assigned FYI ...

Comment by russgold [ 11/Jun/14 ]

If, as notabenem says, it is the KeepAlive objects preventing the garbage collection, that suggests that deploying the EAR is calling javax.rmi.CORBA.registerTarget, but undeploying is not calling javax.rmi/CORBA.unexportObject for each of the remote objects.

I'm going to look through the source to see where this is being called.

Comment by bebbo [ 04/May/16 ]

It's still present in glassfish 4.1.1.

I am using a ContextListener do null out references if contextDestroyed is invoked. For the ORB I am using

    private void fixORB() {
        try {
            // fix the ORB
            final Object globalPM = getMember(null, Class.forName("com.sun.corba.ee.spi.orb.ORB"), "globalPM");
            final Object weakCache = getMember(globalPM, "classToClassData");
            final Map<?, ?> classToClassData = (Map<?, ?>) getMember(weakCache, "map");

            LOG.info("clearing classToclassData map");
            classToClassData.clear();

        } catch (Exception ex) {
            LOG.error(ex, ex);
        }
    }

I am also patching way more locations to get a reliable undeployment/redeployment. See the full code of my ContextListener here: http://franke.ms/glassfish4_1_1_memory_leak.wiki





[GLASSFISH-21246] Grizzly thread pool waiting on LinkedTransferQueue hangs application Created: 03/Nov/14  Updated: 02/May/16

Status: Open
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 4.1_b10
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: afcarv Assignee: oleksiys
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 4.1_b13, JDK 1.7u67, Linux CentOS 3.10.48 x64



 Description   

Elaborating on the issue I posted on GLASSFISH-21211.

After some time running, http-listener-1 thread pool stops responding. Checking the logs, I see multiple messages like the one below:

[2014-11-03T18:50:47.114+0000] [glassfish 4.1] [SEVERE] [] [org.glassfish.grizzly.nio.SelectorRunner] [tid: _ThreadID=60 _ThreadName=http-listener-1-kernel(1) SelectorRunner] [timeMillis: 1415040647114] [levelValue: 1000] [[
  doSelect exception
java.util.concurrent.RejectedExecutionException: The thread pool's task queue is full, limit: 4096
        at org.glassfish.grizzly.threadpool.AbstractThreadPool.onTaskQueueOverflow(AbstractThreadPool.java:464)
        at org.glassfish.grizzly.threadpool.QueueLimitedThreadPool.execute(QueueLimitedThreadPool.java:81)
        at org.glassfish.grizzly.threadpool.GrizzlyExecutorService.execute(GrizzlyExecutorService.java:161)
        at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.executeIoEvent(WorkerThreadIOStrategy.java:100)
        at org.glassfish.grizzly.strategies.AbstractIOStrategy.executeIoEvent(AbstractIOStrategy.java:89)
        at org.glassfish.grizzly.nio.SelectorRunner.iterateKeyEvents(SelectorRunner.java:414)
        at org.glassfish.grizzly.nio.SelectorRunner.iterateKeys(SelectorRunner.java:383)
        at org.glassfish.grizzly.nio.SelectorRunner.doSelect(SelectorRunner.java:347)
        at org.glassfish.grizzly.nio.SelectorRunner.run(SelectorRunner.java:278)
        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:744)
]]

I then took a thread dump which shows all threads in http-listener-1 in a state like the below:

"http-listener-1(31)" daemon prio=10 tid=0x00007ff19422b000 nid=0x6c61 waiting on condition [0x00007ff1f6eed000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000006036fd360> (a java.util.concurrent.LinkedTransferQueue)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
        at java.util.concurrent.LinkedTransferQueue.awaitMatch(LinkedTransferQueue.java:735)
        at java.util.concurrent.LinkedTransferQueue.xfer(LinkedTransferQueue.java:644)
        at java.util.concurrent.LinkedTransferQueue.take(LinkedTransferQueue.java:1137)
        at org.glassfish.grizzly.threadpool.FixedThreadPool$BasicWorker.getTask(FixedThreadPool.java:105)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:557)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
        at java.lang.Thread.run(Thread.java:744)

They seem to be waiting on LinkedTransferQueue take() method, which appears to be not responding (waiting for some item to arrive in the queue?). I also took a memory dump that I can look into if someone points me in the right direction.

Thought this could be related to GRIZZLY-1711 but after applying the latest version (2.3.17-SNAPSHOT) this behavior is still happening.

Let me know if I should get more data - thanks!



 Comments   
Comment by davidwinters1980 [ 03/Nov/14 ]

This appears to be occurring as a result of the http thread pool reaching its limit of 4096.

As per the default domain.xml setting:

<thread-pools>
<thread-pool name="admin-thread-pool" max-thread-pool-size="50" max-queue-size="256"></thread-pool>
<thread-pool name="http-thread-pool" max-queue-size="4096"></thread-pool>
<thread-pool name="thread-pool-1" max-thread-pool-size="200"/>
</thread-pools>

You could configure this to -1 or unlimited but this will likely lead to other issues such as out of memory etc

It would appear as though tasks are being added to this queue faster than the tasks can be processed. I would investigate why this occurring? If you could take a number of thread dumps over a period of time whereby we capture this issue occurring that would be useful.

Furthermore, it maybe worth increasing the value of your http request processing threads as this will allow more tasks to be handled concurrently off the http thread task queue and so it may reach the 4096 limit so quickly. What is the current value of the number of http request processing threads??

The issue you have here is very dependent on the number of http requests being pushed to the http task pool and how quickly these requests are being handled so appropriate tuning of the http parameters may resolve this issue. If this fails then looking at the state of all threads running over a period of time should give you a hint as to why requests are taking so long to process.

Comment by afcarv [ 03/Nov/14 ]

I don't think it's a configuration issue as the environment is able to handle much heavier loads - it may be due to specific and temporary environmental reasons (network latency, database slowdown, etc) but you'd think it would resume work as soon as this is normalized. This does not happen (waited for some hours to be sure), even if the consumer is stopped and there's no inbound traffic anymore - the only way to bring it back online is with a server/cluster restart. I did notice a lot of connections in the CLOSE_WAIT state in the server, though.

Haven't tried to raise the queue limit or remove it yet, but I suspect it would only delay the occurrence or eventually reach an OOM error.

I see no obvious reason for this looking at the thread pool dump, but will post it later for analysis. Thanks!

Comment by afcarv [ 04/Nov/14 ]

Please find attached the full thread dump and the server log file. The dump was taken about 30 minutes after the issue manifested itself - you can see all threads in the http-listener-1-kernel pool reach the queue limit and stop responding. http-thread-pool contains 32 threads; there are 8 acceptor threads.

Interestingly, http-listener-2 (SSL) continues to respond normally. http-listener-1 hanged and required a server restart. The configuration is a 2 instance cluster with a nginx load balancer in front; there are Jersey applications deployed serving RESTful webservices. The configuration can handle about 5x the average load on the server - no increased throughput was observed leading to the issue, which persisted after stopping all inbound traffic.

I will schedule a cron job to take a thread dump every 5 minutes to check on any odd behavior leading to the issue - thanks!

Thread dump: https://www.dropbox.com/s/qejdzhwejlv1zzp/threadump.txt?dl=0
Server log: https://www.dropbox.com/s/rbu24cep9y25aol/server.log?dl=0

Comment by afcarv [ 04/Nov/14 ]

Some more info I got from the memory dump -

I see lots of instances of TCPNIOConnection (1500+) in what appears to be a closing state; as the latest snapshot was applied I can see these with a CloseReason of "LOCALLY". May explain the connections in the CLOSE_WAIT state I saw? Is it possible that nginx closed the socket before a FIN packet could be sent from the server, and now it is not able to end the connection properly? Not sure if this could be just a consequence of some other issue, though.

Comment by oleksiys [ 06/Nov/14 ]

Which Grizzly version is used in 4.1_b10?

Thank you.

Comment by afcarv [ 06/Nov/14 ]

We're using b13 (couldn't find the tag for it so I selected the closest), but I believe it's the same version - 2.3.15.

Currently, 2.3.17-SNAPSHOT is applied.

By the way - we found out that what triggers this behavior is a DB performance degradation, causing the requests to queue and eventually reach the limit. No additional info on why queue isn't being reduced, though.

Comment by davidwinters1980 [ 06/Nov/14 ]

Could you take a number of thread dumps say every 5 minutes so that we can compare the different thread dump files leading up to the hang? Also could you send us on the contents of the <transports> which should contain the different tcp parameters used by Grizzly.

<transports>
<transport byte-buffer-type="HEAP" display-configuration="true" name="tcp" .....></transport>
</transports>

Useful to know db degradation issues are causing requests in the queue to fill up. It might be useful to get some debug grizzly logging on here: org.glassfish.grizzly.level=FINEST

Thanks.

Comment by afcarv [ 10/Nov/14 ]

I had some monitoring in place but we've been focusing on fixing the db degradation so the issue won't be triggered - so far we've been successful, so it looks unlikely I'll be able to collect more data in the production system.

What I'm going to try next is to create a sample application and configuration that will be able to recreate the issue - doesn't look too hard; just a sample RESTful webservice that performs a db query that has an artificial delay in response, small db connection pool and a sample JMeter test script with http requests that will timeout before the app has a chance to respond. Should replicate the conditions pretty closely (don't know if nginx in front plays a role in this or not, so will try without it first).

Will report on any news, thanks!

Comment by oleksiys [ 10/Nov/14 ]

pls. try to patch GFv4.1 with this patch [1].
I need server.log output message(s) like:
"The queue is overflowed. queuePermits=......."

Thank you.

[1] https://dl.dropboxusercontent.com/u/7319744/glassfish-21246/nucleus-grizzly-all.jar

Comment by afcarv [ 22/Oct/15 ]

Hi - I've been looking into this again. We still get a non-responsive cluster from time to time, and it's always due to some external resource that cause the task queue to overfill; I've seen it happen due to a DB slowdown (as I've reported before) and also due to an issue with ActiveMQ (slow response).

Recreating this in a test environment has been proving to be quite tricky, but it appears I have devised a somewhat reliable way to do it using the scenario I've described before and using a test thread pool with at least twice the number of the task queue maximum capacity to generate requests to the application server.

I've successfully triggered this issue in GFv4.0, GFv4.1 and GFv4.1.1.

I will apply your patch next and report back if I get any results - thanks!

Comment by afcarv [ 22/Oct/15 ]

Please find server.log file below:

https://dl.dropboxusercontent.com/u/106573849/GF-21246/server.log

Method "testDAOMethod()" of class "TestDAOBean" calls a stored procedure that waits for 1 minute before giving a response. Ran a test script that kept calling a RESTful endpoint which invoked this method; massive amount of requests caused the http-listener-1 task queue to quickly overfill and stop responding. At this point, I stopped the test script by killing the process.

About 1 hour later, http-listener-1 is still hung. I then made a test call to the SSL endpoint which is handled by http-listener-2; this request went through cleanly, as can also be seen in the log file.

Let me know if you want me to run additional tests or fetch additional information. Thanks!

Comment by ruVooDoo [ 12/Nov/15 ]

Hello, our prod env show the same pattern...
"http-listener-1(119)" daemon prio=10 tid=0x00007f6409038000 nid=0x27e2 waiting on condition [0x00007f62f62e1000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)

  • parking to wait for <0x000000067d016e20> (a java.util.concurrent.LinkedTransferQueue)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
    at java.util.concurrent.LinkedTransferQueue.awaitMatch(LinkedTransferQueue.java:735)
    at java.util.concurrent.LinkedTransferQueue.xfer(LinkedTransferQueue.java:644)
    at java.util.concurrent.LinkedTransferQueue.take(LinkedTransferQueue.java:1137)
    at org.glassfish.grizzly.threadpool.FixedThreadPool$BasicWorker.getTask(FixedThreadPool.java:105)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:556)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
    at java.lang.Thread.run(Thread.java:724)

Thats very wierd, becauseour app working perfect for month`s on GF 4.0, but now it`s hanging... We did not change anything in the app.

Could you please provide a fix?

Comment by oleksiys [ 12/Nov/15 ]

@ruVooDoo the stacktrace you provided doesn't mean GF hangs, it's just a thread waiting for a task to be assigned.
The problem can be somewhere else.
Please provide full stacktrace (all threads) snapshot at the time you see the problem.

Comment by ruVooDoo [ 12/Nov/15 ]

https://www.dropbox.com/s/9ur7963sf3tb2ja/gso_hung_27757.txt?dl=0
We are using GlassFish Server Open Source Edition 4.0 (build 89)

Comment by mmora [ 12/Apr/16 ]

Hi,
I have the same problem as you, I am using GlassFish 4.1.1 with JDK 8u77 and after a while operating the http-thread-pool stops responding, returning blank pages. It happens more often the more use the application.
How I can fix it?

Comment by oleksiys [ 02/May/16 ]

@ ruVooDoo from the stacktrace you shared - many threads are blocked in your WS/EJB/MQ code, I don't think it has anything to do with LinkedTransferQueue.

@mmora is it a blank with an HTTP response code, or connection is getting broken/closed? Please share the stacktrace dump when this happens.





[GLASSFISH-20850] classloader favors modules/guava.jar over guava library in the ear Created: 11/Oct/13  Updated: 01/May/16

Status: Open
Project: glassfish
Component/s: cdi, classloader
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Thomas Andres Assignee: Romain Grécourt
Resolution: Unresolved Votes: 18
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JERSEY-1884 Jersey 2.0 Maven artiifact depends on... Closed

 Description   

I tried to upgrad the guava library in our application to version 15-0. When I deploy the application on glassfish 4.0, I see the following Exception:

Caused by: java.lang.NoSuchMethodError: com.google.common.base.Stopwatch.createStarted()Lcom/google/common/base/Stopwatch;
at MyClient.buildClient(MyClient.java:159)
at MyClient.initClient(MyClient.java:143)
at MyClient.<init>(MyClient.java:74)
at MyClient.<init>(MyClient.java:62)
at MyClientFactory.createClient(MyClientFactory.java:12)
at MyClientProducer.createClient(MyClientProducer.java:16)
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.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:93)

To verify where the class is loaded from, I added:
URL resource = this.getClass().getClassLoader()
.getResource(Stopwatch.class.getName().replaceAll("
.", "/") + ".class");
LOGGER.info("URL for Stopwatch:" + resource.toString());
which gives me
URL for Stopwatch:bundle://108.0:1/com/google/common/base/Stopwatch.class

MyClient, MyClientFactory and MyClientProducer are all inside an ejb jar file.
guava-15.0.jar is in a lib folder next to the ejb jar (with lib/guava-15.0.jar in the ear META-INF/MANIFEST.MF Class-Path)

All other libraries there can be found. It just seems, that the weld classloader favors the guava.jar bundled with glassfish 4 over the one I provide for the application. I would expect the classloader to give stuff deployed with the ear a higher priority.



 Comments   
Comment by Thomas Andres [ 11/Oct/13 ]

BTW: Deploying the same ear on glassfish 3.1.2.2 works. The guava class is loaded correctly from the jar inside my ear.

(with a patched beans.xml, but that's another story...)

Comment by Joe Di Pol [ 11/Oct/13 ]

When we have had similar problems in the past the issue was that an OSGi module was exporting packages without any mechanism to prevent them from being found by the application's hierarchy of class loaders.

The solution was to add mandatory OSGi attributes to the exported packages that must be declared by any other module that wanted to import the packages. This prevents the API/Packages from leaking into the application space. I looked at guava.jar and it does not appear to do this – so maybe this is the problem.

For some additional information on this issue see the following:

https://java.net/jira/browse/GLASSFISH-5385
https://java.net/jira/browse/GLASSFISH-18176

Comment by simon.schlachter [ 31/Oct/13 ]

Exactly the same problem here.

Comment by simon.schlachter [ 01/Nov/13 ]

We were able to workaround the problem, by "patching" the manifests (MANIFEST.MF) of the included guava.jar file and its dependencies.

in guava we added ;mandatory:=password;password="GlassFish to all export-statements.

In the dependent modules we added ;password="GlassFish" to all import statements concerning com.google.common.*

The list of modules we had to patch is

  • jersey-bean-validation.jar
  • jersey-client.jar
  • jersey-common.jar
  • jersey-container-servlet-core.jar
  • jersey-container-servlet.jar
  • jersey-gf-cdi.jar
  • jersey-media-moxy.jar
  • jersey-mvc-jsp.jar
  • jersey-mvc.jar
  • jersey-server.jar

The effect of this change is that guava.jar-classes do no longer leak into the class path of our deployed application. This solves the guava-version-problem for us. The root problem, however, is not solved: Glassfish still favors its own classpath instead of that of the deployed application.

(The Idea for this workaround is originally from GLASSFISH-5385)

Comment by hsaqallah [ 14/Feb/14 ]

Patching GF4's files is error-prone and very impractical for a sane development/test/stage/prod environment. There should have been an easier fix. Too bad. Time to switch to Tomcat 7.

Comment by gcruscoe [ 21/Jul/14 ]

#fishcat

Testing glassfish 4.0.1 b08. I am having this issue with the moduels/guava.jar being used over the guava I have in my .ear project. It is preventing migration from 3.1.2.2 to 4.0.1. This seems like a critical issue that should be fixed for b09. It makes it impossible to even test the rest of the system if your app is using a different / incompatible version of guava.

Also this links a bug that says Jersey is going to fix theirs and when it is incorporated it will fix this. I think that version of Jersey has been incorporated but this issue is still there.

Comment by cristim1979 [ 20/Aug/14 ]

We also encountered the same defect with our application which uses Guava 17.0, and which used to work well on Glassfish 3.1.2.2.
But on Glassfish 4.0 it crashed at deploy; to fix it, we came in the end to same workaround like described by simon.schlachter above - patch 11 of the jars in \modules\ folder. But this is very impractical for a clean/official upgrade to 4.0.

Comment by Thomas Andres [ 22/Aug/14 ]

I just did a quick test with our application on glassfish 4.1 (currently on glassfish 4.0)
Most work out of the box without any changes. Compliments on that!

However I noticed this issue got a bit worse, since v4.1 now has guava v13 bundled which is a downgrade from v14 in GF4.0. (WTF??? what's the reason for this?)
I hope you can fix this for 4.1 release.

Comment by Romain Grécourt [ 22/Aug/14 ]

guava is a dependency for both weld and jersey.
Jersey now shadows what it needs, what remains is weld's dependency.

It's too late to be included in 4.1 release (it will go in the next one).
The workaround is the same, but only involves guava + weld jars.

Comment by Thomas Andres [ 22/Aug/14 ]

But what's the reason to downgrade the guava libray? This will cause additional problem to people who now use guvava v14 to avoid this problem.

Comment by Romain Grécourt [ 22/Aug/14 ]

In v4, guava was provided twice: guava.jar (for jersey) and weld-osgi-bundle.jar: both are using different versions.
In v4.1 Jersey has removed its guava dependency (it's now shadowed).

As of weld 2.1.0.Beta2 guava is not part of weld-osgi-bundle.jar, but just an OSGi dependency.
GlassFish 4.1 bundles weld 2.2.2.Final, that's why we are providing a different guava version than what was in 4.0.

Comment by Thomas Andres [ 22/Aug/14 ]

Thanks for the explanation. Looks strange when you look just at the jar, but makes sense like this.
I just tried replacing guava.jar with the version provided with v4 and that works fine so far. You might wanna consider doing that if you can't fix this issue, since that makes at least the transition from v4 to v4.1 a bit smoother.

Comment by lprimak [ 26/Aug/14 ]

I just put guava-17.jar into Glassfish modules/ directory ant it worked.
Had to delete osgi-cache/* from the domain (but only once after the patch)

Is this not simpler than the other patch in the comments above?

Comment by Romain Grécourt [ 26/Aug/14 ]

This is a server wide workaround (you may want to test a few CDI things though).
The one described above (password=GlassFish) applies for applications (i.e WEB-INF/lib).

Comment by vps [ 24/Feb/15 ]

Still same in 4.1.b13.

I ended up using a custom class loader to work around this.
The code is below, if anyone's interested; obviously it's only meant to solve my particular problem, but can be easily changed to prevent delegation for more classes.
When I started, I tried to prevent delegation of everything, but quickly run into problems with the fact that I package (for some reason) too much API classes (JTA was the first that hit me). Even passing java* packages didn't help, as there was some problem with JSF classes, exacerbated by the fact that I had JSF that was older than what's in GF. It was quicker for me to just limit the delegation to the package prefix that I care about, then to clean up my EAR libraries (I'm sure most of the stuff that I package is my fault, and shouldn't be done that way)

I think the glassfish-application.xml should have a section that describes what should and should not be delegated, based on list of RegEx of class names. Then the EAR library classloader should use that list to determine what to delegate and what to not - this will give flexibility to solve virtually any use cases. I recall WebLogic has something that does that. In all cases, it's reasonable to expect that both GF will need to carry some libraries, and the application carry the same, and they may be in severe conflict, and that may be by design.

EarLibClassLoader.java
/*
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
 *
 * Copyright (c) 1997-2010 Oracle and/or its affiliates. All rights reserved.
 *
 * The contents of this file are subject to the terms of either the GNU
 * General Public License Version 2 only ("GPL") or the Common Development
 * and Distribution License("CDDL") (collectively, the "License").  You
 * may not use this file except in compliance with the License.  You can
 * obtain a copy of the License at
 * https://glassfish.dev.java.net/public/CDDL+GPL_1_1.html
 * or packager/legal/LICENSE.txt.  See the License for the specific
 * language governing permissions and limitations under the License.
 *
 * When distributing the software, include this License Header Notice in each
 * file and include the License file at packager/legal/LICENSE.txt.
 *
 * GPL Classpath Exception:
 * Oracle designates this particular file as subject to the "Classpath"
 * exception as provided by Oracle in the GPL Version 2 section of the License
 * file that accompanied this code.
 *
 * Modifications:
 * If applicable, add the following below the License Header, with the fields
 * enclosed by brackets [] replaced by your own identifying information:
 * "Portions Copyright [year] [name of copyright owner]"
 *
 * Contributor(s):
 * If you wish your version of this file to be governed by only the CDDL or
 * only the GPL Version 2, indicate your decision by adding "[Contributor]
 * elects to include this software in this distribution under the [CDDL or GPL
 * Version 2] license."  If you don't indicate a single choice of license, a
 * recipient has the option to distribute your version of this file under
 * either the CDDL, the GPL Version 2 or to extend the choice of license to
 * its licensees as provided above.  However, if you add GPL Version 2 code
 * and therefore, elected the GPL Version 2 license, then the option applies
 * only if the new code is made subject to such option by the copyright
 * holder.
 */

package org.glassfish.javaee.full.deployment;

import java.net.URL;
import com.sun.enterprise.loader.ASURLClassLoader;
//import com.sun.enterprise.util.CULoggerInfo;
import java.util.logging.Logger;
import java.util.logging.LogManager;
import java.util.logging.Level;
import java.util.regex.*;
import java.util.*;

/**
 * Classloader that is responsible to load the ear libraries (lib/*.jar etc)
 *
 */
public class EarLibClassLoader extends ASURLClassLoader
{

    // private static final Logger _logger=CULoggerInfo.getLogger();
    // private static final Logger _logger=LogManager.getLogManager().getLogger("earcl");
    private static final Logger _logger=Logger.getLogger("earcl");

    private static final Collection<Pattern> preventDelegate =
        new ArrayList<Pattern>();

    static {
        preventDelegate.add(Pattern.compile("^com\\.google\\..*$"));
    }

    public EarLibClassLoader(URL[] urls, ClassLoader classLoader) {
        super(classLoader); 

        for (URL url : urls) {
            addURL(url);
        }
    }

    @Override
    protected String getClassLoaderName() {
        return "EarLibClassLoader";
    }

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        try {
            Class<?> c = super.findClass(name);
            // _logger.log(Level.INFO, "findClass() called for "+name + "->found");
            return c;
        } catch (ClassNotFoundException e) {
            // _logger.log(Level.INFO, "findClass() called for "+name + "->NOT FOUND");
            throw e;
        }
    }


    @Override
    protected Class<?> loadClass(String name, boolean r) throws ClassNotFoundException {

        // let's make it non-delegating!

        // logger.log(Level.INFO, "EAR loading "+name+", resolve:"+r);

        boolean matched = false;
        for (Pattern p : preventDelegate) {
            Matcher m = p.matcher(name);
            if (m.matches()) {
                matched = true;
                break;
            }
        }

        if (!matched) {
            try {
                Class<?> c = super.loadClass(name,r);
                // logger.log(Level.INFO, "not matched "+name+", delegating -> found");
                return c;
            } catch (ClassNotFoundException e) {
                // logger.log(Level.INFO, "not matched "+name+", delegating -> NOT FOUND");
                throw e;
            }
        }
    
        synchronized (getClassLoadingLock(name)) {

            ClassNotFoundException toThrow = null;

            Class<?> c = findLoadedClass(name);
            if (c == null) {
            
                try {
                    c = findClass(name);
                    // logger.log(Level.INFO, "-> self found class"+name+", will return.");
                } catch (ClassNotFoundException ne) {
                    toThrow = ne;
                    // _logger.log(Level.INFO, "-> self could not find class "+name);
                }
            
            }

            if (c == null) {
                ClassLoader parent = getParent();
                if (parent == null) {
                    // _logger.log(Level.INFO, "-> no parent, throwing CNF for "+name);
                    throw toThrow;
                }
                try {
                    c = parent.loadClass(name);
                    // _logger.log(Level.INFO, "-> parent loaded class "+name);
                } catch (ClassNotFoundException ignored) {
                    // _logger.log(Level.INFO, "-> parent could not load class, throwing CNF for "+name);
                    throw toThrow;
                }
            } else {
                // _logger.log(Level.INFO, "-> self class "+name+" is already loaded");
            }

            if (r) {
                // _logger.log(Level.INFO, "-> resolving class");
                resolveClass(c);
            }

            return c;

        }
    
    }

}

Applying this to GF:

# make sure JDK 1.8 is used
# note that the output is written to /tmp/bout
mkdir -p /tmp/bout
/opt/java/jdk1.8/bin/javac -d /tmp/bout/ -cp ~/soft/glassfish4/glassfish/lib/appserv-rt.jar: EarLibClassLoader.java
# now, we need to update the .jar file that contains that class
# it's expected that GlassFish distribution is unzipped somewhere
# change to glassfish home directory before running the next lines
cd glassfish/modules
# let's unzip existing .jar that needs to be updated
mkdir -p _z
cd _z
unzip ../deployment-javaee-full.jar
# copy the modified .class
# note that current directory is _z where we unpacked the existing .jar
cp /tmp/bout/org/glassfish/javaee/full/deployment/EarLibClassLoader.class org/glassfish/javaee/full/deployment/EarLibClassLoader.class
# let's update the .jar file. Note that the jar command is crazy, but we must preserve the manifest!
/opt/java/jdk1.8/bin/jar uvfmM  ../deployment-javaee-full.jar META-INF/MANIFEST.MF .
# now, if necessary, we can update the distribution
# change to the directory that contains the glassfish4 directory as was extracted from .zip file
cd /opt/soft
zip -u glassfish-4.1.zip glassfish4/glassfish/modules/deployment-javaee-full.jar
Comment by lprimak [ 24/Feb/15 ]

How do I apply the above code in my Glassfish installation?

Comment by lprimak [ 25/Feb/15 ]

Ah, this is unfortunate. It requires patching the server itself.
This needs to be fixed by GlassFish team IMHO.

Comment by kithouna [ 02/Jun/15 ]

Simple workaround: I added <class-loader delegate="false"/> to glassfish-web.xml, now Guava is loaded from the WAR.

Comment by lprimak [ 02/Jun/15 ]

Does this work for ear files?

Comment by gabor.varga [ 04/Jun/15 ]

If you set <class-loader delegate="false"/>, JNDI lookups (e.g. with InitialContext.lookup() will fail.

Comment by lprimak [ 07/Sep/15 ]

Just to recap the current status of this issue:
JARs in GF modules/ directory erroneously take precedence of JARs in user specified applications
Examples:

  • guava.jar
  • jackson-*.jar
  • Others?

Here are the current observations:

  •  <class-loader delegate="false"/> 

    works correctly for, but only for WAR files that have guava.jar and other JARs in it's lib/ directory

  • does NOT work correctly if updated JARs are in domain/lib directory
  • vps's patch above works correctly, but only for skinny WARs or EJB-JARs inside EAR files
  • simon.schlachter's patch above was not tested due to it's implementation complexity
Comment by lprimak [ 17/Apr/16 ]

Payara team is actively working to fix this issue

Comment by Thomas Andres [ 18/Apr/16 ]

Thanks for the information. Is there a payara issue to track for news regarding this issue?

Comment by lprimak [ 18/Apr/16 ]

Yes, Thomas,

https://github.com/payara/Payara/issues/419
https://github.com/payara/Payara/issues/431

Comment by lprimak [ 01/May/16 ]

This issue is now fixed in Payara, should be out with the next release (.162)
The functionality is enabled globally with system property:

fish.payara.classloading.delegate=false

similar to configuration in glassfish-web.xml

Also, the functionality can be enabled in individual EAR files with the entry:

<classloading-delegate>false</classloading-delegate>

in glassfish-application.xml





[GLASSFISH-21540] Cannot use non-default password in truststore from remote client (IIOP SSL) Created: 29/Apr/16  Updated: 29/Apr/16

Status: Open
Project: glassfish
Component/s: jms, security
Affects Version/s: 4.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: epms.devteam Assignee: David Zhao
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64 bits and Linux



 Description   

I'm trying to access a Message Queue configured in GlassFish, with SSL, from a standalone client, but I can only make it work if I use the default password (changeit) on my trustStore. I'm always getting "Keystore was tampered with, or password was incorrect" if I try to use a different password.
If I set the Trust Store with the default password and use the following property with a wrong value, it still works "-Djavax.net.ssl.trustStorePassword=<wrong value>", which confirms that it that it completely ignores this setting.
After digging a little deeper, I've detected a behavior that seems a bug. Looking at the stacktrace, one of the first methods being invoked is initJKS() from com.sun.enterprise.security.ssl.impl.SecuritySupportImpl. With the help of javassist, I realized that the following section is being invoked:

if (masterPasswordHelper == null && Globals.getDefaultHabitat() != null)

{ masterPasswordHelper = Globals.getDefaultHabitat().getByType(MasterPasswordImpl.class); }

if (masterPasswordHelper instanceof MasterPasswordImpl)

{ keyStorePass = masterPasswordHelper.getMasterPassword(); trustStorePass = keyStorePass; }

Causing the bypass of the next set of instructions:

if (keyStorePass == null)

{ keyStorePass = System.getProperty(KEYSTORE_PASS_PROP, DEFAULT_KEYSTORE_PASS).toCharArray(); trustStorePass = System.getProperty(TRUSTSTORE_PASS_PROP, DEFAULT_TRUSTSTORE_PASS).toCharArray(); }

And, as a consequence, to ignore the user defined property javax.net.ssl.trustStorePassword.

Why is Globals.getDefaultHabitat() returning a non null value? Why isn't a user defined property overriding any previous setting?

NOTE: Due to PCI compliance requisites, I do need to set a password on the trustStore.






[GLASSFISH-21340] CDI scope annotation on @Provider makes @NameBinding ignored Created: 26/Mar/15  Updated: 29/Apr/16

Status: Open
Project: glassfish
Component/s: jax-rs
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: m-radzikowski Assignee: Marek Potociar
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

1.8.0_40



 Description   

Using CDI scope annotation (e.g. @javax.enterprise.context.RequestScoped) makes annotations with @javax.ws.rs.NameBinding ignored in @javax.ws.rs.ext.Provider.

Sample code:

EnableScopedFilter
@Retention(RUNTIME)
@NameBinding
public @interface EnableScopedFilter {	
}
ScopedFilter
@Provider
@EnableScopedFilter
@RequestScoped
public class ScopedFilter implements ContainerRequestFilter {
	@Override
	public void filter(ContainerRequestContext requestContext) throws IOException {
		System.out.println("Scoped filter triggered on path: " + requestContext.getUriInfo().getPath());
	}
}

This filter is executed on every REST method, not only on these annotated with @EnableScopedFilter. If @RequestScoped is removed everything is ok.

CDI scope annotation is needed is bean-discovery-mode in beans.xml is set to "annotation" and filter needs to @Inject some resources.



 Comments   
Comment by jjsnyder83 [ 30/Mar/15 ]

I don't think this is a CDI issue. I think it is a jax-rs issue. Assigning to jax-rs.

Comment by HeinBloed [ 29/Apr/16 ]

Was this bug resolved in a newer Jersey version? I couldn't find any other information about it. Also facing it with GF 4.1.





[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-21539] JAX-WS HandlerChain issue Created: 23/Apr/16  Updated: 23/Apr/16

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

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

CentOS 6.5 + NetBeans 8.1



 Description   

I got the below exception when deploying web service endpoint with handlers

  • Exception log
    Severe: Component referenced from annotation symbol cannot be found
    symbol: javax.jws.HandlerChain
    location: class master.wsservices.CargoGeneralServices
    Severe: Annotations processing failed for file:/home/cargo-tracker/target/cargo-tracker/
  • JAX-WS
    @WebService
    @HandlerChain(file = "handler-chain.xml")
    public class WSGeneralService {
    /**
  • Web service operation
    */
    @WebMethod(operationName = "hello")
    public CargoDTO hello(@WebParam(name = "name") String name) { return "Hello, " + name; }

    }

  • Handler chain file
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <javaee:handler-chains
    xmlns:javaee="http://java.sun.com/xml/ns/javaee"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <javaee:handler-chain>
    <javaee:handler>
    <javaee:handler-class>JWSSOAPInterceptor</javaee:handler-class>
    </javaee:handler>
    </javaee:handler-chain>
    </javaee:handler-chains>
  • Handler class

public class JWSSOAPInterceptor implements SOAPHandler<SOAPMessageContext>{

@Override
public Set<QName> getHeaders()

{ return null; }

@Override
public boolean handleMessage(SOAPMessageContext context) {
Boolean outboundProperty = (Boolean)
context.get (MessageContext.MESSAGE_OUTBOUND_PROPERTY);

if (outboundProperty.booleanValue())

{ System.out.println("\nOutbound message:"); }

else

{ System.out.println("\nInbound message:"); }

System.out.println("======== Response: "+context.getMessage().toString());

return true;
}

@Override
public boolean handleFault(SOAPMessageContext context)

{ return true; }

@Override
public void close(MessageContext context) {

}

}






[GLASSFISH-21538] Admin Console shows blank page after some configuration changes Created: 21/Apr/16  Updated: 21/Apr/16

Status: Open
Project: glassfish
Component/s: admin, admin_gui
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: tmpsa Assignee: Chris Kasso
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 14



 Description   

After certain changes in the configuration, and a restart of GF, the Admin Console goes bananas. It prompts for login all right, but then responds with a blank page (empty HTML page).

Any of the following two steps in my attempt to install and configure 4.1.1 will reproducibly cause this breakage on my server. There does not seem to be any significant entries in server.log, unfortunately.

+ Configurations > server-config > Security

  • In 'Default Realm' select admin-realm and click "Save"
  • Restart Glassfish to verify that it still works.

+ Use default principal-to-role mapping, no need for a sun-web.xml
In Configurations > server-config > Security

  • Check the box "Default Principal to Role Mapping"
  • Click "Save"
  • Restart Glassfish to verify that it still works.

I will happily assist with further details if necessary.
This problem is a show-stopper; it prevents me from upgrading from 3.1.2.2 to 4.1.1!



 Comments   
Comment by tmpsa [ 21/Apr/16 ]

Btw: Java version 1.8.0_74





[GLASSFISH-21532] com.sun.jts.CosTransactions.GlobalTID breaks the equals/hashCode contract Created: 09/Apr/16  Updated: 19/Apr/16

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

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


 Description   

Whilst testing JTS transaction propagation between glassfish and other application servers I hit a recovery problem (which I reported via https://java.net/projects/glassfish/lists/dev/archive/2016-04/message/0) caused by implementation of the GlobalTID.hashCode() method. It is possible to create to GlobalTID instances with are the same according to the equals method but have different hash codes. A simple test showing the problem is:

GlobalTID Test
import org.omg.CosTransactions.otid_t;
import com.sun.jts.CosTransactions.GlobalTID;

public class X {
    public static void main(String[] args) {
        test();
    }

    public static void test() {
        otid_t otid1 = toOtid("xyz".getBytes(), "a".getBytes());
        otid_t otid2 = toOtid("xyz".getBytes(), "".getBytes());

        GlobalTID tid1 = new GlobalTID(otid1);
        GlobalTID tid2 = new GlobalTID(otid2);

        if (!tid1.equals(tid2))
            throw new AssertionError("GlobalTIDs should be equal");

        // equal objects must have the same hashCode
        if (tid1.hashCode() != tid2.hashCode())
            throw new AssertionError("equal GlobalTID objects should have the same hash code");
    }

    private static otid_t toOtid(byte[] gtid, byte[] bqual) {
        otid_t otid = new otid_t();

        otid.formatID = 0;
        otid.tid = new byte[gtid.length + bqual.length];
        otid.bqual_length = bqual.length;

        /*
         * gtrid must be first then immediately followed by bqual.
         * bqual must be between 1 and 64 bytes if for XA.
         */

        System.arraycopy(gtid, 0, otid.tid, 0, gtid.length);
        System.arraycopy(bqual, 0, otid.tid, gtid.length, bqual.length);

        return otid;
    }
}

To compile and run the example put the following three jars on the classpath:

export CLASSPATH=.:glassfish-corba-omgapi.jar:jts.jar:common-util.jar






[GLASSFISH-21537] JsonObjectBuilder incorrect validation in add function Created: 19/Apr/16  Updated: 19/Apr/16

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

Type: Bug Priority: Minor
Reporter: Partim Assignee: Joe Di Pol
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The JsonObjectBuilder add method has a bug where if another name in the same scope is added it will overwrite that one with the new one without casting an exception or displaying any error of any kind. The problem is with no check before adding the value to the valueMap which makes it so that the old value overwrites the old one.

Relevant parts are in JsonObjectBuilderImpl method JsonObjectBuilder third line change from:
valueMap.put(name, new JsonStringImpl(value));
to:
if(valueMap.contains(name))

{ throw new SomeInvalidNameException("Two values cannot have the same name in the same scope"); }

valueMap.put(name, new JsonStringImpl(value));






[GLASSFISH-21536] NPE at "org.glassfish.api.jdbc.SQLTraceRecord.toString(SQLTraceRecord.java:231)" Created: 15/Apr/16  Updated: 15/Apr/16

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

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

Any



 Description   

The following code generates a NPE:
Class: SQLTraceRecord.java
Reason: The "param.toString()" is unsafe because it is quite normal that an SQL UPDATE provides a NULL param to force a NULL value in a given database table column.
As this is a trace the null should be simply printed as string "null".

@Override
public String toString() {
StringBuffer sb = new StringBuffer();
sb.append("ThreadID=" + getThreadID() + " | ");
sb.append("ThreadName=" + getThreadName() + " | ");
sb.append("TimeStamp=" + getTimeStamp() + " | ");
sb.append("ClassName=" + getClassName() + " | ");
sb.append("MethodName=" + getMethodName() + " | ");
if(params != null && params.length > 0) {
int index = 0;
for(Object param : params)

{ sb.append("arg[" + index++ + "]=" + param.toString() + " | "); // ERROR IS HERE }

}
//TODO add poolNames and other fields of this record.
return sb.toString();
}

This is the NPE trace:

Severe: java.lang.NullPointerException
at org.glassfish.api.jdbc.SQLTraceRecord.toString(SQLTraceRecord.java:231)
at com.sun.gjc.util.SQLTraceLogger.sqlTrace(SQLTraceLogger.java:69)
at com.sun.gjc.util.SQLTraceDelegator.sqlTrace(SQLTraceDelegator.java:94)
at com.sun.gjc.spi.JdbcObjectsFactory$1.invoke(JdbcObjectsFactory.java:142)
at com.sun.proxy.$Proxy244.prepareStatement(Unknown Source)






[GLASSFISH-21114] Failure to lookup EJB in ear/war Created: 01/Jul/14  Updated: 14/Apr/16

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 4.1_b05, 4.1_b06, 4.1_b07
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dbcjbn Assignee: Marek Potociar
Resolution: Unresolved Votes: 18
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0_1-review, fishcat

 Description   

I have an ear which includes an EJB and a jax-rs WAR module, both listed in the application.xml file of the EAR.

The war contains jax-rs Application and resource bean classes, and the resource class injects stateless bean from the EJB module using @EJB annotation.

When I access the REST resource after deploy GlassFish is unable to locate the jax-rs resource bean, which lives inside the WAR. It looks like GlassFish assumes it is to be found in the EJB module (see Stacktrace below).

I have a small example application exhibiting this problem, that I will gladly upload if possible.

The problem does not appear to be in GlassFish versions 4.0 up to and including 4.0.1 b04.

We have done testing on both Java 7 and 8.

[2014-07-01T12:06:22.179+0200] [glassfish 4.0] [WARNING] [] [org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider] [tid: _ThreadID=123 _ThreadName=http-listener-1(1)] [timeMillis: 1404209182179] [levelValue: 900] [[
An instance of EJB class, dk.dbc.gf.ejb.HelloWorldBean, could not be looked up using simple form name. Attempting to look up using the fully-qualified form name.
javax.naming.NamingException: Lookup failed for 'java:app/gf-4.0.1-fail-ejb-1.0-SNAPSHOT/HelloWorldBean' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}

[Root exception is javax.naming.NameNotFoundException: No object bound to name java:app/gf-4.0.1-fail-ejb-1.0-SNAPSHOT/HelloWorldBean]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider.lookupSimpleForm(EjbComponentProvider.java:378)
at org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider.lookup(EjbComponentProvider.java:360)
at org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider.access$000(EjbComponentProvider.java:100)
at org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider$EjbFactory.provide(EjbComponentProvider.java:123)
at org.jvnet.hk2.internal.FactoryCreator.create(FactoryCreator.java:96)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456)
at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2151)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:641)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:626)
at org.glassfish.jersey.internal.inject.Injections.getOrCreate(Injections.java:172)
at org.glassfish.jersey.server.model.MethodHandler$ClassBasedMethodHandler.getInstance(MethodHandler.java:185)
at org.glassfish.jersey.server.internal.routing.PushMethodHandlerRouter.apply(PushMethodHandlerRouter.java:74)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:112)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:115)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:115)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:115)
at org.glassfish.jersey.server.internal.routing.RoutingStage.apply(RoutingStage.java:94)
at org.glassfish.jersey.server.internal.routing.RoutingStage.apply(RoutingStage.java:63)
at org.glassfish.jersey.process.internal.Stages.process(Stages.java:197)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:261)
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:297)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:252)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1025)
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:372)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:382)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:345)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:220)
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.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.naming.NameNotFoundException: No object bound to name java:app/gf-4.0.1-fail-ejb-1.0-SNAPSHOT/HelloWorldBean
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:741)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:715)
at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:167)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:471)
... 64 more
]]



 Comments   
Comment by Joe Di Pol [ 01/Jul/14 ]

There have been some recent Jersey integrations. Assigning to Jakub for initial evaluation.

Comment by dbcjbn [ 04/Aug/14 ]

Would you happen to have an estimate on when this issue will be addressed, please?

Comment by dbcjbn [ 10/Sep/14 ]

This bug has also been observed on GlassFish v4.1

Comment by sgerr [ 16/Sep/14 ]

Bug is reproduced at Glassfish 4.1. It seems it is related to https://java.net/jira/browse/JERSEY-2122, but Jersey bug is at fixed state (fix version is 2.6), whereas Glassfish 4.1 is packaged with jersey of version 2.10.4-0. Unfortunately, this bug still appears. Is it scheduled for resolution?

Comment by giates2000 [ 21/Sep/14 ]

Due to this issue all my working jee7 rest web services are now stopped on glassfish v. 4.1, is there any workaround ?

Comment by gray [ 20/Oct/14 ]

I've found what is causing this bug and added comment to https://java.net/jira/browse/JERSEY-2122.

Comment by gray [ 21/Oct/14 ]

https://java.net/jira/browse/JERSEY-2690

Comment by MarvinEmilBrach [ 08/Mar/15 ]

posssible workaround: replace @Stateless with:
@javax.enterprise.context.RequestScoped
@javax.enterprise.context.ApplicationScoped
@javax.enterprise.context.ConversationScoped // NOT tested
@javax.enterprise.context.SessionScoped // NOT tested

perhaps related to https://java.net/jira/browse/GLASSFISH-21199

Comment by dobromyslov [ 15/Mar/15 ]

@RequestScoped breaks transactions in Jersey and it requires to mark methods as @Transactional.

Also Weld does not work well with @RequestScoped and raises an exception sometimes:
https://issues.jboss.org/browse/WELD-1774

Comment by dobromyslov [ 22/Mar/15 ]

java.lang.IllegalStateException: WELD-000335: Context is already active
Raises when I redeploy with JRebel.
It's been fixed in WELD 2.2.8.Final.

Comment by Sparksis [ 16/May/15 ]

I've submitted a pull request which fixes the issue in Jersey: https://github.com/jersey/jersey/pull/162

Unfortunately the the pull request is still pending.

Comment by nabizamani [ 14/Apr/16 ]

Is this here still an open issue? I'm just wondering because there is no reaction from Oracle!

Comment by Jakub Podlesak [ 14/Apr/16 ]

I am no longer on Jersey team. IIUC, this has already been fixed in Jersey (as per https://github.com/jersey/jersey/commit/8636f65b992322008bb987409af0dd97dec3b95f ). So this bug should get fixed in GlassFish once the corresponding Jersey version gets integrated.





[GLASSFISH-21357] Entity Tables are not created during deployment time Created: 10/May/15  Updated: 14/Apr/16

Status: Open
Project: glassfish
Component/s: configuration, deployment
Affects Version/s: 4.1
Fix Version/s: None

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

GlassFish Server Open Source Edition 4.1 (build 13) with latest JDK 8


Tags: create, deployment, entity, generate, jpa, persistence, table

 Description   

It seems that in Glassfish 4.1 DB tables for JPA entity classes are not generated during deployment time. Previously, when deploying the application with the correct persistence.xml file and with generation type "create" (in GF 4.1 this would be <property name="javax.persistence.schema-generation.database.action" value="create"/>) then the tables should be created at deployment time.

This does not happen anymore. It seems to be a change of behavior and has caused heavy backwards compatibility issues for us after migrating from GF 3.1.2.2 to GF 4.1. It seems that since Glassfish 4.1 you need to use your PU somewhere before the tables are created. In other words: tables are created only when they are needed the first time.

The following stack overflow articles discuss that topic as well:

http://stackoverflow.com/questions/25489359/entity-table-is-not-creating-using-jpa-2-1

https://stackoverflow.com/questions/25935866/how-to-use-jpa-with-java-ee-7-glassfish-4-1-and-maven-on-javadb/28841583#28841583



 Comments   
Comment by Lukas Jungmann [ 11/May/15 ]

if you're using eclipselink, then adding 'eclipselink.deploy-on-startup=true' to your persistence.xml should resolve the problem

Comment by nabizamani [ 07/Dec/15 ]

No progress after 6 months? This is a Java EE spec incompatibility or at least a change of the behavior from 3.1.2.2 to 4.1.x! How could the Java EE spec compliance tests pass??? I can see that this ticket is assigned to Masoud Kalali, but he has zero activity since May this year! So what is going on at Oracle?????

Comment by Masoud Kalali [ 07/Dec/15 ]

Considering that I am no longer active in GlassFish space I am assigning all the tickets to Chris Kasso in Java EE/ Application Servers team and he can reassign them as appropriate.

Comment by nabizamani [ 14/Apr/16 ]

Another 4 months have passed and no reaction. That means almost 1 year is over and there is no reaction!
No one at Oracle interested to work on this?





[GLASSFISH-21312] java.io.IOException: java.util.concurrent.TimeoutException comes up from time to time Created: 23/Feb/15  Updated: 14/Apr/16

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

Type: Bug Priority: Major
Reporter: nabizamani Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 14.04 LTS Server x64, java 1.8.0_31 + JCE Unlimited Strength, GlassFish Server Open Source Edition 4.1 (build 13)



 Description   

Fo a client I migrated from Glassfish 3.1.2.2 to the latest Glassfish 4.1 and now suddenly I can see java.util.concurrent.TimeoutException (see logs below). I can't tell where this comes from. I checked all the log files from GF 3.1.2.2 and there I can't find even a single entry...

[2015-02-23T11:06:43.377+0100] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=27 _ThreadName=http-listener-1(2)] [timeMillis: 1424686003377] [levelValue: 900] [[
StandardWrapperValve[default]: Servlet.service() for servlet default threw exception
java.io.IOException: java.util.concurrent.TimeoutException
at org.glassfish.grizzly.http.io.OutputBuffer.blockAfterWriteIfNeeded(OutputBuffer.java:973)
at org.glassfish.grizzly.http.io.OutputBuffer.write(OutputBuffer.java:686)
at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:355)
at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:342)
at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:161)
at org.apache.catalina.servlets.DefaultServlet.copy(DefaultServlet.java:2199)
at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:1085)
at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:568)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:96)
at org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:96)
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.util.concurrent.TimeoutException
at org.glassfish.grizzly.impl.SafeFutureImpl$Sync.innerGet(SafeFutureImpl.java:357)
at org.glassfish.grizzly.impl.SafeFutureImpl.get(SafeFutureImpl.java:264)
at org.glassfish.grizzly.http.io.OutputBuffer.blockAfterWriteIfNeeded(OutputBuffer.java:962)
... 42 more
]]



 Comments   
Comment by oleksiys [ 23/Feb/15 ]

This Exception appears when the server can't write the data to a client. Most probably client or network can't keep up with the server's pace.
You're right, in 3.1.2 we throw different Exception, but logic is the same.

Do you see a particular problem related to this Exception?

Comment by nabizamani [ 23/Feb/15 ]

As of now I don't see any real problem other than annoying amount of logs.
I have also some other new log entries which we never had in Glassfish 3.1.2.2:

  • java.lang.IllegalStateException: getOutputStream() has already been called for this response
  • java.lang.IllegalStateException: Unknown JCDI-enabled managed bean org.apache.struts2.views.jsp.TextTag@ee5597c of class class org.apache.struts2.views.jsp.TextTag

I believe that latter one occurs during restart oder the server or when underlying, maybe deploying.
I will monitor this the next days and let you know about my findings.

Comment by oleksiys [ 23/Feb/15 ]

Well, I think we can reduce the logging level for this exception.
Regarding:

java.lang.IllegalStateException: getOutputStream() has already been called for this response

looks like you call response.getWriter() after response.getOutputStream() was called, you can't combine byte- and character-based writes, that's why you see the exception.

Comment by nabizamani [ 23/Feb/15 ]

Yes, I figured that. However, we did not change anything in the jsp that seems to produce this exception. Like I said, I will monitor and analyze things and post my findings here...

Comment by nabizamani [ 24/Feb/15 ]

I think I got some fIndings:

I get somehow java.io.IOException: java.util.concurrent.TimeoutException
I cannot really reproduce it, it just happens from time to time...
Because of the exception my error page defined in web.xml gets called:

web.xml (just the relevant part):

<!-- catch all errors -->
<error-page>
    <location>/WEB-INF/jsp/error/error.jsp</location>
</error-page>

/WEB-INF/jsp/error/error.jsp :

<%@page isErrorPage="true" session="false"
%><%@ page import="org.apache.log4j.Logger"
%><%@ page trimDirectiveWhitespaces="true" 
%><%
response.setStatus(response.getStatus());   //or some other code
%><html>
    <head>
        <title>Error <%= response.getStatus() %></title>
    </head>
    <body>
        <h2 style="color:red;">Error <%= response.getStatus() %></h2>
    </body>
</html>
<%
Logger log = Logger.getLogger("error");
String uri = (String) request.getAttribute("javax.servlet.error.request_uri");
String info = "(ip='"+request.getRemoteAddr()+"' x-forwarded-for='"+request.getHeader("x-forwarded-for")+"')";
String qs = request.getQueryString();
if (qs != null)
    log.error("HTTP Status "+response.getStatus() +" for request '"+uri+"?"+qs+"' "+info);
else
    log.error("HTTP Status "+response.getStatus() +" for request '"+uri+"' "+info);
%>

So the error.jsp is called, and right after that I get this error in the log file:
java.lang.IllegalStateException: getOutputStream() has already been called for this response

I guess that is because Glassfish has either already sent "some" response or because the connection is closed (i.e. by peer?). What does timeout exactly mean? What kind of timeout are we talking about?

However, I still get the log entries I have in the error.jsp. This is an example log entry:
2015-02-24 17:27:44,985 ERROR error._jspService:76 - HTTP Status 200 for request '/assets/plugins/bootstrap/css/bootstrap.css' (ip='41.216.47.46' x-forwarded-for='null')]]

As you can see the HTTP Status code is 200 (and that is correct, because the file is on the server). Although an error was thrown by the runtime, I guess because the connection was closed or something... I believe that throwing TimeoutException because maybe a connection has closed for some reason and passing it all the way up is the issue here. Do you know if there is some change in the code somewhere here between 3.1.2.2 and 4.1? I can also see some "java.io.IOException: Broken pipe" exceptions in the logs (I believe this is related somehow).

A log file with some relevant parts is attached.

Comment by nabizamani [ 24/Feb/15 ]

Sorry, I can't attach files... So here some logs:

[2015-02-24T17:27:44.984+0100] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=36 _ThreadName=http-listener-2(2)] [timeMillis: 1424795264984] [levelValue: 900] [[
StandardWrapperValve[default]: Servlet.service() for servlet default threw exception
java.io.IOException: java.util.concurrent.TimeoutException
at org.glassfish.grizzly.http.io.OutputBuffer.blockAfterWriteIfNeeded(OutputBuffer.java:973)
at org.glassfish.grizzly.http.io.OutputBuffer.write(OutputBuffer.java:686)
at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:355)
at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:342)
at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:161)
at org.apache.catalina.servlets.DefaultServlet.copy(DefaultServlet.java:2199)
at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:1085)
at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:568)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.web.filter.ForceHttpsFilter.doFilter(ForceHttpsFilter.java:51)
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.util.concurrent.TimeoutException
at org.glassfish.grizzly.impl.SafeFutureImpl$Sync.innerGet(SafeFutureImpl.java:357)
at org.glassfish.grizzly.impl.SafeFutureImpl.get(SafeFutureImpl.java:264)
at org.glassfish.grizzly.http.io.OutputBuffer.blockAfterWriteIfNeeded(OutputBuffer.java:962)
... 45 more
]]

[2015-02-24T17:27:44.986+0100] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=36 _ThreadName=Thread-8] [timeMillis: 1424795264986] [levelValue: 800] [[
2015-02-24 17:27:44,985 ERROR error._jspService:76 - HTTP Status 200 for request '/assets/plugins/bootstrap/css/bootstrap.css' (ip='41.216.47.46' x-forwarded-for='null')]]

[2015-02-24T17:27:44.986+0100] [glassfish 4.1] [WARNING] [] [javax.enterprise.web.core] [tid: _ThreadID=36 _ThreadName=http-listener-2(2)] [timeMillis: 1424795264986] [levelValue: 900] [[
Servlet.service() for servlet jsp threw exception
java.lang.IllegalStateException: getOutputStream() has already been called for this response
at org.apache.catalina.connector.Response.getWriter(Response.java:777)
at org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:224)
at javax.servlet.ServletResponseWrapper.getWriter(ServletResponseWrapper.java:152)
at org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:195)
at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:188)
at org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:240)
at org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:185)
at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:137)
at org.apache.jsp.WEB_002dINF.jsp.error.error_jsp._jspService(error_jsp.java:88)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:411)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:875)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:739)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:695)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:626)
at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:500)
at org.apache.catalina.core.StandardHostValve.dispatchToErrorPage(StandardHostValve.java:699)
at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:309)
at org.apache.catalina.core.StandardHostValve.postInvoke(StandardHostValve.java:232)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:417)
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)
]]

[2015-02-24T17:27:44.987+0100] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=36 _ThreadName=http-listener-2(2)] [timeMillis: 1424795264987] [levelValue: 900] [[
org.apache.catalina.core.StandardHostValve@6d45b284: Exception Processing ErrorPage[errorCode=0, location=/WEB-INF/jsp/error/error.jsp]
java.lang.IllegalStateException: getOutputStream() has already been called for this response
at org.apache.catalina.connector.Response.getWriter(Response.java:777)
at org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:224)
at javax.servlet.ServletResponseWrapper.getWriter(ServletResponseWrapper.java:152)
at org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:195)
at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:188)
at org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:240)
at org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:185)
at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:137)
at org.apache.jsp.WEB_002dINF.jsp.error.error_jsp._jspService(error_jsp.java:88)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:411)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:875)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:739)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:695)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:626)
at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:500)
at org.apache.catalina.core.StandardHostValve.dispatchToErrorPage(StandardHostValve.java:699)
at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:309)
at org.apache.catalina.core.StandardHostValve.postInvoke(StandardHostValve.java:232)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:417)
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)
]]

[2015-02-24T18:03:01.398+0100] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=38 _ThreadName=Thread-8] [timeMillis: 1424797381398] [levelValue: 800] [[
2015-02-24 18:03:01,397 ERROR error._jspService:76 - HTTP Status 404 for request '/robots.txt' (ip='77.66.121.243' x-forwarded-for='null')]]

[2015-02-24T18:12:38.665+0100] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=39 _ThreadName=http-listener-2(5)] [timeMillis: 1424797958665] [levelValue: 900] [[
StandardWrapperValve[default]: Servlet.service() for servlet default threw exception
java.io.IOException: Broken pipe
at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
at sun.nio.ch.IOUtil.write(IOUtil.java:51)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:470)
at org.glassfish.grizzly.nio.transport.TCPNIOUtils.flushByteBuffer(TCPNIOUtils.java:149)
at org.glassfish.grizzly.nio.transport.TCPNIOUtils.writeSimpleBuffer(TCPNIOUtils.java:133)
at org.glassfish.grizzly.nio.transport.TCPNIOAsyncQueueWriter.write0(TCPNIOAsyncQueueWriter.java:109)
at org.glassfish.grizzly.nio.transport.TCPNIOAsyncQueueWriter.write0(TCPNIOAsyncQueueWriter.java:91)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.write(AbstractNIOAsyncQueueWriter.java:261)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.write(AbstractNIOAsyncQueueWriter.java:170)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.write(AbstractNIOAsyncQueueWriter.java:70)
at org.glassfish.grizzly.nio.transport.TCPNIOTransportFilter.handleWrite(TCPNIOTransportFilter.java:126)
at org.glassfish.grizzly.filterchain.TransportFilter.handleWrite(TransportFilter.java:191)
at org.glassfish.grizzly.ssl.SSLBaseFilter$SSLTransportFilterWrapper.handleWrite(SSLBaseFilter.java:1004)
at org.glassfish.grizzly.filterchain.ExecutorResolver$8.execute(ExecutorResolver.java:111)
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.filterchain.FilterChainContext.write(FilterChainContext.java:848)
at org.glassfish.grizzly.ssl.SSLBaseFilter.handleWrite(SSLBaseFilter.java:332)
at org.glassfish.grizzly.filterchain.ExecutorResolver$8.execute(ExecutorResolver.java:111)
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.filterchain.FilterChainContext.write(FilterChainContext.java:848)
at org.glassfish.grizzly.filterchain.FilterChainContext.write(FilterChainContext.java:817)
at org.glassfish.grizzly.http.io.OutputBuffer.flushBuffer(OutputBuffer.java:1024)
at org.glassfish.grizzly.http.io.OutputBuffer.write(OutputBuffer.java:680)
at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:355)
at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:342)
at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:161)
at org.apache.catalina.servlets.DefaultServlet.copyRange(DefaultServlet.java:2477)
at org.apache.catalina.servlets.DefaultServlet.copy(DefaultServlet.java:2212)
at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:1085)
at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:568)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.web.filter.ForceHttpsFilter.doFilter(ForceHttpsFilter.java:51)
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)
]]

[2015-02-24T18:12:38.666+0100] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=39 _ThreadName=Thread-8] [timeMillis: 1424797958666] [levelValue: 800] [[
2015-02-24 18:12:38,666 ERROR error._jspService:76 - HTTP Status 200 for request '/download/img/prifile.jpg‚ (ip='23.229.97.36' x-forwarded-for='null')]]

[2015-02-24T18:12:38.666+0100] [glassfish 4.1] [WARNING] [] [javax.enterprise.web.core] [tid: _ThreadID=39 _ThreadName=http-listener-2(5)] [timeMillis: 1424797958666] [levelValue: 900] [[
Servlet.service() for servlet jsp threw exception
java.lang.IllegalStateException: getOutputStream() has already been called for this response
at org.apache.catalina.connector.Response.getWriter(Response.java:777)
at org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:224)
at javax.servlet.ServletResponseWrapper.getWriter(ServletResponseWrapper.java:152)
at org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:195)
at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:188)
at org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:240)
at org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:185)
at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:137)
at org.apache.jsp.WEB_002dINF.jsp.error.error_jsp._jspService(error_jsp.java:88)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:411)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:875)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:739)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:695)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:626)
at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:500)
at org.apache.catalina.core.StandardHostValve.dispatchToErrorPage(StandardHostValve.java:699)
at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:309)
at org.apache.catalina.core.StandardHostValve.postInvoke(StandardHostValve.java:232)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:417)
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)
]]

[2015-02-24T18:12:38.667+0100] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=39 _ThreadName=http-listener-2(5)] [timeMillis: 1424797958667] [levelValue: 900] [[
org.apache.catalina.core.StandardHostValve@6d45b284: Exception Processing ErrorPage[errorCode=0, location=/WEB-INF/jsp/error/error.jsp]
java.lang.IllegalStateException: getOutputStream() has already been called for this response
at org.apache.catalina.connector.Response.getWriter(Response.java:777)
at org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:224)
at javax.servlet.ServletResponseWrapper.getWriter(ServletResponseWrapper.java:152)
at org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:195)
at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:188)
at org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:240)
at org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:185)
at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:137)
at org.apache.jsp.WEB_002dINF.jsp.error.error_jsp._jspService(error_jsp.java:88)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:411)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:875)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:739)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:695)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:626)
at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:500)
at org.apache.catalina.core.StandardHostValve.dispatchToErrorPage(StandardHostValve.java:699)
at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:309)
at org.apache.catalina.core.StandardHostValve.postInvoke(StandardHostValve.java:232)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:417)
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)
]]

[2015-02-24T18:49:08.494+0100] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=30 _ThreadName=Thread-8] [timeMillis: 1424800148494] [levelValue: 800] [[
2015-02-24 18:49:08,493 ERROR error._jspService:76 - HTTP Status 404 for request '/WEB-INF/tiles.xml' (ip='202.46.62.153' x-forwarded-for='null')]]

Comment by nabizamani [ 24/Feb/15 ]

I can confirm the assumptions I made above and I can reproduce it now:

1. I assume you have access to a remote glassfish server - NOT ON YOUR OWN MACHINE!
2. Deploy some large file onto that server which you download via browser in the next step - large enough so that you have enough time to disable the network connection (i.e. wifi) on you local machine abruptly
3. Use your browser to download that large file after you have deployed it
4. Once the download has started make sure to a abruptly disable your network connection (on your local machine) before the download finishes - that will simulate a lost network connection...
5. Now check the log files, they will be pretty close to what you can see in my logs

That means:
1. It seems from time to time people accessing our machine simply loose their connection while requesting/downloading some content (that ist not unusual)
2. In GF 4.1 these events are raised/logged as exceptions, it was not like this in GF 3.1.2.2
3. This can cause unwanted behavior, see my explanations in the previous comments. Was there some related change in the Java EE 7 specs???

I don't think that calling the error-page defined in the web.xml is a good decision in case some client has lost network connectivity (caused because the exception is thrown). I am not even sure if it's worth logging it, is it? Others might have different opinions...

Can you reproduce the issue? What do you think?
I think the caller of the Grizzly API should swallow the exceptions, unless there was a change in the Java EE specs...

Comment by oleksiys [ 25/Feb/15 ]

I changed the error message in Grizzly to be more understandable, TimeoutException will be hidden and user will see IOException only with better description.
Otherwise I'll redirect this issue to webcontainer, since it's webcontainer logging the exception and tries to serve the error page.

Comment by nabizamani [ 07/Dec/15 ]

Is this here still considered by anyone at oracle? Almost 10 months and no reaction? Is Oracle interested in Glassfish at all????????

Comment by nabizamani [ 14/Apr/16 ]

Well, again... is there anyone working on this here??????





[GLASSFISH-21535] The result of EntityManager.find() is not managed Created: 14/Apr/16  Updated: 14/Apr/16

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.1, 4.1.1
Fix Version/s: None

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


 Description   
@Path("/employees")
@Produces({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
//@Stateless    //we can't use this because of bug in Glassfish 4.1, see http://stackoverflow.com/questions/25879898/glassfish-4-1-cant-run-restful-service-when-using-ear-ejb-web-module
@RequestScoped  //this is a workaround that works for us
public class Employees {
    
	@PersistenceContext(unitName = "myPU")
    private EntityManager em;
    
    @PUT
    @Produces({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
    @Path("/{empId}")
    public Response updateEmployeeFirstName(@NotNull @PathParam("empId") Long empId, @PathParam("firstName") String firstName) throws ParseException, JOSEException {
        Employee emp = em.find(Employee.class, empId);
    	if(emp != null){
    		System.out.println("em.contains(emp) ==> " + em.contains(emp)); //always false
    		emp.setFirstName(firstName);
    		//em.merge(emp);	//because emp is not managed this would be a workaround

    		//...
    	}else{
    		return Response.status(Status.NOT_FOUND).build();
    	}
    }
   
}

This issue is somehow related to https://java.net/jira/browse/GLASSFISH-20968, which is flagged as resolved - but that's false!

Dear Oracle team,
There are many GF issues open and many of the have a very high priority - these issues make GF even incompatible to the Java EE 7 spec!! Any other Java EE 7 server would have never been "certified" with all theses issues, especially because these issues break the Java EE 7 spec! Like another person mentioned in the other ticket "I still wonder if the TCK is so weak with regard to extended persistence context, or glassfish 4 was only declared passing it." How can this happen?

This issue is a blocker as it is breaking Java EE compliance! Furthermore, people who want to learn JPA, Java EE etc. will be confused a lot and might get a wrong impression of Java EE!



 Comments   
Comment by nabizamani [ 14/Apr/16 ]

Also see http://stackoverflow.com/questions/21356448/jpa-entity-found-by-find-in-a-stateful-ejb-extended-is-not-managed

Comment by nabizamani [ 14/Apr/16 ]

Little mistake: the parameter firstName does not come from @PathParam("firstName"). Instead it comes from a FormParam...





[GLASSFISH-20968] find() method with EXTENDED Persistence Context and TX_TYPE: NOT_SUPPORTED Created: 02/Feb/14  Updated: 14/Apr/16  Resolved: 27/Jun/14

Status: Resolved
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.0
Fix Version/s: 4.1

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

Ubuntu 64bits, OpenJDK 7, JavaDB


Tags: 4_0_1-evangelists, 4_0_1-mustfix

 Description   

According to spec:

"The find method (provided it is invoked without a lock or invoked with LockModeType.NONE)
and the getReference method are not required to be invoked within a transaction. If an entity man-
ager with transaction-scoped persistence context is in use, the resulting entities will be detached; if an
entity manager with an extended persistence context is used, they will be managed. See section 3.3 for
entity manager use outside a transaction."

That's is not properly working for GF4 (I have tested that with GF3 and works as expected):

If I have a Gateway like this:

@Stateful
@TransactionAttribute(NOT_SUPPORTED)
public class CustomerGateway {

@PersistenceContext(unitName = "customersPU", type = EXTENDED)
private EntityManager em;
private Customer customer;

public Customer find(Long id)

{ // customer is not managed! this.customer = em.find(Customer.class, id); // Prints false! System.out.println("Method find: " + em.contains(customer)); // Prints false too (2 is the id of an entity)! System.out.println("Method find: " + em.contains(em.find(Customer.class, 2L)); // A workaround customer = em.merge(customer); // Print true. System.out.println("Method find after merge: " + em.contains(customer)); return this.customer; }

Is not working according to spec.

I have create a GitHub project, maybe is useful for you:
https://github.com/sdmoralesma/SO-21356448



 Comments   
Comment by jclingan [ 01/May/14 ]

If evaluation of this issue shows spec compliance issues, then this bug should be fixed.

Comment by Ed Bratt [ 20/May/14 ]

This is marked Must Fix for 4.0.1. Please evaluate. Thank you.

Comment by ethan.wang [ 27/Jun/14 ]

Fixed by change 63399

Comment by pdudits [ 22/Jan/16 ]

It looks that this is not entirely fixed. Making any query in extended persistence context will detach all entities. I'll file a new issue for that.

Comment by nabizamani [ 10/Apr/16 ]

@pdudits you are absolutely right! This issue is still not fixed! When calling em.find(...) the result is not managed. At least in Glassfish 4.1.1 and I'm not very happy about this! Did you already open another issue for this? If not I will open one and mention it here.

Comment by pdudits [ 10/Apr/16 ]

My pull request will fix that in next Payara release. I still wonder if the TCK is so weak with regard to extended persistence context, or glassfish 4 was only declared passing it.

Comment by nabizamani [ 14/Apr/16 ]

@pdudits Thanks for that! I totally agree with what you say, also because this is not the first issue of that kind (and the other are still open)! I have just opened another ticket here: https://java.net/jira/browse/GLASSFISH-21535

To everyone: please not for the other ticket! I can't even believe that this issue is naked as "fixed" - this is wrong!





[GLASSFISH-21534] Jersey Client POSTs between GF apps (microservice) timeout Created: 13/Apr/16  Updated: 13/Apr/16

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

Type: Bug Priority: Major
Reporter: jmanko Assignee: Joe Di Pol
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish Server Open Source Edition 4.1.1 (build 1)
Windows Server 2008R2


Tags: Jersey

 Description   

I'm attempting a REST request from one GF deployed app to another (on same server), but the request is times out. I've tried to increased the timeout value, but that doesn't work.

Here is some sample code:

ClientConfig clientConfig = null;
Client client = null;
WebTarget webTarget = null;
FormDataMultiPart formDataMultiPart = null;
Invocation.Builder invocationBuilder = null;
Response response = null;

clientConfig = new ClientConfig();
clientConfig.register(MultiPartFeature.class);
clientConfig.register(ListReader.class);

String url = "http://localhost:8080/someapp"
String urlPath = "/rest/path";

Map<String, String> params = new HashMap<>();
params.put("option", "value");

Map<String, String> formFields = new HashMap<>();
formFields.put("field1", "value");

List<BodyPart> fileParts = null;

// See http://www.adam-bien.com/roller/abien/entry/setting_timeout_for_the_jax
clientConfig.property("jersey.config.client.connectTimeout", 7000);
clientConfig.property("jersey.config.client.readTimeout", 7000);
client = ClientBuilder.newClient(clientConfig);
webTarget = client.target(url).path(urlPath);

if (params != null && !params.isEmpty()) {
for (String key : params.keySet())

{ webTarget = webTarget.queryParam(key, params.get(key)); }

}

formDataMultiPart = new FormDataMultiPart();
formDataMultiPart.setMediaType(MediaType.MULTIPART_FORM_DATA_TYPE);
if (fileParts != null && !fileParts.isEmpty()) {
for (BodyPart bodyPart : fileParts)

{ formDataMultiPart.bodyPart(bodyPart); }

}

if (formFields != null && !formFields.isEmpty()) {
for (Map.Entry<String, String> formField : formFields.entrySet())

{ formDataMultiPart.field(formField.getKey(), formField.getValue()); }

}

invocationBuilder = webTarget.request(MediaType.APPLICATION_JSON);
response = invocationBuilder.post(Entity.entity(formDataMultiPart, formDataMultiPart.getMediaType()));






[GLASSFISH-19104] NullPointerException was thrown out when delete a nonexistent lifecycle module Created: 25/Sep/12  Updated: 12/Apr/16  Resolved: 25/Sep/12

Status: Resolved
Project: glassfish
Component/s: lifecycle_modules
Affects Version/s: 4.0_b54
Fix Version/s: 4.0_b56_ms5

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

Windows XP, Windows 7


Attachments: Text File GLASSFISH-19104.patch    
Tags: admin

 Description   

[Bug Description]
When executed "delete-lifecycle-module" command by specifing a name that does not exist, it will be failed and the NullPointerException was thrown out.

[Operations]
STEP1 Start the domain

asadmin> start-domain
Waiting for domain1 to start ..............................
Successfully started the domain : domain1
domain Location: D:\glassfish3\glassfish\domains\domain1
Log File: D:\glassfish3\glassfish\domains\domain1\logs\server.log
Admin Port: 4848
Command start-domain executed successfully.

STEP2. Execute the delete-lifecycle-module to delete a lifecycle-module that does not exist.

asadmin> delete-lifecycle-module not_exist
remote failure: User is not authorized for this command
java.lang.NullPointerException
Command delete-lifecycle-module failed.

[affected versions]
1 4.0_b54
2 Glassfish's trunk until 2012/09/25



 Comments   
Comment by zhouronghui [ 25/Sep/12 ]

The patch of GLASSFISH-19104

Comment by zhouronghui [ 25/Sep/12 ]

Dear Tom

I think it's caused by the NULL check was omitted
in DeleteLifecycleModuleCommand#getAccessChecks,
and I made a patch for this issue and attached to
the ISSUE. Would you please check it?

PS:
The NullPointerException was thrown out and
the stack trace in server.log was as follows:

 
[#|2012-09-25T15:46:58.318+0900|SEVERE|44.0|javax.enterprise.system.tools.admin.security.authorization|_ThreadID=12;_ThreadName=admin-listener(1);|org.glassfish.deployment.admin.DeleteLifecycleModuleCommand
java.lang.NullPointerException
	at java.net.URI$Parser.parse(URI.java:3004)
	at java.net.URI.<init>(URI.java:577)
	at java.net.URI.create(URI.java:839)
	at com.sun.enterprise.admin.util.CommandSecurityChecker.resourceURIFromAccessCheck(CommandSecurityChecker.java:244)
	at com.sun.enterprise.admin.util.CommandSecurityChecker.checkAccessRequired(CommandSecurityChecker.java:189)
	at com.sun.enterprise.admin.util.CommandSecurityChecker.authorize(CommandSecurityChecker.java:139)
~omitted~
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:558)
	at java.lang.Thread.run(Thread.java:662)
|#]
Comment by Hong Zhang [ 25/Sep/12 ]

As Tim helped make this part of the security changes, I will let Tim take a look to see if the attached patch is the best place to fix (or should the NPE check made in CommandSecurityChecker.resourceURIFromAccessCheck so other similar code paths are covered as well).

Comment by Tim Quinn [ 25/Sep/12 ]

Fix checked in.

Project: glassfish
Repository: svn
Revision: 56123
Author: tjquinn
Date: 2012-09-25 15:54:10 UTC
Link:

Log Message:
------------
Fix for 19104.

The code which prepares the access check did not adequately protect against a null resource name being used (which happens if the specified life cycle module does not exist).

Revisions:
----------
56123

Modified Paths:
---------------
trunk/main/nucleus/deployment/admin/src/main/java/org/glassfish/deployment/admin/DeleteLifecycleModuleCommand.java

Comment by Hari92 [ 12/Apr/16 ]

I'm getting the below error while deploying a war which is worked earlier in Tomcat but not working in Glassfish 4.0
[2016-04-13T00:02:23.156+0530] [glassfish 4.0] [SEVERE] [NCLS-ADMIN-00011] [javax.enterprise.system.tools.admin.security.authorization] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1460485943156] [levelValue: 1000] [[
An unexpected exception occurred.
java.lang.RuntimeException: java.lang.NullPointerException
at org.glassfish.deployment.admin.DeployCommand.preAuthorization(DeployCommand.java:314)
at com.sun.enterprise.admin.util.CommandSecurityChecker$1.run(CommandSecurityChecker.java:187)
at com.sun.enterprise.admin.util.CommandSecurityChecker$1.run(CommandSecurityChecker.java:183)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.admin.util.CommandSecurityChecker.authorize(CommandSecurityChecker.java:183)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1203)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
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.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:331)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:165)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$ArchiveJarEntrySource.<init>(InputJarArchive.java:581)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$ArchiveJarEntrySource.<init>(InputJarArchive.java:573)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.createEntryEnumeration(InputJarArchive.java:451)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.entries(InputJarArchive.java:203)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.access$100(InputJarArchive.java:74)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$1.enumeration(InputJarArchive.java:166)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$CollectionWrappedEnumeration.<init>(InputJarArchive.java:724)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.getDirectories(InputJarArchive.java:161)
at org.glassfish.javaee.full.deployment.EarDetector.isEARFromIntrospecting(EarDetector.java:142)
at org.glassfish.javaee.full.deployment.EarDetector.handles(EarDetector.java:110)
at com.sun.enterprise.v3.server.ApplicationLifecycle.getArchiveHandler(ApplicationLifecycle.java:211)
at org.glassfish.deployment.admin.DeployCommand.preAuthorization(DeployCommand.java:246)
... 52 more
]]

Comment by Hari92 [ 12/Apr/16 ]

C:\Soft64\glassfish-4.0\glassfish4\glassfish\bin>asadmin deploy --force=true C:\Users\HA288049\Desktop\recoengine\recoengine.war
remote failure: Error during authorization
java.lang.RuntimeException: java.lang.NullPointerException
Command deploy failed.





[GLASSFISH-21533] The WAR file working in Tomcat server is not working in Glassfish 4.0 Created: 12/Apr/16  Updated: 12/Apr/16

Status: Open
Project: glassfish
Component/s: admin, deployment
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Hari92 Assignee: Chris Kasso
Resolution: Unresolved Votes: 0
Labels: maven
Remaining Estimate: 1 week
Time Spent: Not Specified
Original Estimate: 1 week
Environment:

java 1.8



 Description   

[2016-04-13T00:02:23.156+0530] [glassfish 4.0] [SEVERE] [NCLS-ADMIN-00011] [javax.enterprise.system.tools.admin.security.authorization] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1460485943156] [levelValue: 1000] [[
An unexpected exception occurred.
java.lang.RuntimeException: java.lang.NullPointerException
at org.glassfish.deployment.admin.DeployCommand.preAuthorization(DeployCommand.java:314)
at com.sun.enterprise.admin.util.CommandSecurityChecker$1.run(CommandSecurityChecker.java:187)
at com.sun.enterprise.admin.util.CommandSecurityChecker$1.run(CommandSecurityChecker.java:183)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.admin.util.CommandSecurityChecker.authorize(CommandSecurityChecker.java:183)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1203)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
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.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:331)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:165)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$ArchiveJarEntrySource.<init>(InputJarArchive.java:581)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$ArchiveJarEntrySource.<init>(InputJarArchive.java:573)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.createEntryEnumeration(InputJarArchive.java:451)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.entries(InputJarArchive.java:203)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.access$100(InputJarArchive.java:74)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$1.enumeration(InputJarArchive.java:166)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$CollectionWrappedEnumeration.<init>(InputJarArchive.java:724)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.getDirectories(InputJarArchive.java:161)
at org.glassfish.javaee.full.deployment.EarDetector.isEARFromIntrospecting(EarDetector.java:142)
at org.glassfish.javaee.full.deployment.EarDetector.handles(EarDetector.java:110)
at com.sun.enterprise.v3.server.ApplicationLifecycle.getArchiveHandler(ApplicationLifecycle.java:211)
at org.glassfish.deployment.admin.DeployCommand.preAuthorization(DeployCommand.java:246)
... 52 more
]]






[GLASSFISH-21510] class including invokedynamic is breaking deployment - BufferUnderflowException Created: 04/Feb/16  Updated: 08/Apr/16

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

Type: Bug Priority: Major
Reporter: floR Assignee: Hong Zhang
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java 1.8.0_72
glassfish 4.1.1
ubuntu 14.4



 Description   

When trying to deploy an enterprise application including classes with bytecode containing invokedynamic, the deployment randomly stops with throwing a BufferUnderflowException:

java.nio.BufferUnderflowException
at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:151)
at com.sun.enterprise.deployment.annotation.introspection.ConstantPoolInfo.containsAnnotation(ConstantPoolInfo.java:86)
...

This is always preceeded by severe warnings like

Severe: Unknow type constant pool 18 at position5
Severe: Unknow type constant pool 0 at position6
Severe: Unknow type constant pool 0 at position7

This is a problem especially when using Java 8's method reference operator/lamdas.



 Comments   
Comment by floR [ 04/Feb/16 ]

The problem seems to be the missing support of Java 7's contstant pool types Method handle, Method type and InvokeDynamic (ids 15, 16 and 18) in the class
com.sun.enterprise.deployment.annotation.introspection.ConstantPoolInfo of modules/dol.jar.

This class is used for checking the existence of annotations. For that reason, it inspects the constant pool part of the .class files byte by byte.
When trying to process any of the unsupported types, it simply logs the warning "Unknow [sic] type constant pool x at position i" and proceeds processing with the next byte, missing to skip bytes blonging to the types data structure.

This can result in trying to read bytes belonging to an irregular inferred constant pool entry of type string with an illegal length (inferred from the constant pool entry) => BufferUnderflowException.

Comment by koen.serneels [ 08/Apr/16 ]

Hi. We are experiencing the exact same problem. Is there any news on this issue?

Btw; it is very surprising to me that no one reported this issue before. I mean, it cannot be that no one experienced this issue since Java8 and GF4?
Moreover, we are experiencing this in an older version of GF. So this gives a pretty good indication that this is not something that has been introduced recently.

Comment by payara_steve [ 08/Apr/16 ]

This may be due to an old asm jar packaged with GlassFish. We have had something which sounds the same in Payara see https://github.com/payara/Payara/issues/689 . If you can deploy to a prerelease buid of Payara this would indicate the problem is in the asm library version and needs some refactoring to fix.

Comment by koen.serneels [ 08/Apr/16 ]

@payara_steve : I don't directly see how this would be ASM related. As pointed out by floR, the problem resides in ConstantPoolInfo which is called at deployment time.
This class has no dependency on ASM and performs some bytecode interpretation by itself. However, as (also pointed out by floR in his excellent post http://stackoverflow.com/questions/28301584/javaee-glassfish-bufferunderflowexception) this code tries to ignore unknown types (new types introduced with Java8 in the meantime) by skipping the current byte and continuing at the next byte. However, the next byte is in this case still part of the data structure of the unknown type. It should have skipped the amount of bytes the type data structure is composed of instead, before assuming the next type. This leads to misinterpretation and (depending on the case) exceptions as these bytes have different meaning than what is expected. But for what it's worth, I tried upgrading the GF ASM in our GF version to the latest one, but no difference as expected.

Now, the ConstantPoolInfo is apparently no longer used when deploying WARs on GF4 (as also pointed out by floR). Based on the things I'm seeing here I can confirm this as none of my breakpoints are triggered when deploying WARs on GF4, while they are on the (older) version we are using. On GF4 it seems that this code is indeed only executed for EAR and EJB modules while it is also executed on WARs on older GF versions. Upgrading to GF4 might solve our problem as we currently only have WARs. But it is clear that this problem needs attention. This code is still in the codebase and still causing trouble depending on conditions. Moreover, there is some randomness involved as we have several classes with lambda's but only one is currently posing a problem. It will probably depend on some factors and value of the misinterpreted bytes if the BufferUnderflowException is triggered or not





[GLASSFISH-4634] Don't EXPUNGE failed periodic timers unconditionally Created: 06/Apr/08  Updated: 08/Apr/16  Resolved: 07/Oct/10

Status: Resolved
Project: glassfish
Component/s: ejb_container
Affects Version/s: 9.1peur1
Fix Version/s: 3.1_ms06

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

Operating System: Windows XP
Platform: PC


Issuezilla Id: 4,634

 Description   

I set up a periodic timer and then caused it to throw an exception. After number
of retries was done and failed the timer was expunged/destroyed.

==

For example,

[#|2008-03-03T12:47:47.859+1100|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=31;_ThreadName=p:
thread-pool-1; w: 30;'5@@1204499852281@@server@@domain1' 'TimedObject =
TimerServiceSessionBean' 'Application = testtimerservice_server'
'BEING_DELIVERED' 'PERIODIC' 'Container ID = 78938621512646656' 'Mon Mar 03
12:47:42 EST 2008' '30000' ;2;|EJB5119:Expunging timer
['5@@1204499852281@@server@@domain1' 'TimedObject = TimerServiceSessionBean'
'Application = testtimerservice_server' 'BEING_DELIVERED' 'PERIODIC' 'Container
ID = 78938621512646656' 'Mon Mar 03 12:47:42 EST 2008' '30000' ] after [2]
failed deliveries|#]

==

But I had expected that after the timer period had elapsed it might try again.

Perhaps there can be a check-box in the Admin GUI to allow the user to decide if
period timers should be EXPUNGED on failure, or whether they should fire again
next time the timer period elapses.



 Comments   
Comment by rsoika [ 25/Jun/09 ]

I have the same problem running a timer service on "Sun Java System Application
Server 9.1_02 (build b04-fcs)"
The timer service runs more than 10 hours without a problem.
Than I got a EJB exception and the timer is canceled.
See server.log snipped below:

[ScheduledWorkflowService] 0 workitems processed|#]
[#|2009-06-25T05:05:09.534+0100|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=16;_ThreadName=p:
thread-pool-1; w: 4;ScheduledWorkflowServiceImplementation;|EJB5018: An
exception was thrown during an ejb invocation on
[ScheduledWorkflowServiceImplementation]|#]

[#|2009-06-25T05:05:09.535+0100|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=16;_ThreadName=p:
thread-pool-1; w: 4;|
javax.ejb.EJBException
at
com.sun.ejb.containers.BaseContainer.processSystemException(BaseContainer.java:3869)
at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3769)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3571)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1354)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1316)
at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:2855)
at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1401)
at com.sun.ejb.containers.EJBTimerService.access$100(EJBTimerService.java:99)
at
com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:1952)
at
com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.service(EJBTimerService.java:1948)
at com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555)
Caused by: java.lang.NullPointerException
at java.util.Date.getMillisOf(Date.java:939)
at java.util.Date.after(Date.java:912)
at
org.imixs.workflow.jee.ejb.ScheduledWorkflowServiceImplementation.processWorkItems(ScheduledWorkflowServiceImplementation.java:325)
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:585)
at
com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
at
com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:2824)
... 6 more

#]

[#|2009-06-25T05:05:09.537+0100|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=16;_ThreadName=p:
thread-pool-1; w: 4;'3@@1245854622991@@server@@domain1' 'TimedObject =
ScheduledWorkflowServiceImplementation' 'Application =
imixs-shareyourwork-ear-1.0.2' 'BEING_DELIVERED' 'PERIODIC' 'Container ID =
81602958556332042' 'Wed Jun 24 15:55:00 GMT+01:00 2009' '600000'
;2;|EJB5119:Expunging timer ['3@@1245854622991@@server@@domain1' 'TimedObject =
ScheduledWorkflowServiceImplementation' 'Application =
imixs-shareyourwork-ear-1.0.2' 'BEING_DELIVERED' 'PERIODIC' 'Container ID =
81602958556332042' 'Wed Jun 24 15:55:00 GMT+01:00 2009' '600000' ] after [2]
failed deliveries|#]

Comment by marina vatkina [ 06/Oct/10 ]

I'm changing that part of the code...

Comment by marina vatkina [ 07/Oct/10 ]

With rev is the "reschedule-failed-timer" property is set on the
ejb-timer-service property (i.e. globally), the timers that failed redelivery
will be rescheduled for the next timeout. The server needs to be restarted for
the property to be applied.

Comment by marina vatkina [ 07/Oct/10 ]

It was with rev 41521

Comment by ashishkp [ 17/Nov/11 ]

Nice instructions on .

http://javabarista.blogspot.com/2011/10/reschedule-failed-timer-in-glassfish-31.html

Comment by tkruse [ 08/Apr/16 ]

We faced the same problem, in our case marking an inner transaction with @Transactional, and the TimerBean with @TransactionManagement(TransactionManagementType.BEAN) seemed a viable workaround, I assume this would also mean there will be no immediate retry.

Also in some cases not rolling back transactions via @Transactional(dontRollbackOn=RuntimeException.class) might be viable.





[GLASSFISH-21448] Can not enable secure admin Created: 23/Oct/15  Updated: 31/Mar/16

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

Type: Bug Priority: Major
Reporter: muellermi Assignee: Joe Di Pol
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7



 Description   

1. Start GlassFish admin console
2. choose server, Secure Admin
GF displays "an error occured"

3. click onto enable...

GF displays internal error:
HTTP Status 500 - Internal Server Error

type Exception report

messageInternal Server Error

descriptionThe server encountered an internal error that prevented it from fulfilling this request.

exception

javax.servlet.ServletException: javax.el.PropertyNotFoundException: Target Unreachable, 'null' returned null

root cause

javax.faces.component.UpdateModelException: javax.el.PropertyNotFoundException: Target Unreachable, 'null' returned null

root cause

javax.el.PropertyNotFoundException: Target Unreachable, 'null' returned null

note The full stack traces of the exception and its root causes are available in the GlassFish Server Open Source Edition 4.1.1 logs.
GlassFish Server Open Source Edition 4.1.1

Excerpt from log:
[2015-10-23T09:42:58.356+0200] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=46 _ThreadName=admin-listener(3)] [timeMillis: 1445586178356] [levelValue: 900] [[
StandardWrapperValve[FacesServlet]: Servlet.service() for servlet FacesServlet threw exception
javax.el.PropertyNotFoundException: Target Unreachable, 'null' returned null
at com.sun.el.parser.AstValue.getTarget(AstValue.java:192)
at com.sun.el.parser.AstValue.setValue(AstValue.java:226)
at com.sun.el.ValueExpressionImpl.setValue(ValueExpressionImpl.java:294)
at javax.faces.component.UIInput.updateModel(UIInput.java:832)
at javax.faces.component.UIInput.processUpdates(UIInput.java:749)
at javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1291)
at javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1291)
at javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1291)
at javax.faces.component.UIForm.processUpdates(UIForm.java:281)
at javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1291)
at javax.faces.component.UIViewRoot.processUpdates(UIViewRoot.java:1254)
at com.sun.faces.lifecycle.UpdateModelValuesPhase.execute(UpdateModelValuesPhase.java:78)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658)
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.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
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.doChainInvoke(StandardPipeline.java:678)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
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:206)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
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:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
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:591)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
at java.lang.Thread.run(Unknown Source)
]]

[2015-10-23T09:44:31.411+0200] [glassfish 4.1] [INFO] [] [org.glassfish.admingui] [tid: _ThreadID=47 _ThreadName=admin-listener(4)] [timeMillis: 1445586271411] [levelValue: 800] [[
Exception Occurred :null]]



 Comments   
Comment by pczurak [ 25/Mar/16 ]

I am getting the same issue with Glassfish version 4.1.1 running on Linux
Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)

Has anyone found a fix for this?

Comment by hora1806 [ 31/Mar/16 ]

I have the same issue.

I did workaround

asadmin enable-secure-admin

Comment by phendley [ 31/Mar/16 ]

I have seen something similar in past and while not 100% positive, I believe a problem may be that there has to be non-empty password in effect. I believe one can enable the secure admin by doing sequence similar to following:
asadmin change-admin-password (not sure if we need to recycle GF afterwards??)
asadmin enable-secure-admin (not sure if we need to recycle GF afterwards??)
-phendley

Comment by pczurak [ 31/Mar/16 ]

I've found a workaround
Installed Glassfish 4.1 and then updated Glassfish to 4.1.1





[GLASSFISH-21531] Glassfish fails to start with jdk9 due to wrong jdk version detection Created: 31/Mar/16  Updated: 31/Mar/16

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

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


 Description   

"SEVERE: GlassFish requires JDK 7, you are using JDK version 1"






[GLASSFISH-21530] What is GRIZZLY0013? Created: 24/Mar/16  Updated: 24/Mar/16

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

Type: Bug Priority: Major
Reporter: t.shimada Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 4.1
Grizzly 2.3.15
Oracle JDK 1.8.0_61



 Description   

Hello I'm TOSHIKAZU. Our Glassfish have problem.
Please teach me how to fix or workaround.

Overview
========
In my client & server of commercially operating of our system has came up with the message of [WARNING][Error] in Glassfish's server.log as problem.
We don't know why has occuerd these problem from our glassfish server.

the following message:
■a part of server.log
---------------------------------------------------
[YYYY-MM-DDT18:51:02.575+0900] [glassfish 4.1] [WARNING] [] [org.glassfish.grizzly.filterchain.DefaultFilterChain] [tid: _ThreadID=132 _ThreadName=BidRateTimer] [timeMillis: 1458553862575] [levelValue: 900] [[
GRIZZLY0013: Exception during FilterChain execution
java.lang.IllegalArgumentException
at java.nio.Buffer.limit(Buffer.java:275)
at org.glassfish.grizzly.nio.transport.TCPNIOUtils.fill(TCPNIOUtils.java:200)
at org.glassfish.grizzly.nio.transport.TCPNIOUtils.writeCompositeBuffer(TCPNIOUtils.java:81)
at org.glassfish.grizzly.nio.transport.TCPNIOAsyncQueueWriter.write0(TCPNIOAsyncQueueWriter.java:112)
at org.glassfish.grizzly.nio.transport.TCPNIOAsyncQueueWriter.write0(TCPNIOAsyncQueueWriter.java:91)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.write(AbstractNIOAsyncQueueWriter.java:261)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.write(AbstractNIOAsyncQueueWriter.java:170)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.write(AbstractNIOAsyncQueueWriter.java:70)
at org.glassfish.grizzly.nio.transport.TCPNIOTransportFilter.handleWrite(TCPNIOTransportFilter.java:126)
at org.glassfish.grizzly.filterchain.TransportFilter.handleWrite(TransportFilter.java:191)
at org.glassfish.grizzly.filterchain.ExecutorResolver$8.execute(ExecutorResolver.java:111)
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.filterchain.FilterChainContext.write(FilterChainContext.java:848)
at org.glassfish.grizzly.filterchain.FilterChainContext.write(FilterChainContext.java:817)
at org.glassfish.grizzly.http.io.OutputBuffer.flushBuffer(OutputBuffer.java:1024)
at org.glassfish.grizzly.http.io.OutputBuffer.flushBinaryBuffers(OutputBuffer.java:1011)
at org.glassfish.grizzly.http.io.OutputBuffer.flushAllBuffers(OutputBuffer.java:982)
at org.glassfish.grizzly.http.io.OutputBuffer.flush(OutputBuffer.java:737)
at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:291)
at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:275)
at org.apache.catalina.connector.CoyoteOutputStream.flush(CoyoteOutputStream.java:175)
at jp.co.fractal.fx.webpublisher.handler.EventHandler.onEvent(EventHandler.java:88)
at org.glassfish.grizzly.comet.DefaultNotificationHandler.notify0(DefaultNotificationHandler.java:117)
at org.glassfish.grizzly.comet.DefaultNotificationHandler.notify(DefaultNotificationHandler.java:93)
at org.glassfish.grizzly.comet.DefaultNotificationHandler.notify(DefaultNotificationHandler.java:83)
at org.glassfish.grizzly.comet.CometContext.notify(CometContext.java:437)
at jp.co.my.do.publisher.management.CometManagement.notifyPrd(CometManagement.java:115)
at jp.co.my.do.publisher.management.timertask.DataPushTask.eventNotify(DataPushTask.java:131)
at jp.co.my.do.publisher.management.timertask.DtatPushTask.run(DataPushTask.java:99)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
]]
---------------------------------------------------

Symptom
=======
#1 When Occuer, Many sessions from rich client will be disconnected to Glassfish server.

#2 Since we will be unbale to connect to server from rich clients every one.

#3 When we tried to reboot the domain(process) of Glassfish, But it was not fix.
In fact the domain(process) couldn't be started by restart command.

#4 Stop its Domain -> Reboot OS -> Start its Domain
Then We try to do the bellow of methods, We can recover our system. Since the rich clients can connect to server as usual.

Our environments
=====
Glassfish 4.1
Grizzly 2.3.15
Oracle JDK 1.8.0_61

Question 1
=====
Do you know why come up this [WARNING][Error]?
What happen has this [WARNING][Error] our glassfish?

Question 2
=====
Do you know how to workaround?

Question 3
=====
Do you know how to fix?

Question 4
=====
Do you has experienced improving this problem as case example?

Question 5
=====
How should we invest when we has this problem?

Best Regards.






[GLASSFISH-21529] after running asadmin enable-secure-admin , encounter problem stop/start glassfish Created: 23/Mar/16  Updated: 23/Mar/16

Status: Open
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: None
Fix Version/s: None

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

running Glassfish-4.0-b59 on window XP platform with jdk1.7.0_07


Issue Links:
Cloners
clones GLASSFISH-19207 after running asadmin enable-secure-a... Closed

 Description   

This started on glassfish-4.0-b59 and b58, did not have this issue on glassfish-4.0-b57.

after running asadmin enable-secure-admin, and re-cycling glassfish
you cannot stop/start glassfish anymore.

error from the command line is this:
Z:\glassfish3\glassfish\bin>asadmin stop-domain
NCLS-ADMIN-0010
CLI306: Warning - The server located at Z:\glassfish3\glassfish\domains\domain
is not running.
Command stop-domain executed successfully.

When the process is checked glassfish is running.
Also, this was confirmed multiple times on b58 and 59 with same results.

The server.log is attached.



 Comments   
Comment by wfsaxton [ 23/Mar/16 ]

I wasn't able to re-open this previous issue, but I'm encountering this same exact issue on the latest version of glassfish (4.1.1) on Linux

host:/glassfish/glassfish4/bin$ ./asadmin start-domain
Waiting for domain1 to start .......
Successfully started the domain : domain1
domain Location:/glassfish/glassfish4/glassfish/domains/domain1
Log File: /glassfish/glassfish4/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.
host:/glassfish/glassfish4/bin$ ./asadmin change-admin-password
Enter admin user name [default: admin]>
Enter the admin password>
Enter the new admin password> (adminadmin)
Enter the new admin password again> (adminadmin)
Command change-admin-password executed successfully.
host:/glassfish/glassfish4/bin$ ./asadmin stop-domain
Waiting for the domain to stop .
Command stop-domain executed successfully.
host:/glassfish/glassfish4/bin$ ./asadmin start-domain
Waiting for domain1 to start ....
Successfully started the domain : domain1
domain Location: /glassfish/glassfish4/glassfish/domains/domain1
Log File: /glassfish/glassfish4/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.
host:/glassfish/glassfish4/bin$ ./asadmin enable-secure-admin
You must restart all running servers for the change in secure admin to take effect.
Command enable-secure-admin executed successfully.
host:/glassfish/glassfish4/bin$ ./asadmin stop-domain
Waiting for the domain to stop .
Command stop-domain executed successfully.
host:/glassfish/glassfish4/bin$ ./asadmin start-domain
Waiting for domain1 to start ....
Successfully started the domain : domain1
domain Location: /glassfish/glassfish4/glassfish/domains/domain1
Log File:/glassfish/glassfish4/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.
host:/glassfish/glassfish4/bin$ ./asadmin stop-domain
CLI306: Warning - The server located at /glassfish/glassfish4/glassfish/domains/domain1 is not running.
Command stop-domain executed successfully.





[GLASSFISH-19207] after running asadmin enable-secure-admin , encounter problem stop/start glassfish Created: 22/Oct/12  Updated: 23/Mar/16  Resolved: 02/Mar/13

Status: Closed
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 4.0_b58, 4.0_b59
Fix Version/s: None

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

running Glassfish-4.0-b59 on window XP platform with jdk1.7.0_07


Attachments: XML File after-change-domain.xml     XML File after-startup-domain.xml     File server.log-b59    
Issue Links:
Cloners
is cloned by GLASSFISH-21529 after running asadmin enable-secure-a... Open
Related
is related to JAVASERVERFACES-2557 Failure with client side state saving... Closed

 Description   

This started on glassfish-4.0-b59 and b58, did not have this issue on glassfish-4.0-b57.

after running asadmin enable-secure-admin, and re-cycling glassfish
you cannot stop/start glassfish anymore.

error from the command line is this:
Z:\glassfish3\glassfish\bin>asadmin stop-domain
NCLS-ADMIN-0010
CLI306: Warning - The server located at Z:\glassfish3\glassfish\domains\domain
is not running.
Command stop-domain executed successfully.

When the process is checked glassfish is running.
Also, this was confirmed multiple times on b58 and 59 with same results.

The server.log is attached.



 Comments   
Comment by Tim Quinn [ 22/Oct/12 ]

I could not reproduce this on Mac OS X with Java 1.7.0_7 and promoted GlassFish build 59.

The error from the server log (thanks for that) shows that there is something going wrong in the SSL handshake. The secure admin logic has not changed in the recent builds, so it's not yet clear why the errors are happening in your environment.

I'm now trying to get a Windows XP system set up to try to reproduce the error there.

Comment by Tim Quinn [ 22/Oct/12 ]

I was able to reproduce the problem on Windows XP with Java 1.7.0_7 and GlassFish build 59.

I also saw the problem using Java 1.6.0 instead.

There was a Grizzly integration just prior to build 58, so I am transferring this to the Grizzly component.

Comment by oleksiys [ 23/Oct/12 ]

I see nothing wrong w/ Grizzly, the exception is thrown from SSL layer.
Reassigning to security team, may be this is caused by recent JDK updates.

Thanks.

Comment by Tim Quinn [ 23/Oct/12 ]

I have reproduced the problem on a Windows XP system.

Using GlassFish build 57 things work with both Java 1.6.0-37 and 1.7.0_09.

Using build 58 the sequence of steps fails with both versions of Java.

Here are the steps I used:

Install GlassFish.

asadmin start-domain
asadmin change-admin-password # answer prompts to give a non-empty admin password
asadmin enable-secure-admin # you should be prompted for the user and pw; press enter for the user and enter the new pw you set for the pw
asadmin stop-domain
asadmin start-domain
asadmin uptime

Both b57 and b58 will display the server's SSL cert information and prompt the user whether to trust it. (This is normal.)

b57 then prompts for the password and, if you provide it, the uptime command completes normally as expected.
b58 does not prompt for the password but instead reports the error.

Comment by larry.mccay [ 31/Oct/12 ]

After careful review, I am reassigning this to the grizzly team. There was a change made for SPDY which you can view here: http://java.net/projects/grizzly/sources/git/revision/f51d0801c29505b1c74768b73b15207c4b0ac418

SSLUtils and SSLFilter were both modified in this change and appear in the stacktrace in windows environments.
There have been issues with SPDY on windows due to a lack of support for NPN - perhaps there is some assumption of SPDY support leaking into SSL here?

Comment by Ryan Lubke [ 05/Dec/12 ]

The code referenced in the Oct 31 comment isn't currently what is integrated in v4 so it's not relevant.. For what it's worth, the correct code is in the 2.3.x branch.

That said, I've looked at the stacktrace and I'm in agreement with Alexey - this isn't a Grizzly issue.

See:

Caused by: java.security.NoSuchAlgorithmException: SunTlsRsaPremasterSecret KeyGenerator not available
	at javax.crypto.KeyGenerator.<init>(KeyGenerator.java:158)
	at javax.crypto.KeyGenerator.getInstance(KeyGenerator.java:207)
	at sun.security.ssl.JsseJce.getKeyGenerator(JsseJce.java:267)
	at sun.security.ssl.RSAClientKeyExchange.generateDummySecret(RSAClientKeyExchange.java:249)

This implies something isn't installed correctly or a configuration option is messing things up.
One possible problem that the searches pointed to was java.ext.dirs property causing issues.

I don't currently have a Windows VM available for testing. Tim or Tee, could either of you provide the domain.xml from your win32 environment once you start getting the error?

Note: I'm still of the opinion that this isn't a Grizzly issue, but will spend a few cycles to see if we can narrow down the issue.

Comment by Tim Quinn [ 05/Dec/12 ]

Attaching two domain.xml files:

after-startup-domain.xml - the file just after creating a new domain and starting it
after-change-domain.xml - the file just after enabling secure admin and restarting the domain

Both are from b58 (the first GlassFish build where this problem first appeared)

Comment by Tim Quinn [ 05/Dec/12 ]

At Ryan's request, here's some more information.

The GlassFish server.log shows java.ext.dirs defined as

C:\Program Files\Java\jre7/lib/ext:C:\Program Files\Java\jre7/jre/lib/ext:C:\tim\asgroup\b58\glassfish3\glassfish\domains\domain1/lib/ext

There is no lib directory under the jre directory on my system, so I ran

dir "C:\Program Files\Java\jre7\lib\ext" "C:\tim\asgroup\b58\glassfish3\glassfish\domains\domain1\lib\ext"

and here's the result:

Volume in drive C has no label.
Volume Serial Number is 8C50-8553

Directory of C:\Program Files\Java\jre7\lib\ext

10/23/2012 06:45 AM <DIR> .
10/23/2012 06:45 AM <DIR> ..
09/24/2012 09:28 PM 84,196 access-bridge.jar
09/24/2012 09:17 PM 8,934 dnsns.jar
09/24/2012 09:27 PM 43,593 jaccess.jar
09/24/2012 10:00 PM 1,013,521 localedata.jar
10/22/2012 05:05 PM 829 meta-index
09/24/2012 09:16 PM 15,943 sunec.jar
09/24/2012 09:26 PM 198,176 sunjce_provider.jar
09/24/2012 09:17 PM 30,695 sunmscapi.jar
09/24/2012 09:17 PM 238,226 sunpkcs11.jar
09/24/2012 09:29 PM 68,654 zipfs.jar
10 File(s) 1,702,767 bytes

Directory of C:\tim\asgroup\b58\glassfish3\glassfish\domains\domain1\lib\ext

12/05/2012 01:34 PM <DIR> .
12/05/2012 01:34 PM <DIR> ..
0 File(s) 0 bytes
2 Dir(s) 8,502,603,776 bytes free

Comment by Ryan Lubke [ 22/Feb/13 ]

Sorry for the delay in coming back to this.

I've just tested this with b76 on Windows 7 without issue.

@Tim and/or @Tee: Are you still able to reproduce this on XP with b76 (or later)?

Comment by Ryan Lubke [ 02/Mar/13 ]

Closing as cannot reproduce. If someone is still able to reproduce this, please re-open with details.





[GLASSFISH-21238] Response code 400 on a DELETE request with a body Created: 21/Oct/14  Updated: 22/Mar/16

Status: Reopened
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 4.1
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: ganichev Assignee: oleksiys
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Same behavior on linux x64, windows 7 x64. jdk1.8.0_20



 Description   

When a browser sends a request with a method DELETE and some body, glassfish replies with the response code 400. No corresponding filters or a servlet are called.

When a DELETE request contains no body, then servlet's methods are called as usual.

Glassfish 4.0 has no such problem.

Th sample request is:

DELETE /struct/StructureElement/3751?_dc=1413865817878 HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Content-Length: 11
Origin: http://localhost:8080
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.101 Safari/537.36
Content-Type: application/json
Accept: */*
Referer: http://localhost:8080/struct-client/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,ru;q=0.6
Cookie: BPMSESSIONID=8aMBU61U7xn1RFSObP1slBhkvMCC; JSESSIONID=d116d19d27d9a381eef12b5acacd; treeForm_tree-hi=treeForm:tree:resources:JDBC:connectionPoolResources:ypool

{"id":3751}


 Comments   
Comment by timuralp [ 22/May/15 ]

This comes up when attempting to implement OpenStack Swift, as the Bulk Delete operation specifies the DELETE verb with an entity containing the list of (container, object) pairs to remove – http://docs.openstack.org/kilo/config-reference/content/object-storage-bulk-delete.html

Comment by gaul [ 15/Jun/15 ]

Calling HttpServer.getServerConfiguration().setAllowPayloadForUndefinedHttpMethods(true) addresses this issue for me.

Comment by oleksiys [ 15/Jun/15 ]

Right, but IMO we have to keep the existing behavior as default and introduce new configuration attribute for <http> element to enable "allow-payload-for-undefined-http-methods".

Comment by oleksiys [ 23/Jun/15 ]

fixed.

Revision: 63971
Date: 2015-06-23 14:35:37 UTC

introduced new http attribute allow-payload-for-undefined-http-methods, which is false by default.

Comment by obi_orjiekwe [ 07/Mar/16 ]

Hi,

I have set this property in asadmin but I am still getting HTTP 400 when I call DELETE with request body:

asadmin set server-config.network-config.protocols.protocol.http-listener-1.http.allow-payload-for-undefined-http-methods=true

Are there any further settings to be applied to make this work?
Please can you also confirm this is fixed in GlassFish 4.1.1?

Regards

Comment by oleksiys [ 08/Mar/16 ]

you're right, it's not fix in 4.1.1
I've just commited the fix to the 4.1.x branch

Comment by obi_orjiekwe [ 22/Mar/16 ]

hi oleksiys, what is the easiest way to obtain I can obtain this patch/fix? thanks for your help





[GLASSFISH-21528] AdminGui does not start after changing master password Created: 21/Mar/16  Updated: 21/Mar/16

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

Type: Bug Priority: Major
Reporter: LeoLux Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours
Environment:

Windows 10
Glassfish Nightly from 2016-03-21 (http://download.oracle.com/glassfish/5.0/nightly/latest-glassfish.zip)


Tags: admin_gui, security

 Description   

Reproduce:
1. Use a clean version of glassfish 5
2. Execute "asadmin change-master-password --savemasterpassword=true domain1" and change the password from "changeit" to "whatever"
3. start the domain by executing "asadmin start-domain domain1"
4. Watch the stacktrace in the server log:

2016-03-21T12:27:19.290+0100|Information: GlassFish Server Open Source Edition 5.0 (1) startup time : Felix (2.125ms), startup services(1.122ms), total(3.247ms)
2016-03-21T12:27:19.400+0100|Information: JTS5014: Recoverable JTS instance, serverId = [100]
2016-03-21T12:27:19.572+0100|Warnung: Cannot start JMX connector JmxConnector config:

{ name = system, Protocol = rmi_jrmp, Address = 0.0.0.0, Port = 8686, AcceptAll = false, AuthRealmName = admin-realm, SecurityEnabled = false}

due to exception java.net.MalformedURLException: Bad URL path: _W_724V_01011603_00_007:8686/jndi/rmi://mathias-lenovo.Speedport_W_724V_01011603_00_007:8686/jmxrmi
2016-03-21T12:27:19.587+0100|Schwerwiegend: java.net.MalformedURLException: Bad URL path: _W_724V_01011603_00_007:8686/jndi/rmi://mathias-lenovo.Speedport_W_724V_01011603_00_007:8686/jmxrmi
at javax.management.remote.JMXServiceURL.validate(JMXServiceURL.java:406)
at javax.management.remote.JMXServiceURL.validate(JMXServiceURL.java:411)
at javax.management.remote.JMXServiceURL.<init>(JMXServiceURL.java:226)
at org.glassfish.admin.mbeanserver.RMIConnectorStarter.start(RMIConnectorStarter.java:306)
at org.glassfish.admin.mbeanserver.JMXStartupService$JMXConnectorsStarterThread.startConnector(JMXStartupService.java:313)
at org.glassfish.admin.mbeanserver.JMXStartupService$JMXConnectorsStarterThread.run(JMXStartupService.java:350)
2016-03-21T12:27:19.790+0100|Information: Grizzly Framework 2.3.23 started in: 187ms - bound to [/0.0.0.0:7676]
2016-03-21T12:27:19.822+0100|Information: HV000001: Hibernate Validator 5.1.2.Final
2016-03-21T12:27:22.994+0100|Information: Listening to REST requests at context: /management/domain.
2016-03-21T12:27:23.087+0100|Information: Registered com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl@1f52eb6f as OSGi service registration: org.apache.felix.framework.ServiceRegistrationImpl@44cb460e.
2016-03-21T12:27:23.509+0100|Information: visiting unvisited references
2016-03-21T12:27:24.009+0100|Information: Created HTTP listener http-listener-1 on host/port 0.0.0.0:8080
2016-03-21T12:27:24.009+0100|Information: Created HTTP listener http-listener-2 on host/port 0.0.0.0:8181
2016-03-21T12:27:24.025+0100|Information: Created HTTP listener admin-listener on host/port 0.0.0.0:4848
2016-03-21T12:27:24.041+0100|Information: Created virtual server server
2016-03-21T12:27:24.041+0100|Information: Created virtual server __asadmin
2016-03-21T12:27:24.259+0100|Information: Setting JAAS app name glassfish-web
2016-03-21T12:27:24.259+0100|Information: Virtual server server loaded default web module
2016-03-21T12:27:24.462+0100|Schwerwiegend: Exception while deploying the app [__admingui]
2016-03-21T12:27:24.462+0100|Schwerwiegend: Exception during lifecycle processing
MultiException stack 1 of 6
java.lang.IllegalStateException: java.io.IOException: Keystore was tampered with, or password was incorrect
at com.sun.enterprise.security.ssl.impl.SecuritySupportImpl.loadStores(SecuritySupportImpl.java:251)
at com.sun.enterprise.security.ssl.impl.SecuritySupportImpl.initJKS(SecuritySupportImpl.java:184)
at com.sun.enterprise.security.ssl.impl.SecuritySupportImpl.<init>(SecuritySupportImpl.java:139)
at com.sun.enterprise.security.ssl.impl.SecuritySupportImpl.<init>(SecuritySupportImpl.java:134)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
at org.glassfish.hk2.utilities.reflection.ReflectionHelper.makeMe(ReflectionHelper.java:1350)
at org.jvnet.hk2.internal.ClazzCreator.createMe(ClazzCreator.java:271)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:365)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:693)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:78)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:211)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:234)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:693)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:78)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:211)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:234)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:88)
at com.sun.enterprise.security.ee.SecuritySniffer.setup(SecuritySniffer.java:115)
at com.sun.enterprise.v3.server.ContainerStarter.startContainer(ContainerStarter.java:97)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainer(ApplicationLifecycle.java:997)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:702)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:377)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:406)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:211)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:100)
Caused by: java.io.IOException: Keystore was tampered with, or password was incorrect
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:772)
at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:55)
at java.security.KeyStore.load(KeyStore.java:1433)
at com.sun.enterprise.security.ssl.impl.SecuritySupportImpl.loadKS(SecuritySupportImpl.java:288)
at com.sun.enterprise.security.ssl.impl.SecuritySupportImpl.loadStores(SecuritySupportImpl.java:242)
... 59 more
Caused by: java.security.UnrecoverableKeyException: Password verification failed
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:770)
... 63 more
MultiException stack 2 of 6
java.lang.IllegalStateException: Unable to perform operation: create on com.sun.enterprise.security.ssl.impl.SecuritySupportImpl
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:392)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:693)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:78)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:211)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:234)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:693)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:78)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:211)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:234)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:88)
at com.sun.enterprise.security.ee.SecuritySniffer.setup(SecuritySniffer.java:115)
at com.sun.enterprise.v3.server.ContainerStarter.startContainer(ContainerStarter.java:97)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainer(ApplicationLifecycle.java:997)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:702)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:377)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:406)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:211)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:100)
MultiException stack 3 of 6
java.lang.IllegalArgumentException: While attempting to resolve the dependencies of com.sun.enterprise.security.ssl.SSLUtils errors were found
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:246)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:693)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:78)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:211)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:234)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:88)
at com.sun.enterprise.security.ee.SecuritySniffer.setup(SecuritySniffer.java:115)
at com.sun.enterprise.v3.server.ContainerStarter.startContainer(ContainerStarter.java:97)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainer(ApplicationLifecycle.java:997)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:702)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:377)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:406)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:211)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:100)
MultiException stack 4 of 6
java.lang.IllegalStateException: Unable to perform operation: resolve on com.sun.enterprise.security.ssl.SSLUtils
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:386)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:693)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:78)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:211)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:234)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:88)
at com.sun.enterprise.security.ee.SecuritySniffer.setup(SecuritySniffer.java:115)
at com.sun.enterprise.v3.server.ContainerStarter.startContainer(ContainerStarter.java:97)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainer(ApplicationLifecycle.java:997)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:702)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:377)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:406)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:211)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:100)
MultiException stack 5 of 6
java.lang.IllegalArgumentException: While attempting to resolve the dependencies of com.sun.enterprise.security.SecurityLifecycle errors were found
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:246)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:88)
at com.sun.enterprise.security.ee.SecuritySniffer.setup(SecuritySniffer.java:115)
at com.sun.enterprise.v3.server.ContainerStarter.startContainer(ContainerStarter.java:97)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainer(ApplicationLifecycle.java:997)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:702)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:377)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:406)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:211)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:100)
MultiException stack 6 of 6
java.lang.IllegalStateException: Unable to perform operation: resolve on com.sun.enterprise.security.SecurityLifecycle
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:386)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:88)
at com.sun.enterprise.security.ee.SecuritySniffer.setup(SecuritySniffer.java:115)
at com.sun.enterprise.v3.server.ContainerStarter.startContainer(ContainerStarter.java:97)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainer(ApplicationLifecycle.java:997)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:702)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:377)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:406)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:211)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:100)

2016-03-21T12:27:24.541+0100|Schwerwiegend: Application deployment failed: Exception while deploying the app [__admingui]



 Comments   
Comment by LeoLux [ 21/Mar/16 ]

I tried to reproduce the issue by myself without success. There is no exception even if change the keystore.jsk file by adding another key-pair entry.

I think that the cause is outside of the information given by the stacktrace and outside of the reproduction steps given in this issue. However I am sure that the changing the master password has lead to this issue somehow and for once.

As the bug can't be reproduced reliably this issue can be closed.





[GLASSFISH-19470] RAR5031:System Exception -> NPE Created: 18/Dec/12  Updated: 18/Mar/16

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: 3.1.2_b23
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Heikki Salokanto Assignee: sfelts
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish 3.1.2 build 23
Oracle 10.2.0.5 ia64 2-node RAC


Tags: JDBC, NullPointerException, RAR5031, connection, pool

 Description   

We are getting occasional "RAR5031" System Exceptions followed by a NullPointerException. This looks somewhat similar to GLASSFISH-13390.

It appears to have something to do with the JDBC connections or connection pools but the trace is all but clear. The DB is a 2-node RAC of 10.2.0.5.

2012-12-18T03:55:26.350+0200|SEVERE|glassfish3.1.2|javax.enterprise.resource.resourceadapter.com.sun.enterprise.resource|
_ThreadID=24;_ThreadName=Thread-2;|RAR5031:System Exception
java.lang.NullPointerException

2012-12-18T03:55:26.350+0200|SEVERE|glassfish3.1.2|javax.enterprise.resource.resourceadapter.com.sun.enterprise.resource|
_ThreadID=24;_ThreadName=Thread-2;|RAR5031:System Exception
com.sun.appserv.connectors.internal.api.PoolingException: java.lang.NullPointerException
        at com.sun.enterprise.resource.ConnectorXAResource.getResourceHandle(ConnectorXAResource.java:255)
        at com.sun.enterprise.resource.ConnectorXAResource.end(ConnectorXAResource.java:159)
        at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.delistResource(JavaEETransactionManagerSimplified.java:528)
        at com.sun.enterprise.resource.rm.SystemResourceManagerImpl.delistResource(SystemResourceManagerImpl.java:145)
        at com.sun.enterprise.resource.pool.PoolManagerImpl.resourceClosed(PoolManagerImpl.java:381)
        at com.sun.enterprise.resource.listener.LocalTxConnectionEventListener.connectionClosed(LocalTxConnectionEventListener.java:77)
        at com.sun.gjc.spi.ManagedConnection.connectionClosed(ManagedConnection.java:784)
        at com.sun.gjc.spi.base.ConnectionHolder.close(ConnectionHolder.java:217)
        at com.sun.gjc.spi.jdbc40.ConnectionHolder40.close(ConnectionHolder40.java:587)
        at org.hibernate.connection.DatasourceConnectionProvider.closeConnection(DatasourceConnectionProvider.java:97)
        at org.hibernate.jdbc.ConnectionManager.closeConnection(ConnectionManager.java:474)
        at org.hibernate.jdbc.ConnectionManager.aggressiveRelease(ConnectionManager.java:429)
        at org.hibernate.jdbc.ConnectionManager.afterStatement(ConnectionManager.java:304)
        at org.hibernate.jdbc.AbstractBatcher.closePreparedStatement(AbstractBatcher.java:572)
        at org.hibernate.jdbc.AbstractBatcher.closeStatement(AbstractBatcher.java:291)
        at org.hibernate.jdbc.AbstractBatcher.closeQueryStatement(AbstractBatcher.java:307)
        at org.hibernate.jdbc.AbstractBatcher.closeQueryStatement(AbstractBatcher.java:234)
        at org.hibernate.loader.Loader.doQuery(Loader.java:854)
        at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:274)
        at org.hibernate.loader.Loader.doList(Loader.java:2533)
        at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2276)
        at org.hibernate.loader.Loader.list(Loader.java:2271)
        at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:119)
        at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1716)
        at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:347)
        at my.own.dao.package.MyOwnDAO.selaa(MyOwnDAO.java:126)
        at my.own.package.MyClass.selaa(MyClass.java:42)
        at sun.reflect.GeneratedMethodAccessor606.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
        at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
        at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5388)
        at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
        at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
        at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
        at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
        at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
        at sun.reflect.GeneratedMethodAccessor117.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
        at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
        at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370)
        at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5360)
        at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5348)
        at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:214)
        at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
        at $Proxy246.selaa(Unknown Source)
        at my.own.package.__EJB31_Generated__MyOwnClass__Intf____Bean__.selaa(Unknown Source)
        at my.another.package.AnotherClass.onMessage(AnotherClass.java:145)
        at sun.reflect.GeneratedMethodAccessor604.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        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.invokeTargetBeanMethod(BaseContainer.java:4180)
        at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5368)
        at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5348)
        at com.sun.ejb.containers.MessageBeanContainer.deliverMessage(MessageBeanContainer.java:1099)
        at com.sun.ejb.containers.MessageBeanListenerImpl.deliverMessage(MessageBeanListenerImpl.java:81)
        at com.sun.enterprise.connectors.inbound.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:171)
        at $Proxy336.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

The method MyOwnDAO.selaa() (=browse) is as follows. Exception is thrown on line 126 which is criteria.list().

    public static List<AGame> selaa(String serialnumber, boolean onlyActive) throws AvepsiDAOException {
        Session session = HibernateUtil.getNMSession();
        Transaction tx = null;
        try {
            tx = session.beginTransaction();
            Criteria criteria = session.createCriteria(AGame.class);
            criteria.add(Restrictions.eq("serialnumber", serialnumber));
            if (onlyActive) {
                criteria.add(Restrictions.eq("active", 1));
            }
            List list = criteria.list();
            tx.commit();
            return list;
        } catch (HibernateException e) {
            rollbackIfActive(tx);
            throw new AvepsiDAOException(e, serialnumber);            
        }
    }

Connection validation is 'on'.



 Comments   
Comment by emailnbw [ 29/May/14 ]

Occasionally seeing the same thing. Glassfish 3.1.2 b23 w/Oracle ojdbc6 driver.

Comment by sekmiller [ 18/Mar/16 ]

We are still seeing this in Glassfish 4.1





[GLASSFISH-21437] Can't create new JDBC Resource from admin web interface Created: 08/Oct/15  Updated: 14/Mar/16  Resolved: 14/Mar/16

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ionut_ursuleanu Assignee: Joe Di Pol
Resolution: Duplicate Votes: 10
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 x64, Java 8 update 51


Issue Links:
Duplicate
duplicates GLASSFISH-21443 Impossible to create a mail session Open

 Description   

After pressing the "New" button from JDBC Resources page the following exception is thrown:

2015-10-08T16:58:53.729+0300|Severe: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event215'.
	at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
	at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
	at com.sun.jsftemplating.layout.descriptors.LayoutComponent.beforeCreate(LayoutComponent.java:348)
	at com.sun.jsftemplating.layout.descriptors.LayoutComponent.getChild(LayoutComponent.java:288)
	at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:556)
	at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:551)
	at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
	at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
	at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:255)
	at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:256)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
	at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:123)
	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658)
	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.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
	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.doChainInvoke(StandardPipeline.java:678)
	at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
	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:206)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
	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:283)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
	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:591)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.reflect.InvocationTargetException
	at sun.reflect.GeneratedMethodAccessor167.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
	at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
	... 46 more
Caused by: java.lang.NullPointerException
	at com.sun.jsftemplating.handlers.UtilHandlers.mapPut(UtilHandlers.java:314)
	... 51 more


 Comments   
Comment by hink084 [ 09/Oct/15 ]

This happened to me as well. However it occurred every time I hit the "New" button anywhere within Glassfish - JDBC Resources, HTTP Listeners, Virtual Servers, etc. I ended up reverting to Glassfish 4.1.

My default settings are: Windows 7, Java 1.8.0_60 x64.
I also tried running v4.1.1 with Java 1.7.0_79 x64 by setting the AS_JAVA variable, but I still received the RuntimeException.

Comment by mzsolt [ 20/Oct/15 ]

The same problem occurs on Linux either trying to create a virtual server or a new HTTP listener, or anywhere! IMHO it's a blocker problem. GLASSFISH-21444 and GLASSFISH-21436 may be caused by this exact same NullPointerException in UtilHandlers.java:314!

Comment by LeoLux [ 04/Nov/15 ]

This is a showstopper and it occurs on my Linux machine running Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)

Comment by LeoLux [ 05/Nov/15 ]

This is a major bug and it has been created almost a month ago. Not a single progress since then. This seems to be a political issue at Oracle.

Comment by aquaglia [ 06/Nov/15 ]

I also had to downgrade to version 4.1.
I wonder why this issue has been assigned but never got updated. This is not very professional.

Comment by symbicator [ 13/Dec/15 ]

The same issue here.
Kubuntu 15.10
java version "1.8.0_66" Java(TM) SE Runtime Environment (build 1.8.0_66-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
It's already two months, there is no updates on the issue.
Looks like downgrading to the version 4.1 is the only solution for now =(

Comment by aquaglia [ 14/Dec/15 ]

It seems Oracle wants people to move to WebLogic or to JBoss Community Edition.

Comment by mscpetejohanson [ 14/Dec/15 ]

Further fuel for bumping the move to WildFly in our list of priorities.





[GLASSFISH-21443] Impossible to create a mail session Created: 16/Oct/15  Updated: 14/Mar/16

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

Type: Bug Priority: Major
Reporter: mbutton Assignee: Anissa Lam
Resolution: Unresolved Votes: 5
Labels: mail
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Red Hat Enterprise Linux Server release 6.6 (Santiago)


Issue Links:
Duplicate
is duplicated by GLASSFISH-21437 Can't create new JDBC Resource from a... Closed
is duplicated by GLASSFISH-21444 error java.lang.RuntimeException Closed

 Description   

Context :
JVM invocation command line:
/logiciels/jdk1.8.0_60/bin/java [ ... ]
Running GlassFish Version: GlassFish Server Open Source Edition 4.1.1 (build 1)]]

Hi, I've freshly installed the GlassFish 4.1.1.
I then ran those commands :

asadmin create-domain myDomain
asadmin start-domain myDomain
asadmin --host localhost --port 4848 enable-secure-admin

When I log in to the admin console, I'm trying to create a mail session, and I get a "class java.lang.RuntimeException" message.
In the log file, I can see :

[2015-10-16T11:41:27.535+0200] [glassfish 4.1] [INFO] [] [org.glassfish.admingui] [tid: _ThreadID=96 _ThreadName=admin-listener(8)] [timeMillis: 1444988487535] [levelValue: 800] [[
Exception Occurred :null]]

[2015-10-16T11:41:27.541+0200] [glassfish 4.1] [SEVERE] [] [javax.enterprise.resource.webcontainer.jsf.context] [tid: _ThreadID=96 _ThreadName=admin-listener(8)] [timeMillis: 1444988487541] [levelValue: 1000] [[
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event143'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.beforeCreate(LayoutComponent.java:348)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.getChild(LayoutComponent.java:288)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:556)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:551)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:255)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:256)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:123)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658)
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.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
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.doChainInvoke(StandardPipeline.java:678)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
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:206)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
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:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
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:591)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor158.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 60 more
Caused by: java.lang.NullPointerException
at com.sun.jsftemplating.handlers.UtilHandlers.mapPut(UtilHandlers.java:314)
... 65 more
]]



 Comments   
Comment by mbutton [ 16/Oct/15 ]

I also tried with a 5.0 beta, and it's the same result.

However, I just confirmed that it is correctly working with 3.1.2.2 (build 5).

Comment by Romain Grécourt [ 16/Oct/15 ]

Looking at the stack trace you tried to create a mail session using the admin console.

Can you try against GF 4.0 and 4.1 ?
Can you also try using jdk7 ?

Thanks.

Comment by mbutton [ 20/Oct/15 ]

Bonjour Romain,

you're right : I tried to create a mail session through the admin console.

I first tried with a JDK 7, and then when I encountered the problem, I read about the recommandations, which were :
Java EE 7 requires JDK 7 or above, JDK 8 u60 or above is recommended for GlassFish 4.1.1

I then decided to try with a JDK 8u60, and since it didn't fix my problem, I opened that case.
Now, everything is working fine with a GF 3.1.2.2, but I unfortunately have no more time to spend on the subject (thus, I won't be able to test against GF 4.0 & 4.1)
I just thought it would be useful for the community to know about that regression.

Thanks.

Comment by ekremkucuk [ 25/Dec/15 ]

I had similar problem.

I have started glassfish 4.1.1 instance as usual running with JDK 1.8.0_65

I have clicked Resources -> Java Mail Sessions

On right frame "class java.lang.RuntimeException" is written on blank page.

On Console:

2015-12-25T18:32:04.324+0200|Info: Exception Occurred :null
2015-12-25T18:32:04.328+0200|Severe: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event144'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.beforeCreate(LayoutComponent.java:348)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.getChild(LayoutComponent.java:288)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:556)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:551)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:255)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:256)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:123)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658)
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.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
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.doChainInvoke(StandardPipeline.java:678)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
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:206)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
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:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
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:591)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor208.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 46 more
Caused by: java.lang.NullPointerException
at com.sun.jsftemplating.handlers.UtilHandlers.mapPut(UtilHandlers.java:314)
... 51 more

Comment by fmateo [ 22/Jan/16 ]

This problem is not just for mail session. There is a similar exception for every "New" operation using the web console.
I have confirmed that this was working ok on Glassfish 4.0 and 4.1.





[GLASSFISH-21444] error java.lang.RuntimeException Created: 18/Oct/15  Updated: 14/Mar/16  Resolved: 14/Mar/16

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: taoufik_01 Assignee: Anissa Lam
Resolution: Duplicate Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates GLASSFISH-21443 Impossible to create a mail session Open

 Description   

Hello
path : admin consol /JMS Ressources/JMS Resources/Connections factories
glassfish version 4.1.1
JDK 8
windows 8

When i click on the New factory i get this error : class java.lang.RuntimeException. im blocked with issue . thanks for your help



 Comments   
Comment by Romain Grécourt [ 19/Oct/15 ]

Please provide the exception found in server.log.
I'd advice you to try using JDK7 to see if that makes a difference.

Comment by clux87 [ 12/Jan/16 ]

I have the same error, my server log:

Información: Exception Occurred :null
Información: Exception Occurred :null
Información: Exception Occurred :null
Grave: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event166'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.beforeCreate(LayoutComponent.java:348)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.getChild(LayoutComponent.java:288)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:556)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:551)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:255)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:256)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:123)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658)
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.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
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.doChainInvoke(StandardPipeline.java:678)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
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:206)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
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:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
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:591)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor169.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 46 more
Caused by: java.lang.NullPointerException
at com.sun.jsftemplating.handlers.UtilHandlers.mapPut(UtilHandlers.java:314)
... 51 more





[GLASSFISH-18942] ejb-timer pool kills scheduled tasks when its thread is associated with transaction marked for rollback Created: 25/Jul/12  Updated: 14/Mar/16  Resolved: 30/Jul/13

Status: Resolved
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2_b23, 3.1.2, 3.1.2.2
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: pdudits Assignee: Srini
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows Server 2008R2, JDK 1.7u5, Oracle 11g, standalone instance, Transaction and EJB monitoring set to HIGH


Tags: 4_0_1-review

 Description   

When a call to com.sun.ejb.containers.TimerBean fails likely due to EclipseLink error (unfortunately I fail to find any primary cause for this), the executing thread will remain associated with transaction in state Status.MARKED_FOR_ROLLBACK. After that every task that gets executed in this thread will fail with following stacktrace:

[#|2012-07-23T13:51:30.016+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=618;
_ThreadName=Thread-2;|javax.ejb.TransactionRolledbackLocalException: Client's transaction aborted
	at com.sun.ejb.containers.BaseContainer.useClientTx(BaseContainer.java:4722)
	at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:4601)
	at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1914)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
	at $Proxy525.findTimer(Unknown Source)
	at com.sun.ejb.containers.EJBTimerService.getValidTimerFromDB(EJBTimerService.java:2044)
	at com.sun.ejb.containers.EJBTimerService.checkForTimerValidity(EJBTimerService.java:2033)
	at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1792)
	at com.sun.ejb.containers.EJBTimerService.access$100(EJBTimerService.java:108)
	at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:2646)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
	at java.lang.Thread.run(Thread.java:722)

As a result, the scheduled task is expunged and is no longer executed. After restarting the instance things work again (as expunging from the database failed due to same exception). The situation was verified in debugger: At BaseContainer.java:4722, the clientTx were always the same, as well as Thread ID. The container should likely roll back the transaction in this scenario.

Excerpt from server log of the offending thread:

[#|2012-07-23T13:51:30.016+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=618;
_ThreadName=Thread-2;|EJB5184: A system exception occurred during an invocation on EJB TimerBean, method: public 
com.sun.ejb.containers.TimerState com.sun.ejb.containers.TimerBean.findTimer(com.sun.ejb.containers.TimerPrimaryKey)|#]

[#|2012-07-23T13:51:30.016+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=618;
_ThreadName=Thread-2;|javax.ejb.TransactionRolledbackLocalException: Client's transaction aborted

[#|2012-07-23T13:51:30.016+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=618;
_ThreadName=Thread-2;|EJB5184: A system exception occurred during an invocation on EJB TimerBean, method: public void 
com.sun.ejb.containers.TimerBean.remove(com.sun.ejb.containers.TimerPrimaryKey)|#]
[#|2012-07-23T13:51:30.016+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=618;
_ThreadName=Thread-2;|javax.ejb.TransactionRolledbackLocalException: Client's transaction aborted
[#|2012-07-23T13:51:30.016+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=618;
_ThreadName=Thread-2;|EJB5118: Failure removing timer bean [3@@1342689087527@@main@@main]|#]
[#|2012-07-23T13:51:30.016+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=618;
_ThreadName=Thread-2;|javax.ejb.EJBTransactionRolledbackException
[#|2012-07-23T13:55:00.000+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=618;
_ThreadName=Thread-2;|EJB5184:A system exception occurred during an invocation on EJB TimerBean, method: public
com.sun.ejb.containers.TimerState com.sun.ejb.containers.TimerBean.findTimer(com.sun.ejb.containers.TimerPrimaryKey)|#]
[#|2012-07-23T13:55:00.000+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=618;
_ThreadName=Thread-2;|javax.ejb.TransactionRolledbackLocalException: Client's transaction aborted
[#|2012-07-23T13:55:00.000+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=618;
_ThreadName=Thread-2;|EJB5184:A system exception occurred during an invocation on EJB TimerBean, method: public void 
com.sun.ejb.containers.TimerBean.remove(com.sun.ejb.containers.TimerPrimaryKey)|#]
[#|2012-07-23T13:55:00.000+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=618;
_ThreadName=Thread-2;|javax.ejb.TransactionRolledbackLocalException: Client's transaction aborted
[#|2012-07-23T13:55:00.000+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=618;
_ThreadName=Thread-2;|EJB5118:Failure removing timer bean [1@@1342689087527@@main@@main]|#]
[#|2012-07-23T13:55:00.000+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=618;
_ThreadName=Thread-2;|javax.ejb.EJBTransactionRolledbackException
[#|2012-07-23T14:03:13.014+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=618;
_ThreadName=Thread-2;|EJB5184:A system exception occurred during an invocation on EJB TimerBean, method: public 
com.sun.ejb.containers.TimerState com.sun.ejb.containers.TimerBean.findTimer(com.sun.ejb.containers.TimerPrimaryKey)|#]


 Comments   
Comment by aandrade12345 [ 31/Aug/12 ]

I'm having the same issue on a @Schedule(hour = "", minute = "", second = "*/4", persistent = false) method of an ejb.

Does anyone knows a workaround ? For this bug ?

Debian 6 Linux/OpenJDK 1.7 (IcedTea7 2.1.1)/Glassfish 3.1.2.2/EclipseLink/Postgres 9.1

Comment by jfowler2 [ 26/Apr/13 ]

I am also seeing this exact same issue, on an intermittent but frequently recurring basis. The only workaround I've found is to undeploy my application, restart Glassfish, and then redeploy (this really isn't a suitable workaround for a production system though).

Windows Server 2008/Oracle JDK 1.6.0_43/Glassfish 3.1.2.2/EclipseLink/Oracle db

Comment by marina vatkina [ 26/Apr/13 ]

Set the number of retries to a really large value. Increase the retry delay if you think that the retry shouldn't happen too soon.

Comment by jfowler2 [ 26/Apr/13 ]

Marina, when we see this issue, it happens on every single timer invocation. For example, we have an EJB timer that runs every 30 seconds, and when Glassfish gets into this state, every 30 seconds we will see the error above until the application is undeployed and Glassfish is restarted. So I'm not sure how increasing the retry value would correct the problem (I think we'd just see this error even more frequently?).

Comment by marina vatkina [ 26/Apr/13 ]

Why does it get into that state? If you increase the retry delay, it won't run the next timeout until the current one either succeeds or fails after the required number of retries, and the latter causes the timer removal.

Comment by jfowler2 [ 26/Apr/13 ]

Marina, that is a great question - I have no idea why it gets into this state. As you can see from the stack trace in the description, this error occurs before the application's code even gets called. It appears to me that the container tries to associate a transaction for the timer invocation, finds that the transaction is somehow already aborted, and therefore aborts the timer invocation. But maybe you can shed more light on that aspect.

With regard to the retry delay, what I was asking is why that would correct the problem. If the timer literally fails on every single invocation, wouldn't having a retry limit set to 100 (for example) merely cause 100 failures instead of just one? Also, for our application logic to work correctly, we really don't want any retries. If a failure occurs, we just want the next timer invocation to occur normally so that we can try again then.

Comment by marina vatkina [ 26/Apr/13 ]

Is there anything in the server log prior to the stack trace? It should be quite simple to add a flag not to retry and not to remove timers. But let's first try to understand why do you get into this weird case. Because retry should complete this tx and start a new one after the delay. So if this doesn't work, how would the next delivery succeed?

Comment by jfowler2 [ 26/Apr/13 ]

Yes, we do have errors earlier in the log. These are earlier exceptions in our application code invoked from other EJB timers. For example, one of our EJB timers invokes a separate EJB that in turn makes a web service call to an external system, and this web service can fail due to network connectivity issues, for example. In the EJB that makes the service call, we have a @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) annotation, so I would assume that errors in this EJB would not affect any transactions in progress (correct me if I am wrong).

Can you elaborate on "add a flag not to retry and not to remove timers"? Are you talking about something in our code, or in Glassfish code?

Also, I'm wondering why a retry is necessary to complete the tx? Shouldn't the tx complete on the initial timer invocation, even if it was aborted? Why do subsequent timer invocations keep trying to use the same aborted tx? Why don't they start a new tx?

Comment by marina vatkina [ 26/Apr/13 ]

What probably happens is the RuntimeException from the "separate" EJB invocation is not caught in the EJB timeout code, and it gets propagated outside of the timeout callback, which causes the timeout to fail. If you catch and suppress the exception, the timeout will succeed and the next timeout will come at the next interval.

But that doesn't explain the stack above because a) there should be no transaction yet started by the container and b) if getValidTimerFromDB call fails, the timer won't even be delivered.

"Add a flag" will be an RFE in GF code.

Comment by jfowler2 [ 26/Apr/13 ]

It is not a RuntimeException, it is a regular (checked) exception. We do have a catch(Throwable) clause to catch and log any exceptions. Also, it should never be able to propagate back to the timer, because this is in an MDB (which received a JMS message published by an EJB invoked from the original timer).

I understand that exceptions propagating back to the timer will cause a delivery failure and eventually expunge the timer, but in our case there should be no way for any exception to make it back to the timer (we've designed very carefully to avoid this).

I agree, it doesn't explain the stack trace above. It's as if the transaction is already aborted before the timer ever gets invoked.

Comment by marina vatkina [ 26/Apr/13 ]

Then let's go back to my question above: what does the server.log complain about prior to the stack trace? (It might be not just before the stack trace, but some time earlier).

Comment by jfowler2 [ 26/Apr/13 ]

Going back through the server.log prior to the issue, the only errors I saw were periodic failures of a web service call to connect to the external system (same one I described above).

Comment by marina vatkina [ 26/Apr/13 ]

Can you enable 'jta' logger to FINE level to see the transaction boundaries?

Comment by jfowler2 [ 26/Apr/13 ]

Is it the javax.enterprise.resource.jta logger? I notice that produces LOTS of logging output. I will enable this next time we are performing testing (probably early next week) when the problem is likely to re-occur.

Comment by marina vatkina [ 26/Apr/13 ]

Yes. That one shouldn't produce too much. The "transaction" logger reports XA work - and that does produce a lot of data.

Comment by jfowler2 [ 28/May/13 ]

Marina, the issue did finally occur again. I changed javax.enterprise.resource.jta to FINE. This produced a huge amount of transaction logging. I'm not sure how to sift through this for something meaningful that would be related to this issue. Did you have something in mind I should be looking for?

Comment by marina vatkina [ 28/May/13 ]

Searching through the log you should be able to see why there is still a transaction on this thread: thread id is printed as part of the log message and you can navigate by that thread id up to check if there was a problem completing transaction on that thread. Because the failure is for the container's TimerBean, not your impl. That said, if a thread was returned to the pool with a transaction still associated, we can get into this problem.

HTH.

Comment by jfowler2 [ 29/May/13 ]

I've looked through my logs more. Here is a frequently occurring pattern:

[#|2013-05-28T15:27:52.514+0000|FINE|glassfish3.1.2|javax.enterprise.resource.jta.com.sun.enterprise.transaction|_ThreadID=35;_ThreadName=Thread-2;ClassName=com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate;MethodName=getTransaction;|TM: getTransaction: tx=JavaEETransactionImpl: txId=425924 nonXAResource=null jtsTx=null localTxStatus=1 syncs=[com.sun.ejb.containers.ContainerSynchronization@57724e9, org.eclipse.persistence.transaction.JTASynchronizationListener@51183fcc], tm=com.sun.jts.jta.TransactionManagerImpl@20d32a8|#]

[#|2013-05-28T15:27:52.514+0000|FINE|glassfish3.1.2|javax.enterprise.resource.jta.com.sun.enterprise.transaction|_ThreadID=35;_ThreadName=Thread-2;ClassName=com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate;MethodName=getTransaction;|TM: getTransaction: tx=JavaEETransactionImpl: txId=425924 nonXAResource=null jtsTx=null localTxStatus=1 syncs=[com.sun.ejb.containers.ContainerSynchronization@57724e9, org.eclipse.persistence.transaction.JTASynchronizationListener@51183fcc], tm=com.sun.jts.jta.TransactionManagerImpl@20d32a8|#]

[#|2013-05-28T15:27:52.514+0000|FINE|glassfish3.1.2|javax.enterprise.resource.jta.com.sun.enterprise.transaction|_ThreadID=35;_ThreadName=Thread-2;ClassName=com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate;MethodName=getStatus;|TM: status: MarkedRollback|#]

[#|2013-05-28T15:27:52.514+0000|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=35;_ThreadName=Thread-2;|EJB5184:A system exception occurred during an invocation on EJB TimerService, method: public void com.lmco.energyc2.drms.datasvc.TimerService.transitionBrokerEvents()|#]

[#|2013-05-28T15:27:52.514+0000|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=35;_ThreadName=Thread-2;|javax.ejb.TransactionRolledbackLocalException: Client's transaction aborted
at com.sun.ejb.containers.BaseContainer.useClientTx(BaseContainer.java:4722)
at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:4601)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1914)
at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:4055)
at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1832)
at com.sun.ejb.containers.EJBTimerService.access$100(EJBTimerService.java:108)
at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:2646)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)

#]

It looks like the transaction logging is saying the tx is marked for rollback, but then it tries to invoke my timer and gets the error above. I then see this pattern in the logs repeated with other EJB timers we have, using the same tx (txId=425924).

Comment by marina vatkina [ 29/May/13 ]

Look earlier than that - try to find the point where transaction was started/created on that thread and at which point it was marked for rollback...

Comment by jfowler2 [ 30/May/13 ]

I've searched for the string "txId=425924" in our logs, and the earliest hit I get is an entry that has the same form as the one I posted above, just earlier in time and invoking a different EJB timer.

Regardless of the original reason for tx rollback, I'm wondering why the same thread keeps using the same rollbacked tx to invoke different timers? Once the tx is rollbacked, shouldn't the thread create a new tx for the next timer (or other task) that is has to do?

Comment by marina vatkina [ 30/May/13 ]

It's never rolled back - the EJB container thinks it's a client tx and doesn't complete it. So the actual error that needs to be tracked down - why there is an incomplete tx on the thread (i.e. either some GF component on some path does not rollback tx marked for rollback or your app uses a UserTransaction which escapes the rollback).

That said, GF should be able to cleanup on such error condition. Do you mind filing a bug on that? I think it's the thread pool responsibility, but you can start with 'jts' (for transactions).

Comment by jfowler2 [ 30/May/13 ]

We do not use UserTransactions anywhere in our application.

I'm happy to file a bug, but doesn't this JIRA issue (18942) suffice? Or do you need me to file a separate one?

Comment by marina vatkina [ 30/May/13 ]

To fix this one, we would need to track down why the initial tx wasn't completed...

Comment by pdudits [ 31/May/13 ]

As I understand it, both jfowler2 and I are reporting exactly the same issue:

  1. A transaction associated with a thread of async thread pool gets associated with transaction, that is marked for rollback, and we are unable to find initial cause - in neither case we saw a report about rollback.
  2. Upon timer delivery, timer implementation tries to fetch data from database, reuses the associated TX and fails with Client's transaction aborted
  3. The TX is not rolled back and is keeped associated with the thread, so it is impossible to run any transactional method in it anymore

The issue I tried to report is exactly point 3, careless of what cause the TX rollback in the first place. Async pool cannot be left with transaction associated after invocation is completed, or Timer app should start a new transaction every time, as there is no transaction to join at time of timer delivery anyway.

Comment by marina vatkina [ 31/May/13 ]

Sorry, it took that long to understand it (and the subject line took me away from the actual issue). The timer is just a symptom - if another EJB would be used, it would get into the same issue.

Comment by marina vatkina [ 30/Jul/13 ]

Reset tx in afterExecute:

Sending ejb-container/src/main/java/com/sun/ejb/containers/EjbThreadPoolExecutor.java
Transmitting file data .
Committed revision 62431.

Comment by jfowler2 [ 17/Jan/14 ]

I pulled in your fix to EjbThreadPoolExecutor.java, rebuilt, and have been running with the patched jar. Your afterExecute method logs a warning if the tx is non-null. I see that warning in my logs:

NON-NULL TX IN AFTER_EXECUTE. TX STATUS: 1

That status value maps to javax.transaction.Status.STATUS_MARKED_ROLLBACK. But your afterExecute method only clears the thread tx if the status is STATUS_ROLLBACK, STATUS_COMMITTED, or STATUS_UNKNOWN. In all other cases it calls tm.rollback(). So is this correct behavior in this case? If tm.rollback() is called, will the tx be cleared from the thread?

Comment by marina vatkina [ 17/Jan/14 ]

rollback will do the cleanup. the problem was with an incomplete transaction.

Comment by Ed Bratt [ 25/Apr/14 ]

Please consider as candidate for 4.0.1

Comment by alebor [ 25/Jun/14 ]

We need this patch also for GF 3.1.2.2. When is this available?

Comment by gteichrow [ 12/Mar/16 ]

Alebor: we are having this issue currently (GF 3.1.2.2 Build5/Centos/Postgres). Is there a subsequent build that you aware of that has this fixed? Or a patched jar?

thx for any comments.!

Comment by alebor [ 14/Mar/16 ]

gteichrow: As fas as I know there is no patch for this on GF 3.1.2.2. In my case the problem was related to JMS message redelivery (poison messages) and wrong transactions. Poison messages are JMS delivery deadlocks caused by continuous redelivery of a Message to JMS Queue/Topiq. By not re-throwing runtime exceptions in MDBs, JMS will acknowledge the message and no redelivery will happen. We did not want re-deliveries because it can cause JMS deadlock when something really goes bad during high traffic. Maybe this helps?





[GLASSFISH-20837] Glassfish admin listener thread failure trying to login due to NPE Created: 01/Oct/13  Updated: 11/Mar/16

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: arie_golos Assignee: Anissa Lam
Resolution: Unresolved Votes: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux SUSE 11.3, JDK 1.7.0_25 64 bit, Glassfish4.0
I believe this also happened on my windows 7 machine


Tags: 4_0_1-reviewed, admin-gui

 Description   

[2013-10-01T11:07:19.750-0400] [glassfish 4.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=197 _ThreadName=admin-listener(16)] [timeMillis: 1380640039750] [levelValue: 900] [[
StandardWrapperValve[FacesServlet]: Servlet.service() for servlet FacesServlet threw exception
java.lang.NullPointerException
at org.glassfish.admingui.common.util.GuiUtil.genId(GuiUtil.java:343)
at org.glassfish.admingui.common.handlers.UtilHandlers.encodeId(UtilHandlers.java:1011)
at sun.reflect.GeneratedMethodAccessor684.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.beforeCreate(LayoutComponent.java:348)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.getChild(LayoutComponent.java:288)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:556)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:551)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:590)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:590)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:590)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:255)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:254)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
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.doChainInvoke(StandardPipeline.java:678)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java: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.portunif.PUFilter.handleRead(PUFilter.java:231)
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.portunif.PUFilter.handleRead(PUFilter.java:231)
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:724)



 Comments   
Comment by MisterNibble [ 18/Dec/14 ]

I can confirm the same issue; exception at org.glassfish.admingui.common.util.GuiUtil.genId(GuiUtil.java:343) with the official Glassfish 4.1 release on Ubuntu 12.04 x64 (with all latest updates) and JDK 1.8.0_25-b17 x64. This is after I patched to the latest version of Tyrus (1.9), updated Java Server Faces (javax.faces.jar) to 2.2.8-04 and upgraded nucleus-grizzly-all.jar to 2.3.17 (without which my application is completely unusable).

This error also causes application deployment to fail in Netbeans 8.0.2 because Netbeans requires a usable Admin interface to deploy.

Comment by smillidge-c2b2 [ 20/Dec/14 ]

Can you provide step by step instructions to reproduce?

Comment by MisterNibble [ 21/Dec/14 ]

The error occurs when the Admin console is open in a tab for a few hours. No discernible cause besides that.

Comment by arie_golos [ 23/Dec/14 ]

I can also add to the above MisterNibble comment, that I observed that problem in Chrome today, but when I pasted the same login URL in IE, it worked just fine.

Comment by hink084 [ 11/Mar/16 ]

I can confirm this still happens in Glassfish 4.1. I opened the Admin console, it stood idle for about an hour while I was at lunch, clicked on the "Home" button in the upper left corner of the page, and then this error occurred.

RHEL v6.7 x64, JDK 1.8.74 x64, Glassfish 4.1





[GLASSFISH-21522] NullPointerException during WebDirContext.lookupFromJars Created: 05/Mar/16  Updated: 11/Mar/16

Status: Open
Project: glassfish
Component/s: classloader, deployment, web_container
Affects Version/s: 4.0, 4.1, 4.1.1
Fix Version/s: None

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

Mac OS X El Capitan, JDK 8u74



 Description   

When my application starts, the ServletContextListener is called and starts up several threads to run in the background. Sometimes it works, and sometimes I get NPEs that keep the application from starting correctly:

Caused by: java.lang.NullPointerException
at org.apache.naming.resources.WebDirContext.lookupFromJars(WebDirContext.java:325)
at org.apache.naming.resources.WebDirContext.getAttributes(WebDirContext.java:298)
at org.apache.naming.resources.BaseDirContext.getAttributes(BaseDirContext.java:787)
at org.apache.naming.resources.ProxyDirContext.cacheLoad(ProxyDirContext.java:1533)
at org.apache.naming.resources.ProxyDirContext.cacheLookup(ProxyDirContext.java:1456)
at org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:274)
at org.glassfish.web.loader.WebappClassLoader.findResourceInternalFromRepositories(WebappClassLoader.java:2892)
at org.glassfish.web.loader.WebappClassLoader.findResourceInternal(WebappClassLoader.java:2842)
at org.glassfish.web.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2736)
at org.glassfish.web.loader.WebappClassLoader.findClass(WebappClassLoader.java:1194)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1750)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1633)

After extensive debugging with the sources for 4.1.1, I found that there are two competing methods inside of org.glassfish.loader.WebappClassLoader:

protected boolean openJARs() {
if (started && (jarFiles.length > 0)) {
lastJarAccessed = System.currentTimeMillis();
if (jarFiles[0] == null) {
for (int i = 0; i < jarFiles.length; i++) {
try

{ jarFiles[i] = new JarFile(jarRealFiles[i]); }

catch (IOException e) {
if (logger.isLoggable(Level.FINE))

{ logger.log(Level.FINE, "Failed to open JAR", e); }

for (int j = 0; j < i; j++) {
try

{ jarFiles[j].close(); }

catch (Throwable t)

{ // Ignore }

}
return false;
}
}
}
}
return true;
}

public void closeJARs(boolean force) {
if (jarFiles.length > 0) {
synchronized (jarFiles) {
if (force || (System.currentTimeMillis()
> (lastJarAccessed + 90000))) {
for (int i = 0; i < jarFiles.length; i++) {
try {
if (jarFiles[i] != null)

{ jarFiles[i].close(); jarFiles[i] = null; }

} catch (IOException e) {
if (logger.isLoggable(Level.FINE))

{ logger.log(Level.FINE, "Failed to close JAR", e); }

}
}
}
}
}
}

It turns out that closeJARs() is called from org.apache.catalina.core.StandardContext.start, at the end of the startup routine:

// Close all JARs right away to avoid always opening a peak number
// of files on startup
if (getLoader() instanceof WebappLoader)

{ ((WebappLoader) getLoader()).closeJARs(true); }

The obvious problem is that while closeJARs() is being run in the startup thread, the openJARs() method is also being run by the ServletContextListener as it loads classes during its own initialization routines. Since openJARs() is not synchronized on the jarFiles object like closeJARs() is, both methods run concurrently and overwrite the array items, creating an array with 'holes' in it, where some items are null and some are not. Thus, while doing a lookup in WebDirContext.lookupFromJars, we hit a null array item in the jarFiles array and get an NPE.

It seems like the fix for this should be to simply add a 'synchronized' block in openJARs() after the first 'if' check; however, using jarFiles as the lock for all these operations seems like a poor choice, especially because the addJar() and stop() methods also don't synchronize access and change the object reference for the lock. It seems like a different, final Object should be used instead.



 Comments   
Comment by cplummer [ 11/Mar/16 ]

FYI, I've also engaged the Payara devs on this issue and created an application that can reproduce the issue:

https://github.com/payara/Payara/issues/693





[GLASSFISH-21527] CLONE - External LDAP connection randomly closing Created: 10/Mar/16  Updated: 10/Mar/16

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

Type: Bug Priority: Minor
Reporter: javacentrum Assignee: kumarjayanti
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Solaris
Platform: Sun


Issue Links:
Cloners
clones GLASSFISH-5146 External LDAP connection randomly clo... Resolved
Issuezilla Id: 5,146

 Description   

An external LDAP connection is configured as an external JNDI resource. The
LDAP connection and deployed applications work fine.

If the system is then left idle for an hour or so the LDAP connection gets
closed. I am not sure who is closing the connection but glassfish is not aware
that the connection has been closed. The next time the application is used, it
throws an exception when it tries to use the closed connection.

If an external LDAP server times out the connection, Glassfish should know this
and try to reestablish the connection the next time it is needed.

I get the following exception when I try to use the connection. The only way to
get it back is to restart the app server.

javax.naming.CommunicationException: connection closed [Root exception is
java.io.IOException: connection closed];

Caused by: java.io.IOException: connection closed
at com.sun.jndi.ldap.LdapClient.ensureOpen(LdapClient.java:1558)
at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:504)
at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1944)



 Comments   
Comment by javacentrum [ 10/Mar/16 ]

I have same problem in GF 3.1.2.2 on Sun Solaris 10 and Linux 64bit (kernel 4.2.0-30-generic). No matter if I closing context or not after use. I don't understand why is bug 5146 marked as Resolved/Fixed.





[GLASSFISH-5146] External LDAP connection randomly closing Created: 12/Jun/08  Updated: 10/Mar/16  Resolved: 13/Apr/11

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 9.1peur2
Fix Version/s: 3.1

Type: Bug Priority: Minor
Reporter: chrys Assignee: kumarjayanti
Resolution: Fixed Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Solaris
Platform: Sun


Issue Links:
Cloners
is cloned by GLASSFISH-21527 CLONE - External LDAP connection rand... Open
Issuezilla Id: 5,146

 Description   

An external LDAP connection is configured as an external JNDI resource. The
LDAP connection and deployed applications work fine.

If the system is then left idle for an hour or so the LDAP connection gets
closed. I am not sure who is closing the connection but glassfish is not aware
that the connection has been closed. The next time the application is used, it
throws an exception when it tries to use the closed connection.

If an external LDAP server times out the connection, Glassfish should know this
and try to reestablish the connection the next time it is needed.

I get the following exception when I try to use the connection. The only way to
get it back is to restart the app server.

javax.naming.CommunicationException: connection closed [Root exception is
java.io.IOException: connection closed];

Caused by: java.io.IOException: connection closed
at com.sun.jndi.ldap.LdapClient.ensureOpen(LdapClient.java:1558)
at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:504)
at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1944)



 Comments   
Comment by kumarjayanti [ 12/Jun/08 ]

assigning to self.

Comment by justinwyer [ 24/Nov/08 ]

I experience the exact same problem. After a few hours the connection is closed
and implicit reconnection never occurs. I even created a timer bean that
performs a ldap search every 10 minutes in a futile attempt to keep the
connection alive, no luck.

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 catoaune [ 03/Jun/10 ]
      • Issue 5146 has been confirmed by votes. ***
Comment by kumarjayanti [ 13/Apr/11 ]

Please try with V3.1 .

Comment by ymajoros [ 31/Jan/12 ]

Happened 2 time on my dev machine, after some period of inactivity, using GF 3.1.1

Comment by ymajoros [ 07/Feb/12 ]

No code was changed since 2010, no work on this at any time... How could it be magically resolved in 3.1 on 11/Apr/13?

Can someone reopen?

Comment by rsoika [ 26/Oct/12 ]

I also can confirm that the same problem still occurs on GlassFish 3.1.2 on Win32.
My external ldap resource is connected to a Microsoft Active Directory

Comment by rsoika [ 06/Nov/12 ]

I think the problem is that a client which is using the external ldap context may not close the context or the a namingEnumeration after searching an object.
As a result the ldapContext is still open. I think this szeanrio can happen if a namingEnumeration was not enumerated until its end and was not explicitly closed by the client. A ldapContext.close() will have no effect.
After a while the ldap server will than cut the connection. The next time a client requests a LdapContext object he will receive a closed (from the server side) connection object.

I did not know the implementation details in GlassFish, so maybe that I am wrong.
But eventually GlassFish need to register an UnsolicitedNotificationListener to watch if a pooled LdapContext was closed from the server side? Than GlassFish could throw the context away or try to reconnect it?

http://docs.oracle.com/javase/tutorial/jndi/ldap/close.html

Comment by dersalz [ 24/Apr/13 ]

I'm running Glassfisch 3.1.2.2 on a Win64.
My external ldap resource is connected to a Microsoft Active Directory.

I'm having exactly the same problem. After a while I'm getting a closed connection exception.

Any workarounds or solutions on this?

Comment by rsoika [ 24/Apr/13 ]

Can someone please reopen this bug report?

Comment by javacentrum [ 10/Mar/16 ]

I have same problem in GF 3.1.2.2 on Sun Solaris 10 and Linux 64bit (kernel 4.2.0-30-generic). No matter if I closing context or not after use. I don't understand why is this bug marked as Resolved/Fixed.





[GLASSFISH-21519] High cpu load on RMI call Created: 01/Mar/16  Updated: 09/Mar/16

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

Type: Bug Priority: Major
Reporter: ruVooDoo Assignee: Scott Oaks
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 1 week
Time Spent: Not Specified
Original Estimate: 1 week
Environment:

1.7.0_25-b15
Red Hat Enterprise Linux Server release 6.5
4 core&32 Gb Ram Virtual Machine


Tags: rmi, webservice

 Description   

We have a high load (>3M requests per day) application, that receives request via SOAP and then call an external system thought RMI. So, basically its a proxy-client, thats get request and return answer from external system to client in a sync way. We call it facade\proxy architecture. So, our facade service receive SOAP request, than call over RMI our proxy service, which actually perform SOAP call to external system. All process is synchronous.
Our problem is, that any single request (4-5 sec in duration) generate a 100% CPU load on VM when we using RMI interaction between modules. When we provide production load on APP our VM just hung due very high CPU load.

I've dumped threads when I generate a single test call, and I see that one thread running on this:
"http-listener-1(32)" daemon prio=10 tid=0x00007f27e831f000 nid=0x12be runnable [0x00007f27c32e8000]
java.lang.Thread.State: RUNNABLE
at java.util.zip.Inflater.inflateBytes(Native Method)
at java.util.zip.Inflater.inflate(Inflater.java:256)

  • locked <0x000000076e17ea50> (a java.util.zip.ZStreamRef)
    at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
    at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:122)
    at org.apache.felix.framework.util.WeakZipFileFactory$WeakZipFile$WeakZipInputStream.read(WeakZipFileFactory.java:669)
    at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:337)
    at java.io.DataInputStream.readUTF(DataInputStream.java:589)
    at java.io.DataInputStream.readUTF(DataInputStream.java:564)
    at com.sun.xml.bind.v2.bytecode.ClassTailor.tailor(ClassTailor.java:146)
    at com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector.tailor(AccessorInjector.java:122)
    at com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector.prepare(AccessorInjector.java:83)
    at com.sun.xml.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:179)
    at com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection.optimize(Accessor.java:286)
    at com.sun.xml.bind.v2.runtime.property.SingleReferenceNodeProperty.<init>(SingleReferenceNodeProperty.java:82)
    at sun.reflect.GeneratedConstructorAccessor223.newInstance(Unknown Source)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

Could you please advise us, what we need to do, to prevent this issue? We switch back to pure HTTP (exclude RMI) interconnect between apps and this work just fine, but we need to use RMI...



 Comments   
Comment by ruVooDoo [ 09/Mar/16 ]

Hello?





[GLASSFISH-21526] Access Logs are not being pruned in accordance with Max File Count Created: 07/Mar/16  Updated: 07/Mar/16

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

Type: Bug Priority: Minor
Reporter: gzkramer Assignee: Joe Di Pol
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

SLES 11.3



 Description   

While using Glassfish with rotating access logs, I ran into an issue where I ran out of disk space on a VM because the excess access logs (as defined by the Max File Count and/or 'com.sun.enterprise.server.logging.max_history_files") were not being pruned.

After some investigation, it seemed as though PEAccessLogValve.java in the web-glue module was supposedly responsible for pruning older access logs. More specifically, the open() method contained the logic for deleting the excess access logs. Unfortunately there seemed to be at least one issue (possibly more) within open()'s logic. In the second conditional which contains the logic for pruning access logs, there are extraneous conditions which can cause the access log deletion to be unreachable. The conditional says if (rotatable && !addDateTimeStampToFirstAccessLogFile && !firstAccessLogFile) then you can begin the logic for checking if an access log should be deleted. Because of the "!addDateTimeStampToFirstAccessLogFile" condition, if you are timestamping your first access log you can never delete old access logs.






[GLASSFISH-21224] Jenkins does not start after update from GlassFish 4.0 to 4.1 Created: 08/Oct/14  Updated: 07/Mar/16

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

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

OS: Debian GNU/Linux 7.6 (i386)
JDK: openjdk-7-* packages from Debian

OpenJDK Runtime Environment (IcedTea 2.5.1) (7u65-2.5.1-5~deb7u1)
OpenJDK Client VM (build 24.65-b04, mixed mode, sharing)



 Description   

Today I updated my installation of GlassFish 4.0 to 4.1 with the Update Tool. After that Jenkins (I redeployed the latest version 1.583) has not been starting at all. The GlassFish server.log contains the following error:

[2014-10-08T15:44:03.852+0900] [glassfish 4.1] [SEVERE] [] [hudson.util.BootFailure] [tid: _ThreadID=223 _ThreadName=Jenkins initialization thread] [timeMillis: 1412750643852] [levelValue: 1000] [[
Failed to initialize Jenkins
hudson.util.HudsonFailedToLoad: java.lang.NullPointerException
at hudson.WebAppMain$3.run(WebAppMain.java:234)
Caused by: java.lang.NullPointerException
at org.glassfish.web.loader.WebappClassLoader.findResourceInternalFromJars(WebappClassLoader.java:2976)
at org.glassfish.web.loader.WebappClassLoader.findResourceInternal(WebappClassLoader.java:2846)
at org.glassfish.web.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2736)
at org.glassfish.web.loader.WebappClassLoader.findClass(WebappClassLoader.java:1194)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1750)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1633)
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2570)
at java.lang.Class.getDeclaredMethods(Class.java:1855)
at org.jvnet.hudson.annotation_indexer.Index$2$1.fetch(Index.java:102)
at org.jvnet.hudson.annotation_indexer.Index$2$1.hasNext(Index.java:72)
at org.jenkinsci.bytecode.TransformationSpec.loadRule(TransformationSpec.java:63)
at org.jenkinsci.bytecode.Transformer.loadRules(Transformer.java:40)
at org.jenkinsci.bytecode.Transformer.loadRules(Transformer.java:24)
at hudson.PluginManager.<init>(PluginManager.java:190)
at hudson.LocalPluginManager.<init>(LocalPluginManager.java:47)
at jenkins.model.Jenkins.<init>(Jenkins.java:787)
at hudson.model.Hudson.<init>(Hudson.java:82)
at hudson.model.Hudson.<init>(Hudson.java:78)
at hudson.WebAppMain$3.run(WebAppMain.java:222)
]]

It could be an indication of a potential bug in Jenkins but the NPE happens in org.glassfish.web.loader.WebappClassLoader.findResourceInternalFromJa
rs and it has not been a problem with GlassFish 4.0, it may be possibly a regression bug in GlassFish 4.1.



 Comments   
Comment by kazssym [ 13/Oct/14 ]

To reproduce the problem, I downloaded glassfish-4.1.jar and made a fresh instance on another machine. On that machine, I could deploy jenkins.jar and the Jenkins appears to run correctly. So this problem may be due to my upgraded environment.

I will recheck my deployed instance again.

Comment by kazssym [ 13/Oct/14 ]

I tried in a simpler installation with Jenkins as the only application in the admin server. I had no problem using the exactly same ~/.jenkins workspace. I cannot still resolve the issue yet, but I found this in the server.log:

[2014-10-13T16:06:49.439+0900] [glassfish 4.1] [SEVERE] [] [hudson.util.BootFail
ure] [tid: _ThreadID=123 _ThreadName=Jenkins initialization thread] [timeMillis:
 1413184009439] [levelValue: 1000] [[
  Failed to initialize Jenkins
hudson.util.HudsonFailedToLoad: java.lang.IllegalStateException: second instance
        at hudson.WebAppMain$3.run(WebAppMain.java:234)
Caused by: java.lang.IllegalStateException: second instance
        at jenkins.model.Jenkins.<init>(Jenkins.java:741)
        at hudson.model.Hudson.<init>(Hudson.java:82)
        at hudson.model.Hudson.<init>(Hudson.java:78)
        at hudson.WebAppMain$3.run(WebAppMain.java:222)
]]

This may indicates Jenkins' initialization was run multiple times.

Comment by kazssym [ 13/Oct/14 ]

I finally found that Jenkins fails to start on a cluster instance. I could start it on a standalone instance if I enabled Jenkins on that instance only.

Comment by petrjanata [ 07/Mar/16 ]

Hi, I have also experienced NPE from WebappClassLoader.findResourceInternalFromJars.
It is hard to provide a reproducible test case, because it is triggered by race condition.
I presume that the problem is caused by incorrect synchronization around instance variable JarFile[] jarFiles of WebappClassLoader.

I have seen during debugging that this array initially contains all jar files from the application WAR.

[ jar1, jar2, jar3 ]

When the NPE happens, the array has the same length, but from some index all elements are null.

[ jar1, null, null ]

Method closeJARs synchronizes on jarFiles but does not make a defensive copy of the reference. Other methods replace instance variable jarFiles with a new array. The closeJARs than happily nullifies the new array from some index.
Even worse, the reference to this array is leaked to other classes (WebDirContext) that do not use any synchronization at all.

There are probably some other problems too. I will try to provide patch with proper synchronization next week.





[GLASSFISH-21484] Observed CDI event anotated with TransactionPhase.AFTER_SUCCESS throws IllegalStateException: Transaction is not active in the current thread Created: 20/Jan/16  Updated: 07/Mar/16

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

Type: Bug Priority: Major
Reporter: fmachado Assignee: Joe Di Pol
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I'm not sure if this is an issue that should be fixed on Glassfish or Weld side but, as I was not able to replicate it with the latest Wildfly version, I'm reporting here first.

From a JMS message that was received asynchronously, I'm calling a Stateless LocalBean that, at some point, will fire a CDI event. With another SLB that I'm using as the event handler, a method annotated with @Observes(during = TransactionPhase.AFTER_SUCCESS) will fail and throw java.lang.IllegalStateException: Transaction is not active in the current thread if this method tries to access any EJB (even if it is annotated with @TransactionManagement(TransactionManagementType.BEAN)).

[2016-01-20T03:57:41.238+0100] [glassfish 4.1] [WARNING] [] [javax.enterprise.ejb.container] [tid: _ThreadID=101 _ThreadName=p: thread-pool-1; w: 1] [timeMillis: 1453258661238] [levelValue: 900] [[
  Exception during Singleton ResourceHandler processing
java.lang.IllegalStateException: Transaction is not active in the current thread.
	at com.sun.enterprise.transaction.JavaEETransactionImpl.checkTransationActive(JavaEETransactionImpl.java:722)
	at com.sun.enterprise.transaction.JavaEETransactionImpl.registerSynchronization(JavaEETransactionImpl.java:692)
	at com.sun.ejb.containers.SimpleEjbResourceHandlerImpl.checkTransaction(SimpleEjbResourceHandlerImpl.java:120)
	at com.sun.ejb.containers.SimpleEjbResourceHandlerImpl.<init>(SimpleEjbResourceHandlerImpl.java:69)
	at com.sun.ejb.containers.SimpleEjbResourceHandlerImpl.getResourceHandler(SimpleEjbResourceHandlerImpl.java:88)
	at com.sun.ejb.containers.AbstractSingletonContainer.setResourceHandler(AbstractSingletonContainer.java:182)
	at com.sun.ejb.containers.AbstractSingletonContainer.createEjbInvocation(AbstractSingletonContainer.java:171)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:192)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
	at com.sun.proxy.$Proxy185.isEnabled(Unknown Source)
	at com.fmachado.jeetest.ejb.__EJB31_Generated__MySingleton__Intf____Bean__.isEnabled(Unknown Source)
	at com.fmachado.jeetest.ejb.event.MyBusinessEventHandler.handleEvent(MyBusinessEventHandler.java:27)
	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: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.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 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:62)
	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: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.$Proxy183.handleEvent(Unknown Source)
	at com.fmachado.jeetest.ejb.event.__EJB31_Generated__MyBusinessEventHandler__Intf____Bean__.handleEvent(Unknown Source)
	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.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:414)
	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127)
	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
	at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65)
	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
	at com.fmachado.jeetest.ejb.event.MyBusinessEventHandler$Proxy$_$$_Weld$EnterpriseProxy$.handleEvent(Unknown Source)
	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.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:90)
	at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:271)
	at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:258)
	at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:237)
	at org.jboss.weld.event.DeferredEventNotification$1.execute(DeferredEventNotification.java:63)
	at org.jboss.weld.event.DeferredEventNotification$RunInRequest.run(DeferredEventNotification.java:100)
	at org.jboss.weld.event.DeferredEventNotification.run(DeferredEventNotification.java:57)
	at org.jboss.weld.event.TransactionSynchronizedRunnable.afterCompletion(TransactionSynchronizedRunnable.java:54)
	at com.sun.jts.jta.SynchronizationImpl.after_completion(SynchronizationImpl.java:156)
	at com.sun.jts.CosTransactions.RegisteredSyncs.distributeAfter(RegisteredSyncs.java:191)
	at com.sun.jts.CosTransactions.TopCoordinator.afterCompletion(TopCoordinator.java:2589)
	at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:414)
	at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:231)
	at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:622)
	at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:331)
	at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.commitDistributedTransaction(JavaEETransactionManagerJTSDelegate.java:174)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:859)
	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:4566)
	at org.glassfish.ejb.mdb.MessageBeanContainer.afterMessageDeliveryInternal(MessageBeanContainer.java:1326)
	at org.glassfish.ejb.mdb.MessageBeanContainer.afterMessageDelivery(MessageBeanContainer.java:1301)
	at org.glassfish.ejb.mdb.MessageBeanListenerImpl.afterMessageDelivery(MessageBeanListenerImpl.java:86)
	at com.sun.enterprise.connectors.inbound.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:143)
	at com.sun.proxy.$Proxy258.afterDelivery(Unknown Source)
	at com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:361)
	at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:107)
	at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
	at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
]]

I'm attaching a PoC that can be easily built and deployed.



 Comments   
Comment by fmachado [ 20/Jan/16 ]

I uploaded the PoC and complete server log files ( from both 4.1 and 4.1.1 versions) to my Dropbox account:
https://www.dropbox.com/sh/abpmiiriqmc50sp/AAAMvvbeM__xV5yOrl85WSOja

Deploy, open http://localhost:8080/jeetest-web/MyServlet?payload=somepayload and check your server.log file.

Thanks for your help guys!

Comment by gimlet [ 01/Feb/16 ]

Hi! I had explored that issue. Updating of Weld to version 2.2.16-Final solves it.

Comment by rhadoo_io [ 07/Mar/16 ]

i get a similar exception:

[2016-03-07T13:14:41.224+0000] [glassfish 4.1] [WARNING] [] [javax.enterprise.ejb.container] [tid: _ThreadID=170 _ThreadName=__ejb-thread-pool1] [timeMillis: 1457356481224] [levelValue: 900] [[
Exception during Singleton ResourceHandler processing
java.lang.IllegalStateException: Transaction is not active in the current thread.
at com.sun.enterprise.transaction.JavaEETransactionImpl.checkTransationActive(JavaEETransactionImpl.java:722)
at com.sun.enterprise.transaction.JavaEETransactionImpl.registerSynchronization(JavaEETransactionImpl.java:692)
at com.sun.ejb.containers.SimpleEjbResourceHandlerImpl.checkTransaction(SimpleEjbResourceHandlerImpl.java:120)
at com.sun.ejb.containers.SimpleEjbResourceHandlerImpl.getResourceList(SimpleEjbResourceHandlerImpl.java:96)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.getExistingResourceList(JavaEETransactionManagerSimplified.java:610)
at com.sun.enterprise.resource.pool.PoolManagerImpl.handleLazilyAssociatedConnectionPools(PoolManagerImpl.java:606)
at com.sun.enterprise.resource.pool.PoolManagerImpl.postInvoke(PoolManagerImpl.java:596)
at com.sun.enterprise.resource.pool.PoolManagerImpl.afterPostInvoke(PoolManagerImpl.java:575)
at org.glassfish.api.invocation.InvocationManagerImpl.postInvoke(InvocationManagerImpl.java:244)
at org.glassfish.jms.injection.AbstractJMSContextManager.cleanup(AbstractJMSContextManager.java:141)
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.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:98)
at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:91)
at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:131)
at org.glassfish.jms.injection.JMSCDIExtension$LocalPassivationCapableBean.destroy(JMSCDIExtension.java:216)
at org.jboss.weld.util.bean.IsolatedForwardingBean.destroy(IsolatedForwardingBean.java:50)
at org.glassfish.cdi.transaction.TransactionScopedBean.afterCompletion(TransactionScopedBean.java:112)
at com.sun.jts.jta.SynchronizationImpl.after_completion(SynchronizationImpl.java:146)
at com.sun.jts.CosTransactions.RegisteredSyncs.distributeAfter(RegisteredSyncs.java:191)
at com.sun.jts.CosTransactions.TopCoordinator.afterCompletion(TopCoordinator.java:2589)
at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:414)
at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:231)
at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:622)
at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:331)
at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.commitDistributedTransaction(JavaEETransactionManagerJTSDelegate.java:175)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:859)
at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:723)
at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:519)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4566)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2074)
at com.sun.ejb.containers.EjbAsyncTask.call(EjbAsyncTask.java:114)
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)

but upgrading weld doesn't seem to help:
asadmin osgi lb | grep 'Weld OSGi'
29|Resolved | 1|Weld OSGi Bundle (2.2.16.Final)





[GLASSFISH-21525] glassfish weld services NullPointerException Created: 07/Mar/16  Updated: 07/Mar/16

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

Type: Bug Priority: Major
Reporter: sajara13 Assignee: Joe Di Pol
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

SunOS 5.11 11.2 sun4v sparc SUNW, SPARC-Enterprise-T5220
Glassfish 4.1.1, cluster with 2 instances



 Description   

One instance of my cluster does not want to be in running state. When i try to start it the exception is thrown. I cleared OSGI cache and genereted/ files in my domain.
Is it beacause EJB container wants to create MDB when Weld is not yet initialized?
When i look into JCDIServiceImpl code I see the beanManager instance may be null.
Is it possible to initalize Weld first before EJB container starts createing MDB?
Why is that? How to overcome this problem?

An exception when starting one of the instances:

[javax.enterprise.system.container.ejb.mdb.org.glassfish.ejb.mdb] [tid: _ThreadID=194 _ThreadName=__ejb-thread-pool1] [timeMillis: 457104178570] [levelValue: 1000] [[  java.lang.reflect.InvocationTargetExceptionjava.lang.NullPointerException
        at org.glassfish.weld.services.JCDIServiceImpl._createJCDIInjectionContext(JCDIServiceImpl.java:195)
        at org.glassfish.weld.services.JCDIServiceImpl.createJCDIInjectionContext(JCDIServiceImpl.java:179)
        at com.sun.ejb.containers.BaseContainer.createEjbInstanceAndContext(BaseContainer.java:1696)
        at org.glassfish.ejb.mdb.MessageBeanContainer.createMessageDrivenEJB(MessageBeanContainer.java:789)
        at org.glassfish.ejb.mdb.MessageBeanContainer.access$100(MessageBeanContainer.java:119)
        at org.glassfish.ejb.mdb.MessageBeanContainer$MessageBeanContextFactory.create(MessageBeanContainer.java:547)
        at com.sun.ejb.containers.util.pool.NonBlockingPool.preload(NonBlockingPool.java:337)
        at com.sun.ejb.containers.util.pool.NonBlockingPool.doResize(NonBlockingPool.java:585)
        at com.sun.ejb.containers.util.pool.NonBlockingPool$IdleBeanWork.run(NonBlockingPool.java:683)
        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)


My MDB code is like this:
JmsReceiver.java

@TransactionManagement(TransactionManagementType.BEAN)
public class JmsReceiver implements MessageListener {

	@Inject
 	private Logger l;

	@Inject
 	private Service service;

	
	@Override
	public void onMessage(Message message) {
            logger.("Begin processing {}",message)
            //some stuff here....
}



 Comments   
Comment by sajar