[jira] Resolved: (AXIS2-4247) JAX-WS API fails to build an endpoint reference (IllegalStateException) when service is published with Endpoint.publish()
[
https://issues.apache.org/jira/browse/AXIS2-4247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Nagy resolved AXIS2-4247.
--
Resolution: Fixed
Assignee: Bill Nagy
JAX-WS API fails to build an endpoint reference (IllegalStateException) when
service is published with Endpoint.publish()
-
Key: AXIS2-4247
URL: https://issues.apache.org/jira/browse/AXIS2-4247
Project: Axis2
Issue Type: Bug
Components: jaxws
Affects Versions: nightly
Environment: JDK 1.6.0_06, WinXP
Reporter: Franck Michel
Assignee: Bill Nagy
Attachments: Axis2Test.java, LaunchAxis2Test.java,
WithwsdlLocation.patch
Hi, I'm facing a trouble using the Enpoint.publish() JAXWS API. I've checked
several issues that may be related, with no success until now :
https://issues.apache.org/jira/browse/AXIS2-3116?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel
https://wso2.org/jira/browse/CARBON-738
I'm using the last nightly build as some issues were fixed on this kind of
thing recently.
I publish a very basic WS Endpoint.publish(String url) API: the service seems
to be published (isPublished() returns true), but it fails to return an
endpoint reference. My code does this (the code of the web service is at the
end of this post):
Endpoint endPoint = Endpoint.create(new Axis2Test());
endPoint.publish(http://localhost:8081/services/Test;);
logger.debug(isPublished: + endPoint.isPublished());
logger.debug(getProperties: + endPoint.getProperties());
logger.debug(getMetadata: + endPoint.getMetadata());
logger.debug(getEndpointReference: +
endPoint.getEndpointReference());
This fails on endPoint.getEndpointReference(), an returns:
2009-02-23 11:28:37,242 [main] DEBUG
fr.anr.techlog.neurolog.server.LaunchStandaloneWebServices:18 - isPublished:
true
2009-02-23 11:28:37,242 [main] DEBUG
fr.anr.techlog.neurolog.server.LaunchStandaloneWebServices:19 -
getProperties: null
2009-02-23 11:28:37,242 [main] DEBUG
fr.anr.techlog.neurolog.server.LaunchStandaloneWebServices:20 - getMetadata:
null
2009-02-23 11:28:37,492 [main] FATAL
fr.anr.techlog.neurolog.server.LaunchStandaloneWebServices:24 - Unable to
create server
java.lang.IllegalStateException: Unable to locate a deployed service that
maps to the requested endpoint, Service: {http://mypackage/}Axis2TestService,
Port: {http://mypackage/}Axis2TestPort
at
org.apache.axis2.jaxws.addressing.factory.impl.Axis2EndpointReferenceFactoryImpl.createEndpointReference(Axis2EndpointReferenceFactoryImpl.java:66)
at
org.apache.axis2.jaxws.addressing.factory.impl.Axis2EndpointReferenceFactoryImpl.createEndpointReference(Axis2EndpointReferenceFactoryImpl.java:97)
at
org.apache.axis2.jaxws.addressing.util.EndpointReferenceUtils.createAxis2EndpointReference(EndpointReferenceUtils.java:133)
at
org.apache.axis2.jaxws.server.endpoint.EndpointImpl.getEndpointReference(EndpointImpl.java:244)
at
org.apache.axis2.jaxws.server.endpoint.EndpointImpl.getEndpointReference(EndpointImpl.java:261)
at mypackage.LaunchA2xis2Test.main(LaunchA2xis2Test.java:21)
Also, accessing the service using Firefox returns this :
2009-02-23 11:52:46,184 [HttpConnection-8081-2] ERROR
org.apache.axis2.engine.AxisEngine:212 - The service cannot be found for the
endpoint reference (EPR) /services/Test?wsdl
org.apache.axis2.AxisFault: The service cannot be found for the endpoint
reference (EPR) /services/Test?wsdl
at
org.apache.axis2.engine.DispatchPhase.checkPostConditions(DispatchPhase.java:65)
at org.apache.axis2.engine.Phase.invoke(Phase.java:333)
at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:264)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:163)
at
org.apache.axis2.transport.http.util.RESTUtil.invokeAxisEngine(RESTUtil.java:136)
at
org.apache.axis2.transport.http.util.RESTUtil.processURLRequest(RESTUtil.java:130)
at
org.apache.axis2.transport.http.HTTPWorker.service(HTTPWorker.java:257)
at
org.apache.axis2.transport.http.server.AxisHttpService.doService(AxisHttpService.java:281)
at
org.apache.axis2.transport.http.server.AxisHttpService.handleRequest(AxisHttpService.java:187)
at
org.apache.axis2.transport.http.server.HttpServiceProcessor.run(HttpServiceProcessor.java:82)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061)
at
[jira] Resolved: (AXIS2-3547) JAXWS Sessions working in Standalone Axis2+Tomcat / Axis2+SimpleAxisServer with Simple JAXWS client
[ https://issues.apache.org/jira/browse/AXIS2-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Nagy resolved AXIS2-3547. -- Resolution: Invalid I've tried out a number of scenarios, and a JAX-WS client and service are able to utilize HTTP sessions correctly. The JAX-WS spec does not talk about sessions beyond being able to participate in an HTTP session (i.e. being able to set/extract things in the Servlet context,) so further integration with the Axis2 session model is not required for compliance with the spec. JAXWS Sessions working in Standalone Axis2+Tomcat / Axis2+SimpleAxisServer with Simple JAXWS client --- Key: AXIS2-3547 URL: https://issues.apache.org/jira/browse/AXIS2-3547 Project: Axis 2.0 (Axis2) Issue Type: Bug Reporter: Davanum Srinivas Assignee: Bill Nagy Priority: Blocker Fix For: 1.4 Looks like the JAXWS Sessions scenarios need work. - JAXWS Service inside Tomcat/Axis2 should be able to participate in a transport session - JAXWS Service inside SimpleAxisServer/Axis2 should be able to participate in a transport session These services should be able to work with - Standalone Axis2/ADB client with sessions enabled. - JAXWS Client with sessions enabled. thanks., dims -- 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-2098) There are numerous public methods on MessageContext that do not have comments.
[ https://issues.apache.org/jira/browse/AXIS2-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Nagy reassigned AXIS2-2098: Assignee: Roy A. Wood Jr. (was: Bill Nagy) There are numerous public methods on MessageContext that do not have comments. -- Key: AXIS2-2098 URL: https://issues.apache.org/jira/browse/AXIS2-2098 Project: Axis 2.0 (Axis2) Issue Type: Task Components: kernel Reporter: Bill Nagy Assignee: Roy A. Wood Jr. -- 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-2095) There are numerous public methods on ConfigurationContext which do not have comments.
[ https://issues.apache.org/jira/browse/AXIS2-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Nagy reassigned AXIS2-2095: Assignee: Roy A. Wood Jr. (was: Bill Nagy) There are numerous public methods on ConfigurationContext which do not have comments. - Key: AXIS2-2095 URL: https://issues.apache.org/jira/browse/AXIS2-2095 Project: Axis 2.0 (Axis2) Issue Type: Task Components: kernel Reporter: Bill Nagy Assignee: Roy A. Wood Jr. -- 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-2084) Improve performance in AxisEngine by removing calls to MessageContext.activate()
[ https://issues.apache.org/jira/browse/AXIS2-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Nagy resolved AXIS2-2084. -- Resolution: Fixed Assignee: Bill Nagy Improve performance in AxisEngine by removing calls to MessageContext.activate() Key: AXIS2-2084 URL: https://issues.apache.org/jira/browse/AXIS2-2084 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: kernel Reporter: Ann Robinson Assigned To: Bill Nagy Priority: Minor Attachments: patch.txt The AxisEngine currently invokes the MessageContext.activate() method to ensure that a message context is in a usable state, in the event that a message context has been saved/restored. However, this responsibility can be shifted to the code that saves/restore the message context so the AxisEngine should not need to make this call. The solution is to remove calls to MessageContext.activate() from the AxisEngine. -- 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-2002) Reduce the trace messages for object serialization to improve performance with trace enabled
[ https://issues.apache.org/jira/browse/AXIS2-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Nagy resolved AXIS2-2002. -- Resolution: Fixed Reduce the trace messages for object serialization to improve performance with trace enabled - Key: AXIS2-2002 URL: https://issues.apache.org/jira/browse/AXIS2-2002 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: kernel Reporter: Ann Robinson Assigned To: Bill Nagy Attachments: patch.txt, patch502673.txt There is extensive tracing being performed by the message context serialization related code. While this has been helpful in quickly debugging problems, the amount of trace messages needs to be reduced to improve performance when tracing is enabled. Since much of the read/write to streams is done in a utility class, the improvement can be made there. -- 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-2094) The class level comment on ConfigurationContext is not very descriptive.
The class level comment on ConfigurationContext is not very descriptive. Key: AXIS2-2094 URL: https://issues.apache.org/jira/browse/AXIS2-2094 Project: Axis 2.0 (Axis2) Issue Type: Task Components: kernel Reporter: Bill Nagy -- 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-2095) There are numerous public methods on ConfigurationContext which do not have comments.
There are numerous public methods on ConfigurationContext which do not have comments. - Key: AXIS2-2095 URL: https://issues.apache.org/jira/browse/AXIS2-2095 Project: Axis 2.0 (Axis2) Issue Type: Task Components: kernel Reporter: Bill Nagy -- 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-2096) The isServerSide/setServerSide methods on MessageContext are inappropriately named.
The isServerSide/setServerSide methods on MessageContext are inappropriately named. --- Key: AXIS2-2096 URL: https://issues.apache.org/jira/browse/AXIS2-2096 Project: Axis 2.0 (Axis2) Issue Type: Task Components: kernel Reporter: Bill Nagy The isServerSide/setServerSide methods on MessageContext are inappropriately named, as they would lead one to believe that it is a test as to whether or not you were running in a server environment (as opposed to on a client.) -- 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-2097) The class level comment on MessageContext is not very descriptive.
The class level comment on MessageContext is not very descriptive. -- Key: AXIS2-2097 URL: https://issues.apache.org/jira/browse/AXIS2-2097 Project: Axis 2.0 (Axis2) Issue Type: Task Components: kernel Reporter: Bill Nagy -- 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-2098) There are numerous public methods on MessageContext that do not have comments.
There are numerous public methods on MessageContext that do not have comments. -- Key: AXIS2-2098 URL: https://issues.apache.org/jira/browse/AXIS2-2098 Project: Axis 2.0 (Axis2) Issue Type: Task Components: kernel Reporter: Bill Nagy -- 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-2099) The class level comment on PhaseHolder is not very descriptive.
The class level comment on PhaseHolder is not very descriptive. --- Key: AXIS2-2099 URL: https://issues.apache.org/jira/browse/AXIS2-2099 Project: Axis 2.0 (Axis2) Issue Type: Task Components: kernel Reporter: Bill Nagy -- 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-2100) The class level comment on PhaseResolver is not very descriptive.
The class level comment on PhaseResolver is not very descriptive. - Key: AXIS2-2100 URL: https://issues.apache.org/jira/browse/AXIS2-2100 Project: Axis 2.0 (Axis2) Issue Type: Task Components: kernel Reporter: Bill Nagy -- 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-2101) The engageModuleToOperation method on PhaseResolver is missing a comment.
The engageModuleToOperation method on PhaseResolver is missing a comment. - Key: AXIS2-2101 URL: https://issues.apache.org/jira/browse/AXIS2-2101 Project: Axis 2.0 (Axis2) Issue Type: Task Components: kernel Reporter: Bill Nagy -- 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-2102) The logic in the engageModuleToOperation method on PhaseResolver is very obfuscated.
The logic in the engageModuleToOperation method on PhaseResolver is very obfuscated. Key: AXIS2-2102 URL: https://issues.apache.org/jira/browse/AXIS2-2102 Project: Axis 2.0 (Axis2) Issue Type: Task Components: kernel Reporter: Bill Nagy The logic in the engageModuleToOperation method on PhaseResolver is very obfuscated (e.g. why is there a for loop for iterating over the set of flows when there is a switch block inside of it which explicitly enumerates each flow?) -- 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-2076) Improve trace correlation for message context serialization
[ https://issues.apache.org/jira/browse/AXIS2-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Nagy resolved AXIS2-2076. -- Resolution: Fixed Assignee: Bill Nagy Improve trace correlation for message context serialization --- Key: AXIS2-2076 URL: https://issues.apache.org/jira/browse/AXIS2-2076 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: kernel Reporter: Ann Robinson Assigned To: Bill Nagy Priority: Minor Attachments: patch.txt In debugging some of the more complicated application scenarios, it has become clear that having better correlation in the trace messages among some of the objects in the message context object graph is very helpful in determining failure points. The following needs to be done: - Make use of the logCorrelationIDString in the MessageContext - Add a logCorrelationIDString to the OperationContext - Add a logCorrelationIDString to the Options - Add some try..catch blocks around the use of ObjectStateUtils.writeObject(...) for some objects In addition, clean up the following - remove commented out System.out.println lines - move the check of the NeedsToBeReconciled flag to a method -- 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-1649) Invocation with useSeparateListener option set will never complete if an error occurs in the outbound transport
Invocation with useSeparateListener option set will never complete if an error occurs in the outbound transport --- Key: AXIS2-1649 URL: http://issues.apache.org/jira/browse/AXIS2-1649 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: kernel Reporter: Bill Nagy Assigned To: Bill Nagy If the useSeparateListener option is set, MessageContext.TRANSPORT_NON_BLOCKING will, in turn, be set forcing the actual message transmission to occur on another thread via the TransportNonBlockingInvocationWorker. However, the TransportNonBlockingInvocationWorker swallows all exceptions, so if an error occurs during the outbound transport, the callback will never be notified and the requestor will hang indefinately. I will modify the TransportNonBlockingInvocationWorker to invoke Callback.onError(), if it exists, passing the exception and eliminating the hang. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (AXIS2-1233) Handlers do not get a chance to undo work if a fault occurs or complete work when message processing finishes (this was split off from AXIS2-653)
[ http://issues.apache.org/jira/browse/AXIS2-1233?page=all ] Bill Nagy closed AXIS2-1233. Resolution: Fixed Handlers do not get a chance to undo work if a fault occurs or complete work when message processing finishes (this was split off from AXIS2-653) - Key: AXIS2-1233 URL: http://issues.apache.org/jira/browse/AXIS2-1233 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: core Reporter: Bill Nagy Assigned To: Bill Nagy Attachments: qoslifecyclepatch.txt I split this off of AXIS2-653, so that we could track this bit of work separately. The basic gist of the matter is that the handlers do not have an opportunity to clean up/complete their work after message processing has completed (either due to a fault or to successful processing.) Here's some of the original discussion: http://marc.theaimsgroup.com/?l=axis-devm=114505970102143w=2 . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (AXIS2-1238) org.apache.axis2.deployment.util.PhasesInfo has hard coded phase names which prevent the phase ordering in axis2.xml from functioning properly
[ http://issues.apache.org/jira/browse/AXIS2-1238?page=all ] Bill Nagy closed AXIS2-1238. Resolution: Invalid This was addressed (at least partially -- there are still hardcoded names, but less of them) between the time that I brought it up and when I opened the JIRA. org.apache.axis2.deployment.util.PhasesInfo has hard coded phase names which prevent the phase ordering in axis2.xml from functioning properly -- Key: AXIS2-1238 URL: http://issues.apache.org/jira/browse/AXIS2-1238 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: deployment Reporter: Bill Nagy Assigned To: Bill Nagy Priority: Critical org.apache.axis2.deployment.util.PhasesInfo has hard coded phase names (well, the constant equivalent of them anyways.) This makes it impossible to add new phases in certain cases and have the ordering during execution reflect what appeared in the axis2.xml file. (e.g. the change that Ruchith just made to add a security phase to the outflow won't work correctly, as the PhaseInfo class will return the Security phase as an operation-level phase and not a global phase, thus screwing up the execution order in AxisEngine.send(...).) Simply adding a new hard coded constant switch (as seems to have been done in the past) is not a good solution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (AXIS2-1233) Handlers do not get a chance to undo work if a fault occurs or complete work when message processing finishes (this was split off from AXIS2-653)
[ http://issues.apache.org/jira/browse/AXIS2-1233?page=all ] Bill Nagy reopened AXIS2-1233: -- This issue is being reopened as the changes were backed out due to Sanjiva's -1. Handlers do not get a chance to undo work if a fault occurs or complete work when message processing finishes (this was split off from AXIS2-653) - Key: AXIS2-1233 URL: http://issues.apache.org/jira/browse/AXIS2-1233 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: core Reporter: Bill Nagy Assigned To: Bill Nagy Priority: Blocker Attachments: qoslifecyclepatch.txt I split this off of AXIS2-653, so that we could track this bit of work separately. The basic gist of the matter is that the handlers do not have an opportunity to clean up/complete their work after message processing has completed (either due to a fault or to successful processing.) Here's some of the original discussion: http://marc.theaimsgroup.com/?l=axis-devm=114505970102143w=2 . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1233) Handlers do not get a chance to undo work if a fault occurs or complete work when message processing finishes (this was split off from AXIS2-653)
Handlers do not get a chance to undo work if a fault occurs or complete work when message processing finishes (this was split off from AXIS2-653) - Key: AXIS2-1233 URL: http://issues.apache.org/jira/browse/AXIS2-1233 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: core Reporter: Bill Nagy Assigned To: Bill Nagy Priority: Blocker I split this off of AXIS2-653, so that we could track this bit of work separately. The basic gist of the matter is that the handlers do not have an opportunity to clean up/complete their work after message processing has completed (either due to a fault or to successful processing.) Here's some of the original discussion: http://marc.theaimsgroup.com/?l=axis-devm=114505970102143w=2 . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-1233) Handlers do not get a chance to undo work if a fault occurs or complete work when message processing finishes (this was split off from AXIS2-653)
[ http://issues.apache.org/jira/browse/AXIS2-1233?page=all ] Bill Nagy updated AXIS2-1233: - Attachment: qoslifecyclepatch.txt This is the patch that was originally attached to AXIS2-653. Handlers do not get a chance to undo work if a fault occurs or complete work when message processing finishes (this was split off from AXIS2-653) - Key: AXIS2-1233 URL: http://issues.apache.org/jira/browse/AXIS2-1233 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: core Reporter: Bill Nagy Assigned To: Bill Nagy Priority: Blocker Attachments: qoslifecyclepatch.txt I split this off of AXIS2-653, so that we could track this bit of work separately. The basic gist of the matter is that the handlers do not have an opportunity to clean up/complete their work after message processing has completed (either due to a fault or to successful processing.) Here's some of the original discussion: http://marc.theaimsgroup.com/?l=axis-devm=114505970102143w=2 . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-653) Handler method cleanup is never called
[ http://issues.apache.org/jira/browse/AXIS2-653?page=all ] Bill Nagy updated AXIS2-653: Attachment: (was: qoslifecyclepatch.txt) Handler method cleanup is never called Key: AXIS2-653 URL: http://issues.apache.org/jira/browse/AXIS2-653 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: core Affects Versions: 1.0 Reporter: Thilo Frotscher Assigned To: Deepal Jayasinghe Priority: Blocker 1) My IDE couldn't find any references to method cleanup in the Axis2 source code. It's never called... 2) What happens if the handler's invoke method thows a fault? Javadoc for invoke says that onFault would be called. But there is no such method... 3) User guide, page 4 - mentions a method called revoke. There is no such method in interface Handler. - refers to green lines in sample configuration...there are no green lines - sample configuration contains mistakes -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-653) Handler method cleanup is never called
[ http://issues.apache.org/jira/browse/AXIS2-653?page=comments#action_12437571 ] Bill Nagy commented on AXIS2-653: - I've created a new task, AXIS2-1233, to track the handler invocation/lifecycle issues (i.e. not the cleanup(...)) and moved my patch there. Had I been smarter, I would have created a sub-task instead of a new issue... Handler method cleanup is never called Key: AXIS2-653 URL: http://issues.apache.org/jira/browse/AXIS2-653 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: core Affects Versions: 1.0 Reporter: Thilo Frotscher Assigned To: Deepal Jayasinghe Priority: Blocker 1) My IDE couldn't find any references to method cleanup in the Axis2 source code. It's never called... 2) What happens if the handler's invoke method thows a fault? Javadoc for invoke says that onFault would be called. But there is no such method... 3) User guide, page 4 - mentions a method called revoke. There is no such method in interface Handler. - refers to green lines in sample configuration...there are no green lines - sample configuration contains mistakes -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1237) OutInAxisOperation invokes the InFlow and InFaultFlow when a fault is received in a response
OutInAxisOperation invokes the InFlow and InFaultFlow when a fault is received in a response Key: AXIS2-1237 URL: http://issues.apache.org/jira/browse/AXIS2-1237 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: core Reporter: Bill Nagy Assigned To: Bill Nagy OutInAxisOperation invokes the InFlow for all response messages, even if that response is a fault. See the discussion at http://marc.theaimsgroup.com/?l=axis-devm=115835375100509w=2 for more details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1238) org.apache.axis2.deployment.util.PhasesInfo has hard coded phase names which prevent the phase ordering in axis2.xml from functioning properly
org.apache.axis2.deployment.util.PhasesInfo has hard coded phase names which prevent the phase ordering in axis2.xml from functioning properly -- Key: AXIS2-1238 URL: http://issues.apache.org/jira/browse/AXIS2-1238 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: deployment Reporter: Bill Nagy Assigned To: Bill Nagy Priority: Critical org.apache.axis2.deployment.util.PhasesInfo has hard coded phase names (well, the constant equivalent of them anyways.) This makes it impossible to add new phases in certain cases and have the ordering during execution reflect what appeared in the axis2.xml file. (e.g. the change that Ruchith just made to add a security phase to the outflow won't work correctly, as the PhaseInfo class will return the Security phase as an operation-level phase and not a global phase, thus screwing up the execution order in AxisEngine.send(...).) Simply adding a new hard coded constant switch (as seems to have been done in the past) is not a good solution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-653) Handler method cleanup is never called
[ http://issues.apache.org/jira/browse/AXIS2-653?page=all ] Bill Nagy updated AXIS2-653: Attachment: qoslifecyclepatch.txt Here's a patch that implements the QoS/handler lifecycle. (This still doesn't fix the module lifecycle issue [i.e. the cleanup() method not being invoked.]). The flowComplete(...) method for a handler will be invoked as the stack is unwound from either a successful completion or an error. (If you want to know the order in which things occur, you can look at the comparisons at the end of the test cases.) The only extra info that is kept is two linked lists in the MessageContext which maintain the set of phases that have been processed. (If a phase could certainly keep extra state if it desired, but I didn't need to do so in any of the standard Axis2 phases.) The only cost to execute (besides list insertions) is the added invocation of the flowComplete(...) on each handler that was executed during processing of the message. (The handler can do whatever it wants in the flowComplete(...), so we have no control over how long that takes.) Handler method cleanup is never called Key: AXIS2-653 URL: http://issues.apache.org/jira/browse/AXIS2-653 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: core Affects Versions: 1.0 Reporter: Thilo Frotscher Assigned To: Deepal Jayasinghe Priority: Blocker Attachments: qoslifecyclepatch.txt 1) My IDE couldn't find any references to method cleanup in the Axis2 source code. It's never called... 2) What happens if the handler's invoke method thows a fault? Javadoc for invoke says that onFault would be called. But there is no such method... 3) User guide, page 4 - mentions a method called revoke. There is no such method in interface Handler. - refers to green lines in sample configuration...there are no green lines - sample configuration contains mistakes -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-1119) Dispatcher support for ServiceMode=MESSAGE annotation
[ http://issues.apache.org/jira/browse/AXIS2-1119?page=all ] Bill Nagy updated AXIS2-1119: - Component/s: jaxws Dispatcher support for ServiceMode=MESSAGE annotation - Key: AXIS2-1119 URL: http://issues.apache.org/jira/browse/AXIS2-1119 Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Components: jaxws Reporter: Jeff Barrett The Dispatcher currently assumes ServiceMode=PAYLOAD (e.g. the Body of the message). MESSAGE mode support for ProviderT types of Source, SOAPMessage, and String needs to be added. I am working on a patch which I will submit shortly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-653) Handler method cleanup is never called
[ http://issues.apache.org/jira/browse/AXIS2-653?page=comments#action_12431888 ] Bill Nagy commented on AXIS2-653: - Hi Deepal. I actually proposed this modification to the lifecycle sometime in April ( http://marc.theaimsgroup.com/?l=axis-devm=114505970102143w=2 ), but haven't gotten the code out yet. You still need a cleanup() method to match the init() to allow, for instance, a handler that is maintaining a DB connection throughout its lifetime (the lifetime of the system as you said) to close the connection when it is being shut down (i.e. when the system is stopped.) As for the antiinvoke methods, you need to make sure that they get called in the opposite order that the invokes happened (and in the same place in the call stack,) that they are called only for those handlers who have had their invokes called, and that they are called both for normal completion as well as in the case of a fault. Handler method cleanup is never called Key: AXIS2-653 URL: http://issues.apache.org/jira/browse/AXIS2-653 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: core Affects Versions: 1.0 Reporter: Thilo Frotscher Assigned To: Deepal Jayasinghe Priority: Blocker 1) My IDE couldn't find any references to method cleanup in the Axis2 source code. It's never called... 2) What happens if the handler's invoke method thows a fault? Javadoc for invoke says that onFault would be called. But there is no such method... 3) User guide, page 4 - mentions a method called revoke. There is no such method in interface Handler. - refers to green lines in sample configuration...there are no green lines - sample configuration contains mistakes -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1095) Transmission with MTOM enabled fails when client sets useSeparateListener for req/rsp
Transmission with MTOM enabled fails when client sets useSeparateListener for req/rsp - Key: AXIS2-1095 URL: http://issues.apache.org/jira/browse/AXIS2-1095 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: M2 Reporter: Bill Nagy Attachments: EchoRawMTOMTest.java, maven.xml, MTOM-enabled-axis2.xml, TEST-org.apache.axis2.mtom.EchoRawMTOMTest.txt I was creating a new testcase when I ran into this issue, but I was able to replicate it by modifying the EchoRawMTOMTest in the integration module. I have added the addressing mar to the build and enabled addressing in the config file. The test case continues to work until I add options.setUseSeparateListener(true). I've attached my modified files as well as the test report. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-1095) Transmission with MTOM enabled fails when client sets useSeparateListener for req/rsp
[ http://issues.apache.org/jira/browse/AXIS2-1095?page=all ] Bill Nagy updated AXIS2-1095: - Attachment: MTOM-enabled-axis2.xml Transmission with MTOM enabled fails when client sets useSeparateListener for req/rsp - Key: AXIS2-1095 URL: http://issues.apache.org/jira/browse/AXIS2-1095 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: M2 Reporter: Bill Nagy Attachments: EchoRawMTOMTest.java, maven.xml, MTOM-enabled-axis2.xml, TEST-org.apache.axis2.mtom.EchoRawMTOMTest.txt I was creating a new testcase when I ran into this issue, but I was able to replicate it by modifying the EchoRawMTOMTest in the integration module. I have added the addressing mar to the build and enabled addressing in the config file. The test case continues to work until I add options.setUseSeparateListener(true). I've attached my modified files as well as the test report. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-1095) Transmission with MTOM enabled fails when client sets useSeparateListener for req/rsp
[ http://issues.apache.org/jira/browse/AXIS2-1095?page=all ] Bill Nagy updated AXIS2-1095: - Affects Version/s: (was: M2) Transmission with MTOM enabled fails when client sets useSeparateListener for req/rsp - Key: AXIS2-1095 URL: http://issues.apache.org/jira/browse/AXIS2-1095 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Reporter: Bill Nagy Attachments: EchoRawMTOMTest.java, maven.xml, MTOM-enabled-axis2.xml, TEST-org.apache.axis2.mtom.EchoRawMTOMTest.txt I was creating a new testcase when I ran into this issue, but I was able to replicate it by modifying the EchoRawMTOMTest in the integration module. I have added the addressing mar to the build and enabled addressing in the config file. The test case continues to work until I add options.setUseSeparateListener(true). I've attached my modified files as well as the test report. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-1095) Reception of response from server when using MTOM fails when client sets useSeparateListener for req/rsp
[ http://issues.apache.org/jira/browse/AXIS2-1095?page=all ] Bill Nagy updated AXIS2-1095: - Summary: Reception of response from server when using MTOM fails when client sets useSeparateListener for req/rsp (was: Transmission with MTOM enabled fails when client sets useSeparateListener for req/rsp) Clarified the summary (I hope) Reception of response from server when using MTOM fails when client sets useSeparateListener for req/rsp Key: AXIS2-1095 URL: http://issues.apache.org/jira/browse/AXIS2-1095 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Reporter: Bill Nagy Attachments: EchoRawMTOMTest.java, maven.xml, MTOM-enabled-axis2.xml, TEST-org.apache.axis2.mtom.EchoRawMTOMTest.txt I was creating a new testcase when I ran into this issue, but I was able to replicate it by modifying the EchoRawMTOMTest in the integration module. I have added the addressing mar to the build and enabled addressing in the config file. The test case continues to work until I add options.setUseSeparateListener(true). I've attached my modified files as well as the test report. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-938) Plugpoint to allow for migration between context and TLS
[ http://issues.apache.org/jira/browse/AXIS2-938?page=comments#action_12424587 ] Bill Nagy commented on AXIS2-938: - (Sorry that I'm a little late to the discussion; I just switched machines and apparently my mail filtering is screwed up.) The plugpoint was indeed meant to be PM-agnostic, and I know for a fact that when Tuscany integrates with Axis2 they will need this as well. As Nick pointed out, the invocations have to happen at the PM layer, as the PM may introduce thread-switches of its own, and that's the only place that will know when all of those have been completed or will know before they start. As to putting the LinkedList into the AxisConfiguration vs. the ConfigurationContext, I had likened the migrators to modules, transports, phases, etc. all of which reside in the AxisConfiguration. At least on the client side, migrators are going to have to be statically registered/deployed, as they need to be invoked high up in the PM and not much of the engine will have executed at that point in time. If you still think that they belong in the ConfigurationContext, then I'm happy to move the List. -Bill Plugpoint to allow for migration between context and TLS Key: AXIS2-938 URL: http://issues.apache.org/jira/browse/AXIS2-938 Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Components: core, jaxws Reporter: Bill Nagy Assigned To: Bill Nagy Attachments: tlsmigrator.patch We have an issue with some APIs (e.g. security, Tx) requiring that data be present on Thread Local Storage (TLS). I believe that we can work around (at least for now) needing to migrate information between threads, and can simply get away with storing it in one of the contexts and then moving it to TLS before we get into user space (i.e. up through the service programming model) and then back again if need be. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-910) JAXWS: Update AxisInvocationController to use the OperationClient instead of the ServiceClient
[ http://issues.apache.org/jira/browse/AXIS2-910?page=all ] Bill Nagy resolved AXIS2-910. - Resolution: Fixed JAXWS: Update AxisInvocationController to use the OperationClient instead of the ServiceClient -- Key: AXIS2-910 URL: http://issues.apache.org/jira/browse/AXIS2-910 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: jaxws Reporter: Nick Gallardo Assigned To: Bill Nagy Attachments: 910-src-patch.txt, 910-test-patch.txt, jaxws-test-patch.txt For the purposes of greater flexibility, the AxisInvocationController should use the Axis2 OperationClient API rather than using the ServiceClient. I've started a little bit of this work in a sandbox and will hopefully have patches to post later on today. Also, this work is dependant upon the patch that I posted for JIRA issue 909. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-938) Plugpoint to allow for migration between context and TLS
Plugpoint to allow for migration between context and TLS Key: AXIS2-938 URL: http://issues.apache.org/jira/browse/AXIS2-938 Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Components: core, jaxws Reporter: Bill Nagy Assigned To: Bill Nagy Attachments: tlsmigrator.patch We have an issue with some APIs (e.g. security, Tx) requiring that data be present on Thread Local Storage (TLS). I believe that we can work around (at least for now) needing to migrate information between threads, and can simply get away with storing it in one of the contexts and then moving it to TLS before we get into user space (i.e. up through the service programming model) and then back again if need be. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-938) Plugpoint to allow for migration between context and TLS
[ http://issues.apache.org/jira/browse/AXIS2-938?page=all ] Bill Nagy updated AXIS2-938: Attachment: tlsmigrator.patch Plugpoint to allow for migration between context and TLS Key: AXIS2-938 URL: http://issues.apache.org/jira/browse/AXIS2-938 Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Components: core, jaxws Reporter: Bill Nagy Assigned To: Bill Nagy Attachments: tlsmigrator.patch We have an issue with some APIs (e.g. security, Tx) requiring that data be present on Thread Local Storage (TLS). I believe that we can work around (at least for now) needing to migrate information between threads, and can simply get away with storing it in one of the contexts and then moving it to TLS before we get into user space (i.e. up through the service programming model) and then back again if need be. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2-910) JAXWS: Update AxisInvocationController to use the OperationClient instead of the ServiceClient
[ http://issues.apache.org/jira/browse/AXIS2-910?page=all ] Bill Nagy reassigned AXIS2-910: --- Assignee: Bill Nagy (was: Rich Scheuerle) JAXWS: Update AxisInvocationController to use the OperationClient instead of the ServiceClient -- Key: AXIS2-910 URL: http://issues.apache.org/jira/browse/AXIS2-910 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: jaxws Reporter: Nick Gallardo Assigned To: Bill Nagy Attachments: 910-src-patch.txt, 910-test-patch.txt, jaxws-test-patch.txt For the purposes of greater flexibility, the AxisInvocationController should use the Axis2 OperationClient API rather than using the ServiceClient. I've started a little bit of this work in a sandbox and will hopefully have patches to post later on today. Also, this work is dependant upon the patch that I posted for JIRA issue 909. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-909) JAXWS: Fix the invokeOneWay and invokeAsync (callback) implementations in AxisInvocationController.
[ http://issues.apache.org/jira/browse/AXIS2-909?page=all ] Bill Nagy resolved AXIS2-909. - Resolution: Fixed JAXWS: Fix the invokeOneWay and invokeAsync (callback) implementations in AxisInvocationController. --- Key: AXIS2-909 URL: http://issues.apache.org/jira/browse/AXIS2-909 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: jaxws Reporter: Nick Gallardo Assigned To: Bill Nagy Attachments: patch.txt I've implemented the invokeOneWay and invokeAsync-callback methods in the AxisInvocationController. The sync had already been implemented in a previous defect. Also, I've updated the BaseDispatch to use this rather than the original AxisController. This brings us much closer to removing the AxisController API in favor of the AxisInvocationController. The changes to the async impl requires updates to the callbacks that are used. Specifically, the AsyncResponse/AsyncResponseProcessor have been renamed to be a little more intuitive. The AsyncListener is the task that will wait for the async response to come back. This will be wrapped in an AsyncListenerWrapper that controls the starting and stopping. This AsyncListenerWrapper is what will be used by the JAX-WS client to determine if a response is available or not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2-909) JAXWS: Fix the invokeOneWay and invokeAsync (callback) implementations in AxisInvocationController.
[ http://issues.apache.org/jira/browse/AXIS2-909?page=all ] Bill Nagy reassigned AXIS2-909: --- Assignee: Bill Nagy JAXWS: Fix the invokeOneWay and invokeAsync (callback) implementations in AxisInvocationController. --- Key: AXIS2-909 URL: http://issues.apache.org/jira/browse/AXIS2-909 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: jaxws Reporter: Nick Gallardo Assigned To: Bill Nagy Attachments: patch.txt I've implemented the invokeOneWay and invokeAsync-callback methods in the AxisInvocationController. The sync had already been implemented in a previous defect. Also, I've updated the BaseDispatch to use this rather than the original AxisController. This brings us much closer to removing the AxisController API in favor of the AxisInvocationController. The changes to the async impl requires updates to the callbacks that are used. Specifically, the AsyncResponse/AsyncResponseProcessor have been renamed to be a little more intuitive. The AsyncListener is the task that will wait for the async response to come back. This will be wrapped in an AsyncListenerWrapper that controls the starting and stopping. This AsyncListenerWrapper is what will be used by the JAX-WS client to determine if a response is available or not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
