[GLASSFISH-20479] JPA 2.1: select where mystr<>'' also returns zero-length strings Created: 06/May/13  Updated: 09/May/13  Resolved: 09/May/13

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

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

JDK 1.7.0_21, Glassfish 4.0_b88 (2013-05-05), JavaDB or MySQL


Tags: glassfish4, jpa, persistence

 Description   

Creating a JPA query searching for strings that are not empty - example:

select e from NewEntity e where e.name<>''

This also returns the empty strings where e.name = '' which is incorrect. This does not happen with earlier JPA/Eclipselink versions.

I can provide a test case if necessary.



 Comments   
Comment by Peter Salomonsen [ 07/May/13 ]

Simple test case:

EntityManager em = Persistence.createEntityManagerFactory("JPA21testPU").createEntityManager();
em.getTransaction().begin();
NewEntity ent = new NewEntity();
ent.setName("Test");
em.persist(ent);
ent = new NewEntity();
ent.setName("");
em.persist(ent);
em.getTransaction().commit();
List<NewEntity> neList = em.createQuery("select e from NewEntity e where e.name<>''").getResultList();
if(neList.size()!=1)

{ System.out.println("BUG: Should only return one entity - but returned: "+neList.size()); }

for(NewEntity ne : neList)

{ System.out.println(ne.toString()+" name = '"+ne.getName()+"'"); }

em.close();

Comment by Mitesh Meswani [ 09/May/13 ]

Fixed with integration of EclipseLink 2.5.0-RC2





[GLASSFISH-20478] PSR:FUNC Unable to deploy WebServices application: Illegal Class loader binding Created: 06/May/13  Updated: 16/May/13  Resolved: 08/May/13

Status: Closed
Project: glassfish
Component/s: deployment
Affects Version/s: 4.0_b87_RC3
Fix Version/s: 4.0_b88_RC4

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

Tags: 4_0-approved, PSRBUG, VIKKUMAR

 Description   

Starting in build 87, tests to deploy SPECjEnterprise fail; the WS stack is unable to create a DirContext:

[2013-05-06T09:21:33.964-0700] [glassfish 4.0] [WARNING] [AS-WSJSR109IMPL-00082] [javax.enterprise.webservices] [tid: _ThreadID=32 _ThreadName=admin-listener(1)] [timeMillis: 1367857293964] [levelValue: 900] [[
Deployment failed
java.lang.IllegalStateException: Illegal class loader binding
at org.apache.naming.resources.DirContextURLStreamHandler.get(DirContextURLStreamHandler.java:231)
at org.apache.naming.resources.DirContextURLStreamHandler.openConnection(DirContextURLStreamHandler.java:131)
at org.apache.naming.resources.DirContextURLStreamHandlerService$DelegatingDirContextURLStreamHandler.openConnection(DirContextURLStreamHandlerService.java:76)
at org.apache.naming.resources.DirContextURLStreamHandlerService.openConnection(DirContextURLStreamHandlerService.java:86)
at org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:271)
at java.net.URL.openConnection(URL.java:971)
at java.net.URL.openStream(URL.java:1037)
at com.sun.xml.ws.api.server.SDDocumentSource$1.read(SDDocumentSource.java:118)
at com.sun.xml.ws.server.SDDocumentImpl.create(SDDocumentImpl.java:124)
at com.sun.xml.ws.server.EndpointFactory.categoriseMetadata(EndpointFactory.java:669)
at com.sun.xml.ws.server.EndpointFactory.create(EndpointFactory.java:244)
at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:158)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:577)
...

Instructions on running deployment of SPECj can be found at http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/Running+the+startup+benchmark



 Comments   
Comment by Hong Zhang [ 06/May/13 ]

As the stack trace is from webservices code, assign to webservices team for evaluation.

Comment by Martin Grebac [ 06/May/13 ]

Lukasi would you please evaluate? Thanks.

Comment by Lukas Jungmann [ 07/May/13 ]

During deployment, ws code in servletcontextlistener calls servletContext.getResource(...). This call returns url 'jndi:/server/supplier/WEB-INF/wsdl/BuyerService/SupplierDelivery.wsdl'. The wsdl contains relative import which is later resolved to 'jndi:/server/supplier/WEB-INF/wsdl/BuyerService/DeliveryMessage.xsd' but when openStream() is called on this URL, java.lang.IllegalStateException: Illegal class loader binding is thrown.
On the other hand calling openStream() method on 'jndi:/server/supplier/WEB-INF/wsdl/BuyerService/SupplierDelivery.wsdl' is successful.

It looks like schema imported (DeliveryMessage.xsd) from the wsdl (SupplierDelivery.wsdl) is not being bound to JNDI during deployment/before application startup any more.

This used to work properly till 4.0-b86 but something what causes this issue has changed between revisions 61613 (b86) - 61760 (b87)

Full stacktrace is:

[2013-05-07T15:08:38.892+0200] [glassfish 4.0] [SEVERE] [AS-WSJSR109IMPL-00014] [javax.enterprise.webservices] [tid: _ThreadID=40 _ThreadName=admin-listener(1)] [timeMillis: 1367932118892] [levelValue: 1000] [[
  Error parsing WSDL {0}.
java.lang.IllegalStateException: Illegal class loader binding
	at org.apache.naming.resources.DirContextURLStreamHandler.get(DirContextURLStreamHandler.java:231)
	at org.apache.naming.resources.DirContextURLStreamHandler.openConnection(DirContextURLStreamHandler.java:131)
	at org.apache.naming.resources.DirContextURLStreamHandlerService$DelegatingDirContextURLStreamHandler.openConnection(DirContextURLStreamHandlerService.java:76)
	at org.apache.naming.resources.DirContextURLStreamHandlerService.openConnection(DirContextURLStreamHandlerService.java:86)
	at org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:271)
	at java.net.URL.openConnection(URL.java:971)
	at java.net.URL.openStream(URL.java:1037)
	at org.glassfish.webservices.WsUtil.parseRelativeImports(WsUtil.java:372)
	at org.glassfish.webservices.WsUtil.getWsdlsAndSchemas(WsUtil.java:1735)
	at org.glassfish.webservices.WsUtil.addFileAndDecendents(WsUtil.java:1771)
	at org.glassfish.webservices.WsUtil.getWsdlsAndSchemas(WsUtil.java:1744)
	at org.glassfish.webservices.WsUtil.getWsdlsAndSchemas(WsUtil.java:1709)
	at org.glassfish.webservices.WSServletContextListener.registerEndpoint(WSServletContextListener.java:145)
	at org.glassfish.webservices.WSServletContextListener.contextInitialized(WSServletContextListener.java:104)
	at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:5362)
	at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:743)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:5898)
	at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
	at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2278)
	at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1924)
	at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
	at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
	at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
	at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
	at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:356)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
	at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:233)
	at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:255)
	at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:133)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
	at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java: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.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.service(ContainerMapper.java:246)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
	at java.lang.Thread.run(Thread.java:722)
]]
Comment by Lukas Jungmann [ 07/May/13 ]

There has been no change in web services area which would cause this issue. Tom/Hong, can you assign this to the right person, please? See my evaluation in a previous comment.
Thanks!

Comment by Tom Mueller [ 07/May/13 ]

After performing a binary search on SVN revisions to the GlassFish trunk/main source tree, this test failure shows up first with revision 61689:

r61689 | jjsnyder83 | 2013-04-26 15:11:43 -0500 (Fri, 26 Apr 2013) | 1 line

A war that is not cdi-enabled can't access an ejb that is cdi-enabled. https://java.net/jira/browse/GLASSFISH-19251

Assigning to JJ to investigate. It isn't clear at all why this change would impact this test.

Comment by jjsnyder83 [ 07/May/13 ]

Please provide me with an application and source code so I can investigate.

Comment by Tom Mueller [ 07/May/13 ]

Instructions for running the benchmark that reproduces this problem are at the URL in the description.
The problem is seen with the devx_jee benchmark, i.e., ./run devx_jee.gf (once that file is edited to point to your install).

Comment by jjsnyder83 [ 08/May/13 ]

I know the issue and am testing a fix.

Comment by jjsnyder83 [ 08/May/13 ]

The fix must not break the fix that was put in place for https://java.net/jira/browse/GLASSFISH-18152

Comment by jjsnyder83 [ 08/May/13 ]

Fixed on trunk, revision: 61897

Comment by jjsnyder83 [ 08/May/13 ]

Updated on trunk, revision: 61898

Comment by jjsnyder83 [ 08/May/13 ]

What is the impact on the customer of the bug?
CDI causing web services to not work. Specific case is the SpecJ benchmark in this bug.

How likely is it that a customer will see the bug and how serious is the bug?
Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
What CTS failures are caused by this bug?
very

What is the cost/risk of fixing the bug?
low

How risky is the fix? How much work is the fix? Is the fix complicated?
low...Only a few lines of code changed.

Is there an impact on documentation or message strings?
No

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
The SpecJ benchmark in this issue.

Which is the targeted build of 4.0 for this fix?
4.0_b88_RC4

If this an integration of a new version of a component from another project,
what are the changes that are being brought in? This might be list of
Jira issues from that project or a list of revision messages.
N/A

Comment by Tom Mueller [ 08/May/13 ]

Approved for 4.0.

Comment by jjsnyder83 [ 08/May/13 ]

Updated on 4.0
Committed revision 61902.

Comment by Scott Oaks [ 16/May/13 ]

Able to deploy on build 89.





[GLASSFISH-20472] GMBAL 4.0.0-b001 integration Created: 06/May/13  Updated: 07/May/13  Resolved: 07/May/13

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 4.0
Fix Version/s: 4.0_b88_RC4

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

Tags: 4_0-approved

 Description   

GMBAL 4.0.0-b001 fixes Bug#16680733.

  • What is the impact on the customer of the bug?

Error Running AppClient with Remote Applications when Security Manager is ON.

  • How likely is it that a customer will see the bug and how serious is the bug?

Always.

  • Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?

Not a regression.

  • What CTS failures are caused by this bug?

compat12/ejb/sec tests are failing, when Security Manager is ON.

  • What is the cost/risk of fixing the bug?
    How risky is the fix? How much work is the fix? Is the fix complicated?

Low Risk. Fix is isolated.

  • Is there an impact on documentation or message strings?

No.

  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

Run Remote App tests with Security Manager.

  • Which is the targeted build of 4.0 for this fix?

B88.

  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.

The fix is done in GMBAL.

Proposed POM change: (maven release in progress)
Index: nucleus/pom.xml
===================================================================
— nucleus/pom.xml (revision 61833)
+++ nucleus/pom.xml (working copy)
@@ -126,7 +126,7 @@
<hk2.plugin.version>2.1.92</hk2.plugin.version>
<trilead-ssh2.version>build212-hudson-6</trilead-ssh2.version>
<pfl.version>4.0.0-b003</pfl.version>

  • <gmbal.version>3.2.0-b003</gmbal.version>
    + <gmbal.version>4.0.0-b001-SNAPSHOT</gmbal.version>
    <woodstox.version>4.1.2</woodstox.version>
    <antlr.version>2.7.6</antlr.version>
    <jersey.version>2.0-rc2</jersey.version>
    ================================================================

Code change is already done in GMBAL master:

https://java.net/projects/gmbal/sources/master/revision/287
https://java.net/projects/gmbal/sources/master/revision/288

QL tests PASS. compat12/ejb/sec CTS7 tests PASS.



 Comments   
Comment by Tom Mueller [ 06/May/13 ]

Approved for 4.0. Please be sure to check in to both the 4.0 branch and the trunk.

Comment by Harshad Vilekar [ 07/May/13 ]

Committed the fix to GlassFish trunk: svn revision #61862

Comment by Harshad Vilekar [ 07/May/13 ]

Committed the fix to GlassFish 4.0: svn revision #61871.





[GLASSFISH-20466] Standard JMS Activation Configs Don't Work Created: 05/May/13  Updated: 07/May/13  Resolved: 06/May/13

Status: Closed
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b87_RC3
Fix Version/s: 4.0_b88_RC4

Type: Bug Priority: Blocker
Reporter: reza_rahman Assignee: David Zhao
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to MQ-298 If destinationLookup is set, destinat... Resolved

 Description   

@MessageDriven(activationConfig = {
@ActivationConfigProperty(
propertyName = "destinationLookup",
propertyValue = "java:global/jms/HandlingEventRegistrationAttemptQueue")
})

Does not trigger the MDB while old-style non-standard MDBs are triggered correctly:

@MessageDriven(mappedName = "java:global/jms/HandlingEventRegistrationAttemptQueue")

Please advise. Unless I am doing something wrong, this is a serious issue...



 Comments   
Comment by David Zhao [ 06/May/13 ]

Reza,

You need providing one more activation property "destinationType".

@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue")

Comment by reza_rahman [ 07/May/13 ]

That works perfectly - thank you very much for taking a look at this promptly.

Comment by Nigel Deakin [ 07/May/13 ]

...but this is a good feature to add. Logged as MQ-298





[GLASSFISH-20461] embedded glassfish bundles wrong version of CDI-api Created: 03/May/13  Updated: 06/May/13  Resolved: 06/May/13

Status: Closed
Project: glassfish
Component/s: embedded
Affects Version/s: None
Fix Version/s: 4.0_b88_RC4

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

Tags: 4_0-approved

 Description   

An old version of the cdi-api is being included in embedded-glassfish causing java.lang.NoSuchMethodError at app deployment time.

What is the impact on the customer of the bug?

Without the fix users cannot deploy to embedded glassfish

What is the cost/risk of fixing the bug?

Very low, changing from cdi-api 1.1PRD to 1.1 in appserver/web

Is there an impact on documentation or message strings?

No.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

quicklook, cdi tck

Which is the targeted build of 4.0 for this fix?

88.

If this an integration of a new version of a component from another project,
what are the changes that are being brought in? This might be list of
Jira issues from that project or a list of revision messages.

N/A.



 Comments   
Comment by Tom Mueller [ 03/May/13 ]

Approved for 4.0.

Comment by mtaube [ 06/May/13 ]

Committed to trunk and branch (61850).





[GLASSFISH-20456] Eclipselink 2.5 fails to parse JPQL query involving embedded maps Created: 03/May/13  Updated: 09/May/13  Resolved: 09/May/13

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

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

JDK 1.7.0_21, Windows 7 64bit



 Description   

A bug in EclipseLink's Hermes parser is causing deployment error on specific named queries that are JPA 2.0 compatible and worked on 3.1.2. The bug was originally described in GLASSFISH-19316, and EclipseLink Bug 394033. I reopened the EclipseLink bug, but have no authorizations to reopen Glassfish issue.

To reproduce the issue, try to deploy project attached to original issue



 Comments   
Comment by Tom Mueller [ 07/May/13 ]

Just tried this on the latest build of 4.0 branch and this still failed:

$ asadmin deploy ~/Downloads/jpql-map-1.0-SNAPSHOT.jar
remote failure: Error occurred during deployment: Exception while deploying the app [jpql-map-1.0-SNAPSHOT] : Exception [EclipseLink-28019] (Eclipse Persistence Services - 2.5.0.v20130425-368d603): org.eclipse.persistence.exceptions.EntityManagerSetupException
Exception Description: Deployment of PersistenceUnit [testpu] failed. Close all factories for this PersistenceUnit.
Internal Exception: Exception [EclipseLink-0] (Eclipse Persistence Services - 2.5.0.v20130425-368d603): org.eclipse.persistence.exceptions.JPQLException
Exception Description: Internal problem encountered while compiling [select c from Charger c join c.locationAttributes cc where key(cc) = :attrKey and value(cc) = :attrValue].
Internal Exception: java.lang.NullPointerException. Please see server.log for more details.
Command deploy failed.

The exception report in the server.log file is:

[2013-05-07T09:54:43.547-0500] [glassfish 4.0] [SEVERE] [] [org.eclipse.persistence.session.file:/Users/tomuell/test/glassfish/glassfish4/glassfish/domains/domain1/applications/jpql-map-1.0-SNAPSHOT/_testpu.ejb] [tid: _ThreadID=34 _ThreadName=admin-listener(2)] [timeMillis: 1367938483547] [levelValue: 1000] [[

Local Exception Stack:
Exception [EclipseLink-0] (Eclipse Persistence Services - 2.5.0.v20130425-368d603): org.eclipse.persistence.exceptions.JPQLException
Exception Description: Internal problem encountered while compiling [select c from Charger c join c.locationAttributes cc where key(cc) = :attrKey and value(cc) = :attrValue].
Internal Exception: java.lang.NullPointerException
at org.eclipse.persistence.internal.jpa.jpql.HermesParser.buildUnexpectedException(HermesParser.java:207)
at org.eclipse.persistence.internal.jpa.jpql.HermesParser.populateQueryImp(HermesParser.java:296)
at org.eclipse.persistence.internal.jpa.jpql.HermesParser.buildQuery(HermesParser.java:163)
at org.eclipse.persistence.internal.jpa.EJBQueryImpl.buildEJBQLDatabaseQuery(EJBQueryImpl.java:142)
at org.eclipse.persistence.internal.jpa.JPAQuery.processJPQLQuery(JPAQuery.java:221)
at org.eclipse.persistence.internal.jpa.JPAQuery.prepare(JPAQuery.java:182)
at org.eclipse.persistence.queries.DatabaseQuery.prepareInternal(DatabaseQuery.java:621)
at org.eclipse.persistence.internal.sessions.AbstractSession.processJPAQuery(AbstractSession.java:4301)
at org.eclipse.persistence.internal.sessions.AbstractSession.processJPAQueries(AbstractSession.java:4262)
at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.initializeDescriptors(DatabaseSessionImpl.java:572)
at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.postConnectDatasource(DatabaseSessionImpl.java:792)
at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.loginAndDetectDatasource(DatabaseSessionImpl.java:736)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider.login(EntityManagerFactoryProvider.java:239)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:681)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.getAbstractSession(EntityManagerFactoryDelegate.java:204)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.createEntityManagerImpl(EntityManagerFactoryDelegate.java:304)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManagerImpl(EntityManagerFactoryImpl.java:336)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:302)
at org.glassfish.persistence.jpa.JPADeployer$2.visitPUD(JPADeployer.java:451)
at org.glassfish.persistence.jpa.JPADeployer$PersistenceUnitDescriptorIterator.iteratePUDs(JPADeployer.java:510)
at org.glassfish.persistence.jpa.JPADeployer.iterateInitializedPUsAtApplicationPrepare(JPADeployer.java:492)
at org.glassfish.persistence.jpa.JPADeployer.event(JPADeployer.java:398)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:484)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java: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:722)
Caused by: java.lang.NullPointerException
at org.eclipse.persistence.queries.DatabaseQuery.addArgument(DatabaseQuery.java:449)
at org.eclipse.persistence.queries.DatabaseQuery.addArgument(DatabaseQuery.java:419)
at org.eclipse.persistence.internal.jpa.jpql.HermesParser.addArguments(HermesParser.java:98)
at org.eclipse.persistence.internal.jpa.jpql.HermesParser.populateQueryImp(HermesParser.java:287)
... 77 more
]]

Comment by Mitesh Meswani [ 09/May/13 ]

Fixed with integration of EclipseLink 2.5.0-RC2





[GLASSFISH-20452] [Regression] Client test was not able to load persistence api through javaee.jar during compilation on GF web distribution Created: 01/May/13  Updated: 02/May/13  Resolved: 02/May/13

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

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

OEL Linux 6.2, jdk1.7.0_21



 Description   

Build 87. Web distribution.

The client tests load persistence api through javaee.jar and failed with following errors during compilation:

compile-common-as:
[mkdir] Created dir: /home/mmzhang/paas/appserver-sqe/build/pe/amd64_chicago_Linux/ejb31/classes
[echo] sqe-common.xml: Compiling test source files
[javac] /home/mmzhang/paas/appserver-sqe/build-config/sqe-common.xml:512: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
[javac] Compiling 3 source files to /home/mmzhang/paas/appserver-sqe/build/pe/amd64_chicago_Linux/ejb31/classes
[javac] /home/mmzhang/paas/appserver-sqe/pe/ejb/ejb31/war/nointerfacecmt/web/servlet/JpaBean.java:3: error: package javax.persistence does not exist
[javac] import javax.persistence.Entity;
[javac] ^
[javac] /home/mmzhang/paas/appserver-sqe/pe/ejb/ejb31/war/nointerfacecmt/web/servlet/JpaBean.java:4: error: package javax.persistence does not exist
[javac] import javax.persistence.Id;
[javac] ^
[javac] /home/mmzhang/paas/appserver-sqe/pe/ejb/ejb31/war/nointerfacecmt/web/servlet/JpaBean.java:5: error: package javax.persistence does not exist
[javac] import javax.persistence.GeneratedValue;
[javac] ^
[javac] /home/mmzhang/paas/appserver-sqe/pe/ejb/ejb31/war/nointerfacecmt/web/servlet/JpaBean.java:6: error: package javax.persistence does not exist
[javac] import javax.persistence.GenerationType;
[javac] ^
[javac] /home/mmzhang/paas/appserver-sqe/pe/ejb/ejb31/war/nointerfacecmt/web/servlet/JpaBean.java:7: error: package javax.persistence does not exist
[javac] import javax.persistence.Table;
[javac] ^
[javac] /home/mmzhang/paas/appserver-sqe/pe/ejb/ejb31/war/nointerfacecmt/web/servlet/JpaBean.java:8: error: package javax.persistence does not exist
[javac] import javax.persistence.Column;
[javac] ^
[javac] /home/mmzhang/paas/appserver-sqe/pe/ejb/ejb31/war/nointerfacecmt/web/servlet/JpaBean.java:10: error: cannot find symbol
[javac] @Entity
[javac] ^
[javac] symbol: class Entity
[javac] /home/mmzhang/paas/appserver-sqe/pe/ejb/ejb31/war/nointerfacecmt/web/servlet/JpaBean.java:11: error: cannot find symbol
...

The same tests were passing on b81.



 Comments   
Comment by Mitesh Meswani [ 01/May/13 ]

This should be fixed as of 04/26th nighthy

I checked with Ming. These tests were executed against build of 04/25. Can you please reexecute the tests against any build after 04/26 to verify.

Comment by Mitesh Meswani [ 02/May/13 ]

Marking as fixed. Please rerun the test as described above.





[GLASSFISH-20449] Unable to use jsp .tag files when there are session beans in the web application (WAR) Created: 01/May/13  Updated: 07/May/13  Resolved: 07/May/13

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0_b88_RC4

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

Mac OSX, JDK 1.7.0_21


Tags: 4_0-approved, ejb, taglib, web

 Description   

Simple web application with .tag file in WEB-INF/tags. Create a simple stateless session bean. Create two jsp files using the .tag file, and only one of them will work. If the stateless bean is removed both jsp files work.

The custom tag in the .tag file only works for the first viewed jsp, the others referring that same tag will not work (unless the session bean is removed).



 Comments   
Comment by Peter Salomonsen [ 01/May/13 ]

I can attach an example web project, but I don't see where to do this - so here's what you need to reproduce:

My tag file - WEB-INF/tags/test.tag

<%@tag description="put the tag description here" pageEncoding="UTF-8"%>
Test

My JSP files (test1.jsp and test2.jsp)
<%@page contentType="text/html" pageEncoding="UTF-8"%>
<%@ taglib prefix="gui" tagdir="/WEB-INF/tags/" %>
<gui:test></gui:test>

My session bean:

@Stateless
public class testsb {
public void hello() {

}
}


So when the session bean is there - you can only use one of the jsp files, but when removing the session bean both jsps work.

Comment by michael.y.chen [ 01/May/13 ]

Peter, can you please provide a test caes?

Comment by Peter Salomonsen [ 01/May/13 ]

Test case provided above - I can also provide a web project if necessary but I don't find a place to upload it.

Comment by michael.y.chen [ 01/May/13 ]

attachment if turned off due to security issue. Can you email the test case to the "issues @ glassfish.java.net"?

Comment by Peter Salomonsen [ 01/May/13 ]

The test case is sent to the email above. You should get the following exception when testing:

java.lang.ClassCastException: org.apache.jsp.tag.web.test_tag cannot be cast to org.apache.jsp.tag.web.test_tag
at org.apache.jsp.tagreuse_jsp._jspx_meth_gui_test_0(tagreuse_jsp.java:86)
at org.apache.jsp.tagreuse_jsp._jspService(tagreuse_jsp.java:63)
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)

Comment by kchung [ 01/May/13 ]

Thanks, Peter. Unfortunately when I tried downloading your zip file, I got an internal error. Would appreciate if you can send the test directly to kinman.chung@oracle.com. Thanks.

Comment by Peter Salomonsen [ 01/May/13 ]

OK - I sent it directly to your mail address. Hope you're able to open it now.

Comment by kchung [ 01/May/13 ]

The test failed on B86, as reported, but passes with a build from the trunk. Please try again with B87, when it is available, and if it still fails, reopen this.

Thanks for reporting the bug and providing the test.

Comment by Peter Salomonsen [ 02/May/13 ]

Just tried on B87 and it still fails. How do I reopen this issue?

Comment by kchung [ 03/May/13 ]

Verified that the problem exists in B87. I have a fix in jsp-impl, yet to be integrated.

Comment by Peter Salomonsen [ 03/May/13 ]

replaced javax.servlet.jsp-2.3.2-SNAPSHOT.jar into gf/modules/javax.servlet.jsp fixed the issue.

Comment by kchung [ 06/May/13 ]

Change Control comments

  • What is the impact on the customer of the bug?

A major functionality will not work if not fixed.

  • What is the cost/risk of fixing the bug?

There two parts to the fix
1. Don't generate codes to invoke ResourceInjector for tag files.
2. For classic tag handlers and tag that extends SimpleTags, generate code to invoke ResourceInjector.PreDestroy

The risk is medium, since it potentially affects codes generated for all JSP pages. However, risk is also limited in a sense, because it removes unnecessary calls to ResourceInjector (for tag file) and adds cleanups (for others), so it should not alter the behavior of existing working JSP pages.

  • Is there an impact on documentation or message strings?

No.

  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

JSP portion of devtests. JSP tck tests (except EL related tests)

  • Which is the targeted build of 4.0 for this fix?

b88 final build

  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.

Project: jsp
Repository: svn
Revision: 1453
Author: kchung
Date: 2013-05-06 21:16:13 UTC
Link:

Log Message:
------------
1. Tag files should not call recource injector
2. Tag handler should call PreDestroy when released.
This fixes https://java.net/jira/browse/GLASSFISH-20449 and https://java.net/jira/browse/GLASSFISH-18650

Revisions:
----------
1453

Diffs:
------
Index: trunk/impl/src/main/java/org/apache/jasper/compiler/Generator.java
===================================================================
— trunk/impl/src/main/java/org/apache/jasper/compiler/Generator.java (revision 1452)
+++ trunk/impl/src/main/java/org/apache/jasper/compiler/Generator.java (revision 1453)
@@ -2429,6 +2429,10 @@
out.print(tagHandlerVar);
out.println(");");
} else

{ + out.printin("if (_jspx_resourceInjector != null) "); + out.print("_jspx_resourceInjector.preDestroy("); + out.print(tagHandlerVar); + out.println(");"); out.printin(tagHandlerVar); out.println(".release();"); }

@@ -2472,6 +2476,10 @@
out.print(tagHandlerVar);
out.println(");");
} else

{ + out.printin("if (_jspx_resourceInjector != null) "); + out.print("_jspx_resourceInjector.preDestroy("); + out.print(tagHandlerVar); + out.println(");"); out.printin(tagHandlerVar); out.println(".release();"); }

@@ -2511,11 +2519,15 @@
out.print(" ");
out.print(tagHandlerVar);
out.print(" = ");

  • out.print("(_jspx_resourceInjector != null) ? ");
  • out.print("_jspx_resourceInjector.createTagHandlerInstance(");
    + if (n.getTagFileInfo() == null) { + // Tag files do not support resource injection + out.print("(_jspx_resourceInjector != null)? "); + out.print("_jspx_resourceInjector.createTagHandlerInstance("); + out.print(tagHandlerClassName); + out.print(".class) : "); + }

    + out.print("new ");
    out.print(tagHandlerClassName);

  • out.print(".class) : new ");
  • out.print(tagHandlerClassName);
    out.println("();");

generateSetters(n, tagHandlerVar, handlerInfo, true);
@@ -2561,6 +2573,14 @@
declareScriptingVars(n, VariableInfo.AT_END);
syncScriptingVars(n, VariableInfo.AT_END);

+ if (n.getTagFileInfo() == null)

{ + // Tag files do not support resource injection + out.printin("if (_jspx_resourceInjector != null) "); + out.print("_jspx_resourceInjector.preDestroy("); + out.print(tagHandlerVar); + out.println(");"); + }

+
n.setEndJavaLine(out.getJavaLine());
}

Comment by Tom Mueller [ 07/May/13 ]

Approved for GF 4.0

Comment by kchung [ 07/May/13 ]

Fix committed to 4.0 branch and trunk.





[GLASSFISH-20441] JMSContext cannot be injected in a @SessionScoped bean Created: 30/Apr/13  Updated: 19/Sep/14  Resolved: 03/May/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b87_RC3
Fix Version/s: 4.0_b88_RC4, 4.1

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

Tags: 4_0-approved, fishcat

 Description   
@Named
@SessionScoped
public class SendPointsBean implements Serializable {

   @Inject
    JMSContext context;

   ...
}

throws

Error occurred during deployment: Exception while loading the app : CDI
deployment failure:WELD-001413 The bean Managed Bean [class
org.glassfish.movieplex7.points.ReceivePointsBean] with qualifiers
[@Default @Any @Named] declares passivating scope but has non-
serializable dependency
org.glassfish.jms.injection.JMSCDIExtension$LocalBean@f6c4da4. Please
see server.log for more details.

I can inject ConnectionFactory and use it to create a local JMSContext but using the code fragment above shows the following deployment failure.



 Comments   
Comment by David Zhao [ 02/May/13 ]

Arun,

Could you share a small application for reproduction?

I tried injecting JMSContext into a SessionScoped managed bean and then inject the managed bean into jsf. Both deployment and run are OK with only warning printed in server.log.

[2013-05-02T10:43:04.912+0800] [glassfish 4.0] [WARNING] [] [org.jboss.weld.Bootstrap] [tid: _ThreadID=37 _ThreadName=ad
min-listener(3)] [timeMillis: 1367462584912] [levelValue: 900] [[
WELD-001473 javax.enterprise.inject.spi.Bean implementation org.glassfish.jms.injection.JMSCDIExtension$LocalBean@984cb6 declared a normal scope but does not implement javax.enterprise.inject.spi.PassivationCapable. It won't be possible to inject this bean into a bean with passivating scope (@SessionScoped, @ConversationScoped). This can be fixed by assigning the Bean implementation a unique id by implementing the PassivationCapable interface.]]

Comment by arungupta [ 02/May/13 ]

Tried with b87 and got the same error. Attaching the sample app as well.

Complete stack trace below:

In-place deployment at /Users/arungup/code/workspaces/javaee7-samples~source/samples/jms/jmscontext-cdi/target/jmscontext-cdi-1.0-SNAPSHOT
Initializing...
deploy?DEFAULT=/Users/arungup/code/workspaces/javaee7-samples~source/samples/jms/jmscontext-cdi/target/jmscontext-cdi-1.0-SNAPSHOT&name=jmscontext-cdi&contextroot=/jmscontext-cdi&force=true failed on GlassFish Server 4.0 (87)
Error occurred during deployment: Exception while loading the app : CDI deployment failure:Exception List with 2 exceptions:
Exception 0 :
org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001413 The bean Managed Bean [class org.glassfish.sample.jmscontext.cdi.MessageReceiver] with qualifiers [@Any @Default] declares passivating scope but has non-serializable dependency org.glassfish.jms.injection.JMSCDIExtension$LocalBean@6eac366b
at org.jboss.weld.bootstrap.Validator.validateInjectionPointPassivationCapable(Validator.java:473)
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:418)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:325)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:177)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:208)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:519)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:505)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:480)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:536)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:216)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
Exception 0 :
org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001413 The bean Managed Bean [class org.glassfish.sample.jmscontext.cdi.MessageSender] with qualifiers [@Any @Default] declares passivating scope but has non-serializable dependency org.glassfish.jms.injection.JMSCDIExtension$LocalBean@6eac366b
at org.jboss.weld.bootstrap.Validator.validateInjectionPointPassivationCapable(Validator.java:473)
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:418)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:325)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:177)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:208)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:519)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:505)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:480)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:536)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:216)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
. Please see server.log for more details.
The module has not been deployed.
See the server log for details.
at org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:210)
at org.netbeans.modules.maven.j2ee.ExecutionChecker.performDeploy(ExecutionChecker.java:178)
at org.netbeans.modules.maven.j2ee.ExecutionChecker.executionResult(ExecutionChecker.java:130)
at org.netbeans.modules.maven.execute.MavenCommandLineExecutor.run(MavenCommandLineExecutor.java:212)
at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:153)

Comment by arungupta [ 02/May/13 ]

Sample is now available at:

https://blogs.oracle.com/arungupta/resource/jmscontext-cdi.zip

Comment by David Zhao [ 03/May/13 ]

What is the impact on the customer of the bug?
This is related to https://java.net/jira/browse/GLASSFISH-20441.
It is for the sample showing JMSContext injection (new JMS 2.0 feature) in @SessionScoped managed bean.

What is the cost/risk of fixing the bug?
It's small change, low risk

Is there an impact on documentation or message strings?
No.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
JMSContext injection related test cases

Which is the targeted build of 4.0 for this fix?
4.0_b88

If this an integration of a new version of a component from another project,
what are the changes that are being brought in? This might be list of
Jira issues from that project or a list of revision messages.
N/A

Comment by David Zhao [ 03/May/13 ]

Fixed in 4.0 by revision 61813.
Ported to trunk by revision 61816.

Comment by Bruno Borges [ 14/May/13 ]

Tried this on GlassFish 4.0 b88 promoted on 08-May-2013 18:59 and it is not fixed.

Comment by David Zhao [ 14/May/13 ]

Bruno,

What do you mean for it is not fixed? What have you observed? JMSContext injection failure or just the warning logged?

Comment by arungupta [ 15/May/13 ]

I tried my simple use case that sends a message as:

@SessionScoped
@JMSDestinationDefinitions({@JMSDestinationDefinition(name = "java:global/jms/myQueue",
        interfaceName = "javax.jms.Queue")
})
public class MessageSender implements Serializable {

    @Inject
    JMSContext context;
   
    @Resource(mappedName="java:global/jms/myQueue")
    Queue myQueue;

    public void sendMessage(String message) {
        context.createProducer().send(myQueue, message);
    }
}

and receives a message as:

@SessionScoped
public class MessageReceiver implements Serializable {

    @Inject
    private JMSContext context;
   
    @Resource(mappedName="java:global/jms/myQueue")
    Queue myQueue;

    public String receiveMessage() {
        String message = context.createConsumer(myQueue).receiveBody(String.class, 1000);
        return message;
    }
}

And that worked.

I filed the bug because this scenario was not working and now works with 88.

What exactly is not working ?





[GLASSFISH-20440] [BATCH RI] Batch Runtime fails to call listeners for partitioned steps Created: 30/Apr/13  Updated: 04/May/13  Resolved: 04/May/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0_b88_RC4

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

Any


Tags: 4_0-approved

 Description   

The batch runtime fails to call any of the spec'd programming model's listeners for a partitioned step on the partitioned threads.

Though we do call the StepListener's beforeStep()/afterStep() on the main thread, we fail to call ChunkListener, SkipListener, RetryListener, ItemReadListener, etc. on each partitioned threads.

This is a significant restriction on the programming model for partitioned steps.



 Comments   
Comment by Mahesh Kannan [ 03/May/13 ]
  • What is the impact on the customer of the bug?
    Though we do call the StepListener's beforeStep()/afterStep() on the main thread, we fail to call ChunkListener, SkipListener, RetryListener, ItemReadListener, etc. on each partitioned threads.
  • What is the impact on the customer of the bug?
    This is a significant restriction on the programming model for partitioned steps.
  • What is the cost/risk of fixing the bug?
    Very low, since the RI team has already run the TCK / CTS tests
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Batch QE tests

Which is the targeted build of 4.0 for this fix?
88.

If this an integration of a new version of a component from another project,
what are the changes that are being brought in?
Requires b30 jars from IBM Batch

Comment by Mahesh Kannan [ 03/May/13 ]
  • What is the impact on the customer of the bug?
    Though we do call the StepListener's beforeStep()/afterStep() on the main thread, we fail to call ChunkListener, SkipListener, RetryListener, ItemReadListener, etc. on each partitioned threads.
  • What is the impact on the customer of the bug?
    This is a significant restriction on the programming model for partitioned steps.
  • What is the cost/risk of fixing the bug?
    Very low, since the RI team has already run the TCK / CTS tests
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Batch QE tests
  • Which is the targeted build of 4.0 for this fix?
    88.
  • If this an integration of a new version of a component from another project,
    What are the changes that are being brought in?
    Requires b30 jars from IBM Batch

The pom.xml changes diffs are pasted below:

svn diff main/appserver/pom.xml
Index: main/appserver/pom.xml
===================================================================
— main/appserver/pom.xml (revision 61823)
+++ main/appserver/pom.xml (working copy)
@@ -125,9 +125,9 @@
<jsonp.version>1.0</jsonp.version>
<concurrent-api.version>1.0</concurrent-api.version>
<concurrent.version>1.0</concurrent.version>

  • <javax.batch-api.version>1.0-b26</javax.batch-api.version>
  • <com.ibm.jbatch-runtime-all.version>1.0-b26</com.ibm.jbatch-runtime-all.version>
  • <com.ibm.jbatch-ri-spi.version>1.0-b26</com.ibm.jbatch-ri-spi.version>
    + <javax.batch-api.version>1.0-b30</javax.batch-api.version>
    + <com.ibm.jbatch-runtime-all.version>1.0-b30</com.ibm.jbatch-runtime-all.version>
    + <com.ibm.jbatch-ri-spi.version>1.0-b30</com.ibm.jbatch-ri-spi.version>
    <javax.xml.soap-api.version>1.3.5</javax.xml.soap-api.version>
    <javax.management.j2ee-api.version>1.1.1</javax.management.j2ee-api.version>
    </properties>
Comment by Mahesh Kannan [ 04/May/13 ]

Actullay, need to integrate b29 jars

svn diff appserver/pom.xml
Index: appserver/pom.xml
===================================================================
— appserver/pom.xml (revision 61827)
+++ appserver/pom.xml (working copy)
@@ -126,9 +126,9 @@
<jsonp.version>1.0</jsonp.version>
<concurrent-api.version>1.0</concurrent-api.version>
<concurrent.version>1.0</concurrent.version>

  • <javax.batch-api.version>1.0-b26</javax.batch-api.version>
  • <com.ibm.jbatch-runtime-all.version>1.0-b26</com.ibm.jbatch-runtime-all.version>
  • <com.ibm.jbatch-ri-spi.version>1.0-b26</com.ibm.jbatch-ri-spi.version>
    + <javax.batch-api.version>1.0-b29</javax.batch-api.version>
    + <com.ibm.jbatch-runtime-all.version>1.0-b29</com.ibm.jbatch-runtime-all.version>
    + <com.ibm.jbatch-ri-spi.version>1.0-b29</com.ibm.jbatch-ri-spi.version>
    <javax.xml.soap-api.version>1.3.5</javax.xml.soap-api.version>
    <javax.management.j2ee-api.version>1.1.1</javax.management.j2ee-api.version>
    </properties>
Comment by Mahesh Kannan [ 04/May/13 ]

Integrate b29 jars:

============================

Branch commit info:

svn commit -m "Fix for 20440. QL Passed. Batch devtests passed. Approved by Michael" pom.xml
Sending pom.xml
Transmitting file data .
Committed revision 61832.

=============================

Trunk commit info:

svn commit -m "Fix for 20440. QL Passed. Batch devtests passed. Approved by Michael" pom.xml
Sending pom.xml
Transmitting file data .
Committed revision 61833.

==============================





[GLASSFISH-20431] Need glassfish-all javadocs Created: 29/Apr/13  Updated: 24/Jun/13

Status: Open
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0_b88_RC4

Type: Bug Priority: Major
Reporter: Joe Di Pol Assignee: Romain Grécourt
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

For GlassFish 3 we have:

https://glassfish.java.net/docs/v3/api/

we need a version of that for GlassFish 4 (https://glassfish.java.net/docs/4/api/)

The build currently generates only the Java EE 7 API javadocs.



 Comments   
Comment by Joe Di Pol [ 24/Jun/13 ]

Mike says published link should be: http://glassfish.java.net/docs/4/api/





[GLASSFISH-20428] [Regression] BATCH CLI: asadmin list-batch-job-executions or list-batch-steps with an operand value returns IllegalArgumentException Created: 29/Apr/13  Updated: 04/May/13  Resolved: 04/May/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0_b88_RC4

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

OEL6


Tags: 4_0-approved

 Description   

Looks like fix for GLASSFISH-20264 caused this issue

Steps:

1) Run asadmin list-batch-job-executions <instance_id>

bash-4.1$ asadmin list-batch-job-executions 1
remote failure: Can not set java.lang.Long field org.glassfish.batch.ListBatchJobExecutionsProxy.instanceId to java.lang.String
Can not set java.lang.Long field org.glassfish.batch.ListBatchJobExecutionsProxy.instanceId to java.lang.String
Usage: list-batch-job-executions [--executionid=executionid] [--terse=false] [--output=output] [--header=header] [--target=server] [--long=long] [instanceid]
Command list-batch-job-executions failed.

Stacktrace:

[2013-04-29T04:36:10.064-0700] [glassfish 4.0] [SEVERE] [NCLS-CORE-00003] [javax.enterprise.system.core] [tid: _ThreadID=34 _ThreadName=admin-listener(2)] [timeMillis: 1367235370064] [levelValue: 1000] [[
Exception while running a command
java.lang.IllegalArgumentException: Can not set java.lang.Long field org.glassfish.batch.ListBatchJobExecutionsProxy.instanceId to java.lang.String
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164)
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168)
at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:81)
at java.lang.reflect.Field.set(Field.java:680)
at org.jvnet.hk2.config.InjectionManager.syncDoInject(InjectionManager.java:171)
at org.jvnet.hk2.config.InjectionManager.inject(InjectionManager.java:73)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.injectParameters(CommandRunnerImpl.java:362)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1188)
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.GeneratedMethodAccessor67.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java: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:161)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
]]



 Comments   
Comment by Mahesh Kannan [ 04/May/13 ]
  • What is the impact on the customer of the bug?
    Cannot list batch job executions or steps. So this is a significant regression
  • What is the cost/risk of fixing the bug?
    Very low, and fixing involves changing a few lines in three files.
    Doesn't affect CTS tests at all. I have run the batch devtests as well.
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Batch QE tests
  • Which is the targeted build of 4.0 for this fix?
    88.
  • If this an integration of a new version of a component from another project,
    What are the changes that are being brought in?
    NA
Comment by Mahesh Kannan [ 04/May/13 ]

The fix is to check if the input is a long.

===============================

Branch commit info:

svn commit -m "Fix for 20428. QL Passed. Batch devtests passed. Approved by Michael"
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/AbstractListCommandProxy.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutions.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutionsProxy.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobStepsProxy.java
Transmitting file data ....
Committed revision 61830.
makannan-mac% svn info
Path: .
URL: https://svn.java.net/svn/glassfish~svn/branches/4.0/appserver/batch
Repository Root: https://svn.java.net/svn/glassfish~svn
Repository UUID: 6f3ba3e3-413c-0410-a8aa-90bee3ab43b5
Revision: 61829
Node Kind: directory
Schedule: normal
Last Changed Author: mk111283
Last Changed Rev: 61563
Last Changed Date: 2013-04-19 10:28:11 -0700 (Fri, 19 Apr 2013)

=========================

trunk commit info:

svn commit -m "Fix for 20428. QL Passed. Batch devtests passed. Approved by Michael"
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/AbstractListCommandProxy.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutions.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutionsProxy.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobStepsProxy.java
Transmitting file data ...

==========================





[GLASSFISH-20418] xJCL invalid per schema, see SysOut for now for details Created: 26/Apr/13  Updated: 06/May/13  Resolved: 06/May/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b87_RC3
Fix Version/s: 4.0_b88_RC4

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

Win7 Jdk7


Tags: 4_0-approved, fishcat

 Description   

If I have a invalid job.xml I get the following exception which I find is not very helpful at all.
Is there any chance to improve this for the developers?

At least a hint what exactly went wrong would be a good idea ...

Caused by: java.lang.IllegalArgumentException: xJCL invalid per schema, see SysOut for now for details
at com.ibm.jbatch.container.jsl.impl.JobModelResolverImpl.unmarshalJobXML(JobModelResolverImpl.java:73)
at com.ibm.jbatch.container.jsl.impl.JobModelResolverImpl.access$000(JobModelResolverImpl.java:45)
at com.ibm.jbatch.container.jsl.impl.JobModelResolverImpl$1.run(JobModelResolverImpl.java:127)
at com.ibm.jbatch.container.jsl.impl.JobModelResolverImpl$1.run(JobModelResolverImpl.java:125)
at java.security.AccessController.doPrivileged(Native Method)
at com.ibm.jbatch.container.jsl.impl.JobModelResolverImpl.resolveModel(JobModelResolverImpl.java:123)
at com.ibm.jbatch.container.jsl.impl.JobModelResolverImpl.resolveModel(JobModelResolverImpl.java:45)
at com.ibm.jbatch.container.jobinstance.JobExecutionHelper.startJob(JobExecutionHelper.java:114)
at com.ibm.jbatch.container.impl.BatchKernelImpl.startJob(BatchKernelImpl.java:120)
at com.ibm.jbatch.container.api.impl.JobOperatorImpl.start(JobOperatorImpl.java:105)
at net.eisele.glassfish.jbatchexample.sb.SalesBean.runJob(SalesBean.java:45)
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.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1081)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1153)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4695)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:630)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:582)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:582)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:140)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:369)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4667)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4655)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
... 61 more



 Comments   
Comment by ScottKurz [ 30/Apr/13 ]

The SAXParseException you'd get is a good clue to start. We should just change to a Logger warning() message rather than writing to SysOut (which I don't even understand the handling of). Will make that change at next opportunity to ship a fix.

Comment by Mahesh Kannan [ 30/Apr/13 ]

Assigning to Scott

Comment by Mahesh Kannan [ 30/Apr/13 ]

Scott, I assume that the this is a very low risk fix.

Comment by ScottKurz [ 30/Apr/13 ]

It is low risk. It shouldn't impact any runtime logic... we just had the validation handler code doing: System.out.println() that I can change to do a logger.warning().

Comment by ScottKurz [ 03/May/13 ]

In case it helps let me show what the message will look like in the server log.

We're using:

http://docs.oracle.com/javaee/5/api/javax/xml/bind/ValidationEventHandler.html

and the server log entry will look something like this:

LINKED EXC: org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content was found starting with element 'listeners'. One of '

{"http://xmlns.jcp.org/xml/ns/javaee":reader}

' is expected.
LOCATOR INFO:
------------
COLUMN NUMBER: 14
LINE NUMBER: 23
OFFSET: -1
CLASS: class javax.xml.bind.helpers.ValidationEventLocatorImpl
NODE: null
OBJECT: null
URL: null|#]

[#|2013-05-03T16:56:36.614-0400|WARNING|glassfish 4.0|com.ibm.jbatch.jsl.util.JSLValidationEventHandler|_ThreadID=27;_ThreadName=http-listener-1(4);_TimeMillis= 1367614596614;_LevelValue=900;|
JSL invalid per XSD, details:
MESSAGE: unexpected element (uri:"http://xmlns.jcp.org/xml/ns/javaee", local:"listeners"). Expected elements are <

{http://xmlns.jcp.org/xml/ns/javaee}

skippable-exception-classes>,<

{http://xmlns.jcp.org/xml/ns/javaee}

no-rollback-exception-classes>,<

{http://xmlns.jcp.org/xml/ns/javaee}

retryable-exception-classes>,<

{http://xmlns.jcp.org/xml/ns/javaee}

reader>,

{http://xmlns.jcp.org/xml/ns/javaee}

checkpoint-algorithm>,<

{http://xmlns.jcp.org/xml/ns/javaee}

processor>,<

{http://xmlns.jcp.org/xml/ns/javaee}

writer>

Comment by myfear [ 06/May/13 ]

That looks good to me! Thanks!

Comment by Mahesh Kannan [ 06/May/13 ]
  • What is the impact on the customer of the bug?
    User may not get a clear idea about what went wrong / where the error is in a job xml
  • What is the cost/risk of fixing the bug?
    Very, Very low, and in fact has already been fixed in b29 itself.
    Doesn't affect CTS tests at all. I have run the batch devtests as well.
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Batch QE tests
  • Which is the targeted build of 4.0 for this fix?
    88.
  • If this an integration of a new version of a component from another project,
    What are the changes that are being brought in?
    NA
Comment by Tom Mueller [ 06/May/13 ]

Approved for 4.0.

Comment by Mahesh Kannan [ 06/May/13 ]

The issue was fixed when we integrated b29 jars. Here are the commit messages for b29 integration

Integrate b29 jars:

============================

Branch commit info:

svn commit -m "Fix for 20440. QL Passed. Batch devtests passed. Approved by Michael" pom.xml
Sending pom.xml
Transmitting file data .
Committed revision 61832.

=============================

Trunk commit info:

svn commit -m "Fix for 20440. QL Passed. Batch devtests passed. Approved by Michael" pom.xml
Sending pom.xml
Transmitting file data .
Committed revision 61833.

==============================





[GLASSFISH-20317] JASPIC 1.1's new register session doesn't work Created: 15/Apr/13  Updated: 08/May/13  Resolved: 08/May/13

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0_b88_RC4

Type: Bug Priority: Major
Reporter: arjan tijms Assignee: quang.dang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved, fishcat

 Description   

In JASPIC 1.1 a new feature was specified that allows a SAM to ask the runtime to register a session. See http://java.net/jira/browse/JASPIC_SPEC-3 and http://jcp.org/aboutJava/communityprocess/maintenance/jsr196/module-asking-for-container-auth-session.pdf

Changes for this were made to GlassFish 4, but in practice they don't seem to work.

From a SAM's validateRequest method I called the following code:

public static void setRegisterSession(MessageInfo messageInfo) {
    messageInfo.getMap().put("javax.servlet.http.registerSession", TRUE.toString());
}

An authenticated identity was set via code such as the following:

CallerPrincipalCallback callerPrincipalCallback = new CallerPrincipalCallback(clientSubject, "test");
GroupPrincipalCallback groupPrincipalCallback = new GroupPrincipalCallback(
    clientSubject, new String[] { "architect" }
);
 
try {
    handler.handle(new Callback[] { callerPrincipalCallback, groupPrincipalCallback });
} catch (IOException | UnsupportedCallbackException e) {
    e.printStackTrace();
}
 
return SUCCESS;

After this a protected resource could indeed be invoked, but after requesting the same protected resource again, the SAM was also invoked again without any trace from the previously established authenticated identity. If I'm not mistaken the idea is that the runtime remembers this authenticated identity (name + groups/roles) and will not invoke the SAM again until the user explicitly log outs, or removes the HTTP session.

p.s. I also tested on GlassFish 3.1.2.2 using the proprietary key com.sun.web.RealmAdapter.register and checked by stepping into the GlassFish source code that the "register" branch is indeed taken in RealmAdapter:

if (register) {
      AuthenticatorProxy proxy = new AuthenticatorProxy(authenticator, wp, authType);
      proxy.authenticate(request, response, config);
} else {
       request.setAuthType((authType == null) ? PROXY_AUTH_TYPE : authType);
       request.setUserPrincipal(wp);
}

There too the authenticated identity was not remembered.



 Comments   
Comment by shreedhar_ganapathy [ 16/Apr/13 ]

Jeff, could you have someone from your team look into this?

Comment by arjan tijms [ 16/Apr/13 ]

I asked Ron Monzillo about this issue as well, and he kindly provided some clarification about the usage of this feature.

As it appears, the container is not supposed to fully automatically establish the authenticated identity, but it still calls the SAM with the previously authenticated identity available from request.getUserPrincipal. This should be passed into the CallerPrincipalHandler again in order to re-authenticate.

However, it still doesn't fully work. The userPrincpal's name is indeed restored, but any previously set groups are not restored. From the mail exchange with Ron:

In the case of glassfish, if you have the callback handler handle a CPC constructed with the principal obtained from getCallerPrincipal, and the principal was originally established using a CPC constructed with the principal name, then the groups should be restablished from the container specific principal.

I tested with the approach you outlined on both GlassFish 3.1.2.2 and GlassFish 4 (b84) with the old resp. new key.

The good news is that it indeed works for the principal. request.getUserPrincipal indeed returns a non-null principal, which can be passed into the CBH and then the authenticated identity is established.

The bad news is that on both versions of GlassFish it does not seem to work for the groups.

This is the code I used in the beginning of the validateRequest method:

   Principal userPrincipal = request.getUserPrincipal();
        
        if (userPrincipal != null) {
            
            try {
              
                handler.handle(new Callback[] { 
                    new CallerPrincipalCallback(clientSubject, userPrincipal) }
                );
                
                return SUCCESS;
                
            } catch (IOException | UnsupportedCallbackException e) {
                // Should not happen
                throw new IllegalStateException(e);
            }
        }

If I try to access a protected resource again (one that I could access after authentication first succeeded by using both the CallerPrincipalCallback and the GroupPrincipalCallback), access is denied and a 403 is returned.

If I then try to access a non-protected resource and print out the the userPrincipal and the group/role that was used before, then the userPrincipal returns the correct name, but the group is false.

E.g. by putting the following in a very basic JSP page:

<%=request.getUserPrincipal() %>

<%=request.isUserInRole("architect") %> 

Using a debugger I can see that in the SAM the associated SecurityContext (secCtx in the WebPrincipal) does have the right group.

Comment by shreedhar_ganapathy [ 19/Apr/13 ]

Hi Tim
Do you have an eta for this fix? Any chance this will make it before next promoted build i.e Tuesday 4/23?

Comment by Tim Quinn [ 19/Apr/13 ]

Shreedhar,

I believe Jeff is aware that I'm not able to work on this.

I'll go ahead and reassign this back to him to avoid any misunderstanding.

Comment by arjan tijms [ 21/Apr/13 ]

I'm not 100% sure if this is the right approach, but modifying com.sun.enterprise.security.jmac.callback.BaseContainerCallbackHandler as follows makes the feature work for the simple test case explained above:

private void processCallerPrincipal(CallerPrincipalCallback cpCallback) {
    final Subject fs = cpCallback.getSubject();
    Principal principal = cpCallback.getPrincipal();

    String realmName = null;
    if (handlerContext != null) {
        realmName = handlerContext.getRealmName();
    }

    // Start added
    
    if (principal instanceof WebPrincipal) {
        
        @SuppressWarnings("unchecked")
        Set<Principal> principals = ((WebPrincipal) principal).getSecurityContext().getPrincipalSet();
        
        if (principals != null && !principals.isEmpty()) {
            List<String> groups = new ArrayList<String>();
            for (Principal webOwnedPrincipal : principals) {
                if (webOwnedPrincipal instanceof Group) {
                    groups.add(webOwnedPrincipal.getName());
                }
            }
            processGroupPrincipal(new GroupPrincipalCallback(fs, groups.toArray(new String[groups.size()])));
        } 
    }

    // End added

    boolean isCertRealm = CertificateRealm.AUTH_TYPE.equals(realmName);

    // [...]
}
Comment by quang.dang [ 26/Apr/13 ]

Investigating...

Comment by arjan tijms [ 26/Apr/13 ]

Investigating...

Quang dang, thanks for looking into this! if there's any way I can help, either by testing, debugging or something else, please let me know.

Comment by quang.dang [ 01/May/13 ]

Arjan, how many requests to the protected-resource do you have to make from the browser before seeing the first 403 response ?

Comment by arjan tijms [ 01/May/13 ]

how many requests to the protected-resource do you have to make from the browser before seeing the first 403 response?

It's the very first request AFTER the one in which the initial authentication was done.

So, the SAM will check for userPrincipal != null. If it is null, it does the authentication by using the handler normally. Meaning, it will use both the CallerPrincipalCallback and the GroupPrincipalCallback for the initial authentication. It then returns SUCCESS and the protected resource is displayed.

After that, the very first request to the same protected resource will generate the 403.

Comment by quang.dang [ 01/May/13 ]

I understand the initial auth is done on the first request and I expect to get 403 on the second request. However that is not what I am seeing. I see 403 on the third request. For some reason, on the second request, request.getUserPrincipal() still returns null. Maybe it's just my environment or maybe I'm seeing another bug. I've observed this behavior consistently after many server restarts.

Comment by arjan tijms [ 01/May/13 ]

Hmmm, that's odd. I very consistently see it on the second request. For my test app I've added my test SAM programmatically instead of installing it inside GlassFish. Maybe that's the difference? I've tested with both GlassFish 3.1.2.2 (using the old proprietary key name) and GlassFish 4.0 build 83 and 84.

I'll try to put together a minimal example and post it back here.

Comment by arjan tijms [ 01/May/13 ]

So this is rather interesting...

In a minimal example I'm seeing the same behavior that you mentioned now. I've published it at: https://github.com/arjantijms/glassfish-20317

It's a Maven project for a web (war) project, with an embedded SAM. Just build and deploy it. Then

In a more complex SAM where the SAM is already invoked a couple of times (due to a message exchange with the user), the principal is NOT null after the first request after the initial authentication. I've published the code for this as well at: https://github.com/arjantijms/two-factor-sam (it's only the separate SAM).

Comment by arjan tijms [ 01/May/13 ]

In case it might be helpful, I've created a self-contained web app for the test case with the SAM I used previously as well. It's published at: https://github.com/arjantijms/glassfish-20317b

It's again a Maven project for a web (war) project, with an embedded SAM. Just build and deploy it. Then

  • Request http://localhost:8080/glassfish-20317b/protected/a.jsp. The SAM will redirect to /login.jsp.
  • Enter foo for the username and bar for the password. The SAM will redirect to /token.jsp.
  • Enter abc for the token. The SAM will redirect to /protected/a.jsp and during processing of /protected/a.jsp will authenticate and access to the page will be granted.
  • Request http://localhost:8080/glassfish-20317b/protected/a.jsp again, and the principal will NOT be null, and after the re-authentication protocol is executed access will NOT be granted since the roles/groups are not being restored.

Just to be sure I've re-tried this a couple of times, and every time the first request after the one in which authentication has taken place has a non-NULL principal, while in the https://github.com/arjantijms/glassfish-20317 example the first request after the authentication has a NULL principal, and only at second request it's non-NULL.

Comment by quang.dang [ 01/May/13 ]

Bug filed for the null principal: https://java.net/jira/browse/GLASSFISH-20451

Comment by quang.dang [ 06/May/13 ]

What is the impact on the customer of the bug?
This is to implement the session registration feature in JASPIC 1.1.

What is the cost/risk of fixing the bug?
This is a low-medium risk bug. It should be fixed/implemented to satisfy the JASPIC spec requirement.

Is there an impact on documentation or message strings?
No

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
JASPIC related tests.

Which is the targeted build of 4.0 for this fix?
4.0_b88

Comment by Tom Mueller [ 06/May/13 ]

Approved for 4.0. Please be sure to check the fix in to the 4.0 branch and the trunk.

Comment by quang.dang [ 07/May/13 ]

4.0 revision 61884, appserver/security/core-ee/src/main/java/com/sun/enterprise/security/jmac/callback/BaseContainerCallbackHandler.java

Comment by arjan tijms [ 08/May/13 ]

Thanks for the fix Quang Dang!

If you're still working on the code, please ignore the following, but I noticed that in rev 61884 of BaseContainerCallbackHandler#processCallerPrincipal there's a boolean useName set to false but thereafter not used anymore.

When reading through reuseWebPrincipal (which is quite an impressive check), I noticed two tiny typos in the comments. Hardly worth mentioning really, but on line 263 it says "WebPrincipla" and on line 331 it says "remove any exiting".

I'll see if I can do some local testing with the code later today. Thanks again!

Comment by quang.dang [ 08/May/13 ]

trunk rev. 61899

Comment by quang.dang [ 08/May/13 ]

Ron gave some serious thought on this issue and came up with that fix.
The spellings got corrected.





[GLASSFISH-20308] Unable to Deploy JAX-RS Restful Application Class Not Found JsonStructureBodyReader Created: 14/Apr/13  Updated: 03/May/13  Resolved: 03/May/13

Status: Resolved
Project: glassfish
Component/s: json
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0_b88_RC4, 4.0

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

Embedded Container


Tags: 4_0-approved

 Description   

This should not be happening in the GlassFish

Surely application code does not need to refer or import an internal Glassfish class:

org/glassfish/json/jaxrs/JsonStructureBodyReader

Apr 14, 2013 1:58:11 PM org.glassfish.jersey.servlet.init.JerseyServletContainerInitializer addServletWithDefaultConfiguration
INFO: Registering the Jersey servlet application, named javax.ws.rs.core.Application, with the following root resource and provider classes: [class je7hb.jaxrs.basic.RestfulBookService]
Apr 14, 2013 1:58:11 PM org.glassfish.jersey.server.ApplicationHandler initialize
INFO: Initiating Jersey application, version Jersey: 2.0-rc1 2013-03-26 02:00:32...
Apr 14, 2013 1:58:11 PM org.apache.catalina.core.StandardContext log
SEVERE: WebModule[/mywebapp]StandardWrapper.Throwable
java.lang.NoClassDefFoundError: org/glassfish/json/jaxrs/JsonStructureBodyReader
at org.glassfish.jersey.jsonp.JsonProcessingFeature.configure(JsonProcessingFeature.java:66)
at org.glassfish.jersey.model.internal.CommonConfig.configureFeatures(CommonConfig.java:617)
at org.glassfish.jersey.model.internal.CommonConfig.configureMetaProviders(CommonConfig.java:558)
at org.glassfish.jersey.server.ResourceConfig.configureMetaProviders(ResourceConfig.java:768)
at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:313)
at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:146)
at org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:269)
at org.glassfish.jersey.internal.Errors$2.call(Errors.java:249)
at org.glassfish.jersey.internal.Errors$2.call(Errors.java:246)
at org.glassfish.jersey.internal.Errors.process(Errors.java:275)
at org.glassfish.jersey.internal.Errors.process(Errors.java:257)
at org.glassfish.jersey.internal.Errors.processWithException(Errors.java:246)
at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:266)
at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:256)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:167)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:349)
at javax.servlet.GenericServlet.init(GenericServlet.java:244)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1583)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1382)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5670)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5912)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(Containeava:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2278)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1924)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at je7hb.common.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.deployWithRename(AbstractEmbeddedRunner.java:86)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFileAndWait(SimpleEmbeddedRun ner.java:36)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFileAndWait(SimpleEmbeddedRunner.java:31)
at je7hb.jaxrs.basic.EmbeddedRunner.main(EmbeddedRunner.java:7)

Apr 14, 2013 1:58:11 PM org.apache.catalina.core.StandardContext log
SEVERE: WebModule[/mywebapp]Servlet /mywebapp threw load() exception
java.lang.NoClassDefFoundError: org/glassfish/json/jaxrs/JsonStructureBodyReader
at org.glassfish.jersey.jsonp.JsonProcessingFeature.configure(JsonProcessingFeature.java:66)
at org.glassfish.jersey.model.internal.CommonConfig.configureFeatures(CommonConfig.java:617)
at org.glassfish.jersey.model.internal.CommonConfig.configureMetaProviders(CommonConfig.java:558)
at org.glassfish.jersey.server.ResourceConfig.configureMetaProviders(ResourceConfig.java:768)
at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:313)
at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:146)
at org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:269)
at org.glassfish.jersey.internal.Errors$2.call(Errors.java:249)
at org.glassfish.jersey.internal.Errors$2.call(Errors.java:246)
at org.glassfish.jersey.internal.Errors.process(Errors.java:275)
at org.glassfish.jersey.internal.Errors.process(Errors.java:257)
at org.glassfish.jersey.internal.Errors.processWithException(Errors.java:246)
at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:266)
at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:256)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:167)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:349)
at javax.servlet.GenericServlet.init(GenericServlet.java:244)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1583)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1382)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext670)a:5
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5912)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2278)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1924)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at je7on.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.deployWithRename(AbstractEmbeddedRunner.java:86)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFileAndWait(SimpleEmbeddedRunner.java:36)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFileAndWait(SimpleEmbeddedRunner.java:31)
at je7hb.jaxrs.basic.EmbeddedRunner.main(EmbeddedRunner.java:7)

Apr 14, 2013 1:58:11 PM org.apache.catalina.core.StandardContext start
SEVERE: Startup of context /mywebapp failed due to previous errors
Apr 14, 2013 1:58:11 PM org.apache.catalina.core.ContainerBase addChildInternal
SEVERE: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: org.apache.catalina.LifecycleException: java.lang.NoClassDefFoundError: org/glassfish/json/jaxrs/JsonStructureBodyReader
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5920)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2278)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1924)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterpridmin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at je7hb.common.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.deployWithRename(AbstractEmbeddedRunner.java:86)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFileAndWait(SimpleEmbeddedRunner.java:36)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFileAndWait(SimpleEmbeddedRunner.java:31)
at je7hb.jaxrs.basic.EmbeddedRunner.main(EmbeddedRunner.java:7)
Caused by: org.apache.catalina.LifecycleException: java.lang.NoClassDefFoundError: org/glassfish/json/jaxrs/JsonStructureBodyReader
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5678)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5912)
... 28 more
Caused by: java.lang.NoClassDefFoundError: org/glassfish/json/jaxrs/JsonStructureBodyReader
at org.glassfish.jersey.jsonp.JsonProcessingFeature.configure(JsonProcessingFeature.java:66)
at org.glassfish.jersey.model.internal.CommonConfig.configureFeatures(CommonConfig.java:617)
at org.glassfish.jersey.model.internal.CommonConfig.configureMetaProviders(CommonConfig.java:558)
at org.glassfish.jersey.server.ResourceConfig.configureMetaProviders(ResourceConfig.j)va:768
at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:313)
at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:146)
at org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:269)
at org.glassfish.jersey.internal.Errors$2.call(Errors.java:249)
at org.glassfish.jersey.internal.Errors$2.call(Errors.java:246)
at org.glassfish.jersey.internal.Errors.process(Errors.java:275)
at org.glassfish.jersey.internal.Errors.process(Errors.java:257)
at org.glassfish.jersey.internal.Errors.processWithException(Errors.java:246)
at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:266)
at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:256)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:167)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:349)
at javax.servlet.GenericServlet.init(GenericServlet.java:244)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1583)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1382)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5670)
... 29 more

Apr 14, 2013 1:58:11 PM com.sun.enterprise.web.WebApplication start
WARNING: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: org.apache.catalina.LifecycleException: java.lang.NoClassDefFoundError: org/glassfish/json/jaxrs/JsonStructureBodyReader
java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: org.apache.catalina.LifecycleException: java.lang.NoClassDefFoundError: org/glassfish/json/jaxrs/JsonStructureBodyReader
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1044)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enteweb.WebContainer.loadWebModule(WebContainer.java:2278)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1924)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at je7hb.common.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.deployWithRename(AbstractEmbeddedRunner.java:86)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFileAndWait(SimpleEmbeddedRunner.java:36)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFileAndWait(SimpleEmbeddedRunner.java:31)
at je7hb.jaxrs.basic.EmbeddedRunner.beddedRunner.java:7)

Apr 14, 2013 1:58:11 PM org.glassfish.internal.data.ModuleInfo start
SEVERE: Exception while invoking class com.sun.enterprise.web.WebApplication start method
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: org.apache.catalina.LifecycleException: java.lang.NoClassDefFoundError: org/glassfish/json/jaxrs/JsonStructureBodyReader
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:168)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at je7hb.common.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.deployWithRename(AbstractEmbeddedRunner.java:86)
je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFileAndWait(SimpleEmbeddedRunner.java:36)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFileAndWait(SimpleEmbeddedRunner.java:31)
at je7hb.jaxrs.basic.EmbeddedRunner.main(EmbeddedRunner.java:7)

Apr 14, 2013 1:58:11 PM com.sun.enterprise.v3.server.ApplicationLifecycle deploy
SEVERE: Exception during lifecycle processing
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: org.apache.catalina.LifecycleException: java.lang.NoClassDefFoundError: org/glassfish/json/jaxrs/JsonStructureBodyReader
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:168)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at je7hb.common.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.deployWithRename(AbstractEmbeddedRunner.java:86)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFileAndWait(SimpleEmbeddedRunner.java:36)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFileAndWait(SimpleEmbeddedRunner.java:31)
at je7hb.jaxrs.basic.EmbeddedRunner.main(EmbeddedRunner.java:7)

Apr 14, 2013 1:58:11 PM org.glassfish.api.ActionReport failure
SEVERE: Exception while loading the app
Apr 14, 2013 1:58:11 PM com.sun.enterprise.web.WebContainer unloadWebModule
SEVERE: Undeployment failed for context /mywebapp
Apr 14, 2013 1:58:11 PM org.glassfish.deployment.admin.DeployCommand execute
SEVERE: Exception while loading the app : java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: org.apache.catalina.LifecycleException: java.lang.NoClassDefFoundError: org/glassfish/json/jaxrs/JsonStructureBodyReader

        • Press the ENTER key to stop the server ****


 Comments   
Comment by Michal Gajdos [ 26/Apr/13 ]

Can you list modules under glassfish4\glassfish\modules? I am especially if you have jsonp-jaxrs.jar library.
How do you run your GF instance?

Comment by peter_pilgrim [ 26/Apr/13 ]

I am actually using the embedded GlassFish container in a Gradle build file and this is the environment where I found the JAX-RS failure.

Here is my Gradle build that specifies the dependencies that I use.

// build.gradle
apply plugin: 'java'
apply plugin: 'war'
apply plugin: 'maven'
apply plugin: 'eclipse'
apply plugin: 'idea'

// Define equivalent Maven GAV coordinates.
group = 'com.javaeehandbook.book1'
archivesBaseName = 'ch08-jaxrs-basic'
version = '1.0'

repositories {
maven

{ url 'https://maven.java.net/content/groups/promoted' }

maven

{ url 'http://repository.jboss.org/nexus/content/groups/public' }

mavenCentral()
mavenLocal()
}

dependencies

{ providedCompile 'org.glassfish.main.extras:glassfish-embedded-all:4.0-b84' providedCompile 'javax:javaee-api:7.0-b84' providedCompile 'javax:javaee-web-api:7.0-b84' providedCompile 'com.javaeehandbook.book1:glassfish-embedded-runner:1.0' compile 'org.glassfish.main.extras:glassfish-embedded-all:4.0-b84' compile 'javax:javaee-api:7.0-b84' compile 'com.javaeehandbook.book1:glassfish-embedded-runner:1.0' testCompile 'junit:junit:4.11' }

task wrapper(type: Wrapper)

{ gradleVersion = '1.5' }

//End

Maybe this jsonp-jaxrs is not being build into the embedded Glassfish 4.0 bundle or something along those lines?

Hope that helps.

Comment by Michal Gajdos [ 26/Apr/13 ]

The problem seems to be in embedded GF itself - it contains all Jersey libs as regular GF but does not contain JSON-P classes. I've sent a patch to Jitu.

Comment by jitu [ 26/Apr/13 ]

Here is the michael's patch.

---------------
Index: appserver/extras/embedded/web/pom.xml
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
— appserver/extras/embedded/web/pom.xml (revision 61635)
+++ appserver/extras/embedded/web/pom.xml (revision )
@@ -3,7 +3,7 @@

DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.

  • Copyright (c) 1997-2012 Oracle and/or its affiliates. All rights reserved.
    + Copyright (c) 1997-2013 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
@@ -237,6 +237,13 @@
<dependency>
<groupId>org.glassfish.main.packager</groupId>
<artifactId>jersey</artifactId>
+ <version>$

{project.version}</version>
+ <type>zip</type>
+ <optional>true</optional>
+ </dependency>
+ <dependency>
+ <groupId>org.glassfish.main.packager</groupId>
+ <artifactId>json</artifactId>
<version>${project.version}

</version>
<type>zip</type>
<optional>true</optional>
Index: appserver/extras/embedded/all/pom.xml
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
— appserver/extras/embedded/all/pom.xml (revision 61635)
+++ appserver/extras/embedded/all/pom.xml (revision )
@@ -3,7 +3,7 @@

DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.

  • Copyright (c) 1997-2012 Oracle and/or its affiliates. All rights reserved.
    + Copyright (c) 1997-2013 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
@@ -277,6 +277,13 @@
<dependency>
<groupId>org.glassfish.main.packager</groupId>
<artifactId>jersey</artifactId>
+ <version>$

{project.version}</version>
+ <type>zip</type>
+ <optional>true</optional>
+ </dependency>
+ <dependency>
+ <groupId>org.glassfish.main.packager</groupId>
+ <artifactId>json</artifactId>
<version>${project.version}

</version>
<type>zip</type>
<optional>true</optional>

Comment by dapeng_hu [ 27/Apr/13 ]

Move plugin version definition from connectors sub modules to top level pom.xml.

Comment by buddypine [ 02/May/13 ]

I'm still getting this issue in 4.0-b87 using glassfish-embedded in a Gradle build, the org.glassfish.json package does not seem to be present in the jar.

05:30:16.083 [DEBUG] [TestEventLogger] java.lang.NoClassDefFoundError: org/glassfish/json/jaxrs/JsonStructureBodyReader
05:30:16.083 [DEBUG] [TestEventLogger] at org.glassfish.jersey.jsonp.JsonProcessingFeature.configure(JsonProcessingFeature.java:66)
05:30:16.083 [DEBUG] [TestEventLogger] at org.glassfish.jersey.model.internal.CommonConfig.configureFeatures(CommonConfig.java:617)
05:30:16.084 [DEBUG] [TestEventLogger] at org.glassfish.jersey.model.internal.CommonConfig.configureMetaProviders(CommonConfig.java:558)
05:30:16.084 [DEBUG] [TestEventLogger] at org.glassfish.jersey.client.ClientConfig$State.initRuntime(ClientConfig.java:361)
05:30:16.084 [DEBUG] [TestEventLogger] at org.glassfish.jersey.client.ClientConfig$State.access$000(ClientConfig.java:84)
05:30:16.084 [DEBUG] [TestEventLogger] at org.glassfish.jersey.client.ClientConfig$State$3.get(ClientConfig.java:116)
05:30:16.085 [DEBUG] [TestEventLogger] at org.glassfish.jersey.client.ClientConfig$State$3.get(ClientConfig.java:113)
05:30:16.085 [DEBUG] [TestEventLogger] at org.glassfish.jersey.internal.util.collection.Values$LazyValue.get(Values.java:275)
05:30:16.085 [DEBUG] [TestEventLogger] at org.glassfish.jersey.client.ClientConfig.getRuntime(ClientConfig.java:667)
05:30:16.085 [DEBUG] [TestEventLogger] at org.glassfish.jersey.client.ClientRequest.getClientRuntime(ClientRequest.java:169)
05:30:16.085 [DEBUG] [TestEventLogger] at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:629)
05:30:16.086 [DEBUG] [TestEventLogger] at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:366)
05:30:16.086 [DEBUG] [TestEventLogger] at org.glassfish.jersey.client.JerseyInvocation$Builder.get(JerseyInvocation.java:270)

Comment by Michal Gajdos [ 03/May/13 ]

Reopening the issue as the patch was not applied and the issue was closed by mistake.

Comment by Michal Gajdos [ 03/May/13 ]
  • What is the impact on the customer of the bug?

Without the fix users won't be able to deploy a JAX-RS application into the embedded GF because jersey-media-json-processing requires javax.json, jsonp-jaxrs to be on the classpath (if these libraries are not present the mentioned exception would be raised).

  • What is the cost/risk of fixing the bug?

You can see the patch here [1] - adding json packager dependency to the embedded (all/web) modules.

[1] https://java.net/jira/browse/GLASSFISH-20308?focusedCommentId=362674&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_362674

  • Is there an impact on documentation or message strings?

No.

  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

Deploy an JAX-RS application into an embedded GF instance + run all tests for Embedded GF.

  • Which is the targeted build of 4.0 for this fix?

88.

  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.

N/A.

Comment by Tom Mueller [ 03/May/13 ]

Approved for 4.0. Please check the fix into the 4.0 branch and the trunk.





[GLASSFISH-20092] Expression Language 3.0 issues Created: 28/Mar/13  Updated: 02/Apr/13  Resolved: 02/Apr/13

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 4.0_b81
Fix Version/s: 4.0_b88_RC4

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

Ubuntu 12.04 32b



 Description   

Please try following EL3.0 statements in JSP:

#1 lambda function

$

{v = (x,y)->x+y; v(1,2)}

If I run the page Server log shows:

org.apache.jasper.JasperException: /index.jsp(16,10) PWC6296: The function v must be used with a prefix when a default namespace is not specified
at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:81)
at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:376)
at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:204)
at org.apache.jasper.compiler.Validator$ValidateVisitor$1FVVisitor.visit(Validator.java:1599)
at org.apache.jasper.compiler.ELNode$Function.accept(ELNode.java:166)

========================
#2 string concatenation

$

{"A"+"B"}

Server log shows msg:

java.lang.NumberFormatException: For input string: "A"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Long.parseLong(Long.java:441)
at java.lang.Long.valueOf(Long.java:540)
at com.sun.el.lang.ELArithmetic$LongDelegate.coerce(ELArithmetic.java:210)
at com.sun.el.lang.ELArithmetic.coerce(ELArithmetic.java:378)
at com.sun.el.lang.ELArithmetic.add(ELArithmetic.java:259)
...

=======================
#3 string concatenation II

$

{"A" cat "B"}

Server log shows:

org.apache.jasper.JasperException: /index.jsp(16,9) PWC6038: "${"A" cat "B"}

" contains invalid expression(s): javax.el.ELException: Error Parsing: $

{"A" cat "B"}

at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:81)
at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:376)
at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:188)
...

======================
#4 Static field

$

{T(pckg.Test).label}

it is marked in editor and also in browser/server log

org.apache.jasper.JasperException: /index.jsp(16,10) PWC6296: The function T must be used with a prefix when a default namespace is not specified
at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:81)
at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:376)
at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:204)
at org.apache.jasper.compiler.Validator$ValidateVisitor$1FVVisitor.visit(Validator.java:1599)
at org.apache.jasper.compiler.ELNode$Function.accept(ELNode.java:166)
...

====================
#5 Set & Map declaration

${v = {1,2}}

or

${v = {"one":1, "two":2, "three":3}}

Server log shows:

org.apache.jasper.JasperException: /index.jsp(16,9) PWC6038: "${v =

{1,2}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${v = {1,2}

at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:81)
at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:376)
at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:188)
at org.apache.jasper.compiler.JspUtil.validateExpressions(JspUtil.java:656)
at org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:760)
at org.apache.jasper.compiler.Node$ELExpression.accept(Node.java:947)
...

With JSF 2.2, #1 works but the rest doesn't as well.

Originally reported against NetBeans, see issue http://netbeans.org/bugzilla/show_bug.cgi?id=228029

Java: 1.7.0_17; Java HotSpot(TM) Client VM 23.7-b01
Runtime: Java(TM) SE Runtime Environment 1.7.0_17-b32
System: Linux version 3.2.0-39-generic-pae running on i386; UTF-8; en_US (nb)
GlassFish 4 b81



 Comments   
Comment by vriha [ 28/Mar/13 ]

Please ignore #2, #3, #4, I checked latest draft and it was changed. I'm sorry for troubles

Comment by kchung [ 28/Mar/13 ]

#2 and #3
The spec has been modified to use "=" as the concatenation operator. "" and "cat" are not backward compatible.

#4 T(...)
The spec has removed this syntax. Only Test.label is now allowed.

I'll look into #1, and #5.

Comment by kchung [ 02/Apr/13 ]

Fixed in r61092.





[GLASSFISH-20028] 4.0 deployment performance - ejb container module get loaded for a pure web application Created: 25/Mar/13  Updated: 03/Apr/13  Resolved: 03/Apr/13

Status: Closed
Project: glassfish
Component/s: hk2
Affects Version/s: 4.0_b81
Fix Version/s: 4.0_b88_RC4

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

Issue Links:
Related
is related to GLASSFISH-17038 3.1.1 deployment performance - ejb co... Resolved
Tags: 4_0-approved, devx_web

 Description   

The ejb-container module get loaded for a simple web app deployment.
After the intial deployment, the ejb-container module is loaded and in active state.

152|Active | 1|GlassFish Core EJB container implementation (4.0.0.SNAPSHOT)

The snippet of stack trace to trigger this module loading during initial deployment:

org.jvnet.hk2.osgiadapter.OsgiPopulatorPostProcessor$1.loadClass(OsgiPopulatorPostProcessor.java:77)
org.jvnet.hk2.internal.ServiceLocatorImpl.loadClass(ServiceLocatorImpl.java:1639)
org.jvnet.hk2.internal.ServiceLocatorImpl.reifyDescriptor(ServiceLocatorImpl.java:362)
org.jvnet.hk2.internal.ServiceLocatorImpl.narrow(ServiceLocatorImpl.java:1701)
org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetDescriptor(ServiceLocatorImpl.java:898)
org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:570)
org.jvnet.hk2.internal.IterableProviderImpl.get(IterableProviderImpl.java:87)
com.sun.enterprise.security.ee.SecurityDeployer$AppDeployEventListener.event(SecurityDeployer.java:149)
org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)

Based on the stack trace, I am assigning it to HK2 team for initial evaluation.



 Comments   
Comment by Hong Zhang [ 25/Mar/13 ]

We have an issue logged for 3.1 also:
http://java.net/jira/browse/GLASSFISH-17038

But I believe that all the old dependencies were already resolved. The above stack trace is something new in 4.0.

Comment by jwells [ 25/Mar/13 ]

Can you attach the application you are deploying?

Comment by Hong Zhang [ 25/Mar/13 ]

(I think the attachment is still disabled in JIRA).

You can use v1.war attached in this issue:

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

Comment by Hong Zhang [ 25/Mar/13 ]

I just verified the ejb container jar is not loaded in 3.1.2.2 so issue 16460 was indeed fixed, and this is a regresion in 4.0.

Comment by Tom Mueller [ 01/Apr/13 ]

Here is the code combination that appears to be causing this problem.

The appserver security code (appserver/security/core-ee module, SecurityDeployer.event method) has the following code:

A field is declared as follows:

@Inject
@Named("webSecurityCIH")
private Provider<RegisteredComponentInvocationHandler> registeredComponentInvocationHandlerProvider;

Then in the event method, it calls:

RegisteredComponentInvocationHandler handler = registeredComponentInvocationHandlerProvider.get();

The WebSecurityComponentInvocationHandler class has this declaration:

@Service(name="webSecurityCIH")
@Singleton
public class WebSecurityComponentInvocationHandler implements RegisteredComponentInvocationHandler {

and the EjbSecurityComponentInvocationHandler class (in the ejb-container module) has this declaration:

@Service(name="ejbSecurityCIH")
@Singleton
public class EjbSecurityComponentInvocationHandler implements RegisteredComponentInvocationHandler {

While processing the "get" call, HK2 is activating the ejb-container module even though it shouldn't be because the @Named annotation should limit the Provider to returning a service named "webSecurityCIH".

Comment by jwells [ 01/Apr/13 ]

This is fixed in the current hk2. But we have not been able to uptake that version into GlassFish because of problems in cloudlogic.

Comment by Hong Zhang [ 02/Apr/13 ]

I updated workspace and got the latest HK2 integration

r61090 | mtaube | 2013-04-02 05:43:34 -0700 (Tue, 02 Apr 2013) | 1 line
uptake hk2 2.1.78 after succesful cpas admin devtest run

and still see similar stack trace triggering EJB container loading for deployment.

Comment by jwells [ 03/Apr/13 ]
  • What is the impact on the customer of the bug?
    There will be increased performance in some boot scenarios

How likely is it that a customer will see the bug and how serious is the bug?
They will see better boot performance if they have webapps with no ejbs

Is it a regression?
It is a performance regression

Does it meet other bug fix criteria (security, performance, etc.)?
It makes the performance of boot better in some scenarios

What CTS failures are caused by this bug?
None

  • What is the cost/risk of fixing the bug?
    Low risk

How risky is the fix? How much work is the fix? Is the fix complicated?
The fix was not complicated

  • Is there an impact on documentation or message strings?
    No
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    WebApp and EJB
  • Which is the targeted build of 4.0 for this fix?
    I don't know
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.

http://gf-hudson.us.oracle.com/hudson/job/promote-hk2/166/changes#detail0

Comment by Tom Mueller [ 03/Apr/13 ]

Approved for 4.0.

Comment by jwells [ 03/Apr/13 ]

$ svn --message "GLASSFISH-20028 Fix performance regression" commit
Sending nucleus/pom.xml
Transmitting file data .
Committed revision 61140.





[GLASSFISH-19257] pkg repositories for GlassFish 4 Created: 29/Oct/12  Updated: 29/May/13  Resolved: 29/May/13

Status: Resolved
Project: glassfish
Component/s: update_center
Affects Version/s: 4.0_b60
Fix Version/s: 4.0_b88_RC4

Type: New Feature Priority: Critical
Reporter: Joe Di Pol Assignee: Snjezana Sevo-Zenzerovic
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved

 Description   

We need to come up with a pkg repository scheme for GlassFish 4. Initially this only needs to cover the RI and SDK. We should try strongly to reduce the number of repositories. For example we could put all native packages in a "native" repository, and try not to have a special SDK repository.

So, that would look something like this:

# These hold only platform neutral packages and are used by all platforms (ignoring AIX for now)
http://pkg.glassfish.org/4/dev
http://pkg.glassfish.org/4/release

# These hold native packages. It's possible we could only have "release" if 
# we're only talking UC and JDK
http://pkg.glassfish.org/4/native/dev/solaris/sunos-sparc
http://pkg.glassfish.org/4/native/dev/solaris/sunos-i386
http://pkg.glassfish.org/4/native/dev/solaris/linux
http://pkg.glassfish.org/4/native/dev/solaris/darwin-universal
http://pkg.glassfish.org/4/native/dev/solaris/windows-i386

http://pkg.glassfish.org/4/native/release/solaris/sunos-sparc
http://pkg.glassfish.org/4/native/release/solaris/sunos-i386
http://pkg.glassfish.org/4/native/release/solaris/linux
http://pkg.glassfish.org/4/native/release/solaris/darwin-universal
http://pkg.glassfish.org/4/native/release/solaris/windows-i386

By putting the native packages in their own repo we save on disk space and the hassle of pushing out new packages.



 Comments   
Comment by Joe Di Pol [ 10/Apr/13 ]

Jill has deployed these repositories:

http://pkg.glassfish.org/4/native/release/solaris-x86/
http://pkg.glassfish.org/4/native/release/solaris-sparc/
http://pkg.glassfish.org/4/native/release/linux/
http://pkg.glassfish.org/4/native/release/mac/
http://pkg.glassfish.org/4/native/release/windows/

http://pkg.oracle.com/javaeesdk/7/native/release/solaris-x86/
http://pkg.oracle.com/javaeesdk/7/native/release/solaris-sparc/
http://pkg.oracle.com/javaeesdk/7/native/release/linux/
http://pkg.oracle.com/javaeesdk/7/native/release/mac/
http://pkg.oracle.com/javaeesdk/7/native/release/windows/

SDK7 native repos redirect back to the GF4 native repos.

The currently contain UC 2.3.5,0-56.2852

Comment by Jill Sato [ 24/Apr/13 ]

I have added the rest of the GF4/SDK7 non-native repositories:
(These all redirect to the same non-native repo)

http://pkg.glassfish.org/4/release/solaris-x86/
http://pkg.glassfish.org/4/release/solaris-sparc/
http://pkg.glassfish.org/4/release/linux/
http://pkg.glassfish.org/4/release/mac/
http://pkg.glassfish.org/4/release/windows/

http://pkg.oracle.com/javaeesdk/7/release/solaris-x86/
http://pkg.oracle.com/javaeesdk/7/release/solaris-sparc/
http://pkg.oracle.com/javaeesdk/7/release/linux/
http://pkg.oracle.com/javaeesdk/7/release/mac/
http://pkg.oracle.com/javaeesdk/7/release/windows/

Comment by Joe Di Pol [ 30/Apr/13 ]

The pkg.depotd repos are up (thanks Jill). The installation bundles need to be updated with the new URLs. Assigning to Snjezana to finish up that work.

Comment by Snjezana Sevo-Zenzerovic [ 30/Apr/13 ]
  • What is the impact on the customer of the bug?

Housekeeping task. We need to switch IPS image configuration to use new 4.x release specific set of UC repositories.

  • What is the cost/risk of fixing the bug?

Low to moderate risk. Need to replace repository URLs and verify that UC client bootstrap continues to work as expected with new native/non-native repository separation.

  • Is there an impact on documentation or message strings?

No impact on message strings, some impact on documentation if it explicitly references repository URLs.

  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

Installer and UC client bootstrap testing.

  • Which is the targeted build of 4.0 for this fix?

b87

  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.

N/A

Comment by Tom Mueller [ 30/Apr/13 ]

Approved for 4.0.

Comment by Snjezana Sevo-Zenzerovic [ 01/May/13 ]

Unfortunately, hit an issue with client bootstrap from non-preferred repository, will update the issue once we complete the analysis.

Comment by Snjezana Sevo-Zenzerovic [ 07/May/13 ]

Bootstrap issue related to the client bootstrap from non-preferred repository has been tracked to the bootstrap bug which will be fixed in subsequent UC 2.3 update release. In order to avoid integrating new UC update release, we decided to apply the workaround which is to perform explicit catalog refresh prior to running client bootstrap. Workaround has been applied to installer configuration code and to the private copy of bootstrap scripts which are added to GlassFish packager.

Checked into trunk as revisions 61841 and 61869. 4.0 branch merge and verification in progress.

Comment by Snjezana Sevo-Zenzerovic [ 07/May/13 ]

Checked into 4.0 branch as revisions 61874 and 61875.

Keeping the RFE open until we make corresponding changes to SDK distribution assembly.

Comment by Snjezana Sevo-Zenzerovic [ 29/May/13 ]

SDK repository configuration updated in SDK b88. Resolving the issue.





[GLASSFISH-18650] Memory leak with tag-files and CDI enabled Created: 20/Apr/12  Updated: 03/Aug/14  Resolved: 07/May/13

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

Type: Bug Priority: Minor
Reporter: enrico_olivelli Assignee: kchung
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

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


Attachments: Zip Archive StressTags.zip    

 Description   

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

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

This is a memory leak which leads to OutOfMemoryErrors very quickly



 Comments   
Comment by enrico_olivelli [ 20/Apr/12 ]

attaching a simple test case

Comment by enrico_olivelli [ 20/Apr/12 ]

Steps to reproduce:

  • run the sample project
  • run the test
  • take and heap dump of Glassfish
  • look for "mytag" instances
Comment by enrico_olivelli [ 14/Jul/12 ]

any news on this issue ?

Comment by pukkaone [ 07/Dec/12 ]

A custom tag implemented as a Simple Tag Handler by extending the SimpleTagSupport convenience class also exhibits exactly the same symptoms.

Comment by Sivakumar Thyagarajan [ 10/Dec/12 ]

Transferring this issue to JJ Snyder.

Comment by shreedhar_ganapathy [ 19/Apr/13 ]

Hi JJ
The issue is fairly old. Is this issue reproducible with latest builds?
Could you provide an update?

Comment by mtaube [ 23/Apr/13 ]

This is still happening on the latest build. WebContainer.createTagHandlerInstance is causing ManagedBeanManagerImpl.createManagedBean to be called to instantiate the tag, but the corresponding .destroyManagedBean is never called, hence the leak.

Comment by Martin Grebac [ 24/Apr/13 ]

Why was this assigned to me?

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

The calling stack is as follows:

 com.sun.enterprise.web.WebContainer.createTagHandlerInstance(WebContainer.java:1043)
	at com.sun.enterprise.web.jsp.ResourceInjectorImpl.createTagHandlerInstance(ResourceInjectorImpl.java:104)
	at org.apache.jsp.index_jsp._jspx_meth_my_mytag_0(index_jsp.java:86)
	at org.apache.jsp.index_jsp._jspService(index_jsp.java:63)
	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)

I see ResourceInjectorImpl#preDestroy which is not invoked.

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

Assign to Kinman to further to investigate the jsp part.

Comment by kchung [ 29/Apr/13 ]

The JSP compiler is generating calls to the injection manager to process annotations when the tag file instance is created, without calling preDestroy after doTag, causing memory leaks. This is wrong, because annotations are not supported for JSP tag files. Removing the calls to the injection manager should fix this problem.

Comment by kchung [ 30/Apr/13 ]

Upon closer examination, I failed to see the reported memory leakage.

Running the test quickly lead to "error:java.net.NoRouteToHostException: Can't assign requested address", probably due too many open connections.

The memory usage when running the test did increase monotonically, but at a rate that is acceptable, due probably to unclosed open connections. The behavior is similar for plain JSP pages, not just for tag files.

As far as I can tell, the buffer is released after the request returns.

There is still the issue of calling the injection manager unnecessarily. This should be fixed in a future release.

Comment by mtaube [ 30/Apr/13 ]

I saw the java.net.NoRouteToHostException happen on MacOS, just add a Thread.sleep(500) to the loop in the test and that problem goes away.

Comment by jjsnyder83 [ 30/Apr/13 ]

Tag libraries are supported for cdi integration. There is a cdi tck test for this so disabling it will cause the cdi tck to fail. Please do not disable it! Also I think acustom tag implemented as a Simple Tag Handler by extending the SimpleTagSupport convenience class also exhibits exactly the same symptoms.

Comment by aosama [ 02/May/13 ]

guys i am facing the same issue , the tag handler is eating up the memory real quick

can we have a quick fix for this

Comment by kchung [ 03/May/13 ]

I am sending you a patch that may fix your issue. Can your give it a try and let me know?

Comment by kchung [ 03/May/13 ]

Oops! aosama, what's your email? You can send that info to kinman.chung@oracle.com. Thanks.

Comment by aosama [ 05/May/13 ]

hi kim, i dropped u a note hope u got my email its aosama [at] gmail [dot] com

Comment by kchung [ 07/May/13 ]

Fixed in 4.0 and trunk.

There are two parts to the fix.

1. ResourceInjector will not be invoked for tag files.
2. ResourceInjector.preDestroy is called for
a. tags that extend SimpleTagSupport, and
b. classic tag hanlder
1. with tag pooling on (default), when the app exits
2. with tag pooling off, at end tag

i

Comment by slominskir [ 05/Jun/14 ]

I can confirm the attached test case passes in 4.0, but if you add parameters to the tag a memory leak occurs. I've created a new issue: GLASSFISH-21083.





Generated at Tue Jun 30 12:43:18 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.