[GLASSFISH-20516] Uptake Weld 2.0.0.SP1 Created: 13/May/13  Updated: 14/May/13  Resolved: 14/May/13

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

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

Tags: 4_0-approved

 Comments   
Comment by jjsnyder83 [ 13/May/13 ]

What is the impact on the customer of the bug?
CDI causing severe memory leak. See https://java.net/jira/browse/GLASSFISH-20474

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...SP1 only addresses this leak.

Is there an impact on documentation or message strings?
No

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
See https://java.net/jira/browse/GLASSFISH-20474

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

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 [ 13/May/13 ]

Approved for 4.0.

Comment by jjsnyder83 [ 14/May/13 ]

Fixed by uptake of Weld 2.0.0.SP1
Committed on trunk: revision 61974.
Committed on 4.0: revision 61975.





[GLASSFISH-20510] URISyntaxException getting monitoring data Created: 11/May/13  Updated: 19/Sep/14  Resolved: 06/Jun/13

Status: Resolved
Project: glassfish
Component/s: monitoring
Affects Version/s: 4.0_b88_RC4
Fix Version/s: 4.0_b89_RC5, 4.1

Type: Bug Priority: Critical
Reporter: marina vatkina Assignee: Tim Quinn
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-20613 Need to improve fix to URISyntaxExcep... Resolved
Tags: 4_0-approved

 Description   

1. start GF and derby
2. asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.ejb-container=HIGH
3. In devtests/ejb/timer/timertests do 'ant build deploy run'
4. asadmin get -m "*"
remote failure: Error during authorization
java.net.URISyntaxException: Illegal character in path at index 100: admin:/server/applications/ejb-timer-service-app/TimerBean/bean-methods/countTimersOwnedByServerIds-[Ljava%5C/lang%5C/String;/dotted-name
Command get failed.

Full stack trace:
java.net.URISyntaxException: Illegal character in path at index 100: admin:/server/applications/ejb-timer-service-app/TimerBean/bean-methods/countTimersOwnedByServerIds-[Ljava%5C/lang%5C/String;/dotted-name
at java.net.URI$Parser.fail(URI.java:2829)
at java.net.URI$Parser.checkChars(URI.java:3002)
at java.net.URI$Parser.parseHierarchical(URI.java:3086)
at java.net.URI$Parser.parse(URI.java:3034)
at java.net.URI.<init>(URI.java:824)
at com.sun.enterprise.admin.util.CommandSecurityChecker.resourceURIFromAccessCheck(CommandSecurityChecker.java:363)
at com.sun.enterprise.admin.util.CommandSecurityChecker.checkAccessRequired(CommandSecurityChecker.java:253)
at com.sun.enterprise.admin.util.CommandSecurityChecker.authorize(CommandSecurityChecker.java:193)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1203)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: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$1.service(JerseyContainerCommandService.java:169)
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)



 Comments   
Comment by Tim Quinn [ 13/May/13 ]

Because command authorization is involved here, I looked at this problem. With Marina's suggestion to add

asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.ejb-container=HIGH

before trying the "asadmin get" command, I was able to reproduce the problem.

This seems to be a new failure that does not seem to be related to a change in command authorization itself.

The "get" command creates AccessCheck objects dynamically based on what specific data is retrieved (rather than, for example, using the @AccessRequired annotation which would require knowing at build-time what resource name is being accessed). As part of creating the AccessCheck object, the resource name is converted into a URI which the authorization service can consume.

For the "get" command the resource name is derived from the dotted name of the data item being accessed. In this case, the dotted name is

"server.applications.ejb-timer-service-app.TimerBean.bean-methods.countTimersOwnedByServerIds-[Ljava\.lang\.String;.dotted-name"

It's the MonitoringReporter class which converts the dotted names into resource names. Up until now at least the dotted names processed during "get" have been valid Java identifiers, so that class's getAccessChecks method did not need to do any URI encoding to handle special characters.

Is this dotted name what's intended? If so, then the MonitoringReporter.getAccessChecks method can be revised to encode the URI.

If not then whatever is creating the dotted name should be changed to create a valid string.

Comment by marina vatkina [ 13/May/13 ]

Fixed the steps in the description.

Comment by Byron Nevins [ 13/May/13 ]

Following the instructions this looks fishy –

--libraries $

{libraries}

Is this right?


deploy-common-pe:
[exec] asadmin --host localhost --port 4848 --user admin --passwordfile /Users/wnevins/dev/v2/appserv-tests/config/adminpassword.txt --interactive=false --echo=true --terse=true deploy --libraries ${libraries}

--force=false --precompilejsp=false --verify=false --retrieve /Users/wnevins/dev/v2/appserv-tests/build/module/archive --generatermistubs=false --availabilityenabled=false --asyncreplication=true --target server --keepreposdir=false --keepfailedstubs=false --isredeploy=false --logreportederrors=true --_classicstyle=false /Users/wnevins/dev/v2/appserv-tests/build/module/archive/ejb-timer-timertestsApp.ear
[exec] Application deployed with name ejb-timer-timertestsApp.
[echo] Deployment on target server server successful

Comment by marina vatkina [ 13/May/13 ]

This doesn't affect monitoring

Comment by Byron Nevins [ 13/May/13 ]

This probably has nothing to do with Monitoring, and everything to do with the authorization code that was added to the get command.

Comment by Byron Nevins [ 13/May/13 ]

Analysis:

EjbMonitoringUtils.stringify() – it sets the name of the probe to be the method name with the args appended.

If the args happen to have an array then a "[" character will be in the name.
Which URI parsing code barfs on and throws an Exception.
The security code doesn't handle that exception – it just reports it and the command fails.

It is unusual to create a probe name in this fashion. It is only done by ejb-container.
Nevertheless I think that the security code ought to handle it in any case – even if the above method is changed to NOT put "[" into names.

– that's why I've assigned it to Tim.

Marina could provide a work-around by not allowing the "[" into names by,say, search & replace of that character with something else.

Note:
The probes of interest are in ejb container ->

~/dev/bg/main/appserver/ejb> tg countTimersOwnedByServerIds
/Users/wnevins/dev/bg/main/appserver/ejb/ejb-full-container/src/main/java/org/glassfish/ejb/persistent/timer/PersistentEJBTimerService.java[189]:
totalTimers = timerLocal_.countTimersOwnedByServerIds(serverIds);
/Users/wnevins/dev/bg/main/appserver/ejb/ejb-full-container/src/main/java/org/glassfish/ejb/persistent/timer/TimerBean.java[588]:
public String[] countTimersOwnedByServerIds(String[] serverIds) {
/Users/wnevins/dev/bg/main/appserver/ejb/ejb-full-container/src/main/java/org/glassfish/ejb/persistent/timer/TimerLocal.java[148]:
String[] countTimersOwnedByServerIds(String[] serverIds);

Comment by Byron Nevins [ 13/May/13 ]

Note that this issue is a great candidate for adding a permanent regression Dev Test...

Comment by Byron Nevins [ 13/May/13 ]

I made a simple change/built/tested. It fixes the problem just fine:

I did NOT check it in though...

~/dev/v2/appserv-tests/devtests/ejb/timer/timertests> getm "*" | wc -l
8525

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

Index: src/main/java/com/sun/ejb/monitoring/stats/EjbMonitoringUtils.java
===================================================================
— src/main/java/com/sun/ejb/monitoring/stats/EjbMonitoringUtils.java (revision 61944)
+++ src/main/java/com/sun/ejb/monitoring/stats/EjbMonitoringUtils.java (working copy)
@@ -133,6 +133,7 @@
sb.append(SEP).append(c.getName().replaceAll("_", "
."));
}
String result = sb.toString().replaceAll("
.", "\\\\.");
+ result = StringUtils.replace(result, "[", "_ARRAY_");
if (_logger.isLoggable(Level.FINE))

{ _logger.fine("==> Converted method String: " + result); }
Comment by Byron Nevins [ 13/May/13 ]

In case you use my work-around code change in the previous comment, you'd also need this import:

import com.sun.enterprise.util.StringUtils;

Comment by Tim Quinn [ 14/May/13 ]

I expect we will use standard URI encoding to deal with this.

Comment by Tim Quinn [ 14/May/13 ]

What is the impact on the customer of the bug?
The 'asadmin get -m ' command can incorrectly report an authorization failure, depending on what monitored properties are being accessed.

How likely is it that a customer will see the bug and how serious is the bug?
This is a regression which causes at least one EJB devtest to fail.

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 - We will use the standard Java SE URLEncoding class to encode the URI that is based on the property.

Is there an impact on documentation or message strings?
No

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
Any tests which use asadmin commands. (The EJB devtest which Marina described earlier will show whether the bug has been fixed or not.)

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

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 [ 14/May/13 ]

Approved for 4.0.

Comment by Tim Quinn [ 14/May/13 ]

Fixes checked into the branch and the trunk.

Project: glassfish
Repository: svn
Revision: 61977
Author: tjquinn
Date: 2013-05-14 14:55:27 UTC
Link:

Log Message:
------------
Fix for GLASSFISH-20510 URISyntaxException getting monitoring data

The "get" command, as some other asadmin commands, must compute the admin security access checks dynamically based on exactly which resources that invocation of the command accesses. The CommandSecurityChecker class then submits each individual resource separately to the authorization service, passing each resource as a URI. In the case of "get" the resource names come from the dotted names for the items reported.

Some EJB monitoring probes (reported using 'get -m "*"' for example) contain characters that are not legal in a URI, but CommandSecurityChecker did not encode such names.

With this fix, such encoding takes place using the standard SE URLEncoding class. The effect is a no-op if the resource name already conforms to URI/URL rules and encodes the resource name otherwise.

Approved for 4.0: Tom
Reviewed: Tom
Test: Passed QL tests, the sequence of commands identified by Marina in the issue

Revisions:
----------
61977

Modified Paths:
---------------
branches/4.0/nucleus/admin/util/src/main/java/com/sun/enterprise/admin/util/CommandSecurityChecker.java

======
Revisions:
----------
61976

Modified Paths:
---------------
trunk/main/nucleus/admin/util/src/main/java/com/sun/enterprise/admin/util/CommandSecurityChecker.java

Comment by Tim Quinn [ 06/Jun/13 ]

The change I made earlier side-stepped the problem but in a way that causes problems in the resource names that are constructed for admin access control. The problem does NOT affect 4.0 but should be fixed.

Comment by Tim Quinn [ 06/Jun/13 ]

I decided to open a new issue, targeting a release after 4.0, rather than confusing the sequence of events on the old issue.





[GLASSFISH-20499] Potential IllegalStateException in form based login Created: 10/May/13  Updated: 10/May/13  Resolved: 10/May/13

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

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

Tags: 4_0-approved

 Description   

In FormAuthenticator#forwardToLoginPage, it has the following:

        if (isChangeSessionIdOnAuthentication()) {
            request.changeSessionId();
        }

This is a potential IllegalStateException here as session may be null.



 Comments   
Comment by Shing Wai Chan [ 10/May/13 ]

fix in trunk
Sending web-core/src/main/java/org/apache/catalina/authenticator/FormAuthenticator.java
Transmitting file data .
Committed revision 61945.

Comment by Shing Wai Chan [ 10/May/13 ]
  • What is the impact on the customer of the bug?
    a possible IllegalStateException when there is no session created for a form based login application
  • What is the cost/risk of fixing the bug?
    low. One line fix
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    SQE web tests
  • Which is the targeted build of 4.0 for this fix?
    4.0_b89
  • 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 Shing Wai Chan [ 10/May/13 ]

port fix to 4.0 branch
Sending src/main/java/org/apache/catalina/authenticator/FormAuthenticator.java
Transmitting file data .
Committed revision 61946.





[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-20474] PSR:PERF Major memory leak in EJB app when implicit CDI is enabled Created: 06/May/13  Updated: 14/May/13  Resolved: 14/May/13

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

Type: Bug Priority: Critical
Reporter: amitagarwal 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   

We have a micro benchmark that creates, invokes and deletes local session beans. In latest build 87 (as well as on latest nightly) we noticed old gen quickly gets filled up resulting into continuous Full GCs. This degrades throughput by almost 100%. Class histogram shows that object[] and jboss related objects are quite high in count,

num #instances #bytes class name
----------------------------------------------
1: 6948972 426066232 [Ljava.lang.Object;
2: 6890964 275638560 org.jboss.weld.context.CreationalContextImpl
3: 6890799 220505568 org.jboss.weld.context.SerializableContextualFactory$PassivationCapableSerializableContextual
4: 6943875 166653000 java.util.ArrayList
5: 6891146 165387504 java.util.Collections$SynchronizedRandomAccessList
6: 6890799 165379176 org.jboss.weld.context.SerializableContextualInstanceImpl
7: 112215 16187000 <constMethodKlass>
8: 112215 15273944 <methodKlass>
9: 164287 14696232 [C
10: 13927 13510664 [I
11: 11519 12491400 <constantPoolKlass>
12: 11519 8483480 <instanceKlassKlass>
13: 9661 6845568 <constantPoolCacheKlass>
14: 54051 4324080 java.lang.reflect.Method



 Comments   
Comment by marina vatkina [ 06/May/13 ]

This might be a CDI issue. Can you try disabling CDI scanning to see if it makes any difference?

Comment by Scott Oaks [ 06/May/13 ]

Setting cdi-server.emable-implicit-cdi=false eliminates the memory leak.

The leak is ultimately held by the eventListeners of the WebModule – the WelListener holds an httpConvesationContext, which holds a creationalContext, which holds a CreatinalContextImpl, which holds a huge ArrayList of the SerializeableContextualInstanceImpl objects.

Comment by jjsnyder83 [ 06/May/13 ]

Can you send me the app please? j.j.snyder@oracle.com

Comment by jjsnyder83 [ 07/May/13 ]

This looks like a memory leak in Weld. I have sent the application along with relevant information to JBoss asking for their opinion.

Comment by jjsnyder83 [ 09/May/13 ]

The same leak appears to happen in JBoss application server too.
See https://issues.jboss.org/browse/WELD-1425

Comment by jjsnyder83 [ 13/May/13 ]

What is the impact on the customer of the bug?
CDI causing severe memory leak.

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...SP1 only addresses this leak.

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 application in this jira.

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

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 [ 13/May/13 ]

Approved for 4.0.

Comment by jjsnyder83 [ 14/May/13 ]

Fixed by uptake of Weld 2.0.0.SP1
Committed on trunk: revision 61974.
Committed on 4.0: revision 61975.





[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-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-20455] Updated 3RD-PARTY-LICENSE.txt and 3RD-PARTY-LICENSE-WEB-PROFILE.txt Created: 02/May/13  Updated: 15/May/13  Resolved: 15/May/13

Status: Resolved
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0_b87_RC3
Fix Version/s: 4.0_b89_RC5

Type: Bug Priority: Blocker
Reporter: Joe Di Pol Assignee: michael.y.chen
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 updated content for 3RD-PARTY-LICENSE.txt and 3RD-PARTY-LICENSE-WEB-PROFILE.txt.



 Comments   
Comment by michael.y.chen [ 07/May/13 ]

3rd party license file update. This is a must have. txt file update with no risk.

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

Nancy and I are working on this. We should have this done by 5/13.

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

The 3rd party license files are delivered to RE. They will include it in the build.

Comment by Romain Grécourt [ 14/May/13 ]

3 party files are actually part of the source tree, see https://svn.java.net/svn/glassfish~svn/branches/4.0/appserver/packager/legal/src/main/resources/glassfish/legal/

Re-opening, the right way is to update those license files properly.

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

Licenses checked into GlassFish trunk and branch workspaces (which is prerequisite for GF b89). Keeping the issue open until RI workspace checkin is complete.

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

Updated 3rd party licenses checked into RI branch and trunk workspaces.





[GLASSFISH-20453] WebPipeline is not invoked Created: 01/May/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: None
Fix Version/s: 4.0_b87_RC3

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

Tags: 4_0-approved

 Description   

The WebPipeline is not invoked in GlassFish 4.0.



 Comments   
Comment by Shing Wai Chan [ 01/May/13 ]
  • What is the impact on the customer of the bug?
    WebPipeline is not invoked. Some functionality may be missing.
  • What is the cost/risk of fixing the bug?
    Add back the WebPipeline as in 3.1.1.
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    SQE web tests
  • Which is the targeted build of 4.0 for this fix?
    4.0_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 Shing Wai Chan [ 01/May/13 ]

Sending web-glue/src/main/java/com/sun/enterprise/web/BasePersistenceStrategyBuilder.java
Transmitting file data .
Committed revision 61790.





[GLASSFISH-20451] Authenticated user principal is not cached in the web session after initial successful authentication by a JASPIC ServerAuthModule (SAM) Created: 01/May/13  Updated: 04/May/13  Resolved: 04/May/13

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

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

Tags: 4_0-approved

 Description   

This is related to https://java.net/jira/browse/GLASSFISH-20317, which has more detail.
First request to a protected resource gets authenticated successfully by the SAM.
On the second request, the SAM tries to retrieve the user principal from request.getUserPrincipal() and gets null. However on the third request, request.getUserPrincipal() returns the correct principal in SAM's validateRequest() method!



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

After the ServerAuthModule validates the request, a WebPrincipal is created. At this time the container tries to cache
the principal in the session( AuthenticatorBase.register() ). However the session has not yet been created! The session will not be created until much later when the jsp's service method is invoked.
When the second request comes in, the test SAM attemps to retrieve the user principal from the request/session(which wasn't saved in the first request). As a result the test SAM carries out the authentication again and this time it finds a session(thanks to the late session creation near the end of the first request) and the principal gets cached in the session as intended.
On the third and subsequent requests, the principal is always there as long as the session has not expired. I think the fix is to properly create a session early enough so it is available when AuthenticatorBase.register() is called.

Comment by Shing Wai Chan [ 02/May/13 ]

With the latest code in trunk (with the fix GLASSFISH-20453), I see a different behavior for the test posted in https://java.net/jira/browse/GLASSFISH-20317 .

In RealmAdapter#validate, we have the following code:

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

In the first two accesses of protected/a.jsp, we are in the "if" case above and hence, we have "non-null" principal and #isUserInRole("architect") = true.
In the third access of protected/a.jsp, we are in the "else" case above and have a "non-null" principal and #isUserInRole("architect") = false, hence 403.

From the debugger, I notice the value of #isUserInRole will change after calling proxy.authenticate.

I also find that if I access index.jsp first and then to protected/a.jsp, the result is the same.

Assign the issue to security for further investigation.

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

What is the impact on the customer of the bug?
This is related to https://java.net/jira/browse/GLASSFISH-20317.
It is necessary to fix this first in order to fix GLASSFISH-20317.

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?
JASPIC related and SQE web tests

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 quang.dang [ 04/May/13 ]

/branches/4.0/appserver/security/webintegration/src/main/java/com/sun/web/security/RealmAdapter.java
Rev. 61824

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

Sending appserver/security/webintegration/src/main/java/com/sun/web/security/RealmAdapter.java
Transmitting file data .
Committed revision 61828.
(trunk)





[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-20448] Tyrus 1.0 integration Created: 01/May/13  Updated: 06/May/13  Resolved: 06/May/13

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

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

Tags: 4_0-approved

 Description   

Integration of Tyrus-1.0, already added to promoted repo:

dhcp-prague08-third-floor-10-163-26-14:main stepan$ svn diff
Index: appserver/pom.xml
===================================================================
— appserver/pom.xml (revision 61782)
+++ appserver/pom.xml (working copy)
@@ -122,7 +122,7 @@
<weld.version>2.0.0.Final</weld.version>
<wsdl4j.version>1.6.2</wsdl4j.version>
<websocket-api.version>1.0</websocket-api.version>

  • <tyrus.version>1.0-rc4</tyrus.version>
    + <tyrus.version>1.0</tyrus.version>
    <jsonp.version>1.0</jsonp.version>
    <concurrent-api.version>1.0-b06</concurrent-api.version>
    <concurrent.version>1.0-b08</concurrent.version>


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

Approved for 4.0.





[GLASSFISH-20444] EclipseLink MOXy bundle throws CNFE in Web Profile due to unsatisfied javax.xml.bind package import Created: 30/Apr/13  Updated: 09/May/13  Resolved: 09/May/13

Status: Closed
Project: glassfish
Component/s: jax-rs
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0

Type: Bug Priority: Blocker
Reporter: Jakub Podlesak Assignee: Jakub Podlesak
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-20445 org.eclipse.persistence.moxy bundle h... Open
Tags: 4_0-approved

 Description   

This was revealed when integrating final Jersey 2.0 bits into GF. (Jersey auto-discoverable MOXy providers has been enabled in the final Jersey 2.0 version)

Following is an excerpt from modules/org.eclipse.persistence.moxy.jar:

Import-Package: com.sun.xml.bind;resolution:=optional,com.sun.xml.bind
 .annotation;resolution:=optional,javax.activation;resolution:=optiona
 l,javax.ws.rs;resolution:=optional,javax.ws.rs.core;resolution:=optio
 nal,javax.ws.rs.ext;resolution:=optional,javax.xml.bind;version="2.0.
 0";resolution:=optional,javax.xml.bind.annotation;version="2.0.0";res
 olution:=optional,javax.xml.bind.annotation.adapters;version="2.0.0";
 resolution:=optional,javax.xml.bind.attachment;version="2.0.0";resolu
 tion:=optional,javax.xml.bind.helpers;version="2.0.0";resolution:=opt
 ional

javax.xml.bind.* packages should not be marked optional, but that is IMHO only a minor bug,
that i am going to file separately.

Now in the full GlassFish profile, the java.xml.bind dependency gets resolved just fine from the bundled JAXB implementation:

gogo$ inspect p r 216 | grep jaxb
javax.xml.bind.annotation.adapters; version=2.2.7 -> jaxb-api [2]
javax.xml.bind.annotation; version=2.2.7 -> jaxb-api [2]
javax.xml.bind.attachment; version=2.2.7 -> jaxb-api [2]
javax.xml.bind; version=2.2.7 -> jaxb-api [2]
javax.xml.bind.helpers; version=2.2.7 -> jaxb-api [2]
gogo$

While in web profile distribution, JAXB is taken from the Java runtime, and exported with the default
version (0.0.0.0), which leaves the import unsatisfied:

gogo$ inspect p r 166 | grep jaxb
gogo$
gogo$ inspect p r 166
org.eclipse.persistence.moxy [166] imports packages:
----------------------------------------------------
javax.activation; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.namespace; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.stream; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.transform; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.transform.dom; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.transform.sax; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.transform.stax; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.transform.stream; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.validation; version=0.0.0 -> org.apache.felix.framework [0]
org.w3c.dom; version=0.0.0 -> org.apache.felix.framework [0]
org.xml.sax; version=0.0.0 -> org.apache.felix.framework [0]
javax.ws.rs; version=2.0.0 -> javax.ws.rs-api [112]
javax.ws.rs.core; version=2.0.0 -> javax.ws.rs-api [112]
javax.ws.rs.ext; version=2.0.0 -> javax.ws.rs-api [112]
org.eclipse.persistence.internal.libraries.asm; version=3.3.1 -> org.eclipse.persistence.asm [160]
...


 Comments   
Comment by Jakub Podlesak [ 30/Apr/13 ]

The following patch resolves the bug for me:

Index: nucleus/osgi-platforms/felix/src/main/resources/config/osgi.properties
===================================================================
--- nucleus/osgi-platforms/felix/src/main/resources/config/osgi.properties      (revision 61743)
+++ nucleus/osgi-platforms/felix/src/main/resources/config/osgi.properties      (working copy)
@@ -410,12 +410,12 @@

 endorsed-standard-packages=\
  javax.annotation, \
- javax.xml.bind, \
- javax.xml.bind.annotation, \
- javax.xml.bind.annotation.adapters, \
- javax.xml.bind.attachment, \
- javax.xml.bind.helpers, \
- javax.xml.bind.util, \
+ javax.xml.bind;version="2.0.0", \
+ javax.xml.bind.annotation;version="2.0.0", \
+ javax.xml.bind.annotation.adapters;version="2.0.0", \
+ javax.xml.bind.attachment;version="2.0.0", \
+ javax.xml.bind.helpers;version="2.0.0", \
+ javax.xml.bind.util;version="2.0.0", \
  javax.jws, \
  javax.jws.soap, \
  javax.xml.ws, \
Comment by Jakub Podlesak [ 30/Apr/13 ]

Including also excerpt from the server.log, when the bug was first revealed:

java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2442)
	at java.lang.Class.privateGetPublicMethods(Class.java:2562)
	at java.lang.Class.getMethods(Class.java:1427)
	at org.glassfish.jersey.server.model.MethodList.getMethods(MethodList.java:106)
	at org.glassfish.jersey.server.model.MethodList.<init>(MethodList.java:93)
...
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBException not found by org.eclipse.persistence.moxy [168]
	at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1532)
	at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
	at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
Comment by Jakub Podlesak [ 30/Apr/13 ]

Increased priority, as this bug actually blocks Jersey 2.0 final bits integration into GlassFish.

Comment by Jakub Podlesak [ 01/May/13 ]

Added 4_0-review tag, required info for the review follow:

  • What is the impact on the customer of the bug?
  • Jersey 2.0 can not be integrated without this bug being resolved (full profile would be fine, but there are ql test failures in the web profile)
  • MOXy JAX-RS providers will not work in web profile
  • What is the cost/risk of fixing the bug?
  • a patch is already available, certain risk is there as quite a low level layer is affected, however all ql tests has passed with the patch applied
  • Is there an impact on documentation or message strings?
  • There is no such impact.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
  • JAXB related tests
  • Which is the targeted build of 4.0 for this fix?
  • b87
Comment by Sanjeeb Sahoo [ 01/May/13 ]

Jakub,

I don't know who is responsible for integrating moxy, so I am assigning this to you so that you can reassign if need be. We don't export Java SE packages with versions as SE team does not maintain package versions. They release the whole platform as one version. So, we only version packages that we distribute via our modules. In case moxy can't modify its import to relax the version constraint, I suggest we use a framework extension bundle as discussed in [1] to satisfy its requirement when running in GlassFish environment.

Sahoo

[1] https://weblogs.java.net/blog/ss141213/archive/2009/05/use_of_framewor.html?force=357

Comment by blaise_doughan [ 01/May/13 ]

Sahoo,

The Full Profile doesn't require the extension bundle, shouldn't the Web Profile be changed to match the Full Profile WRT the JAXB dependency instead of pulling it from Java SE?

-Blaise

Comment by Sanjeeb Sahoo [ 02/May/13 ]

No, we don't want to override JAXB in web profile when Java SE provided one is sufficient. Actually, thinking more, there is even a better alternative, but that will require change to moxy. If moxy makes the following change, then we would be fine as well:

Let moxy import JAXB packages with version = 0.0.0. Some had objected that it would mean someone can actually try to run it with JAXB1 and face issues. To avoid that, moxy bundle can add the following header:

Bundle-RequiredExecutionEnvironment: JavaSE-1.6

This would mean that it can run on Java SE 6 and above and all those JREs include JAXB 2. It would prevent moxy to resolve on lesser JREs.

Thanks,
Sahoo

Comment by Jakub Podlesak [ 02/May/13 ]

The above suggestion relies on the fact JAXB packages are exported from the system bundle, but it is not guaranteed IIUC.
So the import could still fail. Also the fact that while JAXB 2.0 is required by the MOXy bundle, it's import
header would state the JAXB version does not matter is alarming. The only thing that needs to be fixed in the MOXy bundle
headers is IMHO to remove the optional import parameter.

Comment by Sanjeeb Sahoo [ 02/May/13 ]

Since there is no real standard governing JAXB package version, moxy requiring javax.xml.bind; version=2.0.0 can be troublesome for moxy bundle in some environment, where as dependence on an execution environment is a more portable solution with same effect. Moreover, it would require no changes in glassfish side. Having said that I just noticed that moxy depends on com.sun.xml.bind, so for that to resolve we may need a framework extension anyway. So, I will let someone experiment to chose one of the alternatives.

Comment by Jakub Podlesak [ 03/May/13 ]

Sending appserver/packager/glassfish-jpa/pom.xml
Adding appserver/persistence/jaxb-exporting-fragment
Adding appserver/persistence/jaxb-exporting-fragment/pom.xml
Sending appserver/persistence/pom.xml
Sending appserver/web
Sending nucleus/pom.xml
Transmitting file data ....
Committed revision 61822.

Fix based on the newly introduced system fragment submitted together with the final 2.0 Jersey integration.

Comment by Jakub Podlesak [ 03/May/13 ]

Fix submitted.

Comment by Tom Mueller [ 03/May/13 ]

Please commit the change to the trunk also and correctly indicate the fixed versions in the fix version field.
When you resolve the bug, please indicate the revision for the trunk as well as the 4.0 branch.
Reopening the issue.

Comment by Jakub Podlesak [ 06/May/13 ]

The change has been backed out from the 4.0 and has never been submitted into the main trunk.
The rollback was done as the fix broke QL tests run against the full profile with security manager turned on.

Comment by Marek Potociar [ 09/May/13 ]

Jersey 2.0 integration has succeeded.





[GLASSFISH-20442] restore BeanValidatorNamingProxy to nucleus Created: 30/Apr/13  Updated: 30/Apr/13  Resolved: 30/Apr/13

Status: Closed
Project: glassfish
Component/s: bean-validator
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0_b87_RC3

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   

BeanValidatorNamingProxy was recently removed from nucleus, favoring an alternate implementation (in weld-integration) that integrates with CDI (since the Validator/ValidatorFactory needs to be retrieved from CDI when available). This is problematic in appclient distribution where the weld-integration module is not present.

The solution is to restore BeanValidatorNamingProxy and delegate to the weld-integration if available (implemented with @Inject @Optional @Named(...)).. This way, CDI will be interrogated for Validator objects if CDI is available, but the object will be returned either way.



 Comments   
Comment by mtaube [ 30/Apr/13 ]

This bug is causing the following CTS failure: com/sun/ts/tests/ejb30/misc/jndi/earjar/Client.java#beanValidator: Client_beanValidator

Comment by mtaube [ 30/Apr/13 ]

What is the impact on the customer of the bug?
appclients cannot look up Validator/ValidatorFactory from jndi

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

Is it a regression?
Yes.

Does it meet other bug fix criteria (security, performance, etc.)?
no.

What CTS failures are caused by this bug?
com/sun/ts/tests/ejb30/misc/jndi/earjar/Client.java#beanValidator: Client_beanValidator

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 – restores previous behavior and adds a delegation model

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

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
EJB, EJB cts, bean-validation CTS

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

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.
No.

Comment by mtaube [ 30/Apr/13 ]

Sending appserver/web/weld-integration/src/main/java/org/glassfish/weld/ValidationNamingProxy.java
Adding nucleus/core/kernel/src/main/java/org/glassfish/kernel/bean_validator/BeanValidatorNamingProxy.java
Transmitting file data ..
Committed revision 61753.





[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-20437] SFSB PreDestroy never commits during undeploy Created: 30/Apr/13  Updated: 30/Apr/13  Resolved: 30/Apr/13

Status: Resolved
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0_b87_RC3

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

Tags: 4_0-approved

 Description   

SFSB container calls PreDestroy during undeploy, but ContainerSynchronization prevents transaction completion.

  • What is the impact on the customer of the bug?
    PreDestroy behavior is not as described in the EJB spec
  • How likely is it that a customer will see the bug and how serious is the bug?
    If the code expects to flush data to the database, the data will be lost
  • Is it a regression?
    It's a missing part in the new functionality
  • Does it meet other bug fix criteria (security, performance, etc.)?
    no.
  • What CTS failures are caused by this bug?
    None.
  • 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?
    Minimal.
  • Is there an impact on documentation or message strings?
    no.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    EJB
  • Which is the targeted build of 4.0 for this fix?
    rc3.
  • 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.
    No.


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

Fixed by accounting for SFSB PreDestroy called in a transaction.
Sending src/main/java/com/sun/ejb/containers/ContainerSynchronization.java
Transmitting file data .
Committed revision 61740.





[GLASSFISH-20435] NullPointer exception in domain log on cluster or instance creation Created: 29/Apr/13  Updated: 30/Apr/13  Resolved: 30/Apr/13

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0_b87_RC3

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

Tags: 4_0-approved

 Description   

gf-transaction-cluster-devtest reports NPEs during "create-cluster" or "create-local-instance --cluster" call (the log reports various actions on different threads, and the instance log starts at 13:15:42.166-0700) for the 'selfrecovery' and 'autorecovery' tests in the transaction/ee suite. It doesn't happen in other tests.

These are the DAS server.log fragments:

1:

[2013-04-29T13:15:36.997-0700] [glassfish 4.0] [INFO] [membership.snapshot.analysis] [ShoalLogger] [tid: _ThreadID=108 _ThreadName=GMS ViewWindowThread Group-c1] [timeMillis: 1367266536997] [levelValue: 800] [[
GMS1016: Analyzing new membership snapshot received as part of event: JOINED_AND_READY_EVENT for member: server of group: c1]]

[2013-04-29T13:15:37.424-0700] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=55 _ThreadName=pool-8-thread-1] [timeMillis: 1367266537424] [levelValue: 1000] [[
Exception while processing config bean changes :
java.lang.NullPointerException
at java.lang.reflect.Proxy.getInvocationHandler(Proxy.java:656)
at org.jvnet.hk2.config.ConfigSupport.getImpl(ConfigSupport.java:246)
at com.sun.enterprise.v3.admin.listener.CombinedJavaConfigSystemPropertyListener$1.changed(CombinedJavaConfigSystemPropertyListener.java:249)
at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:288)
at com.sun.enterprise.v3.admin.listener.CombinedJavaConfigSystemPropertyListener.changed(CombinedJavaConfigSystemPropertyListener.java:195)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:400)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:390)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:280)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:278)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
]]

[2013-04-29T13:15:38.233-0700] [glassfish 4.0] [INFO] [NCLS-CLSTR-20001] [javax.enterprise.cluster.gms.bootstrap] [tid: _ThreadID=154 _ThreadName=pool-24-thread-1] [timeMillis: 1367266538233] [levelValue: 800] [[
Adding instance in1 to health history table.]]

2:
[2013-04-29T13:18:07.273-0700] [glassfish 4.0] [INFO] [membership.snapshot.analysis] [ShoalLogger] [tid: _ThreadID=240 _ThreadName=GMS ViewWindowThread Group-c1] [timeMillis: 1367266687273] [levelValue: 800] [[
GMS1016: Analyzing new membership snapshot received as part of event: JOINED_AND_READY_EVENT for member: server of group: c1]]

[2013-04-29T13:18:08.084-0700] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=234 _ThreadName=pool-49-thread-1] [timeMillis: 1367266688084] [levelValue: 1000] [[
Exception while processing config bean changes :
java.lang.NullPointerException
at java.lang.reflect.Proxy.getInvocationHandler(Proxy.java:656)
at org.jvnet.hk2.config.ConfigSupport.getImpl(ConfigSupport.java:246)
at com.sun.enterprise.v3.admin.listener.CombinedJavaConfigSystemPropertyListener$1.changed(CombinedJavaConfigSystemPropertyListener.java:249)
at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:288)
at com.sun.enterprise.v3.admin.listener.CombinedJavaConfigSystemPropertyListener.changed(CombinedJavaConfigSystemPropertyListener.java:195)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:400)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:390)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:280)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:278)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
]]

[2013-04-29T13:18:08.784-0700] [glassfish 4.0] [INFO] [NCLS-CLSTR-20001] [javax.enterprise.cluster.gms.bootstrap] [tid: _ThreadID=220 _ThreadName=pool-43-thread-1] [timeMillis: 1367266688784] [levelValue: 800] [[
Adding instance in1 to health history table.]]



 Comments   
Comment by Tom Mueller [ 30/Apr/13 ]

More information is needed on how to reproduce this issue.
I tried running the appserv-tests/devtests/transaction/ee tests by setting S1AS_HOME and APS_HOME and running "ant all", but the build fails. I tried just creating clustered instances and the message doesn't show up.
It would be helpful if the hudson job set "AS_LOGFILE" so that the commands that it executes would be recorded and the timestamps could be aligned with the server.log error messages.

Comment by marina vatkina [ 30/Apr/13 ]

The tests are executed by running 'ant all' (may be the S1AS_HOME and APS_HOME are not set properly?). The tests that report the NPE are 'selfrecovery' and 'autorecovery'

Comment by Tom Mueller [ 30/Apr/13 ]

To recreate the problem easily, do the following on a clean install:

asadmin start-domain
asadmin create-cluster c1
asadmin create-system-properties --cluster c1 a=b

The NullPointerException message is printed in the log during the 3rd command.

Comment by Byron Nevins [ 30/Apr/13 ]

Tom - Nice job turning it into a 3 command scenario. But #3 is wrong:

WRONG:
asadmin create-system-properties --cluster c1 a=b

RIGHT:
asadmin create-system-properties --target c1 a=b

Comment by Tom Mueller [ 30/Apr/13 ]
  • What is the impact on the customer of the bug?

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

If the customer adds a system property to a cluster config, they will see this NPE.

Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
No. This was there in 3.1.2 also.
What CTS failures are caused by this bug?
None.

  • 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. Just add checks for cluster==null in the right places.

  • Is there an impact on documentation or message strings?
    No
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Tests that set system properties.
  • Which is the targeted build of 4.0 for this fix?
    Next one.
  • 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 Tom Mueller [ 30/Apr/13 ]

Fixed on the trunk in revision 61757.





[GLASSFISH-20433] Faces Flows: Automatic enabling of client window mode doesn't work unless XML defined flows exists Created: 29/Apr/13  Updated: 07/May/13  Resolved: 07/May/13

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

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 3 hours, 20 minutes
Original Estimate: 2 hours

Tags: 4_0-approved

 Description   

ClientWindow mode must be enabled for Faces Flows to work.

The JSF spec requires that client window mode must be automatically enabled if one or more flows are detected. This automatic enabling only works if at least one of the flows is defined in XML.



 Comments   
Comment by Ed Burns [ 29/Apr/13 ]

The workaround is to manually enable ClientWindow mode in web.xml:

<context-param>
<param-name>javax.faces.CLIENT_WINDOW_MODE</param-name>
<param-value>url</param-value>
</context-param>

Comment by Ed Burns [ 29/Apr/13 ]
  • What is the impact on the customer of the bug?

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

This bug only shows up when using Faces Flows, and only when there are no XML based flows, only Java based flows.

Is it a regression?

No

Does it meet other bug fix criteria (security, performance, etc.)?

What CTS failures are caused by this bug?

None

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

How risky is the fix?

Minimal. Small change to one source file at a leaf node in the call stack.

How much work is the fix?

Use the same logic in the XML auto-enabling to achieve Java auto enabling.

Is the fix complicated?

No

  • Is there an impact on documentation or message strings?

No

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

Flow tests.

  • 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.

this is the main JIRA for this issue.

Comment by Ed Burns [ 29/Apr/13 ]

Index: jsf-ri/src/main/java/com/sun/faces/application/ApplicationAssociate.java
===================================================================
— jsf-ri/src/main/java/com/sun/faces/application/ApplicationAssociate.java (revision 11915)
+++ jsf-ri/src/main/java/com/sun/faces/application/ApplicationAssociate.java (working copy)
@@ -323,6 +323,9 @@
FlowDiscoveryCDIContext flowDiscoveryContext = (FlowDiscoveryCDIContext) beanManager.getContext(FlowDefinition.class);
List<Producer<Flow>> flowProducers = flowDiscoveryContext.getFlowProducers();
WebConfiguration config = WebConfiguration.getInstance();
+ if (!flowProducers.isEmpty())

{ + enableClientWindowModeIfNecessary(context); + }

for (Producer<Flow> cur : flowProducers)

{ Flow toAdd = cur.produce(beanManager.<Flow>createCreationalContext(null)); @@ -338,9 +341,26 @@ }
  • + private void enableClientWindowModeIfNecessary(FacesContext context) {
    +
    + WebConfiguration config = WebConfiguration.getInstance(context.getExternalContext());
    +
    + String optionValue = config.getOptionValue(WebConfiguration.WebContextInitParameter.ClientWindowMode);
    + boolean clientWindowNeedsEnabling = false;
    + if ("none".equals(optionValue))

    Unknown macro: {+ clientWindowNeedsEnabling = true;+ String featureName = + WebConfiguration.WebContextInitParameter.ClientWindowMode.getQualifiedName();+ LOGGER.log(Level.WARNING, + "{0} was set to none, but Faces Flows requires {0} is enabled. Setting to ''url''.", new Object[]{featureName});+ }

    else if (null == optionValue)

    { + clientWindowNeedsEnabling = true; + }

    + if (clientWindowNeedsEnabling)

    { + config.setOptionValue(WebConfiguration.WebContextInitParameter.ClientWindowMode, "url"); + }

    + }

  • }

public void initializeFacelets() {

Comment by Tom Mueller [ 29/Apr/13 ]

Approved for 4.0.

Comment by Ed Burns [ 29/Apr/13 ]

Running automated tests against this fix now.

Comment by Ed Burns [ 29/Apr/13 ]

Safe to integrate to GlassFish 4.0 when < http://slc03qna.us.oracle.com:7070/hudson/view/Mojarra%202.2/job/2_2_x-test-glassfish-4_0/97/ > and < http://hudson-sca.us.oracle.com/view/MOJARRA_ALL/job/MOJARRA_2_2_0_GLASSFISH_3_1_2_2_NO_CLUSTER/33/ > are clean.

Both are clean.

Comment by Ed Burns [ 07/May/13 ]

svn commit -m "Integrate Mojarra 2.2.0 Final and JSF API 2.2 Final" appserver/pom.xml
Sending appserver/pom.xml
Transmitting file data .
Committed revision 61873.





[GLASSFISH-20432] integrate javax.ejb-api:3.2 javax.transaction-api:1.2 Created: 29/Apr/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: glassfish
Component/s: None
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0_b87_RC3

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

Tags: 4_0-approved

 Description   

Integrate final version of ejb-api and transaction-api.
This requires CCP as we re-inlined the jaxrpc that ejb depends on inside the ejb-api jar. Hence we can get rid of javax.xml.rpc-api.jar in the webprofile.

Also, javax.management-j2ee-api had to be relaxed and javax.xml.rpc.jar was not importing its exported package making the OSGi runtime resolving improper wirings. (javax.ejb used instead of javax.xml.rpc jar)

Full diff:

Index: appserver/pom.xml
===================================================================
--- appserver/pom.xml	(revision 61733)
+++ appserver/pom.xml	(working copy)
@@ -70,15 +70,15 @@
         <mojarra.version>2.2.0-m15</mojarra.version>
         <jsf-ext.version>0.2</jsf-ext.version>
         <woodstock.version>4.0.2.10</woodstock.version>
-        <javax.ejb-api.version>3.2-b02</javax.ejb-api.version>
+        <javax.ejb-api.version>3.2</javax.ejb-api.version>
         <javax.interceptor-api.version>1.2</javax.interceptor-api.version>
-        <javax.xml.rpc-api.version>1.1</javax.xml.rpc-api.version>
-        <javax.transaction-api.version>1.2-b03</javax.transaction-api.version>
+        <javax.xml.rpc-api.version>1.1.1</javax.xml.rpc-api.version>
+        <javax.transaction-api.version>1.2</javax.transaction-api.version>
         <jaxws-api.version>2.2.8</jaxws-api.version>
         <javax.faces-api.version>2.2-m12</javax.faces-api.version>
         <cdi-api.version>1.1-PRD</cdi-api.version>
         <javax.inject.version>1</javax.inject.version>
-        <javax.resource-api.version>1.7-b05</javax.resource-api.version>
+        <javax.resource-api.version>1.7</javax.resource-api.version>
         <javax.enterprise.deploy-api.version>1.6</javax.enterprise.deploy-api.version>
         <javax.security.jacc-api.version>1.5</javax.security.jacc-api.version>
         <javax.security.auth.message-api.version>1.1</javax.security.auth.message-api.version>
@@ -129,7 +129,7 @@
         <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.xml.soap-api.version>1.3.5</javax.xml.soap-api.version>
-	<javax.management.j2ee-api.version>1.1</javax.management.j2ee-api.version>
+	<javax.management.j2ee-api.version>1.1.1</javax.management.j2ee-api.version>
     </properties>
 
     <modules>
@@ -277,11 +277,10 @@
                                 <artifactId>javax.transaction-api</artifactId>
                                 <version>${javax.transaction-api.version}</version>
                             </artifact>
-                            <nonFinal>true</nonFinal>
+                            <nonFinal>false</nonFinal>
                             <jarType>api</jarType>     
-                            <specVersion>1.1</specVersion>
-                            <newSpecVersion>1.2</newSpecVersion>
-                            <specBuild>03</specBuild>
+                            <specVersion>${javax.transaction-api.version}</specVersion>
+                            <specImplVersion>${javax.transaction-api.version}</specImplVersion>
                             <apiPackage>javax.transaction</apiPackage>
                         </spec>
                         <spec>
@@ -376,11 +375,10 @@
                                 <artifactId>javax.ejb-api</artifactId>
                                 <version>${javax.ejb-api.version}</version>
                             </artifact>
-                            <nonFinal>true</nonFinal>
+                            <nonFinal>false</nonFinal>
                             <jarType>api</jarType>
-                            <specVersion>3.1</specVersion>
-                            <newSpecVersion>3.2</newSpecVersion>
-                            <specBuild>02</specBuild>
+                            <specVersion>${javax.ejb-api.version}</specVersion>
+			    <specImplVersion>${javax.ejb-api.version}</specImplVersion>
                             <apiPackage>javax.ejb</apiPackage>
                         </spec>
                         <spec>
@@ -401,11 +399,10 @@
                                 <artifactId>javax.resource-api</artifactId>
                                 <version>${javax.resource-api.version}</version>
                             </artifact>
-                            <nonFinal>true</nonFinal>
+                            <nonFinal>false</nonFinal>
                             <jarType>api</jarType>
-                            <specVersion>1.6</specVersion>
-                            <newSpecVersion>1.7</newSpecVersion>
-                            <specBuild>05</specBuild>
+                            <specVersion>${javax.resource-api.version}</specVersion>
+			    <specImplVersion>${javax.resource-api.version}</specImplVersion>
                             <apiPackage>javax.resource</apiPackage>
                         </spec>
                         <spec>
@@ -429,7 +426,7 @@
                             <nonFinal>false</nonFinal>
                             <jarType>api</jarType>
                             <specVersion>1.1</specVersion>
-                            <specImplVersion>1.1</specImplVersion>
+                            <specImplVersion>${javax.xml.rpc-api.version}</specImplVersion>
                             <apiPackage>javax.xml.rpc</apiPackage>
                         </spec>
                         <spec>
@@ -453,7 +450,7 @@
                             <nonFinal>false</nonFinal>
                             <jarType>api</jarType>
                             <specVersion>1.1</specVersion>
-                            <specImplVersion>1.1</specImplVersion>
+                            <specImplVersion>${javax.management.j2ee-api.version}</specImplVersion>
                             <apiPackage>javax.management.j2ee</apiPackage>
                         </spec>
                         <spec>
Index: appserver/packager/glassfish-common-full/pom.xml
===================================================================
--- appserver/packager/glassfish-common-full/pom.xml	(revision 61733)
+++ appserver/packager/glassfish-common-full/pom.xml	(working copy)
@@ -213,7 +213,10 @@
             <groupId>org.glassfish</groupId>
             <artifactId>javax.enterprise.concurrent</artifactId>
         </dependency>
-       
+        <dependency>
+            <groupId>javax.xml.rpc</groupId>
+            <artifactId>javax.xml.rpc-api</artifactId>
+        </dependency>  
     </dependencies>
 </project>
 
Index: appserver/packager/glassfish-common-web/pom.xml
===================================================================
--- appserver/packager/glassfish-common-web/pom.xml	(revision 61733)
+++ appserver/packager/glassfish-common-web/pom.xml	(working copy)
@@ -337,11 +337,7 @@
         <dependency>
             <groupId>javax.transaction</groupId>
             <artifactId>javax.transaction-api</artifactId>
-        </dependency>
-        <dependency>
-            <groupId>javax.xml.rpc</groupId>
-            <artifactId>javax.xml.rpc-api</artifactId>
-        </dependency>        
+        </dependency>      
     </dependencies>
     
     <repositories>


 Comments   
Comment by Romain Grécourt [ 29/Apr/13 ]
  • What is the impact on the customer of the bug?
    No final API used in GF for EJB and Transaction

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

  • What is the cost/risk of fixing the bug?
    medium, it involves OSGi wiring solving + packaging change to have javax.xml.rpc-api.jar only in Full Profile.

How risky is the fix? How much work is the fix? Is the fix complicated?
Relatively easy.

  • Is there an impact on documentation or message strings?
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    QL wp and GP.
  • Which is the targeted build of 4.0 for this fix?
    RC3.
  • 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.
    osgi metadata, relaxing some imports and making sure bundles are well doing substitutable export.
Comment by Tom Mueller [ 29/Apr/13 ]

Approved for 4.0.

Comment by Romain Grécourt [ 01/May/13 ]

done with svn revision #61754





[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-20426] promoted artifact has wrong url Created: 29/Apr/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0_b87_RC3

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Romain Grécourt
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved

 Description   

org.glassfish.main/glassfish-parent/4.0-b84/glassfish-parent-4.0-b84.pom has following non-existent URL:

https://github.com/sonatype/jvnet-parent/glassfish-nucleus-parent/glassfish-parent/tags/4.0-b84/jvnet-parent/glassfish-nucleus-parent/glassfish-parent

This must be the case for other artifacts as well.



 Comments   
Comment by Romain Grécourt [ 29/Apr/13 ]
  • What is the impact on the customer of the bug?
    Maven pom showing irrelevant information

How likely is it that a customer will see the bug and how serious is the bug?
It's unprofesional, anybody looking at the pom could see the problem.

Is it a regression?
yes.
Does it meet other bug fix criteria (security, performance, etc.)?
no.
What CTS failures are caused by this bug?
None.

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

How risky is the fix? How much work is the fix? Is the fix complicated?
Trivial.

  • Is there an impact on documentation or message strings?
    no.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    none.
  • Which is the targeted build of 4.0 for this fix?
    rc3.
  • 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.
    No.
Comment by Romain Grécourt [ 01/May/13 ]

Index: appserver/pom.xml
===================================================================
— appserver/pom.xml (revision 61761)
+++ appserver/pom.xml (working copy)
@@ -57,6 +57,7 @@
<scm>
<connection>scm:svn:https://svn.java.net/svn/glassfish~svn/trunk/main/appserver</connection>
<developerConnection>scm:svn:https://svn.java.net/svn/glassfish~svn/trunk/main/appserver</developerConnection>
+ <url>https://svn.java.net/svn/glassfish~svn/trunk/main/appserver</url>
</scm>

<properties>
Index: nucleus/pom.xml
===================================================================
— nucleus/pom.xml (revision 61761)
+++ nucleus/pom.xml (working copy)
@@ -59,6 +59,7 @@
<scm>
<connection>scm:svn:https://svn.java.net/svn/glassfish~svn/trunk/main/nucleus</connection>
<developerConnection>scm:svn:https://svn.java.net/svn/glassfish~svn/trunk/main/nucleus</developerConnection>
+ <url>https://svn.java.net/svn/glassfish~svn/trunk/main/nucleus</url>
</scm>
<issueManagement>
<system>IssueTracker</system>
romano@dhcp-prague08-third-floor-10-163-25-212:~/workspaces/glassfish/git-ws/all/main$ svn commit -m "fix for GLASSFISH-20426"
Sending appserver/pom.xml
Sending nucleus/pom.xml
Transmitting file data ..
Committed revision 61762.





[GLASSFISH-20423] JASPIC AuthConfigFactory impl (i.e, BaseAuthConfigFactory) does not make required permission checks Created: 26/Apr/13  Updated: 06/May/13  Resolved: 03/May/13

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

Type: Bug Priority: Major
Reporter: monzillo 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

 Description   

JASPIC MR for release 1.1 clarified AuthConfigFactory implementation related permission checking requirements, for example

  • When a SecurityManager is enabled, before loading the argument
  • provider, and before making any changes to the factory, this method must
  • confirm that the calling access control context has been granted the
  • {@link #providerRegistrationSecurityPermission}

similar clarifications where added to the following 5 methods

1. public abstract String
registerConfigProvider(String className, Map properties, String layer, String appContext, String description);

2. public abstract String
registerConfigProvider(AuthConfigProvider, String layer, String appContext, String description);

3. public abstract boolean
removeRegistration(String registrationID);

4. public abstract String[]
detachListener(RegistrationListener listener, String layer, String appContext);

5. public abstract void refresh();

The base class for the Glassfish AuthConfigFactory reference implementation is,
./appserver/security/jaspic-provider-framework/src/main/java/com/sun/jaspic/config/factory/BaseAuthConfigFactory.java

The following block of code needs to be added at the start of each of BaseAuthConfigFactory's implementatation of the
above methods.

SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkPermission(AuthConfigFactory.providerRegistrationSecurityPermission);
}

I will attached a proposed diff to this issue

As as a result of the addition of these permission checks, some programs will
need to be granted these permissions in order to run with the SecurityManager enabled.

At the present time tehse interfaces are used predominantly during application deployment
at which time they are called from container code that is running with AllPermission.



 Comments   
Comment by monzillo [ 26/Apr/13 ]

removed proposed resolution (i.e., diff) as it was reformatted and became incomprehensible.

Comment by quang.dang [ 01/May/13 ]
  • What is the impact on the customer of the bug?

This is to satisfy the permission checking requirements for the AuthConfigFactory impl in
JASPIC MR for release 1.1. It is not a regression.

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

The fix is not complicated and requires not much work. However running the relevant tests with the security manager enabled will take some time. This might be a medium risk fix and would only affect the env where the security manager is turned on.

  • 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 with the security manager enabled
  • Which is the targeted build of 4.0 for this fix?
    1.0_b88
Comment by quang.dang [ 03/May/13 ]

/branches/4.0/appserver/security/jaspic-provider-framework/src/main/java/com/sun/jaspic/config/factory/BaseAuthConfigFactory.java
Rev. 61823

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

trunk Rev. 61847
appserver/security/jaspic-provider-framework/src/main/java/com/sun/jaspic/config/factory/BaseAuthConfigFactory.java





[GLASSFISH-20421] Uptake Weld 2.0.0.Final Created: 26/Apr/13  Updated: 26/Apr/13  Resolved: 26/Apr/13

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

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

Tags: 4_0-approved

 Description   

What is the impact on the customer of the bug?
2.0.0.Final version of Weld.

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?
N/A

What is the cost/risk of fixing the bug?
N/A

How risky is the fix? How much work is the fix? Is the fix complicated?
N/A

Is there an impact on documentation or message strings?
No

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

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

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






[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-20412]  WebSocket API 1.0 Tyrus 1.0-rc4 integration Created: 25/Apr/13  Updated: 26/Apr/13  Resolved: 26/Apr/13

Status: Resolved
Project: glassfish
Component/s: web_socket
Affects Version/s: None
Fix Version/s: 4.0_b87_RC3

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

Tags: 4_0-approved

 Description   

Integration of WebSocket API and Tyrus (RI); both already present in promoted repo: https://maven.java.net/content/groups/promoted/

patch:

Pavels-MacBook-Pro:main pavel$ svn diff
Index: appserver/pom.xml
===================================================================
--- appserver/pom.xml	(revision 61651)
+++ appserver/pom.xml	(working copy)
@@ -120,8 +120,8 @@
         <jaxr.version>JAXR_RA_20091012</jaxr.version>
         <weld.version>2.0.0.CR4</weld.version>
         <wsdl4j.version>1.6.2</wsdl4j.version>
-        <websocket-api.version>1.0-rc5</websocket-api.version>
-        <tyrus.version>1.0-rc3</tyrus.version>
+        <websocket-api.version>1.0</websocket-api.version>
+        <tyrus.version>1.0-rc4</tyrus.version>
         <jsonp.version>1.0-b06</jsonp.version>
         <concurrent-api.version>1.0-b06</concurrent-api.version>
         <concurrent.version>1.0-b08</concurrent.version>
@@ -341,11 +341,10 @@
                                 <artifactId>javax.websocket-api</artifactId>
                                 <version>${websocket-api.version}</version>
                             </artifact>
-                            <nonFinal>true</nonFinal>
+                            <nonFinal>false</nonFinal>
                             <jarType>api</jarType>     
-                            <specVersion>0.0</specVersion>
-                            <newSpecVersion>1.0</newSpecVersion>
-                            <specBuild>18</specBuild>
+                            <specVersion>1.0</specVersion>
+                            <specImplVersion>${websocket-api.version}</specImplVersion>
                             <apiPackage>javax.websocket</apiPackage>
                         </spec>
                         <spec>


 Comments   
Comment by Pavel Bucek [ 26/Apr/13 ]

Committed revision 61691.





[GLASSFISH-20409] EJB container resolved during server startup Created: 25/Apr/13  Updated: 03/May/13  Resolved: 03/May/13

Status: Closed
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0_b86_RC2

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

Tags: 4_0-approved, devx_web

 Description   

With BV 1.1 there is a new CDI portable extension that leads to the EJB container being resolved when bean validation is activated. Mason traced this down as follows:

I think I have chased this down as follows (not that I've trimmed this considerably.. there is quite a lot that is being brought in via web.glue):

org.glassfish.hk2.external.bean-validator [20] imports packages:
javax.enterprise.inject; version=1.0.0 -> org.jboss.weld.osgi-bundle [274]

org.jboss.weld.osgi-bundle [274] imports packages:
org.glassfish.weld; version=4.0.0 -> org.glassfish.main.web.weld-integration [273]

org.glassfish.main.web.weld-integration [273] imports packages:
org.glassfish.web.deployment.descriptor; version=4.0.0 -> org.glassfish.main.web.glue [262]

org.glassfish.main.web.glue [262] imports packages:
com.sun.ejb; version=4.0.0 -> org.glassfish.main.ejb.ejb-container [71]

This is due to a CDI portable extension (new in BV 1.1) that is now bundled in org.glassfish.hk2.external.bean-validator.

This issue for for fixing this so that EJB container is not resolved when bean validation is used, unless the portal extension is actually used.

To see this, just start an empty server and use the osgi lb command:

asadmin start-domain
asadmin osgi lb -l | grep ejb
   26|Installed  |    1|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/cmp-ejb-mapping.jar
   31|Installed  |    1|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/cmp-support-ejb.jar
   51|Installed  |    1|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/console-ejb-lite-plugin.jar
   52|Installed  |    1|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/console-ejb-plugin.jar
   71|Resolved   |    1|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/ejb-container.jar
   72|Installed  |    1|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/ejb-full-container.jar
   73|Resolved   |    1|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/ejb-internal-api.jar
   74|Installed  |    1|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/ejb.security.jar
   81|Active     |    1|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/gf-ejb-connector.jar
  130|Resolved   |    1|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/javax.ejb-api.jar
  168|Resolved   |    1|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/jersey-gf-ejb.jar
  286|Active     |    2|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/autostart/osgi-ejb-container.jar

Here, the ejb-container.jar bundle should be Installed rather than Resolved.

There may be other reasons why ejb-container.jar is getting resolved.

This issue is for making sure that ejb-container.jar is not resolved during server startup.



 Comments   
Comment by mtaube [ 26/Apr/13 ]

What is the impact on the customer of the bug?
Startup performance in certain cases is slower than it needs to be

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?
performance

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?
not risky, this change repackages the CDI portable extension so that the core bean-validator bundle does not resolve cdi/web/ejb components transitively.

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, bean validation tck

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

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

Comment by Tom Mueller [ 29/Apr/13 ]

Built revision 61710 and ejb-container.jar is still resolved after starting the server.

When marking an issue as resolved, please include the revision number for the fix. Based on looking at the svn log, it appears that this was supposed to be fixed in 61661.

I'm reopening this since this isn't fixed.

Comment by mtaube [ 29/Apr/13 ]

This should no longer be happening due to bean-validator;

$ bin/asadmin osgi inspect package r 21
org.glassfish.hk2.external.bean-validator [21] imports packages:
----------------------------------------------------------------
javax.script; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.namespace; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.stream; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.stream.events; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.transform; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.transform.stream; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.validation; version=0.0.0 -> org.apache.felix.framework [0]
org.xml.sax; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.bind.annotation.adapters; version=2.2.7 -> jaxb-api [2]
javax.xml.bind.annotation; version=2.2.7 -> jaxb-api [2]
javax.xml.bind; version=2.2.7 -> jaxb-api [2]
javax.el; version=3.0.0 -> com.sun.el.javax.el [132]
javax.persistence; version=2.1.0 -> javax.persistence [143]

$ bin/asadmin osgi inspect package r 20
org.glassfish.hk2.external.bean-validator-cdi [20] imports packages:
--------------------------------------------------------------------
Nothing

Command osgi executed successfully.

Comment by Tom Mueller [ 29/Apr/13 ]

Note: I'm modifying this issue to be about making sure that ejb-container.jar is not resolved during server startup, not just for fixing the BV problem. (Yes, yes, I could have created another issue.)

Comment by Tom Mueller [ 29/Apr/13 ]

After Mason's changes to the BV module, the ejb-container.jar is now being resolved as a result of bringing in the <jdbc-resource> config bean during parsing of domain.xml.

Comment by Tom Mueller [ 30/Apr/13 ]

Assigning to Mason to provide information about the weld dependencies and how it is impacting this.

Comment by mtaube [ 30/Apr/13 ]

the weld-osgi bundle is importing org.glassfish.weld:

org.jboss.weld.osgi-bundle [275] exports packages:
--------------------------------------------------
javax.decorator; version=1.0.0 UNUSED
javax.enterprise.inject; version=1.0.0 imported by:
org.glassfish.fighterfish.osgi-cdi [285]
org.glassfish.main.web.weld-integration [274]
org.glassfish.javax.faces [136]
javax.enterprise.inject.spi; version=1.0.0 imported by:
org.glassfish.jersey.containers.glassfish.jersey-gf-cdi [168]
org.eclipse.persistence.core [211]
org.glassfish.main.web.sse [267]
org.glassfish.fighterfish.osgi-cdi [285]
org.glassfish.main.web.weld-integration [274]
org.glassfish.javax.faces [136]
javax.enterprise.context.spi; version=1.0.0 imported by:
org.glassfish.jersey.containers.glassfish.jersey-gf-cdi [168]
org.eclipse.persistence.core [211]
org.glassfish.fighterfish.osgi-cdi [285]
org.glassfish.main.web.sse [267]
org.glassfish.main.web.weld-integration [274]
org.glassfish.javax.faces [136]
javax.enterprise.context; version=1.0.0 imported by:
org.glassfish.main.web.gf-weld-connector [89]
org.glassfish.main.web.sse [267]
org.glassfish.fighterfish.osgi-cdi [285]
org.glassfish.main.web.weld-integration [274]
javax.transaction-api [152]
org.glassfish.javax.faces [136]
javax.enterprise.util; version=1.0.0 imported by:
org.glassfish.main.web.sse [267]
org.glassfish.fighterfish.osgi-cdi [285]
org.glassfish.main.web.weld-integration [274]
javax.transaction-api [152]
javax.enterprise.event; version=1.0.0 imported by:
org.glassfish.jersey.containers.glassfish.jersey-gf-cdi [168]
org.glassfish.fighterfish.osgi-cdi [285]
org.glassfish.main.web.sse [267]
org.glassfish.main.web.weld-integration [274]
org.glassfish.javax.faces [136]
org.jboss.weld.context; version=1.0.0 UNUSED
org.jboss.weld.ejb; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.bean; version=1.0.0 UNUSED
org.jboss.weld.bean.builtin; version=1.0.0 UNUSED
org.jboss.weld.bean.proxy; version=1.0.0 UNUSED
org.jboss.weld.servlet.api; version=1.0.0 UNUSED
org.jboss.weld.bootstrap.api; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.context.api; version=1.0.0 UNUSED
org.jboss.weld.servlet.api.helpers; version=1.0.0 UNUSED
org.jboss.weld.bootstrap.api.helpers; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.ejb.api; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.manager.api; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.interceptor.spi.model; version=1.0.0 UNUSED
org.jboss.weld.ejb.spi.helpers; version=1.0.0 UNUSED
org.jboss.weld.validation.spi; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.serialization.spi; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.interceptor.spi.context; version=1.0.0 UNUSED
org.jboss.weld.interceptor.spi.metadata; version=1.0.0 UNUSED
org.jboss.weld.transaction.spi; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.injection.spi.helpers; version=1.0.0 UNUSED
org.jboss.weld.serialization.spi.helpers; version=1.0.0 UNUSED
org.jboss.weld.bootstrap.spi; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.injection.spi; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.resources.spi; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.interceptor.spi.instance; version=1.0.0 UNUSED
org.jboss.weld.resources.spi.helpers; version=1.0.0 UNUSED
org.jboss.weld.bootstrap.spi.helpers; version=1.0.0 UNUSED
org.jboss.weld.ejb.spi; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.security.spi; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.bootstrap; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.event; version=1.0.0 UNUSED
org.jboss.weld.injection; version=1.0.0 UNUSED
org.jboss.weld.manager; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.servlet; version=1.0.0 UNUSED
org.jboss.weld.util; version=1.0.0 UNUSED
org.jboss.weld.el; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.jsf; version=1.0.0 UNUSED
org.jboss.weld.proxy.util; version=0.0.0 UNUSED
org.jboss.weld.bean.proxy.util; version=0.0.0 UNUSED
org.jboss.weld.context.http; version=0.0.0 UNUSED
org.jboss.weld.context.bound; version=0.0.0 UNUSED
org.jboss.weld.context.cache; version=0.0.0 UNUSED
org.jboss.weld.bean.builtin.ee; version=0.0.0 UNUSED
javassist.util.proxy; version=0.0.0 UNUSED
org.jboss.weld.interceptor.proxy; version=0.0.0 UNUSED
org.jboss.weld.interceptor.util.proxy; version=0.0.0 UNUSED
org.jboss.weld.util.bean; version=0.0.0 UNUSED
org.jboss.weld.serialization; version=0.0.0 UNUSED
org.jboss.weld.injection.attributes; version=0.0.0 UNUSED
org.jboss.weld.util.collections; version=0.0.0 UNUSED
org.jboss.weld.annotated.slim; version=0.0.0 UNUSED
org.jboss.weld.annotated.slim.backed; version=0.0.0 UNUSED

Command osgi executed successfully.

org.jboss.weld.osgi-bundle [275] imports packages:
--------------------------------------------------
javax.naming; version=0.0.0 -> org.apache.felix.framework [0]
javax.naming.spi; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.parsers; version=0.0.0 -> org.apache.felix.framework [0]
org.w3c.dom; version=0.0.0 -> org.apache.felix.framework [0]
org.xml.sax; version=0.0.0 -> org.apache.felix.framework [0]
org.xml.sax.helpers; version=0.0.0 -> org.apache.felix.framework [0]
sun.misc; version=0.0.0 -> org.apache.felix.framework [0]
javax.annotation; version=1.2.0 -> javax.annotation-api [1]
javax.validation; version=1.1.0 -> org.glassfish.hk2.external.bean-validator [21]
javax.el; version=3.0.0 -> com.sun.el.javax.el [132]
javax.faces.application; version=2.2.0 -> org.glassfish.javax.faces [136]
javax.faces.context; version=2.2.0 -> org.glassfish.javax.faces [136]
javax.inject; version=1.0.0 -> org.glassfish.hk2.external.javax.inject [137]
javax.interceptor; version=1.2.0 -> javax.interceptor-api [138]
javax.persistence; version=2.1.0 -> javax.persistence [143]
javax.servlet; version=3.1.0 -> javax.servlet-api [147]
javax.servlet.http; version=3.1.0 -> javax.servlet-api [147]
javax.transaction; version=1.2.0.b03 -> javax.transaction-api [152]
org.glassfish.weld; version=4.0.0 -> org.glassfish.main.web.weld-integration [274]

Command osgi executed successfully.

Comment by mtaube [ 03/May/13 ]

This is a dup of GLASSFISH-20450 - Weld combination of API/implementation in single bundle slows down server startup





[GLASSFISH-20408] glassfish-verifier: bin script don't have execution permissions Created: 25/Apr/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0_b87_RC3

Type: Bug Priority: Critical
Reporter: Romain Grécourt Assignee: Romain Grécourt
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Tags: 4_0-approved, packaging, updatecenter, updatetool, verifier

 Description   

glassfish-verifier: bin script don't have execution permissions



 Comments   
Comment by Romain Grécourt [ 25/Apr/13 ]
  • What is the impact on the customer of the bug?
    Direct impact if they try to install glassfish-verifier package, they will have to chmod the bin verify script.

How likely is it that a customer will see the bug and how serious is the bug?
Every person trying to install and use glassfish-verify will see the bug.
Not serious, but unprofessional

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

What CTS failures are caused by this bug?
None.

  • What is the cost/risk of fixing the bug?
    Easy, it should be a change in the pkg prototype to specify the permissions properly.

How risky is the fix? How much work is the fix? Is the fix complicated?
not risky.

  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Install glassfish-verifier and try to start the script after installation.
  • 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.
Comment by Romain Grécourt [ 01/May/13 ]

Project: glassfish
Repository: svn
Revision: 61763
Author: romain_grecourt
Date: 2013-05-01 09:33:41 UTC
Link:

Log Message:
------------
fix for GLASSFISH-20408, make glassfish-verifier bin scripts executable

Revisions:
----------
61763

Modified Paths:
---------------
trunk/main/appserver/packager/glassfish-verifier/pom.xml

Added Paths:
------------
trunk/main/appserver/packager/glassfish-verifier/src/main/assembly
trunk/main/appserver/packager/glassfish-verifier/src/main/assembly/glassfish-verifier.xml

Diffs:
------
Index: trunk/main/appserver/packager/glassfish-verifier/src/main/assembly/glassfish-verifier.xml
===================================================================
— trunk/main/appserver/packager/glassfish-verifier/src/main/assembly/glassfish-verifier.xml (revision 0)
+++ trunk/main/appserver/packager/glassfish-verifier/src/main/assembly/glassfish-verifier.xml (revision 61763)
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!--
+
+ DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
+
+ Copyright (c) 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
+ and Distribution License("CDDL") (collectively, the "License"). You
+ may not use this file except in compliance with the License. You can
+ obtain a copy of the License at
+ https://glassfish.dev.java.net/public/CDDL+GPL_1_1.html
+ or packager/legal/LICENSE.txt. See the License for the specific
+ language governing permissions and limitations under the License.
+
+ When distributing the software, include this License Header Notice in each
+ file and include the License file at packager/legal/LICENSE.txt.
+
+ GPL Classpath Exception:
+ Oracle designates this particular file as subject to the "Classpath"
+ exception as provided by Oracle in the GPL Version 2 section of the License
+ file that accompanied this code.
+
+ Modifications:
+ If applicable, add the following below the License Header, with the fields
+ enclosed by brackets [] replaced by your own identifying information:
+ "Portions Copyright [year] [name of copyright owner]"
+
+ Contributor(s):
+ If you wish your version of this file to be governed by only the CDDL or
+ only the GPL Version 2, indicate your decision by adding "[Contributor]
+ elects to include this software in this distribution under the [CDDL or GPL
+ Version 2] license." If you don't indicate a single choice of license, a
+ recipient has the option to distribute your version of this file under
+ either the CDDL, the GPL Version 2 or to extend the choice of license to
+ its licensees as provided above. However, if you add GPL Version 2 code
+ and therefore, elected the GPL Version 2 license, then the option applies
+ only if the new code is made subject to such option by the copyright
+ holder.
+
+-->
+
+<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 http://maven.apache.org/xsd/assembly-1.1.2.xsd">
+
+ <id>stage-package</id>
+ <formats>
+ <format>dir</format>
+ </formats>
+
+ <includeBaseDirectory>false</includeBaseDirectory>
+ <fileSets>
+ <fileSet>
+ <directory>$

{temp.dir}/glassfish/bin</directory>
+ <outputDirectory>${install.dir.name}/glassfish/bin</outputDirectory>
+ <fileMode>755</fileMode>
+ </fileSet>
+ <fileSet>
+ <directory>${temp.dir}

</directory>
+ <excludes>
+ <exclude>glassfish/bin/*</exclude>
+ <exclude>pkg_proto.py</exclude>
+ </excludes>
+ <outputDirectory>$

{install.dir.name}

</outputDirectory>
+ </fileSet>
+ </fileSets>
+</assembly>

Property changes on: trunk/main/appserver/packager/glassfish-verifier/src/main/assembly/glassfish-verifier.xml
___________________________________________________________________
Added: svn:eol-style

    1. -0,0 +1 ##
      +native
      \ No newline at end of property
      Index: trunk/main/appserver/packager/glassfish-verifier/pom.xml
      ===================================================================
      • trunk/main/appserver/packager/glassfish-verifier/pom.xml (revision 61762)
        +++ trunk/main/appserver/packager/glassfish-verifier/pom.xml (revision 61763)
        @@ -52,6 +52,10 @@
        <name>Verifier Package</name>
        <packaging>distribution-fragment</packaging>
        <description>This pom describes how to assemble the Verifier package</description>
        +
        + <properties>
        + <temp.dir>$ {project.build.directory}

        /dependency</temp.dir>
        + </properties>

<build>
<plugins>





Cannot get ValidationFactory if CDI is disabled. (GLASSFISH-20401)

[GLASSFISH-20404] bypass NamedNamingObjectManager when BeanManager not enabled Created: 24/Apr/13  Updated: 25/Apr/13  Resolved: 25/Apr/13

Status: Closed
Project: glassfish
Component/s: naming
Affects Version/s: None
Fix Version/s: 4.0_b86_RC2

Type: Sub-task 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   

currently, if the BeanManager is not available, a lookup of java:comp/Validator will fail with an IllegalStateException. This is due to the proxying of java:comp namespace. Instead of throwing an IllegalStateException, the registry in JavaURLContext should be consulted:

[2013-04-24T11:50:49.637-0400] [glassfish 4.0] [SEVERE] [] [javax.enterprise.web] [tid: _ThreadID=68 _ThreadName=AutoDeployer] [timeMillis: 1366818649637] [levelValue: 1000] [[
WebModule[/ejb3_assembly_appres_warejb_web]Servlet /ejb3_assembly_appres_warejb_web threw load() exception
java.lang.IllegalStateException: Cannot resolve bean manager
at org.glassfish.weld.BeanManagerNamingProxy.handle(BeanManagerNamingProxy.java:121)
at org.glassfish.weld.ValidationNamingProxy.obtainBeanManager(ValidationNamingProxy.java:191)
at org.glassfish.weld.ValidationNamingProxy.handle(ValidationNamingProxy.java:103)
at com.sun.enterprise.naming.impl.NamedNamingObjectManager.tryNamedProxies(NamedNamingObjectManager.java:134)
at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:166)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:471)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
at javax.naming.InitialContext.lookup(Unknown Source)
at javax.naming.InitialContext.lookup(Unknown Source)
at com.sun.ts.tests.ejb30.common.helper.ServiceLocator.lookup(ServiceLocator.java:72)
at com.sun.ts.tests.ejb30.common.helper.ServiceLocator.lookupNoTry(ServiceLocator.java:28)
at com.sun.ts.tests.ejb30.assembly.appres.common.AppResTest.verifyValidatorAndFactory(AppResTest.java:79)
at com.sun.ts.tests.ejb30.assembly.appres.common.AppResTest.beanPostConstruct(AppResTest.java:118)
at com.sun.ts.tests.ejb30.assembly.appres.common.TestServletBase2.postConstruct(TestServletBase2.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl$3.run(InjectionManagerImpl.java:743)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.invokeLifecycleMethod(InjectionManagerImpl.java:737)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:508)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:141)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:127)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:324)
at com.sun.enterprise.web.WebContainer.createServletInstance(WebContainer.java:983)
at com.sun.enterprise.web.WebModule.createServletInstance(WebModule.java:2130)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1404)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1381)
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(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2278)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1924)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:537)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:164)
at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:595)
at org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:482)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:410)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:401)
at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:233)
at java.util.TimerThread.mainLoop(Unknown Source)
at java.util.TimerThread.run(Unknown Source)
]]



 Comments   
Comment by mtaube [ 24/Apr/13 ]

What is the impact on the customer of the bug?
While investigating GLASSFISH-20401 we found the weld integration code was masking an underlying problem by attempting to obtain the BeanManager (in some cases, when CDI is not available, the BeanManager is not available and an IllegalStateException is thrown)

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?
javaeetck/src/com/sun/ts/tests/ejb30/assembly/appres/warejb

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

Is there an impact on documentation or message strings?
No

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
EJB, Quicklook, EJB cts, Bean Validation cts

I have also verified that the following tests pass :
QL, bv-tck

Which is the targeted build of 4.0 for this fix?
Build-86

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.
No.

Comment by mtaube [ 25/Apr/13 ]

Committed revision 61643.





[GLASSFISH-20403] stop standalone connectors after stopping all other applications during server shutdown Created: 24/Apr/13  Updated: 29/Apr/13  Resolved: 29/Apr/13

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: 4.0_b85
Fix Version/s: 4.0_b86_RC2

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

Tags: 4_0-approved

 Description   

While evaluating issues GLASSFISH-20389 an GLASSFISH-20390
we found that standalone resource-adapters (connectors) are not stopped after stopping the other applications.

During server startup, while loading the applications, standalone connectors are started first and then other type of applications (war/ear/MDBs etc.,)
This is needed so that any application (war/ear/MDB) that is dependent on the standalone connector will work fine.

Similarly, the reverse must happen while stopping (shutting down) application server.



 Comments   
Comment by Jagadish [ 24/Apr/13 ]
  • What is the impact on the customer of the bug?
    While investigating GLASSFISH-20389 and GLASSFISH-20390, we found this issue. This might be seen
    randomly depending upon the order in which "applications" are registered in domain.xml.
  • 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?
    This issue will be seen randomly. No CTS failures.
    This is a regression compared to GlassFish 2.x, exposed while debugging an issue related to Java EE 7 feature.
  • What is the cost/risk of fixing the bug?
    Fix is simple, to make sure that the standalone connectors are not stopped before stopping all other applications.

How risky is the fix? How much work is the fix? Is the fix complicated?
Fix is simple.
Fix is reviewed by Hong Zhang (Deployment)

  • Is there an impact on documentation or message strings?
    No
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Deployment, Connector, EJB SQE Tests
    [I have verified Connector SQE tests]
    I have also verified that the following tests pass :
    QL (Web, Classic), deployment-dev, ejb-dev, connector-dev, jdbc-dev, connector-standalone-cts (Web, Classic), resources-admin-cli.
  • Which is the targeted build of 4.0 for this fix?
    Build-86
  • 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.
    No.
Comment by Tom Mueller [ 24/Apr/13 ]

Approved for 4.0.

Comment by Jagadish [ 29/Apr/13 ]

FIX INFORMATION :
svn revision : 61635
Modified Paths:
---------------
trunk/main/nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/server/ApplicationLoaderService.java





[GLASSFISH-20397] CLI prints NullPointerException when remote server returns 500 with unknown data Created: 24/Apr/13  Updated: 25/Apr/13  Resolved: 25/Apr/13

Status: Resolved
Project: glassfish
Component/s: command_line_interface
Affects Version/s: 4.0_b85
Fix Version/s: 4.0_b86_RC2

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

Tags: 4_0-approved

 Description   

CLI prints NullPointerException when remote server returns 500 with unknown data. It is theoretically not possible with direct connection to GF. But can be seen when port is wrong or maybe by proxy server.

It was identify by Bug 16553490.



 Comments   
Comment by martin.mares [ 24/Apr/13 ]

I have fix ready. I need to solve if I have to wait until new nucleus branch or if I can commit it into current ReleaseCandidate.

Comment by martin.mares [ 24/Apr/13 ]
Index: nucleus/admin/util/src/main/java/com/sun/enterprise/admin/remote/RemoteRestAdminCommand.java
===================================================================
--- nucleus/admin/util/src/main/java/com/sun/enterprise/admin/remote/RemoteRestAdminCommand.java	(revision 61586)
+++ nucleus/admin/util/src/main/java/com/sun/enterprise/admin/remote/RemoteRestAdminCommand.java	(working copy)
@@ -44,6 +44,7 @@
 import com.sun.enterprise.admin.remote.reader.CliActionReport;
 import com.sun.enterprise.admin.remote.reader.ProprietaryReader;
 import com.sun.enterprise.admin.remote.reader.ProprietaryReaderFactory;
+import com.sun.enterprise.admin.remote.reader.StringProprietaryReader;
 import com.sun.enterprise.admin.remote.sse.GfSseEventReceiver;
 import com.sun.enterprise.admin.remote.sse.GfSseEventReceiverProprietaryReader;
 import com.sun.enterprise.admin.remote.sse.GfSseInboundEvent;
@@ -815,36 +816,42 @@
                 } else {
                     ProprietaryReader<ParamsWithPayload> reader
                             = ProprietaryReaderFactory.getReader(ParamsWithPayload.class, resultMediaType);
-                    final InputStream is;
                     if (urlConnection.getResponseCode() == HttpURLConnection.HTTP_INTERNAL_ERROR) {
-                        is = urlConnection.getErrorStream();
+                        ActionReport report;
+                        if (reader == null) {
+                            report = new CliActionReport();
+                            report.setActionExitCode(ExitCode.FAILURE);
+                            report.setMessage(urlConnection.getResponseMessage());
+                        } else {
+                            report = reader.readFrom(urlConnection.getErrorStream(), resultMediaType).getActionReport();
+                        }
+                        setActionReport(report);
                     } else {
-                        is = urlConnection.getInputStream();
-                    }
-                    ParamsWithPayload pwp = reader.readFrom(is, resultMediaType);
-                    if (pwp.getPayloadInbound() == null) {
-                        setActionReport(pwp.getActionReport());
-                    } else if (resultMediaType.startsWith("multipart/")) {
-                        RestPayloadImpl.Inbound inbound = pwp.getPayloadInbound();
-                        setActionReport(pwp.getActionReport());
-                        if (logger.isLoggable(Level.FINER)) {
-                            logger.log(Level.FINER, "------ PAYLOAD ------");
-                            Iterator<Payload.Part> parts = inbound.parts();
-                            while (parts.hasNext()) {
-                                Payload.Part part = parts.next();
-                                logger.log(Level.FINER, " - {0} [{1}]", new Object[]{part.getName(), part.getContentType()});
+                        ParamsWithPayload pwp = reader.readFrom(urlConnection.getInputStream(), resultMediaType);
+                        if (pwp.getPayloadInbound() == null) {
+                            setActionReport(pwp.getActionReport());
+                        } else if (resultMediaType.startsWith("multipart/")) {
+                            RestPayloadImpl.Inbound inbound = pwp.getPayloadInbound();
+                            setActionReport(pwp.getActionReport());
+                            if (logger.isLoggable(Level.FINER)) {
+                                logger.log(Level.FINER, "------ PAYLOAD ------");
+                                Iterator<Payload.Part> parts = inbound.parts();
+                                while (parts.hasNext()) {
+                                    Payload.Part part = parts.next();
+                                    logger.log(Level.FINER, " - {0} [{1}]", new Object[]{part.getName(), part.getContentType()});
+                                }
+                                logger.log(Level.FINER, "---- END PAYLOAD ----");
                             }
-                            logger.log(Level.FINER, "---- END PAYLOAD ----");
+                            PayloadFilesManager downloadedFilesMgr =
+                                    new PayloadFilesManager.Perm(fileOutputDir, null, logger, null);
+                            try {
+                                downloadedFilesMgr.processParts(inbound);
+                            } catch (CommandException cex) {
+                                throw cex;
+                            } catch (Exception ex) {
+                                throw new CommandException(ex.getMessage(), ex);
+                            }
                         }
-                        PayloadFilesManager downloadedFilesMgr =
-                                new PayloadFilesManager.Perm(fileOutputDir, null, logger, null);
-                        try {
-                            downloadedFilesMgr.processParts(inbound);
-                        } catch (CommandException cex) {
-                            throw cex;
-                        } catch (Exception ex) {
-                            throw new CommandException(ex.getMessage(), ex);
-                        }
                     }
                 }
             }
Comment by martin.mares [ 24/Apr/13 ]

Please, where to add this fix? Add it tu current trunk (Release candidate) or wait for branch? Thanks

Comment by martin.mares [ 24/Apr/13 ]
  • What is the impact on the customer of the bug?

CLI can print inappropriate message containing "NullPointerException" in very special situation.
It is regression.

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

Very small fix. 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?

Any CLI tests are good.

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

Nearest

  • 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 [ 24/Apr/13 ]

Approved for 4.0.





[GLASSFISH-20396] Incorrect Implementation of NoBodyResponse#setContentLengthLong in HttpServlet.java Created: 24/Apr/13  Updated: 24/Apr/13  Resolved: 24/Apr/13

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: None
Fix Version/s: 4.0_b87_RC3

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

Tags: 4_0-approved

 Description   

An issue has been filed about the incorrect implementation of NoBodyResponse#setContentLengthLong in https://java.net/jira/browse/SERVLET_SPEC-69

Since this is an implementation issue, per request, a GlassFish issue is filed for this.



 Comments   
Comment by Shing Wai Chan [ 24/Apr/13 ]
  • What is the impact on the customer of the bug?
    Incorrect implementation of content length in case of HEAD in HttpServlet
  • What is the cost/risk of fixing the bug?
    low
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    SQE web tests
  • Which is the targeted build of 4.0 for this fix?
    4.0_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.
    Yes. https://java.net/jira/browse/SERVLET_SPEC-69
Comment by Shing Wai Chan [ 24/Apr/13 ]

Sending javax.servlet/src/main/java/javax/servlet/http/HttpServlet.java
Sending javax.servlet/src/main/java/javax/servlet/http/LocalStrings.properties
Transmitting file data ..
Committed revision 61607.

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

Sending pom.xml
Transmitting file data .
Committed revision 61626.





[GLASSFISH-20394] NPE in RelativePathResolver Created: 23/Apr/13  Updated: 24/Apr/13  Resolved: 24/Apr/13

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 4.0_b85
Fix Version/s: 4.0_b86_RC2

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

Tags: 4_0-approved

 Description   

Most references to the domain-scoped password alias store (looked up using hk2) in this class use the get... method which populates the field if necessary, but two references in one method do not, referring directly to the field itself, and those references can lead to NPEs.

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

This is a regression. Diagnosing a connector devtest error led to this.

  • What is the cost/risk of fixing the bug?
    Very low risk. Two call sites in one class need to invoke a method (which is already used in other places in the class) instead of referring directly to a field.
  • Is there an impact on documentation or message strings?
    No
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    QL
  • Which is the targeted build of 4.0 for this fix?
    b86_RC2
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in?
    n/a


 Comments   
Comment by Tim Quinn [ 24/Apr/13 ]

Fix checked in.

Project: glassfish
Repository: svn
Revision: 61604
Author: tjquinn
Date: 2013-04-24 00:42:12 UTC
Link:

Log Message:
------------
GLASSFISH-20394 - NPE in RelativePathResolver

Earlier changes introduced the getDomainScopedPasswordAliasStore method which, when needed, looks up an hk2 service. Two call sites in the class weren't converted to use the method instead of referring directly to the field. This led to NPEs.

This changes replaces the direct field references with invocations of the get... method.

Approved: Michael
Reviewed: Chris
Passed: QL, offending connector deftest that exposed the NPE

Revisions:
----------
61604

Modified Paths:
---------------
trunk/main/nucleus/common/internal-api/src/main/java/org/glassfish/internal/api/RelativePathResolver.java





[GLASSFISH-20391] Use of JDBCRealm causes infinite injection chain at boot, causing the server to never boot Created: 23/Apr/13  Updated: 24/Apr/13  Resolved: 24/Apr/13

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

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

Issue Links:
Dependency
depends on HK2-6 StackOverflowError injecting circular... Resolved
Tags: 4_0-approved

 Description   

Here is the stack that is in infinite recursion:

"RunLevelControllerThread-1366739020320" daemon prio=10 tid=0x00007f66a0005800 nid=0x4361 in Object.wait() [0x00007f66e67e2000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)

  • waiting on <0x00000000e0ba6ea8> (a org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext)
    at java.lang.Object.wait(Object.java:503)
    at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:129)
  • locked <0x00000000e0ba6ea8> (a org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext)
    at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:579)
    at org.jvnet.hk2.internal.IterableProviderImpl.get(IterableProviderImpl.java:87)
    at com.sun.enterprise.connectors.ConnectorRuntime.getResourceManager(ConnectorRuntime.java:973)
  • locked <0x00000000f5979288> (a com.sun.enterprise.connectors.ConnectorRuntime)
    at com.sun.enterprise.connectors.ConnectorRuntime.postConstruct(ConnectorRuntime.java:889)
    at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:281)
    at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:328)
    at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
    at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
    at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:579)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:566)
    at com.sun.enterprise.security.ee.auth.realm.jdbc.JDBCRealm.init(JDBCRealm.java:169)
  • locked <0x00000000e157d140> (a com.sun.enterprise.security.ee.auth.realm.jdbc.JDBCRealm)
    at com.sun.enterprise.security.auth.realm.Realm.doInstantiate(Realm.java:334)
  • locked <0x00000000fd96c298> (a java.lang.Class for com.sun.enterprise.security.auth.realm.Realm)
    at com.sun.enterprise.security.auth.realm.Realm.instantiate(Realm.java:225)
  • locked <0x00000000fd96c298> (a java.lang.Class for com.sun.enterprise.security.auth.realm.Realm)
    at com.sun.enterprise.security.auth.realm.RealmConfig.createRealms(RealmConfig.java:82)
    at com.sun.enterprise.security.auth.realm.RealmsManager.createRealms(RealmsManager.java:278)
    at com.sun.enterprise.security.auth.realm.RealmsManager.createRealms(RealmsManager.java:211)
    at org.glassfish.security.services.impl.AuthenticationServiceImpl.initialize(AuthenticationServiceImpl.java:178)
    at org.glassfish.security.services.impl.AuthenticationServiceImpl.postConstruct(AuthenticationServiceImpl.java:286)
    at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:281)
    at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:328)
    at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
    at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
    at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
    at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
  • locked <0x00000000e157d320> (a java.lang.Object)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:558)
    at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
    at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:191)
    at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:214)
    at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:311)
    at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
    at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
    at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
    at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
  • locked <0x00000000e157d410> (a java.lang.Object)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:558)
    at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
    at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:191)
    at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:214)
    at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:311)
    at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
    at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
    at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
    at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
  • locked <0x00000000e157d500> (a java.lang.Object)
    at org.jvnet.hk2.internal.IterableProviderImpl$MyIterator.next(IterableProviderImpl.java:205)
    at org.glassfish.resourcebase.resources.listener.ResourceManager.notifyListeners(ResourceManager.java:136)
    at org.glassfish.resourcebase.resources.listener.ResourceManager.postConstruct(ResourceManager.java:128)
    at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:281)
    at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:328)
    at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
    at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:158)
    at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
    at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
  • locked <0x00000000e157d5b8> (a java.lang.Object)
    at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:673)
    at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:660)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
    at java.lang.Thread.run(Thread.java:722)


 Comments   
Comment by jwells [ 23/Apr/13 ]

The infinite recursion is via:

ResourceManager(postConstruct->notifyListeners) -> (through an unknown chain) -> JDBCRealm -> ConnectorRuntime(postConstruct) -> ResourceManager

Comment by Alex Pineda [ 23/Apr/13 ]

This issue affects SQE's Core-DAS Security test suite and caused 300+ tests not to run (DNR). Need this fix to complete the testing of the GF 4.0 release

Comment by jwells [ 24/Apr/13 ]

What is the impact on the customer of the bug?

They will be unable to use JDBC realms

What is the cost/risk of fixing the bug?

The risk is small (the fix is simple) and the cost is high (using a JDBC realm will cause the server to hang during boot)

Is there an impact on documentation or message strings?

No

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

Security

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.

n/a

Comment by Tom Mueller [ 24/Apr/13 ]

Approved for 4.0.

Comment by jwells [ 24/Apr/13 ]

Fixed at change 61625





[GLASSFISH-20390] Possible concurrency issue in AsyncClientShutdownTask.run() in the MDB container Created: 23/Apr/13  Updated: 26/Apr/13  Resolved: 26/Apr/13

Status: Closed
Project: glassfish
Component/s: jca
Affects Version/s: 4.0_b85
Fix Version/s: 4.0_b87_RC3

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

Tags: 4_0-approved

 Description   

While trying to verify GLASSFISH-20296, we found that endpointDeactivation may not be called during application undeployment intermittently.

We (Jagadish and I) think this could be due to a concurrency issue in AsynClientShutdownTask in
https://svn.java.net/svn/glassfish~svn/trunk/main/appserver/ejb/ejb-full-container/src/main/java/org/glassfish/ejb/mdb/MessageBeanContainer.java.

To reproduce:

  • In a multi-core laptop (Dell XPS) run the following
    Uncomment the lookup logic in endpointDeactivation in ra/src/connector/SimpleResourceAdapterImpl.java of https://svn.java.net/svn/glassfish~svn/trunk/v2/appserv-tests/devtests/connector/v3/connector1.6, and run the test "ant all".
  • observe that the endpointDeactivation is not called.
    [actually you should be able to use any MDB test that uses a resource adapter to deliver messages. Undeploy the application that uses the RA, and check if endpointDeactivation is called.]

If you set a breakpoint in AsyncClientShutdownTask.run() you can observe that the MessageBeanCllient.close() – which would actually call the RA's endpointDeactivation in the connector's code – is not called intermittently.

Making the "done" local variable in AsyncClientShutdownTask "volatile" appears to fix the issue.

If you can't seem to reproduce the issue, and would like to have us (Jagadish/I) verify your fixes, please let us know. We can reproduce this issue fairly reguarly.



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

It's not called on undeploy on my mac as well

Comment by marina vatkina [ 23/Apr/13 ]

The endpoint is not called because activeRar in ConnectorMessageBeanClient.close is null. Is it the same as GLASSFISH-20389?

Comment by marina vatkina [ 24/Apr/13 ]

activeRar is also null when undeploying ejb/ejb32/mdb test

Comment by Sivakumar Thyagarajan [ 24/Apr/13 ]

Marina: This issue is not related to GLASSFISH-20389. Infact that issue is now fixed with rev 61615, but you should still be able to reproduce this issue. If you can't reproduce and want us to run a diagnostic patch, please provide us a patch.

Transferring this to you.

Comment by marina vatkina [ 25/Apr/13 ]
  • What is the impact on the customer of the bug?
    It is reported to be seen on a multi-core device
  • 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?
    Not a regression, but the endpoint remains active until the server shutdown. May cause problems with redeployment.
  • What is the cost/risk of fixing the bug?
    Very low

How risky is the fix? How much work is the fix? Is the fix complicated?
Very low

  • Is there an impact on documentation or message strings?
    No
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Connector, EJB
  • Which is the targeted build of 4.0 for this fix?
    Next
  • 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.
    No.
Comment by Sivakumar Thyagarajan [ 26/Apr/13 ]

Marking this issue as closed, as we couldn't reproduce it anymore on trunk.





[GLASSFISH-20389] endpointDeactivation not called for during MDB undeployment for MDB's with no resource-adapter-mid specified Created: 23/Apr/13  Updated: 24/Apr/13  Resolved: 24/Apr/13

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: 4.0_b85
Fix Version/s: 4.0_b86_RC2

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

Tags: 4_0-approved

 Description   

While trying to verify another issue(GLASSFISH-20296), it was found that ResourceAdapter.endpointDeactivation was not called for MDBs that do not specify the resource-adapter-mid in their glassfish-ejb-jar.xml.

To reproduce:



 Comments   
Comment by Jagadish [ 23/Apr/13 ]
  • What is the impact on the customer of the bug?
    Customer's implementation of EndpointDeactivation in their RAR implementation will not get called
    if <resource-adapter-mid> is not specified in the ejb descriptor.
  • How likely is it that a customer will see the bug and how serious is the bug?
    This issue will be seen in inbound resource-adapters, <resource-adapter-mid> is not
    specified in the ejb descriptor.
  • Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
    What CTS failures are caused by this bug?
    No CTS failures. This seems to be a bug that existed ever since the "default" RA detection
    mechanism was introduced (Probably, GlassFish 3.0)
  • What is the cost/risk of fixing the bug?
    Fix is simple, use the same logic to determine the "matching" RA during endpoint activation
    that is used today for endpoint deactivation also.
  • How risky is the fix? How much work is the fix? Is the fix complicated?
    Fix is simple, refactored the RA selection algorithm so that its used during endpoint
    deactivation also.
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    I shall make sure that no regressions in connector SQE tests happen before checking in.
    [QL, connector-dev, jdbc-dev, jms-dev, connector-standalone-cts (Web, Classic), resources-admin-cli are all passing.]
  • Which is the targeted build of 4.0 for this fix?
    Build-86
  • 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.
    No
Comment by Tom Mueller [ 23/Apr/13 ]

Approved for 4.0.

Comment by Jagadish [ 24/Apr/13 ]

FIX INFORMATION :

svn log -v -r 61615
------------------------------------------------------------------------
r61615 | jr158900 | 2013-04-24 15:24:52 +0530 (Wed, 24 Apr 2013) | 9 lines
Changed paths:
M /trunk/main/appserver/connectors/connectors-inbound-runtime/src/main/java/com/sun/enterprise/connectors/inbound/ConnectorMessageBeanClient.java
M /trunk/main/appserver/connectors/connectors-inbound-runtime/src/main/resources/com/sun/enterprise/connectors/inbound/LocalStrings.properties

GLASSFISH-20389 : endpointDeactivation not called for during MDB undeployment for MDB's with no resource-adapter-mid specified

Fix is to make sure that resource-adapter-mid is derived during endpoint deactivation similar to
how it is done during endpoint activation





[GLASSFISH-20385] Integrate Jersey 2.0-rc2 into the GF main trunk Created: 23/Apr/13  Updated: 23/Apr/13  Resolved: 23/Apr/13

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

Type: Task Priority: Critical
Reporter: Jakub Podlesak Assignee: michael.y.chen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-20354 EJBException thrown in JAXRS resource... Resolved
blocks GLASSFISH-20332 @PreDestroy not called on Application... Resolved
blocks GLASSFISH-20255 @Inject Strange Errors Closed
Tags: 4_0-approved

 Description   

This should bring the following fixes in:

https://java.net/jira/browse/GLASSFISH-20354
https://java.net/jira/browse/GLASSFISH-20332
https://java.net/jira/browse/GLASSFISH-20255



 Comments   
Comment by Jakub Podlesak [ 23/Apr/13 ]

Sending nucleus/admin/rest/rest-service/src/main/java/org/glassfish/admin/rest/adapter/RestManagementResourceProvider.java
Sending nucleus/pom.xml
Transmitting file data ..
Committed revision 61593.





[GLASSFISH-20383] [regression] NCDFE during shutdown of glassfish Created: 23/Apr/13  Updated: 25/Apr/13  Resolved: 25/Apr/13

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

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

Tags: 4_0-approved

 Description   

To reproduce:
java -jar modules/glassfish.jar
Allow it to start. You will see a message like following in the console:

Registered com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl@747e2f as OSGi service registration:

Now 'Ctrl C' or Kill it. You will notice the following message in the console:
Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "GlassFish Shutdown Hook"

This didn't use to happen.



 Comments   
Comment by jwells [ 24/Apr/13 ]

Here is a better stack trace:

java.lang.NoClassDefFoundError: org/glassfish/hk2/runlevel/internal/CurrentTaskFuture$DownAllTheWay
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture.<init>(CurrentTaskFuture.java:106)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.proceedTo(AsyncRunLevelContext.java:279)
at org.glassfish.hk2.runlevel.internal.RunLevelControllerImpl.proceedTo(RunLevelControllerImpl.java:66)
at com.sun.enterprise.v3.server.AppServerStartup.proceedTo(AppServerStartup.java:555)
at com.sun.enterprise.v3.server.AppServerStartup.stop(AppServerStartup.java:508)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.stop(GlassFishImpl.java:88)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.dispose(GlassFishImpl.java:97)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.dispose(GlassFishDecorator.java:73)
at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishRuntime.shutdown(EmbeddedOSGiGlassFishRuntime.java:112)
at com.sun.enterprise.glassfish.bootstrap.GlassFishRuntimeDecorator.shutdown(GlassFishRuntimeDecorator.java:63)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntime.shutdown(OSGiGlassFishRuntime.java:82)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher$1.run(GlassFishMain.java:212)
Caused by: java.lang.ClassNotFoundException: Unable to load class 'org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$DownAllTheWay' because the bundle wiring for org.glassfish.hk2.runlevel is no longer valid.
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1494)
at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
... 12 more

Comment by jwells [ 24/Apr/13 ]

I guess I could cause this to stop happening by forcing the loading of the DownAllTheWay class early on. But that seems... stupid...

Comment by jwells [ 24/Apr/13 ]

The problem is in OSGiGlassFishRuntime:

public void shutdown() throws GlassFishException {
if (framework == null)

{ return; // already shutdown }

try

{ framework.stop(); framework.waitForStop(0); }

catch (InterruptedException ex)

{ throw new GlassFishException(ex); } catch (BundleException ex) { throw new GlassFishException(ex); }

super.shutdown();
framework = null; // guard against repeated calls.
}

Notice that the shutdown of the framework happens before the super.shutdown().

But that means that if any of the shutdown work needs to load any classes, they will fail (as we see in this bug).

So I am wondering if this ordering is on purpose, and what the effect would be on changing the ordering to do the super.shutdown first, and the framework shutdown last.

I will try it now, and verify that it fixes this problem and report back in this bug.

Comment by jwells [ 24/Apr/13 ]

In fact, when I change the order this nice thing happens after ^C:

^C
Completed shutdown of Log manager service
Completed shutdown of GlassFish runtime

Comment by jwells [ 24/Apr/13 ]

Here is the diff that fixes this bug:

Index: nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/OSGiGlassFishRuntime.java
===================================================================
— nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/OSGiGlassFishRuntime.java (revision 61615)
+++ nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/OSGiGlassFishRuntime.java (working copy)
@@ -72,6 +72,8 @@
return; // already shutdown
}
try

{ + super.shutdown(); + framework.stop(); framework.waitForStop(0); }

catch (InterruptedException ex)

{ @@ -79,8 +81,9 @@ }

catch (BundleException ex)

{ throw new GlassFishException(ex); }
  • super.shutdown();
  • framework = null; // guard against repeated calls.
    + finally { + framework = null; // guard against repeated calls. + }

    }

@Override

Comment by jwells [ 24/Apr/13 ]

What is the impact on the customer of the bug?

The server will shutdown properly when hit with a kill (15) signal

What is the cost/risk of fixing the bug?

I'm not sure of the cost, and I'd rate the fix as being medium to 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?

EJB, Admin

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.

n/a

Comment by jwells [ 25/Apr/13 ]

Fixed at change 61642





[GLASSFISH-20375] JNDI does not work in HttpUpgradeHandler#init and ReadListener#onDataAvailable, etc Created: 23/Apr/13  Updated: 23/Apr/13  Resolved: 23/Apr/13

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

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

Tags: 4_0-approved

 Description   

While running a Servlet 3.1 upgrade web application with CDI, I see the following in server.log:
No valid EE environment for injection of test.Test

After discussing with CDI team, we found that the JNDI lookup is not working in ReadListener#onDataAvailable.
After further investigation, I found that the JNDI lookup is not workiing for HttpUpgradeHandler and Read/WriteListener methods.



 Comments   
Comment by Shing Wai Chan [ 23/Apr/13 ]
  • What is the impact on the customer of the bug?
    JNDI is not working in upgrade and non-blocking IO listeners.
    This will also impact the CDI operations.
  • What is the cost/risk of fixing the bug?
    Calling InvocationManager.preInvoke/postInvoke around corresponding operations.
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    SQE web and CDI related tests
  • Which is the targeted build of 4.0 for this fix?
    4.0_b86
  • 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 Shing Wai Chan [ 23/Apr/13 ]

Sending appserver/web/web-core/src/main/java/org/apache/catalina/ContainerEvent.java
Sending appserver/web/web-core/src/main/java/org/apache/catalina/connector/InputBuffer.java
Sending appserver/web/web-core/src/main/java/org/apache/catalina/connector/OutputBuffer.java
Sending appserver/web/web-core/src/main/java/org/apache/catalina/connector/WebConnectionImpl.java
Sending appserver/web/web-core/src/main/java/org/apache/catalina/core/StandardPipeline.java
Sending appserver/web/web-glue/src/main/java/com/sun/web/server/WebContainerListener.java
Transmitting file data ......
Committed revision 61589.





[GLASSFISH-20372] Globals.get throws unexpected exception IllegalStateException during shutdown Created: 22/Apr/13  Updated: 23/Apr/13  Resolved: 23/Apr/13

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

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

Issue Links:
Dependency
depends on HK2-110 Globals.get() throws java.lang.Illega... Resolved
Tags: 4_0-approved

 Description   

Revision 61428 for GLASSFISH-20206 causes WARNING when jmsra is shut down. The reason might be catching MultiException instead of RunLevelException.

Index: D:/work_dir/glassfish/trunk/all/main/appserver/jms/jms-core/src/main/java/com/sun/enterprise/connectors/jms/system/ActiveJmsResourceAdapter.java
===================================================================
— D:/work_dir/glassfish/trunk/all/main/appserver/jms/jms-core/src/main/java/com/sun/enterprise/connectors/jms/system/ActiveJmsResourceAdapter.java (revision 61427)
+++ D:/work_dir/glassfish/trunk/all/main/appserver/jms/jms-core/src/main/java/com/sun/enterprise/connectors/jms/system/ActiveJmsResourceAdapter.java (revision 61428)
@@ -126,9 +126,9 @@
import org.glassfish.server.ServerEnvironmentImpl;

import org.jvnet.hk2.annotations.Service;
+import org.glassfish.hk2.api.MultiException;
import org.glassfish.hk2.api.PostConstruct;
import org.glassfish.hk2.api.ServiceLocator;
-import org.glassfish.hk2.runlevel.RunLevelException;

import javax.inject.Singleton;
import org.jvnet.hk2.config.types.Property;
@@ -402,7 +402,7 @@
GrizzlyService grizzlyService = null;
try

{ grizzlyService = Globals.get(GrizzlyService.class); - }

catch (RunLevelException rle)

{ + }

catch (MultiException rle)

{ // if GrizzlyService was shut down already, skip removing the proxy. }

if (grizzlyService != null)

To reproduce it:

1. start glassfish
2. asadmin jms-ping --target server
3. shut down glassfish

Then WARNING appears in server.log,

[2013-04-22T11:13:48.973+0800] [glassfish 4.0] [WARNING] [] [javax.enterprise.resource.jms.com.sun.enterprise.connectors.jms.system] [tid: _ThreadID=133 _ThreadName=Thread-29] [timeMillis: 1366600428973] [levelValue: 900] [[
Error occurs when shutting down JMSRA: Service com.sun.enterprise.v3.services.impl.GrizzlyService was started at level 0 but it has a run level of 10. The full descriptor is SystemDescriptor(
implementation=com.sun.enterprise.v3.services.impl.GrizzlyService
contracts=

{com.sun.enterprise.v3.services.impl.GrizzlyService,org.glassfish.api.container.RequestDispatcher}
scope=org.glassfish.hk2.runlevel.RunLevel
qualifiers={}
descriptorType=CLASS
descriptorVisibility=NORMAL
metadata=runLevelValue={10},Bundle-SymbolicName={org.glassfish.main.core.kernel},Bundle-Version={4.0.0.SNAPSHOT}
rank=50
loader=OsgiPopulatorPostProcessor.HK2Loader(OSGiModuleImpl:: Bundle = [org.glassfish.main.core.kernel [192]], State = [READY],9394331)
proxiable=null
analysisName=null
id=690
locatorId=0
identityHashCode=16925195
reified=true)]]

[2013-04-22T11:13:48.973+0800] [glassfish 4.0] [WARNING] [ra.stop.failed] [javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service] [tid: _ThreadID=132 _ThreadName=Thread-28] [timeMillis: 1366600428973] [levelValue: 900] [[
RAR8053: RA [ jmsra ] stop failed, java.util.concurrent.ExecutionException: java.lang.RuntimeException: java.lang.IllegalStateException: Service com.sun.enterprise.v3.services.impl.GrizzlyService was started at level 0 but it has a run level of 10. The full descriptor is SystemDescriptor(
implementation=com.sun.enterprise.v3.services.impl.GrizzlyService
contracts={com.sun.enterprise.v3.services.impl.GrizzlyService,org.glassfish.api.container.RequestDispatcher}

scope=org.glassfish.hk2.runlevel.RunLevel
qualifiers={}
descriptorType=CLASS
descriptorVisibility=NORMAL
metadata=runLevelValue=

{10},Bundle-SymbolicName={org.glassfish.main.core.kernel},Bundle-Version={4.0.0.SNAPSHOT}
rank=50
loader=OsgiPopulatorPostProcessor.HK2Loader(OSGiModuleImpl:: Bundle = [org.glassfish.main.core.kernel [192]], State = [READY],9394331)
proxiable=null
analysisName=null
id=690
locatorId=0
identityHashCode=16925195
reified=true)]]

[2013-04-22T11:13:48.974+0800] [glassfish 4.0] [INFO] [] [javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service] [tid: _ThreadID=132 _ThreadName=Thread-28] [timeMillis: 1366600428974] [levelValue: 800] [[
shutdown of RA [ jmsra ] is either already complete or already cancelled]]

[2013-04-22T11:13:48.974+0800] [glassfish 4.0] [WARNING] [ra.stop-unsuccessful] [javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service] [tid: _ThreadID=132 _ThreadName=Thread-28] [timeMillis: 1366600428974] [levelValue: 900] [[
RAR7095: jmsra shutdown unsuccessful. Please refer the server and/or resource adapter logs for more information.]]

*****************************
StackTrace
*****************************

[2013-04-22T20:44:40.836+0800] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=133 _ThreadName=Thread-8] [timeMillis: 1366634680836] [levelValue: 1000] [[
java.lang.IllegalStateException: Service com.sun.enterprise.v3.services.impl.GrizzlyService was started at level 0 but it has a run level of 10. The full descriptor is SystemDescriptor(
implementation=com.sun.enterprise.v3.services.impl.GrizzlyService
contracts={com.sun.enterprise.v3.services.impl.GrizzlyService,org.glassfish.api.container.RequestDispatcher}
scope=org.glassfish.hk2.runlevel.RunLevel
qualifiers={}
descriptorType=CLASS
descriptorVisibility=NORMAL
metadata=runLevelValue={10}

,Bundle-SymbolicName=

{org.glassfish.main.core.kernel}

,Bundle-Version=

{4.0.0.SNAPSHOT}

rank=50
loader=OsgiPopulatorPostProcessor.HK2Loader(OSGiModuleImpl:: Bundle = [org.glassfish.main.core.kernel [192]], State = [READY],2947307)
proxiable=null
analysisName=null
id=690
locatorId=0
identityHashCode=9063159
reified=true)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.validate(AsyncRunLevelContext.java:228)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:155)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:579)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:566)
at org.glassfish.internal.api.Globals.get(Globals.java:86)
at com.sun.enterprise.connectors.jms.system.ActiveJmsResourceAdapter.destroy(ActiveJmsResourceAdapter.java:404)
at com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl$RAShutdownTask.run(ResourceAdapterAdminServiceImpl.java:624)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)]]



 Comments   
Comment by jwells [ 22/Apr/13 ]

This is causing some shutdown processing to not occur which is then in turn causing subsequent reboots of the server to fail.

Comment by jwells [ 23/Apr/13 ]

What is the impact on the customer of the bug?

When a customer that has used JMS shuts the server down there will not be a log. This is also possibly causing subsequent reboots to fail, as JMS is not coming down properly.

What is the cost/risk of fixing the bug?

Right now several automated testing suites are failing because the server is not shutting down. Hence the risk for not fixing this bug is high. The risk is also very small.

Is there an impact on documentation or message strings?

No

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

EJB, Admin, Web

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.

http://gf-hudson.us.oracle.com/hudson/job/promote-hk2/185/changes
https://java.net/jira/browse/HK2-110

There is also a minor performance change in this set of changes

Comment by Tom Mueller [ 23/Apr/13 ]

Approved for 4.0. However, I don't see the connection between this failure and subsequent server starts. Please explain that.

Comment by jwells [ 23/Apr/13 ]

The explanation is that since JMS is not shutting down properly it is possible it is holding file descriptors for transaction logs or network descriptors. If the next server process boots prior to the last one truly shutting down it is possible that there could be an issue booting the next server. However, I have not observed this myself, nor do I have any proof. So... it is just a theory!

Comment by jwells [ 23/Apr/13 ]

Fixed at change 61595





[GLASSFISH-20369] The I/O streams should be closed before resuming since they might not be available after resume in upgrade. Created: 22/Apr/13  Updated: 22/Apr/13  Resolved: 22/Apr/13

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

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

Tags: 4_0-approved

 Description   

The I/O streams should be closed before resuming since they might not be available after resume in upgrade. This can cause NPE when WebConnection#close is performed in ReadListener#onDataAvailable.

Caused by: java.lang.NullPointerException
    at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:261)
    at org.apache.catalina.connector.CoyoteOutputStream.close(CoyoteOutputStream.java:186)
    at org.apache.catalina.connector.WebConnectionImpl.close(WebConnectionImpl.java:126)



 Comments   
Comment by Amy Roh [ 22/Apr/13 ]

What is the impact on the customer of the bug?

Users will see the NPE and stacktrace.

What is the cost/risk of fixing the bug?

Low risk. I have ran web devtests and checked with web socket team to make sure there is no regression.

Is there an impact on documentation or message strings?

No.

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

web/web socket tests

Which is the targeted build of 4.0 for this fix?

4.0_b86_RC2

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

na

Comment by Tom Mueller [ 22/Apr/13 ]

Approved for 4.0.

Comment by Amy Roh [ 22/Apr/13 ]

Fixed in 61581.





[GLASSFISH-20367] [Regression] MES object and MSES object continuosly keep on throwing RejectedExecutionException for succesive submission if once same exception is encountered. Created: 22/Apr/13  Updated: 05/Jun/13  Resolved: 23/Apr/13

Status: Resolved
Project: glassfish
Component/s: concurrency
Affects Version/s: 4.0_b85
Fix Version/s: 4.0_b86_RC2

Type: Bug Priority: Major
Reporter: shobhit.singh Assignee: anthony.lai
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ubuntu


Tags: 4_0-approved, 4_0-release-notes, 4_0-release-notes-completed, 4_0-release-notes-drafted

 Description   

If during submission of a task from servlet1, concurrency utils object eg: concurrent/mes1 throws RejectedExecutionException then if we try to execute another servlet submitting task to same object i.e. concurrent/mes1 it will still keep on throwing RejectedExecutionException.

Applicable to both MES and MSES.



 Comments   
Comment by Alex Pineda [ 22/Apr/13 ]

Assigning to Concurrency Dev lead.

Comment by anthony.lai [ 22/Apr/13 ]

Both servlets would be sharing the same MES object. So if the MES is not able to accept task submission, it would reject task submissions from both servlets.

Comment by anthony.lai [ 23/Apr/13 ]

Got more info from Shobhit.

Some of his testcases test for behavior when an MES resource is disabled. So within those tests they would first disable an MES resource, and then re-enable it. When the next testcase runs, the MES resource is still shut down and thus the next test fails.

This is expected behavior. When an MES resource is disabled and then re-enabled, a different instance of MES is created. The application has retained the reference to the disabled (ie shut down) MES resource and needed to be restarted (such as disabled and then enabled) to reference the active and enabled MES.

Within the test case I notice a problem with the default MES. Even after an application is restarted it is still referencing the default MES that was shut down. Thus I am reopening this issue for this problem.

Comment by anthony.lai [ 23/Apr/13 ]
  • What is the impact on the customer of the bug?

Once the default MES, MSES, or MTF is shutdown, a server restart is required for applications to refer to a working copy of the resource even after the resource is re-enabled. With this fix, only a restart of the application is needed.

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

Low risk. Minor change in DefaultMES, DefaultMSES, and DefaultMTF classes to no longer maintain a cached copy of the MES, MSES, or MTF.

  • Is there an impact on documentation or message strings?
    No
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    QL. Concurrency CTS.
  • Which is the targeted build of 4.0 for this fix?
    4.0_b86
  • 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 anthony.lai [ 23/Apr/13 ]

Project: glassfish
Repository: svn
Revision: 61602
Author: anthony.lai
Date: 2013-04-23 22:51:14 UTC
Link:

Log Message:
------------
GLASSFISH-20367 - remove cached default concurrency resource objects from
deployer classes.
Approved by Michael.
Passed QL and Concurrency CTS.

Revisions:
----------
61602

Modified Paths:
---------------
trunk/main/appserver/concurrent/concurrent-impl/src/main/java/org/glassfish/concurrent/runtime/deployer/DefaultManagedScheduledExecutorService.java
trunk/main/appserver/concurrent/concurrent-impl/src/main/java/org/glassfish/concurrent/runtime/deployer/DefaultManagedExecutorService.java
trunk/main/appserver/concurrent/concurrent-impl/src/main/java/org/glassfish/concurrent/runtime/deployer/DefaultManagedThreadFactory.java

Comment by Alex Pineda [ 14/May/13 ]

Added Release Notes tag so the issue can be documented and communicated to the Glassfish users.

Comment by Gail Risdal [ 31/May/13 ]

Added the following to the release notes:

[Regression] MES object and MSES object continuously keep on throwing RejectedExecutionException for successive submission if once same exception is encountered. (20367)

Description
If multiple servlets share the same concurrent resource (managed executor service, managed scheduled executor service, or managed thread factory), and the resource rejects submission of a task from one servlet, it will reject submission of a task from all other servlets using that resource. This is expected behavior and occurs when a concurrent resource is disabled and then reenabled, at which time a different instance of the resource is created.

Workaround
Restart the application.





[GLASSFISH-20366] [Regression] thread is not starting with an interrupted status. Created: 22/Apr/13  Updated: 24/Apr/13  Resolved: 24/Apr/13

Status: Resolved
Project: glassfish
Component/s: concurrency
Affects Version/s: 4.0_b85
Fix Version/s: 4.0_b86_RC2

Type: Bug Priority: Major
Reporter: shobhit.singh Assignee: anthony.lai
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu


Tags: 4_0-approved

 Description   

When thread is created by ManagedThreadFactory instance but are started after the ManagedThreadFactory has shut down then thread is not starting with an interrupted status.



 Comments   
Comment by Alex Pineda [ 22/Apr/13 ]

Assigning to Concurrency Dev lead.

Comment by anthony.lai [ 23/Apr/13 ]
  • What is the impact on the customer of the bug?

RI behavior is inconsistent with the spec.

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

Low risk. Added a check to interrupt the thread during thread start if the thread is already marked as shutdown.

  • Is there an impact on documentation or message strings?

No

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

QL. Concurrency CTS.

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

4.0_b86

  • 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.

Integration from JSR236 RI project. Only other changes in this new version besides fix for this JIRA issue are only unit tests related.

Comment by anthony.lai [ 24/Apr/13 ]

Project: glassfish
Repository: svn
Revision: 61627
Author: anthony.lai
Date: 2013-04-24 17:04:53 UTC
Link:

Log Message:
------------
GLASSFISH-20366 thread from shutdown MTF should start with interrupted state.
Ran QL and concurrency CTS.

Revisions:
----------
61627

Modified Paths:
---------------
trunk/main/appserver/pom.xml
(pick up fix from JSR236 RI version 1.0-b08)





[GLASSFISH-20361] ml build missing localized woodstock jars Created: 19/Apr/13  Updated: 23/Apr/13  Resolved: 23/Apr/13

Status: Resolved
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0_b85
Fix Version/s: 4.0_b86_RC2

Type: Bug Priority: Major
Reporter: Anissa Lam 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, console

 Description   

I believe the build team is aware of this, but want to keep track of this through the issue.

In latest nightly build, 4/18, there is still missing localized woodstock jars in the ml build.

In 3.1.2 release, the 2 jars is installed under glassfish/modules directory:
1. webui-jsf-plugin-l10n.jar
2. webui-jsf-suntheme-plugin-l10n.jar

Here is the workspace for the 2 woodstock jar for 3.1.2
https://svn.java.net/svn/glassfish~svn/branches/l10n-3.1.2/woodstock/



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 20/Apr/13 ]

These need to be moved from l10n workspace to GlassFish workspace and integrated into packager. Targeting b86.

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

Regression compared to 3.1.2 release. These two jars are required for full Admin GUI localization.

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

Low risk. Fix is limited to migrating existing woodstock localized jar modules from l10n workspace to GlassFish workspace and adjusting pom files.

  • Is there an impact on documentation or message strings?

Fix migrates existing localized content to GF workspace, no further changes to message strings.

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

Admin GUI l10n testing.

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

b86

  • 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





[GLASSFISH-20358] Intermittent issues stopping and starting the server with "java.lang.IllegalStateException: Service already unregistered." Created: 19/Apr/13  Updated: 22/Apr/13  Resolved: 22/Apr/13

Status: Closed
Project: glassfish
Component/s: admin
Affects Version/s: 4.0_b85
Fix Version/s: None

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

Tags: 4_0-approved

 Description   

Web devtests perform many stop/start for functionality testings that require server restart and failing to do so is affecting test results. This intermittent issue is causing multiple failures in web devtests.

The server fails to shut down with an error "java.lang.IllegalStateException: Service already unregistered." and subsequent restart fails since the shutdown did not happen.

According to Sahoo, "it will surely impact embeddability of glassfish which is leveraged in cloudlogic and other places".

[2013-04-25T20:22:24.190-0700] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=63 _ThreadName=Thread-16] [timeMillis: 1366946544190] [levelValue: 800] [[
Server shutdown initiated]]

[2013-04-25T20:22:24.191-0700] [glassfish 4.0] [WARNING] [NCLS-BOOTSTRAP-00029] [javax.enterprise.bootstrap] [tid: _ThreadID=63 _ThreadName=Thread-16] [timeMillis: 1366946544191] [levelValue: 900] [[
Exception while unregistering:
java.lang.IllegalStateException: Service already unregistered.
at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:123)
at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl.unregisterService(EmbeddedOSGiGlassFishImpl.java:93)
at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl.stop(EmbeddedOSGiGlassFishImpl.java:81)
at com.sun.enterprise.v3.admin.StopServer.doExecute(StopServer.java:79)
at com.sun.enterprise.v3.admin.StopDomainCommand.execute(StopDomainCommand.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at org.glassfish.api.AsyncImpl$1$1.run(AsyncImpl.java:76)
]]

.....

[2013-04-25T20:22:47.601-0700] [glassfish 4.0] [INFO] [NCLS-CORE-00017] [javax.enterprise.system.core] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1366946567601] [levelValue: 800] [[
GlassFish Server Open Source Edition 4.0 (re-continuous) startup time : Felix (3,641ms), startup services(3,534ms), total(7,175ms)]]

[2013-04-25T20:22:47.601-0700] [glassfish 4.0] [SEVERE] [NCLS-CORE-00019] [javax.enterprise.system.core] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1366946567601] [levelValue: 1000] [[
Shutting down server due to startup exception
java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:344)
at sun.nio.ch.Net.bind(Net.java:336)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:199)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at org.glassfish.grizzly.nio.transport.TCPNIOBindingHandler.bindToChannelAndAddress(TCPNIOBindingHandler.java:131)
at org.glassfish.grizzly.nio.transport.TCPNIOBindingHandler.bind(TCPNIOBindingHandler.java:87)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.bind(TCPNIOTransport.java:450)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.bind(TCPNIOTransport.java:439)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.bind(TCPNIOTransport.java:95)
at org.glassfish.grizzly.config.GenericGrizzlyListener.start(GenericGrizzlyListener.java:168)
at com.sun.enterprise.v3.services.impl.GlassfishNetworkListener.start(GlassfishNetworkListener.java:94)
at com.sun.enterprise.v3.services.impl.GrizzlyProxy.start(GrizzlyProxy.java:230)
at com.sun.enterprise.v3.services.impl.GrizzlyService.createNetworkProxy(GrizzlyService.java:470)
at com.sun.enterprise.v3.services.impl.GrizzlyService.postConstruct(GrizzlyService.java:393)
at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:281)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:328)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:158)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:673)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:660)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
]]

[2013-04-25T20:22:47.640-0700] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=51 _ThreadName=Thread-13] [timeMillis: 1366946567640] [levelValue: 800] [[
Server shutdown initiated]]



 Comments   
Comment by Amy Roh [ 19/Apr/13 ]

The server.log can be viewed from http://hudson-sca.us.oracle.com/job/webtier-dev-tests-bg/3047/artifact/glassfish-v3-image/glassfish4/glassfish/domains/domain1/logs/server.log.save. FYI, this intermittent issue started happening more consistently from 4/17.

Comment by jwells [ 19/Apr/13 ]

So the exception itself is innocuous, right? I mean, it just means that whatever service it is has already been removed which may happen if Felix comes down before this code is run. There must be some other underlying issue, as this one isn't going to stop any subsequent shutdown processing. This is the code printing out that error:

try

{ reg.unregister(); logger.log(Level.INFO, LogFacade.SERVICE_UNREGISTERED, this); }

catch (IllegalStateException e)

{ LogFacade.log(logger, Level.WARNING, LogFacade.SERVICE_UNREGISTRATION_EXCEPTION, e, e); }

Now, this could be indicative of some race condition that is not fully understood, but this particular warning is not serious. Is the process that had this still running when this happens? Can we get a jstack?

Comment by Amy Roh [ 19/Apr/13 ]

The server does fail to shut down and restart. The ISE is the only exception/error displayed in the server.log. It is possible that some race condition is happening. A jstack isn't available since the hanging issue is no longer happening, the process continues, and finishes the test suite.

Comment by Amy Roh [ 21/Apr/13 ]

This stack trace is sent to interested parties before. Including in the bug report for future reference since java.net is back up.

[2013-04-26T05:45:57.122-0700] [glassfish 4.0] [WARNING] [resources.resource-manager.connector-descriptor.bind.failure] [LogStrings.com.sun.appserv.connectors.internal.api] [tid: _ThreadID=16 _ThreadName=RunLevelControllerThread-1366980356771] [timeMillis: 1366980357122] [levelValue: 900] [[
RAR8706: Unable to bind connector descriptor for resource-adapter [ jaxr-ra ]. Following exception occurred : javax.naming.NamingException: Unable to acquire SerialContextProvider for SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is java.lang.NullPointerException]]]

[2013-04-26T05:45:57.121-0700] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=16 _ThreadName=Thread-8] [timeMillis: 1366980357121] [levelValue: 1000] [[
java.lang.NullPointerException
at com.sun.enterprise.naming.impl.SerialContext.getORB(SerialContext.java:347)
at com.sun.enterprise.naming.impl.SerialContext.getProviderCacheKey(SerialContext.java:354)
at com.sun.enterprise.naming.impl.SerialContext.getRemoteProvider(SerialContext.java:384)
at com.sun.enterprise.naming.impl.SerialContext.getProvider(SerialContext.java:329)
at com.sun.enterprise.naming.impl.SerialContext.rebind(SerialContext.java:675)
at com.sun.enterprise.naming.impl.SerialContext.rebind(SerialContext.java:692)
at javax.naming.InitialContext.rebind(InitialContext.java:431)
at javax.naming.InitialContext.rebind(InitialContext.java:431)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.publishObject(GlassfishNamingManagerImpl.java:210)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.publishObject(GlassfishNamingManagerImpl.java:196)
at com.sun.appserv.connectors.internal.ConnectorResourceManagerLifecycleListener.bindConnectorDescriptorProxies(ConnectorResourceManagerLifecycleListener.java:147)
at com.sun.appserv.connectors.internal.ConnectorResourceManagerLifecycleListener.bindConnectorDescriptors(ConnectorResourceManagerLifecycleListener.java:136)
at com.sun.appserv.connectors.internal.ConnectorResourceManagerLifecycleListener.resourceManagerStarted(ConnectorResourceManagerLifecycleListener.java:184)
at com.sun.appserv.connectors.internal.ConnectorResourceManagerLifecycleListener.resourceManagerLifecycleEvent(ConnectorResourceManagerLifecycleListener.java:177)
at org.glassfish.resourcebase.resources.listener.ResourceManager.notifyListeners(ResourceManager.java:132)
at org.glassfish.resourcebase.resources.listener.ResourceManager.postConstruct(ResourceManager.java:123)
at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:281)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:328)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:158)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:673)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:660)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)]]

[2013-04-26T05:45:58.958-0700] [glassfish 4.0] [INFO] [NCLS-CORE-00015] [javax.enterprise.system.core] [tid: _ThreadID=13 _ThreadName=RunLevelControllerThread-1366980356767] [timeMillis: 1366980358958] [levelValue: 800] [[
Shutdown requested
MultiException stack 1 of 1
MultiException stack 1 of 4
java.lang.RuntimeException: javax.naming.NamingException: Unable to acquire SerialContextProvider for SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}

[Root exception is java.lang.NullPointerException]
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.postConstruct(InjectionManagerImpl.java:117)
at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:281)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:328)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:558)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:191)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:214)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:311)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:158)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:673)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:660)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$UpOneJob.run(CurrentTaskFuture.java:490)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: javax.naming.NamingException: Unable to acquire SerialContextProvider for SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is java.lang.NullPointerException]
at com.sun.enterprise.naming.impl.SerialContext.getProvider(SerialContext.java:334)
at com.sun.enterprise.naming.impl.SerialContext.rebind(SerialContext.java:675)
at com.sun.enterprise.naming.impl.SerialContext.rebind(SerialContext.java:692)
at javax.naming.InitialContext.rebind(InitialContext.java:431)
at javax.naming.InitialContext.rebind(InitialContext.java:431)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.publishObject(GlassfishNamingManagerImpl.java:210)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.publishObject(GlassfishNamingManagerImpl.java:196)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.postConstruct(InjectionManagerImpl.java:114)
... 21 more
Caused by: java.lang.NullPointerException
at com.sun.enterprise.naming.impl.SerialContext.getORB(SerialContext.java:347)
at com.sun.enterprise.naming.impl.SerialContext.getProviderCacheKey(SerialContext.java:354)
at com.sun.enterprise.naming.impl.SerialContext.getRemoteProvider(SerialContext.java:384)
at com.sun.enterprise.naming.impl.SerialContext.getProvider(SerialContext.java:329)
... 28 more
MultiException stack 2 of 4
java.lang.IllegalStateException: Unable to perform operation: post construct on com.sun.enterprise.container.common.impl.util.InjectionManagerImpl
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:346)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:558)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:191)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:214)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:311)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:158)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:673)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:660)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$UpOneJob.run(CurrentTaskFuture.java:490)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
MultiException stack 3 of 4
java.lang.IllegalArgumentException: While attempting to resolve the dependencies of com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl errors were found
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:226)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:311)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:158)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:673)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:660)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$UpOneJob.run(CurrentTaskFuture.java:490)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
MultiException stack 4 of 4
java.lang.IllegalStateException: Unable to perform operation: resolve on com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:340)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:158)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:673)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:660)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$UpOneJob.run(CurrentTaskFuture.java:490)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)

[2013-04-26T05:45:59.018-0700] [glassfish 4.0] [SEVERE] [NCLS-CORE-00016] [javax.enterprise.system.core] [tid: _ThreadID=13 _ThreadName=RunLevelControllerThread-1366980356767] [timeMillis: 1366980359018] [levelValue: 1000] [[
Startup service failed to start
MultiException stack 1 of 1
MultiException stack 1 of 4
java.lang.RuntimeException: javax.naming.NamingException: Unable to acquire SerialContextProvider for SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}

[Root exception is java.lang.NullPointerException]
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.postConstruct(InjectionManagerImpl.java:117)
at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:281)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:328)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:558)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:191)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:214)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:311)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:158)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:673)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:660)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$UpOneJob.run(CurrentTaskFuture.java:490)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: javax.naming.NamingException: Unable to acquire SerialContextProvider for SerialContext[myEnv=

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

[Root exception is java.lang.NullPointerException]
at com.sun.enterprise.naming.impl.SerialContext.getProvider(SerialContext.java:334)
at com.sun.enterprise.naming.impl.SerialContext.rebind(SerialContext.java:675)
at com.sun.enterprise.naming.impl.SerialContext.rebind(SerialContext.java:692)
at javax.naming.InitialContext.rebind(InitialContext.java:431)
at javax.naming.InitialContext.rebind(InitialContext.java:431)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.publishObject(GlassfishNamingManagerImpl.java:210)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.publishObject(GlassfishNamingManagerImpl.java:196)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.postConstruct(InjectionManagerImpl.java:114)
... 21 more
Caused by: java.lang.NullPointerException
at com.sun.enterprise.naming.impl.SerialContext.getORB(SerialContext.java:347)
at com.sun.enterprise.naming.impl.SerialContext.getProviderCacheKey(SerialContext.java:354)
at com.sun.enterprise.naming.impl.SerialContext.getRemoteProvider(SerialContext.java:384)
at com.sun.enterprise.naming.impl.SerialContext.getProvider(SerialContext.java:329)
... 28 more
MultiException stack 2 of 4
java.lang.IllegalStateException: Unable to perform operation: post construct on com.sun.enterprise.container.common.impl.util.InjectionManagerImpl
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:346)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:558)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:191)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:214)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:311)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:158)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:673)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:660)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$UpOneJob.run(CurrentTaskFuture.java:490)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
MultiException stack 3 of 4
java.lang.IllegalArgumentException: While attempting to resolve the dependencies of com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl errors were found
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:226)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:311)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:158)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:673)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:660)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$UpOneJob.run(CurrentTaskFuture.java:490)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
MultiException stack 4 of 4
java.lang.IllegalStateException: Unable to perform operation: resolve on com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:340)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:158)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:673)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:660)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$UpOneJob.run(CurrentTaskFuture.java:490)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
]]

[2013-04-26T05:45:59.133-0700] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=57 _ThreadName=Thread-12] [timeMillis: 1366980359133] [levelValue: 800] [[
Server shutdown initiated]]

[2013-04-26T05:45:59.138-0700] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=58 _ThreadName=Thread-13] [timeMillis: 1366980359138] [levelValue: 800] [[
Server shutdown initiated]]

[2013-04-26T05:45:59.141-0700] [glassfish 4.0] [INFO] [NCLS-BOOTSTRAP-00027] [javax.enterprise.bootstrap] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1366980359141] [levelValue: 800] [[
Registered com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl@66e9d9f0 as OSGi service registration: org.apache.felix.framework.ServiceRegistrationImpl@5cf33dce.]]

[2013-04-26T05:45:59.401-0700] [glassfish 4.0] [INFO] [NCLS-JMX-00005] [javax.enterprise.system.jmx] [tid: _ThreadID=52 _ThreadName=Thread-11] [timeMillis: 1366980359401] [levelValue: 800] [[
JMXStartupService has started JMXConnector on JMXService URL service:jmx:rmi://don-vm2.us.oracle.com:53510/jndi/rmi://don-vm2.us.oracle.com:53510/jmxrmi]]

[2013-04-26T05:46:00.150-0700] [glassfish 4.0] [INFO] [NCLS-BOOTSTRAP-00028] [javax.enterprise.bootstrap] [tid: _ThreadID=57 _ThreadName=Thread-12] [timeMillis: 1366980360150] [levelValue: 800] [[
Unregistered com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl@66e9d9f0 from service registry.]]

[2013-04-26T05:46:00.151-0700] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=57 _ThreadName=Thread-7] [timeMillis: 1366980360151] [levelValue: 800] [[
FileMonitoring shutdown]]

[2013-04-26T05:46:00.155-0700] [glassfish 4.0] [WARNING] [NCLS-BOOTSTRAP-00029] [javax.enterprise.bootstrap] [tid: _ThreadID=58 _ThreadName=Thread-13] [timeMillis: 1366980360155] [levelValue: 900] [[
Exception while unregistering:
java.lang.IllegalStateException: Service already unregistered.
at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:123)
at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl.unregisterService(EmbeddedOSGiGlassFishImpl.java:93)
at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl.stop(EmbeddedOSGiGlassFishImpl.java:81)
at com.sun.enterprise.v3.admin.StopServer.doExecute(StopServer.java:79)
at com.sun.enterprise.v3.admin.StopDomainCommand.execute(StopDomainCommand.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:537)
at org.glassfish.api.AsyncImpl$1$1.run(AsyncImpl.java:76)

Comment by jwells [ 22/Apr/13 ]

I have fixed two deadlocks in logging by adding dependencies in the services and have also ensured that the Globals service has been moved to start level 0 to ensure that it comes up prior to any services at level 1 get started (which will get rid of the NPE reported in this bug).

I have run quicklook and the EJB devtests...

Comment by jwells [ 22/Apr/13 ]

The change number that I believe fixes this is 61580.

Comment by jwells [ 22/Apr/13 ]

This has broken some upstream Hudsons. I have a fix, so I'll re-open this until the new and improved fix is in.

Comment by jwells [ 22/Apr/13 ]

Change 61582 uses a common API interface rather than the services themselves which is a better solution and should fix the upstream Hudsons.





[GLASSFISH-20356] JPA remote SLSB tests failed with CDI enabled Created: 19/Apr/13  Updated: 03/May/13  Resolved: 26/Apr/13

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

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

OEL6, JDK1.7.0_10


Tags: 4_0-approved

 Description   

JPA remote SLSB tests failed with CDI enabled
glassfish-4.0-b85.zip
appserver-sqe/pe/ejb/ejb30/issue/1153/basic
Testing EJB3 Issue 1153
appserver-sqe/pe/ejb/ejb30/issue/1251
Testing EJB 3.0 Issue 1251 Multiple PUs

Tests failed on b85 promoted, but passed on b84 promoted.

Thanks Mitesh for the initial analysis:
Injection of EntityManager not happening into a remote SLSB.
The tests started to fail with nightly of Apr 12 and pass
after disabling implicit-cdi (using asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=false).



 Comments   
Comment by Mitesh Meswani [ 19/Apr/13 ]

Assigning to JJ since this issue is due to enable-implicit-cdi

Comment by tlcksnyder [ 19/Apr/13 ]

Exception from 1153 log ftp://adc2120166.us.oracle.com/pub/tmp/appserver-sqe_130418_EJB3_six_test_failure/issue_1153_basic.server.log.txt:
java.lang.NullPointerException
at SessionBean.findPerson(SessionBean.java:52)
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:55)
at sun.reflect.GeneratedMethodAccessor53.invoke(Unknown Source)
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.GeneratedMethodAccessor85.invoke(Unknown Source)
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.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:205)
at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:79)
at $Proxy400.findPerson(Unknown Source)
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.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:143)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:173)
at com.sun.corba.ee.impl.protocol.ServerRequestDispatcherImpl.dispatchToServant(ServerRequestDispatcherImpl.java:528)
at com.sun.corba.ee.impl.protocol.ServerRequestDispatcherImpl.dispatch(ServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequestRequest(MessageMediatorImpl.java:1549)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequest(MessageMediatorImpl.java:1425)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleInput(MessageMediatorImpl.java:930)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:213)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequest(MessageMediatorImpl.java:694)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.dispatch(MessageMediatorImpl.java:496)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.doWork(MessageMediatorImpl.java:2222)
at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)]]

Exception for 1251 ftp://adc2120166.us.oracle.com/pub/tmp/appserver-sqe_130418_EJB3_six_test_failure/issue_1251_server_log.txt

Comment by jjsnyder83 [ 19/Apr/13 ]

Can you provide info on how to download and execute the tests?

Comment by sherryshen [ 19/Apr/13 ]

1) To set up test env, please reference the instruction section I, IIa
http://aseng-wiki.us.oracle.com/asengwiki/display/ASQA/4.0+Core+Test+Instructions
(use co-ejb instead of co-core to save check out time).

After check out, do

$ ant start-domain
$ ant startDerby

in $SPS_HOME to start glassfish and derby.

2) To run test suite, do "ant all" in test suite dir, e.g.
appserver-sqe/pe/ejb/ejb30/issue/1153/basic
appserver-sqe/pe/ejb/ejb30/issue/1251

Comment by jjsnyder83 [ 25/Apr/13 ]

What is the impact on the customer of the bug?
EJB's won't work.

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?
The tests listed in this jira.

What is the cost/risk of fixing the bug?
N/A

How risky is the fix? How much work is the fix? Is the fix complicated?
N/A

Is there an impact on documentation or message strings?
No

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

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

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

Comment by jjsnyder83 [ 26/Apr/13 ]

Committed revision 61664.

Comment by sherryshen [ 03/May/13 ]

Verified the fix on build 87 promoted on May 1, 2013.





[GLASSFISH-20354] EJBException thrown in JAXRS resource that's also an EJB bean is sometimes consumed by CDI Created: 19/Apr/13  Updated: 23/Apr/13  Resolved: 23/Apr/13

Status: Resolved
Project: glassfish
Component/s: jax-rs
Affects Version/s: 4.0_b85
Fix Version/s: 4.0_b86_RC2

Type: Bug Priority: Critical
Reporter: jan.supol Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-20385 Integrate Jersey 2.0-rc2 into the GF ... Resolved
Tags: 4_0-approved

 Description   

In a resource

@Stateless
@Path("/ssb")
public class StatelessRootResource {
	@Path("exception")
	@GET
	public String throwException() {
		throw new EJBException(new WebApplicationException(Status.CREATED));
	}
}

the EJBException should be unwrapped and the exception processed by JAXRS according to JAXRS Spec. However, this only happens in about 50% of deployments (tested 15times in a row). It seems that status 201 is returned only when JAXRS container is dealing with it. Sometimes, Status 500 returned and the exception is logged to server log. However, when

asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=false

,
Status 201 has been returned 10x in a row, no 500.



 Comments   
Comment by Jakub Podlesak [ 19/Apr/13 ]

As discussed offline with Jan, we need to make sure Jersey's EJB component provider takes precedence over the CDI one.

Comment by Jakub Podlesak [ 19/Apr/13 ]

set fixByVersion to b86. The fix should be delivered as part of Jersey 2.0-rc2

Comment by Jakub Podlesak [ 23/Apr/13 ]

This has already been fixed in Jersey 2.0-rc2, where EJB component provider takes precedence over the CDI one, so that also appropriated Exception mapper is configured all right.

Comment by Jakub Podlesak [ 23/Apr/13 ]

Added 4_0-review tag, required info for the review follow:

  • What is the impact on the customer of the bug?
  • If this was not fixed, customer would likely face a nasty non-deterministic behaviour (this bug shows up in 6 out of 10 cases)
    -This is clearly a regression
  • What is the cost/risk of fixing the bug?
  • The risk is quite low, and the bug was already fixed in Jersey 2.0-rc2
  • Is there an impact on documentation or message strings?
  • There is no such impact.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
  • JAX-RS/EJB integration tests
  • Which is the targeted build of 4.0 for this fix?
  • b86
Comment by Jakub Podlesak [ 23/Apr/13 ]

Fixed with Jersey 2.0-rc2 integration (https://java.net/jira/browse/GLASSFISH-20385)





[GLASSFISH-20353] Login failed: unable to find LoginModule class: com.sun.enterprise.security.auth.login.LDAPLoginModule Created: 19/Apr/13  Updated: 22/Apr/13  Resolved: 22/Apr/13

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

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

security-devtests-trunk


Tags: 4_0-approved

 Description   

The LDAP realm security devtests fail with OOTB configuration:

[2013-04-18T13:19:57.083-0700] [glassfish 4.0] [WARNING] [web.login.failed] [javax.enterprise.system.container.web.com.sun.web.security] [tid: _ThreadID=20 _ThreadName=http-listener-1(2)] [timeMillis: 1366316397083] [levelValue: 900] [[
WEB9102: Web Login Failed: com.sun.enterprise.security.auth.login.common.LoginException: Login failed: unable to find LoginModule class: com.sun.enterprise.security.auth.login.LDAPLoginModule]]



 Comments   
Comment by Craig Perez [ 19/Apr/13 ]

I have workaround for the Husdon job that updates <domain>/config/login.conf to use:

ldapRealm

{ org.glassfish.security.services.impl.LDAPLoginModule required; }

;

Comment by Tim Quinn [ 19/Apr/13 ]

Do not restore the original class. I moved it as part of fixing a separate issue (GLASSFISH-20125). I thought I scoured the entire system for references to it but obviously missed this one.

The login.conf needs to be updated to refer to the class in its new place.

[shaun]If we revise login.conf of GF4.0 with new package name, any issue for domain upgrade on existing domain? Or should something be done on domain upgrade?

Comment by Tim Quinn [ 19/Apr/13 ]

Good point, Sean. The domain upgrade should deal with this. I am not sure but I suspect the upgrade does not currently deal with login.conf.

Comment by spei [ 22/Apr/13 ]

What is the impact on the customer of the bug?

If some uses the LDAPRealm, he may get a ClassNotFoundExcepton since the package name was revised for LDAPLoginModule.

What is the cost/risk of fixing the bug?

Low risk. Restored the package name to its original com.sun.enterprise.security.auth.login.LDAPLoginModule, revised the LDAPAdminAccessConfigurator to use the old package name; this avoids the upgrade issue;

Is there an impact on documentation or message strings?

No.

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

Security tests

Which is the targeted build of 4.0 for this fix?

4.0_b86_RC2

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

na

Comment by Tom Mueller [ 22/Apr/13 ]

Approved for 4.0.

Comment by spei [ 22/Apr/13 ]

Restore the LDAPLoginmodule to original package com.sun.enterprise.security.auth.login, also removed security devtest workaround.

Committed revision 61583.
Committed revision 61584.





[GLASSFISH-20352] Integrate JDK 7u21 into Java EE 7 SDK cobundles Created: 19/Apr/13  Updated: 29/Apr/13  Resolved: 29/Apr/13

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

Type: Bug Priority: Major
Reporter: Snjezana Sevo-Zenzerovic 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   

Java EE 7 SDK cobundles with JDK should contain JDK 7u21 which is about to be released.

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

Java EE 7 SDK cobundles with JDK are expected to contain the latest available JDK release.

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

Low risk.

  • Is there an impact on documentation or message strings?

Documentation should reference JDK 7u21 as part of SDK cobundles.

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

BAT test suite, which is standard to verify JDK integrations.

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

SDK b85.

  • 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.

This integrates JDK 7u21.



 Comments   
Comment by Tom Mueller [ 19/Apr/13 ]

Approved for 4.0.





[GLASSFISH-20351] Uptake Weld 2.0.0.CR4 Created: 19/Apr/13  Updated: 23/Apr/13  Resolved: 23/Apr/13

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

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

Tags: 4_0-approved

 Description   

What is the impact on the customer of the bug?
Customers can't run without it

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?
It is the latest version of Weld so we must have it

What is the cost/risk of fixing the bug?
N/A

How risky is the fix? How much work is the fix? Is the fix complicated?
N/A

Is there an impact on documentation or message strings?
No

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

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

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 [ 19/Apr/13 ]

Approved for 4.0.

Comment by tlcksnyder [ 23/Apr/13 ]

skipping CR3 & uptaking CR4 instead.

Comment by jjsnyder83 [ 23/Apr/13 ]

Committed revision 61592.





Loading of HK2 cache data slows down server initialization (GLASSFISH-20298)

[GLASSFISH-20350] Make DescriptorImpl Externalizable instead of Serializable Created: 19/Apr/13  Updated: 19/Apr/13  Resolved: 19/Apr/13

Status: Closed
Project: glassfish
Component/s: hk2
Affects Version/s: None
Fix Version/s: 4.0_b87_RC3

Type: Sub-task 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   

From parent task:

I've measured the time required for loadCachedData in both 4.0 and 3.1.2. This is for a subsequent restart, and is an average of 5 runs on a MBP:

4.0: 424 ms ("Felix" start time is 2726 ms), inhabitants size = 516415
3.1.2: 194 ms ("Felix start time is 1615 ms), inhabitants size = 371748

loadCachedData is approximately 20-25% faster if DescriptorImpl implements Externalizable (using the string-based representation of a Descriptor) instead of Serializable.

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

Startup performance on a 'warm boot' is slowed down by serialization

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

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?

quicklook

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

4.0_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.


 Comments   
Comment by Tom Mueller [ 19/Apr/13 ]

Approved for 4.0

Comment by mtaube [ 19/Apr/13 ]

Committed revision 61562.





[GLASSFISH-20346] csfFLOWDISCOVERYCDIHELPER registered multiple times causing ambiguous resolution Created: 10/Apr/13  Updated: 26/Apr/13  Resolved: 26/Apr/13

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

Type: Bug Priority: Critical
Reporter: Jozef Hartinger Assignee: Manfred Riem
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved

 Description   

FlowDiscoveryCDIHelper is both deployed in an explicit bean archive and registered by FlowDiscoveryCDIExtension. This causes the bean to be registered twice which results in the deployment exception.



 Comments   
Comment by Jozef Hartinger [ 10/Apr/13 ]

The JSF RI jar contains a beans.xml file which is not necessary.

Comment by Ed Burns [ 10/Apr/13 ]

In practice, I found the beans.xml was necessary to enable the flow discovery to work on both GlassFish 3.1.2.2 and GlassFish 4.0, each of which have different versions of Weld.

Let me take it out and try again. Whatever we end up with, it must work on both GlassFish 3.1.2.2 and GlassFish 4.0.

Comment by Ed Burns [ 10/Apr/13 ]

Can you please send a reproducer to issues@javaserverfaces.java.net ?

Thanks,

Ed

Comment by Jozef Hartinger [ 11/Apr/13 ]

Any war with CDI enabled causes the failure. It may not in GF as GF is not probably picking up the archive as a BDA but then there is no point in having beans.xml in the Mojarra archive anyway.

It causes problem with JBoss AS integration and it will also cause problems if you try to bundle a JSF impl with your deployment (when deploying to a plain Servlet container).

Check the bean archive definition and how bean discovery works at https://github.com/jboss/cdi/blob/master/spec/packagingdeployment.asciidoc

Comment by Manfred Riem [ 11/Apr/13 ]

Jozef,

As stated by Ed we need to make sure this works both on GF 3.1.2.2 and GF 4.0. If we remove the beans.xml how can we make sure the Weld 1.1.x runtime (which is part of GF 3.1.2.2) registers the FlowDiscoveryCDIExtension? Is there an API that we can use to do so?

Comment by Jozef Hartinger [ 11/Apr/13 ]

beans.xml was never a requirement for extension registration. There is an API:

https://github.com/weld/api/blob/2.0/weld-spi/src/main/java/org/jboss/weld/bootstrap/spi/Deployment.java#L153

However, at least for GF 4 you do not need to use it. The extension is picked up automatically.

Comment by Manfred Riem [ 11/Apr/13 ]

Jozef,

We need to have it work both in 3.1.2.2 and 4.0. If I remove the beans.xml file the 3.1.2.2 server won't pick it up anymore. So how can I register the extension manually in that case? Do you have a code sample anywhere I can look at?

Thanks!

Comment by Jozef Hartinger [ 11/Apr/13 ]

If that really happens on 3.1 then you would need to fix GF's Weld integration code in 3.1.

Comment by Manfred Riem [ 12/Apr/13 ]

Applied to 2.2 trunk,

svn commit -m "Removing beans.xml to see if GF 3.1.2.2 requires it" beans.xml
Deleting beans.xml

Committed revision 11874.

Both the 3.1.2.2 and 4.0 are fine with this change. Inspection of the JAR file does not show the beans.xml as in the location it was in previously.

Comment by Manfred Riem [ 18/Apr/13 ]

Applied to 2.2.0 branch,

svn commit -m "Removing unnecessary beans.xml file, which will prevent double registration of the csfFLOWDISCOVERYCDIHELPER"
Deleting share\beans.xml

Committed revision 11888.

Comment by Ed Burns [ 18/Apr/13 ]
  • What is the impact on the customer of the bug?

A customer is seeing this bug when running Mojarra in JBoss AS. The impact is that apps fail to deploy.

  • What CTS failures are caused by this bug?

No known.

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

Cost: remove beans.xml from javax.faces.jar. Risk: destabilize weld integration.

  • Is there an impact on documentation or message strings?

No.

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

Tests that show weld working with JSF.

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

b86.

  • 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.
Comment by Tom Mueller [ 18/Apr/13 ]

Approved for 4.0.

Comment by Ed Burns [ 26/Apr/13 ]

This will be in 2.2.0-m15, due for integration on Monday 29 April 2013.

Comment by Manfred Riem [ 26/Apr/13 ]

Verified the tests are all still passing.





[GLASSFISH-20342] [REGRESSION] Remote SFSB.remove fails with IllegalStateException: Transaction exists on current thread. Created: 17/Apr/13  Updated: 30/Apr/13  Resolved: 30/Apr/13

Status: Resolved
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0_b87_RC3

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

linux


Tags: 4_0-approved, ian

 Description   

build: promoted build84

This is a Regression bug since the same tests passed against build83. I am not sure which component this bug belongs to and I just assign it to JMS module, please feel free to assign it to other component owner if it's not a JMS bug. Thanks.

Steps to reproduce the bug:

1. Install GF4.0, start domain
2. Checkout SQE workspace:
cvs co appserver-sqe/bootstrap.xml
(CVSROOT: :pserver:<your cvs user>@sunsw.us.oracle.com:/m/jws
cd appserver-sqe
ant -f bootstrap.xml co-bat
3.set following env. variables
S1AS_HOME <GF install dir>, for example: /export/test/v4/glassfish4/glassfish
SPS_HOME <appserver-sqe>, for example: /export/test/appserver-sqe
ANT_HOME <ant location>, for example: /export/test/ant-1.7.1
JAVA_HOME <java location>, for example: /export/test/jdk1.7.0_11
4. cd <workspace dir>/appserver-sqe/, run "ant startDerby" to start derby database
5. cd <workspace dir>/appserver-sqe/pe/integrated-apps/bank, run "ant all".

3 test cases failed and the following errors displayed in the client side:

[echo] JMS1.1:JMS-P2P,UnifiedAPI:StatefulSession-CMT,ReceiveMap,CallStatefulSession:#8 : FAIL
[echo] Error : RemoteException : java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
[echo] java.rmi.RemoteException: null; nested exception is:
[echo] javax.ejb.EJBException
[echo]
[echo]
[echo]
[echo] Wrong type of message received
[echo]
[echo] JMS1.1:JMS-PubSub,UnifiedAPI:AppClient-DurableSubscription,ReceiveText:StatefulSession-CMT,SendText:#9 : FAIL
[echo] Error : Did not receive expected message
[...]
[echo] - SyncControllerJNDI:Lookup:JMS_Destination:Queue:CreatedWith-j2eeadmin:#6: PASS -
[echo] - SyncControllerJMS1.1:JMS-P2P,UnifiedAPI:StatefulSession-CMT,ReceiveMap,CallStatefulSession:#8: FAIL -
[echo] - SyncControllerJNDI:Lookup:JMS_Destination:Topic:CreatedWith-j2eeadmin:#5: PASS -
[echo] - SyncControllerJNDI:Lookup:SessionBean:Stateful:#2: PASS -
[echo] - SyncControllerJMS1.1:JMS-PubSub,UnifiedAPI:AppClient-DurableSubscription,ReceiveText:StatefulSession-CMT,SendText:#9: FAIL -
[echo] - SyncControllerJMS1.1:JMS-P2P,UnifiedAPI:AppClient-SendMap:StatefulSession-CMT,ReceiveMap:#7: PASS -
[echo] - SyncControllerJNDI:Lookup:SessionBean:Stateful:#1: PASS -
[echo] - SyncControllerCMP2.0:UnpopulateDatabase:#11: PASS -
[echo] - SyncControllerJNDI:Lookup:JMS_ConnectionFactory:Topic:CreatedWith-j2eeadmin:#4: PASS -
[echo] - SyncControllerJMS1.1:JMS-UnifiedAPI:AppClient-CloseJMSConnection:#10: PASS -
[echo] - SyncControllerCMP2.0:PopulateDatabase:#3: PASS -
[echo] -----------------------------------------
[echo] Total PASS: 9
[echo] Total FAIL: 2

----------- ------------------------
6. There are some exceptions in server.log
------------------------------------

EJB5184:A system exception occurred during an invocation on EJB ContentControllerEjb, method: null]]

[2013-04-17T14:09:51.546-0700] [glassfish 4.0] [WARNING] [] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=117 _ThreadName=p: thread-pool-1; w: 4] [timeMillis: 1366232991546] [levelValue: 900] [[

javax.ejb.EJBException: java.lang.IllegalStateException: Transaction exists on current thread.
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2016)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1979)
at com.sun.ejb.containers.StatefulSessionContainer.removeBean(StatefulSessionContainer.java:1185)
at com.sun.ejb.containers.EJBObjectImpl.remove(EJBObjectImpl.java:198)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invokeEJBObjectMethod(EJBObjectInvocationHandler.java:283)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:170)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:123)
at $Proxy245.remove(Unknown Source)
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.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:239)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:150)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:226)
at com.sun.ejte.j2ee.bank.contentcontroller.ejb._ContentController_DynamicStub.remove(com/sun/ejte/j2ee/bank/contentcontroller/ejb/_ContentController_DynamicStub.java)
at com.sun.ejte.j2ee.bank.jmsasynccontroller.ejb.DepositMdb.onMessage(DepositMdb.java:91)
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:1057)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1129)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:4118)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4675)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4655)
at org.glassfish.ejb.mdb.MessageBeanContainer.deliverMessage(MessageBeanContainer.java:1197)
at org.glassfish.ejb.mdb.MessageBeanListenerImpl.deliverMessage(MessageBeanListenerImpl.java:81)
at com.sun.enterprise.connectors.inbound.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:171)
at $Proxy278.onMessage(Unknown Source)
at com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:283)
at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:107)
at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Caused by: java.lang.IllegalStateException: Transaction exists on current thread.
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.resume(JavaEETransactionManagerSimplified.java:990)
at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:441)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4475)

at com.sun.ejb.containers.StatefulSessionContainer.postInvokeTx(StatefulSessionContainer.java:1852)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2009)
... 33 more
]]



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

What is the date of build 84? Does this test fail on the latest nightly? A fix for a similar issue was committed on Apr 9th.

Comment by sonialiu [ 17/Apr/13 ]

Promoted build84-RC1 was promoted on 04/10
Apr 10 10:18 glassfish-4.0-b84.zip

Comment by sonialiu [ 17/Apr/13 ]

I just ran the tests against latest nightly build (04/17 nightly) and it also failed.

Comment by ethan.wang [ 18/Apr/13 ]

Already reproduced the exception with latest GF build, will look further into it for the cause.

Comment by shreedhar_ganapathy [ 19/Apr/13 ]

Any further update on this bug? Is this to be fixed for 4.0 release?
We need to ensure we have the fixes for 4.0 wrapped up ASAP.

Comment by ethan.wang [ 24/Apr/13 ]

By far this looks like a concurrent issue to me. In preInvokeTx() we suspend the tx before invoking removeBean() against a SFSB, I checked and the current tx was set to null as expected. Then in postInvokeTx () we try to resume the tx but we find the current tx is not null anymore, so an IllegalStateException is raised saying "Transaction exists on current thread".

Current tx is saved in a TreadLocal object by TransactionManager and the failed cases are in relevant with JMS asynchronous messaging,so it seems like a concurrent issue. I'm looking further into it for the root cause.

Comment by ethan.wang [ 26/Apr/13 ]

The root cause is clear now. For SFSB using BMT, when remove() is being called upon it, postInvokeTx() would be invoked twice, the 1st one is for the PreDestroy callback and another is for remove() method itself, so when tx is suspended for remove(), the second attempt of resuming the tx would fail because it's already resumed. I discussed with Marina about this and I'm working on a fix now.

Comment by marina vatkina [ 30/Apr/13 ]
  • What is the impact on the customer of the bug?
    BMT bean remove fails when called in a transaction
  • How likely is it that a customer will see the bug and how serious is the bug?
    BMT bean remove fails when called in a transaction
  • Is it a regression?
    Yes.
  • Does it meet other bug fix criteria (security, performance, etc.)?
    no.
  • What CTS failures are caused by this bug?
    None.
  • What is the cost/risk of fixing the bug?
    Low so far - testing
  • How risky is the fix? How much work is the fix? Is the fix complicated?
    Minimal so far - testing
  • Is there an impact on documentation or message strings?
    no.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    EJB
  • Which is the targeted build of 4.0 for this fix?
    rc3.
  • 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.
    No.
Comment by marina vatkina [ 30/Apr/13 ]

Fixed by bypassing tx if it's a BMT SFSB.
Sending ejb-container/src/main/java/com/sun/ejb/containers/StatefulSessionContainer.java
Transmitting file data .
Committed revision 61741.





[GLASSFISH-20340] [regression] Make HK2 cache io buffer size is not configurable Created: 17/Apr/13  Updated: 18/Apr/13  Resolved: 18/Apr/13

Status: Closed
Project: glassfish
Component/s: hk2
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0_b87_RC3

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

Tags: 4_0-approved, performance

 Description   

It used to be configurable earlier, but during hk2 2.x, it has been changed to become a fixed value. Fix it so that perf team can use it to tune the system.



 Comments   
Comment by mtaube [ 18/Apr/13 ]

What is the impact on the customer of the bug?

They will see a performance improvement during startup when io buffer size is optimized for the machine running glassfish

What is the cost/risk of fixing the bug?

This particular change is not risky, will only take effect if a property is specified in osgi.properties

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

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.

n/a

Comment by Tom Mueller [ 18/Apr/13 ]

I hesitate in approving this in that I don't completely agree that this should even be tunable (or should have ever been tunable). More knobs are not necessarily better, and there isn't any proof that different values are needed for different systems. And even if different values were beneficial, is there actually going to be documentation on how users could actually tune this value or is there a performance tuner that sets the value. IMHO, it would be better to just determine a single value that is reasonable for the systems that we target and put that value in the code.

Approved for 4.0.





[GLASSFISH-20335] [BATCH RI] PartitionedStepControllerImpl is one-off when retrieving work from parallelBatchWorkUnits Created: 17/Apr/13  Updated: 19/Apr/13  Resolved: 19/Apr/13

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

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

3.5.0-24-generic #37-Ubuntu SMP Thu Feb 7 01:50:30 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux


Tags: 4_0-approved

 Description   

Disclaimer: The bug was found on b25 of the BATCH-RI

Example: Partition plan with 4 partitions and 2 threads
On line 334
// Start up to to the max num we are allowed from the num threads attribute
The variable numCurrentSubmitted has value 2 after completing this

Starting from line 375
if (readyToSubmitAnother) {
numCurrentCompleted++;
logger.fine("Ready to submit another (if there is another left to submit); numCurrentCompleted = " + numCurrentCompleted);
if (numCurrentCompleted < numTotalForThisExcecution) {
if (numCurrentSubmitted < numTotalForThisExcecution) {
numCurrentSubmitted++;
logger.fine("Submitting # " + numCurrentSubmitted + " out of " + numTotalForThisExcecution + " total for this execution");
if (stepStatus.getStartCount() > 1)

{ batchKernel.startGeneratedJob(parallelBatchWorkUnits.get(numCurrentSubmitted)); }

else

{ batchKernel.restartGeneratedJob(parallelBatchWorkUnits.get(numCurrentSubmitted)); }

readyToSubmitAnother = false;

The numCurrentSubmitted is increased to 3 and the next workUnit is retrieved is 3, thereby skipping entry 2 of the arry.
This means that while retrieving the last workUnit an exception is thrown and the third workUnit is never executed.

The exception was:
Wed Apr 17 19:37:41 CEST 2013 [com.ibm.jbatch.container.impl.BaseStepControllerImpl execute] WARNING: Caught exception executing step: java.lang.IndexOutOfBoundsException: Index: 4, Size: 4
at java.util.ArrayList.rangeCheck(ArrayList.java:604)
at java.util.ArrayList.get(ArrayList.java:382)
at com.ibm.jbatch.container.impl.PartitionedStepControllerImpl.executeAndWaitForCompletion(PartitionedStepControllerImpl.java:385)



 Comments   
Comment by blankema [ 17/Apr/13 ]

I have a test project (maven based) and a patch file but could not find where to upload it.

If needed, just contact me.

Comment by shreedhar_ganapathy [ 17/Apr/13 ]

-> Mahesh for eval on Batch RI.

Comment by Mahesh Kannan [ 18/Apr/13 ]

Just wanted to add that currently (RC1) GlassFish is using only b23 batch jars.
Anyways, Scott can comment on this more

Comment by ScottKurz [ 18/Apr/13 ]

This is a bug. As we didn't test @threads in the TCK we ended up not testing it at all. I will fix in the next drop.

Comment by ScottKurz [ 18/Apr/13 ]

Actually there's another bug here where we're neglecting to even honor the @threads attribute. I'm guessing this is the patch file mentioned since without this fixed I can't see how you could have created this in the first place. If you want to send it in case there's something else I missed.. you can send to ScottKurz@java.net, but I think I have this fixed now. Thanks for identifying this...

BTW, Mahesh... I think this is b25. The 84 driver was supposed to have been built on 10 Apr 2013 ... and we delivered b25 on 4/9.

Comment by Mahesh Kannan [ 19/Apr/13 ]
  • What is the impact on the customer of the bug?
    Without this fix some workUnit is never executed
  • What is the cost/risk of fixing the bug?
    Medium. Just a few lines. But Scott has already fixed this.
  • Is there an impact on documentation or message strings?
    No
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    All batch tests. Although I have run batch devtests and QL.
  • Which is the targeted build of 4.0 for this fix?
    The fix is ready, Most likely in RC2.
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
    This requires integration of b26 jars from IBM
Comment by Tom Mueller [ 19/Apr/13 ]

Approved for 4.0, but in the future please fill out the change control template.

Comment by ScottKurz [ 19/Apr/13 ]

Just confirming that this is indeed fixed in 1.0-b26.

Comment by Mahesh Kannan [ 19/Apr/13 ]

Resolved in b26 jars.

Svn commit info

svn commit -m "Integrate b26 jars. Fix for 20335, 20264. QL and batch devtests passed. Approved by Tom"
Sending appserver/pom.xml
Transmitting file data ....
Committed revision 61563.





[GLASSFISH-20333] Stray package prototype file included in GlassFish distribution Created: 17/Apr/13  Updated: 23/Apr/13  Resolved: 23/Apr/13

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

Type: Bug Priority: Major
Reporter: Snjezana Sevo-Zenzerovic 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   

IPS based GlassFish distributions contain stray glassfish/pkg_proto.py file. pkg_proto.py file belongs to glassfish-common-web package. It looks like something may be off with assembly descriptor and file does not get filtered out.



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

It is a regression compared to previous releases. While it is not directly affecting functionality, it is quite visible and may introduce some confusion for the end user.

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

Low risk. File is not getting filtered out during package content staging so assembly descriptor file needs to be updated.

  • Is there an impact on documentation or message strings?

No.

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

Regular GF testing is sufficient.

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

b86

  • 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





[GLASSFISH-20331] [Batch CLI] NPE thrown out when start the domain Created: 17/Apr/13  Updated: 19/Apr/13  Resolved: 19/Apr/13

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

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

Win7


Tags: 4_0-approved

 Description   

The NPE were thrown out on the version of glassfish which I have built at 12/4/2013 in my local platform. Here's my reproduced steps:
1). asadmin start-domain
2). asadmin create-instance ins1
3). asadmin deploy test_sample1.war
4). asadmin deploy test_sample2.war
5). asadmin stop-domain
6). asadmin start-domain

After step6, the NPE were thrown out as follows:

[2013-04-17T19:51:55.327+0900] [glassfish 4.0] [WARNING] [NCLS-CORE-00069] [javax.enterprise.system.core] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1366195915327] [levelValue: 900] [[
  Exception while dispatching an event
java.lang.NullPointerException
	at org.glassfish.batch.spi.impl.BatchRuntimeHelper.registerIfBatchJobsDirExists(BatchRuntimeHelper.java:178)
	at org.glassfish.batch.spi.impl.BatchRuntimeHelper.event(BatchRuntimeHelper.java:191)
	at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
	at com.sun.enterprise.v3.server.AppServerStartup.postStartupJob(AppServerStartup.java:358)
	at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:285)
	at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:179)
	at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:170)
	at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
	at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
	at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl.start(EmbeddedOSGiGlassFishImpl.java:75)
	at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
	at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishImpl.start(OSGiGlassFishImpl.java:71)
	at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
	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.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
	at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:54)
]]


 Comments   
Comment by Jeremy_Lv [ 17/Apr/13 ]

Here's attached the code of the reproduced web application:
test_sample1.war

package com.fujitsu.test.hello;


import java.io.IOException;
import java.io.PrintWriter;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;


/**
*
* @author Jeremy
*/
@WebServlet(name="MyServlet", urlPatterns={""})
public class UserServlet extends HttpServlet {

   protected void processRequest(HttpServletRequest request, HttpServletResponse response)
   throws ServletException, IOException {
       response.setContentType("text/html;charset=UTF-8");
       PrintWriter out = response.getWriter();
       try {
           out.println("<html>");
           out.println("<head>");
           out.println("<title>Servlet3.0 HelloWorld</title>");
           out.println("</head>");
           out.println("<body>");
           out.println("<h1>Hello! Servlet3.0 Sample1111111111</h1>");
           System.out.println("start to execute System.exit()");
           System.exit(1);
           System.out.println("System.exit() has been executed");
           out.println("</body>");
           out.println("</html>");
         
       } finally { 
           out.close();
       }
   } 

   @Override
   protected void doGet(HttpServletRequest request, HttpServletResponse response)
   throws ServletException, IOException {
       processRequest(request, response);
   } 

   @Override
   protected void doPost(HttpServletRequest request, HttpServletResponse response)
   throws ServletException, IOException {
       processRequest(request, response);
   }


   @Override
   public String getServletInfo() {
       return "Short description";
   }
}

test_sample2.war

package com.fujitsu.test.hello;


import java.io.IOException;
import java.io.PrintWriter;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;


/**
*
* @author Jeremy
*/
@WebServlet(name="MyServlet", urlPatterns={""})
public class UserServlet extends HttpServlet {

   protected void processRequest(HttpServletRequest request, HttpServletResponse response)
   throws ServletException, IOException {
       response.setContentType("text/html;charset=UTF-8");
       PrintWriter out = response.getWriter();
       try {
           out.println("<html>");
           out.println("<head>");
           out.println("<title>Servlet3.0 HelloWorld</title>");
           out.println("</head>");
           out.println("<body>");
           out.println("<h1>Hello! Servlet3.0 Sample22222222222</h1>");
           System.out.println("start to execute System.exit()");
           System.out.println("System.exit() has been executed");
           out.println("</body>");
           out.println("</html>");
         
       } finally { 
           out.close();
       }
   } 

   @Override
   protected void doGet(HttpServletRequest request, HttpServletResponse response)
   throws ServletException, IOException {
       processRequest(request, response);
   } 

   @Override
   protected void doPost(HttpServletRequest request, HttpServletResponse response)
   throws ServletException, IOException {
       processRequest(request, response);
   }


   @Override
   public String getServletInfo() {
       return "Short description";
   }
}

The only difference between the test_sample1 and test_sample2 is that I add the code of "System.exit(1);" in the test_sample1.

Comment by Jeremy_Lv [ 17/Apr/13 ]

If anyone need these two applications, pl. send the mail to me(lvsongping@cn.fujitsu.com).

Comment by TangYong [ 17/Apr/13 ]

This seemed to be batch module's issue.

Comment by TangYong [ 17/Apr/13 ]

Also noting the issue happened on cluster scene.

Comment by Mahesh Kannan [ 17/Apr/13 ]

Marking as Batch CLI issue

Comment by Mahesh Kannan [ 18/Apr/13 ]

First of all couldn't reproduce this issue.

The offending line (@ 178) is as follows:

ClassLoader cl = moduleInfo.getModuleClassLoader();
@178 ==> if (cl.getResource("META-INF/batch-jobs") != null)

{ tagNamesRequiringCleanup.add(config.getName() + ":" + applicationInfo.getName()); }

The only way this could happen is if moduleInfo.getModuleClassLoader(); is null (System class loader). Not sure if apps can be
deployed using system CL.

Anyways, I have added a null check to this line as follows:
ClassLoader cl = moduleInfo.getModuleClassLoader();
@178 ==> if (cl != null && cl.getResource("META-INF/batch-jobs") != null)

{ tagNamesRequiringCleanup.add(config.getName() + ":" + applicationInfo.getName()); }
Comment by Jeremy_Lv [ 18/Apr/13 ]

Mashech:
Here's some comments in line:
1). I will update the source to the latest one and check whether the NPE is still exist.
2). pl. tell me your mail address so that I can send you these two application and you can reproduce in your platform.
3). I will also try to add the null check you have pointed out to check whether the issue is still exist.

Thanks

-jeremy

Comment by Jeremy_Lv [ 18/Apr/13 ]

Sorry about the wrong steps, Here's the exactly steps:
1. asadmin start-domain
2. asadmin create-cluster clu1
3. asadmin create-instance --node localhost-domain1 --cluster clu1 instance1
4. asadmin deploy --target clu1 test_sample1.war
5. asadmin deploy --target clu1 test_sample2.war
6. asadmin stop-domain
7. asadmin start-domain

Comment by Mahesh Kannan [ 18/Apr/13 ]

Thanks for listing the exact steps. Yes, now I can reproduce. Fix will be available in the next build

Comment by Mahesh Kannan [ 18/Apr/13 ]

What is the impact on the customer of the bug?
If any application has been deployed to a cluster / standalone instance, User will see an NPE when the domain is re-started.

What is the cost/risk of fixing the bug?
Very low. A few lines.

Is there an impact on documentation or message strings?
Yes. Logging a message at Warning Level should any other exception occur.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
I have run the devtests successfully. The bug submitter was kind enough to do a bunch of tests.
<from-submitter>
Here's my steps to tests:
1). asadmin start-domain
2). asadmin create-cluster clu1
3). asadmin create-instance --cluster clu1 --node localhost-domain1 instance1
4). asadmin deploy test_sample1.war
5). asadmin deploy --target clu1 test_sample2.war
6). asadmin stop-domain
7). asadmin start-domain
8). asadmin stop-cluster clu1
9). asadmin start-cluster clu1
10). asadmin undeploy test_sample1
11). asadmin undeploy --target clu1 test_sample2

After all, there's no NPE were thrown out after applied your changes into the latest building source.

BTW: I have also run the QL tests and all of the tests passed

QL tests results:

testng-summary:
[echo] [testng]
[echo] [testng] ===============================================
[echo] [testng] QuickLookTests
[echo] [testng] Total tests run: 117, Failures: 0, Skips: 0
[echo] [testng] ===============================================
[echo] [testng]
[INFO] Executed tasks
[INFO] ------------------------------------------------------------------------
</from-submitter>

Which is the targeted build of 4.0 for this fix?
The fix is ready, not sure if it will make it into RC2.

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

n/a

Comment by Mahesh Kannan [ 18/Apr/13 ]
  • What is the impact on the customer of the bug?
    Without this fix the user will see an NPE during restart if any apps have been deployed to a cluster)
  • What is the cost/risk of fixing the bug?
    Very low. Just a few lines.
  • Is there an impact on documentation or message strings?
    Yes. A Few message Strings
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    All batch tests. Although I have run batch devtests and the bug submitter has extensively tested the patch.

Which is the targeted build of 4.0 for this fix?
The fix is ready, Most likely in RC2.

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

Comment by Tom Mueller [ 18/Apr/13 ]

Approved for 4.0.

Comment by Mahesh Kannan [ 19/Apr/13 ]

svn commit -m "Fix for 20331. QL and Batch devtests passed. Approved by Tom" glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeHelper.java

Sending glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeHelper.java
Transmitting file data .
Committed revision 61549.





[GLASSFISH-20324] EJB devtest ejb30/clientview/core failing with Weld 2.0.0.CR2 Created: 16/Apr/13  Updated: 17/Apr/13  Resolved: 17/Apr/13

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

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

Tags: 4_0-approved

 Comments   
Comment by jjsnyder83 [ 16/Apr/13 ]

Dev test failure

Comment by jjsnyder83 [ 16/Apr/13 ]

What is the impact on the customer of the bug?

  • It's not released to the customer yet.

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?
It is a regression in the ejb dev tests

  • 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
  • Is there an impact on documentation or message strings?
    No
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    EJB Dev tests
  • Which is the targeted build of 4.0 for this fix?
  • The next 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.
Comment by Tom Mueller [ 16/Apr/13 ]

Approved for 4.0





[GLASSFISH-20318] SFSB passivation fails with CDI enabled Created: 16/Apr/13  Updated: 24/Aug/14  Resolved: 23/Apr/13

Status: Resolved
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0_b85

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

Issue Links:
Dependency
depends on GLASSFISH-20325 SFSB passivation fails with NotSerial... Resolved
Tags: 4_0-approved

 Description   

with CDI enabled, SFSB passivation fails for beans that do not implement Serializable interface because our generated subclass is not being used when instance is created.



 Comments   
Comment by marina vatkina [ 16/Apr/13 ]
  • What is the impact on the customer of the bug?
    Regression: SFSB instance will be destroyed at passivation for beans that are not explicitly serializable
  • How likely is it that a customer will see the bug and how serious is the bug?
    It will break existing applications with SFSBs that are not explicitly serializable
  • What CTS failures are caused by this bug?
    CTS doesn't test passivation because its setup is appserver specific
  • What is the cost/risk of fixing the bug?
    Either class modification or implementing delegates in the ejb-container code.
  • Is there an impact on documentation or message strings?
    no
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    QA regression tests
  • Which is the targeted build of 4.0 for this fix?
    the next
  • Is this an integration of a new version of a component from another project?
    no
Comment by Tom Mueller [ 16/Apr/13 ]

Approved for 4.0

Comment by marina vatkina [ 23/Apr/13 ]

Do manual field serialization/deserialization when an EJB instance is created by CDI, and is not subclassed by our _Serializable code-gen.
Note that EJB devtets that fail because of the Weld bug need CR3 build of Weld or later to be restored.

Sending ejb-container/src/main/java/com/sun/ejb/EJBUtils.java
Sending ejb-container/src/main/java/com/sun/ejb/containers/StatefulSessionContainer.java
Sending ejb-container/src/main/java/com/sun/ejb/containers/util/cache/LruSessionCache.java
Sending ejb-container/src/main/java/com/sun/ejb/spi/container/SFSBContainerCallback.java
Transmitting file data ....
Committed revision 61586.

Comment by lprimak [ 24/Aug/14 ]

This is not completely fixed. As of GF 4.1 August 21, 2014,
when trying to access not-serializable SFSBs in Availability HA cluster configuration,
I get the exceptions below:
Related issues:
https://java.net/jira/browse/GLASSFISH-20892
https://java.net/jira/browse/GLASSFISH-20899

---------------------------
[2014-08-24T15:36:28.304-0400] [glassfish 4.1] [WARNING] [] [javax.enterprise.ejb.container] [tid: _ThreadID=99 _ThreadName=ajp-listener-1(5)] [timeMillis: 1408908988304] [levelValue: 900] [[

javax.ejb.EJBException
at com.sun.ejb.containers.EJBContainerTransactionManager.processSystemException(EJBContainerTransactionManager.java:748)
at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:698)
at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:515)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4566)
at com.sun.ejb.containers.StatefulSessionContainer.postInvokeTx(StatefulSessionContainer.java:1853)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2074)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2044)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy798.isDisableStats(Unknown Source)
at com.baw.website.beans.ui.layout.Layout.isStatsEnabled(Layout.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:363)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at com.sun.el.parser.AstValue.getValue(AstValue.java:140)
at com.sun.el.parser.AstValue.getValue(AstValue.java:204)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194)
at javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:457)
at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:852)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1854)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:456)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.CmsFilter.doFilter(CmsFilter.java:32)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.filters.EjbPingFilter.doFilter(EjbPingFilter.java:44)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.GzipResponseFilter.doFilter(GzipResponseFilter.java:149)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.FacesExceptionFilter.doFilter(FacesExceptionFilter.java:56)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.facesviews.FacesViewsForwardingFilter.doFilter(FacesViewsForwardingFilter.java:130)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.CmsFilter.doFilter(CmsFilter.java:32)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.filters.EjbPingFilter.doFilter(EjbPingFilter.java:44)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:115)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.security.WebSecurityFilter$1.call(WebSecurityFilter.java:90)
at com.flowlogix.security.WebSecurityFilter$1.call(WebSecurityFilter.java:84)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
at com.flowlogix.security.WebSecurityFilter.doFilter(WebSecurityFilter.java:83)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.ShiroInitFilter.doFilter(ShiroInitFilter.java:41)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:175)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:415)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalArgumentException: object is not an instance of declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1081)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1153)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4786)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:656)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at com.flowlogix.security.ShiroSecurityInterceptor.propagateShiroSecurity(ShiroSecurityInterceptor.java:64)
at sun.reflect.GeneratedMethodAccessor376.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)
at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:52)
at sun.reflect.GeneratedMethodAccessor123.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:369)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4758)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4746)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
... 107 more
]]

[2014-08-24T15:36:28.307-0400] [glassfish 4.1] [SEVERE] [] [javax.enterprise.resource.webcontainer.jsf.application] [tid: _ThreadID=99 _ThreadName=ajp-listener-1(5)] [timeMillis: 1408908988307] [levelValue: 1000] [[
Error Rendering View[/index.xhtml]
javax.el.ELException: /resources/templates/layout.xhtml @194,60 rendered="#

{layout.statsEnabled}

": javax.ejb.EJBException
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:114)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194)
at javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:457)
at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:852)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1854)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:456)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.CmsFilter.doFilter(CmsFilter.java:32)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.filters.EjbPingFilter.doFilter(EjbPingFilter.java:44)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.GzipResponseFilter.doFilter(GzipResponseFilter.java:149)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.FacesExceptionFilter.doFilter(FacesExceptionFilter.java:56)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.facesviews.FacesViewsForwardingFilter.doFilter(FacesViewsForwardingFilter.java:130)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.CmsFilter.doFilter(CmsFilter.java:32)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.filters.EjbPingFilter.doFilter(EjbPingFilter.java:44)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:115)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.security.WebSecurityFilter$1.call(WebSecurityFilter.java:90)
at com.flowlogix.security.WebSecurityFilter$1.call(WebSecurityFilter.java:84)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
at com.flowlogix.security.WebSecurityFilter.doFilter(WebSecurityFilter.java:83)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.ShiroInitFilter.doFilter(ShiroInitFilter.java:41)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:175)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:415)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)
Caused by: javax.el.ELException: javax.ejb.EJBException
at javax.el.BeanELResolver.getValue(BeanELResolver.java:368)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at com.sun.el.parser.AstValue.getValue(AstValue.java:140)
at com.sun.el.parser.AstValue.getValue(AstValue.java:204)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109)
... 92 more
Caused by: javax.ejb.EJBException
at com.sun.ejb.containers.EJBContainerTransactionManager.processSystemException(EJBContainerTransactionManager.java:748)
at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:698)
at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:515)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4566)
at com.sun.ejb.containers.StatefulSessionContainer.postInvokeTx(StatefulSessionContainer.java:1853)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2074)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2044)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy798.isDisableStats(Unknown Source)
at com.baw.website.beans.ui.layout.Layout.isStatsEnabled(Layout.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:363)
... 99 more
Caused by: java.lang.IllegalArgumentException: object is not an instance of declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1081)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1153)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4786)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:656)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at com.flowlogix.security.ShiroSecurityInterceptor.propagateShiroSecurity(ShiroSecurityInterceptor.java:64)
at sun.reflect.GeneratedMethodAccessor376.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)
at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:52)
at sun.reflect.GeneratedMethodAccessor123.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:369)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4758)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4746)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
... 107 more
]]

[2014-08-24T15:36:28.338-0400] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=99 _ThreadName=ajp-listener-1(5)] [timeMillis: 1408908988338] [levelValue: 900] [[
StandardWrapperValve[Faces Servlet]: Servlet.service() for servlet Faces Servlet threw exception
java.lang.IllegalArgumentException: object is not an instance of declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1081)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1153)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4786)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:656)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at com.flowlogix.security.ShiroSecurityInterceptor.propagateShiroSecurity(ShiroSecurityInterceptor.java:64)
at sun.reflect.GeneratedMethodAccessor376.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)
at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:52)
at sun.reflect.GeneratedMethodAccessor123.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:369)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4758)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4746)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy798.isDisableStats(Unknown Source)
at com.baw.website.beans.ui.layout.Layout.isStatsEnabled(Layout.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:363)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at com.sun.el.parser.AstValue.getValue(AstValue.java:140)
at com.sun.el.parser.AstValue.getValue(AstValue.java:204)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194)
at javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:457)
at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:852)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1854)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:456)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.CmsFilter.doFilter(CmsFilter.java:32)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.filters.EjbPingFilter.doFilter(EjbPingFilter.java:44)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.GzipResponseFilter.doFilter(GzipResponseFilter.java:149)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.FacesExceptionFilter.doFilter(FacesExceptionFilter.java:56)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.facesviews.FacesViewsForwardingFilter.doFilter(FacesViewsForwardingFilter.java:130)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.CmsFilter.doFilter(CmsFilter.java:32)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.filters.EjbPingFilter.doFilter(EjbPingFilter.java:44)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:115)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.security.WebSecurityFilter$1.call(WebSecurityFilter.java:90)
at com.flowlogix.security.WebSecurityFilter$1.call(WebSecurityFilter.java:84)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
at com.flowlogix.security.WebSecurityFilter.doFilter(WebSecurityFilter.java:83)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.ShiroInitFilter.doFilter(ShiroInitFilter.java:41)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:175)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:415)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)
]]

[2014-08-24T15:36:39.431-0400] [glassfish 4.1] [SEVERE] [AS-EJB-00004] [javax.enterprise.ejb.container] [tid: _ThreadID=97 _ThreadName=ajp-listener-1(3)] [timeMillis: 1408908999431] [levelValue: 1000] [[
[NRU-com.baw.website.beans.sfsb.impl.SharedWebstats]: Cannot load from BACKUPSTORE FOR Key: <[1f00900a0983b5c6-ee0001103a22bcb3-1]>]]

[2014-08-24T15:36:39.432-0400] [glassfish 4.1] [WARNING] [AS-EJB-00056] [javax.enterprise.ejb.container] [tid: _ThreadID=97 _ThreadName=ajp-listener-1(3)] [timeMillis: 1408908999432] [levelValue: 900] [[
A system exception occurred during an invocation on EJB SharedWebstats, method: public void com.baw.website.beans.sfsb.impl.SharedWebstats.ping()]]

[2014-08-24T15:36:39.432-0400] [glassfish 4.1] [WARNING] [] [javax.enterprise.ejb.container] [tid: _ThreadID=97 _ThreadName=ajp-listener-1(3)] [timeMillis: 1408908999432] [levelValue: 900] [[

javax.ejb.NoSuchObjectLocalException: The EJB does not exist. session-key: 1f00900a0983b5c6-ee0001103a22bcb3-1
at com.sun.ejb.containers.StatefulSessionContainer._getContext(StatefulSessionContainer.java:1626)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2579)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1971)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:210)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy798.ping(Unknown Source)
at com.flowlogix.ejb.StatefulUtil.pingStateful(StatefulUtil.java:68)
at com.flowlogix.web.services.EjbModule$1.service(EjbModule.java:46)
at $HttpServletRequestHandler_584822218a2dad.service(Unknown Source)
at org.got5.tapestry5.jquery.services.AjaxUploadServletRequestFilter.service(AjaxUploadServletRequestFilter.java:27)
at $HttpServletRequestHandler_584822218a2dad.service(Unknown Source)
at org.tynamo.security.services.impl.SecurityConfiguration$1.call(SecurityConfiguration.java:56)
at org.tynamo.security.services.impl.SecurityConfiguration$1.call(SecurityConfiguration.java:54)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
at org.tynamo.security.services.impl.SecurityConfiguration.service(SecurityConfiguration.java:54)
at $HttpServletRequestFilter_584822218a2dab.service(Unknown Source)
at $HttpServletRequestHandler_584822218a2dad.service(Unknown Source)
at org.apache.tapestry5.upload.internal.services.MultipartServletRequestFilter.service(MultipartServletRequestFilter.java:44)
at $HttpServletRequestHandler_584822218a2dad.service(Unknown Source)
at org.apache.tapestry5.internal.gzip.GZipFilter.service(GZipFilter.java:53)
at $HttpServletRequestHandler_584822218a2dad.service(Unknown Source)
at org.apache.tapestry5.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62)
at $HttpServletRequestFilter_584822218a2d9e.service(Unknown Source)
at $HttpServletRequestHandler_584822218a2dad.service(Unknown Source)
at org.apache.tapestry5.services.TapestryModule$1.service(TapestryModule.java:852)
at $HttpServletRequestHandler_584822218a2dad.service(Unknown Source)
at $HttpServletRequestHandler_584822218a2d9d.service(Unknown Source)
at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:171)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:415)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)
]]





[GLASSFISH-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-20316] Findbugs: IS2_INCONSISTENT_SYNC: Inconsistent synchronization Created: 15/Apr/13  Updated: 15/Apr/13  Resolved: 15/Apr/13

Status: Closed
Project: glassfish
Component/s: bean-validator
Affects Version/s: None
Fix Version/s: 4.0_b85

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, findbugs

 Description   

This is a fix of a Low Priority findbugs issue:

Errors:
================================================================================
mtaube: appserver/web/weld-integration/src/main/java/org/glassfish/weld/ValidationNamingProxy.java:105: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.weld.ValidationNamingProxy.beanManagerNamingProxy; locked 66% of time
mtaube: appserver/web/weld-integration/src/main/java/org/glassfish/weld/ValidationNamingProxy.java:150: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.weld.ValidationNamingProxy.beanManagerNamingProxy; locked 66% of time
mtaube: appserver/web/weld-integration/src/main/java/org/glassfish/weld/ValidationNamingProxy.java:181: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.weld.ValidationNamingPro

  • What is the impact on the customer of the 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?

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

very low risk, adds synchronization to a critical section

  • Is there an impact on documentation or message strings?

no

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

jsr-349 cts

  • Which is the targeted build of 4.0 for this fix?
  • 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.


 Comments   
Comment by Tom Mueller [ 15/Apr/13 ]

Approved for 4.0.





[GLASSFISH-20313] NPE in buildLogFileIndex after rotated log file Created: 15/Apr/13  Updated: 18/Apr/13  Resolved: 18/Apr/13

Status: Resolved
Project: glassfish
Component/s: logging
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: Anissa Lam Assignee: sandeep.shrivastava
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved, console

 Description   

This can be reproduced consistently. Steps to reproduce:

1. go to Server (Admin Server) and click "Rotate Log File" button. Log file is rotated, works fine.
2. click the "View Log File" button, the logViewer will show up, but because of the NPE, there is the message "An error has occured", and there is no log shown.
3. click the search button again, and it now works fine.

Here is the stack trace;

[#|2013-04-15T11:51:17.577-0700|INFO|glassfish 4.0|javax.enterprise.admin.rest|_ThreadID=34;_ThreadName=admin-listener(2);_TimeMillis=1366051877577;_LevelValue=800;_MessageID=NCLS-REST-00003;|
An error occurred while processing the request. Please see the server logs for details.
java.lang.RuntimeException: java.lang.NullPointerException
at com.sun.enterprise.server.logging.logviewer.backend.LogFile.buildLogFileIndex(LogFile.java:209)
at com.sun.enterprise.server.logging.logviewer.backend.LogFile.getLastIndexNumber(LogFile.java:284)
at com.sun.enterprise.server.logging.logviewer.backend.LogFilter.getLogRecordsUsingQuery(LogFilter.java:202)
at com.sun.enterprise.server.logging.logviewer.backend.LogFilter.getLogRecordsUsingQuery(LogFilter.java:349)
at org.glassfish.admin.rest.resources.custom.StructuredLogViewerResource.getWithType(StructuredLogViewerResource.java:176)
at org.glassfish.admin.rest.resources.custom.StructuredLogViewerResource.getJson(StructuredLogViewerResource.java:100)
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$TypeOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:195)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:217)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:231)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:227)
at org.glassfish.jersey.internal.Errors.process(Errors.java:275)
at org.glassfish.jersey.internal.Errors.process(Errors.java:257)
at org.glassfish.jersey.internal.Errors.process(Errors.java:227)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:191)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:819)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
at org.glassfish.admin.rest.adapter.RestAdapter$2.service(RestAdapter.java:318)
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 java.util.regex.Matcher.getTextLength(Matcher.java:1234)
at java.util.regex.Matcher.reset(Matcher.java:308)
at java.util.regex.Matcher.<init>(Matcher.java:228)
at java.util.regex.Pattern.matcher(Pattern.java:1088)
at com.sun.enterprise.server.logging.parser.LogParserFactory.detectLogFormat(LogParserFactory.java:115)
at com.sun.enterprise.server.logging.parser.LogParserFactory.createLogParser(LogParserFactory.java:90)
at com.sun.enterprise.server.logging.logviewer.backend.LogFile.buildLogFileIndex(LogFile.java:185)
... 46 more

#]


 Comments   
Comment by rajendra_inamdar [ 15/Apr/13 ]

Looks like it is trying to index the empty file after it is rotated.

Comment by sandeep.shrivastava [ 17/Apr/13 ]
  • What is the impact on the customer of the bug?

Customer will run into this issue if he/she opens the log viewer for a log file immediately after it has been rotated and the current log file is still empty.

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

There is a medium probability that the customer will run into this issue, if they are actively viewing the log files and the rotation happens.

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

The exception did not happen in GF 3.1.2.2, it is happening in new code added to support both ODL and Uniform log format. There was no exception in the prior release, the log viewer did not show any records for the empty log file.

What CTS failures are caused by this bug?

There are no CTS failures due to this issue.

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

How risky is the fix? How much work is the fix? Is the fix complicated?

The fix is straight forward to handle the empty log file. 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?

This only affects the UI. Anissa has verified the fix offline.

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

4.0_b85

  • 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 [ 17/Apr/13 ]

Approved for 4.0.

Comment by sandeep.shrivastava [ 18/Apr/13 ]

This is fixed with revision 61489.





[GLASSFISH-20311] [SDK]Java EE 7 sample-The JobOperator API Batch Sample Application AND The Payroll Batch Sample Application Created: 15/Apr/13  Updated: 18/Apr/13  Resolved: 18/Apr/13

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

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

EE7 sdk build84


Tags: 4_0-approved

 Description   

In the doc, there is one build instruction 'mvn build'. I got no build phases exceptions from maven. Is it correct command line?
It works if I am going to use 'mvn install'

Attached original line below:

-Build the sample application by running the mvn build command from a command line terminal.



 Comments   
Comment by Daniel [ 15/Apr/13 ]

The exceptions are attached below:
[ERROR] Unknown lifecycle phase "build". You must specify a valid lifecycle phase or a goal in the format <plugin-prefix>:<goal> or <plugin-group-id>:<plugin-artifact-id>[:<plugin-version>]:<goal>. Available lifecycle phases are: validate, initialize, generate-sources, process-sources, generate-resources, process-resources, compile, process-classes, generate-test-sources, process-test-sources, generate-test-resources, process-test-resources, test-compile, process-test-classes, test, prepare-package, package, pre-integration-test, integration-test, post-integration-test, verify, install, deploy, pre-site, site, post-site, site-deploy, pre-clean, clean, post-clean. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/LifecyclePhaseNotFoundException

Comment by shreedhar_ganapathy [ 17/Apr/13 ]

Assigning to Mahesh for now

Comment by Mahesh Kannan [ 18/Apr/13 ]

Agreed. It should have been mvn package (instead of mvn build)

Comment by Mahesh Kannan [ 18/Apr/13 ]
  • What is the impact on the customer of the bug?
    The doc instructs the users to use 'mvn build' which is totally wrong. It should have been 'mvn package'
  • What is the cost/risk of fixing the bug?
    Very low. Just updating the index.html
  • Is there an impact on documentation or message strings?
    No

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
Actually, none. The fix is to just update index.html

Which is the targeted build of 4.0 for this fix?
The fix is ready, not sure if it will make it into RC2.

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

n/a

Comment by Tom Mueller [ 18/Apr/13 ]

Approved for 4.0

Comment by Mahesh Kannan [ 18/Apr/13 ]

Here are the diffs:

svn diff payroll/docs/index.html partition/docs/index.html joboperator-api/docs/index.html
Index: payroll/docs/index.html
===================================================================
— payroll/docs/index.html (revision 1127)
+++ payroll/docs/index.html (working copy)
@@ -191,7 +191,7 @@
the <a href="../../../docs/UserREADME.html">common build instructions.</a></li>
<li><code><i>samples_install_dir</i></code> is the sample application base directory. Go to: <code><i>samples_install_dir</i>/javaee7/batch/payroll</code>.
</li>

  • <li>Build the sample application by running the <code>mvn build</code> command from a command line terminal.</li>
    + <li>Build the sample application by running the <code>mvn package</code> command from a command line terminal.</li>
    <li>Deploy the sample application by running the <code>asadmin deploy --force target/payroll.war</code> command from a command line terminal.</li>
    <li>The front page of this sample is at <code>http://localhost:8080/payroll/JobSubmitterServlet</code>.<br>
    (The port number might vary.)</li>
    Index: partition/docs/index.html
    ===================================================================
      • partition/docs/index.html (revision 1127)
        +++ partition/docs/index.html (working copy)
        @@ -173,7 +173,7 @@
        the <a href="../../../docs/UserREADME.html">common build instructions.</a></li>
        <li><code><i>samples_install_dir</i></code> is the sample application base directory. Go to: <code><i>samples_install_dir</i>/javaee7/batch/joboperator-api</code>.
        </li>
  • <li>Build the sample application by running <code>mvn build</code> command from a command line terminal.</li>
    + <li>Build the sample application by running <code>mvn package</code> command from a command line terminal.</li>
    <li>Deploy the sample application by running <code>asadmin deploy --force target/joboperator-api.war</code> command from a command line terminal.</li>
    <li>The front page of this sample is at <a href="http://localhost:8080/joboperator-api/PayrollJobSubmitterServlet">http://localhost:8080/joboperator-api/PayrollJobSubmitterServlet</a>.
    (The port number might vary.)</li>
    Index: joboperator-api/docs/index.html
    ===================================================================
      • joboperator-api/docs/index.html (revision 1127)
        +++ joboperator-api/docs/index.html (working copy)
        @@ -174,7 +174,7 @@
        the <a href="../../../docs/UserREADME.html">common build instructions.</a></li>
        <li><code><i>samples_install_dir</i></code> is the sample application base directory. Go to: <code><i>samples_install_dir</i>/javaee7/batch/joboperator-api</code>.
        </li>
  • <li>Build the sample application by running the <code>mvn build</code> command from a command line terminal.</li>
    + <li>Build the sample application by running the <code>mvn package</code> command from a command line terminal.</li>
    <li>Deploy the sample application by running the <code>asadmin deploy --force target/joboperator-api.war</code> command from a command line terminal.</li>
    <li>The front page of this sample is at <code>http://localhost:8080/joboperator-api/PayrollJobSubmitterServlet</code><br>
    (The port number might vary.)</li>

Svn commit message:

svn commit -m "Fix for 20311. Approved by Tom." payroll/docs/index.html partition/docs/index.html joboperator-api/docs/index.html
Sending joboperator-api/docs/index.html
Sending partition/docs/index.html
Sending payroll/docs/index.html
Transmitting file data ...
Committed revision 1128.





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

&