[GLASSFISH-18967] CTS7 ejb30/lite tests fail deploying test war file Created: 31/Jul/12  Updated: 07/Aug/12  Resolved: 07/Aug/12

Status: Closed
Project: glassfish
Component/s: other
Affects Version/s: 4.0_b47
Fix Version/s: 4.0_b48

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

Attachments: File ejblite_packaging_war_datasource_singleton_ejblitejsf_vehicle_web.war    

 Description   

The attached war file fails to deploy on glassfish V4 B47. I didn't have this issue with B46 and earlier.

Here is a snippet from the server log:

[#|2012-07-31T12:18:11.316-0400|SEVERE|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=28;_ThreadName=Thread-2;|Application validation fails for given application ejblite_packaging_war_datasource_singleton_ejblitejsf_vehicle_web
java.lang.IllegalStateException: Application validation fails for given application ejblite_packaging_war_datasource_singleton_ejblitejsf_vehicle_web
at com.sun.enterprise.deployment.util.ApplicationValidator.accept(ApplicationValidator.java:105)
at com.sun.enterprise.deployment.BundleDescriptor.visit(BundleDescriptor.java:621)
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openWith(ApplicationFactory.java:239)
at org.glassfish.javaee.core.deployment.DolProvider.processDOL(DolProvider.java:188)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:222)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:96)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:870)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:812)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:373)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:228)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:416)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:515)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:531)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1426)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:113)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1696)
at org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:145)
at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:570)
at org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:457)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:389)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:380)
at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:221)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)

#]


 Comments   
Comment by Dennis MacConnell [ 31/Jul/12 ]

All you have to do to reproduce this issue is:
1) unzip glassfish-4.0-b47.zip
2) asadmin start-domain
3) copy the attached war to the autodeploy directory

Comment by Hong Zhang [ 31/Jul/12 ]

Naman had recently added some data source related validation code based on Java EE 7 spec. Assign to him to evaluate if this is an issue with the validation logic or the test application.

And looks like we should improve the validation error message also to provide more information about what part of the application (resources) had failed validation so user knows how to fix it as needed.

Comment by naman_mehta [ 01/Aug/12 ]

Looked into this. It's duet to all bundle descriptors is returning the same name. Need to find some alternative for the same.

Comment by naman_mehta [ 01/Aug/12 ]

I have commented validation code temporary to pass this failure. Need to fix descriptor name related issue.

Comment by naman_mehta [ 07/Aug/12 ]

As per the bug all modules (EJB Bunbdle, Application, WEB Bundle) returns the same name. So discussed with the hong and added prefix to each bundle to avoid duplication of module name. In case of two ejb bundles part of ear it always returns the unique name so no need to make any change in that scenario.

Sending dol/src/main/java/com/sun/enterprise/deployment/util/ApplicationValidator.java
Transmitting file data .
Committed revision 55332.





[GLASSFISH-18952] [regression] web test failed with empty contextpath specified in sun-web.xml Created: 26/Jul/12  Updated: 02/Aug/12  Resolved: 26/Jul/12

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

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

RHL5 JDL1.6.0_30


Attachments: Zip Archive test1.zip    
Tags: 40-regression

 Description   

glassfish-4.0-b47.zip

appserver-sqe/pe/tomcat/servlet/product_test/servlet2_5/contextpath/test1
The same test passed on b46, but failed on b47 with 404 error.



 Comments   
Comment by sherryshen [ 26/Jul/12 ]

Test source and war.

Comment by sherryshen [ 26/Jul/12 ]

To reproduce the issue
1) deploy war from attached test1.zip
asadmin deploy contextpath-test1.war
2) access uri /test/TestServlet
see "HTTP Status 404" on build 47
see "pass" in response on build 46

Comment by Shing Wai Chan [ 26/Jul/12 ]

I have checkout an up-to-date workspace and the test passes.
This may be due to build b47 picking up part of the fix for http://java.net/jira/browse/GLASSFISH-18866 .
So, I will mark this as a duplicate of 18866.

Comment by sherryshen [ 02/Aug/12 ]

Test passed on glassfish-4.0-b48.zip.





[GLASSFISH-18934] The addIndex method in Config is not using the name parameter but rather the DEFAULT_INSTANCE_NAME Created: 24/Jul/12  Updated: 02/Aug/12  Resolved: 02/Aug/12

Status: Closed
Project: glassfish
Component/s: admin
Affects Version/s: future release
Fix Version/s: 4.0_b48

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


 Description   

The addIndex method in Config class is not using the name parameter but rather it uses the default ServerEnvironment.DEFAULT_INSTANCE_NAME which will inert any name that is passed to it using the name parameer.



 Comments   
Comment by Masoud Kalali [ 02/Aug/12 ]

Fixed in rev=55196
http://svnsearch.org/svnsearch/repos/GLASSFISH/search?p=/trunk/main/nucleus/admin/config-api/src/main/java/com/sun/enterprise/config/serverbeans/Config.java&rev=55196&





[GLASSFISH-18866] Two different wars with same context root can be deployed on server Created: 04/Jul/12  Updated: 26/Jul/12  Resolved: 24/Jul/12

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 4.0_b41
Fix Version/s: 4.0_b48

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

Windows Xp


Attachments: File test_sample1.war     File test_sample2.war    

 Description   

[Bug Description]
Two different wars with same context root can be deployed on server.

[Operations]
1deploy the test_sample1.war with context root value called "test_sample1" to the server in admin-gui

2.deploy the test_sample2.war to the server in admin-gui with the same context root value as test_sample1.war ,
and deploy will be failed at the first time because context root is not unique.

3.repeat the step 2 again,the test_sample2.war can be deployed successfully without any error message.

4.After step3, "http://localhost:8080/test_sample1" can be accessed successfully, however, the contents of repsonse comes from test_sample2.war.

5.by means of admin-cli, the results of step1~step3 are also the same as the results of admin-gui.

[Affected versions ]
1 4.0_b41
2 gf's trunk until 2012/06/22



 Comments   
Comment by Jeremy_Lv [ 04/Jul/12 ]

This issue is related to the issue trac as follows:
http://java.net/jira/browse/GLASSFISH-18861

Comment by Hong Zhang [ 05/Jul/12 ]

The cause of the issue is probably similar, the failed deployment of test_sample2.war affected the test_sample1.war also which should not happen. Will investigate with some discussions with web team.

Comment by Hong Zhang [ 11/Jul/12 ]

When I was looking at step 2 as to why the failed deployment for second application will affect first application, I did not see any undeploy code path gets invoked explicitly for the first application, so probably as part of the web container reject loading the second application, somehow the first application also get unloaded? I will let web team to do some further investigation on this.

Comment by Jeremy_Lv [ 13/Jul/12 ]

when deployed these two applications with same contextroot in a cluster,however, it can be deployed successfully thought the warmming messages displayed in GUI.
The messages in server.log isn't useful,the server.log as follows:

[#|2012-07-13T14:40:16.218+0800|INFO|44.0|org.glassfish.admingui|_ThreadID=18;_ThreadName=Thread-2;|GUI deployment: uploadToTempfile|#]

[#|2012-07-13T14:40:16.234+0800|INFO|44.0|org.glassfish.admingui|_ThreadID=18;_ThreadName=Thread-2;|uploadFileName=C:\Documents and Settings\Administrator\デスクトップ\test_sample2.war|#]

[#|2012-07-13T14:45:12.265+0800|INFO|44.0|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=14;_ThreadName=Thread-2;|test_sample2 was successfully deployed in 344 milliseconds.|#]

[#|2012-07-13T14:45:13.890+0800|WARNING|44.0|org.glassfish.admingui|_ThreadID=18;_ThreadName=Thread-2;|RestResponse.getResponse() gives WARNING. endpoint = 'http://localhost:4848/management/domain/applications/application'; attrs = '

{id=C:\Documents and Settings\Administrator\Local Settings\Temp\test_sample27070464121751395390.war, enabled=true, contextroot=test_sample1, precompilejsp=false, verify=false, availabilityenabled=false, name=test_sample2, target=cluster001, force=false, properties=preserveAppScopedResources=false, keepstate=false}

'|#]

Comment by Shing Wai Chan [ 18/Jul/12 ]

test_sample1 has been unloaded during the deployment failure of the test_sample2.
This is due to a lookup issue.
A fix has been found and verified in my local workspace.
I will checkin the workspace once it is opened.

Comment by Jeremy_Lv [ 19/Jul/12 ]

I agree with the Shing Wai Chan's ideas to this deploy issue based on server,because my modified files are based on it.
But when it comes to the phenomenon that the two wars with same contextroot deployed on the same cluster,the handing logic are not same as deployed on server, it needn't handle the method called loadWebModule in WebContainer.java.

Comment by Shing Wai Chan [ 24/Jul/12 ]

Sending web/web-glue/src/main/java/com/sun/enterprise/web/WebApplication.java
Sending web/web-glue/src/main/java/com/sun/enterprise/web/WebContainer.java
Transmitting file data ..
Committed revision 55181.

Comment by Shing Wai Chan [ 25/Jul/12 ]

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





[GLASSFISH-18801] Web Services tester fails accessibility requirements Created: 12/Jun/12  Updated: 27/Jul/12  Resolved: 27/Jul/12

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2_b23
Fix Version/s: 4.0_b48

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

Tags: metro2_2_1-waived

 Description   

When you open the Web Service Tester at, for example, http://localhost:8080/HelloServiceBeanService/HelloServiceBean?Tester (for the HelloServiceBean application in the Java EE 6 Tutorial, http://docs.oracle.com/javaee/6/tutorial/doc/bnbor.html#bnbox), you get an HTML page whose source looks like this:

<HTML><HEAD><TITLE>HelloServiceBeanService Web Service Tester</TITLE></HEAD><BODY><H1>HelloServiceBeanService Web Service Tester</H1><br>This form will allow you to test your web service implementation (<A HREF="http://stella:8080/HelloServiceBeanService/HelloServiceBean?WSDL">WSDL File</A>)<hr>To invoke an operation, fill the method parameter(s) input boxes and click on the button labeled with the method name.<H3>Methods :</H3><FORM METHOD="POST">public abstract java.lang.String com.sun.tutorial.javaee.ejb.helloservice.HelloServiceBean.sayHello(java.lang.String)<BR><INPUT TYPE=SUBMIT NAME=action value=sayHello> (<INPUT TYPE=TEXT NAME=PARAMsayHello0>)<BR><HR></FORM></BODY></HTML><FORM METHOD="POST">public abstract void com.sun.tutorial.javaee.ejb.helloservice.HelloServiceBean.helloServiceBean()<BR><INPUT TYPE=SUBMIT NAME=action value=helloServiceBean> ()<BR><HR></FORM></BODY></HTML>

In order to make this page accessible, only a few changes are needed:

1) Change <HTML> to <HTML LANG="en">. The LANG attribute is required for each HTML page. If the page varies depending on the locale, the correct locale should be used.

2) Each of the three <INPUT> tags requires a label, which is normally provided by the TITLE attribute. So the changed tags would look something like this, where sayHello is the method name.

<INPUT TYPE=SUBMIT NAME=action title="sayHello" value=sayHello>

<INPUT TYPE=TEXT NAME=PARAMsayHello0 title="sayHello parameter">

<INPUT TYPE=SUBMIT NAME=action title="helloServiceBean" value=helloServiceBean>

The requirement comes from http://www.access-board.gov/sec508/guide/1194.22.htm#%28n%29.



 Comments   
Comment by Lukas Jungmann [ 27/Jul/12 ]

http://java.net/projects/glassfish/sources/svn/revision/55235





[GLASSFISH-18787] Classloader leak in com.sun.xml.ws.server.WSEndpointImpl Created: 06/Jun/12  Updated: 26/Jul/12  Resolved: 26/Jul/12

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2
Fix Version/s: 4.0_b48

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

Linux


Tags: metro2_2_1-waived

 Description   

After undeploying a web app which uses JAX-WS web services LazyMOMProvider still references the WS implementation class. This causes all the classes loaded by the web app classloader to be referenced until the app server restart.

jhat dump:
--> class com.sun.xml.ws.api.server.LazyMOMProvider (160 bytes) (static field INSTANCE
--> com.sun.xml.ws.api.server.LazyMOMProvider@0xe0821148 (52 bytes) (field endpointsWaitingForMOM
--> java.util.HashSet@0xe082b0e8 (24 bytes) (field map
--> java.util.HashMap@0xe08323f0 (64 bytes) (field table
--> [Ljava.util.HashMap$Entry;@0xe66afe18 (528 bytes) (Element 16 of [Ljava.util.HashMap$Entry;@0xe66afe18
--> java.util.HashMap$Entry@0xe87f13b8 (44 bytes) (field key
--> com.sun.xml.ws.server.WSEndpointImpl@0xe87f1c48 (194 bytes) (field implementationClass
--> class com.test.TestWebServiceImpl (160 bytes) (??
--> org.glassfish.web.loader.WebappClassLoader@0xe82706a8 (324 bytes)

It seems that this if clause in WSEndpoinImpl.closeManagedObjectManager evaluates to true and thus prevents the unregistration:

// ManagedObjectManager doesn't need to be closed because it exists only as a proxy
if (managedObjectManager instanceof WSEndpointMOMProxy
&& !((WSEndpointMOMProxy)managedObjectManager).isInitialized())

{ close = false; }

 Comments   
Comment by syvalta [ 06/Jun/12 ]

The instance is always registered during creation in the constructor, so it should be unconditionally unregistered in the dispose. I guess the fix would be to move LazyMOMProvider.INSTANCE.unregisterEndpoint(this) out of the if blocks so that it is always executed.

Comment by Lukas Jungmann [ 19/Jun/12 ]

fixed in jaxws-ri workspace[1], will get to GF in the next integration

[1]: http://java.net/projects/jax-ws/sources/sources/revision/13203

Comment by Lukas Jungmann [ 26/Jul/12 ]

integrated in svn r.55202





[GLASSFISH-18780] java.lang.NoClassDefFoundError: com/sun/msv/datatype/xsd/UnsignedShortType Created: 04/Jun/12  Updated: 26/Jul/12  Resolved: 26/Jul/12

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b39
Fix Version/s: 4.0_b48

Type: Bug Priority: Minor
Reporter: adf59 Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The following stack trace error is occurring on a CTS jaxrpc test causing a test regression.

Last week (B38) the class was bundled in jaxb-osgi.jar. This week (B39) it is missing.

Here is the stack trace:

[#|2012-06-01T13:59:10.017-0400|SEVERE|44.0|javax.enterprise.resource.webservices.rpc.server.http|_ThreadID=117;_ThreadName=Thread-2;|caught throwable
java.lang.NoClassDefFoundError: com/sun/msv/datatype/xsd/UnsignedShortType
at com.sun.xml.rpc.encoding.simpletype.XSDUnsignedShortEncoder.stringToObject(XSDUnsignedShortEncoder.java:63)
at com.sun.xml.rpc.encoding.literal.LiteralSimpleTypeSerializer.deserialize(LiteralSimpleTypeSerializer.java:168)
at com.sun.ts.tests.jaxrpc.ee.wsi.rpc.literal.marshalltest.FooVariousSchemaTypes_LiteralSerializer.doDeserialize(FooVariousSchemaTypes_LiteralSerializer.java:70)
at com.sun.xml.rpc.encoding.literal.LiteralObjectSerializerBase.internalDeserialize(LiteralObjectSerializerBase.java:233)
at com.sun.xml.rpc.encoding.literal.LiteralObjectSerializerBase.deserialize(LiteralObjectSerializerBase.java:141)
at com.sun.ts.tests.jaxrpc.ee.wsi.rpc.literal.marshalltest.FooVariousSchemaTypesListType_LiteralSerializer.doDeserialize(FooVariousSchemaTypesListType_LiteralSerializer.java:53)
at com.sun.xml.rpc.encoding.literal.LiteralObjectSerializerBase.internalDeserialize(LiteralObjectSerializerBase.java:233)
at com.sun.xml.rpc.encoding.literal.LiteralObjectSerializerBase.deserialize(LiteralObjectSerializerBase.java:141)
at com.sun.ts.tests.jaxrpc.ee.wsi.rpc.literal.marshalltest.NewSchemaTest_echoVariousSchemaTypesListTypeTest_RequestStruct_LiteralSerializer.doDeserialize(NewSchemaTest_echoVariousSchemaTypesListTypeTest_RequestStruct_LiteralSerializer.java:50)
at com.sun.xml.rpc.encoding.literal.LiteralObjectSerializerBase.internalDeserialize(LiteralObjectSerializerBase.java:233)
at com.sun.xml.rpc.encoding.literal.LiteralObjectSerializerBase.deserialize(LiteralObjectSerializerBase.java:141)
at com.sun.ts.tests.jaxrpc.ee.wsi.rpc.literal.marshalltest.NewSchemaTest_2_Tie.deserialize_echoVariousSchemaTypesListTypeTest(NewSchemaTest_2_Tie.java:3324)
at com.sun.ts.tests.jaxrpc.ee.wsi.rpc.literal.marshalltest.NewSchemaTest_2_Tie.readFirstBodyElement(NewSchemaTest_2_Tie.java:2626)
at com.sun.xml.rpc.server.StreamingHandler.handle(StreamingHandler.java:262)
at com.sun.xml.rpc.server.http.JAXRPCServletDelegate.doPost(JAXRPCServletDelegate.java:465)



 Comments   
Comment by Lukas Jungmann [ 26/Jul/12 ]

fixed in r55219





[GLASSFISH-18740] Webservice stacktrace is not included in the HTTP response even if com.sun.xml.ws.fault.SOAPFaultBuilder.enableCaptureStackTrace is true Created: 18/May/12  Updated: 01/Aug/12  Resolved: 01/Aug/12

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b36
Fix Version/s: 4.0_b48

Type: Bug Priority: Major
Reporter: tak09 Assignee: Lukas Jungmann
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Attachments: File jaxws-w2j-03-web.war     Zip Archive src.zip    
Issue Links:
Dependency
depends on JAX_WS-1076 disableCaptureStackTrace vs captureSt... Resolved
Tags: metro2_2_1-waived

 Description   

Problem 1
In GlassFish v2.1.2, the HTTP response contains stacktrace from server.
However, in GlassFish v4, stacktrace is not included in the HTTP response.
First, I have set jvm option -Dcom.sun.xml.ws.fault.SOAPFaultBuilder.enableCaptureStackTrace=true in GFv4, but the stacktrace was not in the HTTP response.

Then, I saw this bug ticket. http://java.net/jira/browse/JAX_WS-883
I set another jvm option -Dcom.sun.xml.ws.fault.SOAPFaultBuilder.captureStackTrace=true in GFv4.
I ran the test program again, but still did not see stacktrace in HTTP response.

Problem 2
In GFv2.1.2, stactrace is written in the server.log, but in GFv4, stacktrace is not written in server.log.

To reproduce the issue:
First, follow the steps below using GlassFish v4.

  1. Deploy the war file.
    • Start GlassFish asadmin start-domain
    • Deploy the attached war file. (jaxws-w2j-03-web.war)
  2. Prepare client program
  3. Run Client to confirm test program works
    • Run client
      > java fromwsdl.client.AddNumbersClient
    • You will see the message like this:
      "Caught AddNumbersFault_Exception: Numbers: -10, 20"
  4. Verify the result
    • Problem 1: Check the xml HTTP response data sent from server.
      You might want to use a tool such as TCPMon to see the raw data in xml. The xml does not contain stacktrace if GFv4.
    • Problem 2: Check the server.log . The log does not have stacktrace if GFv4.
  5. Set the jvm options.
    • Open domain.xml and set the following jvm options.
      -Dcom.sun.xml.ws.fault.SOAPFaultBuilder.captureStackTrace=true
      -Dcom.sun.xml.ws.fault.SOAPFaultBuilder.enableCaptureStackTrace=true
  6. Restart GlassFish
  7. Verify the jvm options
    • Run the client again.
    • Check the HTTP response. The HTTP response does not include stacktrace if GFv4.
    • Check the server.log. server.log does not contain stacktrace if GFv4.

Once this is finished with GlassFish v4, repeat the same step using GlassFish v2.1.2. Compare the HTTP response. You will see the stacktrace in the HTTP response xml in GFv2. Compare the server.log as well, you will also find the stacktrace in server.log if GFv2.1.2.

Why stacktrace is not recorded in server.log or not included in HTTP response in v4? That used to work in v2.1.2.



 Comments   
Comment by Lukas Jungmann [ 01/Aug/12 ]

this works as designed - JAX-WS RI docs will be updated (JAX_WS-1076)

server-side stack traces are still being sent but not by default (set com.sun.xml.ws.fault.SOAPFaultBuilder.captureStackTrace=true to turn it on) and when it is set to 'on', only stack traces of exceptions which are not service-specific are being sent. To apply this to attached sample app - AddNumbersFaultException is service specific exception and ws developer can set its message to provide necessary info, if AddNumbersFaultException is replaced by ie RuntimeException stacktrace is sent as well as shown in the server log

this change has been made in issue JAX_WS-761





[GLASSFISH-17326] Nucleus class DeploymentUtils has Java EE references Created: 20/Sep/11  Updated: 26/Jul/12  Resolved: 26/Jul/12

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

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

Issue Links:
Related
is related to GLASSFISH-18329 Deployment/kernel cleanup - Phase 4: ... Open
Tags: 3_1_x-exclude, nucleus-cleanup

 Description   

The DeploymentUtils class which resides in nucleus contains references to the Java EE deployment descriptor file names and other Java EE references, including an isJavaEE method. These need to be refactored.



 Comments   
Comment by Hong Zhang [ 17/Oct/11 ]

This is part of the nucleus clean up work for BG.

Comment by Hong Zhang [ 26/Apr/12 ]

Some progress made this week related to this:

1. Remove javax.enterprise.deploy dependency from nucleus distribution (deployment-common module). Move various methods of getting archive types from DeploymentUtils to DOLUtils and update the classes referencing the methods.

2. Have the archive handlers be responsible for returning the associated class path URLs for the archive instead of having the DeploymentUtils class do it for them. Add an ArchiveHandler.getClassPathURIs API for each archive handler to return its corresponding class path URLs and move out the relevant logic from DeploymentUtils (deploymenmt-common module) and SnifferManagerImpl (core-kernel module).

Comment by Sanjeeb Sahoo [ 27/Apr/12 ]

1. Pl. reference svn revision no. in JIRA and mention JIRA ids in svn comments wherever possible.
2. This task should either be closed or set as a child of GLASSFISH-18329

Comment by Hong Zhang [ 26/Jul/12 ]

Replace various isXXX methods with generic isArchiveOfType methods (one takes a DeploymentContext when it's applicable for optimization, and one does not for the case where DeploymentContext is not available from the calling code) to remove Java EE dependencies from DeploymentUtils. The container specific logic are moved to the corresponding container modules.

Committed svn version: svn 55221

Comment by Sanjeeb Sahoo [ 26/Jul/12 ]

Very nice. Thank you, Hong.





Generated at Tue Jul 07 10:04:24 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.