from:"Amila Suriarachchi"

  name
  unique)
  
   Therefore, I've improved our deployment engine to deploy services
 by
   looking at the hierarchical path of the service. For example this
   allows us to deploy a service
  repository/services/foo/bar/version.aar.
   And also this allows us to deploy any number of services as
 follows.
   repository/services/versionService/1.0.0/version.aar
   repository/services/versionService/1.0.1/version.aar
  Don't you think this is complex ? what is different between
  services/versionService/1.0.1/version.aar and
  services/version-1.0.1.aar ?. As far as I know second one is
 better
  than the first one (and you do not need much modification to handle
  that). Which is the commonly used approach for all sort of version
  management. (am I missing something?)
  
   In the implementation, I've attached the hierarchical part of the
   service (versionService/1.0.1/) in front of the service name
  which is
   read from the services.xml. And also I've fixed the URI based
   dispatching logics to dispatch the services correctly.
  Then how about addressing based dispatching ?
  I remember the mess we had when someone introduce portName into
  the URL,
  I think we still have issues with that (though no one uses the
  feature).
  
   This improvement doesn't affect any of the existing
 functionalities.
  Of course it does? how do you make sure when you change the
 dispatcher
  it does not break any of the existing features ? (we do not have
  enough
  test cases to cover all the cases) I think I have enough experience
 in
  Axis2, what when someone change something hoping that does not break
  something.
   The only limitation of this is we can't deploy a RESTful service
 in
   this manner.
  This is a problem right?
  When the system move from one version to other, client will notice
  that
  the service does not work any more?
   Those can only be supported at repository/service level. That is
   because, incoming URL of a RESTful service can contain '/'
 separated
   parameters to the service.
  oh boy, you are making system tooo, complicated.
 
  I am sorry I am -1 on this approach,  we need to discuss this
  before we
  implement.
  In fact I remember we had some discussion on this at one of the
  apachecon, there also we did not come to a conclusion.
 
  Thanks,
  Deepal
 
 
 
 
  --
  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
 
 
  --
  Thank you!
 
 
  http://blogs.deepal.org
  http://deepal.org
 
 




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

Re: Supporting hierarchical service deployment

On Fri, Aug 28, 2009 at 7:04 PM, Deepal jayasinghe deep...@gmail.comwrote:

 Hi Isuru,

 Thank you for taking your time and looking to this issues, but I do not
 agree the way you have address it, please see my comments below. The
 reason I am telling this is, as I can see this has so many issues, and
 you have made it complicated too :) . I believe you might know that we
 have version support for modules and we do not handle that like this. So
 this simply break the consistency, and this introduce new URL patterns ,
 though you have not encounter now, I am sure you are going to face a
 number of issues (when it come to dispatching).

  Currently Axis2 can only deploy services at the repository/services
  level. This makes it impossible to deploy several versions of the same
  service.
 I do not agree, you can have the version name in the aar file, for
 example foo-1.0.aar and foo-1.1.aar. Then at the deployment time just
 append the version number to the service name (to make the service name
 unique)


This may be a possible way of doing versioning. But IMHO not the best way.
Please have a look at here[1]. If we follow what you have mentioned here
then we need to add
all files of axis2 versions into one folder and rename them as pom-1.5.xml,
pom-1.4.xml etc. No need to say this is a mess.
Consider a situation where you have 10 services and 5 versions. you can ask
the question why
can't you keep all in one folder. But the practical way is to have them in
separate folders with the version numbers.

So if we have the hierarchical deployment we can have directory based
versioning.

thanks,
Amila.

[1]https://svn.apache.org/repos/asf/webservices/axis2/branches/java/


 
  Therefore, I've improved our deployment engine to deploy services by
  looking at the hierarchical path of the service. For example this
  allows us to deploy a service repository/services/foo/bar/version.aar.
  And also this allows us to deploy any number of services as follows.
  repository/services/versionService/1.0.0/version.aar
  repository/services/versionService/1.0.1/version.aar
 Don't you think this is complex ? what is different between
 services/versionService/1.0.1/version.aar and
 services/version-1.0.1.aar ?. As far as I know second one is better
 than the first one (and you do not need much modification to handle
 that). Which is the commonly used approach for all sort of version
 management. (am I missing something?)
 
  In the implementation, I've attached the hierarchical part of the
  service (versionService/1.0.1/) in front of the service name which is
  read from the services.xml. And also I've fixed the URI based
  dispatching logics to dispatch the services correctly.
 Then how about addressing based dispatching ?
 I remember the mess we had when someone introduce portName into the URL,
 I think we still have issues with that (though no one uses the feature).
 
  This improvement doesn't affect any of the existing functionalities.
 Of course it does? how do you make sure when you change the dispatcher
 it does not break any of the existing features ? (we do not have enough
 test cases to cover all the cases) I think I have enough experience in
 Axis2, what when someone change something hoping that does not break
 something.
  The only limitation of this is we can't deploy a RESTful service in
  this manner.
 This is a problem right?
 When the system move from one version to other, client will notice that
 the service does not work any more?
  Those can only be supported at repository/service level. That is
  because, incoming URL of a RESTful service can contain '/' separated
  parameters to the service.
 oh boy, you are making system tooo, complicated.

 I am sorry I am -1 on this approach,  we need to discuss this before we
 implement.
 In fact I remember we had some discussion on this at one of the
 apachecon, there also we did not come to a conclusion.

 Thanks,
 Deepal




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

Re: Please revert API changes done as per AXIS2-4465

On Sat, Aug 29, 2009 at 4:24 PM, Andreas Veithen
andreas.veit...@gmail.comwrote:

 I would like to inform all of you that I decided to significantly
 reduce my activity in the Axis2 project. Over the last months I have
 worked primarily on JIRA issues and on improving the test suites of
 SAAJ and ADB [1]. This work has put me in the line of fire of people
 who are not willing or not able to let a discussion occur in a
 constructive way. Considering that I dedicate some of my free time to
 do this and that my professional life is already stressful enough, I
 can live very well without this. Doing the dirty job of fixing bugs is
 simply not worth it under these conditions.

 The fact is that in AXIS2-4465, I have implemented a fix that
 inadvertently removed a public method and causing a subtle issue in a
 dependent project. I have been immediately accused of drastic and
 deliberate changes to public APIs and these accusations went as far as
 talking about merrily chang[ing] APIs and things are going to
 become a big mess. In addition these accusations have been put
 forward while being vague on the exact issue that the fix caused (the
 complete information about this was only disclosed in the 35th post in
 this thread). This caused the discussion to quickly degrade instead of
 remaining focused on the facts and drawing the conclusions after
 analyzing those facts. Furthermore, in another thread, my fix in
 AXIS2-4465 has been implicitly put on a level with a proposed
 modification that would change the deployment subsystem, dispatchers
 and transports. I think that all this goes way beyond legitimate
 criticism and also way beyond what one would expect in a constructive
 discussion.


First of all I should thank you for your good work in Axis2 specially for
ADB. I think it is a coinside that all three people worked with ADB codegen
has the name starting with A (Ajith, Amila, Andreas) :)

I feel sorry for the first reason you have mentioned. But I think this is
not the first time of that. If you see the
Deepals comments on what Isuru has done I can't see any positiveness. I am
not saying it is correct but I would like to ask you not to take them
personal. I think at least you got an agreeable solution at the end. Anyway
disscussing things in dev list always is a good idea.

The second reason you have mention I think is a complete misunderstanding.
There is no connection between those two.

I my point of view there is no point in contributing an open source project
in a stress. But try to do for the fun :).

Hope you use your free time and contribute to axis2 as you were, in furture
as well.


thanks,
Amila.




 Note that I am not resigning from the Axis2 project; I will just shift
 priorities.

 Andreas

 [1]
 http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fwebservices%2Faxis2%2Ftrunk%2Fjavaauthor=veithen




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

Re: Please revert API changes done as per AXIS2-4465

On Sat, Aug 29, 2009 at 7:30 PM, Deepal Jayasinghe deep...@gmail.comwrote:

  think my suggestion would do this.
 
  This discussion should involve Axis2-dev, carbon-dev, synapse-dev. So
 please
  start a discussion by engaging all these communities in a different
 thread
  with the correct heading.
 

 Amila, I did not see this in the first place could you please tell me
 why we need to engage people from carbon-dev. What is the point of
 trying to get outside apache mailing lists into Apache discussion.

Good point. Lets only discuss in Axis2-dev.

thanks,
Amila.



 Thanks,
 Deepal




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

Re: Please revert API changes done as per AXIS2-4465

On Sat, Aug 29, 2009 at 8:35 PM, Deepal jayasinghe deep...@gmail.comwrote:


 
 
  On Sat, Aug 29, 2009 at 7:49 PM, Deepal jayasinghe deep...@gmail.com
  mailto:deep...@gmail.com wrote:
 
  If you feel so I am so sorry, it was not intensional, I really like
  Axis2 not because I have contributed to it but because it is a useful
  project. When I see someone try to break something in the project
  it is
  hard for me to keep silent.
 
 
  But 40 minutes prior to that in reply to Andreas' mail you wrote:
 
  =
  It is so sad to hear this, I know you contributed a lot and helped to
  move the project forward. When we implement a feature we can not
  consider all the projects using it. Just think one more time, we really
  need your help ., I really value your contribution.
  =
 I am sorry . I think my bad English made you misunderstand what I meant .

 As I mentioned Axis2 is a very useful project and we can not make the
 changes as we wish (since the project is matured).  If I had  a chance
 to go though Andreas's  patch I would have argued the same way as I did
 with Isuru.

Andreas,
If Deepal saw your patch, I am sure it is not get commited anyway :).



 Having said that  when I implement a feature we can not consider all the
 projects using it (For example I do not know what kind of features of
 Axis2 that Tuscany uses), however if I know I am going to break some of
 the existing stuff in Axis2 I will not do that or will not let others to
 do it (like in Isuru's case). But if I got to know that I have break
 something on other dependent project (though JIRA or emails) , then I
 would consider fixing the issue to solve their problem too.
 
  So its ok for one person to break things (Andreas, which is what
  started this thread)
 I hope you can understand it is hard for me to find time to go though
 Axis2 mails, when Andreas's patch mailing thread taking place I was so
 busy with my assignments so did not have  time. Unfortunately I had a
 chance to go though Isuru's mail yesterday, that wasted my whole day for
 nothing.
  but not the other (Isuru, on the hierarchical service stuff)? Why the
  double standard?
 
 It is not double stand, I already mentioned the rational behind that. It
 about time...,Otherwise I do not care who the person is if he trying to
 break anything, I have done that to Dims, Glen, Amila and few others (of
 course when I had time).

Andreas,

Now you can understand what I tried to say. Please try to go through the
this
deployment thread and take your own judgement of warring about Axis2
breaking and stopping
some one doing a new thing.
Hope you realise there is no reason you to resign from Axis2 because of the
discussion
you have mentioned :).

thanks,
Amila.




 I think this will be the last time I am going to say NO to any new
 feature adding or existing stuff breaking, I will simply do not care it
 anymore (I do not have time to waste). But will still to reply to mails
 in axis-user list.

 Thanks,
 Deepal
  (I haven't read thru the hierarchical service thread yet; I will and I
  will reply to it - my belief is that it doesn't need to break anything
  that works now but maybe the way its been done is not that way. Anyway
  I will read thru that thread and reply later.
 
  Sanjiva.
  --
  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/


 --
 Thank you!


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




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

Re: [PROPOSAL] Axis2 Deployer behaviour on hot update

2009-08-27 Thread Amila Suriarachchi

On Thu, Aug 27, 2009 at 10:06 AM, Ruwan Linton ruwan.lin...@gmail.comwrote:

 Hi devs,

 I am trying to implement the Hot deployment and Hot update of the synapse
 artifacts, and realized that there are some issues; I first thought of
 writing our own deployment behaviour because we wanted some conditions to be
 checked on the hot update case undeployment of the artifacts.

 Let me first describe how Hot update works in axis2, correct me if I am
 wrong but from what I have figured out so far, axis2 repository listener
 task calls unDeploy method of the deployer implementation first and then
 calls the deploy method again to deploy the artifact with the changes.

 So this approach has two issues,

1. There is a considerable downtime of the artifact which is being hot
updated
2. There is no means of knowing the case where the undeploy method
being called, for example synapse needs to have a main sequence for it to
operate properly, so synapse has to force the user to not to undeploy the
main sequence while it should allow the user to hot update it.

 I propose adding a update method to the Deployer interface or passing the
 state as an argument, we could use the DeploymentFileData class to provide
 the operation, but that doesn't resolve the issue because the undeploy
 method has a String file name as its argument, so this canot be fixed
 without an API change in the deployer implementation.

 Being said the above I can implement this in Synapse, but since we had huge
 debates earlier on writing stuff on synapse replacing axis2 stuff just
 because they do not fit into synapse without letting the axis2 community
 know about those, I thought of proposing this to the axis2 as well.

 WDYT?

 Or may be I am missign something which can resolve the above 2 issues, in
 which case please be kind enough to point me to the behaviour that I should
 be using.. :-)


I went through the deployment engine code and it seems bit complicated and
can not solve without changing Deployer interface.

Let me put this suggestion if it works for you :).

At the undeploy method you get the file name. Then you can check whether
this file exists.
if not exist this is only an undeployment so you do the undeployment
if exists then this is a update, you keep this entry in your deployer. Now
at the deploy method if there is an entry you do an update and if not do a
fresh deployments.

Anyway I think, writing a synapse deployer would be a correct long term
solution since you can customise it purely for synapse needs.

thanks,
Amila.



 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: Unable to get Header tags in custom module's inflow handler

2009-08-26 Thread Amila Suriarachchi

On Wed, Aug 19, 2009 at 9:44 PM, Senthil Sona sws...@cisco.com wrote:

Hi Rampart team,

In a client class we have our custom module and rampart engaged. While
sending the request, we are setting some header tags in outflow handler of
custom module. while request going out, first custom module's outflow
handler is executing then rampart module's outflow handler is executing.
When request goes til webservice, (webservice is also having rampart and
custom module engage), then webservice custom module's inflow handler is
executing. We have a code to extract custom header tags in inflow handler.
But the custom header tags we have set in outflow handler is not coming
till
inflow handler. And in inflow handler the envelope is in encrypt form.
Could
you please tell me how to get these header values in inflow handler.

If you look at the axis2.xml phases you can see the Out flow handler order
is the reverse of inflow handler order.
so when you add handlers you need to think like that. If custom out handler
is before security phase in out flow then
custom in handler should be after security phase in inflow.

thanks,
Amila.

Please reply as soon as possible. This is very urgent.

Thanks,
Swapna Soni.
--
View this message in context:
http://www.nabble.com/Unable-to-get-Header-tags-in-custom-module%27s-inflow-handler-tp25047272p25047272.html
Sent from the Axis - Dev mailing list archive at Nabble.com.

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

Re: Please revert API changes done as per AXIS2-4465

2009-08-25 Thread Amila Suriarachchi

On Tue, Aug 25, 2009 at 5:45 PM, Davanum Srinivas dava...@gmail.com wrote:

 Amila,

 you said:

 You have not put any comment in my suggestion to  resolve the issue
 keeping
 your change and with out breaking carbon. We will test it and commit if you
 don't have any suggestions to fix this issue.

 Do you have proposed patch on how to fix this break?


yes. Please see my first mail on Monday.
This does not change any functionality but do it in a slightly different
way.

here is the commit[1].

thanks,
Amila.

[1] http://svn.apache.org/viewvc?view=revrevision=807512



 thanks,
 dims


 On 08/25/2009 01:02 AM, Amila Suriarachchi wrote:

 You have not put any comment in my suggestion to  resolve the issue
 keeping
 your change and with out breaking carbon. We will test it and commit if
 you
 don't have any suggestions to fix this issue.




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

Re: Please revert API changes done as per AXIS2-4465

hi,

I had time to go through your comment and I think what you suggest is the
correct way to address the problem.
So +1 for that.

Then I looked into the our code and found that we have also done the same
technique with separate two
Transport listeners :).

Because we have our own two transport listeners this code gives us problems,

// This method should not be part of the public API. In particular we must
not allow subclasses
// to override this method because we don't make any guarantees as to
when exactly this method
// is called.
private void preprocessRequest(HttpServletRequest req) throws
ServletException {
initContextRoot(req);

AxisServletListener listener = req.isSecure() ? httpsListener :
httpListener;
if (listener == null) {
throw new ServletException(req.getScheme() +  is forbidden);
} else {
// Autodetect the port number if necessary
if (listener.getPort() == -1) {
listener.setPort(req.getServerPort());
}
}
}

Here you assume anyone use Axis2 as a library has used AxisServletListner
and kept it as a private variable in Axis2Servlet.

Instead of I would like to implement this method like this,


// This method should not be part of the public API. In particular we must
not allow subclasses
// to override this method because we don't make any guarantees as to
when exactly this method
// is called.
private void preprocessRequest(HttpServletRequest req) throws
ServletException {
initContextRoot(req);

TransportInDescription transportInDescription =
req.isSecure() ?
this.axisConfiguration.getTransportIn(Constants.TRANSPORT_HTTPS) :

this.axisConfiguration.getTransportIn(Constants.TRANSPORT_HTTP);
if (transportInDescription == null) {
throw new ServletException(req.getScheme() +  is forbidden);
} else {
if (transportInDescription.getReceiver() instanceof
AxisServletListener) {
AxisServletListener listener = (AxisServletListener)
transportInDescription.getReceiver();
if (listener.getPort() == -1) {
listener.setPort(req.getServerPort());
}
}
}
}

In this way we do not keep the Axis2Specific listener and take it from the
axis configuration and check for port only if it is an Axis2Servlet
listener.

WDYT?

thanks,
Amila.



On Sat, Aug 22, 2009 at 12:45 PM, Srinath Perera hemap...@gmail.com wrote:

  I am not sure whether clearly understand the difference between how
  AxisServelet works and how SimpleHTTPServer works. In the case of
  AxisServlet, we first start AxisServlet and then we start Axis2, so when
  we start Axis2 we already have HTTP listener running (and hence
  TransportInDec). So once the system start we just create a
  TransportInDec using servlet and set that as the HTTP TransportDec (and
  of course we replace what is in axis2.xml for HTTP with this
  transportInDec, and we must do that). Whereas in SimpleHTTPServer, we
  first start Axis2 and then we use transport in axis2.xml to configure
  the system, so we use the tarnporInDec to configure the SimpleHTTPServer.

 Yep, this is right. One reason it is there is that to allow both
 simple HTTP server and servlet share the same axis2.xml which is not
 required, rather a convenience. In a servlet case transport receiver
 is not initialized at all (I do not think it has changed).

 Thanks
 Srinath

 --
 
 Srinath Perera, Ph.D.
   WSO2 Inc. http://wso2.com
   Blog: http://srinathsview.blogspot.com/




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

Re: Please revert API changes done as per AXIS2-4465

 if it is an Axis2Servlet
  listener.
 
  WDYT?
 
  thanks,
  Amila.
 
 
 
  On Sat, Aug 22, 2009 at 12:45 PM, Srinath Perera hemap...@gmail.com
 wrote:
 
   I am not sure whether clearly understand the difference between how
   AxisServelet works and how SimpleHTTPServer works. In the case of
   AxisServlet, we first start AxisServlet and then we start Axis2, so
 when
   we start Axis2 we already have HTTP listener running (and hence
   TransportInDec). So once the system start we just create a
   TransportInDec using servlet and set that as the HTTP TransportDec
 (and
   of course we replace what is in axis2.xml for HTTP with this
   transportInDec, and we must do that). Whereas in SimpleHTTPServer, we
   first start Axis2 and then we use transport in axis2.xml to configure
   the system, so we use the tarnporInDec to configure the
   SimpleHTTPServer.
 
  Yep, this is right. One reason it is there is that to allow both
  simple HTTP server and servlet share the same axis2.xml which is not
  required, rather a convenience. In a servlet case transport receiver
  is not initialized at all (I do not think it has changed).
 
  Thanks
  Srinath
 
  --
  
  Srinath Perera, Ph.D.
WSO2 Inc. http://wso2.com
Blog: http://srinathsview.blogspot.com/
 
 
 
  --
  Amila Suriarachchi
  WSO2 Inc.
  blog: http://amilachinthaka.blogspot.com/
 




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

Adding the Apache tomcat tribes and juli jars to axis2 distributions

hi,

Currently Apache tomcat tribes and juli jars are excluded from the axis2
distributions
see (modules/distribution/src/main/assembly/bin-assembly.xml). These jars
are required to run the
axis2 clustering. Is there any reason not to exclude them I'll add them.

thanks,
Amila.

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

Re: Please revert API changes done as per AXIS2-4465

 start Axis2 we already have HTTP listener running (and hence
TransportInDec). So once the system start we just create a
TransportInDec using servlet and set that as the HTTP TransportDec
(and
of course we replace what is in axis2.xml for HTTP with this
transportInDec, and we must do that). Whereas in SimpleHTTPServer,
 we
first start Axis2 and then we use transport in axis2.xml to
 configure
the system, so we use the tarnporInDec to configure the
SimpleHTTPServer.
  
   Yep, this is right. One reason it is there is that to allow both
   simple HTTP server and servlet share the same axis2.xml which is not
   required, rather a convenience. In a servlet case transport receiver
   is not initialized at all (I do not think it has changed).
  
   Thanks
   Srinath
  
   --
   
   Srinath Perera, Ph.D.
 WSO2 Inc. http://wso2.com
 Blog: http://srinathsview.blogspot.com/
  
  
  
   --
   Amila Suriarachchi
   WSO2 Inc.
   blog: http://amilachinthaka.blogspot.com/
  
 
 
 
  --
  Amila Suriarachchi
  WSO2 Inc.
  blog: http://amilachinthaka.blogspot.com/
 




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

ADB test failure

.databinding.utils.ConverterUtilTest)

Tests run: 60, Failures: 8, Errors: 52, Skipped: 0

[INFO]

[ERROR] BUILD FAILURE
[INFO]

[INFO] There are test failures.

Has anyone got it working?

thanks,
Amila.

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

Re: Please revert API changes done as per AXIS2-4465

, you may have
   to live with it for a long time.
  
   Azeez
  
   On Thu, Aug 20, 2009 at 11:38 AM, Davanum Srinivasdava...@gmail.com
 
   wrote:
   Azeez,
  
   We are still following, commit-then-review right?
  
   thanks,
   dims
  
   On 08/20/2009 07:33 AM, Afkham Azeez wrote:
  
   Hi Andreas,
   The changes you've done to the APIs as per
   https://issues.apache.org/jira/browse/AXIS2-4465 badly breaks some
 of
   the projects that depend on Axis2. Please revert this, and please
   engage the community before making such drastic changes in the
   future.
  
  
  
  
  
   --
   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
  
 
 
 
  --
  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
 
 




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

Re: ADB test failure

I get rid of the first exception after building Axiom. But now getting this
exception

---
 T E S T S
---
Running org.apache.axis2.databinding.ADBSOAPModelBuilderTest
Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 0.11 sec 
FAILURE!
Running org.apache.axis2.databinding.utils.reader.ADBXMLStreamReaderTest
Tests run: 15, Failures: 0, Errors: 15, Skipped: 0, Time elapsed: 0.074 sec
 FAILURE!
Running org.apache.axis2.databinding.utils.MultirefHelperTest
Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 0.02 sec 
FAILURE!
Running org.apache.axis2.databinding.utils.SimpleArrayReaderStateMachineTest
Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 0.022 sec
 FAILURE!
Running org.apache.axis2.databinding.types.xsd.ArrayTest
OMElement == ns1:Array xmlns:ns1=
http://schemas.xmlsoap.org/soap/encoding/; xmlns:s1=
http://www.w3.org/2001/XMLSchema;
   ns1:arrayType=s1:ur-type[5]
s1:int1/s1:int
s1:int2/s1:int
s1:int3/s1:int
s1:int4/s1:int
s1:int5/s1:int
/ns1:Array
Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 0.024 sec
 FAILURE!
Running org.apache.axis2.databinding.utils.NamedStaxOMBuilderTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.006 sec
 FAILURE!
Running
org.apache.axis2.databinding.utils.SimpleElementReaderStateMachineTest
Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.008 sec
 FAILURE!
Running org.apache.axis2.databinding.utils.writer.MTOMAwareOMBuilderTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.007 sec
 FAILURE!



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
---
Test set: org.apache.axis2.databinding.ADBSOAPModelBuilderTest
---
Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 0.111 sec  
FAILURE!
testSimpleArrayList(org.apache.axis2.databinding.ADBSOAPModelBuilderTest)  Time 
elapsed: 0.036 sec   ERROR!
java.lang.ExceptionInInitializerError
at 
org.apache.axis2.databinding.ADBSOAPModelBuilderTest.testSimpleArrayList(ADBSOAPModelBuilderTest.java:79)
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)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
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)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338)
at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997)
Caused by: org.apache.commons.logging.LogConfigurationException: User-specified 
log class 'org.apache.commons.logging.impl.Log4JLogger' cannot be found or is 
not useable.
at 
org.apache.commons.logging.impl.LogFactoryImpl.discoverLogImplementation(LogFactoryImpl.java:874)
at 
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:604)
at 
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:336)
at 
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:310)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685)
at 
org.apache.axiom.om.impl.builder.StAXBuilder.clinit(StAXBuilder.java:58)
... 24 more

testPrintEvents(org.apache.axis2

Re: Please revert API changes done as per AXIS2-4465

On Fri, Aug 21, 2009 at 12:58 AM, Andreas Veithen andreas.veit...@gmail.com
 wrote:

 If the user registered a transport receiver for http or https that is
 not of type AxisServletListener, then this would obviously mean that
 he doesn't want to use the servlet based transport for these
 protocols, but some other implementation. So the question in principle
 doesn't apply. However, in Axis2 1.5 it is necessary to register the
 SimpleHTTPServer as http transport even when AxisServlet is used,
 because otherwise the generated WSDLs don't contain any endpoints. For
 compatibility this is still supported and AxisServlet will replace the
 transport receiver by AxisServletListener (and print a warning).


Can someone like Deepal (or any one who is with the Axis2 from day 0 )
explain why servlet transport is written in this way? I mean adding a
transport receiver for SimpleHttpTransport in axis2.xml and use servlet?

thanks,
Amila.



 Andreas

 On Thu, Aug 20, 2009 at 14:44, Hiranya Jayathilakahiranya...@gmail.com
 wrote:
  Hi Andreas,
 
  By looking at the code I got the impression that HTTP transport receivers
  should extend the AxisServletListener class for your logic of port auto
  detection to work. Is that correct? What happens if the transport
 receivers
  used do not extend this class? All request handler methods call the
  preprocessRequest method which in turns run port auto detection. If the
  transport receivers do not extend AxisServlerListener how is that
 handled?
 
  Thanks,
  Hiranya
 
 
  On Thu, Aug 20, 2009 at 6:05 PM, Andreas Veithen 
 andreas.veit...@gmail.com
  wrote:
 
  Afkham,
 
  The only change I see in the public APIs is the disappearance of the
  initContextRoot method. We can easily fix this be restoring the
  original initContextRoot method and let the preprocessRequest method
  call initContextRoot. Do you see any other things to change?
 
  Andreas
 
  On Thu, Aug 20, 2009 at 13:45, Afkham Azeezafk...@gmail.com wrote:
   Yes Dims. However, if everybody continues to merrily change APIs,
   making public methods private  so on, things are going to become a
   big mess. Axis2 provides public APIs, and those may be having
   problems, but still they are public APIs. This is why you have to be
   very careful when defining APIs; if you get them wrong, you may have
   to live with it for a long time.
  
   Azeez
  
   On Thu, Aug 20, 2009 at 11:38 AM, Davanum Srinivasdava...@gmail.com
   wrote:
   Azeez,
  
   We are still following, commit-then-review right?
  
   thanks,
   dims
  
   On 08/20/2009 07:33 AM, Afkham Azeez wrote:
  
   Hi Andreas,
   The changes you've done to the APIs as per
   https://issues.apache.org/jira/browse/AXIS2-4465 badly breaks some
 of
   the projects that depend on Axis2. Please revert this, and please
   engage the community before making such drastic changes in the
 future.
  
  
  
  
  
   --
   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
  
 
 
 
  --
  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
 




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

Re: ADB test failure

I could run all the tests sucessfully by adding log4j dependency to parent
pom.xml.

I am wondering why it is not the case otherwise.

thanks,
Amila.




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

Re: ADB test failure