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 <[EMAIL PROTECTED]> wrote:
+1 ... I also believe we should be able to have module define/arrange
phases without
having to edit the axis2.xml file and the handlers themselves can take
care of fault processing.
Even in Rampart we use the same handler in the fault flows and we do
the fault handling internally
without really checking which flow it is in.
But, as Amila mentioned, until we get those implemented lets go ahead
with the changes to axis2.xml to
help fix the Rampart fault handling issue.
Thanks,
Ruchith
On Dec 12, 2007 7:15 PM, Amila Suriarachchi <[EMAIL PROTECTED]> wrote:
hi glen,
I am agreeing with you for the two features you have mentioned. And also As
I remember these two features
were there in the list that came up after last Apache Con hacathon. So there
were no objections for this
features.
But for the moment since axis2 do not have these features the only option
Nandana have is to edit the axis2.xml. So lets allow him to continue with
this change and later it can be changed once those features are there.
thanks,
Amila.
On Dec 12, 2007 6:39 PM, Glen Daniels <[EMAIL PROTECTED]> wrote:
Hi Nandana!
Nandana Mihindukulasooriya wrote:
Hi Devs,
Rampart is in the process of providing security in the fault
flows. In order to do that,
we need to introduce security phase in to out fault flow. It is already
there in the in fault flow.
so the axis2.xml have to modified to include,
<phaseOrder type="OutFaultFlow">
<!-- user can add his own phases to this area -->
<phase name="OperationOutFaultPhase"/>
<phase name="RMPhase"/>
<phase name="PolicyDetermination"/>
<phase name="MessageOut"/>
*<phase name="Security"/>*
</phaseOrder>
I'd much rather that we bit the bullet and finally got dynamic phase
deployment working. It is ridiculous to keep changing our default
axis2.xml (think about how many already deployed versions there are, and
even how many copies we have floating around in our tests etc) when the
whole point of Modules is that they should "drop in" to your system and
require minimal, if any, configuration. I'm up for taking point on
this, and should hopefully be able to get started soon.
That said, I also think we should dispense with Fault Flows as has been
discussed a few times. They don't do much useful work and unnecessarily
complicate the configuration. There should just be "in" and "out", and
if you have a handler which really cares whether a message is a fault or
not, it should just check that in invoke().
There's my $0.02 - thoughts, devs?
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Amila Suriarachchi,
WSO2 Inc.
--
http://blog.ruchith.org
http://wso2.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
