[GLASSFISH-19982] [regression] GlassFish 4-b80-ml.zip generates bundle warnings flooding the server.log Created: 21/Mar/13  Updated: 21/Mar/13  Resolved: 21/Mar/13

Status: Resolved
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0_b80_EE7MS6
Fix Version/s: 4.0_b81

Type: Bug Priority: Blocker
Reporter: myfear Assignee: Joe Di Pol
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Welcome to GlassFish Server Open Source Edition 4.0 (build 80)
JDK 1.7_u15
Win 7-64bit


Tags: fishcat

 Description   

Starting GF I get a bunch of warnings for every module all following this example:

[2013-03-21T07:22:48.062+0100] [glassfish 4.0] [WARNING] [] [org.jvnet.hk2.osgiadapter] [tid: _ThreadID=119 _ThreadName=admin-listener(6)] [timeMillis: 1363846968062] [levelValue: 900] [[
Exception org.osgi.framework.BundleException: Could not create bundle object. while adding location = file:/D:/glassfish4-b80-ml/glassfish/modules/appclient-server-core-l10n.jar]]

This is flooding the logfile :<



 Comments   
Comment by TangYong [ 21/Mar/13 ]

In windows xp, the issue does not happen. as for win 7 64 bit, I will validate it from my home env.

Comment by myfear [ 21/Mar/13 ]

I could provide a complete logfile ... drop me a line myfear at web dot de

Comment by Sanjeeb Sahoo [ 21/Mar/13 ]

While using 4.0-b80-ml.zip on Linux, I do see exceptions like:

[#|2013-03-21T01:01:09.317-0700|WARNING|glassfish 4.0|org.jvnet.hk2.osgiadapter|_ThreadID=78;_ThreadName=Thread-12;_TimeMillis=1363852869317;_LevelValue=900;|
Exception org.osgi.framework.BundleException: Could not create bundle object. while adding location = file:/scratch/sanjsaho/software/gf-4.0-b80-ml/glassfish4/glassfish/modules/console-corba-plugin-l10n.jar|#]

But, I also notice exceptions at the start of the server like this:

Launching GlassFish on Felix platform
Mar 21, 2013 1:00:59 AM com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner createBundleProvisioner
INFO: Create bundle provisioner class = class com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner.
Mar 21, 2013 1:00:59 AM com.sun.enterprise.glassfish.bootstrap.LogFacade log
WARNING: Failed to install file:/scratch/sanjsaho/software/gf-4.0-b80-ml/glassfish4/glassfish/modules/console-jms-plugin-l10n.jar.
org.osgi.framework.BundleException: Could not create bundle object.
at org.apache.felix.framework.Felix.installBundle(Felix.java:2940)
at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:165)
at com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner.install(BundleProvisioner.java:445)
at com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner.installBundles(BundleProvisioner.java:205)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntimeBuilder.build(OSGiGlassFishRuntimeBuilder.java:142)
at org.glassfish.embeddable.GlassFishRuntime._bootstrap(GlassFishRuntime.java:157)
at org.glassfish.embeddable.GlassFishRuntime.bootstrap(GlassFishRuntime.java:110)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:112)
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)
Caused by: java.lang.IllegalArgumentException: invalid version "$

Unknown macro: {project.osgi.version}

": non-numeric "${project"
at org.osgi.framework.Version.parseInt(Version.java:170)
at org.osgi.framework.Version.<init>(Version.java:126)
at org.apache.felix.framework.util.VersionRange.parse(VersionRange.java:98)
at org.apache.felix.framework.util.manifestparser.ManifestParser.parseFragmentHost(ManifestParser.java:1335)
at org.apache.felix.framework.util.manifestparser.ManifestParser.<init>(ManifestParser.java:146)
at org.apache.felix.framework.BundleRevisionImpl.<init>(BundleRevisionImpl.java:118)
at org.apache.felix.framework.BundleImpl.createRevision(BundleImpl.java:1199)
at org.apache.felix.framework.BundleImpl.<init>(BundleImpl.java:96)
at org.apache.felix.framework.Felix.installBundle(Felix.java:2887)
... 13 more
Caused by: java.lang.NumberFormatException: For input string: "${project"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:481)
at java.lang.Integer.parseInt(Integer.java:527)
at org.osgi.framework.Version.parseInt(Version.java:168)
... 21 more

To see them, you need to start with -v option:

asadmin start-domain -v

This exception is happening because of bad manifest:

[MANIFEST console-jms-plugin-l10n.jar]
Archiver-Version Plexus Archiver
Bnd-LastModified 1363208767995
Build-Jdk 1.7.0_09
Built-By java_re
Bundle-Description Java.net - The Source for Java Technology Collaboration
Bundle-ManifestVersion 2
Bundle-Name Admin Console JMS Plugin l10n
Bundle-SymbolicName org.glassfish.main.admingui.console-jms-plugin-l10n
Bundle-Version 4.0.0.b80
Created-By Apache Maven Bundle Plugin
Fragment-Host org.glassfish.main.admingui.console-jms-plugin; bundle-version=${project.osgi.version}
Manifest-Version 1.0
Tool Bnd-1.15.0

The good thing is I don't see such exceptions in b81. In b81, the manifest has been fixed. I don't know how we ended up promoting b80 with such a blocking bug, but that's a question for our release engineering team. I am assigning it to them. They should close it as RESOLVED with an explanation for the svn revision that fixed the issue. They should also fix promotion process to avoid such issues in future.

Comment by Romain Grécourt [ 21/Mar/13 ]

You don't know ? The answer is easy though.

I fixed this last sunday, b81 includes the fix.

Comment by Sanjeeb Sahoo [ 21/Mar/13 ]

I don't deny the answer was perhaps easy to find by looking at all check in logs. I didn't put that effort. I am still looking for an answer as to how how we promoted this zip? Don't we run any tests again ml builds?

Comment by Romain Grécourt [ 21/Mar/13 ]

My comment was exactly about this question.
Note that those are warinings, even if we tested the ml bundles, the tests would have passed.

Comment by Romain Grécourt [ 21/Mar/13 ]

There is no test that uses l10n bundles AFAIK.

Comment by Sanjeeb Sahoo [ 21/Mar/13 ]

Thanks for clarifying, Romain. You are absolutely right, they are warnings. I missed that part. Server does come up fine. It's just that the l10n does not work. So, that does reduce the severity of the issue to major from blocking. I assume our l10n QA would have caught that issue in due course of time.





[GLASSFISH-19977] Stopping a GF instance leads to Exception during invocation of InjectionManager.destroyManagedObject Created: 21/Mar/13  Updated: 25/Mar/13  Resolved: 25/Mar/13

Status: Closed
Project: glassfish
Component/s: web_container
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b81

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

GlassFish Server Open Source Edition 4.0 (build 80)


Tags: fishcat

 Description   

Stopping a GF instance leads to

INFO: Closing down : org.glassfish.tyrus.server.TyrusEndpoint@499a6ca9
SEVERE: Exception during invocation of InjectionManager.destroyManagedObject on org.glassfish.tyrus.servlet.TyrusServletFilter@29a86daf of web module StandardEngine[glassfish-web].StandardHost[server].StandardContext[/MissionControl]
java.lang.IllegalStateException: Unknown JCDI-enabled managed bean org.glassfish.tyrus.servlet.TyrusServletFilter@29a86daf of class class org.glassfish.tyrus.servlet.TyrusServletFilter
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.destroyManagedBean(ManagedBeanManagerImpl.java:628)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.destroyManagedObject(InjectionManagerImpl.java:439)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.destroyManagedObject(InjectionManagerImpl.java:414)
at com.sun.web.server.WebContainerListener.preDestroy(WebContainerListener.java:186)
at com.sun.web.server.WebContainerListener.containerEvent(WebContainerListener.java:151)
at org.apache.catalina.core.ContainerBase.fireContainerEvent(ContainerBase.java:1579)
at org.apache.catalina.core.ApplicationFilterConfig.release(ApplicationFilterConfig.java:334)
at org.apache.catalina.core.StandardContext.filterStop(StandardContext.java:5329)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:6092)
at com.sun.enterprise.web.WebModule.stop(WebModule.java:720)
at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1172)
at com.sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java:2444)
at com.sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java:2399)
at com.sun.enterprise.web.WebApplication.stop(WebApplication.java:190)
at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:161)
at org.glassfish.internal.data.ModuleInfo.stop(ModuleInfo.java:324)
at org.glassfish.internal.data.ApplicationInfo.stop(ApplicationInfo.java:380)
at com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:1056)
at com.sun.enterprise.v3.server.ApplicationLifecycle.disable(ApplicationLifecycle.java:2121)
at com.sun.enterprise.v3.server.ApplicationLifecycle.disable(ApplicationLifecycle.java:113)
at org.glassfish.deployment.admin.DisableCommand.execute(DisableCommand.java:375)
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:1761)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.deployment.admin.UndeployCommand.execute(UndeployCommand.java:367)
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:1761)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:235)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:257)
at org.glassfish.admin.rest.resources.TemplateRestResource.runCommand(TemplateRestResource.java:560)
at org.glassfish.admin.rest.resources.TemplateRestResource.doDelete(TemplateRestResource.java:301)
at org.glassfish.admin.rest.resources.TemplateRestResource.delete(TemplateRestResource.java:186)
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:350)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:345)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:214)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:207)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:203)
at org.glassfish.jersey.internal.Errors.process(Errors.java:251)
at org.glassfish.jersey.internal.Errors.process(Errors.java:233)
at org.glassfish.jersey.internal.Errors.process(Errors.java:203)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:190)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:865)
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)



 Comments   
Comment by myfear [ 21/Mar/13 ]

It is not only during instance stop .. more likely it is the undeployment phase. ..

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

This is a duplicate of http://java.net/jira/browse/GLASSFISH-19961 and have been fixed.





[GLASSFISH-19961] ServletContext#addFilter(String, Filter) causes Exception to be logged when web app is undeployed Created: 20/Mar/13  Updated: 20/Mar/13  Resolved: 20/Mar/13

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

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

Issue Links:
Related
is related to TYRUS-107 IlegalStateException logged in server... Resolved

 Description   

[#|2013-02-27T17:48:48.620+0100|SEVERE|glassfish 4.0|javax.enterprise.web|_ThreadID=60;_ThreadName=admin-listener(1);_TimeMillis=1361983728620;_LevelValue=1000;|Exception during invocation of InjectionManager.destroyManagedObject on org.glassfish.tyrus.servlet.TyrusServletFilter@1fe7f184 of web module StandardEngine[glassfish-web].StandardHost[server].StandardContext[/sample-cdi]
java.lang.IllegalStateException: Unknown JCDI-enabled managed bean org.glassfish.tyrus.servlet.TyrusServletFilter@1fe7f184 of class class org.glassfish.tyrus.servlet.TyrusServletFilter
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.destroyManagedBean(ManagedBeanManagerImpl.java:628)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.destroyManagedObject(InjectionManagerImpl.java:439)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.destroyManagedObject(InjectionManagerImpl.java:414)
at com.sun.web.server.WebContainerListener.preDestroy(WebContainerListener.java:186)
at com.sun.web.server.WebContainerListener.containerEvent(WebContainerListener.java:151)
at org.apache.catalina.core.ContainerBase.fireContainerEvent(ContainerBase.java:1579)
at org.apache.catalina.core.ApplicationFilterConfig.release(ApplicationFilterConfig.java:334)
at org.apache.catalina.core.StandardContext.filterStop(StandardContext.java:5319)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:6082)
at com.sun.enterprise.web.WebModule.stop(WebModule.java:725)
at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1172)
at com.sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java:2438)
at com.sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java:2393)
at com.sun.enterprise.web.WebApplication.stop(WebApplication.java:191)
at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:161)
at org.glassfish.internal.data.ModuleInfo.stop(ModuleInfo.java:324)
at org.glassfish.internal.data.ApplicationInfo.stop(ApplicationInfo.java:380)
at com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:1056)
at com.sun.enterprise.v3.server.ApplicationLifecycle.disable(ApplicationLifecycle.java:2121)
at com.sun.enterprise.v3.server.ApplicationLifecycle.disable(ApplicationLifecycle.java:113)
at org.glassfish.deployment.admin.DisableCommand.execute(DisableCommand.java:375)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:538)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:547)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1424)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1759)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1675)
at org.glassfish.deployment.admin.UndeployCommand.execute(UndeployCommand.java:367)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:528)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:524)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:523)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:547)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1424)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1759)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1675)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:233)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:255)
at org.glassfish.admin.rest.resources.TemplateRestResource.runCommand(TemplateRestResource.java:560)
at org.glassfish.admin.rest.resources.TemplateRestResource.doDelete(TemplateRestResource.java:301)
at org.glassfish.admin.rest.resources.TemplateRestResource.delete(TemplateRestResource.java:186)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:93)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:350)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:345)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:207)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:183)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:852)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:321)
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.doHandle(HttpHandler.java:164)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:175)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:273)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:820)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)

#]


 Comments   
Comment by Shing Wai Chan [ 20/Mar/13 ]

Sending web-glue/src/main/java/com/sun/web/server/WebContainerListener.java
Transmitting file data .
Committed revision 60633.





[GLASSFISH-19955] Empty lines in javax.persistence.sql-load-script-source lead to exceptions Created: 20/Mar/13  Updated: 26/Mar/13  Resolved: 26/Mar/13

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

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

Environment: Name of the Operating System: Windows 7
Binary Architecture name of the Operating System: amd64, Version: 6.1
Number of processors available on the Operating System: 8

GlassFish Server Open Source Edition 4.0 (build 80)


Tags: fishcat

 Description   

Having configured a
<property name="javax.persistence.sql-load-script-source" value="META-INF/load.sql"/>
in persistence xml which contains empty lines like in-between the following insert statements:

INSERT INTO PERSON ("ID","DAYSWEEK", "EMAIL","HOURSWEEK","LOCATION","NAME", "PASSWORD", "ORGUNIT_ID") VALUES (2,5, 'someone@somewhere.net', 40, 'Munich','My Peer', 'test', 1)

INSERT INTO MISSION ("ID","NAME") VALUES (1, 'Java EE 7 Working Demo')

leads to

Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.5.0.v20130312-9664d23): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLNonTransientConnectionException: Es wurde ein Netzprotokollfehler gefunden. Die Verbindung wurde beendet. Ein PROTOCOL Datenstrom-Syntaxfehler wurde erfasst. Ursache: 0x9.236. Versuch, eine Reintext-Verbindung mit einem SSL-konformen Server herzustellen?
Error Code: 40000
Call:
Query: DataModifyQuery(sql="")
at org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:340)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.processExceptionForCommError(DatabaseAccessor.java:1607)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:671)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:558)
at org.eclipse.persistence.internal.sessions.AbstractSession.basicExecuteCall(AbstractSession.java:1979)
at org.eclipse.persistence.sessions.server.ServerSession.executeCall(ServerSession.java:570)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:223)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:209)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeNoSelectCall(DatasourceCallQueryMechanism.java:252)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeNoSelect(DatasourceCallQueryMechanism.java:232)
at org.eclipse.persistence.queries.DataModifyQuery.executeDatabaseQuery(DataModifyQuery.java:85)
at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:899)
at org.eclipse.persistence.internal.sessions.AbstractSession.internalExecuteQuery(AbstractSession.java:3191)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1781)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1763)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1714)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeNonSelectingCall(AbstractSession.java:1483)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeNonSelectingSQL(AbstractSession.java:1501)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.writeSourceScriptToDatabase(EntityManagerSetupImpl.java:4061)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.writeDDL(EntityManagerSetupImpl.java:3812)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:724)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.getAbstractSession(EntityManagerFactoryDelegate.java:204)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.getDatabaseSession(EntityManagerFactoryDelegate.java:182)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.getDatabaseSession(EntityManagerFactoryImpl.java:527)
at org.eclipse.persistence.jpa.PersistenceProvider.createContainerEntityManagerFactory(PersistenceProvider.java:358)
at org.glassfish.persistence.jpa.PersistenceUnitLoader.loadPU(PersistenceUnitLoader.java:199)
at org.glassfish.persistence.jpa.PersistenceUnitLoader.<init>(PersistenceUnitLoader.java:107)
at org.glassfish.persistence.jpa.JPADeployer$1.visitPUD(JPADeployer.java:223)
at org.glassfish.persistence.jpa.JPADeployer$PersistenceUnitDescriptorIterator.iteratePUDs(JPADeployer.java:510)
at org.glassfish.persistence.jpa.JPADeployer.createEMFs(JPADeployer.java:230)
at org.glassfish.persistence.jpa.JPADeployer.prepare(JPADeployer.java:168)
at com.sun.enterprise.v3.server.ApplicationLifecycle.prepareModule(ApplicationLifecycle.java:922)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:431)
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:1761)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.sql.SQLNonTransientConnectionException: Es wurde ein Netzprotokollfehler gefunden. Die Verbindung wurde beendet. Ein PROTOCOL Datenstrom-Syntaxfehler wurde erfasst. Ursache: 0x9.236. Versuch, eine Reintext-Verbindung mit einem SSL-konformen Server herzustellen?
at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown Source)
at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
at org.apache.derby.client.am.Connection.prepareStatement(Unknown Source)
at com.sun.gjc.spi.base.ConnectionHolder.prepareStatement(ConnectionHolder.java:586)
at com.sun.gjc.spi.jdbc40.ConnectionWrapper40.prepareCachedStatement(ConnectionWrapper40.java:255)
at com.sun.gjc.spi.jdbc40.ConnectionWrapper40.prepareCachedStatement(ConnectionWrapper40.java:52)
at com.sun.gjc.spi.ManagedConnectionImpl.prepareCachedStatement(ManagedConnectionImpl.java:992)
at com.sun.gjc.spi.jdbc40.ConnectionWrapper40.prepareStatement(ConnectionWrapper40.java:173)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.prepareStatement(DatabaseAccessor.java:1553)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.prepareStatement(DatabaseAccessor.java:1502)
at org.eclipse.persistence.internal.databaseaccess.DatabaseCall.prepareStatement(DatabaseCall.java:750)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:619)
... 63 more
Caused by: org.apache.derby.client.am.DisconnectException: Es wurde ein Netzprotokollfehler gefunden. Die Verbindung wurde beendet. Ein PROTOCOL Datenstrom-Syntaxfehler wurde erfasst. Ursache: 0x9.236. Versuch, eine Reintext-Verbindung mit einem SSL-konformen Server herzustellen?
at org.apache.derby.client.net.Reply.doSyntaxrmSemantics(Unknown Source)
at org.apache.derby.client.net.NetConnectionReply.parseSYNTAXRM(Unknown Source)
at org.apache.derby.client.net.NetConnectionReply.parseCommonError(Unknown Source)
at org.apache.derby.client.net.NetStatementReply.parsePrepareError(Unknown Source)
at org.apache.derby.client.net.NetStatementReply.parsePRPSQLSTTreply(Unknown Source)
at org.apache.derby.client.net.NetStatementReply.readPrepareDescribeOutput(Unknown Source)
at org.apache.derby.client.net.StatementReply.readPrepareDescribeOutput(Unknown Source)
at org.apache.derby.client.net.NetStatement.readPrepareDescribeOutput_(Unknown Source)
at org.apache.derby.client.am.Statement.readPrepareDescribeOutput(Unknown Source)
at org.apache.derby.client.am.PreparedStatement.readPrepareDescribeInputOutput(Unknown Source)
at org.apache.derby.client.am.PreparedStatement.flowPrepareDescribeInputOutput(Unknown Source)
at org.apache.derby.client.am.PreparedStatement.prepare(Unknown Source)
at org.apache.derby.client.am.Connection.prepareStatementX(Unknown Source)
... 73 more



 Comments   
Comment by sherryshen [ 20/Mar/13 ]

Thank for reporting the problem.
I tracked the issue with
https://bugs.eclipse.org/bugs/show_bug.cgi?id=403936

Comment by arungupta [ 21/Mar/13 ]

I believe the issue has already been fixed, targeting it for 4.0.

Comment by Mitesh Meswani [ 26/Mar/13 ]

Fixed with integration of EclipseLink 2.5.0-M10





[GLASSFISH-19951] [Regression] Unable to set lifecycle module property Created: 20/Mar/13  Updated: 21/Mar/13  Resolved: 20/Mar/13

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 4.0_b80_EE7MS6
Fix Version/s: 4.0_b81

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

Using glassfish-4.0-b80-unix.sh build, OEL6 machine, JDK 1.7.0_13, local install and user (agpineda).


Tags: 40_regression

 Description   

The following test scenario is failing on the promoted build80 (MS6). It works on promoted build 79. The scenario is from SQE's AdminCLI test suite. The scenario is as follows:

o asadmin --user admin1 --passwordfile $TEST/appserver-sqe/common/admincli/config/template/t_passwd1.txt create-domain --domaindir $TEST/glassfish4/glassfish/testdomaindir --adminport 10000 --instanceport 10005 testdomain
Domain testdomain created.
Domain testdomain admin port is 10,000.
Domain testdomain admin user is "admin1".
Command create-domain executed successfully.

o asadmin --user admin1 --passwordfile $TEST/appserver-sqe/common/admincli/config/template/t_passwd1.txt start-domain --domaindir $TEST/glassfish4/glassfish/testdomaindir testdomain
Successfully started the domain : testdomain
Command start-domain executed successfully.

o asadmin --user admin1 --passwordfile $TEST/appserver-sqe/common/admincli/config/template/t_passwd1.txt --host wolfrun.us.oracle.com --port 10000 create-lifecycle-module --classname TestLifecycleModule2 TestLifecycleModule2
Command create-lifecycle-module executed successfully.

o asadmin --user admin1 --passwordfile $TEST/appserver-sqe/common/admincli/config/template/t_passwd1.txt --host wolfrun.us.oracle.com --port 10000 list-lifecycle-modules
TestLifecycleModule2
Command list-lifecycle-modules executed successfully.

On build 79, one can see the following results (it passes)

o asadmin --user admin1 --passwordfile $TEST/appserver-sqe/common/admincli/config/template/t_passwd1.txt --host wolfrun.us.oracle.com --port 10000 set applications.application.TestLifecycleModule2.property.load-order=1
applications.application.TestLifecycleModule2.property.load-order=1
Command set executed successfully.
o asadmin --user admin1 --passwordfile $TEST/appserver-sqe/common/admincli/config/template/t_passwd1.txt --host wolfrun.us.oracle.com --port 10000 get applications.application.TestLifecycleModule2.*
applications.application.TestLifecycleModule2.property.is-failure-fatal=false
applications.application.TestLifecycleModule2.property.class-name=TestLifecycleModule2

    • applications.application.TestLifecycleModule2.property.load-order=1 **
      applications.application.TestLifecycleModule2.property.isLifecycle=true
      applications.application.TestLifecycleModule2.async-replication=true
      applications.application.TestLifecycleModule2.availability-enabled=false
      applications.application.TestLifecycleModule2.deployment-order=100
      applications.application.TestLifecycleModule2.directory-deployed=false
      applications.application.TestLifecycleModule2.enabled=true
      applications.application.TestLifecycleModule2.name=TestLifecycleModule2
      applications.application.TestLifecycleModule2.object-type=user
      Command get executed successfully.

On build 80, it fails as follows:

o asadmin --user admin1 --passwordfile $TEST/appserver-sqe/common/admincli/config/template/t_passwd1.txt --host wolfrun.us.oracle.com --port 10000 set applications.application.TestLifecycleModule2.property.load-order=1
Command set failed.
remote failure: Could not change the attributes: HV000028: Unexpected exception during isValid call.
HV000028: Unexpected exception during isValid call.
o asadmin --user admin1 --passwordfile $TEST/appserver-sqe/common/admincli/config/template/t_passwd1.txt --host wolfrun.us.oracle.com --port 10000 get applications.application.TestLifecycleModule2.*
applications.application.TestLifecycleModule2.property.is-failure-fatal=false
applications.application.TestLifecycleModule2.property.class-name=TestLifecycleModule2
applications.application.TestLifecycleModule2.property.isLifecycle=true
applications.application.TestLifecycleModule2.async-replication=true
applications.application.TestLifecycleModule2.availability-enabled=false
applications.application.TestLifecycleModule2.deployment-order=100
applications.application.TestLifecycleModule2.directory-deployed=false
applications.application.TestLifecycleModule2.enabled=true
applications.application.TestLifecycleModule2.name=TestLifecycleModule2
applications.application.TestLifecycleModule2.object-type=user
Command get executed successfully

Please note that in build 79 the property is set and visible after the "get" operation. On build 80, the "set" operation fails and the property is not listed after the "get". As mentioned, the test case is from our AdminCli test suite and it's a GF 2.x scenario. A comment on the test case notes, the "lifecycle module is created with the only the required parameters".



 Comments   
Comment by Tom Mueller [ 20/Mar/13 ]

I tried this on the latest trunk build, and it works fine. So this has been fixed recently (I'm not sure which revision).

Comment by Alex Pineda [ 21/Mar/13 ]

Don't see the issue in promoted build 81. I would be curious to know what got changed that caused this regression as this was not expected. Feel free to close the bug.





[GLASSFISH-19939] NPE happened in org.glassfish.admin.mbeanserver.ConnectorStarter.stop while running fighterfish test Created: 19/Mar/13  Updated: 19/Mar/13  Resolved: 19/Mar/13

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

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

Win7 64bit



 Description   

After running fighterfish test, not only GLASSFISH-19905 happened, but also, the following exception also happened,

[2013-03-19T23:34:08.073+0800] [glassfish 4.0] [WARNING] [NCLS-CORE-00069] [javax.enterprise.system.core] [tid: _ThreadID=12 _ThreadName=FelixStartLevel] [timeMillis: 1363707248073] [levelValue: 900] [CLASSNAME: org.glassfish.kernel.event.EventsImpl] [METHODNAME: send] [[
Exception while dispatching an event
java.lang.NullPointerException
at org.glassfish.admin.mbeanserver.ConnectorStarter.stop(ConnectorStarter.java:124)
at org.glassfish.admin.mbeanserver.RMIConnectorStarter.stopAndUnexport(RMIConnectorStarter.java:310)
at org.glassfish.admin.mbeanserver.JMXStartupService$JMXConnectorsStarterThread.shutdown(JMXStartupService.java:245)
at org.glassfish.admin.mbeanserver.JMXStartupService.shutdown(JMXStartupService.java:193)
at org.glassfish.admin.mbeanserver.JMXStartupService.access$000(JMXStartupService.java:96)
at org.glassfish.admin.mbeanserver.JMXStartupService$ShutdownListener.event(JMXStartupService.java:163)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at com.sun.enterprise.v3.server.AppServerStartup.stop(AppServerStartup.java:429)
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.GlassFishMainActivator.stop(GlassFishMainActivator.java:257)
at org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:667)
at org.apache.felix.framework.Felix.stopBundle(Felix.java:2518)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1297)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)
at java.lang.Thread.run(Thread.java:722)
]]



 Comments   
Comment by TangYong [ 19/Mar/13 ]

I have seen the source[1],

[1]: trunk\main\nucleus\common\mbeanserver\src\main\java\org\glassfish\admin\mbeanserver\ConnectorStarter.java

In stop method, we must check whether mConnectorServer is NULL.

Comment by Tom Mueller [ 19/Mar/13 ]

Changing to the amx component.

Comment by Tim Quinn [ 19/Mar/13 ]

Do we understand why this error occurs only during FighterFish tests and not in any other situations?

Checking for null would certainly resolve this issue but is there some other underlying problem that doing so would mask?

Comment by Tim Quinn [ 19/Mar/13 ]

Fix checked in.

Project: glassfish
Repository: svn
Revision: 60589
Author: tjquinn
Date: 2013-03-19 17:53:37 UTC
Link:

Log Message:
------------
Fix for 19939

During FighterFish testing a NPE resulted from ConnectorStarter.stop being invoked apparently before a concrete subclass's start was invoked.

This change checks the connector server for non-nullness before invoking stop on it.

Revisions:
----------
60589

Modified Paths:
---------------
trunk/main/nucleus/common/mbeanserver/src/main/java/org/glassfish/admin/mbeanserver/ConnectorStarter.java





[GLASSFISH-19938] [Fighterfish]adding -Xmx512m into test/it/pom.xml Created: 19/Mar/13  Updated: 25/Mar/13  Resolved: 25/Mar/13

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

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

windows xp



 Description   

Pl. seeing http://java.net/projects/glassfish/lists/dev/archive/2013-03/message/71

The issue has been triggered in my local env and just as sahoo's suggestion, maybe we need to add -Xmx512m into test/it/pom.xml.

BTW: only by setting MAVEN_OPTS=-Xmx512m -XX:PermSize=256m can not resolve the issue, because the maven-surefire-plugin forks a new JVM by default[1].

[1]: http://stackoverflow.com/questions/4066424/java-lang-outofmemoryerror-java-heap-space-in-maven



 Comments   
Comment by TangYong [ 19/Mar/13 ]

Done.

[Revision]
60575





[GLASSFISH-19936] ADMINGUI : property sort doesnot deselects the selected rows. Created: 19/Mar/13  Updated: 19/Mar/13  Resolved: 19/Mar/13

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b81

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

Windows 7, Build 80


Tags: admin-gui, property, table

 Description   

property sort doesnot deselects the selected rows.

In edit context service ( any concurrent service ) window
create some properties.
select some / all properties.
sort name or value or description property.
it sorts properly but not deselects the selected property and it disables only the delete properties.
due to that selected properties cannot delete.

In the Table the final column Description is given as "Description:"
In the above ":" has to be removed.



 Comments   
Comment by Anissa Lam [ 19/Mar/13 ]

For the property table selection.

Logically, user will do the sorting to get what they want first, then select and then delete. This case works fine.
It is a corner case where user select the rows first, and then do the sorting. Its true that the delete button won't be activated. This is more like a p5 issue. Thats a limitation in the table design. Its is not an easy fix, considering the risk involved, and the easy workaround to deselect/select the rows again, this part will not be fixed.

The Description column header has been fixed to without the colon.





[GLASSFISH-19934] AdminGUI : Error message should be clear. Created: 19/Mar/13  Updated: 19/Mar/13  Resolved: 19/Mar/13

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b81

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

Tags: admin-gui, managed-scheduled-executor-service

 Description   

Tested in 4.0Build80

In New - Managed scheduled executor service
provide Hung after as -1 and save the page.

Throws error as
=================
An error has occurred
Managed scheduled executor service t creation failed. javax.validation.ConstraintViolationException: Constraints for this ManagedScheduledExecutorService configuration have been violated: on property [ hungAfterSeconds ] violation reason [ must be greater than or equal to 0 ] javax.validation.ConstraintViolationException: Constraints for this ManagedScheduledExecutorService configuration have been violated: on property [ hungAfterSeconds ] violation reason [ must be greater than or equal to 0 ]
=======================

Error should be appropriate.

"javax.validation.ConstraintViolationException: Constraints for this ManagedScheduledExecutorService configuration have been violated: on property [ hungAfterSeconds ] violation reason [ must be greater than or equal to 0 ] " is printed twice.



 Comments   
Comment by Anissa Lam [ 19/Mar/13 ]

I cannot reproduce this in my latest workspace. This is probably fixed but didn't make into promoted build 80.
Mark as resolved. If you still see this after 3/19 nightly build or build 81, please reopen.





[GLASSFISH-19933] ADMINGUI : New Managed thread factory Context Information - default is not selected all Created: 19/Mar/13  Updated: 19/Mar/13  Resolved: 19/Mar/13

Status: Resolved
Project: glassfish
Component/s: concurrency
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b81

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

Tags: admin-gui, console, managed-thread-factories

 Description   

Tested in 4.0 Build 80

New Managed thread factory the Context Information by default is not selected all.

1.Select Managed thread factory
2. click new.

context information is selected with Enabled by default.
But context information ( classloader, JNDI, Security, WorkArea ) are not selected by default. By default it selects only Classloader.

Selecting of any number of values and save it will save all the values.

  • select only classloader and save it with the jndiname as "test1"
    Now open test1. (edit it )
    you will see all the values are selected ( classloader, JNDI, Security, WorkArea )


 Comments   
Comment by Anissa Lam [ 19/Mar/13 ]

managed-thread-factory has a typo in the contextinfo attribute name. It is all lower case.
For all the other 3 concurrency resources, it is camelcase contextInfo (I is capitalized).

Console expects it to be camelCase as like others. Thus, this bug.
Transfer to Hong for a fix.

Comment by Hong Zhang [ 19/Mar/13 ]

Add the alias for contextinfo option as contextInfo for the managed-thread-factory which was missing previously.





Clean up connector modules of various modules (GLASSFISH-17656)

[GLASSFISH-19927] Move concurrent config out of concurrent-impl Created: 19/Mar/13  Updated: 19/Mar/13  Resolved: 19/Mar/13

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

Type: Sub-task Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Hong Zhang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: spo

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

Move the config beans out of the concurrent-impl module to a new module concurrent-connector. The config beans need to be loaded during server start up so we should separate them out.





[GLASSFISH-19926] [Regression] command create-domain failed due to portbase and custom token Created: 19/Mar/13  Updated: 21/Mar/13  Resolved: 21/Mar/13

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 4.0_b80_EE7MS6
Fix Version/s: 4.0_b81

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

GlassFish Server Open Source Edition 4.0 (build 80), Linux, jdk1.7.0_17


Tags: 40_regression

 Description   

Glassfish domain creation fails while using this command. This used to work fine for very long. Not sure what changed.

[exec] asadmin --host localhost --port 4848 --user admin --passwordfile /scratch/aime1/hudson-root/password.txt --interactive=false --echo=true --terse=false create-domain --portbase 10000 --savemasterpassword=false --usemasterpassword=false --savelogin=false --nopassword=false --checkports=true domain2
[exec] Using port 10048 for Admin.
[exec] Using port 10080 for HTTP Instance.
[exec] Using port 10076 for JMS.
[exec] Using port 10037 for IIOP.
[exec] Using port 10081 for HTTP_SSL.
[exec] Using port 10038 for IIOP_SSL.
[exec] Using port 10039 for IIOP_MUTUALAUTH.
[exec] Using port 10086 for JMX_ADMIN.
[exec] Using port 10066 for OSGI_SHELL.
[exec] Using port 10009 for JAVA_DEBUGGER.
[exec] Distinguished Name of the self-signed X.509 Server Certificate is:
[exec] [CN=blr2230390.idc.oracle.com,OU=GlassFish,O=Oracle Corporation,L=Santa Clara,ST=California,C=US]
[exec] Distinguished Name of the self-signed X.509 Server Certificate is:
[exec] [CN=blr2230390.idc.oracle.com-instance,OU=GlassFish,O=Oracle Corporation,L=Santa Clara,ST=California,C=US]
[exec] null( java.lang.NumberFormatException: null )
[exec] CLI130: Could not create domain, domain2
[exec] Command create-domain failed.



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

The failure can be reproduced with this simpler command:

asadmin create-domain --portbase domain2

The exception is coming from CustomTokenClient.java, line 126 where it is getting the value of the JMS_PROVIDER_PORT (a custom token). Apparently when the --portbase option is used, a value is not being calculated for the custom token.

Alok, can you please look into this. This might be config modularity related too.

This issue must be fixed for the 4.0 release.

Comment by Alex Pineda [ 19/Mar/13 ]

Adding "Regression" to the bug synopsis and using QA 40_regression tag.

Comment by Alok Jain [ 19/Mar/13 ]

I have fixed the issue and submitted my changes (Revision # 60585). This fix is available from the build # 13809 (http://gf-hudson.us.oracle.com/hudson/job/gf-trunk-build-continuous/13809/)

Comment by Alex Pineda [ 19/Mar/13 ]

Seeing the same failure in our AdminCLI test suite. The test case is:
o asadmin --user portbaseuser --passwordfile $HOME/workspace/alex-admincli/appserver-sqe/pe/admincli/config/runtime/pepassword.txt create-domain --portbase 9999 portbasedomain
It fails with the same error.

Comment by Alok Jain [ 20/Mar/13 ]

The problem was with handling the portbase argument with the custom token. This fix will also resolve the issue caused in AdminCLI test. Can this be verified against the Hudson build or do we need to wait for the next build promotion?

Comment by Alok Jain [ 21/Mar/13 ]

Fixed the code to handle the portbase argument with custom tokens.

Comment by Alex Pineda [ 21/Mar/13 ]

AdminCLI test suite issue is resolved with promoted build 81. The tests are passing now (4 of them).





[GLASSFISH-19907] removing unused import and field in osgi-container Created: 17/Mar/13  Updated: 25/Mar/13  Resolved: 25/Mar/13

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

Type: Improvement Priority: Minor
Reporter: TangYong Assignee: TangYong
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In osgi-container module, there are some unused imports and filed.

1. org.glassfish.extras.osgicontainer.OSGiContainer

removing the following unused imports in order to make sources more clean

1) import org.glassfish.internal.deployment.GenericDeployer;
2) import java.util.Map;
3) import java.util.HashMap;
4) import java.lang.ref.WeakReference;
5) import com.sun.enterprise.module.Module;

2 org.glassfish.extras.osgicontainer.OSGiDeployer

removing the following unused filed because unused filed can have a minor effect on running

private static final String BUNDLE_ID = "bundle.id";



 Comments   
Comment by TangYong [ 17/Mar/13 ]

fixed.
Revision: 60517





[GLASSFISH-19904] 4.0 SDK: Build failure and errors when executing EL Sample Created: 16/Mar/13  Updated: 29/Mar/13  Resolved: 29/Mar/13

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

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

Installed java_ee_sdk-7-b79-jdk7-linux-x64.sh*, on OEL6 machine, using Maven version 3.0.5. Configured Maven environment as noted in http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/BG+Development+Environment+Guide



 Description   

Using the Sample instructions, the el3.0 sample fails to run. The instructions say to run "mvn clean compile exec:java" as it does not need a container to run. The exacts steps followed were:

o cd $HOME/glassfish4/samples/el
o mvn clean
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

o mvn compile
[INFO] Building Java EE 7 Expression Language Samples 4.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] — maven-enforcer-plugin:1.0:enforce (enforce-maven) @ el-samples —
[INFO]
[INFO] — maven-resources-plugin:2.5:resources (default-resources) @ el-samples —
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /home/agpineda/workspace/glassfish4/samples/el/src/main/resources
[INFO]
[INFO] — maven-compiler-plugin:2.4:compile (default-compile) @ el-samples —
[INFO] Compiling 1 source file to /home/agpineda/workspace/glassfish4/samples/el/target/classes
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

o mvn exec:java
[INFO] Building Java EE 7 Expression Language Samples 4.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] >>> exec-maven-plugin:1.1:java (default-cli) @ el-samples >>>
[INFO]
[INFO] — maven-enforcer-plugin:1.0:enforce (enforce-maven) @ el-samples —
[INFO]
[INFO] <<< exec-maven-plugin:1.1:java (default-cli) @ el-samples <<<
[INFO]
[INFO] — exec-maven-plugin:1.1:java (default-cli) @ el-samples —

====
Input EL string: 'Hello, world!'
Output Value: Hello, world!

====
Input EL string: Boolean.TRUE
Output Value: true

====
Input EL string: Integer.numberOfTrailingZeros(16)
Output Value: 4

====
Input EL string: 10 cat 11
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.299s
[INFO] Finished at: Fri Mar 15 22:07:15 PDT 2013
[INFO] Final Memory: 7M/149M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.1:java (default-cli) on project el-samples: An exception occured while executing the Java class. null: InvocationTargetException: Error Parsing: $

{10 cat 11}

: Encountered "cat" at line 1, column 6.
[ERROR] Was expecting one of:
[ERROR] "}" ...
[ERROR] "." ...
[ERROR] "[" ...
[ERROR] ";" ...
[ERROR] ">" ...
[ERROR] "gt" ...
[ERROR] "<" ...
[ERROR] "lt" ...
[ERROR] ">=" ...
[ERROR] "ge" ...
[ERROR] "<=" ...
[ERROR] "le" ...
[ERROR] "==" ...
[ERROR] "eq" ...
[ERROR] "!=" ...
[ERROR] "ne" ...
[ERROR] "&&" ...
[ERROR] "and" ...
[ERROR] "||" ...
[ERROR] "or" ...
[ERROR] "*" ...
[ERROR] "+" ...
[ERROR] "-" ...
[ERROR] "?" ...
[ERROR] "/" ...
[ERROR] "div" ...
[ERROR] "%" ...
[ERROR] "mod" ...
[ERROR] "+=" ...
[ERROR] "=" ...
[ERROR] -> [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/MojoExecutionException



 Comments   
Comment by Alex Pineda [ 20/Mar/13 ]

Still see the problem on build 80 (MS6)

Comment by Alex Pineda [ 28/Mar/13 ]

The problem appears resolved in SDK build 81. Just tried it and it works.

Comment by Dhiru Pandey [ 29/Mar/13 ]

Confirmed by reporter that it works in build 81





[GLASSFISH-19895] JMS resource configuration annotations and deployment descriptor elements changes: use of className Created: 15/Mar/13  Updated: 21/Mar/13  Resolved: 20/Mar/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b80_EE7MS6
Fix Version/s: 4.0_b81

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: Simon Meng
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-19894 JMS resource configuration annotation... Resolved
Tags: jms-2-implementation

 Description   

The JMS API will soon be updated to add a new element interfaceName to the annotations JMSConnectionFactoryDefinition and JMSDestinationDefinition.

The Java EE schema will also soon be updated to add a new element <interface-name> to the deployment descriptor elements <jms-connection-factory> and <jms-destination>.

The initial implementation of these changes is defined in GLASSFISH-19894. However once that has been done, the following additional handling is required for JMSDestinationDefinition/<jms-destination>.

Normally the className/<class-name> element is not used and should be ignored, since interfaceName/<interface-name> is sufficient to identify the <admin-object> element in the resource adapter's ra.xml which defines the managed connection factory class name.

However the connector spec allows the case where ra.xml contains two <admin-object>> elements with the same interface. In this case the className/<class-name> element should be used to determine which <admin-object>> element to use.

Note that for JMSConnectionFactoryDefinition/<jms-connection-factory>, no further changes are needed to the handling of these definitions beyond those defined in GLASSFISH-19894. className/<class-name> should always be ignored.



 Comments   
Comment by Simon Meng [ 19/Mar/13 ]

The new attribute is interfaceName. Update the issue description accordingly.

Comment by Simon Meng [ 20/Mar/13 ]

Fix at revision 60613

Comment by Simon Meng [ 21/Mar/13 ]

When updating MDB runtime info, it uses className, the new attribute interfaceName should be used here.
Committed revision 60664 to fix this issue.





[GLASSFISH-19894] JMS resource configuration annotations and deployment descriptor elements changes: new attribute interfaceName Created: 15/Mar/13  Updated: 20/Mar/13  Resolved: 20/Mar/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b80_EE7MS6
Fix Version/s: 4.0_b81

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: Simon Meng
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-19895 JMS resource configuration annotation... Resolved
Tags: jms-2-implementation

 Description   

The JMS API will soon be updated to add a new element interfaceName to the annotations JMSConnectionFactoryDefinition and JMSDestinationDefinition.

The Java EE schema will also soon be updated to add a new element <interface-name> to the deployment descriptor elements <jms-connection-factory> and <jms-destination>.

This requires the following changes to the processing of these definitions in GlassFish:

1. The required interface should be obtained from interfaceName/<iinterface-name> rather than className/<class-name> as previously.

2. The className/<class-name> elements should now be ignored. (A separate issue will be logged to handle supporting the cases where className/<class-name> is used.)

3. In the case of JMSConnectionFactoryDefinition and <jms-connection-factory>, if interfaceName/<interface-name> is not specified then a value of javax.jms.Connectionfactory should be used.



 Comments   
Comment by Simon Meng [ 19/Mar/13 ]

The new attribute is interfaceName. Update the summary and description accordingly.

Comment by Simon Meng [ 20/Mar/13 ]

Fix at revision 60613





[GLASSFISH-19890] Handling of JMS resource configuration annotations and deployment descriptor elements should use jmsra if resource adapter not specified Created: 15/Mar/13  Updated: 20/Mar/13  Resolved: 20/Mar/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b80_EE7MS6
Fix Version/s: 4.0_b81

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: Simon Meng
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jms-2-implementation

 Description   

This issue relates to the JMS resource configuration annotations JMSConnectionFactoryDefinition and JMSDestinationDefinition and to the corresponding deployment descriptor elements <jms-connection-factory> and <jms-destination>.

If the resource adapter is not specified (using the resourceAdapter annotation element or the <resource-adapter> deployment descriptor element) then the jmsra resource adapter should be used by default. Previously this would have been an error.

Note that this change can be implemented immediately with no need to wait for any changes to the JMS API or to the Java EE schema.



 Comments   
Comment by Simon Meng [ 20/Mar/13 ]

Fix at revision 60613





[GLASSFISH-19880] Web regression from svn 60399 Created: 14/Mar/13  Updated: 16/Mar/13  Resolved: 16/Mar/13

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

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


 Description   

We are seeing regression in servlet tck and web devtests since svn commit 60399.

TCK
[javatest.batch] FAILED........com/sun/ts/tests/servlet/spec/errorpage/URLClient.java#statusCodeErrorPageTest

Web devtests
[java] - scriptlet-syntax-error-correct-error-message: FAIL -
[java] - responseExceptionMessageEncoding: FAIL -



 Comments   
Comment by Shing Wai Chan [ 14/Mar/13 ]

The first one is fixed in the following:
Sending
war-util/src/main/java/org/glassfish/web/util/HtmlEntityEncoder.java
Sending
web-core/src/main/java/org/apache/catalina/servlets/WebdavServlet.java
Sending web-core/src/main/java/org/apache/catalina/ssi/SSIServlet.java
Sending
web-core/src/main/java/org/apache/catalina/valves/ErrorReportValve.java
Transmitting file data ....
Committed revision 60475.

Comment by Shing Wai Chan [ 16/Mar/13 ]

Sending web/war-util/src/main/java/org/glassfish/web/util/HtmlEntityEncoder.java
Sending web/web-core/src/main/java/org/apache/catalina/connector/Response.java
Sending web/web-core/src/main/java/org/apache/catalina/core/ApplicationDispatcherForward.java
Sending web/web-core/src/main/java/org/apache/catalina/core/StandardHostValve.java
Sending web/web-core/src/main/java/org/apache/catalina/servlets/CGIServlet.java
Sending web/web-core/src/main/java/org/apache/catalina/servlets/DefaultServlet.java
Sending web/web-core/src/main/java/org/apache/catalina/ssi/SSIConfig.java
Sending web/web-core/src/main/java/org/apache/catalina/ssi/SSIEcho.java
Sending web/web-core/src/main/java/org/apache/catalina/ssi/SSIExec.java
Sending web/web-core/src/main/java/org/apache/catalina/ssi/SSIFilter.java
Sending web/web-core/src/main/java/org/apache/catalina/ssi/SSIFlastmod.java
Sending web/web-core/src/main/java/org/apache/catalina/ssi/SSIFsize.java
Sending web/web-core/src/main/java/org/apache/catalina/ssi/SSIInclude.java
Sending web/web-core/src/main/java/org/apache/catalina/ssi/SSIPrintenv.java
Sending web/web-core/src/main/java/org/apache/catalina/ssi/SSIProcessor.java
Sending web/web-core/src/main/java/org/apache/catalina/ssi/SSIServlet.java
Sending web/web-core/src/main/java/org/apache/catalina/ssi/SSISet.java
Sending web/web-core/src/main/java/org/apache/catalina/valves/ErrorReportValve.java
Sending webservices/jsr109-impl/src/main/java/org/glassfish/webservices/WsUtil.java
Transmitting file data ...................
Committed revision 60515.





[GLASSFISH-19868] Batch RI : Batch Exceptions : JobExecutionAlreadyCompleteException not thrown when restarting a completed Job Created: 14/Mar/13  Updated: 02/Apr/13  Resolved: 02/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b81

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


 Description   

Tested with latest nightly : glassfish-4.0-b80-03_13_2013

Steps:

1) Restart a job execution which is already completed.

Issue--> JobExecutionAlreadyCompleteException not thrown. Creates a new Job execution with the server logs. But actually the job not started.

Expected: JobExecutionAlreadyCompleteException should be thrown, and Job Operator should create a new execution.

[2013-03-14T18:18:15.890+0530] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=29 _ThreadName=Thread-3] [timeMillis: 1363265295890] [levelValue: 800] [[

    • GlassFishBatchExecutorServiceProvider.getExecutorService() called]]

[2013-03-14T18:18:15.890+0530] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=29 _ThreadName=Thread-3] [timeMillis: 1363265295890] [levelValue: 800] [[
Job with Execution id:287 restarted]]



 Comments   
Comment by ScottKurz [ 15/Mar/13 ]

OK.. I see we hadn't implemented this and have done so internally. Available next respin.

Comment by ScottKurz [ 27/Mar/13 ]

This should have been in for awhile now.. in 1.0-b19, I believe.





[GLASSFISH-19866] NPE in ContextRootCheckValidator that blocks disabling an application that does not have "context-root" Created: 14/Mar/13  Updated: 14/Mar/13  Resolved: 14/Mar/13

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

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


 Description   

svn revision 60360 which is a fix for GLASSFISH-18861 seems to check for contextroot of <application>

context-root will not be available for all type of applications (eg : .ear, .rar etc.,)

When such a .rar/.ear is deployed and we try to disable the application by calling :
asadmin set applications.application.generic-ra.enabled=false
or
applications.application.connector16App.enabled=false

enable operation fails and I see the following NPE.

[2013-03-14T14:21:29.153+0530] [glassfish 4.0] [SEVERE] [NCLS-CORE-0003] [javax.enterprise.system.core] [tid: _ThreadID=41 _ThreadName=admin-listener(1)] [timeMillis: 1363251089153] [levelValue: 1000] [[
Exception while running a command
javax.validation.ValidationException: HV000028: Unexpected exception during isValid call.
at org.hibernate.validator.internal.engine.constraintvalidation.ConstraintTree.validateSingleConstraint(ConstraintTree.java:287)
at org.hibernate.validator.internal.engine.constraintvalidation.ConstraintTree.validateConstraints(ConstraintTree.java:137)
at org.hibernate.validator.internal.engine.constraintvalidation.ConstraintTree.validateConstraints(ConstraintTree.java:95)
at org.hibernate.validator.internal.metadata.core.MetaConstraint.validateConstraint(MetaConstraint.java:85)
at org.hibernate.validator.internal.engine.ValidatorImpl.validateConstraint(ValidatorImpl.java:477)
at org.hibernate.validator.internal.engine.ValidatorImpl.validateConstraintsForDefaultGroup(ValidatorImpl.java:423)
at org.hibernate.validator.internal.engine.ValidatorImpl.validateConstraintsForCurrentGroup(ValidatorImpl.java:387)
at org.hibernate.validator.internal.engine.ValidatorImpl.validateInContext(ValidatorImpl.java:339)
at org.hibernate.validator.internal.engine.ValidatorImpl.validate(ValidatorImpl.java:157)
at org.jvnet.hk2.config.WriteableView.canCommit(WriteableView.java:303)
at org.jvnet.hk2.config.Transaction.canCommit(Transaction.java:89)
at org.jvnet.hk2.config.Transaction.commit(Transaction.java:108)
at org.jvnet.hk2.config.ConfigSupport.apply(ConfigSupport.java:390)
at com.sun.enterprise.v3.admin.SetCommand.set(SetCommand.java:461)
at com.sun.enterprise.v3.admin.SetCommand.execute(SetCommand.java:167)
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:1761)
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:350)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:345)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:214)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:207)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:203)
at org.glassfish.jersey.internal.Errors.process(Errors.java:251)
at org.glassfish.jersey.internal.Errors.process(Errors.java:233)
at org.glassfish.jersey.internal.Errors.process(Errors.java:203)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:190)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:865)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:161)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.NullPointerException
at com.sun.enterprise.config.serverbeans.customvalidators.ContextRootCheckValidator.isValid(ContextRootCheckValidator.java:102)
at com.sun.enterprise.config.serverbeans.customvalidators.ContextRootCheckValidator.isValid(ContextRootCheckValidator.java:60)
at org.hibernate.validator.internal.engine.constraintvalidation.ConstraintTree.validateSingleConstraint(ConstraintTree.java:284)
... 67 more

Fix is to ensure that context root is not null and then check for equality of context-root.

I shall send the .ear and .rar by email since I can't attach them in the JIRA.



 Comments   
Comment by Amy Roh [ 14/Mar/13 ]

Fixed in 60464.





[GLASSFISH-19863] using REST to configure-batch-runtime always fails Created: 13/Mar/13  Updated: 15/Mar/13  Resolved: 15/Mar/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b81

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

Tags: console

 Description   

Calling configure-batch-runtime is giving back a status 405 FAILURE.
I believe i am passing in the correct payload and using the correct endpoint.

[#|2013-03-10T21:00:27.225-0700|SEVERE|glassfish 4.0|org.glassfish.admingui|_ThreadID=78;_ThreadName=admin-listener(1);_TimeMillis=1362974427225;_LevelValue=1000;|
RestResponse.getResponse() gives FAILURE. endpoint = 'http://localhost:4848/management/domain/configure-batch-runtime'; attrs = '

{executorServiceLookupName=java:comp/DefaultManagedExecutorService, dataSourceLookupName=jdbc/__TimerPool}

'|#]



 Comments   
Comment by Mahesh Kannan [ 15/Mar/13 ]

svn commit -m "Fix for 19863: The RestEndpoint.opType should have been a POST (instead of a GET)"
Sending batch-connector/src/main/java/org/glassfish/batch/ConfigureBatchRuntime.java
Sending batch-connector/src/main/java/org/glassfish/batch/ListBatchJobExecutions.java
Sending batch-connector/src/main/java/org/glassfish/batch/ListBatchRuntimeConfiguration.java
Transmitting file data ...
Committed revision 60482.





[GLASSFISH-19857] CLICommands in admin-cli.jar showing up twice in list-commands --localonly output Created: 13/Mar/13  Updated: 02/Apr/13  Resolved: 02/Apr/13

Status: Resolved
Project: glassfish
Component/s: command_line_interface
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b81

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


 Description   

The list-commands --localonly output is showing the CLICommands that are in admin-cli.jar twice:

$ asadmin list-commands --localonly

                    • Local Commands **********
                      backup-domain
                      change-admin-password
                      change-master-password
                      create-domain
                      create-local-instance
                      create-service
                      delete-domain
                      delete-local-instance
                      export
                      export
                      help
                      help
                      import-sync-bundle
                      install-node
                      install-node-dcom
                      install-node-ssh
                      list-backups
                      list-commands
                      list-commands
                      list-domains
                      login
                      login
                      monitor
                      multimode
                      multimode
                      osgi-shell
                      restart-domain
                      restart-local-instance
                      restore-domain
                      setup-local-dcom
                      setup-ssh
                      start-database
                      start-domain
                      start-local-instance
                      stop-database
                      stop-domain
                      stop-local-instance
                      uninstall-node
                      uninstall-node-dcom
                      uninstall-node-ssh
                      unset
                      unset
                      validate-multicast
                      verify-domain-xml
                      version
                      version

Command list-commands executed successfully.

This is probably related to the recent changes in how CLICommands are looked up by the command framework.






[GLASSFISH-19852] 4.0 SDK : Installer window shows improper version Created: 13/Mar/13  Updated: 21/Mar/13  Resolved: 21/Mar/13

Status: Resolved
Project: glassfish
Component/s: installation
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b81

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

OEL 6 , Windows 8



 Description   

Steps to reproduce:

Invoke the installation of javaee 7 sdk b79 build.
Most of the installer windows shows the version as "java ee 6 SDK" instead of "java ee 7 SDK".



 Comments   
Comment by Alex Pineda [ 13/Mar/13 ]

Assigning bug to installation component

Comment by Snjezana Sevo-Zenzerovic [ 21/Mar/13 ]

I am consolidating all installer branding/versioning issues, so closing this as duplicate of umbrella issue GLASSFISH-19998.





[GLASSFISH-19820] list-managed-executor-services is returning wrong services Created: 11/Mar/13  Updated: 18/Mar/13  Resolved: 18/Mar/13

Status: Resolved
Project: glassfish
Component/s: concurrency
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b81

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


 Description   

list-managed-executor-services should not include the ManagedScheduledExecutorService.

%asadmin list-managed-executor-services
concurrent/__defaultManagedExecutorService
concurrent/__defaultManagedScheduledExecutorService
Command list-managed-executor-services executed successfully.

The other 3 list services is working correctly.



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

Filter out managed scheduled executor service when listing managed executor services.





[GLASSFISH-19712] IllegalArgumentException from ClassLoader.definePackage Created: 22/Feb/13  Updated: 14/Mar/13  Resolved: 14/Mar/13

Status: Resolved
Project: glassfish
Component/s: classloader
Affects Version/s: 4.0_b77
Fix Version/s: 4.0_b81

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

Mac OS or Solaris x86



 Description   

The admin devtests are periodically seeing failures that result in the inability to fetch the index.html page from an instance. This typically happens once or twice in every run of the admin devtest hudson job. See:
http://hudson-sca.us.oracle.com/job/admin-devtests-trunk/

I recreated this problem locally on MacOS by using a manual run of just the cluster tests. I stopped the test after the failure so I could see what was happening. The log messages below showed up in the server.log file. These seem to indicate some sort of problem with starting the web container.

I don't know if these exceptions are what are causing the failure to serve static HTML pages.

The behavior of the instance when it gets into this state is as follows:

$ curl -v http://localhost:18080/

  • About to connect() to localhost port 18080 (#0)
  • Trying ::1...
  • connected
  • Connected to localhost (::1) port 18080 (#0)
    > GET / HTTP/1.1
    > User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8r zlib/1.2.5
    > Host: localhost:18080
    > Accept: /
    >
    < HTTP/1.1 500 Internal Server Error
    < X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 4.0 Java/Oracle Corporation/1.7)
    < Server: GlassFish Server Open Source Edition 4.0
    < Content-Language:
    < Content-Type: text/html
    < Date: Fri, 22 Feb 2013 01:57:24 GMT
    < Connection: close
    < Content-Length: 0
    <
  • Closing connection #0

[#|2013-02-21T19:00:42.480-0600|SEVERE|glassfish 4.0|javax.enterprise.web.core|_ThreadID=1;_ThreadName=main;_TimeMillis=1361494842480;_LevelValue=1000;_MessageID=AS-WEB-CORE-00113;|Startup of context failed due to previous errors|#]

[#|2013-02-21T19:00:42.482-0600|SEVERE|glassfish 4.0|javax.enterprise.web.core|_ThreadID=1;_ThreadName=main;_TimeMillis=1361494842482;_LevelValue=1000;_MessageID=AS-WEB-CORE-00114;|Exception during cleanup after start failed
org.apache.catalina.LifecycleException: Manager has not yet been started
at org.apache.catalina.session.StandardManager.stop(StandardManager.java:934)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:6092)
at com.sun.enterprise.web.WebModule.stop(WebModule.java:725)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5909)
at com.sun.enterprise.web.WebModule.start(WebModule.java:696)
at org.apache.catalina.core.ContainerBase.startChildren(ContainerBase.java:1593)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1290)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:982)
at org.apache.catalina.core.ContainerBase.startChildren(ContainerBase.java:1593)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1290)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:402)
at org.apache.catalina.startup.Embedded.start(Embedded.java:993)
at com.sun.enterprise.web.WebContainer.postConstruct(WebContainer.java:867)
at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:264)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:306)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:433)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:87)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2099)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
at org.glassfish.internal.data.EngineInfo.getContainer(EngineInfo.java:86)
at org.glassfish.kernel.javaee.WebContainerStarter.startWebContainer(WebContainerStarter.java:241)
at org.glassfish.kernel.javaee.WebContainerStarter.postConstruct(WebContainerStarter.java:180)
at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:264)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:306)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:433)
at org.glassfish.hk2.runlevel.internal.RunLevelContext.findOrCreate(RunLevelContext.java:119)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2099)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
at com.sun.enterprise.v3.server.AppServerStartup$StartupActivator.activate(AppServerStartup.java:516)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.activateRunLevel(RunLevelControllerImpl.java:820)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.upActiveRecorder(RunLevelControllerImpl.java:776)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.run(RunLevelControllerImpl.java:671)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$SyncProceedToWorker.proceedTo(RunLevelControllerImpl.java:938)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl.proceedTo(RunLevelControllerImpl.java:577)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl.proceedTo(RunLevelControllerImpl.java:351)
at com.sun.enterprise.v3.server.AppServerStartup.proceedTo(AppServerStartup.java:381)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:255)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:173)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:164)
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:55)

#]

[#|2013-02-21T19:00:42.483-0600|SEVERE|glassfish 4.0|javax.enterprise.web.core|_ThreadID=1;_ThreadName=main;_TimeMillis=1361494842483;_LevelValue=1000;|Container StandardEngine[glassfish-web].StandardHost[server].StandardContext[] has not been started
org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: com.sun.xml.ws.transport.http.servlet
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5913)
at com.sun.enterprise.web.WebModule.start(WebModule.java:696)
at org.apache.catalina.core.ContainerBase.startChildren(ContainerBase.java:1593)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1290)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:982)
at org.apache.catalina.core.ContainerBase.startChildren(ContainerBase.java:1593)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1290)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:402)
at org.apache.catalina.startup.Embedded.start(Embedded.java:993)
at com.sun.enterprise.web.WebContainer.postConstruct(WebContainer.java:867)
at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:264)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:306)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:433)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:87)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2099)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
at org.glassfish.internal.data.EngineInfo.getContainer(EngineInfo.java:86)
at org.glassfish.kernel.javaee.WebContainerStarter.startWebContainer(WebContainerStarter.java:241)
at org.glassfish.kernel.javaee.WebContainerStarter.postConstruct(WebContainerStarter.java:180)
at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:264)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:306)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:433)
at org.glassfish.hk2.runlevel.internal.RunLevelContext.findOrCreate(RunLevelContext.java:119)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2099)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
at com.sun.enterprise.v3.server.AppServerStartup$StartupActivator.activate(AppServerStartup.java:516)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.activateRunLevel(RunLevelControllerImpl.java:820)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.upActiveRecorder(RunLevelControllerImpl.java:776)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.run(RunLevelControllerImpl.java:671)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$SyncProceedToWorker.proceedTo(RunLevelControllerImpl.java:938)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl.proceedTo(RunLevelControllerImpl.java:577)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl.proceedTo(RunLevelControllerImpl.java:351)
at com.sun.enterprise.v3.server.AppServerStartup.proceedTo(AppServerStartup.java:381)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:255)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:173)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:164)
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:55)
Caused by: java.lang.IllegalArgumentException: com.sun.xml.ws.transport.http.servlet
at java.lang.ClassLoader.definePackage(ClassLoader.java:1601)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2190)
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1472)
at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1923)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1357)
at org.apache.felix.framework.BundleWiringImpl.searchDynamicImports(BundleWiringImpl.java:1598)
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1479)
at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1923)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1832)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:937)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl$4$1.run(OSGiModuleImpl.java:434)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl$4$1.run(OSGiModuleImpl.java:431)
at java.security.AccessController.doPrivileged(Native Method)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl$4.loadClass(OSGiModuleImpl.java:431)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:238)
at java.lang.ClassLoader.loadClass(ClassLoader.java:410)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1676)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1579)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:363)
at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
at org.glassfish.web.loader.ServletContainerInitializerUtil.getInterestList(ServletContainerInitializerUtil.java:193)
at org.apache.catalina.core.StandardContext.callServletContainerInitializers(StandardContext.java:5955)
at com.sun.enterprise.web.WebModule.callServletContainerInitializers(WebModule.java:779)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5888)
... 47 more

#]

[#|2013-02-21T19:00:42.486-0600|INFO|glassfish 4.0|javax.enterprise.system.core.ee|_ThreadID=1;_ThreadName=main;_TimeMillis=1361494842486;_LevelValue=800;_MessageID=AS-CORE-JAVAEE-0002;|Done with starting web container.|#]



 Comments   
Comment by Sanjeeb Sahoo [ 28/Feb/13 ]

Felix 4.2.0 leverages parallel class loading feature of JDK7, so may be it has something to do with it. Can you run tests with -verbose:class jvm option and attach the jvm log for a failure case?

Comment by Amy Roh [ 28/Feb/13 ]

I'm observing the same failure in web devtests (http://hudson-sca.us.oracle.com/job/webtier-dev-tests-bg/2323) so this is not an instance-only problem.

From Tom, "Here is the except from jvm.log that mentions the com.sun.xml.ws.transport.http.servlet package:

<writer thread='22275'/>
[Loaded com.sun.xml.ws.transport.http.servlet.JAXWSRIDeploymentProbeProvider from file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/webservices-osgi.jar]
[Loaded com.sun.xml.ws.api.Component from file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/webservices-osgi.jar]
[Loaded com.sun.xml.ws.api.server.BoundEndpoint from file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/webservices-osgi.jar]
<writer thread='5891'/>
[Loaded java.lang.Throwable$PrintStreamOrWriter from /Library/Java/JavaVirtualMachines/jdk1.7.0_11.jdk/Contents/Home/jre/lib/rt.jar]
[Loaded java.lang.Throwable$WrappedPrintWriter from /Library/Java/JavaVirtualMachines/jdk1.7.0_11.jdk/Contents/Home/jre/lib/rt.jar]
<writer thread='22275'/>
[Loaded com.sun.xml.ws.api.config.management.Reconfigurable from file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/webservices-osgi.jar]
[Loaded com.sun.xml.ws.api.server.Adapter from file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/webservices-osgi.jar]
[Loaded com.sun.xml.ws.transport.http.HttpAdapter from file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/webservices-osgi.jar]
[Loaded com.sun.xml.ws.transport.http.servlet.ServletAdapter from file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/webservices-osgi.jar]
<writer thread='5891'/>
[Loaded java.util.Objects from /Library/Java/JavaVirtualMachines/jdk1.7.0_11.jdk/Contents/Home/jre/lib/rt.jar]
<writer thread='22275'/>
[Loaded com.sun.xml.ws.transport.http.servlet.JAXWSRIServletProbeProvider from file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/webservices-osgi.jar]
<writer thread='5891'/>"

Comment by Amy Roh [ 28/Feb/13 ]

https://issues.apache.org/jira/browse/FELIX-3939

Comment by Amy Roh [ 28/Feb/13 ]

Caused by: java.lang.IllegalArgumentException: com.sun.xml.ws.transport.http.servlet
at java.lang.ClassLoader.definePackage(ClassLoader.java:1601)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2190)

The IAE is from ClassLoader.java:1601 and ClassLoader#getPackage("com.sun.xml.ws.transport.http.servlet") is not NULL.

ClassLoader#definePackage

1592 protected Package definePackage(String name, String specTitle,
1593 String specVersion, String specVendor,
1594 String implTitle, String implVersion,
1595 String implVendor, URL sealBase)
1596 throws IllegalArgumentException
1597 {
1598 synchronized (packages) {
1599 Package pkg = getPackage(name);
1600 if (pkg != null)

{ 1601 throw new IllegalArgumentException(name); 1602 }

1603 pkg = new Package(name, specTitle, specVersion, specVendor,
1604 implTitle, implVersion, implVendor,
1605 sealBase, this);
1606 packages.put(name, pkg);
1607 return pkg;
1608 }
1609 }

Comment by Amy Roh [ 04/Mar/13 ]

The new felix.jar with a patch for FELIX-3939 fixes the issue. Please close this bug when the new Felix is integrated into the trunk.

Comment by Tom Mueller [ 07/Mar/13 ]

Any update on when a new felix with the fix can be integrated? This is still causing periodic admin devtest failures (3 out of the last 23). Thanks.

Comment by Sanjeeb Sahoo [ 08/Mar/13 ]

I am working with Felix community and I expect a release to be out by early next week. So, I say we can see this bug fixed by late next week.

Comment by Tom Mueller [ 08/Mar/13 ]

Sahoo reported seeing the behavior caused by this bug in the appserver quicklook tests too.

Comment by Amy Roh [ 08/Mar/13 ]

FWIW, I am able to see the same behavior from deploying a simple single war file from time to time.

Comment by Sanjeeb Sahoo [ 14/Mar/13 ]

Integrated Felix 4.2.1 in svn #60459 to fix this issue.





[GLASSFISH-19699] ClassNotFoundException for JdbcResourceInjector when install-node is run Created: 20/Feb/13  Updated: 26/Mar/13  Resolved: 26/Mar/13

Status: Resolved
Project: glassfish
Component/s: distributed management
Affects Version/s: 4.0_b76_EE7MS5
Fix Version/s: 4.0_b81

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


 Description   

When the install-node command is run, the following exception is printed:

$ asadmin install-node x
MultiException stack 1 of 1
java.lang.ClassNotFoundException: org.glassfish.jdbc.config.JdbcResourceInjector
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at org.jvnet.hk2.internal.Utilities.loadClass(Utilities.java:464)
at org.jvnet.hk2.internal.ServiceLocatorImpl.loadClass(ServiceLocatorImpl.java:1618)
at org.jvnet.hk2.internal.ServiceLocatorImpl.reifyDescriptor(ServiceLocatorImpl.java:360)
at org.jvnet.hk2.internal.ServiceLocatorImpl.narrow(ServiceLocatorImpl.java:1678)
at org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetDescriptor(ServiceLocatorImpl.java:895)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getServiceHandle(ServiceLocatorImpl.java:1141)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getServiceHandle(ServiceLocatorImpl.java:1130)
at org.jvnet.hk2.config.DomDocument.getModelByElementName(DomDocument.java:156)
at org.jvnet.hk2.config.ConfigParser.handleElement(ConfigParser.java:164)
at org.jvnet.hk2.config.ConfigParser.handleElement(ConfigParser.java:231)
at org.jvnet.hk2.config.ConfigParser.handleElement(ConfigParser.java:238)
at org.jvnet.hk2.config.ConfigParser.handleElement(ConfigParser.java:190)
at org.jvnet.hk2.config.ConfigParser.parse(ConfigParser.java:100)
at org.jvnet.hk2.config.ConfigParser.parse(ConfigParser.java:130)
at org.jvnet.hk2.config.ConfigParser.parse(ConfigParser.java:116)
at org.jvnet.hk2.config.ConfigParser.parse(ConfigParser.java:112)
at com.sun.enterprise.admin.cli.cluster.NativeRemoteCommandsBase.checkIfNodeExistsForHost(NativeRemoteCommandsBase.java:340)
at com.sun.enterprise.admin.cli.cluster.InstallNodeBaseCommand.validate(InstallNodeBaseCommand.java:100)
at com.sun.enterprise.admin.cli.cluster.InstallNodeSshCommand.validate(InstallNodeSshCommand.java:95)
at com.sun.enterprise.admin.cli.CLICommand.execute(CLICommand.java:296)
at com.sun.enterprise.admin.cli.AdminMain.executeCommand(AdminMain.java:352)
at com.sun.enterprise.admin.cli.AdminMain.doMain(AdminMain.java:289)
at org.glassfish.admin.cli.AsadminMain.main(AsadminMain.java:54)

It doesn't matter what hostname is passed to the command (I used "x" in this case). If you pass in more arguments, you get even more exceptions. This doesn't seem to effect the operation of the command.



 Comments   
Comment by Tom Mueller [ 20/Feb/13 ]

This output appears to be coming from line 359 of NativeRemoteCommandsBase.java where it catches an exception while parsing the domain.xml. It seems odd that this class is parsing all of the domain.xml files from all of the domains in the default domains directory. If multiple domains are going to be checked, why check those in the default domains directory. What if there are other domains in other directories that are unknown to this command. It seems that this check is a halfhearted attempt to make sure that this node isn't already installed in some other domain. Since it doesn't check all domains, it doesn't seem worth doing.

I suspect that the reason for the exception is that the entire modules directory is not in the classpath for the local command, so it isn't able to access all classes that are needed to be able to parse a domain.xml file. The command would need to create a class loader based on the entire modules directory in order to parse the domain.xml file.

Comment by Byron Nevins [ 20/Feb/13 ]

Revision 43131 -

The problem is in InstallNodeBaseCommand.java
method == validate()

What it does

A check of the domains that just happen to be in the default domains dir is performed.

Line 340 -->
DomDocument doc = parser.parse(domainURL);

That line throws an Exception. A stacktrace is dumped (To scare the user?), the Exception is swallowed and totally ignored. It returns false, which then has no further effect.

Comment by Yamini K B [ 21/Feb/13 ]

There are 2 issues here:
1. Looking through the history of NativeRemoteCommandBase, there has been some changes related to HK2 which is causing the exception. The following change fixes that:

Index: src/main/java/com/sun/enterprise/admin/cli/cluster/NativeRemoteCommandsBase.java
===================================================================
— src/main/java/com/sun/enterprise/admin/cli/cluster/NativeRemoteCommandsBase.java (revision 59713)
+++ src/main/java/com/sun/enterprise/admin/cli/cluster/NativeRemoteCommandsBase.java (working copy)
@@ -65,6 +65,8 @@
import com.sun.enterprise.config.serverbeans.Domain;
import com.sun.enterprise.config.serverbeans.Nodes;
import com.sun.enterprise.config.serverbeans.Node;
+import com.sun.enterprise.module.ModulesRegistry;
+import com.sun.enterprise.module.single.StaticModulesRegistry;

import com.sun.enterprise.universal.glassfish.TokenResolver;
import com.sun.enterprise.util.io.DomainDirs;
@@ -327,14 +329,9 @@
}
);

  • ServiceLocator serviceLocator = ServiceLocatorFactory.getInstance().create("default");
  • try { - HK2Populator.populate(serviceLocator, new ClasspathDescriptorFileFinder(cl), null); - }

    catch (IOException e)

    { - logger.log(Level.SEVERE, "Error initializing HK2", e); - }
  • + ModulesRegistry registry = new StaticModulesRegistry(cl);
    + ServiceLocator serviceLocator = registry.createServiceLocator("default");
    +
    ConfigParser parser = new ConfigParser(serviceLocator);
    URL domainURL = domainXMLFile.toURI().toURL();
    DomDocument doc = parser.parse(domainURL);

2. The command should scan domains in user configured domains dir as well.

Comment by Tom Mueller [ 21/Feb/13 ]

WRT #2 in the previous comment, there is no way of knowing where the "user configured domains dirs" might be. They are not configured. Domains directories are only ever specified using a --domaindir option.

Other than list-domains, we don't have any command that looks at or does anything to more than one domain. And with list-domains, it only looks at the domains in the directory passed via the --domaindir option (or the default).

I strongly recommend that this "feature" of looking at multiple domains be removed from the install-node command.

Comment by Yamini K B [ 26/Mar/13 ]

Fix checked in r60828





[GLASSFISH-19594] Upgrade Derby to 10.9 Created: 28/Jan/13  Updated: 19/Mar/13  Resolved: 19/Mar/13

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

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


 Description   

Need to upgrade Derby in Java EE7 SDK to at least 10.9



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 19/Mar/13 ]

JavaDB 10.9.1.0 integrated into GlassFish workspace.





[GLASSFISH-19486] Glassfish 4 installer should detect and require JDK7. Created: 29/Dec/12  Updated: 19/Mar/13  Resolved: 19/Mar/13

Status: Resolved
Project: glassfish
Component/s: installation
Affects Version/s: 4.0_b69
Fix Version/s: 4.0_b81

Type: Improvement Priority: Critical
Reporter: Mohamed Taman Assignee: Snjezana Sevo-Zenzerovic
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 Professional SP1
Mac OS X v10.6.8


Tags: adoptajsr

 Description   

I have JDK6(Default) and JDK7 installed on the same machine (Windows and Mac), and when I have unzipped the glassfish_4_b69 and run it for the first time it reports the following exception

*"asadmin> start-domain domain1
Waiting for domain1 to start .............Error starting domain domain1.
The server exited prematurely with exit code 1.
Before it died, it produced the following output:
........
Caused by: A MultiException has 2 exceptions. They are:
1. java.lang.UnsupportedClassVersionError: org/glassfish/jdbc/config/JdbcResourceInjector : Unsupported major.minor version 51.0"
*

After investigation, It should run on JDK7 not JDK6, but the error is misleading somehow, it should be there some sort of detection for the exact version of proper supported JDK, and then reports a proper error message, something like "Unsupported JDK version, use JDK7 version."+

Also

The windows installer detects and show the jdk6 even I have JDK 7 installed without warnings, and when I pointed to JDK 7 it give me a warning message the there is no java home selected.



 Comments   
Comment by Tom Mueller [ 02/Jan/13 ]

The version checking in the startup logic has been changed to enforce JDK 7 in revision 57887 on the trunk.

Comment by Tom Mueller [ 02/Jan/13 ]

Reassigning this to the installation component so that the last part (under "Also") can be fixed. Specifically, the installer needs to detect only JDK 7 installs for GF 4. This fix is required for 4.0.

Comment by Snjezana Sevo-Zenzerovic [ 19/Mar/13 ]

JDK 7 specified as the lowest supported version in install wrapper and JDK selection screen.





[GLASSFISH-19258] Java EE 7 SDK Ease of Use Created: 29/Oct/12  Updated: 21/Mar/13  Resolved: 21/Mar/13

Status: Resolved
Project: glassfish
Component/s: sample_apps
Affects Version/s: 4.0_b60
Fix Version/s: 4.0_b81

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

Issue Links:
Related
is related to GLASSFISH-19256 Java EE 7 Samples Framework Resolved
is related to GLASSFISH-19438 Install summary screen should be impr... Open

 Description   

We have some requirements to improve out-of-the-box Java EE 7 SDK ease of use. Specifically:

  • The Java EE 6 SDK offers a lot of documentation - API documentation, First Cup, GlassFish QuickStart, and the Java EE samples. However, locating these can be difficult for a new Java EE developer. In addition, the about_sdk.html file gives information about what the SDK artifacts are, but offers no recommendation as to the steps the user should take to learn Java EE.
  • There should be an index.html file in the top-level SDK directory with details what the SDK offers. The about_sdk.html file currently fulfills this role, but should be moved to the top-level directory ($SDK_HOME/index.html) and renamed to index.html. In addition, this file should also be updated to recommend to the user the steps they should take to learn Java EE 7.
    • Apparently there are actually two such files, one for the Full Profile (about_sdk.html) and the other one for the Web Profile (about_sdk_web.html). Need to figure out how to handle this (index.html and index_web.html)?
  • The docs & samples directories should be based off the top-level SDK directory. They are currently "buried" under the glassfish sub-directory and difficult for the user to find. Users often run "ls" or "dir" to determine what's available. The default documentation that ships with GlassFish (quickstart.html, features.html, etc) can remain in the glassfish/docs subdirectory. Example:
    $SDK_HOME/docs 
    $SDK_HOME/samples 
    $SDK_HOME/glassfish 
    
  • The existing Java EE 6 SDK links to the Java EE 6 tutorial online. The Java EE 7 SDK will bundle the Java EE 7 Tutorial PDF file and also link to the online HTML tutorial.
  • First cup (and tutorial) should go under $SDK_HOME/docs


 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 21/Mar/13 ]

Marking issue as fixed since all integrated items are conforming to proposed file layout in upcoming Java EE SDK promoted build 81. First cup tutorial and Java EE tutorial which are pending integration will follow the suite.





[GLASSFISH-18746] [PERF] memory footprint has increased due to org.apache.felix.bundlerepository.jar Created: 21/May/12  Updated: 08/Apr/13  Resolved: 01/Apr/13

Status: Resolved
Project: glassfish
Component/s: OSGi
Affects Version/s: 4.0_b33
Fix Version/s: 4.0_b81

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

Issue Links:
Dependency
blocks GLASSFISH-18693 [PERF] regression in startup/deployme... Resolved
Duplicate
is duplicated by GLASSFISH-19168 [PERF] New call to Felix RepositoryAd... Resolved
Tags: PSRBUG, devx_web

 Description   

Addition of org.apache.felix.bundlerepository.jar file has increased footprint by 10 to 12 MB. Due to this startup/deployment benchmark has regressed further by 5% to 6%.



 Comments   
Comment by TangYong [ 31/Oct/12 ]

Hi sahoo,

I found that after starting Glassfish Domain, the status of org.apache.felix.bundlerepository bundle is Active,

202|Active | 1|Apache Felix Bundle Repository (1.6.6)

However, in my gf's osgi.properties, glassfish.osgi.ondemand=false. In theory, the status of org.apache.felix.bundlerepository bundle should be "Installed" rather than "Active". So, I doubted that there is something with wrong and I will see in depth.

Thanks.
Tang

Comment by TangYong [ 31/Oct/12 ]

I have known the reason: on osgi.properties,

obr.bundles=$

{com.sun.aas.installRootURI}

modules/org.apache.felix.bundlerepository.jar and obr.bundles is contained in $

{core.bundles}

. So, felix auto-started org.apache.felix.bundlerepository bundle.

Comment by TangYong [ 31/Oct/12 ]

Hi sahoo,

I think that gf's kernel should consider to start org.apache.felix.bundlerepository bundle according to "glassfish.osgi.ondemand = true" rather than putting org.apache.felix.bundlerepository into glassfish.osgi.auto.start.level.1.

Thanks.
Tang

Comment by Sanjeeb Sahoo [ 01/Nov/12 ]

We don't want to know about ondemand flag from gf code as the flag is introduced by hk2/osgi-adapter. So, either we change hk2/osgi-adapter to add obr bundle when the flag is present or we make the provisioning options more sophisticated such that we can do conditional provisioning. Although I prefer the later, we have to be very careful about performance impact. Anyway, this is not a priority issue for now and we will definitely address this in 4.0 release.

Comment by Scott Oaks [ 07/Nov/12 ]

It is a priority issue for us; it's hard to see what else has regressed (or figure out what else to improve) without addressing the largest culprit.

Could we add the flag for now and then decide about the conditional provisioning later?

Comment by Tom Mueller [ 15/Feb/13 ]

Sahoo, please respond to Scott's last question. Or, propose some alternative for this issue. Getting rid of the developer scenario benchmark regression is a release criteria for Java EE 7, so this is a high priority.
Thanks.

Comment by Tom Mueller [ 01/Apr/13 ]

Reopening this because there isn't any explanation provided for what was actually fixed. This module is still in the "resolved" state after a server start.

$ asadmin osgi lb -l | grep bundlerep
207|Resolved | 1|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/org.apache.felix.bundlerepository.jar

I ran a simple test where I removed the org.apache.felix.bundlerepository.jar file from the modules directory and run the developer scenario benchmark. The memory footprint reported by the test went down 10MB. Here are the results:

$ ./compare  -r logdir.devx_web_4.0_baseline_4_1/ logdir.devx_web_4.0
==============================================================================
logdir.devx_web_4.0_baseline_4_1/:
  Benchmark           Samples        Mean     Stdev             Geomean Weight
  devx_web                  2       12.30      0.17
    average_redeployN       2        0.87      0.03
    deployNaccess           2        4.56      0.00
    elapsed_time            2       12.30      0.17
    footprint               2   410900.00   7280.37
    server_startup          2        5.12      0.07
==============================================================================
logdir.devx_web_4.0:
  Benchmark           Samples        Mean     Stdev   %Diff     P  Significant
  devx_web                  2       12.05      0.05    2.01 0.263            *
    average_redeployN       2        0.84      0.00    4.29 0.335            *
    deployNaccess           2        4.38      0.06    3.99 0.141            *
    elapsed_time            2       12.05      0.05    2.01 0.263            *
    footprint               2   400708.00   2324.97    2.48 0.277            *
    server_startup          2        5.17      0.01   -0.92 0.529            *
==============================================================================

Note: the footprint number is reported in KB.

It isn't clear what is causing the org.apache.felix.bundlerepository to be resolved.

Comment by Sanjeeb Sahoo [ 01/Apr/13 ]

The bundle is resolved because hk2 osgi-adapter optionally depends on it. It's hard to believe just resolving the bundle causes an additional 10MB. It's a tiny bundle with not much dependency, so the impact of installing & resolving such a bundle is negligible. Your observation matches with mine if I don't cause the bundle to activate, so I configured the bundle to be not activated in svn #60460.

Given below are the numbers generated by my tests. These are purely generated by starting and stopping the server in a loop with a sleep in between. First number is elapsed time to start the server. The second number is resident memory size (rss) reported in KB:

TEST STARTED AT Mon Apr 1 22:47:51 IST 2013 - CLEAN_CACHE=NO - svn #61055 - no obr
0:05.28
122844
0:05.32
121940
0:05.22
122396
0:05.18
122540
0:05.15
122928

TEST STARTED AT Mon Apr 1 22:55:59 IST 2013 - CLEAN_CACHE=NO - svn #61055
0:05.21
123252
0:05.35
123228
0:05.15
123664
0:05.41
122260
0:05.20
122908

The numbers for web profile are also given below:

TEST STARTED AT Mon Apr 1 23:05:31 IST 2013 - CLEAN_CACHE=NO - svn #61055 - web profile
0:04.52
102392
0:04.61
102492
0:04.50
102148
0:04.49
102004
TEST STARTED AT Mon Apr 1 23:08:58 IST 2013 - CLEAN_CACHE=NO - svn #61055 - web profile - no obr
0:04.53
103176
0:04.65
103328
0:04.47
103520
0:04.45
102672

Before reopening, please have perf team compare between builds with svn #60459 and svn #60460.





[GLASSFISH-18334] REST endpoint for validate-dcom gives error. Created: 07/Feb/12  Updated: 19/Mar/13  Resolved: 19/Mar/13

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b22
Fix Version/s: 4.0_b81, 4.0

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


 Description   

I have changed the REST endpoint to management/domain/nodes/validate-dcom so it is the same as in 3.1.2 and how it should be.
Now i am seeing another problem.

Cannot find host in validate-dcom command model, file a bug injection failed on com.sun.enterprise.v3.admin.cluster.ValidateDcom.host with class java.lang.String
validate-dcom command output:

Cannot find host in validate-dcom command model, file a bug
injection failed on com.sun.enterprise.v3.admin.cluster.ValidateDcom.host with class java.lang.String

Exit Code: FAILURE



 Comments   
Comment by Byron Nevins [ 08/Feb/12 ]

Notice how you are calling POST but it is defined as GET

if ("#

{pageSession.valueMap['type']}

=DCOM"){
gfr.fixWinPswd();
//call validate-dcom first
if ("#

{pageSession.valueMap['validateDcom']}

"){
createMap(result="#

{pageSession.dMap}");
mapPut(map="#{pageSession.dMap}

", key="host" value="#

{pageSession.valueMap['nodehost']}

");
foreach(var="dattr" list=

{"windowsuser", "windowsdomain", "windowspassword" "remotetestdir" }

){
mapGet(Map="#

{pageSession.valueMap}

" Key="#

{requestScope.dattr}" Value="#{requestScope.dval}");
if ("#{requestScope.dval}"){
mapPut(map="#{pageSession.dMap}", key="#{requestScope.dattr}

" value="#

{requestScope.dval}

");
}
}
gf.restRequest( endpoint="#

{sessionScope.REST_URL}

/nodes/validate-dcom" attrs="#

{pageSession.dMap}

" method="POST" )
}

Comment by Anissa Lam [ 29/Jan/13 ]

change to admingui so i can look at it again.

Comment by Anissa Lam [ 12/Feb/13 ]

Fix by HCF (3/25)

Comment by Anissa Lam [ 12/Feb/13 ]

Issues need to be addressed before 4.0 HCF (3/25)

Comment by Anissa Lam [ 15/Feb/13 ]

move to 4.0.1 as clustering related feature will not be in 4.0 console.

Comment by Anissa Lam [ 14/Mar/13 ]

move back to 4.0 , try to fix this for 4.0

Comment by Anissa Lam [ 19/Mar/13 ]

With http://localhost:4848/management/domain/nodes/validate-dcom as the endpoint, and doing a GET solved the issue.

Console is able to show the user any error reported by the backend.





[GLASSFISH-17842] Deployment of not spec conform EJB succeeds / @PostConstruct Created: 29/Nov/11  Updated: 20/Mar/13  Resolved: 20/Mar/13

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1.1
Fix Version/s: 4.0_b81

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

Win 7, JDK 7


Attachments: File PostConstructTest.war     Java Source File PostConstructTestBean.java    
Tags: 3_1_2-exclude, deployment, spec

 Description   

According to Java EE 6 spec an EJB method with @PostConstruct MUST NOT throw a checked Exception.
http://docs.oracle.com/javaee/6/api/javax/annotation/PostConstruct.html

Deployment validation seems not to check this, as it is possible to deploy such an EJB without any warnings.
See example below.



 Comments   
Comment by marina vatkina [ 14/Dec/11 ]

This is a generic annotation

Comment by Hong Zhang [ 14/Dec/11 ]

ok, we will see what we can do from the deployment side in the next release.

Comment by Jeremy_Lv [ 03/Sep/12 ]

I'll look into this issue and try to check the validation about it.

Comment by Jeremy_Lv [ 05/Sep/12 ]

Hong:
I think the deployment validation about @PostConstruct and @PostDestroy haven't checked the specification documented by community.
We'd better add a validation method about checking it from the deployment side as the specification documented.

Comment by Hong Zhang [ 07/Sep/12 ]

Ok, you can look into where would be the best place to add this and how to add this. If this is a EJB specific check, probably the check should go into main/appserver/ejb/ejb-container/src/main/java/org/glassfish/ejb/deployment/util/EjbBundleValidator.java, if it's a validation applied to multiple areas, probably the check should be added to the base class validator main/appserver/deployment/dol/src/main/java/com/sun/enterprise/deployment/util/ComponentValidator.java

Comment by Hong Zhang [ 20/Mar/13 ]

Added validation logic to validate lifecycle methods annotated with @PostConstruct and @PreDestroy to conform to the EE spec.





Generated at Sun Feb 14 08:26:22 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.