Re: [VOTE] Web Services Reorg Part 1 : Axis2 TLP
Sorry for the delay +1 indeed Aj On Mon, Nov 9, 2009 at 1:11 PM, Ruwan Linton wrote: > +1 > > Ruwan > > > On Sun, Nov 8, 2009 at 11:36 PM, Bill Nagy wrote: > >> +1 >> >> -Bill >> >> On Fri, 2009-11-06 at 09:20 -0800, Glen Daniels wrote: >> > Greetings, everyone. >> > >> > A bunch of us here at ApacheCon were talking about the Axis2 TLP idea, >> and >> > how to move this forward in the simplest and most effective way. We >> came up >> > with *exactly* the same structure that we had proposed a year ago. :) >> So, >> > having only altered the page in order to remove a step (the promotion of >> > WS-Commons sub-sub-projects to WS subprojects - this isn't really >> necessary >> > as we can still decide what to do about each sub-sub-project >> individually >> > later), I'd like to bring the following proposal up for a VOTE of the >> Web >> > Services PMC. If this passes, I plan to submit this resolution to the >> board >> > as soon as possible. >> > >> > http://wiki.apache.org/ws/FrontPage/Proposals/Axis2TLPProposal >> > >> > Note that I added just the first few people in the current PMC roster as >> > examples. I also nominated myself as the Axis2 chair for now - if >> anyone >> > else would like to volunteer to do this, please let me know. Eventually >> I'd >> > like to drop one or the other PMC chair role, but for now I'm OK doing >> both. >> > >> > So if you would, please: >> > >> > 1) VOTE >> > 2) Add yourself to the list of project members on the wiki page if you >> are an >> > existing PMC member and would like to be on the new Axis2 PMC >> > >> > Here is my +1 for this proposal. >> > >> > Thanks, >> > --Glen >> >> > > > -- > Ruwan Linton > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb > > WSO2 Inc.; http://wso2.org > email: ru...@wso2.com; cell: +94 77 341 3097 > blog: http://ruwansblog.blogspot.com > -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein
Re: AW: [jira] Commented: (AXIS2-3300) minOccurs="0" always generated by Java2WSDL - problems with .NET client generation
NET WebService Studio > >> 2.0, the result is the following: > >> > - all the generated C# methods input parameters are > >> doubled, except for the string ones: the doubled parameters > >> are booleans whose meaning is: "is the previous parameter > >> specified or not?" > >> > - all the generated C# methods return parameters are > >> void, except for the string ones > >> > The actual result are clients with methods like > >> these: > >> > public void a(string, int, bool); > >> > public string b(int, bool, string); > >> > This is obviously a problem, particularly for the > >> "void" return type. > >> > If I remove minOccurs="0", clients are generated > >> correctly by .NET WebService Studio 2.0. > >> > The issue is this: why does Java2WSDL always adds > >> minOccurs="0"? If its meaning were "it can be null", I think > >> nillable="true" attribute should be more appropriate... > >> Moreover, if I substitute Integer with int in the original > >> Java class methods, minOccurs="0" is still added by > >> Java2WSDL, even if an int cannot be null. > >> > >> -- > >> This message is automatically generated by JIRA. > >> - > >> You can reply to this email to add a comment to the issue > >> online. > >> > >> > > > > > > > > > -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein
Re: [Axis2] SMS transport for axis2
Hi Charith, This is a very good idea indeed. As many pointed out, there are immense benefits in doing this and it is indeed great for a GSoC. I think Sagara has a good point. Since there is a character limit per message you need to think about how larger payloads can be transfered. For cell phones I remember there was a format where you can send one single message consisting of up to some max number of separate messages. I remember this to be Nokia specific thing since they appeared messed up in the old Ericcsson I used to have.[ Am writing this mail offline so can't google :( Not sure whether it was adopted as a standard ] . You can definitely take a look at such things. Ultimately if you can comeup with a protocol binding (such as the WSDL bindings for HTTP or SMTP) that would be an ideal outcome. Such a binding would at least become a de-facto standard if you are successful :) Guys that have more knowledge in SMS can help out here, Can SMS transfer binary ? [I doubt whether it can. It seemed to be only ASCII]. If so you can think of more space efficient XML serializations such as fastinfoset. Just some ideas Ajith 2009/3/19 Sagara Gunathunga : > Hi Charith, > It always better to implement for a specification instead of a > specific implementation such as SMSlib , Initially you can set up > SMPPSim for testing it just like running a HTTP server. > > Any way what is your plan to handle size of the the payload messages ..? > > This is not a problem with other protocols like HTTP,JMS or mail but > SMS you need to think about the size of the massage. According to > the SMPP spec "short_message size" is limited to 254 Octet String, > also this value may be vary with networks. pay your attention for > possible solution for this. > > Thanks , > -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein
Re: [Axis2-1.4.1] Error handling
Would it be a possibility to have a flag in the AxisFault to mark it
as an application generated or system generated exception ?
Then we can decide to log accordingly or even provide system level
properties to control that behavior'
Ajith
2009/3/20 DV :
>
> Every time I throw an application fault the error gets displayed in server
> side as an error.
>
> To reproduce: run the faulthandling example from the distribution
> (xis2-1.4.1/samples/faulthandling)
>
> In the server side you get:
>
> ERROR] Account does not exist!
> org.apache.axis2.AxisFault: Account does not exist!
> at
> example.BankServiceMessageReceiverInOut.createAxisFault(BankServiceMessageReceiverInOut.java:237)
> at
> example.BankServiceMessageReceiverInOut.invokeBusinessLogic(BankServiceMessageReceiverInOut.java:75)
> at
> org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40)
> at
> org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:100)
> at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:176)
> at
> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
> at
> org.apache.axis2.transport.http.HTTPWorker.service(HTTPWorker.java:278)
> at
> org.apache.axis2.transport.http.server.AxisHttpService.doService(AxisHttpService.java:281)
> at
> org.apache.axis2.transport.http.server.AxisHttpService.handleRequest(AxisHttpService.java:187)
> at
> org.apache.axis2.transport.http.server.HttpServiceProcessor.run(HttpServiceProcessor.java:82)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
> at java.lang.Thread.run(Thread.java:613)
>
>
> I tracked the source of the error and it is in class AxisEngine line 212:
>
> catch (AxisFault e) {
> log.error(e.getMessage(), e); // <<<<<
> msgContext.setFailureReason(e);
> flowComplete(msgContext);
> throw e;
> }
>
> Now, the only way to deal with it now is to switch off logging which is never
> a good idea. This seems a pretty bad issue if you want to use faults.
> Comments? Especially from the axis committers.
>
> Dino
>
>
>
>
--
Ajith Ranabahu
Reading, after a certain age, diverts the mind too much from its
creative pursuits. Any man who reads too much and uses his own brain
too little falls into lazy habits of thinking - Albert Einstein
Re: [DISCUSS] Axis2 as TLP
Hi, See my comments inline. On Sat, Nov 1, 2008 at 10:49 AM, Amila Suriarachchi <[EMAIL PROTECTED]> wrote: > hi, > > By going through all these discussions what I can think of is that going for > TLP neither make it better nor worse. > >> 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. > > yes. The advantage here is that they have separate svn and they can have > independent releases. Axis2 can depends on particular Axiom Version while > people developing Axiom. or Rampart/Sandesha can use a pirticular > Axis2 version (if need) and can have independent releases. > > So in this scene WS project has broken things into separate manageable > components with the time. Of course this has happened generally with the > time and may happen in future as well. > > What is the big management advantage we get moving them to TLPs? Clarification here. There is not going to be axiom.apache.org or rampart.apache.org. Only Axis2 is going to move to a TLP and directly related sub projects will be under that as subprojects. > I agree that there are a lot of jiras and incomplete web sits. The reason > for this is lack of time committees getting to work on these project due to > various personal reasons. So I think this is a different issue which can not > be addressed by going for TLP. > > For an example both Ajith and Chinthaka were very active committers in this > project. But now they only participate in discussions. Can we expect any > change after going TLP? Lets say Deepal going to fix 50 issues after going > TLP, why he can not do it now? (Here I have nothing make personal I try to > explain what I want to say) True - As I have mentioned numerous times earlier there is not going to be any magic that solves our problems when Axis2 is moved to TLP. Instead we get a focused commiterbase and a PMC. When we attract committers we get to them to a more focused project. There is not going to be anything new happening with the current committers. instead we spare the confusion to all the newbies. > > >> >> > >> > Anyway, why I don't agree is I don't see a problem with the current >> > way. Even if there is a problem, I still don't see how things will be >> > better if we go to multiple TLPs. >> 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. > > Well, are you saying that being a TLP a prestigious status? Of course this > is a personal thing and I am not thinking like that. If so that is a > different concern. There is a sense of independence and an expanded state of visibility in being a TLP. Why do you think the new projects graduating from incubator want to go TLP directly rather than hanging around as subprojects of an umbrella ? why is it that we see most of the donated projects (say hadoop and lucene from Yahoo or xmlbeans from BEA) becoming TLP's rather than settling down as subprojects ? IMHO the expanded visibility gives better opportunities to market themselves and also help them increase their focused commiterbase. > > > thanks, > Amila. >> -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Axis2 as TLP
Hi, My comments are inline On Fri, Oct 31, 2008 at 11:27 PM, Eran Chinthaka <[EMAIL PROTECTED]> wrote: > Hi, > > I thought of not giving any inputs to this as once it seemed things were > getting personal. But let me try once again. > I assure you - nothing personal :) > Let me first understand something. Isn't this a problem that should be > discussed or voted, if required, in PMC, as this is about project > management. Why this is raised in dev list without any consent in PMC? I > know this decision will affect devs too, but > > If its ok to discuss these issues in dev lists, without any decision in PMC, > I think it is best to cc other mailing lists too.( I can remember Dims > sending this mail to general list initially. ) I think we had enough chat about this in the PMC and if you remember how the conversation ended, we needed more input. dev@ and general@ seems to be the right place to do so. > Also if there is a vote can committers vote? > I don't think so. I look at this thread as a means of getting more input from a crowd with broader interest. Once the things are done the vote would (could) be in PMC. > Please don't take any of those questions personal. I am just trying to > understand. > > Please see my comments in-line. > > On Fri, Oct 31, 2008 at 12:04 PM, Ajith Ranabahu <[EMAIL PROTECTED]> > wrote: >> >> I should kick myself for not reading Axis2 mail frequently. I just >> spent 20 minutes reading the complete thread and just throwing my 2 >> cents. >> > > 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 ;) > Yes I agree people are unpredictable animals :) Atleast there was no such strong arguments to/against the move in the PMC list. > Anyway, why I don't agree is I don't see a problem with the current way. > Even if there is a problem, I still don't see how things will be better if > we go to multiple TLPs. Here is a case that might take us back to the past. why was it that we did not start sandesha as a module of Axis but rather a separate sub project ? Why did we move Axiom, savan,rampart and every bit of reusable functionality out of the main Axis2 source tree ? With functionality comes specialization and this separation makes each of these little projects manageable. Now the same argument gets applied to Axis2 since Axis2 has become a large (if not the largest) portion of WS. it has achieved its own specialization and own set of followers As I noted earlier - things are not going to get fixed automagically. it just becomes easier to manage. There is a chance that a renewed strength and motivation sweeping through the committer base if we make a move but that is not guaranteed or relied on. > >> >> 2. I have to agree to Dims that we have not been active as usual. >> There are open Jira's and I haven't had time to fix the few things >> that are pending in my niche projects (XMLSchema and tcpmon) let alone >> in Axis2. > > Ajith, I don't agree with you here. Axis2 now has a new breed of developers > who are happily working on various components. People will be inactive for > various reasons, but that is the nature of opensource projects. Those new people work on Axis2. They don't contribute to WS as a whole (meaning other Axis2 unrelated projects such as juddi,muse or scout) but work on very specific Axis2 components. What would be the more appropriate choice when it comes to committership ? Give them committership in the Axis2 project or give them committership in WS ? > >> >> 3. I've been told that (before my time in Apache) that it is >> discouraged to put projects in an umbrella of functionality, say like >> in ws* or xml*. Instead Apache has embraced the >> related-or-not-related-but-interesting type of project names with >> 'projects' and not umbrellas. Just to make it clear does the words >> jackrabbit, lucene, synapse, Mina or Lenya make any hint of what the >> project actually does ? So i don't see the point of keeping Axis2 >> under the umbrella of ws* anymore. if the ws* argument to hold I would >> say all other Apache projects that provide the SOAP stack capability >> should come under ws* as well (such as CXF) > > Ok if your argument is about the name WS, as Deepal suggested let's rename > this to something else. Say Kurumba ;) (Ok that was meant to be a joke, just > to be clear) > kurumba would have been fine (for the sake of the argument) since I can't see what motivated a name like jackrabbit :)
Re: [DISCUSS] Axis2 as TLP
I should kick myself for not reading Axis2 mail frequently. I just spent 20 minutes reading the complete thread and just throwing my 2 cents. 1. I am +1 (not a vote, a token of agreement) on making Axis2 a TLP. I have supported the decision in the PMC and I am still in support for it. As Deepal says I don't understand why people are so much worried about making Axis2 a TLP. We have kept all the major components as subprojects so far and what difference would it make if we house them in a different place ? 2. I have to agree to Dims that we have not been active as usual. There are open Jira's and I haven't had time to fix the few things that are pending in my niche projects (XMLSchema and tcpmon) let alone in Axis2. However I personally feel that it would be easier to do a better job (better than being done right now) if the teams are small and focused rather than generic and all over the place. Again the volume and the size clearly warrants a break just for the ease of management. Mind you - it would not automatically fix the problem - the site would not get fixed by magic and the Jiras would not vanish. However it may make it easier to do so. For the sake of the argument if a disgruntled user goes on commenting about Axis2 he would be shooting at the ws pmc. But the WS pmc consists of many other innocent PMCers that have nothing to do with Axis2! if we have clear separation then the responsibilities are clear. 3. I've been told that (before my time in Apache) that it is discouraged to put projects in an umbrella of functionality, say like in ws* or xml*. Instead Apache has embraced the related-or-not-related-but-interesting type of project names with 'projects' and not umbrellas. Just to make it clear does the words jackrabbit, lucene, synapse, Mina or Lenya make any hint of what the project actually does ? So i don't see the point of keeping Axis2 under the umbrella of ws* anymore. if the ws* argument to hold I would say all other Apache projects that provide the SOAP stack capability should come under ws* as well (such as CXF) 4. I don't suppose there is anyone with a secret (evil ;P) agenda of becoming the member of two PMC's supporting the split. But as I pointed out earlier ws has grown out of its bounds and its time we split things up for the sake of managing the complexity. Who we put as the chair is a different question and hopefully would be selected the democratic way (or by just looking at the mail count :D) For my final conclusion I am in support of this proposal. Ajith On Fri, Oct 31, 2008 at 10:59 AM, Paul Fremantle <[EMAIL PROTECTED]> wrote: > On Fri, Oct 31, 2008 at 1:51 PM, Davanum Srinivas <[EMAIL PROTECTED]> wrote: >> Though given Paul's and other people's response. > > Dims, my response was a light-hearted comment on the situation, and > made no reference to whether or not Axis2 should be a TLP. I'm sorry > if you took it in a way it wasn't meant to be taken, but I certainly > wasn't making any comment against the proposal. I am in favour of > making Axis2 a TLP, and I'm surprised if anything I have said led you > or anyone else to think otherwise. > > Paul > > -- > 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 > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing a Birthday in a distributed scenario
hi, See my comments inline On Fri, Jul 11, 2008 at 5:38 AM, Sanjaya Karunasena <[EMAIL PROTECTED]> wrote: > Well, I didn't mean to say the original design is bad. It just what we will > end up if we stick to what is given by java. is it not the idea when we use Java in the first place ? > > If you look at some simple design elements like; > > - Time, Date and Duration/Interval/Period get maps to a Date. > - DateTime and Timestamp get maps to a Calendar. > > Now my domain model is gone. Can I get it back, during the reverse > execution? I don't think so. > > Interestingly, your have taken data integrity very lightly :-). Not really. The case here is that the moment you decided to put a an XML messaging layer in the middle you did take the risk of losing some of your data integrity. None of the current languages (to be safe I suppose I should say 'only a handful') can do a lossless type conversion from XML or to XML. The current mappings are designed to be an optimal (in function and usability) transfer from XML -> Java and Java -> XML. If you really want serious data integrity you can easily switch to something like XMLBeans as the data binding framework and (hopefully) not lose a thing. If that does not work then you can customize and get your own bindings and Axis2 is flexible enough to provide that. Again I was somewhat mislead with the JDBC example earlier. ADB was designed with XML in mind and it was meant to be an efficient XML <-> java converter. I suppose its doing fine at the moment in that regard. > > So, if the majority think using Axis2's extensibility to overcome this issue > is the way to go, I will have to respect that. :-) Well the thing is that the use case presented is an exotic one. From the millions of people who use Axis2 how many of them would have such a set up and how many anticipate running into a problem like that ? If they do they can customize Axis2 and cook up their own solution while the rest keeps cruising along. The idea of making things flexible is exactly to give such freedom to users. BTW I did write a detailed mail regarding my reasons to not change anything Ajith > > /Sanjaya > > > - Original Message > From: Ajith Ranabahu <[EMAIL PROTECTED]> > To: axis-dev@ws.apache.org > Sent: Friday, July 11, 2008 12:40:15 PM > Subject: Re: Representing a Birthday in a distributed scenario > > On Fri, Jul 11, 2008 at 2:59 AM, Eran Chinthaka > <[EMAIL PROTECTED]> wrote: >> Hi, >> >> On Thu, Jul 10, 2008 at 10:41 PM, Sanjaya Karunasena <[EMAIL PROTECTED]> >> wrote: >>> >>> I am happy! Finally there is some one who is interested in this topic :-) >> >> Hmm, I know there are some more people interested in these issues. It is >> just that they are much busier than me ;) >> >> >> I think I can understand the issue ( I guess so). DateTime within Java >> might have a problem, as explained by you. But don't you have to live with >> it, if you select to use it. >> >> When some one associates a type with it, he should know the limitations of >> it and select the proper one. So if you think Java DateTime is not >> appropriate, there are two options I can see for this problem. >> >> 1.. Define your own type with the level of accuracy you want and associate >> it as the type >> 2. Pass your own type mapping to the system, with your util library date >> time util mapping to xsd:datetime. >> >> You agree that, this is a use case, which is rare. So I think asking the >> users to provide their own type mapping is a fare deal. > > Yep. We have enough flexibility in the system to allow users customize > their code generation. I suppose we even have some documentation as > part of the standard doc release of how to go about doing that. So if > they really want custom times they can change the type mapping to > change their own types. > >> >> This is not a design problem, within Axis2, as I see. If you are not >> comfortable with the type mapping, we have the extensibility to provide a >> different one (Ajith and Amila, please correct me if I'm wrong). So it is >> a >> good design we have I guess ;) > > No need for correction :) In fact AFAIR the typemapper is completely > separated so that when you want to generate code for a different > language (say C) all you need is to replace the typemapper and the > templates (might have to do a bit of tweaking of other components as > well but they won't be huge) > >> >> >> -- >> With Mettha, >> Eran Chinthaka >> >> >> Health is the
Re: Representing a Birthday in a distributed scenario
On Fri, Jul 11, 2008 at 2:59 AM, Eran Chinthaka <[EMAIL PROTECTED]> wrote: > Hi, > > On Thu, Jul 10, 2008 at 10:41 PM, Sanjaya Karunasena <[EMAIL PROTECTED]> > wrote: >> >> I am happy! Finally there is some one who is interested in this topic :-) > > Hmm, I know there are some more people interested in these issues. It is > just that they are much busier than me ;) > > > I think I can understand the issue ( I guess so). DateTime within Java > might have a problem, as explained by you. But don't you have to live with > it, if you select to use it. > > When some one associates a type with it, he should know the limitations of > it and select the proper one. So if you think Java DateTime is not > appropriate, there are two options I can see for this problem. > > 1.. Define your own type with the level of accuracy you want and associate > it as the type > 2. Pass your own type mapping to the system, with your util library date > time util mapping to xsd:datetime. > > You agree that, this is a use case, which is rare. So I think asking the > users to provide their own type mapping is a fare deal. Yep. We have enough flexibility in the system to allow users customize their code generation. I suppose we even have some documentation as part of the standard doc release of how to go about doing that. So if they really want custom times they can change the type mapping to change their own types. > > This is not a design problem, within Axis2, as I see. If you are not > comfortable with the type mapping, we have the extensibility to provide a > different one (Ajith and Amila, please correct me if I'm wrong). So it is a > good design we have I guess ;) No need for correction :) In fact AFAIR the typemapper is completely separated so that when you want to generate code for a different language (say C) all you need is to replace the typemapper and the templates (might have to do a bit of tweaking of other components as well but they won't be huge) > > > -- > 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 -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing a Birthday in a distributed scenario
ent thing is working, > 99% of the time why bother worrying about it. > > I can still remember what Sanjiva and Glen wrote on the white board during > the last day of first Axis2 summit. We always should KISS and adhere to > YAGNI, which I liked a lot. > > Please note that, I appreciate your suggestion and understand what your > point is. But making it a first class citizen by putting those in to ADB, > hmm ... I don't think I will agree to that. > > On Tue, Jul 8, 2008 at 1:47 AM, Sanjaya Karunasena <[EMAIL PROTECTED]> > wrote: >> >> Hi All, >> >> Usually to represent some thing like a Birthday java Date class is used. >> However, it internally make use of a Calendar instance in most of the >> operations. >> This means unless we send timezone information in a Web Service request >> with the birthday, there is a time window, when the client and the server is >> in two different timezones, the day get represented inaccurately. >> >> I came across this library (http://joda-time.sourceforge.net) which >> doesn't suffer from such design flaws. >> (http://joda-time.sourceforge.net/key_partial.html) >> >> Thoughts? Probably we need to fix ADB to handle this. >> >> /Sanjaya >> >> > > > > -- > 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 > -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Generating a wrong port address for POJO deployment
t;>> can do that because by looking at the endpoint we can decide the exact >>>>>> binding which the client has picked. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Here the right thing would be to throw an exception saying incorrect >>>>>>>> >>>>>>> SOAP version where as Axis2 server won't complain which IMO is a bug. >>>>>> >>>>> Now if >>>> >>>>> you use http://localhost:8080/axis2/services/foo.SOAP11Endpoint as the >>>>>> >>>>> SOAP >>>> >>>>> 1.1. binding endpoint we can do a prior evaluation of the request and >>>>>> >>>>> throw >>>> >>>>> an exception if we receive a SOAP 1.2 request which IMO is the correct >>>>>> behavior. >>>>>> >>>>>>> >>>>>>>> Only problem I have is having the SOAP11Endpoint name in the >>>>>>> address , >>>>>>> >>>>>>> >>>>>> Please explain why do you have a problem with [service].[port] format >>>>>> ? >>>>>> >>>>>> >>>>>> >>>>>> I do not mind sending that as some where else. >>>>>>> >>>>>>> >>>>>> >>>>>> Where would you suggest that we should have the port name s.t. we can >>>>>> decide the intended port (or the binding) of the request and do throw >>>>>> an >>>>>> exception if the client has sent a SOAP 1.2 request by error where he >>>>>> >>>>> would >>>> >>>>> have actually intended the SOAP 1.1 endpoint ? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>>> I know that the structure of endpoint address is important that it >>>>>>>> >>>>>>> is >>>> >>>>> something that we should not be mess around. That is the exact reason >>>>>> >>>>> why I >>>> >>>>> posted[1] it to developer mailing list. However I think we should be >>>>>> flexible enough to change what we agreed on if there are valid reasons >>>>>> >>>>> to do >>>> >>>>> so and if we don't lose anything by doing it. >>>>>> >>>>>>> >>>>>>>> One reason for using [service].[port] would be that it allows the >>>>>>>> >>>>>>> server >>>> >>>>> to do prior evaluations of SOAP requests hence make it less error-prone >>>>>> >>>>> (As >>>> >>>>> I mention in my earlier) >>>>>> >>>>>>> >>>>>>>> Another reason would be that [service].[port] format makes lot of >>>>>>>> >>>>>>> sense >>>> >>>>> if we want to support multiple policy alternatives scenario at the >>>>>> Axis2 >>>>>> server-side. Lets say a service requires strong authentication, but >>>>>> >>>>> gives >>>> >>>>> the client multiple options of SSL mutual authentication, username >>>>>> with >>>>>> >>>>> a >>>> >>>>> signature, SAML with a signature or Kerberos. It does it via a policy >>>>>> in >>>>>> >>>>> the >>>> >>>>> services.xml which contains an alternative for each scenario. >>>>>> >>>>>>> >>>>>>>> Now one option would be to do some processing of the request to >>>>>>>> >>>>>>> figure >>>> >>>>> out the option the client has chosen and then do a complete evaluation >>>>>> against that policy alternative. But it can be very expensive >>>>>> depending >>>>>> >>>>> of >>>> >>>>> the complexity of each policy alternative and of cause the number of >>>>>> >>>>> policy >>>> >>>>> alternatives which service exposes. Further there is a possibility that >>>>>> >>>>> some >>>> >>>>> policy alternatives are indeterminate by only looking at the request. >>>>>> >>>>>>> >>>>>>>> The other option would be to generate multiple endpoints s.t. each >>>>>>>> >>>>>>> endpoint would correspond to exactly one policy alternative during >>>>>> the >>>>>> deployment time. >>>>>> >>>>>>> >>>>>>>> e.g. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> binding="ns:VersionSoap11Binding"> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> location=" >>>> http://localhost:8080/axis2/services/Version.VersionHttpSoap11EndpointWithSSL"/> >>>> >>>> >>>>> >>>>>>>> >>>>>>> >>>>>>> name="VersionHttpSoap11EndpointWithUsernameAndSignature" >>>> >>>>> binding="ns:VersionSoap11Binding"> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> location=" >>>> http://localhost:8080/axis2/services/Version.VersionHttpSoap11EndpointWithUsernameAndSignature"/> >>>> >>>> >>>>> >>>>>>>> >>>>>>> >>>>>>> binding="ns:VersionSoap11Binding"> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> location=" >>>> http://localhost:8080/axis2/services/Version.VersionHttpSoap11EndpointSAMLAndSignature"/> >>>> >>>> >>>>> >>>>>>>> >>>>>>> >>>>>>> binding="ns:VersionSoap11Binding"> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> location=" >>>> http://localhost:8080/axis2/services/Version.VersionHttpSoap11EndpointWithSSLWithKerberos"/> >>>> >>>> >>>>> >>>>>>>> . >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> That way we can straight way say the option client as picked and >>>>>>>> >>>>>>> evaluate the quest based on the target policy alternative with IMO is >>>>>> a >>>>>> better way of supporting multiple policy alternatives at the >>>>>> >>>>> server-side. We >>>> >>>>> need to use [service].[port] format if we are to implement the support >>>>>> >>>>> for >>>> >>>>> multiple policy alternatives feature. >>>>>> >>>>>>> >>>>>>>> Thank you so much for such a descriptive mail. I will think though >>>>>>> and >>>>>>> >>>>>> send a reply soon.. >>>>>> >>>>>>> >>>>>>> -Deepal >>>>>>> >>>>>>> >>>>>>> - >>>>>>> >>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Sanka Samaranayake >>>>>> WSO2 Inc. >>>>>> >>>>>> http://sankas.blogspot.com/ >>>>>> http://www.wso2.org/ >>>>>> >>>>>> - >>>>>> >>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Davanum Srinivas :: http://davanum.wordpress.com >>>>> >>>>> >>>>> >>>>> >>>>> - >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Amila Suriarachchi, >>>> WSO2 Inc. >>>> >>> >>> >>> >>> -- >>> Davanum Srinivas :: http://davanum.wordpress.com >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> --- >> Daniel Kulp >> [EMAIL PROTECTED] >> http://www.dankulp.com/blog >> >> >> >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> > > -- > Sanka Samaranayake > WSO2 Inc. > > http://sankas.blogspot.com/ > http://www.wso2.org/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein
Re: [Axis2] Common VOTE for XmlSchema/Axiom/Neethi
Hi +1 for all On Wed, Apr 9, 2008 at 12:18 PM, Lawrence Mandel <[EMAIL PROTECTED]> wrote: > Sounds good Dims. I'll pick up the release candidates and test in Woden. > > Lawrence > > > > > > Davanum Srinivas <[EMAIL PROTECTED]> > 04/09/2008 11:18 AM > Please respond to > axis-dev@ws.apache.org > > > To > Axis developer list , [EMAIL PROTECTED], > [EMAIL PROTECTED] > cc > > Subject > [Axis2] Common VOTE for XmlSchema/Axiom/Neethi > > > > > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Folks, > > In the interest of time, i propose we make a joint vote for all 3 commons > projects (XmlSchema/Axiom/Neethi). Then woden > can pick up xmlschema/axiom and make their release. Then we cut Axis2 1.4 > FINAL. > > Sounds like a plan? > > thanks, > dims > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.5 (Cygwin) > > iD8DBQFH/N5FgNg6eWEDv1kRAnQuAJ451uaLzmeN0DI+nhrUu61UgyWQiACgjohI > IAtgVSq7D8fXem03FW7XVk0= > =GgCd > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein
[ANN][XMLSchema] XMLSchema 1.4 Released
We are pleased to announce the release of Apache XMLSchema 1.4 of Apache WS-Commons.This release includes numerous bug fixes and a major behavioral change of the API. Element and Type retrieval via QNames has been modified to traverse the full schema tree and hence be cautious when upgrading from an earlier version. More details would be available in the release notes and the javadocs. The binary, source and document release artifacts are available at http://ws.apache.org/commons/XmlSchema/download.cgi XMLSchema is a lightweight schema object model that can be used to manipulate and generate XML schema representations. It has no external dependencies and can be easily integrated into an existing project. You are welcome to kick the tires and get XMLSchema on the move. If you like to help us shape XMLSchema, any contribution in the form of coding, testing,submitting improvements to the documentation, and reporting bugs are always welcome. Thank you for your interest in XMLSchema! - The XMLSchema Development Team signature.asc Description: OpenPGP digital signature
[Vote][XmSchema] Release time again
Hi all, I've fixed the critical Jiras and left two unsolved ones for further discussion (as mentioned in one of my earlier mails). After merging the trunk to the branch (thanks Dims for the fixes) I've put up the signed and md5ed 1.4-RC3 release artifacts up in the usual place (http://people.apache.org/~ajith/xmlschema/). Please give it a try and let me know of any issues. I have tested this with Axis2 and woden (source in trunks) and found no issues. Here is my +1 for this release. -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 JAXBRI binding and MTOM not working
Hi,
Perhaps this has to do with JAXB using the StAX interfaces to
read/write XML ? If you see the MTOM support in ADB you'll see we went
to great lengths to provide a way to carry over the binary blob to the
data binding framework without text conversions. We did this by
introducing a property value through the StAX readers getProperties
method (See [1] for details)
So unless the data binding framework would know about this behavior
then it is unlikely that they support optimal binary. AFAIK we have a
similar problem with XMLBeans
Ajith
[1] http://wso2.org/library/236
On Wed, Mar 12, 2008 at 7:08 AM, Narayan Dhillon
<[EMAIL PROTECTED]> wrote:
>
>
>
>
> Hi,
>
>
>
> I tried a simple web service client with JAXB binding, and noticed that MTOM
> parts are being in-lined in the soap message as opposed to being XOP
> attachments.
>
> The same client works fine with ADB binding. Is this a known issue?
>
> Any pointers on this will be greatly appreciated.
>
>
>
> Code example:
>
> FileDataSource fileDataSource = new FileDataSource("C:\\upload.dat");
>
> DataHandler fileDataHandler = new DataHandler(fileDataSource);
>
> InitiateRequest request = new InitiateRequest();
>
> request.setRequestId("x");
>
> request.setSubmission(fileDataHandler);
>
> request.setSignature(sigDataHandler);
>
>
>
> System.out.println(stub.initiateRequest(request));
>
>
>
> Response:
>
> --MIMEBoundaryurn_uuid_EAE9BC656EBBB536921205317613109
>
> Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
>
> Content-Transfer-Encoding: binary
>
> Content-ID: <0.urn:uuid:[EMAIL PROTECTED]>
>
>
>
>xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
>
>
>
>
>
>x
>
>VGVzdCBQYWluIFN1Ym1pc3Npb24=
>
>VGVzdCBzaWduYXR1cmU=
>
>
>
>
>
>
> --MIMEBoundaryurn_uuid_EAE9BC656EBBB536921205317613109--0
>
>
>
> Regards, Narayan
>
>
>
>
>
>
> *
> This email is issued by a VocaLink group company. It is confidential and
> intended for the exclusive use of the addressee only. You should not
> disclose its contents to any other person. If you are not the addressee (or
> responsible for delivery of the message to the addressee), please notify the
> originator immediately by return message and destroy the original message.
> The contents of this email will have no contractual effect unless it is
> otherwise agreed between a specific VocaLink group company and the
> recipient.
>
> The VocaLink group companies include, among others: VocaLink Limited
> (Company No 06119048, VAT No. 907 9619 87) which is registered in England
> and Wales at registered office Drake House, Homestead Road, Rickmansworth,
> WD3 1FX. United Kingdom, Voca Limited (Company no 1023742, VAT No. 907 9619
> 87) which is registered in England and Wales at registered office Drake
> House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire. WD3
> 1FX. United Kingdom, LINK Interchange Network Limited (Company No 3565766,
> VAT No. 907 9619 87) which is registered in England and Wales at registered
> office Arundel House, 1 Liverpool Gardens, Worthing, West Sussex, BN11 1SL
> and VocaLink Holdings Limited (Company No 06119036, VAT No. 907 9619 87)
> which is registered in England and Wales at registered office Drake House,
> Homestead Road, Rickmansworth, WD3 1FX. United Kingdom.
>
> The views and opinions expressed in this email may not reflect those of any
> member of the VocaLink group. This message and any attachments have been
> scanned for viruses prior to leaving the VocaLink group network; however,
> VocaLink does not guarantee the security of this message and will not be
> responsible for any damages arising as a result of any virus being passed on
> or arising from any alteration of this message by a third party. The
> VocaLink group may monitor emails sent to and from the VocaLink group
> network.
>
> This message has been checked for all email viruses by MessageLabs.
> *
>
--
Ajith Ranabahu
Reading, after a certain age, diverts the mind too much from its
creative pursuits. Any man who reads too much and uses his own brain
too little falls into lazy habits of thinking - Albert Einstein
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOYE][Axis2] Dims as 1.4 Release Manager
+1 On Fri, Mar 7, 2008 at 9:44 PM, Nadir Amra <[EMAIL PROTECTED]> wrote: > +1 > > Nadir K. Amra > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Server-side defaulting is now difficult
Thanks for the clarification. I am +1 to go ahead Ajith On Fri, Mar 7, 2008 at 12:29 AM, Chuck Williams <[EMAIL PROTECTED]> wrote: > > Hi Ajith, > > Our person working on Axis2 now, An Hong, has discovered the right fix. > amilas already did all the plumbing for this in r585400, so the code > generator already adds a defaultValue attribute for the property to the xml > bean description that is transformed by ADBBeanTemplate.xsl. The property > is initialized to the correct default in the generated java bean now! > > The problem is that one piece was missed. The parse() method overwrites > with MIN_VALUE (or NaN) the correct default value already in place from > constructing the bean. All that is required is to omit this arbitrary value > defaulting in parse() whenever the @defaultValue attribute exists on the > property. > > This is a simple change. An is testing it now and will open a jira with > the patch. > > Hope all is well with you! > > Chuck > > > Ajith Ranabahu wrote on 03/06/2008 05:06 PM: > > Hi Chuck, > > Does it mean that ADB does not populate the correct default value > (supplied in the schema) ? Or is it just that it defaults to a random > (unpredictable) value ? > > if its the latter I think we can easily provide a fix for that. The > former (which I think may even be treated as a bug) however would > require some effort > > Ajith > > On Thu, Mar 6, 2008 at 9:06 PM, Chuck Williams <[EMAIL PROTECTED]> wrote: > > > Hi All, > > It's been a long time. We are trying to upgrade to the latest Axis2 and > have run into a serious issue. Axis2 now uses various MIN_VALUE's and > NaN's as the marker for unset values in ADB binding code, rather than > the previous behavior of using 0. > > Our server needs to either have wsdl-declared defaults used, which axis2 > adb message parsing code does not do, or to implement its own > defaulting, which is what it has been doing. However, testing for the > specific axis2 implementation market for unset values, e.g. > Integer.MIN_VALUE, to discover a parameter has not been set seems too > hackish. > > A simple solution would be to add a new method to the automatically > generated ADB binding class. There are already protected localTracker > boolean variables that are true iff the value has been set. Adding an > is accessor for the property, e.g. isSet(), would resolve the > issue simply and fully. > > Does this seem a reasonable thing to do or am I missing something? > > If it is reasonable, even though I'm now out of date on the code base, > the ADBBindingTemplate.xsl is familiar ground from before. I could make > this extension if no one objects, else we'll probably patch this locally. > > Please advise. > > Thanks, > > Chuck > > > - > 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] -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Server-side defaulting is now difficult
Hi Chuck, Does it mean that ADB does not populate the correct default value (supplied in the schema) ? Or is it just that it defaults to a random (unpredictable) value ? if its the latter I think we can easily provide a fix for that. The former (which I think may even be treated as a bug) however would require some effort Ajith On Thu, Mar 6, 2008 at 9:06 PM, Chuck Williams <[EMAIL PROTECTED]> wrote: > Hi All, > > It's been a long time. We are trying to upgrade to the latest Axis2 and > have run into a serious issue. Axis2 now uses various MIN_VALUE's and > NaN's as the marker for unset values in ADB binding code, rather than > the previous behavior of using 0. > > Our server needs to either have wsdl-declared defaults used, which axis2 > adb message parsing code does not do, or to implement its own > defaulting, which is what it has been doing. However, testing for the > specific axis2 implementation market for unset values, e.g. > Integer.MIN_VALUE, to discover a parameter has not been set seems too > hackish. > > A simple solution would be to add a new method to the automatically > generated ADB binding class. There are already protected localTracker > boolean variables that are true iff the value has been set. Adding an > is accessor for the property, e.g. isSet(), would resolve the > issue simply and fully. > > Does this seem a reasonable thing to do or am I missing something? > > If it is reasonable, even though I'm now out of date on the code base, > the ADBBindingTemplate.xsl is familiar ground from before. I could make > this extension if no one objects, else we'll probably patch this locally. > > Please advise. > > Thanks, > > Chuck > > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] 1.4 Release Management / Planning
Hi, On Thu, Mar 6, 2008 at 10:12 AM, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Team, > How about we cut a Axis2 1.4 RC1 end of next week (14th) to get things > started? We can do one RC a week or so. > > Rich, > You taking on Axiom. Right? > > Jeremy, > Can we please plan for some woden milestones? Please let us know. > > Ajith, > You taking on XmlSchema. Right? Please let us know. Yep. The release is all ready and good to go. However I've not seen the required number of votes for the release (I suppose lazy consensus would not count for releases:)) so please take some time to play with the artifacts and vote > Sanka, > Can you please help with Neethi as usual? Please let us know. > > Deepal, > Would you have time for Axis2? I can volunteer as Release Manager if you > wish or we can share the responsibility as > usual. Either works for me. > > Sandakith, > Stand alone TCK would be the biggest blocker for the final release. Any > feedback on how that's going? > > thanks, > dims > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.5 (Cygwin) > > iD8DBQFH0AnTgNg6eWEDv1kRAu47AJ9Gj1bxKIgAg09Feu87yVdMyqqSuwCghtq5 > 2LbRF6CxY6bl7NguRASVk/c= > =ijFU > -END PGP SIGNATURE- > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Michele Mazzucco as Axis2 Committer
+1 On Mon, Mar 3, 2008 at 8:56 PM, Thilina Gunarathne <[EMAIL PROTECTED]> wrote: > Here's my +1 > Welcome aboard.. > > ~Thilina > > > > On Mon, Mar 3, 2008 at 1:52 PM, Nicholas L Gallardo <[EMAIL PROTECTED]> > wrote: > > > > > > +1, absolutely. > > > > -Nick > > > > > > R J Scheuerle Jr/Austin/[EMAIL PROTECTED] > > > > > > > > > > > > > > > > R J Scheuerle Jr/Austin/[EMAIL PROTECTED] > > > > 03/03/2008 10:52 AM > > > > Please respond to > > axis-dev@ws.apache.org > > > > > > > > To > > axis-dev@ws.apache.org > > > > > > cc > > axis-dev@ws.apache.org > > > > > > Subject > > > > > > Re: [VOTE] Michele Mazzucco as Axis2 Committer > > > > > > > > +1 > > > > Rich Scheuerle > > IBM Web Services > > Apache Axis2 ([EMAIL PROTECTED]) > > 512-838-5115 (IBM TL 678-5115) > > Brian De Pradine <[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > > > > > Brian De Pradine <[EMAIL PROTECTED]> > > > > 03/03/2008 09:58 AM > > Please respond to > > axis-dev@ws.apache.org > > To > > axis-dev@ws.apache.org > > cc > > Subject > > Re: [VOTE] Michele Mazzucco as Axis2 Committer > > > > > > +1 from me. > > > > Cheers > > > > Brian DePradine > > Web Services Development > > IBM Hursley > > External +44 (0) 1962 816319 Internal 246319 > > > > If you can't find the time to do it right the first time, where will you > > find the time to do it again? > > > > > > Davanum Srinivas <[EMAIL PROTECTED]> wrote on 03/03/2008 15:31:26: > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > Folks, > > > > > > I am tired of applying Michele's patches :) So Let's please invite > > > Michele to join us as a committer > > > > > > Please see all of Michele's efforts here. Lot's of user mailing list > > > participation, tons of JIRA's and Patches! > > > > > > http://apache.markmail.org/search/?q=Michele%20Mazzucco > > > > > > Thanks, > > > dims > > > > > > > > > -BEGIN PGP SIGNATURE- > > > Version: GnuPG v1.4.5 (Cygwin) > > > > > > iD8DBQFHzBnOgNg6eWEDv1kRAvDnAKCeCC/O3QqVTlSTd0lmoiaPxPyjQgCfXO2c > > > Q4uwcvSTy7ISzs4TEHaR1fo= > > > =nRyn > > > -----END PGP SIGNATURE- > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > > > > > > > > > > > > -- > Thilina Gunarathne - http://thilinag.blogspot.com > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Moving Axis2 code base into JDK 1.5
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 -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Understanding Axis2 dependencies
Hi Tom, On 10/22/07, Tom Jordahl <[EMAIL PROTECTED]> wrote: > [Concerning commons-logging] > > also what would you replace it with ? > > I actually think that the JDK 1.4 logging APIs would probably do the > trick, not have "jar hell" problems, and be functional enough for most > everyone. > Agreed :) But if we are to change all the commons logging references it will be a long hard effort (just speculation though). If my understanding is right, we can set the configuration to use the java.util logging quite easily and not ship the log4j.jar. > -- > Tom Jordahl > > -Original Message- > From: Ajith Ranabahu [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 17, 2007 10:39 PM > To: axis-dev@ws.apache.org > Subject: Re: [Axis2] Understanding Axis2 dependencies > > Hi, > > On 10/17/07, Eran Chinthaka <[EMAIL PROTECTED]> wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Since the topic is about jar dependencies, I'd like to comment on two > > aspects. > > > > 1. As one can see there is a huge number of dependencies we have in > > Axis2 and I think we ship almost all of them with our releases. Why > > should we release both xbeans and jibx with adb? My suggestion, let's > > ship the minimum number of jars required for a user. If he needs to > use > > XmlBeans, then let him download it. Same thing for JiBX. > > And also it is better to see the minimum set of jars required to run a > > client somewhere. I raised this point couple of days before also. If > you > > need to do a SOAP call, you need to include more than 20-25 jars. > > Yes we can do that. We already pick up the databinding implementation > by reflection and it is easy enough to print a message to print a > readable error message for the absence of the jars. > What I prefer to have is jar bundles for each databinding. Say for > XMLBeans we have a xmlbeans bundle (Xbeans jar, the Xbeans-codegen > module etc) and so on. > > > 2. Why do we need to have commons-logging? One would say well it let's > > you plug "any" logging module. How many of the users have really used > a > > logging framework other than log4j? This is YAGNI for me. (you can > also > > see very good comments about commons-logging from our valuable admirer > > here http://www.bileblog.org/?p=259) > > Well not really. All our logging code is based on commons-logging. If > we are to remove this code it would be somewhat significant effort and > also what would you replace it with ? The way it is right now is the > best way. What we can do is to send the default config to use > java.util logging so that we do not need to send the log4j jar along. > > > > > > Just my 2 cents. > > > > Thanks, > > Chinthaka > > > > Sanka Samaranayke wrote: > > > Hi, > > > > > > > > > > > > > > > Sanjiva Weerawarana wrote: > > >> Thanks Ajith. > > >> > > >> I think we should document this somewhere- we often get this > question > > >> and there's obviously reasons for why we have all these > dependencies. > > >> We need to clearly indicate which things are optional and indicate > > >> under what conditions they come into use. > > >> > > >> I am not a fan of going back to the seven different distributions > > >> model as that was confusing to users. Knowing the dependency > reasons > > >> will help embedders decide what they really need to pull in and > what's > > >> optional. > > >> > > >> One jar I didn't understand is the mex jar. Why is that around; > that > > >> should only be in the mex mar I believe. > > > > > > You need that jar if you use MexClient in your client code. > > > > > > Thanks, > > > Sanka > > > > > >> > > >> > > >> Sanjiva. > > >> > > >> Ajith Ranabahu wrote: > > >>> Hi Lawrence, > > >>> Let me see whether I can make sense of some of the stuff. Others > will > > >>> chip in as needed and will surely holler if I make a mistake. > > >>> > > >>>> Axis2 Third Party Dependencies > > >>>> -- > > >>>> activation-1.1.jarMIME support > > >>>> annogen-0.1.0.jar Annotation support > > >>>> axiom-api-1.2.5.jar XML pull parsing > > >>>> axiom-
Re: [Axis2] Understanding Axis2 dependencies
Hi, On 10/17/07, Eran Chinthaka <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Since the topic is about jar dependencies, I'd like to comment on two > aspects. > > 1. As one can see there is a huge number of dependencies we have in > Axis2 and I think we ship almost all of them with our releases. Why > should we release both xbeans and jibx with adb? My suggestion, let's > ship the minimum number of jars required for a user. If he needs to use > XmlBeans, then let him download it. Same thing for JiBX. > And also it is better to see the minimum set of jars required to run a > client somewhere. I raised this point couple of days before also. If you > need to do a SOAP call, you need to include more than 20-25 jars. Yes we can do that. We already pick up the databinding implementation by reflection and it is easy enough to print a message to print a readable error message for the absence of the jars. What I prefer to have is jar bundles for each databinding. Say for XMLBeans we have a xmlbeans bundle (Xbeans jar, the Xbeans-codegen module etc) and so on. > 2. Why do we need to have commons-logging? One would say well it let's > you plug "any" logging module. How many of the users have really used a > logging framework other than log4j? This is YAGNI for me. (you can also > see very good comments about commons-logging from our valuable admirer > here http://www.bileblog.org/?p=259) Well not really. All our logging code is based on commons-logging. If we are to remove this code it would be somewhat significant effort and also what would you replace it with ? The way it is right now is the best way. What we can do is to send the default config to use java.util logging so that we do not need to send the log4j jar along. > > Just my 2 cents. > > Thanks, > Chinthaka > > Sanka Samaranayke wrote: > > Hi, > > > > > > > > > > Sanjiva Weerawarana wrote: > >> Thanks Ajith. > >> > >> I think we should document this somewhere- we often get this question > >> and there's obviously reasons for why we have all these dependencies. > >> We need to clearly indicate which things are optional and indicate > >> under what conditions they come into use. > >> > >> I am not a fan of going back to the seven different distributions > >> model as that was confusing to users. Knowing the dependency reasons > >> will help embedders decide what they really need to pull in and what's > >> optional. > >> > >> One jar I didn't understand is the mex jar. Why is that around; that > >> should only be in the mex mar I believe. > > > > You need that jar if you use MexClient in your client code. > > > > Thanks, > > Sanka > > > >> > >> > >> Sanjiva. > >> > >> Ajith Ranabahu wrote: > >>> Hi Lawrence, > >>> Let me see whether I can make sense of some of the stuff. Others will > >>> chip in as needed and will surely holler if I make a mistake. > >>> > >>>> Axis2 Third Party Dependencies > >>>> -- > >>>> activation-1.1.jarMIME support > >>>> annogen-0.1.0.jar Annotation support > >>>> axiom-api-1.2.5.jar XML pull parsing > >>>> axiom-dom-1.2.5.jar XML pull parsing > >>>> axiom-impl-1.2.5.jar XML pull parsing > >>>> backport-util-concurrent-2.2.jar ? > >>> > >>> Thread pooling support. This feature is built in for Java 1.5 and this > >>> particular jar has a backport of that code to Java 1.4 > >>> > >>>> commons-codec-1.3.jar URL encoding? > >>>> commons-fileupload-1.1.1.jar Used for uploading new service > >>>> files in the admin client? > >>> > >>> Yes - needed only when using the webapp > >>> > >>>> commons-httpclient-3.0.1.jar Used by the Axis2 kernel? > >>> > >>> Yes - but primarily on the client side. I believe it is needed in the > >>> server side if asynchronous calls are to be supported. > >>> > >>>> commons-io-1.2.jar? > >>>> commons-logging-1.1.jar Is this related to Log4J? > >>> > >>> Well kind of. Commons logging is a common API on multiple logging > >>> frameworks (log4j/java.util.logg
Re: [Axis2] Understanding Axis2 dependencies
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 -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting axis2 transport out from the kernel
> > What will be shipped with Axis2 release? All of them or none? > If it is none, > do you expect people to download Axis2 release AND another transport > that he/she wants to use? > else will we release the transport we have now? > if yes, then Synapse will again have the same problem. Well not really - If we separate the transports (making it into a seperate jar) Synapse can always ship their transport jar instead of the standard Axis2 one. Axis2 distro can contain the full transport jar (or jars) if needed. We *might* want to rethink the strategy if we are to create separate jars for each transport - simply to create less confusion. > > What will be inside default axis2.xml? > The usual entries. Only difference will be that the referenced classes will be in a separate jar file. > Well the best thing, IMO, is to ship the current http transport with the > release, by default and let users download others if they want to use. > The intuition is that most of the time the transport will be http and > will make the life easier for about 90% of the users. Hmm.. again something that we would need to rethink. Recently I've been dragged into a war on 'out of the box' functionality in infoq (http://www.infoq.com/articles/os-ws-stacks-background) and this is one point that may come under it. I would say just ship everything we have right now (having it in a separate jar is a different issue) > Also I'd like to evaluate the impact of this on the HTTP binding > implementation that we have now. I think that also will go out of Kernel. > > ) > Just my 2 cents. Yep - mine too :)) > > Thanks, > Chinthaka > -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] Release process posted to wiki
FYI http://wiki.apache.org/ws/FrontPage/Axis2/release_process Based on the discussion in the mailing list -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Axis2 Maven2 command to build the dist
Hi, I'm not a maven expert but there is a maven assembly plugin that can be used to create the distributions. examples can be found in the xmlschema project. in order to create the distribution artifacts you have to say 'mvn clean install site assembly:assembly' which creates the necessary zip files. (note that you have to create the assembly config files which says what to copy) IMHO it is always better to separate out the tasks for just building the jar and building the distro. We ca have an alias for convenience (which I've no idea how) Ajith On 7/10/07, Saminda Abeyruwan <[EMAIL PROTECTED]> wrote: Yes. There is a profile to create the distribution. IMHO would we need to have a profile to create the distribution? If someone using install phase, it should be a good idea to create every artifact. Thus, users doesn't need to know anything about a profile. Thus, to create ultimate artifacts just need to use mvn clean install , Thank you Saminda On 7/10/07, Thilina Gunarathne < [EMAIL PROTECTED]> wrote: > Thanks Saminda.. > > But you also need to use -Drelease in order to create them.. Following > worked for me.. > "mvn clean install -o -Dmaven.test.skip=true -Drelease" > > Thanks, > Thilina > > On 7/10/07, Saminda Abeyruwan <[EMAIL PROTECTED]> wrote: > > You'll able to find the distributions under modules/distribution/target > > > > Thank you > > > > Saminda > > > > > > On 7/10/07, Thilina Gunarathne < [EMAIL PROTECTED]> wrote: > > > > > > Hi devs, > > > What's the Axis2 maven2 command to create the distribution...Also > > > under what directory will I be able to find the created dists... > > > I tried doing a simple "mvn clean install -o -Dmaven.test.skip=true" , > > > but I wasn't able to find the created distribution artifacts... > > > > > > thanks, > > > Thilina > > > > > > -- > > > Thilina Gunarathne - http://www.wso2.com - http://thilinag.blogspot.com > > > > > > > > - > > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > -- > > Saminda Abeyruwan > > > > Software Engineer > > WSO2 Inc. - www.wso2.org > > > -- > Thilina Gunarathne - http://www.wso2.com - http://thilinag.blogspot.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Saminda Abeyruwan Software Engineer WSO2 Inc. - www.wso2.org -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN][Axis2] Axis2 1.3-RC1 release
As for XMLSchema I posted a RC but did not tag the SVN. What should be the process in making an RC like this ? My understanding was that the build is made with any of the published RC's (in this case Axiom and XMLSchema) rather than snapshots. Ajith On 7/7/07, Asankha C. Perera <[EMAIL PROTECTED]> wrote: Deepal These are things I noted with the RC1: 1. missing log4j JAR from lib 2. better to add the lib folder itself to the start of the classpath (axisserver.sh/bat) - this would help us place java keystores etc in the lib for other purposes easily 3. place default log4j.properties in lib These are not critical bugs, but suggestions for improvement. So I am not sure if you want to include these into axis2 at this stage or not.. thanks asankha Deepal Jayasinghe wrote: > Hi all, > > I have upload Axis2 1.3 RC1 artifact into my apache home location [1] , > please test and make sure all the JIRAs we marked as fixed are there in > the release , in addition to that if you find any issues with the > release please create a JIRA [2] , then we can fix that for next RC. > This release is based on the SVN version number of following projects. > > Axiom : - 553458 > Neethi : 553469 > XML Schema : 553334 > > We have a number of major changes from 1.2 to 1.3 and most of them are > listed in apache axis2 wiki [3]. We have fixed more about 350 JIRA > issues from 1.2 to 1.3 in addition to the following new feature additions ; > - Clustering support > - Doc-lt/bare wsdl generation and run time support (RPC MRs can handle > doc-lit/ bare ) > - Custom deployment support > - NIO transport integration > > Our plan is to make Axis2 1.3 release as mush as stable and robust, so > please help us by reviewing this release candidate. > > > [1] : http://people.apache.org/~deepal/axis2/1.3-RC1/ > [2] : https://issues.apache.org/jira/browse/AXIS2 > [3] : http://wiki.apache.org/ws/FrontPage/Axis2/changesfrom1.2to1.3 > > > Thanks > 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] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (AXIS2-2827) Release process guidelines not showing up after "mvn site"
Hi Glen, I guess the maven 1 and maven 2 site structures are different. So if you generate the site by maven site (instead of 'mvn site') you might get the right site. Ajith On 6/20/07, Glen Daniels (JIRA) <[EMAIL PROTECTED]> wrote: Release process guidelines not showing up after "mvn site" -- Key: AXIS2-2827 URL: https://issues.apache.org/jira/browse/AXIS2-2827 Project: Axis 2.0 (Axis2) Issue Type: Bug Reporter: Glen Daniels Assignee: Chatra Nakkawita Fix For: 1.3 Hi Chatra! I added xdocs/release-process.html to the source tree, and also updated navigation.xml in what I thought was the right way to get it to link in. Unfortunately when I do a "mvn site" to build the site, I don't see a link to the new file on the sidebar, nor does the actual release-process.html file seem to get copied to the target/site directory. Could you take a look and let me know what I've done wrong here? Thanks, --Glen -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] locked=false
I remember a discussion but not sure what was the last decision. I'm ok with it anyway :) Ajith On 6/17/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote: Team, Anyone remember if we decided to get rid of locked=false in the xml's in svn? since that's the default? thanks, dims -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] Quick start guide for Axis2
Hi, I've sent this as a reply to one of the conversations yesterday but this seems worth more interaction from the community. So here is our discussion on user documentation We were discussing the user guide during the hackathon .The general consensus was that the current documentation lacks a 'quick starter guide'. Right now one has to scan through at least 4 pages to get to the first code block which will be annoying if you are looking to use Axis2 quickly [Which is the majority case]. Most of the OSS projects (and even products!) tend to have a quick starter guide which is a one page guide of doing the most common tasks. This is lacking in Axis2 and we ended up outlining this quick starter guide. After all the quality matters more than the quantity in this case. The outline for this quick starter guide is at http://wiki.apache.org/ws/FrontPage/Axis2/userguide. All o you are welcome to let us know what you think about it. The goal is to create a 10 minute one page guide to Axis2 (which explains the basics ) and we suppose that will be the most used (and probably the most needed at this point) piece of documentation for Axis2. -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r547848 - in /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2: engine/AxisServer.java transport/SimpleAxis2Server.java
Hi,
Ok here is a brief explantion of what we discussed during the
hackathon and since it was not extensively recorded in IRC i believe
it will do good to know the thought process and perhaps it will cool
down this heated discussion :)
We were discussing the user guide .The general consensus was that the
current documentation lacks a 'quick starter guide'. Right now one has
to scan through at least 4 pages to get to the first code block which
will be annoying if you are looking to use Axis2 quickly. Most of the
OSS projects (and even products!) tend to have a quick starter guide
which is a one page guide of doing the most common tasks. This is
lacking in Axis2 and we ended up outlining this quick starter guide.
After all the quality matters more than the quantity in this case.
Anyway one important topic that came up in this discussion was the
importance of having simple ways of doing the basic things. So
inspired by Glens shortest possible service deployment testing effort
Deepal wrote this AxisServer. IMO its more of a utility (which
provides a convenience) rather than an API change or a new
functionality addition. If others think it should not be pushed right
now I'm also fine with that but IMHO its a collection of things you
would anyway do to programmatically deploy a service. (Maybe a name
change to something like AxisServerUtility would make it obvious ?)
Does this work for you? please see svn revision 547859.
*new AxisServer(true).deployService("className");
This seems reasonable to me. I have to agree that it would be better
to explicitly state the conditions in this case.
--
Ajith Ranabahu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] maven 1 with java 6 build error
Hi guys, I will add this to the documentation but I found the hard way that there is some error with maven (both 1.0.2 and 1.1RC1) maven:addPath command in Java 6. The bottom line is Axis2 build fails with maven 1.x and Java 6 (at least in Linux) Just letting others know. Drop a mail if any of you managed to run this combination -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 contexts use unsyncronized HashMap instead of Hashtables
IIRC the flip side of the same argument was brought as a reason. Hashtables are slower than hashmaps due to the synching. In how many places do we have to synch if we just use the map ? if there are many I suggest we use the hashtable. However if there are only one or two place where we have to sync then I suggest we keep the maps for performance reasons. Ajith On 6/11/07, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote: +1, then we do not need to add sync block in our code , since hashtable does that for us. Thanks Deepal > Did we had a reason to use HashMaps instead of Hashtables?, which I > belive is the correct approach. Please Comment > > https://issues.apache.org/jira/browse/AXIS2-2794 > > Thanks > Srinath > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] Plan for the hackathon
oops - missed the prefix ! -- Forwarded message -- From: Ajith Ranabahu <[EMAIL PROTECTED]> Date: Jun 11, 2007 1:38 AM Subject: Plan for the hackathon To: Axis developer list Hi all, I am sure the Axis2ers around the world are excited about the hackathon that is about to start tomorrow [Well today - (Monday 11th June) :)] Unfortunately I can only come for half the days but I'm sure any major decision will be reported to the list and the irc will be live as usual (I will participate in the sessions remotely as far as possible) However more importantly we need to outline the objective and layout the things we plan to attack. I will outline some items I felt as important to address while browsing the Jira list. Others are welcome to jump in and correct me in any place that I've missed. Again I believe the objective of this hackathon is to fix whatever is broken in the existing functionality rather than adding or discussing new features. 1. Exception handling Number of issues have been reported about incorrect exception handling, irrelavant exceptions being thrown etc. So it seems that this is something we need to look at more carefully and correct. 2 .WSDL2WS and ADB issues There are number of 'edge cases' reported about WSDL2WS - specially against the ADB binding. While some of these will fall into new features, I suppose we should address all the issues that are against the existing features and make it work for some of those edge cases. 3. Java2WSDL issues There are some blockers reported about Java2WSDL. I believe Java2WSDL works ok for most of the cases but there seems to be some cases we need to answer. Both for WSDL2WS and Java2WSDL, they are the two most 'visible' components for the users and that makes it important 4. Misc There are a ton of small issue that does not specifically fall into a broad category. I'm hoping we can cover most of them by the time we end up fixing the major issues but we could tackle whatever is remaining once the major issues are covered. 5. Documentation While we will not sit and write the user guide once more at this occasion I see this as a time we can add some of the missing javadocs to the source (and also correct some header problems. I see a Jira that says some license headers are not proper) Anything else we can try to tackle in this limited time frame? Ajith Ranabahu -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Plan for the hackathon
Hi all, I am sure the Axis2ers around the world are excited about the hackathon that is about to start tomorrow [Well today - (Monday 11th June) :)] Unfortunately I can only come for half the days but I'm sure any major decision will be reported to the list and the irc will be live as usual (I will participate in the sessions remotely as far as possible) However more importantly we need to outline the objective and layout the things we plan to attack. I will outline some items I felt as important to address while browsing the Jira list. Others are welcome to jump in and correct me in any place that I've missed. Again I believe the objective of this hackathon is to fix whatever is broken in the existing functionality rather than adding or discussing new features. 1. Exception handling Number of issues have been reported about incorrect exception handling, irrelavant exceptions being thrown etc. So it seems that this is something we need to look at more carefully and correct. 2 .WSDL2WS and ADB issues There are number of 'edge cases' reported about WSDL2WS - specially against the ADB binding. While some of these will fall into new features, I suppose we should address all the issues that are against the existing features and make it work for some of those edge cases. 3. Java2WSDL issues There are some blockers reported about Java2WSDL. I believe Java2WSDL works ok for most of the cases but there seems to be some cases we need to answer. Both for WSDL2WS and Java2WSDL, they are the two most 'visible' components for the users and that makes it important 4. Misc There are a ton of small issue that does not specifically fall into a broad category. I'm hoping we can cover most of them by the time we end up fixing the major issues but we could tackle whatever is remaining once the major issues are covered. 5. Documentation While we will not sit and write the user guide once more at this occasion I see this as a time we can add some of the missing javadocs to the source (and also correct some header problems. I see a Jira that says some license headers are not proper) Anything else we can try to tackle in this limited time frame? Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axis2] More Modules and classpaths
Hi, We want to allow people to express constraints on things that may or may not be deployed yet, because that enables constellations of related Modules to be developed without requiring that they all be deployed at once. May be we can add a flag 'skipUnknownPhases' (as an attribute with either true or false values) to the phase rule and make it explicit and obvious ? -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 Architecture problems.
Hi, I will write a summary of the discussion to the list later today (if anyone else wants to go ahead please do - don't wait for me :)) but let me just answer a few concerns first. First of all I was mistaken about the handlers during the last conversation. Now the handlers are stateful (i.e. we are talking about the handler instances) and the different instances of the same handler now have different 'next handler' references. So the issue I was thinking of - single handler being invoked multiple times, can be done without a problem even with this approach. However I have an issue with exception processing. If you look at the current approach the unhandled exceptions thrown by a handler is caught by the engine. (See the while loop from lines 185-229 in class AxisEngine). The engine knows exactly which point of the execution the exception occurred and can take necessary action. However if we do the handler - next approach we cannot get the exception out of the handler that actually threw it. Even if you put a catch block in the previous handler it may not be generic or scalable since there is no guarantee what the next handler is going to be. We can find a way to deal with this (perhaps by sending the exception to a different exception handler utility) but the bottom line is that any unhandled exception will travel upstream and come out of the first handler. The other concern is that now we have to have multiple handler instances. We can patch the current implementation easily to use only one instance of a given handler without incurring any cost (if the current approach of cloning causes memory footprint to increase). However if we adopt this approach of stateful handlers we *have* to make separate handler instances, for the operations that needs it. Remember ajith what you now have is some thing design by many people over the years with the experience they have time to time. So I can not give give you and in detail design on the first place. What I am basically telling is if you think in the way I have explained earlier you would have find easier solutions than given in this solution. Yes - The architecture needs to evolve over iterations. There is no way of figuring out the absolutely correct architecture at the first run :) I also believe that we need to revisit some of the architecture decisions and reconsider some of our decisions since we have a better idea of how things are right now. > II. Things that are deemed very important and inherent part of a SOAP > engine are not put in handlers but implemented as part of the engine > (e.g mustundertand checking) Having a centralized controller makes it > easier for us to handle such things that is your perception. and that is what we are talking about. for me I would suggest to put these to the final handler. which could be a default handler for all messages and which calls to the TS. The thinking behind this was that if such controls were enforced as handlers there is a possibility of users skipping those making the SOAP processing procedure invalid. yes agree. As I explained earlier it is about changing the handler flow. How it affects to the MEP? The only question (with the current Axis2) I have is when we get a request back why it directly goes to the Operational client and invoke receive than doing this at the Transport Receiver. Which we do at the server side. This I'm not so sure why. Deepal will be able to answer this question correctly have a look at this jira https://issues.apache.org/jira/browse/AXIS2-2703 when we receive messages at the server we do not know the operation. So do not know the operational level handler chain to invoke. So what we does is we first invoke global handlers and after dispatching operational handlers. Yes - The service / operation level handlers gets plugged onto the handler chain as soon as the service and the operation is found. (i,e. after dispatching) but we can't mix them. (please correct me if I wrong). if I understood correctl (again please correct me if I wrong) this is the reason why we have some constrains for placing handlers. Partly yes . If you want to put a service specific handler then it has to be placed after the dispatching phase because there is no way of knowing the service (or the operation) before dispatching. In other words if you put something in the global phases it always will always be executed , regardless of the operation and the service. There are some exceptions though. If you take security , if the message is encrypted, there is no way of dispatching (except if the transport provides dispatching information - such as the SOAPAction header in SOAP 1.1 HTTP binding) without decrypting the message. So some handlers for the security module are placed in pre-dispatch phase to avoid this problem. Ruchith will correct me if what I've said right now if
Re: Axis2 Architecture problems.
savvy
guy like Amila, it would be a nightmare for a complete newbie who
wants get his feet wet. IMHO we should have a few documents that
explain these architectural decisions (and the thinking behind them)
and include them in Axis2 documentation.
Finally - can we please keep the subject intact when discussing these
topics ? I've had a hard time tracking the relevant messages since
there was substantial amount of discussion in a thread with slightly
different subject !
Ajith
On 5/30/07, Amila Suriarachchi <[EMAIL PROTECTED]> wrote:
hi deepl,
I agree with you that we have already release the 1.2 and there is no way to
do any changes (even every one agrees as well).
this is a solution came to my mind which would adreess the two issues you
have
raise.
public void next(MessageContext messageContext) throws AxisFault {
InvocationResponse responese = this.invoke(messageContext);
if (responese == InvocationResponse.CONTINUE){
this.nextHandler.next(messageContext);
}else if (responese == InvocationResponse.SUSPEND){
// do nothing
}
}
if we put this method to AbstractHandler we can preserve the
API and enforce to return a value.
thanks,
--
Ajith Ranabahu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 Architecture problems. ... not any more ;)
Hi, 5. Again, as Ajith mentioned also, we do not know the handler chain before hand. IIRC, we have templates of handler chains and we clone from it to get the fixed set of handlers. But after that we need to include service and operation specific handlers. Ajith, yes we do have service specific handlers and it is useful. For example engaging modules per service basis using WS-Policy. It is not just a "possible" use case, people do use it. Thanks for the clarification :) I was actually thinking more of the operation specific handlers. I believe the reason why we replicate that handler chain at the operation level is to support not just service specific handlers but also operation specific handlers. Now that I've taken a closer look again at the things, I see that we provide the functionality to engage specific modules 'per operation' (in which case a operation specific handler chain is needed). Anyway there is always the possibility that a user may need his/her own handlers to be engaged per operation. However we may be able to improve a bit of the code :) Since the handlers are stateless replicating them would not mean anything (shouldn't make a difference). Should we able to create a read-only List implementation where only one of the handler instances exist in the engine ? -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 Architecture problems.
Hi Amila, Here are some of the answers to your questions. I believe other will chip in with whatever they can contribute (and ofcourse correct me if I'm wrong :)) but I will try to answer as many of your questions as possible. 1. AFAIR the primary reason why the operation client is implemented as a centralized controller is that we need to support different MEPs. Axis engine nor the handlers would know nothing about the MEPs and there would be no need. The only MEP specific implementation would be the operation client and that will invoke the Axis engine as many times as needed to complete the MEP. This is not so obvious right now since the primary MEPs we encounter are in-only and in-out. But WSDL2.0 is around the corner and supporting multiple MEPs would be of great importance to a framework that supports WSDL2.0. 2. I believe the reason to clone and add the handlers as a new list was that it was expected that there would be service specific and operation specific handlers. I'm not sure how much we've seen this being useful, or even whether we support this in the current code. We may need to take a look at this code once again though. 3. Fault flow is separated (treated specially) since there could be a need for the handlers to make use of the fact that its a fault (Say something like a rollback of some database update which happened during the inflow). If we use the usual message path, this will require a number of logical statements to determine whether its a fault or in the worst case, reading upto the first child of the SOAP body to determine whether its a fault (which destroys our advantage of streaming). Treating faults separately gives us the advantage of tackling that case easily. However there is an issue when the message cannot be determined before hand to be either a fault or a non-fault response. This particularly happens in the asynchronous reply case (over HTTP) where there is no HTTP information regarding the nature of the message.(in contrast, the sysnchronous HTTP case can be dealt with very easily since the HTTP code 500 will indicate a SOAP fault). I'm not sure what happens when the messages are encrypted (whether the HTTP code will still be indicating the fault). We once discussed this in much detail and the decision was (AFAIR) is to switch the flow as soon as possible (i.e. the first point we detect the message to be a fault) I think this is something we should look back at but I psersonally think keeping a fault flow will be useful. Thanks Ajith On 5/28/07, Amila Suriarachchi <[EMAIL PROTECTED]> wrote: here with I have attached the pdf format. On 5/28/07, Amila Suriarachchi <[EMAIL PROTECTED] > wrote: > hi, > here with I have attached an document which describes some of the problems > I see with the current axis2 architecture and a possible solution. > > Please have a look and put your comments. > > Amila. > > -- > Amila Suriarachchi, > WSO2 Inc. > -- Amila Suriarachchi, WSO2 Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axis2] Release process
Hi, This is covered explicitly: oops - my quick reading skipped that part :( Sorry for the confusion but now its all clear. In any case my +1 is unchanged :) -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axis2] Release process
Hi Glen, This is great and definitely +1 Here is something that we need to talk about concretely. When fixing the bugs for the release how would the commits happen ? I mean do we do the changes to both the branch and the trunk at the same time or is it the release manager who has to do the merging ? On 23/04/07, Glen Daniels <[EMAIL PROTECTED]> wrote: > Hi Axis2 developers: > > In an effort to coalesce some recent discussion into a policy, here is a > proposal for how we should manage releases and dealing with SVN. If we > can agree on this, I'll check in an HTML version, and we can start > following these guidelines for our next release. > > This is important stuff, please take a moment to read it over and see if > you agree with the principles. The goals are 1) minimize "speed bumps" > to active development, 2) make it easy to manage releases both as > they're going out and for future bug fixes, 3) make sure we don't lose > anything and also avoid giant merges. > > Please chime in with +1/-1 and/or comments. > > Thanks, > --Glen > > === > > --- Cutting a branch > > * When a release is ready to go, release manager (RM) puts forward a > release plan as per standard Apache process, including dates. This gets > VOTEd on by the committers. During this period the trunk is still the > only relevant source base. > > * As soon as a release is approved (or even before), RM should add the > new version into JIRA as a target. > > * At the point where we would normally do the "code freeze" for a > release, the RM cuts a branch named for the release. This branch is > where the release candidates and releases will happen. > > * Ideally a release branch is only around for a week or maybe two before > the release happens. > > * The only things that should EVER get checked into the release branch > are - 1) bug fixes targeted at the release, 2) release-specific updates > (documentation, SNAPSHOT removal, etc). In particular new functionality > does not go here unless it is a solution to a JIRA report targeted at > the release. > > * Normal development continues on the trunk. > > --- Dependencies and branches > > * The trunk should always be "cutting edge" and as such should usually > be pointing at SNAPSHOT versions of all dependencies. This allows for > continuous integration with our partner projects. > > * Soon after a release branch is cut, the RM is responsible for removing > ALL dependencies on SNAPSHOT versions and replacing them with officially > released versions. This change happens only on the release branch. > > --- Managing change and issue resolution with a release branch > > * The RM goes through JIRA issues and sets "fix for" to point to both > "NIGHTLY" and the new branched release number for the fixes that are > targeted for the release after the branch is cut. > > * In general, the assignee/coder fixes JIRA issues or makes other > changes *on the trunk*. If the JIRA issue is targeted at the release, > or upon coder's discretion, they then merge the fix over to the release > branch. > > * This way the trunk is ALWAYS up-to-date, and we don't have to worry > about losing fixes that have only been made on the release branch. > > * When the assignee resolves an issue, they confirm it's been fixed in > both branches, if appropriate. > > --- Checking changes into the branch > > * If bug fixes are needed later for a release which has long since > happened (to fix user issues, etc), those fixes generally should also > happen on the trunk first assuming the problem still exists on the trunk. > > * There are only two cases where we would ever check anything into the > branch without first checking it into the trunk. 1) Release specific > items (release number references, release notes, removal of SNAPSHOTs), > and 2) if the trunk has moved on in some incompatible way. > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- David Illsley - IBM Web Services Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN][XMLSchema] XMLSchema 1.3.1 Released
We are pleased to announce the release of Apache XMLSchema 1.3.1 of Apache WS-Commons.This release includes numerous bug fixes and a new feature addition that enables users to register extension types with the schema parser.The binary, source and document releases are available at http://ws.apache.org/commons/XmlSchema/download.cgi XMLSchema is a lightweight schema object model that can be used to manipulate and generate XML schema representations. It has no external dependencies and can be easily integrated into an existing project. You are welcome to kick the tires and get XMLSchema on the move. If you like to help us shape XMLSchema, any contribution in the form of coding, testing,submitting improvements to the documentation, and reporting bugs are always welcome. Thank you for your interest in XMLSchema! - The XMLSchema Development Team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2][XmlSchema] XMLSchema RC3
Hi all, I fixed almost all the bugs that were reported and placed an RC-3 in the same location [1]. Please test :) -- Ajith Ranabahu [1] http://people.apache.org/~ajith/xmlschema/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axis2] locked="false"
Hi, While I'm +1 for removing the explicit locked="false" attributes It may not be right to trash the concept right away. IMHO I see that this may become useful if Axis2 is in a hosting environment and the host would not want any of his users to override his settings. So I would say interpret the absence of the attribute as a 'false' but keep the concept Ajith On 3/22/07, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: Not only do I not mind it but can you please also remove the entire concept? AFAIK we have *never* found a need for the "locked" vs. "unlocked" concept .. so let's just dink it. YAGNI and all that. Sanjiva. Glen Daniels wrote: > Anyone mind if we remove the explicit locked="false" attributes from > most of the parameters in the default axis2.xml? > > --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/ Director; Open Source Initiative; http://www.opensource.org/ 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] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axiom] [axis2] Coding style
Hi all,
LOL :) Seriously, though, someone probably does need to own the
structural part (making sure that we have common utilities for getting
messages and finding resource files). The actual work of moving the
messages into resource files and changing the code should be a task that
we split up and everyone shares... ApacheCon EU's hackathon might be a
good time for this kind of thing
We do have this framework in place. However rather than keeping
everything in one place we made i18n sections in each module so that
each module has its own lang property file (I'm guessing we probably
did that after moving out Axiom). If you look at the source trees of
the modules kernel, codegen, adb-codegen etc, the i18n package
includes the language property files.
One drawback in the way we have right now is the copying of the
resources class. I believe that each module should have its own lang
file (surely it would be impractical to maintain a huge property file
with every string used in every class in every module!) but perhaps
the resource loading class can be maintained separately in one place ?
Right now its all static.
>> 2) When generating exceptions like this, it really isn't very useful to
>> say "received some other implementation" or "value wasn't what was
>> expected". It's much more helpful to actually put the problem value
>> into the exception In this case it only takes an extra moment to code
>>
>>"but received " + reason.getClass() + "."
>
> 1000 appologies for this code written by me some time back. Won't happen
> again :(.
Don't take it personally (I was hoping for a ":)" instead of a ":("), we
really do have these kinds of issues everywhere and we ALL do this stuff
sometimes. I just happened to notice this a bunch of places and think
it's useful to remind ourselves of patterns.
--Glen
-----
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ajith Ranabahu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [AXIS2] Added xsdconfig support for wsdl2java
Hi, This is cool and we are glad to accept such enahancements :) Here is what you should do. 1. Create a patch - this is quite easy to do in svn - if you are in windows with tortoise SVN client, right click on the axis2 source folder and say create patch. For the linux command line client I guess the command would be svn diff. 2. Create a Jira (say "Improvements to XMLBeans codegen") and attach the patch file. There is an agreement that says you are allowing Apache to use it. Dont forget to say yes :) Commiters can apply the patch only if you say yes to that agreement. This should do it. Then we can look at the code and apply the patch and add the new bit of fuctionality to the codebase Ajith On 2/3/07, Alistair Young <[EMAIL PROTECTED]> wrote: Hi there, I needed xsdconfig support when using XMLBeans data binding during building from WSDL, so I've added it to Axis2 1.1.1. Is it possible to distribute it for approval? I've modified the classes: org.apache.axis2.xmlbeans.CodeGenerationUtility org.apache.axis2.wsdl.codegen.CodeGenConfiguration org.apache.axis2.wsdl.codegen.CodegenConfigLoader org.apache.axis2.util.CommandLineOptionConstants.WSDL2JavaConstants org.apache.axis2.wsdl.util.WSDL2JavaOptionsValidator and added a new class: org.apache.axis2.wsdl.util.XSDConfig I've added two new options for wsdl2java: -xc FULL_PATH_TO_XSDCONFIG_FILE -xsdconfig FULL_PATH_TO_XSDCONFIG_FILE At the moment I just support: Axis2BindingConfig::lookupJavanameForQName as the package name mapping native to XMLBeans clashes with: Axis2BindingConfig::lookupPackageForNamespace Alistair -- mov eax,1 mov ebx,0 int 80h - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [continuum] BUILD SUCCESSFUL: Axis2
Hi David, Just a thought - it would be nice if the online report is accessibe from the outside - I mean the link without 'localhost' but a real address :) -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Wrong links in the downloads section
Hi guys, I found that some of the tool links in page http://ws.apache.org/axis2/tools/index.html are wrong. Specifically the file names are listed in the link in camel case (like Axis2_Service_Archiver.zip) but the actual file name is all lower case. This results in a 404 when you try to download. -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Additional Axis2 documentation (Was : Axis2 web services on OracleAS OC4J)
Hi all, After seeing this post I felt that we should have some documentation that explains such known issues with servlet containers other than tomcat, as part of the Axis2 documentation. This would be useful rather than asking people to sift through the JIRA issues. Ajith -- Forwarded message -- From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Jan 23, 2007 9:39 AM Subject: Re: Axis2 web services on OracleAS OC4J To: axis-user@ws.apache.org I finally managed to allocate the source of the problem. There is an apache http server around the oc4j and this server , when chunked encoding is used, returns 503 - service unavailable because of CONTENT LENGTH !! problem. So I used HTTP 1.0 and avoided this mess. But there is still one problem when I use encrypted (using latest rampart) soap messages. In OC4J I encouter this error: [AJPRequestHandler-ApplicationServerThread-7] DEBUG org.apache.rampart.handler.WSDoAllReceiver - WSDoAllReceiver: exit invoke() [AJPRequestHandler-ApplicationServerThread-7] DEBUG org.apache.axis2.transport.http.AxisServlet - org.apache.axis2.AxisFault: WSDoAllReceiver: security processing failed; nested exception is: org.apache.ws.security.WSSecurityException: Cannot encrypt/decrypt data; nested exception is: java.lang.IllegalArgumentException: No attributes are implemented [AJPRequestHandler-ApplicationServerThread-7] DEBUG org.apache.axis2.addressing.AddressingHelper - isReplyRedirected: FaultTo is null. Returning isReplyRedirected It looks like wrong documentBuilder, because at first decrypted xml is printed on the screen... __ Od: [EMAIL PROTECTED] Komu: "axis-user" Datum: 22.01.2007 19:25 Předmět: Axis2 web services on OracleAS OC4J Hi, has anyone managed to configure any web service using Axis2 on Oracle Application Server? I even tryed to deploy axis2.war on Tomcat and OracleAS on the same machine. Whereas on Tomcat everything works just fine, on OracleAS when I want to sumarize "validation" all libraries and resources are available, but in the part devoted to examination of the version it says: service is not available. The very same problem I have when I use my own project based on web services. thanks in advance for any information, frogg - 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] -- Ajith Ranabahu
Re: [Axis2] Giving custom names for stubs and skeletons
Hi, Nope. Right now the stub/skeleton names are made using the service name as the source and adding relevant suffixes (like stub,skeleton) Ajith On 1/22/07, Eran Chinthaka <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Is there anyway to give custom names to the stubs and skeletons that we generate? For example, I like to name my stub as MyOwnStub rather than the name GetQuoteServiceStub given by the code-generator (presumably using the WSDL service information). - -- Chinthaka -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFtYP7jON2uBzUhh8RAnD9AKCJ7C/yPHjY0FZAsqT6w9Y+232ZtwCeK9lH Ha2a0GHTKhlIwG255/bTZmc= =OuU1 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Passing databinding specific parameters
Hi, Easter eggs ;) Its open source so all easter eggs are in plain view :)). BTW the extra parameters are documented in [1] and the ADB[2] and Jibx [3] guides also document how to use these extra parameters. Anyway supporing all the parameters the XMLBeans compiler supports is a bit tricky since we are directly invoking the internal compileXMLBeans method. If you look at the XMLBeans main class (called through the scomp bat/sh file) there are a number of objects created by looking at the users parameters before compilation. We are generating some of these parameter-related objects to suit the Axis2 environment and call the internal compile method directly rather than calling the main method. I'm sure some tweaking would be possible but I'm not so sure whether we will be able to support the full set of XMLBeans tweaks. Ajith [1] http://ws.apache.org/axis2/tools/1_1/CodegenToolReference.html [2] http://ws.apache.org/axis2/1_1_1/adb/adb-codegen-integration.html [3]http://ws.apache.org/axis2/1_1_1/jibx/jibx-codegen-integration.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Passing databinding specific parameters
Sorry for the delay we already have a mechanism and a convention for this :) the user can pass databinding specific parameters by preceding them with -E. Say for adb you can pass -Eh for helper mode. [to be exact these are extra parameters which can be utilized by ANY extension. One can pass adb specific params while code generating for XMLbeans where the extra parameters would be completely ignored] The codegenerator does not process these but merely stores the args and the values in config info bag so that any extension can use it. We already have such parameters for ADB, and jibx. I don't think we have anything for XMLBeans yet but its definitely possible. Ajith On 1/21/07, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote: +1 for the approach. Thanks Deepal > When we invoke WSDL2Java, providing a databinding name, how about > allowing the user to pass some parameters to the databinding framework > as well. > > For example, when the user is asking to use XMLBeans as the data binding > framework, then isn't it better if we let the user pass some parameters > to XMLbeans, like generate jdk 1.5 code, etc., (see [1] for set of > params you can pass in to XMLBeans). We can easily do this by getting > those inputs, with the WSDL2Code, and just passing them to the > databinding framework when we invoke the schema compiler. > > What do you all think about this? > > -- Chinthaka > > [1] : http://xmlbeans.apache.org/docs/2.0.0/guide/antXmlbean.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Deepal "The highest tower is built one brick at a time" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][Axis2] Move Savan module out of the Axis2 into a new Apache WS subproject
+1 Ajith On 1/19/07, Brian De Pradine <[EMAIL PROTECTED]> wrote: +1 from me. Cheers Brian DePradine Web Services Development IBM Hursley External +44 (0) 1962 816319 Internal 246319 If you can't find the time to do it right the first time, where will you find the time to do it again? "Sanka Samaranayake" <[EMAIL PROTECTED]> wrote on 19/01/2007 05:00:27: > Hi, > > Savan is a WS-Eventing implementation on top Axis2 and currently > lives as a module inside Axis2. > > I propose we move it into a separate Apache WS sub project which > will make Axis2 codebase clean > and also to do separate releases of Savan. > > Here is my +1 !! > > Thanks, > Sanka > > > -- > Sanka Samaranayake > WSO2 Inc. > > http://sankas.blogspot.com/ > http://www.wso2.org/ -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Maven2 for Axis2 1.2?
Hi Tom, I am neither an Ant fan nor a maven fan but I believe in picking the "right tool for the job" :) In terms of ease of maintenance and improved functionality i would say maven is a better tool for the job than Ant. I don't think dumping maven completely would be seen as a possible alternative :) Ajith On 1/15/07, Tom Jordahl <[EMAIL PROTECTED]> wrote: Chiming in *really* late on this thread, but I still don't see the advantages to Maven over JPA (Just Plain Ant). Sure seems like Axis2 spends more time worrying about Maven than we all did in Axis1 land rewriting our functional test system (and complaining about what we ended up with ;-). Why don't you just get rid of it entirely? Bet your build would go fast then. -- Tom Jordahl "Grump old Axis 1.x developer" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO databinding extension for Axis2
Hi, There is an artilcles about how the code generator works here [1]. I guess that should be helpful as a start Ajith [1] http://wso2.org/library/35 On 1/8/07, chen congwu <[EMAIL PROTECTED]> wrote: I have just read through the data binding module in axis2, in my opinion, a new data binding framework can be supported by developing the following utility classes, that is the Extention class which engaged the data binding libs at runtime. A CodegenerationUtil class which extract the schema information from the wsdl and call the binding frame- work's schema compiler to generate data classes. Get the type mapping information, register into the Code generation core module. A XSLT trans- form file which can be used by the code generation module with the reg- istered type mapping information to generate the service skeleton and client stub. In addition, the "Tuscany WS" means ws developed by SCA specification. --- Graduate Student with Institute of Software, China Academy of Sciences, China Comain Chen Mail: [EMAIL PROTECTED] ,[EMAIL PROTECTED] -邮件原件- 发件人: Angel Todorov [mailto:[EMAIL PROTECTED] 发送时间: 2007年1月8日 22:32 收件人: axis-dev@ws.apache.org 抄送: [EMAIL PROTECTED] 主题: Re: SDO databinding extension for Axis2 Hi Anthony, Thanks for the info. What exactly do you mean by "Tuscany WS support" ? Also, is there any in-depth tutorial that describes how custom data binding extensions can be wired into Axis2 ? For now i see the only way is to browse through the source code of the codegen , including adb / xmlbeans ..., etc , extensions. Thanks in advance. Regards, Angel On 1/8/07, Anthony Elder <[EMAIL PROTECTED]> wrote: > Yes the Apache Tuscany project has integrated SDO with Axis2 and the > tooling like WSDL2Java, however at the moment it only works with the > Tuscany WS support. There was talk of creating an Axis2 data binding for > SDO that works outside of Tuscany...its mainly a matter of time and > priorities. People like you showing interest could help to get it done. If > we did this would you use it? Would you like to help to do it? > >...ant > > Tuscany dev. > > > > "Angel Todorov" <[EMAIL PROTECTED]> on 08/01/2007 10:03:34 > > Please respond to axis-dev@ws.apache.org > > To:axis-dev@ws.apache.org > cc: > Subject:SDO databinding extension for Axis2 > > > Hello Axis2 dev team, > > I have several questions regarding the integration of SDO into Axis2's > databinding framework: > > 1) Is an SDO extension already available in some release of Axis2? > 2) If not, is implementing the AbstractDBProcessingExtension the only > thing that has to be done, in order to be able to specify SDO as a > parameter to WSDL2Java ? > > 3) I saw that the Tuscany project have some discussion about SDO <=> > Axis2, but i am still not sure whether tuscany has already done the > SDO integration. Do you have any idea what the status is ? > > Thanks very much for your feedback. > > Best Regards, > Angel > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu
Re: [Axix2] [Vote] Move rampart, rahas and secpolicy modules of axis2 out into a new project
Hi, I have to agree 100% on the effectiveness of the integration tests, specially the ones with security and I know in many cases we ended up finding bugs in non-security code due to the security tests. In effect it means that these tests need to be there somewhere to run constantly to figure out whether there is a problem. One thing I wanted to point out was that this is true for all sub projects - including sandesha , rampart and any other part of Axis2 we think of moving out to a seperate project. Also there can be issues with certain combinations of these modules (Say Sandesha and Rampart together makes some weird problem but Sandesha alone and rampart alone runs fine). Where would this kind of 'mixed up' tests reside ? Here is my suggestion. We move all the integration 'cross project' tests into a seperate project , something like 'Axis2 Integration'. This project will contain only unit tests and depend on Axis2 and all its sub projects. Since we are running continuum it can detect any of the test failures in the integration project. Eran has a point about many commits being done upto an integration failure (which makes it hard to detect the erroneous commit). What I think is by increasing the frequency of continuum (say 4 hours or 6 hours instead of 24 hours) we can sufficiently mitigate the risk. IMHO this would decrease the build time of Axis2 and also gives us a clear place to put all the cross project tests. Ajith On 1/7/07, Eran Chinthaka <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Illsley wrote: > I'm dead against moving security out of the axis2 build and leaving a > substantial amount of security tests in the axis2 builds. The converse > to an earlier argument is also true, namely that axis2 becomes > dependant on rampart to build and that people working on rampart won't > see the axis2 build failures. +1. And +1 for setting up the continuum build. But this is different from the point I wanna make. Forgive me if my explanation made you all think some thing else. What I was continuously pointing out was lack of integration tests Axis2 has on its own. The security tests Ruchith had written, which are in integration module, were testing the real Axis2 integration stuff together with his security scenarios. What I was asking is to understand the exact integration scenarios those security tests are testing, in security tests, and write new set of tests Axis2, without depending on security or any other tests. Let me give you an example. IIRC, Security scenario 1 test fails, if the addressing handlers are not engaged. This tests, the module deployment functionality, handler integration mechanism, execution chains and the addressing module. If we move this scenario 1 test out from Axis2, then what I ask is some one to write a new tests to test the above functionalities. Please understand that I never wanted to keep security tests inside Axis2, when the rampart is moved out. Yes I also against it. One could argue that continuum will fix the problem. But IMHO, it won't. The reason is none will check with continuum for each and every commit. So the only option is to run continuum as a cron job, once a day. By the time continuum fails and generates a mail, there can be numerous commits done to the commit. So everyone is having trouble fixing the problem. Since I believe in prevention than cure :), let's add some more integration tests in to Axis2, to fill the vacuum created due to the removal of security tests. Since we always run all the tests in Axis2, before committing anything, you will get to know the problem before hand, rather than waiting for continuum. But yes, continuum will point out the effect of a change in Axis2 to some other dependent project. But the changes I am referring are critical for Axis2. When I was doing changes to Axis2, getting the integration tests passed, especially the security tests, was the most challenging part, at least for me. I assume it is the same for everyone out there. Ruchith, you can remember we talked about this some time back, meaning the importance of security integration tests. If what I am talking is unclear, please add more to this discussion. Thanks, Chinthaka -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFoRuojON2uBzUhh8RAr23AJsF/4oxi6n/PJOPNisdZlKYtKqheACgmSDv W7zOCQWxprF0yVzXL/w88zw= =x9pa -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [AXIS2] MTOM Policy assertion
I also have to agree with Thilina. This is something like savan , which we can initially put under the Axis2 tree and move out later if needed. It is better to leave neethi alone without cluttering it with other stuff such as specific policy assertions. Ajith On 1/7/07, Sanka Samaranayke <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I agree with Thilina. Apache Neethi provides extension mechanism where domain specific types can be used as assertions. The framework provides processing model to combine and interpret them. IMHO MTOM policy assertions are yet another extension. Therefore it doesn't belong in Neethi rather in Axis2. Best, Sanka Thilina Gunarathne wrote: > AFAIK Neethi is the policy framework.. The concrete implementations > like these stay in the relevant locations.. Ex: sec policy resides in > Axis2 & will get moved with security.. > > IMHO this needs to go in to Axis2. > >> It is also used for optimizing encrypted attachments. So should it go >> to Neethi, because it is used both by Rampart and Axis2. > Rampart anyway depends on Axis2.. So i don't see any issue in putting > it to Axis2. > > Thanks, > ~Thilina > > On 1/5/07, Dimuthu Leelaratne <[EMAIL PROTECTED]> wrote: >> It deosn't depend on Axis2. >> >> -Dimuthu >> >> On 1/5/07, David Illsley <[EMAIL PROTECTED]> wrote: >> > IMO If it doesn't depend on axis2 classes it should go into >> neethi. If >> > it does it should go in Axis2. >> > >> > David >> > >> > On 05/01/07, Dimuthu Leelaratne <[EMAIL PROTECTED]> >> wrote: >> > > Hi Deepal, >> > > We can argue both ways. >> > > >> > > This policy assertion will be mainly used by Axis2 to optimize >> binary >> > > data. So it should go to Axis2. >> > > >> > > It is also used for optimizing encrypted attachments. So should >> it go >> > > to Neethi, because it is used both by Rampart and Axis2. >> > > >> > > Thanks, >> > > Dimuthu. >> > > >> > > On 1/5/07, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote: >> > > > Hi Dimuthu ; >> > > > >> > > > If it is Axis2 specific then , it should go to Axis2 .o.w to >> Neethi >> > > > >> > > > >> > > > Thanks >> > > > Deepal >> > > > >> > > > >> > > > > Hi All, >> > > > > >> > > > > I am coding MTOM Policy assertion mentioned in >> > > > > http://blogs.cocoondev.org/dims/archives/003534.html >> > > > > >> > > > > >> > > > > I coded a builder and the relevant model for the policy >> assertion. The >> > > > > problem is where to put the implementation? To which >> project should >> > > > > this belong to? >> > > > > >> > > > > We can put this in "Axis2" or "Neethi". >> > > > > >> > > > > Thanks, >> > > > > Dimuthu. >> > > > > >> > > > > >> - >> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > > > > For additional commands, e-mail: [EMAIL PROTECTED] >> > > > > >> > > > > >> > > > > >> > > > >> > > > -- >> > > > Thanks, >> > > > Deepal >> > > > >> > > > "The highest tower is built one brick at a time" >> > > > >> > > > >> > > > >> > > > >> - >> > > > 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] >> > > >> > > >> > >> > >> > -- >> > David Illsley - IBM Web Services Development >> > >> > >> - >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - -- Sanka Samaranayake WSO2 Inc. http://sankas.blogspot.com/ http://www.wso2.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFFoR8N/Hd0ETKdgNIRAireAJ9VFH7Q+80GTvmXlsgtYrZVg/4p2wCfbasn yQDtK3EMIfNJwPFoI4S4O5w= =rhje -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axix2] [Vote] Move rampart, rahas and secpolicy modules of axis2 out into a new project
+1 -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2]Re: ZipException
Hi, I'm assuming that you are using Axis2 and trying to make an aar file. There is no unjar/unzip operation going on at that stage so the most likely thing to happen (for a file not found exception) is the failure to create the directory structure. So first check whether you have the permissions to create directories. Also some more information about the error (like the stacktrace) would be helpful. BTW are you on windows or linux ? Ajith On 12/28/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Experts, When I try any quickstart example for generate.service, ANT throws an exception java.util.zip.ZipException , system could not find the file specified. It doesnt show which file it is trying unzip or unjar. I believe this issue is related to a file getting into classpath which java is not able to unjar. I am using ant 1.7.0 which is released recently. I just stuck because of this . please help. Thanks - Sudhir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Modules for databinding
Hi Thilina, Would there be a lot of changes in the branch that would need to go into the trunk ? I'm not so sure whether breaking up the modules before the merge would be a good idea :) Ajith On 12/25/06, Thilina Gunarathne <[EMAIL PROTECTED]> wrote: I'm +1 for that... IIRC JAXBRI is already separated out to a module.. So the only thing left is JAXME... We don't have to wait till the release.. Feel free to work in the trunk as the release goes on the 1.1 branch... ~Thilina On 12/26/06, Ajith Ranabahu <[EMAIL PROTECTED]> wrote: > Hi guys, > I hope you guys remember we had some discussion about how databinding > frameworks should be handled and we came to a conclusion that every > databinding framework should go into a new module (and invoked by > reflection through the relevant databinding extension). Following this > philosophy ADB, JibX and XMLBeans have been moved to seperate modules. > However I see that some of the databinding frameworks such as jaxme > and Jaxb are still in the old style. This I think needs to be > corrected (after the current pending release ofcourse :) which means > the changes would go into the trunk after the merge) > I do see a small disadvantage though. It increases the number of > modules! I'm not sure how a zillion modules will look in the eyes of > others :) > > Any thoughts of how we go about doing this ? > > -- > Ajith Ranabahu > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Thilina Gunarathne WSO2, Inc.; http://www.wso2.com/ Home page: http://webservices.apache.org/~thilina/ Blog: http://thilinag.blogspot.com/ ----- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] Modules for databinding
Hi guys, I hope you guys remember we had some discussion about how databinding frameworks should be handled and we came to a conclusion that every databinding framework should go into a new module (and invoked by reflection through the relevant databinding extension). Following this philosophy ADB, JibX and XMLBeans have been moved to seperate modules. However I see that some of the databinding frameworks such as jaxme and Jaxb are still in the old style. This I think needs to be corrected (after the current pending release ofcourse :) which means the changes would go into the trunk after the merge) I do see a small disadvantage though. It increases the number of modules! I'm not sure how a zillion modules will look in the eyes of others :) Any thoughts of how we go about doing this ? -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axis2] release planning
Hi, As much a fan I am for 'release early release often', I have a feeling that two months of development may not yield enough changes to fully constitute a release (just a feeling though). So would it be sensible to do 4 month develop/test/release cycle rather than a 3 month one ? (3 months development ,1 month test/bugfix/document altogether 3 releases per year) The time gap allows the gathering of more usecases and gives people room to play around. By the time we get to the next 'bug fix' stage, people would have played around with the earlier release and found all the issues. Ajith On 12/19/06, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote: I am big +1 for this approach. Let's start that process immediately after 1.1.1 release . Thanks Deepal Sanjiva Weerawarana wrote: >Folks, I'd like to suggest that we try to do 3-monthly releases .. with >2 months of development and one more of wrapping up / packaging. I'm >motivated to suggest this after the debacle of the 1.1 release .. we >spent more than *6 months* releasing it and to me that's just crazy. > >Release early, release often is an important open source mantra. Given >that we're still in a fairly rapid innovation mode, this is even more >important. > >This also will force us to work thru a bit of a roadmap so users know >what features to expect in what version (to whatever extent possible to >do that in an open source project .. I'm not suggesting we plan >everything). > >Thoughts? > >Sanjiva. > > -- Thanks, Deepal "The highest tower is built one brick at a time" ----- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 - Client refactoring
Hi would it be possible to state the changes that are planned - perhaps a small writeup ? Ajith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 1.1 : java2wsdl Tool FlattensObjects in Schema
Hi, Perhaps you can try with options in the java2wsdl tool (Axis 1.4 version) to generate a doc/lit WSDL and try with it. I guess the defaults for Axis 1.4 java2wsdl is rpc/encoded ? (not sure though) Ajith -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][VOTE] Axis2 1.1.1 release
20th November ?? (I hope you meant December) - I'm +1 as long as we fix all the blockers :) Ajith On 12/14/06, David Illsley <[EMAIL PROTECTED]> wrote: +1 for a bug-fix release. Given the questions that have arisen, maybe a comment about Java6 would be a good addition to the release notes. David On 14/12/06, Thilina Gunarathne <[EMAIL PROTECTED]> wrote: > Hi all, > It's been almost a month since the 1.1 release. I feel the time is > right to do a 1.1.1 bug fix release, since there have been a > considerable number of bug fixes over 1.1. > > Most of the fixes that went to the 1.1 branch were related to > performance improvements. > > I propose to do the 1.1.1 release on Wednesday 20th November. > > Here's my +1 for the 1.1.1 release. > > -- > Thilina Gunarathne > WSO2, Inc.; http://www.wso2.com/ > Home page: http://webservices.apache.org/~thilina/ > Blog: http://thilinag.blogspot.com/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- David Illsley - IBM Web Services Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] More questions on WSDL2Java options
Hi, Which are the valid values for the attribute "dbf"? adb, xmlbeans, jaxme, jibx, jaxbri? Yes, basically the databinding types that are registered with the system (see the codegen.databinding.frameworks entry in the codegen-config.properties file) are allowed here What happens if the properties of the existing classes don't match the datatypes defined in XSD. Does the code generator check that? Nope - usually what happens is that the extension that processes this is at the last (or near to the last) of the extension chain so there it overrides the whatever the populated mappings. Its upto the user to determine whether he wants to use custom mappings or not and when he does so it becomes his responsibility to make sure the classes are compatible! The system just copies the entries in the file to the internal mapping structure. Just to make sure that I got this right: this option is about the method signatures in the classes, *regardless* of the SOAP message style that is used. Or does this option only apply if a particular SOAP message style is used? Well kind of - The rpc/lit style is the primary style we can unwrap but if the schema is compatible you can even unwrap a doc/lit WSDL. However the system, when unwrapping is specified, tries to unwrap regardless of the style. If this option is for ADB only, shouldn't it be -Euw instead? No - even XMLBeans can be unwrapped (And jibx too) . So its a top level option rather than a specific one. Yes, the classnames look more like Axis 1.x. But they are still dependent on Axis2 libs. So why would I want to use this option? Can you give an example when this is needed, please. Think of it as this. The skeleton is not dependant on any Axis2 Specific libraries (unless you use either ADB or no databinding - even in the ADB case the helper mode will cause plain java beans to be generated with no traces of Axis2 specifics). If you do have a Axis1 skeleton already written then you can actually just place that class and make it work in this case (perhaps with minor modifications but no big changes that span the whole set of generated classes) HTH -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] More questions on WSDL2Java options
Hi Thilo, Here are some small explanations of what each option does -r: specifies the repository against which the code is generated... What effect does this have on the result? When would this be useful or what's the use case? The usecase for this is codegenerating with a WSDL that has WS-Policy statements. When you have policy statements the system should know what the assertions are and how to deal with them. This is done by using the modules in a repository and hence a repository needs to be pointed out. This has no effect if you don't have any WSP entries in your WSDL. -em: this is to specify an external mapping file. For what kind of mapping? External databinding mappings. There has been numerous cases where users wanted to use the classes they already have (say the XMLBeans classes they've already generated seperately) rather than codegen generating them. The mapping file is an xml file in the following format localName type Note that the mapping element can be repeated. So basically the system picks up classes that are specified rather than generating them. However you can specify only the ones that you want to replace where the system will generate the rest. - uw: switches on unwrapping. Of What? Does this refer to wrapped SOAP message style? Where can I find an example? I guess Dennis gave a good explanation of this. ADB unwrapping indeed works but it may 'glitch' in some extreme cases. Anyway the noticeable change for the user is the change in the method signature. -b: I can see what this option is doing, but what is the actual purpose of it?? Backward compatibility flag. This basically drills down to the naming of the classes that are generated. When the flag is on, the generated class names are compatible with the Axis 1.x style ( that is why its called backward compatible flag :)) I also found that the official User Guide documents different sets of options for the command-line tool and the Ant task. Both sets are again different from the set of options that is diplayed in the usage information when invoking WSDL2Java at the command-line. This should be consolidated. Yes I agree. This is another classic case of documentation being slow in synchronizing with the changes in the code. I'm tied till thursday this week but I'll see whether I can clear things up by the weekend. (Unless of course somebody else jumps up and finishes it before then ;)) Thanks, Thilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2]Putting All Axis2 stuff in One Jar[1.1 release]
Hi, I have a small concern on this. When we make the jars we should name them in such a manner that it makes no conflict (I remember we had a similar issue with two jars having the same name). So I propose that we name the jars according to distro. Say like axis2-min-1.1.jar and axis2-std-1.1.jar. Ajith On 10/25/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote: Srinath Perera wrote: > Hi All; > > For 1.1 are we planing to put all Axis2 jars on one axis2 jar. (When I > purposed, Eran agreed .. no body opposed ...). ? > > We could keep all other jars in the maven repositories, but for the > relase we can make a one jar out of all axis2 classes. +1 ( again :) ) > > It is best if we can do same for Axiom as well Well, I do not agree with this. People some times doesn't need DOM jar at all. Anyway, there was a request from Abdera team to take out SOAP specific stuff from axiom api and axiom impl. We need to discuss that also in commons-dev. Waiting till Axis2 1.1 hit the road. -- Chinthaka -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote][Axis2] Amila, Keith and Sandakith as committers
+1 to all of them. -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Axis 1.1 war distro broken ?
Hi guys, After all the talk about the war I found that both the available war distributions listed in the nightly build page, fail to deploy in Tomcat 5.0.x in Ubuntu 6 ! (it works ok in a Windows Tomcat 5.5 installation though). Has anyone else encountered this problem ? -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Distribution packaging restructuring
Hi, Yep - I've the same feeling about some of the Jaxb jars. That is why I wanted to clarify the jar list On 10/17/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote: Ajith Ranabahu wrote: > Hi, > Yep I know right now we simply do a 'copy-deps' :) I was wondering > whether you guys wanted to remove any jars from those standard deps - > just to clarify which jars are in and which are out. IIRC, Thilina created a wiki to keep track of the jars needed. Especially Dennis mentioned once that, even if some jars are mentioned as deps in JiBX they need not be distributed. -- Chinthaka -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axis2] How can I get a reference to the ConfigurationContext from the DescriptionBuilders
Hi, But wouldn't that mean you would be creating a *new* configContext ? If you have an Axis2 instance already running wouldn't ListenerManager.defaultConfigurationContext be the right one to take ? Ajith On 10/17/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote: Rajith Attapattu wrote: > Hi All, > > I have acess to the AxisConfiguration in my DescriptionBuilder, now how > do I get access to the ConfigurationContext from there ? new ConfigurationContext(axisConfiguration) should do. Rajith, seems you need a coffee :) - Chinthaka -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Distribution packaging restructuring
Hi, Yep I know right now we simply do a 'copy-deps' :) I was wondering whether you guys wanted to remove any jars from those standard deps - just to clarify which jars are in and which are out. Ajith On 10/17/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote: Ajith Ranabahu wrote: > Hi > Let me clarify things a bit > > 1. We are *not* shipping a war ? I have no objection about not having > a downlodable, ready to use war distro but I'm not so sure how the > user community will respond to that - specially after shipping the war > file as an artifact in all the past releases. > > 2. I'm interested in knowing the content of the lib folder ;) > run maven cache-war-deps and maven cache-std-deps :). In English, union of all the dependencies of standard distribution + webapp maven module. -- Chinthaka -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Distribution packaging restructuring
Hi
Let me clarify things a bit
1. We are *not* shipping a war ? I have no objection about not having
a downlodable, ready to use war distro but I'm not so sure how the
user community will respond to that - specially after shipping the war
file as an artifact in all the past releases.
2. I'm interested in knowing the content of the lib folder ;)
Ajith
On 10/17/06, Thilina Gunarathne <[EMAIL PROTECTED]> wrote:
Hi all,
Currently I'm doing some refactorings to the Axis2 distributions, mainly to
improve the first time user experience.. This also focuses on improving the
sample structure too..
Following are the release artifacts that will be released from 1.1-RC2
onwards..
1. axis2-1.1.zip - see below for the new structure
have the root folder of the zip as axis2-1.1/ (will unzip into axis2-1.1)
2. axis2-1.1-min.zip - for the advanced users who need just the core axis2
functionality
have the root folder of the zip as axis2-1.1/ (will unzip into axis2-1.1)
3. axis2-1.1-src.zip - source distro, users can use maven goals to create
min,std and war
have the root folder of the zip as axis2-1.1/src/ (will unzip into
axis2-1.1/src)
4. axis2-1.1-docs.zip - all the docs (java docs+xdocs)
have the root folder of the zip as axis2-1.1 /docs/ (will unzip into
axis2-1.1/docs)
Having root folders as above will put the stuff in place nicely when the
user expands main,docs and src in the same dir..
I have ripped off the axis2.war from the distributions. Users will have the
ability to create axis2.war from the axis2 main binary distribution. This
will help a lot to users who are planning to deploy axis2 in servlet
containers other than tomcat. With this users will be able to customize (put
service.aar's, etc..) the war easily..
** Contents of axis2-1.1.zip **
axis2-1.1/
bin/
axis2.{sh/bat} -classpath what_ever_the_user_class
* this new script will work similar to "java" and will run the
given client class with whatever the user given options using the
../repository as the axis2 repository
java2wsdl.{sh/bat} scripts
wsdl2java.{sh/bat} scripts
axis2server.{sh/bat} scripts - http-server renamed
* this will use ../repository,
../conf/axis2.xml as defaults, and will set up the listeners mentioned in
there.
lib/
webapp/
WEB-INF/
web.xml
classes/
*.properties
build.xml - script to create the war. Make sure to create
*.list
axis2-web/
admin/
will contain the jsp's of the admin console users can delete this if they
do not want the admin-console in the war
samples/
foo/
build.xml - compile,create .aar and drop it to
../../repository/services ...Another goal to compile & run client
src/samples/foo/
client/
service/
lib/
readme.txt - what is this sample, pre requisites, how to
run.This will point to "docs" if it is present
docs/ - optional, in the case of GUI samples
index.html
boo/
conf/
axis2.xml
repository/
services/
version.aar
sample-foo.aar
sample-boo.aar
modules/
addressing.mar
soap-monitor.mar
Names of all the scripts we ship with Axis2 needs to be in lowercase...
Hope everybody will find the new structure help full...
Thanks,
Thilina
--
http://webservices.apache.org/~thilina/
http://thilinag.blogspot.com/
--
Ajith Ranabahu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Axis2, Axis 2 or Axis 2.0?
+1 On 10/16/06, Jaliya Ekanayake <[EMAIL PROTECTED]> wrote: +1 for Axis2 -Jaliya - Original Message - From: "Srinath Perera" <[EMAIL PROTECTED]> To: ; <[EMAIL PROTECTED]> Sent: Monday, October 16, 2006 7:00 AM Subject: Re: [Axis2] Axis2, Axis 2 or Axis 2.0? > +1 .. That is mybelif too > > On 10/16/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote: >> >> It should be Axis2 everywhere. And the releases should be Axis2 1.0, >> Axis2 1.1, etc., IMHO. >> >> -- Chinthaka >> >> Thilo Frotscher wrote: >> > >> > Hello, >> > >> > This might be a minor issue at this stage but I think the name of this >> > project >> > should generally be clarified. At several different places (articles, >> > code, >> > documentation, JIRA, Eclipse plugins etc) at least three different >> > names >> > can >> > be found: >> > >> > - Axis2 (definitely the most frequent one, so I assume that's the right >> > one) >> > - Axis 2 >> > - Axis 2.0 (this rises questions concerning the release version 1.1 :-) >> > >> > The project name should be consistent *everywhere*. >> > >> > Thanks, >> > Thilo >> > >> > - >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >> >> >> >> > > > -- > > Srinath Perera: > Indiana University, Bloomington > http://www.cs.indiana.edu/~hperera/ > http://www.bloglines.com/blog/hemapani > > - > 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] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] What to include in the Axis2 1.1 distributions??
Hi, And provide all aditional dependacncies of Axis2 as a one zip file from the site. Or add a minmial standard and exteneded distribution. I agree with Srinath in this. My guess is there would be users who want everything and some would want most of it but not all. Right now we have standard and minimal distributions so how about having 1. minimal 2. standard 3. full (complete) distributions ? I guess we should include a clear description of what is in and what is not in the distribution page (http://ws.apache.org/axis2/download/1_0/download.cgi). Right now what I feel is minimal to be an embeddable version with absolutely needed libs, standard to be the 80% case with most of the needed jars (hence the discussion in this thread applies to the standard distro) and complete with all the stuff in one package. Thoughts ? Ajith On 10/14/06, Srinath Perera <[EMAIL PROTECTED]> wrote: Just looked at the std distribution .. we have 3 axom jars 10 Axis2 jars !!! Lets bring them down to two jars .. Most of these axis2 jars are small. So no harm putting everything in the one jar I would say 1) Get rid of bcel-5.2.jar 2) jaxme-* 3) spring-* And provide all aditional dependacncies of Axis2 as a one zip file from the site. Or add a minmial standard and exteneded distribution. Thanks Srinath -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Patch for AXIS2-1338
Hmm... The instnace XML is indeed valid but it seems the way we handle things (atleast the assumption we made) is not correct. Right now the xsd:anyType generates an OMElement as the field (which essentially assumes that anyType will be a complex type!). But as this example shows it can be a primitive or derived type and our deserialization will fail. The most important issue here is that even if we manage to get the deser right, the generating of OMElement would not be right in this case. (How can you assign an integer or string to an OMElement ??) Would java.lang.Object be a good choice ? Ajith On 10/11/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: Amila, JIRA is down...The patch for AXIS2-1338 does not take into account the following request. You can use say XMLSPY to validate the xml using the enclosed xsd. http://types.echo.services"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://types.echo.services echo.xsd"> String String String myString String Thanks, dims -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2]Embdeding Jetty to Axis2
Hi, Does this mean we would be shipping a Jetty based HTTP server (adding a Jetty dependancy ) Ajith On 10/9/06, Rajith Attapattu <[EMAIL PROTECTED]> wrote: Srinath, I personally think it's a good move. Regards, Rajith On 10/9/06, Brian De Pradine <[EMAIL PROTECTED] > wrote: > > +1 from me. > > Cheers > > Brian DePradine > Web Services Development > IBM Hursley > External +44 (0) 1962 816319 Internal 246319 > > If you can't find the time to do it right the first time, where will you find the time to do it again? > > > "Jaliya Ekanayake" <[EMAIL PROTECTED]> wrote on 08/10/2006 15:20:49: > > > > Hi All, > > > > One other advantage is that we can simply give an Axis2 server for the user > > as well. > > All they want is to start the Axis2 server which is based on Jetty. > > > > Thanks, > > -Jaliya > > > > > > - Original Message - > > From: "Srinath Perera" <[EMAIL PROTECTED]> > > To: > > Cc: "Thilina Gunarathne" <[EMAIL PROTECTED]>; "Jaliya Ekanayake" > > <[EMAIL PROTECTED]> > > Sent: Sunday, October 08, 2006 7:56 AM > > Subject: [Axis2]Embdeding Jetty to Axis2 > > > > > > > Hi All; > > > Myself and jaliya were talking about trying to do lot of async > > > requests using Axis2 client .. it falis at about 40-50 requests and we > > > belive that is becouse ..simple HTTP server can't handle the load. > > > > > > I was looking at the jetty and found out that Jetty6 allow you to > > > embed it to the application tightly. For an example > > > > > > Server server = new Server(8080); > > > Context root = new Context(server,"/",Context.SESSIONS); > > > root.addServlet(new ServletHolder(new HelloServlet(serviceMap)), "/*"); > > > server.start(); > > > > > > Will create a new server and add a servlet. > > > > > > I belive if we embdeded Jetty to Axis2 > > > 1) Axis2 can use jetty as the listener for async messages > > > 2) Axis2 can started up standalone using jetty > > > > > > I belive I could port our Axis2 servlet to jetty pretty easily. > > > > > > If people agree I think we should have it as a module and if it is > > > sucessful I think we should switch to it as our default container some > > > day > > > > > > thoughts? > > > Srinath > > > > > > > > > > > > -- > > > > > > Srinath Perera: > > > http://www.cs.indiana.edu/~hperera/ > > > http://www.bloglines.com/blog/hemapani > > > > > > - > > > 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] > > > -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2]WSDL2Java Code generation option
Hi, I guess you have a point about -ss and -sd. I mean we can assume that -ss implies -sd Ajith On 10/9/06, Srinath Perera <[EMAIL PROTECTED]> wrote: Hi AJith,All; As far as I understand 1) no options client side only 2) -s server side 3) -sd -ss service side discriptions, this only work with -ss 4) -g all, but no service.xml .. So I put -g -sd ..still none becouse -sd only works with -ss .. so -g -ss and -sd Sorry but I feel this is far too complex. shall we change the options for 1.1? for example (Or do we need to me backward compatible with the tool options?) -GClient or nothing for Client -GServer for server with service.xml -GAll for everything -GTest all with test case Do we have use case for generating server side code without a service.xml file ? Do we have use case for generating service.xml without server side code? (we could at least assume -ss given -sd) thoughts? Thanks Srinath On 10/7/06, Ajith Ranabahu <[EMAIL PROTECTED]> wrote: > Hi, > I guess I should say why this style was selected. As for Axis1 the > code generator always generates the client code when asked for the > server side code. It seemed a bit ugly an somewhat confusing from the > users point of view [ I also get a stub when I ask for a skeleton ??] > . Hence the option -g to (generate-all) needs to be used to generate > both the client and server side code. > > Ajith > > On 10/7/06, Dennis Sosnoski <[EMAIL PROTECTED]> wrote: > > Try the -g option. > > > > - Dennis > > > > Davanum Srinivas wrote: > > > :) +1 from me. I tried sneaking this in a couple of times via the > > > testcase generation option. Not sure if it still works. (-ss -sd -t) > > > > > > -- dims > > > > > > On 10/7/06, Srinath Perera <[EMAIL PROTECTED]> wrote: > > >> Hi All; > > >> > > >> Right now When we codegen for server side with WSDL2Java .. when we > > >> give -sd or -ss > > >> it create only server side code. > > >> > > >> However it is very useful if it generate both server and client side > > >> code. Axis1.1 use to do that. If you think about it .. 90% of the time > > >> user will need to check does his service is working and will generate > > >> the client side code as well. > > >> > > >> Thanks > > >> Srinath > > >> > > >> -- > > >> > > >> Srinath Perera: > > >>http://www.cs.indiana.edu/~hperera/ > > >>http://www.bloglines.com/blog/hemapani > > >> > > >> ----- > > >> 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] > > > > > > > -- > Ajith Ranabahu > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Srinath Perera: Indiana University, Bloomington http://www.cs.indiana.edu/~hperera/ http://www.bloglines.com/blog/hemapani - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2]WSDL2Java Code generation option
Hi, I guess I should say why this style was selected. As for Axis1 the code generator always generates the client code when asked for the server side code. It seemed a bit ugly an somewhat confusing from the users point of view [ I also get a stub when I ask for a skeleton ??] . Hence the option -g to (generate-all) needs to be used to generate both the client and server side code. Ajith On 10/7/06, Dennis Sosnoski <[EMAIL PROTECTED]> wrote: Try the -g option. - Dennis Davanum Srinivas wrote: > :) +1 from me. I tried sneaking this in a couple of times via the > testcase generation option. Not sure if it still works. (-ss -sd -t) > > -- dims > > On 10/7/06, Srinath Perera <[EMAIL PROTECTED]> wrote: >> Hi All; >> >> Right now When we codegen for server side with WSDL2Java .. when we >> give -sd or -ss >> it create only server side code. >> >> However it is very useful if it generate both server and client side >> code. Axis1.1 use to do that. If you think about it .. 90% of the time >> user will need to check does his service is working and will generate >> the client side code as well. >> >> Thanks >> Srinath >> >> -- >> >> Srinath Perera: >>http://www.cs.indiana.edu/~hperera/ >>http://www.bloglines.com/blog/hemapani >> >> - >> 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] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi-modules in Eclipse
Hmm.. I guess you are talking about maven2. If maven2 does that it'll be awesom. Any idea whether this is possible in Maven 1 ? Ajith On 9/29/06, Raymond Feng <[EMAIL PROTECTED]> wrote: That's what exactly what we do, but the "mounting" is logical. The interdependencies are set to the projects instead of jars by the maven eclipse plugin if you run mvn eclipse:eclipse from the root. Thanks, Raymond - Original Message - From: "Ajith Ranabahu" <[EMAIL PROTECTED]> To: Sent: Friday, September 29, 2006 10:32 AM Subject: Re: Multi-modules in Eclipse > Hi guys, > There were some thoughts of mounting the whole module directory as a > workspace and have each module mounted as a project . That way you can > set interdependancies set to projects. However the maven plugin is not > capable of doing that I guess. > > Ajith > > On 9/29/06, Raymond Feng <[EMAIL PROTECTED]> wrote: >> Hi, >> >> We (Tuscany developers using Eclipse) run "mvn eclipse:eclipse" to create >> the IDE artifacts such as .project and .classpath after the SVN checkout. >> And then you can import (existing) projects into Eclipse. It's very >> straightforward. The only caveat comes from the maven eclipse plugin >> which >> doesn't support inclusion/exclusion patterns and as a result you cannot >> have >> overlapping source folders for one module. >> >> Thanks, >> Raymond >> >> - Original Message - >> From: "Jeremy Boynes" <[EMAIL PROTECTED]> >> To: >> Sent: Friday, September 29, 2006 6:46 AM >> Subject: Re: Multi-modules in Eclipse >> >> >> > On Sep 29, 2006, at 2:27 AM, Paul Fremantle wrote: >> > >> >> Hi >> >> >> >> At some point there was some talk of creating a util to help import >> >> multi-module projects into Eclipse. Did anything come of it? >> > >> > Eclipse users in Tuscany are using the maven-eclipse-plugin - not one >> > myself so I don't know how well it works (I think there may be a few >> > gremlins). >> > >> > -- >> > Jeremy >> > >> > >> > - >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > Ajith Ranabahu > > - > 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] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi-modules in Eclipse
Hi guys, There were some thoughts of mounting the whole module directory as a workspace and have each module mounted as a project . That way you can set interdependancies set to projects. However the maven plugin is not capable of doing that I guess. Ajith On 9/29/06, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, We (Tuscany developers using Eclipse) run "mvn eclipse:eclipse" to create the IDE artifacts such as .project and .classpath after the SVN checkout. And then you can import (existing) projects into Eclipse. It's very straightforward. The only caveat comes from the maven eclipse plugin which doesn't support inclusion/exclusion patterns and as a result you cannot have overlapping source folders for one module. Thanks, Raymond - Original Message - From: "Jeremy Boynes" <[EMAIL PROTECTED]> To: Sent: Friday, September 29, 2006 6:46 AM Subject: Re: Multi-modules in Eclipse > On Sep 29, 2006, at 2:27 AM, Paul Fremantle wrote: > >> Hi >> >> At some point there was some talk of creating a util to help import >> multi-module projects into Eclipse. Did anything come of it? > > Eclipse users in Tuscany are using the maven-eclipse-plugin - not one > myself so I don't know how well it works (I think there may be a few > gremlins). > > -- > Jeremy > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > ----- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Release Plan Revisited
A quick question Is ws-commons- java5 jdk1.5 specific ? I vaguely remember such an issue. Ajith On 9/27/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Sep 27, 2006, at 9:31 AM, Thilina Gunarathne wrote: > Hi, > >> We also have an issue with XmlSchema using the older version of stax- >> api. > AFAIK XmlSchema uses the stax-api only for the QName. The difference > between two versions of stax-api is just one method signature change, > which IMHO does not affect at all for the XmlSchema.. I'm pretty sure > XmlSchema will work absolutely fine with the stax-api-1.0.1.jar, > meaning we can use stax-api-1.0.1.jar & XmlSchema-1.1.jar with Axis2 > 1.1. Yes. The problem is that dependency resolution in Maven2 resulted in the selection of stax 1.0 rather than 1.0.1 causing axiom to break because it now needs the newer API. A change has been made in XmlSchema's trunk so that it no longer gets QName etc. from stax-api but from ws-commons-java5. >> This has been fixed in trunk by replacing the dependency on stax- >> api with one on ws-commons-java5 but not yet released. > > This is not clear to me... I couldn't find any dependency on > ws-commons- java5 inside Axis2. XmlSchema now depends on ws-commons-java5 and so Axis2 gets it transitively. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Axis2 is ignoring my WSDL
Hi Guys, Even though this discussion took off in the user list it seems more relevant to the dev list (so I'm forwarding it to the dev list). BTW it would be good if one of you can open a Jira so that this won't be just forgotton :) Ajith On 9/22/06, Bhatra, Junaid <[EMAIL PROTECTED]> wrote: Going further on this, even if you do NOT use RPCMessageReceiver and supply your own WSDL, Axis2 **still** modifies/overrides your WSDL unless you specify the "useOriginalwsdl" parameter. The logic seems inverted to me. In contrast, the default behavior of Axis 1.x is to honor the user-specified WSDL. -Original Message- From: Martin Gainty [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 5:19 PM To: axis-user@ws.apache.org Subject: Re: Axis2 is ignoring my WSDL What I found is.. if you use any style other than RPC the wsdl's wont be created under AXIS2 Martin -- * This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately by telephone or email and destroy the original message without making a copy. Thank you. - Original Message - From: "robert lazarski" <[EMAIL PROTECTED]> To: Sent: Thursday, September 21, 2006 4:10 PM Subject: Re: Axis2 is ignoring my WSDL > You can use your own wsdl provided you use any other message receiver > except for RPC*. If you have a wsdl that you made yourself or got > from somewhere, why not just use databinding via xmlbeans or adb ? > > Robert > > On 9/21/06, D. Kreft <[EMAIL PROTECTED]> wrote: >> On 9/21/06, robert lazarski <[EMAIL PROTECTED]> wrote: >> >> > If you are using RPCMessageReceiver it doesn't make sense to use your >> > own WSDL . This is a FAQ: >> > >> > http://www.wso2.net/kb/104 >> >> Yeah, I saw that a couple of days ago. I think I actually read it more >> than once. >> >> The explanation of why I would *really* like to have a WSDL generated >> at build time is not something I really wanted to get into, so I'll >> try to keep this short and sweet. >> >> The presence of a WSDL at build time makes it much easier for builds >> of other packages (the smallest unit of software development at my >> company) to depend upon my service (at build time)--and it also makes >> it possible to determine if a particular build of my service has the >> contract that another developer is interested in. It is unacceptable >> in our environment to have to query a WSDL from a running service at >> build time--developers might not have network access, they might be >> trying to code to a built-but-not-yet-deployed WSDL, or any one of a >> number of different reasons. >> >> But philosophical arguments aside, I still don't understand why my >> wsdl would not be used if it is where the Axis2 docs say it should be. >> >> -dan >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] Re: Adding Support for xs:union in ADB
Hi, Yes it seems to be the right approach. So you have multiple setters for each type in the union and a boolean keeps track of the value that was set the last ? BTW its good to see you working on this :) Ajith On 9/15/06, Maryam Moazeni <[EMAIL PROTECTED]> wrote: Hi All, Regarding the implementation of xs:union, I'd like to have Axis2 developers' opinions. Like particle "choice" that a tracker is set for each element that is set, we can have a tracker for each type in the "union" as well. Therefore, we can keep track of the type that is first set. I think every thing else would be the same as before. Any thoughts? Thanks in advance, Maryam -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][Vote] Create a branch for the Axis2 1.1 release
Hi Bill, Yep - subversion makes it very easy to merge the branches. However it does not talk about conflicts ! So merging is easy if there are no conflicts. Also the authors must make sure they commit and apply the changes to the trunk (with the consent of the release manager of course) at the same time - a bit of a burden to the authors when the numbers are high. SO We'll let the RM (Thilina) decide when to cut the branch. My personal feeling is you guys can keep on working in the trunk and the RM will cut a branch after the code freeze so that the trunk folks can move on without any hassel. Code freeze means the code is fairly stable so whatever the changes that happens to the branch will be minimal. Anyway its Thilina's call :) On 9/15/06, Bill Nagy <[EMAIL PROTECTED]> wrote: Hi all, There's actually a good description of the why and how's of creating a release branch in the Subversion book (http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.branchmerge.commonuses.patterns.release) I don't understand why folks are saying that figuring out what goes where is tricky or that the work is that difficult. I agree with dims that the RM should be in charge of creating the branch for the release -- that branch is then the RM's responsibility. The RM gets to decide which bug fixes (or features I suppose) get added to the branch after it is made. The RM, however, has no more of a vote than anyone else as to what gets placed into the trunk. Bug fixes that are made to the release branch should most likely be committed to the trunk as well, but the RM doesn't have to be the one that does it. (If another committer made the change to the release branch, then they should probably also commit the change to the trunk.) Moving changes between branches with subversion is relatively trivial, and, unless the release drags on, I can't imagine that the code bases will diverge that much. -Bill On Fri, 2006-09-15 at 10:45 -0400, Rajith Attapattu wrote: > I am also worried about the concerns raised by Ajith and then Eran. > Especially the decision around when to create the branch and what > fixes should be propagated to the trunk are going to be a bit tricky. > > I also agree that the workload for the RM is going to be increased > substantially. > > How about if we free the RM of his other duties (bug fixes ..etc) and > get him to do RM on a full-time basis during the release cycle? > We need a person to fully manage the release process, especially make > the important decisions of which fixes are propagated to trunk ..etc > without being burdened by other tasks. > > Regards, > > Rajith > > On 9/15/06, Brent Ulbricht <[EMAIL PROTECTED]> wrote: > > +1 for a branch > > I agree that the branch would be best created when new > function cannot be committed to head. > > Brent Ulbricht > IBM Software Group - WebSphere FVT > [EMAIL PROTECTED] > > > > > > Jeff Barrett/Austin/[EMAIL PROTECTED] > > 09/15/2006 07:49 AM > >Please respond to > axis-dev@ws.apache.org > > > To > axis-dev@ws.apache.org > cc > > > Subject > Re: > [Axis2][Vote] > Create a branch > for the Axis2 > 1.1 release > > > > > > > > > > > > +1 to creating the branch. > > As to the timing of the creating the branch, It seems it needs > to be created at the point when we are asked to stop > committing new function to HEAD, i.e. "code freeze". > > Thanks, > Jeff > > IBM Software Group - WebSphere Web Services Development > Phone: 512-838-4587 or Tie Line 678-4587 > Internet e-mail and Sametime ID: [EMAIL PROTECTED] > > Nicholas L > Gallardo/Austin/[EMAIL PROTECTED] > > 09/14/2006 04:18 PM >Please respond to > axis-dev@ws.apache.org > > To > axis-dev@ws.apache.org > cc > > > Subject > Re: > [Axis2][Vote] > Create a branch > for the Axis2 > 1.1 release > > > > > > > > > > > > > > Ajith, > > Branching before would allow others to continue longer term > development items while the final fixes are being applied to > the upcoming release. > > Regards, > > Nicholas Gallardo > WebSphere - WebServices Development > [EMAIL PROTECTED] > Phone: 512-838-1182 >
Re: [Axis2] Codegen tool command line options
Hi, IIRC I was told that what went into the Commons CLI was infact the commandline parser from Axis1! Ajith On 9/15/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: Samisa, Did you look into the parser inside Axis 1.X? On 9/14/06, Samisa Abeysinghe <[EMAIL PROTECTED]> wrote: > Ajith Ranabahu wrote: > > Hi, > > Lemme add my thoughts here. > > > >> > >> First: > >> It is the usual convention that we use -- for long options. Long options > >> are any option that has more than one char. e.g. ss, sd > >> Either we have to come up with single char alternatives to them or have > >> to change the syntax to -- > > > > The problem with always having 1 character short options is that they > > become less descriptive and gets confusing soon. And it is not nice to > > have them use the long version always. Perhaps we can go into an Axis > > 1.1 like options where uppercase and lowercase letters are used in > > places of conflict [1]. However we have come long way with these > > options and it will not be nice to break the whole thing by reverting > > all the option names. We would have to do deprecate - drop cycle. > > > >> Second: > >> If I use -lc it breaks, I have to use -l c > > > > Yes - the for the current commandline options parsers the parameters > > need to be seperated by a space. I'm not sure whether this greatly > > affects usability (linux/unix lovers may not agree with me on that ;)) > > but we can definitely improve the parser to take that into account. > > > Well I was looking into the parser to improve it. This is where I > concluded that we need GetOpt like thing. > The point is when we have both -lc -ss as options, then it converts to > option l with arg c > option s with arg s > However we treat ss as one option, so while the parser logic could be > improved, it becomes overly complex. > > As a solution to the concern that you have raised against the use of --, > we can hide the user from -- by treating > -ss as -s a; -sd as -s d; -sn as -s n and -ssi as -s si internally. > This again is complex logic, but I hope we may live with it. > > >> Third: > >> We have getopt like implementation in Java. e.g. Xalan has > >> src/org/apache/xalan/xsltc/cmdline/getopt/GetOpt.java > >> We can use this and improve command line option parsing > > > > There is this thing called commons commandline [2]. I have tried > > several times to put that in but did not get time to do it. I'm not > > sure how suitable the xerces thing would be (It may give us a direct > > dependancy on xerces that we do not want) so I guess something like > > the commons CLI would be the right thing. > Well I was thinking copying GetOpt.java from Xalan and improving to that > to match our needs (Should be OK as it is the same licence). I had a > look at CLI, but for me, it is too complex for our requirement. > > I could look into GetOpt.java and improve it, however to do that, I need > to know the number of args expected by each command line option > mentioned in > CommandLineOptionConstants.WSDL2JavaConstants. Could you please let me > know those numbers? > > Thanks, > Samisa... > > > >> Fourth: > >> Without something like getopt, we cannot drop the need for -uri in the > >> current syntax (I think there a Jira requesting to drop -uri option) > > > > Well you can :) But it'll rather be better to go ahead with commons > > CLI and use the capabilities of that to deal with it. > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][Vote] Create a branch for the Axis2 1.1 release
Hi Nick,Yep, That is definitely a reason to do so. What I'm a bit worried about is that when you do a branch then whatever the bug fixes you do to the branch would also need to go to the trunk. And believe me, there is going to be a significant number of bug fixes before the release :) So I guess the best time to do the branch would be just after the code freeze, so that the folks who want to work on the code can keep on working with it without effecting the release. AjithOn 9/14/06, Nicholas L Gallardo <[EMAIL PROTECTED]> wrote: Ajith, Branching before would allow others to continue longer term development items while the final fixes are being applied to the upcoming release. Regards, Nicholas Gallardo WebSphere - WebServices Development [EMAIL PROTECTED] Phone: 512-838-1182 Building: 901 / 5G-016 "Ajith Ranabahu" <[EMAIL PROTECTED]> 09/14/2006 04:11 PM Please respond to axis-dev@ws.apache.org To axis-dev@ws.apache.org cc Subject Re: [Axis2][Vote] Create a branch for the Axis2 1.1 release Hi guys, If I understand right the branching usually happens at the same time of a release (or slightly after) and is usually used to fix issues in that particular release. We can definitely use a branch before the release but is there any particular reason why we need a branch before the release ? -- Ajith Ranabahu -- Ajith Ranabahu
Re: [Axis2][Vote] Create a branch for the Axis2 1.1 release
Hi guys,If I understand right the branching usually happens at the same time of a release (or slightly after) and is usually used to fix issues in that particular release. We can definitely use a branch before the release but is there any particular reason why we need a branch before the release ? -- Ajith Ranabahu
Re: org.apache.axis2.om.OMElement not in war distribution
21) at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442) at org.apache.catalina.core.StandardService.start(StandardService.java:450) at org.apache.catalina.core.StandardServer.start(StandardServer.java:709) at org.apache.catalina.startup.Catalina.start(Catalina.java:551) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Codegen tool command line options
Hi, Lemme add my thoughts here. First: It is the usual convention that we use -- for long options. Long options are any option that has more than one char. e.g. ss, sd Either we have to come up with single char alternatives to them or have to change the syntax to -- The problem with always having 1 character short options is that they become less descriptive and gets confusing soon. And it is not nice to have them use the long version always. Perhaps we can go into an Axis 1.1 like options where uppercase and lowercase letters are used in places of conflict [1]. However we have come long way with these options and it will not be nice to break the whole thing by reverting all the option names. We would have to do deprecate - drop cycle. Second: If I use -lc it breaks, I have to use -l c Yes - the for the current commandline options parsers the parameters need to be seperated by a space. I'm not sure whether this greatly affects usability (linux/unix lovers may not agree with me on that ;)) but we can definitely improve the parser to take that into account. Third: We have getopt like implementation in Java. e.g. Xalan has src/org/apache/xalan/xsltc/cmdline/getopt/GetOpt.java We can use this and improve command line option parsing There is this thing called commons commandline [2]. I have tried several times to put that in but did not get time to do it. I'm not sure how suitable the xerces thing would be (It may give us a direct dependancy on xerces that we do not want) so I guess something like the commons CLI would be the right thing. Fourth: Without something like getopt, we cannot drop the need for -uri in the current syntax (I think there a Jira requesting to drop -uri option) Well you can :) But it'll rather be better to go ahead with commons CLI and use the capabilities of that to deal with it. -- Ajith Ranabahu [1]http://ws.apache.org/axis/java/reference.html#WSDL2JavaReference [2] http://jakarta.apache.org/commons/cli/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][Vote] Thilina as the release manager for Axis2 1.1
+1 -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] Fwd: binary and enumFacet are incompatible with unordered in ADBBeanTemplate
Forwarding with the Axis2 prefix. I nearly missed it :)
BTW I guess these changes are done by Dims and Thilina for MTOM
compatibility so I guess they are the best people to test what went
wrong here :)
On 9/6/06, Chuck Williams <[EMAIL PROTECTED]> wrote:
Hi Dims and Ajith,
I believe you guys added revisions 434331 and 436663 as part of a fix
for Axis2-1065. Unfortunately these changes break the build and the
template. E.g., the sforce enterprise wsdl generates bogus code and
kills a clean build.
Simply backing out the changes in these two revisions causes the build
to succeed and all tests to pass. However, I suspect this will regress
Axis2-1065 and the same type of problem exists for enumFacet.
The issue is this. For ordered property sets, the main property parsing
loop generates code like this (in pseudo-code notation):
if (elementName=="name1") {
...
} else throw "Unexpected subelement"
if (elementName=="name2") {
...
} else throw "Unexpected subelement"
...
While in the unordered case the same code looks like this:
while (!endElement) {
if (elementName=="name1") {
...
}
else if (elementName=="name2") {
...
}
...
}
The binary MTOM code that was added fills the role of one the embedded
if's but is not of the same form, not an if at all. This code works in
the first ordered case, but in the second unordered case it doesn't work
at all to have fixed code expecting to just read a binary value where
one of the if's is supposed to be. Also in the binary case in the
current template the else is still generated after the MTOM code that is
not an if, whence the syntax violation in the code generated for the
sforce wsdl, which evidently has a binary property in an unordered
property set.
I'm no expert on MTOM. Can't you still test that you've got the right
property (the binary property) by using the start-element name? For the
template to work in the unordered case, some test that you've got the
binary propery is essential. The existing template does not do this,
which can only work in the ordered case where you know you are at the
right position, and even in this case does not do the proper error
checking to verify this.
I would commit the attached template as axis2 passes all tests, but the
logs indicate you made the revisions that created this problem to fix
another problem and so I don't want to just back that out without
bringing this to your attention first.
Chuck
-----
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ajith Ranabahu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: WSS4J 2.0(?)
Hi, Nope I'm not missing anything :) I'm saying keep the integration tests as it is (I'm talking about the security tests in the integration module) and they can run having rampart as an external dependancy. That's it. You don't want to move them anywhere. If Axis2 code is not compatible with the latest rampart build (which now comes as an external dependancy), Axis2 build will fail! In my mind Axis2 integration tests belong in Axis2 and not anywhere else. We do have XMLBeans and Jibx tests that way. Ajith On 9/1/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote: Ajith Ranabahu wrote: > Hi, > I'm also +1 on this move - it makes things modular and easy to handle. > BTW I don't think you need to move the integration tests - they are > *Axis2* integration tests and they should not go to any other project! No, you miss something here Ajith. They are not mere integration tests. They test how Rahas or Rampart or whatever works hand-in-hand. But that includes Axis2 integration tests as well. Thats the reason behind me mentioning that we need some test cases to test the integration to compensate the removal of Security integration tests. Read point #2 my earlier mail. -- Chinthaka -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WSS4J 2.0(?)
Hi, Ok, the fact that they are the home for their C counterparts is valid to some extent to make it to the top level ( I mean as direct children of WS project - subsequent uses of top level would mean the same stated otherwise). But why did we place XMLSchema, Axiom, neethi, tcpmon and such independent pieces of software inside ws-commons then ? If we are promoting rampart, rahas and savan as ellegible to be in the top level, Axiom, Neethi and XMLSchema deserve to come out of their hiding as well :) Simply what I'm trying to point out is this. Rampart, Rahas ans Savan are very tightly bound to Axis2 and no one is able to use them as 'standalone' pieces (As opposed to something like WSS4J which is not bound to any such framework). It would be better to reflect this obvious fact in the project structure as well. Ajith On 8/31/06, Ruchith Fernando <[EMAIL PROTECTED]> wrote: Ajith, If we implement this, it is going to be exactly similar to the WS-FX project ... which we got rid of, some time back ! It is much more clearer to have the different WS-* implementations at direct children of the WS project. Also its important to note that these sub-projects (Rampart, Rahas, Sandesha, Kandula etc) will also provide a home for their implementations in other languages as well , such as C. Thanks, Ruchith On 9/1/06, Ajith Ranabahu <[EMAIL PROTECTED]> wrote: > Hi, > I'm also +1 on this move - it makes things modular and easy to handle. > BTW I don't think you need to move the integration tests - they are > *Axis2* integration tests and they should not go to any other project! > Of course the rampart module will be external after the change but > that does not mean that the integration tests have to be too :) > I would also like to draw your attention to the structure of the > projects as well. If you look at the current project structure almost > all the projects that are under the ws project space are mostly > independent of each other [1]. For example WSS4J,Woden (which is > really incubated) and other tit bits in ws-commons. It is true that > there are projects that are explicitly focused on adding support to > other projects (like Kandula and Sandesha) but what I feel is that > since Savan and rampart are going to be very Axis2 specific, they > would not fit as immediate children of the ws project space. To me it > makes good sense to have a sub project called Axis2-modules (whatever > the name you guys prefer. I don't want it to be another naming war :)) > and have savan and rampart under that - just like what we have in > ws-commons right now. > > do I make any sense ? > > Ajith > > [1] http://ws.apache.org/#Project+List > > On 8/31/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote: > > Another big +1 from me too. > > > > I was really worried about the increasing number of modules within Axis2 > > project, but didn't take this up as people were busy with other > > important issues. I'd like to add two more things to Ruchith's proposal. > > > > 1. Move Savan also to a sub-project out of Axis2 > > > > 2. Write some integration tests in Axis2 to compensate the valuable > > tests Ruchith had written to test the integrity of Axis2 client and > > server. Whenever you do some random changes in Axis2, security tests > > were failing as they were the only tests which tested the real > > integration. Since these tests also will be moved with Rahas and > > Rampart, we need to have some tests to compensate them > > > > 3. Need to have a gump like thingy setup to run all the tests in Axis2 > > and related projects and to bug whoever breaks the total build. > > > > Any volunteers? > > > > -- Chinthaka > > > > Sanjiva Weerawarana wrote: > > > On Thu, 2006-08-31 at 20:28 +0530, Ruchith Fernando wrote: > > >> Basically how about pushing these up to be two new sub projects or the > > >> Apache Web services project : > > >> > > >> Ramaprt - WS-Security and WS-SecureConversation implementation > > >> Rahas - WS-Trust implementation > > >> > > >> This is similar to the way we have Sandesha (WS-RM impl), and they > > >> will have their own release cycles etc. ? > > > > > > Big +1 from me. I don't see any need to clutter up WSS4J with all this > > > stuff - let's keep WSS4J at the level it is and add separate projects to > > > cover the other functionality (which are Axis2 and Axiom coupled > > > anyway). > > > > > > Sanjiva. > > > > > > > > > - > > > To unsubscribe, e-m
Re: [Axis2] Jar Files ...
Hi Joe, I guess that it is possible to the rampart module to be a 'mix and match' so the best thing to do would be to build them from source :) Ajith On 8/31/06, Joe Wyrembelski <[EMAIL PROTECTED]> wrote: In which Jar file can I find the org.apache.rahas package? The only one I have available is axis2-rahas-SNAPSHOT.jar, and I have a suspicion that the classes within were compiled against a different version of Axis2 than what I am trying to deploy against. Background: I've used WSDL2Java to generate my client (Using Axis2 1.0) and am following through the examples in the rampart presentation by Ruchith Fernando (http://www.wso2.net/presentations/rampart/java/2006/08/04/secure-ws), but am having classpath problems. The Jar files that are included with the presentation samples are a mix of current and snapshot versions, and I'm finding that you can't just mix and match. :) Thanks! Joe -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WSS4J 2.0(?)
Hi, I'm also +1 on this move - it makes things modular and easy to handle. BTW I don't think you need to move the integration tests - they are *Axis2* integration tests and they should not go to any other project! Of course the rampart module will be external after the change but that does not mean that the integration tests have to be too :) I would also like to draw your attention to the structure of the projects as well. If you look at the current project structure almost all the projects that are under the ws project space are mostly independent of each other [1]. For example WSS4J,Woden (which is really incubated) and other tit bits in ws-commons. It is true that there are projects that are explicitly focused on adding support to other projects (like Kandula and Sandesha) but what I feel is that since Savan and rampart are going to be very Axis2 specific, they would not fit as immediate children of the ws project space. To me it makes good sense to have a sub project called Axis2-modules (whatever the name you guys prefer. I don't want it to be another naming war :)) and have savan and rampart under that - just like what we have in ws-commons right now. do I make any sense ? Ajith [1] http://ws.apache.org/#Project+List On 8/31/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote: Another big +1 from me too. I was really worried about the increasing number of modules within Axis2 project, but didn't take this up as people were busy with other important issues. I'd like to add two more things to Ruchith's proposal. 1. Move Savan also to a sub-project out of Axis2 2. Write some integration tests in Axis2 to compensate the valuable tests Ruchith had written to test the integrity of Axis2 client and server. Whenever you do some random changes in Axis2, security tests were failing as they were the only tests which tested the real integration. Since these tests also will be moved with Rahas and Rampart, we need to have some tests to compensate them 3. Need to have a gump like thingy setup to run all the tests in Axis2 and related projects and to bug whoever breaks the total build. Any volunteers? -- Chinthaka Sanjiva Weerawarana wrote: > On Thu, 2006-08-31 at 20:28 +0530, Ruchith Fernando wrote: >> Basically how about pushing these up to be two new sub projects or the >> Apache Web services project : >> >> Ramaprt - WS-Security and WS-SecureConversation implementation >> Rahas - WS-Trust implementation >> >> This is similar to the way we have Sandesha (WS-RM impl), and they >> will have their own release cycles etc. ? > > Big +1 from me. I don't see any need to clutter up WSS4J with all this > stuff - let's keep WSS4J at the level it is and add separate projects to > cover the other functionality (which are Axis2 and Axiom coupled > anyway). > > Sanjiva. > > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SOAPFaultException with Axis2 WSDL2Java
Hi, This is a question for the mailing list so I recommend you to ansl these questions from the list (axis-dev, axis-user). Anyway I a not so sure what the problem here. Can you attach the WSDL file ? Ajith On 8/28/06, Kumar, Sanjeev <[EMAIL PROTECTED]> wrote: Hello Ajith, I am using Axis2. Downloaded the nightly build and ran the WSDL2Java. Following error is seen: Using AXIS2_HOME: D:\Axis2 Using JAVA_HOME:D:\j2sdk1.4.2_12 Exception in thread "main" org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.codegen.CodeGenerationException: java.lang.RuntimeException: Element QName is null for SOAPFaultExceptionSession! at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224) at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32) at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:21) Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: java.lang.RuntimeException: Element QName is null for SOAPFaultExceptionSession! at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.emitStub(AxisServiceBasedMultiLanguageEmitter.java:322) at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:213) ... 2 more Caused by: java.lang.RuntimeException: Element QName is null for SOAPFaultExceptionSession! at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.getFaultParamElements(AxisServiceBasedMultiLanguageEmitter.java:1778) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.getFaultElement(AxisServiceBasedMultiLanguageEmitter.java:1728) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.loadOperations(AxisServiceBasedMultiLanguageEmitter.java:1449) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.createDOMDocumentForCallbackHandler(AxisServiceBasedMultiLanguageEmitter.java:640) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.writeCallBackHandlers(AxisServiceBasedMultiLanguageEmitter.java:616) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.emitStub(AxisServiceBasedMultiLanguageEmitter.java:300) ... 3 more I inserted following lines In the downloaded sample Axis2SampleDocLit.wsdl I inserted the above line for exception. Could you please let me know why this error occurs when this exception support is added in wsdl file. Without SOAPFaultException insertion it works fine. It seems that "falult" is not supported?? Best Regards Sanjeev Software Developer Phone: +49-2404-901-524 Fax: +49-2404-901-724 [EMAIL PROTECTED] www.cycos.com Cycos AG Joseph-Von-Fraunhofer-Str. 7 D-52477, Alsdorf. -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
