[jira] Created: (AXIS2-4620) Adding OnDemandLogger to allow the LogFactory lookup to occur on first touch versus during static class initialization
Adding OnDemandLogger to allow the LogFactory lookup to occur on first touch versus during static class initialization -- Key: AXIS2-4620 URL: https://issues.apache.org/jira/browse/AXIS2-4620 Project: Axis2 Issue Type: Bug Components: kernel Reporter: Rich Scheuerle Assignee: Rich Scheuerle Problem: In most classes, the Log and LogFactory are statically declared (example AxisServlet). This causes the Log to be discovered and loaded during the class loading, which can be expensive. If Axis2 is embedded, the wrong Log may be calculated (i.e. it may get the Log associated with the static loading versus the Log associated with the application's classloader). Solution: Adding a OnDemandLogger object will defer the Log construction until the Log is needed. This solution was proposed by Nikhil Thaker and Muhammad Sadiq. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4620) Adding OnDemandLogger to allow the LogFactory lookup to occur on first touch versus during static class initialization
[ https://issues.apache.org/jira/browse/AXIS2-4620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4620. --- Resolution: Fixed Adding OnDemandLogger to allow the LogFactory lookup to occur on first touch versus during static class initialization -- Key: AXIS2-4620 URL: https://issues.apache.org/jira/browse/AXIS2-4620 Project: Axis2 Issue Type: Bug Components: kernel Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 24h Remaining Estimate: 24h Problem: In most classes, the Log and LogFactory are statically declared (example AxisServlet). This causes the Log to be discovered and loaded during the class loading, which can be expensive. If Axis2 is embedded, the wrong Log may be calculated (i.e. it may get the Log associated with the static loading versus the Log associated with the application's classloader). Solution: Adding a OnDemandLogger object will defer the Log construction until the Log is needed. This solution was proposed by Nikhil Thaker and Muhammad Sadiq. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4603) JAX-WS: JAXB Unmarshal code no longer has direct access to the required XMLStreamReader
[ https://issues.apache.org/jira/browse/AXIS2-4603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4603. --- Resolution: Fixed JAX-WS: JAXB Unmarshal code no longer has direct access to the required XMLStreamReader --- Key: AXIS2-4603 URL: https://issues.apache.org/jira/browse/AXIS2-4603 Project: Axis2 Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 120h Remaining Estimate: 120h Background: The JAX-WS programming model uses JAX-B objects as the representation of user business data. The JAX-WS runtime in Axis2 is responsibile for building the JAXBContext and marshaling and umarshaling the JAX-B objects. The marshaling and unmarshaling includes marshaling and unmarshaling MTOM data. When unmarshaling JAXB, the streaming, non-cached parser (original XMLStreamReader) or cached XMLStreamReader (OMStaXWrapper) is used as the input XMLStreamReader for the JAXB unmarshal code. Problem: The Axiom implementation has been changed such that the non-cached parser is now wrapped by one or more other axiom wrappers or delegates. Failure to the access the original steaming parser has resulted in poorer performance in some cases when unmarshaling WSCommons-518 now exposes additional methods to access the original non-cached parser. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4606) JAX-WS: Secondary error occurs while processing AsncResponse
[
https://issues.apache.org/jira/browse/AXIS2-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rich Scheuerle resolved AXIS2-4606.
---
Resolution: Fixed
JAX-WS: Secondary error occurs while processing AsncResponse
Key: AXIS2-4606
URL: https://issues.apache.org/jira/browse/AXIS2-4606
Project: Axis2
Issue Type: Bug
Components: jaxws
Reporter: Rich Scheuerle
Assignee: Rich Scheuerle
Original Estimate: 72h
Remaining Estimate: 72h
While processing a JAX-WS aysnchronous response, a NullPointerException may
occur in the onError method of the jaxws AsyncResponse object.
This is an exception that occurs while processing an exception and leads to
instability in the system.
For example it may lead to a hung system if the caller does not adequately
account for such secondary errors.
protected void onError(Throwable flt, MessageContext faultCtx) {
if (log.isDebugEnabled()) {
log.debug(AsyncResponse received a fault.);
}
fault = flt;
faultMessageContext = faultCtx;
faultMessageContext.setEndpointDescription(endpointDescription);
NPE occurs here.
Proposed Solution:
The code will be changed to check for a null faultMessageContext before using
it. A null faultMessageContext is an indication that the onError is
processing a local exception (versus an error from an Endpoint's SOAP Fault).
The onError method will also be hardened to catch other other errors and
respond gracefully. Throwing secondary exceptions from onError leads to
system instability.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4606) JAX-WS: Secondary error occurs while processing AsncResponse
JAX-WS: Secondary error occurs while processing AsncResponse
Key: AXIS2-4606
URL: https://issues.apache.org/jira/browse/AXIS2-4606
Project: Axis2
Issue Type: Bug
Components: jaxws
Reporter: Rich Scheuerle
Assignee: Rich Scheuerle
While processing a JAX-WS aysnchronous response, a NullPointerException may
occur in the onError method of the jaxws AsyncResponse object.
This is an exception that occurs while processing an exception and leads to
instability in the system.
For example it may lead to a hung system if the caller does not adequately
account for such secondary errors.
protected void onError(Throwable flt, MessageContext faultCtx) {
if (log.isDebugEnabled()) {
log.debug(AsyncResponse received a fault.);
}
fault = flt;
faultMessageContext = faultCtx;
faultMessageContext.setEndpointDescription(endpointDescription);
NPE occurs here.
Proposed Solution:
The code will be changed to check for a null faultMessageContext before using
it. A null faultMessageContext is an indication that the onError is processing
a local exception (versus an error from an Endpoint's SOAP Fault).
The onError method will also be hardened to catch other other errors and
respond gracefully. Throwing secondary exceptions from onError leads to system
instability.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4603) JAX-WS: JAXB Unmarshal code no longer has direct access to the required XMLStreamReader
JAX-WS: JAXB Unmarshal code no longer has direct access to the required XMLStreamReader --- Key: AXIS2-4603 URL: https://issues.apache.org/jira/browse/AXIS2-4603 Project: Axis2 Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Background: The JAX-WS programming model uses JAX-B objects as the representation of user business data. The JAX-WS runtime in Axis2 is responsibile for building the JAXBContext and marshaling and umarshaling the JAX-B objects. The marshaling and unmarshaling includes marshaling and unmarshaling MTOM data. When unmarshaling JAXB, the streaming, non-cached parser (original XMLStreamReader) or cached XMLStreamReader (OMStaXWrapper) is used as the input XMLStreamReader for the JAXB unmarshal code. Problem: The Axiom implementation has been changed such that the non-cached parser is now wrapped by one or more other axiom wrappers or delegates. Failure to the access the original steaming parser has resulted in poorer performance in some cases when unmarshaling WSCommons-518 now exposes additional methods to access the original non-cached parser. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AXIS2-4603) JAX-WS: JAXB Unmarshal code no longer has direct access to the required XMLStreamReader
[ https://issues.apache.org/jira/browse/AXIS2-4603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800977#action_12800977 ] Rich Scheuerle commented on AXIS2-4603: --- Thanks for the suggestion, but there are two problems with that approach. 1) The JAXB Umarshaller works more efficiently if the XMLStreamReader from the same vendor is used. Thus there is a need to access the original parser. 2) Adding an XOPEncodingStreamReader may be one solution for accessing DataHandlers...but I believe that it also adds a buffering. thanks, Rich JAX-WS: JAXB Unmarshal code no longer has direct access to the required XMLStreamReader --- Key: AXIS2-4603 URL: https://issues.apache.org/jira/browse/AXIS2-4603 Project: Axis2 Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 120h Remaining Estimate: 120h Background: The JAX-WS programming model uses JAX-B objects as the representation of user business data. The JAX-WS runtime in Axis2 is responsibile for building the JAXBContext and marshaling and umarshaling the JAX-B objects. The marshaling and unmarshaling includes marshaling and unmarshaling MTOM data. When unmarshaling JAXB, the streaming, non-cached parser (original XMLStreamReader) or cached XMLStreamReader (OMStaXWrapper) is used as the input XMLStreamReader for the JAXB unmarshal code. Problem: The Axiom implementation has been changed such that the non-cached parser is now wrapped by one or more other axiom wrappers or delegates. Failure to the access the original steaming parser has resulted in poorer performance in some cases when unmarshaling WSCommons-518 now exposes additional methods to access the original non-cached parser. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4562) JAX-WS: JAXBContext construction in JAX-WS should avoid SessionBean
[ https://issues.apache.org/jira/browse/AXIS2-4562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4562. --- Resolution: Fixed JAX-WS: JAXBContext construction in JAX-WS should avoid SessionBean --- Key: AXIS2-4562 URL: https://issues.apache.org/jira/browse/AXIS2-4562 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 24h Remaining Estimate: 24h Background: The JAX-WS runtime inspects the JAX-WS artifacts to determine which packages or classes should be part of the JAXBContext. In most cases, the JAXBContext is constructed with a series of packages (which is relatively fast). However if a package does not contain JAXB ObjectFactory or package.info, then the JAXBUtils code must inspect individual classes in the package to see if they are actually JAXB tolerable. Problem: When the code falls down this secondary lookup path, it should avoid classes that implement javax.ejb.SessionBean. Such classes are not JAXB classes and inspecting those classes can result in degraded performance. Solution: I have a design to inspect classes to see if they should be skipped over. For example classes that implement SessionBean should be skipped. This new code avoids loading the SessionBean objects (which may not be present). I am testing the solution, and I am designing a unit test to verify the code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (AXIS2-1471) Updating resource.properties files for kernel and jaxws modules
[ https://issues.apache.org/jira/browse/AXIS2-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle reopened AXIS2-1471: --- Updating resource.properties files for kernel and jaxws modules --- Key: AXIS2-1471 URL: https://issues.apache.org/jira/browse/AXIS2-1471 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: jaxws, kernel Environment: Systems running with English locale. Reporter: Ming Cheung Assignee: Rich Scheuerle Priority: Trivial Attachments: patch.txt, patch2.txt, patch3.txt The purpose of revising these resources.properties files is for the possibility of translating these files into multiple National languages files such as Germany, Spanish, Japanese, and etc in the future. The new uploaded patch contains files which are formatted with proper English syntax, spelling and usage. These changes have also been reviewed by a Technical Writer. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-1471) Updating resource.properties files for kernel and jaxws modules
[ https://issues.apache.org/jira/browse/AXIS2-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-1471. --- Resolution: Fixed Updating resource.properties files for kernel and jaxws modules --- Key: AXIS2-1471 URL: https://issues.apache.org/jira/browse/AXIS2-1471 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: jaxws, kernel Environment: Systems running with English locale. Reporter: Ming Cheung Assignee: Rich Scheuerle Priority: Trivial Attachments: patch.txt, patch2.txt, patch3.txt The purpose of revising these resources.properties files is for the possibility of translating these files into multiple National languages files such as Germany, Spanish, Japanese, and etc in the future. The new uploaded patch contains files which are formatted with proper English syntax, spelling and usage. These changes have also been reviewed by a Technical Writer. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4576) ConcurrentModificationException in JAX-WS Handler chain processing
ConcurrentModificationException in JAX-WS Handler chain processing -- Key: AXIS2-4576 URL: https://issues.apache.org/jira/browse/AXIS2-4576 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Problem: A ConcurrentModificationException may occur in the JAX-WS handler chain processing if two applications (on separate threads) provide the same handler list. Solution: The HandlerChainProcessor will be chained to make a local copy of the list during the handler processing. This will avoid the CME. Kudos to Mike Rheinheimer and Nick Gallardo for contributing their thoughts to this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4576) ConcurrentModificationException in JAX-WS Handler chain processing
[ https://issues.apache.org/jira/browse/AXIS2-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4576. --- Resolution: Fixed ConcurrentModificationException in JAX-WS Handler chain processing -- Key: AXIS2-4576 URL: https://issues.apache.org/jira/browse/AXIS2-4576 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 24h Remaining Estimate: 24h Problem: A ConcurrentModificationException may occur in the JAX-WS handler chain processing if two applications (on separate threads) provide the same handler list. Solution: The HandlerChainProcessor will be chained to make a local copy of the list during the handler processing. This will avoid the CME. Kudos to Mike Rheinheimer and Nick Gallardo for contributing their thoughts to this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (AXIS2-4264) Empty action not applied in CommonsHTTPTransportSender
[ https://issues.apache.org/jira/browse/AXIS2-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle reassigned AXIS2-4264: - Assignee: Rich Scheuerle Empty action not applied in CommonsHTTPTransportSender -- Key: AXIS2-4264 URL: https://issues.apache.org/jira/browse/AXIS2-4264 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: transports Affects Versions: 1.5, 1.4.1, 1.4, 1.3 Reporter: Alexis Midon Assignee: Rich Scheuerle Fix For: 1.6 Attachments: AXIS2-4264.patch.txt Hello there, I'm invoking a service using a ServiceClient, the wsdl operation declares an empty soapAction. However the soapActiuon actually sent is urn:anonOutInOp which the server refuses. This action is the action the anonymous operation urn:anonOutInOp and is set by the ServiceClient. Later when CommonsHTTPTransportSender#findSOAPAction [1] is invoked, if the action of the MessageContext is null or empty, the operation action is used. The empty case seems like a bug, because this is the action set in the wsdl and it is not applied. This opinion is strengthened by the fact that other senders do not have this behavior. The right behavior would be: if null ; use the operation action as a default if empty ; send an empty soapAction Could you confirm please? Alexis [1] http://is.gd/m0Mt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (AXIS2-4264) Empty action not applied in CommonsHTTPTransportSender
[ https://issues.apache.org/jira/browse/AXIS2-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle reopened AXIS2-4264: --- ReopenedNote that the code supplied by Dims checks for the same constructed name 3 times instead of checking for the 3 constructed names. Empty action not applied in CommonsHTTPTransportSender -- Key: AXIS2-4264 URL: https://issues.apache.org/jira/browse/AXIS2-4264 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: transports Affects Versions: 1.5, 1.4.1, 1.4, 1.3 Reporter: Alexis Midon Fix For: 1.6 Attachments: AXIS2-4264.patch.txt Hello there, I'm invoking a service using a ServiceClient, the wsdl operation declares an empty soapAction. However the soapActiuon actually sent is urn:anonOutInOp which the server refuses. This action is the action the anonymous operation urn:anonOutInOp and is set by the ServiceClient. Later when CommonsHTTPTransportSender#findSOAPAction [1] is invoked, if the action of the MessageContext is null or empty, the operation action is used. The empty case seems like a bug, because this is the action set in the wsdl and it is not applied. This opinion is strengthened by the fact that other senders do not have this behavior. The right behavior would be: if null ; use the operation action as a default if empty ; send an empty soapAction Could you confirm please? Alexis [1] http://is.gd/m0Mt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4264) Empty action not applied in CommonsHTTPTransportSender
[ https://issues.apache.org/jira/browse/AXIS2-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4264. --- Resolution: Fixed Empty action not applied in CommonsHTTPTransportSender -- Key: AXIS2-4264 URL: https://issues.apache.org/jira/browse/AXIS2-4264 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: transports Affects Versions: 1.5, 1.4.1, 1.4, 1.3 Reporter: Alexis Midon Assignee: Rich Scheuerle Fix For: 1.6 Attachments: AXIS2-4264.patch.txt Hello there, I'm invoking a service using a ServiceClient, the wsdl operation declares an empty soapAction. However the soapActiuon actually sent is urn:anonOutInOp which the server refuses. This action is the action the anonymous operation urn:anonOutInOp and is set by the ServiceClient. Later when CommonsHTTPTransportSender#findSOAPAction [1] is invoked, if the action of the MessageContext is null or empty, the operation action is used. The empty case seems like a bug, because this is the action set in the wsdl and it is not applied. This opinion is strengthened by the fact that other senders do not have this behavior. The right behavior would be: if null ; use the operation action as a default if empty ; send an empty soapAction Could you confirm please? Alexis [1] http://is.gd/m0Mt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (AXIS2-4562) JAX-WS: JAXBContext construction in JAX-WS should avoid SessionBean
[ https://issues.apache.org/jira/browse/AXIS2-4562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle reopened AXIS2-4562: --- JAX-WS: JAXBContext construction in JAX-WS should avoid SessionBean --- Key: AXIS2-4562 URL: https://issues.apache.org/jira/browse/AXIS2-4562 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 24h Remaining Estimate: 24h Background: The JAX-WS runtime inspects the JAX-WS artifacts to determine which packages or classes should be part of the JAXBContext. In most cases, the JAXBContext is constructed with a series of packages (which is relatively fast). However if a package does not contain JAXB ObjectFactory or package.info, then the JAXBUtils code must inspect individual classes in the package to see if they are actually JAXB tolerable. Problem: When the code falls down this secondary lookup path, it should avoid classes that implement javax.ejb.SessionBean. Such classes are not JAXB classes and inspecting those classes can result in degraded performance. Solution: I have a design to inspect classes to see if they should be skipped over. For example classes that implement SessionBean should be skipped. This new code avoids loading the SessionBean objects (which may not be present). I am testing the solution, and I am designing a unit test to verify the code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4565) JAX-WS: Fails to examine the @RequestWrapper targetNamespace. Also needs to tolerate wsimport NS-PKG mapping algorithm
JAX-WS: Fails to examine the @RequestWrapper targetNamespace. Also needs to tolerate wsimport NS-PKG mapping algorithm - Key: AXIS2-4565 URL: https://issues.apache.org/jira/browse/AXIS2-4565 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Background: The JAX-WS runtime examines the web service annotations and packages to determine which packages should be included in the JAXBContext. The JAX-WS runtime uses the namespace-package algorithm defined by the JAXB Specification when it needs to convert namespace references into packages. --- Problem 1: The JAX-WS runtime is not examining the targentnamespace parameter on the @RequestWrapper and @ResponseWrapper annotations. Thus it might neglect to include a package in the JAXBContext. (Note that this is rare. The JAX-WS runtime looks at the package referenced in the className parameter. Thus problems only occur if the wrapper element and the wrapper complexType are defined in two separate schemas...which is rare) Problem 2: Many applications are built using the wsimport tool. This tool apparently has a slightly different namespace-package mapping algorithm. For example, the JAXB specification (rule 8b) indicates if a namespace word collides with a java keyword, then a _ is appended . JAXB Rule: urn://my.interface.com becomes com.interface_.my. The wsimport tool prepends the underscore. WSIMPORT Rule: urn://my.interface.com becomes com._interface.my. -- Proposed Solution: For 1) The engine will be changed to examine the @RequestWrapper and @ResponseWrapper targetnamespace parameters. For 2) The engine will be changed to tolerate both rules. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4565) JAX-WS: Fails to examine the @RequestWrapper targetNamespace. Also needs to tolerate wsimport NS-PKG mapping algorithm
[ https://issues.apache.org/jira/browse/AXIS2-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4565. --- Resolution: Fixed JAX-WS: Fails to examine the @RequestWrapper targetNamespace. Also needs to tolerate wsimport NS-PKG mapping algorithm - Key: AXIS2-4565 URL: https://issues.apache.org/jira/browse/AXIS2-4565 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 24h Remaining Estimate: 24h Background: The JAX-WS runtime examines the web service annotations and packages to determine which packages should be included in the JAXBContext. The JAX-WS runtime uses the namespace-package algorithm defined by the JAXB Specification when it needs to convert namespace references into packages. --- Problem 1: The JAX-WS runtime is not examining the targentnamespace parameter on the @RequestWrapper and @ResponseWrapper annotations. Thus it might neglect to include a package in the JAXBContext. (Note that this is rare. The JAX-WS runtime looks at the package referenced in the className parameter. Thus problems only occur if the wrapper element and the wrapper complexType are defined in two separate schemas...which is rare) Problem 2: Many applications are built using the wsimport tool. This tool apparently has a slightly different namespace-package mapping algorithm. For example, the JAXB specification (rule 8b) indicates if a namespace word collides with a java keyword, then a _ is appended . JAXB Rule: urn://my.interface.com becomes com.interface_.my. The wsimport tool prepends the underscore. WSIMPORT Rule: urn://my.interface.com becomes com._interface.my. -- Proposed Solution: For 1) The engine will be changed to examine the @RequestWrapper and @ResponseWrapper targetnamespace parameters. For 2) The engine will be changed to tolerate both rules. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4562) JAX-WS: JAXBContext construction in JAX-WS should avoid SessionBean
[ https://issues.apache.org/jira/browse/AXIS2-4562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4562. --- Resolution: Fixed JAX-WS: JAXBContext construction in JAX-WS should avoid SessionBean --- Key: AXIS2-4562 URL: https://issues.apache.org/jira/browse/AXIS2-4562 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 24h Remaining Estimate: 24h Background: The JAX-WS runtime inspects the JAX-WS artifacts to determine which packages or classes should be part of the JAXBContext. In most cases, the JAXBContext is constructed with a series of packages (which is relatively fast). However if a package does not contain JAXB ObjectFactory or package.info, then the JAXBUtils code must inspect individual classes in the package to see if they are actually JAXB tolerable. Problem: When the code falls down this secondary lookup path, it should avoid classes that implement javax.ejb.SessionBean. Such classes are not JAXB classes and inspecting those classes can result in degraded performance. Solution: I have a design to inspect classes to see if they should be skipped over. For example classes that implement SessionBean should be skipped. This new code avoids loading the SessionBean objects (which may not be present). I am testing the solution, and I am designing a unit test to verify the code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (AXIS2-4550) Parser incorrectly complains about mising prefix or duplicate attributes on the soap message
[ https://issues.apache.org/jira/browse/AXIS2-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle reassigned AXIS2-4550: - Assignee: Rich Scheuerle Parser incorrectly complains about mising prefix or duplicate attributes on the soap message Key: AXIS2-4550 URL: https://issues.apache.org/jira/browse/AXIS2-4550 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Lori VanGulick Assignee: Rich Scheuerle Attachments: AXIS2-4550.patch When using the when the JAX-WS DispatchOMElement or ProviderOMElement APIs, there may be cases where the parser incorrectly reports missing prefix and/or duplicate attributes on the SOAP message. Under some circumstances the JAX-WS implementation of the DispatchOMElement and ProviderOMElement APIs are not able to find the namespace or attribute declarations that are located on ancestor xml elements or these declarations were incorrectly discovered to be duplicated. The algorithm should be corrected to propagate namespace and attribute declarations to child elements. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (AXIS2-4556) In a SOAP attachment message, the Content-Type header's boundary parameter value must be quoted
[ https://issues.apache.org/jira/browse/AXIS2-4556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle reassigned AXIS2-4556: - Assignee: Rich Scheuerle In a SOAP attachment message, the Content-Type header's boundary parameter value must be quoted --- Key: AXIS2-4556 URL: https://issues.apache.org/jira/browse/AXIS2-4556 Project: Axis 2.0 (Axis2) Issue Type: Bug Reporter: Wendy Raschke Assignee: Rich Scheuerle Priority: Minor If SOAP Messages with Attachments (SwA) or SOAP Message Transmission Optimization Mechanism (MTOM) is used to send attachments, the Axis2 runtime will send a Content-Type header with a boundary parameter whose value is not quoted. Here is an example: Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_9152FA64BB334CBE261257799614016; type=application/xop xml; start=0.urn:uuid:9152fa64bb334cbe261257799614...@apache.org; start-info=application/soap xml; action=http://xmlsoap.org/EchoStringArrayAsBinaryArray; In order to be WS-I-compliant, the boundary value should be quoted. In this case, the boundary parameter should appear as boundary=MIMEBoundaryurn_uuid_9152FA64BB334CBE261257799614016; The WS-I Basic Profile 2.0 Specification, Rule R1109 states, Parameters on the Content-Type MIME header field-value in a request MESSAGE MUST be a quoted string. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (AXIS2-4556) In a SOAP attachment message, the Content-Type header's boundary parameter value must be quoted
[ https://issues.apache.org/jira/browse/AXIS2-4556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle closed AXIS2-4556. - Resolution: Fixed Will be fixed by WSCOMMONS-510 In a SOAP attachment message, the Content-Type header's boundary parameter value must be quoted --- Key: AXIS2-4556 URL: https://issues.apache.org/jira/browse/AXIS2-4556 Project: Axis 2.0 (Axis2) Issue Type: Bug Reporter: Wendy Raschke Assignee: Rich Scheuerle Priority: Minor If SOAP Messages with Attachments (SwA) or SOAP Message Transmission Optimization Mechanism (MTOM) is used to send attachments, the Axis2 runtime will send a Content-Type header with a boundary parameter whose value is not quoted. Here is an example: Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_9152FA64BB334CBE261257799614016; type=application/xop xml; start=0.urn:uuid:9152fa64bb334cbe261257799614...@apache.org; start-info=application/soap xml; action=http://xmlsoap.org/EchoStringArrayAsBinaryArray; In order to be WS-I-compliant, the boundary value should be quoted. In this case, the boundary parameter should appear as boundary=MIMEBoundaryurn_uuid_9152FA64BB334CBE261257799614016; The WS-I Basic Profile 2.0 Specification, Rule R1109 states, Parameters on the Content-Type MIME header field-value in a request MESSAGE MUST be a quoted string. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4550) Parser incorrectly complains about mising prefix or duplicate attributes on the soap message
[ https://issues.apache.org/jira/browse/AXIS2-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4550. --- Resolution: Fixed Parser incorrectly complains about mising prefix or duplicate attributes on the soap message Key: AXIS2-4550 URL: https://issues.apache.org/jira/browse/AXIS2-4550 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Lori VanGulick Assignee: Rich Scheuerle Attachments: AXIS2-4550.patch When using the when the JAX-WS DispatchOMElement or ProviderOMElement APIs, there may be cases where the parser incorrectly reports missing prefix and/or duplicate attributes on the SOAP message. Under some circumstances the JAX-WS implementation of the DispatchOMElement and ProviderOMElement APIs are not able to find the namespace or attribute declarations that are located on ancestor xml elements or these declarations were incorrectly discovered to be duplicated. The algorithm should be corrected to propagate namespace and attribute declarations to child elements. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4561) JAX-WS: ClassCastException when DispatchOMElement receives a SOAPFault
JAX-WS: ClassCastException when DispatchOMElement receives a SOAPFault Key: AXIS2-4561 URL: https://issues.apache.org/jira/browse/AXIS2-4561 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle The following exception occurred when a JAX-WS DispatchOMElement API was used on the client, and the server responded with a message containing a SOAPFault. javax.xml.ws.WebServiceException: java.lang.ClassCastException: org.apache.axiom.om.impl.llom.OMSourcedElementImpl incompatible with org.apache.axiom.soap.SOAPFault at org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:175) at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:70) at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:128) at org.apache.axis2.jaxws.client.dispatch.BaseDispatch.invoke(BaseDispatch.java:244) Analysis: The ParserInputStreamCustomBuilder was inadvertently optimizing the input stream even though the message contained a SOAPFault. I am changing the code to detect this situation and disable the optimization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4561) JAX-WS: ClassCastException when DispatchOMElement receives a SOAPFault
[ https://issues.apache.org/jira/browse/AXIS2-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4561. --- Resolution: Fixed JAX-WS: ClassCastException when DispatchOMElement receives a SOAPFault Key: AXIS2-4561 URL: https://issues.apache.org/jira/browse/AXIS2-4561 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 24h Remaining Estimate: 24h The following exception occurred when a JAX-WS DispatchOMElement API was used on the client, and the server responded with a message containing a SOAPFault. javax.xml.ws.WebServiceException: java.lang.ClassCastException: org.apache.axiom.om.impl.llom.OMSourcedElementImpl incompatible with org.apache.axiom.soap.SOAPFault at org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:175) at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:70) at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:128) at org.apache.axis2.jaxws.client.dispatch.BaseDispatch.invoke(BaseDispatch.java:244) Analysis: The ParserInputStreamCustomBuilder was inadvertently optimizing the input stream even though the message contained a SOAPFault. I am changing the code to detect this situation and disable the optimization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4562) JAX-WS: JAXBContext construction in JAX-WS should avoid SessionBean
JAX-WS: JAXBContext construction in JAX-WS should avoid SessionBean --- Key: AXIS2-4562 URL: https://issues.apache.org/jira/browse/AXIS2-4562 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Background: The JAX-WS runtime inspects the JAX-WS artifacts to determine which packages or classes should be part of the JAXBContext. In most cases, the JAXBContext is constructed with a series of packages (which is relatively fast). However if a package does not contain JAXB ObjectFactory or package.info, then the JAXBUtils code must inspect individual classes in the package to see if they are actually JAXB tolerable. Problem: When the code falls down this secondary lookup path, it should avoid classes that implement javax.ejb.SessionBean. Such classes are not JAXB classes and inspecting those classes can result in degraded performance. Solution: I have a design to inspect classes to see if they should be skipped over. For example classes that implement SessionBean should be skipped. This new code avoids loading the SessionBean objects (which may not be present). I am testing the solution, and I am designing a unit test to verify the code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (AXIS2-4509) ProviderOMElement Performance Improvement.
[ https://issues.apache.org/jira/browse/AXIS2-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle reopened AXIS2-4509: --- This JIRA neglected to add the performance on the return path (DispatchOMElement). I am making a small change to enable this code on the return path. And I am going to add a verification test. Kudos to dims for providing the prototype for this change. ProviderOMElement Performance Improvement. Key: AXIS2-4509 URL: https://issues.apache.org/jira/browse/AXIS2-4509 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: jaxws Reporter: Nikhil Thaker Assignee: Nikhil Thaker Attachments: axis2_4509.txt I am introducing code that will improve performance for Provider OM. The code improves serialize calls on OM as we now create an OMSourcedElement backed by a data Source that feeds contents from Parser. This eliminates the expensive serialize code path that goes though OMSerializeUtils -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4459) JAX-WS implementation throws JAXBException for complextypes
[ https://issues.apache.org/jira/browse/AXIS2-4459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4459. --- Resolution: Fixed This isssue is fixed by AXIS2-3341 JAX-WS implementation throws JAXBException for complextypes --- Key: AXIS2-4459 URL: https://issues.apache.org/jira/browse/AXIS2-4459 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Affects Versions: 1.5 Environment: Windows XP Service Pack 3. Java 1.6.0_13 Reporter: Brandon Richins Assignee: Rich Scheuerle Attachments: JaxWsExample.zip When calling an operation on a JAX-WS service that returns an array, Axis2 throws a JAXBException indicating that XYZ class is not known to this context. It seems able to marshall when returning a single element. But arrays don't seem to work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-3736) java.util.List is not known to this context
[
https://issues.apache.org/jira/browse/AXIS2-3736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rich Scheuerle resolved AXIS2-3736.
---
Resolution: Fixed
Should be resolved by AXIS2-3341
java.util.List is not known to this context
---
Key: AXIS2-3736
URL: https://issues.apache.org/jira/browse/AXIS2-3736
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: jaxws
Reporter: Davanum Srinivas
Assignee: Rich Scheuerle
Attachments: apples.zip
== SEI
@WebService
@XmlSeeAlso({ Apple.class, Fuji.class })
public interface AppleFinder {
ListApple getApple(String appType);
}
== Impl
@WebService(endpointInterface =
org.apache.cxf.systest.type_substitution.AppleFinder,
serviceName = AppleFinder)
public class AppleFinderImpl implements AppleFinder {
public ListApple getApple(String appleType) {
ListApple apples = new ArrayListApple();
apples.add(new Fuji(Red, mild, Fuji-1));
apples.add(new Fuji(Yellow, sweet, Fuji-2));
return apples;
}
}
= Stack Trace =
[javax.xml.bind.JAXBException: java.util.List is not known to this context]
at
com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:331)
at
com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:175)
at
org.apache.axis2.datasource.jaxb.JAXBDSContext$3.run(JAXBDSContext.java:664)
at
org.apache.axis2.java.security.AccessController.doPrivileged(AccessController.java:76)
at
org.apache.axis2.datasource.jaxb.JAXBDSContext.marshalByType(JAXBDSContext.java:566)
at
org.apache.axis2.datasource.jaxb.JAXBDSContext.marshal(JAXBDSContext.java:294)
at
org.apache.axis2.jaxws.message.databinding.impl.JAXBBlockImpl._outputFromBO(JAXBBlockImpl.java:175)
at
org.apache.axis2.jaxws.message.impl.BlockImpl.outputTo(BlockImpl.java:342)
at
org.apache.axis2.jaxws.message.impl.BlockImpl.serialize(BlockImpl.java:266)
at
org.apache.axiom.om.impl.llom.OMSourcedElementImpl.internalSerializeAndConsume(OMSourcedElementImpl.java:664)
at
org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:918)
at
org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:947)
at
org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:918)
at
org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:947)
at
org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.serializeInternally(SOAPEnvelopeImpl.java:240)
at
org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.internalSerialize(SOAPEnvelopeImpl.java:228)
at
org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:947)
at
org.apache.axiom.om.impl.llom.OMNodeImpl.serializeAndConsume(OMNodeImpl.java:471)
at
org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:68)
at
org.apache.axis2.transport.http.CommonsHTTPTransportSender.sendUsingOutputStream(CommonsHTTPTransportSender.java:330)
at
org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:213)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:448)
at
org.apache.axis2.jaxws.server.JAXWSMessageReceiver.receive(JAXWSMessageReceiver.java:210)
... 9 more
Caused by: javax.xml.bind.JAXBException: java.util.List is not known to this
context
at
com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:242)
at
com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:257)
at
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:143)
at
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:185)
at
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementBeanInfoImpl.java:305)
at
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:312)
at
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:71)
at
com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:490)
at
com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:328)
... 31 more
Caused by: javax.xml.bind.JAXBException: java.util.List is not known to this
context
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImpl.java:587)
at
[jira] Assigned: (AXIS2-4530) XMLFaultUtils.createSAAJFault() creates a fault with incorrect node
[
https://issues.apache.org/jira/browse/AXIS2-4530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rich Scheuerle reassigned AXIS2-4530:
-
Assignee: Rich Scheuerle
XMLFaultUtils.createSAAJFault() creates a fault with incorrect node
---
Key: AXIS2-4530
URL: https://issues.apache.org/jira/browse/AXIS2-4530
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: jaxws
Reporter: Wendy Raschke
Assignee: Rich Scheuerle
Attachments: AXIS-4530.patch
A web service creates a SOAPFaultException with a SOAP fault like the below:
...
soap:Faultsoap:Codesoap:Valuesoap:Receiver/soap:Valuesoap:Subcodesoap:Valueq0:Err_600/soap:Value/soap:Subcode/soap:Codesoap:Reasonsoap:Text
xml:lang=en{etc}soap:Text/soap:Reasonsoap:Nodehttp://example.host:8080/HelloService/HelloService.asmx/soap:Nodesoap:RoleHelloWorld/soap:Rolesoap:Detail//soap:Fault...
It throws it, and when the client catches this exception and gets the
SOAPFault from it, it does not get the proper value for Node. i.e., when it
calls SOAPFault.getNode(), it gets null. This is due to this code in
XMLFaultUtils.createSAAJFault():
// Set the Node...only applicable for SOAP 1.2
if (xmlFault.getNode() != null
protocolNS.equals(SOAPConstants.URI_NS_SOAP_1_2_ENVELOPE))
{
soapFault.setFaultRole(xmlFault.getNode());
// -- Incorrect
}
The indicated line should be changed to
soapFault.setFaultNode(xmlFault.getNode());
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work started: (AXIS2-4530) XMLFaultUtils.createSAAJFault() creates a fault with incorrect node
[
https://issues.apache.org/jira/browse/AXIS2-4530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on AXIS2-4530 started by Rich Scheuerle.
XMLFaultUtils.createSAAJFault() creates a fault with incorrect node
---
Key: AXIS2-4530
URL: https://issues.apache.org/jira/browse/AXIS2-4530
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: jaxws
Reporter: Wendy Raschke
Assignee: Rich Scheuerle
Attachments: AXIS-4530.patch
A web service creates a SOAPFaultException with a SOAP fault like the below:
...
soap:Faultsoap:Codesoap:Valuesoap:Receiver/soap:Valuesoap:Subcodesoap:Valueq0:Err_600/soap:Value/soap:Subcode/soap:Codesoap:Reasonsoap:Text
xml:lang=en{etc}soap:Text/soap:Reasonsoap:Nodehttp://example.host:8080/HelloService/HelloService.asmx/soap:Nodesoap:RoleHelloWorld/soap:Rolesoap:Detail//soap:Fault...
It throws it, and when the client catches this exception and gets the
SOAPFault from it, it does not get the proper value for Node. i.e., when it
calls SOAPFault.getNode(), it gets null. This is due to this code in
XMLFaultUtils.createSAAJFault():
// Set the Node...only applicable for SOAP 1.2
if (xmlFault.getNode() != null
protocolNS.equals(SOAPConstants.URI_NS_SOAP_1_2_ENVELOPE))
{
soapFault.setFaultRole(xmlFault.getNode());
// -- Incorrect
}
The indicated line should be changed to
soapFault.setFaultNode(xmlFault.getNode());
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4530) XMLFaultUtils.createSAAJFault() creates a fault with incorrect node
[
https://issues.apache.org/jira/browse/AXIS2-4530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rich Scheuerle resolved AXIS2-4530.
---
Resolution: Fixed
XMLFaultUtils.createSAAJFault() creates a fault with incorrect node
---
Key: AXIS2-4530
URL: https://issues.apache.org/jira/browse/AXIS2-4530
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: jaxws
Reporter: Wendy Raschke
Assignee: Rich Scheuerle
Attachments: AXIS-4530.patch
A web service creates a SOAPFaultException with a SOAP fault like the below:
...
soap:Faultsoap:Codesoap:Valuesoap:Receiver/soap:Valuesoap:Subcodesoap:Valueq0:Err_600/soap:Value/soap:Subcode/soap:Codesoap:Reasonsoap:Text
xml:lang=en{etc}soap:Text/soap:Reasonsoap:Nodehttp://example.host:8080/HelloService/HelloService.asmx/soap:Nodesoap:RoleHelloWorld/soap:Rolesoap:Detail//soap:Fault...
It throws it, and when the client catches this exception and gets the
SOAPFault from it, it does not get the proper value for Node. i.e., when it
calls SOAPFault.getNode(), it gets null. This is due to this code in
XMLFaultUtils.createSAAJFault():
// Set the Node...only applicable for SOAP 1.2
if (xmlFault.getNode() != null
protocolNS.equals(SOAPConstants.URI_NS_SOAP_1_2_ENVELOPE))
{
soapFault.setFaultRole(xmlFault.getNode());
// -- Incorrect
}
The indicated line should be changed to
soapFault.setFaultNode(xmlFault.getNode());
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4528) Performance issue with SOAPHANDLER'S HANDLEMESSAGE
[ https://issues.apache.org/jira/browse/AXIS2-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4528. --- Resolution: Fixed Performance issue with SOAPHANDLER'S HANDLEMESSAGE -- Key: AXIS2-4528 URL: https://issues.apache.org/jira/browse/AXIS2-4528 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Lori VanGulick Fix For: 1.6 Attachments: AXIS2-4528patch.diff Implementations of HandlerPostInvoker have no way to determine if the SOAP message has even been accessed by the handlers. Without this information they may needlessly expand the message causing performance degradation. Add a property jaxws.messageAccessed to the SOAPMessageContext when a SOAPMessageContext.getMessage() is performed. HandlerPostInvoker implementations can then check for the property. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4523) JAX-WS fails to unmarshal a service exception if the fault detail contains multiple detail entries.
JAX-WS fails to unmarshal a service exception if the fault detail contains multiple detail entries. --- Key: AXIS2-4523 URL: https://issues.apache.org/jira/browse/AXIS2-4523 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Background: When an inbound SOAP message contains a SOAP Fault, the JAX-WS engine examines the element inside of the Fault detail. This child element of the detail is called a detail entry in SAAJ. If the JAX-WS engine finds a matching service exception (aka application exception), the engine will use the contents of the detail entry to create a service exception. Problem: The vendor sending the message may add other detail entries to the detail element. For example the vendor may add an exception or stacktrace element that contains debug information about the location of the exception on the server. The presence of these extra detail entries caused the JAX-WS engine to incorrectly unmarshal the fault as a system exception (not a service exception). Solution: The solution is very simple. The code currently only attempts service exception unmarshalling if there is one detail entry. The code will be changed to attempt service exception unmarshalling if there are one or more detail entries. The first one will be used to do the service exception unmarshalling. I have a fix, and am testing it now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (AXIS2-4523) JAX-WS fails to unmarshal a service exception if the fault detail contains multiple detail entries.
[ https://issues.apache.org/jira/browse/AXIS2-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AXIS2-4523 started by Rich Scheuerle. JAX-WS fails to unmarshal a service exception if the fault detail contains multiple detail entries. --- Key: AXIS2-4523 URL: https://issues.apache.org/jira/browse/AXIS2-4523 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 24h Remaining Estimate: 24h Background: When an inbound SOAP message contains a SOAP Fault, the JAX-WS engine examines the element inside of the Fault detail. This child element of the detail is called a detail entry in SAAJ. If the JAX-WS engine finds a matching service exception (aka application exception), the engine will use the contents of the detail entry to create a service exception. Problem: The vendor sending the message may add other detail entries to the detail element. For example the vendor may add an exception or stacktrace element that contains debug information about the location of the exception on the server. The presence of these extra detail entries caused the JAX-WS engine to incorrectly unmarshal the fault as a system exception (not a service exception). Solution: The solution is very simple. The code currently only attempts service exception unmarshalling if there is one detail entry. The code will be changed to attempt service exception unmarshalling if there are one or more detail entries. The first one will be used to do the service exception unmarshalling. I have a fix, and am testing it now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4523) JAX-WS fails to unmarshal a service exception if the fault detail contains multiple detail entries.
[ https://issues.apache.org/jira/browse/AXIS2-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4523. --- Resolution: Fixed Resolved with 823318 JAX-WS fails to unmarshal a service exception if the fault detail contains multiple detail entries. --- Key: AXIS2-4523 URL: https://issues.apache.org/jira/browse/AXIS2-4523 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 24h Remaining Estimate: 24h Background: When an inbound SOAP message contains a SOAP Fault, the JAX-WS engine examines the element inside of the Fault detail. This child element of the detail is called a detail entry in SAAJ. If the JAX-WS engine finds a matching service exception (aka application exception), the engine will use the contents of the detail entry to create a service exception. Problem: The vendor sending the message may add other detail entries to the detail element. For example the vendor may add an exception or stacktrace element that contains debug information about the location of the exception on the server. The presence of these extra detail entries caused the JAX-WS engine to incorrectly unmarshal the fault as a system exception (not a service exception). Solution: The solution is very simple. The code currently only attempts service exception unmarshalling if there is one detail entry. The code will be changed to attempt service exception unmarshalling if there are one or more detail entries. The first one will be used to do the service exception unmarshalling. I have a fix, and am testing it now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4502) JAX-WS Needs a property to prevent lossy transformations before the application handlers are called
JAX-WS Needs a property to prevent lossy transformations before the application handlers are called --- Key: AXIS2-4502 URL: https://issues.apache.org/jira/browse/AXIS2-4502 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Problem: When a message is received, we want to quickly transform the message into the final form to reduce memory and increase speed. For example, in the JAX-WS server inbound case, the message payload is transformed into a JAXB object (which is what the JAXWS @WebService needs). However if the customer has installed a JAX-WS soap handler AND that handler inspects the message payload (the contents of the soap Body), then the JAXB object must be re-transformed into an SAAJ tree. This re-transformation is slow and is also lossy. For example, the namespaces in the original message and post-JAXB message may be different. Most SOAP Handlers don't touch the SOAP body. The JAX-WS specification does not provide a mechanism to allow SOAP Handlers to tell the engine their intent. So we want to expose an option that would allow a customer (developer or administrator) to preserve the original message. Solution: The Axis JAX-RPC web service engine had a property call high fidelity. The intention of the property was to preserve the original message. I am working on a fix to introduce a jaxws.payload.highFidelity property. The property will be available for programatic property (used by the developer )or as a configuration parameter (used by an administrator). ** * Context Property: * Name: jaxws.payload.highFidelity * Value: Boolean.TRUE or Boolean.FALSE * Default: null, which is interpreted as FALSEengine may set this to TRUE in some cases. * * Configuration Parameter * Name: jaxws.payload.highFidelity * Value: String or Boolean representing true or false * Default: null, which is interpreted as FALSE * * Description: * If the value is false, the jax-ws engine will transform the message in the most * performant manner. In some cases these transformations will cause the loss of some information. * For example, JAX-B transformations are lossy. * * If the value is true, the jax-ws engine will transform the message in the most loss-less manner. * In some cases this will result in slower performance. The message in such cases is high fidelity, * which means that it is a close replica of the original message. * * Customers should accept the default behavior (false), and only set the value to true if it is * necessary for a SOAP Handler or other code requires a high fidelity message. * * The engine will first examine the Context property. If not set, the value of the Configuration * property is used. */ public static final String JAXWS_PAYLOAD_HIGH_FIDELITY = jaxws.payload.highFidelity; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AXIS2-4502) JAX-WS Needs a property to prevent lossy transformations before the application handlers are called
[ https://issues.apache.org/jira/browse/AXIS2-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12758036#action_12758036 ] Rich Scheuerle commented on AXIS2-4502: --- Resolved by revision 817419 JAX-WS Needs a property to prevent lossy transformations before the application handlers are called --- Key: AXIS2-4502 URL: https://issues.apache.org/jira/browse/AXIS2-4502 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 24h Remaining Estimate: 24h Problem: When a message is received, we want to quickly transform the message into the final form to reduce memory and increase speed. For example, in the JAX-WS server inbound case, the message payload is transformed into a JAXB object (which is what the JAXWS @WebService needs). However if the customer has installed a JAX-WS soap handler AND that handler inspects the message payload (the contents of the soap Body), then the JAXB object must be re-transformed into an SAAJ tree. This re-transformation is slow and is also lossy. For example, the namespaces in the original message and post-JAXB message may be different. Most SOAP Handlers don't touch the SOAP body. The JAX-WS specification does not provide a mechanism to allow SOAP Handlers to tell the engine their intent. So we want to expose an option that would allow a customer (developer or administrator) to preserve the original message. Solution: The Axis JAX-RPC web service engine had a property call high fidelity. The intention of the property was to preserve the original message. I am working on a fix to introduce a jaxws.payload.highFidelity property. The property will be available for programatic property (used by the developer )or as a configuration parameter (used by an administrator). ** * Context Property: * Name: jaxws.payload.highFidelity * Value: Boolean.TRUE or Boolean.FALSE * Default: null, which is interpreted as FALSEengine may set this to TRUE in some cases. * * Configuration Parameter * Name: jaxws.payload.highFidelity * Value: String or Boolean representing true or false * Default: null, which is interpreted as FALSE * * Description: * If the value is false, the jax-ws engine will transform the message in the most * performant manner. In some cases these transformations will cause the loss of some information. * For example, JAX-B transformations are lossy. * * If the value is true, the jax-ws engine will transform the message in the most loss-less manner. * In some cases this will result in slower performance. The message in such cases is high fidelity, * which means that it is a close replica of the original message. * * Customers should accept the default behavior (false), and only set the value to true if it is * necessary for a SOAP Handler or other code requires a high fidelity message. * * The engine will first examine the Context property. If not set, the value of the Configuration * property is used. */ public static final String JAXWS_PAYLOAD_HIGH_FIDELITY = jaxws.payload.highFidelity; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4502) JAX-WS Needs a property to prevent lossy transformations before the application handlers are called
[ https://issues.apache.org/jira/browse/AXIS2-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4502. --- Resolution: Fixed JAX-WS Needs a property to prevent lossy transformations before the application handlers are called --- Key: AXIS2-4502 URL: https://issues.apache.org/jira/browse/AXIS2-4502 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 24h Remaining Estimate: 24h Problem: When a message is received, we want to quickly transform the message into the final form to reduce memory and increase speed. For example, in the JAX-WS server inbound case, the message payload is transformed into a JAXB object (which is what the JAXWS @WebService needs). However if the customer has installed a JAX-WS soap handler AND that handler inspects the message payload (the contents of the soap Body), then the JAXB object must be re-transformed into an SAAJ tree. This re-transformation is slow and is also lossy. For example, the namespaces in the original message and post-JAXB message may be different. Most SOAP Handlers don't touch the SOAP body. The JAX-WS specification does not provide a mechanism to allow SOAP Handlers to tell the engine their intent. So we want to expose an option that would allow a customer (developer or administrator) to preserve the original message. Solution: The Axis JAX-RPC web service engine had a property call high fidelity. The intention of the property was to preserve the original message. I am working on a fix to introduce a jaxws.payload.highFidelity property. The property will be available for programatic property (used by the developer )or as a configuration parameter (used by an administrator). ** * Context Property: * Name: jaxws.payload.highFidelity * Value: Boolean.TRUE or Boolean.FALSE * Default: null, which is interpreted as FALSEengine may set this to TRUE in some cases. * * Configuration Parameter * Name: jaxws.payload.highFidelity * Value: String or Boolean representing true or false * Default: null, which is interpreted as FALSE * * Description: * If the value is false, the jax-ws engine will transform the message in the most * performant manner. In some cases these transformations will cause the loss of some information. * For example, JAX-B transformations are lossy. * * If the value is true, the jax-ws engine will transform the message in the most loss-less manner. * In some cases this will result in slower performance. The message in such cases is high fidelity, * which means that it is a close replica of the original message. * * Customers should accept the default behavior (false), and only set the value to true if it is * necessary for a SOAP Handler or other code requires a high fidelity message. * * The engine will first examine the Context property. If not set, the value of the Configuration * property is used. */ public static final String JAXWS_PAYLOAD_HIGH_FIDELITY = jaxws.payload.highFidelity; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (AXIS2-4463) Unreachable code in JAXBAttachmentUnmarshaller
[
https://issues.apache.org/jira/browse/AXIS2-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on AXIS2-4463 started by Rich Scheuerle.
Unreachable code in JAXBAttachmentUnmarshaller
--
Key: AXIS2-4463
URL: https://issues.apache.org/jira/browse/AXIS2-4463
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: jaxws
Reporter: Andreas Veithen
Assignee: Rich Scheuerle
Priority: Minor
While reviewing some code, I noticed that
org.apache.axis2.datasource.jaxb.JAXBAttachmentUnmarshaller contains
unreachable code. There are two places where the following if statement is
used:
if (xmlStreamReader instanceof OMXMLStreamReader) {
...
}
xmlStreamReader is an attribute of JAXBAttachmentUnmarshaller, but this
attribute is never initialized and remains null (this is obviously a bug; see
code in the constructor). Since null instanceof X is always false, the code
inside the if statement is unreachable.
Since this code is related to XOP/MTOM processing, I'm wondering how it is
possible that MTOM actually works in JAX-WS (does it?). Also it would be
interesting to analyze why this issue doesn't trigger any test failure.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (AXIS2-4463) Unreachable code in JAXBAttachmentUnmarshaller
[
https://issues.apache.org/jira/browse/AXIS2-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12752603#action_12752603
]
Rich Scheuerle commented on AXIS2-4463:
---
I agree that the code is dead code.
The purpose of the JAXBAttachmentUnmarshaller is to access the DataHandler for
the MTOM attachment so that it can be handed to the JAXB unmarshaling engine.
The purpose of the dead code was to ensure that the underlying reader used
inlining (thus avoiding the JAXBAttachmentUnmarshaller work) in some cases. I
see that a code mistake was made, and the best solution right now is to remove
the dead code.
I am finishing my testing and then I will commit.
Unreachable code in JAXBAttachmentUnmarshaller
--
Key: AXIS2-4463
URL: https://issues.apache.org/jira/browse/AXIS2-4463
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: jaxws
Reporter: Andreas Veithen
Assignee: Rich Scheuerle
Priority: Minor
While reviewing some code, I noticed that
org.apache.axis2.datasource.jaxb.JAXBAttachmentUnmarshaller contains
unreachable code. There are two places where the following if statement is
used:
if (xmlStreamReader instanceof OMXMLStreamReader) {
...
}
xmlStreamReader is an attribute of JAXBAttachmentUnmarshaller, but this
attribute is never initialized and remains null (this is obviously a bug; see
code in the constructor). Since null instanceof X is always false, the code
inside the if statement is unreachable.
Since this code is related to XOP/MTOM processing, I'm wondering how it is
possible that MTOM actually works in JAX-WS (does it?). Also it would be
interesting to analyze why this issue doesn't trigger any test failure.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (AXIS2-3773) Dispatch Sync with Async Transport is not working
[ https://issues.apache.org/jira/browse/AXIS2-3773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle closed AXIS2-3773. - Resolution: Fixed Dispatch Sync with Async Transport is not working - Key: AXIS2-3773 URL: https://issues.apache.org/jira/browse/AXIS2-3773 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle The JAXWS Dispatch.invoke() (synchronous) api with an Async MEP is not being honored. A synchronous MEP is being used instead. This issue was discovered by Martin Adams (IBM). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (AXIS2-3341) Marshaling arrays and lists seems to be wrong
[ https://issues.apache.org/jira/browse/AXIS2-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AXIS2-3341 started by Rich Scheuerle. Marshaling arrays and lists seems to be wrong - Key: AXIS2-3341 URL: https://issues.apache.org/jira/browse/AXIS2-3341 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Affects Versions: 1.3, 1.2 Environment: JDK 1.5 and Geronimo 1.1 , also Websphere 6.1 Reporter: Boris Georgiev Assignee: Rich Scheuerle Attachments: jaxws-axis2.zip, return_messages.txt The problem seems to be about incorrect marshaling of arrays and lists. Looks like, for each element in the array is called the method toString(), then all of the array elements are separated by spaces and finally all the result is placed in a single xml element. As I see, according to the schema in the WSDL, every element of the array needs to be in its own element. Then, calling toString() may work for a simple type, it is completely meaningless for a complex types, as it is usually the string representation of the object's handle. I get the same result with or without response wrapper objects. I observe it for the return types, I have not tested it for arrays in the input paparameters. Can I use some other databinding mechanism, in order to avoid this and how? To demonstarate it, I have created a simple web service project. The service name is GenericService there are four methods, returning: array of string, array of a complex type, list of string and a list of a complex type. The attached file return_messages.txt contains the messages: as they are observed and as they need to be for arrays. For lists, the messages are the same. Te attached file jaxw-axis2.zip contains the sample geronimo/eclipse project, without the axis2 libraries. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (AXIS2-4459) JAX-WS implementation throws JAXBException for complextypes
[ https://issues.apache.org/jira/browse/AXIS2-4459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AXIS2-4459 started by Rich Scheuerle. JAX-WS implementation throws JAXBException for complextypes --- Key: AXIS2-4459 URL: https://issues.apache.org/jira/browse/AXIS2-4459 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Affects Versions: 1.5 Environment: Windows XP Service Pack 3. Java 1.6.0_13 Reporter: Brandon Richins Assignee: Rich Scheuerle Attachments: JaxWsExample.zip When calling an operation on a JAX-WS service that returns an array, Axis2 throws a JAXBException indicating that XYZ class is not known to this context. It seems able to marshall when returning a single element. But arrays don't seem to work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4463) Unreachable code in JAXBAttachmentUnmarshaller
[
https://issues.apache.org/jira/browse/AXIS2-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rich Scheuerle resolved AXIS2-4463.
---
Resolution: Fixed
Unreachable code in JAXBAttachmentUnmarshaller
--
Key: AXIS2-4463
URL: https://issues.apache.org/jira/browse/AXIS2-4463
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: jaxws
Reporter: Andreas Veithen
Assignee: Rich Scheuerle
Priority: Minor
While reviewing some code, I noticed that
org.apache.axis2.datasource.jaxb.JAXBAttachmentUnmarshaller contains
unreachable code. There are two places where the following if statement is
used:
if (xmlStreamReader instanceof OMXMLStreamReader) {
...
}
xmlStreamReader is an attribute of JAXBAttachmentUnmarshaller, but this
attribute is never initialized and remains null (this is obviously a bug; see
code in the constructor). Since null instanceof X is always false, the code
inside the if statement is unreachable.
Since this code is related to XOP/MTOM processing, I'm wondering how it is
possible that MTOM actually works in JAX-WS (does it?). Also it would be
interesting to analyze why this issue doesn't trigger any test failure.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4481) JAX-WS Marshaling is not optimized if xsi:type is requested
[ https://issues.apache.org/jira/browse/AXIS2-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4481. --- Resolution: Fixed JAX-WS Marshaling is not optimized if xsi:type is requested --- Key: AXIS2-4481 URL: https://issues.apache.org/jira/browse/AXIS2-4481 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Priority: Minor Original Estimate: 24h Remaining Estimate: 24h The JAX-WS engine uses the marshal methods provided by JAX-B. The JAX-B supports marshaling to an XMLStreamWriter or an OutputStream. In most cases, the JAX-WS runtime uses the latter (marshaling to OutputStream). This is accomplished by getting the target OutputStream from the XMLStreamWriter. However, there is one path where this optimization is not being used. This JIRA corrects this path -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4482) WebServiceContext contents persist after the JAX-WS call
WebServiceContext contents persist after the JAX-WS call Key: AXIS2-4482 URL: https://issues.apache.org/jira/browse/AXIS2-4482 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle The @WebServiceContext information is only applicable during the server invocation of the JAX-WS web service message. After the invocation, the resources (ie. soap message) held by the @WebServiceContext should be released so that it can be properly garbage collected. Failure to do this causes a memory leak. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4482) WebServiceContext contents persist after the JAX-WS call
[ https://issues.apache.org/jira/browse/AXIS2-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4482. --- Resolution: Fixed The fix and a verification test is provided in revision 809569. WebServiceContext contents persist after the JAX-WS call Key: AXIS2-4482 URL: https://issues.apache.org/jira/browse/AXIS2-4482 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle The @WebServiceContext information is only applicable during the server invocation of the JAX-WS web service message. After the invocation, the resources (ie. soap message) held by the @WebServiceContext should be released so that it can be properly garbage collected. Failure to do this causes a memory leak. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4481) JAX-WS Marshaling is not optimized if xsi:type is requested
JAX-WS Marshaling is not optimized if xsi:type is requested --- Key: AXIS2-4481 URL: https://issues.apache.org/jira/browse/AXIS2-4481 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Priority: Minor The JAX-WS engine uses the marshal methods provided by JAX-B. The JAX-B supports marshaling to an XMLStreamWriter or an OutputStream. In most cases, the JAX-WS runtime uses the latter (marshaling to OutputStream). This is accomplished by getting the target OutputStream from the XMLStreamWriter. However, there is one path where this optimization is not being used. This JIRA corrects this path -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4474) JAXWS Provider does not respect FaultTo when a SOAPFault is returned
JAXWS Provider does not respect FaultTo when a SOAPFault is returned Key: AXIS2-4474 URL: https://issues.apache.org/jira/browse/AXIS2-4474 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle If a JAXWS web service implementation or Provider throws and exception, the jaxws engine creates an appropriate SOAP Fault. The SOAP Fault is returned to the caller or sent to the FaultTo address. However a JAXWS mode=Message Provider may return an object representing a SOAP Fault (i.e. no exception is thrown). In such cases, the JAX-WS is failing to recognize the SOAP Fault and the the subsequent Faul is returned to the caller (instead of being directed to a FaultTo address). The error is in the ProviderDispatcher. A small code change is needed to analyze the returned object and create a Fault message context if necessary. I am testing this small change and will have it done later today. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4474) JAXWS Provider does not respect FaultTo when a SOAPFault is returned
[ https://issues.apache.org/jira/browse/AXIS2-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4474. --- Resolution: Fixed JAXWS Provider does not respect FaultTo when a SOAPFault is returned Key: AXIS2-4474 URL: https://issues.apache.org/jira/browse/AXIS2-4474 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 24h Remaining Estimate: 24h If a JAXWS web service implementation or Provider throws and exception, the jaxws engine creates an appropriate SOAP Fault. The SOAP Fault is returned to the caller or sent to the FaultTo address. However a JAXWS mode=Message Provider may return an object representing a SOAP Fault (i.e. no exception is thrown). In such cases, the JAX-WS is failing to recognize the SOAP Fault and the the subsequent Faul is returned to the caller (instead of being directed to a FaultTo address). The error is in the ProviderDispatcher. A small code change is needed to analyze the returned object and create a Fault message context if necessary. I am testing this small change and will have it done later today. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4396) JAX-WS:@XmlSeeAlso annotations are not being processed on an SEI, which causes an application failure
JAX-WS:@XmlSeeAlso annotations are not being processed on an SEI, which causes an application failure - Key: AXIS2-4396 URL: https://issues.apache.org/jira/browse/AXIS2-4396 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle A JAX-WS Service Endpoint Interface (SEI) may contain @XmlSeeAlso annotations. These annotations inform the runtime about the existence of specific classes that are not directly referencedby the web service. The JAX-WS runtime uses the annotations to determine how to marshal or unmarshal data objects. Due to a problem in the JAX-WS runtime, these annotations are not being processed correctly. This may cause the JAX-WS runtime to unmarshal the data objects as Data Object Model (DOM) Elements instead of JAXB objects. When the web service application attempts to process the data object an error may occur indicating that the DOM Element is incompatible with a user class. Example: javax.xml.ws.soap.SOAPFaultException: org.apache.xerces.dom.ElementNSImpl incompatible with some_class org.apache.axis2.jaxws.marshaller.impl.alt.MethodMarshallerUtils ... The root of the problem is that the SEI is not being correctly located for the scenario where the web service implementation does not implment the SEI but instead uses the @WebService endpointInterface parameter to designate the SEI. The solution is to locate and load the SEI for this scenario, and process the @XmlSeeAlso annotations on the SEI. I am completing my testing on the solution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4397) JAX-WS: The port-name-pattern regular expression processing is incorrect
JAX-WS: The port-name-pattern regular expression processing is incorrect Key: AXIS2-4397 URL: https://issues.apache.org/jira/browse/AXIS2-4397 Project: Axis 2.0 (Axis2) Issue Type: Bug Reporter: Rich Scheuerle Assignee: Rich Scheuerle Scenario: A customer can supply JAX-WS application handlers with their application. The customer indicates which handlers are run by providing an xml file describing the handler chain. The following example xml file indicates that test.MyHandler handler should be run for all ports (*). jws:handler-chains xmlns:jws=http://java.sun.com/xml/ns/javaee; jws:handler-chain name=MyHandlerChain jws:protocol-bindingssome value/jws:protocol-bindings jws:port-name-pattern*/jws:port-name-pattern jws:handler jws:handler-classtest.MyHandler/jws:handler-class /jws:handler /jws-handler-chain /jws:handler-chains Due to an error introduced by a prior fix, this scenario will not succeed. The test.MyHandler handler will not run, and no errors are reported by the JAX-WS engine. This failure is limited to the case where the customer uses a single wildcard (*) in the jws:port-name-pattern or jws:service-name-pattern. Solution: The JAX-WS runtime code that performs the regular expression evaluation for the jws:port-name-pattern and jws:service-name-pattern elements is incorrect. I am working on a fix that will correct the algorithm. I will also provide unit tests to verify the behavior. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4395) JAX-WS: Consistent code across the invoke apis
[ https://issues.apache.org/jira/browse/AXIS2-4395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4395. --- Resolution: Fixed Committed Revision:786046 JAX-WS: Consistent code across the invoke apis -- Key: AXIS2-4395 URL: https://issues.apache.org/jira/browse/AXIS2-4395 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 2h Remaining Estimate: 2h Problem: There are five different client invoke entry points into the web service engine. Four are in BaseDispatch: - synchronous invoke - invokeOneWay - invokeAsync (Future) - invokeAsync (Callback) And one in JAXWSProxyhanderl -invokeSEIMethod There have been several bug fixes/improvements over the past year where developers have added code to one or more of these methods and neglected the same change in the other methods. The most recent example is some session managrment (changes). Solution: Scrub the code to look for any other obvious mistakes. Add comments to assist developers when changing the code. Add debug statements as necessary. Next Actions: Paul Mariduena has completed this work in his sandbox. I am working on committing the code to Apache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4396) JAX-WS:@XmlSeeAlso annotations are not being processed on an SEI, which causes an application failure
[ https://issues.apache.org/jira/browse/AXIS2-4396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4396. --- Resolution: Fixed Committed Revision: 786049 JAX-WS:@XmlSeeAlso annotations are not being processed on an SEI, which causes an application failure - Key: AXIS2-4396 URL: https://issues.apache.org/jira/browse/AXIS2-4396 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 2h Remaining Estimate: 2h A JAX-WS Service Endpoint Interface (SEI) may contain @XmlSeeAlso annotations. These annotations inform the runtime about the existence of specific classes that are not directly referencedby the web service. The JAX-WS runtime uses the annotations to determine how to marshal or unmarshal data objects. Due to a problem in the JAX-WS runtime, these annotations are not being processed correctly. This may cause the JAX-WS runtime to unmarshal the data objects as Data Object Model (DOM) Elements instead of JAXB objects. When the web service application attempts to process the data object an error may occur indicating that the DOM Element is incompatible with a user class. Example: javax.xml.ws.soap.SOAPFaultException: org.apache.xerces.dom.ElementNSImpl incompatible with some_class org.apache.axis2.jaxws.marshaller.impl.alt.MethodMarshallerUtils ... The root of the problem is that the SEI is not being correctly located for the scenario where the web service implementation does not implment the SEI but instead uses the @WebService endpointInterface parameter to designate the SEI. The solution is to locate and load the SEI for this scenario, and process the @XmlSeeAlso annotations on the SEI. I am completing my testing on the solution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4397) JAX-WS: The port-name-pattern regular expression processing is incorrect
[ https://issues.apache.org/jira/browse/AXIS2-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4397. --- Resolution: Fixed Committed Revision:786055 JAX-WS: The port-name-pattern regular expression processing is incorrect Key: AXIS2-4397 URL: https://issues.apache.org/jira/browse/AXIS2-4397 Project: Axis 2.0 (Axis2) Issue Type: Bug Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 2h Remaining Estimate: 2h Scenario: A customer can supply JAX-WS application handlers with their application. The customer indicates which handlers are run by providing an xml file describing the handler chain. The following example xml file indicates that test.MyHandler handler should be run for all ports (*). jws:handler-chains xmlns:jws=http://java.sun.com/xml/ns/javaee; jws:handler-chain name=MyHandlerChain jws:protocol-bindingssome value/jws:protocol-bindings jws:port-name-pattern*/jws:port-name-pattern jws:handler jws:handler-classtest.MyHandler/jws:handler-class /jws:handler /jws-handler-chain /jws:handler-chains Due to an error introduced by a prior fix, this scenario will not succeed. The test.MyHandler handler will not run, and no errors are reported by the JAX-WS engine. This failure is limited to the case where the customer uses a single wildcard (*) in the jws:port-name-pattern or jws:service-name-pattern. Solution: The JAX-WS runtime code that performs the regular expression evaluation for the jws:port-name-pattern and jws:service-name-pattern elements is incorrect. I am working on a fix that will correct the algorithm. I will also provide unit tests to verify the behavior. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (AXIS2-4391) JAX-WS: Two Services Cannot Have the Same Name Error
[ https://issues.apache.org/jira/browse/AXIS2-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle reopened AXIS2-4391: --- Jeff Barrett has another fix for a slightly different scneario, but the same symptom. His fix will prevent the different threads from using the same name. I am working on the final testing of the fix. JAX-WS: Two Services Cannot Have the Same Name Error Key: AXIS2-4391 URL: https://issues.apache.org/jira/browse/AXIS2-4391 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Fix For: 1.6 Original Estimate: 1h Remaining Estimate: 1h If a JAX-WS client runs over a long period of time, making many calls to javax.xml.ws.Service.getPort(), an error likethis might occur: org.apache.axis2.AxisFault: Two services cannot have same name. A service with the HelloWorldWebService.HelloWorldPort1517705846 name already exists in the system. The error is due to multiple threads simultaneously calling an internal method in the JAX-WS engine. The solution is to change the method to be synchronized so that only one thread at a time can call it. The solution was coded by Wendy Raschke, and Rich Scheuerle will be committing the fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4391) JAX-WS: Two Services Cannot Have the Same Name Error
[ https://issues.apache.org/jira/browse/AXIS2-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4391. --- Resolution: Fixed Second Revision:786126 JAX-WS: Two Services Cannot Have the Same Name Error Key: AXIS2-4391 URL: https://issues.apache.org/jira/browse/AXIS2-4391 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Fix For: 1.6 Original Estimate: 1h Remaining Estimate: 1h If a JAX-WS client runs over a long period of time, making many calls to javax.xml.ws.Service.getPort(), an error likethis might occur: org.apache.axis2.AxisFault: Two services cannot have same name. A service with the HelloWorldWebService.HelloWorldPort1517705846 name already exists in the system. The error is due to multiple threads simultaneously calling an internal method in the JAX-WS engine. The solution is to change the method to be synchronized so that only one thread at a time can call it. The solution was coded by Wendy Raschke, and Rich Scheuerle will be committing the fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4388) JAX-WS: ClassNotFoundException for JAX-WS parameter
JAX-WS: ClassNotFoundException for JAX-WS parameter --- Key: AXIS2-4388 URL: https://issues.apache.org/jira/browse/AXIS2-4388 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle If a JAX-WS web method contains a parameter that is an array,the following ClassNotFoundException may occur: org.apache.axis2.jaxws.description.builder.DescriptionBuilderUtils forName Exception thrown from AccessController: java.lang.ClassNotFoundException:[com..Class ... org.apache.axis2.jaxws.description.builder.DescriptionBuilderUtils.loadClassFromComposite(DescriptionBuilderUtils.java:325) ... Solution: The problem is in the DescriptionBuilderUtils.reparseIfArray method. If the input representation of the class is not in a correct binary form, then it is corrected. For example, sometimes a [my.Foo is input instead of the required [Lmy.Foo; The new code will now correctly add the L and ; Kudos to Paul Mariduena for his work with the design and testing of this fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4264) Empty action not applied in CommonsHTTPTransportSender
[ https://issues.apache.org/jira/browse/AXIS2-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4264. --- Resolution: Fixed Committed revision 785637 Empty action not applied in CommonsHTTPTransportSender -- Key: AXIS2-4264 URL: https://issues.apache.org/jira/browse/AXIS2-4264 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: transports Affects Versions: 1.5, 1.4.1, 1.4, 1.3 Reporter: Alexis Midon Attachments: AXIS2-4264.patch.txt Hello there, I'm invoking a service using a ServiceClient, the wsdl operation declares an empty soapAction. However the soapActiuon actually sent is urn:anonOutInOp which the server refuses. This action is the action the anonymous operation urn:anonOutInOp and is set by the ServiceClient. Later when CommonsHTTPTransportSender#findSOAPAction [1] is invoked, if the action of the MessageContext is null or empty, the operation action is used. The empty case seems like a bug, because this is the action set in the wsdl and it is not applied. This opinion is strengthened by the fact that other senders do not have this behavior. The right behavior would be: if null ; use the operation action as a default if empty ; send an empty soapAction Could you confirm please? Alexis [1] http://is.gd/m0Mt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4388) JAX-WS: ClassNotFoundException for JAX-WS parameter
[ https://issues.apache.org/jira/browse/AXIS2-4388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4388. --- Resolution: Fixed Committed Revision: 785647 JAX-WS: ClassNotFoundException for JAX-WS parameter --- Key: AXIS2-4388 URL: https://issues.apache.org/jira/browse/AXIS2-4388 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 24h Remaining Estimate: 24h If a JAX-WS web method contains a parameter that is an array,the following ClassNotFoundException may occur: org.apache.axis2.jaxws.description.builder.DescriptionBuilderUtils forName Exception thrown from AccessController: java.lang.ClassNotFoundException:[com..Class ... org.apache.axis2.jaxws.description.builder.DescriptionBuilderUtils.loadClassFromComposite(DescriptionBuilderUtils.java:325) ... Solution: The problem is in the DescriptionBuilderUtils.reparseIfArray method. If the input representation of the class is not in a correct binary form, then it is corrected. For example, sometimes a [my.Foo is input instead of the required [Lmy.Foo; The new code will now correctly add the L and ; Kudos to Paul Mariduena for his work with the design and testing of this fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4390) JAXWS: Java2Security Violation Fixes
JAXWS: Java2Security Violation Fixes Key: AXIS2-4390 URL: https://issues.apache.org/jira/browse/AXIS2-4390 Project: Axis 2.0 (Axis2) Issue Type: Bug Reporter: Rich Scheuerle Assignee: Rich Scheuerle Two Java2Security violations were detected during IBM testing. The first violation occurs in org/apache/axis2/jaxws/description/impl/DescriptionUtils.openHandlerConfig stream. The non-priv code causes the handler configuration access to fail. This can cause user applications to fail. The second violation occurs in the JAX-WS JavaBeanDispatcher while getting the Context ClassLoader. Solution; I am correcting the code to add the appropriate ammount of doPriv stanzas. Kudos to Paul Mariduena for his cooperation on the design and testing of these fixes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4390) JAXWS: Java2Security Violation Fixes
[ https://issues.apache.org/jira/browse/AXIS2-4390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4390. --- Resolution: Fixed Committed revision 785720 JAXWS: Java2Security Violation Fixes Key: AXIS2-4390 URL: https://issues.apache.org/jira/browse/AXIS2-4390 Project: Axis 2.0 (Axis2) Issue Type: Bug Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 24h Remaining Estimate: 24h Two Java2Security violations were detected during IBM testing. The first violation occurs in org/apache/axis2/jaxws/description/impl/DescriptionUtils.openHandlerConfig stream. The non-priv code causes the handler configuration access to fail. This can cause user applications to fail. The second violation occurs in the JAX-WS JavaBeanDispatcher while getting the Context ClassLoader. Solution; I am correcting the code to add the appropriate ammount of doPriv stanzas. Kudos to Paul Mariduena for his cooperation on the design and testing of these fixes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4391) JAX-WS: Two Services Cannot Have the Same Name Error
JAX-WS: Two Services Cannot Have the Same Name Error Key: AXIS2-4391 URL: https://issues.apache.org/jira/browse/AXIS2-4391 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle If a JAX-WS client runs over a long period of time, making many calls to javax.xml.ws.Service.getPort(), an error likethis might occur: org.apache.axis2.AxisFault: Two services cannot have same name. A service with the HelloWorldWebService.HelloWorldPort1517705846 name already exists in the system. The error is due to multiple threads simultaneously calling an internal method in the JAX-WS engine. The solution is to change the method to be synchronized so that only one thread at a time can call it. The solution was coded by Wendy Raschke, and Rich Scheuerle will be committing the fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4391) JAX-WS: Two Services Cannot Have the Same Name Error
[ https://issues.apache.org/jira/browse/AXIS2-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4391. --- Resolution: Fixed Committed 785748 JAX-WS: Two Services Cannot Have the Same Name Error Key: AXIS2-4391 URL: https://issues.apache.org/jira/browse/AXIS2-4391 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 1h Remaining Estimate: 1h If a JAX-WS client runs over a long period of time, making many calls to javax.xml.ws.Service.getPort(), an error likethis might occur: org.apache.axis2.AxisFault: Two services cannot have same name. A service with the HelloWorldWebService.HelloWorldPort1517705846 name already exists in the system. The error is due to multiple threads simultaneously calling an internal method in the JAX-WS engine. The solution is to change the method to be synchronized so that only one thread at a time can call it. The solution was coded by Wendy Raschke, and Rich Scheuerle will be committing the fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4392) JAXWS: DispatchSOAPMessage and ProviderSOAPMessage don't honor SOAPAction MIMEHeader
JAXWS: DispatchSOAPMessage and ProviderSOAPMessage don't honor SOAPAction MIMEHeader Key: AXIS2-4392 URL: https://issues.apache.org/jira/browse/AXIS2-4392 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Scenario: A customer can use DispatchSOAPMessage or ProviderSOAPMessage apis to interact with a web service at the SAAJ SOAPMessage level. The SAAJ SOAPMessage api allows the customer to set the transport MIME Headers for the message. If a customer sets the SOAPAction header using SAAJ, it is not being honored. Solution: The solution is to copy the value of the SOAPAction header onto the Axis2 MessageContext. This solution is provided by Wendy Rashke. I am working with Wendy to commit the code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4392) JAXWS: DispatchSOAPMessage and ProviderSOAPMessage don't honor SOAPAction MIMEHeader
[ https://issues.apache.org/jira/browse/AXIS2-4392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4392. --- Resolution: Fixed Committed 785750 JAXWS: DispatchSOAPMessage and ProviderSOAPMessage don't honor SOAPAction MIMEHeader Key: AXIS2-4392 URL: https://issues.apache.org/jira/browse/AXIS2-4392 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 1h Remaining Estimate: 1h Scenario: A customer can use DispatchSOAPMessage or ProviderSOAPMessage apis to interact with a web service at the SAAJ SOAPMessage level. The SAAJ SOAPMessage api allows the customer to set the transport MIME Headers for the message. If a customer sets the SOAPAction header using SAAJ, it is not being honored. Solution: The solution is to copy the value of the SOAPAction header onto the Axis2 MessageContext. This solution is provided by Wendy Rashke. I am working with Wendy to commit the code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4393) JAXWS: If JAXB classes are not packaged with the JAXWS Application, the service may fail
JAXWS: If JAXB classes are not packaged with the JAXWS Application, the service may fail Key: AXIS2-4393 URL: https://issues.apache.org/jira/browse/AXIS2-4393 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Under normal circumstances, a JAX-WS web service application uses JAXB classes to represent the method and parameter data for document/literal operations. However, very simple web service applications may not contain JAXB classes. For example, a JAX-WS document/literal method that only has Java primitive parameters might be developed without JAXB classes. Another example is a benchmark application. A benchmark application that is developed by other vendors and might not contain JAXB classes If JAXB classes are not present, the JAX-WS runtime will perform correctly in most cases. When the following conditions are met, the JAX-WS runtime will fail with a NullPointerException error: * The JAX-WS web service has a style/use defined as document/literal. * The JAX-WS web service is defined as or defaults to the wrapped mapping. * The JAX-WS web service does not contain JAXB classes. * The JAX-WS web service receives a message that indicates that one of the parameters to the JAX-WS operation is null or missing. The NullPointerException will occur when the JAX-WS runtime receives the incoming message. Here is an example error: javax.xml.ws.WebServiceException: java.lang.NullPointerException at org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:175) at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:70) at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:128) at org.apache.axis2.jaxws.marshaller.impl.alt.DocLitWrappedMinimalMethodMarshaller.demarshalRequest(DocLitWrappedMinimalMethodMarshaller.java:221) Solution: In the scenario described above, the JAX-WS unmarshalling engine uses an algorithm called document literal wrapped minimal unmarshalling. The algorithm currently does not have the ability to recognize missing elements/parameters. The algorithm will be upgraded to handle this scenario. In addition, other clases in the JAX-WS runtime were changed to provide the necessary information to detect the missing parameters. This solution has been tested and will be committed shortly. All of the code is in the JAXWS runtime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4393) JAXWS: If JAXB classes are not packaged with the JAXWS Application, the service may fail
[ https://issues.apache.org/jira/browse/AXIS2-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4393. --- Resolution: Fixed Committed 785755 JAXWS: If JAXB classes are not packaged with the JAXWS Application, the service may fail Key: AXIS2-4393 URL: https://issues.apache.org/jira/browse/AXIS2-4393 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 2h Remaining Estimate: 2h Under normal circumstances, a JAX-WS web service application uses JAXB classes to represent the method and parameter data for document/literal operations. However, very simple web service applications may not contain JAXB classes. For example, a JAX-WS document/literal method that only has Java primitive parameters might be developed without JAXB classes. Another example is a benchmark application. A benchmark application that is developed by other vendors and might not contain JAXB classes If JAXB classes are not present, the JAX-WS runtime will perform correctly in most cases. When the following conditions are met, the JAX-WS runtime will fail with a NullPointerException error: * The JAX-WS web service has a style/use defined as document/literal. * The JAX-WS web service is defined as or defaults to the wrapped mapping. * The JAX-WS web service does not contain JAXB classes. * The JAX-WS web service receives a message that indicates that one of the parameters to the JAX-WS operation is null or missing. The NullPointerException will occur when the JAX-WS runtime receives the incoming message. Here is an example error: javax.xml.ws.WebServiceException: java.lang.NullPointerException at org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:175) at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:70) at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:128) at org.apache.axis2.jaxws.marshaller.impl.alt.DocLitWrappedMinimalMethodMarshaller.demarshalRequest(DocLitWrappedMinimalMethodMarshaller.java:221) Solution: In the scenario described above, the JAX-WS unmarshalling engine uses an algorithm called document literal wrapped minimal unmarshalling. The algorithm currently does not have the ability to recognize missing elements/parameters. The algorithm will be upgraded to handle this scenario. In addition, other clases in the JAX-WS runtime were changed to provide the necessary information to detect the missing parameters. This solution has been tested and will be committed shortly. All of the code is in the JAXWS runtime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4039) JAXWS: Store the exception thrown from a web method implementation in a property so that it can be queried by an outbound jaxws handler
JAXWS: Store the exception thrown from a web method implementation in a property so that it can be queried by an outbound jaxws handler --- Key: AXIS2-4039 URL: https://issues.apache.org/jira/browse/AXIS2-4039 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Scenario: A JAXWS webservice on the server throws an exception (checked or unchecked). The JAXWS engine converts the exception into a message containing a SOAP Fault. An outbound JAXWS application handler is installed. In the handleFault method, the customer wants to do some work related to the exception. For example, the customer may want to log exception information in a database. Problem: The conversion of the Exception - SOAP Fault is lossy. Some of the information about the Exception is lost. For example, the stack trace of the exception is not captured (and should not be captured) in the SOAP Fault. Other java information is also lost. Solution: Store the Exception on a new property. The outbound JAXWS application handler can then access the exception directly to query java specific information. Next Step: I have coded the solution and verification tests. The changes are minimal and I will be committing the changes later today. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-4039) JAXWS: Store the exception thrown from a web method implementation in a property so that it can be queried by an outbound jaxws handler
[ https://issues.apache.org/jira/browse/AXIS2-4039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4039. --- Resolution: Fixed JAXWS: Store the exception thrown from a web method implementation in a property so that it can be queried by an outbound jaxws handler --- Key: AXIS2-4039 URL: https://issues.apache.org/jira/browse/AXIS2-4039 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 24h Remaining Estimate: 24h Scenario: A JAXWS webservice on the server throws an exception (checked or unchecked). The JAXWS engine converts the exception into a message containing a SOAP Fault. An outbound JAXWS application handler is installed. In the handleFault method, the customer wants to do some work related to the exception. For example, the customer may want to log exception information in a database. Problem: The conversion of the Exception - SOAP Fault is lossy. Some of the information about the Exception is lost. For example, the stack trace of the exception is not captured (and should not be captured) in the SOAP Fault. Other java information is also lost. Solution: Store the Exception on a new property. The outbound JAXWS application handler can then access the exception directly to query java specific information. Next Step: I have coded the solution and verification tests. The changes are minimal and I will be committing the changes later today. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-3969) JAXWS end-to-end test clean-up
[ https://issues.apache.org/jira/browse/AXIS2-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-3969. --- Resolution: Fixed Thanks Samuel for the hard work resolving these duplicate classes. JAXWS end-to-end test clean-up --- Key: AXIS2-3969 URL: https://issues.apache.org/jira/browse/AXIS2-3969 Project: Axis 2.0 (Axis2) Issue Type: Test Components: jaxws Environment: windows Reporter: Samuel Isokpunwu Assignee: Rich Scheuerle Attachments: patch1.txt Class already define compilation errors in jaxws-integration and metadata packages. The duplications of test artifacts classes with identical package names across these packages are causing compilation errors when deployed into eclipse IDE. Adjusted some of the test package structure of jaxws-integration and metadata test package to resolve these errors. Also updated pom.xml of jaxws-integration package to reflect some of this package updates. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2-3969) JAXWS end-to-end test clean-up
[ https://issues.apache.org/jira/browse/AXIS2-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle reassigned AXIS2-3969: - Assignee: Rich Scheuerle JAXWS end-to-end test clean-up --- Key: AXIS2-3969 URL: https://issues.apache.org/jira/browse/AXIS2-3969 Project: Axis 2.0 (Axis2) Issue Type: Test Components: jaxws Environment: windows Reporter: Samuel Isokpunwu Assignee: Rich Scheuerle Attachments: patch1.txt Class already define compilation errors in jaxws-integration and metadata packages. The duplications of test artifacts classes with identical package names across these packages are causing compilation errors when deployed into eclipse IDE. Adjusted some of the test package structure of jaxws-integration and metadata test package to resolve these errors. Also updated pom.xml of jaxws-integration package to reflect some of this package updates. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-3969) JAXWS end-to-end test clean-up
[ https://issues.apache.org/jira/browse/AXIS2-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12621260#action_12621260 ] Rich Scheuerle commented on AXIS2-3969: --- Samuel, The jaxws tests are simple unit tests (no client/server tests) The metadata tests are simple unit tests for the metadata processing (no client/server tests) The jaxws-integration tests are the client/server tests. --- I see that you renamed the following packages in the jaxws-integration tests: org.apache.axis2.jaxws.provider -- org.apache.axis2.jaxws.iprovider I suggest you take a different approach. Instead of renaming the package in the complicated jaxws-integration module, please change the packages in the much less complicated jaxws module. JAXWS end-to-end test clean-up --- Key: AXIS2-3969 URL: https://issues.apache.org/jira/browse/AXIS2-3969 Project: Axis 2.0 (Axis2) Issue Type: Test Components: jaxws Environment: windows Reporter: Samuel Isokpunwu Assignee: Rich Scheuerle Attachments: patch1.txt Class already define compilation errors in jaxws-integration and metadata packages. The duplications of test artifacts classes with identical package names across these packages are causing compilation errors when deployed into eclipse IDE. Adjusted some of the test package structure of jaxws-integration and metadata test package to resolve these errors. Also updated pom.xml of jaxws-integration package to reflect some of this package updates. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-3963) Null DataHandler objects as MIME attachments
[ https://issues.apache.org/jira/browse/AXIS2-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12620622#action_12620622 ] Rich Scheuerle commented on AXIS2-3963: --- I am running tests on the patch. I will commit by the end of the day. Null DataHandler objects as MIME attachments Key: AXIS2-3963 URL: https://issues.apache.org/jira/browse/AXIS2-3963 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: jaxws Environment: windows Reporter: Samuel Isokpunwu Assignee: Rich Scheuerle Attachments: patch3.txt Using SWA- raw MIME attachments, it is desireable to be able specify a null DataHandler object as a method parameter when there is no attachment to be returned. (For example, in a document retrieval service when the document image is not found).Both client and server threw NPE's when this happened. This change allows this to work. The resulting soap message message is a mime type message with only one part, the soap envelope. This is allowable per WS-I.Attachment Profile 1.0 clause R2917. Code description and implementation was originally done by Bruce Tiffany/Austin/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-3963) Null DataHandler objects as MIME attachments
[ https://issues.apache.org/jira/browse/AXIS2-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-3963. --- Resolution: Fixed Committed 683622 Null DataHandler objects as MIME attachments Key: AXIS2-3963 URL: https://issues.apache.org/jira/browse/AXIS2-3963 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: jaxws Environment: windows Reporter: Samuel Isokpunwu Assignee: Rich Scheuerle Attachments: patch3.txt Using SWA- raw MIME attachments, it is desireable to be able specify a null DataHandler object as a method parameter when there is no attachment to be returned. (For example, in a document retrieval service when the document image is not found).Both client and server threw NPE's when this happened. This change allows this to work. The resulting soap message message is a mime type message with only one part, the soap envelope. This is allowable per WS-I.Attachment Profile 1.0 clause R2917. Code description and implementation was originally done by Bruce Tiffany/Austin/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2-3963) Null DataHandler objects as MIME attachments
[ https://issues.apache.org/jira/browse/AXIS2-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle reassigned AXIS2-3963: - Assignee: Rich Scheuerle Null DataHandler objects as MIME attachments Key: AXIS2-3963 URL: https://issues.apache.org/jira/browse/AXIS2-3963 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: jaxws Environment: windows Reporter: Samuel Isokpunwu Assignee: Rich Scheuerle Attachments: patch1.txt Using SWA- raw MIME attachments, it is desireable to be able specify a null DataHandler object as a method parameter when there is no attachment to be returned. (For example, in a document retrieval service when the document image is not found).Both client and server threw NPE's when this happened. This change allows this to work. The resulting soap message message is a mime type message with only one part, the soap envelope. This is allowable per WS-I.Attachment Profile 1.0 clause R2917. Code description and implementation was originally done by Bruce Tiffany/Austin/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Work started: (AXIS2-3963) Null DataHandler objects as MIME attachments
[ https://issues.apache.org/jira/browse/AXIS2-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AXIS2-3963 started by Rich Scheuerle. Null DataHandler objects as MIME attachments Key: AXIS2-3963 URL: https://issues.apache.org/jira/browse/AXIS2-3963 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: jaxws Environment: windows Reporter: Samuel Isokpunwu Assignee: Rich Scheuerle Attachments: patch1.txt Using SWA- raw MIME attachments, it is desireable to be able specify a null DataHandler object as a method parameter when there is no attachment to be returned. (For example, in a document retrieval service when the document image is not found).Both client and server threw NPE's when this happened. This change allows this to work. The resulting soap message message is a mime type message with only one part, the soap envelope. This is allowable per WS-I.Attachment Profile 1.0 clause R2917. Code description and implementation was originally done by Bruce Tiffany/Austin/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-3963) Null DataHandler objects as MIME attachments
[ https://issues.apache.org/jira/browse/AXIS2-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12620274#action_12620274 ] Rich Scheuerle commented on AXIS2-3963: --- I have some questions about the patch. I am working with Samuel on a possible modification to the patch. Null DataHandler objects as MIME attachments Key: AXIS2-3963 URL: https://issues.apache.org/jira/browse/AXIS2-3963 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: jaxws Environment: windows Reporter: Samuel Isokpunwu Assignee: Rich Scheuerle Attachments: patch1.txt Using SWA- raw MIME attachments, it is desireable to be able specify a null DataHandler object as a method parameter when there is no attachment to be returned. (For example, in a document retrieval service when the document image is not found).Both client and server threw NPE's when this happened. This change allows this to work. The resulting soap message message is a mime type message with only one part, the soap envelope. This is allowable per WS-I.Attachment Profile 1.0 clause R2917. Code description and implementation was originally done by Bruce Tiffany/Austin/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-3965) JAXWS: Parser is not closed
JAXWS: Parser is not closed
---
Key: AXIS2-3965
URL: https://issues.apache.org/jira/browse/AXIS2-3965
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: jaxws
Reporter: Rich Scheuerle
Assignee: Rich Scheuerle
History:
Pull parsing requires that the last consumer closes the parser. We have had a
number of defects related to failures in closing the parser. This leads to
open resources and memory leakage.
Problem:
Sandy Kao has provided a fix for yet another scenario where the parser is not
being closed.
The patch is to the MessageImpl code in JAXWS:
ByteArrayOutputStream outStream = new ByteArrayOutputStream();
element.serialize(outStream);
+ // In some cases (usually inbound) the builder will not be closed
after
+ // serialization. In that case it should be closed manually.
+ if (element.getBuilder() != null
!element.getBuilder().isCompleted()) {
+element.close(false);
+ }
byte[] bytes = outStream.toByteArray();
I have tested and will commit the patch soon.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-3965) JAXWS: Parser is not closed
[
https://issues.apache.org/jira/browse/AXIS2-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rich Scheuerle resolved AXIS2-3965.
---
Resolution: Fixed
683353
JAXWS: Parser is not closed
---
Key: AXIS2-3965
URL: https://issues.apache.org/jira/browse/AXIS2-3965
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: jaxws
Reporter: Rich Scheuerle
Assignee: Rich Scheuerle
Original Estimate: 0.08h
Remaining Estimate: 0.08h
History:
Pull parsing requires that the last consumer closes the parser. We have had
a number of defects related to failures in closing the parser. This leads to
open resources and memory leakage.
Problem:
Sandy Kao has provided a fix for yet another scenario where the parser is not
being closed.
The patch is to the MessageImpl code in JAXWS:
ByteArrayOutputStream outStream = new ByteArrayOutputStream();
element.serialize(outStream);
+ // In some cases (usually inbound) the builder will not be
closed after
+ // serialization. In that case it should be closed manually.
+ if (element.getBuilder() != null
!element.getBuilder().isCompleted()) {
+element.close(false);
+ }
byte[] bytes = outStream.toByteArray();
I have tested and will commit the patch soon.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-3966) JAX-WS: Client engine should detach input stream after use
JAX-WS: Client engine should detach input stream after use -- Key: AXIS2-3966 URL: https://issues.apache.org/jira/browse/AXIS2-3966 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Background: The JAX-WS client engine (dispatch/proxy/asyncResponse) is ultimately responsible for creating business objects (or exception) for the client call. After that point, the unmarshalling is complete and the input stream (from the transport layer) is no longer needed. Problem: In some situations, the input stream is not closed. Since the input stream comes from the transport layer, this could result in resources not being freed. (For example connection resources may not be freed). Solution: The soap builder code already wraps the incoming input stream with an axiom DetachableInputStream. The DetachableInputStream has a detach method, which copies the remainder of the original stream to a local stream. This allows the original stream (i.e. the HttpInputStream) to free its resources without any loss of information for the consumer of the stream. I am making changes to the jaxws dispatch/proxy/asyncResponse code to always call DetachableInputStream.detach() after all of the business objects are unmarshalled. This will effectively guarantee that the input stream from the transport layer is closed and allow resources to be freed. I have am testing these changes and will integrate soon. All of the changes are in the jaxws module -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-3966) JAX-WS: Client engine should detach input stream after use
[ https://issues.apache.org/jira/browse/AXIS2-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-3966. --- Resolution: Fixed 683433 JAX-WS: Client engine should detach input stream after use -- Key: AXIS2-3966 URL: https://issues.apache.org/jira/browse/AXIS2-3966 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 0.5h Remaining Estimate: 0.5h Background: The JAX-WS client engine (dispatch/proxy/asyncResponse) is ultimately responsible for creating business objects (or exception) for the client call. After that point, the unmarshalling is complete and the input stream (from the transport layer) is no longer needed. Problem: In some situations, the input stream is not closed. Since the input stream comes from the transport layer, this could result in resources not being freed. (For example connection resources may not be freed). Solution: The soap builder code already wraps the incoming input stream with an axiom DetachableInputStream. The DetachableInputStream has a detach method, which copies the remainder of the original stream to a local stream. This allows the original stream (i.e. the HttpInputStream) to free its resources without any loss of information for the consumer of the stream. I am making changes to the jaxws dispatch/proxy/asyncResponse code to always call DetachableInputStream.detach() after all of the business objects are unmarshalled. This will effectively guarantee that the input stream from the transport layer is closed and allow resources to be freed. I have am testing these changes and will integrate soon. All of the changes are in the jaxws module -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-3959) JAXWS: MustUnderstand checker should not recalculate the headers needed by the sei methods
[ https://issues.apache.org/jira/browse/AXIS2-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle updated AXIS2-3959: -- Component/s: jaxws JAXWS: MustUnderstand checker should not recalculate the headers needed by the sei methods -- Key: AXIS2-3959 URL: https://issues.apache.org/jira/browse/AXIS2-3959 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 24h Remaining Estimate: 24h Background: MustUnderstand checking must be performed for all required headers. This includes the headers associated with JAXWS method parameters and headers associated with JAXWS handlers. Problem: Currently the JAXWS headers associated with the JAXWS method parameters are recalculated on each request. This has a performance overhead. Solution: The solution is to calculate the JAXWS headers for the method parameters one time and save the list on the AxisService. The JAXWS header calculation associated with handlers remains unchanged. Next Step: I am doing the final testing on the change. Kudos to David Strite who discovered this performance boost and worked with me on the proposed change. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-3959) JAXWS: MustUnderstand checker should not recalculate the headers needed by the sei methods
JAXWS: MustUnderstand checker should not recalculate the headers needed by the sei methods -- Key: AXIS2-3959 URL: https://issues.apache.org/jira/browse/AXIS2-3959 Project: Axis 2.0 (Axis2) Issue Type: Improvement Reporter: Rich Scheuerle Assignee: Rich Scheuerle Background: MustUnderstand checking must be performed for all required headers. This includes the headers associated with JAXWS method parameters and headers associated with JAXWS handlers. Problem: Currently the JAXWS headers associated with the JAXWS method parameters are recalculated on each request. This has a performance overhead. Solution: The solution is to calculate the JAXWS headers for the method parameters one time and save the list on the AxisService. The JAXWS header calculation associated with handlers remains unchanged. Next Step: I am doing the final testing on the change. Kudos to David Strite who discovered this performance boost and worked with me on the proposed change. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-3960) JAXWS: Namespace to Package algorithm should ignore some common namespaces
[ https://issues.apache.org/jira/browse/AXIS2-3960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle updated AXIS2-3960: -- Component/s: jaxws JAXWS: Namespace to Package algorithm should ignore some common namespaces -- Key: AXIS2-3960 URL: https://issues.apache.org/jira/browse/AXIS2-3960 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Priority: Minor Original Estimate: 24h Remaining Estimate: 24h Background: The JAXWS engine builds a list of packages required to invoke a service. (For example, this list of packages is used to construct internal JAXBContexts). The preferred method of obtaining these packages is by walking the schema annotations. However, there is also a fallback search to build the packages from the wsdl/schema namespaces. This fallback mechanism is essential in cases where annotations are not fully declared. Problem: The fallback search (SchemaReaderImpl) attempts to build packages for each namespace that it discovers. However there are some namespaces (like the wsaddressing namespace) that should be excluded from this namespace-package search. Solution: I am working on a small change to the code that will exclude certain namespaces from the namespace-package search. Once completed, it will be easy to add other namespaces into the exclusion list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Work started: (AXIS2-3960) JAXWS: Namespace to Package algorithm should ignore some common namespaces
[ https://issues.apache.org/jira/browse/AXIS2-3960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AXIS2-3960 started by Rich Scheuerle. JAXWS: Namespace to Package algorithm should ignore some common namespaces -- Key: AXIS2-3960 URL: https://issues.apache.org/jira/browse/AXIS2-3960 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Priority: Minor Original Estimate: 24h Remaining Estimate: 24h Background: The JAXWS engine builds a list of packages required to invoke a service. (For example, this list of packages is used to construct internal JAXBContexts). The preferred method of obtaining these packages is by walking the schema annotations. However, there is also a fallback search to build the packages from the wsdl/schema namespaces. This fallback mechanism is essential in cases where annotations are not fully declared. Problem: The fallback search (SchemaReaderImpl) attempts to build packages for each namespace that it discovers. However there are some namespaces (like the wsaddressing namespace) that should be excluded from this namespace-package search. Solution: I am working on a small change to the code that will exclude certain namespaces from the namespace-package search. Once completed, it will be easy to add other namespaces into the exclusion list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Work started: (AXIS2-3959) JAXWS: MustUnderstand checker should not recalculate the headers needed by the sei methods
[ https://issues.apache.org/jira/browse/AXIS2-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AXIS2-3959 started by Rich Scheuerle. JAXWS: MustUnderstand checker should not recalculate the headers needed by the sei methods -- Key: AXIS2-3959 URL: https://issues.apache.org/jira/browse/AXIS2-3959 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 24h Remaining Estimate: 24h Background: MustUnderstand checking must be performed for all required headers. This includes the headers associated with JAXWS method parameters and headers associated with JAXWS handlers. Problem: Currently the JAXWS headers associated with the JAXWS method parameters are recalculated on each request. This has a performance overhead. Solution: The solution is to calculate the JAXWS headers for the method parameters one time and save the list on the AxisService. The JAXWS header calculation associated with handlers remains unchanged. Next Step: I am doing the final testing on the change. Kudos to David Strite who discovered this performance boost and worked with me on the proposed change. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-3960) JAXWS: Namespace to Package algorithm should ignore some common namespaces
JAXWS: Namespace to Package algorithm should ignore some common namespaces -- Key: AXIS2-3960 URL: https://issues.apache.org/jira/browse/AXIS2-3960 Project: Axis 2.0 (Axis2) Issue Type: Bug Reporter: Rich Scheuerle Assignee: Rich Scheuerle Priority: Minor Background: The JAXWS engine builds a list of packages required to invoke a service. (For example, this list of packages is used to construct internal JAXBContexts). The preferred method of obtaining these packages is by walking the schema annotations. However, there is also a fallback search to build the packages from the wsdl/schema namespaces. This fallback mechanism is essential in cases where annotations are not fully declared. Problem: The fallback search (SchemaReaderImpl) attempts to build packages for each namespace that it discovers. However there are some namespaces (like the wsaddressing namespace) that should be excluded from this namespace-package search. Solution: I am working on a small change to the code that will exclude certain namespaces from the namespace-package search. Once completed, it will be easy to add other namespaces into the exclusion list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-3960) JAXWS: Namespace to Package algorithm should ignore some common namespaces
[ https://issues.apache.org/jira/browse/AXIS2-3960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-3960. --- Resolution: Fixed 682004 JAXWS: Namespace to Package algorithm should ignore some common namespaces -- Key: AXIS2-3960 URL: https://issues.apache.org/jira/browse/AXIS2-3960 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Priority: Minor Original Estimate: 24h Remaining Estimate: 24h Background: The JAXWS engine builds a list of packages required to invoke a service. (For example, this list of packages is used to construct internal JAXBContexts). The preferred method of obtaining these packages is by walking the schema annotations. However, there is also a fallback search to build the packages from the wsdl/schema namespaces. This fallback mechanism is essential in cases where annotations are not fully declared. Problem: The fallback search (SchemaReaderImpl) attempts to build packages for each namespace that it discovers. However there are some namespaces (like the wsaddressing namespace) that should be excluded from this namespace-package search. Solution: I am working on a small change to the code that will exclude certain namespaces from the namespace-package search. Once completed, it will be easy to add other namespaces into the exclusion list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-3959) JAXWS: MustUnderstand checker should not recalculate the headers needed by the sei methods
[ https://issues.apache.org/jira/browse/AXIS2-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-3959. --- Resolution: Fixed 682006 JAXWS: MustUnderstand checker should not recalculate the headers needed by the sei methods -- Key: AXIS2-3959 URL: https://issues.apache.org/jira/browse/AXIS2-3959 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Original Estimate: 24h Remaining Estimate: 24h Background: MustUnderstand checking must be performed for all required headers. This includes the headers associated with JAXWS method parameters and headers associated with JAXWS handlers. Problem: Currently the JAXWS headers associated with the JAXWS method parameters are recalculated on each request. This has a performance overhead. Solution: The solution is to calculate the JAXWS headers for the method parameters one time and save the list on the AxisService. The JAXWS header calculation associated with handlers remains unchanged. Next Step: I am doing the final testing on the change. Kudos to David Strite who discovered this performance boost and worked with me on the proposed change. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-3925) JAXWS: MTOM attachment is lost if outbound JAXWS handler is installed
JAXWS: MTOM attachment is lost if outbound JAXWS handler is installed - Key: AXIS2-3925 URL: https://issues.apache.org/jira/browse/AXIS2-3925 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Problem Description: The JAXWS message's internal form is converted from OM to SAAJ when a JAXWS SOAP handler is called. After the SOAP handler chain completes, the SAAJ message is converted back into OM. Currently, if the OM contains an MTOM attachment, the attachment is lost during the SAAJ - OM conversion. Solution: The solution is very simple. The SAAJConverter code is used to convert the SAAJ message back to OM. In my sandbox, I have modified this code to optionally accept an OM AttachmentMap. I also have a added a unit test to verify the code. I will commit this change after I complete a few more tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-3925) JAXWS: MTOM attachment is lost if outbound JAXWS handler is installed
[ https://issues.apache.org/jira/browse/AXIS2-3925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-3925. --- Resolution: Fixed Committed Revision 677926 JAXWS: MTOM attachment is lost if outbound JAXWS handler is installed - Key: AXIS2-3925 URL: https://issues.apache.org/jira/browse/AXIS2-3925 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Problem Description: The JAXWS message's internal form is converted from OM to SAAJ when a JAXWS SOAP handler is called. After the SOAP handler chain completes, the SAAJ message is converted back into OM. Currently, if the OM contains an MTOM attachment, the attachment is lost during the SAAJ - OM conversion. Solution: The solution is very simple. The SAAJConverter code is used to convert the SAAJ message back to OM. In my sandbox, I have modified this code to optionally accept an OM AttachmentMap. I also have a added a unit test to verify the code. I will commit this change after I complete a few more tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-3918) JAXWS: Fix the logging of user exceptions thrown by the webservice
JAXWS: Fix the logging of user exceptions thrown by the webservice -- Key: AXIS2-3918 URL: https://issues.apache.org/jira/browse/AXIS2-3918 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Problem: The JAXWS web service provided by the user may throw an exception. If the exception is an not an expected exception (i.e. an unchecked exception) then it should be logged as an error to aid servicability. Unchecked exceptions should not be logged as errors. Solution: I am renaming the jaxws FailureLogger class to WebServiceExceptionLogger. This logger will log unexpected exceptions (i.e. unchecked exceptions) to the error log. If a user wants more extensive logging, the user may specify debug logging for the WebServiceExceptionLogger. This will cause all exceptions thrown by the WebService to be logged. I will be checking in this code soon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-3918) JAXWS: Fix the logging of user exceptions thrown by the webservice
[ https://issues.apache.org/jira/browse/AXIS2-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-3918. --- Resolution: Fixed Committed revision 677254. JAXWS: Fix the logging of user exceptions thrown by the webservice -- Key: AXIS2-3918 URL: https://issues.apache.org/jira/browse/AXIS2-3918 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Problem: The JAXWS web service provided by the user may throw an exception. If the exception is an not an expected exception (i.e. an unchecked exception) then it should be logged as an error to aid servicability. Unchecked exceptions should not be logged as errors. Solution: I am renaming the jaxws FailureLogger class to WebServiceExceptionLogger. This logger will log unexpected exceptions (i.e. unchecked exceptions) to the error log. If a user wants more extensive logging, the user may specify debug logging for the WebServiceExceptionLogger. This will cause all exceptions thrown by the WebService to be logged. I will be checking in this code soon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2-3904) Remove limitation of Maintain Session value to String type.
[ https://issues.apache.org/jira/browse/AXIS2-3904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle reassigned AXIS2-3904: - Assignee: Rich Scheuerle Remove limitation of Maintain Session value to String type. --- Key: AXIS2-3904 URL: https://issues.apache.org/jira/browse/AXIS2-3904 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: jaxws Environment: windows Reporter: Samuel Isokpunwu Assignee: Rich Scheuerle Attachments: patch.txt Original Estimate: 0h Remaining Estimate: 0h Updated a method in BindingProvider.java in jaxws client side to return an object type instead of casting the object to a String type. This was done to accommodate applications that may return maintain session value as any object type other than String. Prior code: --- . String sessionValue = null; . sessionValue = (String)properties.get(sessionKey); . requestContext.put(HTTPConstants.COOKIE_STRING, sessionValue); Current changes: --- . Object sessionValue = null; . sessionValue = properties.get(sessionKey); . requestContext.put(HTTPConstants.COOKIE_STRING, sessionValue); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-3904) Remove limitation of Maintain Session value to String type.
[ https://issues.apache.org/jira/browse/AXIS2-3904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-3904. --- Resolution: Fixed Thanks Samuel. This fix is now committed. Remove limitation of Maintain Session value to String type. --- Key: AXIS2-3904 URL: https://issues.apache.org/jira/browse/AXIS2-3904 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: jaxws Environment: windows Reporter: Samuel Isokpunwu Assignee: Rich Scheuerle Attachments: patch.txt Original Estimate: 0h Remaining Estimate: 0h Updated a method in BindingProvider.java in jaxws client side to return an object type instead of casting the object to a String type. This was done to accommodate applications that may return maintain session value as any object type other than String. Prior code: --- . String sessionValue = null; . sessionValue = (String)properties.get(sessionKey); . requestContext.put(HTTPConstants.COOKIE_STRING, sessionValue); Current changes: --- . Object sessionValue = null; . sessionValue = properties.get(sessionKey); . requestContext.put(HTTPConstants.COOKIE_STRING, sessionValue); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2-3845) Caching QName of Element and Attribute to save memory
[ https://issues.apache.org/jira/browse/AXIS2-3845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle reassigned AXIS2-3845: - Assignee: Rich Scheuerle Caching QName of Element and Attribute to save memory - Key: AXIS2-3845 URL: https://issues.apache.org/jira/browse/AXIS2-3845 Project: Axis 2.0 (Axis2) Issue Type: Improvement Environment: windows Reporter: Takahide Nogayama Assignee: Rich Scheuerle Attachments: patch.txt Original Estimate: 168h Remaining Estimate: 168h Currently we create QName for each getQName() method of OMElement.impl and OMAttributeImpl. If we cache these qnames, we can save memory and cpu cost of creating the new same QName instances. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-3845) Caching QName of Element and Attribute to save memory
[ https://issues.apache.org/jira/browse/AXIS2-3845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-3845. --- Resolution: Fixed Thanks for the patch ! Committed revision 665696. Caching QName of Element and Attribute to save memory - Key: AXIS2-3845 URL: https://issues.apache.org/jira/browse/AXIS2-3845 Project: Axis 2.0 (Axis2) Issue Type: Improvement Environment: windows Reporter: Takahide Nogayama Assignee: Rich Scheuerle Attachments: patch.txt Original Estimate: 168h Remaining Estimate: 168h Currently we create QName for each getQName() method of OMElement.impl and OMAttributeImpl. If we cache these qnames, we can save memory and cpu cost of creating the new same QName instances. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2-3816) AccessControlException when running with Java2Security
[ https://issues.apache.org/jira/browse/AXIS2-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle reassigned AXIS2-3816: - Assignee: Rich Scheuerle AccessControlException when running with Java2Security -- Key: AXIS2-3816 URL: https://issues.apache.org/jira/browse/AXIS2-3816 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: kernel Affects Versions: 1.4 Reporter: Lori VanGulick Assignee: Rich Scheuerle Priority: Minor Attachments: d516000.1patch.txt Hit the following AccessControlExceptions when installing the axis2 1.4 ear with java2security enabled: java.security.AccessControlException: Access denied (java.util.PropertyPermission Axis2.prohibitDebugLogging read) at java.security.AccessController.checkPermission(AccessController.java:108) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:210) at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285) at java.lang.System.getProperty(System.java:378) at java.lang.System.getProperty(System.java:362) at org.apache.axis2.util.LoggingControl.clinit(LoggingControl.java:43) at java.lang.J9VMInternals.initializeImpl(Native Method) at java.lang.J9VMInternals.initialize(J9VMInternals.java:200) at org.apache.axis2.handlers.addressing.AddressingInHandler.init(AddressingInHandler.java:68) at org.apache.axis2.deployment.util.Utils.addFlowHandlers(Utils.java:133) . java.security.AccessControlException: Access denied (java.io.FilePermission C:\pyxis\WebSphere\AppServer\profiles\AppSrv01\installedApps\bulbrichtNode01Cell\axis2.ear\axis2.war\WEB-INF\scriptServices read) at java.security.AccessController.checkPermission(AccessController.java:108) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:210) at java.lang.SecurityManager.checkRead(SecurityManager.java:871) at java.io.File.list(File.java:971) at java.io.File.listFiles(File.java:1051) at org.apache.axis2.scripting.ScriptRepositoryListener.findServicesInDirectory(ScriptRepositoryListener.java:43) .. java.security.AccessControlException: Access denied (java.lang.RuntimePermission modifyThreadGroup) at java.security.AccessController.checkPermission(AccessController.java:108) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:210) at com.ibm.ws.security.core.SecurityManager.checkAccess(SecurityManager.java:351) at java.lang.ThreadGroup.checkAccess(ThreadGroup.java:225) at java.lang.Thread.initialize(Thread.java:331) at java.lang.Thread.init(Thread.java:267) at java.lang.Thread.init(Thread.java:91) at java.util.Timer$TimerImpl.init(Unknown Source) at java.util.Timer.init(Unknown Source) at org.apache.axis2.deployment.scheduler.Scheduler.init(Scheduler.java:28) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
