On Dec 18, 2007 10:12 AM, Glen Daniels <[EMAIL PROTECTED]> wrote: > Hi Amila, all: > > I'm not sure exactly what the benefit of changing this in Axis2 right > now is. If we change the default axis2.xml in the Axis2 SVN, that means > that SNAPSHOTs of Axis2 will start working "out of the box" with the new > Rampart. But people using the released versions will still need to > manually make the same changes to local axis2.xml files in order to use > it, right? And we're not going to push out an Axis2 release just for > this (even if we did, people upgrading would STILL need to make the same > changes if they were using a non-default axis2.xml).... > > So it seems like you could get the same effect for now by explaining in > the Rampart documentation how to change the axis2.xml in the correct way > - or even including a sample. > > Make sense? (note I'm not saying -1, just trying to understand)
yes I got your point. But rampart trunk depends on the Axis2-SNAPSHOT and they need to change the axis2 default xml in order to pass the test cases. When we do a change locally we need to commit it to the repository soon. These test cases can not be committed util we change the axis2 default xml. Thanks, Amila. > > > Thanks, > --Glen > > Amila Suriarachchi wrote: > > > > > > On Dec 14, 2007 3:31 PM, David Illsley <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > +1 to dynamic phase support, and -0 to changing the axis2.xml to > help > > rampat in the short term.... > > > > > > hi david, > > Let me explain this bit more. > > Nandana is working with rampart and he is trying to solve the following > > issue. > > http://issues.apache.org/jira/browse/RAMPART-90 > > According to the current Axis2 status he can not do this without > > changing the axis2.xml. Obviously Nadana can not change the axis2 kernal > > and add dynamic phase support. Therefore I believe it is not fair to > > ask to hold rampart issues while axis2 changes when there is an > > alternative. > > > > And also he is quite agree to change the rampart module.xml once axis2 > > has this feature. > > > > with this reasoning I am putting +1 to do this change now. Since deepal > > has also put a +1 to this I think he can proceed with this change. (you > > have put only -0) > > > > hope you agree with this. > > > > Thanks, > > Amila. > > > > > > but I'm not happy about shipping an Axis2 > > release with a solution we've already agreed sucks, needs replaced, > > and results in config file churn for users... so lets get the > dynamic > > phase support designed and implemented! > > > > > > > > > > > > > > Do we have any requirements above modules defining a phase and its > > relative location in the flow? > > Cheers, > > David > > > > On Dec 13, 2007 5:30 AM, Ruchith Fernando > > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > wrote: > > > +1 ... I also believe we should be able to have module > > define/arrange > > > phases without > > > having to edit the axis2.xml file and the handlers themselves can > > take > > > care of fault processing. > > > Even in Rampart we use the same handler in the fault flows and we > do > > > the fault handling internally > > > without really checking which flow it is in. > > > > > > But, as Amila mentioned, until we get those implemented lets go > ahead > > > with the changes to axis2.xml to > > > help fix the Rampart fault handling issue. > > > > > > Thanks, > > > Ruchith > > > > > > > > > On Dec 12, 2007 7:15 PM, Amila Suriarachchi > > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > > wrote: > > > > hi glen, > > > > > > > > I am agreeing with you for the two features you have mentioned. > > And also As > > > > I remember these two features > > > > were there in the list that came up after last Apache Con > > hacathon. So there > > > > were no objections for this > > > > features. > > > > > > > > But for the moment since axis2 do not have these features the > > only option > > > > Nandana have is to edit the axis2.xml. So lets allow him to > > continue with > > > > this change and later it can be changed once those features are > > there. > > > > > > > > thanks, > > > > Amila. > > > > > > > > > > > > > > > > On Dec 12, 2007 6:39 PM, Glen Daniels < [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > > Hi Nandana! > > > > > > > > > > > > > > > > > > > > > > > > > Nandana Mihindukulasooriya wrote: > > > > > > Hi Devs, > > > > > > Rampart is in the process of providing security in > > the fault > > > > > > flows. In order to do that, > > > > > > we need to introduce security phase in to out fault flow. > > It is already > > > > > > there in the in fault flow. > > > > > > so the axis2.xml have to modified to include, > > > > > > > > > > > > <phaseOrder type="OutFaultFlow"> > > > > > > <!-- user can add his own phases to this area > --> > > > > > > <phase name="OperationOutFaultPhase"/> > > > > > > <phase name="RMPhase"/> > > > > > > <phase name="PolicyDetermination"/> > > > > > > <phase name="MessageOut"/> > > > > > > *<phase name="Security"/>* > > > > > > </phaseOrder> > > > > > > > > > > I'd much rather that we bit the bullet and finally got > > dynamic phase > > > > > deployment working. It is ridiculous to keep changing our > > default > > > > > axis2.xml (think about how many already deployed versions > > there are, and > > > > > even how many copies we have floating around in our tests > > etc) when the > > > > > whole point of Modules is that they should "drop in" to your > > system and > > > > > require minimal, if any, configuration. I'm up for taking > > point on > > > > > this, and should hopefully be able to get started soon. > > > > > > > > > > That said, I also think we should dispense with Fault Flows > > as has been > > > > > discussed a few times. They don't do much useful work and > > unnecessarily > > > > > complicate the configuration. There should just be "in" and > > "out", and > > > > > if you have a handler which really cares whether a message is > > a fault or > > > > > not, it should just check that in invoke(). > > > > > > > > > > There's my $0.02 - thoughts, devs? > > > > > > > > > > --Glen > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Amila Suriarachchi, > > > > WSO2 Inc. > > > > > > > > > > > > -- > > > http://blog.ruchith.org > > > http://wso2.org > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > -- > > David Illsley - IBM Web Services Development > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > -- > > Amila Suriarachchi, > > WSO2 Inc. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Amila Suriarachchi, WSO2 Inc.
