Closed glassfishrobot closed 13 years ago
glassfishrobot
commented
6 years ago glassfishrobot
commented
13 years ago @glassfishrobot Commented kasso said: Alex, in the description you say: "Nor the failures are seen with the latest jdk (JDK1.6.0_24)".
Is this saying the failure is not seen with _24?
Have you tried these on other platforms?
glassfishrobot
commented
13 years ago @glassfishrobot Commented ap2257 said: I can make the system available for debugging if required. Just contact me and I will provide the username/password on the machine.
And just to clarify. On build41 the samples work with JDK1.6.0_23 or JDK1.6.0_24.
glassfishrobot
commented
13 years ago @glassfishrobot Commented ap2257 said: Have not tried on other platforms yet. I will do so later today (Win7 and OEL5).
glassfishrobot
commented
13 years ago @glassfishrobot Commented scatari said: Alex, Can u please try the following on the same machine?
-Install B41(SDK with JDK) on a different directory.
-Make B43 GlassFish binaries to point to B41's jdk by editing asenv.conf and setting JAVA_HOME and PATH.
-Run the tests on B43 binaries to see if you can reproduce. If you can, then this can be isolated to a potential issue in the new JDK drop.
glassfishrobot
commented
13 years ago @glassfishrobot Commented ap2257 said: Scatari,
I did a similar experiment. o I installed B41 SDK. I edited the asenv.conf file to point to B43's JDK and the sample deployed correctly. o Also, I pointed B43 to my local (not B41's) JDK which is JDK1.6.0_23 and it failed to deploy.
glassfishrobot
commented
13 years ago @glassfishrobot Commented @honghzzhang said: I am not sure why the cast exception will happen, Bhakti might have better idea. But the stack trace attached would only be triggered when the -Dwriteout.xml=true debug option is turned on (to write out generated deployment descriptor). And when VNC into the test machine, I did see the problematic installation (/home/sqe/Workspace/glassfish3) has this jvm option.
in the domain.xml. And the installation that worked (/home/sqe/SDK/glassfish3) did not have this jvm-option set in the domain.xml. This could possibly explain why one had problem and the other not. Please use the default setting (with no debug jvm-option) to run the test again to see if it makes a difference. We should also try to figure out why we would have the stack trace when the debug option is turned on. But that's a less serious issue.
glassfishrobot
commented
13 years ago @glassfishrobot Commented ap2257 said: Hong,
I will try your suggestion and comment out the jvm option in domain.xml and report back.
glassfishrobot
commented
13 years ago @glassfishrobot Commented ramapulavarthi said: I reproduced the issue and its a bug in writing out the Web Services runtime descriptor when writeout.xml system property is set. Attaching a patch for this issue.
glassfishrobot
commented
13 years ago @glassfishrobot Commented ramapulavarthi said: Patch for the issue.
glassfishrobot
commented
13 years ago @glassfishrobot Commented ap2257 said: Hong,
I commented out "
glassfishrobot
commented
13 years ago @glassfishrobot Commented @honghzzhang said: Great, thanks Alex. So that mystery is now solved. We now just need to decide whether Rama's fix should make in 3.1 or not (it probably would not as the error just happen when the debug option is turned on).
glassfishrobot
commented
13 years ago @glassfishrobot Commented ap2257 said: Thanks for clarifying about the fix. Be aware that I did not explicitly add this option to domain.xml. I installed the same on both installations. I'm going to try to figure out how his happened in my testing. I'll wait to hear about the fix.
glassfishrobot
commented
13 years ago @glassfishrobot Commented ap2257 said: Removing the Regression label and tag as the test case does not insert a Debug option. In other words, this is not a regression as the test has not been, to my knowledge, been executed with a jvm debug option. It's still an issue, but not a regression.
glassfishrobot
commented
13 years ago @glassfishrobot Commented ramapulavarthi said: I would like to understand if the test execution has enabled this debug option explicitly or the domain was created with this option by default. If it is the later, then we have an issue.
glassfishrobot
commented
13 years ago @glassfishrobot Commented ap2257 said: I don't believe the Installer domain creation is inserting this option as evidenced by the fact that the new installation, provided as reference, does not show the debug option in domain.xml. The test case that I execute, does not insert this option either. My guess is that a previous test that I executed, did the insertion. I plan to investigate this further. In short, the installer does not insert this option by default. That is my conclusion at this point.
glassfishrobot
commented
13 years ago @glassfishrobot Commented @ssevozen said: Correct - 'asadmin create-domain' does not create the domain with this option out of the box and this is true for all distributions. This had to be the artifact of the BAT test run.
glassfishrobot
commented
13 years ago @glassfishrobot Commented kasso said: Based on the information we have this is not a stopper. Excluding it from 3.1.
glassfishrobot
commented
13 years ago @glassfishrobot Commented ramapulavarthi said: Committed a fix to the trunk.
45182
trunk/v3/deployment/dol/src/main/java/com/sun/enterprise/deployment/archivist/Archivist.java
glassfishrobot
commented
13 years ago @glassfishrobot Commented ramapulavarthi said: Fixed in v3.1.1 as rev:45182
glassfishrobot
commented
13 years ago @glassfishrobot Commented File: GLASSFISH-16035.patch Attached By: ramapulavarthi
glassfishrobot
commented
13 years ago @glassfishrobot Commented Was assigned to ramapulavarthi
glassfishrobot
commented
7 years ago @glassfishrobot Commented This issue was imported from java.net JIRA GLASSFISH-16035
glassfishrobot
commented
13 years ago @glassfishrobot Commented Reported by ap2257
glassfishrobot
commented
13 years ago @glassfishrobot Commented Marked as fixed on Thursday, May 19th 2011, 10:11:09 am
With build43 using SDK with Linux JDK, the Web Services samples fail to deploy. This problem was not seen on build41. Just verified to make sure. Nor the failures are seen with the latest jdk (JDK1.6.0_24)
The deployment failure is shown when invoking "ant all" in /glassfish3/glassfish/samples/javaee6/webservices/hello-singleton-ejb (as one example). The error is:
deploy: [exec] Deprecated syntax, instead use: [exec] asadmin --user admin --passwordfile /home/sqe/Workspace/glassfish3/glassfish/samples/bp-project/passwordfile --host localhost --port 4848 deploy [options] ... [exec] Command deploy failed. [exec] remote failure: Error occurred during deployment: Exception while deploying the app [hello-singleton-ejb] : com.sun.enterprise.deployment.EjbBundleDescriptor cannot be cast to com.sun.enterprise.deployment.WebServicesDescriptor. Please see server.log for more details.
In the server.log, the following is displayed: [#|2011-02-17T08:52:59.785-0800|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=80;_ThreadName=Thread-1;|Exception while deploying the app [hello-singleton-ejb]|#]
[#|2011-02-17T08:52:59.786-0800|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=80;_ThreadName=Thread-1;|com.sun.enterprise.deployment.EjbBundleDescriptor cannot be cast to com.sun.enterprise.deployment.WebServicesDescriptor java.lang.ClassCastException: com.sun.enterprise.deployment.EjbBundleDescriptor cannot be cast to com.sun.enterprise.deployment.WebServicesDescriptor at com.sun.enterprise.deployment.io.runtime.WLWebServicesDeploymentDescriptorFile.(WLWebServicesDeploymentDescriptorFile.java:62)
at com.sun.enterprise.deployment.archivist.Archivist.writeWLWebServicesDescriptors(Archivist.java:1092)
at com.sun.enterprise.deployment.archivist.Archivist.writeWLRuntimeDeploymentDescriptors(Archivist.java:1034)
at com.sun.enterprise.deployment.archivist.Archivist.writeExtraDeploymentDescriptors(Archivist.java:1045)
at com.sun.enterprise.deployment.archivist.Archivist.writeDeploymentDescriptors(Archivist.java:961)
at com.sun.enterprise.deployment.archivist.DescriptorArchivist.write(DescriptorArchivist.java:176)
at com.sun.enterprise.deployment.archivist.DescriptorArchivist.write(DescriptorArchivist.java:83)
at org.glassfish.javaee.core.deployment.DolProvider.saveAppDescriptor(DolProvider.java:304)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:199)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:93)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:826)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:768)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1067)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1247)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:465)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:222)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
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)
| #] |
[#|2011-02-17T08:52:59.792-0800|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=80;_ThreadName=Thread-1;|Exception while deploying the app [hello-singleton-ejb] : com.sun.enterprise.deployment.EjbBundleDescriptor cannot be cast to com.sun.enterprise.deployment.WebServicesDescriptor|#]
The steps to reproduce this issue are:
The same issue is seen on the other 2 WebServices samples - hello-jaxws2.2 and hello-webserviceref
Environment
RHEL 5 system 64 bit OS, Browser is Firefox 3.6.13, Build java_ee_sdk-6u2-b43-jdk-linux.sh. JDK 1.6.0_24 or JDK1.6.0_23 Linux.
Affected Versions
[3.1_dev]