[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] 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-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);
> 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);
[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-tabpanel&focusedCommentId=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] 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] 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] 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-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] 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-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] 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-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] 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] 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] 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] 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] 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] 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] Resolved: (AXIS2-4561) JAX-WS: ClassCastException when Dispatch 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 Dispatch 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 Dispatch 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-4561) JAX-WS: ClassCastException when Dispatch receives a SOAPFault
JAX-WS: ClassCastException when Dispatch 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 Dispatch 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-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 Dispatch > or Provider 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 > Dispatch and Provider 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] 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] 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] 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 Dispatch > or Provider 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 > Dispatch and Provider 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] Reopened: (AXIS2-4509) Provider 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 (Dispatch). 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. > Provider 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-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 {
> List getApple(String appType);
> }
> == Impl
> @WebService(endpointInterface =
> "org.apache.cxf.systest.type_substitution.AppleFinder",
> serviceName = "AppleFinder")
> public class AppleFinderImpl implements AppleFinder {
> public List getApple(String appleType) {
> List apples = new ArrayList();
> 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.
[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-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 ] Rich Scheuerle resolved AXIS2-3341. --- Resolution: Fixed > 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] 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:Receiverq0:Err_600
> xml:lang="en">{etc}soap:Text>http://example.host:8080/HelloService/HelloService.asmxHelloWorld...
> 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:Receiverq0:Err_600
> xml:lang="en">{etc}soap:Text>http://example.host:8080/HelloService/HelloService.asmxHelloWorld...
> 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] 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:Receiverq0:Err_600
> xml:lang="en">{etc}soap:Text>http://example.host:8080/HelloService/HelloService.asmxHelloWorld...
> 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] 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] 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] 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] 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] 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-tabpanel&focusedCommentId=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] 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-3341) Marshaling arrays and lists seems to be wrong
[ https://issues.apache.org/jira/browse/AXIS2-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753167#action_12753167 ] Rich Scheuerle commented on AXIS2-3341: --- I have reproduced the problem with a JAX-WS test based on the provided example. I am currently working on a solution. Thanks, 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] 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] 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] 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] 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] Commented: (AXIS2-4463) Unreachable code in JAXBAttachmentUnmarshaller
[
https://issues.apache.org/jira/browse/AXIS2-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] 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] 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-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-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-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] 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-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-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] 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-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 (*). > > xmlns:jws="http://java.sun.com/xml/ns/javaee";> > > some value > * > > test.MyHandler > > > > > 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 or . > Solution: > The JAX-WS runtime code that performs the regular expression evaluation for > the and 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-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-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] 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 (*). http://java.sun.com/xml/ns/javaee";> some value * test.MyHandler 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 or . Solution: The JAX-WS runtime code that performs the regular expression evaluation for the and 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] 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-4395) JAX-WS: Consistent code across the invoke apis
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 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-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-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-4392) JAXWS: Dispatch and Provider 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: Dispatch and Provider 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 Dispatch or Provider 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-4392) JAXWS: Dispatch and Provider don't honor SOAPAction MIMEHeader
JAXWS: Dispatch and Provider 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 Dispatch or Provider 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-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-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-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-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-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] 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] 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-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] 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-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] 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-tabpanel&focusedCommentId=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] 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] 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] 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-tabpanel&focusedCommentId=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-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] 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-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-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] 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-tabpanel&focusedCommentId=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] 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] 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] 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] 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] 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] 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] 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] 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] 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-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] 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-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-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] 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-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-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]
