Re: [VOTE] Web Services Reorg Part 1 : Axis2 TLP
+1 Thanks, Keith. On Sat, Nov 7, 2009 at 6:59 PM, Prabath Siriwardena prab...@wso2.comwrote: +1 Thanks regards. -Prabath 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 -- Thanks, Keith. Keith Chapman blog: http://www.keith-chapman.org
Re: [Axis2] release process
Hi Mike, That you for your contribution, we appreciate it. I assigned the two issues you had raised, one of them to Amila cause he is the guy more familiar with the code generation process. He will go through your patch and commit it. In the mean time I'll have a look at the other issue you raised. Hence these issues will be fixed in the next release. Thanks, Keith. On Tue, Nov 3, 2009 at 4:46 AM, Michail Prusakov michail.prusa...@jmsys.ltwrote: Hello, I have registered a few issues in JIRA, posted the fixes for them and have a very simple question: will they ever make it to the officially released version? (yes, I have read here: http://ws.apache.org/axis2/release-process.html) Regards, Mike -- Thanks, Keith. Keith Chapman blog: http://www.keith-chapman.org
Re: [VOTE] Axis2 1.5.1 - final vote (I hope :) )
+1 binding. Thanks, Keith. On Tue, Oct 20, 2009 at 10:48 AM, Glen Daniels g...@thoughtcraft.comwrote: OK, after adding the default 30-second timeout for connection starvation issues, and confirming that Rampart now works fine with 1.5.1, let's try this one more time. Please VOTE on releasing 1.5.1 - then we can get moving on 1.6! You can find the distribution files in here: http://people.apache.org/~gdaniels/stagingRepo/org/apache/axis2/distribution/1.5.1/http://people.apache.org/%7Egdaniels/stagingRepo/org/apache/axis2/distribution/1.5.1/ And the M2 repository with everything is at: http://people.apache.org/~gdaniels/stagingRepohttp://people.apache.org/%7Egdaniels/stagingRepo The SVN tag is: http://svn.apache.org/repos/asf/webservices/axis2/tags/java/v1.5.1RC3 ...and I'll add a proper v1.5.1 tag as soon as this release goes final. Please offer your VOTE (and indicate binding/non-binding). Here's my +1 (binding). Many thanks, --Glen -- Thanks, Keith. Keith Chapman blog: http://www.keith-chapman.org
Re: axis2 security bug?
=true //ns:return/ns:getPatientDetailsResponse/soapenv:Body/soapenv:Envelope 0 Auchh, without user authentication neither SSL transport :S -- Jaime Hablutzel (tildes omitidas intencionalmente) 9 8964 0369 -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/ -- Jaime Hablutzel (tildes omitidas intencionalmente) 9 8964 0369 -- Thanks, Keith. Keith Chapman blog: http://www.keith-chapman.org
Re: Supporting hierarchical service deployment
a contextPath=xxx option in services.xml as well. However, treating the file system hierarchy as a hierarchy is, you know, rather natural. I think Isuru has shown that there is no extra performance loss or any other loss by supporting hierachically deployed services. You DON'T need to use them unless you want to of course - and if there's no hierarchy there's no change at all (subject to having enough unit tests to make sure that old and new behavior for the old feature is not changed). Sanjiva. On Sat, Aug 29, 2009 at 7:05 PM, Deepal jayasinghe deep...@gmail.comwrote: On Fri, Aug 28, 2009 at 8:30 PM, Andreas Veithen andreas.veit...@gmail.com mailto:andreas.veit...@gmail.com wrote: Guys, Are we actually discussing the right question? Looking at the patch proposed by Isuru, I have the impression that versioning is merely one use case, but that (in contrast to modules) the code doesn't make any assumption about the meaning of the hierarchy in the repository (it could be version number, but it could also something completely different). Fundamentally the change is not about versioning, but about giving the user the possibility to define the structure of the endpoint URL. yes. this should be the idea. it is to support hierarchical service folder structure to mange services. Versioning is only one possible use case. I think this is a common requirement. For an example if we take a web site people don't put all their .jsp or .html files in the root directory. They manage them in a some meaningful folder structure and even page url maps to it. You are mistaken in the case of web site .jsp files are like .class files. So even in Web Service we have package hierarchy. I can hardly think of any reason for opposing to introduce such feature to axis2 service deployment provided that it *does not break existing functionality*. If you look at the directory structure (as I told you before) information repeat it self. It is analogous to Shop is closed because it is not open. Just because feature X is good in project Y, we should not introduce that to Axis2. If you or someone want to do such a feature of course they can do that, just ad a new deployer to handle the they want, even in you case we can do the same. Let's create a new deployer and manage anyway you like, and then if you think it is ok, then commit the new deployer to Axis2. However I am not ok with introducing new URL pattern, I think Isuru already agreed to replace / with - Deepal, I feel you have given over weight to the versioning support which is a use case of this. In the way to have told people can have versioning without any support of axis2, by just naming service in the way they need. Yes. At the end of the day whether it is / or - would become a unique name. So it is the service name. Comming into the other point of probable break of existing functionality Can you please come up with the set of use case scenarios for this? Then we can ask Isuru to provide integration test for all these scenarios. This may test the existing functionality as well :) I am sorry I do not have time to comeup with scenarios when someone add new features, specially even without going through the existing JIRA. I think we should not be pessimistic and think deployment engine is done for ever and any change will break it. Not at all, how many changes we made, in this case my concern is not the deployment engine it is the URL pattern. Isuru, Please provide a set of integration tests for the scenarios mentioned. :) Thanks, Deepal -- Sanjiva Weerawarana, Ph.D. Founder, Director Chief Scientist; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ -- Sanjiva Weerawarana, Ph.D. Founder, Director Chief Scientist; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ -- Keith Chapman blog: http://www.keith-chapman.org
Re: Unable to upgrade to axis2 1.4.1 or 1.5
-- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: Axis2 API design issue, Should we fix it?
Shall we go ahead with this change then? Thanks, Keith. On Wed, May 6, 2009 at 7:11 PM, Amila Suriarachchi amilasuriarach...@gmail.com wrote: On Wed, May 6, 2009 at 4:33 PM, Glen Daniels g...@thoughtcraft.comwrote: Amila Suriarachchi wrote: Hm - it seems like you didn't actually get my point. We CAN'T return the actual allServices map because that would be breaking the abstraction boundary provided by the class. As I remember this change was done to avoid concurrent modifications to service map[1]. Right - before this change we were doing something actively bad/wrong, i.e. returning the internal map. After the change we were returning a cloned copy of the map (though not using clone() for some reason), which is good in that it prevented people from misusing it. At that time services map was a HashMap and could not fix the issue by changing it to a ConcurrentHashMap since API method returns a HashMap. Currently anyone can get a copy of internal map (I think we can not use clone() method since internal implementation is ConcurrentHashMap and we need to return a HashMap). And if they want to add or remove service they have to use addService and removeService respectively. Keith, if you really need the internal map IMHO best way is to add a new API method. Ah, no. The best way is NOT TO OFFER ACCESS TO THE INTERNAL MAP. Keith's suggestion is to change the API so that it returns a Map - this would be much more correct since it increases the level of abstraction for the method, and would therefore let us, the implementors, freely decide how this should work internally. Right now we have problems because someone made this method overly specific, and this is what we should fix. (I was incorrect earlier when I said this wouldn't break people, btw - I was thinking about stuff like getServices().get(MyService), but of course HashMap foo = getServices() would fail. I still think we should fix it.) My comment is that we should not only return a Map, we should change the implementation to make sure the Map is immutable, and make sure the JavaDoc explains what is going on. +1. Here the real problem is this API contains a hashMap instead of Map. What I got from the Keiths' first mail is that he need the API change to return the internal map without copying. I suggested to add a new method if he really need it so that only he use that method. I agree with you that this is not a good change. thanks, Amila. Make sense? --Glen -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/ -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: Axis2 API design issue, Should we fix it?
I don't think we can put it into 1.5. Lets make the change in the trunk so that it will be available in the next release. Thanks, Keith. On Mon, May 11, 2009 at 1:45 PM, Andreas Veithen andreas.veit...@gmail.comwrote: +1, but we need to agree on the target release for this change. Andreas On Mon, May 11, 2009 at 09:57, keith chapman keithgchap...@gmail.com wrote: Shall we go ahead with this change then? Thanks, Keith. On Wed, May 6, 2009 at 7:11 PM, Amila Suriarachchi amilasuriarach...@gmail.com wrote: On Wed, May 6, 2009 at 4:33 PM, Glen Daniels g...@thoughtcraft.com wrote: Amila Suriarachchi wrote: Hm - it seems like you didn't actually get my point. We CAN'T return the actual allServices map because that would be breaking the abstraction boundary provided by the class. As I remember this change was done to avoid concurrent modifications to service map[1]. Right - before this change we were doing something actively bad/wrong, i.e. returning the internal map. After the change we were returning a cloned copy of the map (though not using clone() for some reason), which is good in that it prevented people from misusing it. At that time services map was a HashMap and could not fix the issue by changing it to a ConcurrentHashMap since API method returns a HashMap. Currently anyone can get a copy of internal map (I think we can not use clone() method since internal implementation is ConcurrentHashMap and we need to return a HashMap). And if they want to add or remove service they have to use addService and removeService respectively. Keith, if you really need the internal map IMHO best way is to add a new API method. Ah, no. The best way is NOT TO OFFER ACCESS TO THE INTERNAL MAP. Keith's suggestion is to change the API so that it returns a Map - this would be much more correct since it increases the level of abstraction for the method, and would therefore let us, the implementors, freely decide how this should work internally. Right now we have problems because someone made this method overly specific, and this is what we should fix. (I was incorrect earlier when I said this wouldn't break people, btw - I was thinking about stuff like getServices().get(MyService), but of course HashMap foo = getServices() would fail. I still think we should fix it.) My comment is that we should not only return a Map, we should change the implementation to make sure the Map is immutable, and make sure the JavaDoc explains what is going on. +1. Here the real problem is this API contains a hashMap instead of Map. What I got from the Keiths' first mail is that he need the API change to return the internal map without copying. I suggested to add a new method if he really need it so that only he use that method. I agree with you that this is not a good change. thanks, Amila. Make sense? --Glen -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/ -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: Axis2 API design issue, Should we fix it?
AFAIK there have been quite a bit of development on the trunk since the Axis2 1.5 branch was cut hence if we are to do a 1.5.1 release it will have to be done off the 1.5 branch and not the trunk. Hence I don't see an issue with doing this change on the trunk. Thanks, Keith. On Mon, May 11, 2009 at 3:09 PM, Andreas Veithen andreas.veit...@gmail.comwrote: Please note that changing the return types from concrete implementations to interfaces will break binary compatibility. This means that if we do the change on trunk now, the next release from trunk should be a major release, i.e. 1.6. How are we going to handle the case where we need to produce a new release quickly after 1.5 to fix serious issues (don't forget that 1.4.1 was produces by merging only selected changes from trunk to 1.4 and that therefore 1.5 contains probably lots of changes)? If we don't do the API changes immediately, then we keep the option of doing a 1.5.1 maintenance release from the trunk. Andreas On Mon, May 11, 2009 at 10:27, keith chapman keithgchap...@gmail.com wrote: I don't think we can put it into 1.5. Lets make the change in the trunk so that it will be available in the next release. Thanks, Keith. On Mon, May 11, 2009 at 1:45 PM, Andreas Veithen andreas.veit...@gmail.com wrote: +1, but we need to agree on the target release for this change. Andreas On Mon, May 11, 2009 at 09:57, keith chapman keithgchap...@gmail.com wrote: Shall we go ahead with this change then? Thanks, Keith. On Wed, May 6, 2009 at 7:11 PM, Amila Suriarachchi amilasuriarach...@gmail.com wrote: On Wed, May 6, 2009 at 4:33 PM, Glen Daniels g...@thoughtcraft.com wrote: Amila Suriarachchi wrote: Hm - it seems like you didn't actually get my point. We CAN'T return the actual allServices map because that would be breaking the abstraction boundary provided by the class. As I remember this change was done to avoid concurrent modifications to service map[1]. Right - before this change we were doing something actively bad/wrong, i.e. returning the internal map. After the change we were returning a cloned copy of the map (though not using clone() for some reason), which is good in that it prevented people from misusing it. At that time services map was a HashMap and could not fix the issue by changing it to a ConcurrentHashMap since API method returns a HashMap. Currently anyone can get a copy of internal map (I think we can not use clone() method since internal implementation is ConcurrentHashMap and we need to return a HashMap). And if they want to add or remove service they have to use addService and removeService respectively. Keith, if you really need the internal map IMHO best way is to add a new API method. Ah, no. The best way is NOT TO OFFER ACCESS TO THE INTERNAL MAP. Keith's suggestion is to change the API so that it returns a Map - this would be much more correct since it increases the level of abstraction for the method, and would therefore let us, the implementors, freely decide how this should work internally. Right now we have problems because someone made this method overly specific, and this is what we should fix. (I was incorrect earlier when I said this wouldn't break people, btw - I was thinking about stuff like getServices().get(MyService), but of course HashMap foo = getServices() would fail. I still think we should fix it.) My comment is that we should not only return a Map, we should change the implementation to make sure the Map is immutable, and make sure the JavaDoc explains what is going on. +1. Here the real problem is this API contains a hashMap instead of Map. What I got from the Keiths' first mail is that he need the API change to return the internal map without copying. I suggested to add a new method if he really need it so that only he use that method. I agree with you that this is not a good change. thanks, Amila. Make sense? --Glen -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/ -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: Axis2 API design issue, Should we fix it?
+1 Sounds good to me. Thanks, Keith. On Mon, May 11, 2009 at 3:58 PM, Andreas Veithen andreas.veit...@gmail.comwrote: I forgot about the refactoring of the clustering API, which is in trunk but didn't go into 1.5. That indeed means that that we can't do a 1.5.1 release from trunk. To summarize, the roadmap for the months after the 1.5 release (when is this actually going to happen?) would look like this: Release 1.5.1 (from 1.5 branch): - Critical bug fixes (if required) - Changes that didn't make it into 1.5 (e.g. the changes in axis2-saaj) and that can easily be merged from the trunk (if there is a user demand for this) Release 1.6 (current trunk): - API cleanup (concrete classes - interfaces) - Refactoring of the clustering API (already in trunk) - Improvements to message builder/formatter API and implementations, as discussed in December - Clarifications and improvements in the transport API (if I'm not mistaken, there was a discussion around this some time ago) - ... If everybody is fine with this, then we should go ahead. Andreas On Mon, May 11, 2009 at 11:51, keith chapman keithgchap...@gmail.com wrote: AFAIK there have been quite a bit of development on the trunk since the Axis2 1.5 branch was cut hence if we are to do a 1.5.1 release it will have to be done off the 1.5 branch and not the trunk. Hence I don't see an issue with doing this change on the trunk. Thanks, Keith. On Mon, May 11, 2009 at 3:09 PM, Andreas Veithen andreas.veit...@gmail.com wrote: Please note that changing the return types from concrete implementations to interfaces will break binary compatibility. This means that if we do the change on trunk now, the next release from trunk should be a major release, i.e. 1.6. How are we going to handle the case where we need to produce a new release quickly after 1.5 to fix serious issues (don't forget that 1.4.1 was produces by merging only selected changes from trunk to 1.4 and that therefore 1.5 contains probably lots of changes)? If we don't do the API changes immediately, then we keep the option of doing a 1.5.1 maintenance release from the trunk. Andreas On Mon, May 11, 2009 at 10:27, keith chapman keithgchap...@gmail.com wrote: I don't think we can put it into 1.5. Lets make the change in the trunk so that it will be available in the next release. Thanks, Keith. On Mon, May 11, 2009 at 1:45 PM, Andreas Veithen andreas.veit...@gmail.com wrote: +1, but we need to agree on the target release for this change. Andreas On Mon, May 11, 2009 at 09:57, keith chapman keithgchap...@gmail.com wrote: Shall we go ahead with this change then? Thanks, Keith. On Wed, May 6, 2009 at 7:11 PM, Amila Suriarachchi amilasuriarach...@gmail.com wrote: On Wed, May 6, 2009 at 4:33 PM, Glen Daniels g...@thoughtcraft.com wrote: Amila Suriarachchi wrote: Hm - it seems like you didn't actually get my point. We CAN'T return the actual allServices map because that would be breaking the abstraction boundary provided by the class. As I remember this change was done to avoid concurrent modifications to service map[1]. Right - before this change we were doing something actively bad/wrong, i.e. returning the internal map. After the change we were returning a cloned copy of the map (though not using clone() for some reason), which is good in that it prevented people from misusing it. At that time services map was a HashMap and could not fix the issue by changing it to a ConcurrentHashMap since API method returns a HashMap. Currently anyone can get a copy of internal map (I think we can not use clone() method since internal implementation is ConcurrentHashMap and we need to return a HashMap). And if they want to add or remove service they have to use addService and removeService respectively. Keith, if you really need the internal map IMHO best way is to add a new API method. Ah, no. The best way is NOT TO OFFER ACCESS TO THE INTERNAL MAP. Keith's suggestion is to change the API so that it returns a Map - this would be much more correct since it increases the level of abstraction for the method, and would therefore let us, the implementors, freely decide how this should work internally. Right now we have problems because someone made this method overly specific, and this is what we should fix. (I was incorrect earlier when I said this wouldn't break people, btw - I was thinking about stuff like getServices().get(MyService), but of course HashMap foo = getServices() would fail. I still think we should fix
Re: Axis2 API design issue, Should we fix it?
+1 for making the return Map and returning Collections.unmodifiableMap(allServices); Thanks, Keith. On Wed, May 6, 2009 at 4:33 PM, Glen Daniels g...@thoughtcraft.com wrote: Amila Suriarachchi wrote: Hm - it seems like you didn't actually get my point. We CAN'T return the actual allServices map because that would be breaking the abstraction boundary provided by the class. As I remember this change was done to avoid concurrent modifications to service map[1]. Right - before this change we were doing something actively bad/wrong, i.e. returning the internal map. After the change we were returning a cloned copy of the map (though not using clone() for some reason), which is good in that it prevented people from misusing it. At that time services map was a HashMap and could not fix the issue by changing it to a ConcurrentHashMap since API method returns a HashMap. Currently anyone can get a copy of internal map (I think we can not use clone() method since internal implementation is ConcurrentHashMap and we need to return a HashMap). And if they want to add or remove service they have to use addService and removeService respectively. Keith, if you really need the internal map IMHO best way is to add a new API method. Ah, no. The best way is NOT TO OFFER ACCESS TO THE INTERNAL MAP. Keith's suggestion is to change the API so that it returns a Map - this would be much more correct since it increases the level of abstraction for the method, and would therefore let us, the implementors, freely decide how this should work internally. Right now we have problems because someone made this method overly specific, and this is what we should fix. (I was incorrect earlier when I said this wouldn't break people, btw - I was thinking about stuff like getServices().get(MyService), but of course HashMap foo = getServices() would fail. I still think we should fix it.) My comment is that we should not only return a Map, we should change the implementation to make sure the Map is immutable, and make sure the JavaDoc explains what is going on. Make sense? --Glen -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Axis2 API design issue, Should we fix it?
Hi all,
Due to a design issue in the Axis2 API we have implemented the getServices()
method as follows,
public HashMapString, AxisService getServices() {
HashMapString, AxisService hashMap = new HashMapString,
AxisService(this.allServices.size());
String key;
for (IteratorString iter = this.allServices.keySet().iterator();
iter.hasNext();){
key = iter.next();
hashMap.put(key, this.allServices.get(key));
}
return hashMap;
}
In my view this is highly inefficient, especially if you have plenty of
services in the system. Wouldn't it be better to fix the API and return a
Map instead of a HashMap? If we did that we could simple return allServices
instead of returning a copy of it.
If we are making this change I propose that we fix this for modules,
transports as well.
Thanks,
Keith.
--
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://www.keith-chapman.org
Re: Axis2 API design issue, Should we fix it?
On Wed, May 6, 2009 at 1:50 AM, Glen Daniels g...@thoughtcraft.com wrote:
Hi Keith!
keith chapman wrote:
Due to a design issue in the Axis2 API we have implemented the
getServices() method as follows,
public HashMapString, AxisService getServices() {
HashMapString, AxisService hashMap = new HashMapString,
AxisService(this.allServices.size());
String key;
for (IteratorString iter =
this.allServices.keySet().iterator(); iter.hasNext();){
key = iter.next();
hashMap.put(key, this.allServices.get(key));
}
return hashMap;
}
In my view this is highly inefficient, especially if you have plenty of
services in the system. Wouldn't it be better to fix the API and return
a Map instead of a HashMap? If we did that we could simple return
allServices instead of returning a copy of it.
You don't want to return an actual reference to a mutable object that backs
a
significant data model - otherwise people could just get that Map and
(mistakenly or maliciously) randomly add and delete services.
Agreed. But now that we've been doing it people may have code that expect it
to be there. So we need a mechanism for returning this map.
However, your point about the HashMap in the API is entirely right - we
should make it a Map (which shouldn't break anyone already using it in it's
more specific form). Also, I'm not sure why we're not just returning
allServices.clone()... NIH? :)
I was wondering the same. So your in agreement for changing the API and
returning a Map. Cool.
Thanks,
Keith.
If we are making this change I propose that we fix this for modules,
transports as well.
Sure.
--Glen
--
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://www.keith-chapman.org
Re: Axis2 API design issue, Should we fix it?
See comments inline. On Wed, May 6, 2009 at 8:39 AM, Glen Daniels g...@thoughtcraft.com wrote: keith chapman wrote: In my view this is highly inefficient, especially if you have plenty of services in the system. Wouldn't it be better to fix the API and return a Map instead of a HashMap? If we did that we could simple return allServices instead of returning a copy of it. You don't want to return an actual reference to a mutable object that backs a significant data model - otherwise people could just get that Map and (mistakenly or maliciously) randomly add and delete services. Agreed. But now that we've been doing it people may have code that expect it to be there. So we need a mechanism for returning this map. Um - we aren't currently returning the actual Map, we're returning a clone of it (just done manually instead of using clone()). You had suggested returning the actual Map itself, which is what I was reacting to above. I'm not saying the API should go away. The reason we have implemented a clone is the limitation in the API. If the return type was Map we could have returned the allServices map. Wouldn't this clone be expensive when there are lots of services deployed? +1 to adding JavaDoc saying that please use this map for reading purposes only. Thanks, Keith. rant Of course, if we had any kind of reasonable JavaDoc, there would be a clear indication in the API docs that the returned HashMap was in fact a clone and that inserting or removing things from it would have no effect on the system. /rant Thanks, --Glen -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: invoking a method while undeploying? (like finalize of Object)
Have you lookes at ServiceLifeCycle support in Axis2? Please refer [1] for a tutorial on what it is how to use it. Thanks, Keith. [1] http://wso2.org/library/333 On Wed, Apr 29, 2009 at 6:58 PM, Martin Fernau m.fer...@cps-net.de wrote: Dear all Axis developers, If axis is on the way to undeply a service, is it possible to let axis invoke a method on this Service? Something like implementing a pre defined interface from axis2 (maybe WebService) which defines one method (maybe undeploying() ) which will be called from axis if this webservice is going to be undeployed. In this way the developer has a chance to do several things (cleanup and so on) just before this service is undeployed. Think on this like the finalize-Method of Object. Regards, Martin Fernau -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: Which WSDL version
Hi, ?wsdl generates WSDL 1.1 while ?wsdl2 generates WSDL 2.0. Thanks, Keith. On Thu, Apr 23, 2009 at 2:09 PM, Rudy rud...@gmail.com wrote: Hello, How to know which version of WSDL (1.1 or 2.0) is generated by Axis ? Thank You. -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: using Axiom instead of DOM in ServiceClient.
Sounds good to me. Thanks, Keith. On Thu, Mar 19, 2009 at 9:52 AM, Pradeep Fernando pradee...@gmail.comwrote: hi All, @ Sagara yes, possible to use same existing copy, I think this line gives wrong impression . Description descComp = reader.readWSDL(wsdlLoc); Yes it mislead me. Even the user guide at the woden site gives a wrong impression on the above method. In that case we can use DOM as the WSDL representation model without a problem. So as Sagara proposed we can work it out like this. -read the WSDL and get it as the DOM model. -compare namespaces. -if WSDL11 read it using reader and get a WSDL4J.Definition, in order to feed WSDL11ToAxisServiceBuilder -if WSD20 read it using reader(given that it supports DOM), and get a WODEN.Description to feed WSDL20ToAxisserviceBuilder. Thus we have to add a new constructor in the WSDL20ToAxisServiceBuilder supporting Woden.Description. This will make sure the consistency between WSDL20ToAxisServiceBuilder WSDL11ToAxisserviceBuilder as the latter has a constructor supporting WSDL4J.Definiton. Thanks Andreas,Sagara Keith for your suggestions, This seems to be the perfect solution for me. WDYT devs? cheers, Pradeep Fernando. -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: using Axiom instead of DOM in ServiceClient.
I'm not sure how complete the AXIOM implementation is. The DOM is complete. I will ask this issue on the Woden list. Thanks, Keith. On Tue, Mar 17, 2009 at 4:24 AM, Andreas Veithen andreas.veit...@gmail.comwrote: What about improving WSDL20ToAxisServiceBuilder to support DOM and/or Axiom directly (I think Woden supports both)? Andreas On Mon, Mar 16, 2009 at 06:19, Pradeep Fernando pradee...@gmail.com wrote: Hi Devs, Right now Axis2 s' ServiceClient(Dynamic serviceClient) does not support WSDL2 as it argument. I did few changes to the Code and now it supports WSDL2 as well. But I would like to draw your attention regarding few issues. 1. In order to support both WSDL11 WSDL20 without changing the method signature of the ServiceClient we need to identify the Given WSDL using the namespace. 2. In the current code It uses a dom Element to Represent the WSDL.But in this scenario we need to check the namespace and if it is a WSDL11 Get the javax.wsl.Definition from the reader or else if it is WSDL20, serialize it and write it to a output stream so we can get it as a input stream to build a AxisService out of WSDL20. 3.since the current implementation uses dom element this mechanism results in a double parsing when its a WSDL20.possible solution is using Axiom instead of dom so that when namespace checking it does not parse the entire WSDL. 4. So i replaced Dom with Axiom and used Doom to create the Dom element out of Axiom element when need to fed to the readWSDL() method of the WSDL reader. WDYT devs? comments ,suggestions are mostly welcome. The patch related to this issue can be found in [1] Thanks in advance, Pradeep Fernando. [1] https://issues.apache.org/jira/browse/AXIS2-4253 -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: Improvements to Axis2 Faulty Services Handling
On Fri, Mar 13, 2009 at 2:38 PM, Sameera Jayasoma sameera.madus...@gmail.com wrote: Hi devs, According to the current design of Axis2, faulty services are detected only by the relevant deployer. In order improve the faulty services handling, I need to maintain more information about the faulty services such as, exact error, axis service object. This information is needed when deploying faulty services as normal services. With the current desing, this change has to be implemented in every deployer which uses services.xml file or any other descriptor to engage modules or add specific transports. So I think the best option whould be to do this in a single place. WDYT? +1. We can retractor the code that does this checks and call them during the addition of a service (axisConfiguration.addService) instead of serviceBuilder. That keeps things clean and removes the burden off the deployers (which I feel is the correct thing to do). Thanks, Keith. Thanks Sameera On Wed, Mar 11, 2009 at 8:59 AM, Sameera Jayasoma sameera.madus...@gmail.com wrote: Hi devs, Current behavior of Axis2 does not allows a faulty service to become a normal service. If a service becomes faulty, it remains there forever. There is no way for a faulty service become a normal service, even after its dependencies are available. Axis2 service becomes faulty if, the referenced Axis2 module is not available, the referenced transport is not available, there are classloading issues, the services descriptor file has errors in it, etc.. For an example, Service X is added as a faulty service because the referenced module M has not been deployed at that time. But after the module M is deployed, service X cannot be considered as faulty anymore. Hence the service X should be deployed as a normal service. This kind of scenarios can occur when we run Axis2 in an OSGi environment. Services and modules can come as an OSGi bundles and one can't really predict the order of these bundles. I would like to improve the faulty services handling aspect in Axis2 to cope with these situations. Thanks Sameera -- Sameera Jayasoma Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://tech.jayasoma.org -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [Axis2] 1.4 branch broken?
Hi Dennis, You should go into the tools folder and build the axis2-aar-maven-plugin and the axais-mar-maven-plugin first. Then build axis2 from the root level. Thanks, Keith. On Fri, Mar 6, 2009 at 12:57 PM, Dennis Sosnoski d...@sosnoski.com wrote: Ok, so that's not the cause of the problem. I guess the real issue is just that there's no longer a 1.4-SNAPSHOT repository available. So anyone have any ideas on how I can get the code to build? - Dennis keith chapman wrote: Dennis, Isn't that the correct behaviour? The tag should be versioned 1.4.1 while the branch stays on 1.4-SNAPSHOT. Thanks, Keith, On Fri, Mar 6, 2009 at 12:33 PM, Dennis Sosnoski d...@sosnoski.commailto: d...@sosnoski.com wrote: I did a fresh checkout of the Java 1.4 branch from svn in order to retrofit some code. When I try running mvn install, I get: Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/axis2/axis2-mar-maven-plugin/1.4-SNAPSHOT/axis2-mar-maven-plugin-1.4-SNAPSHOT.jar Downloading: http://ws.zones.apache.org/repository2/org/apache/axis2/axis2-mar-maven-plugin/1.4-SNAPSHOT/axis2-mar-maven-plugin-1.4-SNAPSHOT.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Anyone have an idea of what's wrong? Is it just that the change from 1.4-SNAPSHOT to 1.4.1 was never checked in? Thanks, - Dennis --Dennis M. Sosnoski SOA and Web Services in Java Training and Consulting http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117 -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [Axis2] 1.4 branch broken?
Dennis, Isn't that the correct behaviour? The tag should be versioned 1.4.1 while the branch stays on 1.4-SNAPSHOT. Thanks, Keith, On Fri, Mar 6, 2009 at 12:33 PM, Dennis Sosnoski d...@sosnoski.com wrote: I did a fresh checkout of the Java 1.4 branch from svn in order to retrofit some code. When I try running mvn install, I get: Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/axis2/axis2-mar-maven-plugin/1.4-SNAPSHOT/axis2-mar-maven-plugin-1.4-SNAPSHOT.jar Downloading: http://ws.zones.apache.org/repository2/org/apache/axis2/axis2-mar-maven-plugin/1.4-SNAPSHOT/axis2-mar-maven-plugin-1.4-SNAPSHOT.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Anyone have an idea of what's wrong? Is it just that the change from 1.4-SNAPSHOT to 1.4.1 was never checked in? Thanks, - Dennis -- Dennis M. Sosnoski SOA and Web Services in Java Training and Consulting http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117 -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: What's the fastest way to compile a just-compiled axis2 war?
Well you could just compile the axis2-kernel and replace the jar in the war. That would be the fastest way to do it. Thanks, Keith. On Wed, Feb 11, 2009 at 2:10 PM, Simon Massey si...@60hertz.com wrote: If you use -o then maven will work in offline mode which shaves off a little bit of time. rgds Simon José Ricardo da Silva wrote: Hi, I'm new to axis2 development. I'd like to know if there's a mvn directive which I can use to compile the axis2 war faster. By now I'm using the following command: mvn -Drelease -Dtest=false install But it keeps compiling a huge amount of things. I usually modify only a couple of lines in the axis-kernel module. Isn't there a way to reuse what a I have previously compiled? Thank you very much, José Ricardo. -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: Can anyone point me a simple way to share data between handlers in different flows?
This is what the Axis2 Context hierarchy is for. Store the information you want in the operation Context, so this information is available for you for the whole invocation. Both the inMessageContext and the outMessageContext share the same operation context. Thanks, Keith. On Thu, Feb 12, 2009 at 12:29 AM, José Ricardo da Silva dasilva.jo...@gmail.com wrote: Hi, I've searched on the list archive and found only quite old conversations about sharing data between handlers. I was wondering if someone could point me a very simple way to store data (objects) when a message arrives (InFlow) and possibly read it when a message is sent (OutFlow) or when an AxisFault arrives. Thanks in advance, José Ricardo. -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: The endpoint reference (EPR) for the Operation not found error in weblogic9.2
Hi, Sorry for the late reply, Please have a look at [1]. This explains the reason you get this error. Thanks, Keith. [1] http://www.keith-chapman.org/2009/02/axis2-endpoint-reference-epr-for.html On Tue, Feb 3, 2009 at 11:10 AM, jijisv jij...@gmail.com wrote: I have bundled a Axis2 webservice in an EAR deployed in weblogic9.2. When i call this webservice from my local enviroment using a Test class it works fine. But when i try calling it from another deployed EAR, I get this error. Service invocation failed - com.sampler.framework.webservices.invocation.InvocationException: Webservice Invocation exception, Message: javax.xml.ws.soap.SOAPFaultException: The endpoint reference (EPR) for the Operation not found is http://10.98.149.3:13003/Learning/services/TestService and the WSA Action = at orchestration.handler.OrchestrationEventHandler.execute(OrchestrationEventHandler.java:58) at common.handler.GOLFEventHandler.doBusiness(GOLFEventHandler.java:31) at com.sampler.framework.handler.EventHandler.process(EventHandler.java:77) at com.sampler.framework.ejb.EventListenerBean.onMessage(EventListenerBean.java:147) at common.ejb.GOLFEventListenerBean.onMessage(GOLFEventListenerBean.java:35) at weblogic.ejb.container.internal.MDListener.execute(MDListener.java:429) at weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:335) at weblogic.ejb.container.internal.JMSMessagePoller.processOneMessage(JMSMessagePoller.java:320) at weblogic.ejb.container.internal.JMSMessagePoller.pollForAWhile(JMSMessagePoller.java:477) at weblogic.ejb.container.internal.JMSMessagePoller.pollForChild(JMSMessagePoller.java:512) at weblogic.ejb.container.internal.JMSMessagePoller.run(JMSMessagePoller.java:530) at weblogic.work.ServerWorkManagerImpl$WorkAdapterImpl.run(ServerWorkManagerImpl.java:518) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209) at weblogic.work.ExecuteThread.run(ExecuteThread.java:181) Caused by: com.sampler.framework.orchestration.OrchestrationException: Service invocation failed - com.sampler.framework.webservices.invocation.InvocationException: Webservice Invocation exception, Message: javax.xml.ws.soap.SOAPFaultException: The endpoint reference (EPR) for the Operation not found is http://10.98.149.3:13003/Learning/services/TestService and the WSA Action = at com.sampler.framework.orchestration.actions.PipelineAction.createException(PipelineAction.java:150) at com.sampler.framework.orchestration.actions.InvokeAction.execute(InvokeAction.java:51) at com.sampler.framework.orchestration.OrchestrationController.orchestrate(OrchestrationController.java:73) at orchestration.handler.OrchestrationEventHandler.execute(OrchestrationEventHandler.java:50) ... 13 more Caused by: com.sampler.framework.webservices.invocation.InvocationException: Webservice Invocation exception, Message: javax.xml.ws.soap.SOAPFaultException: The endpoint reference (EPR) for the Operation not found is http://10.98.149.3:13003/Learning/services/TestService and the WSA Action = at com.sampler.framework.webservices.invocation.ServiceInvokerUtil.invoke(ServiceInvokerUtil.java:99) at com.sampler.framework.webservices.invocation.ServiceInvokerUtil.invoke(ServiceInvokerUtil.java:120) at com.sampler.framework.orchestration.actions.InvokeAction.execute(InvokeAction.java:45) ... 15 more Caused by: javax.xml.ws.soap.SOAPFaultException: The endpoint reference (EPR) for the Operation not found is http://10.98.149.3:13003/Learning/services/TestService and the WSA Action = at org.apache.axis2.jaxws.marshaller.impl.alt.MethodMarshallerUtils.createSystemException(MethodMarshallerUtils.java:1249) at org.apache.axis2.jaxws.client.dispatch.BaseDispatch.getFaultResponse(BaseDispatch.java:437) at org.apache.axis2.jaxws.client.dispatch.BaseDispatch.invoke(BaseDispatch.java:167) at com.sampler.framework.webservices.invocation.ServiceInvokerUtil.invoke(ServiceInvokerUtil.java:94) I have checked the request message tested it using SoapUI, it works fine there also. Can somebody help me in identifying the reason for thie error? Thanks. -- View this message in context: http://www.nabble.com/The-endpoint-reference-%28EPR%29-for-the-Operation-not-found-error-in-weblogic9.2-tp21804241p21804241.html Sent from the Axis - Dev mailing list archive at Nabble.com. -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: Issue with mcastBindAddress Clustering Parameter
Hi Hiranya, Hope this article [1] helps. Thanks, Keith. [1] http://wso2.org/library/articles/wso2-carbon-cluster-configuration-language#mcastBindAddress On Sun, Jan 11, 2009 at 12:17 PM, Hiranya Jayathilaka hiranya...@gmail.comwrote: Hi Folks, Currently we define a parameter named mcastBindAddress in the Axis2 clustering configuration. However this parameter name is defined in the TribesConstants class as multicastBindAddress. Is this a bug? This parameter is used in some of the clustering related samples of Apache Synapse as well. However they all seem to work fine. In that case what is the significance of defining this parameter? Any insight into the problem would be much appreciated. Thanks, Hiranya -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [Axis2] Build Failures in the trunk
I reverted my initial commit that caused the build break this afternoon. The build ran without fail after that. Thanks, Keith. On Sun, Dec 14, 2008 at 6:24 PM, Andreas Veithen andreas.veit...@gmail.comwrote: I see a different build failure which is caused by DispatchXMessageSourceTests (jaxws-integration). The failing test case was introduced recently (r722635) by Jarek. When I revert this change locally, jaxws-integration builds fine again. I also noticed that the following artifact is not (or no longer) available from the repositories used in the Maven build: com.intellij:openapi:jar:5.0. This causes a build failure in axis2-idea-plugin. Andreas On Fri, Dec 12, 2008 at 19:17, Deepal jayasinghe deep...@gmail.com wrote: Are org.tempuri.complex.ComplexDataTypesTest, org.tempuri.BaseDataTypesTest. and org.apache.axis2.deployment.WSDL11ToAxisServiceBuilderTest failing for you? If so, that seems to be caused by r724737 and I've mentioned this to Keith a few days ago. Yes those are the test cases which are failing for me, Keith do you have any idea why that happen. Guys, please do not commit to the trunk when there is a build failures, then it become very difficult to fix the initial issue. Keith if the temporal solution to this issue is reverting your commit, please do so. Thank you! Deepal Jarek On Fri, Dec 12, 2008 at 11:36 AM, Deepal jayasinghe deep...@gmail.com wrote: Hi Devs, Seems like someone has commit changes without running the build. So whoever broke the build, please double check your changes and PLEASE try fix the build. As I can see there a number of test failures in integration module. I guess that may be due to some changes happen in XMLSchema, but I am not sure. Please run the build before you do any code commit :) Thank you! Deepal -- Thank you! http://blogs.deepal.org -- Thank you! http://blogs.deepal.org -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: Looking into open issue 3364
Or just get rid of minoccurs, cause it defaults to 1. Thanks, Keith. On Fri, Dec 12, 2008 at 7:54 PM, Deepal jayasinghe deep...@gmail.comwrote: Hi Irantha, As I mentioned in the JIRA, I did a local fix and get that working, however most of the java2wsdl and some runtime code generation tests failed. So I did not commit the changes. My changes only involve in SchemaGenerator, and it is very simple fix. Only thing is to make sure you get the test cases working. Currently for any input type it sets minoccurs to 0 , so you just need to change that to 1. Thank you! Deepal Hi Deepal, I would like to look into open issue 3364. As you have already worked on it, It would be great if you can let me know what you have already done. Thanks, Irantha -- Thank you! http://blogs.deepal.org -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [Axis2] Build Failures in the trunk
Strangely the build passes for me. Just took and update and took a build, it builds without any issues. Will try building on a remote machine. Thanks, Keith. On Fri, Dec 12, 2008 at 10:58 PM, Jarek Gawor jga...@gmail.com wrote: Are org.tempuri.complex.ComplexDataTypesTest, org.tempuri.BaseDataTypesTest. and org.apache.axis2.deployment.WSDL11ToAxisServiceBuilderTest failing for you? If so, that seems to be caused by r724737 and I've mentioned this to Keith a few days ago. Jarek On Fri, Dec 12, 2008 at 11:36 AM, Deepal jayasinghe deep...@gmail.com wrote: Hi Devs, Seems like someone has commit changes without running the build. So whoever broke the build, please double check your changes and PLEASE try fix the build. As I can see there a number of test failures in integration module. I guess that may be due to some changes happen in XMLSchema, but I am not sure. Please run the build before you do any code commit :) Thank you! Deepal -- Thank you! http://blogs.deepal.org -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [jira] Commented: (AXIS2-3870) Memory Leak using ServiceClient
Can you try this on the nightly build please. There was a memory leak that was fixed on the trunk and it was post 1.4.1. Thanks, Keith. On Sat, Dec 6, 2008 at 12:42 AM, Satyanarayana Murthy Godavarti (JIRA) [EMAIL PROTECTED] wrote: [ https://issues.apache.org/jira/browse/AXIS2-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12653895#action_12653895] Satyanarayana Murthy Godavarti commented on AXIS2-3870: --- Hi Amila, I tested my code with latest Axis2 1.4.1 version. I did not see any improvement in the memory leaks. Application is consuming huge amount of memory and getting terminated after few iterations. Can you please advise Memory Leak using ServiceClient --- Key: AXIS2-3870 URL: https://issues.apache.org/jira/browse/AXIS2-3870 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: kernel Affects Versions: 1.4 Reporter: Hans G Knudsen Fix For: 1.4.1 Attachments: ClientLeak.java Hi! I think I see a leak when using ServiceClient. In my client I intialize the ConfigurationContext once and resuse it to initialize the ServiceClient : ServiceClient sender = new ServiceClient(configContext,null); Calling 'cleanup()' on the ServiceClinet explicitly after the service call does not help.. I will supply a small testcase. /hans -- 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] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: PLEASE HELP!!! Any known issue with axis2.1.4.1/tomcat 6? Getting heap error was working fine with axis2.1.3
) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:447) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:379) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:292) at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:424) at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:343) at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:287) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:686) at java.lang.Thread.run(Unknown Source) 17-Nov-2008 17:23:34 org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 17-Nov-2008 17:23:34 org.apache.catalina.core.ApplicationDispatcher invoke SEVERE: Servlet.service() for servlet jsp threw exception java.lang.OutOfMemoryError: Java heap space 17-Nov-2008 17:23:34 org.apache.catalina.core.ApplicationDispatcher invoke -- View this message in context: http://www.nabble.com/PLEASE-HELP%21%21%21-Any-known-issue-with-axis2.1.4.1-tomcat-6--Getting-heap-error-was-working-fine-with-axis2.1.3-tp20729407p20729407.html Sent from the Axis - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org -- View this message in context: http://www.nabble.com/PLEASE-HELP%21%21%21-Any-known-issue-with-axis2.1.4.1-tomcat-6--Getting-heap-error-was-working-fine-with-axis2.1.3-tp20729407p20733541.html Sent from the Axis - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: PLEASE HELP!!! Any known issue with axis2.1.4.1/tomcat 6? Getting heap error was working fine with axis2.1.3
) at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:287) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:686) at java.lang.Thread.run(Unknown Source) 17-Nov-2008 17:23:34 org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 17-Nov-2008 17:23:34 org.apache.catalina.core.ApplicationDispatcher invoke SEVERE: Servlet.service() for servlet jsp threw exception java.lang.OutOfMemoryError: Java heap space 17-Nov-2008 17:23:34 org.apache.catalina.core.ApplicationDispatcher invoke -- View this message in context: http://www.nabble.com/PLEASE-HELP%21%21%21-Any-known-issue-with-axis2.1.4.1-tomcat-6--Getting-heap-error-was-working-fine-with-axis2.1.3-tp20729407p20729407.html Sent from the Axis - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: supporting multiple message receivers for a given operation
Let me clarify the need for multiple MR's. If we think of codegen, as of now Axis2 generates the serverside code based on the portType of a WSDL (It does not take the binding into consideration). Imaging a user has a WSDL such that the response SOAP message should have a custom SOAP header when the request is SOAP 1.1 or 1.2 and a custom http header when the request is REST. Now axis2 codegen cannot handle the above scenario. Now the only way to do this as of now is to write a module and then do the checks within that module and add these headers, but these are really binding details of a service and the AxisBinding hierarchy contains these details and it should have been the responsibility of the MessageReceiver to do this. That means we have a MR per binding or a single MR with a lot of if conditions (I prefer having a MR per binding). This is where the need for multiple MR's come in. Glen/Deepal I agree that taking parts off the path/query/body and binding the SOAP infoset is part of the builder but imaging this situation. Think of having JAX-RS support in Axis2. JAX-RS allows users to annotate a parameter saying that its a http header. Now the cleanest way to handle this is to have multiple MR's, where the MR is fully aware of how to get this parameter that the service needs. This cannot be done at the builder level cause the builders work according to the schema of an incoming message (the fact that this parameter is an http header is not described in schema, but it is available in the axisBinding hierarchy). Do you see its need now? Thanks, Keith. On Thu, Oct 30, 2008 at 12:26 AM, Glen Daniels [EMAIL PROTECTED]wrote: The job of the MessageReceiver is to take a normalized message (i.e. something that looks like SOAP) and do some valid work with it - so this might mean mapping to a Java method and databinding, or calling out to a piece of hardware, or handing the contents of the body to a cached instance of a particular class. It's the job of the earlier parts of the system - the transport code, the Builder, etc - to map the real wire message to the normalized form. If we're using the MessageReceiver to do things like pull data from query parameters, then I put forth that we've designed that system incorrectly, and should fix it. Some earlier chunk of code should do this. Thanks, --Glen Sanjiva Weerawarana wrote: Deepal, the REST deserialization requires one to know the binding to know where to pull stuff from (query params, payload etc.). See WSDL 2.0 HTTP binding to understand how that works. So that has to happen post-dispatch. Sanjiva. Deepal jayasinghe wrote: It is possible that a single POJO (for example) can offer both a RESTful interface and a normal SOAP interface. In fact, that can happen by having both JAX-RS and JAX-WS annotations on the same pojo. Well even without having those annotation we can expose a POJO as a SOAP and REST. I mean REST and SOAP just the wire format , internally what happen is everything get converted into SOAP and at the end POJO class receive a SOAP message. We currently can't handle that because the message receiver is associated with the AxisOperation and not BindingOperation. IMO that was a mistake .. Well no , because BindingOperation introduced after the AxisOperation :) . So what we talked about was to introduce the ability to set the MR on the binding operation but to keep the ability to set it on the operation itself. That allows us to be totally backwards compatible but it solve the problem for wanting both a RESTful and a WS-* binding for the same operation for example. I can not still understand why we need new MR , because at the core what we use is SOAP not anything else , and at the end I mean at the Transport sender level we serialize that to REST or SOAP. Which is done by Message formatters. -Deepal Thoughts? Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: supporting multiple message receivers for a given operation
Hi Dims, I had a look at JAX-RS and thought of starting on it. Thats where this discussion popped up. I was thinking of sending a mail on this to the dev list (regarding support for JAX-RS). Currently in order to write a RESTfull Service in Axis2 you have to deploy your service using WSDL 2.0 [1] but if we have JAX-RS support that will make life easy for users. Thanks, Keith. [1] http://wso2.org/library/3726 On Thu, Oct 30, 2008 at 7:45 AM, Davanum Srinivas [EMAIL PROTECTED] wrote: Keith, Can it wait till we actually decide to do JAX-RS? Why do we need it now in other words, is there an effort to enhance WSDL2Java more to handle these situations? thanks, dims On Wed, Oct 29, 2008 at 10:07 PM, keith chapman [EMAIL PROTECTED] wrote: Let me clarify the need for multiple MR's. If we think of codegen, as of now Axis2 generates the serverside code based on the portType of a WSDL (It does not take the binding into consideration). Imaging a user has a WSDL such that the response SOAP message should have a custom SOAP header when the request is SOAP 1.1 or 1.2 and a custom http header when the request is REST. Now axis2 codegen cannot handle the above scenario. Now the only way to do this as of now is to write a module and then do the checks within that module and add these headers, but these are really binding details of a service and the AxisBinding hierarchy contains these details and it should have been the responsibility of the MessageReceiver to do this. That means we have a MR per binding or a single MR with a lot of if conditions (I prefer having a MR per binding). This is where the need for multiple MR's come in. Glen/Deepal I agree that taking parts off the path/query/body and binding the SOAP infoset is part of the builder but imaging this situation. Think of having JAX-RS support in Axis2. JAX-RS allows users to annotate a parameter saying that its a http header. Now the cleanest way to handle this is to have multiple MR's, where the MR is fully aware of how to get this parameter that the service needs. This cannot be done at the builder level cause the builders work according to the schema of an incoming message (the fact that this parameter is an http header is not described in schema, but it is available in the axisBinding hierarchy). Do you see its need now? Thanks, Keith. On Thu, Oct 30, 2008 at 12:26 AM, Glen Daniels [EMAIL PROTECTED] wrote: The job of the MessageReceiver is to take a normalized message (i.e. something that looks like SOAP) and do some valid work with it - so this might mean mapping to a Java method and databinding, or calling out to a piece of hardware, or handing the contents of the body to a cached instance of a particular class. It's the job of the earlier parts of the system - the transport code, the Builder, etc - to map the real wire message to the normalized form. If we're using the MessageReceiver to do things like pull data from query parameters, then I put forth that we've designed that system incorrectly, and should fix it. Some earlier chunk of code should do this. Thanks, --Glen Sanjiva Weerawarana wrote: Deepal, the REST deserialization requires one to know the binding to know where to pull stuff from (query params, payload etc.). See WSDL 2.0 HTTP binding to understand how that works. So that has to happen post-dispatch. Sanjiva. Deepal jayasinghe wrote: It is possible that a single POJO (for example) can offer both a RESTful interface and a normal SOAP interface. In fact, that can happen by having both JAX-RS and JAX-WS annotations on the same pojo. Well even without having those annotation we can expose a POJO as a SOAP and REST. I mean REST and SOAP just the wire format , internally what happen is everything get converted into SOAP and at the end POJO class receive a SOAP message. We currently can't handle that because the message receiver is associated with the AxisOperation and not BindingOperation. IMO that was a mistake .. Well no , because BindingOperation introduced after the AxisOperation :) . So what we talked about was to introduce the ability to set the MR on the binding operation but to keep the ability to set it on the operation itself. That allows us to be totally backwards compatible but it solve the problem for wanting both a RESTful and a WS-* binding for the same operation for example. I can not still understand why we need new MR , because at the core what we use is SOAP not anything else , and at the end I mean at the Transport sender level we serialize that to REST or SOAP. Which is done by Message formatters. -Deepal Thoughts? Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: supporting multiple message receivers for a given operation
Deepal see my comments inline... On Thu, Oct 30, 2008 at 7:57 AM, Deepal jayasinghe [EMAIL PROTECTED]wrote: keith chapman wrote: Let me clarify the need for multiple MR's. If we think of codegen, as of now Axis2 generates the serverside code based on the portType of a WSDL (It does not take the binding into consideration). Well that is the idea , binding is for the client side not for the server side, at the server side what we need to care is the porttype. This was the initial design and it had to be that because Axis2 did not have the concept of a binding hierarchy, but now it does have that concept so why not use it? I think your missing my point. Yes a service is binding independent (It should not care whether a parameter was present in the url, soap body, http header or even a JMS header) but the MR should be binding dependent. The MR is the guy who should know where to pluck the parameter off in order to inject it into the service. Imaging a user has a WSDL such that the response SOAP message should have a custom SOAP header when the request is SOAP 1.1 or 1.2 and a custom http header when the request is REST. Well , you should not forget that Axis2 is transport independent , meaning at the service level it does not have any idea how the request came and how the response should be serialized. I already answered this above. The service will always be transport independent and it should. And Axis2 is a SOAP engine and we have support for REST . We do not need to make it a REST engine. :) , so REST related serialization should be at the transport level , you may have all the necessary data in the MC. Now axis2 codegen cannot handle the above scenario. Well it can handle SOAP scenario :) Not unless the user writes a module. If we had the concept of multiple MR's codegen could have handled this easily which means we take the burden off users. Codegen can handle this on the client side very nicely cause it is aware of bindings. For e.g If the WSDL said that a particular operation needs a http header named foo the operation in the stub would have foo as a parameter. The fact that it is not a part of the payload and is an http header is hidden in the implementation details of the stub. This is what I'm proposing that we do for the service too. Now the only way to do this as of now is to write a module and then do the checks within that module and add these headers, but these are really binding details of a service and the AxisBinding This is exactly the right way to do , I mean REST is an extension in Axis2 , so the idea or module is to handle extensions. hierarchy contains these details and it should have been the responsibility of the MessageReceiver to do this. That means we have a MR per binding or a single MR with a lot of if conditions (I prefer having a MR per binding). hmm , what happen if we start to generate JMS binding , then do we need to have some other MR for that ? Well I didn't intend to say that YOU MUST ALWAYS HAVE A MR PER BINDING what I mean is you SHOULD be able to. And the default case should work as it is. I think answer is no . And before calling the AxisEngine everything has to be converted into a SOAP message. This is where the need for multiple MR's come in. Glen/Deepal I agree that taking parts off the path/query/body and binding the SOAP infoset is part of the builder but imaging this situation. Think of having JAX-RS support in Axis2. Well we do not need to talk about that since we do not have support for JAX-RS. See my reply below. We do need to talk about this cause this is the start of the discussion as to how we could bring JAX-RS support into Axis2. Thanks, Keith. Thank you! Deepal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: Axis2 Webservice wsdl version
Have you set the *useOriginalwsdl *parameter in your services.xml to true? Also does your service archive file contain a wsdl in its META-INF folder? Thanks, Keith. On Wed, Oct 22, 2008 at 11:49 PM, Rajesh, Peter (CLAIMS, WIP) [EMAIL PROTECTED] wrote: Hi, After deployed the Axis2 webservice (.aar file) in Weblogic, clicked the wsdl url for example, * http://localhost:7001/axis2/services/ABCProcessingService?wsdl*http://localhost:7001/axis2/services/ABCProcessingService?wsdland got the below error **error* * **description*Unable to generate WSDL 1.1 for this service/*description * * **reason*If you wish Axis2 to automatically generate the WSDL 1.1, then please +set useOriginalwsdl as false in your services.xml/*reason* * */*error** But if I mention the wsdl version as wsdl2.0 as below, I can see the wsdl displayed. *http://localhost:7001/axis2/services/ABCProcessingService?wsdl=wsdl2.0*http://localhost:7001/axis2/services/ABCProcessingService?wsdl=wsdl2.0 *Please let me know what I need to do to display the wsdl without mentioning the version wsdl2.0* Thanks Regards, Peter Rajesh * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: Fw: [Axis2] [1.4] Zero Blockers / RC4 this weekend / Plan for 1.4 Final
Yes this is a serious issue. Shall we mark this as a blocker for 1.5? Thanks, Keith. On Tue, Oct 21, 2008 at 10:29 AM, Chris Hyzer [EMAIL PROTECTED] wrote: I have the latest 1.4.1, and I was really hoping this issue would be fixed by now (we were discussing it 6 months ago), but it does not appear to be fixed... will it ever be fixed? I still think it is a serious issue. https://issues.apache.org/jira/browse/AXIS2-3364 Thanks! Chris --- On *Wed, 4/2/08, Chris Hyzer [EMAIL PROTECTED]* wrote: From: Chris Hyzer [EMAIL PROTECTED] Subject: Fw: [Axis2] [1.4] Zero Blockers / RC4 this weekend / Plan for 1.4 Final To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Date: Wednesday, April 2, 2008, 12:47 PM Thanks! Well, I would try to get this into the final 1.4, but it is up to you. I think it is a *major* deficiency in Axis... but a patch would be very useful for me. I have heard a lot of complaints about this, but maybe not enough vocal people who complain to the list. :) Thanks much for your attention. Chris - Forwarded Message From: Deepal jayasinghe [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, April 2, 2008 7:26:25 AM Subject: Re: [Axis2] [1.4] Zero Blockers / RC4 this weekend / Plan for 1.4 Final Chris, If you can get Amila or Deepal's attention...it's possible to get it into 1.4. I looked into , but the problem is we can not fix that in a day. That is why I did not comment on that. Any way I will try to fix that and send a patch or commit to trunk Thank you! Deepal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You rock. That's why Blockbuster's offering you one month of Blockbuster Total Accesshttp://us.rd.yahoo.com/evt=47523/*http://tc.deals.yahoo.com/tc/blockbuster/text5.com, No Cost. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [axis2] Axis2 1.5
How about a Hackathon at ApacheCon to get some critical issues fixed? ApacheCon dates fit your time line perfectly... Thanks, Keith. On Fri, Oct 17, 2008 at 7:42 PM, Glen Daniels [EMAIL PROTECTED] wrote: Team: What do people think about gearing up for a 1.5 release in the not-too-distant future? I figure the earlier we start talking about this the better chance we have of actually getting something out before too long. :) We've had some great fixes on the trunk, the new transport stuff, etc., and I'd like to see 1.5 go out soon in order to get our first Java 1.5 release out there, and start getting into a habit of releasing a bit more early and often. This would also let dependent projects like Synapse have a solid release which works with the new trunk. As a strawman, here's a schedule: * Now - cruise through JIRA and pick the serious blockers. * Now - 11/7 - fix critical issues, review code, docs, etc * 11/7 - cut branch, relase 1.5beta * Handle beta issues * 11/14 - release 1.5RC * Handle RC issues * 11/21 - release 1.5 What do you think, folks? Thanks, --Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: why is axis2 checkout missing some code from source bundle?
As per a discussion we had on the mailing list the transports now reside on a seperate commons project [1]. Even the http transport related stuff can be found there. Thanks, Keith. [1] https://svn.apache.org/repos/asf/webservices/commons/trunk/modules/transport On Fri, Oct 17, 2008 at 1:52 AM, emiddio-verizon [EMAIL PROTECTED]wrote: for example modules/kernel/src/org/apache/axis2/transport/http/AxisServlet.java is not in the checkout system; only the src bundle. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [Axis2] Moving all the transports into a common modules
I don't see any issue with backward compatibility. This chage is something in the axis2.xml, this will not break any code that users have with them. If it was a API call then I can understand. Also this change would not effect generated code (AFAIK). Thanks, Keith. On Thu, Oct 2, 2008 at 9:54 PM, Ruwan Linton [EMAIL PROTECTED] wrote: Hi Deepal, Synapse also has the same backward compatibility issue that you are talking about with the axis2.xml that synapse ships with, therefore shall we keep the transports that synapse community contributed as it is (org.apache.synapse.transports) ;-) Thanks, Ruwan On Thu, Oct 2, 2008 at 9:01 PM, Deepal jayasinghe [EMAIL PROTECTED]wrote: hi, the package name that commons transport module use is org.apache.axis2 I think it should be org.apache.ws.commons Saying no one more time :) I do not think that all the modules in commons should have the package name org.apache.ws.commons , as an example have a look at Axiom and Neethi org.apache.neethi org.apache.axiom So IMO it is ok to have axis2 transport package name as it is :) -Deepal WDYT? thanks, Amila. On Mon, Sep 22, 2008 at 12:03 PM, Amila Suriarachchi [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Sun, Sep 21, 2008 at 2:59 PM, Andreas Veithen [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Deepal, Before we can move anything from Synapse to the new commons module, we need to decide which transports we move (all or only a subset) and based on that, we need to make sure that all the people involved in the maintenance of these transports have commit access to the new module. As a starting point I'll put the synapse SMTP transport to commons transport and try to test with Axis2. thanks, Amila. In the meantime, I also have two comments/questions related to the code that is already in the new module: 1. Wouldn't it be a good idea to take advantage of the move from Axis2 to ws-commons to use a more conventional directory structure, e.g. src/main/java instead of src? 2. I don't see any documentation in the new module. There must have been some docs for the transports in Axis2. When will this be moved? Regards, Andreas On 21 sept. 08, at 03:13, Deepal jayasinghe wrote: Hi all, Few months back we all agreed to move all commons transports (from Axis2 and Synapse) to a common module. As the first step of that I have moved all the Axis2 to transport into a common module in ws-commons [1]. In addition to that we have setup nightly builds from that modules. So now its time for Synapse dev to move their transports into that module :) [1] : https://svn.apache.org/repos/asf/webservices/commons/trunk/modules/transport Thank you! Deepal -- Thank you! http://blogs.deepal.org - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/ -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/ -- Thank you! http://blogs.deepal.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ruwan Linton http://wso2.org - Oxygenating the Web Services Platform http://ruwansblog.blogspot.com/ -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [Axis2] Moving all the transports into a common modules
On Thu, Oct 2, 2008 at 9:54 PM, Ruwan Linton [EMAIL PROTECTED] wrote: Hi Deepal, Synapse also has the same backward compatibility issue that you are talking about with the axis2.xml that synapse ships with, therefore shall we keep the transports that synapse community contributed as it is (org.apache.synapse.transports) ;-) Another good reason to have a common package name. ;). Thanks, Keith. Thanks, Ruwan On Thu, Oct 2, 2008 at 9:01 PM, Deepal jayasinghe [EMAIL PROTECTED]wrote: hi, the package name that commons transport module use is org.apache.axis2 I think it should be org.apache.ws.commons Saying no one more time :) I do not think that all the modules in commons should have the package name org.apache.ws.commons , as an example have a look at Axiom and Neethi org.apache.neethi org.apache.axiom So IMO it is ok to have axis2 transport package name as it is :) -Deepal WDYT? thanks, Amila. On Mon, Sep 22, 2008 at 12:03 PM, Amila Suriarachchi [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Sun, Sep 21, 2008 at 2:59 PM, Andreas Veithen [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Deepal, Before we can move anything from Synapse to the new commons module, we need to decide which transports we move (all or only a subset) and based on that, we need to make sure that all the people involved in the maintenance of these transports have commit access to the new module. As a starting point I'll put the synapse SMTP transport to commons transport and try to test with Axis2. thanks, Amila. In the meantime, I also have two comments/questions related to the code that is already in the new module: 1. Wouldn't it be a good idea to take advantage of the move from Axis2 to ws-commons to use a more conventional directory structure, e.g. src/main/java instead of src? 2. I don't see any documentation in the new module. There must have been some docs for the transports in Axis2. When will this be moved? Regards, Andreas On 21 sept. 08, at 03:13, Deepal jayasinghe wrote: Hi all, Few months back we all agreed to move all commons transports (from Axis2 and Synapse) to a common module. As the first step of that I have moved all the Axis2 to transport into a common module in ws-commons [1]. In addition to that we have setup nightly builds from that modules. So now its time for Synapse dev to move their transports into that module :) [1] : https://svn.apache.org/repos/asf/webservices/commons/trunk/modules/transport Thank you! Deepal -- Thank you! http://blogs.deepal.org - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/ -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/ -- Thank you! http://blogs.deepal.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ruwan Linton http://wso2.org - Oxygenating the Web Services Platform http://ruwansblog.blogspot.com/ -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: large streams with mtom (130 MB) out of memory
Did you turn on attachment caching using the following parameter? parameter name=cacheAttachmentstrue/parameter Thanks, Keith. On Wed, Oct 1, 2008 at 7:48 PM, Wagner, Michael [EMAIL PROTECTED] wrote: Hello, i try to send and receive files with 130MB capacity. The VMs have 512MB of memory. To do so I extended the MTOM example provided by axis2 (sending the file back and write it to a file). It is possible for me to send the file to the server with an adequate amount of memory consumption. However, sending the content from the stream back to the client fails (out of memory). Can somebody tell me what I am doing wrong (I also changed the axis2.xml and service.xml according to the axis2 MTOM description in the web) or extend the MTOM example of axis2? Thanks, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: Client times out before getting back the response
) * *at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Unknown Source)* *at javax.xml.parsers.DocumentBuilder.parse(Unknown Source)* *at com.qualcomm.mediaflo.mdrcommon.utils.XPathEvaluationHelper.init(XPathEvaluationHelper.java:116) * *... 4 more* * * * * Thanks a lot, Nithya -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: Client times out before getting back the response
If you are using service client API then you could try the following, I have
written this client for the version service running on mooshup.com which is
a running instance of the WSO2 Mashup Server [1]
public static void main(String[] args)
throws RemoteException, StudentNotFoundExceptionException1,
InterruptedException {
ServiceClient client = new ServiceClient();
Options options = new Options();
options.setTo(new EndpointReference(
https://mooshup.com/services/system/version;));
options.setAction(
http://services.mashup.wso2.org/version/ServiceInterface/getVersionRequest
);
client.setOptions(options);
client.sendReceiveNonBlocking(null, new MyCallbackHandler());
Thread.sleep(1);
}
static class MyCallbackHandler implements AxisCallback {
public void onMessage(MessageContext messageContext) {
System.out.println(On Message);
System.out.println(messageContext.getEnvelope().getBody().toString());
}
public void onFault(MessageContext messageContext) {
System.out.println(On Fault);
}
public void onError(Exception e) {
System.out.println(On Error);
}
public void onComplete() {
System.out.println(On Message);
}
}
Thanks,
Keith.
[1] http://wso2.org/projects/mashup
On Mon, Sep 29, 2008 at 11:34 PM, Thiruvottiyur Subram, Nithya
[EMAIL PROTECTED] wrote:
Hello,
Thanks for your response. I am new to the whole web service concept, Could
you please help me on how I can make it asynchronous?
Thanks,
Nithya
--
*From:* keith chapman [mailto:[EMAIL PROTECTED]
*Sent:* Monday, September 29, 2008 11:02 AM
*To:* axis-dev@ws.apache.org
*Subject:* Re: Client times out before getting back the response
Did you try calling the service in a async manner? If the server takes
15-10 mins to respond you might be better off doing this.
Thanks,
Keith.
On Mon, Sep 29, 2008 at 11:18 PM, Thiruvottiyur Subram, Nithya
[EMAIL PROTECTED] wrote:
Hello,
We are having problems with our Client when the Server (running as a Web
Service) takes a long time to process the request.
The Client just times out after about 2 minutes in such cases. I tried
setting the options for axis client in many ways:
*options.setProperty(HTTPConstants.SO_TIMEOUT, new Integer(180));
options.setProperty(HTTPConstants.CONNECTION_TIMEOUT, new
Integer(180));*
*options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CONNECTION_TIMEOUT
, new Integer(720));*
*Options.setTimeOutInMillis(1);*
* *
I modified axis2.xml too for timeout in case the server was the one
initiating the closure.
Nothing seems to work..
Below is the error message on the client side. On the server side, there
are no errors and we can see some processing going on (which will take
about 15-20 mins)…
*Sep 23, 2008 1:34:45 PM org.apache.axis2.transport.http.HTTPSender
sendViaPost*
*INFO: Unable to sendViaPost to url[**
http://localhost:8084/WebServerTest/services/MediaFLOMDRQueryService*http://localhost:8084/WebServerTest/services/MediaFLOMDRQueryService
*]*
*java.net.SocketTimeoutException: Read timed out*
*at java.net.SocketInputStream.socketRead0(Native Method)*
*at java.net.SocketInputStream.read(Unknown Source)*
*at java.io.BufferedInputStream.fill(Unknown Source)*
*at java.io.BufferedInputStream.read(Unknown Source)*
*at
org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:77)*
*at
org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:105)*
*at
org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1115)
*
*at
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.readLine(MultiThreadedHttpConnectionManager.java:1373)
*
*at
org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1832)
*
*at
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1590)
*
*at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:995)
*
*at
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:397)
*
*at
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170)
*
*at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
*
*at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346)
*
*at
org.apache.axis2.transport.http.AbstractHTTPSender.executeMethod(AbstractHTTPSender.java:520)
*
*at
org.apache.axis2.transport.http.HTTPSender.sendViaPost
Re: Content Negotiation (Was Re: [AXIS2] Should JSON messages be considered as REST?)
Hi Chinthaka, I did implement content-negotiation in Axis2 some time ago [1]. It was implemented using the Accept header. It can be enabled by adding the following parameter to the axis2.xml parameter name=httpContentNegotiationtrue/parameter Thanks, Keith. [1] http://markmail.org/message/mbnxc2ysq2bt7v6a On Mon, Sep 22, 2008 at 8:53 PM, Eran Chinthaka [EMAIL PROTECTED]wrote: Since our discussion is over on Faults and JSON messages, let's discuss one of the good points raised by Dr. Sanjiva. I think content negotiation is a cool feature to have, especially when we are using HTTP. This is one of the features I personally definitely like to have. Are you guys thinking of using cont-neg on transport level, or will it be sth like we did for service group context using a SOAP header? If we check how browsers and Web servers do content negotiation, it is mainly using Accept, Accept-Encoding, Accept-Charset, etc., header. I think this can be easily done within Axis2 too. But the problem with this approach is that, this cont-neg should happen for every message. If we find out a way to do this for a conversation, it'd great. Basically a client must ask from a server, the content types it can support and client can then use those types to send messages later. This also can be tricky as sometimes Web services server itself might restrict some content types only for some operations. Even if one of us won't be doing this, this is sth a new comer can easily tackle if we list this on tasks to be done list (if we have one ;) ) What do you all think? -- With Mettha, Eran Chinthaka Health is the greatest gift; contentment is the greatest wealth; trusting is the best relationship; nirvana is the highest joy. - Dhammapada -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: Content Negotiation (Was Re: [AXIS2] Should JSON messages be considered as REST?)
Hi Chinthaka, Currently it picks the first matching content-type in the accept header. If for e.g the Accept header was Accept: foo/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q= 0.8,image/png,*/*;q=0.5 then the response would be application/xml (Assuming that there was no matching builder for foo/xml, but if there was a matching builder for foo/xml the response would be foo/xml). Currently this happens on a per request basis, what do u mean by enabling it on a per conversation basis? Thanks, Keith. On Tue, Sep 23, 2008 at 1:28 AM, Eran Chinthaka [EMAIL PROTECTED]wrote: Keith, great piece of work. Is there a way to give preference to content-types too, during the negotiation? Ok let me tell one use case why I like content negotiations enabled for conversations. As we might know already, when we do performance analysis of Axis2, we send large number of messages to a server. This includes sending increasingly large (in size) messages as well. Also these metrics involve measuring the usage of network bandwidth, etc., If we can enable cont-neg at conversation level, you can see how we will win, especially when Axis2 client talks to Axis2 servers. One might think this as a hack, but obviously there should be some advantage, when Axis2 client talk to another Axis2 server/client. This will be ok, with request level cont-negotiation, but will be optimal/useful with conversation level. Thanks, Chinthaka On Mon, Sep 22, 2008 at 2:03 PM, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: Ah excellent! So does the message formatter get selected based on the accept headers sent (which refer to media types IIRC)? That's perfect. Chinthaka, the idea of bringing content negotiation into SOAP is interesting but IMO not that useful. While content neg is a favorite RESTafarian feature, the reality is that it hasn't really proved its mettle. I wanted us to do it because its a simple thing for us to do with our architecture and because for pure HTTP there are some usecases, esp. with pure HTTP scenarios where the browser is involved. I can't find the comment right now but Larry Messinter, who proposed content neg into the http spec, later regretted it. IIRC the quote and ref is in my ws-* vs. rest presentation somewhere! Sanjiva. keith chapman wrote: Hi Chinthaka, I did implement content-negotiation in Axis2 some time ago [1]. It was implemented using the Accept header. It can be enabled by adding the following parameter to the axis2.xml parameter name=httpContentNegotiationtrue/parameter Thanks, Keith. [1] http://markmail.org/message/mbnxc2ysq2bt7v6a On Mon, Sep 22, 2008 at 8:53 PM, Eran Chinthaka [EMAIL PROTECTED] wrote: Since our discussion is over on Faults and JSON messages, let's discuss one of the good points raised by Dr. Sanjiva. I think content negotiation is a cool feature to have, especially when we are using HTTP. This is one of the features I personally definitely like to have. Are you guys thinking of using cont-neg on transport level, or will it be sth like we did for service group context using a SOAP header? If we check how browsers and Web servers do content negotiation, it is mainly using Accept, Accept-Encoding, Accept-Charset, etc., header. I think this can be easily done within Axis2 too. But the problem with this approach is that, this cont-neg should happen for every message. If we find out a way to do this for a conversation, it'd great. Basically a client must ask from a server, the content types it can support and client can then use those types to send messages later. This also can be tricky as sometimes Web services server itself might restrict some content types only for some operations. Even if one of us won't be doing this, this is sth a new comer can easily tackle if we list this on tasks to be done list (if we have one ;) ) What do you all think? -- With Mettha, Eran Chinthaka Health is the greatest gift; contentment is the greatest wealth; trusting is the best relationship; nirvana is the highest joy. - Dhammapada -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- With Mettha, Eran Chinthaka Health is the greatest gift
Re: [AXIS2] Should JSON messages be considered as REST?
Hi Chinthaka,
See comments inline,
On Sun, Sep 21, 2008 at 12:43 AM, Eran Chinthaka
[EMAIL PROTECTED]wrote:
Hi Keith and all,
This argument is based on the following assumption ( You know about
assumptions, if you've watched Under Siege 2 ;) )
Axis2 REST implementation is based on WSDL 2.0 HTTP Binding. At least this
was the case, when I was implementing and sorry if the implementation is now
changed.
Nothing has changed with this regard. ;).
In the spec, it says, if we have our own custom content-type, then it
should be compatible with application/xml (
http://www.w3.org/TR/wsdl20-adjuncts/#_http_ser_xml).
I don't think that thats the case. The WSDL 2.0 spec specifies three
serializations, they are
application/x-www-form-urlencodedhttp://www.w3.org/TR/wsdl20-adjuncts/#_http_x-www-form-urlencoded,
application/xmlhttp://www.w3.org/TR/wsdl20-adjuncts/#_http_operation_xml_encodingand
multipart/form-datahttp://www.w3.org/TR/wsdl20-adjuncts/#_http_operation_multipart_encoding.
And the area in the spec you have referred to is talking about these three.
I the section you have referred to the spec says,
[Definition: The *serialization format* is a media type token
(type/subtype). It identifies rules to serialize the payload in an HTTP
message. Its value is defined by the following rules. The HTTP request
serialization format MUST be in the media type range specified by the {http
input
serializationhttp://www.w3.org/TR/wsdl20-adjuncts/#property-BindingOperation.httpinputserialization}
property.
So it basically supports any media-Type. Its just that the working group
took the trouble in describing the three serializations above in detail.
Do you think application/json is compatible with application/xml?
As long as application/json is a standard I dont see any issues with it.
I don't think so because in the spec once again it says the following here
: http://www.w3.org/TR/wsdl20-adjuncts/#_http_operation_xml_encoding
The instance data http://www.w3.org/TR/wsdl20-adjuncts/#instance_dataof
the input, output or fault message is serialized as an
*XML document* in the message body of the HTTP message Since JSON
serialization is not XML, rather name/value pair, application/xml is not
compatible with application/json.
Answered that too above.
Thanks,
Keith.
So considering JSON messages as REST messages seems to be fundamentally
wrong.
But since we think (at least I think) JSON is something we should support,
we should think about supporting content-types which are not compatible with
SOAP or REST.
Thanks,
Chinthaka
On Wed, Sep 3, 2008 at 11:10 PM, keith chapman [EMAIL PROTECTED]wrote:
Hi devs,
This idea came up because of the following scenario.
Currently the logic for creating a AxisFault for a fault received lies in
org.apache.axis2.util.Utils.java (lines 507 - 530). This works perfectly
when the received fault is SOAP or REST. But it does not work as expected
when the response is JSON ( rather a exception is thrown saying The
MessageContext does not have an associated SOAPFault.). The reason is the
logic we use to build the AxisFault. If the fault message is not a SOAP
message we check for the flag messageContext.isDoingREST() and get the first
element of the SOAPBody as the fault message.
When the fault message is JSON its neither SOAP and the
messageContext.isDoingREST() returns false. Should we consider JSON
messages as REST messages? I believe so.
WDYT?
Thanks,
Keith.
--
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://www.keith-chapman.org
--
With Mettha,
Eran Chinthaka
Health is the greatest gift; contentment is the greatest wealth; trusting
is the best relationship; nirvana is the highest joy. - Dhammapada
--
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://www.keith-chapman.org
Re: [AXIS2] Should JSON messages be considered as REST?
On Sun, Sep 21, 2008 at 12:21 AM, Eran Chinthaka [EMAIL PROTECTED]wrote: Hi Keith, This solution will solve the JSON problem (if we consider JSON messages as REST, which I'll comment in a different email), but will not solve the more general question IMO. Agreed. It would be nice if we could solve the more general question too. We have enabled to plug custom content types, and do we wanna restrict these custom types to always be either REST or SOAP compatible? If yes, then we can live with it. But if not, then we need more flexibility to handle it. For example, as Keith pointed, when we get a SOAP fault, what should be do with it? With current MessageBuilders/MessageFormatters they build/format requests based on content-type. I'm not too familiar with the fault message flow in Axis2 (Will have a look on that and get back) But why arn't we allowing the corresponding builder/formatter to format faults too? If that was the case I think this problem would not occur. Looks like the fundemental problem lies in there. Then the question comes as to what really Axis2 is. If we enable plugging custom types, which are not compatible with SOAP or REST, then aren't we redefining what Axis2 is? Do we wanna make it something which can handle more than Web services It will definitely come in handy for projects such as Synapse who use Axis2. Thanks, Keith. (I consider REST within Axis2 also as Web services, as our REST implementation is based on WSDL 2.0 HTTP binding) Just thinking loud. Thanks, Chinthaka On Fri, Sep 19, 2008 at 10:04 PM, keith chapman [EMAIL PROTECTED]wrote: Let me describe the problem in more detail. As of now Axis2 enables you to plug in various message types by registering them in the axis2.xml. Some of these message types will be SOAP based (like text/xml and application/soap+xml) while others are not. And in the latter case when a exception occurs somewhere in the pipe we do not want to throw the fault as a SOAP message. What we do in the REST case of of now is that we take the fault element in the SOAP body (If not found the first child of the SOAP body) and write that out as the fault. As of now Axis2 treats a few message Types as REST specifically application/xml, multipart/form-data and application/x-www-form-urlencoded. But with the pluggable message types in place this may not work that well. Assume that someone want to to plug in application/foo and that this message type is REST how are we gonna handle it? Should we consider adding a attribute to the messageBuilders/messageFormatters section to indicate weather its REST or not? Thanks, Keith. On Sat, Sep 20, 2008 at 3:22 AM, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: +1 .. but I'm a bit confused. I assume by REST you meant that the response has media type text/xml instead of application/soap+xml, right? If we think about it that way, can we get rid of the isDoingREST flag?? (I've hated that from day 1 and haven't had a chance to really dig thru it and figure out how to get rid of. Maybe this is an opportunity to get it right ..) Sanjiva. keith chapman wrote: Any input on this would be appreciated. Thanks, Keith. On Thu, Sep 4, 2008 at 8:40 AM, keith chapman [EMAIL PROTECTED]wrote: Hi devs, This idea came up because of the following scenario. Currently the logic for creating a AxisFault for a fault received lies in org.apache.axis2.util.Utils.java (lines 507 - 530). This works perfectly when the received fault is SOAP or REST. But it does not work as expected when the response is JSON ( rather a exception is thrown saying The MessageContext does not have an associated SOAPFault.). The reason is the logic we use to build the AxisFault. If the fault message is not a SOAP message we check for the flag messageContext.isDoingREST() and get the first element of the SOAPBody as the fault message. When the fault message is JSON its neither SOAP and the messageContext.isDoingREST() returns false. Should we consider JSON messages as REST messages? I believe so. WDYT? Thanks, Keith. -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc
Re: [AXIS2] Should JSON messages be considered as REST?
I'm not too familiar with YAML. For what sort of situations is YAML used
for? is it used widely?
Thanks,
Keith.
On Sun, Sep 21, 2008 at 8:25 PM, Martin Gainty [EMAIL PROTECTED] wrote:
curious as to when/if a YAML2XML plugin will be available **?*
*thanks,*
*Martin
__
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official
business of Sender. This transmission is of a confidential nature and Sender
does not endorse distribution to any party other than intended recipient.
Sender does not necessarily endorse content contained within this
transmission.
--
Date: Sun, 21 Sep 2008 19:31:42 +0530
From: [EMAIL PROTECTED]
To: axis-dev@ws.apache.org
Subject: Re: [AXIS2] Should JSON messages be considered as REST?
Hi Chinthaka,
See comments inline,
On Sun, Sep 21, 2008 at 12:43 AM, Eran Chinthaka [EMAIL PROTECTED]
wrote:
Hi Keith and all,
This argument is based on the following assumption ( You know about
assumptions, if you've watched Under Siege 2 ;) )
Axis2 REST implementation is based on WSDL 2.0 HTTP Binding. At least this
was the case, when I was implementing and sorry if the implementation is now
changed.
Nothing has changed with this regard. ;).
In the spec, it says, if we have our own custom content-type, then it
should be compatible with application/xml (
http://www.w3.org/TR/wsdl20-adjuncts/#_http_ser_xml).
I don't think that thats the case. The WSDL 2.0 spec specifies three
serializations, they are
application/x-www-form-urlencodedhttp://www.w3.org/TR/wsdl20-adjuncts/#_http_x-www-form-urlencoded,
application/xmlhttp://www.w3.org/TR/wsdl20-adjuncts/#_http_operation_xml_encodingand
multipart/form-datahttp://www.w3.org/TR/wsdl20-adjuncts/#_http_operation_multipart_encoding.
And the area in the spec you have referred to is talking about these three.
I the section you have referred to the spec says,
[Definition: The *serialization format* is a media type token
(type/subtype). It identifies rules to serialize the payload in an HTTP
message. Its value is defined by the following rules. The HTTP request
serialization format MUST be in the media type range specified by the {http
input
serializationhttp://www.w3.org/TR/wsdl20-adjuncts/#property-BindingOperation.httpinputserialization}
property.
So it basically supports any media-Type. Its just that the working group
took the trouble in describing the three serializations above in detail.
Do you think application/json is compatible with application/xml?
As long as application/json is a standard I dont see any issues with it.
I don't think so because in the spec once again it says the following here
: http://www.w3.org/TR/wsdl20-adjuncts/#_http_operation_xml_encoding
The instance data http://www.w3.org/TR/wsdl20-adjuncts/#instance_dataof
the input, output or fault message is serialized as an
*XML document* in the message body of the HTTP message Since JSON
serialization is not XML, rather name/value pair, application/xml is not
compatible with application/json.
Answered that too above.
Thanks,
Keith.
So considering JSON messages as REST messages seems to be fundamentally
wrong.
But since we think (at least I think) JSON is something we should support,
we should think about supporting content-types which are not compatible with
SOAP or REST.
Thanks,
Chinthaka
On Wed, Sep 3, 2008 at 11:10 PM, keith chapman [EMAIL PROTECTED]wrote:
Hi devs,
This idea came up because of the following scenario.
Currently the logic for creating a AxisFault for a fault received lies in
org.apache.axis2.util.Utils.java (lines 507 - 530). This works perfectly
when the received fault is SOAP or REST. But it does not work as expected
when the response is JSON ( rather a exception is thrown saying The
MessageContext does not have an associated SOAPFault.). The reason is the
logic we use to build the AxisFault. If the fault message is not a SOAP
message we check for the flag messageContext.isDoingREST() and get the first
element of the SOAPBody as the fault message.
When the fault message is JSON its neither SOAP and the
messageContext.isDoingREST() returns false. Should we consider JSON
messages as REST messages? I believe so.
WDYT?
Thanks,
Keith.
--
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://www.keith-chapman.org
--
With Mettha,
Eran Chinthaka
Health is the greatest gift; contentment is the greatest wealth; trusting
is the best relationship; nirvana is the highest joy. - Dhammapada
--
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://www.keith-chapman.org
--
See how Windows
Re: [AXIS2] Should JSON messages be considered as REST?
On Mon, Sep 22, 2008 at 9:00 AM, Sanjiva Weerawarana [EMAIL PROTECTED]wrote: I think the whole question of REST is not the point here. Axis2's underlying data model is a SOAP Infoset. As a result, any type of data that runs thru the system has to be represented as a SOAP Infoset. That's not a big deal - essentially it means we need to create two extra Axiom nodes (a s:Envelope node and an s:Body node) and stick a child in there that contains whatever the real data is. Using our nice MTOM integration and the deferred pull architecture of Axiom, we can do that efficiently using OMSourceElement nodes as we've proven multiple times now. That's for incoming stuff - we take whatever that comes in and represent it within a SOAP Infoset. When we have an outgoing message, the inverse question is relevant - if the message is not going out as SOAP, then someone needs to take the real message payload (which is in the child node of the s:Body node) and only write the content of that. That's basically what MessageFormatters do. [So calling all of that REST is totally wrong and an abuse of what REST means. I think we need to refactor that code and get rid of any references to REST as this has nothing to do with REST. Yes I know the history and how it got called that but now its time to fix it.] +1. Better later than never ;). Now to get back to your original point - I think the idea of having message formatters applied to faults too (which you proposed in a later mail) is the right answer. Faults are just messages too and its clearly an oversight that we didn't apply the design orthogonally there too. Time to fix it. +1. Thanks, Keith. Sanjiva. keith chapman wrote: Let me describe the problem in more detail. As of now Axis2 enables you to plug in various message types by registering them in the axis2.xml. Some of these message types will be SOAP based (like text/xml and application/soap+xml) while others are not. And in the latter case when a exception occurs somewhere in the pipe we do not want to throw the fault as a SOAP message. What we do in the REST case of of now is that we take the fault element in the SOAP body (If not found the first child of the SOAP body) and write that out as the fault. As of now Axis2 treats a few message Types as REST specifically application/xml, multipart/form-data and application/x-www-form-urlencoded. But with the pluggable message types in place this may not work that well. Assume that someone want to to plug in application/foo and that this message type is REST how are we gonna handle it? Should we consider adding a attribute to the messageBuilders/messageFormatters section to indicate weather its REST or not? Thanks, Keith. On Sat, Sep 20, 2008 at 3:22 AM, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: +1 .. but I'm a bit confused. I assume by REST you meant that the response has media type text/xml instead of application/soap+xml, right? If we think about it that way, can we get rid of the isDoingREST flag?? (I've hated that from day 1 and haven't had a chance to really dig thru it and figure out how to get rid of. Maybe this is an opportunity to get it right ..) Sanjiva. keith chapman wrote: Any input on this would be appreciated. Thanks, Keith. On Thu, Sep 4, 2008 at 8:40 AM, keith chapman [EMAIL PROTECTED]wrote: Hi devs, This idea came up because of the following scenario. Currently the logic for creating a AxisFault for a fault received lies in org.apache.axis2.util.Utils.java (lines 507 - 530). This works perfectly when the received fault is SOAP or REST. But it does not work as expected when the response is JSON ( rather a exception is thrown saying The MessageContext does not have an associated SOAPFault.). The reason is the logic we use to build the AxisFault. If the fault message is not a SOAP message we check for the flag messageContext.isDoingREST() and get the first element of the SOAPBody as the fault message. When the fault message is JSON its neither SOAP and the messageContext.isDoingREST() returns false. Should we consider JSON messages as REST messages? I believe so. WDYT? Thanks, Keith. -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
Re: [axis2] JAXWS output verbosity
That would be great. Sometimes when the build does fail its hard to locate why it really failed ;). Thanks, Keith. On Mon, Sep 22, 2008 at 9:59 AM, Glen Daniels [EMAIL PROTECTED] wrote: Folks: The JAXWS tests spew a truly outrageous amount of output to the console, much of which are exception stack traces. Despite the fact (based on the successful completion of the build) that these tests are in fact apparently passing, it's pretty scary to see tons of faults go whizzing by. Doesn't put me in my happy place. :) I haven't looked into this yet, but are we logging exceptions in places they should be just (re)thrown, or perhaps swallowed with no output if they're expected? Or are the log4j configs off for the JAXWS tests? If we could make the a successful build actually *look* successful that would be really awesome. Thanks, --Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [AXIS2] Should JSON messages be considered as REST?
Let me describe the problem in more detail. As of now Axis2 enables you to plug in various message types by registering them in the axis2.xml. Some of these message types will be SOAP based (like text/xml and application/soap+xml) while others are not. And in the latter case when a exception occurs somewhere in the pipe we do not want to throw the fault as a SOAP message. What we do in the REST case of of now is that we take the fault element in the SOAP body (If not found the first child of the SOAP body) and write that out as the fault. As of now Axis2 treats a few message Types as REST specifically application/xml, multipart/form-data and application/x-www-form-urlencoded. But with the pluggable message types in place this may not work that well. Assume that someone want to to plug in application/foo and that this message type is REST how are we gonna handle it? Should we consider adding a attribute to the messageBuilders/messageFormatters section to indicate weather its REST or not? Thanks, Keith. On Sat, Sep 20, 2008 at 3:22 AM, Sanjiva Weerawarana [EMAIL PROTECTED]wrote: +1 .. but I'm a bit confused. I assume by REST you meant that the response has media type text/xml instead of application/soap+xml, right? If we think about it that way, can we get rid of the isDoingREST flag?? (I've hated that from day 1 and haven't had a chance to really dig thru it and figure out how to get rid of. Maybe this is an opportunity to get it right ..) Sanjiva. keith chapman wrote: Any input on this would be appreciated. Thanks, Keith. On Thu, Sep 4, 2008 at 8:40 AM, keith chapman [EMAIL PROTECTED]wrote: Hi devs, This idea came up because of the following scenario. Currently the logic for creating a AxisFault for a fault received lies in org.apache.axis2.util.Utils.java (lines 507 - 530). This works perfectly when the received fault is SOAP or REST. But it does not work as expected when the response is JSON ( rather a exception is thrown saying The MessageContext does not have an associated SOAPFault.). The reason is the logic we use to build the AxisFault. If the fault message is not a SOAP message we check for the flag messageContext.isDoingREST() and get the first element of the SOAPBody as the fault message. When the fault message is JSON its neither SOAP and the messageContext.isDoingREST() returns false. Should we consider JSON messages as REST messages? I believe so. WDYT? Thanks, Keith. -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: WSDL Port
Try adding this parameter to the http transport receiver. parameter name=proxyPort8080/parameter Thanks, Keith. On Tue, Sep 16, 2008 at 9:57 PM, Steve Bucknam [EMAIL PROTECTED]wrote: I have an server with axis2 sitting behind a proxy. The proxy has a different port number than the axis server. I am using the hostname parameter to set the hostname in the wsdl to the proxy servers name: parameter name=hostname locked=true1.2.3.4/parameter There doesn't seem to be a corresponding parameter for the port number. I always get: http://1.2.3.4:80/... When I want: http://1.2.3.4:8080/ When I set the hostname to: parameter name=hostname locked=true1.2.3.4:8080/parameter I get: http://1.2.3.4:8080:80/ Is there a way to do what I want? Steve The information transmitted herewith is sensitive information of Chordiant Software or its customers and is intended only for use to the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon, this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [AXIS2] Should JSON messages be considered as REST?
Any input on this would be appreciated. Thanks, Keith. On Thu, Sep 4, 2008 at 8:40 AM, keith chapman [EMAIL PROTECTED]wrote: Hi devs, This idea came up because of the following scenario. Currently the logic for creating a AxisFault for a fault received lies in org.apache.axis2.util.Utils.java (lines 507 - 530). This works perfectly when the received fault is SOAP or REST. But it does not work as expected when the response is JSON ( rather a exception is thrown saying The MessageContext does not have an associated SOAPFault.). The reason is the logic we use to build the AxisFault. If the fault message is not a SOAP message we check for the flag messageContext.isDoingREST() and get the first element of the SOAPBody as the fault message. When the fault message is JSON its neither SOAP and the messageContext.isDoingREST() returns false. Should we consider JSON messages as REST messages? I believe so. WDYT? Thanks, Keith. -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: Adding Smtp and jms transports to transport module
On Mon, Sep 8, 2008 at 3:40 PM, Andreas Veithen [EMAIL PROTECTED]wrote: Amila, The intention was (and still is?) to take the versions of the mail and JMS transports from the Synapse project. That's why they have been removed from Axis2. Yes, I beleive the JMS transport in synapse is ahead than the one we had in Axis2. I tried using the synapse JMS transport (1.2) with Axis2 1.4 but it did not work. I think the transports in Synapse needs some change to be compatible with Axis2. (The problem was that when a response was received at the client it was failing saying the MessageReceiver was not found). Thanks, Keith. I think that it would not be useful to resurrect them. If people use the Axis2 versions of the transports, they should take them from the 1.4 distribution or migrate to the Synapse transports. Regards, Andreas Quoting Amila Suriarachchi [EMAIL PROTECTED]: hi all, As I remember there was a discussion to put Axis2 transports for a different commons project. Finally transports have moved to a different module called transports. But smtp and jms transports are missing from that module. IMHO there are people use these transports. Shall I add them from the Axis2 1.4 branch to transports module? thanks, -- Amila Suriarachchi, WSO2 Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: Adding Smtp and jms transports to transport module
Hi Andreas, Thats exactly the issue. Because of that it always tries to look for a MessageReceiver when a response is received. Thanks, Keith. On Mon, Sep 8, 2008 at 11:32 PM, Andreas Veithen [EMAIL PROTECTED]wrote: Keith, The Synapse transports are compatible with Axis2. The issue you describe looks like SYNAPSE-418. It would be very interesting if you could confirm this. Regards, Andreas On 8 sept. 08, at 17:30, keith chapman wrote: On Mon, Sep 8, 2008 at 3:40 PM, Andreas Veithen [EMAIL PROTECTED] wrote: Amila, The intention was (and still is?) to take the versions of the mail and JMS transports from the Synapse project. That's why they have been removed from Axis2. Yes, I beleive the JMS transport in synapse is ahead than the one we had in Axis2. I tried using the synapse JMS transport (1.2) with Axis2 1.4 but it did not work. I think the transports in Synapse needs some change to be compatible with Axis2. (The problem was that when a response was received at the client it was failing saying the MessageReceiver was not found). Thanks, Keith. I think that it would not be useful to resurrect them. If people use the Axis2 versions of the transports, they should take them from the 1.4 distribution or migrate to the Synapse transports. Regards, Andreas Quoting Amila Suriarachchi [EMAIL PROTECTED]: hi all, As I remember there was a discussion to put Axis2 transports for a different commons project. Finally transports have moved to a different module called transports. But smtp and jms transports are missing from that module. IMHO there are people use these transports. Shall I add them from the Axis2 1.4 branch to transports module? thanks, -- Amila Suriarachchi, WSO2 Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
[AXIS2] Should JSON messages be considered as REST?
Hi devs, This idea came up because of the following scenario. Currently the logic for creating a AxisFault for a fault received lies in org.apache.axis2.util.Utils.java (lines 507 - 530). This works perfectly when the received fault is SOAP or REST. But it does not work as expected when the response is JSON ( rather a exception is thrown saying The MessageContext does not have an associated SOAPFault.). The reason is the logic we use to build the AxisFault. If the fault message is not a SOAP message we check for the flag messageContext.isDoingREST() and get the first element of the SOAPBody as the fault message. When the fault message is JSON its neither SOAP and the messageContext.isDoingREST() returns false. Should we consider JSON messages as REST messages? I believe so. WDYT? Thanks, Keith. -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: WSDL for attachments and WSDL2Java
/ /wsdl:message wsdl:message name=GetAssetSoapOut wsdl:part name=parameters element=tns:GetAssetResponse/ wsdl:part name=asset type=s:base64Binary/ /wsdl:message wsdl:message name=StoreAssetSoapIn wsdl:part name=parameters element=tns:StoreAsset/ wsdl:part name=asset type=s:base64Binary/ /wsdl:message wsdl:message name=StoreAssetSoapOut wsdl:part name=parameters element=tns:StoreAssetResponse/ /wsdl:message wsdl:portType name=VersionCueService wsdl:operation name=GetAsset wsdl:input message=tns:GetAssetSoapIn/ wsdl:output message=tns:GetAssetSoapOut/ /wsdl:operation wsdl:operation name=StoreAsset wsdl:input message=tns:StoreAssetSoapIn/ wsdl:output message=tns:StoreAssetSoapOut/ /wsdl:operation /wsdl:portType wsdl:binding name=VersionCueService type=tns:VersionCueService soap:binding transport=http://schemas.xmlsoap.org/soap/http/ wsdl:operation name=GetAsset soap:operation soapAction=~/WebServices/GetAsset style=document/ wsdl:input soap:body use=literal/ /wsdl:input wsdl:output mime:multipartRelated mime:part soap:body use=literal/ /mime:part mime:part mime:content part=asset type=application/octet-stream/ /mime:part /mime:multipartRelated /wsdl:output /wsdl:operation wsdl:operation name=StoreAsset soap:operation soapAction=~/WebServices/StoreAsset style=document/ wsdl:input mime:multipartRelated mime:part soap:body use=literal/ /mime:part mime:part mime:content part=asset type=application/octet-stream/ /mime:part /mime:multipartRelated /wsdl:input wsdl:output soap:body use=literal/ /wsdl:output /wsdl:operation /wsdl:binding wsdl:service name=VersionCueService wsdl:port name=VersionCueService binding=tns:VersionCueService soap:address location=http://localhost:8080/axis/services/VersionCueService/ /wsdl:port /wsdl:service /wsdl:definitions Thanks in advance, Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [Axis2][VOTE] Axis2 1.4.1 - Take #4
+1 Thanks, Keith. On Thu, Aug 21, 2008 at 5:51 PM, Nandana Mihindukulasooriya [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am calling fresh a vote again for Axis2 1.4.1 and only the source distribution is changed. Only change is removing some binaries that were accidentally included. New source distribution can be found here. Please review. http://people.apache.org/~nandana/axis2-1.4.1/dist/axis2-1.4.1-src.zip thanks, nandana Distributions: http://people.apache.org/~nandana/axis2-1.4.1/dist Maven2 repository: http://people.apache.org/~nandana/axis2-1.4.1/m2-repo/ SVN Info: https://svn.apache.org/repos/asf/webservices/axis2/branches/java/1_4 (Revision: 684402) Here's my +1 to declaring the above dist as Axis2 1.4.1. thanks, nandana Links to the individual Distribution/Tool files are listed below: Distributions : http://people.apache.org/~nandana/axis2-1.4.1/dist/axis2-1.4.1-bin.zip http://people.apache.org/~nandana/axis2-1.4.1/dist/axis2-1.4.1-docs.zip http://people.apache.org/~nandana/axis2-1.4.1/dist/axis2-1.4.1-src.zip http://people.apache.org/~nandana/axis2-1.4.1/dist/axis2-1.4.1-war.zip Tools : http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-aar-maven-plugin-1.4.1.jar http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-ant-plugin-1.4.1.jar http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-eclipse-codegen-wizard.zip http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-eclipse-service-archiver-wizard.zip http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-mar-maven-plugin-1.4.1.jar http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-idea-plugin-1.4.1.zip http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-java2wsdl-maven-plugin-1.4.1.jar http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-wsdl2code-maven-plugin-1.4.1.jar -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIrV3ZmA4ts7hLdV8RAsJPAJ9l2tuD6tbSBOxRbg1E9xNyPcq83ACgiVSo bKWm+W1YD5ZO1w8EZM+FEsQ= =Fx2j -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][VOTE] Axis2 1.4.1 - Take #4
I believe Charitha did test the source build on a clean machine. Thats how we figured out that the docs were not copied to the source build. He had to build axis2-mar-maven-plugin before building the release. Thanks, Keith. On Fri, Aug 22, 2008 at 12:45 AM, Eran Chinthaka [EMAIL PROTECTED] wrote: I downloaded the source distro and tried to build it. But since some of the tools jars (like axis2-maven-plugin) are not in the maven repo yet, I couldn't test the build. I assume some one checked source distro, in a fresh machine, with mvn targets. On Thu, Aug 21, 2008 at 3:04 PM, Eran Chinthaka [EMAIL PROTECTED] wrote: SVN Info: https://svn.apache.org/repos/asf/webservices/axis2/branches/java/1_4 (Revision: 684402) Shouldn't this branch be 1_4_1 and not 1_4? -- With Mettha, Eran Chinthaka Health is the greatest gift; contentment is the greatest wealth; trusting is the best relationship; nirvana is the highest joy. - Dhammapada -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][VOTE] Axis2 1.4.1 - Take #3
Hi Thilina, The docs are needed in the source distribution, otherwise you cannot build using the source distribution. I believe the source distribution should be able to produce the release artifacts on its own. Thanks, Keith. On Wed, Aug 20, 2008 at 10:50 PM, Thilina Gunarathne [EMAIL PROTECTED] wrote: Hi, I notice the size of the source distribution is huge (55MB).. The culprit seems to be the tools module.. It contains binaries for the 3 plugins and a combined binary for them too... One other thing I noticed is that we have included the docs module in to the src dist too, which is not needed according to our earlier plan [1]. This has caused the size of the src dist to be increased quite a bit in the 1.4 release too (6.9 MB in 1.3, 12 MB in 1.4) due to the inclusion of documentation.. thanks, Thilina [1] http://wiki.apache.org/ws/FrontPage/Axis2/releases/1.1/release_artifacts On Wed, Aug 20, 2008 at 4:46 AM, Michele Mazzucco [EMAIL PROTECTED] wrote: +1 for me. Michele On 19 Aug 2008, at 07:28, Nandana Mihindukulasooriya wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Devs, Please review: http://people.apache.org/~nandana/axis2-1.4.1/dist Maven2 repository: http://people.apache.org/~nandana/axis2-1.4.1/m2-repo/ SVN Info: https://svn.apache.org/repos/asf/webservices/axis2/branches/java/1_4 (Revision: 684402) Here's my +1 to declaring the above dist as Axis2 1.4.1. thanks, nandana Links to the individual Distribution/Tool files are listed below: Distributions : http://people.apache.org/~nandana/axis2-1.4.1/dist/axis2-1.4.1-bin.zip http://people.apache.org/~nandana/axis2-1.4.1/dist/axis2-1.4.1-docs.zip http://people.apache.org/~nandana/axis2-1.4.1/dist/axis2-1.4.1-src.zip http://people.apache.org/~nandana/axis2-1.4.1/dist/axis2-1.4.1-war.zip Tools : http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-aar-maven-plugin-1.4.1.jar http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-ant-plugin-1.4.1.jar http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-eclipse-codegen-wizard.zip http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-eclipse-service-archiver-wizard.zip http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-mar-maven-plugin-1.4.1.jar http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-idea-plugin-1.4.1.zip http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-java2wsdl-maven-plugin-1.4.1.jar http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-wsdl2code-maven-plugin-1.4.1.jar -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIqmfymA4ts7hLdV8RAo3HAJ9CgBbKN7V5sBuGlyrWlaRrWDvKCwCbBKaM mPWSjef5I3O0bE4XgaMyn6E= =Wvk4 -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] -- Thilina Gunarathne - http://thilinag.blogspot.com -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][VOTE] Axis2 1.4.1 - Take #3
Did some smoke test with the bin release and the war release using a dummy service and it looked fine. +1 for the release. Thanks, Keith. On Tue, Aug 19, 2008 at 11:58 AM, Nandana Mihindukulasooriya [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Devs, Please review: http://people.apache.org/~nandana/axis2-1.4.1/dist Maven2 repository: http://people.apache.org/~nandana/axis2-1.4.1/m2-repo/ SVN Info: https://svn.apache.org/repos/asf/webservices/axis2/branches/java/1_4 (Revision: 684402) Here's my +1 to declaring the above dist as Axis2 1.4.1. thanks, nandana Links to the individual Distribution/Tool files are listed below: Distributions : http://people.apache.org/~nandana/axis2-1.4.1/dist/axis2-1.4.1-bin.zip http://people.apache.org/~nandana/axis2-1.4.1/dist/axis2-1.4.1-docs.zip http://people.apache.org/~nandana/axis2-1.4.1/dist/axis2-1.4.1-src.zip http://people.apache.org/~nandana/axis2-1.4.1/dist/axis2-1.4.1-war.zip Tools : http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-aar-maven-plugin-1.4.1.jar http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-ant-plugin-1.4.1.jar http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-eclipse-codegen-wizard.zip http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-eclipse-service-archiver-wizard.zip http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-mar-maven-plugin-1.4.1.jar http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-idea-plugin-1.4.1.zip http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-java2wsdl-maven-plugin-1.4.1.jar http://people.apache.org/~nandana/axis2-1.4.1/tools/axis2-wsdl2code-maven-plugin-1.4.1.jar -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIqmfymA4ts7hLdV8RAo3HAJ9CgBbKN7V5sBuGlyrWlaRrWDvKCwCbBKaM mPWSjef5I3O0bE4XgaMyn6E= =Wvk4 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][VOTE] Axis2 1.4.1 release
Hi Nandana, I noticed the following in the war distribution, 1. There is a test.txt in the distribution (This looks like a diff that you used before doing the release) 2. The README has not gone through the ant filter hence it has Apache Axis2 @axisVersion@ build (@TODAY@). This is ok in the bin release. Thanks, Keith. On Fri, Aug 8, 2008 at 8:10 PM, Nandana Mihindukulasooriya [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Devs, ~Axis2 1.4.1 is ready for the vote. Please review: http://people.apache.org/~nandana/axis2-1.4.1/FINAL/dist/zips Maven2 repository: http://people.apache.org/~nandana/axis2-1.4.1/FINAL/m2-repo/ SVN Info: https://svn.apache.org/repos/asf/webservices/axis2/branches/java/1_4 (Revision: 683612) Here's my +1 to declaring the above dist as Axis2 1.4.1. thanks, nandana Links to the individual Distribution/Mar/Tool files are listed below: Distributions : http://people.apache.org/~nandana/axis2-1.4.1/FINAL/dist/zips/axis2-1.4.1-bin.zip http://people.apache.org/~nandana/axis2-1.4.1/FINAL/dist/zips/axis2-1.4.1-docs.zip http://people.apache.org/~nandana/axis2-1.4.1/FINAL/dist/zips/axis2-1.4.1-src.zip http://people.apache.org/~nandana/axis2-1.4.1/FINAL/dist/zips/axis2-1.4.1-war.zip Modules : http://people.apache.org/~nandana/axis2-1.4.1/FINAL/dist/mars/addressing-1.41.mar http://people.apache.org/~nandana/axis2-1.4.1/FINAL/dist/mars/axis2-scripting-1.41.mar http://people.apache.org/~nandana/axis2-1.4.1/FINAL/dist/mars/mex-1.41.mar http://people.apache.org/~nandana/axis2-1.4.1/FINAL/dist/mars/ping-1.41.mar http://people.apache.org/~nandana/axis2-1.4.1/FINAL/dist/mars/soapmonitor-1.41.mar Tools : http://people.apache.org/~nandana/axis2-1.4.1/FINAL/dist/tools/axis2-aar-maven-plugin-1.4.1.jar http://people.apache.org/~nandana/axis2-1.4.1/FINAL/dist/tools/axis2-ant-plugin-1.4.1.jar http://people.apache.org/~nandana/axis2-1.4.1/FINAL/dist/tools/axis2-eclipse-codegen-wizard.zip http://people.apache.org/~nandana/axis2-1.4.1/FINAL/dist/tools/axis2-eclipse-service-archiver-wizard.zip http://people.apache.org/~nandana/axis2-1.4.1/FINAL/dist/tools/axis2-mar-maven-plugin-1.4.1.jar http://people.apache.org/~nandana/axis2-1.4.1/FINAL/dist/tools/axis2-idea-plugin-1.4.1.zip http://people.apache.org/~nandana/axis2-1.4.1/FINAL/dist/tools/axis2-java2wsdl-maven-plugin-1.4.1.jar http://people.apache.org/~nandana/axis2-1.4.1/FINAL/dist/tools/axis2-wsdl2code-maven-plugin-1.4.1.jar -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFInFrdmA4ts7hLdV8RAn/VAJ9qIHAJCQPWQYBp0oiDVYxF1Qt9/wCggey8 ZssFr6oIf5TyWed1HrjHwsE= =aWHE -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r682470 - in /webservices/axis2/branches/java/1_4/modules/kernel/src/org/apache/axis2: description/ transport/http/ transport/jms/ transport/nhttp/
Hi Dims,
I agree that its not a security problem. But REST stuff via WSDL 2.0 would
not work without this fix. Which means that REST via WSDL 2.0 is broken in
Axis 2 1.4. We agreed that if there are critical fixes we would put them
into this release. And this IS a critical fix.
Thanks,
Keith.
On Thu, Aug 7, 2008 at 11:18 AM, Davanum Srinivas [EMAIL PROTECTED] wrote:
Keith,
Do you consider this in scope for a security problem oriented 1.4.1
release?
-- dims
On Thu, Aug 7, 2008 at 12:56 AM, keith chapman [EMAIL PROTECTED]
wrote:
Here is the reason for adding the trailing /
When a WSDL has a httpLocation that is resolved against the base URI, so
lets assume a bindingOperation has whttp:laction=foo/{bar} and that this
is
exposed over 3 endpoints, SOAP 11 SOAP 12 and HTTP.
for the SOAP 11 endpoint the address would be
http://localhost:8080/axis2/services/fooService.SOAP11Endpoint/
for the SOAP 11 endpoint the address would be
http://localhost:8080/axis2/services/fooService.SOAP12Endpoint/
for the SOAP 11 endpoint the address would be
http://localhost:8080/axis2/services/fooService.HTTPEndpoint/
Now the above works perfectly only if the trailing / is there. If its
absent when
http://localhost:8080/axis2/services/fooService.SOAP11Endpoint/
is resolved agaist foo/{bar} the result would be
http://localhost:8080/axis2/services/foo/{bar}http://localhost:8080/axis2/services/foo/%7Bbar%7Dwhich
is incorrect.
So that is the reason for having the trailing /
Now the second point. Why did I remove it ;).
Previously the trailing / was added in the AxisEndpoint class where the
epr was calculated. This leads to undesirable issues when other
transports
are used. For e.g when JMS was used the endpoint address was
jms:/fooService?transport.jms.ConnectionFactoryJNDIName=QueueConnectionFactoryjava.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactoryjava.naming.provider.url=tcp://localhost:61616/
If the dynamic mode of service client was used to write a client for this
it
would fail with a numberFormatException. All because of the trailing /.
The trailing / is needed only for the HTTP case. So it should be the
duty
of the httpListeners to add this trailing /. This was the rationale for
getting rid of this logic from the AxisEndpoint class and adding it to
the
http listeners.
Thanks,
Keith.
On Wed, Aug 6, 2008 at 10:44 PM, Davanum Srinivas [EMAIL PROTECTED]
wrote:
Sorry! had to ask! and is this a security issue? Why is it even being
considered?
-- dims
On Wed, Aug 6, 2008 at 1:06 PM, Saminda Abeyruwan [EMAIL PROTECTED]
wrote:
Is there any particular reason to add the tailing /.
Saminda
On Wed, Aug 6, 2008 at 8:35 AM, Amila Suriarachchi
[EMAIL PROTECTED] wrote:
hi keith,
is there any reason to remove the ending /.
IMHO we should not remove this if there is no problem with that.
Because
someone may have written a code
by considering that /
thanks,
Amila.
On Tue, Aug 5, 2008 at 12:49 AM, [EMAIL PROTECTED] wrote:
Author: keithc
Date: Mon Aug 4 12:19:15 2008
New Revision: 682470
URL: http://svn.apache.org/viewvc?rev=682470view=rev
Log:
Applying patch given by amila to Axis2-3961. Also getting rid of the
trailing / added in axisEndpoint and adding it in the http related
listeners
Modified:
webservices/axis2/branches/java/1_4/modules/kernel/src/org/apache/axis2/description/AxisEndpoint.java
webservices/axis2/branches/java/1_4/modules/kernel/src/org/apache/axis2/transport/http/AxisServlet.java
webservices/axis2/branches/java/1_4/modules/kernel/src/org/apache/axis2/transport/http/CustomListener.java
webservices/axis2/branches/java/1_4/modules/kernel/src/org/apache/axis2/transport/http/SimpleHTTPServer.java
webservices/axis2/branches/java/1_4/modules/kernel/src/org/apache/axis2/transport/jms/JMSListener.java
webservices/axis2/branches/java/1_4/modules/kernel/src/org/apache/axis2/transport/nhttp/HttpCoreNIOListener.java
Modified:
webservices/axis2/branches/java/1_4/modules/kernel/src/org/apache/axis2/description/AxisEndpoint.java
URL:
http://svn.apache.org/viewvc/webservices/axis2/branches/java/1_4/modules/kernel/src/org/apache/axis2/description/AxisEndpoint.java?rev=682470r1=682469r2=682470view=diff
==
---
webservices/axis2/branches/java/1_4/modules/kernel/src/org/apache/axis2/description/AxisEndpoint.java
(original)
+++
webservices/axis2/branches/java/1_4/modules/kernel/src/org/apache/axis2/description/AxisEndpoint.java
Mon Aug 4 12:19:15 2008
@@ -194,7 +194,7 @@
.getEPRsForService(sDOTe, ip);
// we consider only the first
address return
Re: [jira] Created: (AXIS2-3968) Fails to build Axis2-1.4.1 from source distribution
Charitha this is because the axis2-mar-maven plugin is used in the build and its not available in public repos. Can you try going into modules/tools/axis2-mar-maven-plugin and building that first before you attempt to build axis2. (If it fails saying that you need the axis2-aar-maven-plugin you may need to build that too). On Thu, Aug 7, 2008 at 9:53 PM, Charitha Kankanamge (JIRA) [EMAIL PROTECTED]wrote: Fails to build Axis2-1.4.1 from source distribution --- Key: AXIS2-3968 URL: https://issues.apache.org/jira/browse/AXIS2-3968 Project: Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: 1.4.1 Environment: Winxp, Axis2-1.4.1 (Release candidate-2008-08-07), jdk15, maven2.0.8 Reporter: Charitha Kankanamge Assignee: Nandana Mihindukulasooriya Priority: Blocker I couldnot build Axis2-1.4.1 from source distro. See the following output. Downloading: http://ws.zones.apache.org/repository2/org/apache/axis2/axis2-mar-maven-plugin/1.4.1/axis2-mar-maven-plugin-1.4.1.jar Downloading: http://repo1.maven.org/maven2/org/apache/axis2/axis2-mar-maven-plugin/1.4.1/axis2-mar-maven-plugin-1.4.1.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.axis2 -DartifactId=axis2-mar-maven-plugin -Dversion=1.4.1 -Dpackaging=maven-plugin -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.axis2 -DartifactId=axis2-mar-maven-plugin -Dversion=1.4.1 -Dpackaging=maven-plugin -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[ id] org.apache.axis2:axis2-mar-maven-plugin:maven-plugin:1.4.1 from the specified remote repositories: central (http://repo1.maven.org/maven2), ws-zones (http://ws.zones.apache.org/repository2), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository) org.apache.axis2:axis2-mar-maven-plugin:maven-plugin:1.4.1 from the specified remote repositories: central (http://repo1.maven.org/maven2), ws-zones (http://ws.zones.apache.org/repository2), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 8 seconds [INFO] Finished at: Thu Aug 07 21:48:38 IST 2008 [INFO] Final Memory: 8M/15M [INFO] D:\axis2\axis2-1.4.1 -- 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] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: svn commit: r682470 - in /webservices/axis2/branches/java/1_4/modules/kernel/src/org/apache/axis2: description/ transport/http/ transport/jms/ transport/nhttp/
/src/org/apache/axis2/transport/nhttp/HttpCoreNIOListener.java?rev=682470r1=682469r2=682470view=diff
==
---
webservices/axis2/branches/java/1_4/modules/kernel/src/org/apache/axis2/transport/nhttp/HttpCoreNIOListener.java
(original)
+++
webservices/axis2/branches/java/1_4/modules/kernel/src/org/apache/axis2/transport/nhttp/HttpCoreNIOListener.java
Mon Aug 4 12:19:15 2008
@@ -222,7 +222,7 @@
* Return the EPR for the given service (implements deprecated
method
temporarily)
*/
public EndpointReference getEPRForService(String serviceName,
String
ip) throws AxisFault {
-return new EndpointReference(serviceEPRPrefix + serviceName);
+return new EndpointReference(serviceEPRPrefix + serviceName +
/);
}
/**
@@ -234,7 +234,7 @@
*/
public EndpointReference[] getEPRsForService(String serviceName,
String ip) throws AxisFault {
EndpointReference[] endpointReferences = new
EndpointReference[1];
-endpointReferences[0] = new EndpointReference(serviceEPRPrefix
+
serviceName);
+endpointReferences[0] = new EndpointReference(serviceEPRPrefix
+
serviceName + /);
return endpointReferences;
}
--
Amila Suriarachchi,
WSO2 Inc.
--
Davanum Srinivas :: http://davanum.wordpress.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://www.keith-chapman.org
JMS endpoint address always returns null
Hi all, I was playing around with axis2 1.4.1-RC1 and noticed that when the JMS transport is configured the endpoint address is null. Whereas it should have been something like location=jms:/myService?transport.jms.ConnectionFactoryJNDIName=QueueConnectionFactoryjava.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactoryjava.naming.provider.url=tcp://localhost:61616/. I tried debigging through and figured out that this occurs due to this bit of code in the AxisEndpoint class, // we should pass [serviceName].[endpointName] instead of // [endpointName] String sDOTe = serviceName + . + name; EndpointReference[] eprsForService = listener .getEPRsForService(sDOTe, ip); In here we ask the listner the endpoint address using serviceName.endpointName but the JMSListener keeps this mapping using the serviceName hence the above returns null always. How could we solve this issue? I don't think we can creates destination addresses as serviceName.endpointName for each endpoint but rather create just one destination and use the same address for all endpoints. WDYT? Also I think this is something that should be fixed for 1.4.1. I already filed a JIRA on this ( https://issues.apache.org/jira/browse/AXIS2-3961) Thanks, Keith. -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: Hi - A clarification.
Hi, A workaround for you will be to, 1. Save the WSDL file generated by axis2. 2. Edit the types section of the WSDL to suit your needs. 3. Then you will have to generate serverside code using this edited WSDL. 4. Get the generated messagereceiver and set it as your message receirver using the services.xml 5. Bundle the WSDL into the aar and deploy your service Thanks, Keith. On Thu, Jul 24, 2008 at 4:19 PM, Dister Kemp [EMAIL PROTECTED] wrote: Hello Sanka, Thanks for your response. But I was wondering if anything could be specified in the WSDL file which would indicate to AXIS2 to not emit these two tags. Or do you think MessageBuilders is something that could come to my help here. The only issue in my case is that I do not have access to the client sources. The client will directly hit my URL and consume my webservice output XML. Any help is appreciated. Thanks Dister _ On Thu, Jul 24, 2008 at 2:31 PM, Sanka Samaranayake [EMAIL PROTECTED] wrote: I'm afraid you can't do that if the service is deployed as a POJO Web service. One alternative would be to handle those two elements at the client side via a generated stub. Sanka On Wed, Jul 23, 2008 at 5:37 PM, Dister Kemp [EMAIL PROTECTED] wrote: Hello Axis team, I have an issue on which I could not a find a way to resolve with Axis2. I have a server running Axis2 on Tomcat with my POJO app. which exposes some webservices via REST. There is a webservice - register which returns a string - but is basically XML. Now the return on the browser when hitting a webservice endpoint. (register) it comes as ns:registerResponse xmlns:ns=http://abc.com/; ns:return lt;?xml version=1.0 encoding=utf-8?lt;string xmlns=http://abc.com/;lt;abclt;register111 lt;/registerlt;/abclt;/string /ns:return /ns:registerResponse As you can see there are two outer tags ns:registerResponse and ns:return which is causing my XML Parser on the client side to fail. Is there a way to disable those two tags that AXIS2 is sending, so that the XML tag I am sending is the top level lag and that way my client XML parser would work. Any pointers in this regard is highly appreciated. Thanks Dister _ -- Sanka Samaranayake WSO2 Inc. http://sankas.blogspot.com/ http://www.wso2.org/ -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: next axis2 release with healthy JMS support
Hi Micheal, The Synapse guys are very active when it comes to Transports for Axis2. Asankha has been doing numerous improvements on this. So I suggest that you get the synapse-transports jar and drop it into your lib directory and use the JMS transport included in that jar. Thanks, Keith. On Tue, Jul 8, 2008 at 11:25 PM, Wagner, Michael [EMAIL PROTECTED] wrote: Hallo, (Sorry for my question) but when do you expect to release a new version with a healthy JMS support. I could not find anything regarding JMS support in the trunc. So I am a little bit concerned about using Axis2, since JMS is a major issue for me. I have only seen a commit comment like stale JMS code dumped see axis-dev. For sure, the old implementation had some issues (creating always a queue indtead of the topic I need).=20 Can you give me any insight on the time schedule, please? Thanks, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [jira] Created: (AXIS2-3895) Axis2 version 1.2 support for Maven2
I don't think that maven2 support was complete in 1.2. But since 1.3 we've been totally Dependant on Maven2. Thanks, Keith. On Sat, Jul 5, 2008 at 3:21 AM, Prashant Pandit (JIRA) [EMAIL PROTECTED] wrote: Axis2 version 1.2 support for Maven2 Key: AXIS2-3895 URL: https://issues.apache.org/jira/browse/AXIS2-3895 Project: Axis 2.0 (Axis2) Issue Type: Bug Reporter: Prashant Pandit Does Axis2 version 1.2 support Maven 2 -- 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] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: Security hole in Axis2 1.4 + Rampart 1.4
+1 for a 1.4.1. There were some other issues that I noticed in 1.4 as well, some of these are already fixed in trunk. https://issues.apache.org/jira/browse/AXIS2-3819 https://issues.apache.org/jira/browse/AXIS2-3859 https://issues.apache.org/jira/browse/AXIS2-3867 https://issues.apache.org/jira/browse/AXIS2-3877 Thanks, Keith. On Mon, Jun 30, 2008 at 8:59 PM, Nandana Mihindukulasooriya [EMAIL PROTECTED] wrote: Hi, There are few issues with Axis2 1.4 / Rampart 1.4 with the new policy configuration. The new policy configuration which allows us to apply policies to binding hierarchy is a great feature when in comes to ws security policy configuration. It allows security policies to be attached to the correct attachment points. But there are few issues that need to be fixed in Axis2 1.4. I will list them below. 1.) If we configure security using new configuration, service can be accessed without security. In Axis2 1.4, a service is exposed in two EPRs (consider SOAP 1.1 binding). eg. http://localhost:8080/axis2/services/SecureService.SecureServiceHttpSoap11Endpoint http://localhost:8080/axis2/services/SecureService But if we you set the policies using the new configuration, if you do a web service call to the older EPR, you can access the service without any security even though it is secured using the binding hierarchy. This happens because if we call the old EPR, it is not dispatched to a binding. But this leaves the service vulnerable. I think we should dispatch to one of the bindings may be using soap envelope version if we have only one binding with that soap version. We should have a way to dispatch messages which comes to old EPR to one of the bindings else we should have an option to disable that EPR. 2.) In the out flow, policies are not set correctly in the binding message. This is fixed in the trunk but this bug is there in Axis2 1.4. So the option we have is to configure security using the old configuration. But then the problem is policies are attached to the port type which is the correct way to do if we have policies using service,operationmessage tags. But this makes Axis2 not interoperable as security policies should be attached to binding hierarchy according WS Security policy specification. Ideally we should always use the new configuration to apply security. And code generation also doesn't work correctly when the policies attached to the port type (polices are not correctly attached to the stub). So I think it would be great if can consider a Axis2 1.4.1 with these things fixed. thanks, nandana -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: Including the services schema in the distribution
You can use some maven magic to get the xsd into the eclipse plugin. You could even use svn externals to get the xsd into the eclipse plugin codebase without copying the file over. Thanks, Keith. On Mon, Jun 30, 2008 at 8:42 AM, Saminda Wijeratne [EMAIL PROTECTED] wrote: Hi, I'm working on the two eclipse plugins in the axis2 code base. In the eclipse service wizard archive plugin i need to validate the user given services.xml file. for this i need the services.xsd to perform a schema validation. This file is located in the project axis2-kernal, but it is not accessible from the plugin since it is not a part of the plugin project. and the services.xsd is not available in the axis2 distro. Since i need to validate the xml, using schema validation only thing I can do is to add the xsd file as a resource to the plugin project. If anyone else know a better way to get hold of the services schema i'm grateful for your ideas. I'm also wondering wouldn't it be better to have the services schema shipped with the axis2 ditribution itself. WDYT? Thanx in advance, Saminda Wijeratne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [axis2] jar dependency
You will have to upgrade Woden, XMLschema, neethi (I think will will have to upgrade httpcore and commons-httpClient too). These are the obvious ones that come to mind. Thanks, Keith. On Fri, Jun 20, 2008 at 11:49 AM, Tony Dean [EMAIL PROTECTED] wrote: Hi, Recently I received a thorough response about Axis2 jar dependencies. Thanks again for that. However, another question that I have is if I upgrade to Axis2 1.4 core jars and Axiom 1.2.7 do I need to upgrade to the latest versions of the other dependent jars? Which jar dependencies are mandatory to upgrade and which are not? Is this something that has been determined? Thanks. Tony Dean SAS Institute Inc. 919.531.6704 [EMAIL PROTECTED] SAS... The Power to Know http://www.sas.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: How do I tell WSDL2Java not to put URLs in the Stub?
Hi, If you generate the client using Axis2 you can pass the URL to the constructor of the stub. for e.g if FooStub was your stub, you could do the following, FooStub stub = new FooStub(http://localhost:8080/YOUR_URL;); If you use FooStub stub = new FooStub(); instead it would take the URL off the WSDL. Thanks, Keith. On Thu, Jun 19, 2008 at 9:13 PM, MrNobody [EMAIL PROTECTED] wrote: I am trying to generate client side classes for a Web Service where the URL's are configurable (without actually modifying the Stub class) I worked with Web Services once before and the WSDL2Java tool generated ServiceLocator class for the service and I could pass the end point URL through that. It also generated several other classes included interfaces. But now I am trying to do it with this new Web Service and all it generates is a Stub class and a CallbackHandler class. Why is it so different? My goal is to generate client classes where they are not dependent on the end point URL being hard coded in the generated classes, but rely on the URL being passed to them. But the only way I knew to do this was using a ServiceLocator class but unfortunately for this web service it's just not generating that class. Is there a special WSDL2Java command line option I am not using? I dont set any options right now... -- View this message in context: http://www.nabble.com/How-do-I-tell-WSDL2Java-not-to-put-URLs-in-the-Stub--tp18011876p18011876.html Sent from the Axis - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [jira] Created: (AXIS2-3865) wsdl2java generates wrong code
(); } object.setData( org.apache.axis2.databinding.utils.ConverterUtil.convertToBase64Binary(content.toString())); } } Now it works. If necessary I can send my changes -- 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] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: Does Axis2 provide much better performance than Axis 1.X?
Hi, Here are some results of performance testing We've done. You can go through these articles to see the reality (Axis2 is FAST). http://wso2.org/library/91 http://wso2.org/library/588 Thanks, Keith. On Mon, Jun 16, 2008 at 2:43 PM, [EMAIL PROTECTED] wrote: Hi, Sorry for double posting…... I read somewhere that Axis2 provides better performance comparing to Axis 1.X due to the introduction of StAX XML parsing. Based some tests, I can see that for large XML document Axis2 is 5 to 10 times faster than Axis 1.X. I'm a bit confused here since Axis1.X uses SAX parser which should be at least as fast as StAX parser, so why the performance improvement is achieved? Thanks a lot! Regards, Mai Sun -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: Introducing J2XB for Axis
in to things like AXIOM within Axis2. ADB might serve the purpose most of the time, I think. I specially like it since it is light weight and tightly coupled in to the internals of Axiom. If J2XB is a light weight framework to generate schema from Java classes, then perhaps we might be able to use that to improve our Java2WSDL as well. For the time being, IIRC, we use some sorta reflection and annotations mechanism and definitely we like to get some help for that too. Thanks, Eran Chinthaka [1] : http://wso2.org/library/35 On Sun, Jun 1, 2008 at 1:51 AM, Yoav Abrahami [EMAIL PROTECTED] wrote: Hi Eran, J2XB certainly introduces new functionality beyond ADB, XmlBeans or JiBX. * XMLBeans Supports Java code generation from an XML schema - it requires that the generated binding classes be separate then the application classes and it does not generate an XML schema from Java code. * JiBX has good support for binding Java Beans to XML and back. However, it is still missing some features such as XML Schema generation (which is important for WSDL generation), XML list styles, flexibility in enumeration support, etc. * ADB - well, ADB is a simplistic databinding framework, but still has a lot of features missing compared to J2XB. I think that integrating J2XB into Axis 2 is a good idea (and hence this thread). However, I find it difficult to do so myself - I am not a member in the Axis 2 dev team. As such, except the technical difficulty, I do not have the knowledge now Axis 2 is structured and where the I should integrate J2XB (in the code). I am seeking help from you guys here to help in this integration. I can think of 4 possible integration points: * marshaling and unmarshaling XML to Java classes used as parameters for an Axis WS (in an AAR archive). * marshaling and unmarshaling MXL to Java classes used as parameters for an Axis WS client * automatic WSDL generation for a service in an AAR. * extending Java2WSDL to support J2XB binding I am basically looking of developer involvement (from the Axis team) to help creating those integrations. Cheers, Yoav On Sat, May 31, 2008 at 5:13 AM, Eran Chinthaka [EMAIL PROTECTED] wrote: Perhaps you can integrate J2XB into Axis2 and prove, using some experimental results, the areas J2XB is better than ADB or XMLBeans or JiBX. And I hope this will motivate our ADB team and Mr. JiBX (Dennis) to compete with J2BX :) On Fri, May 30, 2008 at 4:30 AM, Yoav Abrahami [EMAIL PROTECTED] wrote: Hi Axis dev team. (I hope this is the right mailing list. if not, my apologies) I have recently released the J2XB (Java 2 XML Binding) project as an open source project. I believe J2XB can be used as a new binding for Axis 2 and offer some unique advantages over the existing bindings. see at http://j2xb.sourceforge.net/index.html J2XB is unique in that it allows to annotate Java classes and generate the XML schema (XSD) from the Java classes, including facets, constraints, etc. In addition, it allows to map any Java class to XML structure in a vary flexible way, supporting any Java class (POJO) including classes with non-trivial constructors and factories. All this is performed without need to write code or to generate code. Connecting J2XB and Axis 2 will result in the ability to white a Web Service the axis way (POJO in an AAR) with WSDL generated including XSD generated form the Java classes. The XSD generated can then be controlled using the J2XB annotations. Note that J2XB allows considerably more control over the XML structure compared to JAXB. In hope that there is interest to join forces, Cheers, Yoav -- With Mettha, Eran Chinthaka Health is the greatest gift; contentment is the greatest wealth; trusting is the best relationship; nirvana is the highest joy. - Dhammapada -- With Mettha, Eran Chinthaka Health is the greatest gift; contentment is the greatest wealth; trusting is the best relationship; nirvana is the highest joy. - Dhammapada -- Amila Suriarachchi, WSO2 Inc. -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [axis2-1.4] woden
dynamically (?wsdl) most who have servers dont care about carrying around 60 jars.. but I can definitely see the need to trim down to run on a laptop or mobile device and yes dims comments on what is necessary and now should be in the readme.txt or RLNotes! http://markmail.org/message/fmebppn7adkdvvra#query:%22AXIS2%20Dependency%20List%22+page:1+mid:wec5ht4u7xs4fcou+state:results Thanks Tony Martin - Original Message - From: Tony Dean [EMAIL PROTECTED] To: axis-dev@ws.apache.org; Martin [EMAIL PROTECTED] Sent: Thursday, May 29, 2008 2:30 PM Subject: RE: [axis2-1.4] woden Martin, The dependency comes into to play when deploying modules. Here is the dependency chain that I tracked down in the source. org.apache.axis2.deployment.ModuleDeployer (line 60) org.apache.axis2.deployment.repository.util.ArchiveReader org.apache.axis2.deployment.resolver.WarBasedWSDLLocator org.apache.woden.resolver.URIResolver There are many more instances of woden dependency. I just listed the one that fails first for me. Are there any other dependencies on Axis2 1.4 that are required that were not required for Axis2 1.3? Also, if I want to upgrade to Axis2 1.4, what jars are mandatory to upgrade along with the Axis2 kernel. That is, I need to axis2 kernel, axiom, stax, woden... anything else? Thanks. -Original Message- From: Martin [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2008 10:55 AM To: axis-dev@ws.apache.org Subject: Re: [axis2-1.4] woden Tony I just downloaded and deployed AXIS2-1.4 and have it running under %AXIS2_HOME%/bin/axis2server.bat (without woden*.jar) Can you display the specific error you are seeing? Also please display the wsdl as I would be interested in seeing the implemented wsdl2 declaration http://www.w3.org/ns/wsdl/ Thanks Martin - Original Message - From: Tony Dean [EMAIL PROTECTED] To: axis-dev@ws.apache.org Sent: Thursday, May 29, 2008 9:53 AM Subject: [axis2-1.4] woden Hi, It appears that the woden distribution is required for axis2 1.4 to work properly. In Axis2 1.3 woden was not required to work properly unless of course you were using wsdl 2.0. Without woden in Axis2 1.4 you can't even bring up the index.jsp page. You get a class not found exception. Can you comment, please? Thanks. Tony Dean SAS Institute Inc. 919.531.6704 [EMAIL PROTECTED] SAS... The Power to Know http://www.sas.com - 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] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [Axis2] Documenting Axis2 1.4 dependencies (Re: [axis2-1.4] woden)
07:04 AM 2,152 version-1.4-sources.jar | 1 File(s) 2,152 bytes | | Total Files Listed: | 60 File(s) 21,587,618 bytes | | this advice from dims | XmlSchema is always needed | woden is completely optional | neethi is always needed | jettison is needed only if you do json | axis2-json is needed only if you do json | axis2-metadata is needed if for jaxws | axis2-fastinfoset is needed only if you try binary xml on the wire | (fastinfoset) | axis2-spring is needed for spring only | jaxen is needed if you want to run xpath on axiom | annogen is needed when we generate wsdl from java dynamically (?wsdl) | | most who have servers dont care about carrying around 60 jars.. | but I can definitely see the need to trim down to run on a laptop or | mobile device | and yes dims comments on what is necessary and now should be in the | readme.txt or RLNotes! | | http://markmail.org/message/fmebppn7adkdvvra#query:%22AXIS2%20Dependency%20List%22+page:1+mid:wec5ht4u7xs4fcou+state:results | | | Thanks Tony | Martin | | - Original Message - From: Tony Dean [EMAIL PROTECTED] | To: axis-dev@ws.apache.org; Martin [EMAIL PROTECTED] | Sent: Thursday, May 29, 2008 2:30 PM | Subject: RE: [axis2-1.4] woden | | | Martin, | | The dependency comes into to play when deploying modules. Here is the | dependency chain that I tracked down in the source. | | org.apache.axis2.deployment.ModuleDeployer (line 60) |org.apache.axis2.deployment.repository.util.ArchiveReader |org.apache.axis2.deployment.resolver.WarBasedWSDLLocator |org.apache.woden.resolver.URIResolver | | There are many more instances of woden dependency. I just listed the | one that fails first for me. | | Are there any other dependencies on Axis2 1.4 that are required that | were not required for Axis2 1.3? | | Also, if I want to upgrade to Axis2 1.4, what jars are mandatory to | upgrade along with the Axis2 kernel. That is, I need to axis2 kernel, | axiom, stax, woden... anything else? | | Thanks. | | | -Original Message- | From: Martin [mailto:[EMAIL PROTECTED] | Sent: Thursday, May 29, 2008 10:55 AM | To: axis-dev@ws.apache.org | Subject: Re: [axis2-1.4] woden | | Tony | | I just downloaded and deployed AXIS2-1.4 and have it running under | %AXIS2_HOME%/bin/axis2server.bat (without woden*.jar) | Can you display the specific error you are seeing? | Also please display the wsdl as I would be interested in seeing the | implemented wsdl2 declaration | http://www.w3.org/ns/wsdl/ | | Thanks | Martin | - Original Message - | From: Tony Dean [EMAIL PROTECTED] | To: axis-dev@ws.apache.org | Sent: Thursday, May 29, 2008 9:53 AM | Subject: [axis2-1.4] woden | | | Hi, | | It appears that the woden distribution is required for axis2 1.4 to | work | properly. In Axis2 1.3 woden was not required to work properly unless | of | course you were using wsdl 2.0. | | Without woden in Axis2 1.4 you can't even bring up the index.jsp page. | You | get a class not found exception. | | Can you comment, please? | | Thanks. | | Tony Dean | SAS Institute Inc. | 919.531.6704 | [EMAIL PROTECTED] | | SAS... The Power to Know | http://www.sas.com | | | | - | 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] | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFIPwj1gNg6eWEDv1kRAgQjAJ9w/cPm0mgjIPbL5ZU/Dmrtk1oHNACgofsS ap23ne4C5Y8LwfSA5Eu9FgE= =WcpM -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- With Mettha, Eran Chinthaka Health is the greatest gift; contentment is the greatest wealth; trusting is the best relationship; nirvana is the highest joy. - Dhammapada -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [Axis2] Generating a wrong port address for POJO deployment
name=VersionHttpSoap11EndpointWithUsernameAndSignature binding=ns:VersionSoap11Binding soap:address location= http://localhost:8080/axis2/services/Version.VersionHttpSoap11EndpointWithUsernameAndSignature / /wsdl:port wsdl:port name=VersionHttpSoap11EndpointWithSAMLAndSignature binding=ns:VersionSoap11Binding soap:address location= http://localhost:8080/axis2/services/Version.VersionHttpSoap11EndpointSAMLAndSignature / /wsdl:port wsdl:port name=VersionHttpSoap11EndpointWithKerberos binding=ns:VersionSoap11Binding soap:address location= http://localhost:8080/axis2/services/Version.VersionHttpSoap11EndpointWithSSLWithKerberos / /wsdl:port . /wsdl:service That way we can straight way say the option client as picked and evaluate the quest based on the target policy alternative with IMO is a better way of supporting multiple policy alternatives at the server-side. We need to use [service].[port] format if we are to implement the support for multiple policy alternatives feature. Thank you so much for such a descriptive mail. I will think though and send a reply soon.. -Deepal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanka Samaranayake WSO2 Inc. http://sankas.blogspot.com/ http://www.wso2.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [Axis2] It is possible to invoke WSDL2.0 described REST Service with a dynamic service client?
Hi Thomas,
You cannot use Service Client to invoke a REST service in a dynamic way at
the moment. May be a festure we can work on for the next release. But you
can use WSDL2Java to generate a stub and invoke your service in a RESTfull
manner though.
Thanks,
Keith.
On Fri, May 9, 2008 at 7:26 PM, Thomas Fischer [EMAIL PROTECTED]
wrote:
Hello,
I hope you can help me. I have a set of REST services described with WSDL
2.0. It is possible to invoke this service based on the WSDL 2.0 file with
an Axis2 serviceclient in a dynamic way?
I get the following error:
org.apache.axis2.AxisFault: WSDLException (at /description):
faultCode=INVALID_WSDL: Expected element '{
http://schemas.xmlsoap.org/wsdl/}definitionshttp://schemas.xmlsoap.org/wsdl/%7Ddefinitions
'.
This seems to me that axis2 doesn't support WSDL 2.0, or? This confuses me,
because I've read that axis2 supports WSDL2.0? (
http://www.ibm.com/developerworks/webservices/library/ws-apacheaxis2/)
It would be really great I've someone could answer me if it is possible to
invoke a REST service with WSDL 2.0 description in Axis2.
Thanks!
Regards,
Thomas
--
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://www.keith-chapman.org
Re: [Axis2] Generating a wrong port address for POJO deployment
Hi Dims, I agree with Sanka that this would not effect any existing code. For e.g if I can a service called foo it does not really matter if I send a request to http://localhost:8080/axis2/services/foo or http://localhost:8080/axis2/services/foo.SOAP11Endpoint. Both should work. The latter gibes you the option of applying binding level security as we are able to dispatch to the endpoint directly. Thanks, Keith. On Fri, May 9, 2008 at 3:56 PM, Davanum Srinivas [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sanka, #1: I specifically requested in that thread that existing code should work as-is. With this change it did not. Specifically if one had existing clients in another language, they needed to be updated with a fresh endpoint since the same service when deployed in Axis2 1.4 showed up at a different URL. #2: Because of this change, we had to jump through hoops to pass the TCK. because the user specified a service name in the annotation and that is *NOT* where the service endpoint shows up. Thanks, dims Sanka Samaranayake wrote: | Hi, | | We discussed about that in a mailing thread[1] sometime back. Why do you | think we should change that? IMO it is desirable to have [service].[port] in | the service address since it makes valuable binding information available | for request processing at service side. | | Sanka | | | [1] http://www.mail-archive.com/axis-dev@ws.apache.org/msg40047.html | | On Fri, May 9, 2008 at 11:49 AM, Deepal jayasinghe [EMAIL PROTECTED] | wrote: | | Hi Sanka and all, | | | When I deploy a very simple POJO service it generates following as the | service section in WSDL. As I know this is not nice and we need to fix this | as soon as possible. It is not good to have | SampleService.SampleServiceHttpSoap12Endpoint as the service address. We | did not agree anywhere about this structure. I even created a JIRA [1] | | wsdl:service name=SampleService | wsdl:port name=SampleServiceHttpSoap11Endpoint | binding=ns:SampleServiceSoap11Binding | soap:address location= | http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpSoap11Endpoint | / | /wsdl:port | | wsdl:port name=SampleServiceHttpSoap12Endpoint | binding=ns:SampleServiceSoap12Bindingsoap12:address location=* | http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpSoap12Endpoint* //wsdl:portwsdl:port | name=SampleServiceHttpEndpoint | binding=ns:SampleServiceHttpBindinghttp:address location= | http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpEndpoint | //wsdl:port/wsdl:service | | [1] : https://issues.apache.org/jira/browse/AXIS2-3794 | | Thanks | Deepal | | - | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | | | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFIJCbMgNg6eWEDv1kRAqryAJ9FbcaKrjGjnG1P1cn2FJvcqgxz7gCgk7YE png0xVXknFFHpQK29Ij1ZU0= =cTor -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [Axis2] Generating a wrong port address for POJO deployment
Hi Deepal, See comments inline On Fri, May 9, 2008 at 11:49 AM, Deepal jayasinghe [EMAIL PROTECTED] wrote: Hi Sanka and all, When I deploy a very simple POJO service it generates following as the service section in WSDL. As I know this is not nice and we need to fix this as soon as possible. Why is it not nice? This gives us the ability to apply binding level security correctly which is not possible with the endpoint addresses we used to have. It is not good to have SampleService.SampleServiceHttpSoap12Endpoint as the service address. Y? I dont see any reason y its not good. We did not agree anywhere about this structure. As Sanka has pointed out this has been discussed in the List. Nobody had any objections to it. The only concern was not to break existing code. Thanks, Keith. I even created a JIRA [1] wsdl:service name=SampleService wsdl:port name=SampleServiceHttpSoap11Endpoint binding=ns:SampleServiceSoap11Binding soap:address location= http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpSoap11Endpoint / /wsdl:port wsdl:port name=SampleServiceHttpSoap12Endpoint binding=ns:SampleServiceSoap12Bindingsoap12:address location=* http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpSoap12Endpoint*//wsdl:portwsdl:port name=SampleServiceHttpEndpoint binding=ns:SampleServiceHttpBindinghttp:address location= http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpEndpoint //wsdl:port/wsdl:service [1] : https://issues.apache.org/jira/browse/AXIS2-3794 Thanks Deepal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [Axis2] where to get Axiom-1.2.7 src version
Hi Stefan, You can get a svn checkout of the 1.2.7 tag from http://svn.apache.org/repos/asf/webservices/commons/tags/axiom/1.2.7/ Thanks, Keith. On Wed, May 7, 2008 at 10:44 PM, Stefan Lischke [EMAIL PROTECTED] wrote: Hi, I need the src version of the axiom-1.2.7 that is delivered with axis2-1.4 for debugging purpose, but the axiom download area does only offer 1.2.6 thanx in advance Stefan -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: WSDL / void POJO functions (patch included)
Hi Felix,
Would be better if you can create a Jira and attach the patch. Jira makes it
easier to keep track of changes.
Thanks,
Keith.
On Tue, May 6, 2008 at 7:57 PM, Felix J. Ogris [EMAIL PROTECTED] wrote:
Hi,
I had some issues with Axis2 1.4 and MS Visual Studio when using POJO
functions without any parameters, eg.:
public String getSomething() {
...
}
From the WSDL, VS generated a prototype for getSomething() that returns an
instance of getSomethingResponse instead of a String. getSomethingResponse
contained one member variable, a String called return. It turned out that
VS
needs an empty input element in the WSDL, eg.:
xs:element name=getSomething
xs:complexType
xs:sequence/
/xs:complexType
/xs:element
My patch applies to
modules/kernel/src/org/apache/axis2/description/java2wsdl/DefaultSchemaGener
ator.java. It does nothing more than removing the check whether
paras.length
is greater than zero in processMethods().
Regards,
Felix
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://www.keith-chapman.org
Re: WSDL / minOccurs (patch included)
Hi Felix, Same again :). Would be better if you can create a Jira and attach the patch. Jira makes it easier to keep track of changes. Thanks, Keith. On Tue, May 6, 2008 at 7:46 PM, Felix J. Ogris [EMAIL PROTECTED] wrote: Sorry, I forgot the diff file :-( Felix - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: Estimated Complexity field in Jira
+1, Suran did bring this idea up some time ago too. If a Jira admin can add these fields I can volunteer to go through some Jiras and assign Estimated Complexities. Thanks, Keith. On Wed, May 7, 2008 at 8:00 AM, Samisa Abeysinghe [EMAIL PROTECTED] wrote: I find that we have a field called Estimated Complexity in our Jira. I propose that we use this field to mark issues to help people pick what to fix based on their expertise. Specially helps with new contributions. I find that the Harmony project is using this. The possible values are: * Unknown * Novice * Moderate * Advanced * Guru * Needs James Gosling I know we traverse through Jiras before a release to pick what to be fixed. We may take a moment to mark this field as well. Thoughts please... Samisa... -- Samisa Abeysinghe http://people.apache.org/~samisa/ http://people.apache.org/%7Esamisa/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [Axis2][VOTE] Axis2 1.4 FINAL
/tools/1_4http://people.apache.org/%7Edims/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) iD8DBQFIEpJWgNg6eWEDv1kRAgi8AKCF/ekND9ViXZDNorhlvyJ8ihK1+gCg0zE3 twU4iTqkxQzeS+DxuTklmO4= =JjHq -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [Axis2][VOTE] Axis2 1.4 FINAL
+1 Thanks, Keith. On Thu, Apr 24, 2008 at 10:09 PM, Davanum Srinivas [EMAIL PROTECTED] 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/http://people.apache.org/%7Edims/axis2-1.4/FINAL/dist/ The m2 repository is here: http://people.apache.org/~dims/axis2-1.4/FINAL/m2-repo/http://people.apache.org/%7Edims/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.ziphttp://people.apache.org/%7Edims/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.ziphttp://people.apache.org/%7Edims/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.ziphttp://people.apache.org/%7Edims/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.ziphttp://people.apache.org/%7Edims/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.marhttp://people.apache.org/%7Edims/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.marhttp://people.apache.org/%7Edims/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.jarhttp://people.apache.org/%7Edims/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.jarhttp://people.apache.org/%7Edims/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.ziphttp://people.apache.org/%7Edims/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.ziphttp://people.apache.org/%7Edims/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.ziphttp://people.apache.org/%7Edims/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.jarhttp://people.apache.org/%7Edims/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.jarhttp://people.apache.org/%7Edims/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.jarhttp://people.apache.org/%7Edims/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] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: Mex jar missing in maven repo
Thanks Dims. That did the trick.
Thanks,
Keith.
On Mon, Apr 21, 2008 at 6:30 AM, Davanum Srinivas [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Try this...(note the classifier)
~dependency
~groupIdorg.apache.axis2/groupId
~artifactIdmex/artifactId
~version${version}/version
~typejar/type
~classifierimpl/classifier
~/dependency
Keith wrote:
| Hi all,
|
| The axis2 mex jar is missing in the maven repo although the mex mar is
| available. The mex jar is missing since 5th April at
|
http://people.apache.org/repo/m2-snapshot-repository/org/apache/axis2/mex/SNAPSHOT/
| Any clue as to why this jar is missing?
|
| Thanks,
| Keith.
|
| Keith Chapman
| Senior Software Engineer
| WSO2 Inc.
| Oxygenating the Web Service Platform.
| http://wso2.org/
|
| blog: http://www.keith-chapman.org
|
| -
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
|
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
iD8DBQFIC+cygNg6eWEDv1kRAsRPAKC/cD3i/z87SEF+kjqFqJRk6rPFxwCfZJSl
FWR8j5XoWos3Df+hr+/5JP4=
=9Zqo
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://www.keith-chapman.org
[AXIS2] SOAP Action is not set by service Client when its invoked via a WSDL
Hi devs,
I was trying accessing an external webservice using service client as
follows,
ServiceClient serviceClient = new ServiceClient(null, new URL(
http://www.webservicex.net/CurrencyConvertor.asmx?wsdl;), new QName(
http://www.webserviceX.NET/,CurrencyConvertor;), CurrencyConvertorSoap);
StAXOMBuilder stAXOMBuilder = new StAXOMBuilder(new
ByteArrayInputStream(
ConversionRateFromCurrencyUSD/FromCurrencyToCurrencyLKR/ToCurrency/ConversionRate.getBytes()));
OMElement omElement = serviceClient.sendReceive(
new QName(http://www.webserviceX.NET/;, ConversionRate),
stAXOMBuilder.getDocumentElement());
System.out.println(omElement.toString());
But this call was failing with the exception
System.Web.Services.Protocols.SoapException: Server did not recognize the
value of HTTP Header SOAPAction: .
The request sent by the client had the header SOAPAction: whereas the
WSDL had soap:operation soapAction=
http://www.webserviceX.NET/ConversionRate; style=document/
debugging through I noticed the following lines in
WSDL11ToAxisServiceBuilder (Line 2340)
if (isServerSide) {
axisBindingOperation.getAxisOperation().setSoapAction(soapActionURI);
}
else {
axisBindingOperation.getAxisOperation().setOutputAction(soapActionURI);
}
and CommonsHTTPTransportSender has the following in line 200
soapActionString = messageContext.getAxisOperation()
.getSoapAction();
Now this looks like a bug to me. Does anybody have a clue as to why we dont
set the soapAction on the axisoperation when the axisService is on the
client side?
Thanks,
Keith.
--
Keith Chapman
Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://www.keith-chapman.org
Re: WSDL 2.0 codegeration fails due to Woden assertion
Lawrence,
Its working fine now.
Thanks,
Keith.
On Wed, Apr 2, 2008 at 8:30 PM, Lawrence Mandel [EMAIL PROTECTED] wrote:
Keith,
Thanks. I see what happened. I committed the changes to branch woden62,
where we'd been working on the new validation infrastructure, but did not
merge the changes into trunk. My mistake. Sorry about the churn.
Everything should be ready to go now.
Lawrence
keith chapman [EMAIL PROTECTED]
04/01/2008 10:03 PM
Please respond to
axis-dev@ws.apache.org
To
axis-dev@ws.apache.org
cc
[EMAIL PROTECTED]
Subject
Re: WSDL 2.0 codegeration fails due to Woden assertion
Hi Lawrence,
Here is the code that is used to read a WSDL.
private Description readInTheWSDLFile(String wsdlURI) throws WSDLException
{
DocumentBuilderFactory documentBuilderFactory =
DocumentBuilderFactory
.newInstance();
documentBuilderFactory.setNamespaceAware(true);
DocumentBuilder documentBuilder;
Document document = null;
try {
documentBuilder = documentBuilderFactory.newDocumentBuilder();
document = documentBuilder.parse(wsdlURI);
} catch (ParserConfigurationException e) {
AxisFault.makeFault(e);
} catch (IOException e) {
AxisFault.makeFault(e);
} catch (SAXException e) {
AxisFault.makeFault(e);
}
return readInTheWSDLFile(document);
}
private Description readInTheWSDLFile(InputStream inputStream) throws
WSDLException {
DocumentBuilderFactory documentBuilderFactory =
DocumentBuilderFactory
.newInstance();
documentBuilderFactory.setNamespaceAware(true);
DocumentBuilder documentBuilder;
Document document = null;
try {
documentBuilder = documentBuilderFactory.newDocumentBuilder();
document = documentBuilder.parse(inputStream);
} catch (ParserConfigurationException e) {
AxisFault.makeFault(e);
} catch (IOException e) {
AxisFault.makeFault(e);
} catch (SAXException e) {
AxisFault.makeFault(e);
}
return readInTheWSDLFile(document);
}
private Description readInTheWSDLFile(Document document) throws
WSDLException {
WSDLReader reader = DOMWSDLFactory.newInstance().newWSDLReader();
if (customWSDLResolver != null) {
reader.setURIResolver(customWSDLResolver);
}
// This turns on WSDL validation which is set off by default.
reader.setFeature(WSDLReader.FEATURE_VALIDATION, false);
WSDLSource wsdlSource = reader.createWSDLSource();
wsdlSource.setSource(document.getDocumentElement());
if (getBaseUri() != null !.equals(getBaseUri())) {
try {
wsdlSource.setBaseURI(new URI(getBaseUri()));
} catch (URISyntaxException e) {
AxisFault.makeFault(e);
}
}
if (log.isDebugEnabled()) {
log.debug(Reading 2.0 WSDL with wsdl uri = + wsdlURI);
log.debug( the stack at this point is: + stackToString());
}
return reader.readWSDL(wsdlSource);
}
With validation set to true it fails. It works fine if I set it to false.
Thanks,
Keith.
On Wed, Apr 2, 2008 at 12:20 AM, Lawrence Mandel [EMAIL PROTECTED]
wrote:
Hi Keith,
Can you pass along the code that instantiates a Woden reader and reads a
WSDL file? I want to make sure I'm performing the same steps as you
because I'm not seeing this failure.
Thanks,
Lawrence
keith chapman [EMAIL PROTECTED]
04/01/2008 09:56 AM
Please respond to
axis-dev@ws.apache.org
To
axis-dev@ws.apache.org
cc
[EMAIL PROTECTED]
Subject
Re: WSDL 2.0 codegeration fails due to Woden assertion
Hi Lawrence,
I found the problem after some investigation. The problem was that I have
set
reader.setFeature(WSDLReader.FEATURE_VALIDATION, true);
Is it possible to perform validation while continuing on error. I tried
setting
reader.setFeature(WSDLReader.FEATURE_VALIDATION, true);
reader.setFeature(WSDLReader.FEATURE_CONTINUE_ON_ERROR, true);
but then I got the following error
Caused by: java.lang.IllegalArgumentException: The feature name
http://ws.apache.org/woden/features/continue_on_error; is not recognized.
Thanks,
Keith.
On Tue, Apr 1, 2008 at 10:20 AM, Lawrence Mandel [EMAIL PROTECTED]
wrote:
Hi Keith,
What failure are you experiencing and what are you expecting? I tested the
target namespace http://services.mashup.wso2.org/version and Woden does
not produce an exception. Woden does report a warning but this is the
expected behaviour.
Lawrence
keith chapman [EMAIL PROTECTED]
03/31/2008 10:20 PM
Please respond to
axis-dev@ws.apache.org
To
[EMAIL PROTECTED], axis-dev@ws.apache.org
cc
Subject
Re: WSDL 2.0 codegeration fails due to Woden assertion
Hi Lawrence,
I took an update of woden
Re: WSDL 2.0 codegeration fails due to Woden assertion
Hi Lawrence, I found the problem after some investigation. The problem was that I have set reader.setFeature(WSDLReader.FEATURE_VALIDATION, true); Is it possible to perform validation while continuing on error. I tried setting reader.setFeature(WSDLReader.FEATURE_VALIDATION, true); reader.setFeature(WSDLReader.FEATURE_CONTINUE_ON_ERROR, true); but then I got the following error Caused by: java.lang.IllegalArgumentException: The feature name http://ws.apache.org/woden/features/continue_on_error; is not recognized. Thanks, Keith. On Tue, Apr 1, 2008 at 10:20 AM, Lawrence Mandel [EMAIL PROTECTED] wrote: Hi Keith, What failure are you experiencing and what are you expecting? I tested the target namespace http://services.mashup.wso2.org/version and Woden does not produce an exception. Woden does report a warning but this is the expected behaviour. Lawrence keith chapman [EMAIL PROTECTED] 03/31/2008 10:20 PM Please respond to axis-dev@ws.apache.org To [EMAIL PROTECTED], axis-dev@ws.apache.org cc Subject Re: WSDL 2.0 codegeration fails due to Woden assertion Hi Lawrence, I took an update of woden, build it localy and tested with axis2 and the issue still prevails. I tested it for other WSDLs too, it fails for http://mooshup.com/services/system/version?wsdl2 as well. Here the targetNamespace is http://services.mashup.wso2.org/version Thanks, Keith. On Sun, Mar 30, 2008 at 12:15 AM, Lawrence Mandel [EMAIL PROTECTED] wrote: Fixed. Lawrence keith chapman [EMAIL PROTECTED] 03/27/2008 11:50 AM Please respond to axis-dev@ws.apache.org To [EMAIL PROTECTED] cc axis-dev@ws.apache.org Subject Re: WSDL 2.0 codegeration fails due to Woden assertion Thanks for looking into it Lawrence. I created a jira issue. https://issues.apache.org/jira/browse/WODEN-203 Thanks, Keith. On Thu, Mar 27, 2008 at 8:28 PM, Lawrence Mandel [EMAIL PROTECTED] wrote: Hi Keith, Description1001 should report a warning in this case. Looks like we'll have to dig into this ASAP. Can you please open a Jira and include any other relevant environmental factors such as OS, connectivity, and JRE provider and version? Thanks, Lawrence keith chapman [EMAIL PROTECTED] 03/27/2008 07:31 AM Please respond to [EMAIL PROTECTED] To [EMAIL PROTECTED], axis-dev@ws.apache.org cc Subject WSDL 2.0 codegeration fails due to Woden assertion Hi Devs, We are having a bit of a problem in Axis2 (codegeration) due to an assertion woden has made. I have attached the wsdl2 of the version service hearwith. As you will note the target namespace of the wsdl is http://axisversion.sample and woden tries to resolve this and failes cause its not a resource that exist. The complete stack trace is given below Exception in thread main org.apache.axis2.wsdl.codegen.CodeGenerationException: Error parsing WSDL at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.init( CodeGenerationEngine.java:159) at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:35) at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:24) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java :39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90) Caused by: WSDLException: faultCode=OTHER_ERROR: Fatal error.: axisversion.sample: java.net.UnknownHostException: axisversion.sample at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177) at java.net.Socket.connect(Socket.java:507) at java.net.Socket.connect(Socket.java:457) at sun.net.NetworkClient.doConnect(NetworkClient.java:157) at sun.net.www.http.HttpClient.openServer(HttpClient.java:365) at sun.net.www.http.HttpClient.openServer(HttpClient.java:477) at sun.net.www.http.HttpClient.init(HttpClient.java:214) at sun.net.www.http.HttpClient.New(HttpClient.java:287) at sun.net.www.http.HttpClient.New(HttpClient.java:299) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient( HttpURLConnection.java:792) at sun.net.www.protocol.http.HttpURLConnection.plainConnect( HttpURLConnection.java:744) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java :669) at sun.net.www.protocol.http.HttpURLConnection.getInputStream( HttpURLConnection.java:913) at java.net.URLConnection.getContent(URLConnection.java:682) at java.net.URL.getContent(URL.java:1021) at org.apache.woden.internal.wsdl20.assertions.Description1001.validate( Description1001.java:28) at org.apache.woden.internal.wsdl20.validation.WSDLValidator.checkAssertions( WSDLValidator.java:109) at org.apache.woden.internal.wsdl20.validation.WSDLValidator.validate( WSDLValidator.java:77) at org.apache.woden.internal.DOMWSDLReader.readWSDL
Re: WSDL 2.0 codegeration fails due to Woden assertion
Hi Lawrence,
Here is the code that is used to read a WSDL.
private Description readInTheWSDLFile(String wsdlURI) throws WSDLException {
DocumentBuilderFactory documentBuilderFactory =
DocumentBuilderFactory
.newInstance();
documentBuilderFactory.setNamespaceAware(true);
DocumentBuilder documentBuilder;
Document document = null;
try {
documentBuilder = documentBuilderFactory.newDocumentBuilder();
document = documentBuilder.parse(wsdlURI);
} catch (ParserConfigurationException e) {
AxisFault.makeFault(e);
} catch (IOException e) {
AxisFault.makeFault(e);
} catch (SAXException e) {
AxisFault.makeFault(e);
}
return readInTheWSDLFile(document);
}
private Description readInTheWSDLFile(InputStream inputStream) throws
WSDLException {
DocumentBuilderFactory documentBuilderFactory =
DocumentBuilderFactory
.newInstance();
documentBuilderFactory.setNamespaceAware(true);
DocumentBuilder documentBuilder;
Document document = null;
try {
documentBuilder = documentBuilderFactory.newDocumentBuilder();
document = documentBuilder.parse(inputStream);
} catch (ParserConfigurationException e) {
AxisFault.makeFault(e);
} catch (IOException e) {
AxisFault.makeFault(e);
} catch (SAXException e) {
AxisFault.makeFault(e);
}
return readInTheWSDLFile(document);
}
private Description readInTheWSDLFile(Document document) throws
WSDLException {
WSDLReader reader = DOMWSDLFactory.newInstance().newWSDLReader();
if (customWSDLResolver != null) {
reader.setURIResolver(customWSDLResolver);
}
// This turns on WSDL validation which is set off by default.
reader.setFeature(WSDLReader.FEATURE_VALIDATION, false);
WSDLSource wsdlSource = reader.createWSDLSource();
wsdlSource.setSource(document.getDocumentElement());
if (getBaseUri() != null !.equals(getBaseUri())) {
try {
wsdlSource.setBaseURI(new URI(getBaseUri()));
} catch (URISyntaxException e) {
AxisFault.makeFault(e);
}
}
if (log.isDebugEnabled()) {
log.debug(Reading 2.0 WSDL with wsdl uri = + wsdlURI);
log.debug( the stack at this point is: + stackToString());
}
return reader.readWSDL(wsdlSource);
}
With validation set to true it fails. It works fine if I set it to false.
Thanks,
Keith.
On Wed, Apr 2, 2008 at 12:20 AM, Lawrence Mandel [EMAIL PROTECTED] wrote:
Hi Keith,
Can you pass along the code that instantiates a Woden reader and reads a
WSDL file? I want to make sure I'm performing the same steps as you
because I'm not seeing this failure.
Thanks,
Lawrence
keith chapman [EMAIL PROTECTED]
04/01/2008 09:56 AM
Please respond to
axis-dev@ws.apache.org
To
axis-dev@ws.apache.org
cc
[EMAIL PROTECTED]
Subject
Re: WSDL 2.0 codegeration fails due to Woden assertion
Hi Lawrence,
I found the problem after some investigation. The problem was that I have
set
reader.setFeature(WSDLReader.FEATURE_VALIDATION, true);
Is it possible to perform validation while continuing on error. I tried
setting
reader.setFeature(WSDLReader.FEATURE_VALIDATION, true);
reader.setFeature(WSDLReader.FEATURE_CONTINUE_ON_ERROR, true);
but then I got the following error
Caused by: java.lang.IllegalArgumentException: The feature name
http://ws.apache.org/woden/features/continue_on_error; is not recognized.
Thanks,
Keith.
On Tue, Apr 1, 2008 at 10:20 AM, Lawrence Mandel [EMAIL PROTECTED]
wrote:
Hi Keith,
What failure are you experiencing and what are you expecting? I tested the
target namespace http://services.mashup.wso2.org/version and Woden does
not produce an exception. Woden does report a warning but this is the
expected behaviour.
Lawrence
keith chapman [EMAIL PROTECTED]
03/31/2008 10:20 PM
Please respond to
axis-dev@ws.apache.org
To
[EMAIL PROTECTED], axis-dev@ws.apache.org
cc
Subject
Re: WSDL 2.0 codegeration fails due to Woden assertion
Hi Lawrence,
I took an update of woden, build it localy and tested with axis2 and the
issue still prevails. I tested it for other WSDLs too, it fails for
http://mooshup.com/services/system/version?wsdl2 as well. Here the
targetNamespace is http://services.mashup.wso2.org/version
Thanks,
Keith.
On Sun, Mar 30, 2008 at 12:15 AM, Lawrence Mandel [EMAIL PROTECTED]
wrote:
Fixed.
Lawrence
keith chapman [EMAIL PROTECTED]
03/27/2008 11:50 AM
Please respond to
axis-dev@ws.apache.org
To
[EMAIL PROTECTED]
cc
axis-dev@ws.apache.org
Subject
Re: WSDL 2.0 codegeration fails due to Woden assertion
Thanks for looking into it Lawrence. I created
Re: WSDL 2.0 codegeration fails due to Woden assertion
Hi Lawrence, I took an update of woden, build it localy and tested with axis2 and the issue still prevails. I tested it for other WSDLs too, it fails for http://mooshup.com/services/system/version?wsdl2 as well. Here the targetNamespace is http://services.mashup.wso2.org/version Thanks, Keith. On Sun, Mar 30, 2008 at 12:15 AM, Lawrence Mandel [EMAIL PROTECTED] wrote: Fixed. Lawrence keith chapman [EMAIL PROTECTED] 03/27/2008 11:50 AM Please respond to axis-dev@ws.apache.org To [EMAIL PROTECTED] cc axis-dev@ws.apache.org Subject Re: WSDL 2.0 codegeration fails due to Woden assertion Thanks for looking into it Lawrence. I created a jira issue. https://issues.apache.org/jira/browse/WODEN-203 Thanks, Keith. On Thu, Mar 27, 2008 at 8:28 PM, Lawrence Mandel [EMAIL PROTECTED] wrote: Hi Keith, Description1001 should report a warning in this case. Looks like we'll have to dig into this ASAP. Can you please open a Jira and include any other relevant environmental factors such as OS, connectivity, and JRE provider and version? Thanks, Lawrence keith chapman [EMAIL PROTECTED] 03/27/2008 07:31 AM Please respond to [EMAIL PROTECTED] To [EMAIL PROTECTED], axis-dev@ws.apache.org cc Subject WSDL 2.0 codegeration fails due to Woden assertion Hi Devs, We are having a bit of a problem in Axis2 (codegeration) due to an assertion woden has made. I have attached the wsdl2 of the version service hearwith. As you will note the target namespace of the wsdl is http://axisversion.sample and woden tries to resolve this and failes cause its not a resource that exist. The complete stack trace is given below Exception in thread main org.apache.axis2.wsdl.codegen.CodeGenerationException: Error parsing WSDL at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.init( CodeGenerationEngine.java:159) at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:35) at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:24) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java :39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90) Caused by: WSDLException: faultCode=OTHER_ERROR: Fatal error.: axisversion.sample: java.net.UnknownHostException: axisversion.sample at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177) at java.net.Socket.connect(Socket.java:507) at java.net.Socket.connect(Socket.java:457) at sun.net.NetworkClient.doConnect(NetworkClient.java:157) at sun.net.www.http.HttpClient.openServer(HttpClient.java:365) at sun.net.www.http.HttpClient.openServer(HttpClient.java:477) at sun.net.www.http.HttpClient.init(HttpClient.java:214) at sun.net.www.http.HttpClient.New(HttpClient.java:287) at sun.net.www.http.HttpClient.New(HttpClient.java:299) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient( HttpURLConnection.java:792) at sun.net.www.protocol.http.HttpURLConnection.plainConnect( HttpURLConnection.java:744) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java :669) at sun.net.www.protocol.http.HttpURLConnection.getInputStream( HttpURLConnection.java:913) at java.net.URLConnection.getContent(URLConnection.java:682) at java.net.URL.getContent(URL.java:1021) at org.apache.woden.internal.wsdl20.assertions.Description1001.validate( Description1001.java:28) at org.apache.woden.internal.wsdl20.validation.WSDLValidator.checkAssertions( WSDLValidator.java:109) at org.apache.woden.internal.wsdl20.validation.WSDLValidator.validate( WSDLValidator.java:77) at org.apache.woden.internal.DOMWSDLReader.readWSDL(DOMWSDLReader.java:207) at org.apache.woden.internal.DOMWSDLReader.readWSDL(DOMWSDLReader.java:233) at org.apache.woden.internal.DOMWSDLReader.readWSDL(DOMWSDLReader.java:268) at org.apache.woden.internal.DOMWSDLReader.readWSDL(DOMWSDLReader.java:127) at org.apache.axis2.description.WSDL20ToAxisServiceBuilder.readInTheWSDLFile( WSDL20ToAxisServiceBuilder.java:1181) at org.apache.axis2.description.WSDL20ToAxisServiceBuilder.init( WSDL20ToAxisServiceBuilder.java:151) at org.apache.axis2.description.WSDL20ToAllAxisServicesBuilder.init( WSDL20ToAllAxisServicesBuilder.java:53) at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.init( CodeGenerationEngine.java:102) at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:35) at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:24) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java :39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25
WSDL 2.0 codegeration fails due to Woden assertion
Hi Devs, We are having a bit of a problem in Axis2 (codegeration) due to an assertion woden has made. I have attached the wsdl2 of the version service hearwith. As you will note the target namespace of the wsdl is http://axisversion.sample and woden tries to resolve this and failes cause its not a resource that exist. The complete stack trace is given below Exception in thread main org.apache.axis2.wsdl.codegen.CodeGenerationException: Error parsing WSDL at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.init( CodeGenerationEngine.java:159) at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:35) at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:24) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90) Caused by: WSDLException: faultCode=OTHER_ERROR: Fatal error.: axisversion.sample: java.net.UnknownHostException: axisversion.sample at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177) at java.net.Socket.connect(Socket.java:507) at java.net.Socket.connect(Socket.java:457) at sun.net.NetworkClient.doConnect(NetworkClient.java:157) at sun.net.www.http.HttpClient.openServer(HttpClient.java:365) at sun.net.www.http.HttpClient.openServer(HttpClient.java:477) at sun.net.www.http.HttpClient.init(HttpClient.java:214) at sun.net.www.http.HttpClient.New(HttpClient.java:287) at sun.net.www.http.HttpClient.New(HttpClient.java:299) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient( HttpURLConnection.java:792) at sun.net.www.protocol.http.HttpURLConnection.plainConnect( HttpURLConnection.java:744) at sun.net.www.protocol.http.HttpURLConnection.connect( HttpURLConnection.java:669) at sun.net.www.protocol.http.HttpURLConnection.getInputStream( HttpURLConnection.java:913) at java.net.URLConnection.getContent(URLConnection.java:682) at java.net.URL.getContent(URL.java:1021) at org.apache.woden.internal.wsdl20.assertions.Description1001.validate( Description1001.java:28) at org.apache.woden.internal.wsdl20.validation.WSDLValidator.checkAssertions( WSDLValidator.java:109) at org.apache.woden.internal.wsdl20.validation.WSDLValidator.validate( WSDLValidator.java:77) at org.apache.woden.internal.DOMWSDLReader.readWSDL(DOMWSDLReader.java :207) at org.apache.woden.internal.DOMWSDLReader.readWSDL(DOMWSDLReader.java :233) at org.apache.woden.internal.DOMWSDLReader.readWSDL(DOMWSDLReader.java :268) at org.apache.woden.internal.DOMWSDLReader.readWSDL(DOMWSDLReader.java :127) at org.apache.axis2.description.WSDL20ToAxisServiceBuilder.readInTheWSDLFile( WSDL20ToAxisServiceBuilder.java:1181) at org.apache.axis2.description.WSDL20ToAxisServiceBuilder.init( WSDL20ToAxisServiceBuilder.java:151) at org.apache.axis2.description.WSDL20ToAllAxisServicesBuilder.init( WSDL20ToAllAxisServicesBuilder.java:53) at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.init( CodeGenerationEngine.java:102) at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:35) at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:24) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90) at org.apache.woden.internal.wsdl20.assertions.Description1001.validate( Description1001.java:42) at org.apache.woden.internal.wsdl20.validation.WSDLValidator.checkAssertions( WSDLValidator.java:109) at org.apache.woden.internal.wsdl20.validation.WSDLValidator.validate( WSDLValidator.java:77) at org.apache.woden.internal.DOMWSDLReader.readWSDL(DOMWSDLReader.java :207) at org.apache.woden.internal.DOMWSDLReader.readWSDL(DOMWSDLReader.java :233) at org.apache.woden.internal.DOMWSDLReader.readWSDL(DOMWSDLReader.java :268) at org.apache.woden.internal.DOMWSDLReader.readWSDL(DOMWSDLReader.java :127) at org.apache.axis2.description.WSDL20ToAxisServiceBuilder.readInTheWSDLFile( WSDL20ToAxisServiceBuilder.java:1181) at org.apache.axis2.description.WSDL20ToAxisServiceBuilder.init( WSDL20ToAxisServiceBuilder.java:151) at org.apache.axis2.description.WSDL20ToAllAxisServicesBuilder.init( WSDL20ToAllAxisServicesBuilder.java:53) at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.init( CodeGenerationEngine.java:102) ... 7 more Thanks, Keith. -- Keith Chapman Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http
Re: WSDL 2.0 codegeration fails due to Woden assertion
Thanks for looking into it Lawrence. I created a jira issue. https://issues.apache.org/jira/browse/WODEN-203 Thanks, Keith. On Thu, Mar 27, 2008 at 8:28 PM, Lawrence Mandel [EMAIL PROTECTED] wrote: Hi Keith, Description1001 should report a warning in this case. Looks like we'll have to dig into this ASAP. Can you please open a Jira and include any other relevant environmental factors such as OS, connectivity, and JRE provider and version? Thanks, Lawrence keith chapman [EMAIL PROTECTED] 03/27/2008 07:31 AM Please respond to [EMAIL PROTECTED] To [EMAIL PROTECTED], axis-dev@ws.apache.org cc Subject WSDL 2.0 codegeration fails due to Woden assertion Hi Devs, We are having a bit of a problem in Axis2 (codegeration) due to an assertion woden has made. I have attached the wsdl2 of the version service hearwith. As you will note the target namespace of the wsdl is http://axisversion.sample and woden tries to resolve this and failes cause its not a resource that exist. The complete stack trace is given below Exception in thread main org.apache.axis2.wsdl.codegen.CodeGenerationException: Error parsing WSDL at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.init( CodeGenerationEngine.java:159) at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:35) at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:24) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java :39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90) Caused by: WSDLException: faultCode=OTHER_ERROR: Fatal error.: axisversion.sample: java.net.UnknownHostException: axisversion.sample at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177) at java.net.Socket.connect(Socket.java:507) at java.net.Socket.connect(Socket.java:457) at sun.net.NetworkClient.doConnect(NetworkClient.java:157) at sun.net.www.http.HttpClient.openServer(HttpClient.java:365) at sun.net.www.http.HttpClient.openServer(HttpClient.java:477) at sun.net.www.http.HttpClient.init(HttpClient.java:214) at sun.net.www.http.HttpClient.New(HttpClient.java:287) at sun.net.www.http.HttpClient.New(HttpClient.java:299) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient( HttpURLConnection.java:792) at sun.net.www.protocol.http.HttpURLConnection.plainConnect( HttpURLConnection.java:744) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java :669) at sun.net.www.protocol.http.HttpURLConnection.getInputStream( HttpURLConnection.java:913) at java.net.URLConnection.getContent(URLConnection.java:682) at java.net.URL.getContent(URL.java:1021) at org.apache.woden.internal.wsdl20.assertions.Description1001.validate( Description1001.java:28) at org.apache.woden.internal.wsdl20.validation.WSDLValidator.checkAssertions( WSDLValidator.java:109) at org.apache.woden.internal.wsdl20.validation.WSDLValidator.validate( WSDLValidator.java:77) at org.apache.woden.internal.DOMWSDLReader.readWSDL(DOMWSDLReader.java:207) at org.apache.woden.internal.DOMWSDLReader.readWSDL(DOMWSDLReader.java:233) at org.apache.woden.internal.DOMWSDLReader.readWSDL(DOMWSDLReader.java:268) at org.apache.woden.internal.DOMWSDLReader.readWSDL(DOMWSDLReader.java:127) at org.apache.axis2.description.WSDL20ToAxisServiceBuilder.readInTheWSDLFile( WSDL20ToAxisServiceBuilder.java:1181) at org.apache.axis2.description.WSDL20ToAxisServiceBuilder.init( WSDL20ToAxisServiceBuilder.java:151) at org.apache.axis2.description.WSDL20ToAllAxisServicesBuilder.init( WSDL20ToAllAxisServicesBuilder.java:53) at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.init( CodeGenerationEngine.java:102) at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:35) at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:24) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java :39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90) at org.apache.woden.internal.wsdl20.assertions.Description1001.validate( Description1001.java:42) at org.apache.woden.internal.wsdl20.validation.WSDLValidator.checkAssertions( WSDLValidator.java:109) at org.apache.woden.internal.wsdl20.validation.WSDLValidator.validate( WSDLValidator.java:77) at org.apache.woden.internal.DOMWSDLReader.readWSDL(DOMWSDLReader.java:207) at org.apache.woden.internal.DOMWSDLReader.readWSDL(DOMWSDLReader.java:233
Re: [VOYE][Axis2] Dims as 1.4 Release Manager
+1 Thanks, Keith On Fri, Mar 7, 2008 at 11:43 AM, Deepal jayasinghe [EMAIL PROTECTED] wrote: Hi Dims, Deepal, Would you have time for Axis2? I can volunteer as Release Manager if you wish or we can share the responsibility as usual. Either works for me. To be honest I was about to send a vote mail to the list making you as the release manager. So I am glad to see you as the release manager here is my +1 for you. And now it is your job to tell us the release plan and how we are going to :) . Thanks Deepal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [Axis2] Get the ball rolling on the stalled 1.4 Release
Hi Nick, Its basically a set of annotations that co-inside with WSDL 2.0 properties (Thats how we offer REST support). Some annotations were taken from JSR-311, but it does not have annotations for all properties. Hence it includes a few more. I sent a mail on this to the Dev list a couple of weeks ago. Also it seems like it will include some rework if we were to put these annotation into the 1.4 release. Hence lets postpone it for the next release. Its the best we can do at this moment. Once the 1.4 release branch is cut I will start this development on trunk. Thanks, Keith. On Fri, Feb 29, 2008 at 8:09 PM, Nicholas L Gallardo [EMAIL PROTECTED] wrote: Keith, What were you thinking of in terms of annotations for REST support? Would it be a new model or an existing one? -Nick [image: Inactive hide details for keith chapman [EMAIL PROTECTED]]keith chapman [EMAIL PROTECTED] *keith chapman [EMAIL PROTECTED]* 02/28/2008 07:24 PM Please respond to axis-dev@ws.apache.org To axis-dev@ws.apache.org cc Subject Re: [Axis2] Get the ball rolling on the stalled 1.4 Release I'll go ahead and apply the patch today cause there are no objections. Thanks, Keith. On Fri, Feb 29, 2008 at 1:34 AM, Davanum Srinivas [EMAIL PROTECTED][EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Keith, Waiting on sanka? - -- dims keith chapman wrote: | Hi Dims, | | I'd like to implement REST support via annotations and services.xml. That | requires the patch on * https://issues.apache.org/jira/browse/AXIS2-3523*https://issues.apache.org/jira/browse/AXIS2-3523to be | applied. I can follow up that with Sanka and get that resolved if there are | no objections. Currently our REST support is mainly via WSDL 2.0deployment | and it will be nice to extend those features for POJOs (Cause thats what | users use most often that not). Thoughts? | | Thanks, | Keith | | On Thu, Feb 28, 2008 at 10:37 PM, Davanum Srinivas * [EMAIL PROTECTED] [EMAIL PROTECTED] | wrote: | | Folks, | | I was looking at the JIRA a bit. There are 4 blockers as of right now. | | Can folks please review JIRA issues and let everyone know if there are | bugs that *have* to be fixed for getting 1.4 out | the door? | | Are there other items on the table or features to implement before we can | get 1.4 out? | | thanks, | dims | - - To unsubscribe, e-mail: [EMAIL PROTECTED][EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED][EMAIL PROTECTED] | | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFHxxPmgNg6eWEDv1kRAvBNAKCW5GYQWNYdWrPL2GhqnoOmh3U4GACeOTC7 2Ytw2adrArsvniQRf8cvrEY= =yWNp -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED][EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -- Keith Chapman Software Engineer WSO2 Inc. Oxygenating the Web Service Platform.* **http://wso2.org/* http://wso2.org/ blog: *http://www.keith-chapman.org* http://www.keith-chapman.org/ -- Keith Chapman Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org graycol.gifecblank.gif
Re: [Axis2] Get the ball rolling on the stalled 1.4 Release
Hi Dims, I'd like to implement REST support via annotations and services.xml. That requires the patch on https://issues.apache.org/jira/browse/AXIS2-3523 to be applied. I can follow up that with Sanka and get that resolved if there are no objections. Currently our REST support is mainly via WSDL 2.0 deployment and it will be nice to extend those features for POJOs (Cause thats what users use most often that not). Thoughts? Thanks, Keith On Thu, Feb 28, 2008 at 10:37 PM, Davanum Srinivas [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Folks, I was looking at the JIRA a bit. There are 4 blockers as of right now. Can folks please review JIRA issues and let everyone know if there are bugs that *have* to be fixed for getting 1.4 out the door? Are there other items on the table or features to implement before we can get 1.4 out? thanks, dims -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFHxupVgNg6eWEDv1kRAjmTAJwJSJtXzbqIOmRphbC8MSobuNe5FACfb43M IM+f2FIVjJbzqlnx1SDH488= =oxq0 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
Re: [Axis2] Get the ball rolling on the stalled 1.4 Release
I'll go ahead and apply the patch today cause there are no objections. Thanks, Keith. On Fri, Feb 29, 2008 at 1:34 AM, Davanum Srinivas [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Keith, Waiting on sanka? - -- dims keith chapman wrote: | Hi Dims, | | I'd like to implement REST support via annotations and services.xml. That | requires the patch on https://issues.apache.org/jira/browse/AXIS2-3523to be | applied. I can follow up that with Sanka and get that resolved if there are | no objections. Currently our REST support is mainly via WSDL 2.0deployment | and it will be nice to extend those features for POJOs (Cause thats what | users use most often that not). Thoughts? | | Thanks, | Keith | | On Thu, Feb 28, 2008 at 10:37 PM, Davanum Srinivas [EMAIL PROTECTED] | wrote: | | Folks, | | I was looking at the JIRA a bit. There are 4 blockers as of right now. | | Can folks please review JIRA issues and let everyone know if there are | bugs that *have* to be fixed for getting 1.4 out | the door? | | Are there other items on the table or features to implement before we can | get 1.4 out? | | thanks, | dims | - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] | | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFHxxPmgNg6eWEDv1kRAvBNAKCW5GYQWNYdWrPL2GhqnoOmh3U4GACeOTC7 2Ytw2adrArsvniQRf8cvrEY= =yWNp -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
