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

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

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

RedHat Linux, Windows, Ubuntu Linux


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

 Description   

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

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

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

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



 Comments   
Comment by nabizamani [ 22/Jul/13 ]

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

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

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

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

Comment by Lukas Jungmann [ 01/Aug/13 ]

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

Comment by Lukas Jungmann [ 01/Aug/13 ]

assign as needed, please. thx.

Comment by replicant77 [ 09/Sep/13 ]

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

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

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

Comment by TangYong [ 10/Sep/13 ]

replicant77

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

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

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

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

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

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

So, I have uploaded a new attachment.

OK, current issue should be the following:

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

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

Comment by TangYong [ 10/Sep/13 ]

I made an initial investigation for the issue,

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

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

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

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

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

Thanks
Tang

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

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

Comment by pbelbin [ 09/Jan/14 ]

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

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

I do see the WEB9052 warnings.

but, after that, I also see this:

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

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

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





[GLASSFISH-18961] system property not resolving password alias Created: 30/Jul/12  Updated: 10/Aug/12  Resolved: 09/Aug/12

Status: Resolved
Project: glassfish
Component/s: configuration
Affects Version/s: 3.1.2_b23, 4.0
Fix Version/s: 4.0_b50_ms4

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

Windows 7 64 bit


Tags: 3_1-next

 Description   

system property defined to reference a password alias such as "$

{ALIAS=myPasswordAlias}"

property resolves to the literal value of "${ALIAS=myPasswordAlias}

" instead of the value of the alias (at least at a fresh start of the domain)

If the system property is deleted and created again the alias is properly resolved



 Comments   
Comment by Tom Mueller [ 07/Aug/12 ]

Confirmed on the trunk. There is an error message in the log file when this happens:

Aug 7, 2012 8:22:35 AM org.glassfish.config.support.TranslatedConfigView getTranslatedValue
SEVERE: Error in dealiasing the password $

{ALIAS=foo}

: password can't be null

This comes from line 89 of TranslatedConfigView.java in the nucleus/admin/config-api module. The "password" referred to in the error message is the master password.

The root cause of this is an ordering problem during startup between the SystemTasksImpl service and the IdmService service. The IdmService reads the master password file and sets the master password internally (which is needed to read the keystore that holds the alias values) and the SystemTasksImpl reads the system properties from the domain.xml and stores them in the environment within the JVM. If SystemTasksImpl is initialized before IdmService, then it cannot read the password aliases. Both IdmService and SystemTasksImpl are run at the "INIT" run-level, so there is no guarantee on the ordering between the services.

Comment by Tom Mueller [ 09/Aug/12 ]

Fixed on the trunk in revision 55379.

Comment by mjpatv [ 09/Aug/12 ]

Does this mean I will have to wait for a future release (version 4) for this fix?

Comment by Tom Mueller [ 10/Aug/12 ]

If you have licensed Oracle GlassFish Server and have a support contract, then this fix can be backported to a 3.x release in a patch. I've added the 3_1-next tag to this issue which marks it as a candidate for a future open source release based on the latest 3.x (if there is one). The other option is to checkout 3.x and backport the fix yourself.





[GLASSFISH-17158] CommandRunnerImple is not able to print the record which has ';' as part of message... Created: 08/Aug/11  Updated: 19/Oct/11  Resolved: 09/Aug/11

Status: Resolved
Project: glassfish
Component/s: command_line_interface
Affects Version/s: 3.1.1, 4.0
Fix Version/s: 3.1.2_b07, 4.0

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

Attachments: Java Source File TestCommand.java    
Issue Links:
Dependency
blocks GLASSFISH-16981 asadmin show-log Open
Tags: 3_1-next

 Description   

Planning to create command for show-log. But the CommandRunnerImpl is not able to print the log records as they have ; as part of name value pairs (_ThreadID=10;_ThreadName=Thread-2.

Attached the sample code for the same. It wouldn't able to print first record which has ; as part of the message.

1. Run attached code as it is, it won't print first record from logList.
2. Now remove ; from logList first record (line number 96). Compile and run again. It will work properly.

Second issue, it wouldn't allow me to format the records with srint.format(...) function.

1. Uncomment the code from line number 102. Call function 'logList = formatString(logList);'
2. Compile and run again. It will work. But it won't allow me to print "--------------" multiple times to separate the records.



 Comments   
Comment by naman_mehta [ 08/Aug/11 ]

Attached the sample java class to reproduce the same.

Comment by Tom Mueller [ 08/Aug/11 ]

The root cause of this problem is in PropsFileActionReporter.java at line 108 where a semicolon ( ; ) is used as a delimiter for the list of children, but there is no assurance that a semicolon isn't embedded in the child.getMessage() value.

Comment by Tom Mueller [ 08/Aug/11 ]

An easy way to reproduce this problem without a test program is the following:

asadmin create-system-properties "a=b;c"
asadmin list-system-properties

The output from the 2nd command will be missing the value of the property because the output message contains a ";".

Comment by Tom Mueller [ 09/Aug/11 ]

Fixed on the trunk in revision 48662.

This is a candidate for fixing in 3.1.2.

Comment by Tom Mueller [ 19/Oct/11 ]

Targeted for 3.1.2.





[GLASSFISH-17100] Cannot change or remove JVM Option -XX:MaxPermSize=192m Created: 25/Jul/11  Updated: 28/Nov/11  Resolved: 28/Nov/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.1_b12
Fix Version/s: 3.1.2_b11

Type: Bug Priority: Major
Reporter: justin.gronfur Assignee: srinik76
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

CentOS 5.5 x86_64 running in a ESXi virtual machine.


Tags: 3_1-next, 3_1_1-scrubbed

 Description   

In the JVM options, there is a default option of -XX:MaxPermSize=192m, however my particular set of applications requires a larger PermSize than 192m. When I increase this number or delete this option entirely and create a different one, it is automatically recreated upon Save. The only way I was able to remove the option was by editing my domain.xml file directly.



 Comments   
Comment by scatari [ 26/Jul/11 ]

Marking to be fixed in the patch release that follows 3.1.1. Does not affect primary functionality of the product.

Comment by srinik76 [ 26/Jul/11 ]

Downloaded v3.1.1 build 12.

Tried the following

In the console jvm options under sever-config, tried modifiying the jvm option -XX:MaxPermSize=199m and tried deleting and recreating it works fine.

Comment by srinik76 [ 26/Jul/11 ]

Please update which config you are trying.

Comment by Anissa Lam [ 26/Jul/11 ]

targeted for release after 3.1.1

Comment by justin.gronfur [ 26/Jul/11 ]

It was on a freshly created cluster config. I tried recreating the cluster from scratch a second time and the problem remained. Once I edited it out of the domain.xml manually it seems to be have as normal.

Of other interest, it was the first option listed in the config so I was wondering if that had something to do with it. That didn't seem to be the problem (although I didn't test that on a fresh cluster config as I had already manually edited domain.xml).

Comment by srinik76 [ 10/Oct/11 ]

Tried in my laptop ubuntu 10.04 LTS, tried creating a new config and modified the jvm option -XX:MaxPermSize
and it saves fine and also delete works fine.

Comment by justin.gronfur [ 12/Oct/11 ]

I played around with this a little bit more and figured out what is going on.
I'm using an automated cluster config tool that had an invalid configuration resulting in
duplicate -XX:MaxPermSize options. When both options are there, you cannot edit or delete the
default 192m option and attempting to delete the custom 384m option results in a "There is
already a -XX:MaxPermSize=192m option" message.

So this is primarily user error, but the jvm option config shouldn't fall over when presented
with duplicate options. In fact it should prevent them from happening in the first place.

Comment by srinik76 [ 28/Nov/11 ]

Tried with latest 3.1.2 build, not able to add any duplicate jvm option back end detects and removes it. So duplicate values does not get saved.





[GLASSFISH-17092] CORBA Warning message on glassfish shutdown Created: 22/Jul/11  Updated: 24/Dec/11  Resolved: 23/Dec/11

Status: Resolved
Project: glassfish
Component/s: orb
Affects Version/s: 3.1.2, 4.0
Fix Version/s: 3.1.2_b16, 4.0

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

Issue Links:
Dependency
blocks GLASSFISH-17852 HA IIOP Tests failed - ReferenceFacto... Resolved
Tags: 3_1-next, 3_1_1-scrubbed, 3_1_2-approved

 Description   

Server log shows the message "WARNING: IOP02310830: ReferenceFactoryManager destroy failed" when glassfish is shutdown.

Steps:
1. asadmin start-domain
2. deploy EJB app with remote interface
3. asadmin stop-domain
4. Check out server.log.

Note: The message is not printed if the app is undeployed before stopping the domain.

--------------- server.log --------------------------------
:
:
[#|2011-07-22T14:22:17.254-0700|INFO|glassfish3.1.1|javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin|_ThreadID=19;_Thre adName=Thread-39;|Server shutdown initiated|#]

[#|2011-07-22T14:22:17.282-0700|WARNING|glassfish3.1.1|javax.enterprise.resource.corba.POA|_ThreadID=19;_ThreadName=Thread-39;|IOP02310830: ReferenceFactoryManager destroy failed
org.omg.CORBA.OBJ_ADAPTER: WARNING: IOP02310830: ReferenceFactoryManager destroy failed vmcid: OMG minor code: 830 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy138.rfmDestroyFailed(Unknown Source)
at com.sun.corba.ee.impl.oa.rfm.ReferenceFactoryManagerImpl.destroy(ReferenceFactoryManagerImpl.java:575)
at com.sun.corba.ee.impl.oa.rfm.ReferenceFactoryImpl.destroy(ReferenceFactoryImpl.java:66)
at org.glassfish.enterprise.iiop.impl.POARemoteReferenceFactory.destroy(POARemoteReferenceFactory.java:555)
at com.sun.ejb.containers.BaseContainer.doContainerCleanup(BaseContainer.java:4333)
at com.sun.ejb.containers.BaseContainer.onShutdown(BaseContainer.java:4237)
at org.glassfish.ejb.startup.EjbApplication.stop(EjbApplication.java:307)
at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:169)
at org.glassfish.internal.data.ModuleInfo.stop(ModuleInfo.java:302)
at org.glassfish.internal.data.ApplicationInfo.stop(ApplicationInfo.java:322)
at com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:999)
at com.sun.enterprise.v3.server.ApplicationLifecycle.disable(ApplicationLifecycle.java:1971)
at com.sun.enterprise.v3.server.ApplicationLoaderService.stopApplication(ApplicationLoaderService.java:454)
at com.sun.enterprise.v3.server.ApplicationLoaderService.preDestroy(ApplicationLoaderService.java:422)
at com.sun.hk2.component.AbstractCreatorInhabitantImpl.dispose(AbstractCreatorInhabitantImpl.java:83)
at com.sun.hk2.component.SingletonInhabitant.release(SingletonInhabitant.java:81)
at com.sun.hk2.component.EventPublishingInhabitant.release(EventPublishingInhabitant.java:108)
at com.sun.hk2.component.LazyInhabitant.release(LazyInhabitant.java:133)
at com.sun.enterprise.v3.server.AppServerStartup.stop(AppServerStartup.java:425)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.stop(GlassFishImpl.java:88)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.stop(GlassFishDecorator.java:68)
at com.sun.enterprise.v3.admin.StopServer.doExecute(StopServer.java:70)
at com.sun.enterprise.v3.admin.StopDomainCommand.execute(StopDomainCommand.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.run(CommandRunnerImpl.java:383)
Caused by: java.lang.NullPointerException
at com.sun.corba.ee.impl.oa.poa.POAImpl.getPOAFactory(POAImpl.java:334)
at com.sun.corba.ee.impl.oa.poa.POAImpl.<init>(POAImpl.java:467)
at com.sun.corba.ee.impl.oa.poa.POAImpl.find_POA(POAImpl.java:1028)
at com.sun.corba.ee.impl.oa.rfm.ReferenceFactoryManagerImpl.destroy(ReferenceFactoryManagerImpl.java:557)
... 23 more

#]
-----------------------------------------------

This Warn message need not (should not ?) show up in the server log by default. To resolve - the log level need to be changed to FINE (or FINEST).



 Comments   
Comment by scatari [ 26/Jul/11 ]

No impact on shutdown, these are just warning messages that need to be cleaned up.

Comment by Harshad Vilekar [ 23/Dec/11 ]
  • What is the impact on the customer of the bug?
    Exception message logged in server log during shutdown.
  • How likely is it that a customer will see the bug and how serious is the bug?
    Shows up every time the server running remote EJB is shutdown.
  • Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
    Exists in 3.1.1 also.
  • What is the cost/risk of fixing the bug?
    Fix is ready.
  • How risky is the fix? How much work is the fix? Is the fix complicated?
    Low risk. Only affects shutdown operation.
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Tests that exercise Remote EJBs. Embedded GlassFish tests.
  • Which is the targeted build of 3.1.2 for this fix?
    B16.
Comment by Harshad Vilekar [ 24/Dec/11 ]

Trunk - Committed revision 51754.





[GLASSFISH-17087] In the AIX build, maven adds extra java classes in the osgi bundle for libpam4j artficat Created: 21/Jul/11  Updated: 02/Nov/11  Resolved: 02/Nov/11

Status: Closed
Project: glassfish
Component/s: build_system
Affects Version/s: 3.1.1
Fix Version/s: 9.0pe

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

AIX


Tags: 3_1-next, 3_1_1-scrubbed

 Description   

There are extra javac/rmic etc classes bundled in libpam4j-repackaged.jar on AIX.



 Comments   
Comment by scatari [ 26/Jul/11 ]

Marking to be fixed in the patch release that follows 3.1.1. Does not affect primary functionality of the product, has impact on product distribution size only on AIX platform.

Comment by janey [ 02/Nov/11 ]

fixed. libpam4j artifacts are not bundled in aixporting-repackaged.jar.





[GLASSFISH-17083] Invalid http_proxy value can cause DAS to fail to start and then fail to exit Created: 21/Jul/11  Updated: 13/Oct/11  Resolved: 29/Sep/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1.1_b11
Fix Version/s: 3.1.2, 4.0

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

Ubuntu 11.04, Java(TM) SE Runtime Environment (build 1.6.0_23-b05), GlassFish Server Open Source Edition 3.1.1-b11 (build 11).


Attachments: Text File server.log     File t.out     File t1.out    
Tags: 3_1-next, 3_1_1-scrubbed

 Description   

Some times when I try to start domain,the start-domain command fails and in the subsequent invocation it works.This is the output I see:

sreekanth@spidy:/space/Sreekanth/servers/glassfish3/glassfish$ asadmin start-domain domain1
Waiting for domain1 to start .......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
No response from the Domain Administration Server (domain1) after 600 seconds.
The command is either taking too long to complete or the server has failed.
Please see the server log files for command status.
Please start with the --verbose option in order to see early messages.
Command start-domain failed.

I did a jps and have 2 processes running:
sreekanth@spidy:/space/Sreekanth/workspace/RSP-BSP/metro-ws-i-tests~rsp-bsp$ jps
2990 admin-cli.jar
3068 ASMain
3468 Jps

I took out jstack for each one and I am attaching the output of jstack here to the bug report.

Then when I again say : asadmin start-domain , I see this:

sreekanth@spidy:/space/Sreekanth/servers/glassfish3/glassfish$ asadmin start-domain domain1
Waiting for domain1 to start ............................
Successfully started the domain : domain1
domain Location: /space/Sreekanth/servers/glassfish3/glassfish/domains/domain1
Log File: /space/Sreekanth/servers/glassfish3/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.



 Comments   
Comment by Tom Mueller [ 21/Jul/11 ]

Do you have the server.log file from when this happens?

t.out is from the ASMain (DAS) and t1.out is from admin-cli.jar (asadmin). The DAS appears
to either have never really got started, or it detected a failure and is trying to exit,
but it didn't exit successfully. The server.log would help to determine which case
this is.

Is this problem reliably reproducible?

Comment by Sreekanth [ 21/Jul/11 ]

Tom I have seen this problem couple of times.I still have the same instance of server but I restarted the domain and i have been running
some tests on it.I am attaching that server log if it helps you.Otherwise I will wait for next time for this to occur and then upload the server log.

Comment by Tom Mueller [ 21/Jul/11 ]

At the beginning of the server.log file, there are a couple of cases where the
DAS tried to startup and then failed to start and shutdown.

The following error message is appears there:

[#|2011-07-13T12:40:49.372+0530|SEVERE|glassfish3.1.1|com.sun.pkg.client.SystemInfo|_ThreadID=10;_ThreadName=Thread-2;|badproxy|#]

[#|2011-07-13T12:40:49.376+0530|SEVERE|glassfish3.1.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=10;_ThreadName=Thread-2;|java.net.MalformedURLException: Unknown protocol: webcache.sfbay.sun.com

This is probably due to having the "http_proxy" environment variable set just to webcache.sfbay.sun.com rather than http://webcache.sfbay.sun.com/.

Since the check for updates only happens periodically, this might explain why you see this happen and then it goes away.

There is a bug in that the DAS is not exiting when it encounters this error. This might be
related to GLASSFISH-16925 which also is a case of the DAS not exiting after it encounters an
error, but that issue is for a different error.

Comment by Sreekanth [ 21/Jul/11 ]

Since you no more need the server.log from my side now,what I will do is change the http_proxy to the "http://webcache.sfbay.sun.com" now and then see if the problem exists next time wwhen I start the domain.

Comment by Tom Mueller [ 26/Jul/11 ]

Updated summary to reflect the actual problem.

Comment by Sreekanth [ 03/Aug/11 ]

After setting the correct proxy, till now I never again observed this issue

Comment by Tom Mueller [ 29/Sep/11 ]

This is fixed on the trunk. The bad http_proxy value no longer causes the server to exit. There is just a SEVERE message printed to the log.

Comment by Tom Mueller [ 13/Oct/11 ]

This is fixed in 3.1.2 also.





[GLASSFISH-17046] Deployment with precompile of jsp of a portable J2EE 6 EAR on a cluster using admin interface doesn't work Created: 14/Jul/11  Updated: 21/Oct/11

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1, 3.1.1_b11
Fix Version/s: None

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

Windows XP
Java 1.6.0_24
J2EE 6.0 portable and distributable EAR application (no dependancy injection)
Note that the EAR has all referenced JARs on manifests as required for portable applications.


Attachments: Zip Archive CSIPortal-J2EE6.zip    
Tags: 3_1-next, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

By testing Glassfish 3.1 (b48) and Glassfish 3.1.1 (b11) I found that the deployment with precompile option doesn't work as expected.

I tried two different packaging:
1) providing utility JARs under EAR/lib
2) providing all utility JARs references on META-INF/MANIFEST.mf for all interested modules.
In both cases the deployment raises the following error that is asserting the JSP cannot resolve many class libraries that are actually visible and correctly packaged in the EAR.

The same packaged EARs are correctly deployed with Netbeans 7.0 in a GF 3.1 (developer profile)

ERROR RAISED:
Error occurred during deployment: Exception while preparing the app : JSP Compilation Error: org.apache.jasper.JasperException: PWC6033: Error in Javac compilation for JSP PWC6199: Generated servlet error: string:///download_jsp.java:8: package com.portal.util does not exist PWC6199: Generated servlet error: string:///download_jsp.java:9: package com.portal.util does not exist PWC6199: Generated servlet error: string:///download_jsp.java:12: package com.contshipitalia.broker does not exist PWC6199: Generated servlet error: string:///download_jsp.java:13: package com.contshipitalia.persistence does not exist PWC6199: Generated servlet error: string:///download_jsp.java:14: package com.contshipitalia.persistence does not exist PWC6199: Generated servlet error: string:///download_jsp.java:15: package com.contshipitalia.util does not exist PWC6199: Generated servlet error: string:///download_jsp.java:16: package com.contshipitalia.net does not exist PWC6197: An error occurred at li .... msg.seeServerLog

Using GF 3.1.1 errors are thousand and I do not list them here but I just can say the deployment is completely corrupted in this version using the admin GUI.
I had no time to test the asadmin command-line yet.

Using GF 3.1 I tried a deployement always using the asadmin GUI but without precompile option and I found that the EAR is deployed with no errors apparently.
Anyway the Application it doesn't work as I obtain always HTTP 404 when a jsp or servlet is requested.
The 404 is raised because pages are searched in the docroot location which is empty after deployment:

[#|2011-07-14T10:53:34.500+0200|SEVERE|glassfish3.1|org.apache.jasper.servlet.JspServlet|_ThreadID=23;_ThreadName=Thread-1;|PWC6117: File "D%3A%5Cglassfish3%5Cglassfish%5Cnodes%5Clocalhost-domain1%5Cinstance1%5Cdocroot%5Cnews%5Clatest_news.jsp" not found|#]

By inspecting the GF directories I found that under /domain1/applications/... the EAR has been deployed, and docroot is empty.
A request to a jsp or servlet do not trigger its compilation bacause it is not resolved under /docroot.

It is not clear the role of /docroot that should be optional (see when static pages in the root are installed on a web server)



 Comments   
Comment by cistox [ 14/Jul/11 ]

Please read

Glassfish 3.1 (b48)

as

Glassfish 3.1 (b43)

Comment by Anissa Lam [ 14/Jul/11 ]

>> I had no time to test the asadmin command-line yet.
It will be nice if you can try this using CLI.
It is just one single command:
%asadmin deploy --precompilejsp=true myApplication.war

If you can attach the application, that will definitely help too.

I have double checked that when user checks the "Precompile JSP" checkbox, console passes in "precompilejsp" as "true".
I am going to assign to "deployment" for evaluation.

Comment by cistox [ 15/Jul/11 ]

I tried the deployment using the command-line.

I provided the EAR separately as attachment.

These are the details:

D:\glassfish3\bin>asadmin deploy --precompilejsp=true --target CSIPortal-cluster
CSIPortal-J2EE6.ear
remote failure: Unknown plain text format. A properly formatted response from a
PlainTextActionReporter
always starts with one of these 2 strings: PlainTextActionReporterSUCCESS or Pla
inTextActionReporterFAILURE. The response we received from the server was not u
nderstood: Signature-Version: 1.0
message: Error occurred during deployment: Exception while preparing t
he app : JSP Compilation Error: org.apache.jasper.JasperException: PW
C6033: Error in Javac compilation for JSP

PWC6199: G
enerated servlet error:
string:///download_jsp.java:8: packag
e com.portal.util does not exist

PWC6199: Generated
servlet error:
string:///download_jsp.java:9: package com.por
tal.util does not exist

PWC6199: Generated servlet e
rror:
string:///download_jsp.java:12: package com.contshipita
lia.broker does not exist

PWC6199: Generated servlet
error:
string:///download_jsp.java:13: package com.contshipi
talia.persistence does not exist

PWC6199: Generated
servlet error:
string:///download_jsp.java:14: package com.co
ntshipitalia.persistence does not exist

PWC6199: Gen
erated servlet error:
string:///download_jsp.java:15: package
com.contshipitalia.util does not exist

PWC6199: Gen
erated servlet error:
string:///download_jsp.java:16: package
com.contshipitalia.net does not exist

PWC6197: An e
rror occurred at line: 13 in the jsp file: /resources/download.jsp%%%
EOL%%%PWC6199: Generated servlet error:
string:///download_js
p.java:21: cannot find symbol
symbol : class GenericServiceB
roker
location: class org.apache.jsp.resources.download_jsp%%
%EOL%%%
PWC6197: An error occurred at line: 13 in the jsp fil
e: /resources/download.jsp
PWC6199: Generated servlet error:%
%%EOL%%%string:///download_jsp.java:21: cannot find symbol
sy
mbol : class GenericServiceBroker
location: class org.apache
.jsp.resources.download_jsp

PWC6197: An error occurr
ed at line: 13 in the jsp file: /resources/download.jsp
PWC61
99: Generated servlet error:
string:///download_jsp.java:58:
package com.contshipitalia.net does not exist

PWC619
7: An error occurred at line: 13 in the jsp file: /resources/download
.jsp
PWC6199: Generated servlet error:
string:///down
load_jsp.java:60: package com.contshipitalia.net does not exist%%%EOL
%%%
PWC6197: An error occurred at line: 13 in the jsp file: /
resources/download.jsp
PWC6199: Generated servlet error:%%%EO
L%%%string:///download_jsp.java:63: package com.contshipitalia.net do
es not exist

PWC6197: An error occurred at line: 14
in the jsp file: /resources/download.jsp
PWC6199: Generated s
ervlet error:
string:///download_jsp.java:76: cannot find sym
bol
symbol : variable Form
location: class org.apach
e.jsp.resources.download_jsp

PWC6197: An error occur
red at line: 14 in the jsp file: /resources/download.jsp
PWC6
199: Generated servlet error:
string:///download_jsp.java:89:
cannot find symbol
symbol : class Download
location
: class org.apache.jsp.resources.download_jsp

PWC619
7: An error occurred at line: 14 in the jsp file: /resources/download
.jsp
PWC6199: Generated servlet error:
string:///down
load_jsp.java:95: cannot find symbol
symbol : variable Form%
%%EOL%%%location: class org.apache.jsp.resources.download_jsp%%%EOL%%
%
PWC6197: An error occurred at line: 14 in the jsp file: /re
sources/download.jsp
PWC6199: Generated servlet error:%%%EOL%
%%string:///download_jsp.java:101: cannot find symbol
symbol
: variable Environment
location: class org.apache.jsp.resour
ces.download_jsp

PWC6197: An error occurred at line:
14 in the jsp file: /resources/download.jsp
PWC6199: Generat
ed servlet error:
string:///download_jsp.java:109: cannot fin
d symbol
symbol : class GenericData
location: class
org.apache.jsp.resources.download_jsp

PWC6197: An er
ror occurred at line: 14 in the jsp file: /resources/download.jsp%%%E
OL%%%PWC6199: Generated servlet error:
string:///download_jsp
.java:136: cannot find symbol
symbol : class Download%%%EOL%
%%location: class org.apache.jsp.resources.download_jsp
%%%EO
L%%%PWC6197: An error occurred at line: 14 in the jsp file: /resource
s/download.jsp
PWC6199: Generated servlet error:
stri
ng:///download_jsp.java:165: cannot find symbol
symbol : cla
ss Download
location: class org.apache.jsp.resources.download
_jsp

PWC6197: An error occurred at line: 14 in the j
sp file: /resources/download.jsp
PWC6199: Generated servlet e
rror:
string:///download_jsp.java:167: cannot find symbol%%%E
OL%%%symbol : class Download
location: class org.apache.jsp.
resources.download_jsp

PWC6197: An error occurred at
line: 14 in the jsp file: /resources/download.jsp
PWC6199: G
enerated servlet error:
string:///download_jsp.java:184: cann
ot find symbol
symbol : class Download
location: cla
ss org.apache.jsp.resources.download_jsp

PWC6197: An
error occurred at line: 14 in the jsp file: /resources/download.jsp%
%%EOL%%%PWC6199: Generated servlet error:
string:///download_
jsp.java:205: cannot find symbol
symbol : class Download%%%E
OL%%%location: class org.apache.jsp.resources.download_jsp
%%
%EOL%%%PWC6197: An error occurred at line: 14 in the jsp file: /resou
rces/download.jsp
PWC6199: Generated servlet error:
s
tring:///download_jsp.java:218: cannot find symbol
symbol :
class StringInputStream
location: class org.apache.jsp.resour
ces.download_jsp

PWC6197: An error occurred at line:
14 in the jsp file: /resources/download.jsp
PWC6199: Generat
ed servlet error:
string:///download_jsp.java:243: cannot fin
d symbol
symbol : variable JMail
location: class org
.apache.jsp.resources.download_jsp

PWC6197: An error
occurred at line: 14 in the jsp file: /resources/download.jsp%%%EOL%
%%PWC6199: Generated servlet error:
string:///download_jsp.ja
va:247: cannot find symbol
symbol : variable JMail
l
ocation: class org.apache.jsp.resources.download_jsp
%%%EOL%%
% – PWC6033: Error in Javac compilation for JSP

PWC
6199: Generated servlet error:
string:///download_jsp.java:8:
package com.portal.util does not exist

PWC6199: Gen
erated servlet error:
string:///download_jsp.java:9: package
com.portal.util does not exist

PWC6199: Generated se
rvlet error:
string:///download_jsp.java:12: package com.cont
shipitalia.broker does not exist

PWC6199: Generated
servlet error:
string:///download_jsp.java:13: package com.co
ntshipitalia.persistence does not exist

PWC6199: Gen
erated servlet error:
string:///download_jsp.java:14: package
com.contshipitalia.persistence does not exist

PWC61
99: Generated servlet error:
string:///download_jsp.java:15:
package com.contshipitalia.util does not exist

PWC61
99: Generated servlet error:
string:///download_jsp.java:16:
package com.contshipitalia.net does not exist

PWC619
7: An error occurred at line: 13 in the jsp file: /resources/download
.jsp
PWC6199: Generated servlet error:
string:///down
load_jsp.java:21: cannot find symbol
symbol : class GenericS
erviceBroker
location: class org.apache.jsp.resources.downloa
d_jsp

PWC6197: An error occurred at line: 13 in the
jsp file: /resources/download.jsp
PWC6199: Generated servlet
error:
string:///download_jsp.java:21: cannot find symbol%%%E
OL%%%symbol : class GenericServiceBroker
location: class org
.apache.jsp.resources.download_jsp

PWC6197: An error
occurred at line: 13 in the jsp file: /resources/download.jsp%%%EOL%
%%PWC6199: Generated servlet error:
string:///download_jsp.ja
va:58: package com.contshipitalia.net does not exist
%%%EOL%%
%PWC6197: An error occurred at line: 13 in the jsp file: /resources/d
ownload.jsp
PWC6199: Generated servlet error:
string:
///download_jsp.java:60: package com.contshipitalia.net does not exis
t

PWC6197: An error occurred at line: 13 in the jsp
file: /resources/download.jsp
PWC6199: Generated servlet erro
r:
string:///download_jsp.java:63: package com.contshipitalia
.net does not exist

PWC6197: An error occurred at li
ne: 14 in the jsp file: /resources/download.jsp
PWC6199: Gene
rated servlet error:
string:///download_jsp.java:76: cannot f
ind symbol
symbol : variable Form
location: class or
g.apache.jsp.resources.download_jsp

PWC6197: An erro
r occurred at line: 14 in the jsp file: /resources/download.jsp%%%EOL
%%%PWC6199: Generated servlet error:
string:///download_jsp.j
ava:89: cannot find symbol
symbol : class Download
l
ocation: class org.apache.jsp.resources.download_jsp
%%%EOL%%
%PWC6197: An error occurred at line: 14 in the jsp file: /resources/d
ownload.jsp
PWC6199: Generated servlet error:
string:
///download_jsp.java:95: cannot find symbol
symbol : variabl
e Form
location: class org.apache.jsp.resources.download_jsp%
%%EOL%%%
PWC6197: An error occurred at line: 14 in the jsp fi
le: /resources/download.jsp
PWC6199: Generated servlet error:

string:///download_jsp.java:101: cannot find symbol

symbol : variable Environment
location: class org.apache.jsp
.resources.download_jsp

PWC6197: An error occurred a
t line: 14 in the jsp file: /resources/download.jsp
PWC6199:
Generated servlet error:
string:///download_jsp.java:109: can
not find symbol
symbol : class GenericData
location:
class org.apache.jsp.resources.download_jsp

PWC6197
: An error occurred at line: 14 in the jsp file: /resources/download.
jsp
PWC6199: Generated servlet error:
string:///downl
oad_jsp.java:136: cannot find symbol
symbol : class Download

location: class org.apache.jsp.resources.download_jsp%%%EOL%
%%
PWC6197: An error occurred at line: 14 in the jsp file: /r
esources/download.jsp
PWC6199: Generated servlet error:%%%EOL
%%%string:///download_jsp.java:165: cannot find symbol
symbol
: class Download
location: class org.apache.jsp.resources.d
ownload_jsp

PWC6197: An error occurred at line: 14 i
n the jsp file: /resources/download.jsp
PWC6199: Generated se
rvlet error:
string:///download_jsp.java:167: cannot find sym
bol
symbol : class Download
location: class org.apac
he.jsp.resources.download_jsp

PWC6197: An error occu
rred at line: 14 in the jsp file: /resources/download.jsp
PWC
6199: Generated servlet error:
string:///download_jsp.java:18
4: cannot find symbol
symbol : class Download
locati
on: class org.apache.jsp.resources.download_jsp

PWC6
197: An error occurred at line: 14 in the jsp file: /resources/downlo
ad.jsp
PWC6199: Generated servlet error:
string:///do
wnload_jsp.java:205: cannot find symbol
symbol : class Downl
oad
location: class org.apache.jsp.resources.download_jsp%%%E
OL%%%
PWC6197: An error occurred at line: 14 in the jsp file:
/resources/download.jsp
PWC6199: Generated servlet error:%%%
EOL%%%string:///download_jsp.java:218: cannot find symbol
sym
bol : class StringInputStream
location: class org.apache.jsp
.resources.download_jsp

PWC6197: An error occurred a
t line: 14 in the jsp file: /resources/download.jsp
PWC6199:
Generated servlet error:
string:///download_jsp.java:243: can
not find symbol
symbol : variable JMail
location: cl
ass org.apache.jsp.resources.download_jsp

PWC6197: A
n error occurred at line: 14 in the jsp file: /resources/download.jsp

PWC6199: Generated servlet error:
string:///download
_jsp.java:247: cannot find symbol
symbol : variable JMail%%%
EOL%%%location: class org.apache.jsp.resources.download_jsp
%
%%EOL%%%. Please see server.log for more details.
Exception w
hile invoking class com.sun.enterprise.web.WebDeployer prepare method
: java.lang.RuntimeException: JSP Compilation Error: org.apache.jasp
er.JasperException: PWC6033: Error in Javac compilation for JSP%%%EOL
%%%
PWC6199: Generated servlet error:
string:///downl
oad_jsp.java:8: package com.portal.util does not exist
%%%EOL
%%%PWC6199: Generated servlet error:
string:///download_jsp.j
ava:9: package com.portal.util does not exist

PWC619
9: Generated servlet error:
string:///download_jsp.java:12: p
ackage com.contshipitalia.broker does not exist

PWC6
199: Generated servlet error:
string:///download_jsp.java:13:
package com.contshipitalia.persistence does not exist
%%%EOL
%%%PWC6199: Generated servlet error:
string:///download_jsp.j
ava:14: package com.contshipitalia.persistence does not exist%%%EOL%%
%
PWC6199: Generated servlet error:
string:///downloa
d_jsp.java:15: package com.contshipitalia.util does not exist%%%EOL%%
%
PWC6199: Generated servlet error:
string:///downloa
d_jsp.java:16: package com.contshipitalia.net does not exist

PWC6197: An error occurred at line: 13 in the jsp file: /res
ources/download.jsp
PWC6199: Generated servlet error:%%%EOL%%
%string:///download_jsp.java:21: cannot find symbol
symbol :
class GenericServiceBroker
location: class org.apache.jsp.re
sources.download_jsp

PWC6197: An error occurred at l
ine: 13 in the jsp file: /resources/download.jsp
PWC6199: Gen
erated servlet error:
string:///download_jsp.java:21: cannot
find symbol
symbol : class GenericServiceBroker
loca
tion: class org.apache.jsp.resources.download_jsp

PW
C6197: An error occurred at line: 13 in the jsp file: /resources/down
load.jsp
PWC6199: Generated servlet error:
string:///
download_jsp.java:58: package com.contshipitalia.net does not exist%%
%EOL%%%
PWC6197: An error occurred at line: 13 in the jsp fil
e: /resources/download.jsp
PWC6199: Generated servlet error:%
%%EOL%%%string:///download_jsp.java:60: package com.contshipitalia.ne
t does not exist

PWC6197: An error occurred at line:
13 in the jsp file: /resources/download.jsp
PWC6199: Generat
ed servlet error:
string:///download_jsp.java:63: package com
.contshipitalia.net does not exist

PWC6197: An error
occurred at line: 14 in the jsp file: /resources/download.jsp%%%EOL%
%%PWC6199: Generated servlet error:
string:///download_jsp.ja
va:76: cannot find symbol
symbol : variable Form
loc
ation: class org.apache.jsp.resources.download_jsp

P
WC6197: An error occurred at line: 14 in the jsp file: /resources/dow
nload.jsp
PWC6199: Generated servlet error:
string://
/download_jsp.java:89: cannot find symbol
symbol : class Dow
nload
location: class org.apache.jsp.resources.download_jsp%%
%EOL%%%
PWC6197: An error occurred at line: 14 in the jsp fil
e: /resources/download.jsp
PWC6199: Generated servlet error:%
%%EOL%%%string:///download_jsp.java:95: cannot find symbol
sy
mbol : variable Form
location: class org.apache.jsp.resource
s.download_jsp

PWC6197: An error occurred at line: 1
4 in the jsp file: /resources/download.jsp
PWC6199: Generated
servlet error:
string:///download_jsp.java:101: cannot find
symbol
symbol : variable Environment
location: class
org.apache.jsp.resources.download_jsp

PWC6197: An e
rror occurred at line: 14 in the jsp file: /resources/download.jsp%%%
EOL%%%PWC6199: Generated servlet error:
string:///download_js
p.java:109: cannot find symbol
symbol : class GenericData%%%
EOL%%%location: class org.apache.jsp.resources.download_jsp
%
%%EOL%%%PWC6197: An error occurred at line: 14 in the jsp file: /reso
urces/download.jsp
PWC6199: Generated servlet error:

string:///download_jsp.java:136: cannot find symbol
symbol :
class Download
location: class org.apache.jsp.resources.down
load_jsp

PWC6197: An error occurred at line: 14 in t
he jsp file: /resources/download.jsp
PWC6199: Generated servl
et error:
string:///download_jsp.java:165: cannot find symbol

symbol : class Download
location: class org.apache.
jsp.resources.download_jsp

PWC6197: An error occurre
d at line: 14 in the jsp file: /resources/download.jsp
PWC619
9: Generated servlet error:
string:///download_jsp.java:167:
cannot find symbol
symbol : class Download
location:
class org.apache.jsp.resources.download_jsp

PWC6197
: An error occurred at line: 14 in the jsp file: /resources/download.
jsp
PWC6199: Generated servlet error:
string:///downl
oad_jsp.java:184: cannot find symbol
symbol : class Download

location: class org.apache.jsp.resources.download_jsp%%%EOL%
%%
PWC6197: An error occurred at line: 14 in the jsp file: /r
esources/download.jsp
PWC6199: Generated servlet error:%%%EOL
%%%string:///download_jsp.java:205: cannot find symbol
symbol
: class Download
location: class org.apache.jsp.resources.d
ownload_jsp

PWC6197: An error occurred at line: 14 i
n the jsp file: /resources/download.jsp
PWC6199: Generated se
rvlet error:
string:///download_jsp.java:218: cannot find sym
bol
symbol : class StringInputStream
location: class
org.apache.jsp.resources.download_jsp

PWC6197: An e
rror occurred at line: 14 in the jsp file: /resources/download.jsp%%%
EOL%%%PWC6199: Generated servlet error:
string:///download_js
p.java:243: cannot find symbol
symbol : variable JMail%%%EOL
%%%location: class org.apache.jsp.resources.download_jsp
%%%E
OL%%%PWC6197: An error occurred at line: 14 in the jsp file: /resourc
es/download.jsp
PWC6199: Generated servlet error:
str
ing:///download_jsp.java:247: cannot find symbol
symbol : va
riable JMail
location: class org.apache.jsp.resources.downloa
d_jsp

– PWC6033: Error in Javac compilation for JS
P

PWC6199: Generated servlet error:
string:/
//download_jsp.java:8: package com.portal.util does not exist%%%EOL%%
%
PWC6199: Generated servlet error:
string:///downloa
d_jsp.java:9: package com.portal.util does not exist
%%%EOL%%
%PWC6199: Generated servlet error:
string:///download_jsp.jav
a:12: package com.contshipitalia.broker does not exist
%%%EOL
%%%PWC6199: Generated servlet error:
string:///download_jsp.j
ava:13: package com.contshipitalia.persistence does not exist%%%EOL%%
%
PWC6199: Generated servlet error:
string:///downloa
d_jsp.java:14: package com.contshipitalia.persistence does not exist%
%%EOL%%%
PWC6199: Generated servlet error:
string:///
download_jsp.java:15: package com.contshipitalia.util does not exist%
%%EOL%%%
PWC6199: Generated servlet error:
string:///
download_jsp.java:16: package com.contshipitalia.net does not exist%%
%EOL%%%
PWC6197: An error occurred at line: 13 in the jsp fil
e: /resources/download.jsp
PWC6199: Generated servlet error:%
%%EOL%%%string:///download_jsp.java:21: cannot find symbol
sy
mbol : class GenericServiceBroker
location: class org.apache
.jsp.resources.download_jsp

PWC6197: An error occurr
ed at line: 13 in the jsp file: /resources/download.jsp
PWC61
99: Generated servlet error:
string:///download_jsp.java:21:
cannot find symbol
symbol : class GenericServiceBroker%%%EOL
%%%location: class org.apache.jsp.resources.download_jsp
%%%E
OL%%%PWC6197: An error occurred at line: 13 in the jsp file: /resourc
es/download.jsp
PWC6199: Generated servlet error:
str
ing:///download_jsp.java:58: package com.contshipitalia.net does not
exist

PWC6197: An error occurred at line: 13 in the
jsp file: /resources/download.jsp
PWC6199: Generated servlet
error:
string:///download_jsp.java:60: package com.contshipit
alia.net does not exist

PWC6197: An error occurred a
t line: 13 in the jsp file: /resources/download.jsp
PWC6199:
Generated servlet error:
string:///download_jsp.java:63: pack
age com.contshipitalia.net does not exist

PWC6197: A
n error occurred at line: 14 in the jsp file: /resources/download.jsp

PWC6199: Generated servlet error:
string:///download
_jsp.java:76: cannot find symbol
symbol : variable Form%%%EO
L%%%location: class org.apache.jsp.resources.download_jsp
%%%
EOL%%%PWC6197: An error occurred at line: 14 in the jsp file: /resour
ces/download.jsp
PWC6199: Generated servlet error:
st
ring:///download_jsp.java:89: cannot find symbol
symbol : cl
ass Download
location: class org.apache.jsp.resources.downloa
d_jsp

PWC6197: An error occurred at line: 14 in the
jsp file: /resources/download.jsp
PWC6199: Generated servlet
error:
string:///download_jsp.java:95: cannot find symbol%%%E
OL%%%symbol : variable Form
location: class org.apache.jsp.r
esources.download_jsp

PWC6197: An error occurred at
line: 14 in the jsp file: /resources/download.jsp
PWC6199: Ge
nerated servlet error:
string:///download_jsp.java:101: canno
t find symbol
symbol : variable Environment
location
: class org.apache.jsp.resources.download_jsp

PWC619
7: An error occurred at line: 14 in the jsp file: /resources/download
.jsp
PWC6199: Generated servlet error:
string:///down
load_jsp.java:109: cannot find symbol
symbol : class Generic
Data
location: class org.apache.jsp.resources.download_jsp%%%
EOL%%%
PWC6197: An error occurred at line: 14 in the jsp file
: /resources/download.jsp
PWC6199: Generated servlet error:%%
%EOL%%%string:///download_jsp.java:136: cannot find symbol
sy
mbol : class Download
location: class org.apache.jsp.resourc
es.download_jsp

PWC6197: An error occurred at line:
14 in the jsp file: /resources/download.jsp
PWC6199: Generate
d servlet error:
string:///download_jsp.java:165: cannot find
symbol
symbol : class Download
location: class org.
apache.jsp.resources.download_jsp

PWC6197: An error
occurred at line: 14 in the jsp file: /resources/download.jsp%%%EOL%%
%PWC6199: Generated servlet error:
string:///download_jsp.jav
a:167: cannot find symbol
symbol : class Download
lo
cation: class org.apache.jsp.resources.download_jsp

PWC6197: An error occurred at line: 14 in the jsp file: /resources/do
wnload.jsp
PWC6199: Generated servlet error:
string:/
//download_jsp.java:184: cannot find symbol
symbol : class D
ownload
location: class org.apache.jsp.resources.download_jsp

PWC6197: An error occurred at line: 14 in the jsp f
ile: /resources/download.jsp
PWC6199: Generated servlet error
:
string:///download_jsp.java:205: cannot find symbol%%%EOL%%
%symbol : class Download
location: class org.apache.jsp.reso
urces.download_jsp

PWC6197: An error occurred at lin
e: 14 in the jsp file: /resources/download.jsp
PWC6199: Gener
ated servlet error:
string:///download_jsp.java:218: cannot f
ind symbol
symbol : class StringInputStream
location
: class org.apache.jsp.resources.download_jsp

PWC619
7: An error occurred at line: 14 in the jsp file: /resources/download
.jsp
PWC6199: Generated servlet error:
string:///down
load_jsp.java:243: cannot find symbol
symbol : variable JMai
l
location: class org.apache.jsp.resources.download_jsp%%%EOL
%%%
PWC6197: An error occurred at line: 14 in the jsp file: /
resources/download.jsp
PWC6199: Generated servlet error:%%%EO
L%%%string:///download_jsp.java:247: cannot find symbol
symbo
l : variable JMail
location: class org.apache.jsp.resources.
download_jsp

JSP Compilation Error: org.apa
che.jasper.JasperException: PWC6033: Error in Javac compilation for J
SP

PWC6199: Generated servlet error:
string:///download_jsp.java:8:
package com.portal.util does not exist

PWC6199: Generated servlet er
ror:
string:///download_jsp.java:9: package com.portal.util does not
exist

PWC6199: Generated servlet error:
string:///download_jsp.java:
12: package com.contshipitalia.broker does not exist

PWC6199: Genera
ted servlet error:
string:///download_jsp.java:13: package com.contsh
ipitalia.persistence does not exist

PWC6199: Generated servlet error
:
string:///download_jsp.java:14: package com.contshipitalia.persiste
nce does not exist

PWC6199: Generated servlet error:
string:///downl
oad_jsp.java:15: package com.contshipitalia.util does not exist

PWC6
199: Generated servlet error:
string:///download_jsp.java:16: package
com.contshipitalia.net does not exist

PWC6197: An error occurred at
line: 13 in the jsp file: /resources/download.jsp
PWC6199: Generated
servlet error:
string:///download_jsp.java:21: cannot find symbol
sy
mbol : class GenericServiceBroker
location: class org.apache.jsp.res
ources.download_jsp

PWC6197: An error occurred at line: 13 in the js
p file: /resources/download.jsp
PWC6199: Generated servlet error:
str
ing:///download_jsp.java:21: cannot find symbol
symbol : class Gener
icServiceBroker
location: class org.apache.jsp.resources.download_jsp

PWC6197: An error occurred at line: 13 in the jsp file: /resources/
download.jsp
PWC6199: Generated servlet error:
string:///download_jsp
.java:58: package com.contshipitalia.net does not exist

PWC6197: An
error occurred at line: 13 in the jsp file: /resources/download.jsp
P
WC6199: Generated servlet error:
string:///download_jsp.java:60: pack
age com.contshipitalia.net does not exist

PWC6197: An error occurred
at line: 13 in the jsp file: /resources/download.jsp
PWC6199: Genera
ted servlet error:
string:///download_jsp.java:63: package com.contsh
ipitalia.net does not exist

PWC6197: An error occurred at line: 14 i
n the jsp file: /resources/download.jsp
PWC6199: Generated servlet er
ror:
string:///download_jsp.java:76: cannot find symbol
symbol : var
iable Form
location: class org.apache.jsp.resources.download_jsp

PWC
6197: An error occurred at line: 14 in the jsp file: /resources/downl
oad.jsp
PWC6199: Generated servlet error:
string:///download_jsp.java
:89: cannot find symbol
symbol : class Download
location: class org.
apache.jsp.resources.download_jsp

PWC6197: An error occurred at line
: 14 in the jsp file: /resources/download.jsp
PWC6199: Generated serv
let error:
string:///download_jsp.java:95: cannot find symbol
symbol
: variable Form
location: class org.apache.jsp.resources.download_js
p

PWC6197: An error occurred at line: 14 in the jsp file: /resources
/download.jsp
PWC6199: Generated servlet error:
string:///download_js
p.java:101: cannot find symbol
symbol : variable Environment
locatio
n: class org.apache.jsp.resources.download_jsp

PWC6197: An error occ
urred at line: 14 in the jsp file: /resources/download.jsp
PWC6199: G
enerated servlet error:
string:///download_jsp.java:109: cannot find
symbol
symbol : class GenericData
location: class org.apache.jsp.res
ources.download_jsp

PWC6197: An error occurred at line: 14 in the js
p file: /resources/download.jsp
PWC6199: Generated servlet error:
str
ing:///download_jsp.java:136: cannot find symbol
symbol : class Down
load
location: class org.apache.jsp.resources.download_jsp

PWC6197:
An error occurred at line: 14 in the jsp file: /resources/download.js
p
PWC6199: Generated servlet error:
string:///download_jsp.java:165:
cannot find symbol
symbol : class Download
location: class org.apach
e.jsp.resources.download_jsp

PWC6197: An error occurred at line: 14
in the jsp file: /resources/download.jsp
PWC6199: Generated servlet e
rror:
string:///download_jsp.java:167: cannot find symbol
symbol : c
lass Download
location: class org.apache.jsp.resources.download_jsp

PWC6197: An error occurred at line: 14 in the jsp file: /resources/do
wnload.jsp
PWC6199: Generated servlet error:
string:///download_jsp.j
ava:184: cannot find symbol
symbol : class Download
location: class
org.apache.jsp.resources.download_jsp

PWC6197: An error occurred at
line: 14 in the jsp file: /resources/download.jsp
PWC6199: Generated
servlet error:
string:///download_jsp.java:205: cannot find symbol
sy
mbol : class Download
location: class org.apache.jsp.resources.downl
oad_jsp

PWC6197: An error occurred at line: 14 in the jsp file: /res
ources/download.jsp
PWC6199: Generated servlet error:
string:///downl
oad_jsp.java:218: cannot find symbol
symbol : class StringInputStrea
m
location: class org.apache.jsp.resources.download_jsp

PWC6197: An
error occurred at line: 14 in the jsp file: /resources/download.jsp
P
WC6199: Generated servlet error:
string:///download_jsp.java:243: can
not find symbol
symbol : variable JMail
location: class org.apache.j
sp.resources.download_jsp

PWC6197: An error occurred at line: 14 in
the jsp file: /resources/download.jsp
PWC6199: Generated servlet erro
r:
string:///download_jsp.java:247: cannot find symbol
symbol : vari
able JMail
location: class org.apache.jsp.resources.download_jsp


PWC6033: Error in Javac compilation for JSP

PWC6199: Generated serv
let error:
string:///download_jsp.java:8: package com.portal.util doe
s not exist

PWC6199: Generated servlet error:
string:///download_jsp
.java:9: package com.portal.util does not exist

PWC6199: Generated s
ervlet error:
string:///download_jsp.java:12: package com.contshipita
lia.broker does not exist

PWC6199: Generated servlet error:
string:/
//download_jsp.java:13: package com.contshipitalia.persistence does n
ot exist

PWC6199: Generated servlet error:
string:///download_jsp.ja
va:14: package com.contshipitalia.persistence does not exist

PWC6199
: Generated servlet error:
string:///download_jsp.java:15: package co
m.contshipitalia.util does not exist

PWC6199: Generated servlet erro
r:
string:///download_jsp.java:16: package com.contshipitalia.net doe
s not exist

PWC6197: An error occurred at line: 13 in the jsp file:
/resources/download.jsp
PWC6199: Generated servlet error:
string:///d
ownload_jsp.java:21: cannot find symbol
symbol : class GenericServic
eBroker
location: class org.apache.jsp.resources.download_jsp

PWC619
7: An error occurred at line: 13 in the jsp file: /resources/download
.jsp
PWC6199: Generated servlet error:
string:///download_jsp.java:21
: cannot find symbol
symbol : class GenericServiceBroker
location: c
lass org.apache.jsp.resources.download_jsp

PWC6197: An error occurre
d at line: 13 in the jsp file: /resources/download.jsp
PWC6199: Gener
ated servlet error:
string:///download_jsp.java:58: package com.conts
hipitalia.net does not exist

PWC6197: An error occurred at line: 13
in the jsp file: /resources/download.jsp
PWC6199: Generated servlet e
rror:
string:///download_jsp.java:60: package com.contshipitalia.net
does not exist

PWC6197: An error occurred at line: 13 in the jsp fil
e: /resources/download.jsp
PWC6199: Generated servlet error:
string:/
//download_jsp.java:63: package com.contshipitalia.net does not exist

PWC6197: An error occurred at line: 14 in the jsp file: /resources/
download.jsp
PWC6199: Generated servlet error:
string:///download_jsp
.java:76: cannot find symbol
symbol : variable Form
location: class
org.apache.jsp.resources.download_jsp

PWC6197: An error occurred at
line: 14 in the jsp file: /resources/download.jsp
PWC6199: Generated
servlet error:
string:///download_jsp.java:89: cannot find symbol
sym
bol : class Download
location: class org.apache.jsp.resources.downlo
ad_jsp

PWC6197: An error occurred at line: 14 in the jsp file: /reso
urces/download.jsp
PWC6199: Generated servlet error:
string:///downlo
ad_jsp.java:95: cannot find symbol
symbol : variable Form
location:
class org.apache.jsp.resources.download_jsp

PWC6197: An error occurr
ed at line: 14 in the jsp file: /resources/download.jsp
PWC6199: Gene
rated servlet error:
string:///download_jsp.java:101: cannot find sym
bol
symbol : variable Environment
location: class org.apache.jsp.res
ources.download_jsp

PWC6197: An error occurred at line: 14 in the js
p file: /resources/download.jsp
PWC6199: Generated servlet error:
str
ing:///download_jsp.java:109: cannot find symbol
symbol : class Gene
ricData
location: class org.apache.jsp.resources.download_jsp

PWC619
7: An error occurred at line: 14 in the jsp file: /resources/download
.jsp
PWC6199: Generated servlet error:
string:///download_jsp.java:13
6: cannot find symbol
symbol : class Download
location: class org.ap
ache.jsp.resources.download_jsp

PWC6197: An error occurred at line:
14 in the jsp file: /resources/download.jsp
PWC6199: Generated servle
t error:
string:///download_jsp.java:165: cannot find symbol
symbol
: class Download
location: class org.apache.jsp.resources.download_js
p

PWC6197: An error occurred at line: 14 in the jsp file: /resources
/download.jsp
PWC6199: Generated servlet error:
string:///download_js
p.java:167: cannot find symbol
symbol : class Download
location: cla
ss org.apache.jsp.resources.download_jsp

PWC6197: An error occurred
at line: 14 in the jsp file: /resources/download.jsp
PWC6199: Generat
ed servlet error:
string:///download_jsp.java:184: cannot find symbol

symbol : class Download
location: class org.apache.jsp.resources.do
wnload_jsp

PWC6197: An error occurred at line: 14 in the jsp file: /
resources/download.jsp
PWC6199: Generated servlet error:
string:///do
wnload_jsp.java:205: cannot find symbol
symbol : class Download
loca
tion: class org.apache.jsp.resources.download_jsp

PWC6197: An error
occurred at line: 14 in the jsp file: /resources/download.jsp
PWC6199
: Generated servlet error:
string:///download_jsp.java:218: cannot fi
nd symbol
symbol : class StringInputStream
location: class org.apach
e.jsp.resources.download_jsp

PWC6197: An error occurred at line: 14
in the jsp file: /resources/download.jsp
PWC6199: Generated servlet e
rror:
string:///download_jsp.java:243: cannot find symbol
symbol : v
ariable JMail
location: class org.apache.jsp.resources.download_jsp

PWC6197: An error occurred at line: 14 in the jsp file: /resources/do
wnload.jsp
PWC6199: Generated servlet error:
string:///download_jsp.j
ava:247: cannot find symbol
symbol : variable JMail
location: class
org.apache.jsp.resources.download_jsp

name_value: CSIPortal-J2EE6
name_name: name
keys: name
use-main-children-attribute: false
exit-code: FAILURE

Command deploy failed.

Comment by Hong Zhang [ 15/Jul/11 ]

From the error message, the precompilejsp flag is passed to the web container, but there are some issues in compiling the jsps. Assign to kinman for further evaluation.

Comment by cistox [ 18/Jul/11 ]

Hello,
I extend the issue to servlets.

If I do not precompile JSPs but I just deploy the EAR, then I found that I cannot access either JSPs and Servlets.

a) JSPs are not accessible as they are not compiled even dynamically on request.

b) Servlets are not reachable... thus this seems the servlet container is not able to read the web.xml

We have a distributable WAR inside the EAR along with some EJB modules and JPA entities.

The same EAR is working fine when deployed on a Glassfish 3.1 installed for development (default install option)

Hope this helps, but I please ask you if you could provide a workaround.

I mean a manual way to fix the deployment on a cluster.

Thank you in advance

Roberto Cisternino

Comment by kchung [ 20/Jul/11 ]

When try deploying the ear file, I got the following error:

./asadmin deploy --precompilejsp=true ~/d/CSIPortal-J2EE6.ear
remote failure: Error occurred during deployment: Exception while preparing the app : Invalid resource : jdbc/AS400_MCT__pm. Please see server.log for more details.
Exception while invoking class org.glassfish.persistence.jpa.JPADeployer prepare method : java.lang.RuntimeException: Invalid resource : jdbc/AS400_MCT__pm
Invalid resource : jdbc/AS400_MCT__pm
Command deploy failed.

Comment by cistox [ 20/Jul/11 ]

Well,
I have not mentioned that this is an enterprise application that is using 13 databases, so for a test I would suggest to install the following glassfish-resources.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE resources PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Resource Definitions//EN" "http://glassfish.org/dtds/glassfish-resources_1_5.dtd">
<resources>
<jdbc-resource enabled="true" jndi-name="jdbc/WEBCDB" object-type="user" pool-name="DB2-UDB_WEBCDB">
<description>CSI Portal Central Index DB</description>
</jdbc-resource>
<jdbc-resource enabled="true" jndi-name="jdbc/WEBDBLSCT" object-type="user" pool-name="SQLServer_LSCT">
<description>CSI Portal LSCT Remote DB</description>
</jdbc-resource>
<jdbc-resource enabled="true" jndi-name="jdbc/WEBDBCICT" object-type="user" pool-name="SQLServer_CICT">
<description>CSI Portal CICT Remote DB</description>
</jdbc-resource>
<jdbc-resource enabled="true" jndi-name="jdbc/WEBDBTCR" object-type="user" pool-name="SQLServer_TCR">
<description>CSI Portal TCR Remote DB</description>
</jdbc-resource>
<jdbc-resource enabled="true" jndi-name="jdbc/WEBDBEGATE" object-type="user" pool-name="SQLServer_EGT">
<description>CSI Portal EGT Remote DB</description>
</jdbc-resource>
<jdbc-resource enabled="true" jndi-name="jdbc/WEBDBMCT" object-type="user" pool-name="SQLServer_MCT">
<description>CSI Portal MCT Remote DB</description>
</jdbc-resource>
<jdbc-resource enabled="true" jndi-name="jdbc/WEBDBSOGEMAR" object-type="user" pool-name="ORACLE_SOGEMAR">
<description>CSI Portal SOGEMAR Remote DB</description>
</jdbc-resource>
<jdbc-resource enabled="true" jndi-name="jdbc/MCTSTAPDB" object-type="user" pool-name="SQLServer_Stap_MCT">
<description>MCT Stap DB</description>
</jdbc-resource>
<jdbc-resource enabled="true" jndi-name="jdbc/MCTSrvAcc" object-type="user" pool-name="SQLServer_AccServ_MCT">
<description>MCT Accessorial Services DB</description>
</jdbc-resource>
<jdbc-resource enabled="true" jndi-name="jdbc/MCT_LASHING" object-type="user" pool-name="SQLServer_Lashing_MCT">
<description>MCT Lashing DB</description>
</jdbc-resource>
<jdbc-resource enabled="true" jndi-name="jdbc/AS400_LSCT" object-type="user" pool-name="DB2-AS400_LSCT">
<description>LSCT AS400 DB</description>
</jdbc-resource>
<jdbc-resource enabled="true" jndi-name="jdbc/AS400_MCT" object-type="user" pool-name="DB2-AS400_MCT">
<description>MCT AS400 DB</description>
</jdbc-resource>
<mail-resource debug="false" enabled="true" from="CSIPortal@contshipitalia.com" host="w2kspeexc2.contship.net" jndi-name="mail/mailer" object-type="user" store-protocol="imap" store-protocol-class="com.sun.mail.imap.IMAPStore" transport-protocol="smtp" transport-protocol-class="com.sun.mail.smtp.SMTPTransport" user="CSIPortal">
<description/>
<property name="mail.password" value="SuPerpippox.68"/>
</mail-resource>
<jdbc-connection-pool allow-non-component-callers="true" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="table" datasource-classname="com.ibm.db2.jcc.DB2ConnectionPoolDataSource" fail-all-connections="true" idle-timeout-in-seconds="300" is-connection-validation-required="true" is-isolation-level-guaranteed="true" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="50" max-wait-time-in-millis="60000" name="DB2-UDB_WEBCDB" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.ConnectionPoolDataSource" statement-timeout-in-seconds="-1" steady-pool-size="5" validate-atmost-once-period-in-seconds="0" validation-table-name="DUMMY" wrap-jdbc-objects="true">
<description>WEBCDB - DB2 8.2 Universal JDBC Driver Provider</description>
<property name="serverName" value="10.5.1.77"/>
<property name="portNumber" value="50004"/>
<property name="databaseName" value="WEBCDB"/>
<property name="driverType" value="4"/>
<property name="User" value="addb2"/>
<property name="Password" value="addb2"/>
</jdbc-connection-pool>
<jdbc-connection-pool allow-non-component-callers="false" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="auto-commit" datasource-classname="com.ibm.as400.access.AS400JDBCConnectionPoolDataSource" fail-all-connections="true" idle-timeout-in-seconds="300" is-connection-validation-required="false" is-isolation-level-guaranteed="true" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="15" max-wait-time-in-millis="60000" name="DB2-AS400_LSCT" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.ConnectionPoolDataSource" statement-timeout-in-seconds="-1" steady-pool-size="2" validate-atmost-once-period-in-seconds="0" wrap-jdbc-objects="true">
<description>LSCT - AS400 Toolbox JDBC Driver</description>
<property name="User" value="EDI"/>
<property name="Password" value="vermentino"/>
<property name="serverName" value="10.5.1.21"/>
<property name="databaseName" value="S650514C"/>
<property name="dateFormat" value="ISO"/>
<property name="driver" value="toolbox"/>
<property name="access" value="all"/>
<property name="blockSize" value="32"/>
<property name="blockCriteria" value="2"/>
<property name="dataTruncation" value="true"/>
<property name="dataCompression" value="true"/>
<property name="lazyClose" value="false"/>
<property name="fullOpen" value="false"/>
<property name="extendedMetaData" value="false"/>
<property name="extendedDynamic" value="false"/>
<property name="bigDecimal" value="true"/>
<property name="cursorHold" value="false"/>
</jdbc-connection-pool>
<jdbc-connection-pool allow-non-component-callers="false" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="auto-commit" datasource-classname="com.ibm.as400.access.AS400JDBCConnectionPoolDataSource" fail-all-connections="true" idle-timeout-in-seconds="300" is-connection-validation-required="false" is-isolation-level-guaranteed="true" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="20" max-wait-time-in-millis="60000" name="DB2-AS400_MCT" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.ConnectionPoolDataSource" statement-timeout-in-seconds="-1" steady-pool-size="2" validate-atmost-once-period-in-seconds="0" wrap-jdbc-objects="true">
<description>MCT - AS400 Toolbox JDBC Driver</description>
<property name="User" value="LSCT_WEB"/>
<property name="Password" value="WEB_LSCT"/>
<property name="serverName" value="10.20.1.5"/>
<property name="databaseName" value="TESTDB"/>
<property name="libraries" value="BLOCCOAB"/>
<property name="dateFormat" value="ISO"/>
<property name="driver" value="toolbox"/>
<property name="access" value="all"/>
<property name="blockSize" value="32"/>
<property name="blockCriteria" value="2"/>
<property name="dataTruncation" value="true"/>
<property name="dataCompression" value="true"/>
<property name="lazyClose" value="false"/>
<property name="fullOpen" value="false"/>
<property name="extendedMetaData" value="false"/>
<property name="extendedDynamic" value="false"/>
<property name="bigDecimal" value="true"/>
<property name="cursorHold" value="false"/>
</jdbc-connection-pool>
<jdbc-connection-pool allow-non-component-callers="false" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="table" datasource-classname="com.inet.tds.PDataSource" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="true" is-isolation-level-guaranteed="true" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="35" max-wait-time-in-millis="60000" name="SQLServer_LSCT" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.ConnectionPoolDataSource" statement-timeout-in-seconds="-1" steady-pool-size="5" validate-atmost-once-period-in-seconds="0" validation-table-name="TERMINAL" wrap-jdbc-objects="true">
<description>WEBDB LSCT - Merlia I-NET JDBC Driver for MS SQLServer</description>
<property name="serverName" value="w2kspesql01"/>
<property name="portNumber" value="1433"/>
<property name="databaseName" value="WEBDB_LSCT"/>
<property name="User" value="nodo"/>
<property name="Password" value="nodo"/>
</jdbc-connection-pool>
<jdbc-connection-pool allow-non-component-callers="false" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="table" datasource-classname="com.inet.tds.PDataSource" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="true" is-isolation-level-guaranteed="true" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="30" max-wait-time-in-millis="60000" name="SQLServer_MCT" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.ConnectionPoolDataSource" statement-timeout-in-seconds="-1" steady-pool-size="5" validate-atmost-once-period-in-seconds="0" validation-table-name="TERMINAL" wrap-jdbc-objects="true">
<description>WEBDB MCT - Merlia I-NET JDBC Driver for MS SQLServer</description>
<property name="serverName" value="10.20.1.38"/>
<property name="portNumber" value="1433"/>
<property name="databaseName" value="WEBDB"/>
<property name="User" value="lsct"/>
<property name="Password" value="lsct"/>
</jdbc-connection-pool>
<jdbc-connection-pool allow-non-component-callers="false" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="table" datasource-classname="com.inet.tds.PDataSource" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="true" is-isolation-level-guaranteed="true" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="15" max-wait-time-in-millis="60000" name="SQLServer_CICT" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.ConnectionPoolDataSource" statement-timeout-in-seconds="-1" steady-pool-size="3" validate-atmost-once-period-in-seconds="0" validation-table-name="TERMINAL" wrap-jdbc-objects="true">
<description>WEBDB CICT - Merlia I-NET JDBC Driver for MS SQLServer</description>
<property name="serverName" value="10.80.1.84"/>
<property name="portNumber" value="1433"/>
<property name="databaseName" value="WEBDB_CICT"/>
<property name="User" value="nodo"/>
<property name="Password" value="nodo"/>
</jdbc-connection-pool>
<jdbc-connection-pool allow-non-component-callers="false" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="table" datasource-classname="com.inet.tds.PDataSource" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="true" is-isolation-level-guaranteed="true" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="15" max-wait-time-in-millis="60000" name="SQLServer_TCR" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.ConnectionPoolDataSource" statement-timeout-in-seconds="-1" steady-pool-size="3" validate-atmost-once-period-in-seconds="0" validation-table-name="TERMINAL" wrap-jdbc-objects="true">
<description>WEBDB TCR - Merlia I-NET JDBC Driver for MS SQLServer</description>
<property name="serverName" value="10.0.2.46"/>
<property name="portNumber" value="1433"/>
<property name="databaseName" value="WEBDB_TCR"/>
<property name="User" value="nodo"/>
<property name="Password" value="nodo"/>
</jdbc-connection-pool>
<jdbc-connection-pool allow-non-component-callers="false" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="table" datasource-classname="com.inet.tds.PDataSource" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="true" is-isolation-level-guaranteed="true" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="15" max-wait-time-in-millis="60000" name="SQLServer_EGT" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.ConnectionPoolDataSource" statement-timeout-in-seconds="-1" steady-pool-size="3" validate-atmost-once-period-in-seconds="0" validation-table-name="TERMINAL" wrap-jdbc-objects="true">
<description>WEBDB EGT - Merlia I-NET JDBC Driver for MS SQLServer</description>
<property name="serverName" value="10.60.1.33"/>
<property name="portNumber" value="1433"/>
<property name="databaseName" value="WEBDB_EGT"/>
<property name="User" value="nodo"/>
<property name="Password" value="nodo"/>
</jdbc-connection-pool>
<jdbc-connection-pool allow-non-component-callers="false" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="table" datasource-classname="oracle.jdbc.pool.OracleConnectionPoolDataSource" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="true" is-isolation-level-guaranteed="true" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="15" max-wait-time-in-millis="60000" name="ORACLE_SOGEMAR" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.ConnectionPoolDataSource" statement-timeout-in-seconds="-1" steady-pool-size="3" validate-atmost-once-period-in-seconds="0" validation-table-name="TERMINAL" wrap-jdbc-objects="true">
<description>WEBDB SOGEMAR - ORACLE JDBC Driver</description>
<property name="User" value="dbaportale"/>
<property name="Password" value="sogemar"/>
<property name="url" value="jdbc:oracle:thin:@//10.10.5.14:1521/POS10"/>
</jdbc-connection-pool>
<jdbc-connection-pool allow-non-component-callers="false" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="auto-commit" datasource-classname="com.inet.tds.PDataSource" fail-all-connections="true" idle-timeout-in-seconds="300" is-connection-validation-required="true" is-isolation-level-guaranteed="true" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="10" max-wait-time-in-millis="60000" name="SQLServer_Lashing_MCT" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.ConnectionPoolDataSource" statement-timeout-in-seconds="-1" steady-pool-size="3" validate-atmost-once-period-in-seconds="0" wrap-jdbc-objects="true">
<description>LASHING MCT - Merlia I-NET JDBC Driver for MS SQLServer</description>
<property name="serverName" value="10.20.1.36"/>
<property name="portNumber" value="1433"/>
<property name="databaseName" value="TerminalMonitor"/>
<property name="User" value="lsct"/>
<property name="Password" value="lashing"/>
</jdbc-connection-pool>
<jdbc-connection-pool allow-non-component-callers="false" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="auto-commit" datasource-classname="com.inet.tds.PDataSource" fail-all-connections="true" idle-timeout-in-seconds="300" is-connection-validation-required="true" is-isolation-level-guaranteed="true" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="10" max-wait-time-in-millis="60000" name="SQLServer_Stap_MCT" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.ConnectionPoolDataSource" statement-timeout-in-seconds="-1" steady-pool-size="2" validate-atmost-once-period-in-seconds="0" wrap-jdbc-objects="true">
<description>STAP MCT - Merlia I-NET JDBC Driver for MS SQLServer</description>
<property name="serverName" value="10.20.1.37"/>
<property name="portNumber" value="1433"/>
<property name="databaseName" value="STAP"/>
<property name="User" value="webstap"/>
<property name="Password" value="lsct"/>
</jdbc-connection-pool>
<jdbc-connection-pool allow-non-component-callers="false" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="auto-commit" datasource-classname="com.inet.tds.PDataSource" fail-all-connections="true" idle-timeout-in-seconds="300" is-connection-validation-required="true" is-isolation-level-guaranteed="true" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="10" max-wait-time-in-millis="60000" name="SQLServer_AccServ_MCT" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.ConnectionPoolDataSource" statement-timeout-in-seconds="-1" steady-pool-size="2" validate-atmost-once-period-in-seconds="0" wrap-jdbc-objects="true">
<description>Accessorial Services MCT - Merlia I-NET JDBC Driver for MS SQLServer</description>
<property name="serverName" value="10.20.1.14"/>
<property name="portNumber" value="1433"/>
<property name="databaseName" value="ServiziAccessori"/>
<property name="User" value="lsct2"/>
<property name="Password" value="lsct2"/>
</jdbc-connection-pool>
</resources>

Comment by kchung [ 21/Jul/11 ]

I added your glassfish-resources.xml to META-INF but still have the same error when deployed. Please attach another ear file with this file added. Thanks.

Comment by cistox [ 25/Jul/11 ]

Sorry I do not understand why you put glassfish resources under META-INF as I think you cannot have jndi resources automatically installed on the cluster.

I used this command to install all JNDI and references:

asadmin add-resources --target CSIPortal-cluster glassfish-resources.xml





[GLASSFISH-17044] [PERF] gmbal objects consuming large part of heap Created: 13/Jul/11  Updated: 03/Dec/12

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1, 3.1.1
Fix Version/s: None

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

Attachments: JPEG File heap-dump-gmbal-api-only.jpg     JPEG File HeapDump-gmbal-classes.jpg     File MyEjb.ear    
Issue Links:
Dependency
depends on GLASSFISH_CORBA-5 [PERF] gmbal objects consuming large ... In Progress
depends on METRO-17 [PERF] gmbal objects consuming large ... Resolved
blocks GLASSFISH-16355 startup and footprint of larger size ... Open
Tags: 3_1-next, 3_1_1-scrubbed, 3_1_2-exclude, PSRBUG

 Description   

The gmbal related classes added in 3.x have contributed significantly to the heap regression usage for larger apps between 2.x and 3.x. In fact, now that other issues (notably 16747) have been fixed, these classes constitute almost all of the remaining regression. In a standard domain with specj deployed, the gmbal classes retain some 33MB of heap space (and the entire consumed heap space after startup is only 130MB).



 Comments   
Comment by scatari [ 26/Jul/11 ]

Targeting to be fixed in the patch release post 3.1.1.

Comment by Tom Mueller [ 18/Aug/11 ]

Scott, can you please provide details on how to recreate this issue?

Is monitoring turned on during the test?
Do you see a relatively significant amount of memory consumed by gmbal objects with a smaller application?
How did you determine the values that are quoted in the description?

Comment by Scott Oaks [ 18/Aug/11 ]

The numbers I quoted come from examining the heap dump taken after the domain has started (but not accessed); the 33MB is the size of the memory retained by the 5,619 org.glassfish.gmbal.typelib.DeclarationFactory$EvaluatedClassDeclarationImpl objects.

Monitoring options are out-of-the box settings; the only changes to the domain are to add the necessary JDBC and JMS resources for the app (which in this case is specjappserver). My understanding from Ken is that although there is a way to disable gmbal monitoring, the necessary code is not implemented at the glassfish level (it means using a different gmbal factory to get a no-op gmbal manager). Allowing that might be a good option.

We have only observed this on ejb-related deployments, not on web-only deployments. I'll have to see if we can get measurements from other apps.

Comment by Jennifer Chou [ 14/Oct/11 ]
  • If monitoring is disabled - setting mbean-enabled=false will make no difference.
  • If it is the ManagedObjectManagerFactory that is causing problems, there is only 2 places it is referenced - monitoring and web services. Since the monitoring is disabled it will not go through the code path that references ManagedObjectManagerFactory.

I tried to reproduce the issue, but was unsuccessful.

1. Download glassfish 3.1.1 open source edition
2. asadmin start-domain
3. jconsole <gf pid>
4. MBeans > com.sun.management > Operations
a. enter 'heap.dump.out' in p0
b. clicked on dumpHeap
5. Open 'heap.dump.out' in NetBeans.

I couldn't find any gmbal classes listed under Classes. I searched for 'DeclarationFactory' and 'gmbal'.

What am I missing? Do I need to have specj deployed?

Comment by Scott Oaks [ 14/Oct/11 ]

You don't need specj per se, but you need some application with EJBs deployed.

Comment by Jennifer Chou [ 14/Oct/11 ]

After deploying attached simple EJB app (with a stateless session bean), the gmbal classes can be seen in the screenshot of the heap dump list.

Comment by Jennifer Chou [ 14/Oct/11 ]

After replacing gmbal.jar with gmbal-api-only.jar, the size and number of instances is greatly reduced. See attached screenshot - heap-dump-gmbal-api-only.

gmbal-api-only.jar is downloaded from http://download.java.net/maven/2/org/glassfish/gmbal/gmbal-api-only/3.1.0-b001/gmbal-api-only-3.1.0-b001.jar

Comment by Jennifer Chou [ 14/Oct/11 ]

From Scott:

The gmbal instances are all held by the org.glassfish.gmbal.impl.ManagedObjectManagerImpl object that is held in the ORB.

There is a factory that produces a "null" maanged object manager impl instead of that ManagedObjectManagerImpl, so if we could arrange for the ORB to use that factory when we don't want the overhead of gmbal, that would solve the issue.

Comment by Jennifer Chou [ 28/Oct/11 ]

The fix should be in ORB to defer the gmbal API calls until there is a JMX client connection.

http://java.net/jira/browse/GLASSFISH_CORBA-5

Comment by Jennifer Chou [ 28/Oct/11 ]

The fix should be in metro and WebServicesContainer to defer the gmbal API call until there is a JMX client connection.

http://java.net/jira/browse/METRO-17

Comment by Jennifer Chou [ 28/Dec/11 ]

Transfer to Scott Oaks. This is an umbrella bug to track the 2 issues in ORB and Metro.

Comment by Joe Di Pol [ 18/Jan/12 ]

We've done all we plan on doing for 3.1.2 (See linked Metro bug). The ORB fix will have to wait for a subsequent release.





[GLASSFISH-17039] 3.1.1 deployment performance - webservices module get loaded for a web app with no webservices Created: 13/Jul/11  Updated: 15/Nov/11  Resolved: 22/Aug/11

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.1
Fix Version/s: 3.1.2_b02

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

Attachments: Text File glassfish-17039.patch     Text File started-47.log    
Issue Links:
Dependency
blocks GLASSFISH-16460 Performance regression in server startup Resolved
Tags: 3_1-next, 3_1_1-scrubbed

 Description   

Using the felix console to monitor which module get loaded for the web application deployment, noticed the following webservices modules got active:

47|Active | 1|org.glassfish.webservices.jsr109-impl (3.1.1.SNAPSHOT)

and following got resolved:
17|Resolved | 1|org.glassfish.security.webservices.security (3.1.1.SNAPSHOT)
52|Resolved | 1|org.glassfish.metro.webservices-osgi (2.1.1.b07)

we need to figure out which dependency had triggered the webservices related modules get loaded/resolved, they should not be for a web application with no webservices. The test web application is attached in its parent issue.



 Comments   
Comment by Hong Zhang [ 13/Jul/11 ]

Futher analysis showed the jsr109-impl module was brought in as it contains classes implements AnnotationHandler interface and the SJSASFactory injects the list of the AnnotationHandler [].

-----------------------------------
Inhabitants / stack combination
-----------------------------------
Requested by LazyInhabitant-14679795(org.glassfish.webservices.annotation.handlers.WebServiceHandler, active: null) called from java.util.AbstractList$Itr.next:345 metadata

{class: [org.glassfish.webservices.annotation.handlers.WebServiceHandler] index: [org.glassfish.apf.AnnotationHandler] }

Requested by ConstructorCreator-23397116(com.sun.enterprise.deployment.annotation.factory.SJSASFactory) called from com.sun.enterprise.web.WebContainer.loadSystemDefaultWebModules:1424 metadata

{class: [com.sun.enterprise.deployment.annotation.factory.SJSASFactory] index: [org.glassfish.api.ContractProvider] }

Requested by SingletonInhabitant-10947277(com.sun.enterprise.deployment.annotation.factory.SJSASFactory) called from com.sun.enterprise.web.WebContainer.loadSystemDefaultWebModules:1424 metadata

{class: [com.sun.enterprise.deployment.annotation.factory.SJSASFactory] index: [org.glassfish.api.ContractProvider] }
Comment by Hong Zhang [ 14/Jul/11 ]

Can we try to move the AnnotationHandler impl classes from this jsr109-impl module to another module to avoid loading this module?

We cannot move them to the existing connector module as we don't want to introduce dol dependency on that module. Maybe we have to make a new module called jsr109-glue or something and put the handlers there (and of course make sure this new module does not have dependency on jsr109-impl). It's an additional module, but as jsr109-impl module is a good sized module, I think it will be worthwhile. Any other alternatives you guys can think of?

Comment by ramapulavarthi [ 15/Jul/11 ]

Moving the web services annotation handlers to a new module jsr109-glue so that DOL does not activate jsr109-impl and its dependencies.

Comment by scatari [ 26/Jul/11 ]

Marking to be fixed in the patch release that follows 3.1.1. Does not affect primary functionality of the product, downgrading.

Comment by Bhakti Mehta [ 22/Aug/11 ]

Committed fix in 3.1.2 rev 48931

Comment by Bhakti Mehta [ 24/Aug/11 ]

Committed svn rev 49014 on trunk

Comment by Lukas Jungmann [ 14/Nov/11 ]

also resource bundles have to be moved as GF 3.1.2 (r50799) currently fails when trying to log a message with:

SEVERE: The log message is empty or null. Please log an issue against the component in the logger field.
SEVERE: Exception while deploying the app [WebApplication1]
SEVERE: nullat org.glassfish.apf.AnnotationInfo@2f9c3beb
java.lang.IllegalStateException: nullat org.glassfish.apf.AnnotationInfo@2f9c3beb
...
Caused by: nullat org.glassfish.apf.AnnotationInfo@2f9c3beb
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:367)
...
Caused by: java.lang.NullPointerException
at org.glassfish.webservices.connector.annotation.handlers.WebServiceHandler.processAnnotation(WebServiceHandler.java:141)
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:344)
... 45 more

I'm going to fix this

Comment by Lukas Jungmann [ 15/Nov/11 ]

3.1.2/revision 50861 and trunk/revision 50870





[GLASSFISH-17036] Cannot find entity which actually is there / Works well standalone / Works well with disabled cache Created: 13/Jul/11  Updated: 14/Dec/11  Resolved: 14/Dec/11

Status: Resolved
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 3.1, 3.1.1_b11
Fix Version/s: 3.1.2_b14

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

Win7 Pro SP1 64 Bit de_DE


Attachments: File SuperSimple.ear     Zip Archive Test.zip    
Tags: 3_1-next, 3_1_1-scrubbed

 Description   

We noticed a showstopper in GFv3.1 which still exists in GFv3.1.1_b11.
In certain scenarios it happens that EclipseLink is able to find(cls,pk) an entity, but if the entity contains a @ManyToOne reference, the reference is NULL – which cannot be the case, as in this particular scenario the reference is an additional, object-oriented mapping of the primary key (in terms of DBMS technolog: The primary key and the foreign key share the same columns, and the target object is existing).

The strange thing is: This is working well standalone, also it is working well in GF as soon as the cache is switched off using @Cacheable(false) for all entities used in this scenario. So there must be an issue with JDBC caches in GF.

We can provide a closed-source confidential EAR for reproduction of this bug: Please write to karg@quipsy.de to obtain a copy (since it is confidential we must not upload it into JIRA).

This is a showstopper obviously, as existing data is not found and the workaround enforces a source code change of the deployed application.



 Comments   
Comment by Mitesh Meswani [ 13/Jul/11 ]

Can you please provide some code snippets of your entities and the scenario that triggers it. Does the find(cls,pk) above refer to em.find()? Is it done inside a transaction or outside?

>The strange thing is: This is working well standalone, also it is working well in GF as soon as the cache is switched off using @Cacheable(false)
>for all entities used in this scenario. So there must be an issue with JDBC caches in GF.
Your description seems to indicate that this might be due to a probable EclipseLink bug and you should be able to reproduce it standalone (@Cacheable is interpreted by persistence provider for 2nd level cache. It has nothing to do with any JDBC cache in appserver) Make sure that your standlone test case simulates transactional persistence context (like the managed persistence context within appserver). That is close em after transaction commit.

Comment by mkarg [ 14/Jul/11 ]

Mitesh,

we stripped down the problem to the following scenario:

In our web service we have two methods similar to these ones:

public void saveTest(String partId, String partVersion, short year)

{ Part part = em.find(Part.class, new PartPrimaryKey(partId, partVersion)); em.persist(new ManufacturedAmount(part, year)); }

The first method works well: We checked the database content using an SQL tool and the new row is inserted, and the row contains a valid part foreign key.

Then we run the second method:

public String loadTest(String partId, String partVersion, short year)

{ ManufacturedAmount amount = em.find(ManufacturedAmount.class, new ManufacturedAmountPk(partId, partVersion, year)); if (amount == null) return "Amount not found"; if (amount.getPart() == null) return "Part not found"; return "OK"; }

The second method returns "Part not found", which is weird, as we call both methods with the same parameters and the database proofs that the data actually IS THERE.

If we do @Cacheable(false) on Part and ManufactureAmount, THEN IT WORKS!

Both methods have no explicit transaction setting, so the default (REQUIRED) is in place.

The only special thing we can detect is that the reference from ManufacturedAmount to Part is sharing the some columns with the primary key (partId, partVersion; the pk additionally has year), which we enabled by setting the primary key's fields to updateable=false,insertable=false.

We cannot understand why it does work with cache DISABLED but is NOT working with cache ENABLED. In GFv2ur2 (TopLink Essentials) it was working very well, BTW. To us this just looks like a very weird bug in the EclipseLink cache.

Comment by Mitesh Meswani [ 14/Jul/11 ]

Can you please provider code snippet for your Part and ManufacturedAmoun entities (Specially the @ID and the corresponding relationship attributes for both of them).

To isolate EclipseLink issue, can you try your scaled down version above from a JavaSE test case like as follows
If you are able to reproduce the error, please file an EclipseLink issue at bugs.eclipse.org and update this issue with its reference.

public static void main() {
  EntityManagerFactory emf = Persistence.createEMF(..);

  EntityManager em = emf.createEM();
  em.getEntityTransaction().begin();
  saveTest(em,  partId,  partVersion, year); // Use the em passed here inside the method
  em.getEntityTransaction().commit();
  em.close();

  em = emf.createEM();
  em.getEntityTransaction().begin();
  loadTest(em,  partId,  partVersion, year); // Use the em passed here inside the method
  em.getEntityTransaction().begin();
  em.close();

  emf.close();  

}
Comment by mkarg [ 18/Jul/11 ]

Test.zip contains a standalone test program ("x"). Together with the second upload ("SuperSimple.ear") you will have the following:

(A) SuperSimple.ear – The original EAR containing a web service proofing the failure. See the contained Info.txt how to invoke it from the admin GUI to see the problem. Just ingore all the deployment errors popping up due to missing ressource – you won't need them for the test. The only resource really needed is that one describe in persistence.xml to be able to connect to a database. The web service's second method ("load") will fail if @Cacheable(false) is NOT used, and it will succeed IF it is used.

(B) A complete Eclipse project ("x"), containg the exactly same code, but as a standalone program. This is NOT suffering from that problem and will run fine.

So it seems the problem is not the code, but the problem is the environment: A standalone Eclipse is fine, that one of GlassFish is not.

For your requested code snippets, please find all java sources inside of the "x" project contained in the zip. It will answer your questions.

I hope this helps finding the bug.

Comment by Mitesh Meswani [ 19/Jul/11 ]

Thanks for attaching the test case. Can you please update your standalone test case to follow the pattern above (to simulate transactional em vs. extended as it is currently doing) and try again. From the data provided by you, it looks highly probable that the issue (if it exists) is with EclipseLink run time. Need your help to isolate it

        final EntityManagerFactory emf = Persistence.createEntityManagerFactory("test");
        final EntityManager em = emf.createEntityManager();

        final EntityTransaction tx = em.getTransaction();
        tx.begin();

        final Part part = em.find(Part.class, new PartPrimaryKey(PART_ID, PART_VERSION));
        if (part != null) {
            final ManufacturedAmount manufacturedAmountToSaved = new ManufacturedAmount(part, YEAR);
            em.persist(manufacturedAmountToSaved);
            System.out.println("\nAmount saved.\n");
        } else {
            System.out.println("\nPart not found.\n");
            tx.rollback();
            return;
        }

        tx.commit();
/****************** Insert following code **********/
em.close();
em = emf.createEntityManager();
tx = em.getTransaction();
/****************** End - Insert **********/
        tx.begin();

        final ManufacturedAmount amount = em.find(ManufacturedAmount.class, new ManufacturedAmountPk(PART_ID, PART_VERSION, YEAR));
        if (amount == null)
            System.out.println("\nAmount = NULL.\n");
        else
            System.out.println(String.format("\n Part = %s\n", amount.getPart() == null ? "NULL" : part.toString()));

        tx.commit();


Comment by mkarg [ 19/Jul/11 ]

Mitesh, I inserted the code snippet as you asked me to do and now that reproduces the bug even in the standalone program:

[EL Finest]: 2011-07-19 13:59:13.101-UnitOfWork(614213397)Thread(Thread[main,5,main])-Execute query ReadObjectQuery(name="readObject" referenceClass=ManufacturedAmount sql="SELECT AMOUNTAPRIL, AMOUNTAUGUST, AMOUNTDECEMBER, AMOUNTFEBRUARY, AMOUNTJANUARY, AMOUNTJULY, AMOUNTJUNE, AMOUNTMARCH, AMOUNTMAY, AMOUNTNOVEMBER, AMOUNTOCTOBER, AMOUNTSEPTEMBER, VERSION, YEAR, partId, partVersion FROM MANUFACTUREDAMOUNT WHERE (((YEAR = ?) AND (partId = ?)) AND (partVersion = ?))")
[EL Finest]: 2011-07-19 13:59:13.101-UnitOfWork(614213397)Thread(Thread[main,5,main])-Register the existing object entities.ManufacturedAmount@39697b67(pk=(part='null, 'year='1900'))
[EL Finer]: 2011-07-19 13:59:13.101-UnitOfWork(614213397)Thread(Thread[main,5,main])-begin unit of work commit
[EL Warning]: 2011-07-19 13:59:13.101-UnitOfWork(614213397)Thread(Thread[main,5,main])-Local Exception Stack:
Exception [EclipseLink-7197] (Eclipse Persistence Services - 2.3.0.v20110604-r9504): org.eclipse.persistence.exceptions.ValidationException
Exception Description: Null or zero primary key encountered in unit of work clone [entities.ManufacturedAmount@11e9c82e(pk=(part='null, 'year='1900'))], primary key [[[1900, null, null]: 1900]]. Set descriptors IdValidation or the "eclipselink.id-validation" property.
at org.eclipse.persistence.exceptions.ValidationException.nullPrimaryKeyInUnitOfWorkClone(ValidationException.java:1427)
at org.eclipse.persistence.descriptors.changetracking.DeferredChangeDetectionPolicy.calculateChanges(DeferredChangeDetectionPolicy.java:107)
at org.eclipse.persistence.descriptors.changetracking.DeferredChangeDetectionPolicy.calculateChangesForExistingObject(DeferredChangeDetectionPolicy.java:54)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.calculateChanges(UnitOfWorkImpl.java:636)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabaseWithChangeSet(UnitOfWorkImpl.java:1482)
at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.commitRootUnitOfWork(RepeatableWriteUnitOfWork.java:265)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitAndResume(UnitOfWorkImpl.java:1135)
at org.eclipse.persistence.internal.jpa.transaction.EntityTransactionImpl.commitInternal(EntityTransactionImpl.java:84)
at org.eclipse.persistence.internal.jpa.transaction.EntityTransactionImpl.commit(EntityTransactionImpl.java:63)
at Test.main(Test.java:53)

Obviously EclipseLink understands that the SELECTed object already is in the cache, but then registers it with an in-part empty primary key (primary key [[[1900, null, null] – a primary key must never contain null).

Comment by mkarg [ 19/Jul/11 ]

BTW, how to prevent the forum software to strike-through some parts of my posts, and how to mark posts a code as you did above?

Comment by Mitesh Meswani [ 19/Jul/11 ]

Thanks for the update. Can you please file an issue against EclipseLink attaching your standalone test case and update this issue to reference it.

>formatting in these comments
Now we are able to use wiki markup in comments (when you are writing a comment, click on the yellow '?' icon on right hand side of your text box for syntax). Use

{pre}

tags to avoid unintentional formatting of comment

Comment by mkarg [ 20/Jul/11 ]

This bug is reported to the EclipseLink team as this https://bugs.eclipse.org/bugs/show_bug.cgi?id=352533 issue.

Comment by mkarg [ 20/Jul/11 ]

(Mitesh, thank you for the tip with the '?' icon. Actually I never have seen it before since it always was outside of my screen. Silly me!)

Comment by scatari [ 26/Jul/11 ]

Marking to be fixed in the patch release that follows 3.1.1. Does not affect primary functionality of the product, fix should be through eclipselink project, downgrading.

Comment by mkarg [ 26/Jul/11 ]

I do not understand why you think it dies not affect primary functionality of the product? A third party EAR will definitively crash on GFv3.1.1. That IS a primary fault. There is no workaround that does not induce source code changes to the EAR, so GFv3.1.1 is unuseable for third party products.

Comment by Mitesh Meswani [ 14/Dec/11 ]

Marking this as fixed with integration of EclipseLink 2.3.2.





[GLASSFISH-17006]  glassfish 3.1.1 virtual server nightmare Created: 10/Jul/11  Updated: 19/Jan/12  Resolved: 19/Oct/11

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1_b43
Fix Version/s: None

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

windows 7


Attachments: XML File domain.xml     Text File server.txt    
Issue Links:
Related
is related to GLASSFISH-18060 [JRockit-intermittent] ClassCastExcep... Resolved
Tags: 3_1-next, 3_1_1-scrubbed, http-listener, virtual_server

 Description   

the question here:- http://stackoverflow.com/questions/6633944/glassfish-3-1-virtual-server-nightmare

I m using glassfish 3.1.1 (Edition 3.1 (build 43)) server. I have deployed a web application named "void"

Now i have made a virtual server where in the hosts i have written

$

{com.sun.aas.hostName}

,pradyut.dyndns.org

in network listeners i have chosen

http-listener-1

in the default web module i have chosen the web applcation named "void"

Now there are two issues:

1) Whenever i restart the server the http-sevice-1 goes offline and at every request dumps the stack trace: -

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

SEVERE: PWC3989: An exception or error occurred in the container during the request processing
java.lang.ClassCastException: com.sun.grizzly.config.ContextRootInfo cannot be cast to org.apache.catalina.Context
at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:515)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:267)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)

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

The solution is to

1) Undeploy the application void.
2) Delete the virtual server defined for "void"
3) Restart the server.
4) Deploy application void

There were no issues like this in glassfish 3.0.1 without the clustering(as i remember).

The second problem is whenever i make a virtual server i get the error:-

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

INFO: webContainer.virtual-server.loadedDefaultWebModule
SEVERE: WEB0163: Exception processing HttpService configuration change
org.apache.catalina.LifecycleException: java.lang.Exception: No context matching /void deployed on virtual server void
at com.sun.enterprise.web.WebContainer.updateDefaultWebModule(WebContainer.java:2034)
at com.sun.enterprise.web.WebContainer.updateHost(WebContainer.java:2916)
at com.sun.enterprise.web.WebContainer.updateHttpService(WebContainer.java:3047)
at com.sun.enterprise.web.reconfig.WebConfigListener$1.changed(WebConfigListener.java:159)
at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:332)
at com.sun.enterprise.web.reconfig.WebConfigListener.changed(WebConfigListener.java:114)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:379)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:369)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:259)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:257)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.Exception: No context matching /void deployed on virtual server void
at com.sun.grizzly.util.http.mapper.Mapper.addDefaultContext(Mapper.java:795)
at com.sun.grizzly.util.http.mapper.Mapper.setDefaultContextPath(Mapper.java:759)
at com.sun.enterprise.web.WebContainer.updateDefaultWebModule(WebContainer.java:2026)
... 14 more

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

I have not got any solution to the virtual server nightmare. If you cannot replicate the above error, end the sever process from the OS task manager. then start and try.

thanks
Pradyut



 Comments   
Comment by Cheng Fang [ 10/Jul/11 ]

Assign to web-container.

Comment by Shing Wai Chan [ 11/Jul/11 ]

I have tried the following two scenarios:

Scenario 1:
1. deploy void.war
2. use admin console to modify the virtual server "server" with additional host name, use only http-listener-1, set default web module to "void" (as described above)

Then it works with and without restart the server.

Scenario 2:
1. deploy void.war
2. use admin console to create a new virtual server vs1 with additional host, name, use only http-listener.
3. use admin console to add vs1 as additional virtual server target for the application "void".
4. use admin console to set default web module to "void" in "vs1"

Then it does not work. But it works after restarting the server.

Comment by Shing Wai Chan [ 11/Jul/11 ]

Note that I do not see exception mentioned above in 3.1.1:

java.lang.ClassCastException: com.sun.grizzly.config.ContextRootInfo cannot be cast to org.apache.catalina.Context
at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:515)

In 3.1.1, line 515 of CoyoteAdapter is

        if (context instanceof ContextRootInfo) {
Comment by Amy Roh [ 12/Jul/11 ]

Which version are you using? I tried scenario 2 and both 3.1 final and 3.1.1 b11 (the latest build) works for me without restarting the server.

Please attach your domain.xml that does not work so I can compare with mine.

Comment by Amy Roh [ 12/Jul/11 ]

working domain.xml after

1. deploy hello.war
2. use admin console to create a new virtual server vs1 with additional hostname, use only http-listener.
3. use admin console to add vs1 as additional virtual server target for the application "hello".
4. use admin console to set default web module to "hello" in "vs1"

Comment by pradyut [ 12/Jul/11 ]

We have to restart the server after making a virtual server which should be rectified as
i cannot access my server from a url(pradyut.dyndns.org) after making a virtual server.
After i press save in the "edit virtual server" in the admin console it throws a stack dump:-
=============================================================================================================
SEVERE: WEB0163: Exception processing HttpService configuration change
org.apache.catalina.LifecycleException: java.lang.Exception: No context matching /void deployed on virtual server void
at com.sun.enterprise.web.WebContainer.updateDefaultWebModule(WebContainer.java:2034)
at com.sun.enterprise.web.WebContainer.updateHost(WebContainer.java:2916)
at com.sun.enterprise.web.reconfig.WebConfigListener$1.changed(WebConfigListener.java:136)
at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:332)
at com.sun.enterprise.web.reconfig.WebConfigListener.changed(WebConfigListener.java:114)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:379)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:369)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:259)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:257)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.Exception: No context matching /void deployed on virtual server void
at com.sun.grizzly.util.http.mapper.Mapper.addDefaultContext(Mapper.java:795)
at com.sun.grizzly.util.http.mapper.Mapper.setDefaultContextPath(Mapper.java:759)
at com.sun.enterprise.web.WebContainer.updateDefaultWebModule(WebContainer.java:2026)
... 13 more
=============================================================================================================
It cannot find the web application named "void" already deployed.
It returns a 500 internal server when i access from a url(pradyut.dyndns.org) without throwing any stack dump before
i redeploy the application void or i restart the server .

This should be rectified as this is fault in all the versions of glassfish

Comment by pradyut [ 12/Jul/11 ]

end the running server process from the OS task manager and i think this error will come up.

java.lang.ClassCastException: com.sun.grizzly.config.ContextRootInfo cannot be cast to org.apache.catalina.Context
at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:515)

Comment by Amy Roh [ 21/Jul/11 ]

Can you attach your domain.xml and server.log? I am not able to reproduce your errors and the scenario described is working for me.

Comment by Amy Roh [ 25/Jul/11 ]

You will not get the "No context matching /void deployed on virtual server void" error if you add "void" as additional virtual server target for the application "void" first. If you don't, you'll get the exception in the server.log since the "void" application isn't available for the "void" virtual server. Either way, I am able to access the default web module via http://newhost:8080 once I edit the new virtual server's default web module.

INFO: webContainer.virtual-server.loadedDefaultWebModule
SEVERE: WEB0163: Exception processing HttpService configuration change
org.apache.catalina.LifecycleException: java.lang.Exception: No context matching /void deployed on virtual server void

Comment by pradyut [ 24/Oct/11 ]

I m still geting the error on saving a virtual server although i can access the from the domains mentioned in hosts

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

SEVERE: WEB0163: Exception processing HttpService configuration change
org.apache.catalina.LifecycleException: java.lang.Exception: No context matching /void deployed on virtual server void
at com.sun.enterprise.web.WebContainer.updateDefaultWebModule(WebContainer.java:2054)
at com.sun.enterprise.web.WebContainer.updateHost(WebContainer.java:2933)
at com.sun.enterprise.web.reconfig.WebConfigListener$1.changed(WebConfigListener.java:138)
at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:332)
at com.sun.enterprise.web.reconfig.WebConfigListener.changed(WebConfigListener.java:114)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:401)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:391)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:281)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:279)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.Exception: No context matching /void deployed on virtual server void
at com.sun.grizzly.util.http.mapper.Mapper.addDefaultContext(Mapper.java:795)
at com.sun.grizzly.util.http.mapper.Mapper.setDefaultContextPath(Mapper.java:759)
at com.sun.enterprise.web.WebContainer.updateDefaultWebModule(WebContainer.java:2046)
... 13 more

SEVERE: PWC6117: File "C%3A%5CUsers%5CPradyut%5C.netbeans%5C7.0%5Cconfig%5CGF3%5Cdomain1%5Cdocroot%5Cvoid%5Cnew_shout.jsp" not found
INFO: Portable JNDI names for EJB AnotherBean : [java:global/void/AnotherBean!enew.AnotherBean, java:global/void/AnotherBean]
INFO: Portable JNDI names for EJB NewSessionBean : [java:global/void/NewSessionBean!enew.NewSessionBean, java:global/void/NewSessionBean]
INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.
INFO: WEB0671: Loading application [void] at [/void]
INFO: CORE10010: Loading application void done in 1,532 ms

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

after restarting the server the environement is not loaded, i cannot access localhost from web browser though admin console at localhost:4848 is accessible.
I get the error:-

================================================================================================================================================
SEVERE: PWC3989: An exception or error occurred in the container during the request processing
java.lang.ClassCastException: com.sun.grizzly.config.ContextRootInfo cannot be cast to org.apache.catalina.Context
at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:529)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:271)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:722)

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

Comment by pradyut [ 24/Oct/11 ]

server log file attached.

Comment by Amy Roh [ 24/Oct/11 ]

1. Can you attach your domain.xml? I need to understand your configuration exactly since I can't seem to reproduce the issue.

2. Can you try with 3.1.2 and see if the issue still exists?





[GLASSFISH-17005] list-secure-admin-principals and list-secure-admin-internal-users both incorrectly prompt for a command operand Created: 08/Jul/11  Updated: 02/Dec/11  Resolved: 21/Jul/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1.1, 3.1.2_b02, 4.0
Fix Version/s: 3.1.2_b02, 4.0

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

Tags: 3_1-next, 3_1-next_release-note-added, 3_1-next_release-notes, 3_1_1-scrubbed

 Description   

The list-secure-admin-principals and list-secure-admin-internal-users commands both incorrectly prompt for a command operand. In contrast, they should not – these commands should list all of the respective elements.

The problem is that I incorrectly specified a resolver for the two list commands in the CRUD notation.

This is certainly not a show-stopper for 3.1.1 release. Relatively few users will create secure admin principals or secure admin internal users, so few will need to list them. As a workaround, users can use

asadmin get secure-admin.secure-admin-principal.*

or

asadmin get secure-admin.secure-admin-internal-user.*

In both cases, if no such items are defined then the user gets a message like this:

remote failure: Dotted name path secure-admin.secure-admin-internal-user.* not found.
Command get failed.

which is ugly but it conveys correct information.

I have marked this for review in case others feel strongly that this is in-your-face enough to warrant a fix at this point.

Why fix this issue in 3.1.1?
Although there is a workaround, the error is very in-your-face.

Which is the targeted build of 3.1.1 for this fix?
If approved, b11.

Do regression tests exist for this issue?
not yet

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
Tests involving enabling secure admin; the CRUD list functionality should be fully insulated from other code paths.



 Comments   
Comment by scatari [ 09/Jul/11 ]

Tim,
Please attach the code changes for review.

Thanks

Comment by Tim Quinn [ 09/Jul/11 ]

Here are the code changes. In both cases I have removed the "resolver" setting for the @Listing anno.

Index: src/main/java/com/sun/enterprise/config/serverbeans/SecureAdmin.java
===================================================================
— src/main/java/com/sun/enterprise/config/serverbeans/SecureAdmin.java (revision 47947)
+++ src/main/java/com/sun/enterprise/config/serverbeans/SecureAdmin.java (working copy)
@@ -70,13 +70,13 @@
@Element
@Create(value="enable-secure-admin-principal", decorator=SecureAdminPrincipal.CrDecorator.class, i18n=@I18n("enable.secure.admin.principal.command"))
@Delete(value="disable-secure-admin-principal", resolver=SecureAdminPrincipal.Resolver.class, i18n=@I18n("disable.secure.admin.principal.command"))

  • @Listing(value="list-secure-admin-principals", resolver=SecureAdminPrincipal.Resolver.class, i18n=@I18n("list.secure.admin.principals.command"))
    + @Listing(value="list-secure-admin-principals", i18n=@I18n("list.secure.admin.principals.command"))
    public List<SecureAdminPrincipal> getSecureAdminPrincipal();

@Element
@Create(value="enable-secure-admin-internal-user", decorator=SecureAdminInternalUser.CrDecorator.class, i18n=@I18n("enable.secure.admin.internal.user.command"))
@Delete(value="disable-secure-admin-internal-user", resolver=TypeAndNameResolver.class, i18n=@I18n("disable.secure.admin.internal.user.command"))

  • @Listing(value="list-secure-admin-internal-users", resolver=TypeAndNameResolver.class, i18n=@I18n("list.secure.admin.internal.user.command"))
    + @Listing(value="list-secure-admin-internal-users", i18n=@I18n("list.secure.admin.internal.user.command"))
    public List<SecureAdminInternalUser> getSecureAdminInternalUser();

/**

Comment by scatari [ 11/Jul/11 ]

Tim,
Although the changes look okay, let us defer this to the next release given how close we are to producing a FCS candidate build. Thanks for your understanding and appreciate your efforts to improve 3.1.1 quality. I have already marked them with appropriate tags.

Thanks

Comment by Tim Quinn [ 21/Jul/11 ]

Fixed in trunk.

Project: glassfish
Repository: svn
Revision: 48036
Author: tjquinn
Date: 2011-07-14 21:37:25 UTC
Link:

Log Message:
------------
Check-ins for 16437, 16438, 16545

These changes enhance secure admin so that users can

1. enable multiple certificates as authorized for admin operations
2. have GlassFish processes authenticate to each other using an admin username and password instead of certificates
3. stronger checking that admin messages from other GlassFish processes are from servers in the same domain.

Approved for 3.1.1: Sathyan
Tests: QL, deployment single-instance and cluster devtests

Revisions:
----------
48036

Modified Paths:
---------------
trunk/v3/common/container-common/src/main/java/com/sun/enterprise/container/common/LocalStrings.properties
trunk/v3/common/container-common/src/main/java/com/sun/enterprise/container/common/GenericAdminAuthenticator.java
trunk/v3/security/core/src/main/java/com/sun/enterprise/security/admin/cli/DisableSecureAdminCommand.java
trunk/v3/security/core/src/main/java/com/sun/enterprise/security/admin/cli/EnableSecureAdminCommand.java
trunk/v3/security/core/src/main/resources/com/sun/enterprise/security/admin/cli/LocalStrings.properties
trunk/v3/security/core/src/main/java/com/sun/enterprise/security/admin/cli/SecureAdminCommand.java
trunk/v3/core/kernel/src/main/java/com/sun/enterprise/v3/admin/AdminAdapter.java
trunk/v3/admin/util/src/main/java/com/sun/enterprise/admin/remote/ServerRemoteAdminCommand.java
trunk/v3/admin/config-api/src/main/java/com/sun/enterprise/config/serverbeans/LocalStrings.properties
trunk/v3/admin/config-api/src/main/java/com/sun/enterprise/config/serverbeans/SecureAdmin.java
trunk/v3/admin/util/src/main/java/com/sun/enterprise/admin/remote/RemoteAdminCommand.java
trunk/v3/admin/config-api/src/main/java/com/sun/enterprise/config/serverbeans/SecureAdminPrincipal.java

Added Paths:
------------
trunk/v3/security/core/src/main/java/com/sun/enterprise/security/admin/cli/SecureAdminHelperImpl.java
trunk/v3/admin/config-api/src/main/java/com/sun/enterprise/config/serverbeans/SecureAdminHelper.java
trunk/v3/admin/config-api/src/main/java/com/sun/enterprise/config/serverbeans/SecureAdminInternalUser.java

Comment by Tim Quinn [ 19/Aug/11 ]

Fix for 3.1.2 checked in.

Project: glassfish
Repository: svn
Revision: 48936
Author: tjquinn
Date: 2011-08-19 22:20:09 UTC
Link:

Log Message:
------------
Fix for 17005

In 3.1.1 we added enable- and disable-secure-admin-[principal | internal-user] commands. We also added the corresponding list-xxx commands but they incorrectly demand a command operand.

This check-in fixes that problem with the list-secure-admin-principals and list-secure-admin-internal-users commands.

Revisions:
----------
48936

Modified Paths:
---------------
branches/3.1.2/admin/config-api/src/main/java/com/sun/enterprise/config/serverbeans/SecureAdmin.java

Comment by Tim Quinn [ 18/Oct/11 ]

Updating "fixed in" field.

Comment by Tim Quinn [ 18/Oct/11 ]

Adding 3.1.2-b2 as a fixed-in build to reflect the earlier fix check-in for 3.1.2.

Comment by Tim Quinn [ 18/Oct/11 ]

By virtue of being fixed in then-3.2 this is also fixed in 4.0.

Comment by Tim Quinn [ 18/Oct/11 ]

Restoring original "affects" list which I accidentally changed.





[GLASSFISH-16999] Either PKG_CLIENT_READ_TIMEOUT is too small or Oracle's servers are too slow Created: 08/Jul/11  Updated: 06/Nov/12

Status: Reopened
Project: glassfish
Component/s: update_center
Affects Version/s: 3.1
Fix Version/s: None

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

Win7 Pro SP1 64 Bit de_DE


Issue Links:
Dependency
depends on UPDATECENTER2-2197 Increase PKG_CLIENT_READ_TIMEOUT in J... Closed
Tags: 3_1-next, 3_1-next_release-note, 3_1-next_release-note-added, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

Installation of update tool fails due to timeout (every time we tried it in the past seven days). Either the timeouts programmed into the installer are too small, or Oracle's servers providing the downloads are too slow.

Sometimes no connection at all is possible, but most of the time the download fails:

Proxy: Using system proxy settings.
Install image: C:\glassfish3
Installing updatetool packages.
Downloading 2 packages.
Downloading updatetool (564 files, 4.630.541 bytes).
File 564/564
Downloading wxpython2.8-minimal (346 files, 13.763.618 bytes).
File 46/346Input/output error: Read timed out

Could not download application packages. This could be because:

  • a proxy server is needed to access the internet. Please ensure that
    the system proxy server settings in your Internet Options control panel
    (under Connections:LAN Settings) are correct, or set the HTTP_PROXY
    environment variable to the full URL of the proxy server.
  • the package server is down or otherwise inaccessible or it is
    generating invalid data. Please contact the provider of the package
    server.

The negative side effect is that the graphical installer which internally tries to do this download will fail without clearly telling that actual cause of the problem (just says it cannot install the update tool), so people don't know what to do!

When increasing the timeout we could install without any problem, so this clearly proofs that either the default timeout is too small or Oracle's servers are just too slow. There is nothing wrong with our internet connection and while the download fails, a test drive proofs a FREE bandwith of 1,5 Mb/s (so it is not related to our infrastructure or net access).

C:\>set PKG_CLIENT_CONNECT_TIMEOUT=300
C:\>set PKG_CLIENT_READ_TIMEOUT=300

Proxy: Using system proxy settings.
Install image: C:\glassfish3
Installing updatetool packages.
Downloading 2 packages.
Downloading updatetool (564 files, 4.630.541 bytes).
File 564/564
Downloading wxpython2.8-minimal (346 files, 13.763.618 bytes).
File 346/346
Executing 1.095 install actions.
Registering notifier: Not able to register. Returned exit code 3.
Starting notifier.
Initialization complete.

Please either upgrade your download facilities or increase the default timeouts.

But in any case, please provide a clear message to the user that it is not HIS fault, particularly in the graphical installer.

We have rated this bug as CRITICAL since it prevents a successful complete default installation using the graphical installer.



 Comments   
Comment by Joe Di Pol [ 08/Jul/11 ]

This requires a change to the Update Center bootstrap Java client. I've created UPDATECENTER2-2197 to track that change.

Comment by Joe Di Pol [ 08/Jul/11 ]

This is too late to fix in 3.1.1. I've tagged for inclusion in the Release Notes. We should state that if the installation of update center fails in the installer (or if it fails when running 'pkg' or 'updatetool' from the command line the first time) the user should try the following from the command line:

C:\>set PKG_CLIENT_CONNECT_TIMEOUT=300
C:\>set PKG_CLIENT_READ_TIMEOUT=300
C:\>glassfish3\bin\updatetool

This will bootstrap updatetool using the increased timeouts.

Comment by mkarg [ 11/Jul/11 ]

Looking at the long timeout values needed, I would say this is not a problem of too small timouts, but more of too slow Oracle servers. And, it would be much better for Oracle's reputation to set up more machines instead of asking a user to try again with ridiculously large timeout values.

Comment by Joe Di Pol [ 11/Jul/11 ]

Actually both aspects need to be addressed. The default timeouts should be longer to handle transient network slowness, but I agree we do need to address the operational aspect of this as well.

mkarg, what is your geographic location? Are you located in Germany?

Comment by Rebecca Parks [ 11/Jul/11 ]

Added the following to the 3.1.1 Release Notes:

PKG_CLIENT_READ_TIMEOUT is too small (16999)

Description

Installation of the Update Center sometimes times out and fails.

Workaround

If Update Center installation fails in the installer or when running pkg or updatetool from the command line, enter the following from the command line:

> set PKG_CLIENT_CONNECT_TIMEOUT=300
> set PKG_CLIENT_READ_TIMEOUT=300
> glassfish3\bin\updatetool

Comment by mkarg [ 12/Jul/11 ]

Joe,

yes I am located in Germany. Our overall connectivity to US servers is great, but especially Oracle pages are getting served rather slow. Maybe Oracle Germany could set up some local mirror to overcome this issue?

Regards
Markus

Comment by mkarg [ 13/Jul/11 ]

Just tried out the graphical installer of 3.1.1_b11 having set the above environment variables. In fact, the installer runs well then, but it needs about half an hour to install. In all that time, the progress bar shows 41%. I expect most people to kill that process...

Comment by Joe Di Pol [ 16/Nov/11 ]

The update center bug to increase the client timeouts has been implemented, and we've increased the number of download threads in the client as well. This will mitigate the problem some, but we still have the issue that our IPS package servers are not mirrored geographically which means non-US locations will continue to see slower download speeds (the IPS repository protocol is sensitive to latency in addition to bandwidth).





[GLASSFISH-16998] Secure OSGi shell port Created: 08/Jul/11  Updated: 04/Oct/12  Resolved: 04/Oct/12

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

Type: New Feature Priority: Minor
Reporter: Sanjeeb Sahoo Assignee: Sanjeeb Sahoo
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Attachments: Text File secure-felix-shell.trunk.patch    
Issue Links:
Related
is related to GLASSFISH-13006 Provide way to turn off OSGi shell Resolved
is related to GLASSFISH-19124 [OSGi] Create an asadmin local comman... Resolved
Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-19228 Update documentation for using osgi c... Sub-task Resolved Gail Risdal  
Tags: 3_1-next, 3_1_1-scrubbed

 Description   

See GLASSFISH-13006 for more details. 3.1.1 release manager wants us to open a new bug closing existing GLASSFISH-13006 as that shows up in their query although that's no longer applicable for 3.1.1.



 Comments   
Comment by Sanjeeb Sahoo [ 10/Aug/11 ]

Turned it into an RFE since I have disabled the shell in trunk as well in svn rev #48678.

Comment by Sanjeeb Sahoo [ 07/Feb/12 ]

Vijay,

Could you please look into this next?

Sahoo

Comment by ancoron [ 30/Sep/12 ]

Attached a patch (secure-felix-shell.trunk.patch) to introduce an asadmin CLI bridge for accessing the Gogo/Felix shell (works with both).

This patch essentially does the following:

  1. introduce a remote command ("felix") to access the OSGi shell on a specific server instance (in "appserver/osgi-platforms/felix-cli-remote")
  2. introduce a local command ("felix-shell") to access the OSGi shell with an interactive/multimode frontend (in "appserver/osgi-platforms/felix-cli-interactive")
  3. modify "nucleus/packager/nucleus-osgi" to drop the old remote shell artifact inclusion
  4. modify "appserver/packager/glassfish-osgi" to include the new artifacts
  5. modify "osgi.properties" in "nucleus/osgi-platforms/felix" to replace standard remote shell with new remote command and advance default final startlevel to 3

As this approach does inherit all the security attributes from the asadmin infrastructure it should be safe to assume that the requirements are fulfilled. Also, this command allows to access a specific remote system (DAS being the default) and hence should still keep up with developer needs.

Also nice for system integrators is to know that with this approach there is one port less to secure.

Copyright on this contribution is granted as per the OCA and source files should all comply to this.

Comment by Sanjeeb Sahoo [ 04/Oct/12 ]

Ancoron,

Thank you very much for this great quality patch. In this bug, I am going to incorporate the remote command only. I have opened a new issue called GLASSFISH-19124 to incorporate the local command. Pl see that issue for the exact reason behind this split.

I will also refactor the command name to osgi and osgi-shell instead of felix and felix-shell respectively. The modules will be added in nucleus instead of appserver distributions.

Sahoo

Comment by Sanjeeb Sahoo [ 04/Oct/12 ]

As said earlier, I am committing the patch related to the remote command.
r56267 | ss141213 | 2012-10-05 03:34:23 +0530 (Fri, 05 Oct 2012)

GLASSFISH-16998: Secure OSGi shell port.
Adding osgi-remote-cli module which introduces a remote command called osgi that can be used
to invoke a single osgi shell command.

Patch contributed by Ancoron, I have just made some refactoring.





[GLASSFISH-16984] GlassFish v3.1 is chatty like a fish wife, still... Created: 07/Jul/11  Updated: 08/Jan/12  Resolved: 04/Nov/11

Status: Closed
Project: glassfish
Component/s: logging
Affects Version/s: 3.1
Fix Version/s: 3.1.2_b07, 4.0

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

Win7 Pro SP1 64 Bit de_DE


Issue Links:
Dependency
blocks GLASSFISH-18142 JVM invocation command line is no lon... Closed
Tags: 3_1-next, 3_1_1-scrubbed

 Description   

After asadmin start-domain and logging into the browser console, the log file looks like this (remember, the admin did NOTHING but perform a default installation):

(Yes, please read ALL of them to get a feeling of the common Administrator's daily job!)

07.07.2011 14:38:36 com.sun.enterprise.admin.launcher.GFLauncherLogger info
INFO: JVM invocation command line:
C:\Program Files (x86)\Java\jdk1.6.0_26\bin\java.exe
-cp
C:/glassfish3/glassfish/modules/glassfish.jar
-XX:+UnlockDiagnosticVMOptions
-XX:MaxPermSize=192m
-XX:NewRatio=2
-Xmx512m
-javaagent:C:/glassfish3/glassfish/lib/monitor/btrace-agent.jar=unsafe=true,noServer=true
-client
-Dosgi.shell.telnet.maxconn=1
-Dfelix.fileinstall.disableConfigSave=false
-Djdbc.drivers=org.apache.derby.jdbc.ClientDriver
-Dfelix.fileinstall.dir=C:\glassfish3\glassfish/modules/autostart/
-Djavax.net.ssl.keyStore=C:\glassfish3\glassfish\domains\domain1/config/keystore.jks
-Dosgi.shell.telnet.port=6666
-Djava.security.policy=C:\glassfish3\glassfish\domains\domain1/config/server.policy
-Dfelix.fileinstall.log.level=2
-Dfelix.fileinstall.poll=5000
-Dcom.sun.aas.instanceRoot=C:\glassfish3\glassfish\domains\domain1
-Dosgi.shell.telnet.ip=127.0.0.1
-Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise.config.serverbeans.AppserverConfigEnvironmentFactory
-Djava.endorsed.dirs=C:\glassfish3\glassfish/modules/endorsed;C:\glassfish3\glassfish/lib/endorsed
-Dcom.sun.aas.installRoot=C:\glassfish3\glassfish
-Dfelix.fileinstall.bundles.startTransient=true
-Djava.ext.dirs=C:\Program Files (x86)\Java\jdk1.6.0_26/lib/ext;C:\Program Files (x86)\Java\jdk1.6.0_26/jre/lib/ext;C:\glassfish3\glassfish\domains\domain1/lib/ext
-Dfelix.fileinstall.bundles.new.start=true
-Djavax.net.ssl.trustStore=C:\glassfish3\glassfish\domains\domain1/config/cacerts.jks
-Dorg.glassfish.additionalOSGiBundlesToStart=org.apache.felix.shell,org.apache.felix.gogo.runtime,org.apache.felix.gogo.shell,org.apache.felix.gogo.command
-Dcom.sun.enterprise.security.httpsOutboundKeyAlias=s1as
-Djava.security.auth.login.config=C:\glassfish3\glassfish\domains\domain1/config/login.conf
-DANTLR_USE_DIRECT_CLASS_LOADING=true
Dgosh.args=-nointeractive
-Djava.library.path=C:/Program Files/SQL Anywhere 11/Bin32;C:/glassfish3/glassfish/lib;C:/Program Files (x86)/Java/jdk1.6.0_26/bin;C:/Windows/Sun/Java/bin;C:/Windows/System32;C:/Windows;C:/glassfish3/bin;C:/Program Files/Common Files/Microsoft Shared/Windows Live;C:/Program Files (x86)/Common Files/microsoft shared/Windows Live;C:/Program Files (x86)/CollabNet/Subversion Client;C:/Windows/System32/wbem;C:/Windows/System32/WindowsPowerShell/v1.0;C:/Program Files (x86)/Common Files/Roxio Shared/DLLShared;C:/Program Files (x86)/Common Files/Roxio Shared/10.0/DLLShared;C:/Program Files/TortoiseSVN/bin;C:/Program Files/SQL Anywhere 11/Bin64;C:/Program Files (x86)/curl-7.21.0-ssl-sspi-zlib-static-bin-w32;C:/Programme/apache-ant-1.8.1/bin;C:/Program Files/apache-maven-3.0.2/bin;C:/Program Files/Java/jdk1.6.0_26/bin;C:/Program Files (x86)/Windows Live/Shared;C:/Program Files (x86)/CodeMeter/DevKit/bin
com.sun.enterprise.glassfish.bootstrap.ASMain
-domainname
domain1
-asadmin-args
-host,,,localhost,,,port,,,4848,,,secure=false,,,terse=false,,,echo=false,,,interactive=true,,,start-domain,,,verbose=false,,,debug=false,,,-domaindir,,,C:\glassfish3\glassfish\domains,,,domain1
-instancename
server
-verbose
false
-debug
false
-asadmin-classpath
C:/glassfish3/glassfish/modules/admin-cli.jar
-asadmin-classname
com.sun.enterprise.admin.cli.AsadminMain
-upgrade
false
-type
DAS
-domaindir
C:/glassfish3/glassfish/domains/domain1
-read-stdin
true
07.07.2011 14:38:36 com.sun.enterprise.admin.launcher.GFLauncherLogger info
INFO: Successfully launched in 16 msec.
07.07.2011 14:38:38 null
INFO: Running GlassFish Version: GlassFish Server Open Source Edition 3.1 (build 43)
[#|2011-07-07T14:38:38.479+0200|INFO|glassfish3.1|org.glassfish.ha.store.spi.BackingStoreFactoryRegistry|_ThreadID=10;_ThreadName=Thread-1;|Registered org.glassfish.ha.store.adapter.cache.ShoalBackingStoreProxy for persistence-type = replicated in BackingStoreFactoryRegistry|#]

[#|2011-07-07T14:38:38.697+0200|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.services.impl|_ThreadID=32;_ThreadName=Thread-1;|Grizzly Framework 1.9.31 started in: 78ms - bound to [0.0.0.0:7676]|#]

[#|2011-07-07T14:38:38.697+0200|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.services.impl|_ThreadID=33;_ThreadName=Thread-1;|Grizzly Framework 1.9.31 started in: 93ms - bound to [0.0.0.0:4848]|#]

[#|2011-07-07T14:38:38.697+0200|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.services.impl|_ThreadID=30;_ThreadName=Thread-1;|Grizzly Framework 1.9.31 started in: 109ms - bound to [0.0.0.0:8080]|#]

[#|2011-07-07T14:38:38.697+0200|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.services.impl|_ThreadID=29;_ThreadName=Thread-1;|Grizzly Framework 1.9.31 started in: 93ms - bound to [0.0.0.0:8181]|#]

[#|2011-07-07T14:38:38.697+0200|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.services.impl|_ThreadID=31;_ThreadName=Thread-1;|Grizzly Framework 1.9.31 started in: 93ms - bound to [0.0.0.0:3700]|#]

[#|2011-07-07T14:38:38.713+0200|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.admin.adapter|_ThreadID=1;_ThreadName=Thread-1;|The Admin Console is already installed, but not yet loaded.|#]

[#|2011-07-07T14:38:38.760+0200|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=1;_ThreadName=Thread-1;|GlassFish Server Open Source Edition 3.1 (43) startup time : Felix (1.419ms), startup services(453ms), total(1.872ms)|#]

[#|2011-07-07T14:38:38.931+0200|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=41;_ThreadName=Thread-1;|JMXStartupService: Started JMXConnector, JMXService URL = service:jmx:rmi://MK-Z400.Quipsy.local:8686/jndi/rmi://MK-Z400.Quipsy.local:8686/jmxrmi|#]

[#|2011-07-07T14:40:01.879+0200|INFO|glassfish3.1|org.hibernate.validator.util.Version|_ThreadID=17;_ThreadName=Thread-1;|Hibernate Validator 4.1.0.Final|#]

[#|2011-07-07T14:40:01.879+0200|INFO|glassfish3.1|org.hibernate.validator.engine.resolver.DefaultTraversableResolver|_ThreadID=17;_ThreadName=Thread-1;|Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.|#]

[#|2011-07-07T14:40:02.877+0200|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.services.impl|_ThreadID=70;_ThreadName=Thread-1;|Grizzly Framework 1.9.31 started in: 0ms - bound to [0.0.0.0:8080]|#]

[#|2011-07-07T14:40:03.891+0200|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.services.impl|_ThreadID=74;_ThreadName=Thread-1;|Grizzly Framework 1.9.31 started in: 0ms - bound to [0.0.0.0:8181]|#]

[#|2011-07-07T14:40:03.969+0200|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.admin.adapter|_ThreadID=78;_ThreadName=Thread-1;|The Admin Console is already installed, but not yet loaded.|#]

[#|2011-07-07T14:40:03.969+0200|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.admin.adapter|_ThreadID=78;_ThreadName=Thread-1;|The Admin Console is starting. Please wait.|#]

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

[#|2011-07-07T14:40:05.545+0200|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=78;_ThreadName=Thread-1;|WEB0169: Created HTTP listener [http-listener-1] on host/port [0.0.0.0:8080]|#]

[#|2011-07-07T14:40:05.545+0200|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=78;_ThreadName=Thread-1;|WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]|#]

[#|2011-07-07T14:40:05.545+0200|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=78;_ThreadName=Thread-1;|WEB0169: Created HTTP listener [admin-listener] on host/port [0.0.0.0:4848]|#]

[#|2011-07-07T14:40:05.576+0200|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=78;_ThreadName=Thread-1;|WEB0171: Created virtual server [server]|#]

[#|2011-07-07T14:40:05.576+0200|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=78;_ThreadName=Thread-1;|WEB0171: Created virtual server [__asadmin]|#]

[#|2011-07-07T14:40:06.060+0200|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=78;_ThreadName=Thread-1;|WEB0172: Virtual server [server] loaded default web module []|#]

[#|2011-07-07T14:40:06.356+0200|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security|_ThreadID=78;_ThreadName=Thread-1;|SEC1002: Security Manager is OFF.|#]

[#|2011-07-07T14:40:06.356+0200|INFO|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=21;_ThreadName=Thread-1;|Listening to REST requests at context: /management/domain|#]

[#|2011-07-07T14:40:06.418+0200|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security|_ThreadID=78;_ThreadName=Thread-1;|SEC1010: Entering Security Startup Service|#]

[#|2011-07-07T14:40:06.418+0200|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security|_ThreadID=78;_ThreadName=Thread-1;|SEC1143: Loading policy provider com.sun.enterprise.security.provider.PolicyWrapper.|#]

[#|2011-07-07T14:40:06.450+0200|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=78;_ThreadName=Thread-1;|SEC1115: Realm [admin-realm] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.|#]

[#|2011-07-07T14:40:06.450+0200|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=78;_ThreadName=Thread-1;|SEC1115: Realm [file] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.|#]

[#|2011-07-07T14:40:06.450+0200|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=78;_ThreadName=Thread-1;|SEC1115: Realm [certificate] of classtype [com.sun.enterprise.security.auth.realm.certificate.CertificateRealm] successfully created.|#]

[#|2011-07-07T14:40:06.465+0200|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security|_ThreadID=78;_ThreadName=Thread-1;|SEC1011: Security Service(s) Started Successfully|#]

[#|2011-07-07T14:40:07.448+0200|INFO|glassfish3.1|javax.enterprise.resource.webcontainer.jsf.config|_ThreadID=20;_ThreadName=Thread-1;|Mojarra 2.1.0 (FCS 2.1.0-b11) für Kontext '' wird initialisiert.|#]

[#|2011-07-07T14:40:09.539+0200|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=78;_ThreadName=Thread-1;|WEB0671: Loading application [__admingui] at [/]|#]

[#|2011-07-07T14:40:09.539+0200|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=78;_ThreadName=Thread-1;|CORE10010: Loading application __admingui done in 5.570 ms|#]

[#|2011-07-07T14:40:09.539+0200|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.admin.adapter|_ThreadID=78;_ThreadName=Thread-1;|The Admin Console application is loaded.|#]

[#|2011-07-07T14:40:12.253+0200|WARNING|glassfish3.1|org.apache.catalina.connector.Request|_ThreadID=22;_ThreadName=Thread-1;|PWC4011: Unable to set request character encoding to UTF-8 from context , because request parameters have already been read, or ServletRequest.getReader() has already been called|#]

[#|2011-07-07T14:40:13.535+0200|INFO|glassfish3.1|org.glassfish.admingui|_ThreadID=22;_ThreadName=Thread-1;|Admin Console: Initializing Session Attributes...|#]

[#|2011-07-07T14:40:13.831+0200|WARNING|glassfish3.1|org.glassfish.admingui|_ThreadID=23;_ThreadName=Thread-1;|Cannot create update center Image for C:\glassfish3; Update Center functionality will not be available in Admin Console|#]

I wonder what the typical admin shall do with all this information. Read it? And then?

In comparison, our production database server just prints about FIVE to TEN lines (copyright, IP address, etc.)...!

This is not production grade, this looks like pure debug information for the GlassFish team, not targeting the administrator. But: INFO, WARNING, and ERROR ARE for the Administrator (information for debugging is FINE, FINER, FINEST by definition).

So what to tell the 200 admins now that I am about to ship GFv3.1? How can they find out the information they MUST read?

Proposed solution: Reduce the log levels to FINE for ALL information that is not intended for the Administrator! This is such a log message hell that we must rate this lot of text as one big BUG.



 Comments   
Comment by scatari [ 26/Jul/11 ]

Marking to be fixed in the patch release that follows 3.1.1. Does not affect primary functionality of the product.

Comment by naman_mehta [ 04/Nov/11 ]

Moved unwanted message on start up from info to fine log level.





[GLASSFISH-16958] Administration Console is gone after a while Created: 05/Jul/11  Updated: 21/Jul/11  Resolved: 21/Jul/11

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b11

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

Win7 Pro SP1 64 Bit de_DE


Attachments: File HowToCrashAdminGUI.wmv    
Tags: 3_1-next, 3_1_1-scrubbed

 Description   

Sporadically it happens that administration console is just "gone":

It happened two times in the past day that on http://localhost:4848 the following text is shown:

oracle.com
GlassFish Server 3.1

Your server is now running
To replace this page, overwrite the file index.html in the document root folder of this server. The document root folder for this server is the docroot subdirectory of this server's domain directory.

To manage a server on the local host with the default administration port, go to the Administration Console.

(etc.)

The funny thing is that the the word "Administration Console" actually is a link to http://localhost:4848, so clicking on it shows exactly the same page again.

The server.log does not tell anything about this strange circumstances: Only the usual message are contained that the console was started.



 Comments   
Comment by Anissa Lam [ 05/Jul/11 ]

Please provide more info on how to reproduce this. Sounds like console got undeployed.
What were you doing at that time ? Have you leave it idle for sometime so timeout clickes in ?
so, you restart the server to get back to the console ?
Have you tried clear the browser cache, restart the browser to see how it goes ?

We fixed some issue relating to timeout in 3.1.1.
If you can try the latest promoted build http://dlc.sun.com.edgesuite.net/glassfish/3.1.1/promoted/ and see if you are still seeing that, that will help.

Comment by Anissa Lam [ 05/Jul/11 ]

Since we have passed HCF and there is no easy way to reproduce this, (I have tried and also never seen this before), I am targeting this for 3.2.

Comment by mkarg [ 06/Jul/11 ]

Meanwhile we are two people over here having had that problem, so it seems it is not dependend on my local installation. Both are using Win7 Pro SP1 64 Bit de_DE, installed using the GlassFish Installer EXE for Windows (EN, not ML).

It seems there is no clear way to reproduce it, as it happens sporadically, but we both have a strong feeling that it is a combination of doing asadmin undeploy on our own EAR after leaving the GUI open for a while in the browser.

Just a minute ago I managed to reproduce the problem with the following sequence, but I am not sure whether this will ALWAYS reproduce it:

asadmin start-domain
Open http://localhost:4848 in browser
Click on "Applications" node to see installed EARs (there are none)
Do NOT close browser or click somewhere.
asadmin deploy MyApp.ear
In the already opened browser, once more click on "Applications" (now "MyApp" is shown).
Do NOT close browser or click somewhere.
asadmin undeploy MyApp
In the already opened "Applications" view, click on "MyApp" (which is still be seen as the browser did not do an automatic refresh).
The screen now gets corrupted: While most of the screen is intact, some boxes show 404.
Click on the "Applications" node again (now the complete screen turns into a 404).
Type "http://localhost:4848" in the adress line of the browser (now you have produced the problem: Browser shows "Your server is running").

I was able to reproduce this (at least) two times in a row, without notable waiting times (so it cannot be a timeout).

It is neither a browser nor cache problem. After detecting that IE9 presented that "Your server is running" screen instead of the admin GUI, I opened Firefox and got the same screen. So the server seems to actively sent it to both browsers (I never used Firefox with GFv3 before, so it cannot be taken out of Firefox's cache).

An explicit cache clear (F5 key) does not solve the problem.

After doing asadmin stop-domain followed by asadmin start-domain, still the "wrong" screen is shown, but THEN a cache clear (F5 key) DOES solve the problem and restarts the GUI.

About the target release of this bug report I need to say that for a production grade system this is an unacceptable showstopper (as one has to stop the server to solve it) and such should prevent publication of 3.1.1 without fixing it.

If you still cannot reproduce even with above steps, please let me know. I then will download and try with latest 3.1.1 promo.

Comment by Anissa Lam [ 07/Jul/11 ]

Thanks for the detail steps.
I am trying with my build of 3.1.1, which has the latest code, and cannot reproduce the problem on my Mac.
I have a very strong feeling that this is related to GLASSFISH-16223 and GLASSFISH-16112.
Undeploying an application (JSF in that case) may bring down the console.
Since 3.1 is released, the application deployment code in GUI in 3.1.1 has been rewritten to also use REST and those problem is resolved.
Since it sounds like you are seeing this quite often, please see if you can reproduce this with latest 3.1.1 promoted build , available at http://dlc.sun.com.edgesuite.net/glassfish/3.1.1/promoted/

Comment by mkarg [ 11/Jul/11 ]

I will try RC1 as soon as it got published.

Comment by mkarg [ 13/Jul/11 ]

Tried again using GFv3.1.1_b11 and the problem still exists.

In fact it looks like it even got worse, as virtually after every fifth simple undeploy-deploy cycle the GUI is gone now.

Comment by Anissa Lam [ 13/Jul/11 ]

I still cannot reproduce the problem on my Mac.
Can you please attach the application you are using to reproduce the problem ?

Comment by mkarg [ 14/Jul/11 ]

Can you please request SuperSimple.ear from Tim Quinn (tjquinn)? He has permission to share it with all Oracle employees for cases liket his one (but please erase file after case is solved, as this EAR is confidential closed source).

Comment by Anissa Lam [ 14/Jul/11 ]

sure, I will work with Tim on this.

Comment by Anissa Lam [ 14/Jul/11 ]

One question. Can you reproduce the problem if you just use repeatedly using asadmin (CLI) to deploy/undeploy your application ?

Comment by Anissa Lam [ 14/Jul/11 ]

Obtained SuperSimple.ear from Tim, however, even after creating the required JDBC resource, I get errors relating to persistence and deployment failed.
I need instructions on what needs to be performed first before deploying the app.

Comment by mkarg [ 15/Jul/11 ]

It shouldn't be necessary to make the application really "work" (i. e. find the needed resources) for this issue – I did not create most of that resources (and get the same warnings) but this issues can be reproduced, though. But if you like you can create the needed resources. This template should tell you the seetings you need to mannually do (the EAR does not check java:app, so the file does not solve by itself):

<resources>
<connector-connection-pool name="QUIPSY_KERNEL" resource-adapter-name="SuperSimple#KernelConnector" connection-definition-name="de.quipsy.connector.kernel.api.outbound.KernelConnectionFactory" ping="true" />
<connector-resource jndi-name="QUIPSY_KERNEL" pool-name="QUIPSY_KERNEL" />
<jdbc-connection-pool name="QUIPSY4" datasource-classname="ianywhere.ml.jdbcodbc.jdbc3.ASADataSource" ping="true">
<property name="URL" value="jdbc:ianywhere:DSN=QUIPSY 4 DBFILE" />
</jdbc-connection-pool>
<jdbc-resource jndi-name="jdbc/QUIPSY/5" pool-name="QUIPSY4" />
<mail-resource jndi-name="QUIPSY_MAIL" host="your-server" user="anissa" from="anissa" />
<admin-object-resource res-adapter="jmsra" res-type="javax.jms.ConnectionFactory" jndi-name="QUIPSY_CONNECTION_FACTORY">
<property name="MaxPoolSize" value="1000" />
</admin-object-resource>
<admin-object-resource res-adapter="jmsra" res-type="javax.jms.Topic" jndi-name="QUIPSY_TOPIC">
<property name="PhysicalDestinationName" value="QUIPSY_TOPIC" />
</admin-object-resource>
</resources>

Comment by mkarg [ 15/Jul/11 ]

Anissa: "One question. Can you reproduce the problem if you just use repeatedly using asadmin (CLI) to deploy/undeploy your application ?"

I always only use asadmin deploy and undeploy at CLI, not using any other means of deployment. So the answer is: YES.

Comment by Anissa Lam [ 18/Jul/11 ]

I thought you have been using GUI to deploy and undeploy and after couple times, console is no longer available.
So, this bug is saying, using asadmin deploy/undeploy superSimple.ear several times, you cannot access the admin console. No wonder you said GUI fix for GLASSFISH-16223 and GLASSFISH-16112 has no effect for you, since those changes the GUI code in application deployment, but you are not using GUI to do the deployment at all.

Comment by Anissa Lam [ 18/Jul/11 ]

I can't get SuperSimple.ear to deploy, even after i created the resource one by one that deploy complains.
Here is what i did:

~/Sun/v3/3.1.1/pb11/glassfish/bin 27)  ./asadmin deploy ~/DeployApp/bug16958/SuperSimple.ear

remote failure: Error occurred during deployment: Exception while preparing the app : Invalid resource : jdbc/QUIPSY/5__pm. Please see server.log for more details.
Exception while invoking class org.glassfish.persistence.jpa.JPADeployer prepare method : java.lang.RuntimeException: Invalid resource : jdbc/QUIPSY/5__pm
Invalid resource : jdbc/QUIPSY/5__pm
Command deploy failed.
~/Sun/v3/3.1.1/pb11/glassfish/bin 28)  
~/Sun/v3/3.1.1/pb11/glassfish/bin 28)  
~/Sun/v3/3.1.1/pb11/glassfish/bin 28)  ./asdmin create-jdbc-resource --connectionpoolid __TimerPool jdbc/QUIPSY/5__pm
-bash: ./asdmin: No such file or directory
~/Sun/v3/3.1.1/pb11/glassfish/bin 29)  ./asadmin create-jdbc-resource --connectionpoolid __TimerPool jdbc/QUIPSY/5__pm
JDBC resource jdbc/QUIPSY/5__pm created successfully.
Command create-jdbc-resource executed successfully.
~/Sun/v3/3.1.1/pb11/glassfish/bin 30)  
~/Sun/v3/3.1.1/pb11/glassfish/bin 30)  
~/Sun/v3/3.1.1/pb11/glassfish/bin 30)  
~/Sun/v3/3.1.1/pb11/glassfish/bin 30)  ./asadmin deploy ~/DeployApp/bug16958/SuperSimple.ear

remote failure: Error occurred during deployment: Exception while preparing the app : Invalid resource : jdbc/QUIPSY/5__nontx. Please see server.log for more details.
Exception while invoking class org.glassfish.persistence.jpa.JPADeployer prepare method : java.lang.RuntimeException: Invalid resource : jdbc/QUIPSY/5__nontx
Invalid resource : jdbc/QUIPSY/5__nontx
Command deploy failed.
~/Sun/v3/3.1.1/pb11/glassfish/bin 31)  
~/Sun/v3/3.1.1/pb11/glassfish/bin 31)  ./asadmin list-components
Nothing to list.
Command list-components executed successfully.
~/Sun/v3/3.1.1/pb11/glassfish/bin 32)  
~/Sun/v3/3.1.1/pb11/glassfish/bin 32)  
~/Sun/v3/3.1.1/pb11/glassfish/bin 32)  ./asadmin create-jdbc-resource --connectionpoolid __TimerPool jdbc/QUIPSY/5__nontx
JDBC resource jdbc/QUIPSY/5__nontx created successfully.
Command create-jdbc-resource executed successfully.
~/Sun/v3/3.1.1/pb11/glassfish/bin 33)  
~/Sun/v3/3.1.1/pb11/glassfish/bin 33)  
~/Sun/v3/3.1.1/pb11/glassfish/bin 33)  ./asadmin deploy ~/DeployApp/bug16958/SuperSimple.ear
remote failure: Unknown plain text format.  A properly formatted response from a PlainTextActionReporter 
always starts with one of these 2 strings: PlainTextActionReporterSUCCESS or PlainTextActionReporterFAILURE.  The response we received from the server was not understood: Signature-Version: 1.0
message: Error occurred during deployment: Exception while preparing t
 he app : Exception [EclipseLink-28018] (Eclipse Persistence Services 
 - 2.3.0.v20110604-r9504): org.eclipse.persistence.exceptions.EntityMa
 nagerSetupException
Exception Description: Predeployment of P
 ersistenceUnit [QUIPSY] failed.
Internal Exception: Exception
  [EclipseLink-7333] (Eclipse Persistence Services - 2.3.0.v20110604-r
 9504): org.eclipse.persistence.exceptions.ValidationException%%%EOL%%
 %Exception Description: The reference column name [INTENTIONALLY_IMPL
 EMENTED_BUG_TO_PREVENT_DEPLOYMENT] mapped on the element [field custo
 mer] does not correspond to a valid field on the mapping reference.. 
 Please see server.log for more details.
Exception while invok
 ing class org.glassfish.persistence.jpa.JPADeployer prepare method : 
 javax.persistence.PersistenceException: Exception [EclipseLink-28018]
  (Eclipse Persistence Services - 2.3.0.v20110604-r9504): org.eclipse.
 persistence.exceptions.EntityManagerSetupException
Exception 
 Description: Predeployment of PersistenceUnit [QUIPSY] failed.%%%EOL%
 %%Internal Exception: Exception [EclipseLink-7333] (Eclipse Persisten
 ce Services - 2.3.0.v20110604-r9504): org.eclipse.persistence.excepti
 ons.ValidationException
Exception Description: The reference 
 column name [INTENTIONALLY_IMPLEMENTED_BUG_TO_PREVENT_DEPLOYMENT] map
 ped on the element [field customer] does not correspond to a valid fi
 eld on the mapping reference.
Exception [EclipseLink-28018] (
 Eclipse Persistence Services - 2.3.0.v20110604-r9504): org.eclipse.pe
 rsistence.exceptions.EntityManagerSetupException
Exception Descriptio
 n: Predeployment of PersistenceUnit [QUIPSY] failed.
Internal Excepti
 on: Exception [EclipseLink-7333] (Eclipse Persistence Services - 2.3.
 0.v20110604-r9504): org.eclipse.persistence.exceptions.ValidationExce
 ption
Exception Description: The reference column name [INTENTIONALLY
 _IMPLEMENTED_BUG_TO_PREVENT_DEPLOYMENT] mapped on the element [field 
 customer] does not correspond to a valid field on the mapping referen
 ce.
name_value: SuperSimple
name_name: name
keys: name
use-main-children-attribute: false
exit-code: FAILURE


Command deploy failed.
~/Sun/v3/3.1.1/pb11/glassfish/bin 34)  ./asadmin list-applications
Nothing to list.
Command list-applications executed successfully.
~/Sun/v3/3.1.1/pb11/glassfish/bin 35)

Comment by mkarg [ 19/Jul/11 ]

I see. The problem is the EAR that Tim gave you – it was specifically damaged to provide exactly that deployment error you are experiencing now. I hoped that multiply trying to deploy will produce the problem, which seems not to be the case actually. Sad but true, I do not have any other EAR. After I was fixing "Tim's" problem I have had some other issues (the deployment worked, but we needed to change some more stuff like broken ejb-refs etc.). THAT other EAR was the one I that happened to produce "Your" problem relatively often. "Unfortunately" we fixed all our stuff meanwhile and since then we can deploy/undeploy without producing "Your" problem anymore. So I am sorry but as it seems, "Your" problem only happens in case of an EAR that can be deployed, but has severe problems (like broken ejb-ref etc.) and gets undeployed therefore. Since I do not have such a broken EAR anymore, it seems there is nothing more I can do for you. Sad.

Comment by mkarg [ 19/Jul/11 ]

Anissa, good news: A team member is able to reproduce always using his EAR and GFv3.1! Can you please provide your email address so I can tell you how to download that closed source EAR from our FTP server (I may not upload it to a public tracker, and it is larger than 12 MB anyways

Comment by mkarg [ 20/Jul/11 ]

Found another way to reproduce a similar (but not exactly the same) problem, independent of the EAR:

asadmin start-domain
open browser to view localhost:4848
click somewhere, e. g. server-config
asadmin restart-domain
click somewhere else WHILE THE RESTART IS IN PROGRESS STILL
browser will wait until the restart is done and then show a nice glassfish-provided page telling that this JSF is not found

Comment by Anissa Lam [ 20/Jul/11 ]

I followed the EXACT steps above and cannot reproduce the problem.
Lets focus on reproducing the case as originally filed.

So far, all deployment of application failed, let alone deploy/undeploy/ cycle as mentioned in this bug report.
I have gotten a copy of SuperSimple.ear that was intended to force deployment failure. So, that deployment failed.

Then, I got another copy of SuperSimple.ear from Tim that 'suppose' can be deployed successfully. That failed also.

~/DeployApp/bug16958 9)  v3admin deploy SuperSimple.ear
remote failure: Error occurred during deployment: Exception while preparing the app : Invalid resource : jdbc/QUIPSY/5__pm. Please see server.log for more details.
Exception while invoking class org.glassfish.persistence.jpa.JPADeployer prepare method : java.lang.RuntimeException: Invalid resource : jdbc/QUIPSY/5__pm
Invalid resource : jdbc/QUIPSY/5__pm
Command deploy failed.
~/DeployApp/bug16958 10)  v3admin  create-jdbc-resource --connectionpoolid __TimerPool jdbc/QUIPSY/5__pm
JDBC resource jdbc/QUIPSY/5__pm created successfully.
Command create-jdbc-resource executed successfully.
~/DeployApp/bug16958 11)  v3admin  create-jdbc-resource --connectionpoolid __TimerPool jdbc/QUIPSY/5
JDBC resource jdbc/QUIPSY/5 created successfully.
Command create-jdbc-resource executed successfully.
~/DeployApp/bug16958 12)  v3admin deploy SuperSimple.ear
remote failure: Error occurred during deployment: Exception while loading the app : EJB Container initialization error. Please see server.log for more details.
Command deploy failed.
~/DeployApp/bug16958 13)  v3admin list-applications
Nothing to list.
Command list-applications executed successfully.
~/DeployApp/bug16958 14)

Here is what i need if you want me to continue looking into this issue:

  • Send an application that is REALLY deployable. You can send that to anilam@java.net and i will keep that private and won't share with other.
  • Provide the instructions (CLI command) on what resources I need to create first before deploying the application.
  • I will follow exactly all the CLI commands that you provide to reproduce the case.

I am going to lower this to P3 until i get a reproducible case.
thanks.

Comment by mkarg [ 21/Jul/11 ]

About the prio: I need to object since the prio should not be dependend on your local success to reproduce it but solely upong the actualy impact on the user, which is independend of your personal situation. We have two machines here that produce the behaviour and are about to ship GF 3.1.1 to 200+ enterprises world wide and expect that many of those will call our hotline to complain about this problem, which induces costs that should (and could) be prevented.

About the scenarios: No more need to send you the EAR. At one machine where it happens with our EAR we updated from 3.1 to 3.1.1_b11 and THAT scenario is gone then. So it makes no sense to further insist on getting any SuperSimple.ear that produces this problem as THAT scenario only happened back in 3.1. But, the second scenario (the one that you also cannot reproduce) happens on 3.1.1_b11 and to make you believe I will attach a video so you see what we do exactly to crash it. That machine is a HP Z400 QuadXeon with Win7 Pro SP1 64 Bit de_DE running a Firefox 3.6.18. Maybe you should use such an environment as it possible does not happen on a Mac?

Comment by mkarg [ 21/Jul/11 ]

"How To Crash Admin GUI" video, showing that a freshly installed GF can be crashed easily by just clicking in the GUI while the domain is restarting.

Comment by Anissa Lam [ 21/Jul/11 ]

>> About the scenarios: No more need to send you the EAR. At one machine where it happens with our EAR we updated from 3.1 to 3.1.1_b11 and THAT scenario is gone then. So it makes no sense to further insist on getting any SuperSimple.ear that produces this problem as THAT scenario only happened back in 3.1.
Just want to confirm this. Are you saying that you no longer experience the problem where "deploy/undeploy several times using CLI results in not getting the admin console" is no longer reproducible using 3.1.1 b11 ?
If that is the case, do u mind that I mark this "Cannot reproduce" or "Fixed" since thats what this issue is about ?

Thanks for the video, not that i don't believe you, i just can't reproduce it on my Mac.
I will open another issue for this 2nd scenario – "Cannot access admin console when server is restarting" , will that be fine with you ?
I think it makes it clearer that way.

Comment by mkarg [ 21/Jul/11 ]

While I do not see a need to close this and open another issue, I do not object that and hereby confirm that in GFv3.1.1_b11 the deploy/undeploy case is not reproducible. The only open issue now is the one shown in the video.

Comment by Anissa Lam [ 21/Jul/11 ]

Closing this as "Cannot Reproduce" in 3.1.1_b11.
I have opened GLASSFISH-17086 for the "Admin Console is not available during server re-start". mkarg, you may want to add yourself to watch that issue. That bug is set to "Critical" at your request
If you can attach server.log to GLASSFISH-17086, that will help too.
thanks.





[GLASSFISH-16916] Unable to restart embedded GlassFish instance once the remoteejb is deployed. Created: 27/Jun/11  Updated: 02/Dec/11

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

Type: Bug Priority: Major
Reporter: Bhavanishankar Assignee: sakshi.jain
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

any


Attachments: Text File exception.txt     Java Source File Test.java     Java Source File Test2.java    
Tags: 3_1-next, 3_1-next_release-note-added, 3_1-next_release-notes, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

I have a program which embeds GlassFish like this:

        BootstrapProperties bootstrapProperties = new BootstrapProperties();
        bootstrapProperties.setInstallRoot(System.getenv("S1AS_HOME"));
        GlassFishRuntime glassFishRuntime = GlassFishRuntime.bootstrap(bootstrapProperties);

        GlassFishProperties glassFishProperties = new GlassFishProperties();
        glassFishProperties.setInstanceRoot(System.getenv("S1AS_HOME") + "/domains/domain1");
        GlassFish glassfish = glassFishRuntime.newGlassFish(glassFishProperties);

        glassfish.start();
        String appName = glassfish.getDeployer().deploy(new File("remoteejb.jar"));
        System.out.println("GlassFish started [ " + glassfish + "]");

        glassfish.getDeployer().undeploy(appName);
        glassfish.stop();
        System.out.println("GlassFish stopped");

        glassfish.start();
        appName = glassfish.getDeployer().deploy(new File("remoteejb.jar"));
        System.out.println("GlassFish started [ " + glassfish + "]");

        glassfish.getDeployer().undeploy(appName);
        glassfish.dispose();
        System.out.println("GlassFish disposed");

The above code starts glassfish embedded, deploys a remoteejb application, undeploys the application, stops the server and tries to restart.

But the restart fails with exception in ORB and EJB container, as attached in the exception.txt

To reproduce:

1. Install latest 3.1.1 GlassFish, set S1AS_HOME to this installation.
2. Download remoteejb.jar from GLASSFISH-16546 issue and keep it under /tmp/
3. Download Test.java attachment of this issue (has the same code as I shown above) and keep it under /tmp/
4. Compile and run the test program:

javac -cp $S1AS_HOME/lib/embedded/glassfish-embedded-static-shell.jar Test.java
java -cp $S1AS_HOME/lib/embedded/glassfish-embedded-static-shell.jar:. Test


 Comments   
Comment by Harshad Vilekar [ 30/Jun/11 ]

We are currently reviewing this issue. Restart is not supported in the current ORB implementation. The code doesn't cleanly handle the operation sequence of destroy and then reinitialize. It is going to take us some time for further investigation.

Comment by Harshad Vilekar [ 05/Jul/11 ]

There are issues with cleanup after orb destroy operation. After destroying the old ORB, and creating the new ORB instance, references to older ORB are still lingering around, resulting in the reported exception. For example: com.sun.enterprise.iiop.security.SecIORInterceptor is still holding reference to the old orb. This is going to need more analysis.

As a workaround - If we create a complete new reference to glassFish, then the ORB restart exception is not seen at all. Please see the attached Test2.java.

Note: The test still throws an error: "Exception while loading the app : EJB Timer Service is not available.". That a different issue, not related to orb.

Comment by Bhavanishankar [ 06/Jul/11 ]

Further to the EJB timer issue you have mentioned, there is one more error from EJB container

 "java.lang.RuntimeException: EJB Container initialization error" 

caused due to

 java.lang.RuntimeException: Error while binding JNDI name org.glassfish.tests.embedded.ejb.remoteejb.RemoteEJBInf__3_x_Internal_RemoteBusinessHome__ for EJB : RemoteEJB 

This happens if we stop the first instance without undeploying, like this:


....
        //glassfish.getDeployer().undeploy(appName);
        glassfish.stop();

        glassfish = glassFishRuntime.newGlassFish(glassFishProperties);
        glassfish.start();
        appName = glassfish.getDeployer().deploy(new File("remoteejb.jar"));
...

Comment by Harshad Vilekar [ 08/Jul/11 ]

In the attached test case (Test2.java), we replace stop() by dispose(), and then create a new instance of glassfish. Additional cleanup done by these steps seem to help, and no ORB exception is seen. Changing the category to embedded - Please evaluate the feasibility of implementing the generic cleanup in embedded mode restart sequence.

Related EJB timer issue is tracked in - GLASSFISH-16230. That is not going to be addressed in 3.1.1, adding scrubbed tag to this issue also.

Comment by Bhavanishankar [ 01/Dec/11 ]

assigning.





[GLASSFISH-16892] Admin console fails to login, throws long series of exceptions on GF 3.2b6 promoted build Created: 22/Jun/11  Updated: 14/Oct/11  Resolved: 14/Oct/11

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

Type: Bug Priority: Major
Reporter: ringerc Assignee: Snjezana Sevo-Zenzerovic
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 11.04

Browser: Google Chrome 10.0.648.204
java version "1.6.0_22"
OpenJDK Runtime Environment (IcedTea6 1.10.1pre) (6b22-1.10.1~pre1-0ubuntu1)
OpenJDK Server VM (build 20.0-b11, mixed mode)

Version = GlassFish Server Open Source Edition 3.2-b06 (build 6)


Attachments: GZip Archive glassfish32-base-modules.gz     GZip Archive glassfish32-updated-modules.gz     HTML File pkg-after     HTML File pkg-before     Zip Archive server.log.zip    
Tags: 3_1-next, 3_1_1-scrubbed

 Description   

The admin console is inaccessible on Glassfish 3.2b6. When http://localhost:4848/ is visited the usual loading screen appears. Instead of an automatic login, a username and password prompt is displayed. A long series of exceptions are spewed to the server log - see attached.

The asadmin command-line tool continues to work as expected.

Glassfish was installed from glassfish-3.2-b06-unix.sh .



 Comments   
Comment by Anissa Lam [ 23/Jun/11 ]

Can you go to http://localhost:4848/management/domain to see if you can get to REST interface ?
Looking at the stacktrace, this is coming from REST.

assign to Jason for evaluation.

Caused by: java.lang.LinkageError: loader (instance of org/apache/felix/framework/ModuleImpl$ModuleClassLoaderJava5): attempted duplicate class definition for name: "org/glassfish/admin/rest/resources/generatedASM/DomainAnonymousUserEnabledResource"
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
... 33 more
...
...

Caused by: java.lang.LinkageError: loader (instance of org/apache/felix/framework/ModuleImpl$ModuleClassLoaderJava5): attempted duplicate class definition for name: "org/glassfish/admin/rest/resources/generatedASM/DomainAnonymousUserEnabledResource"
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
... 33 more

...

Caused by: java.lang.LinkageError: loader (instance of org/apache/felix/framework/ModuleImpl$ModuleClassLoaderJava5): attempted duplicate class definition for name: "org/glassfish/admin/rest/resources/generatedASM/DomainLocationResource"
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
... 33 more

Comment by Anissa Lam [ 23/Jun/11 ]

don't know why this bug is under 'rest-interface', yet it shows up when searching for admin-gui bug.
I am going to change it back to admin-gui and then change it to rest-interface again to see if this fix the problem.

Comment by ringerc [ 26/Jun/11 ]

No, access via REST doesn't work either.

$ curl http://localhost:4848/management/domain
<html><head><title>Grizzly/2.0</title><style><!--div.header

{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#003300;font-size:22px;-moz-border-radius-topleft: 10px;border-top-left-radius: 10px;-moz-border-radius-topright: 10px;border-top-right-radius: 10px;padding-left: 5px}

div.body

{font-family:Tahoma,Arial,sans-serif;color:black;background-color:#FFFFCC;font-size:16px;padding-top:10px;padding-bottom:10px;padding-left:10px}

div.footer

{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#666633;font-size:14px;-moz-border-radius-bottomleft: 10px;border-bottom-left-radius: 10px;-moz-border-radius-bottomright: 10px;border-bottom-right-radius: 10px;padding-left: 5px}

BODY

{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;}

B

{font-family:Tahoma,Arial,sans-serif;color:black;}

A

{color : black;}

HR

{color : #999966;}

--></style> </head><body><div class="header">Internal Server Error</div><div class="body"><b>Failed to start Bundle Id [239] State [INSTALLED] [org.glassfish.cluster.gms-adapter(GMS Module):3.2.0.b06]</b><pre> 1: org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:177)
2: org.jvnet.hk2.osgiadapter.OSGiModuleImpl$2$1$1.loadClass(OSGiModuleImpl.java:344)
3: com.sun.hk2.component.LazyInhabitant.loadClass(LazyInhabitant.java:128)
4: com.sun.hk2.component.LazyInhabitant.fetch(LazyInhabitant.java:113)
5: com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:135)
6: com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:86)
7: org.jvnet.hk2.component.Habitat.getComponent(Habitat.java:859)
8: com.sun.enterprise.v3.admin.CommandRunnerImpl.getModel(CommandRunnerImpl.java:152)
9: org.glassfish.admin.rest.generator.ResourcesGeneratorBase.commandIsPresent(ResourcesGeneratorBase.java:318)
10: org.glassfish.admin.rest.generator.ResourcesGeneratorBase.generateCommandResources(ResourcesGeneratorBase.java:299)
... 25 more</pre><b>Root Cause: org.osgi.framework.BundleException: Unresolved constraint in bundle org.glassfish.cluster.gms-adapter [239]: Unable to resolve 239.0: missing requirement [239.0] package; (package=com.sun.enterprise.ee.cms.impl.client) [caused by: Unable to resolve 102.0: missing requirement [102.0] package; (&(package=com.sun.grizzly)(version>=1.9.0)(!(version>=2.0.0)))]</b><pre> 1: org.apache.felix.framework.Felix.resolveBundle(Felix.java:3443)
2: org.apache.felix.framework.Felix.startBundle(Felix.java:1727)
3: org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)
4: org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:169)
5: org.jvnet.hk2.osgiadapter.OSGiModuleImpl$2$1$1.loadClass(OSGiModuleImpl.java:344)
6: com.sun.hk2.component.LazyInhabitant.loadClass(LazyInhabitant.java:128)
7: com.sun.hk2.component.LazyInhabitant.fetch(LazyInhabitant.java:113)
8: com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:135)
9: com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:86)
10: org.jvnet.hk2.component.Habitat.getComponent(Habitat.java:859)
... 28 more</pre>Please see the log for more detail.</div><div class="footer">Grizzly/2.0</div></body></html>

Comment by Anissa Lam [ 26/Jun/11 ]

I tried this on Solaris, by unzipping http://dlc.sun.com.edgesuite.net/glassfish/3.2/promoted/glassfish-3.2-b06.zip
Everything works fine for me.
I can go to REST and i can start the console.

What platform are you running and how do you install this ?
Looking at your log, there is issue with you starting up the server.

Failed to start Bundle Id [239] State [INSTALLED] [org.glassfish.cluster.gms-adapter(GMS Module):3.2.0.b06]</b><pre> 1: org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:177)
2: org.jvnet.hk2.osgiadapter.OSGiModuleImpl$2$1$1.loadClass(OSGiModuleImpl.java:344)
3: com.sun.hk2.component.LazyInhabitant.loadClass(LazyInhabitant.java:128)

This needs to be resolved first.
Try removing the osgi-cache directory, glassfish3/glassfish/domains/domain1/osgi-cache directory and then start the server. See if that helps.

This is not a rest-interface issue, maybe transfer to gms ?

Comment by ringerc [ 26/Jun/11 ]

Ubuntu 11.04 x86 with OpenJDK Runtime Environment (IcedTea6 1.10.1pre) (6b22-1.10.1~pre1-0ubuntu1). Sorry I forgot to mention the architecture in the Environment section in my initial post. The rest of the info is there, though.

After stopping the server, deleting the osgi-cache directory and re-starting the server I see the same symptoms. There's no noticeable change in the log output or exceptions emitted. Deleting the generated/ dir as well as osgi-cache has no further effect.

Interestingly, I can NOT reproduce this issue on my laptop running Fedora x64 using Java 1.6.0_22 (IcedTea6 1.10.2 (fedora-58.1.10.2.fc15-x86-64)).

Comment by ringerc [ 27/Jun/11 ]

Interesting. After a clean-install, I can't reproduce it on the original problem host either.

I'm now extremely confused, as I installed it in the same place as before with the same settings.

.....

OK, figured it out. After installation of the promoted build, Update Tool prompts for the installation of some update packages, one of which is the Jersey core. After that update is applied, the server fails as described above.

I've attached module lists from before and after the update, as emitted by asadmin list-modules.

Is update tool offering updates that aren't from promoted builds / tested sources? If so, should it be, or should it be restricted to offering updates from promoted builds?

Comment by ringerc [ 27/Jun/11 ]

Files containing lists of modules from initial b6 install (-base-modules) and after updatetool (-updated-modules).

Comment by Anissa Lam [ 27/Jun/11 ]

Thanks for spending time to narrow down the problem. That helps a lot.
I am transferring this to packaging for evaluation.

Comment by Snjezana Sevo-Zenzerovic [ 27/Jun/11 ]

Could you please do me a favor and also attach the list of installed IPS packages from affected installation since I have some trouble mapping OSGi module versions back to corresponding IPS packages. To get the package list, please run 'pkg list -f' command from <installdir>/bin directory and capture the output.

I think we have a situation where we published several grizzly and jersey package updates coming from 3.1.1 promoted builds and those are not necessarily compatible with 3.2 b06 because we stopped publishing corresponding updates to 3.2 GlassFish packages when we paused 3.2 promoted builds.

Comment by ringerc [ 27/Jun/11 ]

Done.

[glassfish3.2]$ diff ~/tmp/before ~/tmp/after
2c2
< felix 3.0.8-0 installed u---

> felix 3.0.8-0 installed ----
8,9c8,9
< glassfish-corba 3.2.0-2 installed u---
< glassfish-corba-base 3.2.0-2 installed u---

> glassfish-corba 3.2.0-2 installed ----
> glassfish-corba-base 3.2.0-2 installed ----
19c19
< glassfish-javahelp 2.0.2-1 installed u---

> glassfish-javahelp 2.0.2-1 installed ----
39c39
< jersey 1.7-0.12 installed u---

> jersey 1.8-0.8 installed ----

Comment by Snjezana Sevo-Zenzerovic [ 14/Oct/11 ]

Closing since this issue will not be fixed. 3.2 release has been replaced with 4.0 and we'll start using fresh set of promoted builds and fresh UC repository for 4.x packages.





[GLASSFISH-16866] systemloadaverage not available in monitoring data Created: 15/Jun/11  Updated: 27/Jun/11

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

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

mac, linux


Tags: 3_1-next, 3_1_1-scrubbed

 Description   

The systemloadaverage is not available in the monitoring data. We will need this as part of the elasticity work moving forward. The value returned needs to be a double. The existing code in JVMOSStatsProvider has this method commented out.



 Comments   
Comment by carlavmott [ 15/Jun/11 ]

Not sure how to make this one issue against both 3.1.1 and 3.2. It should apply to both releases.

Comment by scatari [ 27/Jun/11 ]

Enhancement.

Comment by Byron Nevins [ 27/Jun/11 ]

--> Jennifer





[GLASSFISH-16852] [PERF] Large performance regression from grizzly character conversion Created: 13/Jun/11  Updated: 03/Dec/12  Resolved: 13/Dec/11

Status: Closed
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 4.0
Fix Version/s: 4.0_b14

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

Issue Links:
Dependency
blocks GLASSFISH-16851 [PERF] Large peformance regressions i... Closed
Tags: 3_1-next, 3_1_1-scrubbed, 3_1_x-exclude, PSRBUG

 Description   

In glassfish tests after moving to grizzly 2.0 (glassfish b06), we see huge performance regressions from the encoding of page results. Profiles indicated that most of this time is spent in sun.nio.cs.UTF_8.newDecoder(), which is the result of org.glassfish.grizzly.memory.HeapBuffer calling new String(byte[], int, int, Charset).



 Comments   
Comment by oleksiys [ 15/Jun/11 ]

we created and fixed grizzly issue
http://java.net/jira/browse/GRIZZLY-1027

will mark this issue as fixed with the next grizzly integration

Comment by oleksiys [ 13/Dec/11 ]

fixed





[GLASSFISH-16851] [PERF] Large peformance regressions in b06 runtime performance Created: 13/Jun/11  Updated: 03/Dec/12  Resolved: 22/May/12

Status: Closed
Project: glassfish
Component/s: performance
Affects Version/s: 4.0_b06
Fix Version/s: 3.1.2

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

Issue Links:
Dependency
depends on GLASSFISH-16679 [PERF] Large performance regression i... Closed
depends on GLASSFISH-16852 [PERF] Large performance regression f... Closed
Tags: 3_1-next, 3_1_1-scrubbed, PSRBUG

 Description   

There are across-the-board performance issues in b06. We've identified at least two root causes; opening this for tracking them separately.



 Comments   
Comment by scatari [ 27/Jun/11 ]

Issue is filed on 3.2.





[GLASSFISH-16843] Negative value reported for "number of open connections" Created: 10/Jun/11  Updated: 02/Dec/11  Resolved: 22/Sep/11

Status: Resolved
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 4.0
Fix Version/s: 4.0

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

Mac OS X 10.6, glassfish 3.1


Tags: 3_1-next, 3_1_1-scrubbed, 3_1_x-exclude

 Description   

Turn monitoring to "HIGH" for WebContainer and HttpService. Executed the following CLI command :
get -m server.http-service.__asadmin.request.countopenconnections-count

Result :
server.http-service.__asadmin.request.countopenconnections-count = -148



 Comments   
Comment by Amy Roh [ 13/Jun/11 ]

ConnectionMonitor monitors the number of open connections via onAcceptEvent and onCloseEvent methods. The onAcceptEvent method only invokes the connectionAcceptedEvent and therefore increasing the open connection count if the connection's peer address is not NULL. However, the onCloseEvent method invokes the connectionClosedEvent and decrease the count regardless of the connection's peer address. This is causing the count to be a negative number.

@Override
public void onAcceptEvent(final Connection connection) {
final Object peerAddress = connection.getPeerAddress();

if (peerAddress != null)

{ // if peerAddress is null - it's a server connection. we should skip. grizzlyMonitoring.getConnectionQueueProbeProvider().connectionAcceptedEvent( monitoringId, connection.hashCode(), peerAddress.toString()); }

}

@Override
public void onCloseEvent(Connection connection)

{ grizzlyMonitoring.getConnectionQueueProbeProvider().connectionClosedEvent( monitoringId, connection.hashCode()); }

It appears that ConnectionMonitor#onAcceptEvent(final Connection connection) is always called with peer address NULL and the open connection count never gets incremented.

Assigning to Alexey to investigate why grizzly connection peer address is always NULL.

Comment by oleksiys [ 14/Jun/11 ]

just to make sure, it's Glassfish 3.2 related?

Comment by oleksiys [ 04/Jul/11 ]

ping

Comment by Jennifer Chou [ 21/Sep/11 ]

Forum user is also having an issue seeing negative activesessionscurrent.
http://forums.java.net/node/844876

Comment by Amy Roh [ 21/Sep/11 ]

I see that the part of the condition that was causing the discrepancy has been removed in 48946.

bash-3.2$ svn diff -r48076:48946 ConnectionMonitor.java
Index: ConnectionMonitor.java
===================================================================
— ConnectionMonitor.java (revision 48076)
+++ ConnectionMonitor.java (revision 48946)
@@ -61,15 +61,13 @@
}

@Override

  • public void onAcceptEvent(final Connection connection) {
  • final Object peerAddress = connection.getPeerAddress();
    + public void onAcceptEvent(final Connection serverConnection,
    + final Connection clientConnection) {
    + final Object peerAddress = clientConnection.getPeerAddress();
  • if (peerAddress != null) { // if peerAddress is null - it's a server connection. we should skip. - grizzlyMonitoring.getConnectionQueueProbeProvider().connectionAcceptedEvent( - monitoringId, connection.hashCode(), - peerAddress.toString()); - - }

    + grizzlyMonitoring.getConnectionQueueProbeProvider().connectionAcceptedEvent(
    + monitoringId, clientConnection.hashCode(),
    + peerAddress.toString());
    }

Comment by oleksiys [ 22/Sep/11 ]

fixed





[GLASSFISH-16841] unshareable connections enlisted in one transaction can be acquired by another bean acting in a separate transaction Created: 10/Jun/11  Updated: 21/Jun/11  Resolved: 21/Jun/11

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: 3.1
Fix Version/s: None

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

all platforms


Tags: 3_1-next, 3_1_1-scrubbed

 Description   

I wrote a XA transactinal connection factory which is injected into a stateless session bean. This factory is Unshareable. When this bean is used for the first time everything is OK, i.e. a connection is retrieved from this factory and it is enlisted in the transaction manager. At the end of bean's transactional method this connection is put back to the pool and delisted from the transaction manager.

But when this bean is used for the second time, there is an associated session context with a list of resources. In this list, there exists a resource handle with the connection which was used in the previous invocation of this bean. Before the body of the invoked method is executed, this resource handle is enlisted in a new transaction, although this connection is not yet acquired from the factory. It will be done in this body (I think that it is some optimization, which assumes that the same connection will be obtained from the pool once more time).

But it is a trap! Another concurrent instance of bean can get this enlisted connection before the above mentioned instance of bean do it. This connection (resource handle with this connection) has the "enlisted" flag set to true, and it is not (and of course shouldn't be) enlisted once more time. So this connection takes a part in a separate transaction than it is used.

In the method getResourceFromPool of the class com.sun.enterprise.resource.pool.ConnectionPool, there is even the following comment:

// the order of serving a resource request
// 1. free and enlisted in the same transaction
// 2. free and unenlisted
// Do NOT give out a connection that is
// free and enlisted in a different transaction

But there is no verification of this flag anywhere. Even in the method ds.getResource(), where I think it should be (ds is an instance of the class RWLockDataStructure).

This "enlisted" flag should be checked in the method getResourceFromPool (especially that this method is invoked from the method getUnenlistedResource), or no caching of the previous resource handles should be done in the session context of the bean. Why such caching is done - getting a connection from the pool is done independently of this caching?



 Comments   
Comment by Jagadish [ 15/Jun/11 ]

When a connection is not explicitly closed by the application (eg: bean method), it will remain associated with the bean (bean is caching the connection).
Whenever the bean is used again, any resources (connections) still associated with the bean will also take part in the transaction.

I do not expect the use-case where the connection is returned to the pool, but still associated with the bean.

Following test-case setup works fine :
[I see that connection is registered and unregistered with the component appropriately]

jdbc-connection-pool monitoring set to HIGH
[ asadmin set server.monitoring-service.module-monitoring-levels.jdbc-connection-pool=HIGH' ]

Stateless session bean
Resource Sharing is set to Unshareable
Acquires an XA resource (jdbc connection) in the transactional context
does DB work
releases the resource

[number of free connections remain the same (8) ]

Run the same test-case

[number of free connections remain the same (8) ]

Could you provide a test-case that exhibits the reported behavior ?

Comment by michal_kozak [ 16/Jun/11 ]

The connection is returned to the pool and still associated with the bean, when it is closed in the commit or rollback method of the XAResource interface for this connection.

I realized that this use-case is not proper so I changed now my resource adapter and I supplemented an interface of the connection with the close method which does it before the end of transaction.

Now it's OK. I'm sorry for the confusion

Comment by Jagadish [ 21/Jun/11 ]

"The connection is returned to the pool and still associated with the bean, when it is closed in the commit or rollback method of the XAResource interface for this connection."

I have not fully understood the above explanation.

Marking as "not an issue" as you have resolved the issue in your implementation.





[GLASSFISH-16827] enable secure admin screen needs to display error to user Created: 09/Jun/11  Updated: 21/Sep/15  Resolved: 21/Sep/15

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.1_b06
Fix Version/s: 3.1.1

Type: New Feature Priority: Critical
Reporter: Anissa Lam Assignee: Romain Grécourt
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-next, 3_1_1-scrubbed

 Description   

In the Enable Secure Admin screen, there are the 2 options for user to specify adminalias and instancealias.
IF there is problem with with is specified, the enable-secure-admin command fails.
In CLI, i see:

asadmin enable-secure-admin --adminalias alsdkflad --instancealias laskdjflasjkdf
remote failure: Error enabling secure admin : org.jvnet.hk2.config.TransactionFailure: com.sun.enterprise.security.admin.cli.SecureAdminCommand$SecureAdminCommandException: Error enabling secure admin; the keystore does not contain the specified aliases [alsdkflad, laskdjflasjkdf]
com.sun.enterprise.security.admin.cli.SecureAdminCommand$SecureAdminCommandException: Error enabling secure admin; the keystore does not contain the specified aliases [alsdkflad, laskdjflasjkdf]
Command enable-secure-admin failed.

However, in GUI, i don't see the error display, and DAS is restarted regardless.
We should ensure that the command returns successfully before restarting DAS, and display the error to user.



 Comments   
Comment by srinik76 [ 10/Jun/11 ]

Why fix this issue in 3.1.1?
Enable secure admin with wrong parameters does not fail thus misleading user

Which is the targeted build of 3.1.1 for this fix?
3.1.1_b08

Do regression tests exist for this issue?
Dev tests will be added

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

Comment by scatari [ 10/Jun/11 ]

Approved for 3.1.1.

Comment by Anissa Lam [ 14/Jun/11 ]

We will fix this issue in the trunk, since GLASSFISH-16126 will be removed from 3.1.1 branch.

Comment by srinik76 [ 15/Jun/11 ]

Will be done in future release and not in 3.1.1

Comment by Anissa Lam [ 15/Jun/11 ]

relating to new feature in 3.2

Comment by srinik76 [ 17/Jun/11 ]

Sending src/main/resources/appServer/securityAdmin.jsf
Sending src/main/resources/org/glassfish/common/admingui/Strings.properties
Transmitting file data ..
Committed revision 47541.

Checked into the v3 trunk





[GLASSFISH-16825] If It is Impossible to Transform Classes -- Disable Monitoring Created: 08/Jun/11  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1
Fix Version/s: not determined

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

Tags: 3_1-next, 3_1_1-scrubbed, 3_1_x-exclude

 Description   

Very early in the process of booting up a GF Server we should check and see if it is possible to do bytecode transformation of classes. If NOT then we should :

1) if monitoring is enabled, log a SEVERE message about the problem and then disable monitoring – but just for that run. Don't persist it in domain.xml

2) if monitoring is disabled – then do nothing

In either case if the user runs "enable-monitoring" we should return a strongly worded error.



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

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





[GLASSFISH-16813] 212 deploys of icefaces 2 chat, causes max perm gen Created: 06/Jun/11  Updated: 17/Oct/11  Resolved: 17/Oct/11

Status: Closed
Project: glassfish
Component/s: jsf
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b11

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

Linux Ubuntu 64 bit
Java 1.6.0 _ 24


Attachments: File chat.war     PNG File icefaces_chat_212.png    
Tags: 3_1-next, 3_1_1-scrubbed

 Description   

When I deploy this chat application 220 times, I get a MaxPerm gen error
This is more than a simple example, it is a example app from Icefaces

Methodology
1) Unpack clean Glassfish 3.1
2) Copy WAR file to Glasfish home
3) start Glassfish
4) Run shell script loop.sh (shell)
5) wait for 220 deploys

Related to Primefaces issue http://java.net/jira/browse/GLASSFISH-16654

This sample does not include WELD CDI



 Comments   
Comment by rjdkolb [ 06/Jun/11 ]

Icefaces chat WAR

Comment by rjdkolb [ 14/Jun/11 ]

With this mod http://java.net/jira/browse/GLASSFISH-16747 . GlassFish 3.1.1 b7

Deploys now fail at 259 deploys.

Comment by rjdkolb [ 12/Jul/11 ]

This is fixed in 3.1.1 b11

Please see
http://java.net/jira/browse/GLASSFISH-16656
http://java.net/jira/browse/GLASSFISH-16917

Comment by rogerk [ 12/Jul/11 ]

Per latest comments.

Comment by rogerk [ 17/Oct/11 ]

fix version

Comment by rogerk [ 17/Oct/11 ]

fix version.

Comment by rogerk [ 17/Oct/11 ]

Fixed in 3.1.1_b11





[GLASSFISH-16811] JMS - connection refused on 7676 when domain uses 6767 Created: 06/Jun/11  Updated: 21/Sep/15

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

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

Issue Links:
Related
is related to GLASSFISH-20606 create-domain subcommand doesn't writ... Open
Tags: 3_1-next, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

The following is reported from admin@glassfish.java.net
http://java.net/projects/glassfish/lists/admin/archive/2011-06/message/9

--------------------------------
Hi everyone,

We have an application (J2EE) which is JMS based. In order to isolate it from other applications - we always set up a new domain with following port configuration:

ADMIN_PORT=4949

JMX_PORT=6868

JMS_PORT=6767

HTTP_PORT=8585

HTTPS_PORT=1818

ORB_PORT=7300

ORBS_PORT=8302

ORBM_PORT=9302

It turns out that sometimes I see JMS component trying to connect on JMS default port (7676) instead of configured one (6767):

[#|2011-05-23T11:48:29.917-0300|INFO|sun-appserver2.1|javax.resourceadapter.mqjmsra.lifecycle|_ThreadID=10;_ThreadName=main;|MQJMSRA_RA1101: SJSMQ JMS Resource Adapter starting...|#]
[#|2011-05-23T11:48:29.964-0300|INFO|sun-appserver2.1|javax.resourceadapter.mqjmsra.lifecycle|_ThreadID=10;_ThreadName=main;|MQJMSRA_LB1101: Looking for Broker Running at:localhost:6767|#]

[#|2011-05-23T11:49:44.529-0300|WARNING|sun-appserver2.1|javax.jms|_ThreadID=23;_ThreadName=p: thread-pool-1; w: 4;_RequestID=138cb0fe-ad3f-42c1-a11f-88d16c111043;|[C4003]: Error occurred on connection creation [localhost:7676]. - cause: java.net.ConnectException: Connection refused: connect|#]
[#|2011-05-23T11:49:50.576-0300|WARNING|sun-appserver2.1|javax.jms|_ThreadID=23;_ThreadName=p: thread-pool-1; w: 4;_RequestID=138cb0fe-ad3f-42c1-a11f-88d16c111043;|[C4003]: Error occurred on connection creation [localhost:7676]. - cause: java.net.ConnectException: Connection refused: connect|#]
[#|2011-05-23T11:49:56.482-0300|WARNING|sun-appserver2.1|javax.jms|_ThreadID=23;_ThreadName=p: thread-pool-1; w: 4;_RequestID=138cb0fe-ad3f-42c1-a11f-88d16c111043;|[C4003]: Error occurred on connection creation [localhost:7676]. - cause: java.net.ConnectException: Connection refused: connect|#]

Sometimes there are many messages like that in a row (Log file is attached).

I´m wondering if this something internal from Glassfish or something that application does - like a producer which is being initialized with wrong attibuttes.
Even within this error appearing our application communicate with other part.

Anyone already had similar situation?
Thanks in advance,

Márcio Geovani Jasinski
Blumenau, Santa Catarina
Fone: +55 47 9653 4899



 Comments   
Comment by amyk [ 14/Jun/11 ]

From Márcio Geovani Jasinski:

"Until now this seems to have no impact on JMS communication. We have another issue which is openmq shutdown. But I don't think both issues are related. Anyway, this is the discussion link just in case you would like to read and consider whether it is might be related:
http://www.java.net/forum/topic/glassfish/glassfish/openmq-unexpected-shutdown"

Comment by scatari [ 25/Jun/11 ]

Marking as to be considered for next release as according to the submitted report the functionality is not lost.

Comment by Satish Kumar [ 18/Nov/11 ]

It is difficult to diagnose what exactly is happening here without looking at the domain.xml. Please ensure that the jms-service entry is correct for server-config and should be as follows:
<jms-service default-jms-host="default_JMS_host" type="EMBEDDED">
<jms-host host="localhost" port="$

{JMS_PROVIDER_PORT}

" name="default_JMS_host"></jms-host>
</jms-service>

The only time it will try and connect to 7676 is if the jms-host.port is not specified. then it defaults to 7676.

Comment by David Zhao [ 06/Jun/13 ]

I cannot reproduce it with glassfish4 for the defect which was reported against a pretty old version. But I do see that create-domain subcommand doesn't deal with jms.port correctly, so default jms port 7676 could be used for a new domain with different jms.port property. Issue GLASSFISH-20606 was filed for that.





[GLASSFISH-16807] create-http-lb-ref allows to create both server and cluster Created: 06/Jun/11  Updated: 14/Mar/12  Resolved: 28/Jun/11

Status: Resolved
Project: glassfish
Component/s: load_balancer
Affects Version/s: None
Fix Version/s: 3.1.2_b10, 4.0

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

Issue Links:
Dependency
blocks GLASSFISH-16763 Porting Load Balancer Console Pages f... Closed
Tags: 3_1-next, 3_1_1-scrubbed

 Description   

create-http-lb-ref accepts both server and cluster for targets and does not fail. In v2.1.1, it fails with error



 Comments   
Comment by srinik76 [ 06/Jun/11 ]

The fix for this issue blocks admin console operation

Comment by scatari [ 11/Jun/11 ]

Console support for LB is deferred from 3.1.1.

Comment by Yamini K B [ 13/Jun/11 ]

Fix checked in on trunk rev47448

Comment by Yamini K B [ 15/Nov/11 ]

Fix checked in into 3.1.2 branch (svn rev50848)





[GLASSFISH-16805] [osgi-cdi] support @Inject @OSGiService Instance<T> Created: 06/Jun/11  Updated: 22/Nov/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 1
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-18978 select OSGi services used in CDI bean... Sub-task Open Sanjeeb Sahoo  
Tags: 3_1-next

 Description   

Currently having something like
@Inject @OSGiService(dynamic=true)
private Instance<AdminService> adminService;

cause following exception:

java.lang.UnsupportedOperationException: Injection target type javax.enterprise.inject.Instance<org.glassfish.fighterfish.test.app18.AdminService>not supported
at org.glassfish.osgicdi.impl.OSGiServiceExtension.afterBeanDiscovery(OSGiServiceExtension.java:185)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:88)
at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:52)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:43)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:372)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:170)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:270)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:183)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:121)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:107)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:151)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:148)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:55)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:43)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:372)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:170)
... 17 more

#]


 Comments   
Comment by Sanjeeb Sahoo [ 06/Jun/11 ]

assigning to Siva for evaluation.

Comment by Sivakumar Thyagarajan [ 07/Jun/11 ]

Tagging this as 3_1-next, as this is not critical for the 3.1.1 release.

Comment by Sanjeeb Sahoo [ 07/Jun/11 ]

Do you know why it is not working? Can you at least mention the reason?

Comment by Sivakumar Thyagarajan [ 13/Jun/11 ]

Marked it as an improvement(RFE)

Comment by Tom Mueller [ 06/Mar/12 ]

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

Comment by TangYong [ 06/Aug/12 ]

Now, the feature has been supported combined with subTask(GLASSFISH-18978). Please see.

https://github.com/tangyong/gf-cdi-osgi-integration

DEMO1: https://github.com/tangyong/gf-cdi-osgi-integration/tree/master/samples/[RFP146]CDI018
DEMO2: https://github.com/tangyong/gf-cdi-osgi-integration/tree/master/samples/[RFP146]CDI004

Using Way:

1 get all osgi services
@Inject Service<StockQuoteService> sqses;
....

2 get osgi services qualified @ServiceFilter
@Inject @ServiceFilter("(country=CN)") Service<StockQuoteService> sqses;
...

Comment by TangYong [ 22/Nov/12 ]

After event integration was finished, the feature will start because compared with other features, it has been turned more important.





[GLASSFISH-16782] status not available for http load balancers Created: 02/Jun/11  Updated: 21/Oct/11

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

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

Issue Links:
Dependency
blocks GLASSFISH-16763 Porting Load Balancer Console Pages f... Closed
Tags: 3_1-next, 3_1_, 3_1_1-exclude, 3_1_1-next, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

In v2.1.1, while listing http load balancers table contains data (name,target,status)

status is found with the following code

LoadBalancer lb = AMXUtil.getDomainRoot().getLoadBalancerMap().get(key);
if( lb != null)

{ status = GuiUtil.getMessage(lb.isApplyChangeRequired()? "loadBalancer.needApply" : "loadBalancer.upToDate"); }

In v3, to find status what is the call for lb.isApplyChangeRequired(). If back end call is there, we need to create rest api conversion for this.



 Comments   
Comment by srinik76 [ 06/Jun/11 ]

Fix required for 3.1.1

Comment by kshitiz_saxena [ 07/Jun/11 ]

This issue requires some support implementation to detect changes in the load-balancer xml. This implementation must detect changes to cluster, instance, application, loadbalancer config etc. There is significant amount of work involved to achieve it, and cannot be fixed within timeline for 3.1.1. This issue will be taken up post 3.1.1.

In GUI we can remove column showing apply-changes status. It is already documented that auto-detection of load-balancer xml does not exist in 3.1 and will continue in 3.1.1 as well.





[GLASSFISH-16778] RAR7093 : Error while cleaning up ManagedConnection - NullPointerException Created: 01/Jun/11  Updated: 11/Nov/11  Resolved: 11/Nov/11

Status: Closed
Project: glassfish
Component/s: jdbc
Affects Version/s: 3.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: nbw Assignee: Shalini
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.1 FCS (bld 43), Windows 7 Ultimate Edition x64, JDK 1.6.0_22-b04 (32 bit)


Attachments: XML File connectionPoolSettings.xml    
Tags: 3_1-next, 3_1-next_need-more-info, 3_1_1-scrubbed, ConnectionPool, Glassfish, NPE, RAR

 Description   

Glassfish threw a NPE with the following stack trace [1]. This occurred shortly after Glassfish reported to the server.log a WARNING [2] of a possible connection leak in an Oracle JDBC connection pool it manages. The NPE may be a result of the connection leak reclamation process.

-Noah

[1] -

[#|2011-06-01T02:45:36.041-0400|WARNING|glassfish3.1|javax.enterprise.resource.resourceadapter.com.sun.enterprise.resource.allocator|_ThreadID=3;_ThreadName=Thread-1;|RAR7093 : Error while cleaning up ManagedConnection
java.lang.NullPointerException
at com.sun.gjc.spi.ManagedConnection.resetAutoCommit(ManagedConnection.java:507)
at com.sun.gjc.spi.ManagedConnection.resetConnectionProperties(ManagedConnection.java:493)
at com.sun.gjc.spi.ManagedConnection.cleanup(ManagedConnection.java:342)
at com.sun.enterprise.resource.allocator.AbstractConnectorAllocator.cleanup(AbstractConnectorAllocator.java:166)
at com.sun.enterprise.resource.pool.ConnectionPool.cleanupResource(ConnectionPool.java:1074)
at com.sun.enterprise.resource.pool.ConnectionPool.freeResource(ConnectionPool.java:1050)
at com.sun.enterprise.resource.pool.ConnectionPool.freeUnenlistedResource(ConnectionPool.java:1046)
at com.sun.enterprise.resource.pool.ConnectionPool.resourceClosed(ConnectionPool.java:1013)
at com.sun.enterprise.resource.pool.PoolManagerImpl.putbackResourceToPool(PoolManagerImpl.java:419)
at com.sun.enterprise.resource.pool.PoolManagerImpl.resourceClosed(PoolManagerImpl.java:379)
at com.sun.enterprise.resource.listener.LocalTxConnectionEventListener.connectionClosed(LocalTxConnectionEventListener.java:77)
at com.sun.gjc.spi.ManagedConnection.connectionClosed(ManagedConnection.java:769)
at com.sun.gjc.spi.base.ConnectionHolder.close(ConnectionHolder.java:214)
at com.sun.gjc.spi.jdbc40.ConnectionHolder40.close(ConnectionHolder40.java:539)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.closeDatasourceConnection(DatabaseAccessor.java:464)
at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.closeConnection(DatasourceAccessor.java:504)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.closeConnection(DatabaseAccessor.java:487)
at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.decrementCallCount(DatasourceAccessor.java:274)
at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.rollbackTransaction(DatasourceAccessor.java:676)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.rollbackTransaction(DatabaseAccessor.java:1495)
at org.eclipse.persistence.internal.sessions.AbstractSession.basicRollbackTransaction(AbstractSession.java:602)
at org.eclipse.persistence.sessions.server.ClientSession.basicRollbackTransaction(ClientSession.java:153)
at org.eclipse.persistence.internal.sessions.AbstractSession.rollbackTransaction(AbstractSession.java:3384)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.rollbackTransaction(UnitOfWorkImpl.java:4564)
at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.rollbackTransaction(RepeatableWriteUnitOfWork.java:504)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.release(UnitOfWorkImpl.java:4368)
at org.eclipse.persistence.internal.jpa.transaction.EntityTransactionImpl.rollback(EntityTransactionImpl.java:127)
at org.eclipse.persistence.internal.jpa.transaction.EntityTransactionImpl.finalize(EntityTransactionImpl.java:160)
at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)

#]

[2] -

[#|2011-06-01T02:45:20.166-0400|WARNING|glassfish3.1|javax.enterprise.resource.resourceadapter.com.sun.enterprise.resource.pool|_ThreadID=114;_ThreadName=Thread-1;|A potential connection leak detected for connection pool EMPool. The stack trace of the thread is provided below :
com.sun.enterprise.resource.pool.ConnectionPool.setResourceStateToBusy(ConnectionPool.java:324)
com.sun.enterprise.resource.pool.ConnectionPool.getResourceFromPool(ConnectionPool.java:754)
com.sun.enterprise.resource.pool.ConnectionPool.getUnenlistedResource(ConnectionPool.java:632)
com.sun.enterprise.resource.pool.ConnectionPool.internalGetResource(ConnectionPool.java:526)
com.sun.enterprise.resource.pool.ConnectionPool.getResource(ConnectionPool.java:381)
com.sun.enterprise.resource.pool.PoolManagerImpl.getResourceFromPool(PoolManagerImpl.java:242)
com.sun.enterprise.resource.pool.PoolManagerImpl.getResource(PoolManagerImpl.java:167)
com.sun.enterprise.connectors.ConnectionManagerImpl.getResource(ConnectionManagerImpl.java:341)
com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:304)
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:190)
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:165)
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:160)
com.sun.gjc.spi.base.DataSource.getConnection(DataSource.java:110)
org.eclipse.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:126)
org.eclipse.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:94)
org.eclipse.persistence.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:162)
org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.connectInternal(DatasourceAccessor.java:330)
org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.connectInternal(DatabaseAccessor.java:291)
org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.reconnect(DatasourceAccessor.java:565)
org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.reconnect(DatabaseAccessor.java:1434)
org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.incrementCallCount(DatasourceAccessor.java:305)
org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.beginTransaction(DatasourceAccessor.java:238)
org.eclipse.persistence.internal.sessions.AbstractSession.basicBeginTransaction(AbstractSession.java:489)
org.eclipse.persistence.internal.sessions.AbstractSession.basicBeginTransaction(AbstractSession.java:478)
org.eclipse.persistence.sessions.server.ClientSession.addWriteConnection(ClientSession.java:615)
org.eclipse.persistence.sessions.server.ServerSession.acquireClientConnection(ServerSession.java:246)
org.eclipse.persistence.sessions.server.ClientSession.executeCall(ClientSession.java:226)
org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:207)
org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:193)
org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.updateObject(DatasourceCallQueryMechanism.java:750)
org.eclipse.persistence.internal.queries.StatementQueryMechanism.updateObject(StatementQueryMechanism.java:432)
org.eclipse.persistence.internal.queries.DatabaseQueryMechanism.updateObjectForWriteWithChangeSet(DatabaseQueryMechanism.java:1159)
org.eclipse.persistence.queries.UpdateObjectQuery.executeCommitWithChangeSet(UpdateObjectQuery.java:84)
org.eclipse.persistence.internal.queries.DatabaseQueryMechanism.executeWriteWithChangeSet(DatabaseQueryMechanism.java:291)
org.eclipse.persistence.queries.WriteObjectQuery.executeDatabaseQuery(WriteObjectQuery.java:58)
org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:808)
org.eclipse.persistence.queries.DatabaseQuery.executeInUnitOfWork(DatabaseQuery.java:711)
org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWorkObjectLevelModifyQuery(ObjectLevelModifyQuery.java:108)
org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWork(ObjectLevelModifyQuery.java:85)
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2842)
org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1521)
org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1503)
org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1463)
org.eclipse.persistence.internal.sessions.CommitManager.commitChangedObjectsForClassWithChangeSet(CommitManager.java:265)
org.eclipse.persistence.internal.sessions.CommitManager.commitAllObjectsWithChangeSet(CommitManager.java:128)
org.eclipse.persistence.internal.sessions.AbstractSession.writeAllObjectsWithChangeSet(AbstractSession.java:3766)
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabase(UnitOfWorkImpl.java:1404)
org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.commitToDatabase(RepeatableWriteUnitOfWork.java:616)
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabaseWithPreBuiltChangeSet(UnitOfWorkImpl.java:1552)
org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.writeChanges(RepeatableWriteUnitOfWork.java:427)
org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush(EntityManagerImpl.java:744)
com.foo.em.api.pn.EMManager.update(EMManager.java:485)
sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:167)
com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:70)
com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:279)
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:136)
com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:86)
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:136)
com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:74)
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1347)
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1279)
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1229)
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1219)
com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:419)
com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:537)
com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:699)
javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
com.sun.grizzly.ContextTask.run(ContextTask.java:71)
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
java.lang.Thread.run(Thread.java:662)

Monitoring Statistics :

Monitoring Statistics for
EMPool|#]



 Comments   
Comment by Shalini [ 05/Jun/11 ]

Could you please attach a test case to reproduce this issue along with the connection pool configuration?

Comment by nbw [ 06/Jun/11 ]

Connection pool settings in play when the null pointer exception occurred.

Comment by Shalini [ 06/Jun/11 ]

With the jdbc connection pool configuration mentioned by you, i was unable to reproduce this issue. My test case gets a connection in the EJB and does some insert operations in a table and forgets to close this connection. After 60 seconds, the connection is traced as leaked and also reclaimed with the following message in the server.log :

[#|2011-06-07T11:25:36.301+0530|INFO|glassfish3.1|javax.enterprise.resource.resourceadapter.com.sun.enterprise.resource.pool|_ThreadID=69;_ThreadName=Thread-1;|Reclaiming the leaked connection of pool [ jdbc-connectionleaktracing ] and destroying it so as to avoid both the application that leaked the connection and any other request that can potentially acquire the same connection from the pool end up using the connection at the same time|#]

I'm using build 43. If you could attach a testcase (application/ear) to reproduce this issue, it would be great. Are you also seeing any connection validation failure messages in the server.log?

Comment by Shalini [ 12/Jun/11 ]

Tried to do a getConnection within a transaction and forgot to close the connection in the EJB. I got the expected messages that a connection is leaked in the server.log and when leak reclaim was set to true, it was reclaimed.

Need more info to reproduce this issue.

Comment by Shalini [ 11/Nov/11 ]

This issue is not reproducible with the connection pool settings attached. Need more info or an application to reproduce this issue. Hence closing this issue.





[GLASSFISH-16756] container-common includes connector runtime classes Created: 29/May/11  Updated: 29/May/13

Status: In Progress
Project: glassfish
Component/s: naming
Affects Version/s: 3.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Sanjeeb Sahoo Assignee: guojun.shan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-next, 3_1_1-scrubbed, 3_1_x-exclude

 Description   

While experimenting the idea of a light weight web container distribution for GF, I noticed that container common depends on connector runtime. I see no reason for the same. Pl. fix it.



 Comments   
Comment by Jagadish [ 15/Jul/11 ]

I made an attempt sometime back, but there is a dependency between
ComponentEnvManager and @DSD implementation
(ComponentEnvManager instantiates one DataSourceDefinitionProxy per @DSD
via hk2) that need to be resolved.

So, There is a need for notification mechanism in ComponentEnvManager
such that whenever a<JNDIEnvironment> is registered and unregistered,
connector runtime need to be notified and take appropriate action.

Please transfer the issue back to me once a notification mechanism for registering and unregistering Objects in JNDIEnvironment is available.

Please refer :

1) addJNDIBindings
2) unbindFromComponentNamespace
that triggers @DSD register and unregister operations.

Comment by Tom Mueller [ 15/Feb/13 ]

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





[GLASSFISH-16746] pessimistic lock can not generated into SQL in GF V3.1(eclipselink-2.2.0.v20110202-r8913) Created: 27/May/11  Updated: 15/Dec/11  Resolved: 15/Dec/11

Status: Resolved
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 3.1
Fix Version/s: 3.1.2_b14

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

GF V3.1(eclipselink-2.2.0.v20110202-r8913)
Database:SQL Server 2008


Tags: 3_1-next, 3_1_1-scrubbed, EclipseLink, GlassFish, PESSIMISTIC_LOCK

 Description   

the app is following:
===
Query query = em.createQuery("select i from RowLockEntity i where i.id=:id");
query.setParameter("id", id);
query.setHint(QueryHints.PESSIMISTIC_LOCK,lockType);
entity = (RowLockPesEntity)query.getSingleResult();
===
The generated SQL of above app by eclipselink-2.2.0.v20110202-r8913 as following.

===
SELECT ID,ENT_TYPE, NAME, OPT_LOCK_VER FROM ROWLOCKENTITY WHERE (ID = ?)")
===

The generated SQL does not contain pessimistic lock.
This problem occurred not only in SQL Server 2008, but also in Oracle, Derby and so on.



 Comments   
Comment by Mitesh Meswani [ 27/May/11 ]

A better approach for getting pessimistic lock is to use the standard API instead of EclipseLink specific API as follows

Query query = em.createQuery("select i from RowLockEntity i where i.id=:id");
query.setParameter("id", id);
query.setLockMode(javax.persistence.LockModeType.PESSIMISTIC_READ);
//query.setHint(QueryHints.PESSIMISTIC_LOCK,lockType);
entity = (RowLockPesEntity)query.getSingleResult();

That said, I believe EclipseLink should definitely honor the hint if you are executing the query within a transaction. Can you please file a bug against EclipseLink (https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EclipseLink) and cross reference both the bugs.

Comment by Wu Jie [ 29/May/11 ]

filed a bug against EclipseLink as following link:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=347592

Comment by scatari [ 11/Jun/11 ]

Mitesh,
Is the EclipseLink fix made in the trunk included in 2.3.0.x drop into 3.1.1? If not, then this should be deferred from 3.1.1. Could you please update accordingly?

Comment by Mitesh Meswani [ 15/Dec/11 ]

EclipseLink version with corresponding fix is integrated into GlassFish. Marking as fixed.





[GLASSFISH-16742] GlassFish installer should accept and use custom temporary directory location for all operations Created: 26/May/11  Updated: 28/Jun/11

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

Type: Improvement Priority: Major
Reporter: Snjezana Sevo-Zenzerovic Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-next, 3_1_1-scrubbed

 Description   

Issue reported in GlassFish forum:

http://forums.java.net/node/805963?force=937

Installer wrapper script should use custom temporary directory location to extract installer files and then pass same directory location to OpenInstaller runtime.



 Comments   
Comment by scatari [ 06/Jun/11 ]

Pre-approving for 3.1.1.

Comment by scatari [ 27/Jun/11 ]

Will not be taken in for 3.1.1 among other priorities. Targeting for the post 3.1.1 release.





[GLASSFISH-16714] NLS-OLH is not translated in Upgrade Tool Created: 24/May/11  Updated: 11/Feb/13  Due: 24/May/11  Resolved: 11/Feb/13

Status: Closed
Project: glassfish
Component/s: l10n
Affects Version/s: 3.1.1_b05
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: li.wu Assignee: gmurr
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS:OEL 5 w/32bit JDK 6
Server locale: fr_FR.UTF-8
Bundle: ogs-3.0.1-b22-unix-ml.sh; ogs-3.1.1-b05-unix-ml.sh
Browser: Firefox 3.6


Attachments: JPEG File upgrade_gui_fr.jpg    
Tags: 3_1-next, 3_1_1-scrubbed

 Description   

1. Install ogs-3.0.1-b22-unix-ml.sh, start glassfish;
2. Login application server and deploy an application for it;
3. Create a JDBC resouce and then stop glassfish;
4. Install ogs-3.1.1-b05-unix-ml.sh into a different directory.
5. Run 'asupgrade' to under new version path;
6. Check OLH in Upgrade Tool,it is unlocalized.






[GLASSFISH-16712] Classloading issue when accessing class for the first time during JPA shutdown Created: 23/May/11  Updated: 16/Nov/11  Resolved: 16/Nov/11

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1
Fix Version/s: 3.1.2_b11, 4.0

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

Windows 7 Professional 64-bit, JDK 1.6.0 u24, Glassfish 3.1 b43


Attachments: Zip Archive glassfish-classloader-updated.zip    
Tags: 3_1-next, 3_1_1-scrubbed, 3_1_2-review

 Description   

Reference original forum thread here: http://www.java.net/forum/topic/glassfish/glassfish/classloading-issue-when-accessing-class-first-time-during-jpa-shutdown-glassfish-31

To recap, Hibernate (and Ehcache) have relatively complex shutdown routines that sometimes result in the accessing of classes that have not yet been loaded. However, the class loader for the application is already stopped by the time these routines are called, which causes an IllegalStateException to be thrown.

A test case is attached (a stripped down version of the one in the forum thread). Deploying and undeploying yields this stack trace (note that the following JVM flag needs to be added to the domain configuration to avoid an NPE caused by logging in the shutdown routine: -Dorg.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES=false):

org.hibernate.HibernateException: could not destruct listeners
at org.hibernate.event.EventListeners.destroyListeners(EventListeners.java:226)
at org.hibernate.impl.SessionFactoryImpl.close(SessionFactoryImpl.java:972)
at org.hibernate.ejb.EntityManagerFactoryImpl.close(EntityManagerFactoryImpl.java:127)
at org.glassfish.persistence.jpa.JPADeployer.closeEMFs(JPADeployer.java:404)
at org.glassfish.persistence.jpa.JPADeployer.event(JPADeployer.java:395)
at org.glassfish.kernel.event.EventsImpl$1.run(EventsImpl.java:120)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.IllegalStateException: WEB9031: WebappClassLoader unable to load resource [org.hibernate.event.EventListeners$2], because it has not yet been started, or was already stopped
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1410)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1368)
at org.hibernate.event.EventListeners.destroyListeners(EventListeners.java:215)
... 11 more



 Comments   
Comment by Hong Zhang [ 02/Jun/11 ]

As Mitesh replied in the forum thread, it's a little unusual to load classes during EMF clean up in undeploy, however we should try to accommodate this case.

Comment by slominskir [ 16/Jun/11 ]

I'm using Hibernate, but not using EhCache. So it would seem just including Hibernate 3.6 in your web application deployed on GlassFish 3.1 is enough to trigger this Exception. Since this causes a memory leak this is a big problem (must restart server after a few re-deploys). Also, the problem appears to be a regression - I didn't encounter it in GlassFish 3.0.1, but when I upgraded to 3.1 I started to see it. This is discussed further here: http://www.java.net/forum/topic/glassfish/glassfish/undeploy-exception-upgrading-glassfish-301-31

Comment by Nazrul [ 16/Jun/11 ]

One other person ran into this issue while using Hibernate. It would be great if we can take a look at this.

<slominskir>
Something worth mentioning: I encountered a classloader issue in GlassFish 3.1 on undeploy that appears to be a regression from GlassFish 3.0.1: http://www.java.net/forum/topic/glassfish/glassfish/undeploy-exception-upgrading-glassfish-301-31
</slominskir>

Comment by scatari [ 25/Jun/11 ]

Marking it as to be considered after 3.1.1.

Comment by scatari [ 04/Nov/11 ]

Please evaluate this as for possible inclusion into 3.1.2.

Comment by Hong Zhang [ 16/Nov/11 ]

Move the classloader clean up from unload phase to clean phase so EMF clean up which happens before could use the classloader if needed. Changes checked in both trunk and 3.1.2 branch.





[GLASSFISH-16697] NullPointerException when creating virtual host on clean install Created: 22/May/11  Updated: 17/Oct/11  Resolved: 17/Oct/11

Status: Closed
Project: glassfish
Component/s: jsf
Affects Version/s: 3.1, 3.1.1_b05
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ahristov314 Assignee: rogerk
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Fedora Core 14, Clean Install


Tags: 3_1-next, 3_1_1-scrubbed, NullPointerException, Virtual_Host

 Description   

After a clean install to /usr/glassfish3 (using the .zip distribution), access the admin console, then add a virtual server with id: "www.test.com", host names "www.test.com", network listeners "http-listener-1".

[#|2011-05-22T08:48:21.506+0200|WARNING|glassfish3.1|javax.enterprise.resource.webcontainer.jsf.lifecycle|_ThreadID=17;_ThreadName=Thread-1;|java.lang.RuntimeException while attempting to process a 'command' event for 'newButton'.
java.lang.RuntimeException: java.lang.RuntimeException while attempting to process a 'command' event for 'newButton'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.event.CommandActionListener.invokeCommandHandlers(CommandActionListener.java:150)
at com.sun.jsftemplating.layout.event.CommandActionListener.processAction(CommandActionListener.java:98)
at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:769)
at javax.faces.component.UICommand.broadcast(UICommand.java:300)
at com.sun.webui.jsf.component.WebuiCommand.broadcast(WebuiCommand.java:166)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:330)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:232)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'newButton'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:454)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 43 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor99.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 45 more
Caused by: com.sun.jersey.api.client.ClientHandlerException: java.lang.IllegalArgumentException: URI is not absolute
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:131)
at com.sun.jersey.api.client.Client.handle(Client.java:629)
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:601)
at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
at com.sun.jersey.api.client.WebResource$Builder.get(WebResource.java:459)
at org.glassfish.admingui.common.util.RestUtil.get(RestUtil.java:668)
at org.glassfish.admingui.common.util.RestUtil.restRequest(RestUtil.java:185)
at org.glassfish.admingui.common.handlers.RestApiHandlers.restRequest(RestApiHandlers.java:210)
... 50 more
Caused by: java.lang.IllegalArgumentException: URI is not absolute
at java.net.URI.toURL(URI.java:1080)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:139)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:129)
... 57 more

#]

[#|2011-05-22T08:48:21.511+0200|WARNING|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=17;_ThreadName=Thread-1;|StandardWrapperValve[FacesServlet]: PWC1406: Servlet.service() for servlet FacesServlet threw exception
java.lang.NullPointerException
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:410)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:330)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:232)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]


 Comments   
Comment by ahristov314 [ 22/May/11 ]

Forgot to say, just in case it is relevant. JDK is Sun's JDK, v1.6.0_25, not the one that comes with FC 14

Comment by Anissa Lam [ 22/May/11 ]

Can you reproduce this consistently ?
I cannot reproduce this on my Mac, not sure if this is platform dependent.
Can you try to use CLI command to see if you get any error ?
Here is the CLI command:

glassfishv3/glassfish/bin/asadmin create-virtual-server --hosts www.test.com --httplisteners http-listener-1 www.test.com

Comment by ahristov314 [ 23/May/11 ]

Yes I can reproduce this consistently and across different versions. Seems that the exception is Faces-related, so I don't know if the CLI would help. I also get these kinds of Facelet-related NullPointerExceptions in other situations, e.g. when deploying an application on a virtual host.

Anyway, I tried the command you suggested (against the 3.1.1_b05 build) and it worked. The virtual host is created and shown on the admin Anconsole.

A further detail: I'm running glassfish as root right now, to make sure that the problems are not related to any sort of security restrictions.

Comment by Anissa Lam [ 23/May/11 ]

Transfer to jsf for evaluation as the NPE is from FacesServlet.

[#|2011-05-22T08:48:21.511+0200|WARNING|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=17;_ThreadName=Thread-1;|StandardWrapperValve[FacesServlet]: PWC1406: Servlet.service() for servlet FacesServlet threw exception
java.lang.NullPointerException
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:410)

Comment by rogerk [ 23/May/11 ]

I cannot seem to reproduce this.
Here is what I have done:

Downloaded and unzipped : http://dlc.sun.com.edgesuite.net/glassfish/3.1.1/nightly/latest-web.zip

Started up Glassfish: ./asadmin start-domain --verbose=true

Brought up admin gui: localhost:4848

Under "Configurations":
created a new virtual server with the information you provided.

The JDK version I'm running on my mac is: build 1.6.0_24-b07-334-9M3326

I know JSF does have tests with virtual servers.

Is there something I'm missing?

Comment by ahristov314 [ 23/May/11 ]

Well, not really - this is pretty much what I do (the OS and JDK are different, though), except that it fails with a NPE :-/

Comment by rogerk [ 24/May/11 ]

I just tried this on my linux hosted machine:
Linux adc6140208 2.6.18-238.0.0.0.1.el5xen #1 SMP Tue Jan 4 09:38:01 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

with java:

java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b06)
Java HotSpot(TM) Server VM (build 17.0-b16, mixed mode)

without issue.

I suppose I could to use the same java version you are using....

Comment by rogerk [ 02/Jun/11 ]

Could not reproduce - could be OS/Java specific issue.

Comment by rogerk [ 17/Oct/11 ]

Cannot Reproduce.





[GLASSFISH-16680] shut down screen Created: 18/May/11  Updated: 02/Dec/11  Resolved: 18/Jun/11

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b09, 4.0_b08

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

Attachments: PNG File Login.png     JPEG File restart.jpg     PNG File ShutDownDAS.png    
Tags: 3_1-next, 3_1_1-approved

 Description   

After you shut down DAS, the screen shown (localhost:4848/common/appServer/shutdown.jsf) seems to be missing some background images used for look and feel. When you compare this to the login screen, the missing pieces are obvious. See attached.

Please update for both open source and commercial distributions.



 Comments   
Comment by scatari [ 10/Jun/11 ]

Not a serious enough issue to be considered for inclusion in 3.1.1.

Comment by Anissa Lam [ 15/Jun/11 ]

we should fix both shutdown and restart screen.
shutdown screen shows no image.
restart screen has broken image and the S-curve as background which is wrong.

Since we don't have customized branding page for shutdown or restart (RFE thats never implemented), we can just use the 'generic' image the admin console adapter use when waiting for GUI to load.
The image can be found in v3/core/kernel/src/main/java/com/sun/enterprise/v3/admin/adapter/backimage.jpg.

Comment by sirajg [ 16/Jun/11 ]

Why fix this issue in 3.1.1?
Improve user experience

Which is the targeted build of 3.1.1 for this fix?
next build

Do regression tests exist for this issue?
No, manual testing

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
Look at shutdown and restart pages

Comment by scatari [ 16/Jun/11 ]

Approved for 3.1.1_b09.

Comment by sirajg [ 17/Jun/11 ]

Fixed for open source(community-theme) branding

Comment by Anissa Lam [ 18/Jun/11 ]

Fixed the priority order of the shutdown screen in the custom branding jar.
Also ported the change from 3.1.1 to trunk.
All the fix is in both trunk and 3.1.1 branch, for both shutdown and restart screen and for both community and oracle brand.

mark as resolved.





[GLASSFISH-16679] [PERF] Large performance regression in grizzly Created: 18/May/11  Updated: 03/Dec/12  Resolved: 13/Dec/11

Status: Closed
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 4.0_b06
Fix Version/s: 4.0_b14

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

Issue Links:
Dependency
blocks GLASSFISH-16851 [PERF] Large peformance regressions i... Closed
Tags: 3_1-next, 3_1_1-scrubbed, 3_1_x-exclude, PSRBUG

 Description   

Performance of all runtime benchmarks has regressed significantly in 3.2 b06 due to regressions in the new grizzly. For example, a ping servlet test has regressed by 50%.

The new grizzly architecture seems to be a major factor – for example, it takes 2x longer to write output from the servlet (through catalina OutputBuffer.doFlush()) in 3.2 b06 than in b05. Similarly, TCPNIOTransport.read() is taking 50% longer to execute than ReadFilter.read().



 Comments   
Comment by Ryan Lubke [ 18/May/11 ]

Hi Scott,

Do you have any profiling snapshots that you could point us to for review?

Comment by oleksiys [ 19/May/11 ]

also can you pls. share the PingServlet code?

Comment by Justin Lee [ 19/May/11 ]

If I made two builds available one just before and one just after the grizzly integration, would that help to isolate it to the grizzly change?

Comment by Justin Lee [ 19/May/11 ]

For grins and bit of a primitive benchmark, i ran quicklook on the pre/post grizzly builds. The revs, for reference, are 46673 for the pre-grizzly run and 46674 for the post-grizzly build. Pre-grizzly quicklook reported this:

testng-summary:
[echo] [testng]
[echo] [testng] ===============================================
[echo] [testng] QuickLookTests
[echo] [testng] Total tests run: 128, Failures: 0, Skips: 0
[echo] [testng] ===============================================
[echo] [testng]
[INFO] Executed tasks
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 9 minutes 24 seconds
[INFO] Finished at: Thu May 19 10:57:58 EDT 2011
[INFO] Final Memory: 22M/265M
[INFO] ------------------------------------------------------------------------

The post-grizzly build reported this:

testng-summary:
[echo] [testng]
[echo] [testng] ===============================================
[echo] [testng] QuickLookTests
[echo] [testng] Total tests run: 128, Failures: 0, Skips: 0
[echo] [testng] ===============================================
[echo] [testng]
[INFO] Executed tasks
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 8 minutes 35 seconds
[INFO] Finished at: Thu May 19 11:06:45 EDT 2011
[INFO] Final Memory: 22M/265M
[INFO] ------------------------------------------------------------------------

So the post-grizzly build ran almost a full minute faster. This isn't a super scientific test but to me suggests that grizzly alone isn't the culprit. But if a profiling expert (which I am not) would like to use the builds for more rigorous testing, i can make them available.

Comment by Scott Oaks [ 19/May/11 ]

Profiles using Oracle Studio are available at ftp://javaperf.us.oracle.com/pub/16679.tar.gz.

If you have the isolated builds, I will try them. Also, you can just use fhb to drive load to a hello, world type servlet to replicate my tests.

Comment by oleksiys [ 13/Jun/11 ]

add tags 3_1-next and 3_1_1-scrubbed.
This issue is 3.2 related

Comment by oleksiys [ 13/Dec/11 ]

fixed





[GLASSFISH-16669] Importing a SSL signed certificate from the Admin Console From a Certificate On the Server Created: 17/May/11  Updated: 17/May/11

Status: Open
Project: glassfish
Component/s: admin, admin_gui, rest-interface
Affects Version/s: None
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: LocusAsaf Assignee: Jason Lee
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-next

 Description   

Loading a SSL certificate into Glassfish is difficult right now. The instructions in the Glassfish documentation are not very clear and there is a lot of different literature online that differs from it, which makes things even more confusing. It would be great if you could load a certificate into a domain directly from the console (by choosing the signed certificate file from your machine) and then assign it to be used by that domain.



 Comments   
Comment by Jason Lee [ 17/May/11 ]

This is an RFE the user and I discussed on IRC to be considered in the GlassFish 4 timeframe.





[GLASSFISH-16662] Invalid username or password message displayed on every screen Created: 16/May/11  Updated: 13/Jun/11  Resolved: 13/Jun/11

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lidiam Assignee: Jason Lee
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish server 3.1.1 b4 on AIX 6.1, browser: Firefox 3.6.15 on WindowsXP.


Attachments: JPEG File invaliduser-error.JPG     File server.log.accesserror    
Issue Links:
Duplicate
duplicates GLASSFISH-16184 Admin GUI fails to display - server e... Resolved
Tags: 3_1-need_more_info, 3_1-next, 3_1_1-scrubbed

 Description   

I'm logging this issue as a place holder, as I do not have all the information to reproduce it, while it is significant enough that it needs to be logged. Hope we can add more information here as we test it further.

I started testing Admin Console on an existing Glassfish 3.1 installation on an AIX machine. This installation was used by Shaline previously and it has administrative username/password set for the default domain1. After logging in with the user name/password, I deleted existing standalone instance and a config node, then left the system idle for almost an hour. When I got back, clicking on any Tree Node produced the following error at the top of the page:

An error has occurred
Invalid user name or password

I'll attach a screenshot and server.log. The odd thing is, that if I reached a timeout, I should not see any of the Administration Console pages, rather than have this confusing message displayed. I clicked on deploy applications and got to the next screen. Managed to select an application and after clicking OK to deploy the app, I was brought back to the Deploy Application screen, with all fields back to default. The "Invalid user name or password" error message was displayed at each step on the Console screen. After clicking on New Node button, got the following exception:

HTTP Status 500 -

type Exception report

message

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

exception

javax.servlet.ServletException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event220'.

root cause

java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event220'.

root cause

java.lang.reflect.InvocationTargetException

root cause

java.lang.NullPointerException

note The full stack traces of the exception and its root causes are available in the Oracle GlassFish Server 3.1.1 logs.

After talking to Shaline, it looks like this is not a regression but this issue was seen in an earlier build of 3.1 as well.

The workaround is to logout and login to Admin Console again.



 Comments   
Comment by Anissa Lam [ 16/May/11 ]

I remember there was issue reported before relating to session timeout, and Jason looked at that.
Assign to Jason.

Comment by Anissa Lam [ 19/May/11 ]

Add "3_1-next" tag. we can work on this after more info is available.

Comment by Jason Lee [ 13/Jun/11 ]

I'm confident this is caused by the same issue as GLASSFISH-16184 (the scenario and on page behavior are strikingly similar), so I'm going to close it as a duplicate.





[GLASSFISH-16657] 1000 deploys of basically WAR project. No Weld or JSF. PS Old Gen looks like it is leaking ? Created: 16/May/11  Updated: 08/Jul/11  Resolved: 08/Jul/11

Status: Closed
Project: glassfish
Component/s: classloader
Affects Version/s: 3.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: rjdkolb Assignee: kshitiz_saxena
Resolution: Invalid Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java 1.6.0 _24 Linux 64


Attachments: PNG File CMS-old-gen-default.png     PNG File leak_2d.png     File loop.sh     HTML File Objects_comparison.html     File TestMemoryLeak2_D.war     Zip Archive TestMemoryLeak2_D.zip    
Tags: 3_1-next, 3_1_1-scrubbed

 Description   

When I deploy this sample application 1000 times, PS Old Gen does not look right
The sample is a clean WAR, No JSF / WELD or even web.xml

What makes this sample significant is that WAR is basically empty
FYI : Here is a previous bug I filed that was fixed : http://java.net/jira/browse/GLASSFISH-11110

Methodology
1) Unpack clean Glassfish 3.1
2) Copy WAR file to Glasfish home
3) start Glassfish
4) Run shell script loop.sh (shell)
5) wait for 1000 deploys

This issue is the first sample associated with http://java.net/jira/browse/GLASSFISH-16604



 Comments   
Comment by Sanjeeb Sahoo [ 05/Jul/11 ]

Will be addressed in next release.

Comment by Sanjeeb Sahoo [ 05/Jul/11 ]

Kshitiz has agreed to evaluate this bug as he has recently analysed a similar bug involving Weld/JSF. Thanks Kshitiz. After doing the necessary analysis, you can assign it back to me.

Comment by kshitiz_saxena [ 06/Jul/11 ]

CMS old gen view using jprofiler with default jvm settings

Comment by kshitiz_saxena [ 06/Jul/11 ]

In CMS(Concurrent Mark Sweep) old gen view attached with the bug, you can see the increase in old gen space as mentioned in the issue. This will happen as objects are moved from young generation to old generation as minor GC kicks in frequently in young generation. The redeploy keeps creating new objects which minor GC pushes to old gen. The CMS cleans up objects in old generation but could not completely clean it up. The full GC triggered using jprofiler cleans up the old gen.

Initial old gen size : 33MB
Final old gen size after two Full GC calls : 49 MB

So objects are removed from old generation when Full GC kicks in. This signifies that objects are not referenced from root node and can be removed, however CMS does not recognize these objects as unreferenced objects and cleans them up.

Comment by Sanjeeb Sahoo [ 07/Jul/11 ]

From the comments above, the memory has grown by only 8MB after 1000 redeployments. It is not clear if that 8MB is a leak or full GC just returned since it freed more than sufficient memory. Anyway, we will keep looking for any kind of leak and update this bug if we find an answer. Thanks, Kshitiz.

Comment by kshitiz_saxena [ 07/Jul/11 ]

I had taken two snapshot - snapshot1 before starting the run, and then snapshot4 after run + full GC was complete. You can see objects comparisons between snapshot1 and snapshot4 in attached Objects_comparison.html. You can see the total size difference between two snapshots is only 852kB. There is no significant difference in memory consumption as a whole(young + old gen) between two snapshots.

Comment by kshitiz_saxena [ 07/Jul/11 ]

I also tried this scenario setting -Xmx and -Xms to 2048mb. The idea was to delay minor GC. However it did not have much impact. Probably references between objects are pretty complex, which does not allow unreferenced objects to be collected either by minor GC or CMS.

Comment by kshitiz_saxena [ 08/Jul/11 ]

Based on above analysis, I did not find any leak as such. Yes, old gen does grow with redeploy, but lot of those objects are unreferenced. However minor GC and CMS are not able to collect them. They are only collected as part of full GC.

I am closing this issue as invalid.

Comment by rjdkolb [ 08/Jul/11 ]

> Based on above analysis, I did not find any leak as such. Yes, old gen does grow with > redeploy, but lot of those objects are unreferenced. However minor GC and CMS are not > able to collect them. They are only collected as part of full GC.

Since 1000 deploys did not crash this empty war, I agree.
Before I grabbed the screen shot of jconsole, I did run a Garbage collector in jconsole. I assume this is a full GC.

But also there are probably bigger fish to fry.

Thanks very much for the analysis





[GLASSFISH-16630] description element in config hangs startup with parser error Created: 13/May/11  Updated: 21/Oct/11  Resolved: 21/Oct/11

Status: Resolved
Project: glassfish
Component/s: configuration
Affects Version/s: 3.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Bobby Bissett Assignee: Tom Mueller
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: XML File description-element-to-attribute.xsl     XML File domain.xml    
Tags: 3_1-next, 3_1-upgrade, 3_1_1-scrubbed, rel_notes_candidate

 Description   

If a description is set on a jdbc-resource object (e.g. through the admin console), then this is stored in a GF v2 config like this:

<jdbc-resource enabled="true" jndi-name="jdbc/__default" object-type="user" pool-name="DerbyPool">
<description>This is the default pool.</description>
</jdbc-resource>

When someone tries to do a config upgrade on this domain, the config parser fails, and startup hangs, with the following:

Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: org.jvnet.hk2.component.ComponentException: Failed to create a habitat
at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.createHabitat(AbstractModulesRegistryImpl.java:169)
at com.sun.enterprise.module.bootstrap.Main.createHabitat(Main.java:425)
at org.jvnet.hk2.osgiadapter.HK2Main.createHabitat(HK2Main.java:96)
at org.glassfish.kernel.GlassFishActivator$1.newGlassFish(GlassFishActivator.java:104)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:113)
... 6 more
Caused by: java.lang.RuntimeException: Fatal Error. Unable to parse file:/Users/bobby/work/ws/br_3_1_1/v3/distributions/glassfish/target/glassfish3/glassfish/domains/domain1/config/domain.xml
at org.glassfish.config.support.DomainXml.parseDomainXml(DomainXml.java:257)
at org.glassfish.config.support.DomainXml.run(DomainXml.java:109)
at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.populateConfig(AbstractModulesRegistryImpl.java:176)
at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.createHabitat(AbstractModulesRegistryImpl.java:158)
... 10 more
Caused by: javax.xml.stream.XMLStreamException: found: CHARACTERS, expected START_ELEMENT or END_ELEMENT
at org.glassfish.config.support.XMLStreamReaderFilter.thisNextTag(XMLStreamReaderFilter.java:98)
at org.glassfish.config.support.XMLStreamReaderFilter.nextTag(XMLStreamReaderFilter.java:74)
at org.jvnet.hk2.config.ConfigParser.handleElement(ConfigParser.java:148)
at org.jvnet.hk2.config.ConfigParser.handleElement(ConfigParser.java:208)
at org.jvnet.hk2.config.ConfigParser.handleElement(ConfigParser.java:167)
at org.jvnet.hk2.config.ConfigParser.handleElement(ConfigParser.java:208)
at org.jvnet.hk2.config.ConfigParser.handleElement(ConfigParser.java:215)
at org.jvnet.hk2.config.ConfigParser.handleElement(ConfigParser.java:167)
at org.jvnet.hk2.config.ConfigParser.parse(ConfigParser.java:98)
at org.jvnet.hk2.config.ConfigParser.parse(ConfigParser.java:93)
at org.glassfish.config.support.DomainXml.parseDomainXml(DomainXml.java:238)
... 13 more

The workaround is to manually edit domain.xml before running the upgrade to move the description element text into a description attribute instead. I've attached a domain.xml that can be dropped into domain1/config to reproduce. The admin dev test diff is:

hostname% svn diff
Index: resources/configs/v2domain.xml
===================================================================
— resources/configs/v2domain.xml (revision 46824)
+++ resources/configs/v2domain.xml (working copy)
@@ -27,7 +27,9 @@
<resources>
<jdbc-resource enabled="true" jndi-name="jdbc/_TimerPool" object-type="system-admin" pool-name="_TimerPool"/>
<jdbc-resource enabled="true" jndi-name="jdbc/_CallFlowPool" object-type="system-all" pool-name="_CallFlowPool"/>

  • <jdbc-resource enabled="true" jndi-name="jdbc/__default" object-type="user" pool-name="DerbyPool"/>
    + <jdbc-resource enabled="true" jndi-name="jdbc/__default" object-type="user" pool-name="DerbyPool">
    + <description>This is the default pool.</description>
    + </jdbc-resource>
    <jdbc-connection-pool allow-non-component-callers="false" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="auto-commit" datasource-classname="org.apache.derby.jdbc.EmbeddedXADataSource" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="false" is-isolation-level-guaranteed="true" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="32" max-wait-time-in-millis="60000" name="__CallFlowPool" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.XADataSource" statement-timeout-in-seconds="-1" steady-pool-size="8" validate-atmost-once-period-in-seconds="0" wrap-jdbc-objects="false">
    <property name="databaseName" value="$ {com.sun.aas.instanceRoot}

    /lib/databases/sun-callflow"/>
    <property name="connectionAttributes" value=";create=true"/>



 Comments   
Comment by Bobby Bissett [ 13/May/11 ]

This was initially reported by a 2.X customer, so it'd be nice to fix it in 3.1.1 if possible.

Comment by Tom Mueller [ 13/May/11 ]

The description is declared as an @Attribute rather than an @Element in the JdbcResource config bean. I wonder if this should have been an @Element all along. The problem with changing it to an @Element now is that there may be 3.x domain.xml files that have it as an attribute.

Assigning to Jagadish for evaluation.

Comment by gfuser9999 [ 16/May/11 ]

This issue is not only in JdbcResource, custom resource also have issue. Hence the <description> element problem
may exists for other modules too. For completeness, all related tag's that have @Attribute for description
needs to be checked (or apply similar treatmeat) if this issue is fixed.

Comment by Bobby Bissett [ 19/May/11 ]

This issue was moved to the jdbc category, but it's not specific to JDBC. I also see a "description" attribute for the following classes even though the 2.X DTD allowed a description child element:

ConnectorConnectionPool
SystemProperty
ExtensionModule
Event
J2eeApplication
EjbModule
WebModule
ConnectorModule
AppclientModule
CustomResource
ExternalJndiResource
MailResource
PersistenceManagerFactoryResource
AdminObjectResource
ConnectorResource
JdbcConnectionPool
ConnectorConnectionPool
SystemProperty
Mbean

For reference:
http://www.sun.com/software/dtd/appserver/sun-domain_1_3.dtd

Comment by Jagadish [ 19/May/11 ]

True, this is not specific to jdbc alone.
However, most of the resources (jdbc-resource, connector-resource, connector-connection-pool, jdbc-connection-pool, admin-object-resource, mail-resource, custom-resource, jndi-resource etc.,) are affected by this.

"system-property" will also be affected by this.

From my analysis, these are the only non-deprecated elements that will be affected.

However, the deprecated elements like :
J2eeApplication
EjbModule
WebModule
ConnectorModule
AppclientModule

when upgraded will also go through the same issue.

w.r.t resources, these changes (config beans conversion from v2 to v3) were introduced as part of pre-v3 work and it remained the same ever after.

I was trying to do the following in one of the resources so that we could fix the backward compatibility issue, but it does not seem to work. Refer the attribute name ("description") is specified in the annotation rather than the usual way of deriving the name from the method "getDescription1()".

@Attribute("description")
String getDescription1();

void setDescription1(String value) throws PropertyVetoException;

@Element
String getDescription();

Transferring to Tom for investigation.

Comment by Tom Mueller [ 20/May/11 ]

It appears that this would require a change to the way HK2 parses the XML from domain.xml so that for an appropriately marked field in a ConfigBean, the value could be specified as either an attribute or an element in the XML. For example, if a new annotation was defined, @AttributeOrElement, by HK2, it could be used like this in the SystemProperty (or any other) ConfigBean:

@AttributeOrElement
public String getDescription();
public void setDescription(String value) throws PropertyVetoException;

The following variants of XML would then be valid:

<system-property name="a" value="b" description="something"/>

or

<system-property name="a" value="b">
<description>something</description>
</system-property>

The annotation by default could have the value written as an attribute, but it could take an argument that would say to write it as an element.

This would be a fairly significant and risky fix to make for 3.1.1. Maybe this should be deferred to a later release.

Comment by scatari [ 06/Jun/11 ]

Anything to be documented here? I am marking this bug for "to be considered in the next release".

Comment by Tom Mueller [ 08/Jun/11 ]

This issue and its work-around should be documented in the release notes.

The work-around is to manually edit the domain.xml for the domain to be upgraded so that any <description> elements are replaced with description attributes, i.e., replace:

<system-property name="a" value="b">
<description>something</description>
</system-property>

with

<system-property name="a" value="b" description="something"/>

After performing this modification, then proceed with the upgrade as usual.

Comment by Tom Mueller [ 21/Oct/11 ]

XSLT stylesheet for fixing problem in a domain.xml

Comment by Tom Mueller [ 21/Oct/11 ]

The attached XSLT stylesheet, description-element-to-attribute.xsl, will convert all of the description elements in a domain.xml file to attributes. This can be run on a GlassFish v2 domain.xml file that has this problem using the following:

mv domain.xml domain.xml.orig
xsltproc description-element-to-attribute.xl domain.xml.org > domain.xml

Then start up the server normally to complete the upgrade.

Based on the lack of user complaints about this problem, this appears to not be a problem that people are encountering frequently. The attached file provides a workaround for the problem. For future releases, this type of incompatible change to the configuration data will not be made, so the permanent solutions to the problem are not really needed. So marking this as won't fix.





[GLASSFISH-16623] Unknown publisher when launching ogs-3.1-windows.exe Created: 12/May/11  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: installation
Affects Version/s: 3.1, 4.0_b59
Fix Version/s: 4.1.1

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

Windows


Tags: 3_1-next, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

Here's what I did. Download 3.1 from:

http://www.oracle.com/technetwork/middleware/glassfish/downloads/index.html

If you double click on the file:

ogs-3.1-windows.exe

Windows will warn you that the publisher is unknown. If you take a look at the properties on the file you will see that the signature is not valid. The parent cert from Verisign also appears not to be valid.

The cert indicates it is valid to 2012 so the problem is not due to an expired cert. Beyond that I'm not sure what the problem is.

I'm seeing this on an XP system.



 Comments   
Comment by scatari [ 12/May/11 ]

Why fix this issue in 3.1.1?
At the face issue for 3.1.1 customers.

Which is the targeted build of 3.1.1 for this fix?
b10

Do regression tests exist for this issue?
No, the verification should be done through checking the UI in explorer.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
Manually check the signature and verify certificate details.

Comment by scatari [ 03/Jul/11 ]

Will not be addressed in 3.1.1, targeted for the next immediately release following 3.1.1.

Comment by Romain Grécourt [ 12/Dec/11 ]

I didn't have any popup about unknown publisher (i' using xp-sp3 obi-lite), but I've been able to reproduce this issue with some windows installer which were produced by openinstaller. I've reproduced the issue for the following artifacts:

  • ogs-3.1-windows.exe
  • ogs-3.1.1-windows.exe
  • glassfish-3.1.2-b05-windows.exe
  • java_ee_sdk-6u3-windows.exe

To verify that the files were correctly signed I've used signtool which is part of microsoft windows sdk. Here is the output produced for all the openinstaller's artifact:

C:\Documents and Settings\rgrecour\My Documents\installer>signtool verify /pa /v ogs-3.1-windows.exe

Verifying: ogs-3.1-windows.exe
SignTool Error: CryptCATAdminCalcHashFromFileHandle returned error: 0x00000057
        The parameter is incorrect.
Hash of file (sha1): 4629BB77009469B2B3891B01723D407DCB3DBDF3

Signing Certificate Chain:
    Issued to: Class 3 Public Primary Certification Authority
    Issued by: Class 3 Public Primary Certification Authority
    Expires:   Wed Aug 02 23:59:59 2028
    SHA1 hash: A1DB6393916F17E4185509400415C70240B0AE6B

        Issued to: VeriSign Class 3 Code Signing 2009-2 CA
        Issued by: Class 3 Public Primary Certification Authority
        Expires:   Mon May 20 23:59:59 2019
        SHA1 hash: 12D4872BC3EF019E7E0B6F132480AE29DB5B1CA3

            Issued to: Oracle America, Inc.
            Issued by: VeriSign Class 3 Code Signing 2009-2 CA
            Expires:   Sat Jul 06 23:59:59 2013
            SHA1 hash: 9E2B73433C7FF0BE9C2E546C46A3D16A6CDACF32

The signature is timestamped: Tue Oct 12 20:12:53 2010
Timestamp Verified by:
    Issued to: Thawte Timestamping CA
    Issued by: Thawte Timestamping CA
    Expires:   Thu Dec 31 23:59:59 2020
    SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656

        Issued to: VeriSign Time Stamping Services CA
        Issued by: Thawte Timestamping CA
        Expires:   Tue Dec 03 23:59:59 2013
        SHA1 hash: F46AC0C6EFBB8C6A14F55F09E2D37DF4C0DE012D

            Issued to: VeriSign Time Stamping Services Signer - G2
            Issued by: VeriSign Time Stamping Services CA
            Expires:   Thu Jun 14 23:59:59 2012
            SHA1 hash: ADA8AAA643FF7DC38DD40FA4C97AD559FF4846DE

SignTool Error: WinVerifyTrust returned error: 0x80096010
        The digital signature of the object did not verify.

Number of files successfully Verified: 0
Number of warnings: 0
Number of errors: 1

C:\Documents and Settings\rgrecour\My Documents\installer>signtool verify /pa /v ogs-3.1.1-windows.exe

Verifying: ogs-3.1.1-windows.exe
SignTool Error: CryptCATAdminCalcHashFromFileHandle returned error: 0x00000057
        The parameter is incorrect.
Hash of file (sha1): 4629BB77009469B2B3891B01723D407DCB3DBDF3

Signing Certificate Chain:
    Issued to: Class 3 Public Primary Certification Authority
    Issued by: Class 3 Public Primary Certification Authority
    Expires:   Wed Aug 02 23:59:59 2028
    SHA1 hash: A1DB6393916F17E4185509400415C70240B0AE6B

        Issued to: VeriSign Class 3 Code Signing 2009-2 CA
        Issued by: Class 3 Public Primary Certification Authority
        Expires:   Mon May 20 23:59:59 2019
        SHA1 hash: 12D4872BC3EF019E7E0B6F132480AE29DB5B1CA3

            Issued to: Oracle America, Inc.
            Issued by: VeriSign Class 3 Code Signing 2009-2 CA
            Expires:   Sat Jul 06 23:59:59 2013
            SHA1 hash: 9E2B73433C7FF0BE9C2E546C46A3D16A6CDACF32

The signature is timestamped: Tue Oct 12 20:12:53 2010
Timestamp Verified by:
    Issued to: Thawte Timestamping CA
    Issued by: Thawte Timestamping CA
    Expires:   Thu Dec 31 23:59:59 2020
    SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656

        Issued to: VeriSign Time Stamping Services CA
        Issued by: Thawte Timestamping CA
        Expires:   Tue Dec 03 23:59:59 2013
        SHA1 hash: F46AC0C6EFBB8C6A14F55F09E2D37DF4C0DE012D

            Issued to: VeriSign Time Stamping Services Signer - G2
            Issued by: VeriSign Time Stamping Services CA
            Expires:   Thu Jun 14 23:59:59 2012
            SHA1 hash: ADA8AAA643FF7DC38DD40FA4C97AD559FF4846DE

SignTool Error: WinVerifyTrust returned error: 0x80096010
        The digital signature of the object did not verify.

Number of files successfully Verified: 0
Number of warnings: 0
Number of errors: 1

C:\Documents and Settings\rgrecour\My Documents\installer>

C:\Documents and Settings\rgrecour\My Documents\installer>signtool verify /pa /v glassfish-3.1.2-b05-windows.exe

Verifying: glassfish-3.1.2-b05-windows.exe
SignTool Error: CryptCATAdminCalcHashFromFileHandle returned error: 0x00000057
        The parameter is incorrect.
Hash of file (sha1): 4629BB77009469B2B3891B01723D407DCB3DBDF3

Signing Certificate Chain:
    Issued to: Class 3 Public Primary Certification Authority
    Issued by: Class 3 Public Primary Certification Authority
    Expires:   Wed Aug 02 23:59:59 2028
    SHA1 hash: A1DB6393916F17E4185509400415C70240B0AE6B

        Issued to: VeriSign Class 3 Code Signing 2009-2 CA
        Issued by: Class 3 Public Primary Certification Authority
        Expires:   Mon May 20 23:59:59 2019
        SHA1 hash: 12D4872BC3EF019E7E0B6F132480AE29DB5B1CA3

            Issued to: Oracle America, Inc.
            Issued by: VeriSign Class 3 Code Signing 2009-2 CA
            Expires:   Sat Jul 06 23:59:59 2013
            SHA1 hash: 9E2B73433C7FF0BE9C2E546C46A3D16A6CDACF32

The signature is timestamped: Tue Oct 12 20:12:53 2010
Timestamp Verified by:
    Issued to: Thawte Timestamping CA
    Issued by: Thawte Timestamping CA
    Expires:   Thu Dec 31 23:59:59 2020
    SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656

        Issued to: VeriSign Time Stamping Services CA
        Issued by: Thawte Timestamping CA
        Expires:   Tue Dec 03 23:59:59 2013
        SHA1 hash: F46AC0C6EFBB8C6A14F55F09E2D37DF4C0DE012D

            Issued to: VeriSign Time Stamping Services Signer - G2
            Issued by: VeriSign Time Stamping Services CA
            Expires:   Thu Jun 14 23:59:59 2012
            SHA1 hash: ADA8AAA643FF7DC38DD40FA4C97AD559FF4846DE

SignTool Error: WinVerifyTrust returned error: 0x80096010
        The digital signature of the object did not verify.

Number of files successfully Verified: 0
Number of warnings: 0
Number of errors: 1


C:\Documents and Settings\rgrecour\My Documents\installer>signtool verify /pa /v java_ee_sdk-6u3-windows.exe

Verifying: java_ee_sdk-6u3-windows.exe
SignTool Error: CryptCATAdminCalcHashFromFileHandle returned error: 0x00000057
        The parameter is incorrect.
Hash of file (sha1): 4629BB77009469B2B3891B01723D407DCB3DBDF3

Signing Certificate Chain:
    Issued to: Class 3 Public Primary Certification Authority
    Issued by: Class 3 Public Primary Certification Authority
    Expires:   Wed Aug 02 23:59:59 2028
    SHA1 hash: A1DB6393916F17E4185509400415C70240B0AE6B

        Issued to: VeriSign Class 3 Code Signing 2009-2 CA
        Issued by: Class 3 Public Primary Certification Authority
        Expires:   Mon May 20 23:59:59 2019
        SHA1 hash: 12D4872BC3EF019E7E0B6F132480AE29DB5B1CA3

            Issued to: Oracle America, Inc.
            Issued by: VeriSign Class 3 Code Signing 2009-2 CA
            Expires:   Sat Jul 06 23:59:59 2013
            SHA1 hash: 9E2B73433C7FF0BE9C2E546C46A3D16A6CDACF32

The signature is timestamped: Tue Oct 12 20:12:53 2010
Timestamp Verified by:
    Issued to: Thawte Timestamping CA
    Issued by: Thawte Timestamping CA
    Expires:   Thu Dec 31 23:59:59 2020
    SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656

        Issued to: VeriSign Time Stamping Services CA
        Issued by: Thawte Timestamping CA
        Expires:   Tue Dec 03 23:59:59 2013
        SHA1 hash: F46AC0C6EFBB8C6A14F55F09E2D37DF4C0DE012D

            Issued to: VeriSign Time Stamping Services Signer - G2
            Issued by: VeriSign Time Stamping Services CA
            Expires:   Thu Jun 14 23:59:59 2012
            SHA1 hash: ADA8AAA643FF7DC38DD40FA4C97AD559FF4846DE

SignTool Error: WinVerifyTrust returned error: 0x80096010
        The digital signature of the object did not verify.

Number of files successfully Verified: 0
Number of warnings: 0
Number of errors: 1

C:\Documents and Settings\rgrecour\My Documents\installer>

By looking at the above output we can say that there is something wrong: Hash of file (sha1): 4629BB77009469B2B3891B01723D407DCB3DBDF3 is the same for every file! Other than the hash method (sha1) I don't know how this hash is computed, I tried to match this with the string obtained from "sha1sum" and fciv without any results.

Comment by Romain Grécourt [ 14/Dec/11 ]

re-assigning to Sathyan.

Comment by Romain Grécourt [ 20/Oct/12 ]

We should try to fix this for 4.0

Comment by Joe Di Pol [ 21/Mar/13 ]

Unclear to me if this is still an issue or not. Assigning to Snjezana to keep an eye on.

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

FWIW, I know that installer startup dialog on Windows still reports "Unknown publisher". That being said, we probably don't have the luxury of tinkering with this in this release...





[GLASSFISH-16622] Root applications (context root "/") listen on all virtual servers until server is restarted. Created: 12/May/11  Updated: 14/Oct/11  Resolved: 14/Oct/11

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1_b43
Fix Version/s: 4.0_b06

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

Debian inside VServer


Attachments: XML File domain.xml     Text File server.log    
Tags: 3_1-next, context_root, deployment, virtual_server

 Description   

When I deploy a web application with the context root of "/" via the web administrative panel to a virtual server listening on domain "example.com", the application will act as if deployed to every virtual server, including the admin panel. Restarting the server (via asadmin) fixes the problem (after a restart, it only listens on example.com). This happens on initial deployment of an application and upon redeployment of an application.

When redeploying an application, I am selecting the file and clicking OK. I am not changing any options from their default options. After redeploying, the admin panel will cease the function and will instead show errors (such as resource not found) and act as if I am accessing that resource.



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

I tried with both admin cli and console (specifying the virtual server as part of the deployment), and the domain.xml application-ref enetry has the specified virtual server as expected.
Assign to web team to check if the application is also only loaded on the specified virtual server as expected and follow up with the user.

Comment by ckuehl [ 15/May/11 ]

Thanks for looking into this. I did some further testing and it appears to only happen when redeploying an existing application via the web panel, not during initial deployment as I initially reported.

Comment by Amy Roh [ 17/May/11 ]

Hi ckuehl,

To clarify, you're saying if you redeploy an existing application with the context root of "/" using the admin gui, the application will act as if it deployed to every virtual server including the admin webapp and the admin gui will cease to function until restart, correct?

Does this also happen when you redeploy using admin cli and not the admin gui?

Can you please include your domain.xml and server.log after you redeploy in order for us to understand your exact setup?

Thanks,
Amy

Comment by ckuehl [ 17/May/11 ]

Hi,

Yes, your summary is correct.

I have just tested and it also happens when redeploying via the CLI:

asadmin> redeploy --name GraalCenterAccounts /home/appman/GraalCenterAccounts.war
Enter admin user name> admin
Enter admin password for user "admin">
Application deployed with name GraalCenterAccounts.
Command redeploy executed successfully.

I will attach my domain.xml and server.log.

Thanks again for looking into this.

Comment by ckuehl [ 23/May/11 ]

I'd like to clarify again:

When redeploying, it does not act as if deployed to all virtual servers. Instead, all applications, including the administrative GUI, act as if undeployed. I see the "Your server is now running" page when trying to access other applications.

This is also happening occasionally when using the asadmin cli.

Comment by Amy Roh [ 26/May/11 ]

I tried your scenario on mac and everything works as expected. I'm trying to understand how and if our configurations are different.

I see "User [] from host localhost does not have administration access" in your server.log. How are you accessing the admin gui? Can you access it locally?

Comment by ckuehl [ 28/May/11 ]

I tried to setup reliable steps to replicate this bug but was unable to on a different system than the one it occurred on. I have updated to 3.2-b06 and the problem has resolved itself.

Thanks again for the help.

Comment by Amy Roh [ 31/May/11 ]

Issue resolved as the reporter stated. Couldn't reproduce.





[GLASSFISH-16618] ScatteredArchive should allow null name Created: 12/May/11  Updated: 23/May/11  Resolved: 23/May/11

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

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

Tags: 3_1-next, 3_1_1-scrubbed

 Description   

Current requirement to specify SA name contradicts the following features in GlassFish:
a) CLI deploy attributes where name is optional;
b) DOL ignores this name when an app name is provided in the deployment descriptor

In addition, SA can construct an appropriate name from the file used to create SA to avoid code duplication that would need to do the same work on each client side.



 Comments   
Comment by Bhavanishankar [ 23/May/11 ]

This looks like an invalid issue.

(a) CLI deploy attributes where name is optional;

CLI deploy uses the JAR file not ScatteredArchive. So, if you already have a JAR file, don't use ScatteredArchive. Idea of scattered archive is to build on-the-fly archive with the name you have supplied. So, you must supply a name.

(b) DOL ignores this name when an app name is provided in the deployment descriptor

That behavior will remain the same with ScatteredArchive as well.





[GLASSFISH-16615] HA session expires issue Created: 11/May/11  Updated: 17/Oct/11

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

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

Status Whiteboard:

3_1-next

Tags: 3_1-next, 3_1_1-scrubbed, 3_1_x-exclude

 Description   

Suppose we have a load balancer with 3 instances.
1. A section, s1, is created in instance 1 for a given app.
2. There is a network issue. instance 1 is not available in the network.
3. Subsequent requests go to instance 2.
4. The session, s1, in instance 1 is still in memory and will be expired, and then removed.
This will cause an issue.

The same issue is in HA SSO.



 Comments   
Comment by Shing Wai Chan [ 11/May/11 ]

In case of HA SSO, one also need versioning in order to solve the problem. This has been filed as issue GLASSFISH-16377 and the fixed has been checkin to trunk.

Comment by Mahesh Kannan [ 20/May/11 ]

This really requires a new feature to be implemented in shoal. Basically, it requires shoal to maintain info about which instance is the owning instance of a session. This allows shoal to ignore stale 'remove-expire" commands.

This is a new feature and hence deferring it to 3.1-next





[GLASSFISH-16607] glassfish-3.1/mq/bin/imqusermgr does not allow to choose which broker to connect to Created: 11/May/11  Updated: 19/Nov/11  Resolved: 19/Nov/11

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

Type: Bug Priority: Major
Reporter: deathtooracle Assignee: Satish Kumar
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

any unix / linux


Tags: 3_1-next, 3_1_1-scrubbed

 Description   

We have 2 independant domains running on the same server, each with its own broker (ports 7676 and 4976). glassfish-3.1/mq/bin/imqusermgr has no option to connect to the second domain (port 4976) in order to alter user login information, instead it always connects to domain1 on port 7676. As a workaround one must create the user login information on a test glassfish and then copy the file glassfish-3.1/glassfish/domains/domain1/imq/instances/imqbroker/etc/passwd over to the production domain and restart the broker.



 Comments   
Comment by Satish Kumar [ 18/Nov/11 ]

The imqusermgr has a -i option to specify the brokername but does not seem to have an option to specify the broker host/port. In the above scenario the brokername would be the same for both the domains. Although the use case described here is rather unusual, there appears to be no way to connect to the broker running on the non-7676 port.

Reassigning the issue to Amy K to investigate...

Comment by amyk [ 18/Nov/11 ]

imqusermgr has -varhome option to specify MQ_VARHOME of the broker instance, see imqusermgr -h and Oracle GlassFish Server 3.1 Administration Guide,
http://download.oracle.com/docs/cd/E18930_01/html/821-2416/gipbg.html#gktfb

"Should the need to use Message Queue utilities arise, you must use the -varhome option when running certain Message Queue utilities to specify the IMQ_VARHOME location of the Embedded or Local JMS host. This location depends on which GlassFish instance the JMS host is servicing"

Comment by Satish Kumar [ 19/Nov/11 ]

As suggested by Amy, you will need to use the -varhome option.
Closing this issue since it is not a bug...





[GLASSFISH-16587] request.getUserPrincipal() does not return MyPrincipal Created: 09/May/11  Updated: 17/Oct/15

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

Type: Bug Priority: Major
Reporter: gernot1 Assignee: kumarjayanti
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-next, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

I've an own javax.security.auth.message.module.ServerAuthModule implementation.
In validateRequest() I put an instance of MyPrincipal to the callbackhandler
MyPrincipal myprincipal = ...;
callbackHandler.handle(new Callback[]

{ new CallerPrincipalCallback(clientSubject, myprincipal), new GroupPrincipalCallback(...) }

);
In the application request.getUserPrincipal() returns an instance of com.sun.enterprise.security.web.integration.WebPrincipal and NOT an instance of MyPrincipal!

In an ejb the call of ejbContext.getCallerPrincipal() does return an instance of MyPrincipal!

==> request.getUserPrincipal() should return the principal which is set in the ServerAuthModule



 Comments   
Comment by kumarjayanti [ 09/May/11 ]

yes this is a known issue and we made some work on it to get the behavior you are looking for. It is still not committed, more work to do.

Comment by kumarjayanti [ 18/May/11 ]

We will make an attempt to get this fixed for 3.1.1 but cannot commit based on resources and time left.

Comment by sultry [ 14/May/15 ]

Depends on this bug made that workaround:

private static Principal glassfishWorkAround(HttpServletRequest request) {
        Principal principal = null;
        try {
            Principal webPrincipal = request.getUserPrincipal();
            if (webPrincipal != null) {
                Class glassfishWrapper = Class.forName("com.sun.enterprise.security.web.integration.WebPrincipal");
                if (glassfishWrapper.isInstance(webPrincipal)) {
                    Field customPrincipal = glassfishWrapper.getDeclaredField("customPrincipal");
                    customPrincipal.setAccessible(true);
                    principal = (Principal) customPrincipal.get(webPrincipal);
                } else {
                    principal = webPrincipal;
                }
            }
        } catch (IllegalArgumentException | IllegalAccessException | NoSuchFieldException | SecurityException | ClassNotFoundException ex) {
            LOGGER.throwing("SecurityConstraint", "glassfishWorkAround", ex);
        }
        return principal;
}

public static Principal getPrincipal(HttpServletRequest request) {
        return glassfishWorkAround(request);
}

Hope it helps somebody! Anyway hope this bug will be resolved soon.

Comment by arjan tijms [ 17/Oct/15 ]

Any progress here?





[GLASSFISH-16575] Object doesn't support this property or method at ... resource/common/js/adminjsf.js line 2091 Created: 06/May/11  Updated: 16/Jun/11  Resolved: 16/Jun/11

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: brimimc Assignee: Jason Lee
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-next, 3_1_1-scrubbed

 Description   

Though it seems consistent on some machines, it seems like a timing issue. Line 2091 is

adminggui.ajax.pingHeader()

inside the admingui.ajax.get function

It seems that it's possible for this line of code to be executed prior to the loading of the definition of pingHeader (which is defined at the end of the object's declarations)



 Comments   
Comment by Anissa Lam [ 10/May/11 ]

Can you be more specific on what you are experiencing ?

Comment by brimimc [ 10/May/11 ]

I receive a script error when using the admin gui - the error message is

Object doesn't support this property or method at ... resource/common/js/adminjsf.js line 2091

The method it is complaining about seems to be pingHeader()

It looks like a timing issue, if the page is slow to load, it's possible for this line of code to be executed prior to the complete loading of the adminjsf.js. Since pingHeader is defined at the end of the file it's not yet defined.

Comment by brimimc [ 12/May/11 ]

Is that enough detail or do you need more info?

Comment by Jason Lee [ 17/May/11 ]

What browser and OS? Do you have a set of steps we can follow to reproduce this? I'm not seeing it locally. :|

Comment by brimimc [ 17/May/11 ]

Win7/XP 32 bit IE8 - but we have seen it work on XP 32 bit IE8 as well. I don't think it's a platform issue, but a timing issue (e.g if you machine is slower it's more likely to happen).

I'll try and get a stack trace for you, but you should be able to help it along by adding a bunch of noop code before the definition of pingHeader to delay the loading of the method definition.

Comment by brimimc [ 17/May/11 ]

Also of note this is being displayed in the embedded active x IE component - not sure if this have any relation other than it may be slower than the external browser?

Comment by brimimc [ 18/May/11 ]

This was in the log:

07:59:38.06][ERROR]: SCRIPT ERROR: Object doesn't support this property or method at http://msass4:4848/resource/common/js/adminjsf.js line 2091
[07:59:38.17][ERROR]: Error was in: function() {
admingui.ajax.loadPage(

{ url : url, target: document.getElementById('content'), oldOnClickHandler: oldOnClick, sourceNode: node }

);
return false;
}
[07:59:38.18][INFO]: Received DOM Event: [BID: 0][FPATH: ][TYPE: click][PATH: //A[@id='treeForm:tree:applications:applications_link']][LOC: 594, 160][THINK: 175][URL: http://msass4:4848/common/index.jsf][TAG: A][SUBTAG: ][VALUE: Applications]

Comment by Jason Lee [ 02/Jun/11 ]

I just noticed that you said "this is being displayed in the embedded active x IE component". Does that mean you're NOT using the standalone Internet Explorer application but are, rather, using a third party app that embeds IE via this ActiveX control? If so, what app is that? Is it publicly/freely available? I have not been able to reproduce this issue on my WinXP VM with IE 8.

Comment by Jason Lee [ 02/Jun/11 ]

Can this same user reproduce the issue on the more traditional standalone IE 8 on the same box?

Comment by Jason Lee [ 02/Jun/11 ]

I'm not sure the no-op code would achieve much, because, as I understand things, Javascript is single threaded. When the browser finds a script tag, it loads (either from the page or the specified remote resource) the Javascript source and processes it before moving on to the next element on the page. I've done some searching for a definitive answer on that and haven't found anything to contradict it. If I'm wrong, and you know of a definitive refutation, I'd certainly love to see it.

Comment by brimimc [ 03/Jun/11 ]

No, it does seem limited to the embedded active X component.

In fact we may have found the problem outside of glassfish. I'll verify this and get back to you.

Comment by Anissa Lam [ 15/Jun/11 ]

any update ?
We will close this issue on Friday, 6/17, if we don't hear anything. thanks.

Comment by brimimc [ 15/Jun/11 ]

Yes, go ahead and close it. It was due to xmlhttprequest being hijacked and not a problem in glassfish. Sorry for the bogus case.

Comment by Jason Lee [ 16/Jun/11 ]

Closed per reporter's request.





[GLASSFISH-16573] message logged as INFO should be logged as FINE Created: 06/May/11  Updated: 06/Jun/11  Resolved: 06/Jun/11

Status: Resolved
Project: glassfish
Component/s: jsf
Affects Version/s: 3.1.1_b04
Fix Version/s: 3.1.1_b07

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

Attachments: Text File changebundle-GF-16573.txt    
Issue Links:
Duplicate
is duplicated by GLASSFISH-16577 "No execute and render identifiers sp... Resolved
Tags: 3_1-next

 Description   

I am seeing the following message in server.log when running Admin Console.

[#|2011-05-06T09:23:48.508-0700|INFO|glassfish3.1|javax.enterprise.resource.webcontainer.jsf.context|_ThreadID=26;_ThreadName=admin-thread-pool-4848(5);|No execute and render identifiers specified. Skipping component processing.|#]

[#|2011-05-06T09:23:48.509-0700|INFO|glassfish3.1|javax.enterprise.resource.webcontainer.jsf.context|_ThreadID=26;_ThreadName=admin-thread-pool-4848(5);|No execute and render identifiers specified. Skipping component processing.|#]

[#|2011-05-06T09:23:48.509-0700|INFO|glassfish3.1|javax.enterprise.resource.webcontainer.jsf.context|_ThreadID=26;_ThreadName=admin-thread-pool-4848(5);|No execute and render identifiers specified. Skipping component processing.|#]

user will see this log every few clicks in GUI. and everytime it shows up, it shows up as a group of 3.

GUI has a header page, and we just want to do a "ping" ajax request. It will not execute or render anything. This is probably causing this message.
The msg suggests that it is skipping "component processing" because the Ajax request did not ask for any components to be executed or rendered. I don't know if this log is really needed. At most, it should be logged at FINE level.

This logging at INFO happens recently. It did NOT show up in 3.1 final release. But i am seeing that when running the trunk AND also on 3.1.1. This needs to be fixed.



 Comments   
Comment by rogerk [ 20/May/11 ]

Changes.

Comment by rogerk [ 20/May/11 ]

Committed to Mojarra trunk:
Committed revision 9063.

Committed to Mojarra branch MOJARRA_2_1_ROLLING:
Committed revision 9064.

This should be available in the Mojarra 2.1.2 release for GlassFish 3.1.1

Comment by rogerk [ 27/May/11 ]

reopen to edit fix version

Comment by rogerk [ 27/May/11 ]

fix version

Comment by rogerk [ 27/May/11 ]

re-closing

Comment by scatari [ 06/Jun/11 ]

Fixing the target version to include the correct build number.

Comment by scatari [ 06/Jun/11 ]

Fixing the target version to include the correct build number.





[GLASSFISH-16568] GMS can select incorrect network interface when a Virtual Machine created bridge n/w interface (virbr0) exists Created: 06/May/11  Updated: 14/Oct/11

Status: In Progress
Project: glassfish
Component/s: group_management_service
Affects Version/s: 3.1.1_b04
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: varunrupela Assignee: Joe Fialli
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux [FQDN removed] 2.6.18-164.el5 #1 SMP Thu Sep 3 04:15:13 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

Virtual Machine has created a network interface virbr0 on each of 3 machines.
java.net.NetworkInterface.getNetworkInterfaces() is returning virbr0 as first interface.
This interface was not working for TCP point to point messaging in GMS.

Here is network interface config from ifconfig -a.
The virbr0 configuration (same on all 3 machines so the IP address not being unique is a big problem)

eth0 Link encap:Ethernet HWaddr 00:16:36:FF:D5:C8
inet addr:10.12.153.53 Bcast:10.12.153.255 Mask:255.255.255.0
inet6 addr: fe80::216:36ff:feff:d5c8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:163499623 errors:0 dropped:0 overruns:0 frame:0
TX packets:164695644 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:40318720962 (37.5 GiB) TX bytes:68091586600 (63.4 GiB)
Interrupt:66 Memory:fdff0000-fe000000

<deleted eth1 - eth3, none were UP>
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:276021187 errors:0 dropped:0 overruns:0 frame:0
TX packets:276021187 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:47722695747 (44.4 GiB) TX bytes:47722695747 (44.4 GiB)

sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

virbr0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0
inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:137 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:40467 (39.5 KiB)


Attachments: Zip Archive fine-shoal-logs.zip     Zip Archive logs.zip    
Issue Links:
Dependency
blocks GLASSFISH-15425 [STRESS][umbrella] 24x7 RichAccess ru... Open
Related
is related to GLASSFISH-16570 [regression w.r.t 3.1] Classloading i... Resolved
is related to GLASSFISH-16631 resource bundle resolution failing in... Resolved
Tags: 3_1-next, 3_1_1-scrubbed

 Description   

Please see the parent bug http://java.net/jira/browse/GLASSFISH-15425 for scenario details.

On running the RichAccess Big App test the instance logs are observed to be filled with Grizzly and Shoal logger messages of the following type:

******
[#|2011-05-06T11:26:53.439+0530|SEVERE|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=29;_ThreadName=Thread-1;|Connection refused|#]

[#|2011-05-06T11:26:53.445+0530|SEVERE|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=30;_ThreadName=Thread-1;|Connection refused|#]

[#|2011-05-06T11:26:53.447+0530|WARNING|glassfish3.1|ShoalLogger|_ThreadID=31;_ThreadName=Thread-1;|Error during groupHandle.sendMessage(instance103, /richAccess; size=30672|#]

*******

  • No http failures were on observed on the client.
  • 2 sets of logs are being attached. 1 with Shoal logger set to fine and 1 without. Unzip and look under "logs/st-cluster" for the instance logs.
  • This issue appears with both Sun JDK and JRockit JDK


 Comments   
Comment by varunrupela [ 12/May/11 ]

Marked the issue as blocking. Its hard to analyze the logs and extract information useful to debug the run.

Comment by Joe Fialli [ 13/May/11 ]

Perhaps there is firewall configuration preventing connections. GMS is using UDP multicast to find all instances and communicate
GMS notifications. All of that is working just fine.
However, I have not seen any TCP connections succeed.
The gms send messages that are failing are over TCP and they are HA replication sends.

Below is a pure Grizzly connection that that does not have anything to do with GMS. GMS names all of its threads with "gms" in them (even the thread pool given to Grizzly to run gms handlers uses "gms" in the thread name.

There are 1574 of the following failures.

server.log:[#|2011-05-06T11:28:11.435+0530|SEVERE|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|
_ThreadID=40;_ThreadName=Thread-1;|Connection refused|#]

Such a failure looks similar to what would happen if a firewall was blocking ports. It is suspcious that the instances
are all running on same machine and the connections are failing. Thus, firewall is probably blocking intermachine TCP communication.

*************

It was not stated but I have observed that 3 instances and das are all running on one machine.
I have not observed it yet, but if there is not sufficient memory on the machine, the instances
could start running out of memory. My past experience with rich access not all instances where run on one machine.

[#|2011-05-06T11:20:37.552+0530|INFO|glassfish3.1|ShoalLogger|_ThreadID=16;_ThreadName=Thread-1;|GMS1092: GMS View Change Received for group: st-cluster : Members in view for JOINED_AND_READY_EVENT(before change analysis) are :
1: MemberId: instance101, MemberType: CORE, Address: 192.168.122.1:9186:228.9.30.160:9176:st-cluster:instance101
2: MemberId: instance102, MemberType: CORE, Address: 192.168.122.1:9163:228.9.30.160:9176:st-cluster:instance102
3: MemberId: instance103, MemberType: CORE, Address: 192.168.122.1:9091:228.9.30.160:9176:st-cluster:instance103
4: MemberId: server, MemberType: SPECTATOR, Address: 192.168.122.1:9114:228.9.30.160:9176:st-cluster:server

#]

More analysis to come. Just wanted to pass this along.

Comment by Joe Fialli [ 13/May/11 ]

The tcp ports that GMS needs to not be blocked by a firewall are between 9090 and 9200.
For the above run, the ports used were randomly selected from the above range and are
9186, 9163, 9091 ad 9114. The next run will have different ports so unblocking
the tcp port range from 9090 to 9200 is necessary.

Comment by Joe Fialli [ 13/May/11 ]

There would be no log message printed out for this gms send message failure since the logging is set to FINE.
However, the lookup of the Logger is failing. (something different in jrockit environment is causing this.)

The following stack trace is occurring trying to get a resource bundle for a java.util.Logger.
The call is java.util.Logger.getLogger("ShoalLogger.send", "com.sun.enterprise.ee.cms.logging.LogStrings");

The resource bundle in question is com.sun.enterprise.ee.cms.logging.LogStrings.properties.

The error message is incorrectly stating that it is looking for a class called com.sun.enterprise.ee.cms.logging.LogStrings.
No such class exists. We need assistance from someone with class loading/resource bundle knowledge to find out why this is going
wrong in jrockit environment.

[#|2011-05-06T11:26:53.369+0530|WARNING|glassfish3.1|javax.enterprise.system.core.classloading.com.sun.enterprise.loader|_ThreadID=28;_ThreadName=Thread-1;|LDR5207: ASURLClassLoader EarLibClassLoader :
doneCalled = true
doneSnapshot = ASURLClassLoader.done() called ON EarLibClassLoader :
urlSet = []
doneCalled = false
Parent -> org.glassfish.internal.api.DelegatingClassLoader@392aa3fb

AT Fri May 06 11:26:28 IST 2011
BY :java.lang.Throwable: printStackTraceToString
at com.sun.enterprise.util.Print.printStackTraceToString(Print.java:639)
at com.sun.enterprise.loader.ASURLClassLoader.done(ASURLClassLoader.java:211)
at com.sun.enterprise.loader.ASURLClassLoader.preDestroy(ASURLClassLoader.java:179)
at org.glassfish.javaee.full.deployment.EarClassLoader.preDestroy(EarClassLoader.java:114)
at org.glassfish.internal.data.ApplicationInfo.unload(ApplicationInfo.java:358)
at com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:999)
at com.sun.enterprise.v3.server.ApplicationLifecycle.disable(ApplicationLifecycle.java:1970)
at com.sun.enterprise.v3.server.ApplicationConfigListener.disableApplication(ApplicationConfigListener.java:278)
at com.sun.enterprise.v3.server.ApplicationConfigListener.handleOtherAppConfigChanges(ApplicationConfigListener.java:198)
at com.sun.enterprise.v3.server.ApplicationConfigListener.transactionCommited(ApplicationConfigListener.java:146)
at org.jvnet.hk2.config.Transactions$TransactionListenerJob.process(Transactions.java:344)
at org.jvnet.hk2.config.Transactions$TransactionListenerJob.process(Transactions.java:335)
at org.jvnet.hk2.config.Transactions$ListenerNotifier$1.call(Transactions.java:211)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at org.jvnet.hk2.config.Transactions$Notifier$1$1.run(Transactions.java:165)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Parent -> org.glassfish.internal.api.DelegatingClassLoader@392aa3fb
was requested to find class com.sun.enterprise.ee.cms.logging.LogStrings after done was invoked from the following stack trace
java.lang.Throwable
at com.sun.enterprise.loader.ASURLClassLoader.findClassData(ASURLClassLoader.java:780)
at com.sun.enterprise.loader.ASURLClassLoader.findClass(ASURLClassLoader.java:696)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:296)
at java.lang.ClassLoader.loadClass(ClassLoader.java:296)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2289)
at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1364)
at java.util.ResourceBundle.findBundle(ResourceBundle.java:1328)
at java.util.ResourceBundle.findBundle(ResourceBundle.java:1282)
at java.util.ResourceBundle.findBundle(ResourceBundle.java:1282)
at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1224)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:952)
at java.util.logging.Logger.findResourceBundle(Logger.java:1280)
at java.util.logging.Logger.setupResourceInfo(Logger.java:1335)
at java.util.logging.Logger.getLogger(Logger.java:335)
at com.sun.enterprise.ee.cms.logging.GMSLogDomain.getSendLogger(GMSLogDomain.java:87)
at com.sun.enterprise.ee.cms.impl.base.GroupCommunicationProviderImpl.logSendMessageException(GroupCommunicationProviderImpl.java:395)
at com.sun.enterprise.ee.cms.impl.base.GroupCommunicationProviderImpl.sendMessage(GroupCommunicationProviderImpl.java:366)
at com.sun.enterprise.ee.cms.impl.base.GroupHandleImpl.sendMessage(GroupHandleImpl.java:142)
at org.shoal.ha.group.gms.GroupServiceProvider.sendMessage(GroupServiceProvider.java:257)
at org.shoal.ha.cache.impl.interceptor.TransmitInterceptor.onTransmit(TransmitInterceptor.java:83)
at org.shoal.ha.cache.api.AbstractCommandInterceptor.onTransmit(AbstractCommandInterceptor.java:98)
:doneCalled = true
doneSnapshot = ASURLClassLoader.done() called ON EarLibClassLoader :
urlSet = []
doneCalled = false
Parent -> org.glassfish.internal.api.DelegatingClassLoader@392aa3fb

Comment by Joe Fialli [ 13/May/11 ]

The submitted fine server logging did not have any ShoalLogger of FINE level.
Only had FINE logging for org.shoal.ha.

To enable GMS ShoalLogger, one needs to specify ShoalLogger with FINE level.
(Shoal GMS does not use org.shoal.gms* for logger name, but still uses ShoalLogger.)

Since the connection refused is in grizzly, it might be of more use to
set grizzly logging to FINE if it turns out that there is no firewall protection
blocking GMS tcp communications on ports between 9090 and 9200. (the default
gms port ranges. User can override these defaults if necessary.)

[#|2011-05-06T12:48:40.087+0530|SEVERE|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=51;_ThreadName=Thread-1;|Connection refused|#]

So enabling logging of com.sun.grizzly to FINE my help find out why the Connection was refused.

Comment by varunrupela [ 16/May/11 ]

Clarification regarding the setup:

  • Multiple network interfaces are enabled on all the 3 machines on this setup and GMS on each seems to bind to the virtual n/w interface 192.168.122.1.
Comment by Joe Fialli [ 17/May/11 ]

Please follow documentation to configure gms to bind to a specific network interface.

http://download.oracle.com/docs/cd/E18930_01/html/821-2426/gjfnl.html#gjdlw

Also, recommend running "asadmin validate-multicast -bindaddress X.X.X.X" on all three machines
to double check that UDP multicast traffic is working properly on whatever subnet that you select.

Comment by Joe Fialli [ 17/May/11 ]

Removed blocking and regression from subject line and changed subject line to match what the issue was discovered to be.
This was not a regression, same issue would exist in 3.1 as 3.1.1. No changes were made in 3.1.1 that caused
this. There was a change in the configured environment that caused this issue to surface.

Simple workaround is to disable or down the virbr0 network interface that were not being used.

The following error messages were being repeated many times in server.log file.

[#|2011-05-06T11:26:53.445+0530|SEVERE|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=30;_ThreadName=Thread-1;|Connection refused|#]

[#|2011-05-06T11:26:53.447+0530|WARNING|glassfish3.1|ShoalLogger|_ThreadID=31;_ThreadName=Thread-1;|Error during groupHandle.sendMessage(instance103, /richAccess; size=30672|#]

We will add to the GMS log event message above with the IP address trying to be sent to assist in diagnosing this problem in future.

java.net.NetworkInterface.getNetworkInterfaces() was returning the virbr0 network interface as first interface
and that resulted in this issue. To resolve this issue, GMS will default initially to
network interface associated with InetAddress.getLocalHost(), (as long as that n/w interface is multicast enabled
and not a loopback address and UP.) This default would have avoided the reported issue.

When there are multiple n/w interfaces on a machine and the default is not the one desired to use for GMS,
the following documentation should be followed to configure GMS to use a specific n/w interface on each machine.

http://download.oracle.com/docs/cd/E18930_01/html/821-2426/gjfnl.html#gjdlw

Comment by Joe Fialli [ 17/May/11 ]

Also, add a configuration message to show the localPeerID and GMS system advertisement being sent to other machines to dynamically form the GMS group (glassfish cluster). This configuration message will show what IP address that GMS is telling other members of the cluster to contact it at.

Comment by Joe Fialli [ 13/Jun/11 ]

was unable to identify the non-functional virtual network interface using any of the java.network.NetworkInterface
methods. recommend postponing attempting to fix this issue in 3.1.1 time frame since changing the algorithm
on selecting the first network address could potentially introduce a regression for a previously
working existing network configuration. There is no means to just correct this issue without changing
how first network address is selected.

workaround did exist for this issue. simply disabled the virtual network interface that was not
being used.

Comment by Joe Fialli [ 14/Oct/11 ]

lowered priority to fix to minor since there is a workaround. Additionally this problem
is only the result of having a virtual network interface that was created by virtualbox but
was not being used. simply disabling the virb0 network interface that was not being used fixed
the problem. At this time, my recommendation is to document the issue and its workaround in release notes.





[GLASSFISH-16553] Hang observed in embedded tests run as part of web distribution build Created: 04/May/11  Updated: 02/Dec/11  Resolved: 19/Jul/11

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

Type: Bug Priority: Critical
Reporter: Sanjeeb Sahoo Assignee: Bhavanishankar
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu, JDK 1.6


Tags: 3_1-next, 3_1_1-scrubbed

 Description   

My build is stuck here:

"main" prio=10 tid=0x0983d000 nid=0x1077 in Object.wait() [0xb6b4d000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)

  • waiting on <0xa58c4328> (a com.sun.enterprise.v3.server.AppServerStartup$1)
    at java.lang.Thread.join(Thread.java:1143)
  • locked <0xa58c4328> (a com.sun.enterprise.v3.server.AppServerStartup$1)
    at com.sun.enterprise.v3.server.AppServerStartup.stop(AppServerStartup.java:452)
  • locked <0x85352650> (a com.sun.enterprise.v3.server.AppServerStartup)
    at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.stop(GlassFishImpl.java:88)
  • locked <0x85352630> (a com.sun.enterprise.glassfish.bootstrap.StaticGlassFishRuntime$1)
    at org.glassfish.ejb.embedded.EJBContainerProviderImpl.createContainer(EJBContainerProviderImpl.java:200)
  • locked <0x849534e0> (a java.lang.Object)
    at org.glassfish.ejb.embedded.EJBContainerProviderImpl.createEJBContainer(EJBContainerProviderImpl.java:130)
    at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:127)
    at org.glassfish.distributions.test.UnitTest.test(UnitTest.java:93)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
    at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
    at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
    at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
    at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
    at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:66)
    at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35)
    at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
    at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
    at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
    at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
    at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
    at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
    at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
    at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:993)

It seems Marina also observed a similar issue and has conveyed it to Bhavani this morning. So, I am filing this issue. This is NOT reproducible.



 Comments   
Comment by Bhavanishankar [ 05/May/11 ]

This seems to have happened due to the recent changes in EJB container, wherein the EJB container does start-stop of embedded glassfish multiple times during its EJBContainer.createContainer.

It is already a know problem that if glassfish.stop() is called immediately after glassfish.start() without much delay then it leads to a hang. I have filed this issue sometime ago during 3.1 timeframe : http://java.net/jira/browse/GLASSFISH-14877

Latest EJB container is falling exactly into that trap.

I will transfer the issue to Marina with the following suggestions which should help to fix this issue:

1. Remove the glassfish.start/stop/start sequence of calls.

2. As I understood from Marina, the only reason to obtain Habitat before server startup is to copy security files.

To understand more, I quickly glanced through EmbeddedSecurityUtil.copyConfigFiles method. It looks to me that this method only needs to know the instanceRoot. Nothing does it needs from Habitat.

So I would suggest that let EJB container obtain instanceRoot via System.getProperty("com.sun.aas.instanceRoot") and pass it directly to EmbeddedSecurityUtil. This system property will be available soon after you do glassfishRuntime.newGlassFish(). So, you don't need Habitat. (and no start-stop-start sequence is necessary).

3. Don't use the habitat directly in any case. Instead use glassfish.getService(Class<T> serviceType, String serviceName). It is same as habitat.getComponent(componentClass, componentName);

Comment by marina vatkina [ 05/May/11 ]

EJB container gets EmbeddedSecurity from habitat to call it so that security code is not exported...

Comment by marina vatkina [ 05/May/11 ]

I also need habitat directly for the cleanup of transactions and connectors if they are instantiated, e.g.

Inhabitant<TransactionManager> inhabitant =
habitat.getInhabitantByType(TransactionManager.class);
if (inhabitant != null && inhabitant.isInstantiated()) {
TransactionManager txmgr = inhabitant.get();

Comment by marina vatkina [ 05/May/11 ]

Added a short sleep in EJB container for now (rev 46711)

Comment by marina vatkina [ 05/May/11 ]

And one more note - the habitat passed into a method call was one more level of precaution against a malicious call to get the security files

Comment by Sanjeeb Sahoo [ 05/May/11 ]

Marina,

Please disable the test from the build, as I don't think adding a random sleep is sufficient. You are most welcome to have a separate profile where you run this test as part of the build, but it can't be part of everybody's build until a proper fix is made.

Sahoo

Comment by marina vatkina [ 06/May/11 ]

Sahoo, The tests are not part of the build. They are ejb devtests running in their own daily hudson job. Sleeping 1 sec avoids the deadlock and gives us time to find the proper solution to the security file copying problem without completely disabling all ejb embedded tests.

Comment by Sanjeeb Sahoo [ 06/May/11 ]

Marina,

Look at the exception stack trace in the description of this bug. It says
at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:127)

and this stack trace was part of a mvn install in v3 workspace!

So, I suggest we disable this test from the build.

Sahoo

Comment by marina vatkina [ 09/May/11 ]

Sahoo,

I do not own any embedded test that runs as a part of a build. And the stack trace above doesn't specify the test.

-marina

Comment by Bhavanishankar [ 19/Jul/11 ]

I have nothing to fix from my side for this issue. Hence closing it.





[GLASSFISH-16543] Performance regression in JavaEE (ejb) deployment Created: 04/May/11  Updated: 18/Jan/12

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

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

Issue Links:
Dependency
depends on GLASSFISH-17013 Significant apparent regression in OR... Open
depends on MQ-99 Performance regression in MQ start-up... Open
blocks GLASSFISH-16355 startup and footprint of larger size ... Open
Tags: 3_1-next, 3_1_2-exclude

 Description   

JavaEE developer benchmark shows ejb deployment is regressed significantly from 2.1.1 release. We are observing around 230% regression on 3.1.1 builds compare to last build b31g of 2.1.1



 Comments   
Comment by Tim Quinn [ 09/Jun/11 ]

Linking the apparent MQ start-up regression to this umbrella issue for the EJB start-up and deployment regression issue.

Comment by Tim Quinn [ 11/Jul/11 ]

Linking to the ORB start-up regression issue

Comment by scatari [ 26/Jul/11 ]

Targeting to be evaluated further and resolved in the patch release post 3.1.1.

Comment by Joe Di Pol [ 18/Jan/12 ]

We were unable to get the ORB GMBL fix into 3.1.2 (we did get a Metro fix in, but that is not reflected in the EJB benchmark). Deferring from 3.1.2





[GLASSFISH-16513] Events and @Observes(during=TransactionPhase.AFTER_COMPLETION) not working in Glassfish 3.1 Created: 02/May/11  Updated: 11/Dec/11  Resolved: 11/Dec/11

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1
Fix Version/s: 3.1.2_b14

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

Windows 7, 64bit, Windows XP, 32bit


Attachments: File AsyncWebApp.war     Zip Archive AsyncWebApp.zip    
Tags: 3_1-next, 3_1_1-scrubbed, 3_1_2-review, asynchronous, cdi, events, observes, weld-int-required

 Description   

First of all let me state, that the following code example worked just fine in GF 3.0.1. The troubles started when we switched to GF 3.1.

I'm using a method
@Asynchronous
public void executeFlowStep(@Observes(during=TransactionPhase.AFTER_COMPLETION) ExecuteFlowStepEvent executeFlowStepEvent)

Since the switch, whenever this method should receive an ExecuteFlowStepEvent I get the following error message:

WELD-000401 Failure while notifying an observer of event [package].ExecuteFlowStepEvent

No further information or Stacktrace is given. It works if I remove the @Asynchronous annotation and the AFTER_COMPLETION attribute, of course this breaks the program as I depend on the AFTER_COMPLETION timing.

Is this a bug, or is this intended behaviour?

Does this imply that Weld does NOT work with Asynchronous methods/AFTER_COMPLETION attributes?

Why did this work in GF 3.0.1?



 Comments   
Comment by ossaert [ 03/May/11 ]

Some extra info can be found here: http://www.java.net/forum/topic/glassfish/glassfish/weld-11-and-asynchronous-methods-gfv31.

Comment by ossaert [ 05/May/11 ]

by the way, it happens on a Ubuntu 10.04 64bit too.

Comment by Nazrul [ 09/May/11 ]

Compatibility issue with 3.0.1. We should take a look

Comment by ossaert [ 10/May/11 ]

I attached a sample project to illustrate the error. You can deploy the WAR on a GFv3.1 and point the browser to http://xxxx:yyyy/AsyncWebApp/resources/generic. You will see that the finishJob method in the MyActor-class fails with TransactionPhase.AFTER_SUCCESS.

Jan

Comment by Sivakumar Thyagarajan [ 13/Jun/11 ]

While trying to reproduce this issue, I see that WELD throws the WELD-000401 because of the underlying exception: org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308 Unable to resolve any beans for Types: [interface org.jboss.weld.context.ejb.EjbRequestContext]; Bindings: [@javax.enterprise.inject.Any(), @javax.enterprise.inject.Default(), @org.jboss.weld.context.unbound.Unbound()]

Could you share sources for your application? I would like to debug and find why the EJBRequestContext is not available in that injection point. Is there an easier way of reproducing this?

Comment by ossaert [ 14/Jun/11 ]

This is the source which produces the bug. If you have questions, don't hesitate to ask.
Greetings,
Jan

Comment by Sivakumar Thyagarajan [ 26/Jun/11 ]

Thanks Jan for the sources. I am working with the Weld team to understand the root cause. I will update this thread as soon as I have more information. Thanks

Comment by prasads [ 27/Jun/11 ]

Increasing the priority

Comment by Sivakumar Thyagarajan [ 08/Jul/11 ]

Filed https://issues.jboss.org/browse/WELD-936 to track this issue

Comment by Sivakumar Thyagarajan [ 08/Jul/11 ]

Marked issue as "Major"

Comment by stuartdouglas [ 15/Jul/11 ]

This is fixed in weld upstream, and will be part of 1.1.2

Comment by Sivakumar Thyagarajan [ 11/Dec/11 ]

Marking this issue as resolved as with the integration of Weld 1.1.2 and beyond, this issue doesn't occur with latest builds of GlassFish 3.1.2 (b14+) and trunk:

– server.log snippet showing successful invocation of app –
[#|2011-12-11T21:44:50.691+0530|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=25;_ThreadName=Thread-2;|IN BEAN|#]

[#|2011-12-11T21:44:50.762+0530|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=25;_ThreadName=Thread-2;|FINISH|#]
– server.log snippet showing successful invocation of app –





[GLASSFISH-16508] Annotation processing does not happen properly when installRoot has soft-link any where in its path. Created: 01/May/11  Updated: 31/May/11  Resolved: 31/May/11

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b06

Type: Bug Priority: Critical
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: 3_1-next, 3_1_1-scrubbed

 Description   

This morning I encountered a bug that I found hard to believe. I am trying to gather code coverage numbers for my dev test suite which uses a version of embedded glassfish running on OSGi. Such an embedded glassfish is designed to behave identically to non-embedded GlassFish. During the test run, I saw all my JDBC tests failing with following error:

[#|2011-05-01T08:12:50.010+0530|SEVERE|glassfish3.2|javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service|_ThreadID=10;_ThreadName=main;|RAR8061: failed to load resource-adapter-config or RA [ __ds_jdbc_ra ], com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: Unable to get active RA for module __ds_jdbc_ra|#]

I first suspected some role played by cobertura as this was an instrumented glassfish that I was using. That was ruled out when I could not reproduce the issue when I started glassfish from command line. While debugging connector code, I saw some file paths encoded in some variables and then something struck me. My home dir (/home/ss141213) is a softlink to /space/ss141213, so /home/ss141213/bugs/codecoverage/glassfish3/glassfish is actually /space/ss141213/bugs/codecoverage/glassfish3/glassfish. Next I tried running the tests by setting com.sun.aas.installRoot=/space/ss141213/bugs/codecoverage/glassfish3/glassfish/ and the tests passed. I have not even tried to understand where those file paths are used and if that's the issue. You may be knowing the reason already, hence this question. Do you know why com.sun.aas.installRoot being a softlink can cause lead to this failure? Either we fix that or I have to fix the osgi-embedded-glassfish to resolve the softlink and use the resolved name.



 Comments   
Comment by Jagadish [ 01/May/11 ]

It looks like annotation processing does not happen properly whenever
the installation directory ("AS_INSTALL" property in
GF_HOME/config/asenv.conf) or the system property
"com.sun.aas.installRoot" is a directory that has "soft-link" anywhere
in the path.

eg:
Original Install Location :
/space/jagadish/workspaces/v3/distributions/glassfish/target/installation/glassfish3/glassfish

Soft link to the above location : /home/jagadish/Desktop/glassfish-link
ls -l /home/jagadish/Desktop/glassfish-link
lrwxrwxrwx 1 jagadish jagadish 103 2011-05-01
10:25 /home/jagadish/Desktop/glassfish-link
-> /space/jagadish/workspaces/v3/distributions/glassfish/target/installation/glassfish3/glassfish

If AS_INSTALL in asenv.conf is set as
"/home/jagadish/Desktop/glassfish-link", annotation processing does not
work.

Please try the ejb-devtest which will fail for a soft-link based GF
installation location :
appserv-tests/devtests/ejb/ejb30/hello/session

Also refer the original comment where the issue is reported
by Sahoo that JDBC-RARs (annotated RARs) are not started properly.

Based on the conversations with Sahoo and Hong, transferring to deployment team for further investigation.

Comment by Hong Zhang [ 18/May/11 ]

I was able to reproduce the problem with appserv-tests/devtests/ejb/ejb30/hello/session test and have a fix for it now.
However, I am not sure how to reproduce the original problem of __ds_jdbc_ra. I made a soft link for the glassfish installation and I could deploy this connector module fine without any issue.
Jagadish/Sahoo: what will be the easiest way to reproduce the problem with __ds_jdbc_ra with regular glassfish (non-embedded)?

Comment by Jagadish [ 23/May/11 ]

Here is the steps that I have used :

GF INSTALL
DIR : /space/jagadish/workspaces/v3/feb10/v3/distributions/glassfish/target/installation/glassfish3/glassfish

SOFT LINK :
ln
-s /space/jagadish/workspaces/v3/feb10/v3/distributions/glassfish/target/installation/glassfish3/glassfish /home/jagadish/Desktop/glassfish-link

Change "AS_INSTALL" entry in GF_INSTALL/config/asenv.conf to use the
soft link.
In my case, it was changed to "/home/jagadish/Desktop/glassfish-link"

asadmin start-domain domain1
asadmin ping-connection-pool __TimerPool

Ping will fail.

In the server.log, you will find
"RAR8061: failed to load resource-adapter-config or RA [ __xa_jdbc_ra ],
com.sun.appserv.connectors.internal.api.ConnectorRuntimeException:
Unable to get active RA for module __xa_jdbc_ra"

which is due to the failure in processing annotations defined in the
jdbc-resource-adapter classes.

Comment by Hong Zhang [ 24/May/11 ]

For some reason, I did not see any failure with the ping command, the command executed successfully for me. I tried to set a break point in ApplicationLifecycle.deploy and it was never reached (it should when it's loading the __xa_jdbc_ra app, right?). Is there anything else that I need to do to trigger the loading of this system application?

I double checked the softlink and re-run the ejb30 app, I did see a failure there so I think I set the softlink properly.

Comment by Jagadish [ 25/May/11 ]

This is a system resource-adapter and its life-cycle is managed by connector-runtime and hence normal deployment operations/phases will not happen.

Can you provide the steps that you have followed which is supposed to be in-line with the steps I have provided in my previous comment ?
[I do not think it matters, just in case, you can try the steps on a fresh glassfish installation.]

Comment by Hong Zhang [ 25/May/11 ]

This is what I did:
1. install a glassfish under
/home/hzhang/files/sun/glassfish3/glassfish

2. then create a soft link to
$ ln -s /home/hzhang/files/sun/glassfish3/glassfish/ /home/hzhang/files/sun/glassfish-link
$ ls -l /home/hzhang/files/sun/glassfish-link
lrwxrwxrwx 1 hzhang hzhang 44 2011-05-25 08:41 /home/hzhang/files/sun/glassfish-link -> /home/hzhang/files/sun/glassfish3/glassfish/

3. edit the asenv.conf file:
AS_INSTALL="/home/hzhang/files/sun/glassfish-link"

4. start domain
$ asadmin start-domain
Waiting for domain1 to start .......
Successfully started the domain : domain1
domain Location: /home/hzhang/files/sun/glassfish-link/domains/domain1
Log File: /home/hzhang/files/sun/glassfish-link/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.

5. ping the pool
$ asadmin ping-connection-pool __TimerPool
Command ping-connection-pool executed successfully.
Nothing in the server.log.

I was using a 3.1.1 build.

How was the system app loaded, where could I set breakpoint to make sure the loading of this application was triggered?

Comment by Jagadish [ 25/May/11 ]

Only change being, I am using trunk based build. Even, Sahoo seem to have used trunk based build.

I tried 3.1.1 based build (29-Apr-11) and it works fine (no issues).

You can look for ConnectorDDTransformUtils.getConnectorDescriptor that reads the descriptor.

Comment by Hong Zhang [ 25/May/11 ]

This is very strange. I tried with the latest build from trunk (built from revision 47085) and I still don't see any issues. I set a breakpoint in ConnectorDDTransformUtils.getConnectorDescriptor and traced through the annotation processing, things seem to happen as expected.
Can you double check with the latest trunk build? Thanks.

Comment by Hong Zhang [ 26/May/11 ]

I have checked in the fix for ejb30 session test case first while we are figuring out the other test case.

Comment by Jagadish [ 31/May/11 ]

The use-case I have reported fails till 26th April 2011 nightly build (TRUNK) and passes afterwards.
[Next nightly being 28th April 2011.]

Comment by Hong Zhang [ 31/May/11 ]

Jagadish: thanks for finding out about the timeline! I think that part of the issue is related to the following issue:

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

where File.getCanonicalPath was used. The HK2 fix for that issue got integrated into GlassFish on April 26th which matched with the timeline.

As my other part of fix was also checked in. I will mark this issue as fixed now.





[GLASSFISH-16507] Servlet 2.3 test case compile error with JDK7 - missing package com.sun.image.codec.jpeg Created: 30/Apr/11  Updated: 28/Jan/12

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

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

System running RHEL 5 with JDK7 build136 acquired at http://jre.us.oracle.com/java/re/jdk/7/promoted/ea/b136/bundles/ and Glassfish 3.1.1 build3


Tags: 3_1-next, 3_1_1-scrubbed

 Description   

When compiling our Servlet 2.3 test cases, it fails due error: package com.sun.image.codec.jpeg does not exist

In researching through Google, found several references that in OpenJDK this package has been removed and in the Java Advance Imaging Home page (http://java.sun.com/products/java-media/jai/iio.html), under the JPEG section, it mentions that some of the classes are unofficially implemented in the com.sun.image.codec.jpeg package.

What is not clear is what is the story with JDK7 and whether this is a JDK or an implementation issue that needs to be solved in our test case, thus, the reason for the bug report. We hope to get clarity on this point and perhaps instructions on how to replace these classes with a supported type in JDK7.

To see the problem, please follow the following example, but please adjust the glassfish3, jdk, ant location and your id in CVSROOT

% setenv CVSROOT :pserver:cvsguest@sunsw.us.oracle.com:/m/jws
% setenv SPS_HOME /space/test1/ws/appserver-sqe
% setenv S1AS_HOME /space/test1/glassfish3/glassfish
% setenv JAVA_HOME /space/test1/tool/jdk1.7.0-b136
% setenv ANT_HOME /space/test1/tool/apache-ant-1.7.1
% setenv PATH $JAVA_HOME/bin:$ANT_HOME/bin:$S1AS_HOME/bin:$PATH

To check out test source

% cvs co appserver-sqe/bootstrap.xml
% cd appserver-sqe
% ant -f bootstrap.xml co-core

To run the test
% ant start-domain
% ant startDerby
% ant v3g-core-all
% ant v3g-tomcat-all

After the test fishines (or aborts), run the following to stop the server
% ant stopDerby
% ant stop-domain

The complete compile error is:
[javac] Compiling 18 source files to /export/hudson/workspace/alex-core-jdk7/appserver-sqe/build/pe/amd64_wolfrun.us.oracle.com_Linux/tomcat-servlets/classes/com/sun/s1aspesqe/product_test/servlet2_3/WEB-INF/classes
[javac] /export/hudson/workspace/alex-core-jdk7/appserver-sqe/pe/tomcat/servlet/product_test
/servlet2_3/src/filters/FilterImage.java:72: error: package com.sun.image.codec.jpeg does not ex
ist [javac] import com.sun.image.codec.jpeg.JPEGImageEncoder; [javac] ^
[javac] /export/hudson/workspace/alex-core-jdk7/appserver-sqe/pe/tomcat/servlet/product_test
/servlet2_3/src/filters/FilterWEG.java:73: error: package com.sun.image.codec.jpeg does not exis
t [javac] import com.sun.image.codec.jpeg.JPEGImageEncoder; [javac] ^
[javac] /export/hudson/workspace/alex-core-jdk7/appserver-sqe/pe/tomcat/servlet/product_test
/servlet2_3/src/filters/FilterWRES.java:72: error: package com.sun.image.codec.jpeg does not exi
st [javac] import com.sun.image.codec.jpeg.JPEGImageEncoder;
[javac] ^ [javac] /export/hudson/workspace/alex-core-jdk7/appserver-sqe/pe/tomcat/servlet/product_test
/servlet2_3/src/filters/ResponseWrapperNR.java:72: error: package com.sun.image.codec.jpeg does
not exist
[javac] import com.sun.image.codec.jpeg.JPEGImageEncoder;
[javac] ^ [javac] /export/hudson/workspace/alex-core-jdk7/appserver-sqe/pe/tomcat/servlet/product_test/servlet2_3/src/filters/FilterImage.java:144: error: cannot find symbol
[javac] JPEGImageEncoder encoder=com.sun.image.codec.jpeg.JPEGCodec.createJPEGEncoder(imageStream);
[javac] ^
[javac] symbol: class JPEGImageEncoder
[javac] location: class FilterImage
[javac] /export/hudson/workspace/alex-core-jdk7/appserver-sqe/pe/tomcat/servlet/product_test
/servlet2_3/src/filters/FilterImage.java:144: error: package com.sun.image.codec.jpeg does not e
xist
[javac] JPEGImageEncoder encoder=com.sun.image.codec.jpeg.JPEGCodec.createJPEGEncoder(imageStream);
[javac] ^ [javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details. [javac] 6 errors

BUILD FAILED



 Comments   
Comment by Shing Wai Chan [ 02/May/11 ]

According to the error message above, the test case java file, appserver-sqe/pe/tomcat/servlet/product_test/servlet2_3/src/filters/FilterImage.java, refers to the com.sun.image.codec.jpeg.JPEGCodec.

This is a test case class, not in the server code.

Comment by Alex Pineda [ 28/Oct/11 ]

Assigning Tomcat test issue to module owner.

Comment by sb110099 [ 23/Jan/12 ]

This issue is only seen on Windows 7 with jdk7u2.
Need further investigation to modify these tests with equivalent packages in jdk7.
For now , commenting out these tests for Win7 and jdk7 runs.

Thanks,
Sudipa

Comment by sb110099 [ 28/Jan/12 ]

The bug indicating removal of this package (com.sun.image.codec.jpeg) from JDK 7 is found as:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6527962

Have adjusted the tests with "import javax.imageio." instead of com.sun.image.codec. .

Sudipa





[GLASSFISH-16505] DB Logging is not working with auto-recovery on Created: 29/Apr/11  Updated: 16/Nov/11  Resolved: 16/Nov/11

Status: Resolved
Project: glassfish
Component/s: jts
Affects Version/s: 3.1
Fix Version/s: None

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

Issue Links:
Dependency
depends on GLASSFISH-17405 Transaction recovery in a cluster doe... Resolved
Tags: 3_1-next, 3_1_1-scrubbed, 3_1_2-review

 Description   

There are 2 problems with DB logging:

1. This seems to be present since 9.x: DB logging is working only if there is also a LAO resource in the transaction.

2. Critical - resource lookup fails:

[#|2011-04-29T15:24:54.679-0700|SEVERE|glassfish3.2|javax.enterprise.system.core.transaction.com.sun.jts.CosTransactions|_ThreadID=21;_ThreadName=Thread-1;|
javax.naming.NamingException: Lookup failed for 'jdbc/nontx' in SerialContext[myEnv=

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

[Root exception is javax.naming.NameNotFoundException: jdbc]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:518)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at com.sun.jts.CosTransactions.LogDBHelper.<init>(LogDBHelper.java:89)
at com.sun.jts.CosTransactions.LogDBHelper.<clinit>(LogDBHelper.java:75)
at com.sun.jts.CosTransactions.RecoveryManager.dbXARecovery(RecoveryManager.java:1186)
at com.sun.jts.CosTransactions.ResyncThread.run(RecoveryManager.java:1853)
Caused by: javax.naming.NameNotFoundException: jdbc
at com.sun.enterprise.naming.impl.TransientContext.resolveContext(TransientContext.java:310)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:218)
at com.sun.enterprise.naming.impl.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:77)
at com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:119)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:505)
... 7 more



 Comments   
Comment by marina vatkina [ 29/Apr/11 ]

Requesting connector team to investigate the error. To reproduce, use test devtests/transaction/ee/dblogs.

Comment by Jagadish [ 08/Jul/11 ]

originally not planned for 3.1.1. Downgrading as per release criteria.

Comment by Jagadish [ 16/Nov/11 ]

It looks like the resource-refs are created after the cluster (and hence its instances) are started. Recovery Thread will try to look for the resources during server (instance) startup and since the resource-refs are created post server startup, they will not be found.

I tried the following changes in the test-case and jdbc-resource was available for the recovery thread (tested in trunk).

Transferring to Marina for further investigation.

Changes to appserv-tests/devtests/transaction/ee/dblogs/client/Client.java
Index: appserv-tests/devtests/transaction/ee/dblogs/client/Client.java
===================================================================
--- appserv-tests/devtests/transaction/ee/dblogs/client/Client.java	(revision 50848)
+++ appserv-tests/devtests/transaction/ee/dblogs/client/Client.java	(working copy)
@@ -84,6 +84,9 @@
     public void prepare(String path, String tx_log_dir, boolean enable_delegate) {
         try {
             asadmin("create-cluster", CLUSTER_NAME);
+            asadmin("create-resource-ref", "--target", CLUSTER_NAME, DEF_RESOURCE);
+            asadmin("create-resource-ref", "--target", CLUSTER_NAME, XA_RESOURCE);
+            asadmin("create-resource-ref", "--target", CLUSTER_NAME, NONTX_RESOURCE);
             asadmin("create-system-properties", "--target", CLUSTER_NAME, "-Dcom.sun.appserv.transaction.nofdsync");
             asadmin("set", "configs.config." + CLUSTER_NAME + "-config.transaction-service.property.db-logging-resource=" + NONTX_RESOURCE);
             //asadmin("set", "configs.config." + CLUSTER_NAME + "-config.transaction-service.automatic-recovery=true");
@@ -101,9 +104,6 @@
             asadmin("start-cluster", CLUSTER_NAME);
             System.out.println("Started cluster. Setting up resources.");
 
-            asadmin("create-resource-ref", "--target", CLUSTER_NAME, DEF_RESOURCE);
-            asadmin("create-resource-ref", "--target", CLUSTER_NAME, XA_RESOURCE);
-            asadmin("create-resource-ref", "--target", CLUSTER_NAME, NONTX_RESOURCE);
             asadmin("deploy", "--target", CLUSTER_NAME, path);
             System.out.println("Deployed " + path);
         } catch (Exception e) {
Comment by marina vatkina [ 16/Nov/11 ]

After the GLASSFISH-17405 is fixed, the test works as-is.





[GLASSFISH-16478] End User Noticed High CPU Usage in Monitoring Created: 27/Apr/11  Updated: 15/Feb/13  Resolved: 15/Feb/13

Status: Closed
Project: glassfish
Component/s: performance
Affects Version/s: 3.1
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: Byron Nevins Assignee: Scott Oaks
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-next, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

Hi

This is with Glassfish 3.1.

We are trying to track down an issue where our Glassfish startup has become
occasionally (but not consistently) painfully slow along with very high CPU
(over 100% of 1 CPU) usage for the Glassfish process. Slow here means many
minutes for loading a particular webapp, as opposed to 1-2 minutes.

Checking GC with VisualVM showed no problems - enough heap, infrequent
collections - and the VE itself was not swapping.

On running several stack trace dumps back to back I found that the main
thread was spending a lot of time in this section of code (across several
stack trace dumps) - In particular, I was seeing the thread remain in the
string pattern matching section started by
org.glassfish.flashlight.datatree.impl.AbstractTreeNode.getNodesInternal(AbstractTreeNode.java:360).

"main" prio=10 tid=0x000000004efe1000 nid=0x163e runnable
[0x000000004092e000] java.lang.Thread.State: RUNNABLE at
java.lang.String.length(String.java:651) at
java.util.regex.Matcher.getTextLength(Matcher.java:1140) at
java.util.regex.Matcher.reset(Matcher.java:291) at
java.util.regex.Matcher.<init>(Matcher.java:211) at
java.util.regex.Pattern.matcher(Pattern.java:888) at
org.glassfish.flashlight.datatree.impl.AbstractTreeNode.getNodesInternal(AbstractTreeNode.java:360)
at
org.glassfish.flashlight.datatree.impl.AbstractTreeNode.getNodes(AbstractTreeNode.java:331)
at
org.glassfish.admin.monitor.StatsProviderManagerDelegateImpl.resetChildNodeStatistics(StatsProviderManagerDelegateImpl.java:550)
at
org.glassfish.admin.monitor.StatsProviderManagerDelegateImpl.resetStatistics(StatsProviderManagerDelegateImpl.java:539)
at
org.glassfish.admin.monitor.StatsProviderManagerDelegateImpl.enableStatsProvider(StatsProviderManagerDelegateImpl.java:389)
at
org.glassfish.admin.monitor.StatsProviderManagerDelegateImpl.tryToRegister(StatsProviderManagerDelegateImpl.java:191)
at
org.glassfish.admin.monitor.StatsProviderManagerDelegateImpl.register(StatsProviderManagerDelegateImpl.java:157)
at
org.glassfish.external.probe.provider.StatsProviderManager.registerStatsProvider(StatsProviderManager.java:91)
at
org.glassfish.external.probe.provider.StatsProviderManager.register(StatsProviderManager.java:82)
at
org.glassfish.external.probe.provider.StatsProviderManager.register(StatsProviderManager.java:72)
at
org.glassfish.admin.monitor.jvm.JVMStatsProviderBootstrap.postConstruct(JVMStatsProviderBootstrap.java:92)
at
com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator$1.run(ConstructorCreator.java:86)
at java.security.AccessController.doPrivileged(Native Method) at
com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:83)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)

  • locked <0x00002aab01bcf370> (a com.sun.hk2.component.SingletonInhabitant)
    at
    com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
    at
    com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
    at
    com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:326)
    at
    com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:135)
  • locked <0x00002aaac20b3228> (a
    com.sun.enterprise.v3.server.AppServerStartup) at
    com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
  • locked <0x00002aaac20b3200> (a
    com.sun.enterprise.glassfish.bootstrap.GlassFishImpl) 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:39)
    at
    sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597) at
    com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
    at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
    I don't know if this is a red herring, but nothing else in the stack traces
    stood out as much as this did.

Any tips?

Thanks

Patrick

[Message sent by forum member 'pdoubleya']

View Post: http://forums.java.net/node/795868



 Comments   
Comment by Byron Nevins [ 17/Jun/11 ]

Lowering the priority. We need more information, namely actual profiling needs to be done.

Comment by Byron Nevins [ 17/Jun/11 ]

Assigning to Performance team to see if they can reproduce it and/or do actual profiling to see if this is a REAL problem or a coincidence or ???

Comment by Scott Oaks [ 15/Feb/13 ]

We cannot reproduce this. If it is still present in 4.0, please re-open.





[GLASSFISH-16455] Problem using https webservice client with mutual authentication Created: 26/Apr/11  Updated: 08/Nov/11  Resolved: 08/Nov/11

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 3.1
Fix Version/s: 3.1.1, 4.0

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

Red Hat Linux 2.6.18-92.el5 x86_64 x86_64 x86_64 GNU/Linux


Tags: 3_1-next, 3_1_1-exclude, keystore, masterpassword, truststore, webservice

 Description   

Scenario:
Cluster with two instances, one running on a local-node (INST_CLU_LOCAL) and another running on a remote-node (INST_CLU_REMOTE).

Issue:
I have a cluster that run a webservice client that consumes a service that requires mutual authentication. Everything works fine when the request starts from INST_CLU_LOCAL, but when the client starts from INST_CLU_REMOTE the follow error is trown
([#|2011-04-26T10:14:52.807-0300|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=146;_ThreadName=Thread-2;|AxisFault
faultCode:

{http://schemas.xmlsoap.org/soap/envelope/}

Server.userException
faultSubcode:
faultString: javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message
faultActor:
faultNode:
faultDetail:

{http://xml.apache.org/axis/}

stackTrace:javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1623)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:198)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:188)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloRequest(ClientHandshaker.java:286)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:114)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:525)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:465)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:746)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
at org.apache.axis.transport.http.HTTPSender.readHeadersFromSocket(HTTPSender.java:583)
at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:143)
at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)
at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
at org.apache.axis.client.Call.invoke(Call.java:2767)
at org.apache.axis.client.Call.invoke(Call.java:2443)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
at br.inf.portalfiscal.www.cte.wsdl.CTeDistribuicaoRFB.CTeDistribuicaoRFBSoapStub.cteDistribuicao(CTeDistribuicaoRFBSoapStub.java:179)
at br.gov.ce.sefaz.cte.facade.CTeFacade.cteDistribuicao(CTeFacade.java:62)
at br.gov.ce.sefaz.cte.timer.RecuperarCTEReceitaTimer.cteDistribuicao(RecuperarCTEReceitaTimer.java:146)
at br.gov.ce.sefaz.cte.timer.RecuperarCTEReceitaTimer.timeout(RecuperarCTEReceitaTimer.java:89)
at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5367)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundTimeout(SystemInterceptorProxy.java:149)
at sun.reflect.GeneratedMethodAccessor74.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:862)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:371)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5339)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5327)
at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:4033)
at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1835)
at com.sun.ejb.containers.EJBTimerService.access$100(EJBTimerService.java:108)
at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:2708)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

{http://xml.apache.org/axis/}

hostname:sd2awj12.sefazce.corp

javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message
at org.apache.axis.AxisFault.makeFault(AxisFault.java:101)
at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:154)
at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)
at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
at org.apache.axis.client.Call.invoke(Call.java:2767)
at org.apache.axis.client.Call.invoke(Call.java:2443)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
at br.inf.portalfiscal.www.cte.wsdl.CTeDistribuicaoRFB.CTeDistribuicaoRFBSoapStub.cteDistribuicao(CTeDistribuicaoRFBSoapStub.java:179)
at br.gov.ce.sefaz.cte.facade.CTeFacade.cteDistribuicao(CTeFacade.java:62)
at br.gov.ce.sefaz.cte.timer.RecuperarCTEReceitaTimer.cteDistribuicao(RecuperarCTEReceitaTimer.java:146)
at br.gov.ce.sefaz.cte.timer.RecuperarCTEReceitaTimer.timeout(RecuperarCTEReceitaTimer.java:89)
at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5367)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundTimeout(SystemInterceptorProxy.java:149)
at sun.reflect.GeneratedMethodAccessor74.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:862)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:371)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5339)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5327)
at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:4033)
at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1835)
at com.sun.ejb.containers.EJBTimerService.access$100(EJBTimerService.java:108)
at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:2708)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.Fut|#]

[#|2011-04-26T10:14:52.808-0300|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=146;_ThreadName=Thread-2;|ureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1623)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Hands