Re: Axis2 1.5.1, JAX-WS and Rampart: client and endpoint configuration

2010-02-15 Thread Victor Rentea
Please help. I am building an application on this foundation and I want to
know if I took the correct path.

Thank you.


Re: Axis2/Rampart WS-Security performance

2010-02-11 Thread Asankha C. Perera
Hi Amila
>
> > In the very first scenario upto 640 concurrency level both have
> same through put while for 1280 threads UE has a sudden increment
> and for 2560 other ESB has a relatively high change. What could be
> the reason for that?
> Which set are you referring to - the WS-Security case? Sorry I do
> not see what you mean..
>
> 1. Direct Proxy Scenario 500b case.
> And also
> 1. Direct Proxy Scenario 1K case
> for 640 concurrency other ESB has performed well but 1280 and 2560
> done well.
>
> I am just wondering reason for these anomalities.
I think the anomaly is most possibly due to a full GC of the JVM - but
that its limited to the 500 byte / 1280 users case only - for the other
ESB. The usual trend would be for the TPS to increase gradually, and
then drop again after the sweet point of the ESB for the load considered.

If the same test is repeated multiple times, and the averages taken, the
results could eliminate these spikes - but the process could take some
number of hours more. These results were obtained after a warm up run of
1000 iterations at 20 users for each of the 4 scenarios - as we did in
Rounds 1, 2, and 3 before. This was to trigger the JVM to compile the
code with optimization - usually reached after around 10,000 iterations
of a method.

cheers
asankha

-- 
Asankha C. Perera
AdroitLogic, http://adroitlogic.org

http://esbmagic.blogspot.com






Re: Axis2/Rampart WS-Security performance

2010-02-11 Thread Amila Suriarachchi
On Thu, Feb 11, 2010 at 10:23 PM, Asankha C. Perera wrote:

> Hi Amila
> > how many messages you sent for one scenario test?
> > i.e for eg 500b message with 640 threads
> This depends on the concurrency, and can be found exactly by looking at
> the script used to run the load test. For example, when 20 users were
> being used, the iterations were 1000, while for 2560 users, the
> iterations were 10 - this was to keep the overall test execution time
> limited.
> > In the very first scenario upto 640 concurrency level both have same
> > through put while for 1280
> > threads UE has a sudden increment and for 2560 other ESB has a
> > relatively high change. What could be
> > the reason for that?
> Which set are you referring to - the WS-Security case? Sorry I do not
> see what you mean..
>
1. Direct Proxy Scenario 500b case.

And also
1. Direct Proxy Scenario 1K case
for 640 concurrency other ESB has performed well but 1280 and 2560 done
well.

I am just wondering reason for these anomalities.

thanks,
Amila.



> > Are all these results repeatable?
> Yes, you could re-run the test very easily on an EC2 node as per the
> details given at the bottom of the article - it will ofcourse take a
> couple of hours to complete all scenarios - so ensure that your SSH
> client timeout is disabled :D
>
> cheers
> asankha
>
> --
> Asankha C. Perera
> AdroitLogic, http://adroitlogic.org
>
> http://esbmagic.blogspot.com
>
>
>
>
>


-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/


Re: Axis2/Rampart WS-Security performance

2010-02-11 Thread Asankha C. Perera
Hi Amila
> how many messages you sent for one scenario test?
> i.e for eg 500b message with 640 threads
This depends on the concurrency, and can be found exactly by looking at
the script used to run the load test. For example, when 20 users were
being used, the iterations were 1000, while for 2560 users, the
iterations were 10 - this was to keep the overall test execution time
limited.
> In the very first scenario upto 640 concurrency level both have same
> through put while for 1280
> threads UE has a sudden increment and for 2560 other ESB has a
> relatively high change. What could be
> the reason for that? 
Which set are you referring to - the WS-Security case? Sorry I do not
see what you mean..
> Are all these results repeatable?
Yes, you could re-run the test very easily on an EC2 node as per the
details given at the bottom of the article - it will ofcourse take a
couple of hours to complete all scenarios - so ensure that your SSH
client timeout is disabled :D

cheers
asankha

-- 
Asankha C. Perera
AdroitLogic, http://adroitlogic.org

http://esbmagic.blogspot.com






Re: Axis2/Rampart WS-Security performance

2010-02-11 Thread Amila Suriarachchi
hi Asankha,

how many messages you sent for one scenario test?
i.e for eg 500b message with 640 threads

In the very first scenario upto 640 concurrency level both have same through
put while for 1280
threads UE has a sudden increment and for 2560 other ESB has a relatively
high change. What could be
the reason for that? Are all these results repeatable?

thanks,
Amila.

On Thu, Feb 11, 2010 at 12:52 PM, Asankha C. Perera wrote:

>  Hi Dennis
>
> I looked at WSS4j as a foundation for providing WS-Security support for the
> UltraESB,  and realized the fact that its not
> really optimized for use on an ESB; in addition to a few more issues I came
> across. Thus we developed a new library - which is functionally similar to
> WSS4J, which performs over 3 X times or better than WSS4J. However,
> currently it does not yet ship as a separate library - although we may
> decide to do that if there is user interest and demand.
>
> Here is a comparison of it in use against WS-Security based on
> WSS4J/Rampart
>
>
> http://adroitlogic.org/samples-articles-and-tutorials/15-tutorials/48-esb-performance.html
>
> cheers
> asankha
>
>
> Following up on some earlier discussions of Axis2/Rampart WS-Security
> performance, devWorks has now published my latest article in the Java Web
> Services series, comparing Axis2/Rampart with Metro WS-Security performance:
> http://www.ibm.com/developerworks/java/library/j-jws11/ The results are
> very bad for Axis2/Rampart, with Metro more than twice as fast overall in
> the WS-Security tests.
>
> As mentioned in the article, some timing tests with org.apache.rampart.TIME
> logging seemed to indicate that a lot of the overhead is actually occurring
> outside the Rampart handler. I suspect that Axis2 has fallen into the same
> performance pit as Axis in doing conversions to and from different forms of
> the message.
>
> If anyone is interested in investigating further, the full source code for
> the performance comparison is available as a download from the article.
>
>  - Dennis
>
>  --
> Asankha C. Perera
> AdroitLogic, http://adroitlogic.org
> http://esbmagic.blogspot.com
>
>
>


-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/


RE: Axis2/Rampart WS-Security performance

2010-02-11 Thread Martin Gainty

i found building an AXIOM DOM object graph the easiest way to transmit both the 
inmessage and outmessage

For each complexType Axis WSDL2jAVA/wsdl2cODE their own parse method which in 
turn references an extensionMapper tied to that parse ..so 250 complexTypes 
have 250 different parse lookup methods (and 250 different extensionMappers) 

the AXIOM object graph contains all the neceesary information and could be used 
to lookup namespace,localName and value

it seems that Axis iterative use of parse/extensionMapper introduces 
considerable memory/cpu overhead (as well as tying the service to a static 
configuration) 
 
thoughts?
Martin Gainty 
__ 
please do not alter/modify or disrupt this transmission. Thank You




> Date: Thu, 11 Feb 2010 22:19:08 +1300
> From: d...@sosnoski.com
> To: axis-dev@ws.apache.org
> Subject: Re: Axis2/Rampart WS-Security performance
> 
> Hi Asankha,
> 
>  From what I've seen, most of the performance problems with 
> Axis2/Rampart lay outside of WSS4J. Rampart could certainly do a better 
> job of optimizing its use of WSS4J - for example by not going through 
> the overhead of constructing an AXIOM DOM representation of the message 
> and passing that to WSS4J when the security configuration does not 
> require any processing on a particular message (such as for the response 
> message when only using UsernameToken) - but for cases where security 
> processing is actually needed, Rampart also does not appear to be the 
> cause of most of the added overhead.
> 
> I suspect the problems lie in the Axis2/AXIOM interaction, with 
> conversions between different forms of the message soaking up a lot of 
> time (and memory). One of these conversions, the building of an AXIOM 
> DOM representation, does show up as part of the Rampart timings, but I 
> suspect there are more conversions going on outside of Rampart once the 
> message body has to be parsed into a document model. The original Axis 
> has problems of this type, with repeated conversions between string and 
> DOM representations of a message which add a lot of overhead.
> 
> I'm only working with open source code in my articles, so your products 
> are not something I'd cover. If you want a better comparison for 
> WS-Security performance I suggest you try Metro to see how that compares 
> to your code.
> 
>   - Dennis
> 
> 
> Asankha C. Perera wrote:
> > Hi Dennis
> >
> > I looked at WSS4j as a foundation for providing WS-Security support 
> > for the UltraESB, <http://adroitlogic.org> and realized the fact that 
> > its not really optimized for use on an ESB; in addition to a few more 
> > issues I came across. Thus we developed a new library - which is 
> > functionally similar to WSS4J, which performs over 3 X times or better 
> > than WSS4J. However, currently it does not yet ship as a separate 
> > library - although we may decide to do that if there is user interest 
> > and demand.
> >
> > Here is a comparison of it in use against WS-Security based on 
> > WSS4J/Rampart
> >
> > http://adroitlogic.org/samples-articles-and-tutorials/15-tutorials/48-esb-performance.html
> >
> > cheers
> > asankha
> >
> >> Following up on some earlier discussions of Axis2/Rampart WS-Security 
> >> performance, devWorks has now published my latest article in the Java 
> >> Web Services series, comparing Axis2/Rampart with Metro WS-Security 
> >> performance: http://www.ibm.com/developerworks/java/library/j-jws11/ 
> >> The results are very bad for Axis2/Rampart, with Metro more than 
> >> twice as fast overall in the WS-Security tests.
> >>
> >> As mentioned in the article, some timing tests with 
> >> org.apache.rampart.TIME logging seemed to indicate that a lot of the 
> >> overhead is actually occurring outside the Rampart handler. I suspect 
> >> that Axis2 has fallen into the same performance pit as Axis in doing 
> >> conversions to and from different forms of the message.
> >>
> >> If anyone is interested in investigating further, the full source 
> >> code for the performance comparison is available as a download from 
> >> the article.
> >>
> >>  - Dennis
> >>
> > -- 
> > Asankha C. Perera
> > AdroitLogic, http://adroitlogic.org
> >
> > http://esbmagic.blogspot.com
> >
> >
> >
> >   
  
_
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469226/direct/01/

Re: Axis2/Rampart WS-Security performance

2010-02-11 Thread Dennis Sosnoski

Hi Asankha,

From what I've seen, most of the performance problems with 
Axis2/Rampart lay outside of WSS4J. Rampart could certainly do a better 
job of optimizing its use of WSS4J - for example by not going through 
the overhead of constructing an AXIOM DOM representation of the message 
and passing that to WSS4J when the security configuration does not 
require any processing on a particular message (such as for the response 
message when only using UsernameToken) - but for cases where security 
processing is actually needed, Rampart also does not appear to be the 
cause of most of the added overhead.


I suspect the problems lie in the Axis2/AXIOM interaction, with 
conversions between different forms of the message soaking up a lot of 
time (and memory). One of these conversions, the building of an AXIOM 
DOM representation, does show up as part of the Rampart timings, but I 
suspect there are more conversions going on outside of Rampart once the 
message body has to be parsed into a document model. The original Axis 
has problems of this type, with repeated conversions between string and 
DOM representations of a message which add a lot of overhead.


I'm only working with open source code in my articles, so your products 
are not something I'd cover. If you want a better comparison for 
WS-Security performance I suggest you try Metro to see how that compares 
to your code.


 - Dennis


Asankha C. Perera wrote:

Hi Dennis

I looked at WSS4j as a foundation for providing WS-Security support 
for the UltraESB,  and realized the fact that 
its not really optimized for use on an ESB; in addition to a few more 
issues I came across. Thus we developed a new library - which is 
functionally similar to WSS4J, which performs over 3 X times or better 
than WSS4J. However, currently it does not yet ship as a separate 
library - although we may decide to do that if there is user interest 
and demand.


Here is a comparison of it in use against WS-Security based on 
WSS4J/Rampart


http://adroitlogic.org/samples-articles-and-tutorials/15-tutorials/48-esb-performance.html

cheers
asankha

Following up on some earlier discussions of Axis2/Rampart WS-Security 
performance, devWorks has now published my latest article in the Java 
Web Services series, comparing Axis2/Rampart with Metro WS-Security 
performance: http://www.ibm.com/developerworks/java/library/j-jws11/ 
The results are very bad for Axis2/Rampart, with Metro more than 
twice as fast overall in the WS-Security tests.


As mentioned in the article, some timing tests with 
org.apache.rampart.TIME logging seemed to indicate that a lot of the 
overhead is actually occurring outside the Rampart handler. I suspect 
that Axis2 has fallen into the same performance pit as Axis in doing 
conversions to and from different forms of the message.


If anyone is interested in investigating further, the full source 
code for the performance comparison is available as a download from 
the article.


 - Dennis


--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org

http://esbmagic.blogspot.com



  


Re: Axis2/Rampart WS-Security performance

2010-02-10 Thread Asankha C. Perera
Hi Dennis

I looked at WSS4j as a foundation for providing WS-Security support for
the UltraESB,  and realized the fact that its
not really optimized for use on an ESB; in addition to a few more issues
I came across. Thus we developed a new library - which is functionally
similar to WSS4J, which performs over 3 X times or better than WSS4J.
However, currently it does not yet ship as a separate library - although
we may decide to do that if there is user interest and demand.

Here is a comparison of it in use against WS-Security based on WSS4J/Rampart

http://adroitlogic.org/samples-articles-and-tutorials/15-tutorials/48-esb-performance.html

cheers
asankha

> Following up on some earlier discussions of Axis2/Rampart WS-Security
> performance, devWorks has now published my latest article in the Java
> Web Services series, comparing Axis2/Rampart with Metro WS-Security
> performance: http://www.ibm.com/developerworks/java/library/j-jws11/
> The results are very bad for Axis2/Rampart, with Metro more than twice
> as fast overall in the WS-Security tests.
>
> As mentioned in the article, some timing tests with
> org.apache.rampart.TIME logging seemed to indicate that a lot of the
> overhead is actually occurring outside the Rampart handler. I suspect
> that Axis2 has fallen into the same performance pit as Axis in doing
> conversions to and from different forms of the message.
>
> If anyone is interested in investigating further, the full source code
> for the performance comparison is available as a download from the
> article.
>
>  - Dennis
>
-- 
Asankha C. Perera
AdroitLogic, http://adroitlogic.org

http://esbmagic.blogspot.com






Re: Axis2 Deployers doesn't support a directory within another directory under repository??

2010-02-10 Thread Ruwan Linton
On Thu, Feb 11, 2010 at 10:46 AM, Ruwan Linton wrote:

>
>
> On Thu, Feb 11, 2010 at 10:10 AM, Isuru Suriarachchi wrote:
>
>>
>>
>> On Thu, Feb 11, 2010 at 10:05 AM, Amila Suriarachchi <
>> amilasuriarach...@gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Feb 11, 2010 at 8:11 AM, Ruwan Linton wrote:
>>>
 Folks,

 Synapse has a requirement to have a directory called conf/synapse-config
 in the repository and have its own space for sequences, endpoints, proxy
 services so forth inside that.. So the expected deployer config within the
 axis2.xml is as follows;

 >>> class="org.apache.synapse.deployers.SequenceDeployer"/>

 but because of the following code fragment it takes only the last
 director specified in the directory declaration of the deployer. Is there
 any reason for us to restrict the deployer to only one level, even in that
 case we should be treating the directory as the top level direcotry so that
 the path is correct, but here we are calculating a directory path which is
 not existing. With the above case it computes the directory as
 $AXIS2_REPOSITORY/sequences which is completely wrong :-(

 org.apache.axis2.deployment.RepositoryListener [267, 280]

 //This will load the files from the directories
 // specified by axis2.xml (As )
 private void loadOtherDirectories() {
 for (Map.Entry> entry :
 deploymentEngine.getDeployers().entrySet()) {
 String directory = entry.getKey();
 Map extensionMap = entry.getValue();
 for (String extension : extensionMap.keySet()) {
 String[] strings = directory.split("/");
 File dirToSearch = new
 File(deploymentEngine.getRepositoryDir(),
 strings[strings.length - 1]);
 findFileForGivenDirectory(dirToSearch, extension,
 directory);

>>> I think it may work if you specify only 'conf' and above method finds it
>>> recursively.
>>>
>>
>> But if it is set to 'conf', the deployer will try to find sequences inside
>> all sub directories of the 'conf' dir. Therefore it won't be a good solution
>> I guess.
>>
>> +1 for removing this splitting code and supporting a '/' separated path
>> for the directory attribute of the deployer, rather than only supporting one
>> level.
>>
>
> Yes, Isuru is correct.
>
> So inside the conf/synapse-config we have endpoints, proxy services, local
> entries and so forth as well and they will be tried to build as sequences
> and will be failed as well. Note that all these configurations are in .xml
> extension and we cannot differentiate them with the extension.
>
> Let's remove the splitting if there is no valid reason to have that. I had
> a look at the logic and there is no need to have this logic. Also the logic
> is wrong, I think this has been introduced to detect the absolute path
> provided as the directory case, where it should have been better handled
> with the File operations :-)
>

Well, by looking at the JavaDoc for the two argument (File, String) File
constructor we do not need to do anything special, File class handles it
within the constructor.

 If the child
 * pathname string is absolute then it is converted into a relative
 * pathname in a system-dependent way.


Thanks,
Ruwan


>
> I will fix it, and will see if it breaks anything (I don't think so,
> though)
>
> Thanks,
> Ruwan
>
>>
>> Thanks,
>> ~Isuru
>>
>>
>>>
>>> +1 to remove spliting if there is no reason for that.
>>>
>>> thanks,
>>> Amila.
>>>
 }
 }
 }

 Can we get rid of the splitting and let the user declare inner
 directories for the artifacts to be deployed??

 Thanks,
 Ruwan

 --
 Ruwan Linton
 Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
 WSO2 Inc.; http://wso2.org
 email: ru...@wso2.com; cell: +94 77 341 3097
 blog: http://ruwansblog.blogspot.com

>>>
>>>
>>>
>>> --
>>> Amila Suriarachchi
>>> WSO2 Inc.
>>> blog: http://amilachinthaka.blogspot.com/
>>>
>>
>>
>>
>> --
>> Senior Software Engineer,
>> WSO2 Inc. http://wso2.org/
>> Blog : http://isurues.wordpress.com/
>>
>
>
>
> --
> Ruwan Linton
> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
> WSO2 Inc.; http://wso2.org
> email: ru...@wso2.com; cell: +94 77 341 3097
> blog: http://ruwansblog.blogspot.com
>



-- 
Ruwan Linton
Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ru...@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com


Re: Axis2 Deployers doesn't support a directory within another directory under repository??

2010-02-10 Thread Ruwan Linton
On Thu, Feb 11, 2010 at 10:10 AM, Isuru Suriarachchi wrote:

>
>
> On Thu, Feb 11, 2010 at 10:05 AM, Amila Suriarachchi <
> amilasuriarach...@gmail.com> wrote:
>
>>
>>
>> On Thu, Feb 11, 2010 at 8:11 AM, Ruwan Linton wrote:
>>
>>> Folks,
>>>
>>> Synapse has a requirement to have a directory called conf/synapse-config
>>> in the repository and have its own space for sequences, endpoints, proxy
>>> services so forth inside that.. So the expected deployer config within the
>>> axis2.xml is as follows;
>>>
>>> >> class="org.apache.synapse.deployers.SequenceDeployer"/>
>>>
>>> but because of the following code fragment it takes only the last
>>> director specified in the directory declaration of the deployer. Is there
>>> any reason for us to restrict the deployer to only one level, even in that
>>> case we should be treating the directory as the top level direcotry so that
>>> the path is correct, but here we are calculating a directory path which is
>>> not existing. With the above case it computes the directory as
>>> $AXIS2_REPOSITORY/sequences which is completely wrong :-(
>>>
>>> org.apache.axis2.deployment.RepositoryListener [267, 280]
>>>
>>> //This will load the files from the directories
>>> // specified by axis2.xml (As )
>>> private void loadOtherDirectories() {
>>> for (Map.Entry> entry :
>>> deploymentEngine.getDeployers().entrySet()) {
>>> String directory = entry.getKey();
>>> Map extensionMap = entry.getValue();
>>> for (String extension : extensionMap.keySet()) {
>>> String[] strings = directory.split("/");
>>> File dirToSearch = new
>>> File(deploymentEngine.getRepositoryDir(),
>>> strings[strings.length - 1]);
>>> findFileForGivenDirectory(dirToSearch, extension,
>>> directory);
>>>
>> I think it may work if you specify only 'conf' and above method finds it
>> recursively.
>>
>
> But if it is set to 'conf', the deployer will try to find sequences inside
> all sub directories of the 'conf' dir. Therefore it won't be a good solution
> I guess.
>
> +1 for removing this splitting code and supporting a '/' separated path for
> the directory attribute of the deployer, rather than only supporting one
> level.
>

Yes, Isuru is correct.

So inside the conf/synapse-config we have endpoints, proxy services, local
entries and so forth as well and they will be tried to build as sequences
and will be failed as well. Note that all these configurations are in .xml
extension and we cannot differentiate them with the extension.

Let's remove the splitting if there is no valid reason to have that. I had a
look at the logic and there is no need to have this logic. Also the logic is
wrong, I think this has been introduced to detect the absolute path provided
as the directory case, where it should have been better handled with the
File operations :-)

I will fix it, and will see if it breaks anything (I don't think so, though)

Thanks,
Ruwan

>
> Thanks,
> ~Isuru
>
>
>>
>> +1 to remove spliting if there is no reason for that.
>>
>> thanks,
>> Amila.
>>
>>> }
>>> }
>>> }
>>>
>>> Can we get rid of the splitting and let the user declare inner
>>> directories for the artifacts to be deployed??
>>>
>>> Thanks,
>>> Ruwan
>>>
>>> --
>>> Ruwan Linton
>>> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>>> WSO2 Inc.; http://wso2.org
>>> email: ru...@wso2.com; cell: +94 77 341 3097
>>> blog: http://ruwansblog.blogspot.com
>>>
>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>>
>
>
>
> --
> Senior Software Engineer,
> WSO2 Inc. http://wso2.org/
> Blog : http://isurues.wordpress.com/
>



-- 
Ruwan Linton
Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ru...@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com


Re: Axis2 Deployers doesn't support a directory within another directory under repository??

2010-02-10 Thread Isuru Suriarachchi
On Thu, Feb 11, 2010 at 10:05 AM, Amila Suriarachchi <
amilasuriarach...@gmail.com> wrote:

>
>
> On Thu, Feb 11, 2010 at 8:11 AM, Ruwan Linton wrote:
>
>> Folks,
>>
>> Synapse has a requirement to have a directory called conf/synapse-config
>> in the repository and have its own space for sequences, endpoints, proxy
>> services so forth inside that.. So the expected deployer config within the
>> axis2.xml is as follows;
>>
>> > class="org.apache.synapse.deployers.SequenceDeployer"/>
>>
>> but because of the following code fragment it takes only the last director
>> specified in the directory declaration of the deployer. Is there any reason
>> for us to restrict the deployer to only one level, even in that case we
>> should be treating the directory as the top level direcotry so that the path
>> is correct, but here we are calculating a directory path which is not
>> existing. With the above case it computes the directory as
>> $AXIS2_REPOSITORY/sequences which is completely wrong :-(
>>
>> org.apache.axis2.deployment.RepositoryListener [267, 280]
>>
>> //This will load the files from the directories
>> // specified by axis2.xml (As )
>> private void loadOtherDirectories() {
>> for (Map.Entry> entry :
>> deploymentEngine.getDeployers().entrySet()) {
>> String directory = entry.getKey();
>> Map extensionMap = entry.getValue();
>> for (String extension : extensionMap.keySet()) {
>> String[] strings = directory.split("/");
>> File dirToSearch = new
>> File(deploymentEngine.getRepositoryDir(),
>> strings[strings.length - 1]);
>> findFileForGivenDirectory(dirToSearch, extension,
>> directory);
>>
> I think it may work if you specify only 'conf' and above method finds it
> recursively.
>

But if it is set to 'conf', the deployer will try to find sequences inside
all sub directories of the 'conf' dir. Therefore it won't be a good solution
I guess.

+1 for removing this splitting code and supporting a '/' separated path for
the directory attribute of the deployer, rather than only supporting one
level.

Thanks,
~Isuru


>
> +1 to remove spliting if there is no reason for that.
>
> thanks,
> Amila.
>
>> }
>> }
>> }
>>
>> Can we get rid of the splitting and let the user declare inner directories
>> for the artifacts to be deployed??
>>
>> Thanks,
>> Ruwan
>>
>> --
>> Ruwan Linton
>> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>> WSO2 Inc.; http://wso2.org
>> email: ru...@wso2.com; cell: +94 77 341 3097
>> blog: http://ruwansblog.blogspot.com
>>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>



-- 
Senior Software Engineer,
WSO2 Inc. http://wso2.org/
Blog : http://isurues.wordpress.com/


Re: Axis2 Deployers doesn't support a directory within another directory under repository??

2010-02-10 Thread Amila Suriarachchi
On Thu, Feb 11, 2010 at 8:11 AM, Ruwan Linton wrote:

> Folks,
>
> Synapse has a requirement to have a directory called conf/synapse-config in
> the repository and have its own space for sequences, endpoints, proxy
> services so forth inside that.. So the expected deployer config within the
> axis2.xml is as follows;
>
>  class="org.apache.synapse.deployers.SequenceDeployer"/>
>
> but because of the following code fragment it takes only the last director
> specified in the directory declaration of the deployer. Is there any reason
> for us to restrict the deployer to only one level, even in that case we
> should be treating the directory as the top level direcotry so that the path
> is correct, but here we are calculating a directory path which is not
> existing. With the above case it computes the directory as
> $AXIS2_REPOSITORY/sequences which is completely wrong :-(
>
> org.apache.axis2.deployment.RepositoryListener [267, 280]
>
> //This will load the files from the directories
> // specified by axis2.xml (As )
> private void loadOtherDirectories() {
> for (Map.Entry> entry :
> deploymentEngine.getDeployers().entrySet()) {
> String directory = entry.getKey();
> Map extensionMap = entry.getValue();
> for (String extension : extensionMap.keySet()) {
> String[] strings = directory.split("/");
> File dirToSearch = new
> File(deploymentEngine.getRepositoryDir(),
> strings[strings.length - 1]);
> findFileForGivenDirectory(dirToSearch, extension,
> directory);
>
I think it may work if you specify only 'conf' and above method finds it
recursively.

+1 to remove spliting if there is no reason for that.

thanks,
Amila.

> }
> }
> }
>
> Can we get rid of the splitting and let the user declare inner directories
> for the artifacts to be deployed??
>
> Thanks,
> Ruwan
>
> --
> Ruwan Linton
> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
> WSO2 Inc.; http://wso2.org
> email: ru...@wso2.com; cell: +94 77 341 3097
> blog: http://ruwansblog.blogspot.com
>



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/


Re: Axis2/Rampart WS-Security performance

2010-02-01 Thread Dennis Sosnoski

Hi Prabath,

I just tried a couple of simple tests, using the signing+encryption 
policy on the server and trying different variations of policy 
(including no policy) on the client with both Metro and Axis2. All the 
client variations were rejected by the server in both cases, so at least 
at this basic level both Metro and Axis2/Rampart are enforcing the 
server policy.


What sort of shortfalls did you see in Metro's policy-based validations?

 - Dennis


Prabath Siriwardena wrote:

Hi Dennis;

Nice analysis...

Does Metro do policy based validations?

Rampart does validations at two levels - first validation at the 
message level with info gathered from the message it self - and then 
validate the entire message with the defined policy.


If somebody skips the second step - it could open up holes for attacks 
like XML wrapping attacks.


I found few occasions that Metro doesn't do policy based validations. 
Would be glad if you could please confirm it.


Thanks & regards.
-Prabath

Dennis Sosnoski wrote:
Following up on some earlier discussions of Axis2/Rampart WS-Security 
performance, devWorks has now published my latest article in the Java 
Web Services series, comparing Axis2/Rampart with Metro WS-Security 
performance: http://www.ibm.com/developerworks/java/library/j-jws11/ 
The results are very bad for Axis2/Rampart, with Metro more than 
twice as fast overall in the WS-Security tests.


As mentioned in the article, some timing tests with 
org.apache.rampart.TIME logging seemed to indicate that a lot of the 
overhead is actually occurring outside the Rampart handler. I suspect 
that Axis2 has fallen into the same performance pit as Axis in doing 
conversions to and from different forms of the message.


If anyone is interested in investigating further, the full source 
code for the performance comparison is available as a download from 
the article.


 - Dennis





Re: Axis2 build??

2010-01-30 Thread Hiranya Jayathilaka
Thanks for looking into this Andreas.

Thanks,
Hiranya

On Sat, Jan 30, 2010 at 7:25 PM, Andreas Veithen
wrote:

> All,
>
> Starting with version 1.2 of the antrun plugin, it is possible to
> conditionally skip ant executions based on system properties. What
> Ruwan is looking for can thus be achieved using the following syntax:
>
> 
>
> I changed the POMs (see r904780 and AXIS2-3290) to use that approach
> and tested the build successfully in the following scenarios:
>
> * mvn clean install: behaves as usual
> * mvn clean install -Dtest=false: behaves as usual
> * mvn clean install -Dmaven.test.skip=true: this now effectively skips
> test compilation (including ant scripts) and execution
>
> If anyone encounters any problems or discovers any side effects that I
> didn't see, please revert the change (svn merge -c -904780 . .) and
> let me know so that I can investigate the issue.
>
> Andreas
>
> On Thu, Jan 28, 2010 at 04:43, Ruwan Linton 
> wrote:
> > Hi Andreas and all,
> >
> > I sort of figured out the issue, this occurs when you skip tests using
> the
> > maven.test.skip system property. According to the maven documentation
> > maven.test.skip system property not only by passes running tests but also
> by
> > passes compiling tests as well.
> >
> > In this particular case, if the tests are not compiled, the build will be
> > failing because at the tes-compile phase, the ant-run plugin tries to
> create
> > a service archive out those compiled test classes, which is failing. Note
> > that, even though the above property by-passes compiling tests, it does
> not
> > by-pass the maven phase. (There is no way to by-pass phases in maven,
> AFAIK)
> >
> > Then I tried to put this ant task bit into a profile and tried to
> activate
> > it only when the tests are enabled, but maven doesn't seem to give me an
> > option to check whether the tests are enabled or not. Though I can track
> the
> > test disabled scenario, I cannot track the test enabled scenario.
> >
> > As the last option I tried to use the file based profile activation, to
> see
> > the compiled test classes exists or not to activate the ant task. This
> > approach also failed, since maven decides the activated profile at the
> start
> > of the execution at which point the file exists decision is wrong,
> ideally
> > if the profile activation decision should have been taken at the desired
> > phase, but I think there are technical limitations for maven to do so.
> >
> > So with the above analysis I couldn't get this solved, but fortunately
> maven
> > has an option to ask not to run the tests, but let it compile the tests,
> > using the system property called "skipTests".
> >
> > So the conclusion is use;
> >
> > mvn clean install -DskipTests
> >
> > instead of "mvn clean install -Dmaven.test.skip=true" if you want to skip
> > axis2 build tests.
> >
> > Thanks,
> > Ruwan
> >
> > On Thu, Jan 28, 2010 at 1:00 AM, Andreas Veithen <
> andreas.veit...@gmail.com>
> > wrote:
> >>
> >> For the moment I don't have any idea how to debug this. I was going to
> >> suggest setting the verbose option to true on the
> >> maven-compiler-plugin, but that doesn't seem to work.
> >>
> >> Andreas
> >>
> >> On Tue, Jan 26, 2010 at 02:40, Ruwan Linton 
> >> wrote:
> >> > Also, it is getting compiled when you run maven on the
> jaxws-integration
> >> > module, but not compiling when running on the axis2 build root :-(
> >> >
> >> > Any clue??
> >> >
> >> > Thanks,
> >> > Ruwan
> >> >
> >> > On Tue, Jan 26, 2010 at 7:38 AM, Ruwan Linton  >
> >> > wrote:
> >> >>
> >> >> Andreas,
> >> >>
> >> >> I drilled down the problem to not compiling the following test
> packages
> >> >> of
> >> >> jaxws-integration module on my machine;
> >> >>
> >> >> org.apache.axis2.jaxws.type_substitution
> >> >>
> >> >> Because of this the classes that are required for the
> >> >> AppleFinderService
> >> >> creating ant task is missing and cause the above error. I wonder
> >> >> whether the
> >> >> '_' character in the package name causes this issue.
> >> >>
> >> >> Trying to resolve the issue.
> >> >>
> >> >> Thanks,
> >> >> Ruwan
> >> >>
> >> >> On Tue, Jan 26, 2010 at 3:29 AM, Andreas Veithen
> >> >>  wrote:
> >> >>>
> >> >>> Ruwan,
> >> >>>
> >> >>> I just tested with the following combination, which is very close to
> >> >>> what you have (except for the OS):
> >> >>>
> >> >>> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> >> >>> Java version: 1.6.0_17
> >> >>> Java home:
> >> >>> /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> >> >>> Default locale: en_US, platform encoding: MacRoman
> >> >>> OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"
> >> >>>
> >> >>> Result: the build succeeds without any problems, so we still have no
> >> >>> clue what causes this issue.
> >> >>>
> >> >>> Andreas
> >> >>>
> >> >>> On Mon, Jan 25, 2010 at 17:37, Ruwan Linton  >
> >> >>> wrote:
> >> >>> >
> >> >>> >
> >> >>> > On Mon, Jan 25, 2010 at 9:03 PM, Andreas Ve

Re: Axis2/Rampart WS-Security performance

2010-01-30 Thread Prabath Siriwardena

Hi Dennis;

Nice analysis...

Does Metro do policy based validations?

Rampart does validations at two levels - first validation at the message 
level with info gathered from the message it self - and then validate 
the entire message with the defined policy.


If somebody skips the second step - it could open up holes for attacks 
like XML wrapping attacks.


I found few occasions that Metro doesn't do policy based validations. 
Would be glad if you could please confirm it.


Thanks & regards.
-Prabath

Dennis Sosnoski wrote:
Following up on some earlier discussions of Axis2/Rampart WS-Security 
performance, devWorks has now published my latest article in the Java 
Web Services series, comparing Axis2/Rampart with Metro WS-Security 
performance: http://www.ibm.com/developerworks/java/library/j-jws11/ 
The results are very bad for Axis2/Rampart, with Metro more than twice 
as fast overall in the WS-Security tests.


As mentioned in the article, some timing tests with 
org.apache.rampart.TIME logging seemed to indicate that a lot of the 
overhead is actually occurring outside the Rampart handler. I suspect 
that Axis2 has fallen into the same performance pit as Axis in doing 
conversions to and from different forms of the message.


If anyone is interested in investigating further, the full source code 
for the performance comparison is available as a download from the 
article.


 - Dennis





Re: Axis2 build??

2010-01-30 Thread Ruwan Linton
Hi Andreas,

Yes, this is exactly what I was trying to do, but I went on the wrong path
with trying this using profiles. The build is working fine for me in all
scenarios. Thanks Andreas.

Ruwan

On Sat, Jan 30, 2010 at 7:25 PM, Andreas Veithen
wrote:

> All,
>
> Starting with version 1.2 of the antrun plugin, it is possible to
> conditionally skip ant executions based on system properties. What
> Ruwan is looking for can thus be achieved using the following syntax:
>
> 
>
> I changed the POMs (see r904780 and AXIS2-3290) to use that approach
> and tested the build successfully in the following scenarios:
>
> * mvn clean install: behaves as usual
> * mvn clean install -Dtest=false: behaves as usual
> * mvn clean install -Dmaven.test.skip=true: this now effectively skips
> test compilation (including ant scripts) and execution
>
> If anyone encounters any problems or discovers any side effects that I
> didn't see, please revert the change (svn merge -c -904780 . .) and
> let me know so that I can investigate the issue.
>
> Andreas
>
> On Thu, Jan 28, 2010 at 04:43, Ruwan Linton 
> wrote:
> > Hi Andreas and all,
> >
> > I sort of figured out the issue, this occurs when you skip tests using
> the
> > maven.test.skip system property. According to the maven documentation
> > maven.test.skip system property not only by passes running tests but also
> by
> > passes compiling tests as well.
> >
> > In this particular case, if the tests are not compiled, the build will be
> > failing because at the tes-compile phase, the ant-run plugin tries to
> create
> > a service archive out those compiled test classes, which is failing. Note
> > that, even though the above property by-passes compiling tests, it does
> not
> > by-pass the maven phase. (There is no way to by-pass phases in maven,
> AFAIK)
> >
> > Then I tried to put this ant task bit into a profile and tried to
> activate
> > it only when the tests are enabled, but maven doesn't seem to give me an
> > option to check whether the tests are enabled or not. Though I can track
> the
> > test disabled scenario, I cannot track the test enabled scenario.
> >
> > As the last option I tried to use the file based profile activation, to
> see
> > the compiled test classes exists or not to activate the ant task. This
> > approach also failed, since maven decides the activated profile at the
> start
> > of the execution at which point the file exists decision is wrong,
> ideally
> > if the profile activation decision should have been taken at the desired
> > phase, but I think there are technical limitations for maven to do so.
> >
> > So with the above analysis I couldn't get this solved, but fortunately
> maven
> > has an option to ask not to run the tests, but let it compile the tests,
> > using the system property called "skipTests".
> >
> > So the conclusion is use;
> >
> > mvn clean install -DskipTests
> >
> > instead of "mvn clean install -Dmaven.test.skip=true" if you want to skip
> > axis2 build tests.
> >
> > Thanks,
> > Ruwan
> >
> > On Thu, Jan 28, 2010 at 1:00 AM, Andreas Veithen <
> andreas.veit...@gmail.com>
> > wrote:
> >>
> >> For the moment I don't have any idea how to debug this. I was going to
> >> suggest setting the verbose option to true on the
> >> maven-compiler-plugin, but that doesn't seem to work.
> >>
> >> Andreas
> >>
> >> On Tue, Jan 26, 2010 at 02:40, Ruwan Linton 
> >> wrote:
> >> > Also, it is getting compiled when you run maven on the
> jaxws-integration
> >> > module, but not compiling when running on the axis2 build root :-(
> >> >
> >> > Any clue??
> >> >
> >> > Thanks,
> >> > Ruwan
> >> >
> >> > On Tue, Jan 26, 2010 at 7:38 AM, Ruwan Linton  >
> >> > wrote:
> >> >>
> >> >> Andreas,
> >> >>
> >> >> I drilled down the problem to not compiling the following test
> packages
> >> >> of
> >> >> jaxws-integration module on my machine;
> >> >>
> >> >> org.apache.axis2.jaxws.type_substitution
> >> >>
> >> >> Because of this the classes that are required for the
> >> >> AppleFinderService
> >> >> creating ant task is missing and cause the above error. I wonder
> >> >> whether the
> >> >> '_' character in the package name causes this issue.
> >> >>
> >> >> Trying to resolve the issue.
> >> >>
> >> >> Thanks,
> >> >> Ruwan
> >> >>
> >> >> On Tue, Jan 26, 2010 at 3:29 AM, Andreas Veithen
> >> >>  wrote:
> >> >>>
> >> >>> Ruwan,
> >> >>>
> >> >>> I just tested with the following combination, which is very close to
> >> >>> what you have (except for the OS):
> >> >>>
> >> >>> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> >> >>> Java version: 1.6.0_17
> >> >>> Java home:
> >> >>> /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> >> >>> Default locale: en_US, platform encoding: MacRoman
> >> >>> OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"
> >> >>>
> >> >>> Result: the build succeeds without any problems, so we still have no
> >> >>> clue what causes this issue.
> >> >>>
> >> >>> Andreas
> >> >>>
> >> >>>

Re: Axis2 build??

2010-01-30 Thread Andreas Veithen
All,

Starting with version 1.2 of the antrun plugin, it is possible to
conditionally skip ant executions based on system properties. What
Ruwan is looking for can thus be achieved using the following syntax:



I changed the POMs (see r904780 and AXIS2-3290) to use that approach
and tested the build successfully in the following scenarios:

* mvn clean install: behaves as usual
* mvn clean install -Dtest=false: behaves as usual
* mvn clean install -Dmaven.test.skip=true: this now effectively skips
test compilation (including ant scripts) and execution

If anyone encounters any problems or discovers any side effects that I
didn't see, please revert the change (svn merge -c -904780 . .) and
let me know so that I can investigate the issue.

Andreas

On Thu, Jan 28, 2010 at 04:43, Ruwan Linton  wrote:
> Hi Andreas and all,
>
> I sort of figured out the issue, this occurs when you skip tests using the
> maven.test.skip system property. According to the maven documentation
> maven.test.skip system property not only by passes running tests but also by
> passes compiling tests as well.
>
> In this particular case, if the tests are not compiled, the build will be
> failing because at the tes-compile phase, the ant-run plugin tries to create
> a service archive out those compiled test classes, which is failing. Note
> that, even though the above property by-passes compiling tests, it does not
> by-pass the maven phase. (There is no way to by-pass phases in maven, AFAIK)
>
> Then I tried to put this ant task bit into a profile and tried to activate
> it only when the tests are enabled, but maven doesn't seem to give me an
> option to check whether the tests are enabled or not. Though I can track the
> test disabled scenario, I cannot track the test enabled scenario.
>
> As the last option I tried to use the file based profile activation, to see
> the compiled test classes exists or not to activate the ant task. This
> approach also failed, since maven decides the activated profile at the start
> of the execution at which point the file exists decision is wrong, ideally
> if the profile activation decision should have been taken at the desired
> phase, but I think there are technical limitations for maven to do so.
>
> So with the above analysis I couldn't get this solved, but fortunately maven
> has an option to ask not to run the tests, but let it compile the tests,
> using the system property called "skipTests".
>
> So the conclusion is use;
>
> mvn clean install -DskipTests
>
> instead of "mvn clean install -Dmaven.test.skip=true" if you want to skip
> axis2 build tests.
>
> Thanks,
> Ruwan
>
> On Thu, Jan 28, 2010 at 1:00 AM, Andreas Veithen 
> wrote:
>>
>> For the moment I don't have any idea how to debug this. I was going to
>> suggest setting the verbose option to true on the
>> maven-compiler-plugin, but that doesn't seem to work.
>>
>> Andreas
>>
>> On Tue, Jan 26, 2010 at 02:40, Ruwan Linton 
>> wrote:
>> > Also, it is getting compiled when you run maven on the jaxws-integration
>> > module, but not compiling when running on the axis2 build root :-(
>> >
>> > Any clue??
>> >
>> > Thanks,
>> > Ruwan
>> >
>> > On Tue, Jan 26, 2010 at 7:38 AM, Ruwan Linton 
>> > wrote:
>> >>
>> >> Andreas,
>> >>
>> >> I drilled down the problem to not compiling the following test packages
>> >> of
>> >> jaxws-integration module on my machine;
>> >>
>> >> org.apache.axis2.jaxws.type_substitution
>> >>
>> >> Because of this the classes that are required for the
>> >> AppleFinderService
>> >> creating ant task is missing and cause the above error. I wonder
>> >> whether the
>> >> '_' character in the package name causes this issue.
>> >>
>> >> Trying to resolve the issue.
>> >>
>> >> Thanks,
>> >> Ruwan
>> >>
>> >> On Tue, Jan 26, 2010 at 3:29 AM, Andreas Veithen
>> >>  wrote:
>> >>>
>> >>> Ruwan,
>> >>>
>> >>> I just tested with the following combination, which is very close to
>> >>> what you have (except for the OS):
>> >>>
>> >>> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
>> >>> Java version: 1.6.0_17
>> >>> Java home:
>> >>> /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
>> >>> Default locale: en_US, platform encoding: MacRoman
>> >>> OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"
>> >>>
>> >>> Result: the build succeeds without any problems, so we still have no
>> >>> clue what causes this issue.
>> >>>
>> >>> Andreas
>> >>>
>> >>> On Mon, Jan 25, 2010 at 17:37, Ruwan Linton 
>> >>> wrote:
>> >>> >
>> >>> >
>> >>> > On Mon, Jan 25, 2010 at 9:03 PM, Andreas Veithen
>> >>> > 
>> >>> > wrote:
>> >>> >>
>> >>> >> On Mon, Jan 25, 2010 at 15:30, Ruwan Linton
>> >>> >> 
>> >>> >> wrote:
>> >>> >> > Andreas,
>> >>> >> >
>> >>> >> > I don't have maven 2.0 right now to test this, but I was having
>> >>> >> > this
>> >>> >> > issue
>> >>> >> > with maven 2.1.0 and JDK 1.5 as well. Does this means that you
>> >>> >> > are
>> >>> >> > not
>> >>> >> > getting this failure on maven 2.0 and

Re: Axis2 build??

2010-01-28 Thread Ruwan Linton
Andreas,

maven.test.skip property doesn't hold off for single mode tests. There are
some tests in axis2 of that sort but jaxws-integration tests are not.

Thanks,
Ruwan

On Thu, Jan 28, 2010 at 5:44 PM, Andreas Veithen
wrote:

> So this only happens with maven.test.skip=true? There is an open issue
> (AXIS2-3290) saying that maven.test.skip is not effective anyway and
> that to skip the tests, one should use test=false.
>
> Andreas
>
> On Thu, Jan 28, 2010 at 04:43, Ruwan Linton 
> wrote:
> > Hi Andreas and all,
> >
> > I sort of figured out the issue, this occurs when you skip tests using
> the
> > maven.test.skip system property. According to the maven documentation
> > maven.test.skip system property not only by passes running tests but also
> by
> > passes compiling tests as well.
> >
> > In this particular case, if the tests are not compiled, the build will be
> > failing because at the tes-compile phase, the ant-run plugin tries to
> create
> > a service archive out those compiled test classes, which is failing. Note
> > that, even though the above property by-passes compiling tests, it does
> not
> > by-pass the maven phase. (There is no way to by-pass phases in maven,
> AFAIK)
> >
> > Then I tried to put this ant task bit into a profile and tried to
> activate
> > it only when the tests are enabled, but maven doesn't seem to give me an
> > option to check whether the tests are enabled or not. Though I can track
> the
> > test disabled scenario, I cannot track the test enabled scenario.
> >
> > As the last option I tried to use the file based profile activation, to
> see
> > the compiled test classes exists or not to activate the ant task. This
> > approach also failed, since maven decides the activated profile at the
> start
> > of the execution at which point the file exists decision is wrong,
> ideally
> > if the profile activation decision should have been taken at the desired
> > phase, but I think there are technical limitations for maven to do so.
> >
> > So with the above analysis I couldn't get this solved, but fortunately
> maven
> > has an option to ask not to run the tests, but let it compile the tests,
> > using the system property called "skipTests".
> >
> > So the conclusion is use;
> >
> > mvn clean install -DskipTests
> >
> > instead of "mvn clean install -Dmaven.test.skip=true" if you want to skip
> > axis2 build tests.
> >
> > Thanks,
> > Ruwan
> >
> > On Thu, Jan 28, 2010 at 1:00 AM, Andreas Veithen <
> andreas.veit...@gmail.com>
> > wrote:
> >>
> >> For the moment I don't have any idea how to debug this. I was going to
> >> suggest setting the verbose option to true on the
> >> maven-compiler-plugin, but that doesn't seem to work.
> >>
> >> Andreas
> >>
> >> On Tue, Jan 26, 2010 at 02:40, Ruwan Linton 
> >> wrote:
> >> > Also, it is getting compiled when you run maven on the
> jaxws-integration
> >> > module, but not compiling when running on the axis2 build root :-(
> >> >
> >> > Any clue??
> >> >
> >> > Thanks,
> >> > Ruwan
> >> >
> >> > On Tue, Jan 26, 2010 at 7:38 AM, Ruwan Linton  >
> >> > wrote:
> >> >>
> >> >> Andreas,
> >> >>
> >> >> I drilled down the problem to not compiling the following test
> packages
> >> >> of
> >> >> jaxws-integration module on my machine;
> >> >>
> >> >> org.apache.axis2.jaxws.type_substitution
> >> >>
> >> >> Because of this the classes that are required for the
> >> >> AppleFinderService
> >> >> creating ant task is missing and cause the above error. I wonder
> >> >> whether the
> >> >> '_' character in the package name causes this issue.
> >> >>
> >> >> Trying to resolve the issue.
> >> >>
> >> >> Thanks,
> >> >> Ruwan
> >> >>
> >> >> On Tue, Jan 26, 2010 at 3:29 AM, Andreas Veithen
> >> >>  wrote:
> >> >>>
> >> >>> Ruwan,
> >> >>>
> >> >>> I just tested with the following combination, which is very close to
> >> >>> what you have (except for the OS):
> >> >>>
> >> >>> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> >> >>> Java version: 1.6.0_17
> >> >>> Java home:
> >> >>> /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> >> >>> Default locale: en_US, platform encoding: MacRoman
> >> >>> OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"
> >> >>>
> >> >>> Result: the build succeeds without any problems, so we still have no
> >> >>> clue what causes this issue.
> >> >>>
> >> >>> Andreas
> >> >>>
> >> >>> On Mon, Jan 25, 2010 at 17:37, Ruwan Linton  >
> >> >>> wrote:
> >> >>> >
> >> >>> >
> >> >>> > On Mon, Jan 25, 2010 at 9:03 PM, Andreas Veithen
> >> >>> > 
> >> >>> > wrote:
> >> >>> >>
> >> >>> >> On Mon, Jan 25, 2010 at 15:30, Ruwan Linton
> >> >>> >> 
> >> >>> >> wrote:
> >> >>> >> > Andreas,
> >> >>> >> >
> >> >>> >> > I don't have maven 2.0 right now to test this, but I was having
> >> >>> >> > this
> >> >>> >> > issue
> >> >>> >> > with maven 2.1.0 and JDK 1.5 as well. Does this means that you
> >> >>> >> > are
> >> >>> >> > not
> >> >>> >> > getting this failure on maven 2.0 and JDK 1.5??
> >>

Re: Axis2 build??

2010-01-28 Thread Andreas Veithen
So this only happens with maven.test.skip=true? There is an open issue
(AXIS2-3290) saying that maven.test.skip is not effective anyway and
that to skip the tests, one should use test=false.

Andreas

On Thu, Jan 28, 2010 at 04:43, Ruwan Linton  wrote:
> Hi Andreas and all,
>
> I sort of figured out the issue, this occurs when you skip tests using the
> maven.test.skip system property. According to the maven documentation
> maven.test.skip system property not only by passes running tests but also by
> passes compiling tests as well.
>
> In this particular case, if the tests are not compiled, the build will be
> failing because at the tes-compile phase, the ant-run plugin tries to create
> a service archive out those compiled test classes, which is failing. Note
> that, even though the above property by-passes compiling tests, it does not
> by-pass the maven phase. (There is no way to by-pass phases in maven, AFAIK)
>
> Then I tried to put this ant task bit into a profile and tried to activate
> it only when the tests are enabled, but maven doesn't seem to give me an
> option to check whether the tests are enabled or not. Though I can track the
> test disabled scenario, I cannot track the test enabled scenario.
>
> As the last option I tried to use the file based profile activation, to see
> the compiled test classes exists or not to activate the ant task. This
> approach also failed, since maven decides the activated profile at the start
> of the execution at which point the file exists decision is wrong, ideally
> if the profile activation decision should have been taken at the desired
> phase, but I think there are technical limitations for maven to do so.
>
> So with the above analysis I couldn't get this solved, but fortunately maven
> has an option to ask not to run the tests, but let it compile the tests,
> using the system property called "skipTests".
>
> So the conclusion is use;
>
> mvn clean install -DskipTests
>
> instead of "mvn clean install -Dmaven.test.skip=true" if you want to skip
> axis2 build tests.
>
> Thanks,
> Ruwan
>
> On Thu, Jan 28, 2010 at 1:00 AM, Andreas Veithen 
> wrote:
>>
>> For the moment I don't have any idea how to debug this. I was going to
>> suggest setting the verbose option to true on the
>> maven-compiler-plugin, but that doesn't seem to work.
>>
>> Andreas
>>
>> On Tue, Jan 26, 2010 at 02:40, Ruwan Linton 
>> wrote:
>> > Also, it is getting compiled when you run maven on the jaxws-integration
>> > module, but not compiling when running on the axis2 build root :-(
>> >
>> > Any clue??
>> >
>> > Thanks,
>> > Ruwan
>> >
>> > On Tue, Jan 26, 2010 at 7:38 AM, Ruwan Linton 
>> > wrote:
>> >>
>> >> Andreas,
>> >>
>> >> I drilled down the problem to not compiling the following test packages
>> >> of
>> >> jaxws-integration module on my machine;
>> >>
>> >> org.apache.axis2.jaxws.type_substitution
>> >>
>> >> Because of this the classes that are required for the
>> >> AppleFinderService
>> >> creating ant task is missing and cause the above error. I wonder
>> >> whether the
>> >> '_' character in the package name causes this issue.
>> >>
>> >> Trying to resolve the issue.
>> >>
>> >> Thanks,
>> >> Ruwan
>> >>
>> >> On Tue, Jan 26, 2010 at 3:29 AM, Andreas Veithen
>> >>  wrote:
>> >>>
>> >>> Ruwan,
>> >>>
>> >>> I just tested with the following combination, which is very close to
>> >>> what you have (except for the OS):
>> >>>
>> >>> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
>> >>> Java version: 1.6.0_17
>> >>> Java home:
>> >>> /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
>> >>> Default locale: en_US, platform encoding: MacRoman
>> >>> OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"
>> >>>
>> >>> Result: the build succeeds without any problems, so we still have no
>> >>> clue what causes this issue.
>> >>>
>> >>> Andreas
>> >>>
>> >>> On Mon, Jan 25, 2010 at 17:37, Ruwan Linton 
>> >>> wrote:
>> >>> >
>> >>> >
>> >>> > On Mon, Jan 25, 2010 at 9:03 PM, Andreas Veithen
>> >>> > 
>> >>> > wrote:
>> >>> >>
>> >>> >> On Mon, Jan 25, 2010 at 15:30, Ruwan Linton
>> >>> >> 
>> >>> >> wrote:
>> >>> >> > Andreas,
>> >>> >> >
>> >>> >> > I don't have maven 2.0 right now to test this, but I was having
>> >>> >> > this
>> >>> >> > issue
>> >>> >> > with maven 2.1.0 and JDK 1.5 as well. Does this means that you
>> >>> >> > are
>> >>> >> > not
>> >>> >> > getting this failure on maven 2.0 and JDK 1.5??
>> >>> >>
>> >>> >> I've never seen the AppleFinderService failure myself, and I use
>> >>> >> Maven
>> >>> >> 2.0 with JDK 1.5. Searching the mailing list archives for
>> >>> >> "AppleFinderService" indicates that the issue only occurs in
>> >>> >> particular build environments, since for most people the build just
>> >>> >> runs fine.
>> >>> >>
>> >>> >> > Anyway if this is failing on at least one environment we should
>> >>> >> > get
>> >>> >> > that
>> >>> >> > fixed.
>> >>> >>
>> >>> >> +1, but to be able to fix it, we first need to re

Re: Axis2 build??

2010-01-27 Thread Ruwan Linton
Hi Andreas and all,

I sort of figured out the issue, this occurs when you skip tests using the
maven.test.skip system property. According to the maven documentation
maven.test.skip system property not only by passes running tests but also by
passes compiling tests as well.

In this particular case, if the tests are not compiled, the build will be
failing because at the tes-compile phase, the ant-run plugin tries to create
a service archive out those compiled test classes, which is failing. Note
that, even though the above property by-passes compiling tests, it does not
by-pass the maven phase. (There is no way to by-pass phases in maven, AFAIK)

Then I tried to put this ant task bit into a profile and tried to activate
it only when the tests are enabled, but maven doesn't seem to give me an
option to check whether the tests are enabled or not. Though I can track the
test disabled scenario, I cannot track the test enabled scenario.

As the last option I tried to use the file based profile activation, to see
the compiled test classes exists or not to activate the ant task. This
approach also failed, since maven decides the activated profile at the start
of the execution at which point the file exists decision is wrong, ideally
if the profile activation decision should have been taken at the desired
phase, but I think there are technical limitations for maven to do so.

So with the above analysis I couldn't get this solved, but fortunately maven
has an option to ask not to run the tests, but let it compile the tests,
using the system property called "skipTests".

So the conclusion is use;

mvn clean install -DskipTests

instead of "mvn clean install -Dmaven.test.skip=true" if you want to skip
axis2 build tests.

Thanks,
Ruwan

On Thu, Jan 28, 2010 at 1:00 AM, Andreas Veithen
wrote:

> For the moment I don't have any idea how to debug this. I was going to
> suggest setting the verbose option to true on the
> maven-compiler-plugin, but that doesn't seem to work.
>
> Andreas
>
> On Tue, Jan 26, 2010 at 02:40, Ruwan Linton 
> wrote:
> > Also, it is getting compiled when you run maven on the jaxws-integration
> > module, but not compiling when running on the axis2 build root :-(
> >
> > Any clue??
> >
> > Thanks,
> > Ruwan
> >
> > On Tue, Jan 26, 2010 at 7:38 AM, Ruwan Linton 
> > wrote:
> >>
> >> Andreas,
> >>
> >> I drilled down the problem to not compiling the following test packages
> of
> >> jaxws-integration module on my machine;
> >>
> >> org.apache.axis2.jaxws.type_substitution
> >>
> >> Because of this the classes that are required for the AppleFinderService
> >> creating ant task is missing and cause the above error. I wonder whether
> the
> >> '_' character in the package name causes this issue.
> >>
> >> Trying to resolve the issue.
> >>
> >> Thanks,
> >> Ruwan
> >>
> >> On Tue, Jan 26, 2010 at 3:29 AM, Andreas Veithen
> >>  wrote:
> >>>
> >>> Ruwan,
> >>>
> >>> I just tested with the following combination, which is very close to
> >>> what you have (except for the OS):
> >>>
> >>> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> >>> Java version: 1.6.0_17
> >>> Java home:
> >>> /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> >>> Default locale: en_US, platform encoding: MacRoman
> >>> OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"
> >>>
> >>> Result: the build succeeds without any problems, so we still have no
> >>> clue what causes this issue.
> >>>
> >>> Andreas
> >>>
> >>> On Mon, Jan 25, 2010 at 17:37, Ruwan Linton 
> >>> wrote:
> >>> >
> >>> >
> >>> > On Mon, Jan 25, 2010 at 9:03 PM, Andreas Veithen
> >>> > 
> >>> > wrote:
> >>> >>
> >>> >> On Mon, Jan 25, 2010 at 15:30, Ruwan Linton  >
> >>> >> wrote:
> >>> >> > Andreas,
> >>> >> >
> >>> >> > I don't have maven 2.0 right now to test this, but I was having
> this
> >>> >> > issue
> >>> >> > with maven 2.1.0 and JDK 1.5 as well. Does this means that you are
> >>> >> > not
> >>> >> > getting this failure on maven 2.0 and JDK 1.5??
> >>> >>
> >>> >> I've never seen the AppleFinderService failure myself, and I use
> Maven
> >>> >> 2.0 with JDK 1.5. Searching the mailing list archives for
> >>> >> "AppleFinderService" indicates that the issue only occurs in
> >>> >> particular build environments, since for most people the build just
> >>> >> runs fine.
> >>> >>
> >>> >> > Anyway if this is failing on at least one environment we should
> get
> >>> >> > that
> >>> >> > fixed.
> >>> >>
> >>> >> +1, but to be able to fix it, we first need to reproduce it. If I
> get
> >>> >> the time later today, I will try the build with Maven 2.2 and JDK
> 1.6.
> >>> >
> >>> > Thanks, at the same time I am trying to fix it at my end too.
> >>> >
> >>> > Ruwan
> >>> >
> >>> >>
> >>> >> > Thanks,
> >>> >> > Ruwan
> >>> >> >
> >>> >> > On Mon, Jan 25, 2010 at 2:30 PM, Andreas Veithen
> >>> >> > 
> >>> >> > wrote:
> >>> >> >>
> >>> >> >> It is a known issue in the sense that several people complained
> >>> >> >> about
> >>> >> 

Re: Axis2 build??

2010-01-27 Thread Andreas Veithen
For the moment I don't have any idea how to debug this. I was going to
suggest setting the verbose option to true on the
maven-compiler-plugin, but that doesn't seem to work.

Andreas

On Tue, Jan 26, 2010 at 02:40, Ruwan Linton  wrote:
> Also, it is getting compiled when you run maven on the jaxws-integration
> module, but not compiling when running on the axis2 build root :-(
>
> Any clue??
>
> Thanks,
> Ruwan
>
> On Tue, Jan 26, 2010 at 7:38 AM, Ruwan Linton 
> wrote:
>>
>> Andreas,
>>
>> I drilled down the problem to not compiling the following test packages of
>> jaxws-integration module on my machine;
>>
>> org.apache.axis2.jaxws.type_substitution
>>
>> Because of this the classes that are required for the AppleFinderService
>> creating ant task is missing and cause the above error. I wonder whether the
>> '_' character in the package name causes this issue.
>>
>> Trying to resolve the issue.
>>
>> Thanks,
>> Ruwan
>>
>> On Tue, Jan 26, 2010 at 3:29 AM, Andreas Veithen
>>  wrote:
>>>
>>> Ruwan,
>>>
>>> I just tested with the following combination, which is very close to
>>> what you have (except for the OS):
>>>
>>> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
>>> Java version: 1.6.0_17
>>> Java home:
>>> /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
>>> Default locale: en_US, platform encoding: MacRoman
>>> OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"
>>>
>>> Result: the build succeeds without any problems, so we still have no
>>> clue what causes this issue.
>>>
>>> Andreas
>>>
>>> On Mon, Jan 25, 2010 at 17:37, Ruwan Linton 
>>> wrote:
>>> >
>>> >
>>> > On Mon, Jan 25, 2010 at 9:03 PM, Andreas Veithen
>>> > 
>>> > wrote:
>>> >>
>>> >> On Mon, Jan 25, 2010 at 15:30, Ruwan Linton 
>>> >> wrote:
>>> >> > Andreas,
>>> >> >
>>> >> > I don't have maven 2.0 right now to test this, but I was having this
>>> >> > issue
>>> >> > with maven 2.1.0 and JDK 1.5 as well. Does this means that you are
>>> >> > not
>>> >> > getting this failure on maven 2.0 and JDK 1.5??
>>> >>
>>> >> I've never seen the AppleFinderService failure myself, and I use Maven
>>> >> 2.0 with JDK 1.5. Searching the mailing list archives for
>>> >> "AppleFinderService" indicates that the issue only occurs in
>>> >> particular build environments, since for most people the build just
>>> >> runs fine.
>>> >>
>>> >> > Anyway if this is failing on at least one environment we should get
>>> >> > that
>>> >> > fixed.
>>> >>
>>> >> +1, but to be able to fix it, we first need to reproduce it. If I get
>>> >> the time later today, I will try the build with Maven 2.2 and JDK 1.6.
>>> >
>>> > Thanks, at the same time I am trying to fix it at my end too.
>>> >
>>> > Ruwan
>>> >
>>> >>
>>> >> > Thanks,
>>> >> > Ruwan
>>> >> >
>>> >> > On Mon, Jan 25, 2010 at 2:30 PM, Andreas Veithen
>>> >> > 
>>> >> > wrote:
>>> >> >>
>>> >> >> It is a known issue in the sense that several people complained
>>> >> >> about
>>> >> >> it, but AFAIK until now, nobody ever provided detailed information
>>> >> >> about it. Do you also experience that failure with Maven 2.0 and
>>> >> >> JDK
>>> >> >> 1.5?
>>> >> >>
>>> >> >> Andreas
>>> >> >>
>>> >> >> On Mon, Jan 25, 2010 at 03:47, Ruwan Linton
>>> >> >> 
>>> >> >> wrote:
>>> >> >> > Folks,
>>> >> >> >
>>> >> >> > I cannot do a "mvn clean install" on the root of the axis2 build,
>>> >> >> > which
>>> >> >> > blames me for a missing AppleFinderService. Is this a known
>>> >> >> > issue, if
>>> >> >> > so
>>> >> >> > why
>>> >> >> > don't we get this fixed.
>>> >> >> >
>>> >> >> > My build environment is;
>>> >> >> > mvn --version
>>> >> >> > Apache Maven 2.2.1 (r801777; 2009-08-07 01:16:01+0600)
>>> >> >> > Java version: 1.6.0_18
>>> >> >> > Java home: /opt/jdk1.6.0_18/jre
>>> >> >> > Default locale: en_US, platform encoding: UTF-8
>>> >> >> > OS name: "linux" version: "2.6.31-17-generic" arch: "amd64"
>>> >> >> > Family:
>>> >> >> > "unix"
>>> >> >> >
>>> >> >> > Thanks,
>>> >> >> > Ruwan
>>> >> >> >
>>> >> >> > --
>>> >> >> > Ruwan Linton
>>> >> >> > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>>> >> >> > WSO2 Inc.; http://wso2.org
>>> >> >> > email: ru...@wso2.com; cell: +94 77 341 3097
>>> >> >> > blog: http://ruwansblog.blogspot.com
>>> >> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Ruwan Linton
>>> >> > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>>> >> > WSO2 Inc.; http://wso2.org
>>> >> > email: ru...@wso2.com; cell: +94 77 341 3097
>>> >> > blog: http://ruwansblog.blogspot.com
>>> >> >
>>> >
>>> >
>>> >
>>> > --
>>> > Ruwan Linton
>>> > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>>> > WSO2 Inc.; http://wso2.org
>>> > email: ru...@wso2.com; cell: +94 77 341 3097
>>> > blog: http://ruwansblog.blogspot.com
>>> >
>>
>>
>>
>> --
>> Ruwan Linton
>> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>> WSO2 Inc.; http://wso2.org
>> email: ru...@wso2.com; cell: +94 77 341 3097
>> blog: http:

Re: Axis2 build??

2010-01-26 Thread Hiranya Jayathilaka
On Mon, Jan 25, 2010 at 2:00 PM, Andreas Veithen
wrote:

> It is a known issue in the sense that several people complained about
> it, but AFAIK until now, nobody ever provided detailed information
> about it.


Please refer AXIS2-4460 for an error report I posted months back. The
attachment 'attempt3.log' contains the error in question.

Thanks,
Hiranya


> Do you also experience that failure with Maven 2.0 and JDK
> 1.5?
>
> Andreas
>
> On Mon, Jan 25, 2010 at 03:47, Ruwan Linton 
> wrote:
> > Folks,
> >
> > I cannot do a "mvn clean install" on the root of the axis2 build, which
> > blames me for a missing AppleFinderService. Is this a known issue, if so
> why
> > don't we get this fixed.
> >
> > My build environment is;
> > mvn --version
> > Apache Maven 2.2.1 (r801777; 2009-08-07 01:16:01+0600)
> > Java version: 1.6.0_18
> > Java home: /opt/jdk1.6.0_18/jre
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "linux" version: "2.6.31-17-generic" arch: "amd64" Family:
> "unix"
> >
> > Thanks,
> > Ruwan
> >
> > --
> > Ruwan Linton
> > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
> > WSO2 Inc.; http://wso2.org
> > email: ru...@wso2.com; cell: +94 77 341 3097
> > blog: http://ruwansblog.blogspot.com
> >
>



-- 
Hiranya Jayathilaka
Software Engineer;
WSO2 Inc.;  http://wso2.org
E-mail: hira...@wso2.com;  Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com


Re: Axis2 build??

2010-01-25 Thread Ruwan Linton
Also, it is getting compiled when you run maven on the jaxws-integration
module, but not compiling when running on the axis2 build root :-(

Any clue??

Thanks,
Ruwan

On Tue, Jan 26, 2010 at 7:38 AM, Ruwan Linton wrote:

> Andreas,
>
> I drilled down the problem to not compiling the following test packages of
> jaxws-integration module on my machine;
>
> org.apache.axis2.jaxws.type_substitution
>
> Because of this the classes that are required for the AppleFinderService
> creating ant task is missing and cause the above error. I wonder whether the
> '_' character in the package name causes this issue.
>
> Trying to resolve the issue.
>
> Thanks,
> Ruwan
>
>
> On Tue, Jan 26, 2010 at 3:29 AM, Andreas Veithen <
> andreas.veit...@gmail.com> wrote:
>
>> Ruwan,
>>
>> I just tested with the following combination, which is very close to
>> what you have (except for the OS):
>>
>> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
>> Java version: 1.6.0_17
>> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
>> Default locale: en_US, platform encoding: MacRoman
>> OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"
>>
>> Result: the build succeeds without any problems, so we still have no
>> clue what causes this issue.
>>
>> Andreas
>>
>> On Mon, Jan 25, 2010 at 17:37, Ruwan Linton 
>> wrote:
>> >
>> >
>> > On Mon, Jan 25, 2010 at 9:03 PM, Andreas Veithen <
>> andreas.veit...@gmail.com>
>> > wrote:
>> >>
>> >> On Mon, Jan 25, 2010 at 15:30, Ruwan Linton 
>> >> wrote:
>> >> > Andreas,
>> >> >
>> >> > I don't have maven 2.0 right now to test this, but I was having this
>> >> > issue
>> >> > with maven 2.1.0 and JDK 1.5 as well. Does this means that you are
>> not
>> >> > getting this failure on maven 2.0 and JDK 1.5??
>> >>
>> >> I've never seen the AppleFinderService failure myself, and I use Maven
>> >> 2.0 with JDK 1.5. Searching the mailing list archives for
>> >> "AppleFinderService" indicates that the issue only occurs in
>> >> particular build environments, since for most people the build just
>> >> runs fine.
>> >>
>> >> > Anyway if this is failing on at least one environment we should get
>> that
>> >> > fixed.
>> >>
>> >> +1, but to be able to fix it, we first need to reproduce it. If I get
>> >> the time later today, I will try the build with Maven 2.2 and JDK 1.6.
>> >
>> > Thanks, at the same time I am trying to fix it at my end too.
>> >
>> > Ruwan
>> >
>> >>
>> >> > Thanks,
>> >> > Ruwan
>> >> >
>> >> > On Mon, Jan 25, 2010 at 2:30 PM, Andreas Veithen
>> >> > 
>> >> > wrote:
>> >> >>
>> >> >> It is a known issue in the sense that several people complained
>> about
>> >> >> it, but AFAIK until now, nobody ever provided detailed information
>> >> >> about it. Do you also experience that failure with Maven 2.0 and JDK
>> >> >> 1.5?
>> >> >>
>> >> >> Andreas
>> >> >>
>> >> >> On Mon, Jan 25, 2010 at 03:47, Ruwan Linton > >
>> >> >> wrote:
>> >> >> > Folks,
>> >> >> >
>> >> >> > I cannot do a "mvn clean install" on the root of the axis2 build,
>> >> >> > which
>> >> >> > blames me for a missing AppleFinderService. Is this a known issue,
>> if
>> >> >> > so
>> >> >> > why
>> >> >> > don't we get this fixed.
>> >> >> >
>> >> >> > My build environment is;
>> >> >> > mvn --version
>> >> >> > Apache Maven 2.2.1 (r801777; 2009-08-07 01:16:01+0600)
>> >> >> > Java version: 1.6.0_18
>> >> >> > Java home: /opt/jdk1.6.0_18/jre
>> >> >> > Default locale: en_US, platform encoding: UTF-8
>> >> >> > OS name: "linux" version: "2.6.31-17-generic" arch: "amd64"
>> Family:
>> >> >> > "unix"
>> >> >> >
>> >> >> > Thanks,
>> >> >> > Ruwan
>> >> >> >
>> >> >> > --
>> >> >> > Ruwan Linton
>> >> >> > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>> >> >> > WSO2 Inc.; http://wso2.org
>> >> >> > email: ru...@wso2.com; cell: +94 77 341 3097
>> >> >> > blog: http://ruwansblog.blogspot.com
>> >> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Ruwan Linton
>> >> > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>> >> > WSO2 Inc.; http://wso2.org
>> >> > email: ru...@wso2.com; cell: +94 77 341 3097
>> >> > blog: http://ruwansblog.blogspot.com
>> >> >
>> >
>> >
>> >
>> > --
>> > Ruwan Linton
>> > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>> > WSO2 Inc.; http://wso2.org
>> > email: ru...@wso2.com; cell: +94 77 341 3097
>> > blog: http://ruwansblog.blogspot.com
>> >
>>
>
>
>
> --
> Ruwan Linton
> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
> WSO2 Inc.; http://wso2.org
> email: ru...@wso2.com; cell: +94 77 341 3097
> blog: http://ruwansblog.blogspot.com
>



-- 
Ruwan Linton
Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ru...@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com


Re: Axis2 build??

2010-01-25 Thread Ruwan Linton
Andreas,

I drilled down the problem to not compiling the following test packages of
jaxws-integration module on my machine;

org.apache.axis2.jaxws.type_substitution

Because of this the classes that are required for the AppleFinderService
creating ant task is missing and cause the above error. I wonder whether the
'_' character in the package name causes this issue.

Trying to resolve the issue.

Thanks,
Ruwan

On Tue, Jan 26, 2010 at 3:29 AM, Andreas Veithen
wrote:

> Ruwan,
>
> I just tested with the following combination, which is very close to
> what you have (except for the OS):
>
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_17
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"
>
> Result: the build succeeds without any problems, so we still have no
> clue what causes this issue.
>
> Andreas
>
> On Mon, Jan 25, 2010 at 17:37, Ruwan Linton 
> wrote:
> >
> >
> > On Mon, Jan 25, 2010 at 9:03 PM, Andreas Veithen <
> andreas.veit...@gmail.com>
> > wrote:
> >>
> >> On Mon, Jan 25, 2010 at 15:30, Ruwan Linton 
> >> wrote:
> >> > Andreas,
> >> >
> >> > I don't have maven 2.0 right now to test this, but I was having this
> >> > issue
> >> > with maven 2.1.0 and JDK 1.5 as well. Does this means that you are not
> >> > getting this failure on maven 2.0 and JDK 1.5??
> >>
> >> I've never seen the AppleFinderService failure myself, and I use Maven
> >> 2.0 with JDK 1.5. Searching the mailing list archives for
> >> "AppleFinderService" indicates that the issue only occurs in
> >> particular build environments, since for most people the build just
> >> runs fine.
> >>
> >> > Anyway if this is failing on at least one environment we should get
> that
> >> > fixed.
> >>
> >> +1, but to be able to fix it, we first need to reproduce it. If I get
> >> the time later today, I will try the build with Maven 2.2 and JDK 1.6.
> >
> > Thanks, at the same time I am trying to fix it at my end too.
> >
> > Ruwan
> >
> >>
> >> > Thanks,
> >> > Ruwan
> >> >
> >> > On Mon, Jan 25, 2010 at 2:30 PM, Andreas Veithen
> >> > 
> >> > wrote:
> >> >>
> >> >> It is a known issue in the sense that several people complained about
> >> >> it, but AFAIK until now, nobody ever provided detailed information
> >> >> about it. Do you also experience that failure with Maven 2.0 and JDK
> >> >> 1.5?
> >> >>
> >> >> Andreas
> >> >>
> >> >> On Mon, Jan 25, 2010 at 03:47, Ruwan Linton 
> >> >> wrote:
> >> >> > Folks,
> >> >> >
> >> >> > I cannot do a "mvn clean install" on the root of the axis2 build,
> >> >> > which
> >> >> > blames me for a missing AppleFinderService. Is this a known issue,
> if
> >> >> > so
> >> >> > why
> >> >> > don't we get this fixed.
> >> >> >
> >> >> > My build environment is;
> >> >> > mvn --version
> >> >> > Apache Maven 2.2.1 (r801777; 2009-08-07 01:16:01+0600)
> >> >> > Java version: 1.6.0_18
> >> >> > Java home: /opt/jdk1.6.0_18/jre
> >> >> > Default locale: en_US, platform encoding: UTF-8
> >> >> > OS name: "linux" version: "2.6.31-17-generic" arch: "amd64" Family:
> >> >> > "unix"
> >> >> >
> >> >> > Thanks,
> >> >> > Ruwan
> >> >> >
> >> >> > --
> >> >> > Ruwan Linton
> >> >> > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
> >> >> > WSO2 Inc.; http://wso2.org
> >> >> > email: ru...@wso2.com; cell: +94 77 341 3097
> >> >> > blog: http://ruwansblog.blogspot.com
> >> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Ruwan Linton
> >> > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
> >> > WSO2 Inc.; http://wso2.org
> >> > email: ru...@wso2.com; cell: +94 77 341 3097
> >> > blog: http://ruwansblog.blogspot.com
> >> >
> >
> >
> >
> > --
> > Ruwan Linton
> > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
> > WSO2 Inc.; http://wso2.org
> > email: ru...@wso2.com; cell: +94 77 341 3097
> > blog: http://ruwansblog.blogspot.com
> >
>



-- 
Ruwan Linton
Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ru...@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com


Re: Axis2 build??

2010-01-25 Thread Andreas Veithen
Ruwan,

I just tested with the following combination, which is very close to
what you have (except for the OS):

Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_17
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"

Result: the build succeeds without any problems, so we still have no
clue what causes this issue.

Andreas

On Mon, Jan 25, 2010 at 17:37, Ruwan Linton  wrote:
>
>
> On Mon, Jan 25, 2010 at 9:03 PM, Andreas Veithen 
> wrote:
>>
>> On Mon, Jan 25, 2010 at 15:30, Ruwan Linton 
>> wrote:
>> > Andreas,
>> >
>> > I don't have maven 2.0 right now to test this, but I was having this
>> > issue
>> > with maven 2.1.0 and JDK 1.5 as well. Does this means that you are not
>> > getting this failure on maven 2.0 and JDK 1.5??
>>
>> I've never seen the AppleFinderService failure myself, and I use Maven
>> 2.0 with JDK 1.5. Searching the mailing list archives for
>> "AppleFinderService" indicates that the issue only occurs in
>> particular build environments, since for most people the build just
>> runs fine.
>>
>> > Anyway if this is failing on at least one environment we should get that
>> > fixed.
>>
>> +1, but to be able to fix it, we first need to reproduce it. If I get
>> the time later today, I will try the build with Maven 2.2 and JDK 1.6.
>
> Thanks, at the same time I am trying to fix it at my end too.
>
> Ruwan
>
>>
>> > Thanks,
>> > Ruwan
>> >
>> > On Mon, Jan 25, 2010 at 2:30 PM, Andreas Veithen
>> > 
>> > wrote:
>> >>
>> >> It is a known issue in the sense that several people complained about
>> >> it, but AFAIK until now, nobody ever provided detailed information
>> >> about it. Do you also experience that failure with Maven 2.0 and JDK
>> >> 1.5?
>> >>
>> >> Andreas
>> >>
>> >> On Mon, Jan 25, 2010 at 03:47, Ruwan Linton 
>> >> wrote:
>> >> > Folks,
>> >> >
>> >> > I cannot do a "mvn clean install" on the root of the axis2 build,
>> >> > which
>> >> > blames me for a missing AppleFinderService. Is this a known issue, if
>> >> > so
>> >> > why
>> >> > don't we get this fixed.
>> >> >
>> >> > My build environment is;
>> >> > mvn --version
>> >> > Apache Maven 2.2.1 (r801777; 2009-08-07 01:16:01+0600)
>> >> > Java version: 1.6.0_18
>> >> > Java home: /opt/jdk1.6.0_18/jre
>> >> > Default locale: en_US, platform encoding: UTF-8
>> >> > OS name: "linux" version: "2.6.31-17-generic" arch: "amd64" Family:
>> >> > "unix"
>> >> >
>> >> > Thanks,
>> >> > Ruwan
>> >> >
>> >> > --
>> >> > Ruwan Linton
>> >> > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>> >> > WSO2 Inc.; http://wso2.org
>> >> > email: ru...@wso2.com; cell: +94 77 341 3097
>> >> > blog: http://ruwansblog.blogspot.com
>> >> >
>> >
>> >
>> >
>> > --
>> > Ruwan Linton
>> > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>> > WSO2 Inc.; http://wso2.org
>> > email: ru...@wso2.com; cell: +94 77 341 3097
>> > blog: http://ruwansblog.blogspot.com
>> >
>
>
>
> --
> Ruwan Linton
> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
> WSO2 Inc.; http://wso2.org
> email: ru...@wso2.com; cell: +94 77 341 3097
> blog: http://ruwansblog.blogspot.com
>


Re: Axis2 build??

2010-01-25 Thread Ruwan Linton
On Mon, Jan 25, 2010 at 9:03 PM, Andreas Veithen
wrote:

> On Mon, Jan 25, 2010 at 15:30, Ruwan Linton 
> wrote:
> > Andreas,
> >
> > I don't have maven 2.0 right now to test this, but I was having this
> issue
> > with maven 2.1.0 and JDK 1.5 as well. Does this means that you are not
> > getting this failure on maven 2.0 and JDK 1.5??
>
> I've never seen the AppleFinderService failure myself, and I use Maven
> 2.0 with JDK 1.5. Searching the mailing list archives for
> "AppleFinderService" indicates that the issue only occurs in
> particular build environments, since for most people the build just
> runs fine.
>
> > Anyway if this is failing on at least one environment we should get that
> > fixed.
>
> +1, but to be able to fix it, we first need to reproduce it. If I get
> the time later today, I will try the build with Maven 2.2 and JDK 1.6.
>

Thanks, at the same time I am trying to fix it at my end too.

Ruwan


>
> > Thanks,
> > Ruwan
> >
> > On Mon, Jan 25, 2010 at 2:30 PM, Andreas Veithen <
> andreas.veit...@gmail.com>
> > wrote:
> >>
> >> It is a known issue in the sense that several people complained about
> >> it, but AFAIK until now, nobody ever provided detailed information
> >> about it. Do you also experience that failure with Maven 2.0 and JDK
> >> 1.5?
> >>
> >> Andreas
> >>
> >> On Mon, Jan 25, 2010 at 03:47, Ruwan Linton 
> >> wrote:
> >> > Folks,
> >> >
> >> > I cannot do a "mvn clean install" on the root of the axis2 build,
> which
> >> > blames me for a missing AppleFinderService. Is this a known issue, if
> so
> >> > why
> >> > don't we get this fixed.
> >> >
> >> > My build environment is;
> >> > mvn --version
> >> > Apache Maven 2.2.1 (r801777; 2009-08-07 01:16:01+0600)
> >> > Java version: 1.6.0_18
> >> > Java home: /opt/jdk1.6.0_18/jre
> >> > Default locale: en_US, platform encoding: UTF-8
> >> > OS name: "linux" version: "2.6.31-17-generic" arch: "amd64" Family:
> >> > "unix"
> >> >
> >> > Thanks,
> >> > Ruwan
> >> >
> >> > --
> >> > Ruwan Linton
> >> > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
> >> > WSO2 Inc.; http://wso2.org
> >> > email: ru...@wso2.com; cell: +94 77 341 3097
> >> > blog: http://ruwansblog.blogspot.com
> >> >
> >
> >
> >
> > --
> > Ruwan Linton
> > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
> > WSO2 Inc.; http://wso2.org
> > email: ru...@wso2.com; cell: +94 77 341 3097
> > blog: http://ruwansblog.blogspot.com
> >
>



-- 
Ruwan Linton
Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ru...@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com


Re: Axis2 build??

2010-01-25 Thread Andreas Veithen
On Mon, Jan 25, 2010 at 15:30, Ruwan Linton  wrote:
> Andreas,
>
> I don't have maven 2.0 right now to test this, but I was having this issue
> with maven 2.1.0 and JDK 1.5 as well. Does this means that you are not
> getting this failure on maven 2.0 and JDK 1.5??

I've never seen the AppleFinderService failure myself, and I use Maven
2.0 with JDK 1.5. Searching the mailing list archives for
"AppleFinderService" indicates that the issue only occurs in
particular build environments, since for most people the build just
runs fine.

> Anyway if this is failing on at least one environment we should get that
> fixed.

+1, but to be able to fix it, we first need to reproduce it. If I get
the time later today, I will try the build with Maven 2.2 and JDK 1.6.

> Thanks,
> Ruwan
>
> On Mon, Jan 25, 2010 at 2:30 PM, Andreas Veithen 
> wrote:
>>
>> It is a known issue in the sense that several people complained about
>> it, but AFAIK until now, nobody ever provided detailed information
>> about it. Do you also experience that failure with Maven 2.0 and JDK
>> 1.5?
>>
>> Andreas
>>
>> On Mon, Jan 25, 2010 at 03:47, Ruwan Linton 
>> wrote:
>> > Folks,
>> >
>> > I cannot do a "mvn clean install" on the root of the axis2 build, which
>> > blames me for a missing AppleFinderService. Is this a known issue, if so
>> > why
>> > don't we get this fixed.
>> >
>> > My build environment is;
>> > mvn --version
>> > Apache Maven 2.2.1 (r801777; 2009-08-07 01:16:01+0600)
>> > Java version: 1.6.0_18
>> > Java home: /opt/jdk1.6.0_18/jre
>> > Default locale: en_US, platform encoding: UTF-8
>> > OS name: "linux" version: "2.6.31-17-generic" arch: "amd64" Family:
>> > "unix"
>> >
>> > Thanks,
>> > Ruwan
>> >
>> > --
>> > Ruwan Linton
>> > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>> > WSO2 Inc.; http://wso2.org
>> > email: ru...@wso2.com; cell: +94 77 341 3097
>> > blog: http://ruwansblog.blogspot.com
>> >
>
>
>
> --
> Ruwan Linton
> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
> WSO2 Inc.; http://wso2.org
> email: ru...@wso2.com; cell: +94 77 341 3097
> blog: http://ruwansblog.blogspot.com
>


Re: Axis2 build??

2010-01-25 Thread Ruwan Linton
Andreas,

I don't have maven 2.0 right now to test this, but I was having this issue
with maven 2.1.0 and JDK 1.5 as well. Does this means that you are not
getting this failure on maven 2.0 and JDK 1.5??

Anyway if this is failing on at least one environment we should get that
fixed.

Thanks,
Ruwan

On Mon, Jan 25, 2010 at 2:30 PM, Andreas Veithen
wrote:

> It is a known issue in the sense that several people complained about
> it, but AFAIK until now, nobody ever provided detailed information
> about it. Do you also experience that failure with Maven 2.0 and JDK
> 1.5?
>
> Andreas
>
> On Mon, Jan 25, 2010 at 03:47, Ruwan Linton 
> wrote:
> > Folks,
> >
> > I cannot do a "mvn clean install" on the root of the axis2 build, which
> > blames me for a missing AppleFinderService. Is this a known issue, if so
> why
> > don't we get this fixed.
> >
> > My build environment is;
> > mvn --version
> > Apache Maven 2.2.1 (r801777; 2009-08-07 01:16:01+0600)
> > Java version: 1.6.0_18
> > Java home: /opt/jdk1.6.0_18/jre
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "linux" version: "2.6.31-17-generic" arch: "amd64" Family:
> "unix"
> >
> > Thanks,
> > Ruwan
> >
> > --
> > Ruwan Linton
> > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
> > WSO2 Inc.; http://wso2.org
> > email: ru...@wso2.com; cell: +94 77 341 3097
> > blog: http://ruwansblog.blogspot.com
> >
>



-- 
Ruwan Linton
Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ru...@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com


Re: Axis2 build??

2010-01-25 Thread Andreas Veithen
It is a known issue in the sense that several people complained about
it, but AFAIK until now, nobody ever provided detailed information
about it. Do you also experience that failure with Maven 2.0 and JDK
1.5?

Andreas

On Mon, Jan 25, 2010 at 03:47, Ruwan Linton  wrote:
> Folks,
>
> I cannot do a "mvn clean install" on the root of the axis2 build, which
> blames me for a missing AppleFinderService. Is this a known issue, if so why
> don't we get this fixed.
>
> My build environment is;
> mvn --version
> Apache Maven 2.2.1 (r801777; 2009-08-07 01:16:01+0600)
> Java version: 1.6.0_18
> Java home: /opt/jdk1.6.0_18/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.31-17-generic" arch: "amd64" Family: "unix"
>
> Thanks,
> Ruwan
>
> --
> Ruwan Linton
> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
> WSO2 Inc.; http://wso2.org
> email: ru...@wso2.com; cell: +94 77 341 3097
> blog: http://ruwansblog.blogspot.com
>


Re: Axis2 1.5.1 service handling is very slow

2010-01-13 Thread Andreas Veithen
The issue seems to be as follows:

* For POJO services, Axis2 uses the JRE's bean introspector to detect
the properties of the POJOs.
* Following the Java Beans standard, the introspector attempts to find
BeanInfo classes corresponding to these POJOs. BeanInfo classes are
optional and rarely used in this context.
* Axis2 uses the service class loader to introspect the beans. This is
not a standard class loader, but a component specific to Axis2
(DeploymentClassLoader) which uses a different strategy to load the
classes. I had a quick look at the code, and it appears that in order
to load a class, it needs to scan all the JARs used by the service
archive.

Conclusion: in this case, Axis2 repeatedly attempts to load non
existing classes from a class loader that uses a suboptimal strategy
to load resources from JARs.

Unfortunately, I'm not very familiar with the POJO and class loading
parts of Axis2. Maybe some of the other developers can shed some light
on the following questions:

* Shouldn't the POJO code cache the results returned by the bean introspector?
* Why is the DeploymentClassLoader implemented in this way? My guess
is that it is to avoid file locking issues. Thus, it is only used when
hot deployment is enabled?

Andreas

On Wed, Jan 13, 2010 at 15:24, Martin Gerner
 wrote:
> I've attached a full thread dump. I'd greatly appreciate any help in
> determining the cause, as I'm quite a novice when it comes to Axis2 and its
> internal workings. CPU usage for the java process goes up to 100% when it's
> blocking.
>
> The top parts of a few dumps (taken at different times to get an idea about
> whether it's the same thing blocking):
>
> "HttpConnection-8080-1" prio=10 tid=0x08c06c00 nid=0x1c77 runnable
> [0x2e9fe000]
>  java.lang.Thread.State: RUNNABLE
>       at java.util.zip.Inflater.inflateBytes(Native Method)
>       at java.util.zip.Inflater.inflate(Inflater.java:223)
>       - locked <0xa65b86e0> (a java.util.zip.Inflater)
>       at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:135)
>       at java.util.zip.ZipInputStream.read(ZipInputStream.java:146)
>       at java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:92)
>       at java.util.zip.ZipInputStream.getNextEntry(ZipInputStream.java:70)
>       at
> org.apache.axis2.deployment.DeploymentClassLoader.getBytes(DeploymentClassLoader.java:198)
>       at
> org.apache.axis2.deployment.DeploymentClassLoader.getBytes(DeploymentClassLoader.java:178)
>       at
> org.apache.axis2.deployment.DeploymentClassLoader.findClass(DeploymentClassLoader.java:81)
>       at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
>       - locked <0x34220a70> (a
> org.apache.axis2.deployment.DeploymentClassLoader)
>       at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
>       at java.beans.Introspector.instantiate(Introspector.java:1453)
>      [...]
>
>
> 
>
> "HttpConnection-8080-2" prio=10 tid=0x08a4fc00 nid=0x1cf6 runnable
> [0x2e9ad000]
>  java.lang.Thread.State: RUNNABLE
>       at java.util.zip.ZipInputStream.readFully(ZipInputStream.java:403)
>       at java.util.zip.ZipInputStream.readEnd(ZipInputStream.java:361)
>       at java.util.zip.ZipInputStream.read(ZipInputStream.java:148)
>       at java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:92)
>       at java.util.zip.ZipInputStream.getNextEntry(ZipInputStream.java:70)
>       at
> org.apache.axis2.deployment.DeploymentClassLoader.getBytes(DeploymentClassLoader.java:198)
>       at
> org.apache.axis2.deployment.DeploymentClassLoader.getBytes(DeploymentClassLoader.java:178)
>       at
> org.apache.axis2.deployment.DeploymentClassLoader.findClass(DeploymentClassLoader.java:81)
>       at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
>       - locked <0x342afa70> (a
> org.apache.axis2.deployment.DeploymentClassLoader)
>       at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
>       at java.beans.Introspector.instantiate(Introspector.java:1453)
>
> 
>
> Best wishes,
> Martin Gerner
>
> On 13/01/2010 12:30, Andreas Veithen wrote:
>>
>> The type of databinding cannot account for this delay. I would suggest
>> to take a thread dump and try to understand where Axis2 is blocking.
>>
>> Andreas
>>
>> On Wed, Jan 13, 2010 at 13:04, Bruno Simioni 
>> wrote:
>>
>>>
>>> Maybe using JAXB annotations on Java return objects, you can speed up the
>>> process.
>>>
>>> Bruno.
>>>
>>> On Wed, Jan 13, 2010 at 9:51 AM, Martin Gerner
>>>  wrote:
>>>

 Hi all,

 I'm running a simple web service which receives a string from the
 client, processes it and returns an array of custom objects (nothing
 complicated, they're just data holders containing a few ints, strings
 and booleans). While the actual serverside processing performed by my
 server code is performed very fast, the response times from the server
 are very large and seem to be linear in the number of returned objects.

 A short example: if I send a strin

Re: [Axis2] making minOccurs=1 by default for wsdl generated with POJO

2010-01-11 Thread Mauro Molinari

Amila Suriarachchi ha scritto:
There is a different between interoperability and the signature of the 
generated method. Here the problem is having an inconvenient method 
signature. 


Not just that. If we're talking about the operation output parameters, 
there's also a problem of interoperability, because of the "void return 
type" bug described in AXIS2-3300.


It's ok for me to have a "setMinOccursZero" parameter. The main problem 
here is that it has to be well documented, otherwise it would be very 
cryptic to understand its existance without knowing the whole issue.


--
Mauro Molinari
Software Designer & Developer
E-mail: mauro.molin...@cardinis.com


Re: [Axis2] making minOccurs=1 by default for wsdl generated with POJO

2010-01-08 Thread Amila Suriarachchi
On Fri, Jan 8, 2010 at 4:23 PM, Mauro Molinari
wrote:

> Michail Prusakov ha scritto:
>
>  I am sorry I've missed the discussion, but why have you made minOccurs=1
>> for null non-primitives? As far as I see it, if a value is null the wsdl
>> should allow passing it as nill or not passing it at all because:
>> 1) two ways of saying something is null means better interoperability as
>> if a client does not support one way, it can use the other. I believe .NET
>> 1.x clients are good example of this.
>> 2) by omitting a value we can make the soap message smaller and thus
>> increase performance.
>>
>
> Hi Mike,
> if you read the whole discussion and especially the related issue(*),
> you'll see that by specifying minOccurs=0 for null non-primitives will cause
> Axis2 to generate a WSDL from which .NET tools will have problems to
> generate clients. These are .NET bugs, but if they can be avoided it's
> better, otherwise .NET interoperability is severely affected.
>

There is a different between interoperability and the signature of the
generated method. Here the problem is having an inconvenient method
signature.

>
> IMHO the preferred way to solve this would have been to have a flag (false
> by default) to use a ".NET friendly" generation algorithm, but Amila
> preferred not to go this way.
>

I didn't agree on the parameter name. But we can add a parameter like
"setMinOccursZero" to make this compatible with clients which does not
support nillable true.

thanks,
Amila.

>
> (*) https://issues.apache.org/jira/browse/AXIS2-3300
>
>
> --
> Mauro Molinari
> Software Designer & Developer
> E-mail: mauro.molin...@cardinis.com
>



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/


Re: [Axis2] making minOccurs=1 by default for wsdl generated with POJO

2010-01-08 Thread Mauro Molinari

Michail Prusakov ha scritto:
The point which got me worried in the first place was your comment that 
with the current fix
"Axis2 client wouldn't be able to specify "null" as input parameter and 
won't be able to handle null as an output parameter!"


This is not the case, actually, because I mis-interpreted a couple of 
comments of Amila's on this issue.
As I understand it now, nillable=true *is* specified for non-primitive 
parameter types, so the "null" issue I mentioned won't occur.


--
Mauro Molinari
Software Designer & Developer
E-mail: mauro.molin...@cardinis.com


Re: [Axis2] making minOccurs=1 by default for wsdl generated with POJO

2010-01-08 Thread Michail Prusakov

Hi Mauro,

Thanks for your reply. I did signed up for the list a little late so I 
thought I was missing something.


The point which got me worried in the first place was your comment that 
with the current fix
"Axis2 client wouldn't be able to specify "null" as input parameter and 
won't be able to handle null as an output parameter!"


Now if this is this the case then I do not understand why we need a fix 
which solves some old .NET bugs but makes usage of the Axis2 client 
somewhat uncomfortable (you did mention that null can be passed using 
Integer.MIN_VALUE which I also find more than ugly). After all, for .NET 
or other specific client we do have the contract-first approach as you 
have mentioned.


Mike


Mauro Molinari wrote:

Michail Prusakov ha scritto:
I am sorry I've missed the discussion, but why have you made 
minOccurs=1 for null non-primitives? As far as I see it, if a value is 
null the wsdl should allow passing it as nill or not passing it at all 
because:
1) two ways of saying something is null means better interoperability 
as if a client does not support one way, it can use the other. I 
believe .NET 1.x clients are good example of this.
2) by omitting a value we can make the soap message smaller and thus 
increase performance.


Hi Mike,
if you read the whole discussion and especially the related issue(*), 
you'll see that by specifying minOccurs=0 for null non-primitives will 
cause Axis2 to generate a WSDL from which .NET tools will have problems 
to generate clients. These are .NET bugs, but if they can be avoided 
it's better, otherwise .NET interoperability is severely affected.


IMHO the preferred way to solve this would have been to have a flag 
(false by default) to use a ".NET friendly" generation algorithm, but 
Amila preferred not to go this way.


(*) https://issues.apache.org/jira/browse/AXIS2-3300



Re: [Axis2] making minOccurs=1 by default for wsdl generated with POJO

2010-01-08 Thread Mauro Molinari

Amila Suriarachchi ha scritto:

Is it:
a) "nothing (=> minOccurs=1, nillable=false)" for primitives and
"nillable=true (=> still minOccurs=1)" for non-primitives

this should be the way.


Ok, so if it is like this right now, you can close again the issue, 
sorry for my mis-interpretation of your latest comments.


--
Mauro Molinari
Software Designer & Developer
E-mail: mauro.molin...@cardinis.com
___
CARDINIS Solutions
Via San Crispino, 46
35129 Padova - Italy
Tel. +39 0498072095
Fax +39 0497800824
http://www.cardinis.com

---
Questo messaggio è strettamente riservato ai destinatari specificati.
Se è ricevuto per errore si prega di avvisare il mittente e di 
cancellarlo dal proprio sistema.

-
This message is specifically addressed to the recipient(s).
Should you receive it by mistake, please notify the sender and delete it 
from your system.


Re: [Axis2] making minOccurs=1 by default for wsdl generated with POJO

2010-01-08 Thread Mauro Molinari

Michail Prusakov ha scritto:
I am sorry I've missed the discussion, but why have you made minOccurs=1 
for null non-primitives? As far as I see it, if a value is null the wsdl 
should allow passing it as nill or not passing it at all because:
1) two ways of saying something is null means better interoperability as 
if a client does not support one way, it can use the other. I believe 
.NET 1.x clients are good example of this.
2) by omitting a value we can make the soap message smaller and thus 
increase performance.


Hi Mike,
if you read the whole discussion and especially the related issue(*), 
you'll see that by specifying minOccurs=0 for null non-primitives will 
cause Axis2 to generate a WSDL from which .NET tools will have problems 
to generate clients. These are .NET bugs, but if they can be avoided 
it's better, otherwise .NET interoperability is severely affected.


IMHO the preferred way to solve this would have been to have a flag 
(false by default) to use a ".NET friendly" generation algorithm, but 
Amila preferred not to go this way.


(*) https://issues.apache.org/jira/browse/AXIS2-3300

--
Mauro Molinari
Software Designer & Developer
E-mail: mauro.molin...@cardinis.com


Re: [Axis2] making minOccurs=1 by default for wsdl generated with POJO

2010-01-07 Thread Michail Prusakov
I am sorry I've missed the discussion, but why have you made minOccurs=1 
for null non-primitives? As far as I see it, if a value is null the wsdl 
should allow passing it as nill or not passing it at all because:
1) two ways of saying something is null means better interoperability as 
if a client does not support one way, it can use the other. I believe 
.NET 1.x clients are good example of this.
2) by omitting a value we can make the soap message smaller and thus 
increase performance.


Mike

Amila Suriarachchi wrote:



On Thu, Jan 7, 2010 at 4:39 PM, Mauro Molinari 
mailto:mauro.molin...@cardinis.com>> wrote:


Amila Suriarachchi ha scritto:

On Thu, Jan 7, 2010 at 3:35 PM, Mauro Molinari
mailto:mauro.molin...@cardinis.com>
>> wrote:

   Amila Suriarachchi ha scritto:

   ok then lets make minOccurs = 1 by default. As Sosnoski
has said
   it is the the best solution. but that make everyone life
easier.

ohh. this should be 'As Sosnoski has said it is not the the best
solution' :) Sorry for mistake.

thanks,
Amila.


Ok, but... given my last comments on the bug report, what is your
last committed solution then?

Is it:
a) "nothing (=> minOccurs=1, nillable=false)" for primitives and
"nillable=true (=> still minOccurs=1)" for non-primitives

this should be the way.

Amila.
 


- OR -
b) "nothing (=> minOccurs=1, nillable=false)" in any case

Thanks.


-- 
Mauro Molinari

Software Designer & Developer
E-mail: mauro.molin...@cardinis.com 




--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/


Re: [Axis2] making minOccurs=1 by default for wsdl generated with POJO

2010-01-07 Thread Amila Suriarachchi
On Thu, Jan 7, 2010 at 4:39 PM, Mauro Molinari
wrote:

> Amila Suriarachchi ha scritto:
>
>  On Thu, Jan 7, 2010 at 3:35 PM, Mauro Molinari <
>> mauro.molin...@cardinis.com > wrote:
>>
>>Amila Suriarachchi ha scritto:
>>
>>ok then lets make minOccurs = 1 by default. As Sosnoski has said
>>it is the the best solution. but that make everyone life easier.
>>
>> ohh. this should be 'As Sosnoski has said it is not the the best solution'
>> :) Sorry for mistake.
>>
>> thanks,
>> Amila.
>>
>
> Ok, but... given my last comments on the bug report, what is your last
> committed solution then?
>
> Is it:
> a) "nothing (=> minOccurs=1, nillable=false)" for primitives and
> "nillable=true (=> still minOccurs=1)" for non-primitives
>
this should be the way.

Amila.


> - OR -
> b) "nothing (=> minOccurs=1, nillable=false)" in any case
>
> Thanks.
>
>
> --
> Mauro Molinari
> Software Designer & Developer
> E-mail: mauro.molin...@cardinis.com
>



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/


Re: [Axis2] making minOccurs=1 by default for wsdl generated with POJO

2010-01-07 Thread Mauro Molinari

Amila Suriarachchi ha scritto:
On Thu, Jan 7, 2010 at 3:35 PM, Mauro Molinari 
mailto:mauro.molin...@cardinis.com>> wrote:


Amila Suriarachchi ha scritto:

ok then lets make minOccurs = 1 by default. As Sosnoski has said
it is the the best solution. but that make everyone life easier.

ohh. this should be 'As Sosnoski has said it is not the the best 
solution' :) Sorry for mistake.


thanks,
Amila.


Ok, but... given my last comments on the bug report, what is your last 
committed solution then?


Is it:
a) "nothing (=> minOccurs=1, nillable=false)" for primitives and 
"nillable=true (=> still minOccurs=1)" for non-primitives

- OR -
b) "nothing (=> minOccurs=1, nillable=false)" in any case

Thanks.

--
Mauro Molinari
Software Designer & Developer
E-mail: mauro.molin...@cardinis.com


Re: [Axis2] making minOccurs=1 by default for wsdl generated with POJO

2010-01-07 Thread Amila Suriarachchi
On Thu, Jan 7, 2010 at 3:35 PM, Mauro Molinari
wrote:

> Amila Suriarachchi ha scritto:
>
>  ok then lets make minOccurs = 1 by default. As Sosnoski has said it is the
>> the best solution. but that make everyone life easier.
>>
> ohh. this should be 'As Sosnoski has said it is not the the best solution'
:) Sorry for mistake.

thanks,
Amila.

>
> Sorry, I can't find where Sosnoski says that minOccurs=1 by default for
> every kind of parameters is the best solution.
> He said that it's the best to use minOccurs=1 for primitives (as I said),
> while he preferred to keep on using minOccurs=0 for object types, while I
> was saying it was preferrable to use nillable=true because of .NET
> compatibility.
>
> Moreover, if you use minOccurs=1 always, generating a client with Axis2
> from the resulting WSDL, will then lead to the use of primitives that CANNOT
> let you specify a null value.
>
> So, the actual result is:
>
> => starting from public Integer methodA(Integer a);
> => Java2WSDL generates a WSDL with both the return type and the parameter
> type as mandatory (minOccurs=1, not specified but inherited as XML Schema
> default)
> => if you generate a client with WSDL2Java you'll get:
>
> public int methodA(int a);
>
> So, a client would not be able to call the service speciying null as the
> input parameter and could not handle null as the return type.
>
> That's not good at all!
>
>
> --
> Mauro Molinari
> Software Designer & Developer
> E-mail: mauro.molin...@cardinis.com
> ___
> CARDINIS Solutions
> Via San Crispino, 46
> 35129 Padova - Italy
> Tel. +39 0498072095
> Fax +39 0497800824
> http://www.cardinis.com
>
> ---
> Questo messaggio è strettamente riservato ai destinatari specificati.
> Se è ricevuto per errore si prega di avvisare il mittente e di cancellarlo
> dal proprio sistema.
> -
> This message is specifically addressed to the recipient(s).
> Should you receive it by mistake, please notify the sender and delete it
> from your system.
>



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/


Re: [Axis2] making minOccurs=1 by default for wsdl generated with POJO

2010-01-07 Thread Mauro Molinari

Amila Suriarachchi ha scritto:
ok then lets make minOccurs = 1 by default. As Sosnoski has said it is 
the the best solution. but that make everyone life easier.


Sorry, I can't find where Sosnoski says that minOccurs=1 by default for 
every kind of parameters is the best solution.
He said that it's the best to use minOccurs=1 for primitives (as I 
said), while he preferred to keep on using minOccurs=0 for object types, 
while I was saying it was preferrable to use nillable=true because of 
.NET compatibility.


Moreover, if you use minOccurs=1 always, generating a client with Axis2 
from the resulting WSDL, will then lead to the use of primitives that 
CANNOT let you specify a null value.


So, the actual result is:

=> starting from public Integer methodA(Integer a);
=> Java2WSDL generates a WSDL with both the return type and the 
parameter type as mandatory (minOccurs=1, not specified but inherited as 
XML Schema default)

=> if you generate a client with WSDL2Java you'll get:
public int methodA(int a);

So, a client would not be able to call the service speciying null as the 
input parameter and could not handle null as the return type.


That's not good at all!

--
Mauro Molinari
Software Designer & Developer
E-mail: mauro.molin...@cardinis.com
___
CARDINIS Solutions
Via San Crispino, 46
35129 Padova - Italy
Tel. +39 0498072095
Fax +39 0497800824
http://www.cardinis.com

---
Questo messaggio è strettamente riservato ai destinatari specificati.
Se è ricevuto per errore si prega di avvisare il mittente e di 
cancellarlo dal proprio sistema.

-
This message is specifically addressed to the recipient(s).
Should you receive it by mistake, please notify the sender and delete it 
from your system.


Re: [Axis2] making minOccurs=1 by default for wsdl generated with POJO

2010-01-05 Thread Amila Suriarachchi
On Tue, Jan 5, 2010 at 8:26 PM, Mauro Molinari
wrote:

> Mauro Molinari ha scritto:
>
>  Please note that all my trials and researches were carried out on .NET 1.1
>> and .NET 2.0 interoperability. I don't have details on the behaviours of 3.x
>> .NET client generation tools. Maybe in the later versions all the issues
>> have been solved (so that minOccurs=0 could actually be used with no harm),
>> but there are many .NET 1.1/2.0 users still out there.
>>
>
> Well, I should be more clear here. As I wrote in the issue:
>
> https://issues.apache.org/jira/browse/AXIS2-3300
> using nillable=true is actually the safest way to go if we talk about .NET
> >= 2.0.
> In .NET 1.x, the client generation tools simply ignore nillable=true
> attribute, so minOccurs=0 would be in some way better (if we talk about
> operation input parameters, although the doubled-parameters issue) or worse
> (if we talk about output parameters, i.e.: the void return type problem).
>
> In the JIRA issue I explained what would be the best solution in my
> opinion, but Amila does not like the idea to have a "compatibility" flag
> just for .NET 1.x, so as a compromise he proposed the use of nillable=true
> at least to avoid the void return type bug and the doubled-parameter
> aesthetic issue.
>
> In this sense, the nillable=true seems to be the least problematic
> solution, given that .NET 1.x support would still be excluded.


ok then lets make minOccurs = 1 by default. As Sosnoski has said it is the
the best solution. but that make everyone life easier.

thanks,
Amila.

>
>
> --
> Mauro Molinari
> Software Designer & Developer
> E-mail: mauro.molin...@cardinis.com
>



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/


Re: [Axis2] making minOccurs=1 by default for wsdl generated with POJO

2010-01-05 Thread Mauro Molinari

Mauro Molinari ha scritto:
Please note that all my trials and researches were carried out on .NET 
1.1 and .NET 2.0 interoperability. I don't have details on the 
behaviours of 3.x .NET client generation tools. Maybe in the later 
versions all the issues have been solved (so that minOccurs=0 could 
actually be used with no harm), but there are many .NET 1.1/2.0 users 
still out there.


Well, I should be more clear here. As I wrote in the issue:
https://issues.apache.org/jira/browse/AXIS2-3300
using nillable=true is actually the safest way to go if we talk about 
.NET >= 2.0.
In .NET 1.x, the client generation tools simply ignore nillable=true 
attribute, so minOccurs=0 would be in some way better (if we talk about 
operation input parameters, although the doubled-parameters issue) or 
worse (if we talk about output parameters, i.e.: the void return type 
problem).


In the JIRA issue I explained what would be the best solution in my 
opinion, but Amila does not like the idea to have a "compatibility" flag 
just for .NET 1.x, so as a compromise he proposed the use of 
nillable=true at least to avoid the void return type bug and the 
doubled-parameter aesthetic issue.


In this sense, the nillable=true seems to be the least problematic 
solution, given that .NET 1.x support would still be excluded.


--
Mauro Molinari
Software Designer & Developer
E-mail: mauro.molin...@cardinis.com


Re: [Axis2] making minOccurs=1 by default for wsdl generated with POJO

2010-01-05 Thread Mauro Molinari

On Tue, Jan 5, 2010 at 12:06 PM, Dennis Sosnoski  wrote:
It's definitely best to use minOccurs=1 for primitives. nillable=true is 
*not* a good choice in general, and I'd recommend you instead go with 
minOccurs=0 for object types.


Why is nillable=true bad? 1. It requires the element to still be present 
in the message, adding unnecessary bloat (including the xsi namespace 
definition and usage) and confusion for human viewers of the message. 2. 
If required attributes are defined for the element (not an issue for 
POJO deployment, since it doesn't use attributes, but applicable in 
terms of the general use of nillable=true) those attributes need to be 
present even with xsi:nil=true in the document. minOccurs=0 is a cleaner 
representation of optional values.


I know minOccurs="0" is a cleaner representation of optional values, but 
I think that if Axis2 would like to be compatible with .NET clients it 
should try to use the solution more compatible, rather than that more 
"elegant". Or, at least, it should be configurable (and documented) for 
that, especially because the .NET world is very important out there...


Even if minOccurs=0 might be a better solution from an XML 
Schema/instance point of view, if you have a WSDL that defines a service 
input parameter (called "myParam") with minOccurs=0, under certain 
cicrumstances (bound to the type of myParam) .NET clients generated by 
.NET tools from that WSDL have an awful layout like the following


public string myMethod(int myParam, bool myParamSpecified)

That is: myParam is "doubled", a second boolean parameter is added to 
the method signature to specify if the myParam parameter has actually 
been specified (i.e.: its value is significant and it's not null) or not
(i.e.: its value has to be ignored, myParam is to be considered "not 
specified"/"null").


Even worse, if minOccurs=0 is specified on a service output parameter, 
there must be a bug in the .NET generation tools that causes a method to 
be generated like:


public void myMethod(...)

that is, with "void" return type!! This is the main reason for which the 
issue has been opened.


However, even if the issue regarding minOccurs=0 vs nillable=true for 
optional input parameters seems just to be an aesthetic issue (related 
to .NET clients generation), from my daily work experience I had to 
listen to a lot of complaints from .NET developers when they have to 
interface with our services and they go to generate their client code 
from our WSDLs. We use a contract-first approach (as of now, Axis2 
code-first is not quite usable for serious production-quality web 
service development IMHO) so we can choose every time where to use 
minOccurs=0 or nillable=true and, because we need to keep .NET 1.1 
compatibility, sometimes we are forced to use minOccurs=0 even if we 
know about the "double-parameter" generation issue, so we have to 
explain to the .NET client developers *why* we chose that strategy. But 
because the user of a code-first approach usually does not have such 
control (and knowledge...) over the WSDL, I think that Axis2 should try 
to do its best to be as smart as possible when taking care of such 
interoperability issues.


Also, the aesthetic issue could become an actual issue when you have 
services with a lot of input parameters (try to think about an operation 
with a request message with 5 optional parameters, you end up with a 
client method with at least 10 (!!!) input parameters... And so on.


Because of this, using nillable=true seems to be the safest way to go 
here. Actually, if you think of a scenario in which a Java developer is 
writing services using code-first approach and a .NET developer is 
generating its client code with automatic tools, do they really care if, 
for an optional parameter which has not been specified, an XML element 
with an xsi:nil=true attribute is passed on the wire rather than no XML 
element at all?


You may argue that .NET is just one option among many others in the web 
services world, but I think it's a really important one, so I would 
appreciate if Axis2 could be at least configurable to behave in a 
.NET-friendly way.


Please note that all my trials and researches were carried out on .NET 
1.1 and .NET 2.0 interoperability. I don't have details on the 
behaviours of 3.x .NET client generation tools. Maybe in the later 
versions all the issues have been solved (so that minOccurs=0 could 
actually be used with no harm), but there are many .NET 1.1/2.0 users 
still out there.


--
Mauro Molinari
Software Designer & Developer
E-mail: mauro.molin...@cardinis.com


Re: [Axis2] making minOccurs=1 by default for wsdl generated with POJO

2010-01-05 Thread Dennis Sosnoski

Amila Suriarachchi wrote:



On Tue, Jan 5, 2010 at 12:06 PM, Dennis Sosnoski > wrote:


Hi Amila,

It's definitely best to use minOccurs=1 for primitives.
nillable=true is *not* a good choice in general, and I'd recommend
you instead go with minOccurs=0 for object types.

Why is nillable=true bad? 1. It requires the element to still be
present in the message, adding unnecessary bloat (including the
xsi namespace definition and usage) and confusion for human
viewers of the message. 2. If required attributes are defined for
the element (not an issue for POJO deployment, since it doesn't
use attributes, but applicable in terms of the general use of
nillable=true) those attributes need to be present even with
xsi:nil=true in the document. minOccurs=0 is a cleaner
representation of optional values.


if we use minOccurs=0 instead of nillable=true does that fix the issue 
given here[1]. Currently POJO gives preference to nillable=true when 
returning null objects.


thanks,
Amila.

[1] https://issues.apache.org/jira/browse/AXIS2-3300


I think the .Net people prefer using nillable=true, for no good reason 
that I've ever seen presented - somehow they got the idea early on that 
xsi:nil="true" in an instance document is equivalent to a null value in 
code. It's not - required attributes still need to be present on the 
element, as mentioned before, and the element cannot be an abstract 
element in the schema definition (unlike in code, where you commonly use 
references with abstract types to hold either a null or an instance of 
any of the possible matching concrete types).


I'd say it's always a bad idea to specify *both* minOccurs="0" and 
nillable="true". I don't know offhand what .Net does if you only specify 
minOccurs="0", but from the discussion it sounds like it would probably 
still generate the flag variables - so if you want the schemas to be 
optimized for .Net you're probably better off using nillable="true" to 
fit with their misconceptions.


 - Dennis


Re: [Axis2] making minOccurs=1 by default for wsdl generated with POJO

2010-01-05 Thread Amila Suriarachchi
On Tue, Jan 5, 2010 at 12:06 PM, Dennis Sosnoski  wrote:

> Hi Amila,
>
> It's definitely best to use minOccurs=1 for primitives. nillable=true is
> *not* a good choice in general, and I'd recommend you instead go with
> minOccurs=0 for object types.
>
> Why is nillable=true bad? 1. It requires the element to still be present in
> the message, adding unnecessary bloat (including the xsi namespace
> definition and usage) and confusion for human viewers of the message. 2. If
> required attributes are defined for the element (not an issue for POJO
> deployment, since it doesn't use attributes, but applicable in terms of the
> general use of nillable=true) those attributes need to be present even with
> xsi:nil=true in the document. minOccurs=0 is a cleaner representation of
> optional values.
>

if we use minOccurs=0 instead of nillable=true does that fix the issue given
here[1]. Currently POJO gives preference to nillable=true when returning
null objects.

thanks,
Amila.

[1] https://issues.apache.org/jira/browse/AXIS2-3300

>
>  - Dennis
>
> --
> Dennis M. Sosnoski
> Java XML and Web Services
> Axis2 Training and Consulting
> http://www.sosnoski.com - http://www.sosnoski.co.nz
> Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117
>
>
>
>
> Amila Suriarachchi wrote:
>
>> this is related to issue[1]
>>
>> I think it is better to make minOccurs=1 considering the following points
>> and the issue given here[1].
>>
>> 1. if the type is a primitive type then anyway it get assigned a value and
>> hence nillable=true and minOccurs=0 can not be supported.
>> 2. if not primitive always minOccurs=0 and nillable=true maps to null
>> value. hence nillable=true is enough.
>>
>> WDYT?
>>
>> [1] https://issues.apache.org/jira/browse/AXIS2-3300
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>>
>
>


-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/


Re: [Axis2] making minOccurs=1 by default for wsdl generated with POJO

2010-01-04 Thread Dennis Sosnoski

Hi Amila,

It's definitely best to use minOccurs=1 for primitives. nillable=true is 
*not* a good choice in general, and I'd recommend you instead go with 
minOccurs=0 for object types.


Why is nillable=true bad? 1. It requires the element to still be present 
in the message, adding unnecessary bloat (including the xsi namespace 
definition and usage) and confusion for human viewers of the message. 2. 
If required attributes are defined for the element (not an issue for 
POJO deployment, since it doesn't use attributes, but applicable in 
terms of the general use of nillable=true) those attributes need to be 
present even with xsi:nil=true in the document. minOccurs=0 is a cleaner 
representation of optional values.


 - Dennis

--
Dennis M. Sosnoski
Java XML and Web Services
Axis2 Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117



Amila Suriarachchi wrote:

this is related to issue[1]

I think it is better to make minOccurs=1 considering the following 
points and the issue given here[1].


1. if the type is a primitive type then anyway it get assigned a value 
and hence nillable=true and minOccurs=0 can not be supported.
2. if not primitive always minOccurs=0 and nillable=true maps to null 
value. hence nillable=true is enough.


WDYT?

[1] https://issues.apache.org/jira/browse/AXIS2-3300

--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/




Re: [Axis2] Implementing Stomp transport for Axis2

2010-01-02 Thread Dunith Dhanushka
hi folks,

I value your feedback  received on this topic so far.

finally I completed the Stomp transport for Axis2 and submitted the patch to
WS-Commons issue tracker. In addition to that I uploaded a user manual which
describes how to build,configure  and run this transport with Axis2.

I hope you'll be enjoying it...

https://issues.apache.org/jira/browse/WSCOMMONS-514

regards,
Dunith Dhanushka
[dunithd.wordpress.com]


Re: [Axis2] Implementing Stomp transport for Axis2

2010-01-01 Thread Sanjiva Weerawarana
+1 - the transport handling code should be independent of the format of the
data that flows on that transport, which is what MessageBuilder and
MessageFormatter objects take care of. However, in the case of Stomp, is the
transport a raw TCP stream with the binary bits? If so separation of message
formatter etc. is not sensible - the transport itself can do everything and
return a message context as you noted.

Sanjva.

On Sat, Jan 2, 2010 at 12:01 AM, Andreas Veithen
wrote:

> Dunith,
>
> You are entirely right. A transport is not supposed to implement
> message builders and formatters, but only to use (as much as possible)
> these APIs to support various payload formats. Probably that is what
> Thilina wanted to say, but his post was not very clear.
>
> Andreas
>
> On Wed, Dec 30, 2009 at 05:13, Dunith Dhanushka  wrote:
> > Hi folks,
> >
> > Many thanks in advance for your feedback Thilina.
> >
> > I considered Thilina's point before starting the design process and at
> that
> > moment, I have no idea about MessageFormaters and MessageBuilders.
> > I was looking for a methodology that can be applied to mix & match
> message
> > formats irrespective of the transport based on the content type.I
> examined
> > several transports like JMS,XMPP and HTTP in Axis2 earlier versions and I
> > couldn't find seperate classes for MessageBuilder and MessageFormater.
> > Instead they all used a method like
> >
> > -createMessageContext()
> returns
> > MessageContext
> >
> > to populate the MessageContext from the protocol specific data
> > packet(PDU).
> >
> > So I decided to implement a such method inside the StompPacketListener
> and
> > it will read the incoming stomp packet,extract the content and finally
> > creates a MessageContext with a SOAPEnvelope that is independent of the
> > transport protocol.
> >
> > I'll be submitting the patch tomorrow because I have to test it against a
> > Stomp implementation other than Apache ActiveMq.
> >
> > Folks, I wish you a happy new year with peace and prosperity...
> >
> > regards,
> > Dunith Dhanushka
> >
>



-- 
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/


Re: [Axis2] Implementing Stomp transport for Axis2

2010-01-01 Thread Andreas Veithen
Dunith,

You are entirely right. A transport is not supposed to implement
message builders and formatters, but only to use (as much as possible)
these APIs to support various payload formats. Probably that is what
Thilina wanted to say, but his post was not very clear.

Andreas

On Wed, Dec 30, 2009 at 05:13, Dunith Dhanushka  wrote:
> Hi folks,
>
> Many thanks in advance for your feedback Thilina.
>
> I considered Thilina's point before starting the design process and at that
> moment, I have no idea about MessageFormaters and MessageBuilders.
> I was looking for a methodology that can be applied to mix & match message
> formats irrespective of the transport based on the content type.I examined
> several transports like JMS,XMPP and HTTP in Axis2 earlier versions and I
> couldn't find seperate classes for MessageBuilder and MessageFormater.
> Instead they all used a method like
>
> -createMessageContext() returns
> MessageContext
>
>     to populate the MessageContext from the protocol specific data
> packet(PDU).
>
> So I decided to implement a such method inside the StompPacketListener and
> it will read the incoming stomp packet,extract the content and finally
> creates a MessageContext with a SOAPEnvelope that is independent of the
> transport protocol.
>
> I'll be submitting the patch tomorrow because I have to test it against a
> Stomp implementation other than Apache ActiveMq.
>
> Folks, I wish you a happy new year with peace and prosperity...
>
> regards,
> Dunith Dhanushka
>


Re: [Axis2] Implementing Stomp transport for Axis2

2009-12-29 Thread Dunith Dhanushka
Hi folks,

Many thanks in advance for your feedback Thilina.

I considered Thilina's point before starting the design process and at that
moment, I have no idea about MessageFormaters and MessageBuilders.
I was looking for a methodology that can be applied to mix & match message
formats irrespective of the transport based on the content type.I examined
several transports like JMS,XMPP and HTTP in Axis2 earlier versions and I
couldn't find seperate classes for MessageBuilder and MessageFormater.
Instead they all used a method like

*-createMessageContext() returns
MessageContext*

to populate the MessageContext from the protocol specific data
packet(PDU).

So I decided to implement a such method inside the StompPacketListener and
it will read the incoming stomp packet,extract the content and finally
creates a MessageContext with a SOAPEnvelope that is independent of the
transport protocol.

I'll be submitting the patch tomorrow because I have to test it against a
Stomp implementation other than Apache ActiveMq.

Folks, I wish you a happy new year with peace and prosperity...

regards,
Dunith Dhanushka


Re: [Axis2] Implementing Stomp transport for Axis2

2009-12-28 Thread Thilina Gunarathne
Hi Dunith,
> I delegated the message formatting and building responsibility to the
> StompPacketListener so that I could eliminate the need of a message
> formatter and builder.
Hope you are still implementing the MessageFormatter and
MessageBuilder interfaces.. Implementing them allows Axis2 to support
mix & match message formats irrespective of the transport based on the
content type (or the equivalent in the given transport). Also having
the message builder/formatter pluggable will allow the users the
send/receive different formats of messages on top of Stomp transport.

Apologies to my poor knowledge about Stomp, if the above does not fit
at all with Stomp (eg: hard wired message format & transport)..

thanks,
Thilina


>
> For a understanding about this transport, I published a blog post
> illustrating the component architecture. You can visit there using this
> link.
>
> Currently, I've finished coding the transport and running tests on it. I
> like to contribute my code into Axis2 code base. But I have no idea about
> how to do it and what are the procedures I should follow.
>
> I appreciate your feedback on this.
>
> Regards,
> Dunith Dhanuhska
>
>
>
>
>
>



-- 
Thilina Gunarathne  - http://thilinag.blogspot.com


Re: [Axis2] Implementing Stomp transport for Axis2

2009-12-26 Thread Dunith Dhanushka
Hi all,

Many thanks for Amila and Ruwan for the feedback.

StompMessageReceiver class doesn't implement the MessageReceiver interface.
So I renamed it as "StompPacketListener".

I'm running tests at the moment. After I feel everything is ok, then I'll
submit the patch.

Regards,
Dunith Dhanushka


Re: [Axis2] Implementing Stomp transport for Axis2

2009-12-26 Thread Ruwan Linton
Hi Dunith,

So the StompMessageReceiver doesn't implement the MessageReceiver interface,
right? Please rename it to StompPacketListener.

+1 for attaching the code to commons (at least for the moment). First create
a JIRA under the WSCOMMONS project and attach the patch.

Thanks,
Ruwan

On Sat, Dec 26, 2009 at 10:32 AM, Amila Suriarachchi <
amilasuriarach...@gmail.com> wrote:

>
>
> On Fri, Dec 25, 2009 at 11:14 PM, Dunith Dhanushka wrote:
>
>> Hi folks,
>>
>> Many thanks in advance for your feedback Dr. Sanjiva.
>>
>> This is regarding the *StompMessageReceiver. *Actually this not a kind of
>> any ordinary *MessageReceivers* in the Axis2 core ( unlike
>> RawXMLINOnlyMessageReceiver and  RPCMessageReceiver). StompMessageReceiver
>> is a listener or a thread that is waiting for a incoming Stomp packet from
>> the broker. I'll rename it as *StompPacketListener*.
>>
>> In order to facilitate multiple brokers, there can be several
>> StompPacketListener instances and they all share a same worker thread pool
>> which is initialized by the StompListener. When a packet is arrived from a
>> particular broker, it will be dispatched by the appropriate *
>> StompPacketListener*.
>>
>> I delegated the message formatting and building responsibility to the *
>> StompPacketListener* so that I could eliminate the need of a message
>> formatter and builder.
>>
>> For a understanding about this transport, I published a blog post
>> illustrating the component architecture. You can visit there using 
>> thislink.
>>
>> Currently, I've finished coding the transport and running tests on it. I
>> like to contribute my code into Axis2 code base. But I have no idea about
>> how to do it and what are the procedures I should follow.
>>
>
> Axis2 transports are actually at the commons transport[1] project. you can
> create your transport as another
> module and attach the code as a patch for here[2].
>
> thanks,
> Amila.
>
> [1] http://ws.apache.org/commons/transport/
> [2] https://issues.apache.org/jira/browse/WSCOMMONS
>
>
>
>>
>> I appreciate your feedback on this.
>>
>> Regards,
>> Dunith Dhanuhska
>>
>>
>>
>>
>>
>>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>



-- 
Ruwan Linton
Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ru...@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com


Re: [Axis2] Implementing Stomp transport for Axis2

2009-12-25 Thread Amila Suriarachchi
On Fri, Dec 25, 2009 at 11:14 PM, Dunith Dhanushka wrote:

> Hi folks,
>
> Many thanks in advance for your feedback Dr. Sanjiva.
>
> This is regarding the *StompMessageReceiver. *Actually this not a kind of
> any ordinary *MessageReceivers* in the Axis2 core ( unlike
> RawXMLINOnlyMessageReceiver and  RPCMessageReceiver). StompMessageReceiver
> is a listener or a thread that is waiting for a incoming Stomp packet from
> the broker. I'll rename it as *StompPacketListener*.
>
> In order to facilitate multiple brokers, there can be several
> StompPacketListener instances and they all share a same worker thread pool
> which is initialized by the StompListener. When a packet is arrived from a
> particular broker, it will be dispatched by the appropriate *
> StompPacketListener*.
>
> I delegated the message formatting and building responsibility to the *
> StompPacketListener* so that I could eliminate the need of a message
> formatter and builder.
>
> For a understanding about this transport, I published a blog post
> illustrating the component architecture. You can visit there using 
> thislink.
>
> Currently, I've finished coding the transport and running tests on it. I
> like to contribute my code into Axis2 code base. But I have no idea about
> how to do it and what are the procedures I should follow.
>

Axis2 transports are actually at the commons transport[1] project. you can
create your transport as another
module and attach the code as a patch for here[2].

thanks,
Amila.

[1] http://ws.apache.org/commons/transport/
[2] https://issues.apache.org/jira/browse/WSCOMMONS



>
> I appreciate your feedback on this.
>
> Regards,
> Dunith Dhanuhska
>
>
>
>
>
>


-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/


Re: [Axis2] Implementing Stomp transport for Axis2

2009-12-25 Thread Dunith Dhanushka
Hi folks,

Many thanks in advance for your feedback Dr. Sanjiva.

This is regarding the *StompMessageReceiver. *Actually this not a kind of
any ordinary *MessageReceivers* in the Axis2 core ( unlike
RawXMLINOnlyMessageReceiver and  RPCMessageReceiver). StompMessageReceiver
is a listener or a thread that is waiting for a incoming Stomp packet from
the broker. I'll rename it as *StompPacketListener*.

In order to facilitate multiple brokers, there can be several
StompPacketListener instances and they all share a same worker thread pool
which is initialized by the StompListener. When a packet is arrived from a
particular broker, it will be dispatched by the appropriate *
StompPacketListener*.

I delegated the message formatting and building responsibility to the *
StompPacketListener* so that I could eliminate the need of a message
formatter and builder.

For a understanding about this transport, I published a blog post
illustrating the component architecture. You can visit there using
thislink.

Currently, I've finished coding the transport and running tests on it. I
like to contribute my code into Axis2 code base. But I have no idea about
how to do it and what are the procedures I should follow.

I appreciate your feedback on this.

Regards,
Dunith Dhanuhska


Re: [Axis2] Implementing Stomp transport for Axis2

2009-12-24 Thread Sanjiva Weerawarana
Sounds good! However, why do you need a StompMessageReceiver? You should
only need a listener, a sender, a message formatter and a message builder.
The listener and the message builder combine to deliver a MessageContext
into the AxisEngine and in the other direction the sender and formatter
write one to the wire.

Sanjiva.

On Thu, Dec 24, 2009 at 2:27 AM, Dunith Dhanushka  wrote:

> Hi folks,
>
> I just got an idea to write a new transport for axis2 based on Stomp
> protocol. Stomp can be used to deal with any Stomp supported message broker
> (like Apache ActiveMQ) to send and receive messages.
>
> Since Stomp is very simple protocol, many scripting languages such as
> Ruby,PHP and python heavily use it for dealing with message brokers. So if
> Axis2 has Stomp support, they would send SOAP messages into axis2 through
> Stomp supported broker and they will leverage the performance of axis2
> engine, when it comes to consume web services.
>
> As a start, I designed some basic set of classes for the Stomp transport
>
> * StompListener - for listening to incoming Stomp messages
> * StompConnection - represents a connection between axis2 and the
> broker.
> * StompMessageReceiver - worker thread that handles all incoming Stomp
> messages. uses a shared worker thread pool
> * StompConstants - constants specific to Stomp is defined here
> * StompSender - implements the TransportSender interface
> * StompUtils - utilities
>
> So I would like your feedbacks about this implementation.
>
> Cheers!
> Dunith Dhanushka
>
>
>
>


-- 
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/


Re: [Axis2] Regarding the JMS transport in Axis2 version 1.5.1

2009-12-11 Thread Hiranya Jayathilaka
On Fri, Dec 11, 2009 at 10:08 PM, Dunith Dhanushka wrote:

> Hi all,
>
> I'm pretty much new to Axis2 project and this mailing list too.
>
> I observed that in axis2 1.4.1 release, there were JMS and XMPP transports
> in the Axis2 kernel. But when it comes to later versions( I mean versions
> higher than 1.4.1), they were disappeared from the distribution.
>
> Is there any particular reason for that?
>

Axis2 transports are now in a separate project called WS-Commons Transports.
They are available as a separate collection of modules that you can deploy
into Axis2.

Thanks,
Hiranya


>
>
> Cheers!
> Dunith Dhanushka
>



-- 
Hiranya Jayathilaka
Software Engineer;
WSO2 Inc.;  http://wso2.org
E-mail: hira...@wso2.com;  Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com


Re: axis2-eclipse-codegen disappeared

2009-12-03 Thread Saminda Wijeratne
Hi Martin,

Even it is technically missing, I think it was removed and replaced with the
1.4.1 version. try [1]. Notice the zip file name does not contain the
version also. somewhere something had gone wrong.

Regards,
Saminda

[1]
http://www.apache.org/dyn/mirrors/mirrors.cgi/ws/axis2/tools/1_4_1/axis2-eclipse-codegen-wizard.zip

2009/12/3 Martin Gainty 

>  All
>
> i am currently tracking this ibm bug
>
> Exception in thread "main"
> org.apache.axis2.wsdl.codegen.CodeGenerationException
> : Error parsing WSDL
> at
> org.apache.axis2.wsdl.codegen.CodeGenerationEngine.(CodeGenerat
> ionEngine.java:156)
> at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:35)
> at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:24)
> Caused by: javax.wsdl.WSDLException: WSDLException (at /definitions):
> faultCode=
> INVALID_WSDL: Expected element '{
> http://schemas.xmlsoap.org/wsdl/}definitions
> '.
> at com.ibm.wsdl.xml.WSDLReaderImpl.checkElementName(Unknown Source)
> at com.ibm.wsdl.xml.WSDLReaderImpl.parseDefinitions(Unknown Source)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
> at
> org.apache.axis2.wsdl.codegen.CodeGenerationEngine.readInTheWSDLFile(
> CodeGenerationEngine.java:288)
> at
> org.apache.axis2.wsdl.codegen.CodeGenerationEngine.(CodeGenerat
> ionEngine.java:111)
>
>
>
> http://www.apache.org/dyn/mirrors/mirrors.cgi/ws/axis2/tools/1_4/axis2-eclipse-codegen-wizard-1.4.zip
> is empty on all mirrors
> Anyone know where ibm put their axis2-eclipse-codegen code (eclipse plugin
> for axis2 code generation)?
>
> thanks,
> Martin Gainty
> __
> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
>
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
> dient lediglich dem Austausch von Informationen und entfaltet keine
> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
>
> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
> destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
> l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci 
> est interdite. Ce message sert à l'information seulement et n'aura pas 
> n'importe quel effet légalement obligatoire. Étant donné que les email 
> peuvent facilement être sujets à la manipulation, nous ne pouvons accepter 
> aucune responsabilité pour le contenu fourni.
>
>
>
>
>
> --
> Windows LiveT Hotmail is faster and more secure than ever. Learn 
> more.
>


Re: Axis2 Transports 1.0-RC1 for testing

2009-11-28 Thread Charith Wickramarachchi
Hi Ruwan,

I tested the SMS Transport with Axis2 1.5.1.

There was a problem with the GSM implementation coused by the issue that i
have already  reported in WSCOMMONS-508.

To fix that issue please commit the patch i have provided in WSCOMMONS-508
for me then that issue will be resolved.

The SMPP protocol implementation works fine with the axis2 1.5.1.

thanks,
Charith




On Thu, Nov 26, 2009 at 2:06 PM, Ruwan Linton wrote:

> Folks,
>
> Still I am in the process of completing the site, but that wouldn't stop us
> from publishing a binary RC for testing.
>
> Here are the artifacts to be released;
>
> http://people.apache.org/~ruwan/transports-1.0-RC1/artifacts/
>
> and the maven2 repository is;
>
> http://people.apache.org/~ruwan/transports-1.0-RC1/m2_repo/
>
> Hope to have your early feedback on this. If everything goes well, we will
> be able to call the release vote on next week. I need some help on UDP and
> XMPP transport documentations, if there are any volunteers to contribute to
> those, you are more than welcome!
>
> Thanks,
> Ruwan
>
> --
> Ruwan Linton
> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
> WSO2 Inc.; http://wso2.org
> email: ru...@wso2.com; cell: +94 77 341 3097
> blog: http://ruwansblog.blogspot.com
>



-- 
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/


Re: [Axis2] JMS transport in Axis2 1.5.1

2009-11-24 Thread Ruwan Linton
On Tue, Nov 24, 2009 at 2:31 PM, Su AiHua  wrote:

>
> Hi Ruwan,
>
> Thank you very much!
> So do you know the release plan?
>

I am doing the release, it is sort of code freezed from the functionality
vice, but we are still working on the documentation.

You can expect the release by mid or the first week of December.

Thanks,
Ruwan


>
>
> -Aihua Su
>
>
> On Tue, Nov 24, 2009 *, Ruwan Linton * wrote:
>
>  Hi Aihua,
>
> The jms transport for the 1.5.1 has not been released yet, but
> functionality completed in this branch [1], which will be released soon.
>
> [1] -
> https://svn.apache.org/repos/asf/webservices/commons/branches/modules/transport/1.0.0/modules/jms
>
> Thanks,
> Ruwan
>
> On Tue, Nov 24, 2009 at 1:06 PM, Su AiHua 
> http://cn.mc158.mail.yahoo.com/mc/compose?to=diasy_fri...@yahoo.com.cn>
> > wrote:
>
>>I download the Axis2 1.5.1 source codes and can not find the codes
>> related to jms transport.
>> Any one can tell me where I can get the source codes about jms transport?
>> Thanks!
>>
>> -Aihua
>>
>> --
>>
>
>
>
> --
> Ruwan Linton
> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
> WSO2 Inc.; http://wso2.org
> email: 
> ru...@wso2.com;
> cell: +94 77 341 3097
> blog: http://ruwansblog.blogspot.com
>
>
> --
> 好玩贺卡等你发,邮箱贺卡全新上线!




-- 
Ruwan Linton
Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ru...@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com


Re: [Axis2] JMS transport in Axis2 1.5.1

2009-11-24 Thread Su AiHua

Hi Ruwan,
 
Thank you very much!
So do you know the release plan?
 

-Aihua Su

On Tue, Nov 24, 2009 , Ruwan Linton  wrote:



Hi Aihua,

The jms transport for the 1.5.1 has not been released yet, but functionality 
completed in this branch [1], which will be released soon. 

[1] - 
https://svn.apache.org/repos/asf/webservices/commons/branches/modules/transport/1.0.0/modules/jms

Thanks,
Ruwan


On Tue, Nov 24, 2009 at 1:06 PM, Su AiHua  wrote:








I download the Axis2 1.5.1 source codes and can not find the codes related to 
jms transport.
Any one can tell me where I can get the source codes about jms transport? 
Thanks!
 
-Aihua 





-- 
Ruwan Linton
Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ru...@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com 



  ___ 
  好玩贺卡等你发,邮箱贺卡全新上线! 
http://card.mail.cn.yahoo.com/

Re: [Axis2] JMS transport in Axis2 1.5.1

2009-11-24 Thread Ruwan Linton
Hi Aihua,

The jms transport for the 1.5.1 has not been released yet, but functionality
completed in this branch [1], which will be released soon.

[1] -
https://svn.apache.org/repos/asf/webservices/commons/branches/modules/transport/1.0.0/modules/jms

Thanks,
Ruwan

On Tue, Nov 24, 2009 at 1:06 PM, Su AiHua  wrote:

>  I download the Axis2 1.5.1 source codes and can not find the codes
> related to jms transport.
> Any one can tell me where I can get the source codes about jms transport?
> Thanks!
>
> -Aihua
>
> --
> 好玩贺卡等你发,邮箱贺卡全新上线!




-- 
Ruwan Linton
Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ru...@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com


Re: [Axis2] Re: svn commit: r835113 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/client/ServiceClient.java

2009-11-13 Thread Roy Wood
All,

Thanks for the discussion and insight on this. I'll go ahead and revert 
this change and we'll look at doing a more suitable change in JAX-WS.

Roy A. Wood, Jr.
WebSphere Development - Web Services
wood...@us.ibm.com
512-286-9307  T/L:363-9307
11501 Burnet Road,  Austin TX   78758 (Internal ZIP: 9372)



From:
Glen Daniels 
To:
axis-dev@ws.apache.org
Date:
11/13/2009 12:47 PM
Subject:
Re: [Axis2] Re: svn commit: r835113 - 
/webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/client/ServiceClient.java



Hi Bill, Andreas, all:

Just circling around to this.  Thanks, Andreas, for your catch here.  The
default for AUTO_OPERATION_CLEANUP was definitely intended to be true,
specifically to make avoiding the connection starvation problem as 
effortless
(and backwards compatible) as possible.  Please revert that part of the
change if you would, Roy?

ServiceClients (and by association Stubs) are *not* meant to be 
thread-safe.
 There were a number of discussions about this in 2006, 2007, 2008... if 
the
docs aren't crystal-clear on this then I definitely agree we should fix 
them.

Re: the JavaDoc on cleanupTransport(), that's my bad - we do NOT build() 
the
full Axiom tree by default with AUTO_OPERATION_CLEANUP, only when
options.isCallTransportCleanup() is true.  The build() actually happens in
sendReceive() and the JavaDoc discussing it should be there, not on
cleanupTransport().  I apologize for not neatening that up when I made the 
fix.

I'd like to open a separate discussion as to how to make this whole 
cleanup
issue work *right* for Axis2 1.6 (*), and deprecate the ways we've been 
doing
it up until now, but for now we have three options - 1) use
AUTO_OPERATION_CLEANUP by default which cleans up the *last* 
OperationContext
each time you make a new one, 2) use options.setCallTransportCleanup(), 
which
cleans up the *current* OperationContext at the end, accepting the build()
limitations, and 3) shut off both of the above and clean up manually.

Thanks,
--Glen

(*) IMHO there should be a way to have Axiom auto-trigger a cleanup if we
reach the end of the inputStream, and if we don't ever read to the end for 
a
given operation, we'll still need some automatic mechanism involving 
timeouts
or heuristics

Bill Nagy wrote:
> Ignoring the performance degradation for a moment, the
> AUTO_OPERATION_CLEANUP feature had removed thread-safety from the
> ServiceClient (i.e. if two threads invoke
> serviceclient.createClient(...), there is the distinct possibility that,
> before Roy's modification, the code would have cleaned up the transport
> before the first invoking thread had finished.)
> 
> If the ServiceClient is not meant to be thread-safe, then this needs to
> be explicitly stated in the JavaDoc and the JAX-WS code will need to be
> reworked to take this into account.
> 
> If the ServiceClient is supposed to be thread-safe, then either the
> default should remain as Roy has set it (i.e. to be 'false') or the
> cleanup code needs to be rewritten so as not to cause threading issues.
> 
> -Bill
> 
> 
> On Thu, 2009-11-12 at 17:44 -0600, Roy Wood wrote:
>> Andreas, 
>> Yes, I agree...thanks for the correction. I went back and did a quick
>> search on AUTO_OPERATION_CLEANUP and didn't find any intent on what
>> the 
>> actual default should be, other than the original code using a default
>> of 'true'. 
>>
>> This property came to our attention when we ran into a threading
>> problem in one of our test cases. By setting the default to false,
>> thus disabling the call to 
>> 'cleanupTransport' in createClient, the threading problem disappeared.
>> I'm also a bit concerned about the performance warning in
>> cleanupTransport 
>> javadocs. For that reason, as well as, providing a degree backwards
>> compatability,  I would like to propose that the default for this
>> property be 'false'. 
>>
>> Roy A. Wood, Jr.
>> WebSphere Development - Web Services
>> wood...@us.ibm.com
>> 512-286-9307  T/L:363-9307
>> 11501 Burnet Road,  Austin TX   78758 (Internal ZIP: 9372) 
>>
>>
>>
>> Re: svn commit: r835113
>> - 
/webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/client/ServiceClient.java
>>
>> Andreas
>> Veithen 
>> to: 
>> axis-dev 
>> 11/12/2009 03:30 PM
>>
>> Cc: 
>> Glen
>> Daniels
>>
>> Please respond to
>> axis-dev 
>>
>>
>>
>>
>>
>>
>> __
>>
>>
>>
>> That is not correct. The entire Javadoc of the cleanupTransport method
>> was written before the introd

Re: [Axis2] Re: svn commit: r835113 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/client/ServiceClient.java

2009-11-13 Thread Glen Daniels
Hi Bill, Andreas, all:

Just circling around to this.  Thanks, Andreas, for your catch here.  The
default for AUTO_OPERATION_CLEANUP was definitely intended to be true,
specifically to make avoiding the connection starvation problem as effortless
(and backwards compatible) as possible.  Please revert that part of the
change if you would, Roy?

ServiceClients (and by association Stubs) are *not* meant to be thread-safe.
 There were a number of discussions about this in 2006, 2007, 2008... if the
docs aren't crystal-clear on this then I definitely agree we should fix them.

Re: the JavaDoc on cleanupTransport(), that's my bad - we do NOT build() the
full Axiom tree by default with AUTO_OPERATION_CLEANUP, only when
options.isCallTransportCleanup() is true.  The build() actually happens in
sendReceive() and the JavaDoc discussing it should be there, not on
cleanupTransport().  I apologize for not neatening that up when I made the fix.

I'd like to open a separate discussion as to how to make this whole cleanup
issue work *right* for Axis2 1.6 (*), and deprecate the ways we've been doing
it up until now, but for now we have three options - 1) use
AUTO_OPERATION_CLEANUP by default which cleans up the *last* OperationContext
each time you make a new one, 2) use options.setCallTransportCleanup(), which
cleans up the *current* OperationContext at the end, accepting the build()
limitations, and 3) shut off both of the above and clean up manually.

Thanks,
--Glen

(*) IMHO there should be a way to have Axiom auto-trigger a cleanup if we
reach the end of the inputStream, and if we don't ever read to the end for a
given operation, we'll still need some automatic mechanism involving timeouts
or heuristics

Bill Nagy wrote:
> Ignoring the performance degradation for a moment, the
> AUTO_OPERATION_CLEANUP feature had removed thread-safety from the
> ServiceClient (i.e. if two threads invoke
> serviceclient.createClient(...), there is the distinct possibility that,
> before Roy's modification, the code would have cleaned up the transport
> before the first invoking thread had finished.)
> 
> If the ServiceClient is not meant to be thread-safe, then this needs to
> be explicitly stated in the JavaDoc and the JAX-WS code will need to be
> reworked to take this into account.
> 
> If the ServiceClient is supposed to be thread-safe, then either the
> default should remain as Roy has set it (i.e. to be 'false') or the
> cleanup code needs to be rewritten so as not to cause threading issues.
> 
> -Bill
> 
> 
> On Thu, 2009-11-12 at 17:44 -0600, Roy Wood wrote:
>> Andreas, 
>> Yes, I agree...thanks for the correction. I went back and did a quick
>> search on AUTO_OPERATION_CLEANUP and didn't find any intent on what
>> the 
>> actual default should be, other than the original code using a default
>> of 'true'. 
>>
>> This property came to our attention when we ran into a threading
>> problem in one of our test cases. By setting the default to false,
>> thus disabling the call to 
>> 'cleanupTransport' in createClient, the threading problem disappeared.
>> I'm also a bit concerned about the performance warning in
>> cleanupTransport 
>> javadocs. For that reason, as well as, providing a degree backwards
>> compatability,  I would like to propose that the default for this
>> property be 'false'. 
>>
>> Roy A. Wood, Jr.
>> WebSphere Development - Web Services
>> wood...@us.ibm.com
>> 512-286-9307  T/L:363-9307
>> 11501 Burnet Road,  Austin TX   78758 (Internal ZIP: 9372) 
>>
>>
>>
>> Re: svn commit: r835113
>> - 
>> /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/client/ServiceClient.java
>>
>> Andreas
>> Veithen 
>> to: 
>> axis-dev 
>> 11/12/2009 03:30 PM
>>
>> Cc: 
>> Glen
>> Daniels
>>
>> Please respond to
>> axis-dev 
>>
>>
>>
>>
>>
>>
>> __
>>
>>
>>
>> That is not correct. The entire Javadoc of the cleanupTransport method
>> was written before the introduction of the AUTO_OPERATION_CLEANUP
>> property. It only refers to "callTransportCleanup", which is a
>> different property. Since the AUTO_OPERATION_CLEANUP feature is
>> something that has been recently introduced by Glen for the 1.5.1
>> release, it would be good to start a discussion to get his feedback if
>> you think that the default value should be different for the next
>> release.
>>
>> Andreas
>>
>> On Wed, Nov 11, 2009 at 23:54,   wrote:
>>> Author: woodroy
>>> Date: Wed Nov 11 22:54:35 2009
>>> New Revision: 835113
>>>
>>> URL: http://svn.apache.org/viewvc?rev=835113&view=rev
>>> Log:
>>> Use proper default value of AUTO_OPERATION_CLEANUP property
>>>
>>> Javadoc for cleanupTransport states the default value is 'false'
>>>
>>> Modified:
>>>
>>  
>> webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/client/ServiceClient.java
>>> Modified:
>> webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/client/ServiceClient.java
>>> URL:
>> http://svn.apache.org/v

Re: [Axis2] release process

2009-11-13 Thread Amila Suriarachchi
On Wed, Nov 4, 2009 at 1:05 PM, Michail Prusakov
wrote:

> Hello Keith,
>
> Thank you for your answer. Could Amila also take a look at this bug:
> https://issues.apache.org/jira/browse/AXIS2-4544.


fixed the issue thanks for info.

Amila.


> He has posted in his blog (
> http://amilachinthaka.blogspot.com/2009/09/handling-date-and-datetime-with-axis2.html)
> that the java.util.Date interpretation has changed and apparently is not
> working properly at the moment. I've posted a fix, which solves the problem.
>
> Regards,
> Mike
>
>

-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/


Re: Axis2 Transports release (Web Site)

2009-11-12 Thread Ruwan Linton
It should be the responsibility of the whole team, but for this release I am
planing to finish up some documentation and do the release.

Ruwan

On Fri, Nov 13, 2009 at 1:38 AM, Andreas Veithen
wrote:

> The question is not so much where to host the site (should be
> http://ws.apache.org/commons/transport/), but who is going to complete
> the documentation...
>
> Andreas
>
> On Thu, Nov 12, 2009 at 09:41, Ruwan Linton 
> wrote:
> > Folks,
> >
> > I am ready to do the axis2 transports 1.0 release and I have an issue
> > regarding the transports web site, what are we going to do for the web
> site
> > and documentation.
> >
> > Where are we going to host the transports site??
> >
> > Thanks,
> > Ruwan
> >
> > --
> > Ruwan Linton
> > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
> > WSO2 Inc.; http://wso2.org
> > email: ru...@wso2.com; cell: +94 77 341 3097
> > blog: http://ruwansblog.blogspot.com
> >
>



-- 
Ruwan Linton
Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ru...@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com


Re: Axis2 Transports release (Web Site)

2009-11-12 Thread Ruwan Linton
We should be able to do transport releases separately and transports is a
separate project just like Sandesha and Rampart under Axis2 so it needs a
web site from my PoV :-(

Thanks,
Ruwan

On Thu, Nov 12, 2009 at 6:49 PM, Deepal jayasinghe wrote:

> I do not think we need to have a new website. Documentation is in Axis2
> website, and with Axis2 TLP we are going to move transport back into
> axis2, so no need to create a website just for few days.
>
> Thanks,
> Deepal
> > Folks,
> >
> > I am ready to do the axis2 transports 1.0 release and I have an issue
> > regarding the transports web site, what are we going to do for the web
> site
> > and documentation.
> >
> > Where are we going to host the transports site??
> >
> > Thanks,
> > Ruwan
> >
> >
>
>
> --
> Thank you!
>
>
> http://blogs.deepal.org
> http://deepal.org
>
>


-- 
Ruwan Linton
Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ru...@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com


Re: Axis2 Transports release (Web Site)

2009-11-12 Thread Andreas Veithen
The question is not so much where to host the site (should be
http://ws.apache.org/commons/transport/), but who is going to complete
the documentation...

Andreas

On Thu, Nov 12, 2009 at 09:41, Ruwan Linton  wrote:
> Folks,
>
> I am ready to do the axis2 transports 1.0 release and I have an issue
> regarding the transports web site, what are we going to do for the web site
> and documentation.
>
> Where are we going to host the transports site??
>
> Thanks,
> Ruwan
>
> --
> Ruwan Linton
> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
> WSO2 Inc.; http://wso2.org
> email: ru...@wso2.com; cell: +94 77 341 3097
> blog: http://ruwansblog.blogspot.com
>


Re: Axis2 Transports release (Web Site)

2009-11-12 Thread Deepal jayasinghe
I do not think we need to have a new website. Documentation is in Axis2
website, and with Axis2 TLP we are going to move transport back into
axis2, so no need to create a website just for few days.

Thanks,
Deepal
> Folks,
>
> I am ready to do the axis2 transports 1.0 release and I have an issue
> regarding the transports web site, what are we going to do for the web site
> and documentation.
>
> Where are we going to host the transports site??
>
> Thanks,
> Ruwan
>
>   


-- 
Thank you!


http://blogs.deepal.org
http://deepal.org



Re: [Axis2] Update to JAX-WS 2.2

2009-11-09 Thread Davanum Srinivas

Looks like email to secret...@apache.org / fax to +1-919-573-9199
http://markmail.org/message/bz6q5oyjrj3hb37v

The mailing list itself is:
jaxws-tck AT incubator.apache.org (sorry i wrote the wrong address before)

You may also want to join: (where you can ask questions on existing resources, 
this is a public list)
jcp-open AT apache.org

thanks,
dims

On 11/09/2009 03:02 AM, Isuru Suriarachchi wrote:

Hi Dims,

I'm interested in joining this axis-tck mailing list and getting access to
the TCK. Could you please tell me the fax number to send this NDA? it's not
there in the jcp page.

And also I think we need some improvements in the JAXWS user guide as well.
Isn't it? For example, it still says that we can deploy JAXWS services as an
AAR in repository/services. I think it's only possible as a .jar in
repository/servicejars.

Thanks,
~Isuru

On Sat, Oct 31, 2009 at 11:28 PM, Davanum Srinivaswrote:


Sagara,

fyi, Jarek and DanKulp have done the hard work already. There is a axis-tck
mailing list that you can join once you sign and fax in the NDA. Then Jarek
can set you up with the TCK as well as the harness needed to run axis2.

http://www.apache.org/jcp/ApacheNDA.pdf

thanks,
-- dims


On 10/31/2009 12:31 PM, Sagara Gunathunga wrote:


   Sorry for move this discussion in to a different direction :)

   Any one have any idea about what is the status of Axis2 passing
JAX-WS TCK ?  If  I'm correct sometimes ago there was a discussion to
share works with CXF.

Thanks ,

On 10/31/09, Bill Nagy   wrote:


(I forgot the [Axis2] prefix on my original note -- sorry to anyone who
  missed it.)

  If they are necessary to pass the CTS test suites, then yes.  Otherwise
  I can't make any promises.


  -Bill


  On Fri, 2009-10-30 at 23:15 +0530, Isuru Suriarachchi wrote:
  >   Hi Bill,
  >
  >   AFAIK, there are some WSDL generation issues in our JAX-WS
  >   implementation. Specially when Complex types are involved. Are you
  >   going to address those issues as well during this improvement?
  >
  >   Thanks,
  >   ~Isuru
  >
  >
  >   On Fri, Oct 30, 2009 at 7:22 PM, Bill Nagy
  >   wrote:
  >   I just wanted to give everyone a heads-up that we are going
to
  >   start
  >   upgrading the JAX-WS support to conform to the 2.2 spec
  >   relatively soon.
  >   The spec update may be found at
  >   http://jcp.org/en/jsr/detail?id=224.
  >
  >   -Bill
  >
  >
  >
  >
  >
  >















Re: [Axis2] Update to JAX-WS 2.2

2009-11-09 Thread Isuru Suriarachchi
Hi Dims,

I'm interested in joining this axis-tck mailing list and getting access to
the TCK. Could you please tell me the fax number to send this NDA? it's not
there in the jcp page.

And also I think we need some improvements in the JAXWS user guide as well.
Isn't it? For example, it still says that we can deploy JAXWS services as an
AAR in repository/services. I think it's only possible as a .jar in
repository/servicejars.

Thanks,
~Isuru

On Sat, Oct 31, 2009 at 11:28 PM, Davanum Srinivas wrote:

> Sagara,
>
> fyi, Jarek and DanKulp have done the hard work already. There is a axis-tck
> mailing list that you can join once you sign and fax in the NDA. Then Jarek
> can set you up with the TCK as well as the harness needed to run axis2.
>
> http://www.apache.org/jcp/ApacheNDA.pdf
>
> thanks,
> -- dims
>
>
> On 10/31/2009 12:31 PM, Sagara Gunathunga wrote:
>
>>   Sorry for move this discussion in to a different direction :)
>>
>>   Any one have any idea about what is the status of Axis2 passing
>> JAX-WS TCK ?  If  I'm correct sometimes ago there was a discussion to
>> share works with CXF.
>>
>> Thanks ,
>>
>> On 10/31/09, Bill Nagy  wrote:
>>
>>> (I forgot the [Axis2] prefix on my original note -- sorry to anyone who
>>>  missed it.)
>>>
>>>  If they are necessary to pass the CTS test suites, then yes.  Otherwise
>>>  I can't make any promises.
>>>
>>>
>>>  -Bill
>>>
>>>
>>>  On Fri, 2009-10-30 at 23:15 +0530, Isuru Suriarachchi wrote:
>>>  >  Hi Bill,
>>>  >
>>>  >  AFAIK, there are some WSDL generation issues in our JAX-WS
>>>  >  implementation. Specially when Complex types are involved. Are you
>>>  >  going to address those issues as well during this improvement?
>>>  >
>>>  >  Thanks,
>>>  >  ~Isuru
>>>  >
>>>  >
>>>  >  On Fri, Oct 30, 2009 at 7:22 PM, Bill Nagy
>>>  >  wrote:
>>>  >  I just wanted to give everyone a heads-up that we are going
>>> to
>>>  >  start
>>>  >  upgrading the JAX-WS support to conform to the 2.2 spec
>>>  >  relatively soon.
>>>  >  The spec update may be found at
>>>  >  http://jcp.org/en/jsr/detail?id=224.
>>>  >
>>>  >  -Bill
>>>  >
>>>  >
>>>  >
>>>  >
>>>  >
>>>  >
>>>
>>>
>>>
>>
>>
>


-- 
Senior Software Engineer,
WSO2 Inc. http://wso2.org/
Blog : http://isurues.wordpress.com/


Re: [Axis2] release process

2009-11-03 Thread Michail Prusakov

Hello Keith,

Thank you for your answer. Could Amila also take a look at this bug: 
https://issues.apache.org/jira/browse/AXIS2-4544. He has posted in his 
blog 
(http://amilachinthaka.blogspot.com/2009/09/handling-date-and-datetime-with-axis2.html) 
that the java.util.Date interpretation has changed and apparently is not 
working properly at the moment. I've posted a fix, which solves the problem.


Regards,
Mike

Keith Chapman wrote:

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 
mailto:michail.prusa...@jmsys.lt>> wrote:


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: [Axis2] release process

2009-11-03 Thread Keith Chapman
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
wrote:

> 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: [Axis2] Update to JAX-WS 2.2

2009-10-31 Thread Davanum Srinivas

Sagara,

fyi, Jarek and DanKulp have done the hard work already. There is a axis-tck mailing list that you can join once you sign 
and fax in the NDA. Then Jarek can set you up with the TCK as well as the harness needed to run axis2.


http://www.apache.org/jcp/ApacheNDA.pdf

thanks,
-- dims

On 10/31/2009 12:31 PM, Sagara Gunathunga wrote:

   Sorry for move this discussion in to a different direction :)

   Any one have any idea about what is the status of Axis2 passing
JAX-WS TCK ?  If  I'm correct sometimes ago there was a discussion to
share works with CXF.

Thanks ,

On 10/31/09, Bill Nagy  wrote:

(I forgot the [Axis2] prefix on my original note -- sorry to anyone who
  missed it.)

  If they are necessary to pass the CTS test suites, then yes.  Otherwise
  I can't make any promises.


  -Bill


  On Fri, 2009-10-30 at 23:15 +0530, Isuru Suriarachchi wrote:
  >  Hi Bill,
  >
  >  AFAIK, there are some WSDL generation issues in our JAX-WS
  >  implementation. Specially when Complex types are involved. Are you
  >  going to address those issues as well during this improvement?
  >
  >  Thanks,
  >  ~Isuru
  >
  >
  >  On Fri, Oct 30, 2009 at 7:22 PM, Bill Nagy
  >  wrote:
  >  I just wanted to give everyone a heads-up that we are going to
  >  start
  >  upgrading the JAX-WS support to conform to the 2.2 spec
  >  relatively soon.
  >  The spec update may be found at
  >  http://jcp.org/en/jsr/detail?id=224.
  >
  >  -Bill
  >
  >
  >
  >
  >
  >









Re: [Axis2] Update to JAX-WS 2.2

2009-10-31 Thread Sagara Gunathunga
  Sorry for move this discussion in to a different direction :)

  Any one have any idea about what is the status of Axis2 passing
JAX-WS TCK ?  If  I'm correct sometimes ago there was a discussion to
share works with CXF.

Thanks ,

On 10/31/09, Bill Nagy  wrote:
> (I forgot the [Axis2] prefix on my original note -- sorry to anyone who
>  missed it.)
>
>  If they are necessary to pass the CTS test suites, then yes.  Otherwise
>  I can't make any promises.
>
>
>  -Bill
>
>
>  On Fri, 2009-10-30 at 23:15 +0530, Isuru Suriarachchi wrote:
>  > Hi Bill,
>  >
>  > AFAIK, there are some WSDL generation issues in our JAX-WS
>  > implementation. Specially when Complex types are involved. Are you
>  > going to address those issues as well during this improvement?
>  >
>  > Thanks,
>  > ~Isuru
>  >
>  >
>  > On Fri, Oct 30, 2009 at 7:22 PM, Bill Nagy 
>  > wrote:
>  > I just wanted to give everyone a heads-up that we are going to
>  > start
>  > upgrading the JAX-WS support to conform to the 2.2 spec
>  > relatively soon.
>  > The spec update may be found at
>  > http://jcp.org/en/jsr/detail?id=224.
>  >
>  > -Bill
>  >
>  >
>  >
>  >
>  >
>  >
>
>


-- 
Sagara Gunathunga

Blog - http://ssagara.blogspot.com
Web - http://people.apache.org/~sagara/


Re: [Axis2] Update to JAX-WS 2.2

2009-10-31 Thread Bill Nagy
(I forgot the [Axis2] prefix on my original note -- sorry to anyone who
missed it.)

If they are necessary to pass the CTS test suites, then yes.  Otherwise
I can't make any promises.

-Bill

On Fri, 2009-10-30 at 23:15 +0530, Isuru Suriarachchi wrote:
> Hi Bill,
>  
> AFAIK, there are some WSDL generation issues in our JAX-WS
> implementation. Specially when Complex types are involved. Are you
> going to address those issues as well during this improvement? 
>  
> Thanks,
> ~Isuru
> 
> 
> On Fri, Oct 30, 2009 at 7:22 PM, Bill Nagy 
> wrote:
> I just wanted to give everyone a heads-up that we are going to
> start
> upgrading the JAX-WS support to conform to the 2.2 spec
> relatively soon.
> The spec update may be found at
> http://jcp.org/en/jsr/detail?id=224.
> 
> -Bill
> 
> 
> 
> 
> 
> 



Re: axis2 security bug?

2009-10-21 Thread Keith Chapman
To answer your question on the action attribute, It is a optional part of
the Content-Type header (When SOAP 1.2 is used which is your case) which
gives a hint to the server to dispatch the request. If you had used SOAP 1.1
it would have been a separate HTTP header called soapaction (Which is
mandatory in SOAP 1.1).

Thanks,
Keith.

On Wed, Oct 21, 2009 at 9:24 AM, Jaime Hablutzel Egoavil <
hablutz...@gmail.com> wrote:

> I'm using wso2 for axis2 spring support:
>
> pom.xml (extract)
>
>
> org.apache.rampart
> rampart-core
> 1.4
> 
>
>
> 
> org.apache.axis2
> axis2-kernel
> 1.4.1
> 
>
> 
> org.wso2.spring.ws
> wsf-spring
> 1.5
> 
>
> applicationContext.xml
>
> 
> 
>
> 
>  ref="emrauthws">
>  value="emrAuthWs">
>  value="Provee de metodos para acceder a informacion
> detallada.">
> 
> 
> rampart
> 
> 
> 
> 
> 
> policy.xml
> 
> 
> 
> 
>
> 
> 
> 
>
>
> policy.xml
>
>
>  xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";>
> 
> 
>  xmlns:sp="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
> 
> 
> 
>  />
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  xmlns:sp="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
> 
>  sp:IncludeToken="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient";
> />
> 
> 
> http://ws.apache.org/rampart/policy";>
>
> pe.gob.hndac.ldap.PasswordCallbackHandler
> 
> 
> 
> 
>
>
> with rampart-1.3.mar in the classpath, after all, what is content-type
> action attribute for?
>
>
> On Wed, Oct 21, 2009 at 1:33 AM, Amila Suriarachchi <
> amilasuriarach...@gmail.com> wrote:
>
>> what is the axis2 version you use?
>>
>> thanks,
>> Amila.
>>
>>
>> On Tue, Oct 20, 2009 at 7:10 PM, Jaime Hablutzel Egoavil <
>> hablutz...@gmail.com> wrote:
>>
>>> Hi, I'm a newbie in web services and security, I'm using wso2 as an axis2
>>> wrapper for making working with Spring easier, well
>>>
>>> I have published a service that requires user token authentication and
>>> SSL transport using this policy:
>>>
>>> >> xmlns:wsu="
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>> "
>>> xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";>
>>> 
>>> 
>>> >> xmlns:sp="
>>> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
>>> 
>>> 
>>> 
>>> >> RequireClientCertificate="false" />
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> >> xmlns:sp="
>>> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
>>> 
>>> >> sp:IncludeToken="
>>> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient";
>>> />
>>> 
>>> 
>>> http://ws.apache.org/rampart/policy";>
>>>
>>> pe.gob.hndac.ldap.PasswordCallbackHandler
>>> 
>>> 
>>> 
>>> 
>>>
>>> If i send this request (sniffed with TCPmon)
>>>
>>> POST
>>> http://172.17.0.24:8080/emrws/services/emrAuthWs.emrAuthWsHttpSoap12Endpoint/HTTP/1.1
>>> User-Agent: Axis2C/1.5.0
>>> Content-Type: application/soap+xml;charset=UTF-8
>>> ;action="urn:getPatientDetails"
>>> Host: 172.17.0.24:8080
>>> Content-Length: 310
>>>
>>> http://www.w3.org/2003/05/soap-envelope";
>>> xmlns:ws=

Re: axis2 security bug?

2009-10-21 Thread Jaime Hablutzel Egoavil
I'm using wso2 for axis2 spring support:

pom.xml (extract)

   
org.apache.rampart
rampart-core
1.4




org.apache.axis2
axis2-kernel
1.4.1



org.wso2.spring.ws
wsf-spring
1.5


applicationContext.xml










rampart





policy.xml










policy.xml

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";>


http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>



















http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>

http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient";
/>


http://ws.apache.org/rampart/policy";>

pe.gob.hndac.ldap.PasswordCallbackHandler






with rampart-1.3.mar in the classpath, after all, what is content-type
action attribute for?


On Wed, Oct 21, 2009 at 1:33 AM, Amila Suriarachchi <
amilasuriarach...@gmail.com> wrote:

> what is the axis2 version you use?
>
> thanks,
> Amila.
>
>
> On Tue, Oct 20, 2009 at 7:10 PM, Jaime Hablutzel Egoavil <
> hablutz...@gmail.com> wrote:
>
>> Hi, I'm a newbie in web services and security, I'm using wso2 as an axis2
>> wrapper for making working with Spring easier, well
>>
>> I have published a service that requires user token authentication and SSL
>> transport using this policy:
>>
>> > xmlns:wsu="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>> "
>> xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";>
>> 
>> 
>> > xmlns:sp="
>> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
>> 
>> 
>> 
>> > RequireClientCertificate="false" />
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> > xmlns:sp="
>> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
>> 
>> > sp:IncludeToken="
>> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient";
>> />
>> 
>> 
>> http://ws.apache.org/rampart/policy";>
>>
>> pe.gob.hndac.ldap.PasswordCallbackHandler
>> 
>> 
>> 
>> 
>>
>> If i send this request (sniffed with TCPmon)
>>
>> POST
>> http://172.17.0.24:8080/emrws/services/emrAuthWs.emrAuthWsHttpSoap12Endpoint/HTTP/1.1
>> User-Agent: Axis2C/1.5.0
>> Content-Type: application/soap+xml;charset=UTF-8
>> ;action="urn:getPatientDetails"
>> Host: 172.17.0.24:8080
>> Content-Length: 310
>>
>> http://www.w3.org/2003/05/soap-envelope";
>> xmlns:ws="http://ws.hndac.gob.pe";>
>>
>>
>>   
>>  
>>  12
>>   
>>
>> 
>>
>> I receive this answer:
>>
>> http://www.w3.org/2003/05/soap-envelope
>> ">
>>
>>   http://www.w3.org/2003/05/soap-envelope";>
>>  
>> axis2ns19:Sender
>> 
>>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>> ">wsse:InvalidSecurity
>> 
>>  
>>  
>> Missing wsse:Security header
>> in request
>>  
>>  
>>   
>>
>> 
>>
>>
>> Ok, this is an axis fault, it is ok, but if I send:
>>
>> POST
>> http://172.17.0.24:8080/emrws/services/emrAuthWs.emrAuthWsHttpSoap12Endpoint/HTTP/1.1
>> User-Agent: Axis2C/1.5.0
>> Content-Length: 294
>> Content-Type: application/soap+xml;charset=UTF-8
>> Host: 172.17.0.24:8080
>>
>> > xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope";>> xmlns:

Re: axis2 security bug?

2009-10-20 Thread Amila Suriarachchi
what is the axis2 version you use?

thanks,
Amila.

On Tue, Oct 20, 2009 at 7:10 PM, Jaime Hablutzel Egoavil <
hablutz...@gmail.com> wrote:

> Hi, I'm a newbie in web services and security, I'm using wso2 as an axis2
> wrapper for making working with Spring easier, well
>
> I have published a service that requires user token authentication and SSL
> transport using this policy:
>
>  xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";>
> 
> 
>  xmlns:sp="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
> 
> 
> 
>  />
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  xmlns:sp="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
> 
>  sp:IncludeToken="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient";
> />
> 
> 
> http://ws.apache.org/rampart/policy";>
>
> pe.gob.hndac.ldap.PasswordCallbackHandler
> 
> 
> 
> 
>
> If i send this request (sniffed with TCPmon)
>
> POST
> http://172.17.0.24:8080/emrws/services/emrAuthWs.emrAuthWsHttpSoap12Endpoint/HTTP/1.1
> User-Agent: Axis2C/1.5.0
> Content-Type: application/soap+xml;charset=UTF-8
> ;action="urn:getPatientDetails"
> Host: 172.17.0.24:8080
> Content-Length: 310
>
> http://www.w3.org/2003/05/soap-envelope";
> xmlns:ws="http://ws.hndac.gob.pe";>
>
>
>   
>  
>  12
>   
>
> 
>
> I receive this answer:
>
> http://www.w3.org/2003/05/soap-envelope";>
>
>   http://www.w3.org/2003/05/soap-envelope";>
>  
> axis2ns19:Sender
> 
>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> ">wsse:InvalidSecurity
> 
>  
>  
> Missing wsse:Security header in
> request
>  
>  
>   
>
> 
>
>
> Ok, this is an axis fault, it is ok, but if I send:
>
> POST
> http://172.17.0.24:8080/emrws/services/emrAuthWs.emrAuthWsHttpSoap12Endpoint/HTTP/1.1
> User-Agent: Axis2C/1.5.0
> Content-Length: 294
> Content-Type: application/soap+xml;charset=UTF-8
> Host: 172.17.0.24:8080
>
>  xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope";> xmlns:ws="http://ws.hndac.gob.pe";>
>  
>  12
> 
>
> Note the missing action attribute in the http content-type header, I
> receive this answer:
>
> HTTP/1.1 200 OK
> Server: Apache-Coyote/1.1
> Content-Type: application/soap+xml;
> action="urn:getPatientDetailsResponse";charset=UTF-8
> Transfer-Encoding: chunked
> Date: Tue, 20 Oct 2009 13:30:41 GMT
>
> 641
> http://www.w3.org/2003/05/soap-envelope";>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
> soapenv:mustUnderstand="true">http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> wsu:Id="Timestamp-16078681">2009-10-20T13:30:41.184Z2009-10-20T13:35:41.184Z xmlns:ns="http://ws.hndac.gob.pe";>http://model/xsd";
> type="model.Paciente">ALFAROSAENZ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:nil="true"
> />http://www.w3.org/2001/XMLSchema-instance"; xsi:nil="true"
> />http://www.w3.org/2001/XMLSchema-instance";
> xsi:nil="true"
> />1957-08-16T05:00:00.000Z12CARMEN
> ROSAFhttp://www.w3.org/2001/XMLSchema-instance"; xsi:nil="true"
> />http://www.w3.org/2001/XMLSchema-instance"; xsi:nil="true"
> />http://www.w3.org/2001/XMLSchema-instance"; xsi:nil="true"
> />
> 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/


Re: [axis2] Status on Axis2 1.5.1 and Rampart 1.5

2009-10-13 Thread Andreas Veithen
On Mon, Oct 12, 2009 at 16:08, Glen Daniels  wrote:
> Hi folks!
>
> OK, so here are the results of my weekend investigations.  The lockup when
> running the Rampart 1.5 tests with Axis2 1.5.1 was due to http connection
> starvation.  I've fixed two issues and everything works now, but I'd like to
> respin both Axis2 1.5.1 and Rampart 1.5 as a result.  Details below.
>
> First, a quick summary of a major change in Axis2 1.5.1 : we were formerly
> creating new MultithreadedHTTPConenctionManagers all the time in the HTTP
> sender code.  In typical usage you'd never see connection pool starvation
> (since each new MHCM had a new pool), but two major problems occurred.  1)
> Connection reuse wasn't really possible, and 2) we would eventually (in
> high-volume situations) run into the OS limits for open sockets.  So I fixed
> this so that 1.5.1 now re-uses a single MHCM for each ConfigurationContext,
> which allows for sharing connections across ServiceClient instances.
>
> The bigger problem *behind* the problem above is that users of the commons
> HTTPClient library (like Axis2) need to call releaseConnection() on each and
> every HTTPMethod after they are finished.  The
> ServiceClient.cleanupTransport() call does this, but since we never told
> people to call that explicitly,

Well, I did :-) See [1] and [2].

Andreas

[1] http://markmail.org/message/c7wqfwzl23qrheic
[2] http://svn.apache.org/viewvc?view=rev&revision=748730

> no one was in the habit of doing it.  A
> number of bugs about connection starvation came up, and we put in the
> Options.setCallTransportCleanup() option, which automatically calls
> cleanupTransport() after each call, but at a cost - since we're releasing
> connection resources you need to make sure you've read everything, which
> means building the whole Axiom tree.  Bye-bye, streaming.  So I also added a
> different connection cleanup option which automatically cleans up the *last*
> operation as you're setting up the next one.
>
> So, to make the Rampart story very short, the problem was this: a new
> ServiceClient gets created to deal with SecureConversation interactions (see
> STSClient.getServiceClient()).  This SC shares the same ConfigurationContext
> with the outer (i.e. user) SC, so it shares a MHCM and a connection pool.
> The problem is since the STS operations happen inside a user-level operation,
> the record of the "last operation" gets overwritten, and as a result my
> automatic cleanup mechanism can't catch both!  So we lose one connection each
> time we go through the STS process, and that causes a hard lock.
>
> SOLUTION
> 
>
> I did two things to fix this, both of which I think should be reflected in
> the released code.  First, in Rampart, I added a call to
> setCallTransportCleanup(true) in STSClient - this means that the STS
> operations will be forced to build the complete Axiom tree (see above), but
> solves the connection starvation issue.  Second, in Axis2, I added a default
> 30-second timeout while waiting for new connections - this doesn't change the
> functionality at all, but it does mean that we can no longer get into
> situations where the system just locks up forever.  With that change, we'll
> now at least get an Exception if there's a starvation issue, which can then
> be debugged.
>
> Nandana/all, can you check what I did in Rampart and let me know if you
> foresee any problems with it?  I'm going to respin Axis2 1.5.1 with this and
> one other fix, and we should respin Rampart 1.5 as well.
>
> Thoughts/comments?
>
> Thanks,
> --Glen
>


Re: [axis2] Status on Axis2 1.5.1 and Rampart 1.5

2009-10-13 Thread Ruwan Linton
+1 for re-spining the votes.

Thanks,
Ruwan

On Tue, Oct 13, 2009 at 5:24 AM, Nandana Mihindukulasooriya <
nandana@gmail.com> wrote:

> Hi Glen
>
> Nandana/all, can you check what I did in Rampart and let me know if you
>> foresee any problems with it?  I'm going to respin Axis2 1.5.1 with this
>> and
>> one other fix, and we should respin Rampart 1.5 as well.
>>
>
> +1 for re-spining both Axis2 1.5.1 and Rampart 1.5. I checked the change in
> STSClient and it does't seem to have side effects on Rampart functionality.
>
> thanks,
> Nandana
>



-- 
Ruwan Linton
Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ru...@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com


Re: [axis2] Status on Axis2 1.5.1 and Rampart 1.5

2009-10-12 Thread Nandana Mihindukulasooriya
Hi Glen

Nandana/all, can you check what I did in Rampart and let me know if you
> foresee any problems with it?  I'm going to respin Axis2 1.5.1 with this
> and
> one other fix, and we should respin Rampart 1.5 as well.
>

+1 for re-spining both Axis2 1.5.1 and Rampart 1.5. I checked the change in
STSClient and it does't seem to have side effects on Rampart functionality.

thanks,
Nandana


Re: [Axis2] Axis2 war deployment does not work in the current trunk

2009-10-05 Thread Deepal jayasinghe
Thanks Amila, now it works.
>
>
> On Mon, Oct 5, 2009 at 8:44 AM, Deepal jayasinghe  > wrote:
>
> Hi Devs;
>
> I build the war from the trunk and try to deploy that, everything
> works
> fine. However when I try to list the services it gave me the following
> error. I think  this has something to do with the changes that Andreas
> did.
>
>
> No this from the later change I did. Now it is fixed in the trunk.
>
> For this fix we need to shift a separate axis2.xml
> for web app with the new transports. Will do that as well.
>
> thanks,
> Amila.
>  
>
>
> javax.servlet.ServletException: http is forbidden
>at
> 
> org.apache.axis2.transport.http.AxisServlet.preprocessRequest(AxisServlet.java:628)
>at
> org.apache.axis2.transport.http.AxisServlet.doGet(AxisServlet.java:246)
>at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
>at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>at
> 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
>at
> 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>
>
> As I can see this is a big issues (unless I have something done
> wrong).
>
> I just went though the source code and found few issues with that,
> so we
> need to fix those;  Following code in AxisServlet is not correct.
>
>
>httpListener =
> getAxisServletListener(Constants.TRANSPORT_HTTP);
>httpsListener =
> getAxisServletListener(Constants.TRANSPORT_HTTPS);
>
>if (httpListener == null && httpsListener == null) {
>log.warn("No transportReceiver for " +
> AxisServletListener.class.getName() +
>" found. An instance for HTTP will be
> configured
> automatically. " +
>"Please update your axis2.xml file!");
>httpListener = new AxisServletListener();
>TransportInDescription transportInDescription = new
> TransportInDescription(
>Constants.TRANSPORT_HTTP);
>transportInDescription.setReceiver(httpListener);
>  
>  axisConfiguration.addTransportIn(transportInDescription);
>} else if (httpListener != null && httpsListener != null
>&& httpListener.getPort() == -1 &&
> httpsListener.getPort() == -1) {
>log.warn("If more than one transportReceiver for " +
>AxisServletListener.class.getName() + " exists,
> then all instances " +
>"must be configured with a port number. WSDL
> generation will be " +
>"unreliable.");
>}
>
>
> Why do we need to call the following method for each request ?
>
> private void preprocessRequest(HttpServletRequest req) throws
> ServletException {
>initContextRoot(req);
>
>TransportInDescription transportInDescription =
>req.isSecure()?
> this.axisConfiguration.getTransportIn(Constants.TRANSPORT_HTTP) :
>
> this.axisConfiguration.getTransportIn(Constants.TRANSPORT_HTTPS);
>
>if (transportInDescription == null){
>throw new ServletException(req.getScheme() + " is
> forbidden");
>} else {
>if (transportInDescription.getReceiver() instanceof
> AxisServletListener){
>AxisServletListener listner = (AxisServletListener)
> transportInDescription.getReceiver();
>// Autodetect the port number if necessary
>if (listner.getPort() == -1){
>listner.setPort(req.getServerPort());
>}
>}
>}
>
>}
>
>
> As I can see something is really broken, please fix it (or else I
> might
> have to revert to the original AxisServlet code).
>
> Thanks,
> Deepal
>
>
>
>
> -- 
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/


-- 
Thank you!


http://blogs.deepal.org
http://deepal.org



Re: [Axis2] Axis2 war deployment does not work in the current trunk

2009-10-04 Thread Amila Suriarachchi
On Mon, Oct 5, 2009 at 8:44 AM, Deepal jayasinghe  wrote:

> Hi Devs;
>
> I build the war from the trunk and try to deploy that, everything works
> fine. However when I try to list the services it gave me the following
> error. I think  this has something to do with the changes that Andreas
> did.
>

No this from the later change I did. Now it is fixed in the trunk.

For this fix we need to shift a separate axis2.xml
for web app with the new transports. Will do that as well.

thanks,
Amila.


>
> javax.servlet.ServletException: http is forbidden
>at
>
> org.apache.axis2.transport.http.AxisServlet.preprocessRequest(AxisServlet.java:628)
>at
> org.apache.axis2.transport.http.AxisServlet.doGet(AxisServlet.java:246)
>at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
>at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>at
>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
>at
>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>
>
> As I can see this is a big issues (unless I have something done wrong).
>
> I just went though the source code and found few issues with that, so we
> need to fix those;  Following code in AxisServlet is not correct.
>
>
>httpListener = getAxisServletListener(Constants.TRANSPORT_HTTP);
>httpsListener =
> getAxisServletListener(Constants.TRANSPORT_HTTPS);
>
>if (httpListener == null && httpsListener == null) {
>log.warn("No transportReceiver for " +
> AxisServletListener.class.getName() +
>" found. An instance for HTTP will be configured
> automatically. " +
>"Please update your axis2.xml file!");
>httpListener = new AxisServletListener();
>TransportInDescription transportInDescription = new
> TransportInDescription(
>Constants.TRANSPORT_HTTP);
>transportInDescription.setReceiver(httpListener);
>axisConfiguration.addTransportIn(transportInDescription);
>} else if (httpListener != null && httpsListener != null
>&& httpListener.getPort() == -1 &&
> httpsListener.getPort() == -1) {
>log.warn("If more than one transportReceiver for " +
>AxisServletListener.class.getName() + " exists,
> then all instances " +
>"must be configured with a port number. WSDL
> generation will be " +
>"unreliable.");
>}
>
>
> Why do we need to call the following method for each request ?
>
> private void preprocessRequest(HttpServletRequest req) throws
> ServletException {
>initContextRoot(req);
>
>TransportInDescription transportInDescription =
>req.isSecure()?
> this.axisConfiguration.getTransportIn(Constants.TRANSPORT_HTTP) :
>
> this.axisConfiguration.getTransportIn(Constants.TRANSPORT_HTTPS);
>
>if (transportInDescription == null){
>throw new ServletException(req.getScheme() + " is forbidden");
>} else {
>if (transportInDescription.getReceiver() instanceof
> AxisServletListener){
>AxisServletListener listner = (AxisServletListener)
> transportInDescription.getReceiver();
>// Autodetect the port number if necessary
>if (listner.getPort() == -1){
>listner.setPort(req.getServerPort());
>}
>}
>}
>
>}
>
>
> As I can see something is really broken, please fix it (or else I might
> have to revert to the original AxisServlet code).
>
> Thanks,
> Deepal
>



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/


Re: [Axis2] Adb MTOM bug

2009-10-03 Thread Senaka Fernando
On Thu, Oct 1, 2009 at 11:51 PM, Saminda Abeyruwan wrote:

> Thank you!
>
> Saminda
>
>
> On Tue, Sep 29, 2009 at 1:50 AM, Andreas Veithen <
> andreas.veit...@gmail.com> wrote:
>
>> Yes, this has already been fixed in trunk.
>>
>
Yeah, and this issue should occur only if you were in DEBUG mode (or above)
in log4j.

Thanks,
Senaka.

>
>> Andreas
>>
>> On Tue, Sep 29, 2009 at 07:34, Saminda Abeyruwan 
>> wrote:
>> > Hi Devs,
>> >
>> > I am currently using Axis2 1.5 for my research. I have stumble upon a
>> MTOM
>> > data binding bug.  I have a service which send me a pdf file. The client
>> is
>> > generated using adb. The exception I get is attached herewith.
>> >
>> > I fixed the problem in generated code: where it occurs in "parse" method
>> of
>> > GetResponse (line: 463).
>> >
>> > This line says,
>> >
>> object.set_return(((org.apache.axiom.soap.impl.builder.MTOMStAXSOAPModelBuilder)
>> > ((org.apache.axiom.om.impl.llom.OMStAXWrapper)
>> > reader).getBuilder()).getDataHandler(id));
>> >
>> > IMHO, prior should be changed to
>> >
>> >
>> object.set_return(((OMXMLStreamReaderValidator)reader).getDataHandler(id));
>> >
>> > to generated code to work.  Is this bug already fixed in truck ?. If not
>> > I'll open a JIRA and attahced a patch. I am kinda hate to mess up the
>> > templates. :-)
>> >
>> > I have attached a simple service that can be used to re-create this bug.
>> >
>> > Thank you!
>> >
>> > Saminda
>> >
>> > ==
>> > org.apache.axis2.AxisFault:
>> > org.apache.axiom.om.util.OMXMLStreamReaderValidator cannot be cast to
>> > org.apache.axiom.om.impl.llom.OMStAXWrapper
>> > at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
>> > at
>> >
>> edu.miami.cs.client.LibraryServiceStub.fromOM(LibraryServiceStub.java:1252)
>> > at
>> > edu.miami.cs.client.LibraryServiceStub.get(LibraryServiceStub.java:481)
>> > at Client.main(Client.java:28)
>> > 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:597)
>> >
>> >
>> >
>> > ==
>> >
>> >
>> >
>>
>
>


Re: [Axis2] Adb MTOM bug

2009-10-01 Thread Saminda Abeyruwan
Thank you!

Saminda

On Tue, Sep 29, 2009 at 1:50 AM, Andreas Veithen
wrote:

> Yes, this has already been fixed in trunk.
>
> Andreas
>
> On Tue, Sep 29, 2009 at 07:34, Saminda Abeyruwan 
> wrote:
> > Hi Devs,
> >
> > I am currently using Axis2 1.5 for my research. I have stumble upon a
> MTOM
> > data binding bug.  I have a service which send me a pdf file. The client
> is
> > generated using adb. The exception I get is attached herewith.
> >
> > I fixed the problem in generated code: where it occurs in "parse" method
> of
> > GetResponse (line: 463).
> >
> > This line says,
> >
> object.set_return(((org.apache.axiom.soap.impl.builder.MTOMStAXSOAPModelBuilder)
> > ((org.apache.axiom.om.impl.llom.OMStAXWrapper)
> > reader).getBuilder()).getDataHandler(id));
> >
> > IMHO, prior should be changed to
> >
> >
> object.set_return(((OMXMLStreamReaderValidator)reader).getDataHandler(id));
> >
> > to generated code to work.  Is this bug already fixed in truck ?. If not
> > I'll open a JIRA and attahced a patch. I am kinda hate to mess up the
> > templates. :-)
> >
> > I have attached a simple service that can be used to re-create this bug.
> >
> > Thank you!
> >
> > Saminda
> >
> > ==
> > org.apache.axis2.AxisFault:
> > org.apache.axiom.om.util.OMXMLStreamReaderValidator cannot be cast to
> > org.apache.axiom.om.impl.llom.OMStAXWrapper
> > at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
> > at
> >
> edu.miami.cs.client.LibraryServiceStub.fromOM(LibraryServiceStub.java:1252)
> > at
> > edu.miami.cs.client.LibraryServiceStub.get(LibraryServiceStub.java:481)
> > at Client.main(Client.java:28)
> > 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:597)
> >
> >
> >
> > ==
> >
> >
> >
>


Re: [Axis2] Adb MTOM bug

2009-09-28 Thread Andreas Veithen
Yes, this has already been fixed in trunk.

Andreas

On Tue, Sep 29, 2009 at 07:34, Saminda Abeyruwan  wrote:
> Hi Devs,
>
> I am currently using Axis2 1.5 for my research. I have stumble upon a MTOM
> data binding bug.  I have a service which send me a pdf file. The client is
> generated using adb. The exception I get is attached herewith.
>
> I fixed the problem in generated code: where it occurs in "parse" method of
> GetResponse (line: 463).
>
> This line says,
> object.set_return(((org.apache.axiom.soap.impl.builder.MTOMStAXSOAPModelBuilder)
> ((org.apache.axiom.om.impl.llom.OMStAXWrapper)
> reader).getBuilder()).getDataHandler(id));
>
> IMHO, prior should be changed to
>
> object.set_return(((OMXMLStreamReaderValidator)reader).getDataHandler(id));
>
> to generated code to work.  Is this bug already fixed in truck ?. If not
> I'll open a JIRA and attahced a patch. I am kinda hate to mess up the
> templates. :-)
>
> I have attached a simple service that can be used to re-create this bug.
>
> Thank you!
>
> Saminda
>
> ==
> org.apache.axis2.AxisFault:
> org.apache.axiom.om.util.OMXMLStreamReaderValidator cannot be cast to
> org.apache.axiom.om.impl.llom.OMStAXWrapper
>     at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
>     at
> edu.miami.cs.client.LibraryServiceStub.fromOM(LibraryServiceStub.java:1252)
>     at
> edu.miami.cs.client.LibraryServiceStub.get(LibraryServiceStub.java:481)
>     at Client.main(Client.java:28)
>     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:597)
>
>
>
> ==
>
>
>


Re: [Axis2] WS-Security with JAX-WS?

2009-09-04 Thread Dennis Sosnoski

Hi Prabath,

That's interesting, and I'll mention it to people, but I was looking 
specifically for a way of doing this in Axis2.


Thanks,

 - Dennis


Prabath Siriwardena wrote:

Dennis Sosnoski wrote:
Is there any way to make WS-Security work with JAX-WS? 

You can use WSAS [1] to get this done.

You can deploy a JAX-WS service in WSAS and apply security through 
it's security policy wizard.


Thanks & regards.
-Prabath

[1]: http://wso2.org/projects/wsas/java

I haven't been able to find one - there's no services.xml with 
JAX-WS, and security policy in the WSDL appears to be ignored (and 
stripped from the WSDL supplied by the service).


 - Dennis





Re: [Axis2] WS-Security with JAX-WS?

2009-09-04 Thread Prabath Siriwardena

Dennis Sosnoski wrote:
Is there any way to make WS-Security work with JAX-WS? 

You can use WSAS [1] to get this done.

You can deploy a JAX-WS service in WSAS and apply security through it's 
security policy wizard.


Thanks & regards.
-Prabath

[1]: http://wso2.org/projects/wsas/java

I haven't been able to find one - there's no services.xml with JAX-WS, 
and security policy in the WSDL appears to be ignored (and stripped 
from the WSDL supplied by the service).


 - Dennis





Re: [AXIS2 1.4.1 - Xmlbeans] validating an input parameter with anyType in it

2009-09-03 Thread Michel Etienne

Hello

Since I had no answer yet, I repost my question .
Does anybody have an idea ?
Thanks

Best regards
Michel Etienne


Michel Etienne a écrit :

Hello,
I have a problem when I try to validate an input parameter with an 
AnyType member


I use Xmlbeans and I get this error on the server side (I made a 
sample program to show the problem)


2009-07-06 16:23:16,109 [HttpConnection-8080-1]  
WARNServer - >> Invalid object 
demo.dryade.soap.impl.RequestDocumentImpl
>> error: cvc-elt.4.2: Invalid xsi:type qname: 'typ:SpecificType' in 
element RequestPart
2009-07-06 16:23:16,125 [HttpConnection-8080-1]  
WARNServer - Invalid content =
http://soap.dryade.demo"; 
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>

 
   http://types.dryade.demo";>1
   http://types.dryade.demo";>test
   xmlns:typ="http://types.dryade.demo"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>

 true
 any test
   
 


if the server produce an output with the same AnyType , it validate 
correctly :

in an input-output transaction

2009-07-06 16:23:16,125 [HttpConnection-8080-1]  INFO Server - >> 
Valid object demo.dryade.soap.impl.RequestResponseDocumentImpl


in an ouput-only transaction

2009-07-06 16:23:16,250 [HttpConnection-8080-2]  INFO Server - >> 
Valid object demo.dryade.soap.impl.NotifyDocumentImpl


on the client side, the structures are always valid.

I send you the entire code I used for this exemple; it is made with 
AXIS2 1.4.1 on Windows XP platform with Java 1.6


(I can send the entire project archive if necessary)

Thanks for help

Best regards
Michel Etienne


-

Server source :

package demo.server;

import org.apache.log4j.Logger;

import java.util.ArrayList;

import javax.xml.namespace.QName;

import org.apache.xmlbeans.SchemaType;
import org.apache.xmlbeans.XmlBeans;
import org.apache.xmlbeans.XmlObject;
import org.apache.xmlbeans.XmlOptions;
import org.apache.xmlbeans.XmlValidationError;
import org.apache.xmlbeans.impl.common.QNameHelper;

import demo.dryade.soap.DemoServicesSkeletonInterface;
import demo.dryade.soap.NotifyDocument;
import demo.dryade.soap.RequestDocument;
import demo.dryade.soap.RequestResponseDocument;
import demo.dryade.soap.RequestResponseDocument.RequestResponse;
import demo.dryade.types.ComplexType1;
import demo.dryade.types.SpecificType;

public class Server implements DemoServicesSkeletonInterface
{
/**
* Logger for this class
*/
private static final Logger logger = Logger.getLogger(Server.class);

public static boolean checkXmlSchema(XmlObject object)
{
if (object == null)
{
logger.warn("validation null object");
return false;
}
ArrayList validationErrors = new 
ArrayList();

XmlOptions validationOptions = new XmlOptions();
validationOptions.setErrorListener(validationErrors);

boolean validation = object.validate(validationOptions);
if (!validation)
{
StringBuffer errorTxt = new StringBuffer(">> Invalid object 
"+object.getClass().getName());

for (XmlValidationError error : validationErrors)
{
errorTxt.append("\n >> ");
errorTxt.append(error.toString());
}
logger.warn(errorTxt);
logger.warn("Invalid content = \n"+object.toString());

}
else
{
logger.info(">> Valid object "+object.getClass().getName());
}
return validation;
}



@Override
public RequestResponseDocument Request(RequestDocument request)
{
checkXmlSchema(request);

RequestResponseDocument response = 
RequestResponseDocument.Factory.newInstance();

RequestResponse reqResponse = response.addNewRequestResponse();

ComplexType1 part = reqResponse.addNewResponsePart();

part.addElement1(12);
part.setElement2("test");

SpecificType elt3 = SpecificType.Factory.newInstance();
elt3.setElement4(true);
elt3.setElement5("any test");
part.setElement3(elt3);

checkXmlSchema(response);

return response;
}



@Override
public void Notify(NotifyDocument notify)
{
checkXmlSchema(notify);
}

}

- 



Client Source :

package demo.client;


import java.math.BigInteger;
import java.util.ArrayList;

import org.apache.log4j.Logger;
import org.apache.xmlbeans.XmlObject;
import org.apache.xmlbeans.XmlOptions;
import org.apache.xmlbeans.XmlValidationError;

import demo.dryade.soap.DemoServices;
import demo.dryade.soap.DemoServicesStub;
import demo.dryade.soap.NotifyDocument;
import demo.dryade.soap.RequestDocument;
import demo.dryade.soap.RequestResponseDocument;
import demo.dryade.soap.NotifyDocument.Notify;
import demo.dryade.soap.RequestDocument.Request;
import demo.dryade.types.ComplexType1;
import demo.dryade.types.ComplexType2;
import demo.dryade.types.SpecificType;

/**
* @author michel
*
*/
public class Client
{
/**
* Logger for this class
*/
private static final Logger logger = Logger.getLogger(Client.class);

public static boolean check

Re: [Axis2]multiple service in same archive

2009-08-29 Thread Afkham Azeez
Yes, merging the two services.xml files will work.
Azeez

On Sat, Aug 29, 2009 at 11:38 PM, Glen Daniels wrote:

> One of the main reasons we designed service groups was precisely to allow
> people to deploy related web services in a convenient package.  The
> services.xml format works fine with this IIRC - can't Zooz just merge the
> files manually and put both  elements under a single
> ?
>
> Providing a script for this would be easy, but perhaps too trivial to be
> worth doing.
>
> --Glen
>
> Zooz Bee wrote:
> > No particular reason, just wanted to make one .aar file for my web
> > application. Its a very small application, in terms of request it will
> > receive, serving couple services.
> >
> > -zooz
> >
> > 
> > *From:* Sanjiva Weerawarana 
> > *To:* axis-dev@ws.apache.org
> > *Sent:* Saturday, August 29, 2009 12:50:43 PM
> > *Subject:* Re: [Axis2]multiple service in same archive
> >
> > Are you wanting to put them into a single .aar file for a particular
> > reason? If its just to deploy multiple services then, unlike in Axis1,
> > you don't need to put them into one file - just copy all the aar files
> > to the repository.
> >
> > Sanjiva.
> >
> > On Sun, Aug 30, 2009 at 1:05 AM, Zooz Bee  > <mailto:zooz...@yahoo.com>> wrote:
> >
> > Thanks Azeez  for response.
> >
> > Since multiple services can be deployed inside the service group. I
> > thought Axis2 should provide a tool to merge different service.xml
> > inside service group.
> >
> > -Zooz
> >
> >
> >
> >
> --------
> > *From:* Afkham Azeez mailto:afk...@gmail.com>>
> > *To:* axis-dev@ws.apache.org <mailto:axis-dev@ws.apache.org>
> > *Sent:* Saturday, August 29, 2009 11:34:24 AM
> > *Subject:* Re: [Axis2]multiple service in same archive
> >
> > wsdl2java only recognizes services. It is not aware about service
> > groups. You could write an ant/maven plugin that combines the
> > generated code or the services XML files
> >
> > Azeez
> >
> > On Sat, Aug 29, 2009 at 8:34 AM, Zooz Bee  > <mailto:zooz...@yahoo.com>> wrote:
> >
> > Hi,
> >
> > I want to deploy multiple services in same archive. I generated
> > the code from first WSDL. It generates the service.xml file.
> > I generated the code for second WSDL. It also generated the
> > service.xml file. Both service.xml are in format
> >
> > First service.xml
> > 
> > 
> >
> > 
> > 
> >
> >
> > secondt service.xml
> > 
> > 
> >
> > 
> > 
> >
> >
> > Like in Axis1.X using deploy.wsdd file can be used to merge
> > different wsdd  files?
> > My querstion is how can i combine these two service.xml files
> > into one. Is there a tool to combine both files in one xml file.
> >
> > Thanks,
> > Zooz
> >
> >
> >
> >
> >
> >
> > --
> > Thanks
> > Afkham Azeez
> >
> > Blog: http://afkham.org
> > Developer Portal: http://www.wso2.org
> > WSAS Blog: http://wso2wsas.blogspot.com
> > Company: http://wso2.com
> > GPG Fingerprint: 643F C2AF EB78 F886 40C9  B2A2 4AE2 C887 665E 0760
> >
> >
> >
> >
> > --
> > 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/
> >
>



-- 
Thanks
Afkham Azeez

Blog: http://afkham.org
Developer Portal: http://www.wso2.org
WSAS Blog: http://wso2wsas.blogspot.com
Company: http://wso2.com
GPG Fingerprint: 643F C2AF EB78 F886 40C9  B2A2 4AE2 C887 665E 0760


Re: [Axis2]multiple service in same archive

2009-08-29 Thread Zooz Bee
Yes, i am going to manually merge it. I was just looking if any one has already 
written script for this. 
-Zooz





From: Glen Daniels 
To: axis-dev@ws.apache.org
Sent: Saturday, August 29, 2009 4:38:53 PM
Subject: Re: [Axis2]multiple service in same archive

One of the main reasons we designed service groups was precisely to allow
people to deploy related web services in a convenient package.  The
services.xml format works fine with this IIRC - can't Zooz just merge the
files manually and put both  elements under a single ?

Providing a script for this would be easy, but perhaps too trivial to be
worth doing.

--Glen

Zooz Bee wrote:
> No particular reason, just wanted to make one .aar file for my web
> application. Its a very small application, in terms of request it will
> receive, serving couple services.
> 
> -zooz
> 
> 
> *From:* Sanjiva Weerawarana 
> *To:* axis-dev@ws.apache.org
> *Sent:* Saturday, August 29, 2009 12:50:43 PM
> *Subject:* Re: [Axis2]multiple service in same archive
> 
> Are you wanting to put them into a single .aar file for a particular
> reason? If its just to deploy multiple services then, unlike in Axis1,
> you don't need to put them into one file - just copy all the aar files
> to the repository.
> 
> Sanjiva.
> 
> On Sun, Aug 30, 2009 at 1:05 AM, Zooz Bee  <mailto:zooz...@yahoo.com>> wrote:
> 
> Thanks Azeez  for response.
> 
> Since multiple services can be deployed inside the service group. I
> thought Axis2 should provide a tool to merge different service.xml
> inside service group.
> 
> -Zooz
> 
> 
> 
> 
> *From:* Afkham Azeez mailto:afk...@gmail.com>>
> *To:* axis-dev@ws.apache.org <mailto:axis-dev@ws.apache.org>
> *Sent:* Saturday, August 29, 2009 11:34:24 AM
> *Subject:* Re: [Axis2]multiple service in same archive
> 
> wsdl2java only recognizes services. It is not aware about service
> groups. You could write an ant/maven plugin that combines the
> generated code or the services XML files
> 
> Azeez
> 
> On Sat, Aug 29, 2009 at 8:34 AM, Zooz Bee  <mailto:zooz...@yahoo.com>> wrote:
> 
> Hi,
> 
> I want to deploy multiple services in same archive. I generated
> the code from first WSDL. It generates the service.xml file.
> I generated the code for second WSDL. It also generated the
> service.xml file. Both service.xml are in format
> 
> First service.xml
> 
> 
>
> 
> 
> 
> 
> secondt service.xml
> 
> 
>
> 
> 
> 
> 
> Like in Axis1.X using deploy.wsdd file can be used to merge
> different wsdd  files?
> My querstion is how can i combine these two service.xml files
> into one. Is there a tool to combine both files in one xml file.
> 
> Thanks,
> Zooz
> 
> 
> 
> 
> 
> 
> -- 
> Thanks
> Afkham Azeez
> 
> Blog: http://afkham.org
> Developer Portal: http://www.wso2.org
> WSAS Blog: http://wso2wsas.blogspot.com
> Company: http://wso2.com
> GPG Fingerprint: 643F C2AF EB78 F886 40C9  B2A2 4AE2 C887 665E 0760
> 
> 
> 
> 
> -- 
> 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/
> 



  

Re: [Axis2]multiple service in same archive

2009-08-29 Thread Glen Daniels
One of the main reasons we designed service groups was precisely to allow
people to deploy related web services in a convenient package.  The
services.xml format works fine with this IIRC - can't Zooz just merge the
files manually and put both  elements under a single ?

Providing a script for this would be easy, but perhaps too trivial to be
worth doing.

--Glen

Zooz Bee wrote:
> No particular reason, just wanted to make one .aar file for my web
> application. Its a very small application, in terms of request it will
> receive, serving couple services.
> 
> -zooz
> 
> 
> *From:* Sanjiva Weerawarana 
> *To:* axis-dev@ws.apache.org
> *Sent:* Saturday, August 29, 2009 12:50:43 PM
> *Subject:* Re: [Axis2]multiple service in same archive
> 
> Are you wanting to put them into a single .aar file for a particular
> reason? If its just to deploy multiple services then, unlike in Axis1,
> you don't need to put them into one file - just copy all the aar files
> to the repository.
> 
> Sanjiva.
> 
> On Sun, Aug 30, 2009 at 1:05 AM, Zooz Bee  <mailto:zooz...@yahoo.com>> wrote:
> 
> Thanks Azeez  for response.
> 
> Since multiple services can be deployed inside the service group. I
> thought Axis2 should provide a tool to merge different service.xml
> inside service group.
> 
> -Zooz
> 
> 
> 
> 
> *From:* Afkham Azeez mailto:afk...@gmail.com>>
> *To:* axis-dev@ws.apache.org <mailto:axis-dev@ws.apache.org>
> *Sent:* Saturday, August 29, 2009 11:34:24 AM
> *Subject:* Re: [Axis2]multiple service in same archive
> 
> wsdl2java only recognizes services. It is not aware about service
> groups. You could write an ant/maven plugin that combines the
> generated code or the services XML files
> 
> Azeez
> 
> On Sat, Aug 29, 2009 at 8:34 AM, Zooz Bee  <mailto:zooz...@yahoo.com>> wrote:
> 
> Hi,
> 
> I want to deploy multiple services in same archive. I generated
> the code from first WSDL. It generates the service.xml file.
> I generated the code for second WSDL. It also generated the
> service.xml file. Both service.xml are in format
> 
> First service.xml
> 
> 
>
> 
> 
> 
> 
> secondt service.xml
> 
> 
>
> 
> 
> 
> 
> Like in Axis1.X using deploy.wsdd file can be used to merge
> different wsdd  files?
> My querstion is how can i combine these two service.xml files
> into one. Is there a tool to combine both files in one xml file.
> 
> Thanks,
> Zooz
> 
> 
> 
> 
> 
> 
> -- 
> Thanks
> Afkham Azeez
> 
> Blog: http://afkham.org
> Developer Portal: http://www.wso2.org
> WSAS Blog: http://wso2wsas.blogspot.com
> Company: http://wso2.com
> GPG Fingerprint: 643F C2AF EB78 F886 40C9  B2A2 4AE2 C887 665E 0760
> 
> 
> 
> 
> -- 
> 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/
> 


Re: [Axis2]multiple service in same archive

2009-08-29 Thread Zooz Bee
No particular reason, just wanted to make one .aar file for my web application. 
Its a very small application, in terms of request it will receive, serving 
couple services. 

-zooz





From: Sanjiva Weerawarana 
To: axis-dev@ws.apache.org
Sent: Saturday, August 29, 2009 12:50:43 PM
Subject: Re: [Axis2]multiple service in same archive

Are you wanting to put them into a single .aar file for a particular reason? If 
its just to deploy multiple services then, unlike in Axis1, you don't need to 
put them into one file - just copy all the aar files to the repository.

Sanjiva.


On Sun, Aug 30, 2009 at 1:05 AM, Zooz Bee  wrote:

Thanks Azeez  for response. 
>
>Since multiple services can be deployed inside the service group. I thought 
>Axis2 should provide a tool to merge different service.xml inside service 
>group. 
>
>-Zooz
>
>
>
>
>
>

 From: Afkham Azeez 
>To: axis-dev@ws.apache.org
>Sent: Saturday, August 29, 2009 11:34:24 AM
>Subject: Re: [Axis2]multiple service in same
> archive
>
>
>wsdl2java only recognizes services. It is not aware about service groups. You 
>could write an ant/maven plugin that combines the generated code or the 
>services XML files
>
>
>Azeez
>
>
>>On Sat, Aug 29, 2009 at 8:34 AM, Zooz Bee  wrote:
>
>Hi, 
>>
>>I want to deploy multiple services in same archive. I generated the code from 
>>first WSDL. It generates the service.xml file. 
>>>>
>>I generated the code for second WSDL. It also generated the service.xml file. 
>>Both service.xml are in format 
>>
>>First service.xml
>>
>>
>>
>>
>>>>
>>
>>
>>
>>secondt service.xml
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>Like in Axis1.X using deploy.wsdd file can be used to merge different wsdd  
>>files? 
>>My querstion is how can i combine these two service.xml files into one. Is 
>>there a tool to combine both files in one xml file. 
>>
>>Thanks,
>>Zooz
>>
>>
>>
>>
>
>
>-- 
>Thanks
>Afkham Azeez
>
>Blog: http://afkham.org
>Developer Portal: http://www.wso2.org
>>
>WSAS Blog: http://wso2wsas.blogspot.com
>Company: http://wso2.com
>GPG Fingerprint: 643F C2AF EB78 F886 40C9  B2A2 4AE2 C887 665E 0760
>
>


-- 
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/



  

Re: [Axis2]multiple service in same archive

2009-08-29 Thread Sanjiva Weerawarana
Are you wanting to put them into a single .aar file for a particular reason?
If its just to deploy multiple services then, unlike in Axis1, you don't
need to put them into one file - just copy all the aar files to the
repository.

Sanjiva.

On Sun, Aug 30, 2009 at 1:05 AM, Zooz Bee  wrote:

> Thanks Azeez  for response.
>
> Since multiple services can be deployed inside the service group. I thought
> Axis2 should provide a tool to merge different service.xml inside service
> group.
>
> -Zooz
>
>
>
> --
> *From:* Afkham Azeez 
> *To:* axis-dev@ws.apache.org
> *Sent:* Saturday, August 29, 2009 11:34:24 AM
> *Subject:* Re: [Axis2]multiple service in same archive
>
> wsdl2java only recognizes services. It is not aware about service groups.
> You could write an ant/maven plugin that combines the generated code or the
> services XML files
> Azeez
>
> On Sat, Aug 29, 2009 at 8:34 AM, Zooz Bee  wrote:
>
>> Hi,
>>
>> I want to deploy multiple services in same archive. I generated the code
>> from first WSDL. It generates the service.xml file.
>> I generated the code for second WSDL. It also generated the service.xml
>> file. Both service.xml are in format
>>
>> First service.xml
>> 
>> 
>>
>> 
>> 
>>
>>
>> secondt service.xml
>> 
>> 
>>
>> 
>> 
>>
>>
>> Like in Axis1.X using deploy.wsdd file can be used to merge different
>> wsdd  files?
>> My querstion is how can i combine these two service.xml files into one. Is
>> there a tool to combine both files in one xml file.
>>
>> Thanks,
>> Zooz
>>
>>
>>
>>
>
>
> --
> Thanks
> Afkham Azeez
>
> Blog: http://afkham.org
> Developer Portal: http://www.wso2.org
> WSAS Blog: http://wso2wsas.blogspot.com
> Company: http://wso2.com
> GPG Fingerprint: 643F C2AF EB78 F886 40C9  B2A2 4AE2 C887 665E 0760
>
>


-- 
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/


Re: [Axis2]multiple service in same archive

2009-08-29 Thread Zooz Bee
Thanks Azeez  for response. 

Since multiple services can be deployed inside the service group. I thought 
Axis2 should provide a tool to merge different service.xml inside service 
group. 

-Zooz







From: Afkham Azeez 
To: axis-dev@ws.apache.org
Sent: Saturday, August 29, 2009 11:34:24 AM
Subject: Re: [Axis2]multiple service in same archive

wsdl2java only recognizes services. It is not aware about service groups. You 
could write an ant/maven plugin that combines the generated code or the 
services XML files

Azeez


On Sat, Aug 29, 2009 at 8:34 AM, Zooz Bee  wrote:

Hi, 
>
>I want to deploy multiple services in same archive. I generated the code from 
>first WSDL. It generates the service.xml file. 
>>I generated the code for second WSDL. It also generated the service.xml file. 
>>Both service.xml are in format 
>
>First service.xml
>
>
>
>
>>
>
>
>secondt service.xml
>>
>>
>>
>>
>>
>
>
>Like in Axis1.X using deploy.wsdd file can be used to merge different wsdd  
>files? 
>My querstion is how can i combine these two service.xml files into one. Is 
>there a tool to combine both files in one xml file. 
>
>Thanks,
>Zooz
>
>
>
>


-- 
Thanks
Afkham Azeez

Blog: http://afkham.org
Developer Portal: http://www.wso2.org
WSAS Blog: http://wso2wsas.blogspot.com
Company: http://wso2.com
GPG Fingerprint: 643F C2AF EB78 F886 40C9  B2A2 4AE2 C887 665E 0760



  

Re: [Axis2]multiple service in same archive

2009-08-29 Thread Afkham Azeez
wsdl2java only recognizes services. It is not aware about service groups.
You could write an ant/maven plugin that combines the generated code or the
services XML files
Azeez

On Sat, Aug 29, 2009 at 8:34 AM, Zooz Bee  wrote:

> Hi,
>
> I want to deploy multiple services in same archive. I generated the code
> from first WSDL. It generates the service.xml file.
> I generated the code for second WSDL. It also generated the service.xml
> file. Both service.xml are in format
>
> First service.xml
> 
> 
>
> 
> 
>
>
> secondt service.xml
> 
> 
>
> 
> 
>
>
> Like in Axis1.X using deploy.wsdd file can be used to merge different wsdd
> files?
> My querstion is how can i combine these two service.xml files into one. Is
> there a tool to combine both files in one xml file.
>
> Thanks,
> Zooz
>
>
>
>


-- 
Thanks
Afkham Azeez

Blog: http://afkham.org
Developer Portal: http://www.wso2.org
WSAS Blog: http://wso2wsas.blogspot.com
Company: http://wso2.com
GPG Fingerprint: 643F C2AF EB78 F886 40C9  B2A2 4AE2 C887 665E 0760


Re: [Axis2] happy birthday !!!

2009-08-23 Thread Senaka Fernando
Congrats!

Thanks,
Senaka.

On Fri, Aug 21, 2009 at 5:11 PM, Davanum Srinivas  wrote:

> Deepal,
>
> Congrats!
>
> -- dims
>
> On Fri, Aug 21, 2009 at 12:19 AM, Deepal jayasinghe
> wrote:
> > It is the fifth birthday of the project..
> >
> > -- Deepal --
> >
> > Some history of the project...
> > http://blogs.deepal.org/2009/08/happy-birthday-axis2.html
> >
> > --
> > Thank you!
> >
> >
> > http://blogs.deepal.org
> > http://deepal.org
> >
> >
>
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>


Re: [Axis2] happy birthday !!!

2009-08-23 Thread Senaka Fernando
Congrats!

Thanks,
Senaka.

On Fri, Aug 21, 2009 at 5:11 PM, Davanum Srinivas  wrote:

> Deepal,
>
> Congrats!
>
> -- dims
>
> On Fri, Aug 21, 2009 at 12:19 AM, Deepal jayasinghe
> wrote:
> > It is the fifth birthday of the project..
> >
> > -- Deepal --
> >
> > Some history of the project...
> > http://blogs.deepal.org/2009/08/happy-birthday-axis2.html
> >
> > --
> > Thank you!
> >
> >
> > http://blogs.deepal.org
> > http://deepal.org
> >
> >
>
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>


  1   2   3   4   5   6   7   8   9   10   >