Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (athena.apache.org: domain of davidillsley@gmail.com
 designates 64.233.182.191 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=hLbIIa88/sFLIpjV3s/CuMUPesrE+gC8XCvO6HUc4YCkv9NXJElzQfT2uG/uTmjhQHf8qUpqmV5D+9LD8CDxDDBEH5PQoJFe5Puv4qbCX2AQHJdHZ41uMAJeD/UNLVo2QbBtF2cM7kmLDq5nfOmqwN03iliqBne8lPNPJdlDhSI=
Message-ID: <9abd5e730712140201u2d18aacer9c1dd7c62280cff3@mail.gmail.com>
Date: Fri, 14 Dec 2007 10:01:09 +0000
From: "David Illsley" <davidillsley@gmail.com>
To: axis-dev@ws.apache.org
Subject: Re: [AXIS2] Adding security phase to OutFaultFlow
In-Reply-To: <559c463d0712122130ma64decfv544d7cb946c5a60e@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <9e2fff830712120429x51ec7c93nfc6888f3d1219e14@mail.gmail.com>
	 <9e2fff830712120431t20c14ef1j7cb48f2447ebee9d@mail.gmail.com>
	 <475FDD79.6020305@thoughtcraft.com>
	 <60708f4b0712120545o7ccc1c66xa7337904f8d9ced@mail.gmail.com>
	 <559c463d0712122130ma64decfv544d7cb946c5a60e@mail.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 <ruchith.fernando@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 <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