Hi, 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?
Yes, Agreed. But if we do this fix ( adding security to fault flows ), if someone wants to use new Rampart with released Axis2 version, they will anyway have to change their axis2.xml. Even if we add dynamic phase support to Axis2 SNAPSHOT right now, I think people using released versions of Axis2 will still have to change their axis2.xml if they want to use latest Rampart. And there are other practical issues too. Even though this not directly related to Axis2, we in Rampart side will face difficulties in running our test-cases with Axis2 if Rampart doesn't work out of the box with Axis2. > 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. We can include this in the documentation, but wouldn't it be inconsistent. We have security phase in all other three flows ( In, Out, InFault ) and asking users to add it to the Out Fault Flow. We can move to dynamic phase way as soon as it is implemented. But right now, is it the best way to ask users ( even the ones who are just starting with latest Axis2 and Rampart ) to go and change it because we don't support Rampart out of the box ? Thanks, Nandana > > > Make sense? (note I'm not saying -1, just trying to understand) > > 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] > >
