[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
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java
[Axis2] Re: svn commit: r835113 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/client/ServiceClient.java
Ignoring the performance degradation for a moment, the
AUTO_OPERATION_CLEANUP feature had removed thread-safety from the
ServiceClient (i.e. if two threads invoke
serviceclient.createClient(...), there is the distinct possibility that,
before Roy's modification, the code would have cleaned up the transport
before the first invoking thread had finished.)
If the ServiceClient is not meant to be thread-safe, then this needs to
be explicitly stated in the JavaDoc and the JAX-WS code will need to be
reworked to take this into account.
If the ServiceClient is supposed to be thread-safe, then either the
default should remain as Roy has set it (i.e. to be 'false') or the
cleanup code needs to be rewritten so as not to cause threading issues.
-Bill
On Thu, 2009-11-12 at 17:44 -0600, Roy Wood wrote:
Andreas,
Yes, I agree...thanks for the correction. I went back and did a quick
search on AUTO_OPERATION_CLEANUP and didn't find any intent on what
the
actual default should be, other than the original code using a default
of 'true'.
This property came to our attention when we ran into a threading
problem in one of our test cases. By setting the default to false,
thus disabling the call to
'cleanupTransport' in createClient, the threading problem disappeared.
I'm also a bit concerned about the performance warning in
cleanupTransport
javadocs. For that reason, as well as, providing a degree backwards
compatability, I would like to propose that the default for this
property be 'false'.
Roy A. Wood, Jr.
WebSphere Development - Web Services
wood...@us.ibm.com
512-286-9307 T/L:363-9307
11501 Burnet Road, Austin TX 78758 (Internal ZIP: 9372)
Re: svn commit: r835113
-
/webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/client/ServiceClient.java
Andreas
Veithen
to:
axis-dev
11/12/2009 03:30 PM
Cc:
Glen
Daniels
Please respond to
axis-dev
__
That is not correct. The entire Javadoc of the cleanupTransport method
was written before the introduction of the AUTO_OPERATION_CLEANUP
property. It only refers to callTransportCleanup, which is a
different property. Since the AUTO_OPERATION_CLEANUP feature is
something that has been recently introduced by Glen for the 1.5.1
release, it would be good to start a discussion to get his feedback if
you think that the default value should be different for the next
release.
Andreas
On Wed, Nov 11, 2009 at 23:54, wood...@apache.org wrote:
Author: woodroy
Date: Wed Nov 11 22:54:35 2009
New Revision: 835113
URL: http://svn.apache.org/viewvc?rev=835113view=rev
Log:
Use proper default value of AUTO_OPERATION_CLEANUP property
Javadoc for cleanupTransport states the default value is 'false'
Modified:
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/client/ServiceClient.java
Modified:
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/client/ServiceClient.java
URL:
http://svn.apache.org/viewvc/webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/client/ServiceClient.java?rev=835113r1=835112r2=835113view=diff
==
---
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/client/ServiceClient.java
(original)
+++
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/client/ServiceClient.java
Wed Nov 11 22:54:35 2009
@@ -660,7 +660,7 @@
public OperationClient createClient(QName operationQName) throws
AxisFault {
// If we're configured to do so, clean up the last
OperationContext (thus
// releasing its resources) each time we create a new one.
-if
(JavaUtils.isTrue(getOptions().getProperty(AUTO_OPERATION_CLEANUP),
true)
+if
(JavaUtils.isTrue(getOptions().getProperty(AUTO_OPERATION_CLEANUP),
false)
!getOptions().isUseSeparateListener()) {
cleanupTransport();
}
Re: [VOTE] Web Services Reorg Part 1 : Axis2 TLP
+1 -Bill On Fri, 2009-11-06 at 09:20 -0800, Glen Daniels wrote: Greetings, everyone. A bunch of us here at ApacheCon were talking about the Axis2 TLP idea, and how to move this forward in the simplest and most effective way. We came up with *exactly* the same structure that we had proposed a year ago. :) So, having only altered the page in order to remove a step (the promotion of WS-Commons sub-sub-projects to WS subprojects - this isn't really necessary as we can still decide what to do about each sub-sub-project individually later), I'd like to bring the following proposal up for a VOTE of the Web Services PMC. If this passes, I plan to submit this resolution to the board as soon as possible. http://wiki.apache.org/ws/FrontPage/Proposals/Axis2TLPProposal Note that I added just the first few people in the current PMC roster as examples. I also nominated myself as the Axis2 chair for now - if anyone else would like to volunteer to do this, please let me know. Eventually I'd like to drop one or the other PMC chair role, but for now I'm OK doing both. So if you would, please: 1) VOTE 2) Add yourself to the list of project members on the wiki page if you are an existing PMC member and would like to be on the new Axis2 PMC Here is my +1 for this proposal. Thanks, --Glen
Re: [Axis2] Update to JAX-WS 2.2
(I forgot the [Axis2] prefix on my original note -- sorry to anyone who missed it.) If they are necessary to pass the CTS test suites, then yes. Otherwise I can't make any promises. -Bill On Fri, 2009-10-30 at 23:15 +0530, Isuru Suriarachchi wrote: Hi Bill, AFAIK, there are some WSDL generation issues in our JAX-WS implementation. Specially when Complex types are involved. Are you going to address those issues as well during this improvement? Thanks, ~Isuru On Fri, Oct 30, 2009 at 7:22 PM, Bill Nagy n...@watson.ibm.com wrote: I just wanted to give everyone a heads-up that we are going to start upgrading the JAX-WS support to conform to the 2.2 spec relatively soon. The spec update may be found at http://jcp.org/en/jsr/detail?id=224. -Bill
Update to JAX-WS 2.2
I just wanted to give everyone a heads-up that we are going to start upgrading the JAX-WS support to conform to the 2.2 spec relatively soon. The spec update may be found at http://jcp.org/en/jsr/detail?id=224. -Bill
Re: [Axis2][VOTE] Axis2 1.4 FINAL - Take #2
+1 -Bill On Sat, 2008-04-26 at 12:05 -0400, Davanum Srinivas wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Folks, Firstly, Many thanks to Dan Kulp for reviewing the previous cut. I've moved the old directory away (to FINAL-TAKE1 under http://people.apache.org/~dims/axis2-1.4/) and placed the new files. So please review: http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ The m2 repository is here: http://people.apache.org/~dims/axis2-1.4/FINAL/m2-repo/ SVN Info: revision is 651799 on https://svn.apache.org/repos/asf/webservices/axis2/branches/java/1_4 Here's my +1 to declaring the above dist as Axis2 1.4 FINAL. Thanks, dims PS: Here are links to the individual Zip/Jar/Mar files: http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/1_4/axis2-1.4-bin.zip http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/1_4/axis2-1.4-docs.zip http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/1_4/axis2-1.4-src.zip http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/1_4/axis2-1.4-war.zip http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/modules/addressing/1_4/addressing-1.4.mar http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/modules/soapmonitor/1_4/soapmonitor-1.4.mar http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/tools/1_4/axis2-aar-maven-plugin-1.4.jar http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/tools/1_4/axis2-ant-plugin-1.4.jar http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/tools/1_4/axis2-eclipse-codegen-wizard-1.4.zip http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/tools/1_4/axis2-eclipse-service-archiver-wizard-1.4.zip http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/tools/1_4/axis2-idea-plugin-1.4.zip http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/tools/1_4/axis2-java2wsdl-maven-plugin-1.4.jar http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/tools/1_4/axis2-mar-maven-plugin-1.4.jar http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/tools/1_4/axis2-wsdl2code-maven-plugin-1.4.jar PPS: FYI, The Apache SVN is down for an outage/maintainenance. You can see the diffs on axis-cvs mailing list if you are curious. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFIE1KygNg6eWEDv1kRAu7wAKDVq0+uCdEWjZosM8Pm1ApUU8NvUwCfW+i0 jC6ej20Yz6dNAYP71wO0xTY= =1WnY -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][VOTE] Axis2 1.4 FINAL
+1 -Bill On Thu, 2008-04-24 at 12:39 -0400, Davanum Srinivas wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Folks, After all the excitement of the past few days :) We almost forgot the release Please review: http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ The m2 repository is here: http://people.apache.org/~dims/axis2-1.4/FINAL/m2-repo/ SVN Info: revision is 651268 on https://svn.apache.org/repos/asf/webservices/axis2/branches/java/1_4 Here's my +1 to declaring the above dist as Axis2 1.4 FINAL. Thanks, dims PS: Here are links to the individual Zip/Jar/Mar files: http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/1_4/axis2-1.4-bin.zip http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/1_4/axis2-1.4-docs.zip http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/1_4/axis2-1.4-src.zip http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/1_4/axis2-1.4-war.zip http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/modules/addressing/1_4/addressing-1.4.mar http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/modules/soapmonitor/1_4/soapmonitor-1.4.mar http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/tools/1_4/axis2-aar-maven-plugin-1.4.jar http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/tools/1_4/axis2-ant-plugin-1.4.jar http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/tools/1_4/axis2-eclipse-codegen-wizard-1.4.zip http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/tools/1_4/axis2-eclipse-service-archiver-wizard-1.4.zip http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/tools/1_4/axis2-idea-plugin-1.4.zip http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/tools/1_4/axis2-java2wsdl-maven-plugin-1.4.jar http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/tools/1_4/axis2-mar-maven-plugin-1.4.jar http://people.apache.org/~dims/axis2-1.4/FINAL/dist/ws/axis2/tools/1_4/axis2-wsdl2code-maven-plugin-1.4.jar -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFIELfTgNg6eWEDv1kRAtDoAJ9xOJrbhAlQoSnVl7I79C3gDOEFDQCgi7Vy gtoyG/P/Q3RWxIk1wwBphl0= =QD87 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] XmlSchema 1.4.1 / Axiom 1.2.6 / Neethi 2.0.3 Releases for Axis2 1.4
+1 for all -Bill On Thu, 2008-04-10 at 00:47 -0400, Davanum Srinivas wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Folks, Here are the src/bin dist artifacts, the maven2 repo and a revisions.txt with the svn information: http://people.apache.org/~dims/axis2-1.4-commons/ Please VOTE: [ ] - Ship XmlSchema 1.4.1 [ ] - Don't Ship XmlSchema 1.4.1 [ ] - Ship Axiom 1.2.6 [ ] - Don't Axiom 1.2.6 [ ] - Ship Neethi 2.0.3 [ ] - Don't Ship Neethi 2.0.3 Here's my +1 for all 3 distributions. thanks, dims -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFH/ZvsgNg6eWEDv1kRApoAAKDQAsT7hCrn2BruP6c7N6qwvQuIAACeMnhU grBUP5S3B0dYtfu6jMulw38= =tEtH -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[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]
Re: [axis2] Handler interface (cleanup(), flowComplete() and errors)
Hi Glen, On Fri, 2007-06-22 at 12:52 -0400, Glen Daniels wrote: A few questions about the Handler interface based on recent conversations: 1) cleanup() never gets called. Can we remove it now that we've got flowComplete()? I had always assumed that cleanup() was the counterpart to init(), and thus would be called when a handler was deregistered thereby providing the handler with the ability to release resources that it had acquired. I'm happy to have it removed until someone actually needs that type of functionality. 2) flowComplete() seems somewhat flawed in that there is currently no way (AFAICT) to conclusively determine whether it is being called as a result of a fault/thrown exception or due to the normal termination of processing. This leaves no easy way for Handler developers to do rollbacks of any work they've done. It appears we used to have revoke(), which I think seems like the right thing (it's easier to code an explicit fault handler API than it is to remember to check for something that the compiler won't tell you about), but that was apparently replaced with flowComplete()? PROPOSAL - add a failureReason field (of type Exception) to MessageContext, and ensure that the engine ALWAYS sets this if we have to back out the processing chain due to an error. Leave flowComplete() as is, but now implementors can mc.getFailureReason() and react appropriately. +1 3) Why are we forcing every Handler to keep a pointer to it's HandlerDesc? We only call this in a couple of places (Phase), and IMHO it clutters up the interface unnecessarily. It seems like Phase should be keeping HandlerDescs, and those should be pointing to Handlers... that would more loosely and cleanly decouple the two classes. I assume that you mean removing the getHandlerDesc() method (and not removing the HandlerDescription being passed into the Handler) -- +1 if we're already modifying the Handler interface to remove the cleanup() method. Comments/thoughts? If we're only going to do (1) or (3), but not both, then perhaps we shouldn't do either unless it provides a great enough improvement to the code quality such that it's worth forcing users to modify their implementations. Thanks, --Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] API Change - Handler flowComplete
I purposely did not allow flowComplete(...) to throw an exception, as I have no idea what the runtime could possibly do if that occurs seeing as how all of the important work will have already been done and the connections most likely terminated. I would prefer that we leave the interface explicit in this manner (i.e. not make handlers think that the runtime can/will do something useful with an exception by specifying it in the interface) unless we have a valid use case that says otherwise. I believe that given the semantics of what flowComplete(...) is trying to accomplish, that simply logging the exception is a valid means of dealing with it. -Bill On Mon, 2007-03-12 at 15:52 +0530, Chamikara Jayalath wrote: Hi David, On 3/12/07, David Illsley [EMAIL PROTECTED] wrote: So it's valid to do post MR work in flowComplete but swallow exceptions if they occur. The clearest example (in my mind) is removing a transaction from a thread. That itself could have a failure but it shouldn't prevent the other flocwCompletes bing called. From the original proposal: (If the flowComplete(...) method throws an exception, the rest of the handlers must still have their flowComplete(...) methods invoked.) We could wrap the calls to flowComplete with a catch block, ensure all the flowCompletes are called and then throw a new exception with the rootCause of the fist exception caught. That looks like a good option. Will try to implement that. Chamikara David On 12/03/07, Chamikara Jayalath [EMAIL PROTECTED] wrote: Hi David, See your point. We need to clearly define the semantics here. With my change, once an exception get thrown the rest of the handlers will not be called. I was using the flowComplete method as a way to do some post MR work (both here and in Sandesha2). If we do not throw out an exception, that should not be recommended. (In that case I will revert my change). Chamikara On 3/12/07, David Illsley [EMAIL PROTECTED] wrote: Hmm, I'm not sure that an exception there is the right thing to do... but I'll take a look at the code and get back to you. I do have a concern that the whole point of flowComplete is to let handlers get a callback when the flow is complete. If one of them thows an AxisFault, will the remaining handlers get flowComplete called? David On 12/03/07, Chamikara Jayalath [EMAIL PROTECTED] wrote: Yep. (just committed this). In the clustering impl I needed to do some replication stuff in the flowComplete method. Didn't want to eat up exceptions with only a log :-) Chamikara On 3/12/07, David Illsley [EMAIL PROTECTED] wrote: Hi, I imagine there's a reason why you want to do this...? David On 11/03/07, Chamikara Jayalath [EMAIL PROTECTED] wrote: Hi All, Currently the Handler.flowComplete method does not throw any exceptions. Shall we change this to throw out an AxisFault ? Chamikara -- David Illsley - IBM Web Services Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- David Illsley - IBM Web Services Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- David Illsley - IBM Web Services Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
Re: [Axis2] API Change - Handler flowComplete
Hi Chamikara, If you are doing work that is a critical part of the interaction, and where an error needs to be communicated back to the requestor, then that work should be completed before the response message (assuming that the operation isn't one-way) is sent, so that that fault can be returned as the response -- we don't have a MEP that supports any other style of interaction (e.g. sending a response followed by a fault.) This can either be accomplished by placing the logic in the output flow (for req/rsp) or placing the entire req under a transaction. -Bill On Mon, 2007-03-12 at 20:36 +0530, Chamikara Jayalath wrote: Hi Bill, What do u think of the use case where some handler want to do some post-MR work. But still it may want to let the client know of any exceptions that occured (through a SOAP fault). And as David sugested, we can make sure that the flowComplete of all the handlers get called by enclosing it's invocation within a try block and sending only the very first exception to the client. Chamikara On 3/12/07, Bill Nagy [EMAIL PROTECTED] wrote: I purposely did not allow flowComplete(...) to throw an exception, as I have no idea what the runtime could possibly do if that occurs seeing as how all of the important work will have already been done and the connections most likely terminated. I would prefer that we leave the interface explicit in this manner (i.e. not make handlers think that the runtime can/will do something useful with an exception by specifying it in the interface) unless we have a valid use case that says otherwise. I believe that given the semantics of what flowComplete(...) is trying to accomplish, that simply logging the exception is a valid means of dealing with it. -Bill On Mon, 2007-03-12 at 15:52 +0530, Chamikara Jayalath wrote: Hi David, On 3/12/07, David Illsley [EMAIL PROTECTED] wrote: So it's valid to do post MR work in flowComplete but swallow exceptions if they occur. The clearest example (in my mind) is removing a transaction from a thread. That itself could have a failure but it shouldn't prevent the other flocwCompletes bing called. From the original proposal: (If the flowComplete(...) method throws an exception, the rest of the handlers must still have their flowComplete(...) methods invoked.) We could wrap the calls to flowComplete with a catch block, ensure all the flowCompletes are called and then throw a new exception with the rootCause of the fist exception caught. That looks like a good option. Will try to implement that. Chamikara David On 12/03/07, Chamikara Jayalath [EMAIL PROTECTED] wrote: Hi David, See your point. We need to clearly define the semantics here. With my change, once an exception get thrown the rest of the handlers will not be called. I was using the flowComplete method as a way to do some post MR work (both here and in Sandesha2). If we do not throw out an exception, that should not be recommended. (In that case I will revert my change). Chamikara On 3/12/07, David Illsley [EMAIL PROTECTED] wrote: Hmm, I'm not sure that an exception there is the right thing to do... but I'll take a look at the code and get back to you. I do have a concern that the whole point of flowComplete is to let handlers get a callback when the flow is complete. If one of them thows an AxisFault, will the remaining handlers get flowComplete called? David On 12/03/07, Chamikara Jayalath [EMAIL PROTECTED
Re: [AXIS2] Holding response in HTTPWorker
Hi Keith,
The relevant commits are:
Revision 489259 - (view) (download) (annotate) - [select for diffs]
Modified Thu Dec 21 03:39:21 2006 UTC (2 months, 1 week ago) by
chamikara
File length: 13755 byte(s)
Diff to previous 487227 (colored)
Added a mechanism to give the current state of the RequestResponseTransport.
This could be used by RM
in resending of messages. Message will be allowed to be resent only if the
RequestResponseTranspor object
is in the correct state.
Added a mechanism to allow somebody to set an custom transport response code.
For e.g. Sandesha2 has a requirement to return HTTP 408, but there was not way
do do this in Axis2.
Added a boolean property which should be used by transports to decide weather
or not a certain request
thread should be blocked (by calling RequestResponseTransport.awaitResponse ()
) object. Simply doing
this based on wehater or not the request has been is paused is not enough in
some cases.
Please see javadocs for more details.
and
Revision 481505 - (view) (download) (annotate) - [select for diffs]
Modified Sat Dec 2 05:38:19 2006 UTC (2 months, 3 weeks ago) by nagy
File length: 13301 byte(s)
Diff to previous 475355 (colored)
Extended RequestResponseTransport to allow the transport to block after control
is returned (e.g. if the
message is paused) and then resume once a response is available. This will
enable RM to be used for
IN-OUT MEPs over a request/response transport.
In short, it's required for RM to support a request/response transport in a
request/response fashion
(i.e. not as a one-way connection.) Since you can't really use RM with those
other verbs,
I don't really have another use case right now where it would make sense to
replicate that code.
-Bill
On Wed, 2007-02-28 at 11:40 +0530, keith chapman wrote:
Hi,
I was working on adding HTTP methods PUT and DELETE to HTTPWorker so
that we can get that support. This code appears at the end of handling
HTTP POST.
Boolean holdResponse = (Boolean) msgContext.getProperty
(RequestResponseTransport.HOLD_RESPONSE);
if (pi.equals(InvocationResponse.SUSPEND) ||
(holdResponse != null Boolean.TRUE.equals(holdResponse))) {
try {
((RequestResponseTransport)msgContext.getProperty(
RequestResponseTransport.TRANSPORT_CONTROL)).awaitResponse();
}
catch (InterruptedException e) {
throw new IOException(We were interrupted, so this
may not function correctly:+ e.getMessage());
}
}
Whats the reason for having this in the POST case? It does not appear
in the GET. Was wondering whether its needed for PUT too.
Does anybody know the reason for this code?
Thanks,
Keith.
--
Keith Chapman
WSO2 Inc.
Oxygen for Web Services Developers.
http://wso2.org/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axis2] Pinging capability to services deployed in Axis2
[I'm a little late to the conversation but anyways...] I vote against extending the MessageReceiver interface -- unless you go to the service itself (i.e. actually invoke part of its logic,) you're going to end up with responses whose meanings you can't interpret (e.g. This service said that it was up, but it's using the Axis2 programming model so that means ..., and this service said that it was up, but it's using the JAX-WS programming model so that means ..., and this service said that it was up, but I have no idea what it's using so) If you want true service status, then implement that as part of your exposed interface. On the other hand, I think that implementing 'ping' as a module that exposes a 'ping' operation is a fine idea; what you would get is a consistent answer -- whether or not the service is 'available' from the runtime's perspective. That's what the pinging a machine's network interface gives you -- the answer to whether or not the pinged interface is active. -Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axis2] Pinging capability to services deployed in Axis2
Hi Paul, I'm disagreeing with (2) and (3) (and was agreeing with (1).) My problem is that the semantics associated with the response to the ping are not captured anywhere and may, in fact, vary between services -- i.e. somebody accessing the ping service has no idea what the ping response actually indicates. If the ping is implemented solely as a module, without any special hooks into MessageReceivers etc., then every ping to a service indicates that the server is aware of the service and is able to handle requests for it. If a service wants to provide something more specific, then that ability should be explicit within its interface and a user should be expected to consult the service for the extended semantics. If the deployment code wants to do more checking in each case, before it allows a service to be deployed, I'm fine with that. I'm not OK with a service (which requires changes to the core interfaces) being defined over the entire runtime that behaves in an inconsistent fashion. -Bill On Mon, 2007-02-12 at 14:40 +, Paul Fremantle wrote: Bill Maybe I misunderstood the discussion, but I thought we had the following approach in mind. 1) Implement a ping module. This does its best to let you know if the service is up. 2) Add a new interface (e.g. PingableMR) that MR's may implement. This allows the ping module to ask the MR if the service is up. (better than just the module's answer). For example the MR may try to new up an instance of the Service class (if that is appropriate) to ensure classloading is working. 3) The MR that implements the PingableMR interface can see if the service implements the PingableService interface. If this is the case then the MR will call that method. This will allow the service itself to test things (such as connections to databases, classloading, whatever). This is the best test. Unless you deploy the Ping module then none of this is exposed. Paul On 2/12/07, Bill Nagy [EMAIL PROTECTED] wrote: [I'm a little late to the conversation but anyways...] I vote against extending the MessageReceiver interface -- unless you go to the service itself (i.e. actually invoke part of its logic,) you're going to end up with responses whose meanings you can't interpret (e.g. This service said that it was up, but it's using the Axis2 programming model so that means ..., and this service said that it was up, but it's using the JAX-WS programming model so that means ..., and this service said that it was up, but I have no idea what it's using so) If you want true service status, then implement that as part of your exposed interface. On the other hand, I think that implementing 'ping' as a module that exposes a 'ping' operation is a fine idea; what you would get is a consistent answer -- whether or not the service is 'available' from the runtime's perspective. That's what the pinging a machine's network interface gives you -- the answer to whether or not the pinged interface is active. -Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axis2] Clustering prototype available
When you guys get to a state that you are happy with, could you please generate and post a diff between your branch and the trunk, so those of us that are time-impaired can be clear as to exactly what is being done? Thanks. -Bill On Mon, 2007-02-12 at 11:42 -0500, Rajith Attapattu wrote: A big +1 for this proposal. 2. Do not call the ContextListner in property get, set methods. - These events will not be captured by the listener. In my opinion this is key for performance. Now this gives rise to the problem waiting to long for replication, especially in the case of long running invocations or asynch invocations (where the message receiver returns before the business logic is fully executed. To counter that we disscussed on the other clustering thread the following proposal. We can introduce two modes. 1) Container Managed replication 2) Service Managed replication. Container managed replication will call update state when the container things it's time to do so. With user managed replication the service author has the discreetion in calling updateState when ever he wants. The service author can call it for every property change or at any given point as the author things it's appropriate. If we can get the ContextListerner going on the trunk we can quiclky add that to the cluster branch. Deepal ? Rajith On 2/12/07, Chamikara Jayalath [EMAIL PROTECTED] wrote: Hi Rajith, All, ReplicationHandler can be placed at various places of the Handler chain and it does replication both at its 'invoke' and 'flowComplete' methods. FlowComplete methods get called after the invocation of the MessageReceiver, so the state of the contexsts get replicated without a problem even in the InOnly case. Introducing this handler made things more flexible and reduced coupling. I have another suggestion that could reduce coupling further. The idea is to introduce a ContextListner. This will get called in specific places like, 1. When a context get created 2. When a context get removed 3. When a context get flushed. If we can have this feature we will be able to move clustering code into a module. At initiation this module will register a ContextListener which will allow it to listen to context updates. For having a minimum affect on the performance there are several things we can do. 1. Do not initialize the ContextListner Map until the first Listener is added. - This reduces the load to a 'null' check when no listeners are available. 2. Do not call the ContextListner in property get, set methods. - These events will not be captured by the listener. 3. Not all the contexts should call the listeners. - For e.g. we may decide not to call the ContextListeners for events of the MessageContexts. This will not have any performance drawback from the approach we are following now. But it will allow us to fully decouple clustering code from the kernel. What do u think ? Chamikara On 2/12/07, Rajith Attapattu [EMAIL PROTECTED] wrote: Hey Chamikara, Thanks for making the changes, I was busy with Qpid work so couldn't even do the Null change we discussed. However I have a concern about moving updateState from the Engine and placing this in a handler. The handler approach will only work if the MEP is IN_OUT. If this is a IN_ONLY operation then there is no outflow, so update state wan't be called. That is why I put it in the engine. (see the disscussion on the other clustering thread, about using flowComplete() as a replication point) Regards, Rajith On 2/12/07, Chamikara Jayalath [EMAIL PROTECTED] wrote: Hi Deepal, On 2/12/07, Deepal Jayasinghe [EMAIL PROTECTED] wrote: Hi Chamikara; Hi Rajith, All, I did some changes to the clustering code. Please send your comments ...
Re: [Axis2] Adding ClusterManager code the the codebase
What is the cost of this going to be for someone who doesn't want
clustering/this particular approach to clustering? I can't infer much
from the interface -- exactly which respective events are you referring
to?
-Bill
On Thu, 2007-02-01 at 23:16 +0530, Chamikara Jayalath wrote:
At initiation Axis2 will load a ClusterManager implementation object
(if configured) and will call the methods of it whenever respective
events occur.
Chamikara
[1] ClusterManager interface
public abstract class ClusterManager {
public abstract void init (ConfigurationContext context);
public abstract void addContext (AbstractContext context);
public abstract void removeContext (AbstractContext context);
public abstract void addProperty (AbstractContext context, String
propertyName, Object propertyValue);
public abstract void removeProperty (AbstractContext context,
String propertyName);
public abstract void touchProperty (AbstractContext context,
String propertyName);
public abstract void commit ();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Adding ClusterManager code the the codebase
That's what I inferred from the interface -- any time there is a context
change or a property change, you want your interface to be invoked.
That's an awful lot of method invocations (even if they're no-ops) for
something arguably not core to a web services runtime.
-Bill
On Tue, 2007-02-06 at 21:32 +0530, Chamikara Jayalath wrote:
Hi Dims,
As this is still is its design stage final approach hs not been
decided. The current code is available in a branch so no affect on the
performance of the trunk.
A method of the ClusterManager instance hs to be called in events such
as Context creation and removal. Currently these directly get called
from respective places of the context classes (should happen only if a
ClusterManager hs been set i.e. when clustering is enabled).
Chamikara
On 2/6/07, Davanum Srinivas [EMAIL PROTECTED] wrote:
Chamikara,
New notifications? like what we have already for
services/modules?
-- dims
On 2/6/07, Chamikara Jayalath [EMAIL PROTECTED] wrote:
Hi Bill, Dims,
The ClusterManager impl will be initiated with the
ConfigContext. This will
be called in places like Context Creation and removal and
may be property
updates (hvnt fully decided yet). When Clustering is not
present the cost
should be reduced to a null check.
Chamikara
On 2/6/07, Davanum Srinivas [EMAIL PROTECTED] wrote:
Bill,
from what i understand, it's in a separate maven module.
Not in
kernel. So you can ignore it :)
-- dims
On 2/6/07, Bill Nagy [EMAIL PROTECTED] wrote:
What is the cost of this going to be for someone who
doesn't want
clustering/this particular approach to clustering? I
can't infer much
from the interface -- exactly which respective events
are you referring
to?
-Bill
On Thu, 2007-02-01 at 23:16 +0530, Chamikara Jayalath
wrote:
At initiation Axis2 will load a ClusterManager
implementation object
(if configured) and will call the methods of it
whenever respective
events occur.
Chamikara
[1] ClusterManager interface
public abstract class ClusterManager {
public abstract void init (ConfigurationContext
context);
public abstract void addContext (AbstractContext
context);
public abstract void removeContext
(AbstractContext context);
public abstract void addProperty (AbstractContext
context, String
propertyName, Object propertyValue);
public abstract void removeProperty
(AbstractContext context,
String propertyName);
public abstract void touchProperty
(AbstractContext context,
String propertyName);
public abstract void commit ();
}
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
Davanum Srinivas :: http://wso2.org/:: Oxygen for Web
Services Developers
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web
Services Developers
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2]Re: svn commit: r503499 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/context/MessageContext.java
Hi dims,
I am worried about the ease of use of developers, but not necessarily in
this particular case. What I am worried about, however, is requiring
people to recycle their application server (restart their JVM) in
production environments simply to alter logging levels to debug an
issue. If you want to skip the isDebugEnabled(...) etc, do something
like:
private static final boolean loggingEnabled =
(System.getProperty(Axis2.disableLogging) == null);
if (loggingEnabled isDebugEnabled(...))
{
log.debug(...);
}
(I would also put that System.getProperty(...) in a single class so that
you don't have every class invoke it [an expensive op] on loading.)
-Bill
On Mon, 2007-02-05 at 04:29 -0500, Davanum Srinivas wrote:
Bill,
Am not worried about ease of use of the developers. This thing needs
to perform in a production environment. If it wastes 5 mins of
developer time in editing code. So be it!
thanks,
dims
On 2/5/07, Bill Nagy [EMAIL PROTECTED] wrote:
Hi dims,
Thank you for wrapping those, but 2 points: (1) they need to be wrapped
with a log.isWarnEnabled(...) and not a log.isDebugEnabled(...), as the
output message is log.warn(...) and not log.debug(...) and (2) please
don't use a static (and especially a static final) to control logging,
because that prevents users from changing log levels after a class has
been loaded. Thanks.
-Bill
On Sun, 2007-02-04 at 22:49 +, [EMAIL PROTECTED] wrote:
Author: dims
Date: Sun Feb 4 14:49:15 2007
New Revision: 503499
URL: http://svn.apache.org/viewvc?view=revrev=503499
Log:
no need to call no-op methods that prints warnings unless debug is enabled
Modified:
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/context/MessageContext.java
Modified:
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/context/MessageContext.java
URL:
http://svn.apache.org/viewvc/webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/context/MessageContext.java?view=diffrev=503499r1=503498r2=503499
==
---
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/context/MessageContext.java
(original)
+++
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/context/MessageContext.java
Sun Feb 4 14:49:15 2007
@@ -88,6 +88,7 @@
* setup for logging
*/
private static final Log log =
LogFactory.getLog(MessageContext.class);
+private static final boolean isDebugEnabled = log.isDebugEnabled();
/**
* @serial An ID which can be used to correlate operations on a
single
@@ -570,12 +571,16 @@
}
public AxisOperation getAxisOperation() {
-checkActivateWarning(getAxisOperation);
+if(isDebugEnabled) {
+checkActivateWarning(getAxisOperation);
+}
return axisOperation;
}
public AxisService getAxisService() {
-checkActivateWarning(getAxisService);
+if(isDebugEnabled) {
+checkActivateWarning(getAxisService);
+}
return axisService;
}
@@ -585,12 +590,16 @@
* so the service might not match up with this serviceGroup
*/
public AxisServiceGroup getAxisServiceGroup() {
-checkActivateWarning(getAxisServiceGroup);
+if(isDebugEnabled) {
+checkActivateWarning(getAxisServiceGroup);
+}
return axisServiceGroup;
}
public ConfigurationContext getConfigurationContext() {
-checkActivateWarning(getConfigurationContext);
+if(isDebugEnabled) {
+checkActivateWarning(getConfigurationContext);
+}
return configurationContext;
}
@@ -610,7 +619,9 @@
}
public ArrayList getExecutionChain() {
-checkActivateWarning(getExecutionChain);
+if(isDebugEnabled) {
+checkActivateWarning(getExecutionChain);
+}
return executionChain;
}
@@ -646,7 +657,9 @@
*/
public Iterator getInboundExecutedPhases()
{
-checkActivateWarning(getInboundExecutedPhases);
+if(isDebugEnabled) {
+checkActivateWarning(getInboundExecutedPhases);
+}
if (inboundExecutedPhases == null)
{
inboundExecutedPhases = new LinkedList();
@@ -698,7 +711,9 @@
*/
public Iterator getOutboundExecutedPhases()
{
-checkActivateWarning(getOutboundExecutedPhases);
+if(isDebugEnabled) {
+checkActivateWarning(getOutboundExecutedPhases);
+}
if (outboundExecutedPhases == null)
{
outboundExecutedPhases = new LinkedList
Re: [Axis2] Re: [continuum] BUILD FAILURE: Axis2
Thanks Jeremy. I could swear that I tried to do that last night and that what I got didn't have the target directory under modules, so I just thought that it was just the pure source tree. Unfortunately now the previous build has gotten erased so I can't see what went wrong. -Bill On Sat, 2007-02-03 at 06:50 +, Jeremy Hughes wrote: On 03/02/07, Bill Nagy [EMAIL PROTECTED] wrote: How do I (can I?) get at the test report logs for the continuum build? I didn't see anything off of the continuum page except for the log that was in the body of the notification. I assume that, for example, the logs for JAX-WS are at /export/home/illsleyd/continuum/continuum-1.0.3/apps/continuum/working-directory/1/modules/jaxws/target/test-reports, but I have no idea how/if I can get at that directory. You can access the working copy the Continuum server has for each project. The directory you specify is here: http://ws.zones.apache.org:1/continuum/servlet/continuum/target/WorkingCopy.vm/view/WorkingCopy/id/1?userDirectory=modules/jaxws/target/test-reports Cheers, Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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]
[Axis2] Re: [continuum] BUILD FAILURE: Axis2
How do I (can I?) get at the test report logs for the continuum build? I didn't see anything off of the continuum page except for the log that was in the body of the notification. I assume that, for example, the logs for JAX-WS are at /export/home/illsleyd/continuum/continuum-1.0.3/apps/continuum/working-directory/1/modules/jaxws/target/test-reports, but I have no idea how/if I can get at that directory. -Bill - 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]
[Axis2] Re: svn commit: r501805 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/client/OperationClient.java
Can we please come to an agreement to fix a single issue in a commit and
not to make unrelated formatting or other changes at the same time? It
makes it much more difficult to figure out what has been done if you do
that. (Note that I'm not saying that multiple things can't change if
they are related to the same issue/feature, just that we should try to
eliminate irrelevant changes within the same commit.) Thanks.
-Bill
On Wed, 2007-01-31 at 11:32 +, [EMAIL PROTECTED] wrote:
Author: deepal
Date: Wed Jan 31 03:32:17 2007
New Revision: 501805
URL: http://svn.apache.org/viewvc?view=revrev=501805
Log:
fixing 1857
- rather than just keeping parent option object inside opclient ,
changed to create new option putting parent option as parent.
Modified:
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/client/OperationClient.java
Modified:
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/client/OperationClient.java
URL:
http://svn.apache.org/viewvc/webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/client/OperationClient.java?view=diffrev=501805r1=501804r2=501805
==
---
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/client/OperationClient.java
(original)
+++
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/client/OperationClient.java
Wed Jan 31 03:32:17 2007
@@ -25,11 +25,11 @@
import org.apache.axis2.context.OperationContext;
import org.apache.axis2.context.ServiceContext;
import org.apache.axis2.description.AxisOperation;
-import org.apache.axis2.description.TransportOutDescription;
import org.apache.axis2.description.ClientUtils;
+import org.apache.axis2.description.TransportOutDescription;
import org.apache.axis2.i18n.Messages;
-import org.apache.axis2.util.UUIDGenerator;
import org.apache.axis2.util.TargetResolver;
+import org.apache.axis2.util.UUIDGenerator;
import org.apache.axis2.wsdl.WSDLConstants;
import java.util.Iterator;
@@ -47,31 +47,31 @@
*/
public abstract class OperationClient {
- protected AxisOperation axisOp;
-
- protected ServiceContext sc;
-
- protected Options options;
-
- protected OperationContext oc;
-
- protected Callback callback;
-
- /*
- * indicates whether the MEP execution has completed (and hence
ready for
- * resetting)
- */
- protected boolean completed;
-
- protected OperationClient(AxisOperation axisOp, ServiceContext
sc,
- Options options) {
- this.axisOp = axisOp;
- this.sc = sc;
- this.options = options;
- this.completed = false;
- this.oc = new OperationContext(axisOp);
- this.oc.setParent(this.sc);
- }
+protected AxisOperation axisOp;
+
+protected ServiceContext sc;
+
+protected Options options;
+
+protected OperationContext oc;
+
+protected Callback callback;
+
+/*
+* indicates whether the MEP execution has completed (and hence
ready for
+* resetting)
+*/
+protected boolean completed;
+
+protected OperationClient(AxisOperation axisOp, ServiceContext
sc,
+ Options options) {
+this.axisOp = axisOp;
+this.sc = sc;
+this.options = new Options(options);
+this.completed = false;
+this.oc = new OperationContext(axisOp);
+this.oc.setParent(this.sc);
+}
/**
* Sets the options that should be used for this particular
client. This
@@ -162,11 +162,11 @@
/**
- * To close the transport if necessary , can call this method.
The main
- * usage of this method is when client uses two tarnsports for
sending and
- * receiving , and we need to remove entries for waiting calls in
the
+ * To close the transport if necessary , can call this method.
The main
+ * usage of this method is when client uses two tarnsports for
sending and
+ * receiving , and we need to remove entries for waiting calls in
the
* transport listener queue.
- * Note : DO NOT call this method if you are not using two
transports to
+ * Note : DO NOT call this method if you are not using two
transports to
* send and receive
*
* @param msgCtxt : MessageContext# which has all the transport
information
@@ -215,7 +215,8 @@
protected void addReferenceParameters(MessageContext msgctx) {
EndpointReference to = msgctx.getTo();
-if (options.isManageSession()) {
+if (options.isManageSession() || (options.getParent() != null
+options.getParent().isManageSession())) {
EndpointReference tepr = sc.getTargetEPR();
if (tepr != null) {
Map map = tepr.getAllReferenceParameters();
@@ -232,7 +233,7 @@
Re: [Axis2] Issues with the current code base
Hi Rajith,
Usage of the serialization is/will be configurable through Sandesha --
Matt said that he would be adding code to do that (if it isn't there
already.) If the serialization doesn't get invoked, then all that will
occur will be a few no-op method invocations.
I don't agree with point 5 being a definite no no. I believe that it
is a matter of personal preference and if the author of the code
believes that it makes it easier to read and doesn't create issues then
so be it. Any reasonable editor today will have no difficulty locating
the definition if you need to look at it.
As I said, I certainly welcome any concerned party to show me (in
hard/accurate numbers) where the code does not perform and it will be
addressed.
-Bill
On Wed, 2007-01-31 at 10:24 -0500, Rajith Attapattu wrote:
I do have one question for Anne, is this serialization configurable ?
In other words can I switch off this behaviour if I don't want it?
(Pardon me for not going through the code to figure this out )
I also share the same concerns as Deepal about code conventions.
No matter what coding convention was followed, point 5 is a definite
no no.
Sanjiva, I am glad that you are requesting some benchmarking, I was
consistently proposing that Anne should subject this code through some
high volume message scenarios to figure out the performance impact.
The basis for my objections was that the overhead introduced by this
feature, out weighs the benefits of it. YMMV
Rajith
On 1/29/07, Deepal Jayasinghe [EMAIL PROTECTED] wrote:
Hi Bill,
Among the all , the most worst thing I saw in the code is
following kind
of things, I strongly believe we should not have this kind
of code in
the code base, If you found such kind of code please point
out them then
and there.
- String tmpClassNameStr = null; (is this the way we
initialize to
NULL )
- String tmpHasList = no list
- Unnecessary casting
- A number of unused variables
- Variable declarations here and there (as an example
private static
final String - selfManagedDataDelimiter = *;)
I'm indifferent on the first two; in some cases it makes the
code easier
to read and debug at the cost of an assignment and space in
the string
table.
Well , more focus should be for code readability than
debugging .
The third one should be caught by any decent compiler and
eliminated (so long as you're not casting back and forth) and
again
sometimes enhances readability so I'm indifferent on this one
as well.
I agree on the fourth -- I don't think that there's ever a
good case for
extraneous variables. The fifth is again a code readability
issue and
one of the reasons that Java doesn't require that you declare
everything
up front.
Thank's for trying to clarify all these points. Just hope not
everybody
will start writing code like this :-)
BTW in point 5, I was talking about class level 'public
static'
variables, not method level variables.
For e.g.
class {
public static v1;
method1 ();
public static v2();
method2();
}
I dont think this is the way to go.
Deepal.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Issues with the current code base
Hi Sanjiva, On Thu, 2007-02-01 at 21:33 +0530, Sanjiva Weerawarana wrote: On Thu, 2007-02-01 at 06:10 -0800, Bill Nagy wrote: Hi Rajith, Usage of the serialization is/will be configurable through Sandesha -- Matt said that he would be adding code to do that (if it isn't there already.) If the serialization doesn't get invoked, then all that will occur will be a few no-op method invocations. I don't agree with point 5 being a definite no no. I believe that it is a matter of personal preference and if the author of the code believes that it makes it easier to read and doesn't create issues then so be it. Any reasonable editor today will have no difficulty locating the definition if you need to look at it. I disagree- as an open source effort we should write in ways that everyone can easily read and understand. These conventions are not tailorable for personal preference! It seems to me that most people declare variables at the top and methods below. Is that such a hard convention to accept? I don't honestly think that anyone who we want to be writing code for the project would have trouble understanding code simply because braces weren't on the lines where they typically put them or that methods aren't named in the same way that they usually name them. With respect to this particular issue, I don't think that the vast majority of people go look for declarations by scrolling to the top of the file -- IDEs have made that unnecessary. I think that we simply disagree on where to draw the line for reasonable deviations from the rules. As I said, I certainly welcome any concerned party to show me (in hard/accurate numbers) where the code does not perform and it will be addressed. IMO its everyone's responsibility to make sure Axis2 performs well. Telling someone else to run perf tests, do profiling and then point out the place to fix is silly .. that person might as well fix it. Can't Ann write some tests and check the perf and confirm all is koshure?? I completely agree. The issues that have been raised so far, however, have all been of the form The code gets invoked on every invocation -- I don't like that. I was addressing those issues. I committed the code, therefore I am ultimately responsible for it. Before I did so, I read through it and did my best to make sure that it was not adversely effecting performance, and those are the points that I keep raising. Is this a lot of code that was changed/added? Certainly. Do I believe that it is isolated when not in use? Yes. I don't have to run performance tests simply because somebody says so when I'm comfortable with the logic of a particular change. Likewise, I don't believe that anybody runs performance tests for the vast majority of the changes that they make to the code, and they probably have thought about isolation a lot less than was done so for this particular change. Now if you want to raise the issue of performance when this particular branch of code is in use, that's a fair thing to look at. Right from the start, however, I will tell you that what existed before and what exists in the new code are not functionally equivalent. I'm not saying that the new code is slower or that if it is that it shouldn't be made to be faster -- I'm simply saying that it won't be comparing apples to apples. I'd prefer to be having this conversation with Ann .. not that I don't like to chat with you Bill ;-)). That's fine; she's free to speak up (as she did.) I was just aware that she was busy, and since I'm aware of the details I wanted to address your concerns as quickly as possible. Also, as I stated, I committed the code into the tree, and so am ultimately responsible for that commit. -Bill - 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]
Re: [Axis2] Issues with the current code base
Hi Deepal, On Mon, 2007-01-29 at 11:41 +0530, Deepal Jayasinghe wrote: Hi all; I just went though the current code base and realized that MessageContext code has been changed a lot . I found few issues with the code base and hope we need to fix them. So I thought of sending this mail for everyone's consideration. Well someone please explain to me whose going to need MessageContext serialization , Chamikara : Do you want that for Sandesha ? Ruchith : Do you want that for Security ? If none of you want this , who else need this ? As Matt pointed out, we went through this on an earlier discussion -- Sandesha is the intended consumer. I am asking this question b'coz introduction of MC serialization we have the following for each req. - When ever Axis2 received a message it calls activateMessageContext(msgContext); - And what that does is , it calls mc.activate(engineContext); method Unfortunately that method is TOO long and was very difficult to understand:). Ann can you simplify the method (that will be very helpful) . Actually, if you notice, the first line of MessageContext.activate(...) is a short-circuit test on needsToBeReconciled, which is only ever set when the MessageContext (and related parts) are deserialized using the MessageContext deserialization routines -- for all other cases, it ends up being a no-op so you can stop reading at that point 8-]. As for the method being too long, of the 306 lines in that method, 110 are comments/log messages, and the rest of the code consists of if-not-null-invoke-a-method blocks. Unfortunately the MessageContext has a lot of handles to other objects, so there need to be a number of those tests. If you're having difficulty understanding a particular section of that method, please ask and we'd be happy to explain it to you. I certainly think that the rest of the code could use some code bloat (i.e. comments) -- e.g. there are no class-level comments on ListenerManager, AxisConfiguration, PhaseResolver (just to name a few.) In the meantime code convention in MC has changed a lot and need to have very consistent code convention, please do not differ form that. This is the second time that code conventions have been mentioned (Sanjiva brought this up in an earlier discussion as well) -- I was not aware of these, and was unable to find anything in the docs that talk about them. (The Developer Guidelines only talk about the mailing list.) Could you please point me to where these are codified? Among the all , the most worst thing I saw in the code is following kind of things, I strongly believe we should not have this kind of code in the code base, If you found such kind of code please point out them then and there. - String tmpClassNameStr = null; (is this the way we initialize to NULL ) - String tmpHasList = no list - Unnecessary casting - A number of unused variables - Variable declarations here and there (as an example private static final String - selfManagedDataDelimiter = *;) I'm indifferent on the first two; in some cases it makes the code easier to read and debug at the cost of an assignment and space in the string table. The third one should be caught by any decent compiler and eliminated (so long as you're not casting back and forth) and again sometimes enhances readability so I'm indifferent on this one as well. I agree on the fourth -- I don't think that there's ever a good case for extraneous variables. The fifth is again a code readability issue and one of the reasons that Java doesn't require that you declare everything up front. -Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Issues with the current code base
Hi Sanjiva, On Mon, 2007-01-29 at 23:42 +0530, Sanjiva Weerawarana wrote: Bill, IMO I made a mistake in lifting my -1 on this patch .. this could've and should've gone in as an auxiliary bit of code without modifying MC at all. Calling mc.activateMessageContext on *every* message that comes in seems like a major ovehead to the mind even if not to the body (you know what I mean). There was no technical need whatsoever for this code to be in MC itself for Matt to be able to do whatever he needs to make Sandesha persist using Java object serialization instead of the serialization architecture that exists now. Next time I won't give in so easy :). You are certainly entitled to your opinion; I did attempt to continue the discussion. In any case, I'm yet to see an explanation from Anne for the algorithm used to figure out the parent service context etc. for a message context. Anne, can you explain how you're going about figuring those refs out please? Please don't say RTFS :(. I will make sure that she is aware of your request. We need to performance compare 1.1.1 with the current head and see what the impact of this change is. I would be more than happy for someone to compare r495105 to r495106(the version where the changes were committed) and would be more than willing to address any performance concerns that arise from that comparison. On code conventions- search the archives please .. we've had lots of discussion on this in the early days and decided on the conventions. I'm pretty sure we put them in the wiki somewhere but have no idea where off the top of my head :(. Interestingly, even the original JAX-WS proposal by IBM mentions coding conventions: http://wiki.apache.org/ws/FrontPage/Axis2/JAX-WS-Proposal. so maybe someone in IBM found a ref? I was unable to find them on the wiki (I looked at both the current as well as the old root pages.) The JAX-WS proposal only speaks in the abstract about code organization -- it says nothing about the formatting of Java source files. Certainly you can't expect people to adhere to coding guidelines that only appear in email messages from almost 2 years ago or even know that they exist in the first place. -Bill Sanjiva. On Mon, 2007-01-29 at 07:27 -0800, Bill Nagy wrote: Hi Deepal, On Mon, 2007-01-29 at 11:41 +0530, Deepal Jayasinghe wrote: Hi all; I just went though the current code base and realized that MessageContext code has been changed a lot . I found few issues with the code base and hope we need to fix them. So I thought of sending this mail for everyone's consideration. Well someone please explain to me whose going to need MessageContext serialization , Chamikara : Do you want that for Sandesha ? Ruchith : Do you want that for Security ? If none of you want this , who else need this ? As Matt pointed out, we went through this on an earlier discussion -- Sandesha is the intended consumer. I am asking this question b'coz introduction of MC serialization we have the following for each req. - When ever Axis2 received a message it calls activateMessageContext(msgContext); - And what that does is , it calls mc.activate(engineContext); method Unfortunately that method is TOO long and was very difficult to understand:). Ann can you simplify the method (that will be very helpful) . Actually, if you notice, the first line of MessageContext.activate(...) is a short-circuit test on needsToBeReconciled, which is only ever set when the MessageContext (and related parts) are deserialized using the MessageContext deserialization routines -- for all other cases, it ends up being a no-op so you can stop reading at that point 8-]. As for the method being too long, of the 306 lines in that method, 110 are comments/log messages, and the rest of the code consists of if-not-null-invoke-a-method blocks. Unfortunately the MessageContext has a lot of handles to other objects, so there need to be a number of those tests. If you're having difficulty understanding a particular section of that method, please ask and we'd be happy to explain it to you. I certainly think that the rest of the code could use some code bloat (i.e. comments) -- e.g. there are no class-level comments on ListenerManager, AxisConfiguration, PhaseResolver (just to name a few.) In the meantime code convention in MC has changed a lot and need to have very consistent code convention, please do not differ form that. This is the second time that code conventions have been mentioned (Sanjiva brought this up in an earlier discussion as well) -- I was not aware of these, and was unable to find anything in the docs that talk about them. (The Developer Guidelines only talk about the mailing list.) Could you please point me to where these are codified? Among the all , the most worst thing I saw in the code
[Axis2] Re: svn commit: r499521 - in /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2: client/ServiceClient.java description/OutInAxisOperation.java
Hi Sanjiva, I wasn't making the point because I think that it is wrong (at least in this case,) I was making the point that the same process has occurred over and over again in the past -- meaning that there are lots of JIRA issues and even just commits that occur without discussion. I made this statement because, as I indicated, Matt's change didn't modify the API, so I viewed it no differently than other people shifting code around to fix other issues. I read through his change, compiled it, tested it, and it worked so I committed it. Had the API been modified or had it been a major modification I would have brought it up on the list just as I have done in the past. -Bill On Fri, 2007-01-26 at 04:48 +0530, Sanjiva Weerawarana wrote: On Thu, 2007-01-25 at 05:49 -0800, Bill Nagy wrote: I can point out 100s of instances of this pattern of modification without any discussion on the mailing list what so ever. This is the second time you've made this type of an assertion recently (the last time was during the MC serialization discussion when you said that there were lots of areas where things don't work as advertised). If you see a problem please point it out then and there without keeping silent and then making a very general statement of community malpractice. We're an open source project running under a fully open model- if someone's not doing the right thing point it out, ask for an explanation and then let's force changes as needed. Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2]Re: svn commit: r499521 - in /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2: client/ServiceClient.java description/OutInAxisOperation.java
Hi Sanjiva, I find this statement odd -- the JAXWS code has been in place for several months and is clearly another API (yes, I know that it hasn't been packaged in a release, but neither have Matt's changes.) Nobody is advocating that end-users go through the OperationClient, however any other programming models that are layered on top of the base Axis2 runtime (e.g. JAXWS) probably will. Matt's modifications made no reference in any of the comments about this being a new or the preferred API, so I don't see how users are going to be aware of these modifications. It shouldn't make a difference at all where the logic lives -- they should be using what we tell them to use. -Bill On Fri, 2007-01-26 at 04:51 +0530, Sanjiva Weerawarana wrote: On Wed, 2007-01-24 at 22:38 -0600, Nicholas L Gallardo wrote: Matt's patch is intended to push some logic that exists in the ServiceClient down to the OperationClient. I don't see this as a change in the API, just an addition to the behavior based on certain criteria. Would there be a reason for not including this in the OperationClient rather than the ServiceClient? It changes the API because we've so far had exactly one way to invoke a service: using the ServiceClient API. Now we have two. I view that as a major API change because the user experience has changed dramatically. Matt, is this change meant to be something for say JAX-WS to use and not for end users? If so can we document it as such? If not I don't understand how Sandesha has been able to handle every RM scenario we've seen so far without the need for this API change. Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] Improving trace logs
Hi folks, At least for me, trying to parse all but the most trivial trace file is a nightmare -- we have multiple threads, multiple concurrent messages being sent and received on a single thread, message processing being handed off between threads, etc. I figure that there has to be a way to make the logs easier to understand, so as a small first step I would like to propose adding a unique id to each message/MessageContext to be used as a correlation point for each of the log messages. (e.g. Message uid:2J39JAJQI11U2: AxisEngine receive: ...) We can't correlate on the object id's of the MessageContext's, because those change if the message is persisted/restored. We also can't correlate on the WS-A MessageID, as that is not guaranteed to be present, and even if it is, it won't be identified early enough in the flow to prevent having to perform a double correlation. The usefulness of this will, of course, depend upon log messages taking advantage of its presence, but I certainly view it as a worthwhile use of bytes. Comments? -Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [AXIS2] Proposal for saving the message context
I'm not giving up, and I want to argue some more 8-]. From a pure Axis context perspective, I agree (without having looked through the code in detail) that your assertion about there not being any private state is correct. From the perspective of the state as a whole, I don't agree -- in our use of Axis2, for example, we have properties stored in the contexts that have private state information that must be serialized. I'm not arguing with the fact that we COULD place the serialization code outside of the objects that they operate on -- that can always be done (although it may require exposing an interface only used by the serialization mechanism if there is private info) -- I'm arguing about whether or not it SHOULD be done. By moving it outside of the objects themselves, you are duplicating the metadata of the object structure and hierarchy and therefore any changes to that metadata (e.g. adding a new field, changing types, moving fields, etc.) need to be made both to the class and to logic external to the class. I believe this to be error-prone and a bad design. Maybe your are correct in believing that the serialization code can only be used by RM -- even so, I believe that RM is important enough that the core should make allowances for it and that this particular allowance makes for a more maintainable system if nothing else. -Bill On Fri, 2007-01-05 at 23:19 +0530, Sanjiva Weerawarana wrote: On Tue, 2007-01-02 at 15:28 -0800, Bill Nagy wrote: OK, here's my $0.02: (1)I would argue that reliable delivery of messages is an integral part of a web services stack and therefore deserves special treatment in the core where necessary so long as it does not adversely affect processing when the reliability is achieved through other means (such as being inherent with a transport) or is not required. I believe that exposing a serialization/deserialization API as part of the MessageContext API is a part of this. If this API can't be used by other things, then we should try to make it better (See (3) below.) I think we're in agreement that there's no private state involved with this serialization- so there's no fundamental reason for this code to be inside MC instead of outside. (2)I will also argue that, following good design practices (e.g. encapsulation,) objects themselves should be in charge of persisting/restoring their state. The problem is that we've changed the conversation from the right solution to the problem to having a solution which needs a problem. The problem is one of supporting saving state for RM and we both appear to agree that technically this can be outside of MC stuff. The solution that is in front of is much more generic (saving an MC), yet the current impl is not so generic and really cannot be made to be generic. (That's my conclusion after thinking about this for more than an year .. remember we've been here done this before; these objects were serializable a while back and we backtracked. YMMV obviously. Does this increase the amount of code within the objects? Sure. Does it make the objects harder for others to understand? Doubtful -- most of the relevant code is kept within a few methods. Does it make modifications to the object more convenient and less error prone? Certainly -- having all of the code in once place is much easier, although it still requires some degree of vigilance. It's far better to have each object delegate the tasks of serializing to each of its subordinate objects (i.e. fields) than to have a single block of code that understands how to serialize the entire graph -- something which may be impossible if some of the properties stored within the contexts are well encapsulated. Except that in this case none of the things Ann is saving are private members. I would not agree that that means things are not well encapsulated- it means that interesting bits of the various contexts are public properties. (3)This is iterative development -- lets be real, there are a lot of things in Axis2 that don't work quite the way that one would think. I don't believe that anything should be held out simply because it doesn't address every possible usecase, so long as it doesn't break the rest of the system. Sure. If you do know of other areas that need improvement please do open JIRAs so that we can keep track of them. While Ann's patch is undoubtedly not perfect and will continue to evolve, I do believe that it is a step in the right direction and should be committed. I don't agree its the right way to solve the problem but I'm giving up and lifting the objection because this conversation has become unnecessarily politicized. Disappointing but let's get on with it and move onto bigger and better problems we have to deal with! Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED
Re: [AXIS2] Proposal for saving the message context
OK, here's my $0.02: (1)I would argue that reliable delivery of messages is an integral part of a web services stack and therefore deserves special treatment in the core where necessary so long as it does not adversely affect processing when the reliability is achieved through other means (such as being inherent with a transport) or is not required. I believe that exposing a serialization/deserialization API as part of the MessageContext API is a part of this. If this API can't be used by other things, then we should try to make it better (See (3) below.) (2)I will also argue that, following good design practices (e.g. encapsulation,) objects themselves should be in charge of persisting/restoring their state. Does this increase the amount of code within the objects? Sure. Does it make the objects harder for others to understand? Doubtful -- most of the relevant code is kept within a few methods. Does it make modifications to the object more convenient and less error prone? Certainly -- having all of the code in once place is much easier, although it still requires some degree of vigilance. It's far better to have each object delegate the tasks of serializing to each of its subordinate objects (i.e. fields) than to have a single block of code that understands how to serialize the entire graph -- something which may be impossible if some of the properties stored within the contexts are well encapsulated. (3)This is iterative development -- lets be real, there are a lot of things in Axis2 that don't work quite the way that one would think. I don't believe that anything should be held out simply because it doesn't address every possible usecase, so long as it doesn't break the rest of the system. While Ann's patch is undoubtedly not perfect and will continue to evolve, I do believe that it is a step in the right direction and should be committed. -Bill On Fri, 2006-12-22 at 04:49 +0530, Sanjiva Weerawarana wrote: On Thu, 2006-12-21 at 11:14 -0600, Ann Robinson wrote: I have submitted an updated patch for the message context save/restore proposal (under JIRA axis2-1567). Now, when a message context is restored, it looks for existing ServiceContext and ServiceGroupContext objects to use in its object hierarchy. This means that a restored object graph for a MessageContext is made up of mostly existing *Context and Axis* objects. In other words, object re-use for the *Context and Axis* objects is maximized. And, when existing context object are re-used, any saved properties are merged into the existing objects. Just to summarize, when a message context is saved, its state is collected and saved, including: - the settings for various flags in the message context - properties associated with the message context (which are really contained in an Options object) - the actual message - where in the message processing the message is - meta data about the handlers associated with processing the message - meta data about the AxisOperation/AxisService/AxisServiceGroup associated with the message context - the OperationContext/ServiceContext/ServiceGroupContext associated with the message context As far as I can see none of this data is private to a message context; so the answer to the question I asked earlier appears to be that this code can perfectly well live in a utility class. When a message context is restored, the message context object graph is re-built based on the information that was saved. If possible, existing objects are used from the engine where the message context is being restored. Names or IDs are used to find existing objects that correspond to their counterparts from the saved environment. Where existing objects are used, saved properties are merged into the existing objects. I'm confused. What do you mean by existing objects? A particular message exchange lives within a particular service context. You can't just put it back into some exiting object; it must go back into the corresponding service context etc.. is that what you mean? If so how do you record the ID of the service context object? Two different message contexts saved during two save actions could refer to the same service context with different state values of course. The message context save/restore proposal is intended to benefit AXIS2. This proposal gives AXIS2 some functionality that allows AXIS2 to be used in more customer environments. I have indicated in previous postings that the prototype for the message context save/restore proposal has been used internally by IBM. This statement was not intended to divide the open source community along company lines but instead, to indicate that the prototype has been tested and reached a level of stability and that negative side-effects have been minimized. Absolutely. As I stated earlier, there's nothing wrong with providing hooks that help people who build on top of Axis2.
Re: [Axis2][Proposal] Folding changes back to trunk
Hi dims, That's fine, I'll start merging in the changes. -Bill On Wed, 2006-11-15 at 01:06 -0500, Davanum Srinivas wrote: Folks, I spent the day today staring at diff's...tried all sorts of things with svn merge and winmerge. Bottom line, there's tons of changes in the branch and HEAD has much fewer changes. So here's the proposal. (Assuming base svn url is http://svn.apache.org/repos/asf/webservices/axis2/) 1. Freeze check-ins to trunk/java and branches/java/1_1/ 2. copy trunk/java into branches/java/old_trunk/ 3. copy branches/java/1_1/ to trunk/java 4. Fix all the version #'s in project.xml/project.properties/pom.xml's 5. Copy branches/java/old_trunk/modules/jaxws to trunk/java/modules/jaxws (complete overwrite since all changes were made in head) 6. Merge addressing module changes from branches/java/old_trunk/modules/addressing to trunk/java/modules/addressing by hand 7. Merge kernel module changes from branches/java/old_trunk/modules/kernel to trunk/java/modules/kernel by hand 8. Unfreeze trunk/java and branches/java/1_1/ 9. Any other items can be merged on a need basis from old_trunk. I can handle 1-5 and 8. Bill and David, could you please help with 6 and 7? I could use some help with 5 too if i run into trouble getting all the tests to work properly. Everyone can pitch in after step 8. people can continue working on old_trunk, but they would be responsible for merging back...Please remember, we have gone to great lengths to stabilize the code on the branch and this is the best way that i can think of to minimize instability and move forward. Questions, comments, concerns? Thanks, dims - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Can someone explain the logic in AxisEngine.TransportNonBlockingInvocationWorker?
Hi Deepal,
I understand why the class is there; I don't understand why the changes
in 415245 were made -- that's what I was asking for clarification about.
The 'done' block is completely irrelevant and makes the code harder to
read, unless there is something that I'm missing, which is why I was
asking. BTW, the result of your comment modification is inaccurate; the
class is used anytime someone sets the useSeparateListener option on an
OutIn operation, not just when two transports are in use.
-Bill
On Wed, 2006-11-08 at 10:30 +0530, Deepal Jayasinghe wrote:
Hi Bill ;
I added a few comment line into the code.
In revision 415245, some code was added to the
AxisEngine.TransportNonBlockingInvocationWorker with the comment -
minor modification -- this code added a boolean, done, and a while loop
which tests that boolean.
/**
* This class is the workhorse for a non-blocking invocation that uses a
two
* way transport.
*/
private class TransportNonBlockingInvocationWorker implements Runnable {
private MessageContext msgctx;
private TransportSender sender;
private boolean done;
public TransportNonBlockingInvocationWorker(MessageContext msgctx,
TransportSender sender) {
this.msgctx = msgctx;
this.sender = sender;
}
public void run() {
try {
while (!done) {
sender.invoke(msgctx);
done = true;
}
} catch (Exception e) {
log.info(e.getMessage());
}
}
}
The ThreadPool is the the only one that has a handle to the
TransportNonBlockingInvocationWorker instance, and he can't tell what
the outcome was so this addition is rather confusing.
I am not clear what do you mean by this , thread is just to send the
request. It will create AxisEngine and and send the message and wait
till it get the transport ack.
Can someone
enlighten me as to its purpose since the commit message is utterly
useless and there are no other comments in the code?
already done in the code.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
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]
[Axis2] Can someone explain the logic in AxisEngine.TransportNonBlockingInvocationWorker?
In revision 415245, some code was added to the
AxisEngine.TransportNonBlockingInvocationWorker with the comment -
minor modification -- this code added a boolean, done, and a while loop
which tests that boolean.
/**
* This class is the workhorse for a non-blocking invocation that uses a two
* way transport.
*/
private class TransportNonBlockingInvocationWorker implements Runnable {
private MessageContext msgctx;
private TransportSender sender;
private boolean done;
public TransportNonBlockingInvocationWorker(MessageContext msgctx,
TransportSender sender) {
this.msgctx = msgctx;
this.sender = sender;
}
public void run() {
try {
while (!done) {
sender.invoke(msgctx);
done = true;
}
} catch (Exception e) {
log.info(e.getMessage());
}
}
}
The ThreadPool is the the only one that has a handle to the
TransportNonBlockingInvocationWorker instance, and he can't tell what
the outcome was so this addition is rather confusing. Can someone
enlighten me as to its purpose since the commit message is utterly
useless and there are no other comments in the code? (I'm trying to
fix an issue with a requester hanging because it's waiting for a
response that will never come because the transmission actually
failed [since the exception is just getting swallowed here], but
I don't want to screw up a dependency if something's trying to
deal with the exception.) Thanks.
-Bill
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Nightly builds for 1.1 branch
Hi dims, Are you going to start building trunk there as well? (You can't build off of the trunk right now, as the old repositories are still being referenced, and I didn't see any of the trunk jars/mars under http://ws.zones.apache.org/repository/ .) I can't commit my fixes for the Sandesha race condition to 1.1 until I can commit them to trunk as well. Thanks. -Bill On Tue, 2006-10-24 at 19:44 -0400, Davanum Srinivas wrote: Team, Please get the nightly builds from here: http://ws.zones.apache.org/dist/axis2/nightly/ Please note that the repo that was under my id is now here: http://ws.zones.apache.org/repository/ FYI, We had to dump a box (minotaur) that got corrupted in the colo move. thanks, dims - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Nightly builds for 1.1 branch
Hi dims, Not really. We can't build/test/fix code reliably without the repos. -Bill On Wed, 2006-10-25 at 14:05 -0400, Davanum Srinivas wrote: Bill, Can it wait a couple of days? I want to see if the Infra folks get people.apache.org back up. They are almost there... thanks, dims On 10/25/06, Bill Nagy [EMAIL PROTECTED] wrote: Hi dims, Are you going to start building trunk there as well? (You can't build off of the trunk right now, as the old repositories are still being referenced, and I didn't see any of the trunk jars/mars under http://ws.zones.apache.org/repository/ .) I can't commit my fixes for the Sandesha race condition to 1.1 until I can commit them to trunk as well. Thanks. -Bill On Tue, 2006-10-24 at 19:44 -0400, Davanum Srinivas wrote: Team, Please get the nightly builds from here: http://ws.zones.apache.org/dist/axis2/nightly/ Please note that the repo that was under my id is now here: http://ws.zones.apache.org/repository/ FYI, We had to dump a box (minotaur) that got corrupted in the colo move. thanks, dims - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Need help with Axis2 1.1 Release
On Wed, 2006-10-25 at 15:59 -0400, Davanum Srinivas wrote: Folks, We need help with testing Axis2. As Thilina mentioned in another email, we have zero blockers right now. All the API changes are already in. ADB/Codegen seems more solid than ever. We are working on Does this mean that you no longer want me to check in the fix for the Sandesha race condition? (It will alter the Handler interface.) -Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Nightly builds for 1.1 branch
Thanks. All's better now 8-]. -Bill On Wed, 2006-10-25 at 16:42 -0400, Davanum Srinivas wrote: Ok. Switched on only the jars from HEAD: http://ws.zones.apache.org/repository/org.apache.axis2/jars/ -- dims On 10/25/06, Bill Nagy [EMAIL PROTECTED] wrote: Hi dims, Not really. We can't build/test/fix code reliably without the repos. -Bill On Wed, 2006-10-25 at 14:05 -0400, Davanum Srinivas wrote: Bill, Can it wait a couple of days? I want to see if the Infra folks get people.apache.org back up. They are almost there... thanks, dims On 10/25/06, Bill Nagy [EMAIL PROTECTED] wrote: Hi dims, Are you going to start building trunk there as well? (You can't build off of the trunk right now, as the old repositories are still being referenced, and I didn't see any of the trunk jars/mars under http://ws.zones.apache.org/repository/ .) I can't commit my fixes for the Sandesha race condition to 1.1 until I can commit them to trunk as well. Thanks. -Bill On Tue, 2006-10-24 at 19:44 -0400, Davanum Srinivas wrote: Team, Please get the nightly builds from here: http://ws.zones.apache.org/dist/axis2/nightly/ Please note that the repo that was under my id is now here: http://ws.zones.apache.org/repository/ FYI, We had to dump a box (minotaur) that got corrupted in the colo move. thanks, dims - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Need help with Axis2 1.1 Release
Yep -- I was waiting until I could compile and test (i.e. the repos were back up.) 8-] I just committed the changes to 1.1 and will do so to the trunk shortly. Someone will need to modify the Sandesha code (and any other dependent handlers) to do the correct thing. -Bill On Wed, 2006-10-25 at 16:46 -0400, Davanum Srinivas wrote: oops!!! is that still pending? please go ahead. -- dims On 10/25/06, Bill Nagy [EMAIL PROTECTED] wrote: On Wed, 2006-10-25 at 15:59 -0400, Davanum Srinivas wrote: Folks, We need help with testing Axis2. As Thilina mentioned in another email, we have zero blockers right now. All the API changes are already in. ADB/Codegen seems more solid than ever. We are working on Does this mean that you no longer want me to check in the fix for the Sandesha race condition? (It will alter the Handler interface.) -Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axis2] handler API change for race condition fixing
I don't like mixing implementation and interface, but I don't feel like arguing now, so done. -Bill On Wed, 2006-10-25 at 21:25 -0400, Glen Daniels wrote: Hi Sanjiva, Bill: Sanjiva Weerawarana wrote: I know I +1'ed whatever approach but the approach of introducing a top level class for the return status looks ugly to me. If consts aren't good enough can't we at least shove this (static) class inside Handler? That way one returns Handler.InvocationResponse.CONTINUE_PROCESSING etc. which at least tells people immediately what it means. +1 to Sanjiva's suggestion. Removes the need for another import/file, and from inside a Handler-derived class, you can actually still just return InvocationResponse.CONTINUE (see below), which looks clean. I also like InvocationResponse *much* better than InvocationProcessingInstruction. And do we really need the _PROCESSING suffix on CONTINUE/SUSPEND/ABORT? :) Yours for succinct code, --Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] 1_1 build failing (adb_codegen test failures)
(Running IBM JDK 1.5) [junit] [ERROR] Test org.apache.axis2.schema.testsuite.CustomElementsTest FAILED [junit] Running org.apache.axis2.schema.testsuite.IntElementsTest [junit] Tests run: 2, Failures: 2, Errors: 0, Time elapsed: 0.254 sec [junit] [ERROR] Test org.apache.axis2.schema.testsuite.IntElementsTest FAILED [junit] Running org.apache.axis2.schema.testsuite.StringElementsTest [junit] Tests run: 2, Failures: 2, Errors: 0, Time elapsed: 0.242 sec [junit] [ERROR] Test org.apache.axis2.schema.testsuite.StringElementsTest FAILED Testsuite: org.apache.axis2.schema.testsuite.CustomElementsTest Tests run: 2, Failures: 2, Errors: 0, Time elapsed: 0.247 sec - Standard Output --- minOccurs = 0 and nillable true minOccurs = 0 and nillable true - --- - Standard Error - java.lang.NullPointerException at org.apache.axiom.om.impl.MTOMXMLStreamWriter.init(MTOMXMLStreamWriter.java:66) at org.apache.axiom.om.impl.llom.OMNodeImpl.serializeAndConsume(OMNodeImpl.java:410) at org.apache.axiom.om.impl.llom.OMSourcedElementImpl.serializeAndConsume(OMSourcedElementImpl.java:601) at org.apache.axiom.om.impl.llom.OMSourcedElementImpl.serialize(OMSourcedElementImpl.java:562) at org.apache.axiom.om.impl.llom.OMElementImpl.toString(OMElementImpl.java:929) at org.apache.axiom.om.impl.llom.OMSourcedElementImpl.toString(OMSourcedElementImpl.java:751) at java.lang.String.valueOf(String.java:1475) at java.lang.StringBuffer.append(StringBuffer.java:232) at org.apache.axis2.schema.testsuite.CustomElementsTest.testCustom(CustomElementsTest.java:208) at org.apache.axis2.schema.testsuite.CustomElementsTest.testCustom(CustomElementsTest.java:157) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:297) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:672) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:567) - --- Testcase: testCustomArray(org.apache.axis2.schema.testsuite.CustomElementsTest): FAILED null junit.framework.AssertionFailedError at org.apache.axis2.schema.testsuite.CustomElementsTest.testCustomArray(CustomElementsTest.java:48) Testcase: testCustom(org.apache.axis2.schema.testsuite.CustomElementsTest): FAILED null junit.framework.AssertionFailedError at org.apache.axis2.schema.testsuite.CustomElementsTest.testCustom(CustomElementsTest.java:163) Testsuite: org.apache.axis2.schema.testsuite.IntElementsTest Tests run: 2, Failures: 2, Errors: 0, Time elapsed: 0.254 sec - Standard Output --- minOccurs = 0 nillable true - --- - Standard Error - java.lang.NullPointerException at org.apache.axiom.om.impl.MTOMXMLStreamWriter.init(MTOMXMLStreamWriter.java:66) at org.apache.axiom.om.impl.llom.OMNodeImpl.serializeAndConsume(OMNodeImpl.java:410) at org.apache.axiom.om.impl.llom.OMSourcedElementImpl.serializeAndConsume(OMSourcedElementImpl.java:601) at org.apache.axiom.om.impl.llom.OMSourcedElementImpl.serialize(OMSourcedElementImpl.java:562) at org.apache.axiom.om.impl.llom.OMElementImpl.toString(OMElementImpl.java:929) at org.apache.axiom.om.impl.llom.OMSourcedElementImpl.toString(OMSourcedElementImpl.java:751) at java.lang.String.valueOf(String.java:1475) at java.lang.StringBuffer.append(StringBuffer.java:232) at org.apache.axis2.schema.testsuite.IntElementsTest.testIntArray(IntElementsTest.java:90) at org.apache.axis2.schema.testsuite.IntElementsTest.testIntArray(IntElementsTest.java:40) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Re: [Axis2] 1_1 build failing (adb_codegen test failures)
) at org.apache.axiom.om.impl.llom.OMSourcedElementImpl.serialize(OMSourcedElementImpl.java:562) at org.apache.axiom.om.impl.llom.OMElementImpl.toString(OMElementImpl.java:929) at org.apache.axiom.om.impl.llom.OMSourcedElementImpl.toString(OMSourcedElementImpl.java:751) at java.lang.String.valueOf(String.java:1475) at java.lang.StringBuffer.append(StringBuffer.java:232) at org.apache.axis2.schema.testsuite.IntElementsTest.testIntArray(IntElementsTest.java:90) at org.apache.axis2.schema.testsuite.IntElementsTest.testIntArray(IntElementsTest.java:40) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:297) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:672) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:567) Caused by: javax.xml.stream.XMLStreamException: property key cannot be null! at org.apache.axis2.databinding.utils.reader.ADBXMLStreamReaderImpl.processProperties(ADBXMLStreamReaderImpl.java:842) at org.apache.axis2.databinding.utils.reader.ADBXMLStreamReaderImpl.next(ADBXMLStreamReaderImpl.java:789) at org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:116) ... 40 more - --- Testcase: testIntArray(org.apache.axis2.schema.testsuite.IntElementsTest):FAILED null junit.framework.AssertionFailedError at org.apache.axis2.schema.testsuite.IntElementsTest.testIntArray(IntElementsTest.java:46) Testsuite: org.apache.axis2.schema.testsuite.StringElementsTest Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 0.623 sec - Standard Output --- Test minOccurs 0 nillable true Test minOccurs 0 nillable true OMElement ns1:testString2 xmlns:ns1=http://types.echo.services;testValue xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns=http://types.echo.services; xsi:nil=true //ns1:testString2 OMElement ns1:testString2 xmlns:ns1=http://types.echo.services;testValue xmlns=http://types.echo.services;Test/testValue/ns1:testString2 Test minOccurs = 0 nillable false OMElement ns1:testString4 xmlns:ns1=http://types.echo.services; / OMElement ns1:testString4 xmlns:ns1=http://types.echo.services;testValue xmlns=http://types.echo.services;Test/testValue/ns1:testString4 Test minOccurs = 1 nillable true OMElement ns1:testString6 xmlns:ns1=http://types.echo.services;testValue xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns=http://types.echo.services; xsi:nil=true //ns1:testString6 OMElement ns1:testString6 xmlns:ns1=http://types.echo.services;testValue xmlns=http://types.echo.services;Test/testValue/ns1:testString6 Test minOccurs = 1 nillable false OMElement ns1:testString8 xmlns:ns1=http://types.echo.services;testValue xmlns=http://types.echo.services;Test/testValue/ns1:testString8 - --- Testcase: testStringArray(org.apache.axis2.schema.testsuite.StringElementsTest): FAILED null junit.framework.AssertionFailedError at org.apache.axis2.schema.testsuite.StringElementsTest.testStringArray(StringElementsTest.java:47) On Thu, 2006-10-19 at 08:13 -0400, Davanum Srinivas wrote: just checked in rev 465595 in axiom On 10/19/06, Bill Nagy [EMAIL PROTECTED] wrote: (Running IBM JDK 1.5) [junit] [ERROR] Test org.apache.axis2.schema.testsuite.CustomElementsTest FAILED [junit] Running org.apache.axis2.schema.testsuite.IntElementsTest [junit] Tests run: 2, Failures: 2, Errors: 0, Time elapsed: 0.254 sec [junit] [ERROR] Test org.apache.axis2.schema.testsuite.IntElementsTest FAILED [junit] Running org.apache.axis2.schema.testsuite.StringElementsTest [junit] Tests run: 2, Failures: 2, Errors: 0, Time elapsed: 0.242 sec [junit] [ERROR] Test org.apache.axis2.schema.testsuite.StringElementsTest FAILED Testsuite: org.apache.axis2.schema.testsuite.CustomElementsTest Tests run: 2, Failures: 2, Errors: 0, Time elapsed: 0.247 sec - Standard Output --- minOccurs = 0
Re: [Axis2] Proposal to add return type to Handler.invoke(...)
Sold, but I was OK on waiting until after 1.1 as the handler unwind
stuff changed the Handler interface anyways. We still need either the
multi-value return type or another property in the MessageContext to
indicate that message processing should abort vs pause (so that the
handler unwind can happen vs not.) [We may simply be able to replace
the MessageContext.ispaused property with a MessageContext.isaborted
property, as there shouldn't be a race condition with that one, and then
implicitly intrepret a false returned with isAborted==false as the
message is just paused. This is a little less clear in my opinion, but
would do the job.]
If you'd rather have the property, I'm fine with that -- I just want to
make the decision now and not have to change the interface again later.
-Bill
On Thu, 2006-10-19 at 04:57 +0530, Sanjiva Weerawarana wrote:
OK how about this alternative- let's make this change on the HEAD and
the 1.1 branch now? That way we do it and finish it off.
Sanjiva.
On Wed, 2006-10-18 at 11:05 +0530, Sanjiva Weerawarana wrote:
Sorry for the delay Bill.
+1 to your solution. However I'd personally prefer if you change the
return type to be boolean: true means paused and false means all is
cool.
I'm very wary of executing thing change right now because it'll break
all downstream projects including Rahas/Rampart/Sandesha/Synapse etc.
which have not cut 1.1 branches. We definitely want them to run on Axis2
1.1 and so its necessary to not change them. Is there any way to wait
until we get back onto one trunk?
Or maybe the right answer is for those projects to branch too now.
Thoughts?
Sanjiva.
On Tue, 2006-10-17 at 06:39 -0700, Bill Nagy wrote:
Do you still have an objection to this Sanjiva?
-Bill
On Tue, 2006-10-10 at 18:20 -0700, Bill Nagy wrote:
Hi Sanjiva,
The problem isn't that both people are modifying MessageContext.paused,
so synchronizing that isn't going to work, the problem is that if the RM
handler, for instance, pauses the message and returns, but the RM thread
picks up the message and resumes it (thereby unpausing the message)
before control returns to the logic in the Phase/AxisEngine, the
Phase/AxisEngine are going to proceed as if the message was never
paused.
I was trying to avoid the overhead of synchronization when we have
another solution that works just as well (i.e. the return value) without
the overhead (and is more logically correct IMO.)
Using the return code also allows us to capture whether or not a message
was 'paused' vs 'aborted' -- this is important in the handler unwinding,
as no unwinding needs to occur in the 'paused' case while it does in the
'aborted' case.
I prefer an enumeration object because it's clear from the method
signature what is being returned (InvocationProcessingInstruction vs.
int in this case,) but if that's all that is holding you up, I'll switch
it to constants.
-Bill
On Tue, 2006-10-10 at 18:13 +0530, Sanjiva Weerawarana wrote:
On Mon, 2006-10-09 at 19:51 -0700, Bill Nagy wrote:
There is currently a race condition between code that pauses the
message
flow within a handler and resumes it on another thread (e.g.
Sandesha)
and the message flow processing chain (Phase.invoke(...),
AxisEngine.invoke(...), etc.)
(http://issues.apache.org/jira/browse/SANDESHA2-32) This is caused
because the control of processing is keyed off of
MessageContext.paused
and not through some other mechanism (return code, semaphore,
etc.). If
a handler pauses a message and returns, handing the message off to
another thread for execution, there is the possibility that the new
execution thread will resume processing of the message, unsetting
MessageContext.paused, before control returns to one of the invoke
methods. If this happens, the logic in the invoke method, which
looks
at the MessageContext.paused flag, will believe that it should
continue
execution instead of halting.
Can't this be solved by synchronizing access to
MessageContext.paused()?
Sorry I looked at the sandesha issue but didn't see it.
Alternatively,
synchronized {
h.invoke();
h.getPaused();
}
I must be missing something obvious as to why this doesn't work.
Since the problem revolves around flow control logic, I suggest
that we
use the return code from the method invocation to deal with it. I
would
like to add a return code to the Handler.invoke(...) which would
identify how processing of the message should proceed, e.g. :
How does this solve the problem as other thread could go get the MC
and
do stuff while still in this method
Re: [Axis2] Proposal to add return type to Handler.invoke(...)
Do you still have an objection to this Sanjiva?
-Bill
On Tue, 2006-10-10 at 18:20 -0700, Bill Nagy wrote:
Hi Sanjiva,
The problem isn't that both people are modifying MessageContext.paused,
so synchronizing that isn't going to work, the problem is that if the RM
handler, for instance, pauses the message and returns, but the RM thread
picks up the message and resumes it (thereby unpausing the message)
before control returns to the logic in the Phase/AxisEngine, the
Phase/AxisEngine are going to proceed as if the message was never
paused.
I was trying to avoid the overhead of synchronization when we have
another solution that works just as well (i.e. the return value) without
the overhead (and is more logically correct IMO.)
Using the return code also allows us to capture whether or not a message
was 'paused' vs 'aborted' -- this is important in the handler unwinding,
as no unwinding needs to occur in the 'paused' case while it does in the
'aborted' case.
I prefer an enumeration object because it's clear from the method
signature what is being returned (InvocationProcessingInstruction vs.
int in this case,) but if that's all that is holding you up, I'll switch
it to constants.
-Bill
On Tue, 2006-10-10 at 18:13 +0530, Sanjiva Weerawarana wrote:
On Mon, 2006-10-09 at 19:51 -0700, Bill Nagy wrote:
There is currently a race condition between code that pauses the message
flow within a handler and resumes it on another thread (e.g. Sandesha)
and the message flow processing chain (Phase.invoke(...),
AxisEngine.invoke(...), etc.)
(http://issues.apache.org/jira/browse/SANDESHA2-32) This is caused
because the control of processing is keyed off of MessageContext.paused
and not through some other mechanism (return code, semaphore, etc.). If
a handler pauses a message and returns, handing the message off to
another thread for execution, there is the possibility that the new
execution thread will resume processing of the message, unsetting
MessageContext.paused, before control returns to one of the invoke
methods. If this happens, the logic in the invoke method, which looks
at the MessageContext.paused flag, will believe that it should continue
execution instead of halting.
Can't this be solved by synchronizing access to MessageContext.paused()?
Sorry I looked at the sandesha issue but didn't see it.
Alternatively,
synchronized {
h.invoke();
h.getPaused();
}
I must be missing something obvious as to why this doesn't work.
Since the problem revolves around flow control logic, I suggest that we
use the return code from the method invocation to deal with it. I would
like to add a return code to the Handler.invoke(...) which would
identify how processing of the message should proceed, e.g. :
How does this solve the problem as other thread could go get the MC and
do stuff while still in this method?
/**
* This type encapsulates an enumeration of possible message processing
* instruction values that may be returned by a handler/phase within the
* runtime.
*/
public class InvocationProcessingInstruction
{
public static InvocationProcessingInstruction CONTINUE_PROCESSING =
new InvocationProcessingInstruction(0);
public static InvocationProcessingInstruction SUSPEND_PROCESSING = new
InvocationProcessingInstruction(1);
public static InvocationProcessingInstruction ABORT_PROCESSING = new
InvocationProcessingInstruction(2);
private int instructionID;
private InvocationProcessingInstruction(int instructionID)
{
this.instructionID = instructionID;
}
public boolean equals(InvocationProcessingInstruction instruction)
{
return this.instructionID == instruction.instructionID;
}
public int hashCode()
{
return instructionID;
}
}
Most handlers will return
InvocationProcessingInstruction.CONTINUE_PROCESSING; the RM handler may
return that, SUSPEND_PROCESSING (for a pause), or ABORT_PROCESSING (for
a duplicate msg.)
I must be really jetlagged (traveling again): do we need all this or
just use an int to return the status?? (some consts basically).
Sanjiva.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Should requestors not be reusing AxisService's that have been registered for deployed services or is AxisService.isClientSide() untrustworthy?
Hi Sanjiva, Nope, you're not missing anything; I just wanted to make sure that my understanding was correct (that requestors need their own AxisService which is separate from the provider's) and that the Sandesha code was wrong. (org.apache.sandesha2.util.RMMsgCreator.createCreateSeqMsg(...) passes in a message that it has received to org.apache.sandesha2.util.SandeshaUtil.createNewRelatedMessageContext(...) which simply sets the AxisService from the passed-in message onto the new message and adds an OutIn operation to it.) Thanks. -Bill On Sun, 2006-10-15 at 13:44 +0530, Sanjiva Weerawarana wrote: On Thu, 2006-10-12 at 06:37 -0700, Bill Nagy wrote: Hi, If you have a service, (A), deployed into the runtime and you want to invoke either it or another service with the same WSDL, (A'), from that runtime, should you (1)not be passing (A)'s AxisService into the ServiceClient and always creating a new one to represent the client or (2)is AxisService.isClientSide() untrustworthy (i.e. will it sometimes return false even if you are a requestor -- a fact of reusing the AxisService from a deployed service? Thanks. I'm confused (as usual :-)). The scenario is that there's a *service* A with its AxisService AS-A. Now you want to invoke that service right? If so the AxisService for the client is different from the AxisService for the service. Remember the direction of the operations? So you'll have another AxisService AS-AC which is like AS-A except the operations are reversed (and bindings different etc.). So if you do AS-A.isClientSide() it should return false and AS-AC.isClientSide() should return true. Am I missing a link? Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] Should requestors not be reusing AxisService's that have been registered for deployed services or is AxisService.isClientSide() untrustworthy?
Hi, If you have a service, (A), deployed into the runtime and you want to invoke either it or another service with the same WSDL, (A'), from that runtime, should you (1)not be passing (A)'s AxisService into the ServiceClient and always creating a new one to represent the client or (2)is AxisService.isClientSide() untrustworthy (i.e. will it sometimes return false even if you are a requestor -- a fact of reusing the AxisService from a deployed service? Thanks. -Bill - 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]
Re: [Axis2] Proposal to add return type to Handler.invoke(...)
Hi Sanjiva,
The problem isn't that both people are modifying MessageContext.paused,
so synchronizing that isn't going to work, the problem is that if the RM
handler, for instance, pauses the message and returns, but the RM thread
picks up the message and resumes it (thereby unpausing the message)
before control returns to the logic in the Phase/AxisEngine, the
Phase/AxisEngine are going to proceed as if the message was never
paused.
I was trying to avoid the overhead of synchronization when we have
another solution that works just as well (i.e. the return value) without
the overhead (and is more logically correct IMO.)
Using the return code also allows us to capture whether or not a message
was 'paused' vs 'aborted' -- this is important in the handler unwinding,
as no unwinding needs to occur in the 'paused' case while it does in the
'aborted' case.
I prefer an enumeration object because it's clear from the method
signature what is being returned (InvocationProcessingInstruction vs.
int in this case,) but if that's all that is holding you up, I'll switch
it to constants.
-Bill
On Tue, 2006-10-10 at 18:13 +0530, Sanjiva Weerawarana wrote:
On Mon, 2006-10-09 at 19:51 -0700, Bill Nagy wrote:
There is currently a race condition between code that pauses the message
flow within a handler and resumes it on another thread (e.g. Sandesha)
and the message flow processing chain (Phase.invoke(...),
AxisEngine.invoke(...), etc.)
(http://issues.apache.org/jira/browse/SANDESHA2-32) This is caused
because the control of processing is keyed off of MessageContext.paused
and not through some other mechanism (return code, semaphore, etc.). If
a handler pauses a message and returns, handing the message off to
another thread for execution, there is the possibility that the new
execution thread will resume processing of the message, unsetting
MessageContext.paused, before control returns to one of the invoke
methods. If this happens, the logic in the invoke method, which looks
at the MessageContext.paused flag, will believe that it should continue
execution instead of halting.
Can't this be solved by synchronizing access to MessageContext.paused()?
Sorry I looked at the sandesha issue but didn't see it.
Alternatively,
synchronized {
h.invoke();
h.getPaused();
}
I must be missing something obvious as to why this doesn't work.
Since the problem revolves around flow control logic, I suggest that we
use the return code from the method invocation to deal with it. I would
like to add a return code to the Handler.invoke(...) which would
identify how processing of the message should proceed, e.g. :
How does this solve the problem as other thread could go get the MC and
do stuff while still in this method?
/**
* This type encapsulates an enumeration of possible message processing
* instruction values that may be returned by a handler/phase within the
* runtime.
*/
public class InvocationProcessingInstruction
{
public static InvocationProcessingInstruction CONTINUE_PROCESSING =
new InvocationProcessingInstruction(0);
public static InvocationProcessingInstruction SUSPEND_PROCESSING = new
InvocationProcessingInstruction(1);
public static InvocationProcessingInstruction ABORT_PROCESSING = new
InvocationProcessingInstruction(2);
private int instructionID;
private InvocationProcessingInstruction(int instructionID)
{
this.instructionID = instructionID;
}
public boolean equals(InvocationProcessingInstruction instruction)
{
return this.instructionID == instruction.instructionID;
}
public int hashCode()
{
return instructionID;
}
}
Most handlers will return
InvocationProcessingInstruction.CONTINUE_PROCESSING; the RM handler may
return that, SUSPEND_PROCESSING (for a pause), or ABORT_PROCESSING (for
a duplicate msg.)
I must be really jetlagged (traveling again): do we need all this or
just use an int to return the status?? (some consts basically).
Sanjiva.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] Proposal to add return type to Handler.invoke(...)
There is currently a race condition between code that pauses the message
flow within a handler and resumes it on another thread (e.g. Sandesha)
and the message flow processing chain (Phase.invoke(...),
AxisEngine.invoke(...), etc.)
(http://issues.apache.org/jira/browse/SANDESHA2-32) This is caused
because the control of processing is keyed off of MessageContext.paused
and not through some other mechanism (return code, semaphore, etc.). If
a handler pauses a message and returns, handing the message off to
another thread for execution, there is the possibility that the new
execution thread will resume processing of the message, unsetting
MessageContext.paused, before control returns to one of the invoke
methods. If this happens, the logic in the invoke method, which looks
at the MessageContext.paused flag, will believe that it should continue
execution instead of halting.
Since the problem revolves around flow control logic, I suggest that we
use the return code from the method invocation to deal with it. I would
like to add a return code to the Handler.invoke(...) which would
identify how processing of the message should proceed, e.g. :
/**
* This type encapsulates an enumeration of possible message processing
* instruction values that may be returned by a handler/phase within the
* runtime.
*/
public class InvocationProcessingInstruction
{
public static InvocationProcessingInstruction CONTINUE_PROCESSING =
new InvocationProcessingInstruction(0);
public static InvocationProcessingInstruction SUSPEND_PROCESSING = new
InvocationProcessingInstruction(1);
public static InvocationProcessingInstruction ABORT_PROCESSING = new
InvocationProcessingInstruction(2);
private int instructionID;
private InvocationProcessingInstruction(int instructionID)
{
this.instructionID = instructionID;
}
public boolean equals(InvocationProcessingInstruction instruction)
{
return this.instructionID == instruction.instructionID;
}
public int hashCode()
{
return instructionID;
}
}
Most handlers will return
InvocationProcessingInstruction.CONTINUE_PROCESSING; the RM handler may
return that, SUSPEND_PROCESSING (for a pause), or ABORT_PROCESSING (for
a duplicate msg.)
Comments?
-Bill
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] When merging changes between branches please put the revision number that the changes are coming from into the commit message
e.g. Merged r23914 (Spelling fixes) from 1.1 branch. This makes it easier to keep track of which changes have been merged into where. Thanks. -Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Convention violations/ inconsistencies
Please do. +1 -Bill On Mon, 2006-10-02 at 17:19 +0530, Afkham Azeez wrote: Hi, There are a number of spelling mistakes/convention violations in some of the Axis2 API methods. e.g. public void disEngageModule(QName moduleName); Should be disengageModule(QName) In the axis2.xml the phase orders types named as follows: phaseOrder type=inflow phaseOrder type=outflow phaseOrder type=INfaultflow phaseOrder type=Outfaultflow As can be seen, no convention has been followed in naming these, and the same are used as tagnames in the module.xml files. Is it ok if I go ahead and fix these, at this moment? IMHO, we should fix these type of inconsistencies before 1.1 and have cleaner APIs configuration files. -- Thanks Afkham Azeez - 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]
[Axis2] Handler invocation pattern improvements (was Re: svn commit: r450121 - in /webservices/axis2/trunk/java/modules: integration/test/org/apache/axis2/engine/ kernel/src/org/apache/axis2/context/
I have backed out my commit as per the -1, and reopened JIRA 1233. Could you please now explain why you don't agree with my solution to the problem? -Bill On Tue, 2006-09-26 at 21:45 -0700, Bill Nagy wrote: Hi Sanjiva, While the JIRA issue may have had cleanup in the title, points 2 and 3 of the issue (and also Deepal's later comments) deal with what I fixed. I'm not sure that I understand why you say the impl that has been committed is going to slow Axis2 down big time. It makes one extra method invocation to each phase, which in turn makes one extra method call to each handler that was previously invoked for each message flow. If the handlers don't need to do anything, then that time is negligible -- if they do need to do something, then they need to do the work, and spend the time for a reason. -Bill On Wed, 2006-09-27 at 09:58 +0530, Sanjiva Weerawarana wrote: Hi Bill, This change actually addresses part of a JIRA issue that was marked as a blocker (AXIS2-653), and according to Thilina's post these are to be fixed before the release. (I will address the other part as well, but there were two separate issues so I separated this one out and tackled if first.) I think the original issue which was marked a blocker was that cleanup() wasn't called. That's not what's implemented by this patch. I am not opposed to solving the problem you want to solve with this patch but the impl that has been committed is going to slow Axis2 down big time. We have discussed the problem but IIRC didn't come to a consensus on the solution. I'd really rather work thru this more before we do it. If a performance degrading solution is the only one then I'd like to think long and hard about it before doing it. We've gotten hammered on the user mailing list for having stuff that is not fully baked in a major release. Doing this now (literally 2 days before the planned code freeze) is going to put in something that hasn't been tried, tested and proven into a major release. So, I'd like to request that we remove the blocker status on this issue and revert this patch. My apologies but I'm not lifting my -1 on this patch. I guess I should be arguing with the release manager for leaving this as a blocker! Let's pick it up after 1.1 and sort it out. ApacheCon US would be a great time to do it if you'll be around there. Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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]
[Axis2] Why does org.apache.axis2.deployment.util.PhasesInfo have hard coded phase names?
Is there a particular reason that 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. -Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] Why does sending out a fault require two passes through the phases?
Could someone please explain to me why when sending out a fault message, AxisEngine.sendFault(...) invokes all of the phases in the operation outFaultFlow and the global outFaultFlow with the type of MessageContext being set to OUT_FAULT_FLOW and then re-invokes the global outFaultFlow phases with the type of MessageContext being set to OUT_FLOW? (I understand the first part, but not the second invocation.) Also, this doesn't work the same way if the message flow pauses partially through the invocation, as the resume code won't make the second pass. -Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][Vote] Create a branch for the Axis2 1.1 release
Hi all, There's actually a good description of the why and how's of creating a release branch in the Subversion book (http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.branchmerge.commonuses.patterns.release) I don't understand why folks are saying that figuring out what goes where is tricky or that the work is that difficult. I agree with dims that the RM should be in charge of creating the branch for the release -- that branch is then the RM's responsibility. The RM gets to decide which bug fixes (or features I suppose) get added to the branch after it is made. The RM, however, has no more of a vote than anyone else as to what gets placed into the trunk. Bug fixes that are made to the release branch should most likely be committed to the trunk as well, but the RM doesn't have to be the one that does it. (If another committer made the change to the release branch, then they should probably also commit the change to the trunk.) Moving changes between branches with subversion is relatively trivial, and, unless the release drags on, I can't imagine that the code bases will diverge that much. -Bill On Fri, 2006-09-15 at 10:45 -0400, Rajith Attapattu wrote: I am also worried about the concerns raised by Ajith and then Eran. Especially the decision around when to create the branch and what fixes should be propagated to the trunk are going to be a bit tricky. I also agree that the workload for the RM is going to be increased substantially. How about if we free the RM of his other duties (bug fixes ..etc) and get him to do RM on a full-time basis during the release cycle? We need a person to fully manage the release process, especially make the important decisions of which fixes are propagated to trunk ..etc without being burdened by other tasks. Regards, Rajith On 9/15/06, Brent Ulbricht [EMAIL PROTECTED] wrote: +1 for a branch I agree that the branch would be best created when new function cannot be committed to head. Brent Ulbricht IBM Software Group - WebSphere FVT [EMAIL PROTECTED] Jeff Barrett/Austin/[EMAIL PROTECTED] 09/15/2006 07:49 AM Please respond to axis-dev@ws.apache.org To axis-dev@ws.apache.org cc Subject Re: [Axis2][Vote] Create a branch for the Axis2 1.1 release +1 to creating the branch. As to the timing of the creating the branch, It seems it needs to be created at the point when we are asked to stop committing new function to HEAD, i.e. code freeze. Thanks, Jeff IBM Software Group - WebSphere Web Services Development Phone: 512-838-4587 or Tie Line 678-4587 Internet e-mail and Sametime ID: [EMAIL PROTECTED] Nicholas L Gallardo/Austin/[EMAIL PROTECTED] 09/14/2006 04:18 PM Please respond to axis-dev@ws.apache.org To axis-dev@ws.apache.org cc Subject Re: [Axis2][Vote] Create a branch for the Axis2 1.1 release Ajith, Branching before would allow others to continue longer term development items while the final fixes are being applied to the upcoming release. Regards, Nicholas Gallardo WebSphere - WebServices Development [EMAIL PROTECTED] Phone: 512-838-1182 Building: 901 / 5G-016 Ajith Ranabahu [EMAIL PROTECTED] 09/14/2006 04:11 PM Please respond to axis-dev@ws.apache.org To axis-dev@ws.apache.org cc Subject Re: [Axis2][Vote] Create a branch for the Axis2 1.1 release Hi guys, If I understand right the branching usually happens at the same time of a release (or slightly after) and is usually used to fix issues in that particular release. We can definitely use a branch before the
[Axis2] Why does OutInAxisOperation invoke the InFlow and InFaultFlow when a fault is received in a response?
Is there a particular reason that the OutInAxisOperation invokes the InFlow (via AxisEngine.receive()) for all response messages, even though it could most likely use transport information (e.g. ask the transport if an error was returned) to determine that a fault had occurred and simply invoke the InFaultFlow (via AxisEngine.receiveFault())? As it stands now, the InFlow will be executed followed by the InFaultFlow. If the policy (i.e. set of QoS handlers) is different, executing the InFlow could cause the message processing to fail when it would have succeeded using the InFaultFlow. -Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][Vote] Create a branch for the Axis2 1.1 release
Hi Ajith, On Fri, 2006-09-15 at 16:42 -0400, Ajith Ranabahu wrote: Hi Bill, Yep - subversion makes it very easy to merge the branches. However it does not talk about conflicts ! So merging is easy if there are no conflicts. Also the authors must make sure they commit and apply the changes to the trunk (with the consent of the release manager of course) at the same time - a bit of a burden to the authors when the numbers are high. I'm not sure that I understand this last statement. The point of branching is that the code paths don't have to be identical, i.e. a change made to the release branch doesn't have to appear in the trunk at the same time. It doesn't really matter if a bug fix put into the release (or vice versa) appears in the trunk 2 seconds later or 2 days later. (It's unlikely that the code is going to diverge in that period so much as to make the change exponentially more difficult.) Again, the release manager should have no say (other than the one vote) about what goes into the trunk, but should have complete control over the release branch. SO We'll let the RM (Thilina) decide when to cut the branch. My personal feeling is you guys can keep on working in the trunk and the RM will cut a branch after the code freeze so that the trunk folks can move on without any hassel. Code freeze means the code is fairly stable so whatever the changes that happens to the branch will be minimal. Anyway its Thilina's call :) -Bill On 9/15/06, Bill Nagy [EMAIL PROTECTED] wrote: Hi all, There's actually a good description of the why and how's of creating a release branch in the Subversion book (http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.branchmerge.commonuses.patterns.release) I don't understand why folks are saying that figuring out what goes where is tricky or that the work is that difficult. I agree with dims that the RM should be in charge of creating the branch for the release -- that branch is then the RM's responsibility. The RM gets to decide which bug fixes (or features I suppose) get added to the branch after it is made. The RM, however, has no more of a vote than anyone else as to what gets placed into the trunk. Bug fixes that are made to the release branch should most likely be committed to the trunk as well, but the RM doesn't have to be the one that does it. (If another committer made the change to the release branch, then they should probably also commit the change to the trunk.) Moving changes between branches with subversion is relatively trivial, and, unless the release drags on, I can't imagine that the code bases will diverge that much. -Bill On Fri, 2006-09-15 at 10:45 -0400, Rajith Attapattu wrote: I am also worried about the concerns raised by Ajith and then Eran. Especially the decision around when to create the branch and what fixes should be propagated to the trunk are going to be a bit tricky. I also agree that the workload for the RM is going to be increased substantially. How about if we free the RM of his other duties (bug fixes ..etc) and get him to do RM on a full-time basis during the release cycle? We need a person to fully manage the release process, especially make the important decisions of which fixes are propagated to trunk ..etc without being burdened by other tasks. Regards, Rajith On 9/15/06, Brent Ulbricht [EMAIL PROTECTED] wrote: +1 for a branch I agree that the branch would be best created when new function cannot be committed to head. Brent Ulbricht IBM Software Group - WebSphere FVT [EMAIL PROTECTED] Jeff Barrett/Austin/[EMAIL PROTECTED] 09/15/2006 07:49 AM Please respond to axis-dev@ws.apache.org To axis-dev@ws.apache.org cc Subject Re: [Axis2][Vote] Create a branch for the Axis2 1.1 release +1 to creating the branch. As to the timing of the creating the branch, It seems it needs to be created at the point when we are asked to stop committing new function to HEAD, i.e. code freeze. Thanks, Jeff IBM Software Group - WebSphere Web Services Development Phone: 512-838-4587 or Tie Line 678-4587 Internet e-mail and Sametime ID: [EMAIL PROTECTED] Nicholas L Gallardo/Austin/[EMAIL PROTECTED] 09/14/2006 04:18 PM Please respond to axis-dev@ws.apache.org To axis-dev@ws.apache.org cc Subject Re: [Axis2][Vote
[Axis2][Vote] Create a branch for the Axis2 1.1 release
Hi all, I would like to propose that we create a branch in Subversion for the 1.1 release (and all future releases) so that we can continue development on the main trunk while the release is occurring. This would also enable us to make point fixes to each release without requiring that users adopt a whole bag of new features (i.e. the next release) in order to get bug fixes. (I'm not saying that we will backport all bug fixes, just that having the release branch would enable us to do so.) -Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] Options.getProperties() question
Is Options.getProperties() not supposed to return a full Map (including parent properties) or is the current code incorrect? (I'm voting for the later, but I figured that I'd ask before I made any changes.) -Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Build failing
Still doesn't work. This is all that I have in the repo (for XmlSchema that is): ~ ls -lah .maven/repository/org.apache.ws.commons/jars total 144K drwxrwxr-x 2 nagy nagy 4.0K Sep 8 21:05 ./ drwxrwxr-x 3 nagy nagy 4.0K Jun 19 13:38 ../ -rw-rw-r-- 1 nagy nagy 120K Sep 8 21:05 XmlSchema-SNAPSHOT.jar -Bill On Fri, 2006-09-08 at 19:05 -0400, Davanum Srinivas wrote: Please cleanup your old Xmlschema jar from your maven repo... On 9/8/06, Bill Nagy [EMAIL PROTECTED] wrote: I just pulled from Subversion, did a full build (maven clean; maven), and found that some of the codegen tests are failing: Testsuite: org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest Tests run: 4, Failures: 0, Errors: 4, Time elapsed: 0.397 sec Testcase: testScenarioOne(org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest): Caused an ERROR The prefix xs is not bound. java.lang.IllegalStateException: The prefix xs is not bound. at org.apache.ws.commons.schema.SchemaBuilder.getRefQName(SchemaBuilder.java:515) at org.apache.ws.commons.schema.SchemaBuilder.getRefQName(SchemaBuilder.java:496) at org.apache.ws.commons.schema.SchemaBuilder.handleElement(SchemaBuilder.java:1390) at org.apache.ws.commons.schema.SchemaBuilder.handleSequence(SchemaBuilder.java:956) at org.apache.ws.commons.schema.SchemaBuilder.handleComplexType(SchemaBuilder.java:584) at org.apache.ws.commons.schema.SchemaBuilder.handleElement(SchemaBuilder.java:1417) at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:143) at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:67) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:294) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:286) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest.loadSchema(SchemaUnwrapperExtensionTest.java:161) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest.createAndWalkSchema(SchemaUnwrapperExtensionTest.java:147) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest.testScenarioOne(SchemaUnwrapperExtensionTest.java:65) Testcase: testScenarioTwo(org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest): Caused an ERROR The prefix xs is not bound. java.lang.IllegalStateException: The prefix xs is not bound. at org.apache.ws.commons.schema.SchemaBuilder.getRefQName(SchemaBuilder.java:515) at org.apache.ws.commons.schema.SchemaBuilder.getRefQName(SchemaBuilder.java:496) at org.apache.ws.commons.schema.SchemaBuilder.handleElement(SchemaBuilder.java:1390) at org.apache.ws.commons.schema.SchemaBuilder.handleSequence(SchemaBuilder.java:956) at org.apache.ws.commons.schema.SchemaBuilder.handleComplexType(SchemaBuilder.java:584) at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:138) at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:67) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:294) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:286) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest.loadSchema(SchemaUnwrapperExtensionTest.java:161) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest.createAndWalkSchema(SchemaUnwrapperExtensionTest.java:147) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest.testScenarioTwo(SchemaUnwrapperExtensionTest.java:87) Testcase: testScenarioThree(org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest): Caused an ERROR The prefix ns is not bound. java.lang.IllegalStateException: The prefix ns is not bound. at org.apache.ws.commons.schema.SchemaBuilder.getRefQName(SchemaBuilder.java:515) at org.apache.ws.commons.schema.SchemaBuilder.getRefQName(SchemaBuilder.java:496) at org.apache.ws.commons.schema.SchemaBuilder.handleComplexContentExtension(SchemaBuilder.java:875) at org.apache.ws.commons.schema.SchemaBuilder.handleComplexContent(SchemaBuilder.java:713) at org.apache.ws.commons.schema.SchemaBuilder.handleComplexType(SchemaBuilder.java:614) at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:138) at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:67) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:294) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:286
[Axis2] Build failing
I just pulled from Subversion, did a full build (maven clean; maven), and found that some of the codegen tests are failing: Testsuite: org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest Tests run: 4, Failures: 0, Errors: 4, Time elapsed: 0.397 sec Testcase: testScenarioOne(org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest): Caused an ERROR The prefix xs is not bound. java.lang.IllegalStateException: The prefix xs is not bound. at org.apache.ws.commons.schema.SchemaBuilder.getRefQName(SchemaBuilder.java:515) at org.apache.ws.commons.schema.SchemaBuilder.getRefQName(SchemaBuilder.java:496) at org.apache.ws.commons.schema.SchemaBuilder.handleElement(SchemaBuilder.java:1390) at org.apache.ws.commons.schema.SchemaBuilder.handleSequence(SchemaBuilder.java:956) at org.apache.ws.commons.schema.SchemaBuilder.handleComplexType(SchemaBuilder.java:584) at org.apache.ws.commons.schema.SchemaBuilder.handleElement(SchemaBuilder.java:1417) at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:143) at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:67) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:294) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:286) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest.loadSchema(SchemaUnwrapperExtensionTest.java:161) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest.createAndWalkSchema(SchemaUnwrapperExtensionTest.java:147) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest.testScenarioOne(SchemaUnwrapperExtensionTest.java:65) Testcase: testScenarioTwo(org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest): Caused an ERROR The prefix xs is not bound. java.lang.IllegalStateException: The prefix xs is not bound. at org.apache.ws.commons.schema.SchemaBuilder.getRefQName(SchemaBuilder.java:515) at org.apache.ws.commons.schema.SchemaBuilder.getRefQName(SchemaBuilder.java:496) at org.apache.ws.commons.schema.SchemaBuilder.handleElement(SchemaBuilder.java:1390) at org.apache.ws.commons.schema.SchemaBuilder.handleSequence(SchemaBuilder.java:956) at org.apache.ws.commons.schema.SchemaBuilder.handleComplexType(SchemaBuilder.java:584) at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:138) at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:67) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:294) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:286) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest.loadSchema(SchemaUnwrapperExtensionTest.java:161) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest.createAndWalkSchema(SchemaUnwrapperExtensionTest.java:147) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest.testScenarioTwo(SchemaUnwrapperExtensionTest.java:87) Testcase: testScenarioThree(org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest): Caused an ERROR The prefix ns is not bound. java.lang.IllegalStateException: The prefix ns is not bound. at org.apache.ws.commons.schema.SchemaBuilder.getRefQName(SchemaBuilder.java:515) at org.apache.ws.commons.schema.SchemaBuilder.getRefQName(SchemaBuilder.java:496) at org.apache.ws.commons.schema.SchemaBuilder.handleComplexContentExtension(SchemaBuilder.java:875) at org.apache.ws.commons.schema.SchemaBuilder.handleComplexContent(SchemaBuilder.java:713) at org.apache.ws.commons.schema.SchemaBuilder.handleComplexType(SchemaBuilder.java:614) at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:138) at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:67) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:294) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:286) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest.loadSchema(SchemaUnwrapperExtensionTest.java:161) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest.createAndWalkSchema(SchemaUnwrapperExtensionTest.java:147) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest.testScenarioThree(SchemaUnwrapperExtensionTest.java:108) Testcase: testScenarioFour(org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest): Caused an ERROR The prefix ns is not bound. java.lang.IllegalStateException: The prefix ns is not bound. at
[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]
Re: [jira] Commented: (AXIS2-938) Plugpoint to allow for migration between context and TLS
Hi dims, If all you are asking me for is to add calls into the other MessageReceiver's and the ServiceClient, I'd be happy to do it; I just didn't have a use case that required that, so didn't want to clutter the code. Alternatively I can make it more explicit in the comments that it is up to the programming model layer to make these invocations, and that not all may. (The migrators really border between the QoSes and the PM-level code, so anyone implementing one has to understand the PM-layer as well anyways.) Which would you prefer (or did I miss what you were trying to explain?) -Bill On Mon, 2006-07-31 at 14:58 -0400, Davanum Srinivas wrote: Bill, If we decide to mode the whole thing into modules/core, then i will have no problem keeping the methods for migrators and make it similar to modules, transports, phases etc. Here's my problem, the Patch does not reflect the intention. If you check it in as-is right now. Anyone using the core module and *NOT* using module/jaxws will scratch their heads as their entry points are *NEVER* called from the code. Do you see the problem? thanks, dims On 7/31/06, Bill Nagy (JIRA) [EMAIL PROTECTED] wrote: [ 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (AXIS2-938) Plugpoint to allow for migration between context and TLS
Hi Sanjiva, Unless I'm not explaining it well, the only piece that is different from what I had described earlier (http://marc.theaimsgroup.com/?l=axis-devm=115270290506219w=2) is the interface; there are now two extra methods to make it more clear to someone who is writing a migrator (or reading the PM-level code) what the migrator is supposed to be doing (i.e. moving info from the context to the TLS or vice versa.) If that doesn't help, RTFP 8-]. -Bill On Mon, 2006-07-31 at 23:53 +0530, Sanjiva Weerawarana wrote: On Mon, 2006-07-31 at 10:41 -0700, Bill Nagy (JIRA) wrote: (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. I haven't had a chance to go thru the patch yet .. any chance of sending a description of it? From the discussion I see its somewhat diff from what was originally suggested (which is cool of course). If u want to tell me RTFP I'll accept it :). Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [AXIS2] [Sandesha2] Saving the message context
On Fri, 2006-07-28 at 23:46 -0400, Rajith Attapattu wrote: Anne, Again I will advice again serializing the contexts using any form of serialization. This will not scale at all in a production environment. Hi Rajith, Could you please explain this last comment? Again this approach will be error prone and as chamikara mentioned there will be too many information saved in the database. I don't understand why you and Chamikara keep saying that there will be too much information serialized. You have the option of taking complete control of the serialization, thereby writing/reading only the information that you want and in the form that you want it to be in. I don't believe that Ann is arguing for simply using the default serialization, only about who should be in control of making the decisions as to what should be saved. I am looking at clustering certain information within the ctx heirachy for high availability and I would only do with the bare minimum. In my opinion the performance overhead of serializing and deserializing (and validations to avoid erros) is a lot more than saving the required info in a bean like what chamikara does for Sandesha and then reconstructing it. Having the objects persist their own state is far less error prone than having a third-party piece of code do the persistence. For one, anytime someone changes or adds a piece of information that needs to be saved in order to correctly restore the state, they have to remember to modify the external code. It's generally hard enough to remember to modify code embedded in the class itself, much less having to remember to modify a completely separate piece of code. Secondly, you require the objects that need to be saved to expose methods, to return the portions that you want to have serialized, that you may not have to expose otherwise. In effect, the approach that you've chosen has abandoned encapsulation and created fragile dependencies -- this is bad design. -Bill Regards, Rajith On 7/28/06, Chamikara Jayalath [EMAIL PROTECTED] wrote: Hi Ann, Yes. We had introduced Externalizable implementaitons for all of the Context hierarchy objects sometime back. But this approach seemed to be saving too much information on the database. For example at some point there may be following context objects available in a running axis2 instance. 1. configuration context object 2. service group context objects 3 service context objects 4. Operation context objects 5. A lot of message context objects If we try serializing starting from a message context, since we have to serialize every incoming message context all these objects will be serialized every time (recall that the message context hs a link to the configuration context which has links to all other context objects). Think how deficult the reconstruction would be. Every deserialized message context will come up with its own hierarchy of context objects which may not map with the context objects reconstructed by deserializing others message contexts. Thats why I went for this approach of saving only the relavent information. It seemed to be much cleaner and it was working :-) You had mentioned about serializing the AxisOperaion object. All the 'Axis*' objects in Axis2 (AxisConfiguration, AxisServiceGroupt etc.) contains deployment time information. So we can safely ignore them in the serializing process. Chamikara On 7/29/06, Ann Robinson [EMAIL PROTECTED] wrote: Hi Chamikara, Thanks for the information. Did you consider using java.io.Externalizable for the AXIS2 message context-related classes? (Having the work done by the AXIS2 objects would have simplified the actions that Sandesha needed to take in order to save the message context, so I am curious about any issues that were encountered. In the MessageStoreBean, how much of the various objects do you store as Strings? For example, the AxisOperation object contains several lists and the executionChain object contains a list of handlers and phases. Ann WebSphere Development, Web Services Engine IBM 11501 Burnet Rd IZip 9035G021 Austin, TX 78758
[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]
Re: [Axis2] Plugpoint to allow for migration between context and TLS
This took a little longer than I would have liked, but I've opened a JIRA issue (Axis2-938) and attached my patch. Comments are welcome. -Bill On Wed, 2006-07-12 at 14:20 -0400, Bill Nagy wrote: Hi Sanjiva, Logically, you can think of them as an extension to the handler mechanism that runs at the border between the core Axis2 code and the programming model layer (e.g. in the JAX-WS case they'll be run inside of the JAXWSMessageReceiver, the jaxws...AxisInvocationController, and the jaxws...AxisCallback (I believe.)) They're really just a set of utility methods that get invoked to bridge between the Axis2 context model and the external programming model that is exposed to the end user, so they don't have a lifecycle per say. I specifically haven't tied the registration of the migrators (I'm happy for a different name 8-]) to a handler or module, as (1) they are programming model specific, while the modules/handlers deal with the Axis2 model and (2) on the sender side, the modules may not have been engaged by the time that this code needs to execute. Implementation of the migrators falls somewhere between the responsibility of the programming model implementor and the QoS implementor -- as I said, it's really bridging code. I will try to send out the diffs of my code later today after I get the changes put into the new JAX-WS code. -Bill On Wed, 2006-07-12 at 22:12 +0530, Sanjiva Weerawarana wrote: On Wed, 2006-07-12 at 09:40 -0400, Bill Nagy wrote: Hi dims, Sure. You are correct, there is no TLS code currently in Axis2. However we (IBM) have several cases (e.g. security) where we need to migrate information between the Axis2 contexts and TLS. For example, we have identity APIs that rely upon tokens being placed in TLS. While we can have the handler place the information in the MessageContext for example, we need to move it to TLS before we enter user space, so that if the user invokes one of our security APIs the information will be available. (We also need to make sure that the info is removed from TLS when we're done, hence the flowComplete() method.) So is this basically a utility class that a specific handler invokes? Or are you suggesting that people register these migrators against a handler and then they get invoked upon entry/exit? I guess the lifecycle and programming model for TCMigrators is not clear enough to me yet! Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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]
