You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Nandana Mihindukulasooriya <na...@gmail.com> on 2007/12/12 13:31:47 UTC
[AXIS2] Adding security phase to OutFaultFlow
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>
Regards,
Nandana
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by Ruchith Fernando <ru...@gmail.com>.
It will be great if we can get the dynamic phase support into Axis2-1.4...
BUT *until* someone really works on this feature and get it
implemented and tested with
rampart, sandesha, addressing etc... I'd like to go ahead with what
we have right
now and simply add the "Security" phase to OutFaultFlow. As Nandana
mentioned we
already have this in all other flows. This will help us in Rampart to
continue our
implementations and testing.
Thanks,
Ruchith
On Dec 18, 2007 9:58 AM, Amila Suriarachchi <am...@gmail.com> wrote:
>
>
>
> On Dec 14, 2007 3:31 PM, David Illsley <da...@gmail.com> 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 <ru...@gmail.com>
> 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
> <am...@gmail.com> 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 < glen@thoughtcraft.com> 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: axis-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Amila Suriarachchi,
> > > > WSO2 Inc.
> > >
> > >
> > >
> > > --
> > > http://blog.ruchith.org
> > > http://wso2.org
> > >
> > > ---------------------------------------------------------------------
> > >
> > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> > >
> >
> >
> >
> > --
> > David Illsley - IBM Web Services Development
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
--
http://blog.ruchith.org
http://wso2.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
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 <davidillsley@gmail.com
> > <ma...@gmail.com>> 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
> > <ruchith.fernando@gmail.com <ma...@gmail.com>>
> 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
> > <amilasuriarachchi@gmail.com <ma...@gmail.com>>
> > 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 < glen@thoughtcraft.com
> > <ma...@thoughtcraft.com>> 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: axis-dev-unsubscribe@ws.apache.org
> > <ma...@ws.apache.org>
> > > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > <ma...@ws.apache.org>
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Amila Suriarachchi,
> > > > WSO2 Inc.
> > >
> > >
> > >
> > > --
> > > http://blog.ruchith.org
> > > http://wso2.org
> > >
> > >
> >
> ---------------------------------------------------------------------
> > >
> > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > <ma...@ws.apache.org>
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > <ma...@ws.apache.org>
> > >
> > >
> >
> >
> >
> > --
> > David Illsley - IBM Web Services Development
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > <ma...@ws.apache.org>
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > <ma...@ws.apache.org>
> >
> >
> >
> >
> > --
> > Amila Suriarachchi,
> > WSO2 Inc.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by Amila Suriarachchi <am...@gmail.com>.
On Dec 19, 2007 9:40 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Honestly, there isn't really much point to doing this change now.
> Rampart already has an axis2.xml in their test repository - and people
> using Axis2 and/or Rampart already have axis2.xmls in *their*
> repositories. So simply changing the Rampart one will get it working
> there... and explaining how to change your own will get users working.
>
> The only thing we'd gain by doing the change in Axis2 itself now is the
> ability for people picking up new SNAPSHOT releases to have Rampart work
> with the default Axis2 SNAPSHOTs.
In addition to that this can be done with a single obvious commit. Which is
very easier than changing
already written bunch of test cases. Why you want to push this to hard way?
There are addressing, security and RM phases already there in axis2.xml. So
after adding dynamic
phases any way we have to refine all the module.xml files and axis2.xmlfiles.
I am not getting why you so much bother about this no harm single change.
>
> I'm planning to get the dynamic phase stuff happening over the holidays,
> and the next actual release of A2 will have that functionality built in.
>
> So if we want to spend time putting in a change which will just get
> taken out, that's fine, but seems a little silly especially since the
> axis2.xmls that already exist in Rampart and elsewhere are STILL going
> to need to be changed anyway. Make sense?
>
> --Glen
>
> Sanjiva Weerawarana wrote:
> > +1. I suggest we do this change and when we finish the dynamic module
> > thing come back and clean up the module.xml files and remove any extra
> > phases.
> >
> > That's always been the way we've done stuff .. we're not holding forward
> > progress while looking to some major change.
> >
> > Sanjiva.
> >
> > Amila Suriarachchi wrote:
> >>
> >>
> >> On Dec 18, 2007 11:49 AM, Glen Daniels <glen@thoughtcraft.com
> >> <ma...@thoughtcraft.com>> wrote:
> >>
> >> Hi Amila:
> >>
> >> Amila Suriarachchi wrote:
> >> > So it seems like you could get the same effect for now by
> >> explaining in
> >> > the Rampart documentation how to change the axis2.xml in the
> >> correct way
> >> > - or even including a sample.
> >> >
> >> > Make sense? (note I'm not saying -1, just trying to
> >> understand)
> >> >
> >> > yes I got your point. But rampart trunk depends on the
> >> Axis2-SNAPSHOT
> >> > and they need to change the
> >> > axis2 default xml in order to pass the test cases.
> >> > When we do a change locally we need to commit it to the
> >> repository soon.
> >> > These test cases can not be committed util we change the axis2
> >> default xml.
> >>
> >> Hm - really? Why can't Rampart simply use a custom axis2.xml with
> >> the
> >> new Phase at the root of their test repository?
> >>
> >>
> >> Then they have to update their axis2.xml when ever Axis2 does. But at
> >> least that is how(using axis2 kernal default xml) they have done it.
> >> Idea of keeping a axis2-SNAPSHOT dependency is to keep the rampart
> trunk
> >> sync with axis2 trunk.
> >> But I can not understand why you ask rampart people to do a big change
> >> while they could it with a simple
> >> axis2 change. There is no harm to axis2 with this change isn't it?
> >>
> >> thanks,
> >> Amila.
> >>
> >>
> >>
> >> --Glen
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> >> <ma...@ws.apache.org>
> >> For additional commands, e-mail: axis-dev-help@ws.apache.org
> >> <ma...@ws.apache.org>
> >>
> >>
> >>
> >>
> >> --
> >> Amila Suriarachchi,
> >> WSO2 Inc.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by David Illsley <da...@gmail.com>.
Sounds ok to me.
So, do we have any requirements for dynamic phases beyond simply:
A module may define a phase and its location relative to other phases
?
Cheers,
David
On Dec 18, 2007 3:52 PM, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> +1. I suggest we do this change and when we finish the dynamic module
> thing come back and clean up the module.xml files and remove any extra
> phases.
>
> That's always been the way we've done stuff .. we're not holding forward
> progress while looking to some major change.
>
> Sanjiva.
>
> Amila Suriarachchi wrote:
> >
> >
> > On Dec 18, 2007 11:49 AM, Glen Daniels <glen@thoughtcraft.com
>
> > <ma...@thoughtcraft.com>> wrote:
> >
> > Hi Amila:
> >
> > Amila Suriarachchi wrote:
> > > So it seems like you could get the same effect for now by
> > explaining in
> > > the Rampart documentation how to change the axis2.xml in the
> > correct way
> > > - or even including a sample.
> > >
> > > Make sense? (note I'm not saying -1, just trying to understand)
> > >
> > > yes I got your point. But rampart trunk depends on the
> > Axis2-SNAPSHOT
> > > and they need to change the
> > > axis2 default xml in order to pass the test cases.
> > > When we do a change locally we need to commit it to the
> > repository soon.
> > > These test cases can not be committed util we change the axis2
> > default xml.
> >
> > Hm - really? Why can't Rampart simply use a custom axis2.xml with the
> > new Phase at the root of their test repository?
> >
> >
> > Then they have to update their axis2.xml when ever Axis2 does. But at
> > least that is how(using axis2 kernal default xml) they have done it.
> > Idea of keeping a axis2-SNAPSHOT dependency is to keep the rampart trunk
> > sync with axis2 trunk.
> > But I can not understand why you ask rampart people to do a big change
> > while they could it with a simple
> > axis2 change. There is no harm to axis2 with this change isn't it?
> >
> > thanks,
> > Amila.
> >
> >
> >
> > --Glen
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > <ma...@ws.apache.org>
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > <ma...@ws.apache.org>
> >
> >
> >
> >
> > --
> > Amila Suriarachchi,
> > WSO2 Inc.
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
I think we should allow the Rampart folks this judgement call- if they
want it then we should do it (we''ve spent like 30 messages about adding a
string to a config file; a *little* whacky IMO). What it allows is for one
to drop Rampart to a stock Axis2. Yes, a nightly on nightly.
Yes we're planning a release in February- but our track record of timely
Axis2 releases isn't great.
So let's just do it and get on with doing the right thing.
On dynamic phases- Glen it'll be great if you could post some use cases
and requirements and design before writing up a bunch of code. See David's
mail too.
Sanjiva.
Glen Daniels wrote:
> Honestly, there isn't really much point to doing this change now.
> Rampart already has an axis2.xml in their test repository - and people
> using Axis2 and/or Rampart already have axis2.xmls in *their*
> repositories. So simply changing the Rampart one will get it working
> there... and explaining how to change your own will get users working.
>
> The only thing we'd gain by doing the change in Axis2 itself now is the
> ability for people picking up new SNAPSHOT releases to have Rampart work
> with the default Axis2 SNAPSHOTs.
>
> I'm planning to get the dynamic phase stuff happening over the holidays,
> and the next actual release of A2 will have that functionality built in.
>
> So if we want to spend time putting in a change which will just get
> taken out, that's fine, but seems a little silly especially since the
> axis2.xmls that already exist in Rampart and elsewhere are STILL going
> to need to be changed anyway. Make sense?
>
> --Glen
>
> Sanjiva Weerawarana wrote:
>> +1. I suggest we do this change and when we finish the dynamic module
>> thing come back and clean up the module.xml files and remove any extra
>> phases.
>>
>> That's always been the way we've done stuff .. we're not holding
>> forward progress while looking to some major change.
>>
>> Sanjiva.
>>
>> Amila Suriarachchi wrote:
>>>
>>>
>>> On Dec 18, 2007 11:49 AM, Glen Daniels <glen@thoughtcraft.com
>>> <ma...@thoughtcraft.com>> wrote:
>>>
>>> Hi Amila:
>>>
>>> Amila Suriarachchi wrote:
>>> > So it seems like you could get the same effect for now by
>>> explaining in
>>> > the Rampart documentation how to change the axis2.xml in the
>>> correct way
>>> > - or even including a sample.
>>> >
>>> > Make sense? (note I'm not saying -1, just trying to
>>> understand)
>>> >
>>> > yes I got your point. But rampart trunk depends on the
>>> Axis2-SNAPSHOT
>>> > and they need to change the
>>> > axis2 default xml in order to pass the test cases.
>>> > When we do a change locally we need to commit it to the
>>> repository soon.
>>> > These test cases can not be committed util we change the axis2
>>> default xml.
>>>
>>> Hm - really? Why can't Rampart simply use a custom axis2.xml
>>> with the
>>> new Phase at the root of their test repository?
>>>
>>>
>>> Then they have to update their axis2.xml when ever Axis2 does. But at
>>> least that is how(using axis2 kernal default xml) they have done it.
>>> Idea of keeping a axis2-SNAPSHOT dependency is to keep the rampart trunk
>>> sync with axis2 trunk.
>>> But I can not understand why you ask rampart people to do a big
>>> change while they could it with a simple
>>> axis2 change. There is no harm to axis2 with this change isn't it?
>>>
>>> thanks,
>>> Amila.
>>>
>>>
>>>
>>> --Glen
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>>> <ma...@ws.apache.org>
>>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>> <ma...@ws.apache.org>
>>>
>>>
>>>
>>>
>>> --
>>> Amila Suriarachchi,
>>> WSO2 Inc.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Honestly, there isn't really much point to doing this change now.
Rampart already has an axis2.xml in their test repository - and people
using Axis2 and/or Rampart already have axis2.xmls in *their*
repositories. So simply changing the Rampart one will get it working
there... and explaining how to change your own will get users working.
The only thing we'd gain by doing the change in Axis2 itself now is the
ability for people picking up new SNAPSHOT releases to have Rampart work
with the default Axis2 SNAPSHOTs.
I'm planning to get the dynamic phase stuff happening over the holidays,
and the next actual release of A2 will have that functionality built in.
So if we want to spend time putting in a change which will just get
taken out, that's fine, but seems a little silly especially since the
axis2.xmls that already exist in Rampart and elsewhere are STILL going
to need to be changed anyway. Make sense?
--Glen
Sanjiva Weerawarana wrote:
> +1. I suggest we do this change and when we finish the dynamic module
> thing come back and clean up the module.xml files and remove any extra
> phases.
>
> That's always been the way we've done stuff .. we're not holding forward
> progress while looking to some major change.
>
> Sanjiva.
>
> Amila Suriarachchi wrote:
>>
>>
>> On Dec 18, 2007 11:49 AM, Glen Daniels <glen@thoughtcraft.com
>> <ma...@thoughtcraft.com>> wrote:
>>
>> Hi Amila:
>>
>> Amila Suriarachchi wrote:
>> > So it seems like you could get the same effect for now by
>> explaining in
>> > the Rampart documentation how to change the axis2.xml in the
>> correct way
>> > - or even including a sample.
>> >
>> > Make sense? (note I'm not saying -1, just trying to
>> understand)
>> >
>> > yes I got your point. But rampart trunk depends on the
>> Axis2-SNAPSHOT
>> > and they need to change the
>> > axis2 default xml in order to pass the test cases.
>> > When we do a change locally we need to commit it to the
>> repository soon.
>> > These test cases can not be committed util we change the axis2
>> default xml.
>>
>> Hm - really? Why can't Rampart simply use a custom axis2.xml with
>> the
>> new Phase at the root of their test repository?
>>
>>
>> Then they have to update their axis2.xml when ever Axis2 does. But at
>> least that is how(using axis2 kernal default xml) they have done it.
>> Idea of keeping a axis2-SNAPSHOT dependency is to keep the rampart trunk
>> sync with axis2 trunk.
>> But I can not understand why you ask rampart people to do a big change
>> while they could it with a simple
>> axis2 change. There is no harm to axis2 with this change isn't it?
>>
>> thanks,
>> Amila.
>>
>>
>>
>> --Glen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> <ma...@ws.apache.org>
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>> <ma...@ws.apache.org>
>>
>>
>>
>>
>> --
>> Amila Suriarachchi,
>> WSO2 Inc.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
+1. I suggest we do this change and when we finish the dynamic module
thing come back and clean up the module.xml files and remove any extra
phases.
That's always been the way we've done stuff .. we're not holding forward
progress while looking to some major change.
Sanjiva.
Amila Suriarachchi wrote:
>
>
> On Dec 18, 2007 11:49 AM, Glen Daniels <glen@thoughtcraft.com
> <ma...@thoughtcraft.com>> wrote:
>
> Hi Amila:
>
> Amila Suriarachchi wrote:
> > So it seems like you could get the same effect for now by
> explaining in
> > the Rampart documentation how to change the axis2.xml in the
> correct way
> > - or even including a sample.
> >
> > Make sense? (note I'm not saying -1, just trying to understand)
> >
> > yes I got your point. But rampart trunk depends on the
> Axis2-SNAPSHOT
> > and they need to change the
> > axis2 default xml in order to pass the test cases.
> > When we do a change locally we need to commit it to the
> repository soon.
> > These test cases can not be committed util we change the axis2
> default xml.
>
> Hm - really? Why can't Rampart simply use a custom axis2.xml with the
> new Phase at the root of their test repository?
>
>
> Then they have to update their axis2.xml when ever Axis2 does. But at
> least that is how(using axis2 kernal default xml) they have done it.
> Idea of keeping a axis2-SNAPSHOT dependency is to keep the rampart trunk
> sync with axis2 trunk.
> But I can not understand why you ask rampart people to do a big change
> while they could it with a simple
> axis2 change. There is no harm to axis2 with this change isn't it?
>
> thanks,
> Amila.
>
>
>
> --Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> For additional commands, e-mail: axis-dev-help@ws.apache.org
> <ma...@ws.apache.org>
>
>
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by Amila Suriarachchi <am...@gmail.com>.
On Dec 18, 2007 11:49 AM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi Amila:
>
> Amila Suriarachchi wrote:
> > So it seems like you could get the same effect for now by explaining
> in
> > the Rampart documentation how to change the axis2.xml in the correct
> way
> > - or even including a sample.
> >
> > Make sense? (note I'm not saying -1, just trying to understand)
> >
> > yes I got your point. But rampart trunk depends on the Axis2-SNAPSHOT
> > and they need to change the
> > axis2 default xml in order to pass the test cases.
> > When we do a change locally we need to commit it to the repository soon.
> > These test cases can not be committed util we change the axis2 default
> xml.
>
> Hm - really? Why can't Rampart simply use a custom axis2.xml with the
> new Phase at the root of their test repository?
Then they have to update their axis2.xml when ever Axis2 does. But at least
that is how(using axis2 kernal default xml) they have done it. Idea of
keeping a axis2-SNAPSHOT dependency is to keep the rampart trunk
sync with axis2 trunk.
But I can not understand why you ask rampart people to do a big change while
they could it with a simple
axis2 change. There is no harm to axis2 with this change isn't it?
thanks,
Amila.
>
>
> --Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Amila:
Amila Suriarachchi wrote:
> So it seems like you could get the same effect for now by explaining in
> the Rampart documentation how to change the axis2.xml in the correct way
> - or even including a sample.
>
> Make sense? (note I'm not saying -1, just trying to understand)
>
> yes I got your point. But rampart trunk depends on the Axis2-SNAPSHOT
> and they need to change the
> axis2 default xml in order to pass the test cases.
> When we do a change locally we need to commit it to the repository soon.
> These test cases can not be committed util we change the axis2 default xml.
Hm - really? Why can't Rampart simply use a custom axis2.xml with the
new Phase at the root of their test repository?
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by Amila Suriarachchi <am...@gmail.com>.
On Dec 18, 2007 10:12 AM, Glen Daniels <gl...@thoughtcraft.com> 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 <davidillsley@gmail.com
> > <ma...@gmail.com>> 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
> > <ruchith.fernando@gmail.com <ma...@gmail.com>>
> 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
> > <amilasuriarachchi@gmail.com <ma...@gmail.com>>
> > 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 < glen@thoughtcraft.com
> > <ma...@thoughtcraft.com>> 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: axis-dev-unsubscribe@ws.apache.org
> > <ma...@ws.apache.org>
> > > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > <ma...@ws.apache.org>
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Amila Suriarachchi,
> > > > WSO2 Inc.
> > >
> > >
> > >
> > > --
> > > http://blog.ruchith.org
> > > http://wso2.org
> > >
> > >
> >
> ---------------------------------------------------------------------
> > >
> > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > <ma...@ws.apache.org>
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > <ma...@ws.apache.org>
> > >
> > >
> >
> >
> >
> > --
> > David Illsley - IBM Web Services Development
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > <ma...@ws.apache.org>
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > <ma...@ws.apache.org>
> >
> >
> >
> >
> > --
> > Amila Suriarachchi,
> > WSO2 Inc.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by Glen Daniels <gl...@thoughtcraft.com>.
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)
Thanks,
--Glen
Amila Suriarachchi wrote:
>
>
> On Dec 14, 2007 3:31 PM, David Illsley <davidillsley@gmail.com
> <ma...@gmail.com>> 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
> <ruchith.fernando@gmail.com <ma...@gmail.com>> 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
> <amilasuriarachchi@gmail.com <ma...@gmail.com>>
> 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 < glen@thoughtcraft.com
> <ma...@thoughtcraft.com>> 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: axis-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> <ma...@ws.apache.org>
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Amila Suriarachchi,
> > > WSO2 Inc.
> >
> >
> >
> > --
> > http://blog.ruchith.org
> > http://wso2.org
> >
> >
> ---------------------------------------------------------------------
> >
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> <ma...@ws.apache.org>
> >
> >
>
>
>
> --
> David Illsley - IBM Web Services Development
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> For additional commands, e-mail: axis-dev-help@ws.apache.org
> <ma...@ws.apache.org>
>
>
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by Amila Suriarachchi <am...@gmail.com>.
On Dec 14, 2007 3:31 PM, David Illsley <da...@gmail.com> 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 <ru...@gmail.com>
> 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 <am...@gmail.com>
> 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 <gl...@thoughtcraft.com> 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: axis-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Amila Suriarachchi,
> > > WSO2 Inc.
> >
> >
> >
> > --
> > http://blog.ruchith.org
> > http://wso2.org
> >
> > ---------------------------------------------------------------------
> >
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
>
> --
> David Illsley - IBM Web Services Development
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by Deepal jayasinghe <de...@gmail.com>.
Amila Suriarachchi wrote:
> 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 <chinthaka@opensource.lk
> <ma...@opensource.lk>> 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.
Yes , and I do not see any problem with that and believe any USER does
not complain about that , and only developers are trying to introduce that.
>
> 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.
Yes.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by Amila Suriarachchi <am...@gmail.com>.
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 <ch...@opensource.lk> 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 <ru...@gmail.com>
> 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 <
> amilasuriarachchi@gmail.com> 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 <gl...@thoughtcraft.com> 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: axis-dev-unsubscribe@ws.apache.org
> >>>> For additional commands, e-mail: axis-dev-help@ws.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Amila Suriarachchi,
> >>> WSO2 Inc.
> >>
> >>
> >> --
> >> http://blog.ruchith.org
> >> http://wso2.org
> >>
> >> ---------------------------------------------------------------------
> >>
> >> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-dev-help@ws.apache.org
> >>
> >>
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by Deepal Jayasinghe <de...@opensource.lk>.
> wrote:
>> +1. While dynamic self-configuring phases is a cool and all-powerful,
>> it seems overkill for most of what we need. What we need is to make sure
>
> I totally disagree. We've added phases for addressing, security,
> reliability... yes of course those are very common extensions, but
> they are EXTENSIONS. The whole point of the Module architecture was
> that builders of extensions, including (good lord, really?) people not
> even at Apache, should be able to create drop-in components that will
> work without as much painful configuration as we needed in Axis1. We
> obviously haven't achieved that with the current design, since this is
> now the third or fourth time post-release that we're saying "oh yeah
> let's change the base axis2.xml for everyone so that we can use this
> module we're writing."
Well, not everyone write module does not going to change axis2.xml , and
I do not think that all of them will try to add a new phase to
axis2.xml. Most of the time they can live with what we have in axis2.xml
, not only that our phase rules are powerful enough to support what
security is looking for. Even though they try to add a new phase to
axis2.xml they can live without doing that.
>
> We should have had this since the beginning, and we should add it in
> 1.4 as planned.
No objection. However I would like to call for a vote in user list and
developer list before we do major architectural changes , we need to
listen to users who actually uses Axis2 and need to ask their opinion on
those.
>
>> that Axis2 can do security out of the box- that's absolutely
>> critical. CXF for example bundles security and RM with the core
>> platform - if we make this thing so painful to make security to work
>> people will simply walk. Let's not get carried away with abstraction
>> and lose touch with reality.
>
> I think you're making my point here. It's changing everyone's
> axis2.xml that is a pain (how many new Phases do you need to add in
> how many different places? - oh missed one!). The point of the model
> has always been "drop foo.mar into modules/ and it should pretty much
> work." Of course there will be complex issues that will sometimes
> require manual overrides to get arbitrary combinations of stuff
> working together. But for the core set of modules it should be just
> that easy.
As I said earlier , security people can live without it. So I do not see
big issue with that. I do agree what you purpose is very cool and very
useful.
>
>> Making dynamic phases work just for the axis2 base platform only is
>> silly IMO. If outside users are asking for it let's do it- but we
>> first have other high(er) priority items to finish IMO.
>
> There is no question in my mind that we need to do it, unless we're
> going to stop talking about how easy it is to write and add Axis2
> Modules and just admit that we're actually a monolithic platform that
> supports only a few well defined Modules.
:)
We all need think , that Axis2 is not a toy anymore and we should not
and can not change Axis2 codebase and architecture way we want. We need
to think about the people who are using that as well.
-Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Sanjiva Weerawarana wrote:
> +1. While dynamic self-configuring phases is a cool and all-powerful, it
> seems overkill for most of what we need. What we need is to make sure
I totally disagree. We've added phases for addressing, security,
reliability... yes of course those are very common extensions, but they
are EXTENSIONS. The whole point of the Module architecture was that
builders of extensions, including (good lord, really?) people not even
at Apache, should be able to create drop-in components that will work
without as much painful configuration as we needed in Axis1. We
obviously haven't achieved that with the current design, since this is
now the third or fourth time post-release that we're saying "oh yeah
let's change the base axis2.xml for everyone so that we can use this
module we're writing."
We should have had this since the beginning, and we should add it in 1.4
as planned.
> that Axis2 can do security out of the box- that's absolutely critical.
> CXF for example bundles security and RM with the core platform - if we
> make this thing so painful to make security to work people will simply
> walk. Let's not get carried away with abstraction and lose touch with
> reality.
I think you're making my point here. It's changing everyone's axis2.xml
that is a pain (how many new Phases do you need to add in how many
different places? - oh missed one!). The point of the model has always
been "drop foo.mar into modules/ and it should pretty much work." Of
course there will be complex issues that will sometimes require manual
overrides to get arbitrary combinations of stuff working together. But
for the core set of modules it should be just that easy.
> Making dynamic phases work just for the axis2 base platform only is
> silly IMO. If outside users are asking for it let's do it- but we first
> have other high(er) priority items to finish IMO.
There is no question in my mind that we need to do it, unless we're
going to stop talking about how easy it is to write and add Axis2
Modules and just admit that we're actually a monolithic platform that
supports only a few well defined Modules.
--Glen
> Sanjiva.
>
> Deepal Jayasinghe wrote:
>>> Deepal,
>>> I disagree. It complicates the chain and our configuration files for
>>> no benefit to a large number of users.
>>>
>> I do not agree with you in this , because just we have configurations in
>> axis2.xml people will not get confused and did not make the system
>> complicated.
>> If they do not want they can remove that.
>>> The lack of dynamic phases also requires people to repetitively edit
>>> axis2.xml files when adding something we haven't yet added a phase
>>> for....
>> I agree that , but deploying module is not that frequent thing like
>> deploying services. So this is just one time cost.
>>> it's really naff from a user perspective, especially given all
>>> the huffing and puffing in articles about how great our module
>>> architecture is.
>>>
>> Yes I agree with you in this , but there should be a limitation of the
>> flexibility we should give.
>>> Can I ask if there's something specific you're worried about wrt
>>> dynamic phases, or if it's just something you don't see a need for?
>>>
>> I dont see need for it , I know it is very cool and I really like to
>> have. However at the this point Axis2 is kind of stable and people are
>> using that for production so we should not break the backward
>> compatibility. Second as I said earlier mail as well none of the user
>> asked for this.
>>
>> We have lot more to fix and improve in Axis2 (I mean high priority items
>> that users have requested) , so we need to focus on that. My general
>> rule is , if something working fine and no body complain about that ,
>> then we do not need to change that. :)
>>
>> -Deepal
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
+1. While dynamic self-configuring phases is a cool and all-powerful, it
seems overkill for most of what we need. What we need is to make sure that
Axis2 can do security out of the box- that's absolutely critical. CXF for
example bundles security and RM with the core platform - if we make this
thing so painful to make security to work people will simply walk. Let's
not get carried away with abstraction and lose touch with reality.
Making dynamic phases work just for the axis2 base platform only is silly
IMO. If outside users are asking for it let's do it- but we first have
other high(er) priority items to finish IMO.
Sanjiva.
Deepal Jayasinghe wrote:
>> Deepal,
>> I disagree. It complicates the chain and our configuration files for
>> no benefit to a large number of users.
>>
> I do not agree with you in this , because just we have configurations in
> axis2.xml people will not get confused and did not make the system
> complicated.
> If they do not want they can remove that.
>> The lack of dynamic phases also requires people to repetitively edit
>> axis2.xml files when adding something we haven't yet added a phase
>> for....
> I agree that , but deploying module is not that frequent thing like
> deploying services. So this is just one time cost.
>> it's really naff from a user perspective, especially given all
>> the huffing and puffing in articles about how great our module
>> architecture is.
>>
> Yes I agree with you in this , but there should be a limitation of the
> flexibility we should give.
>> Can I ask if there's something specific you're worried about wrt
>> dynamic phases, or if it's just something you don't see a need for?
>>
> I dont see need for it , I know it is very cool and I really like to
> have. However at the this point Axis2 is kind of stable and people are
> using that for production so we should not break the backward
> compatibility. Second as I said earlier mail as well none of the user
> asked for this.
>
> We have lot more to fix and improve in Axis2 (I mean high priority items
> that users have requested) , so we need to focus on that. My general
> rule is , if something working fine and no body complain about that ,
> then we do not need to change that. :)
>
> -Deepal
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by Deepal Jayasinghe <de...@opensource.lk>.
> Deepal,
> I disagree. It complicates the chain and our configuration files for
> no benefit to a large number of users.
>
I do not agree with you in this , because just we have configurations in
axis2.xml people will not get confused and did not make the system
complicated.
If they do not want they can remove that.
> The lack of dynamic phases also requires people to repetitively edit
> axis2.xml files when adding something we haven't yet added a phase
> for....
I agree that , but deploying module is not that frequent thing like
deploying services. So this is just one time cost.
> it's really naff from a user perspective, especially given all
> the huffing and puffing in articles about how great our module
> architecture is.
>
Yes I agree with you in this , but there should be a limitation of the
flexibility we should give.
> Can I ask if there's something specific you're worried about wrt
> dynamic phases, or if it's just something you don't see a need for?
>
I dont see need for it , I know it is very cool and I really like to
have. However at the this point Axis2 is kind of stable and people are
using that for production so we should not break the backward
compatibility. Second as I said earlier mail as well none of the user
asked for this.
We have lot more to fix and improve in Axis2 (I mean high priority items
that users have requested) , so we need to focus on that. My general
rule is , if something working fine and no body complain about that ,
then we do not need to change that. :)
-Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by David Illsley <da...@gmail.com>.
Deepal,
I disagree. It complicates the chain and our configuration files for
no benefit to a large number of users.
The lack of dynamic phases also requires people to repetitively edit
axis2.xml files when adding something we haven't yet added a phase
for.... it's really naff from a user perspective, especially given all
the huffing and puffing in articles about how great our module
architecture is.
Can I ask if there's something specific you're worried about wrt
dynamic phases, or if it's just something you don't see a need for?
Cheers,
David
On Dec 17, 2007 9:25 AM, Deepal jayasinghe <de...@gmail.com> wrote:
> Eran Chinthaka 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?
> Yes for the most commonally used module like Addressing , Sandesha and
> Security.
> > If that is the case then I feel there is something wrong with Axis2
> > architecture itself.
> :)
> >
> >
> > 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.
> Yes I do agree with you , but just having security phase in the chain
> will do nothing unless you have handlers in the phase.
> > 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 strongly believed and believe dynamic phase rules are more than what
> we want , its better if we can find a simple solution than that.
>
> -Deepal
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by Deepal jayasinghe <de...@gmail.com>.
Eran Chinthaka 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?
Yes for the most commonally used module like Addressing , Sandesha and
Security.
> If that is the case then I feel there is something wrong with Axis2
> architecture itself.
:)
>
>
> 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.
Yes I do agree with you , but just having security phase in the chain
will do nothing unless you have handlers in the phase.
> 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 strongly believed and believe dynamic phase rules are more than what
we want , its better if we can find a simple solution than that.
-Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by Eran Chinthaka <ch...@opensource.lk>.
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? If that is the case then I
feel there is something wrong with Axis2 architecture itself.
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 <ru...@gmail.com> 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 <am...@gmail.com> 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 <gl...@thoughtcraft.com> 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: axis-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Amila Suriarachchi,
>>> WSO2 Inc.
>>
>>
>> --
>> http://blog.ruchith.org
>> http://wso2.org
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by David Illsley <da...@gmail.com>.
+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 <ru...@gmail.com> 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 <am...@gmail.com> 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 <gl...@thoughtcraft.com> 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: axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> > >
> >
> >
> >
> > --
> > Amila Suriarachchi,
> > WSO2 Inc.
>
>
>
> --
> http://blog.ruchith.org
> http://wso2.org
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by Ruchith Fernando <ru...@gmail.com>.
+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 <am...@gmail.com> 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 <gl...@thoughtcraft.com> 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: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
--
http://blog.ruchith.org
http://wso2.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by Amila Suriarachchi <am...@gmail.com>.
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 <gl...@thoughtcraft.com> 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: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by Deepal Jayasinghe <de...@opensource.lk>.
> 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.
The argument was to remove only the on-fault flow not the
out-fault-flow. If we are going to remove out-fault-flow we need to
discuss some more about that. In the meantime we need to keep in mind
that Axis2 is in production and people do not like to do this kind of
changes. So I would rather like to keep what we have as it is.
-Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Adding security phase to OutFaultFlow
Posted by Glen Daniels <gl...@thoughtcraft.com>.
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org