Re: [Axis2] Implementing Stomp transport for Axis2
+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 andreas.veit...@gmail.comwrote: 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 duni...@gmail.com 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(External data packet from the other format) 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
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 duni...@gmail.com 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: [VOTE] Web Services Reorg Part 1 : Axis2 TLP
+1. Glen I think we should also give a summary of the discussion of how the rest of the re-org was considered. Sanjiva. On Fri, Nov 6, 2009 at 10:50 PM, Glen Daniels g...@thoughtcraft.com wrote: Greetings, everyone. A bunch of us here at ApacheCon were talking about the Axis2 TLP idea, and how to move this forward in the simplest and most effective way. We came up with *exactly* the same structure that we had proposed a year ago. :) So, having only altered the page in order to remove a step (the promotion of WS-Commons sub-sub-projects to WS subprojects - this isn't really necessary as we can still decide what to do about each sub-sub-project individually later), I'd like to bring the following proposal up for a VOTE of the Web Services PMC. If this passes, I plan to submit this resolution to the board as soon as possible. http://wiki.apache.org/ws/FrontPage/Proposals/Axis2TLPProposal Note that I added just the first few people in the current PMC roster as examples. I also nominated myself as the Axis2 chair for now - if anyone else would like to volunteer to do this, please let me know. Eventually I'd like to drop one or the other PMC chair role, but for now I'm OK doing both. So if you would, please: 1) VOTE 2) Add yourself to the list of project members on the wiki page if you are an existing PMC member and would like to be on the new Axis2 PMC Here is my +1 for this proposal. Thanks, --Glen -- 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: Supporting hierarchical service deployment
Isuru, hiding the hierarchy from Web infrastructure by using '!' IMO is a
bad idea. What dispatching problems are caused by using /? Why can't those
problems be solved?
Sanjiva.
On Thu, Sep 3, 2009 at 3:47 PM, Isuru Suriarachchi isur...@gmail.comwrote:
Hi all,
As using '/' character may cause problems in dispatching, I just used a
separate character ('!') to represent the directory hierarchy in the
service. This allows all types of services to be deployed hierarchically
without any problems (Including RESTful services).
Ex: if we deploy the Echo service at
/repository/services/foo/bar/1.0.0/echo.aar, service name will be
foo!bar!1.0.0!Echo and the EPR will be like
../axis2/services/foo!bar!1.0.0!Echo/echoString
I've attached a new patch to the JIRA (
https://issues.apache.org/jira/browse/AXIS2-4479). This patch doesn't
contain any changes in dispatching logics. And also I've implemented the
ability to deploy JAXWS, Pojo etc.. (which are coming from the axis2.xml)
services hierarchically to make this effort complete. In addition to that,
I've written some deployment tests for hierarchical services.
Thanks,
~Isuru
On Sun, Aug 30, 2009 at 2:48 AM, keith chapman keithgchap...@gmail.comwrote:
I've been out of touch with the Axis2 list for some time. Took a while to
read this thread. Just a few thouths on it.
I don't think that this patch would effect the RESTfull behaviour in any
way. Its just that the user needs to be extra carefull if he wants to use
RESTfull services in cunjunction with the hierarchical services concept. i.e
if he has a services called foo do not use foo as a top level folder in your
hierarchy. Its simple as that. I guess been careful is the price you have to
pay if you wanna use hierarchical services.
I like the idea of having hierarchical services in Axis2. Well I did it
once using the extension points of Axis2 but I'm +1 for having this concept
baked into Axis2.
Also it would be good to base arguments on facts rather than religious
beleifs. Quite a few design desicions made back then when Axis2 was designed
did not take stuff such as this into consideration. Well i'm not blaming the
initial Axis2 community for that. As the project evolves new features such
as this can be added. Good examples are features such as plugable message
builders/formatters (post 1.1), custom deployers (post 1.2 IIRC), the
binding hierarchy concept (post 1.3) are features that were added later in
the cycle. I see the hierarchical service deployment feature as just another
addition to the wide variety of features of Axis2.
Thanks,
Keith.
On Sat, Aug 29, 2009 at 1:24 PM, Sanjiva Weerawarana
sanj...@opensource.lk wrote:
I forgot to address the issue with not being able to support RESTful
services. I think we can- we just need to change the REST dispatcher (argh
if that's what its called its a terrible name!) to look at the context path
of the service(s) and try filtering those out first.
Sanjiva.
On Sat, Aug 29, 2009 at 8:51 PM, Sanjiva Weerawarana
sanj...@opensource.lk wrote:
Deepal, I've read this entire thread and I'm confused as to why you're
objecting.
First of all, I think Isuru sent this thread into a bad start by using
versioning as the reason for wanting to introduce hierarchical service
deployment. That was a mistake but as Andreas' comment pointed out, this is
nothing more than the contextPath concept found in Java containers.
Versioning is at most a special case but let's just take that out of the
discussion because this is not about versioning. If you disagree please
explain why.
Secondly, this can be done outside of Axis2 totally. All we need to do
is write a new deployer and a dispatcher. There's no need to waste time
with
this type of pretty un-objective / emotional debate. However, it was
proposed as a mod to axis2 because it significantly improves axis2
usability
WITHOUT breaking any existing behavior. Or so was the belief. So let's go
thru the discussion and if the view is that this is not necessary in
axis2's
default deployers etc. then no problem.
Now I will explain why this approach is better than alternatives. The
basic requirement is that having a single flat naming scheme for services
is
unnecessarily limiting. Why? Because it requires everyone to agree on the
service name as those names are global. If you're using Axis2 as a library
on a single developer machine that's not an issue. However, if you want to
deploy an axis2 engine to host some number of services for a larger
organization then that invariably results in name conflicts. I assume you
agree that's global names are a limitation.
How do you fix it? One option is to use some naming convention like what
Java packages did for Java classes. So you can have
/services/us.finance.address and /uk.services/marketing.address if (say) US
finance and UK marketing orgs both want to have a service called address.
That basically makes
Re: [PROPOSAL] Axis2 Deployer behaviour on hot update
If we do it the way Deepal had worked on a while ago, the downtime is VERY low. Basically, what we need to do is to mark the AxisService as old (or inactive) and then that immediately stops new messages from being delivered to it. Any already dispatched service is not at all affected - as the handler chain etc. is already computed and in any case we're not changing that AxisService instance. The new AxisService object representing the updated service can then be deployed by making that be what's found by service lookup. In other words, if we do this by locking AxisConfig then the downtime is basically time of object lock + copying a few pointers. Once all messages that are running finish, the old AxisService will just get GC'ed. Hmmm clearly there must be some bug in that logic; its too simple. Sanjiva. On Sun, Aug 30, 2009 at 1:16 PM, Afkham Azeez afk...@gmail.com wrote: Simply deactivating-redeploying-activating is not the ideal solution. It should be; maintenace-mode(service_foo)-redeploy(service_foo)-normal-mode(service_foo) In maintenance mode, a service will not accept new requests, but will complete servicing existing requests. So, there is a difference between deactivating a service putting it into maintenance-mode, unless deactivated services will complete the requests being processed. However, there will be a small downtime for this service. Azeez On Sun, Aug 30, 2009 at 4:02 AM, Deepal jayasinghe deep...@gmail.comwrote: Then there's the question of how to do the update - ideal is to let messages that are already being processed be processed by the still active version and to direct new messages to the new version. I'm not sure that's implementable though .. or it would require one to bring that concept into dispatchers etc. to do the right thing. Ideal is for it to be burnt into the AxisConfig but that's a *huge* change. It is doable, and in fact I have done that, but did not commit my changes, since it was just for fun :). In AxisService you have a method called activate/inactivate, when you inactive a service system does not take any more request to that service (will throw an exception saying service not found) and will process all the current messages. Then, you need call the deployment engine to update the new service (Deployment engine has a method to load a particular services). Then you back in business. 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 -- 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: [PROPOSAL] Axis2 Deployer behaviour on hot update
On Sun, Aug 30, 2009 at 5:18 PM, Deepal jayasinghe deep...@gmail.comwrote: Yes a few bugs, first if the service create any connection like DB or file and put into ConFigCTX then those will not be removed when we do the undeployment since service does not know that. Second, if they add any properties to ConFigCtx then the same thing happens. Third it is Any state that's put into the contexts are runtime state. I was referring only to the static data that's in AxisService/AxisConfiguration etc. - that stuff can just fall off right? Even today, if you call undeploy I don't see how that can tell a service to remove things like DB connections. Those need to be tied to runtime state and somehow associated to messages. hard to detect when to finish the current message processing, because request follows different invocation depending on the MEP. Forth if the service uses something like RM, then we are not going to inform RM about that, so those state will remain there. Fifth based on where we have lib, we load classes various class loaders, so at the deployment time we can not 100% guarantee that we are going to unload all the classes. There may be some other, which did not come into my mind. Well if we load new version of a service its just another AxisService and all the classes loaded by a different class loader. The only issue where there's overlap is when that object is given a name and stuffed into hashmap in AxisConfig (via ServiceGroup but let's ignore that complication for now). I agree its hard/impossible to know when the messages in the system are done. I think what's done in Synapse is they wait for a while .. and after that kill off whatever you can and say done. Anyway, I like the idea and its worth looking into. I'm sure there will be lots of little gotchas that come up :). 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/
Re: Please revert API changes done as per AXIS2-4465
Deepal, here you write: On Sat, Aug 29, 2009 at 7:49 PM, Deepal jayasinghe deep...@gmail.comwrote: 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. = So its ok for one person to break things (Andreas, which is what started this thread) but not the other (Isuru, on the hierarchical service stuff)? Why the double standard? (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/
Re: Supporting hierarchical service deployment
provided that it *does not break existing functionality*. If you look at the directory structure (as I told you before) information repeat it self. It is analogous to Shop is closed because it is not open. Just because feature X is good in project Y, we should not introduce that to Axis2. If you or someone want to do such a feature of course they can do that, just ad a new deployer to handle the they want, even in you case we can do the same. Let's create a new deployer and manage anyway you like, and then if you think it is ok, then commit the new deployer to Axis2. However I am not ok with introducing new URL pattern, I think Isuru already agreed to replace / with - Deepal, I feel you have given over weight to the versioning support which is a use case of this. In the way to have told people can have versioning without any support of axis2, by just naming service in the way they need. Yes. At the end of the day whether it is / or - would become a unique name. So it is the service name. Comming into the other point of probable break of existing functionality Can you please come up with the set of use case scenarios for this? Then we can ask Isuru to provide integration test for all these scenarios. This may test the existing functionality as well :) I am sorry I do not have time to comeup with scenarios when someone add new features, specially even without going through the existing JIRA. I think we should not be pessimistic and think deployment engine is done for ever and any change will break it. Not at all, how many changes we made, in this case my concern is not the deployment engine it is the URL pattern. Isuru, Please provide a set of integration tests for the scenarios mentioned. :) Thanks, Deepal -- Sanjiva Weerawarana, Ph.D. Founder, Director Chief Scientist; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/
Re: Supporting hierarchical service deployment
I forgot to address the issue with not being able to support RESTful services. I think we can- we just need to change the REST dispatcher (argh if that's what its called its a terrible name!) to look at the context path of the service(s) and try filtering those out first. Sanjiva. On Sat, Aug 29, 2009 at 8:51 PM, Sanjiva Weerawarana sanj...@opensource.lkwrote: Deepal, I've read this entire thread and I'm confused as to why you're objecting. First of all, I think Isuru sent this thread into a bad start by using versioning as the reason for wanting to introduce hierarchical service deployment. That was a mistake but as Andreas' comment pointed out, this is nothing more than the contextPath concept found in Java containers. Versioning is at most a special case but let's just take that out of the discussion because this is not about versioning. If you disagree please explain why. Secondly, this can be done outside of Axis2 totally. All we need to do is write a new deployer and a dispatcher. There's no need to waste time with this type of pretty un-objective / emotional debate. However, it was proposed as a mod to axis2 because it significantly improves axis2 usability WITHOUT breaking any existing behavior. Or so was the belief. So let's go thru the discussion and if the view is that this is not necessary in axis2's default deployers etc. then no problem. Now I will explain why this approach is better than alternatives. The basic requirement is that having a single flat naming scheme for services is unnecessarily limiting. Why? Because it requires everyone to agree on the service name as those names are global. If you're using Axis2 as a library on a single developer machine that's not an issue. However, if you want to deploy an axis2 engine to host some number of services for a larger organization then that invariably results in name conflicts. I assume you agree that's global names are a limitation. How do you fix it? One option is to use some naming convention like what Java packages did for Java classes. So you can have /services/us.finance.address and /uk.services/marketing.address if (say) US finance and UK marketing orgs both want to have a service called address. That basically makes the fact that what you have are hierarchically named services opaque to the Web infrastructure. For example, if you were analyzing http logs to see the traffic you can't get a simple answer to how many times have UK guys' services been used?. That's *exactly* the kind of wrong-headed thinking that got WS-* in trouble with the REST guys for improper use of REST (and I'm absolutely one of the early culprits who made the mistake). Another approach is to have a way to specify the context path in the service itself. If you remember, we used to have the concept of service name you could specify in service.xml itself (maybe its still there; I have no idea) - the idea was it would override the .aar file name if thats' there. This is similar- you can have in foo.aar a setting saying contextPath=finance/foo and that means that's where the service is deployed. The advantage of simply using the file system hierarchy to compute that is just simplicity. The context hierarchy is visible to everyone by simply looking at the directory structure. If you check in the repository into SVN (which I know a bunch of people do) it gives a simple way to manage authorization for deployment for different people. I actually think we should support a contextPath=xxx option in services.xml as well. However, treating the file system hierarchy as a hierarchy is, you know, rather natural. I think Isuru has shown that there is no extra performance loss or any other loss by supporting hierachically deployed services. You DON'T need to use them unless you want to of course - and if there's no hierarchy there's no change at all (subject to having enough unit tests to make sure that old and new behavior for the old feature is not changed). Sanjiva. On Sat, Aug 29, 2009 at 7:05 PM, Deepal jayasinghe deep...@gmail.comwrote: On Fri, Aug 28, 2009 at 8:30 PM, Andreas Veithen andreas.veit...@gmail.com mailto:andreas.veit...@gmail.com wrote: Guys, Are we actually discussing the right question? Looking at the patch proposed by Isuru, I have the impression that versioning is merely one use case, but that (in contrast to modules) the code doesn't make any assumption about the meaning of the hierarchy in the repository (it could be version number, but it could also something completely different). Fundamentally the change is not about versioning, but about giving the user the possibility to define the structure of the endpoint URL. yes. this should be the idea. it is to support hierarchical service folder structure to mange services. Versioning is only one possible use case. I think this is a common requirement
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 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 afk...@gmail.com *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 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 serviceGroup service name=xyx /service /serviceGroup secondt service.xml serviceGroup service name=abc /service /serviceGroup 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: [PROPOSAL] Axis2 Deployer behaviour on hot update
On Thu, Aug 27, 2009 at 8:47 PM, Andreas Veithen andreas.veit...@gmail.comwrote: In Axis2, specially in production hot deployment is not something people are going to use regularly. So downtown or hot-update is not an big issues (rather they will turn off both hot-deployment and hot-update) Does the Axis2 deployment mechanism lack this kind of features because people don't use it regularly, or do people not use it regularly because it lacks these features? In my experience so far, people do use / leave hot deployment around but the deployment processes effectively disable it. That is, in no production setting is the developer allowed to update the config of a running server by logging into it :). In one case I know of someone who's updating the (Synapse) system config multiple times a day but does it by putting their servers into service mode in a round-robin fashion but that's the type of care someone must take to hot update a production system. In service mode the server doesn't accept any more messages but processes the messages that were in flight before doing system updates. So effectively he brings a node in a cluster down without affecting service response. However, it does result in a period of time where the servers have different versions of stuff deployed (I think). However, for developers this is very useful ... its like being able to edit a JSP and just refresh the page. Imagine if you had to redeploy the war file to get that to work?! IMO the deployer interface needs an update() method which the deployment logic calls after it determines (somehow) that the service needs to be updated. If we're changing the signature then we might as well do ti right rather than hacking it in (by passing a filename). Then there's the question of how to do the update - ideal is to let messages that are already being processed be processed by the still active version and to direct new messages to the new version. I'm not sure that's implementable though .. or it would require one to bring that concept into dispatchers etc. to do the right thing. Ideal is for it to be burnt into the AxisConfig but that's a *huge* change. If its considered a developer level feature then the current style is ok - just yank the old one and put the new one in. So to answer your question - IMO its because its VERY hard to hot update a system and not have weird/inconsistent behavior. If you absolutely need 24x7 operation with zero (scheduled) downtime then of course you need to do something like what I explained above and then clearly understand the issues related to different nodes having different versions of the service around. Its much easier to have a scheduled downtime. 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/
Re: [PROPOSAL] Axis2 Deployer behaviour on hot update
I forgot to mention another point I've been thinking of - even with hot deployment turned off, what we have by default is a scan and deploy at startup type model. For example, if someone makes a mistake with file permissions a particular service may not (silently) get deployed. IMO we also need to support a more locked-down model similar to what was done for the URL repo code with services.list. Basically to manually write down the list of services to be deployed (in the order that's listed even) instead of discovering what's around and deploying them once. I'm not at all suggesting losing any functionality we have but rather to maybe support services.list in all cases. IIRC that only works (out of necessity) for URL repos as there was no way to get a list then. Now of course we'd just make it an atom feed instead of inventing our own silly little format ... Sanjiva. On Sun, Aug 30, 2009 at 8:15 AM, Sanjiva Weerawarana sanj...@opensource.lkwrote: On Thu, Aug 27, 2009 at 8:47 PM, Andreas Veithen andreas.veit...@gmail.com wrote: In Axis2, specially in production hot deployment is not something people are going to use regularly. So downtown or hot-update is not an big issues (rather they will turn off both hot-deployment and hot-update) Does the Axis2 deployment mechanism lack this kind of features because people don't use it regularly, or do people not use it regularly because it lacks these features? In my experience so far, people do use / leave hot deployment around but the deployment processes effectively disable it. That is, in no production setting is the developer allowed to update the config of a running server by logging into it :). In one case I know of someone who's updating the (Synapse) system config multiple times a day but does it by putting their servers into service mode in a round-robin fashion but that's the type of care someone must take to hot update a production system. In service mode the server doesn't accept any more messages but processes the messages that were in flight before doing system updates. So effectively he brings a node in a cluster down without affecting service response. However, it does result in a period of time where the servers have different versions of stuff deployed (I think). However, for developers this is very useful ... its like being able to edit a JSP and just refresh the page. Imagine if you had to redeploy the war file to get that to work?! IMO the deployer interface needs an update() method which the deployment logic calls after it determines (somehow) that the service needs to be updated. If we're changing the signature then we might as well do ti right rather than hacking it in (by passing a filename). Then there's the question of how to do the update - ideal is to let messages that are already being processed be processed by the still active version and to direct new messages to the new version. I'm not sure that's implementable though .. or it would require one to bring that concept into dispatchers etc. to do the right thing. Ideal is for it to be burnt into the AxisConfig but that's a *huge* change. If its considered a developer level feature then the current style is ok - just yank the old one and put the new one in. So to answer your question - IMO its because its VERY hard to hot update a system and not have weird/inconsistent behavior. If you absolutely need 24x7 operation with zero (scheduled) downtime then of course you need to do something like what I explained above and then clearly understand the issues related to different nodes having different versions of the service around. Its much easier to have a scheduled downtime. 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/ -- 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: Please revert API changes done as per AXIS2-4465
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 Srinivas dava...@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 -- Thank you! http://blogs.deepal.org http://deepal.org -- 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 -- 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: Please revert API changes done as per AXIS2-4465
+1; the response to changing a public API shouldn't be a request to create a unit test to retain the API! Unit tests aren't meant to save an API; they're meant to test behavior. Sanjiva. On Thu, Aug 20, 2009 at 7:31 PM, Afkham Azeez afk...@gmail.com wrote: Creating a unit test is one thing which we can do, but Axis2 has so many public methods, and it is not reasonable at this moment to ask anybody to create unit tests for each of these public methods. I guess there is a purpose in the widely used practice of deprecating methods. Imagine if the other projects that we widely use make such ad-hoc API changes, and when we complain, if they ask us to write a unit test for their APIs; it is not reasonable. We do not want to make life complicated for everybody. Azeez On Thu, Aug 20, 2009 at 12:49 PM, Davanum Srinivasdava...@gmail.com wrote: Azeez, Do you mind creating a unit test(s) for the behavior/API(s) you need? That would help keep desired behavior and enforce that what you need will not be modified. thanks, dims On 08/20/2009 07:45 AM, Afkham Azeez 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 -- 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] Releasing 1.5.1
+1. On Tue, Aug 11, 2009 at 4:23 PM, Glen Daniels g...@thoughtcraft.com wrote: Hi Deepal: Deepal Jayasinghe wrote: So, there are currently no JIRAs left targeted for 1.5.1, and there were at least a few major fixes (in particular the CLOSE_WAIT issues, transport deployer fix, and the module versioning stuff) since 1.5 that I for one would really like to get out into the world ASAP. But we have 17 blockers? so are we going to keep them as it is or are we going address them. As I remember correct we do not do releases when we have blockers. Either we fix them or down grade them. I think the fixes we've already done are pretty critical to get out, and since we already released 1.5 with these, I'm leaning towards just targeting the current blocker list to 1.6, and letting those be our blockers for the next major release (which could be right after ApacheCon?). WDYT? If people think this is OK, I'll try to get a release wrapped up tonight if possible (I'm at a client today so won't be able to do Apache work during the day). Thanks, --Glen -- 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] Is Axis2 dying?
Dennis, ALL of the original people who worked on Axis2 from LSF/WSO2 are now in different places - most of them are in grad schools. One of the really great things that Axis2 has managed to do is attract a fairly broad community of people - IBM has contributed a lot even though they're quiet now. There are people from SoftwareAG contributing a lot and a lot of others. While I don't disagree with Glen that there are lots of places to improve, it is a fact that Axis2 just works now. As a result, for example, I don't expect to see any major work on say Axiom .. unless someone comes up with a brilliant idea on how to make radical changes that would have a lot of impact. One of the things we did reasonably well with Axis2 have a lot of plug points - so for example in WSO2 we've used those a lot in WSO2 (to write providers for other languages for example). This is hardly a dying project - its a mature stable project and frankly, WS-* core platform code is just going to be that for a while ... thank goodness the damned specs are done. I agree the transports issue is real - if the other transports don't work then we do have an issue. Glen? Sanjiva. On Thu, Jul 23, 2009 at 9:16 PM, Dennis Sosnoski d...@sosnoski.com wrote: Hi Sanjiva, Whether officially led by WSO2 or not, certainly most of the direction of the project has come from people associated with WSO2 and/or the Sri Lanka university. Glen is, I believe, the current chair of the PMC, and was also the release manager for the 1.5 release. As to Axis2 status, you don't see a problem in pointing people at a latest Axis2 release which only supports HTTP transport and does not have any corresponding Rampart release? Some delay in getting these other components out is understandable, since they are separate projects (wisely so or not), but it's been a month and a half since Axis2 1.5 was released and there's been no noticeable move toward releasing these essential components. I don't know all the details of how Apache works - is this something which should be addressed by the PMC? Thanks again, - Dennis Sanjiva Weerawarana wrote: Hi Dennis, First of all, it is not true that Axis2 work is lead by WSO2 any more .. that changed a long time ago. We're continuing to contribute but we're not the only contributors. IBM was contributing too but they seem to have take things in-house (again) but I may be wrong (hopefully someone will speak up). I think Axis2 is pretty much a stable product now and lots of people are using it productively. If there are issues that matter to you then as one of the developers should also look at it; there's no company action here! That's simply not the way Apache works. In reality, projects go thru peak development times and stable times. From my personal point of view, Axis2 is done and its working. You've got something scratching? Well, you know how to itch it :). Of course there are 100s of JIRAs but if its not a thing that bothers people it won't get fixed. This is open source; please fix it or find a way to make the bug something that bothers people. Every Axis2 release took months to do. Why? Beats the hell of out of me on one side but on the other side its because there are so many dependent projects. Totally +1 for fixing the Web site stuff up. If the docs are messed up then we should do a 1.5.1 release. Sanjiva. On Thu, Jul 23, 2009 at 5:04 AM, Dennis Sosnoski d...@sosnoski.commailto: d...@sosnoski.com wrote: I'm starting to wonder about the health of the Axis2 project, and thought it might be useful to initiate a discussion on this topic. The 1.5 release of Axis2 took 8 months from initial proposal to when it finally escaped out the door, and the results frankly don't seem to reflect the amount of elapsed time. Even the Javadocs are messed up in the release (as well as on the website). One of the main features headlined in the release notes is the transport refactoring - but the only transport available is HTTP, since there seems to be no inclination to get out a release of the new commons transports (which IMHO shows why splitting these off into a separate project was a bad idea). There isn't even an entry in the WS-Commons page at http://ws.apache.org/commons/projects-overview.html for the transports, so it's hard to tell the state of this project. There's also no indication of when we'll have a Rampart release to go along with Axis2 1.5. I realize a lot of the Axis2 and Rampart work is being led by WSO2, and perhaps the people in that organization have a plan. But if that's the case, I'd appreciate it if they could make it public for the rest of us to know what's going on. Thanks, - 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
Re: [Axis2] Is Axis2 dying?
Hi Dennis, First of all, it is not true that Axis2 work is lead by WSO2 any more .. that changed a long time ago. We're continuing to contribute but we're not the only contributors. IBM was contributing too but they seem to have take things in-house (again) but I may be wrong (hopefully someone will speak up). I think Axis2 is pretty much a stable product now and lots of people are using it productively. If there are issues that matter to you then as one of the developers should also look at it; there's no company action here! That's simply not the way Apache works. In reality, projects go thru peak development times and stable times. From my personal point of view, Axis2 is done and its working. You've got something scratching? Well, you know how to itch it :). Of course there are 100s of JIRAs but if its not a thing that bothers people it won't get fixed. This is open source; please fix it or find a way to make the bug something that bothers people. Every Axis2 release took months to do. Why? Beats the hell of out of me on one side but on the other side its because there are so many dependent projects. Totally +1 for fixing the Web site stuff up. If the docs are messed up then we should do a 1.5.1 release. Sanjiva. On Thu, Jul 23, 2009 at 5:04 AM, Dennis Sosnoski d...@sosnoski.com wrote: I'm starting to wonder about the health of the Axis2 project, and thought it might be useful to initiate a discussion on this topic. The 1.5 release of Axis2 took 8 months from initial proposal to when it finally escaped out the door, and the results frankly don't seem to reflect the amount of elapsed time. Even the Javadocs are messed up in the release (as well as on the website). One of the main features headlined in the release notes is the transport refactoring - but the only transport available is HTTP, since there seems to be no inclination to get out a release of the new commons transports (which IMHO shows why splitting these off into a separate project was a bad idea). There isn't even an entry in the WS-Commons page at http://ws.apache.org/commons/projects-overview.htmlfor the transports, so it's hard to tell the state of this project. There's also no indication of when we'll have a Rampart release to go along with Axis2 1.5. I realize a lot of the Axis2 and Rampart work is being led by WSO2, and perhaps the people in that organization have a plan. But if that's the case, I'd appreciate it if they could make it public for the rest of us to know what's going on. Thanks, - 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 -- 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] Make RPCUtil more flexible
the sender by e-mail immediately, uphold strict confidentiality and neither read, copy, transfer, disseminate, disclose nor otherwise make use of its content in any way and delete the material from your computer. The content of the e-mail and its attachments is the liability of the individual sender, if it does not relate to the affairs of Betware. Betware does not assume any civil or criminal liability should the e-mail or it´s attachments be virus infected. -- 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/
Fwd: nightly build failing? (trying to solve some memory leaks)
-- Forwarded message -- From: Haszlakiewicz, Eric ehas...@transunion.com Date: Wed, Jun 3, 2009 at 9:09 PM Subject: nightly build failing? (trying to solve some memory leaks) To: Apache AXIS C User List axis-c-u...@ws.apache.org I'm trying to track down some memory leaks I'm seeing (just a axis2_stub_create_foo() immediately followed by axis2_stub_free() leaks memory), and I thought I'd try out the latest axis2/java snapshot because I noticed some problems in the generated C code. However, the build has been failing for two weeks with the same error: [INFO] Internal error in the plugin manager getting plugin 'org.apache.axis2:axis2-aar-maven-plugin': Failed to create plugin container for plugin 'Plugin [org.apache.axis2:axis2-aar-maven-plugin]': Error starting container No such file or directory Is anyone going to fix that, or do I need to figure out how to build things myself? eric -- 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: [Vote] Dobri Kitipov as a committer
+1! Amila Suriarachchi wrote: hi all, Dobri Kitipov has been active in the axis2 dev[1] and rampart dev [2] recent time and he has submit patches for various issues. So I would like to propose him as a committer and here is my +1. thanks, Amila. [1] http://markmail.org/search/?q=list%3Aorg.apache.ws.axis-dev+Dobri+Kitipov [2] http://markmail.org/search/?q=list%3Aorg.apache.ws.rampart-dev+Dobri+Kitipov -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/ -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/
Re: Using Axis2 Java with OSGi - some help appreciated
are not wired during the Resolving process performed by the OSGi framework implementation. At the same time, you need to export the package in which message receiver classes reside. I got the code working with the Eclipse/Equinox version of OSGi by patching the following into the manifest for the axis2-kernel jar: Eclipse-BuddyPolicy: dependent ...and then declaring the relevant Tuscany jar files as being buddies of the axis2-kernel bundle in thier manifests. Seems like your implementation works only with Equinox, since you have used Equinox specific constructs. However, I know that this is really a sticking-plaster solution and will only currently work for the Equinox version of OSGi. Do you have a nice neat solution that will work for all the OSGi implementations? Yes. We, in WSO2 have built WSO2 Carbon [1] which runs on OSGi. WSO2 Carbon is the base platform for all the WSO2 java projects. Carbon uses Axis2 and we have solved most of these problems. Yours, Mike. [1] http://wso2.org/projects/carbon -- Sameera Jayasoma Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog:http://tech.jayasoma.org/ -- Sameera http://sameera-jayasoma.blogspot.com/ http://www.flickr.com/photos/sameera-jayasoma -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/
Re: Comments about the new UnknownContentBuilder (AXIS2-4153)
Andreas Veithen wrote: Questions are: * While TextMessageBuilder and TextMessageFormatter should clearly remain optional (i.e. they would only be implemented by builders and formatters that deal with text content), MessageFormatterEx could also be merged into MessageFormatter. The additional getDataSource method can easily be implemented (message formatters are already required to return byte[], so returning a DataSource is not difficult). However this would break existing MessageFormatter implementations outside of Axis2. What do you think? +1 for merging getDataSource() into MessageFormatter. * Is this in scope for Axis2 1.5? No because Axis2 1.5 is already in progress. This is a breaking change and hence should not be rushed. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/
Re: [axis2] Cleaning up the builders and documentation [was Re: Comments about the new UnknownContentBuilder (AXIS2-4153)]
be returned each time this method is called, and [that] the stream must be positioned at the beginning of the data. The consequence will be that the message produced by UnknownContentBuilder can only be read once. This is a serious flaw. 2. The AXIOM tree produced by UnknownContentBuilder has only two nodes: an OMElement and an OMText (with a DataHandler). Using an OMSourcedElement/OMDataSource is not justified for this and would introduce unnecessary complexity and overhead. 3. The code in UnknownContentBuilder to a large extend duplicates the code in org.apache.axis2.format.BinaryBuilder (in axis2-transport-base), which doesn't have problems 1 and 2. Could you please make a proposal how to improve this? Regards, Andreas -- Thilina Gunarathne - http://thilinag.blogspot.com -- Thilina Gunarathne - http://thilinag.blogspot.com -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/
Re: Comments about the new UnknownContentBuilder (AXIS2-4153)
Can we please move the BinaryBuilder to axis2 with the rest of the message builders? Sanjiva. Thilina Gunarathne wrote: Hi Andreas, I'm sorry, I missed this mail.. Saw it only now... I agree with you regarding the 1. But I guess the solution will need to address deferred building, which will make it bit complex... Something like implementing a pushbackInputStream which will directly give the bytes from the transport inputstream while buffering it to give it the next time... Regarding 2, I don't think we can call anything the right solution for this. Normally Axis2 uses OMDataSources to carry native data as long as it can, so that if an entity which knows how to process the native data can take advantage of it.. Also using the OMSourcedElement, clearly distinguish the usage of unknown content from other messages... Regarding the 3, my apologies once again... I was not aware of such a thing when I wrote the above. IMHO builder should live inside Axis2.. I did this (and the mime support) as a solution to the issue raised in Synapse. Wonder why they did not simply use the impl you mentioned May be I'm missing something.. Let's see how we can combine these efforts... thanks, Thilina. 1. The class InputStreamDataSource (the one in org.apache.axis2.builder.unknowncontent) violates the javax.activation.DataSource contract which says for the getInputStream method that a new InputStream object must be returned each time this method is called, and [that] the stream must be positioned at the beginning of the data. The consequence will be that the message produced by UnknownContentBuilder can only be read once. This is a serious flaw. 2. The AXIOM tree produced by UnknownContentBuilder has only two nodes: an OMElement and an OMText (with a DataHandler). Using an OMSourcedElement/OMDataSource is not justified for this and would introduce unnecessary complexity and overhead. 3. The code in UnknownContentBuilder to a large extend duplicates the code in org.apache.axis2.format.BinaryBuilder (in axis2-transport-base), which doesn't have problems 1 and 2. Could you please make a proposal how to improve this? Regards, Andreas -- Thilina Gunarathne - http://thilinag.blogspot.com -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/
Re: Committing patch contributed for MIME message parser and serializer based on Apache mime4j [WSCOMMONS-387]
Oleg? Thilina Gunarathne wrote: Hi All. Wonder why Oleg removed the patch, without even committing it to a branch.. I did not even get a chance to look in to the new patch with deferred building :(... Current API and impl's were designed in a desperate manner to get MTOM SWA working, when we found that java mail does not work well for us. So I'm sure there are many places where we can improve the architecture and the API. I would like to volunteer and team up with Oleg to fix the inflexibility and the API that people were reporting in this thread. Hopefully we can eventually come up with an abstract API to support different implementations and to plug in MIME4J. For this I would like to understand the inflexibility and the concrete use cases in a more detailed manner, so that we'll not just think of MTOM SWA when reorganising these things. I need support from all of you guys for this matter. thanks, Thilina --Thilina Gunarathne - http://thilinag.blogspot.com -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Axis2 as TLP
Deepal, this vote was called when there *clearly* was no consensus in the axis2 community on what constituted the right TLP. I don't know who's schedule we were running to but that's not right. Furthermore, a lot of conversation on that thread was not done in a proper, civil manner. That's why I voted -1. I am going to respond to the new thread- I'm happy to help shape a new TLP proposal that has a better chance of getting consensus. This is not about winning a vote but rather achieving consensus - that's why I was so disappointed that the previous vote was called for ... this is a project that has been around for like 7-8 years (?) and we are trying to rush into a breakup plan. Makes no sense to me. Sanjiva. Deepal jayasinghe wrote: keith chapman wrote: -1 (binding) As the discussion shows we are clearly not ready yet. What is your definition for ready ? do you think any project which graduated as TLPs were ready ? . Not only that we can find a number of project which are in TLP still not ready (compared to Axis2 ). Honestly I do not know the Apache policy for graduating a project as TLP , specially what level of ready they are looking for. If we wait till project to be get ready before moving to TLP I am sure Apache will not have any of the TLPs. And if you vote based on that (ready or not ready) I know you will never +1 for Axis2 as TLP. I guess making Axis2 a TLP at the moment will just increase the complexity than giving any added value. I do not understand this , do you think after we move Axiom , rampart and Neethi from Axis2 to WS complexity increased ? of course not. More and more people started to use Axiom and Neethi after that. I think even ODE will not use Axiom unless we move that as a TLP in WS (top level subproject in WS). Thank you! Deepal Thanks, Keith. On Thu, Nov 20, 2008 at 9:03 PM, Glen Daniels [EMAIL PROTECTED] wrote: Folks: Discussion seems to have died down about the TLP proposal, and I think we heard a lot of valuable viewpoints during the conversation. At this point, I think it's time to VOTE on the idea and see where we're at. I've described what we're voting on on the wiki page [1], and will include it here as well: * Restructure Axis2 as an independent TLP, containing subprojects that *directly* relate to Axis2 - these include all the Modules and Transports. This ends up being a reasonably sized and well-focused project. * Once Axis2 is split out, we'll move the sub-sub-projects inside WS-Commons (Axiom, Neethi, XmlSchema) up to be WS subprojects. This will also involve making sure that the SVN authorizations are appropriately granular. * We'll then do a review of the remaining projects inside WS and based on that, decide whether any further action is needed. Such actions might include promoting more projects to TLPs, or retiring stagnant codebases. Please chime in with your VOTE on this (and indicate binding/non-binding depending on whether you are a PMC member). Here's my +1 (binding). Thanks, --Glen [1] http://wiki.apache.org/ws/FrontPage/Proposals/Axis2TLPProposal -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Axis2 as TLP
Asankha, I totally agree the transports need to be buildable and releasable as an entities by themselves. However, a TLP does not correspond to one piece of code. TLP == community to me. So right now the transports are in the WS TLP but we now can release them separately. I see no reason that would change even with the transports being under the axis2 TLP. So, +1 to making the transports also into a separate subproject. Whether that's under axis2 or ws, I really see no difference. YMMV. Sanjiva. Asankha C. Perera wrote: I am -1 (binding) on this proposal as it is. I am not for, or against Axis2 becoming a TLP, but I am strongly opposed to moving the transports to within Axis2, as it would make it difficult to develop and release new versions of them independently of the Axis2 trunk and release cycles - which are known to be long and painful. Apache Synapse folks developed some of these transports as they are highly dependent on these, and they frequently require quick fixes at transport level to be able to add new features and handle various issues. Thus the ability to get a new version of the transports released when needed is immensely important for Apache Synapse among other issues. In addition as a developer, I have to admit that I hate to build Axis2 trunk each time I want to commit changes to a transport, as it takes ages to build and fills up the M2 repo and finally fails many times due to various issues. The interface between a transport and anything else is clear, and you do not need to stick it deep into a parent codebase to keep both working. We also have had length discussions on this for a long time, and agreement from *all* the key players involved in this discussion, to make the new WS-transports sub project outside of Axis2 - with independent release cycles etc. I do not want to make this VOTE thread a discussion, but wanted everyone to be aware on the effect of these actions on those who develop and use this piece of software. asankha [1] http://markmail.org/message/uvhz22bqnkjq3wmf [2] http://markmail.org/message/fr73nj32lchlgbxi [3] http://markmail.org/message/okzimikvmbhimflr Glen Daniels wrote: Folks: Discussion seems to have died down about the TLP proposal, and I think we heard a lot of valuable viewpoints during the conversation. At this point, I think it's time to VOTE on the idea and see where we're at. I've described what we're voting on on the wiki page [1], and will include it here as well: * Restructure Axis2 as an independent TLP, containing subprojects that *directly* relate to Axis2 - these include all the Modules and Transports. This ends up being a reasonably sized and well-focused project. * Once Axis2 is split out, we'll move the sub-sub-projects inside WS-Commons (Axiom, Neethi, XmlSchema) up to be WS subprojects. This will also involve making sure that the SVN authorizations are appropriately granular. * We'll then do a review of the remaining projects inside WS and based on that, decide whether any further action is needed. Such actions might include promoting more projects to TLPs, or retiring stagnant codebases. Please chime in with your VOTE on this (and indicate binding/non-binding depending on whether you are a PMC member). Here's my +1 (binding). Thanks, --Glen [1] http://wiki.apache.org/ws/FrontPage/Proposals/Axis2TLPProposal -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Committing patch contributed for MIME message parser and serializer based on Apache mime4j [WSCOMMONS-387]
Oleg Kalnichevski wrote: I have commit rights for Synapse, but I do not recall ever being granted WS commit rights. With the transport move you do now. Thilina, while I agree with don't fix if it ain't broke, this is an *improvement* .. not a fix for the sake of a fix. I think we should do it. If it breaks something (like interop) we can always revert .. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Committing patch contributed for MIME message parser and serializer based on Apache mime4j [WSCOMMONS-387]
For what reason? If you decide to veto then you should have the courtesy to give a reason. Sanjiva. Davanum Srinivas wrote: -1 to checking in the patch as-is. thanks, dims On Thu, Nov 20, 2008 at 8:23 AM, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: Oleg Kalnichevski wrote: I have commit rights for Synapse, but I do not recall ever being granted WS commit rights. With the transport move you do now. Thilina, while I agree with don't fix if it ain't broke, this is an *improvement* .. not a fix for the sake of a fix. I think we should do it. If it breaks something (like interop) we can always revert .. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Axis2 as TLP
-1. I'm voting -1 not because of the actual action of creating a TLP for Axis2 but rather because of the process by which this discussion has ensued. The discussion has been unpleasant and downright anti-social / anti-community style and we appear to be pushing forward to fix some problem that is purportedly going to get fixed by this action without any real basis for such belief. I also agree with Chinthaka about keeping Axiom Neethi too as part of the TLP - being part of the TLP has no implication on usage in other projects etc. and I want it kept together because that's where the core community that developed those and maintain those live. So, a disappointed -1 from me (binding). Sanjiva. Glen Daniels wrote: Folks: Discussion seems to have died down about the TLP proposal, and I think we heard a lot of valuable viewpoints during the conversation. At this point, I think it's time to VOTE on the idea and see where we're at. I've described what we're voting on on the wiki page [1], and will include it here as well: * Restructure Axis2 as an independent TLP, containing subprojects that *directly* relate to Axis2 - these include all the Modules and Transports. This ends up being a reasonably sized and well-focused project. * Once Axis2 is split out, we'll move the sub-sub-projects inside WS-Commons (Axiom, Neethi, XmlSchema) up to be WS subprojects. This will also involve making sure that the SVN authorizations are appropriately granular. * We'll then do a review of the remaining projects inside WS and based on that, decide whether any further action is needed. Such actions might include promoting more projects to TLPs, or retiring stagnant codebases. Please chime in with your VOTE on this (and indicate binding/non-binding depending on whether you are a PMC member). Here's my +1 (binding). Thanks, --Glen [1] http://wiki.apache.org/ws/FrontPage/Proposals/Axis2TLPProposal -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: POLOKA proposal in context of existing Apache projects
Hi Serge, Sorry to not have recognized the name .. small world eh? :-). OK now I understand the project - I've been long advocating universities to participate in open source as I see universities as our research division! That's the way we can beat any corporate research division ;-). I'm happy to mentor it and champion it. However, let me try to find another champion though just because of practical time issues .. In terms of sponsor- if you want the WS PMC to sponsor it then you need to make the request to [EMAIL PROTECTED] Alternatively, we can ask the Incubator PMC to sponsor it .. IMO that's easier and that sort of gives you more flexibility in deciding your final ASF home upon graduation. Sanjiva. Mankovskii, Serge wrote: Hi Sanjiva, It is great to hear from you! I think we've met during EDCIS 2002 in Beijing. Arno Jacobsen was there too. It looks like you know Peter Niblett for a while as well! It looks like at the movement that we are not able to secure a member of Apache that would Champion and Sponsor us. I think we need to ask PMC to do that. Can you help us there? Yes, there is code, and a lot of it. But the code is focused on the pub/sub matching, messaging, and federation. It does not use any of WS stack at the moment and it does not follow any standards. We are going to release this code and then work it into the standards stack. It will bring results of six year research into the open source in a way that everybody would be able to use it. Reference Implementation means that within the project there will be it will be a distribution that would contain all that WS-N stack requires and no more or no less than that. To accomplish this objective within MUSE without totally re-implementing it might be a problem. Cheers Serge -Original Message- From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2008 10:45 PM To: [EMAIL PROTECTED] Cc: Mankovskii, Serge; [EMAIL PROTECTED]; [EMAIL PROTECTED]; axis-dev@ws.apache.org Subject: Re: POLOKA proposal in context of existing Apache projects Deepal, that's cart before the horse .. this project needs to get to graduation first :). Serge, are you asking for the WS PMC to sponsor this project for incubation? If so, how does this relate to the WS-Notification impl we already have on top of Axis2? (Muse?) Having one by no means does not mean there can't be another; just trying to understand the relationship. Is there code already developed that you're looking to contribute to the ASF? Or are you proposing to write new code?? The first line of the proposal starts with Poloka will be a standalone reference implementation ... Later text suggests there's working code, but if there is no working code the right model is to join the existing community and build on that codebase. What does reference implementation mean? [Hi Peter (Niblett)! Long time :) ..] Sanjiva. Deepal jayasinghe wrote: I think we can keep this as the same level as Sandesha and Ramparrt. I mean we do not have any modules other than core stuff under Axis2. Deepal Serge, Unfortunately i won't be able to help much at this time due to time pressures. Hopefully one of my fellow PMC members may be interested in moving this forward. Best Wishes. thanks, dims On Fri, Nov 7, 2008 at 3:54 PM, Mankovskii, Serge [EMAIL PROTECTED] wrote: Hi Davanum, In our search for a Champion and Sponsor for the Poloka proposal http://wiki.apache.org/incubator/PolokaProposal We looked into the Savan, ServiceMix, Axis2, and MUSE projects. We find that it makes most sense, so far, to have Poloka as a project under Axis2. It also makes sense to go into the ServiceMix, that implements WS-Notification already, but objectives of ServiceMix and POLOKA are somewhat different in respect to POLOKA goal to provide a stand-alone reference implementation of the spec. Bringing entire ServiceMix in the picture might be too much. However ServiceMix could benefit from the POLOKA work in the future. Poloka (http://poloka.org) could create an Axis2 module implementing handlers creating a messaging network for a federation of Axis2 servers. This way we would be able to support - Standalone WS-Notification compliant notification producer and notification consumer - Standalone WS-BrokeredNotification broker - Federation of WS-BrokeredNotification brokers. It would make sense to integrate Savan functionality within Poloka as time goes but not other way around. I think so because Poloka objective is broader than Savan objective in respect to: - Broker support Broker support is defined in WS-Notification and not in WS-Eventing. Although it is possible that once a broker with WS-Eventing interface is created, the picture might change. - Subscription WS-Eventing defines subscription language based on XPath (content-based semantic). WS-Notification defines subscription Filers using
Re: POLOKA proposal in context of existing Apache projects
Deepal, that's cart before the horse .. this project needs to get to graduation first :). Serge, are you asking for the WS PMC to sponsor this project for incubation? If so, how does this relate to the WS-Notification impl we already have on top of Axis2? (Muse?) Having one by no means does not mean there can't be another; just trying to understand the relationship. Is there code already developed that you're looking to contribute to the ASF? Or are you proposing to write new code?? The first line of the proposal starts with Poloka will be a standalone reference implementation ... Later text suggests there's working code, but if there is no working code the right model is to join the existing community and build on that codebase. What does reference implementation mean? [Hi Peter (Niblett)! Long time :) ..] Sanjiva. Deepal jayasinghe wrote: I think we can keep this as the same level as Sandesha and Ramparrt. I mean we do not have any modules other than core stuff under Axis2. Deepal Serge, Unfortunately i won't be able to help much at this time due to time pressures. Hopefully one of my fellow PMC members may be interested in moving this forward. Best Wishes. thanks, dims On Fri, Nov 7, 2008 at 3:54 PM, Mankovskii, Serge [EMAIL PROTECTED] wrote: Hi Davanum, In our search for a Champion and Sponsor for the Poloka proposal http://wiki.apache.org/incubator/PolokaProposal We looked into the Savan, ServiceMix, Axis2, and MUSE projects. We find that it makes most sense, so far, to have Poloka as a project under Axis2. It also makes sense to go into the ServiceMix, that implements WS-Notification already, but objectives of ServiceMix and POLOKA are somewhat different in respect to POLOKA goal to provide a stand-alone reference implementation of the spec. Bringing entire ServiceMix in the picture might be too much. However ServiceMix could benefit from the POLOKA work in the future. Poloka (http://poloka.org) could create an Axis2 module implementing handlers creating a messaging network for a federation of Axis2 servers. This way we would be able to support - Standalone WS-Notification compliant notification producer and notification consumer - Standalone WS-BrokeredNotification broker - Federation of WS-BrokeredNotification brokers. It would make sense to integrate Savan functionality within Poloka as time goes but not other way around. I think so because Poloka objective is broader than Savan objective in respect to: - Broker support Broker support is defined in WS-Notification and not in WS-Eventing. Although it is possible that once a broker with WS-Eventing interface is created, the picture might change. - Subscription WS-Eventing defines subscription language based on XPath (content-based semantic). WS-Notification defines subscription Filers using Topic Dialects (topic-based semantic), XPath over message content (content-based semantic, same as in WS-Eventing), and resource properties (optional and unclear semantics, needs refinement in the spec). - Matching performance It seems that we can improve performance of XPath matching based on the research done by the PADRES http://research.msrg.utoronto.ca/pub/Padres project. It would be equally applicable to WS-Notification and WS-Eventing. Naweed Tajuddin, a Master student of Prof. Arno Jacobsen, is looking specifically into this issue for his master thesis. What do you think? We are looking for the input and guidance of the Apache community in moving the POLOKA proposal forward. Please help! Regards Serge -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Axis2 as TLP
I have read your emails but I did not find an explanation of why you think we're a shell of what we used to be. While I of course realize that you have personal issues against me, this is a community discussion and you should try to keep the conversation about the community and not about your issues with me. If you don't want to explain your position that we've recently gone downhill that's fine, but telling me to get lost is not good enough and MOST CERTAINLY will not work. I've been around here since before any of this stuff existed and I sure ain't going nowhere .. not as long as I'm alive and kicking! Nice try, though. Sanjiva. Davanum Srinivas wrote: I've given concrete examples if you bothered to read my emails. At this point, i'll say get lost! thanks, dims On Sat, Nov 1, 2008 at 11:57 PM, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: If you want to have a conversation about this topic then you should be ready to explain your statements. You have made bold statements about how things have gone down hill but yet you have no explanation except some attempt at a smart-ass response. Doesn't quite work. Sanjiva. Davanum Srinivas wrote: Thanks for the deep insight and pointing out my double standards. -- dims On Sat, Nov 1, 2008 at 1:25 PM, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: Um, didn't the umbrella grow to this size under your watch?? I'm not opposed to a new TLP, but I don't understand on what basis you're claiming we are now just a shell of what we used to be. Sanjiva. Davanum Srinivas wrote: related note - i once upon a time used to hold ws up as the best model of working in open source. It's a tragic pity that we are now just a shell of what we used to be. my 2 cents. YMMV. -- dims On Fri, Oct 31, 2008 at 6:11 AM, Davanum Srinivas [EMAIL PROTECTED] wrote: Samisa, You have hit the nail on the head. People are who they are. Right now the umbrella is so vast that everyone is able to hide behind others. There is no accountability. When there is a smaller group of active people, There will be better accountability to each other and to the board and to our end users. There are tactics that we can employ for example, we should make a new single release including all projects including XmlSchema, Rampart and Sandesha with Axis2. But still make extra releases of say Sandesha2 as necessary as well separately for Sandesha. You will ask, why can't we do this today and i'll say that these kind of tactics work better with a TLP like focus. thanks, dims On Fri, Oct 31, 2008 at 4:28 AM, Samisa Abeysinghe [EMAIL PROTECTED] wrote: Davanum Srinivas wrote: Eran, Clearly you did not read my previous emails. *PLEASE* read them and then we can continue. For example, I said 1. The proposal was to split Axis2+Anything that Axis2 Uses+Anything that is built on Axis2 into a separate TLP. Also, i said this before, but repeat it again, The current status quo sucks. What we have is not working. - Really bad web sites - Really bad status of JIRA issues - Really bad track record of making releases periodically - There are many disjoint islands - The set of projects mentioned above is totally disjoint from other projects in WS PMC. How can a TLP solve all these? If people are who they are now, even after making Axis2 a TLP, the bad websites and bad release cycles will remain. On the other hand, if we cannot sync the releases of Axis2's sub projects, then irrespective of Axis2 being a TLP, it would turn out to be a useless project. Because one of Axis2's key strenghts is the set of sub projects it has. So IMHO, what is more important is to solve the above problems. However, I doubt if TLP would be a solution for that. Samisa... What we have is broken, We are not the only ones in this situation, this has happened before at Apache with XML and Jakarta PMC's. Please go and look at the history and how the projects are faring now after becoming logical/smaller footprint PMCs. Please go ask them or ask the board@ or ask members if you don't believe, let's learn from their experiences. *IF* people who are on the current projects that are not in the Axis2+Anything that Axis2 Uses+Anything that is built on Axis2 list want to tell us something, they should chime in and tell us what they think and we'll take a vote. Right now it's just a few of us who are just repeating the same things over and over again without even reading what the other person is saying. thanks, dims On Thu, Oct 30, 2008 at 6:07 PM, Eran Chinthaka [EMAIL PROTECTED] wrote: On Thu, Oct 30, 2008 at 5:42 PM, Davanum Srinivas [EMAIL PROTECTED] wrote: Chinthaka, What are the problems that will be created? Please enumerate them. How is it being handled / smoothed over now and what would change specifically to make the cooperation not happen. Problems : 1. Another member will have to waste time on doing PMC work 2. We will lose the tight dependency between Axis2 and related projects like Axiom, Neethi, Sandesha
Re: Multiple deployers in axis2.xml
Deepal, proposing an improvement is not saying some idea that was implemented some time ago was bad. That was the best we could do given the information we had then, but this is about improving things going forward. There's no need to be defensive about decisions we made many years ago .. no decision is perfect and I can name at least 10 major flaws in Axis2 in hindsight. That doesn't mean we were stupid then - just means that we didn't know better. Hindsight is always 20/20. What I'm thinking about is a way to make it MUCH MORE flexible and user friendly than it is now. Clearly, YMMV. “When you're finished changing, you're finished.” .. Benjamin Franklin. Sanjiva. Deepal jayasinghe wrote: we can do some thing like that Jboss does. In Jboss if you want to deploy a web application either it should be put as .war file or under a directory of which name ends with .war . i.e in axis2 point of view either it should be bar.aar file or bar.aar directory. In my point of view always deployer should only map to an extension. -1 , if you think the POJO deployer it can handle both .class files and .jar files , so are you saying thats a problem. If we have the flexibility and if we doing that for a long time without any problem, then we should continue to keep it as it is. In the above way it can support both expanded and single file modes. Hehe , seems like you are not happy with the current way , I do not know whether you know about the deployment mechanism we had before the deployer concept , and do you know how much of work JAX-WS people did to deploy their services. FYI , at Apachecon US 2007 we had a BOF session and their they mentioned what they are doing and the difficulties of the process , so as solution to that problem I introduced the idea of deployer , and whether you agree with me or not , it made the deployment so flexible and more extensible. And I do not see a any issues with that other thane the issue that Jarek mentioned. Thank you! Deepal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple deployers in axis2.xml
Amila Suriarachchi wrote: we can do some thing like that Jboss does. In Jboss if you want to deploy a web application either it should be put as .war file or under a directory of which name ends with .war . i.e in axis2 point of view either it should be bar.aar file or bar.aar directory. Sounds good .. I like it; less options and magic the better. In my point of view always deployer should only map to an extension. In the above way it can support both expanded and single file modes. Yes, but a given deployer can of course support multiple extensions - like for POJOs support .class and .jar both. In Axis2.xml level we should be able to define deployment directories.(In most case one is enough). These directories can have files with any extension and relevant deployer can be used to deploy these files. In http case service path is determined relative to this directory. +1. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Add XmlSchema, Neethi, Axiom to TLP Proposal
hDaniel Kulp wrote: On Monday 03 November 2008 12:46:42 pm Davanum Srinivas wrote: So, should all synapse and cxf folks have access to all these projects? What say you? No. It's still a community and thus the normal meritocracy rules apply. That said, some of those projects may need a swift kick in the pants to get them moving again and getting some fresh blood into them. There are several outstanding patches and requests and such that could warrant some votes on some new people.It shouldn't be hard for a CXF person or Axis2 persons or anyone else to become a committer through the normal means. Unfortunately, that hasn't been working too well lately. Getting the projects promoted a level may help increase some awareness which may help as would looking at the interested people and seeing if they do deserve committership or not. +1 to both points. Dan, what's your suggestion? What do you think is the right answer? Glen, why do you think Axiom as a TLP is not a good idea? Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Axis2 as TLP
Deepal jayasinghe wrote: Amila Suriarachchi wrote: On Sun, Nov 2, 2008 at 6:06 AM, Deepal jayasinghe [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Honestly I have no idea. But some one working closely with Synapse would give the exact Answer. Well , thats the problem. As I mentioned earlier it gets more visibility how can you support your argument using [1] and [2]? As I can see both CXF and Axis2 have followed a similar kind of curve from Mar - Oct. So for me it is a different thing than being a TLP or not. Hehe , that is the point , Axis2 is around for about more than four years but CXF is not that old. CXF has that curve after they graduate as a TLP . Nonsense- it has a solid curve after reaching the 2.0 release. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Axis2 as TLP
I'd certainly +1 a new TLP for Axiom. Given that its being used broadly by others too I think that makes sense. However there are complications there too - one of Axiom's KEY values is its natural MTOM/XOP awareness. That's a bit hard to justify without the relationship to SOAP. Under no condition can we lost that obviously as that's one of the foundational bits of Axiom. Also, I've always wanted to build a type-aware version of Axiom .. one that parses directly out of the XML event stream into a typed data model. I guess that's a bit of what SXC does too. (The other thing I've long wanted to do is a to do a custom parser that avoids copying etc..) However, a lot of this extra metadata for parsing would be coming from WSDL etc. - which again will tie it to SOAP stuff. Overall, I think the Axiom TLP makes most sense right now vs. an axis2 TLP as that's the most standalone of the lot. Sanjiva. Deepal jayasinghe wrote: Hi Sanjiva: Sanjiva Weerawarana wrote: Deepal, so just so I understand - are you saying you *don't* want to keep Axiom with Axis2? I'm not sure about Deepal, but I don't in fact think keeping Axiom under the Axis2 project (yes, even despite the acronym :)) makes sense. In my version of the new world order, Axis2 and the components that are *Axis2-specific* (i.e. cannot profitably be used outside Axis2) should be in the Axis2 project. The stuff that is reusable and more generally focused (i.e. Axiom, Neethi, XmlSchema, etc) should IMO remain in WS so it can continue to be shared. If we're talking about moving Axiom/Neethi/etc., then it really is pretty much s/Web Services/Axis2/g and I wouldn't be in favor of that. +1 .I understand what you mean , yes they should not come under Axis2 , and in fact we should try to get Axiom as a TLP (im not sure about Neethi). Deepal --Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple deployers in axis2.xml
, 2008 at 5:20 PM, Jarek Gawor [EMAIL PROTECTED] wrote: Hi, Does anyone have comments on https://issues.apache.org/jira/browse/AXIS2-4101? In general, I would like to know if we should allow for multiple deployers to be registered for the same file extension (for any directory). Right now, only one is assumed and that causes problems. Thanks, Jarek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Axis2 as TLP
Um, didn't the umbrella grow to this size under your watch?? I'm not opposed to a new TLP, but I don't understand on what basis you're claiming we are now just a shell of what we used to be. Sanjiva. Davanum Srinivas wrote: related note - i once upon a time used to hold ws up as the best model of working in open source. It's a tragic pity that we are now just a shell of what we used to be. my 2 cents. YMMV. -- dims On Fri, Oct 31, 2008 at 6:11 AM, Davanum Srinivas [EMAIL PROTECTED] wrote: Samisa, You have hit the nail on the head. People are who they are. Right now the umbrella is so vast that everyone is able to hide behind others. There is no accountability. When there is a smaller group of active people, There will be better accountability to each other and to the board and to our end users. There are tactics that we can employ for example, we should make a new single release including all projects including XmlSchema, Rampart and Sandesha with Axis2. But still make extra releases of say Sandesha2 as necessary as well separately for Sandesha. You will ask, why can't we do this today and i'll say that these kind of tactics work better with a TLP like focus. thanks, dims On Fri, Oct 31, 2008 at 4:28 AM, Samisa Abeysinghe [EMAIL PROTECTED] wrote: Davanum Srinivas wrote: Eran, Clearly you did not read my previous emails. *PLEASE* read them and then we can continue. For example, I said 1. The proposal was to split Axis2+Anything that Axis2 Uses+Anything that is built on Axis2 into a separate TLP. Also, i said this before, but repeat it again, The current status quo sucks. What we have is not working. - Really bad web sites - Really bad status of JIRA issues - Really bad track record of making releases periodically - There are many disjoint islands - The set of projects mentioned above is totally disjoint from other projects in WS PMC. How can a TLP solve all these? If people are who they are now, even after making Axis2 a TLP, the bad websites and bad release cycles will remain. On the other hand, if we cannot sync the releases of Axis2's sub projects, then irrespective of Axis2 being a TLP, it would turn out to be a useless project. Because one of Axis2's key strenghts is the set of sub projects it has. So IMHO, what is more important is to solve the above problems. However, I doubt if TLP would be a solution for that. Samisa... What we have is broken, We are not the only ones in this situation, this has happened before at Apache with XML and Jakarta PMC's. Please go and look at the history and how the projects are faring now after becoming logical/smaller footprint PMCs. Please go ask them or ask the board@ or ask members if you don't believe, let's learn from their experiences. *IF* people who are on the current projects that are not in the Axis2+Anything that Axis2 Uses+Anything that is built on Axis2 list want to tell us something, they should chime in and tell us what they think and we'll take a vote. Right now it's just a few of us who are just repeating the same things over and over again without even reading what the other person is saying. thanks, dims On Thu, Oct 30, 2008 at 6:07 PM, Eran Chinthaka [EMAIL PROTECTED] wrote: On Thu, Oct 30, 2008 at 5:42 PM, Davanum Srinivas [EMAIL PROTECTED] wrote: Chinthaka, What are the problems that will be created? Please enumerate them. How is it being handled / smoothed over now and what would change specifically to make the cooperation not happen. Problems : 1. Another member will have to waste time on doing PMC work 2. We will lose the tight dependency between Axis2 and related projects like Axiom, Neethi, Sandesha, etc., There are numerous things like this that will happen. If you can point your finger to specific scenarios. We can see if we can come up with specific solutions. (Say common svn area where both committers can have access). Let me back up. What is broken in the current layout that mandates us to go for different TLPs? Also, Don't mind me, i repeat my mantra for the n-th time again. Those who are actively working on a day to day basis should be taking the decisions. What we are doing is not working and i propose we try something new to see if it will work. My point is exactly this. Why do we waste time on going to fix something which is not broken? Let's get back to work ;) -- Samisa Abeysinghe http://people.apache.org/~samisa/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://davanum.wordpress.com -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org
Re: [DISCUSS] Axis2 as TLP
. If you can point your finger to specific scenarios. We can see if we can come up with specific solutions. (Say common svn area where both committers can have access). Let me back up. What is broken in the current layout that mandates us to go for different TLPs? Also, Don't mind me, i repeat my mantra for the n-th time again. Those who are actively working on a day to day basis should be taking the decisions. What we are doing is not working and i propose we try something new to see if it will work. My point is exactly this. Why do we waste time on going to fix something which is not broken? Let's get back to work ;) -- Samisa Abeysinghe http://people.apache.org/~samisa/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Samisa Abeysinghe http://people.apache.org/~samisa/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Axis2 as TLP
Deepal jayasinghe wrote: Ajith, its the nature of people and you can not understand them. I still can not understand why you want to split. See the same argument. If we could understand people well, then perhaps we would not have been surprised when they selected George W for the second time ;) Ok why do you want to move Axiom out from Axis2 , because it has a big advantage when it is there in WS than in Axis2. Deepal, so just so I understand - are you saying you *don't* want to keep Axiom with Axis2? My concern is , Axis2 does not get what it is supposed to get. It is just stay inside something called WS. While some other Web service project acting as TLP. What exactly is axis2 to supposed to get that its not getting. Dims feels that the community is sleeping (paraphrasing) and thinks that going TLP will change that. You seem to think that there's other stuff we're spsed to get - please indicate what that is? I am sorry I do not want to rename WS into something other than Axis2. If we are going to rename then that should be into Axis2 (which include both java and c). So again, what does s/ws/axis2/g buy us? Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Axis2 as TLP
I'd really like to hear from some of the other IBM folks working on axis2/java too - Nick, Bill, etc. - what do you think? You guys have been very quiet! Are you guys off of this stuff now? Sanjiva. Davanum Srinivas wrote: Folks, There was a WS PMC thread which has not yet shown up here So, WDYT? Could we spin off Axis2 and related projects into a separate TLP? Pros / Cons / Thoughts welcome. thanks, dims -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Axis2 as TLP
If you want to have a conversation about this topic then you should be ready to explain your statements. You have made bold statements about how things have gone down hill but yet you have no explanation except some attempt at a smart-ass response. Doesn't quite work. Sanjiva. Davanum Srinivas wrote: Thanks for the deep insight and pointing out my double standards. -- dims On Sat, Nov 1, 2008 at 1:25 PM, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: Um, didn't the umbrella grow to this size under your watch?? I'm not opposed to a new TLP, but I don't understand on what basis you're claiming we are now just a shell of what we used to be. Sanjiva. Davanum Srinivas wrote: related note - i once upon a time used to hold ws up as the best model of working in open source. It's a tragic pity that we are now just a shell of what we used to be. my 2 cents. YMMV. -- dims On Fri, Oct 31, 2008 at 6:11 AM, Davanum Srinivas [EMAIL PROTECTED] wrote: Samisa, You have hit the nail on the head. People are who they are. Right now the umbrella is so vast that everyone is able to hide behind others. There is no accountability. When there is a smaller group of active people, There will be better accountability to each other and to the board and to our end users. There are tactics that we can employ for example, we should make a new single release including all projects including XmlSchema, Rampart and Sandesha with Axis2. But still make extra releases of say Sandesha2 as necessary as well separately for Sandesha. You will ask, why can't we do this today and i'll say that these kind of tactics work better with a TLP like focus. thanks, dims On Fri, Oct 31, 2008 at 4:28 AM, Samisa Abeysinghe [EMAIL PROTECTED] wrote: Davanum Srinivas wrote: Eran, Clearly you did not read my previous emails. *PLEASE* read them and then we can continue. For example, I said 1. The proposal was to split Axis2+Anything that Axis2 Uses+Anything that is built on Axis2 into a separate TLP. Also, i said this before, but repeat it again, The current status quo sucks. What we have is not working. - Really bad web sites - Really bad status of JIRA issues - Really bad track record of making releases periodically - There are many disjoint islands - The set of projects mentioned above is totally disjoint from other projects in WS PMC. How can a TLP solve all these? If people are who they are now, even after making Axis2 a TLP, the bad websites and bad release cycles will remain. On the other hand, if we cannot sync the releases of Axis2's sub projects, then irrespective of Axis2 being a TLP, it would turn out to be a useless project. Because one of Axis2's key strenghts is the set of sub projects it has. So IMHO, what is more important is to solve the above problems. However, I doubt if TLP would be a solution for that. Samisa... What we have is broken, We are not the only ones in this situation, this has happened before at Apache with XML and Jakarta PMC's. Please go and look at the history and how the projects are faring now after becoming logical/smaller footprint PMCs. Please go ask them or ask the board@ or ask members if you don't believe, let's learn from their experiences. *IF* people who are on the current projects that are not in the Axis2+Anything that Axis2 Uses+Anything that is built on Axis2 list want to tell us something, they should chime in and tell us what they think and we'll take a vote. Right now it's just a few of us who are just repeating the same things over and over again without even reading what the other person is saying. thanks, dims On Thu, Oct 30, 2008 at 6:07 PM, Eran Chinthaka [EMAIL PROTECTED] wrote: On Thu, Oct 30, 2008 at 5:42 PM, Davanum Srinivas [EMAIL PROTECTED] wrote: Chinthaka, What are the problems that will be created? Please enumerate them. How is it being handled / smoothed over now and what would change specifically to make the cooperation not happen. Problems : 1. Another member will have to waste time on doing PMC work 2. We will lose the tight dependency between Axis2 and related projects like Axiom, Neethi, Sandesha, etc., There are numerous things like this that will happen. If you can point your finger to specific scenarios. We can see if we can come up with specific solutions. (Say common svn area where both committers can have access). Let me back up. What is broken in the current layout that mandates us to go for different TLPs? Also, Don't mind me, i repeat my mantra for the n-th time again. Those who are actively working on a day to day basis should be taking the decisions. What we are doing is not working and i propose we try something new to see if it will work. My point is exactly this. Why do we waste time on going to fix something which is not broken? Let's get back to work ;) -- Samisa Abeysinghe http://people.apache.org/~samisa/ - To unsubscribe, e-mail: [EMAIL
Re: [DISCUSS] Axis2 as TLP
Of course Deepal but there are bunch of folks from IBM who were very active and who are also deeply involved with Axis2. Sanjiva. Deepal jayasinghe wrote: I'd really like to hear from some of the other IBM folks working on axis2/java too - Nick, Bill, etc. - what do you think? You guys have been very quiet! Are you guys off of this stuff now? Well then it should not only be IBM , there are other folks from other companies and individual working on Axis2, And other thing is Bill was so quiet for a long time :-) . Deepal Sanjiva. Davanum Srinivas wrote: Folks, There was a WS PMC thread which has not yet shown up here So, WDYT? Could we spin off Axis2 and related projects into a separate TLP? Pros / Cons / Thoughts welcome. thanks, dims - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Axis2 as TLP
Jeez, there's a conspiracy behind every statement eh? As I just replied to Deepal, I brought it up because there were a bunch of IBM folks who used to work on Axis2 who were active who also are stakeholders. However, the invitation was not limited to IBM folks - my apologies if such implication was apparent. So, what about other folks - this conversation has been limited to a few people so far and it'll be great to get more voices heard. Sanjiva. Davanum Srinivas wrote: Hmm...why are u bringing up someone's employer? thanks, dims On Sat, Nov 1, 2008 at 3:02 PM, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: I'd really like to hear from some of the other IBM folks working on axis2/java too - Nick, Bill, etc. - what do you think? You guys have been very quiet! Are you guys off of this stuff now? Sanjiva. Davanum Srinivas wrote: Folks, There was a WS PMC thread which has not yet shown up here So, WDYT? Could we spin off Axis2 and related projects into a separate TLP? Pros / Cons / Thoughts welcome. thanks, dims -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple deployers in axis2.xml
Glen Daniels wrote: Hi Jarek, Deepal: Jarek Gawor wrote: Deepal, I think you misunderstood. The code assumes there is one deploeyer per extension. See DeploymentEngine.getDeployerForExtension(). That should either be: Deployer getDeployerForExtension(String directory, String extension) or ListDeployer getDeployerForExtension(String extension) The former, IMO. One extension per directory. +1. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
supporting multiple message receivers for a given operation
This is an issue Keith and I discussed (a while ago) and I don't think I saw it on the list .. I just remembered it hence the sudden email (no particular urgency on it; it just came up). It is possible that a single POJO (for example) can offer both a RESTful interface and a normal SOAP interface. In fact, that can happen by having both JAX-RS and JAX-WS annotations on the same pojo. We currently can't handle that because the message receiver is associated with the AxisOperation and not BindingOperation. IMO that was a mistake .. the detail of how you take the message and construct the data is really binding dependent and should've been on binding operation in the first place. (Well we didn't have binding ops in the first place .. so that's the reason they never went there.) So what we talked about was to introduce the ability to set the MR on the binding operation but to keep the ability to set it on the operation itself. That allows us to be totally backwards compatible but it solve the problem for wanting both a RESTful and a WS-* binding for the same operation for example. Thoughts? Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: supporting multiple message receivers for a given operation
Deepal, the REST deserialization requires one to know the binding to know where to pull stuff from (query params, payload etc.). See WSDL 2.0 HTTP binding to understand how that works. So that has to happen post-dispatch. Sanjiva. Deepal jayasinghe wrote: It is possible that a single POJO (for example) can offer both a RESTful interface and a normal SOAP interface. In fact, that can happen by having both JAX-RS and JAX-WS annotations on the same pojo. Well even without having those annotation we can expose a POJO as a SOAP and REST. I mean REST and SOAP just the wire format , internally what happen is everything get converted into SOAP and at the end POJO class receive a SOAP message. We currently can't handle that because the message receiver is associated with the AxisOperation and not BindingOperation. IMO that was a mistake .. Well no , because BindingOperation introduced after the AxisOperation :) . So what we talked about was to introduce the ability to set the MR on the binding operation but to keep the ability to set it on the operation itself. That allows us to be totally backwards compatible but it solve the problem for wanting both a RESTful and a WS-* binding for the same operation for example. I can not still understand why we need new MR , because at the core what we use is SOAP not anything else , and at the end I mean at the Transport sender level we serialize that to REST or SOAP. Which is done by Message formatters. -Deepal Thoughts? Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: supporting multiple message receivers for a given operation
Dude, the details of such mapping is dependent on the actual service at hand. Again, see WSDL 2.0 HTTP binding (which you know). How do you propose handling that before the service is determined? Yes, we can do it in a handler that runs post-dispatch. And the difference between that and the MR is ?? Sanjiva. Glen Daniels wrote: The job of the MessageReceiver is to take a normalized message (i.e. something that looks like SOAP) and do some valid work with it - so this might mean mapping to a Java method and databinding, or calling out to a piece of hardware, or handing the contents of the body to a cached instance of a particular class. It's the job of the earlier parts of the system - the transport code, the Builder, etc - to map the real wire message to the normalized form. If we're using the MessageReceiver to do things like pull data from query parameters, then I put forth that we've designed that system incorrectly, and should fix it. Some earlier chunk of code should do this. Thanks, --Glen Sanjiva Weerawarana wrote: Deepal, the REST deserialization requires one to know the binding to know where to pull stuff from (query params, payload etc.). See WSDL 2.0 HTTP binding to understand how that works. So that has to happen post-dispatch. Sanjiva. Deepal jayasinghe wrote: It is possible that a single POJO (for example) can offer both a RESTful interface and a normal SOAP interface. In fact, that can happen by having both JAX-RS and JAX-WS annotations on the same pojo. Well even without having those annotation we can expose a POJO as a SOAP and REST. I mean REST and SOAP just the wire format , internally what happen is everything get converted into SOAP and at the end POJO class receive a SOAP message. We currently can't handle that because the message receiver is associated with the AxisOperation and not BindingOperation. IMO that was a mistake .. Well no , because BindingOperation introduced after the AxisOperation :) . So what we talked about was to introduce the ability to set the MR on the binding operation but to keep the ability to set it on the operation itself. That allows us to be totally backwards compatible but it solve the problem for wanting both a RESTful and a WS-* binding for the same operation for example. I can not still understand why we need new MR , because at the core what we use is SOAP not anything else , and at the end I mean at the Transport sender level we serialize that to REST or SOAP. Which is done by Message formatters. -Deepal Thoughts? Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Axis2 as TLP
Jeez I wasn't casting a vote - I expressed my opinion and then made it clear using the Apache terminology for expressing positions. Lighten up dude. Sanjiva. Davanum Srinivas wrote: Folks, this is *NOT* a VOTE thread. Please refrain from casting ballots thanks, dims On Tue, Oct 28, 2008 at 1:46 AM, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: I'm -1 because the Axis2 project is not just axis2- its a collection of enabling pieces (axiom, neethi at least) and a bunch of up stream components (rampart, sandesha2, kandula2, wss4j etc.). So its really the web services project with an entire ws-* framework being covered by that. Calling the whole thing axis2 is not right as its not just about axis2. I would like to clearly identify components within the ws project that are retired or finished. These include (from what I know) scout, wsif, axis1, jaxme, kandula1, and sandesha1. However, as Nadra's message shows, there are parts of the axis1 family still alive and kicking. There are other projects that I think do not use axis1 or axis2 - for example juddi xmlrpc - that I think could go TLP on their own to reduce the size of ws. So I'm -1. However, Glen, what was the motivation for originating that thread? Is there something broken that needs to be fixed? IIRC Dims was always against splitting when he was PMC chair and I'd like to hear the reason for and against by both Glen and Dims too. Sanjiva. Davanum Srinivas wrote: Folks, There was a WS PMC thread which has not yet shown up here So, WDYT? Could we spin off Axis2 and related projects into a separate TLP? Pros / Cons / Thoughts welcome. thanks, dims -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Axis2 as TLP
Deepal jayasinghe wrote: Personally, I'd really like to get all of us committed, willing and able to contribute in a much more coordinated fashion then we are today. We don't hang out on IRC, no weekly chats, not much forward looking discussions, not much enthusiasm or cooperation anymore from looking at the mailing lists. I am trying to see if we can jumpstart that as well with this proposal. Well part of the reason behind that is everyone is busy with their day to day work , for example when we start Axis2 we were fully focus on Axis2 . So it was so easy for us to do all those , but now we work on Axis2 and answer the mail when we get some free time. Anyway I agree that there are some improvements that we need to do. Also the other reason IMO is that axis2 is mostly done .. I have no objection at all to someone starting an axis3 or doing a lot of changes to axis2, but I personally don't have major problems that I see need to be fixed in axis2. Yes there are tons of JIRAs and lots of small issues, but those don't warrant / motivate the types of weekly chats and architectural conversations that we had in the early days. IMO the kernel of a SOAP stack is mostly a solved problem now. I think even CXF is seeing that .. and you don't see people writing new soap stacks any more! Again, if someone has a cool idea for a radical innovation what would drive yet another order of magnitude improvement (or there abouts) then I'm all ears for it. I personally haven't seen the light on how to improve the core of Axis2 CXF any more at this point. That absolutely could change tomorrow, next week, next month or next year but not today, at least for me. I'm not talking about incremental changes but rather radical innovation - the type of thing that will grab people and get their creative juices flowing. IMO a lot of the work that's interesting is now going on around Axis2, not in the core of it. Example, writing new deployers that plug in more stuff, writing cool transports etc. etc. - those all hang around axis2 but that doesn't make axis2 itself really improve. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Axis2 as TLP
How does becoming a TLP change the status quo for getting things done? Sanjiva. Davanum Srinivas wrote: No one is asking that everyone needs to get excited at the proposal. If people are interested, let it move forward. If no one is interested, it will just drop dead. If people take this forward, they will decide what to do next when the TLP is formed, no one will be forced to sign up for work or need to get excited unnecessarily. In other words, Status Quo sucks! let's try something. If it works that's fine. If it doesn't there will be just another TLP. Hey we get one more guy to become a VP :) thanks, dims On Tue, Oct 28, 2008 at 1:10 PM, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: Deepal jayasinghe wrote: Personally, I'd really like to get all of us committed, willing and able to contribute in a much more coordinated fashion then we are today. We don't hang out on IRC, no weekly chats, not much forward looking discussions, not much enthusiasm or cooperation anymore from looking at the mailing lists. I am trying to see if we can jumpstart that as well with this proposal. Well part of the reason behind that is everyone is busy with their day to day work , for example when we start Axis2 we were fully focus on Axis2 . So it was so easy for us to do all those , but now we work on Axis2 and answer the mail when we get some free time. Anyway I agree that there are some improvements that we need to do. Also the other reason IMO is that axis2 is mostly done .. I have no objection at all to someone starting an axis3 or doing a lot of changes to axis2, but I personally don't have major problems that I see need to be fixed in axis2. Yes there are tons of JIRAs and lots of small issues, but those don't warrant / motivate the types of weekly chats and architectural conversations that we had in the early days. IMO the kernel of a SOAP stack is mostly a solved problem now. I think even CXF is seeing that .. and you don't see people writing new soap stacks any more! Again, if someone has a cool idea for a radical innovation what would drive yet another order of magnitude improvement (or there abouts) then I'm all ears for it. I personally haven't seen the light on how to improve the core of Axis2 CXF any more at this point. That absolutely could change tomorrow, next week, next month or next year but not today, at least for me. I'm not talking about incremental changes but rather radical innovation - the type of thing that will grab people and get their creative juices flowing. IMO a lot of the work that's interesting is now going on around Axis2, not in the core of it. Example, writing new deployers that plug in more stuff, writing cool transports etc. etc. - those all hang around axis2 but that doesn't make axis2 itself really improve. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Axis2 as TLP
Glen, so if you agree that its a TLP with Axis2 + up stream and downstream projects then why not push the other stuff from ws into their own TLPs? If we want to consider a new name for the ws project that's an option too but that's a different issue isn't it? Sanjiva. Glen Daniels wrote: Hi Sanjiva: Sanjiva Weerawarana wrote: Also the other reason IMO is that axis2 is mostly done .. I have no objection at all to someone starting an axis3 or doing a lot of changes to axis2, but I personally don't have major problems that I see need to be fixed in axis2. Yes there are tons of JIRAs and lots of small issues, but those don't warrant / motivate the types of weekly chats and architectural conversations that we had in the early days. HTTPD has been around a lot longer than the WS project. Despite its bakedness, people routinely fix bugs, usability issues, submit patches, etc. The development community is often around on IRC. In short, it's an active and functional community around a live codebase. I think Axis2 is, honestly, far from done. And a bunch of the 515(!) JIRAs as of right now are real problems with either functionality or usability. We're not seeing these getting picked off on any kind of regular basis, so regardless of the TLP decision I think it's clear that the team as a whole needs to pay a little more attention to the project, and get that sense of active and functional community back. IMO a lot of the work that's interesting is now going on around Axis2, not in the core of it. Example, writing new deployers that plug in more stuff, writing cool transports etc. etc. - those all hang around axis2 but that doesn't make axis2 itself really improve. Two things here - first, I think that those kinds of things DO make Axis2 itself improve, because they often stretch the boundaries in ways that demonstrate blind spots or problems in the core (example - async transports and the core threading (or lack thereof) model). Second, you're exactly right that there is a lot of work going on around Axis2, which is why making it a TLP with Rampart, Sandesha, etc., as subprojects seems to make a lot of sense. Thanks, --Glen --Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Axis2 as TLP
So Glen, if we're talking about a new TLP what are the proposed components under it? What will remain in the ws TLP because they don't have enough ammo to be a TLP? Sanjiva. Glen Daniels wrote: Hi dims, all: Davanum Srinivas wrote: For a few years now, there is a growing consensus at the board level that a small focused PMC that directly reports to the board is better than a huge umbrella PMCs. two umbrella PMC's have already made transitions including XML and Jakarta. +1. As PMC chair, I've definitely had a challenging time keeping up with everything going on in all the subprojects, and from a purely practical point of view, the board reports each quarter are pretty darn long. One reason is that they have found that a small focused PMC/committer set takes better care of the code, web site, releases, legal issues and basic oversight of day to day workings of a PMC better than a huge umbrella PMC. For example, personally i think Synapse has thrived after it left the fold. +1 Take a look at our web site(s), take a look at our release schedules(s) - for all projects, take a look at our bug tracker(s). Does anyone see that we are doing an excellent job? Point taken. We need to gather momentum, going TLP is an excellent way to do that. A small focused team that is working on a single goal of getting a good set of Axis2 related projects going is i think the right way to go. I think the Axis2 eco system will do better when we go TLP. I agree. Personally, I'd really like to get all of us committed, willing and able to contribute in a much more coordinated fashion then we are today. We don't hang out on IRC, no weekly chats, not much forward looking discussions, not much enthusiasm or cooperation anymore from looking at the mailing lists. I am trying to see if we can jumpstart that as well with this proposal. Well said! This was an excellent note, dims. I also very much believe that an Axis2 TLP will help get us focused on moving forward. fwiw, Juddi and xmlrpc do not have sufficient people on board to go TLP as of this moment. Yes, we should try harder to get more people involved there or we end up moth-balling them. Well, yeah - they're certainly not TLP-capable, but as they're already subprojects I'd like to put off the decision to moth-ball them for a while as long as there is at least one person dedicated to working on them... hence the proposal to keep these guys under WS. Thanks, --Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Axis2 as TLP
I'm -1 because the Axis2 project is not just axis2- its a collection of enabling pieces (axiom, neethi at least) and a bunch of up stream components (rampart, sandesha2, kandula2, wss4j etc.). So its really the web services project with an entire ws-* framework being covered by that. Calling the whole thing axis2 is not right as its not just about axis2. I would like to clearly identify components within the ws project that are retired or finished. These include (from what I know) scout, wsif, axis1, jaxme, kandula1, and sandesha1. However, as Nadra's message shows, there are parts of the axis1 family still alive and kicking. There are other projects that I think do not use axis1 or axis2 - for example juddi xmlrpc - that I think could go TLP on their own to reduce the size of ws. So I'm -1. However, Glen, what was the motivation for originating that thread? Is there something broken that needs to be fixed? IIRC Dims was always against splitting when he was PMC chair and I'd like to hear the reason for and against by both Glen and Dims too. Sanjiva. Davanum Srinivas wrote: Folks, There was a WS PMC thread which has not yet shown up here So, WDYT? Could we spin off Axis2 and related projects into a separate TLP? Pros / Cons / Thoughts welcome. thanks, dims -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST support on Axis2/C
It could be that the XML parser is looking at the accept charset and trying to change the character set and failing? It shouldn't of course (as this is a content negotiation thing it should just do what it knows). Anyway, hopefully this helps .. Sanjiva. Samisa Abeysinghe wrote: Uthaiyashankar wrote: Hi, I think the problem is browser dependent. When I checked with Firefox, it is failing. But works, when I checked with IE. FireFox sends a header Accept-Charset which causes problem. When I capture the message using tcpmon, and then remove that header, it works. We have to debug and find the problem. It fails on Accept-Charset ... strange... Samisa... Regards, Shankar. Gupta, Shivam wrote: Ok.. I get your point. I apologize for misunderstanding the issue. However, I do have enabled the GET method in my service before firing the request from the browser. For your reference, I have attached the services.xml and am also listing the various URI that I entered in the browser to access the service : http://172.31.24.198:1983/axis2/services/get_echo/Hello http://172.31.24.198:1983/axis2/services/echo/get_echo/Hello http://172.31.24.198:1983/axis2/services/get_echo/Hello; http://172.31.24.198:1983/axis2/services/echo/get_echo/Hello; Please guide me. Shivam. -Original Message- From: Samisa Abeysinghe [mailto:[EMAIL PROTECTED] Sent: Friday, October 17, 2008 9:59 AM To: Apache AXIS C Developers List Subject: Re: REST support on Axis2/C Gupta, Shivam wrote: Hi, Yes I have. Infact, if I haven't enabled it, even the echo_rest client should not have worked. echo_rest uses a POST, and your browser request uses a GET. Samisa... Please help. Thanks, Shivam. -Original Message- From: Samisa Abeysinghe [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2008 7:48 PM To: Apache AXIS C Developers List Subject: Re: REST support on Axis2/C Have you enabled GET method in your service? Samisa... Gupta, Shivam wrote: Hello, I have been trying to invoke the echo web service supplied with Axis2/C using REST based invocation. When I try using the echo_rest client, the service responds just fine. However, when I try to invoke the echo web sercvice using a web browser, I get no response from the Axis. The browser just hangs in a wait state. Could you tell me what could possibly be going wrong? I entered the following query styring in the URL window of the browser: http://172.31.24.18:2106/axis2c/services/echo/echoString?text='hello' http://172.31.24.18:2106/axis2c/services/echo/echoString?text=%27hel l o%27 It would be great if you could help me here. Thanks, Shivam. - - -- No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.8.0/1724 - Release Date: 10/14/2008 2:02 AM -- Samisa Abeysinghe Director, Engineering; WSO2 Inc. http://www.wso2.com/ - The Open Source SOA Company - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.8.0/1726 - Release Date: 10/15/2008 7:29 AM -- Samisa Abeysinghe Director, Engineering; WSO2 Inc. http://www.wso2.com/ - The Open Source SOA Company - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.8.1/1733 - Release Date: 10/19/2008 6:02 PM -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: [Axis2] Moving all the transports into a common modules
+1 - given that these are set in axis2.xml I see no issue in changing the package names. Sanjiva. Paul Fremantle wrote: Apologies for reposting I forgot to reply-all. Paul -- Forwarded message -- From: Paul Fremantle [EMAIL PROTECTED] Date: Thu, Oct 2, 2008 at 2:41 PM Subject: Re: [Axis2] Moving all the transports into a common modules To: [EMAIL PROTECTED] Deepal There is a problem :) The JMS transport is completely different. So we can't take the Synapse JMS transport and give it the name of the different (old) Axis2 transport. The second problem is that (suppose) Synapse would like to do a release before the next Axis2 release. Because the old transports are still in the Axis2 core, we cannot ship the updated Commons Transports. Also, the transports are only named in axis2.xml right? I don't think there are backwards compatibility issues. We have never (afaik) maintained full compatibility for axis2.xml. I think we should rename these. Paul On Mon, Sep 22, 2008 at 1:53 PM, Deepal jayasinghe [EMAIL PROTECTED] wrote: Amila Suriarachchi wrote: hi, the package name that commons transport module use is org.apache.axis2 I think it should be org.apache.ws.commons No Amila , we can not do that for transport like HTTP , that would be a major change and backward compatibility killer. So lets keep the package name as it is. [Please do not change the package names :) ] -Deepal WDYT? thanks, Amila. On Mon, Sep 22, 2008 at 12:03 PM, Amila Suriarachchi [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Sun, Sep 21, 2008 at 2:59 PM, Andreas Veithen [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Deepal, Before we can move anything from Synapse to the new commons module, we need to decide which transports we move (all or only a subset) and based on that, we need to make sure that all the people involved in the maintenance of these transports have commit access to the new module. As a starting point I'll put the synapse SMTP transport to commons transport and try to test with Axis2. thanks, Amila. In the meantime, I also have two comments/questions related to the code that is already in the new module: 1. Wouldn't it be a good idea to take advantage of the move from Axis2 to ws-commons to use a more conventional directory structure, e.g. src/main/java instead of src? 2. I don't see any documentation in the new module. There must have been some docs for the transports in Axis2. When will this be moved? Regards, Andreas On 21 sept. 08, at 03:13, Deepal jayasinghe wrote: Hi all, Few months back we all agreed to move all commons transports (from Axis2 and Synapse) to a common module. As the first step of that I have moved all the Axis2 to transport into a common module in ws-commons [1]. In addition to that we have setup nightly builds from that modules. So now its time for Synapse dev to move their transports into that module :) [1] : https://svn.apache.org/repos/asf/webservices/commons/trunk/modules/transport Thank you! Deepal -- Thank you! http://blogs.deepal.org - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/ -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/ -- Thank you! http://blogs.deepal.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail
Re: [VOTE] Andreas Veithen as a WS committer
+1! Asankha C. Perera wrote: Folks Andreas Veithen has been an active committer of the Apache Synapse project from February, and has helped improve, add and enhance the transport implementations that grew under the Synapse project for Apache Axis2. Now as we move some of these transports into WS-Commons, I propose that Andreas be granted Karma in the WS project to help continue this work asankha -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [AXIS2] Should JSON messages be considered as REST?
s for the fault flow too, so that it'll use the corresponding formatter/builder in case of a fault.. OK good - we're all in agreement that not doing the faults was a mistake! Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Content Negotiation (Was Re: [AXIS2] Should JSON messages be considered as REST?)
Ah excellent! So does the message formatter get selected based on the accept headers sent (which refer to media types IIRC)? That's perfect. Chinthaka, the idea of bringing content negotiation into SOAP is interesting but IMO not that useful. While content neg is a favorite RESTafarian feature, the reality is that it hasn't really proved its mettle. I wanted us to do it because its a simple thing for us to do with our architecture and because for pure HTTP there are some usecases, esp. with pure HTTP scenarios where the browser is involved. I can't find the comment right now but Larry Messinter, who proposed content neg into the http spec, later regretted it. IIRC the quote and ref is in my ws-* vs. rest presentation somewhere! Sanjiva. keith chapman wrote: Hi Chinthaka, I did implement content-negotiation in Axis2 some time ago [1]. It was implemented using the Accept header. It can be enabled by adding the following parameter to the axis2.xml parameter name="httpContentNegotiation"true/parameter Thanks, Keith. [1] http://markmail.org/message/mbnxc2ysq2bt7v6a On Mon, Sep 22, 2008 at 8:53 PM, Eran Chinthaka [EMAIL PROTECTED] wrote: Since our discussion is over on Faults and JSON messages, let's discuss one of the good points raised by Dr. Sanjiva. I think content negotiation is a cool feature to have, especially when we are using HTTP. This is one of the features I personally definitely like to have. Are you guys thinking of using cont-neg on transport level, or will it be sth like we did for service group context using a SOAP header? If we check how browsers and Web servers do content negotiation, it is mainly using Accept, Accept-Encoding, Accept-Charset, etc., header. I think this can be easily done within Axis2 too. But the problem with this approach is that, this cont-neg should happen for every message. If we find out a way to do this for a conversation, it'd great. Basically a client must ask from a server, the content types it can support and client can then use those types to send messages later. This also can be tricky as sometimes Web services server itself might restrict some content types only for some operations. Even if one of us won't be doing this, this is sth a new comer can easily tackle if we list this on tasks to be done list (if we have one ;) ) What do you all think? -- With Mettha, Eran Chinthaka Health is the greatest gift; contentment is the greatest wealth; trusting is the best relationship; nirvana is the highest joy. - Dhammapada -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [AXIS2] Should JSON messages be considered as REST?
Sorry Chinthaka can't blame me ;-) .. no way that I told you WSDL 2.0
can only deal with XML :).
Sanjiva.
Eran Chinthaka wrote:
In the spec, it says, if we have our own custom
content-type, then it should be compatible with application/xml (http://www.w3.org/TR/wsdl20-adjuncts/#_http_ser_xml).
I don't think that thats the case. The WSDL 2.0 spec specifies three
serializations, they are application/x-www-form-urlencoded, application/xml and multipart/form-data. And the area in the spec you
have referred to is talking about these three. I the section you have
referred to the spec says,
"[Definition: The serialization
format is a media type token ("type/subtype"). It
identifies rules to serialize the payload in an HTTP message. Its
value is defined by the following rules. The HTTP request
serialization format MUST be in the media type range specified by
the {http input
serialization} property. "
So it basically supports any media-Type. Its just that the working
group took the trouble in describing the three serializations above in
detail.
Ok agreed. I was wrong in interpreting it. I guess some one who was
working in the HTTP binding can clarify this (IIRC, Dr. Sanjiva was
there :D)
Thanks for the clarification, Keith.
Thanks,
Chinthaka
--
Sanjiva Weerawarana, Ph.D.
Founder Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [AXIS2] Should JSON messages be considered as REST?
I think the whole question of "REST" is not the point here. Axis2's underlying data model is a SOAP Infoset. As a result, any type of data that runs thru the system has to be represented as a SOAP Infoset. That's not a big deal - essentially it means we need to create two extra Axiom nodes (a s:Envelope node and an s:Body node) and stick a child in there that contains whatever the real data is. Using our nice MTOM integration and the deferred pull architecture of Axiom, we can do that efficiently using OMSourceElement nodes as we've proven multiple times now. That's for incoming stuff - we take whatever that comes in and represent it within a SOAP Infoset. When we have an outgoing message, the inverse question is relevant - if the message is not going out as SOAP, then someone needs to take the real message payload (which is in the child node of the s:Body node) and only write the content of that. That's basically what MessageFormatters do. [So calling all of that "REST" is totally wrong and an abuse of what "REST" means. I think we need to refactor that code and get rid of any references to REST as this has nothing to do with REST. Yes I know the history and how it got called that but now its time to fix it.] Now to get back to your original point - I think the idea of having message formatters applied to faults too (which you proposed in a later mail) is the right answer. Faults are just messages too and its clearly an oversight that we didn't apply the design orthogonally there too. Time to fix it. Sanjiva. keith chapman wrote: Let me describe the problem in more detail. As of now Axis2 enables you to plug in various message types by registering them in the axis2.xml. Some of these message types will be SOAP based (like text/xml and application/soap+xml) while others are not. And in the latter case when a exception occurs somewhere in the pipe we do not want to throw the fault as a SOAP message. What we do in the REST case of of now is that we take the fault element in the SOAP body (If not found the first child of the SOAP body) and write that out as the fault. As of now Axis2 treats a few message Types as REST specifically application/xml, multipart/form-data and application/x-www-form-urlencoded. But with the pluggable message types in place this may not work that well. Assume that someone want to to plug in application/foo and that this message type is REST how are we gonna handle it? Should we consider adding a attribute to the messageBuilders/messageFormatters section to indicate weather its REST or not? Thanks, Keith. On Sat, Sep 20, 2008 at 3:22 AM, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: +1 .. but I'm a bit confused. I assume by "REST" you meant that the response has media type text/xml instead of application/soap+xml, right? If we think about it that way, can we get rid of the "isDoingREST" flag?? (I've hated that from day 1 and haven't had a chance to really dig thru it and figure out how to get rid of. Maybe this is an opportunity to get it right ..) Sanjiva. keith chapman wrote: Any input on this would be appreciated. Thanks, Keith. On Thu, Sep 4, 2008 at 8:40 AM, keith chapman [EMAIL PROTECTED] wrote: Hi devs, This idea came up because of the following scenario. Currently the logic for creating a AxisFault for a fault received lies in org.apache.axis2.util.Utils.java (lines 507 - 530). This works perfectly when the received fault is SOAP or REST. But it does not work as expected when the response is JSON ( rather a exception is thrown saying "The MessageContext does not have an associated SOAPFault."). The reason is the logic we use to build the AxisFault. If the fault message is not a SOAP message we check for the flag messageContext.isDoingREST() and get the first element of the SOAPBody as the fault message. When the fault message is JSON its neither SOAP and the messageContext.isDoingREST() returns false. Should we consider JSON messages as REST messages? I believe so. WDYT? Thanks, Keith. -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ --
Re: [AXIS2] Should JSON messages be considered as REST?
+1 .. but I'm a bit confused. I assume by "REST" you meant that the response has media type text/xml instead of application/soap+xml, right? If we think about it that way, can we get rid of the "isDoingREST" flag?? (I've hated that from day 1 and haven't had a chance to really dig thru it and figure out how to get rid of. Maybe this is an opportunity to get it right ..) Sanjiva. keith chapman wrote: Any input on this would be appreciated. Thanks, Keith. On Thu, Sep 4, 2008 at 8:40 AM, keith chapman [EMAIL PROTECTED] wrote: Hi devs, This idea came up because of the following scenario. Currently the logic for creating a AxisFault for a fault received lies in org.apache.axis2.util.Utils.java (lines 507 - 530). This works perfectly when the received fault is SOAP or REST. But it does not work as expected when the response is JSON ( rather a exception is thrown saying "The MessageContext does not have an associated SOAPFault."). The reason is the logic we use to build the AxisFault. If the fault message is not a SOAP message we check for the flag messageContext.isDoingREST() and get the first element of the SOAPBody as the fault message. When the fault message is JSON its neither SOAP and the messageContext.isDoingREST() returns false. Should we consider JSON messages as REST messages? I believe so. WDYT? Thanks, Keith. -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AXIS2 1.4: Client problems when changing form plain XML to SOAP-style messages: Disallowed element found in envelope:Envelope..
is:
public OMElement getPoints(OMElement inElem) throws SQLException,
IOException {
//inElem.build();
final MessageContext outContext=new MessageContext();
final SOAPEnvelope env=theSOAPFactory.getDefaultEnvelope();
final OMNamespace ns=theSOAPFactory.createOMNamespace(namespace,
getPointsResponse);
// we can now disreagard this inElem
final OMElement
flexMobilePointListElem=theSOAPFactory.createOMElement(
getPointsResponse,ns);
final ResultSet points;
final OMNamespace
pointNS=theSOAPFactory.createOMNamespace(namespace, FlexMobilePoint);
try {
points=getPointsFromDB();
if (points!=null) {
//final ResultSet filteredPoints =
writeEntryForNullValues(flexMobilePointListElem,
//points);
int i=0;
while (points.next()) {
final OMElement thisPoint =
buildFlexMobilepointFromSQL(points,pointNS);
//
thisPoint.addAttribute(soapFac.createOMAttribute(position, omNs, new
Long(i).toString()));
i++;
flexMobilePointListElem.addChild(thisPoint);
}
}
flexMobilePointListElem.build();
env.getBody().addChild(flexMobilePointListElem);
outContext.setEnvelope(env);
return env;
// return toAxisElement(wrapInSoapMSG(flexMobilePointListElem));
//return flexMobilePointListElem;
} catch (final ClassNotFoundException e) {
throw new SQLException(Unable to instatiate the SQL
backend: ,e);
//} catch (final SOAPException soapExc) {
//throw new RuntimeException(There was a
SOAPException:,soapExc);
//} catch (final XMLStreamException e) {
//throw new RuntimeException(There was a
XMLStreamException:,e);
//} catch (final ParserConfigurationException e) {
//throw new RuntimeException(There was a
ParseConfigurationException,e);
}
//catch (final FactoryConfigurationError e) {
//throw new RuntimeException(There was a
FactoryConfigurationException,e);
//}
catch (final OMException e) {
throw new RuntimeException(There was a unspecified
Exception,e);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Sanjiva Weerawarana, Ph.D.
Founder Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][Proposal] Move JMS / Async NIO transports out of Axis2 into Synapse
Asankha C. Perera wrote: Deepal As we discussed in the mailing list I created a prototype deployer (TransportDeployer) for transport deployment.. This is cool and boy you are fast :-) !.. Very cool indeed! Axis2 transports also needs a few more changes though.. and I'm re-thinking about the suggestion made by Sanjiva on moving the core API's out of Axis2 as well.. for example, TransportSender needs a start() method, just like the Listeners, as there can be Senders that requires initialization, and explicit start/stop behavior.. Else, at ConfigurationContext creation itself, the Senders start through the init() call which is not what you want.. also if you stop a transport, you cannot restart.. Another example is with the AxisServlet listener which must handle its stop() call etc, and refuse to handle any messages through Axis2 if the transport was shutdown.. else if a service does not implement the ServiceLifeCycle interface, it may still be accessible over the servlet transport even if the lister manager was shutdown etc.. So I think its better to *first* work on moving out the current transports from Axis2 as proposed, so that we can focus and review the transports and the design again, and make any improvements for issues we see. I do not think this is something we could try to do in a hurry.. we should also focus on good API documentation that will help anyone write a new transport easily etc +1. Let's get the current code moved and restructured and *then* start improving it. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [Proposal] WS-Commons transports project
Ah I forgot about the commons-dev aspect. Maybe its easier to avoid yet another list and use commons-dev .. so I'm fine with what you proposed. Sanjiva. Glen Daniels wrote: Hey Sanjiva: Sanjiva Weerawarana wrote: Glen, why ws/commons/transports? Why not ws/transports?? We've moved away from commons in Axiom etc. - that is, packages no longer say that and IMO that's better. The package names don't matter - I'm talking about organization of the project. Axiom, Neethi, etc. are all under webservices/commons in SVN, and they all use commons-dev for discussion. Since commons is a place to put common components that are used across the WS universe (and elsewhere), that made sense to me as a place to put transports. I'm fine with webservices/transports too, although I still think they would actually make the most sense as separately buildable/deployable artifacts under axis2/. If we're all in agreement for webservices/transports, let's do that, and I guess we should kick off [EMAIL PROTECTED] too. --Glen Deepal jayasinghe wrote: Glen Daniels wrote: [ Please refer to this thread for context : http://markmail.org/message/lg3giq5kj74gjnxb ] OK, let me make a concrete proposal here. I hereby propose that we kick off a ws-commons transports project. As with the other ws-commons projects, this would have its own release schedule. All current ws-all committers would have commit rights, and we'd add anyone from the Synapse team that would like to work on transports, and isn't already a committer. +1 for making a commons project for Axis2 transports. This will help both Axis2 and other dependent projects such as Synapse. Each transport within ws-commons Transports would be a separate releasable artifact, i.e. org.apache.ws.transports.jms etc... and each such transport would be releasable on its own with an appropriate VOTE of the ws-commons committers. Personally I would like to download all the transport as a single jar , but I do not mind releasing them separately as long as you give single jar as well. Thank you! Deepal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][Proposal] Move JMS / Async NIO transports out of Axis2 into Synapse
Michele, its about making it easy to maintain and use. We gain nothing by putting them into the same jar file. With respect to your comment earlier saying So you end up increasing the limits for files/sockets on you linux box HUH?? What are you talking about?? This has nothing to do with limits for files or sockets! Sanjiva. Michele Mazzucco wrote: Glen, I disagree, each transport is composed by just a few classes, not megs of code. I can't see really see where the problem is if you put JMS and SMTP transports into the same jar file. Michele On 23 Apr 2008, at 13:09, Glen Daniels wrote: Hi Michele: Michele Mazzucco wrote: - First of all, Asankha, why synapse-transports.jar?? That makes no sense to me- so if you have a bug in the VFS code you'll rev all the stuff? Why? There should be one jar per transport. Java provides packages for that. There's no need to have tons of jars! There are well-understood tradeoffs between complication and flexibility here. Having one transport per jar means, as Sanjiva notes, that you can independently version and release transports. It also means that I don't need to carry around megs of code which is useless to me when I want just one transport. Forcing JMS and SMTP into one transports.jar seems just as weird to me as putting Axiom and Neethi into one policy-and-xml.jar. :) Now, that said - I do think it's fine if you want to make a deployment *option* that's just one jar. I think Axis2 might also want to be making available an axis2-complete.jar (name not important) that has Axis2 plus all WS dependencies in it for ease of use in embedding scenarios. But I think these are convenience options that users can pick, as opposed to the right way to do things in the mainstream. Thanks, --Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][Proposal] Move JMS / Async NIO transports out of Axis2 into Synapse
Michele Mazzucco wrote: Yes, since every jar file adds 1 to the number of files opened by a process (your JVM is a process itself). The default limit for files + socket that can be opened by a process is 1024. Um in toy systems maybe .. but this a tunable kernel parameter and in any real server the number is much larger. This is hardly an excuse for not properly modularizing code packaging. Plus the file doesn't remain open- once the files are loaded in the FD is reused. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [Proposal] WS-Commons transports project
Glen, why ws/commons/transports? Why not ws/transports?? We've moved away from commons in Axiom etc. - that is, packages no longer say that and IMO that's better. Sanjiva. Deepal jayasinghe wrote: Glen Daniels wrote: [ Please refer to this thread for context : http://markmail.org/message/lg3giq5kj74gjnxb ] OK, let me make a concrete proposal here. I hereby propose that we kick off a ws-commons transports project. As with the other ws-commons projects, this would have its own release schedule. All current ws-all committers would have commit rights, and we'd add anyone from the Synapse team that would like to work on transports, and isn't already a committer. +1 for making a commons project for Axis2 transports. This will help both Axis2 and other dependent projects such as Synapse. Each transport within ws-commons Transports would be a separate releasable artifact, i.e. org.apache.ws.transports.jms etc... and each such transport would be releasable on its own with an appropriate VOTE of the ws-commons committers. Personally I would like to download all the transport as a single jar , but I do not mind releasing them separately as long as you give single jar as well. Thank you! Deepal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][Proposal] Move JMS / Async NIO transports out of Axis2 into Synapse
Wow, miss this list for a few days and boom! Here's my attempt at a summary position: - First of all, Asankha, why synapse-transports.jar?? That makes no sense to me- so if you have a bug in the VFS code you'll rev all the stuff? Why? There should be one jar per transport. Yes, lots of jar files but so what? - Asankha, you seem to think that the only place transports that Synapse finds interesting are being done is in Synapse. What about CORBA? The code is in Axis2 (and Eranga is still waiting for his commit rights to come thru to finish that off) and of course supporting CORBA is very interesting for Synapse. So you're not solving whatever problem you perceive by saying keep everything I care about in Synapse. - I agree with that Axis2 transports should NOT be in the kernel jar. Can we finally agree (forget the history please) to that now and create new maven modules for each transport and put each one into its own jar? This is for the transports that are (or will remain) in ws/axis2. - Given that these transports are usable by anyone building on Axis2 (and not just Synapse) and that they depend on Axis2 APIs, I believe they should be in a project which releases those transports against given versions of Axis2 APIs. My preference is that it should be in ws/commons/transports or a new sub-project called ws/transports. Asankha, what problem do you see in that approach? I think everyone would +1 you being the RM for this project ;-). - Asankha if you're going to stick a strong -1 in the middle of this debate then I'm going to stick a strong -1 against the status quo of Synapse maintaining its own transports. I think the rules now call for us to keep talking ;-) .. - How about the following compromise position: - we create a new ws/transports project and move http and any other transports out of axis2 into that. - we kill the old NHTTP and JMS tranports in axis2 - move JMS and SMTP out of synapse into the new project - as a general rule, if Axis2 and Synapse are both going to ship the transport in their default distros, then we move the code here - for other transports we strongly encourage people to put them here to enable easier wider use (e.g., WSO2 Mashup Server would inherit all the transports in Axis2 but not those from Synapse .. I think Asankha would want the new and improved SMTP transport to be in the WSO2 Mashup Server too ;-)). Of course we can't enforce that but I would hope that we should be able to come to a sufficient community understanding between the Synapse and WS TLPs to make that work. - this project publishes each transport as a separate jar with a naming convention that identifies the axis2 (API) version it corresponds to. of course trunk will correspond to trunk as always - I'm ok with going one step further and even moving the Axis2 transport APIs into the project and for Axis2 to just use them. This is like what Axis2 does with Axiom for example. The result is that the transports become an enabler for Axis2 (and Synapse and more) just as much as Axiom or XMLSchema is. The benefit is that they're no longer Axis2's transports or Synapse's transports but rather those common transports. (I have to admit I didn't look at the code to evaluate the realisticness of this bit of the proposal - but the rest of it stands on its own anyway.) Sanjiva. Asankha C. Perera wrote: Davanum Srinivas wrote: Agreed that this is definitely a problem. Next question, is do you want do this in Synapse Commons (do you have one?) or WS Commons? We already have all the transports in a separate Maven module, which is published to Apache snapshots and Central repo.. As far as I am concerned, there is no requirement to re-package this code and ship it elsewhere.. If a user wants a particular transport as a separate module, they can ask for an enhancement for it, and we will do our best to facilitate it. So if we are going to have a vote on this 'topic' on axis-dev, I am +1 to deleting the stale copies of the transports currently in Axis2. But if you are going to call for a vote on [EMAIL PROTECTED] to remove critical code developed by the Synapse community from our SVN, to make it easier for axis2 users to get these transports, I'm definitely -1 asankha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Getting axis2 operation from the service
Amila, wsaw:Action is of type anyURI. So I think there is a bug here- the
string SubmitOrder should get resolved as a URI relative to the baseURI
of the document.
If we fix that then these won't match and the right thing will happen.
Sanjiva.
Amila Suriarachchi wrote:
hi all,
Have a look at the code in the AxisService getOperation method.
(AxisService.java 1613)
if (axisOperation == null) {
axisOperation = (AxisOperation) operationsAliasesMap
.get(operationName.getLocalPart());
if (LoggingControl.debugLoggingAllowed log.isDebugEnabled())
log.debug(Operations aliases map: +
operationsAliasesMap);
}
Here it tries to get the operation assuming operation name local part is
equals to the action.
Although this is a common practise it is not a spec requirement.
As a result of this code it fails codegen for wsdls like this.
wsdl:portType name=OrderProcessorService
wsdl:operation name=SubmitOrderTransactedQueue
wsdl:input wsaw:Action=SubmitOrder
message=tns:OrderProcessorService_SubmitOrderTransactedQueue_InputMessage/
/wsdl:operation
wsdl:operation name=SubmitOrder
wsdl:input wsaw:Action=SubmitOrderOnePhase
message=tns:OrderProcessorService_SubmitOrder_InputMessage/
/wsdl:operation
wsdl:operation name=isOnline
wsdl:input wsaw:Action=isOnline
message=tns:OrderProcessorService_isOnline_InputMessage/
/wsdl:operation
/wsdl:portType
since the Action SubmitOrder is defined in first operation it returns a
wrong action when checking
for second operation. It should return null.
Shall we remove this part?
thanks,
Amila.
--
Amila Suriarachchi,
WSO2 Inc.
--
Sanjiva Weerawarana, Ph.D.
Founder Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Getting axis2 operation from the service
David Illsley wrote: Regardless of whether I think this is a bug, there are plenty of people who think it's a feature we simply cannot remove the existing runtime behaviour that the operation name is always a valid action. David, that position is unacceptable if that hack algorithm we have breaks valid WSDLs right? In this case however, I do think that the problem is because we're not properly URIfying @wsaw:Action properly. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[axis2] VOTE: Erange Jayasundera for committer
Eranga is the one who implemented the CORBA module and is working to improve it as well. He did the original work as part of his MSc project and is currently working in the ICT Agency in Sri Lanka. I'm of course +1 for Eranga becoming a committer. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Moving Axis2 code base into JDK 1.5
I agree moving 1.5 is not merely a change of JDK but a change of APIs. However, realistically, I imagine that'll be an incremental process- i.e., no one will sit and go thru and introduce generics wherever possible .. rather we'll start using 1.5 features without restriction when the need arises. So I'm not convinced the JDK 1.5 switch requires any major signalling ... like calling it Axis2 2.0. Given that we're close to the wire on 1.4, we'll have to leave that alone for now. Can we agree that that'll be the last native 1.4 release? We can of course use retotranslator for future releases. Sanjiva. Ajith Ranabahu wrote: Hi, As far as the vote goes I would say 0- From the suggestions we have the ones I can agree is to release 1.4 (the next one) with JDK 1.4 and focus on setting the new JDK version for the next release (I have posted the XmlSchema release candidate which complies to JDK 1.4 a few hours ago and had to expilicitly remove some of the 1.5 features that leaked in :)) I.m definitely +1 for JDK 1.5 (and quite frankly believe it is time for us to move on) AFAICS what it means to move to JDK 1.5 is not merely to compile the source in JDK 1.5. Rather it involves use of generics and changing of backward compatibility libraries (annogen, threadpooling) and may be a redesign of the API's to take advantage of the Java 5 features. All this leads to bugs :) - bugs that may not exist in the code right now. So in my mind properly moving to JDK 1.5 is not a trivial task and need to be taken seriously. One other trivial thing I can think of is the coinciding of release numbers with JDK versions (1.4 - 1.4 , 1.5 - 1.5 ) :)) Ajith -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Moving Axis2 code base into JDK 1.5
Are there critical things that you see in Axis2 1.4 which would be necessary for JDK 1.4 users? If so I can agree with you otherwise I think its time to move on from JDK 1.4 .. Sanjiva. David Illsley wrote: Um, right now I'd be tempted to push out an Axis2 1.4 with JDK 1.4 support soon for existing JDK 1.4 users, then move to 5 for Axis2 1.5. David On Tue, Feb 26, 2008 at 10:35 PM, Amila Suriarachchi [EMAIL PROTECTED] wrote: +1to move to jdk 1.5. thanks, Amila. On Wed, Feb 27, 2008 at 10:01 AM, Lawrence Mandel [EMAIL PROTECTED] wrote: +1 Woden has also discussed a move to Java 5 and the dev team was in favour of this move. As Axis2 depends on Woden we cannot consider this move unless Axis2 also moves. Lawrence Deepal Jayasinghe [EMAIL PROTECTED] 02/26/2008 11:15 PM Please respond to axis-dev@ws.apache.org To axis-dev@ws.apache.org axis-dev@ws.apache.org, [EMAIL PROTECTED] [EMAIL PROTECTED] cc Subject [Axis2] Moving Axis2 code base into JDK 1.5 Hi all , As you might remember few months back Glen asked the list about moving to JDK 1.5 and I think we got very positive feedback. So I thought of asking again and change the code to work with JDK 1.5 . The main reason behind sending this mail is due the dependency we have for annogen. As I can see that project is dead one and there is no development happening so I do not think it is a good idea to depend on such a project. In the meantime we have few issues with annogen as well ,first inner class problem (I have locally fixed that both in Axis2 and Annogen will commit soon) , second is the final class problem. I request a release from annogen after the changes that Dims did , but we did not get any reply so far. We all know that we get better annotation support from JDK 1.5 so if we move to JDK 1.5 we can get rid of the annogen dependency and we can just use JDK for annotation processing. Other problem is generic support , if we move to JDK 1.5 we can have generic support in our POJOs. In addition to POJO we can get better concurrent support in JDK 1.5 as well. So if we move to JDK 1.5 we can get better support , and I do not think any advantage of staying in 1.4 . If some user want to use Axis2 in JDK 1.4 they can happily use Axis2 1.3 , which is very stable version and working fine in 1.4 and 1.5. If any user or developers have any concern on moving to JDK 1.5 please come forward and reply to this mail that will be very helpful for all of us. Here is my +1 for moving to JDK 1.5 to and release Axis2 1.4 in JDK 1.5 Thank you, Deepal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Amila Suriarachchi, WSO2 Inc. -- David Illsley - IBM Web Services Development -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[axis2] [Fwd: URI/IRI Templates]
FYI. Maybe useful for WSDL 2.0 http binding stuff .. I know we have our
own now but just wanted to make sure we're aware of this.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---BeginMessage---
I've added support for URI/IRI Templates to the IRI module based on
http://bitworking.org/projects/URI-Templates/draft-gregorio-uritemplate-02.html
Examples:
Template instances are immutable and threadsafe.
private static final Template template =
new
Template(http://example.org{-opt|/~|user}{user}{-opt|/-/|categories}{-listjoin|/|categories}{-opt|?|foo,bar}{-join||foo,bar});
Templates can be resolved from a Map, from Java object getters and
fields, or from a custom Context implementation
MapString,Object map = new HashMap();
map.put(user,james);
map.put(categories, new String[] {a,b,c});
map.put(foo, abc);
map.put(bar, xyz);
System.out.println(template.expand(map));
http://example.org/~james/-/a/b/c?foo=abcbar=xyz
The Java object approach will examine the public fields and getters of
passed in java objects.
public static class MyObject {
public String user = james;
public List getCategories() {
ListString list =
new ArrayListString();
list.add(a);
list.add(b);
list.add(c);
return list;
}
public Foo[] getFoo() {
return new Foo[] {
new Foo(),
new Foo()
};
}
public String getBar() {
return xyz;
}
}
private static class Foo {
public String toString() { return abcæ; }
}
MyObject myObject = new MyObject();
System.out.println(template.expand(myObject,true));
http://example.org/~james/-/a/b/c?foo=abc%C3%A6foo=abc%C3%A6bar=xyz
The custom Context implementation approach allows template variables to
be resolved dynamically,
CachingContext context = new CachingContext() {
private static final long serialVersionUID = 4896250661828139020L;
protected T T resolveActual(String var) {
if (var.equals(user)) return (T)james;
else if (var.equals(categories))
return (T)new String[] {a,b,c};
else if (var.equals(foo)) return (T)abc;
else if (var.equals(bar)) return (T)xyz;
else return null;
}
public IteratorString iterator() {
return Arrays.asList(
new String[] {user,categories,foo,bar}).iterator();
}
};
System.out.println(template.expand(context));
http://example.org/~james/-/a/b/c?foo=abcbar=xyz
The implementation will continue to evolve as the URI Template spec evolves.
- James
---End Message---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [AXIS2] Adding security phase to OutFaultFlow
I think we should allow the Rampart folks this judgement call- if they want it then we should do it (we''ve spent like 30 messages about adding a string to a config file; a *little* whacky IMO). What it allows is for one to drop Rampart to a stock Axis2. Yes, a nightly on nightly. Yes we're planning a release in February- but our track record of timely Axis2 releases isn't great. So let's just do it and get on with doing the right thing. On dynamic phases- Glen it'll be great if you could post some use cases and requirements and design before writing up a bunch of code. See David's mail too. Sanjiva. Glen Daniels wrote: Honestly, there isn't really much point to doing this change now. Rampart already has an axis2.xml in their test repository - and people using Axis2 and/or Rampart already have axis2.xmls in *their* repositories. So simply changing the Rampart one will get it working there... and explaining how to change your own will get users working. The only thing we'd gain by doing the change in Axis2 itself now is the ability for people picking up new SNAPSHOT releases to have Rampart work with the default Axis2 SNAPSHOTs. I'm planning to get the dynamic phase stuff happening over the holidays, and the next actual release of A2 will have that functionality built in. So if we want to spend time putting in a change which will just get taken out, that's fine, but seems a little silly especially since the axis2.xmls that already exist in Rampart and elsewhere are STILL going to need to be changed anyway. Make sense? --Glen Sanjiva Weerawarana wrote: +1. I suggest we do this change and when we finish the dynamic module thing come back and clean up the module.xml files and remove any extra phases. That's always been the way we've done stuff .. we're not holding forward progress while looking to some major change. Sanjiva. Amila Suriarachchi wrote: On Dec 18, 2007 11:49 AM, Glen Daniels [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Amila: Amila Suriarachchi wrote: So it seems like you could get the same effect for now by explaining in the Rampart documentation how to change the axis2.xml in the correct way - or even including a sample. Make sense? (note I'm not saying -1, just trying to understand) yes I got your point. But rampart trunk depends on the Axis2-SNAPSHOT and they need to change the axis2 default xml in order to pass the test cases. When we do a change locally we need to commit it to the repository soon. These test cases can not be committed util we change the axis2 default xml. Hm - really? Why can't Rampart simply use a custom axis2.xml with the new Phase at the root of their test repository? Then they have to update their axis2.xml when ever Axis2 does. But at least that is how(using axis2 kernal default xml) they have done it. Idea of keeping a axis2-SNAPSHOT dependency is to keep the rampart trunk sync with axis2 trunk. But I can not understand why you ask rampart people to do a big change while they could it with a simple axis2 change. There is no harm to axis2 with this change isn't it? thanks, Amila. --Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -- Amila Suriarachchi, WSO2 Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Dispatch order
The issue here is whether SUPPORT_SINGLE_OP takes priority or the sequence
of deployers do. That is, right now it appears that SSO is tested at the
end of the dispatch phase .. which just makes sure that if that property
has been set it overrides everything else.
Service dispatch also happens in the dispatch phase often ... so I think
the code is right.
Sanjiva.
David Illsley wrote:
Um, presumably it should go after the RequestURIBasedDispatcher so you
don't have to redo the service dispatch?
David
On Dec 19, 2007 3:27 PM, Amila Suriarachchi [EMAIL PROTECTED] wrote:
On Dec 19, 2007 8:32 PM, David Illsley [EMAIL PROTECTED] wrote:
So what's the plan? Where are you going to move the code to?
yes. What I thought was to get this code to a separate dispatcher and set
this dispatcher as the first
dispatcher in the Transport phase.
Amila
David
On Dec 19, 2007 7:11 AM, Amila Suriarachchi [EMAIL PROTECTED]
wrote:
On Dec 19, 2007 10:00 AM, Amila Suriarachchi
[EMAIL PROTECTED]
wrote:
hi all,
1. Here is a code segment found in the
org.apache.axis2.engine.DispatchPhase
checkPostConditions method.
if (operation == null
JavaUtils.isTrue(service.getParameterValue
(AxisService.SUPPORT_SINGLE_OP))) {
Iterator ops = service.getOperations();
// If there's exactly one, that's the one we want. If
there's
more, forget it.
if (ops.hasNext ()) {
operation = (AxisOperation)ops.next();
if (ops.hasNext()) {
operation = null;
}
}
msgContext.setAxisOperation (operation);
}
What it basically doing is that dispatch the operation if the
AxisService.SUPPORT_SINGLE_OP parameter is set and
there is only one operation on it.
Isn't this dispatcher supposed to run just after service being
dispatched?
i.e as the first dispatcher of the Tranport phase.
Think about the scenario where this operation is engaged security. in
this
case it should dispatched before the security.
I think any dispatcher which is possible to run before the security
should
run before it.
I found this security hole and I the only option to fix it to add a
handler
as the last phase to dispatch
to check whether the security is applied or not.
https://issues.apache.org/jira/browse/RAMPART-127
So we need to move this before security definitely.
2. RequestURIBasedDispatcher and SOAPActionBasedDispatcher are both in
Transport and Dispatch phases.
Is there any reason for this? or is it an obsolete code to keep this
in
Dispatch phase?
Shall I do the above changes?
thanks,
Amila.
--
Amila Suriarachchi,
WSO2 Inc.
--
Amila Suriarachchi,
WSO2 Inc.
--
David Illsley - IBM Web Services Development
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Amila Suriarachchi,
WSO2 Inc.
--
Sanjiva Weerawarana, Ph.D.
Founder Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [AXIS2] Adding security phase to OutFaultFlow
+1. I suggest we do this change and when we finish the dynamic module thing come back and clean up the module.xml files and remove any extra phases. That's always been the way we've done stuff .. we're not holding forward progress while looking to some major change. Sanjiva. Amila Suriarachchi wrote: On Dec 18, 2007 11:49 AM, Glen Daniels [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Amila: Amila Suriarachchi wrote: So it seems like you could get the same effect for now by explaining in the Rampart documentation how to change the axis2.xml in the correct way - or even including a sample. Make sense? (note I'm not saying -1, just trying to understand) yes I got your point. But rampart trunk depends on the Axis2-SNAPSHOT and they need to change the axis2 default xml in order to pass the test cases. When we do a change locally we need to commit it to the repository soon. These test cases can not be committed util we change the axis2 default xml. Hm - really? Why can't Rampart simply use a custom axis2.xml with the new Phase at the root of their test repository? Then they have to update their axis2.xml when ever Axis2 does. But at least that is how(using axis2 kernal default xml) they have done it. Idea of keeping a axis2-SNAPSHOT dependency is to keep the rampart trunk sync with axis2 trunk. But I can not understand why you ask rampart people to do a big change while they could it with a simple axis2 change. There is no harm to axis2 with this change isn't it? thanks, Amila. --Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -- Amila Suriarachchi, WSO2 Inc. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [AXIS2] Adding security phase to OutFaultFlow
+1. While dynamic self-configuring phases is a cool and all-powerful, it seems overkill for most of what we need. What we need is to make sure that Axis2 can do security out of the box- that's absolutely critical. CXF for example bundles security and RM with the core platform - if we make this thing so painful to make security to work people will simply walk. Let's not get carried away with abstraction and lose touch with reality. Making dynamic phases work just for the axis2 base platform only is silly IMO. If outside users are asking for it let's do it- but we first have other high(er) priority items to finish IMO. Sanjiva. Deepal Jayasinghe wrote: Deepal, I disagree. It complicates the chain and our configuration files for no benefit to a large number of users. I do not agree with you in this , because just we have configurations in axis2.xml people will not get confused and did not make the system complicated. If they do not want they can remove that. The lack of dynamic phases also requires people to repetitively edit axis2.xml files when adding something we haven't yet added a phase for I agree that , but deploying module is not that frequent thing like deploying services. So this is just one time cost. it's really naff from a user perspective, especially given all the huffing and puffing in articles about how great our module architecture is. Yes I agree with you in this , but there should be a limitation of the flexibility we should give. Can I ask if there's something specific you're worried about wrt dynamic phases, or if it's just something you don't see a need for? I dont see need for it , I know it is very cool and I really like to have. However at the this point Axis2 is kind of stable and people are using that for production so we should not break the backward compatibility. Second as I said earlier mail as well none of the user asked for this. We have lot more to fix and improve in Axis2 (I mean high priority items that users have requested) , so we need to focus on that. My general rule is , if something working fine and no body complain about that , then we do not need to change that. :) -Deepal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improvement to mail transport from a Synapse use case
Saminda Abeyruwan wrote: (2). Allowing CC or BCC is complex, as it is tightly coupled with the MEP. - Simple solution would be to introduce a parameter or property to include CC or BCC list and simply exclude them from the MEP semantics. Thus, it would be same as broadcasting to a set of users. - If MEP is introduced to CC or BCC, we could expect some complex message exchange patterns. Would it be feasible or scalable to integrate CC or BCC to a MEP. You're over-reacting to what having Cc or Bcc means. Those are simply what the message sender wants to do - they have nothing to do with the MEP. There's no assumption of them replying - if they do, well, tough. That's not a new problem- if u take ANY message with WS-Addr headers and send it to multiple places (like what the split mediator does in Synapse) then you could have that problem. We just need to enable the user to set these properties and understand the expected behavior of those receiving copies of messages. That's not unlike in email .. if you bcc someone and they reply, then ouch. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improvement to mail transport from a Synapse use case
David Illsley wrote: Tough on who? AFAIK the first response will be processed by Axis2 regardless of which original recipient received it. Yes. Its user error for messing it up .. Basically, I don't think we should be limiting the ability for someone to use the underlying transport fully. The alternative is that Synapse will write their own version of mail-send which will allow a Cc .. that makes no sense at all to me. Yuk, surely if a mediation does that it has some responsibility for aggregating the responses? Also this sounds like a case where Notification/Eventing might be most appropriate? Even Eventing doesn't solve this problem - if I get a message I have to know whether I'm going to reply or not .. whether it was delivered via eventing or not doesn't make a difference. Yes, but in user e-mail there's some expectation that the user looks at how they were addressed to, perhaps because of the message content. We don't (AFAIK) have any notion of that in SOAP/email, or do we? No, there isn't ... agreed. However, its again up to the people setting this up to make sure that wrong stuff doesn't happen. Example: Lots of people have bots sign up to mailing lists (for archiving, for spammers to easily gather data etc. etc.). Obviously they receive all the mail but they never reply. If they reply (and then reply to the reply etc.) a loop will occur. Has happened before .. I used to run email for Sri Lanka and back in those days (early 90s) it was common for badly configured mail servers to start bouncing bounces and keep doing that. I used to have to manually notice this and fix it. Mail software is smarter now. Of course we could add a none ReplyTo to the copies which would have the desired effect, but if we do that, it really calls for multiple messages to be sent at the ServiceClient level rather than relying on smtp cc, bcc. Yeah that's an option but that's a different thing. I think the underlying principle at question is whether a transport impl should restrict any of the properties of the transport .. my opinion is basically that we should not. Obviously we should configure it correctly for the default config, but if an advanced user wants to set a bcc or whatever, we shouldn't get in the way. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 architecture documentation
Wesley, there are two ways to impl JSR 311 - just implement it straight on a servlet and have your own deployment model etc.. The other option is to allow an Axis2 user to deploy a POJO with those annotations- then the impl would depend on how Axis2 deals with REST but users would not see anything different from the POJO+JSR311. That's the model that's interesting for Axis2 to support and is what is supported by other WS-* implementations too. What it will allow is to write one POJO and make it offer both a RESTful interface and a SOAP interface. Oh yeah, that infuriates RESTafarians. Sanjiva. Wesley Mesquita wrote: Do you mean to say that since REST request data is sent in pure XML that we can use well-known existing XML technologies like STAX, SAX, and DOM?' I thought this. I agree that is a good initiative, make the WS development free of underlying technologies, but this means changing the model that we work (and think) today, is there any plan to make this popular? That is, how to make developers adopt RESTful model? On Dec 10, 2007 1:08 AM, Dustin Amrhein [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: You are correct in saying that REST web services are a departure from the SOAP-centric web services that the Apache Axis architecture is built to support. What exactly do you mean by lower-level APIs in place of SOAP though? Do you mean to say that since REST request data is sent in pure XML that we can use well-known existing XML technologies like STAX, SAX, and DOM? Or, are you referring to something else? Thanks, Dustin Amrhein Web Services Development, IBM */Wesley Mesquita [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]/* wrote: So, as I understood, REST goes in a different way from that we are dealing with WS today in the sense that we wouldn´t deppend of technologies like SOAP, and explore Java lower level APIs, is this right? On Dec 7, 2007 12:45 PM, Nicholas L Gallardo [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Wesley, Here's the page for the JSR. http://jcp.org/en/jsr/detail?id=311 As Sanjiva mentioned, the JSR is still in progress so there's potential for what you see today to be different by the time the spec is complete. Take a look at the JSR and I guess just start asking questions. Before diving into that JSR though, I would Google around and become familiar with the concepts of REST. That will help put some of the JSR lingo into context. Another thing you could do to get familiar with the concept is to build a REST service/client using the existing Axis2 APIs. Please ask away if you have any questions. Cheers, -Nick Inactive hide details for Wesley Mesquita [EMAIL PROTECTED] Wesley Mesquita [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] *Wesley Mesquita [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]* 12/06/2007 03:25 PM Please respond to axis-dev@ws.apache.org mailto:axis-dev@ws.apache.org To axis-dev@ws.apache.org mailto:axis-dev@ws.apache.org cc Subject Re: Axis2 architecture documentation Interesting, I know a little bit of the concepts of REST arch, but I´ve never worked with JSR. If you can tell me where to start I can learn more about this, and I´ll try to do something in the implementation. Wesley. On Dec 6, 2007 11:54 AM, Sanjiva Weerawarana [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: How about implementing JSR-311? That's the new REST annotations JSR. Its a new feature, so its relatively easy .. but u'll need the deployment architecture etc.. But its a fun project and will be useful when done (the JSR is still in progress). Sanjiva. Wesley Mesquita wrote: On Dec 6, 2007 7:31 AM, David Illsley [EMAIL PROTECTED] _ mailto:[EMAIL PROTECTED] mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Wesley, It's great to have someone interested in working on Axis2. Welcome. I guess I'd suggest you try
Re: Axis2 architecture documentation
Nicholas L Gallardo wrote: So does this mean you're changing your mind on JSR technologies? :) :-). I'm not against all of it .. just the heavy useless ones ;-). I am +1 for 183 and 211 ... annotations are useful and no one wants to keep learning new ones. One key thing to keep in mind still is that this stuff only applies to Java language .. not any JVM based language. As a result, any such features need to be kept away from the core - if we plug this beast into Groovy or Rhino (as we've done in the WSO2 Mashup Server) then none of these JSRs come into play at all. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 architecture documentation
How about implementing JSR-311? That's the new REST annotations JSR. Its a new feature, so its relatively easy .. but u'll need the deployment architecture etc.. But its a fun project and will be useful when done (the JSR is still in progress). Sanjiva. Wesley Mesquita wrote: On Dec 6, 2007 7:31 AM, David Illsley [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Wesley, It's great to have someone interested in working on Axis2. Welcome. I guess I'd suggest you try to 'scratch an itch'. You mention you've been using Axis2 is there anything that was really hard to do? Well, there some people in my lab (www.lis.ic.unicamp.br http://www.lis.ic.unicamp.br) that have used Axis 1.x in their works (I know tree MScs that used) , and during the last three months I have tried to use Axis2 to create Web Services from java classes. I explored better the POJO method and I did some scripts to automatize the aar packages creation. My objective is allow the users to send their classes and the service will be deployed in Axis2 environment. I made just simple tests, but I think I´ll have problems in more complex classes (using serialization, attachments and so on). But my new challenge is to find an easy way to create clients. I am exploring the methods described in the site but I still didn´t find this easy way. Anything you found you couldn't do that you'd like to be able to do? David I was able (in a hard or simple way) to do everything I needed. But, like in almost all projects I´ll find something that I can´t do, but, for now, I don´t know what is this :). thanks, Wesley On Dec 5, 2007 2:56 PM, Wesley Mesquita [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I have never worked in a Open Source project, so I don't know how to get really involved just seeing the JIRA's messages, because I still dont have a good view of the areas that these problems are associated. For now, I would like to get simple tasks (in a small or big thing). The best would be if someone can tell me an area to get involved (study documentation, code) and so, try to develop sometrhing. Thanks. On Dec 5, 2007 12:44 PM, Sanjiva Weerawarana [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Wesley Mesquita wrote: Hi everybody, I am using Axis2 in my scientific work at University, and will be very useful the documentation about the architecture of Axis2. I looked at the site and I didn't found anything like this. PS : Are there any open problems in axis2 or anything specific that you (the developers team) want people to work ? I am looking for a open source project to work in my summer vacation. There's a bunch of areas that you can work on! Do you feel like doing a small thing or something large? The best way is to look at some of the pending JIRAs and tackle some small things to get started on. If you want specific big ideas holler again and I'll come up with some items! Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -- Wesley Mesquita LIS/IC - UNICAMP [skype: wesley.mesquita] -- David Illsley - IBM Web Services Development - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -- Wesley Mesquita LIS/IC - UNICAMP [skype: wesley.mesquita] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 architecture documentation
Wesley Mesquita wrote: Hi everybody, I am using Axis2 in my scientific work at University, and will be very useful the documentation about the architecture of Axis2. I looked at the site and I didn't found anything like this. PS : Are there any open problems in axis2 or anything specific that you (the developers team) want people to work ? I am looking for a open source project to work in my summer vacation. There's a bunch of areas that you can work on! Do you feel like doing a small thing or something large? The best way is to look at some of the pending JIRAs and tackle some small things to get started on. If you want specific big ideas holler again and I'll come up with some items! Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Steps for Project Yoko : A Proposal
Axis2 also has CORBA bindings using Yoko. I wonder whether there's a way to look at unifying that work to avoid whatever duplication possible. Axis2 has a pretty complete binding and we're working on client bindings as well (currently the work is mostly to Web service enable a CORBA object). DanK- are you the one who's working on that part in CXF? Can you point us to the binding code? The Axis2 work is here: http://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/corba/ Sanjiva. Jim Jagielski wrote: On Nov 15, 2007, at 9:41 AM, Matt Hogstrom wrote: I believe the easiest way to proceed is to draft a proposal that we will send to both Apache Geronimo and Apache CXF. Apache CXF is still in incubation so I'm not sure if there are any specific issues with doing this while they are incubating. I'm copying the Incubator PMC for their input on this proposal to make sure we have all the i's dotted and t's crossed. ... The remainder of the modules in Yoko are part of the webservices support and are independent of the underlying ORB implementation. api -- interface classes used for the web services support. bindings -- code to implement the CORBA-Web services bindings. tools -- tools for generation WSDL and IDL for the bindings maven-plugin -- some maven plugins that can use the tools for generating binding-related build artifacts. None of the maven-plugin code is used by the ORB. There is also a distribution directory with some sample applications. One set of samples demonstrates using the core ORB, the other set is for WebServices. We recommend that the distribution directory should move to Apache CXF as the webservices examples use the orb samples to bind them as web services. Since Apache Geronimo's only use of CORBA is for exporting EJBs, these samples are not particularly valuable for Geronimo. The Yoko community did not have any committers that expressed an interest in continuing work on these bindings. As such, only the code would be moving to apache CXF. Dan Kulp and I talked a bit yesterday (at least, I *think* it was yesterday)... with my CXF Mentor hat on, I think this makes a lot of sense, not only for the CXF code and functional aspects, but also as a potential mechanism to bring in additional developers for the podling. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] WS-policy client support
And pretty darned sneaky of them to gen a wssp prefix for a private namespace. Of course its fine but still sneaky. Sanjiva. Anne Thomas Manes wrote: That's a proprietary policy assertion language. It's supported only by BEA products. Talk to BEA and convince them to add support for the standard OASIS WS-SecurityPolicy. Anne On 10/31/07, Feng Lu [EMAIL PROTECTED] wrote: Hello friends, I am wondering whether Axis2 support WS-policy client? My WSDL server is Weblogic and the WSDL has following WS-policy. I am not sure whether Axis2 will be able to handle WS-policy in such case. If it does, could anybody let me know how to implement the client side support for this? Any special handling in the stub genration? - wsp:Policy s0:Id=Auth.xml - wssp:Identity xmlns:wssp=http://www.bea.com/wls90/security/policy; - wssp:SupportedTokens - wssp:SecurityToken TokenType=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken; wssp:UsePassword Type=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText; / /wssp:SecurityToken /wssp:SupportedTokens /wssp:Identity /wsp:Policy Thanks a lot for your help! Frank __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rampart 1.2 with Axis2 1.3 final release
Have you tried with Rampart 1.3? Sanjiva. Andrew Puzankov wrote: Hi, Is there a version of Rampart that works with Axis2 1.3 final release? I saw posts in the forum that Rampart 1.2 has issues with Axis1.3 RC1 but does that issue also exist with Axis 1.3 final release? I am trying Rampart 1.2 sample01 (completed all the steps in readme.txt) and getting this error when running server for sample01: org.apache.axis2.deployment.DeploymentException: The rampart module is not valid or has not been deployed. Also if I hit the URL of the samples server: http://localhost:8080/axis2/services/ I get the following error: Faulty Services C:\tools\rampart- 1.2\samples\basic\build\service_repositories\sample01\services\sample01.aar I've tried various versions of Rampart and all report the same error with Axis2 1.3. Is there a version that works with latest Axis? Thank you, Andrew -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Proposal to chage the method signature of set/get documentation
+1 that we'd be making the keep-the-simple-case-simple rule by losing the String method. Keith, what's the harm in having two methods? That is, do both. Sanjiva. Tom Jordahl wrote: Removing String as an argument type seems like a bad idea to me for two reasons: 1. Breaking API compatibility, if it is public, is not nice. 2. If I want to put a string there (which I think you are saying goes in the documentation elements of the WSDL) you are making me create another object. Sure it’s “easy”, but it doesn’t make me like the API much. I think putting a string in this element is the 90+% use case, right? Who is putting XML in here? Is there a public WSDL that you can point to that does this? -- Tom Jordahl *From:* keith chapman [mailto:[EMAIL PROTECTED] *Sent:* Friday, October 26, 2007 8:16 AM *To:* axis-dev@ws.apache.org *Subject:* Re: [Axis2] Proposal to chage the method signature of set/get documentation +1 for changing getDocumentation to return OMNode (no deprecation, same will have to go for setDocumentation). Although this is an API method its mostly used from within for generating the WSDL. Thanks, Keith. On 10/26/07, *Glen Daniels* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Well, +1 except for the fact that you can't overload getDocumentation() and just change the return type - so there's no way to deprecate that one without adding another method like getDocumentationOM(). We could either do that and avoid breaking existing stuff, or just change getDocumentation() and accept the incompatible change. --Glen Sanjiva Weerawarana wrote: +1. keith chapman wrote: Hi Devs, Currently the method signature for det/get documentation in AxisDescriptio is as follows. public String getDocumentation(); public void setDocumentation(String documentation); As you can see it treats the documentation as a string. There are occasions where the documentation can be XML though. If the documentation is XML what we do currently is wrap it in CDATA tags. This works, but its not the best sollution. I propose deprecating the above methods and introducing the following methods which that documentation as an OMNode. public OMNode getDocumentation(); public void setDocumentation(OMNode documentation); This will enable us to set the documentation as an OMText or OMElement. If needed we can retain the old methods without deprecating them (Just leave them as a convenience method), where they will call into the new method. The above proposal is targeted at improving the wsdl served by Axis2. With what we have currently documentation which is XML is wrapped in CDATA tags in the WSDL. Thanks, Keith. -- Keith Chapman WSO2 Inc. Oxygen for Web Services Developers. http://wso2.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -- Keith Chapman WSO2 Inc. Oxygen for Web Services Developers. http://wso2.org/ -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: having the list of a remote axis2 services programmatically
You need some beans that expose the admin functionality as services so that you can control it remotely. If you look at the source for WSO2 WSAS you can see how we do it - you can either use WSAS' directly for it or just copy the bits that you care about. See: http://wso2.org/repos/wso2/trunk/wsas/java/modules/admin/src/org/wso2/wsas/admin/service/ In particular you probably want ServiceAdmin.java. If you look at the WSAS admin console you'll see how these services are used remotely. http://wso2.org/projects/wsas/java Sanjiva. EL ALAMI wrote: Hi everyone, I have been trying to use the axis2 API to have the list of a remote axis2 services , but I can’t find a way to do it. In a more specific description, I need to write a java function that takes as argument the axis2 url (or its repository or something like that) and returns the list of all the services correctly deployed on it. I think that the AxisConfiguration.getServices() method is going to be used, but of course I still need to have of the AxisConfiguration of the remote engine. Can anybody guide me through? I appreciate your help;) -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Proposal to chage the method signature of set/get documentation
+1. keith chapman wrote: Hi Devs, Currently the method signature for det/get documentation in AxisDescriptio is as follows. public String getDocumentation(); public void setDocumentation(String documentation); As you can see it treats the documentation as a string. There are occasions where the documentation can be XML though. If the documentation is XML what we do currently is wrap it in CDATA tags. This works, but its not the best sollution. I propose deprecating the above methods and introducing the following methods which that documentation as an OMNode. public OMNode getDocumentation(); public void setDocumentation(OMNode documentation); This will enable us to set the documentation as an OMText or OMElement. If needed we can retain the old methods without deprecating them (Just leave them as a convenience method), where they will call into the new method. The above proposal is targeted at improving the wsdl served by Axis2. With what we have currently documentation which is XML is wrapped in CDATA tags in the WSDL. Thanks, Keith. -- Keith Chapman WSO2 Inc. Oxygen for Web Services Developers. http://wso2.org/ -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Build break....
Its not a PMC chair thing as much as someone needs to run the scripts under their ID. I believe the script is simply to do a build and copy the file to the right place. Is there any way to make this user independent? In any case, thanks David for taking care of it. Sanjiva. David Illsley wrote: I believe they run/ran under dims's user account on ws.zones, but given his resignation, I assume they weren't kicked back off after a recent ws.zones restart. Glen, I assume this falls to you by default, but I'd be happy to look after a few scripts if you'd like? David On 24/10/2007, keith chapman [EMAIL PROTECTED] wrote: Hi, The nightly builds are missing since the 17th. Any idea how to fix that? Thanks, Keith. On 10/24/07, David Illsley [EMAIL PROTECTED] wrote: The build seems to be broken... http://ws.zones.apache.org:1/continuum/servlet/continuum/target/ProjectBuild.vm?view=ProjectBuildbuildId=3128id=61 David -- David Illsley - IBM Web Services Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman WSO2 Inc. Oxygen for Web Services Developers. http://wso2.org/ -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CORBA Question
Daniel Kulp wrote: Steve, On Friday 21 September 2007, James, Steven wrote: Not sure yet if this is the best mail group to ask this question but it's a start. I'm CCing the yoko-dev group. They have written plugins into CXF (and some idl - wsdl tooling) that allow some level of CORBA support. Using the CXF JAX-WS api's, you can expose a service as a CORBA service or use the CXF clients to talk to a CORBA service. I don't know the full details of what is and is not supported. You'd have to ask them or check their docs/website/wiki. FYI we've done that for Axis2 as well- a fully dynamic serializer/deserializer that takes Axiom and goes in and out of IIOP. The result is that we can post any CORBA object as a Web service and auto generate WSDL etc.. The code is committed but is undergoing some changes to make it work under the Axis2 client API as well - so you can point to a WSDL with a CORBA binding and have the right stuff get wired in so that you can talk to it using the ServiceClient API. (We're basically bringing all WSIF functionality under the Axis2 APIs.) Eranga Jayasundera (cc'ed) implemented this and is working now to finish the client side too with Deepal Jayasinghe (one of the main axis2 committers). An article about this implementation will be ready soon too. (Eranga did this for his MSc thesis for which I was the supervisor .. which is my connection to this.) Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (AXIS2-3233) How to enable Fast Infoset is not documented
Why? Duplicate docs are PITA to maintain. How about sticking a link somewhere? Sanjiva. Deepal jayasinghe wrote: Wouldn't that be great if we can have a document in Axis2 site as well ? -Deepal [ https://issues.apache.org/jira/browse/AXIS2-3233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537202 ] Sanjaya Karunasena commented on AXIS2-3233: --- http://wso2.org/library/2686 /Sanjaya How to enable Fast Infoset is not documented Key: AXIS2-3233 URL: https://issues.apache.org/jira/browse/AXIS2-3233 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: modules Environment: N/A Reporter: Sanjaya Karunasena Priority: Critical How to enable Fast Infoset is documented. Can some one please add the following text to the relevant area of the documentation? How to enable Fast Infoset = In the axis2.xml under the section messageFormatters add the following Message Formatter(s). !-- POX Message Formatter -- messageFormatter contentType=application/fastinfoset class=org.apache.axis2.fastinfoset.FastInfosetPOXMessageFormatter/ !-- SOAP Message Formatter -- messageFormatter contentType=application/soap+fastinfoset class=org.apache.axis2.fastinfoset.FastInfosetMessageFormatter/ Under the section messageBuilders add the following Message Builder. !-- POX Message Builder -- messageBuilder contentType=application/fastinfoset class=org.apache.axis2.fastinfoset.FastInfosetPOXBuilder/ !-- SOAP Message Builder -- messageBuilder contentType=application/soap+fastinfoset class=org.apache.axis2.fastinfoset.FastInfosetBuilder/ If you want to use SOAP set the content type of the message to application/soap+fastinfoset and if you want to use POX set the content type to of the message to application/fastinfoset. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 and WebSphere Interoperability
If you really want to have hardcoded endpoints etc. then the solution is to host those samples somewhere and have some automated execution of those against Axis2 nightly builds. Its not acceptable to commit into the ASF repo some code that is only designed to work against some WebSphere samples. (Is this an IBM question or a 3rd party who wants to do it? Sorry I don't recognize your name and you didn't use an @ibm.com email.) Sanjiva. Andrew Das wrote: Hi David, Thanks for the quick response. The samples we intend to add are specifically designed and customized for WebSphere services. I am not certain the current Axis2 samples will work. Additionally, I can foresee future changes to the WebSphere sample clients based on API/spec changes, so mucking with the Axis2 samples would not be a good idea. Finally, our endpoints will be hardcoded and we need to have enough flexibility to change those in the future. Not sure if my response helped. As I mentioned earlier, we are looking for the best way to accomplish WebSphere interoperability. Therefore I am open to new suggestions if it will help us integrate with Axis2 and satisfy our goals. Thanks. On 10/19/07, *David Illsley* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Andrew, It's not entirely clear to me what you're trying to do... are you looking to add client and service samples into the axis2 build which you can then run against WebSphere? If so, how do the existing Axis2 samples[1] match up to what you're looking for? David [1] http://svn.apache.org/viewvc/webservices/axis2/trunk/java/modules/samples/ http://svn.apache.org/viewvc/webservices/axis2/trunk/java/modules/samples/ On 19/10/2007, Andrew Das [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hello, We are looking to identify a strategy to inject basic samples into the Apache Axis2 build tree. The purpose of the samples will be to test interoperability with the WebSphere WS Feature Pack services. Additionally, we are also interested in testing Quality of services using the same samples integrated in the Axis2 source. Could you please advise on what's the best way to accomplish this? Thanks. -- Regards, Andrew Das -- David Illsley - IBM Web Services Development - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -- Regards, Andrew Das -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [AXIS2] Proposal to implement http content negotiation
+1 from me. For some further discussion on this see [1]. In particular [2] gives rationale for why its ok to give more weight to POX over SOAP 1.1. Sanjiva. [1] http://wso2.org/mailarchive/registry-dev/2007-October/thread.html#473 [2] http://wso2.org/mailarchive/registry-dev/2007-October/000540.html keith chapman wrote: Hi Devs, There have been some thought on http content negotiation. With the concept of builders and formatters we have now this could be implemented trivially. The idea is to use the Accept http header to serve the response requested by the client. While going through this though I came across a issue though. This occurs when a request is sent via a GET using a browser (Cause the browser automatically adds the Accept http header). The Accept header sent by firefox is Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5. The confusion comes in because text/xml is used for both SOAP and REST responses. I believe having http content negotiation as a feature will be a nice addition to Axis2. And I propose that we treat text/xml as a REST response in implementing this. This would mean that you cannot ask for a SOAP 1.1 response uaing http content negotiation (A SOAP 1.1 response will be went only when the request is SOAP 1.1 and there is no matching value in the Accept header). What do u think? Should we go ahead and implement this proposal? Thanks, Keith. -- Keith Chapman WSO2 Inc. Oxygen for Web Services Developers. http://wso2.org/ -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Understanding Axis2 dependencies
? Is this just used by the Axis2 runtime or is it just the standalone SOAP monitor tool? soapmonitor has two parts - the applet and this server side component. We may be able to make it optional (i.e. pack it with the war only) stax-api-1.0.1.jarXML pull parsing - I think this should be replaced in the next version with Geronimo's API as Axiom has made the change I'm not sure whether the API has changed. But this jar is only the API. tribes-6.0.10.jar ? Clustering implementation woden-1.0-incubating-M7b.jar WSDL 2.0 support wsdl4j-1.6.2.jar WSDL 1.1 support wstx-asl-3.2.1.jarXML pull parsing xbean-2.2.0.jar Looks like a competitor to OSGi - where is this used? Don't let the name fool you :) This is actually the XMLBeans core classes. There is a sepearate project called XBeans that has no relation to this. This one is only needed if one uses XMLBeans classes. xalan-2.7.0.jar XSLT - Where is this used? xercesImpl-2.8.1.jar DOM parser - Does Axis2 actually need a DOM parser? I thought everything was done with pull parsing. xml-apis-1.3.03.jar DOM parser Axis2 has some DOM based code in the code generator but the standard VM DOM impl is sufficient for that. The above jars are used primarily by the SAAJ impl which has a DOM level 3 dependency. JDK 1.4 included parser (Crimson) is DOM level 2 I believe. XmlSchema-1.3.2.jar XML schema support Thanks, Lawrence To me it seems that we can ship certain jars only for the webapp. Also we have been discussing three types of distros, minimal, standard and full which will include jars in various degrees but it seemed a bit confusing at that time for the users (this was actually done in 1.0 release). May be it is time to restart these discussions -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Python message receiver for Axis2/Java
Great! We have a Javascript (Rhino) receiver and also a BSF one .. one option is to get Jython to work thru the BSF receiver. Sanjiva. Heshan Suri wrote: Hi, I am working on writing a message receiver for Axis2/Java to support Web services, written in python. I hope to use Jython to execute the Python service. I am really grateful if someone can give some suggestions on this. Thanks in advance, -Heshan -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
