I am not an expert on this area. Please see my comments bellow and please correct me if I am wrong.
On Dec 14, 2007 11:05 PM, Eran Chinthaka <[EMAIL PROTECTED]> wrote: > I also agree with David here. > > Nandana, can you please explain why you need to hard code security > phases in to axis2.xml? Does this mean we need to have n number of > phases if Axis2 is supporting n WS-* spcs? exactly yes (if new WS* spces needs handlers and those handlers can not be placed in available phases). I think this is the reason why phases like addressing, security and RM are there in the axis2.xml. If that is the case then I > feel there is something wrong with Axis2 architecture itself. As I guess this is the reason Modules (or module.xml) does not allow you to declare Phases. Phases can only be declared in Axis2.xml it self. Module can only declare handlers for any flow. To place a handler in a phase then that phase must be there in the axis2.xml for corresponding flow. So in this case if some one wants to place a security handler at outFault flow then security phase must be there in the outfault flow in axis2.xml. Module writer can only use phase rules to place the handler within the phase. Since there is no Security phase in OutFaultFlow there is no place to add the security handlers. thanks, Amila. > > I like/prefer to keep Axis2 to the minimum. I for one, and believe most > of other users, do not bother to use security at this time. I can quote > you very large scientific systems working with Axis2 without WS-Security > but with just transport level security. Why do we wanna have some set of > phases, which I never need, hard coded in to the system. > > I know, our security guru (you know who he is ;) ) will tell me that it > is not a harm to add one more phase in to Axis2. But why do we wanna > hack the system, without properly implementing it with dynamic phases or > whatever it is. > > I am also 0- on this. > > Thanks, > Chinthaka > > David Illsley wrote: > > +1 to dynamic phase support, and -0 to changing the axis2.xml to help > > rampat in the short term....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]> > 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]> 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]> 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] > >>>> For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>>> > >>> > >>> > >>> -- > >>> Amila Suriarachchi, > >>> WSO2 Inc. > >> > >> > >> -- > >> http://blog.ruchith.org > >> http://wso2.org > >> > >> --------------------------------------------------------------------- > >> > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Amila Suriarachchi, WSO2 Inc.
