cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: isGET in interceptors...
Date Fri, 15 Dec 2006 15:56:04 GMT
On 12/15/06, Guillaume Nodet <gnodet@gmail.com> wrote:
>
> I'm not quite sure that there is a need to change the chain
> dynamically at all.  Why not considering a tree instead of
> a simple list ?  Depending on some conditions (HTTP VERB,
> operation QName, ...), a branch of the tree would be used.
> I guess this may need a bit of design, but would allow a clean
> separation of interceptors between, while allowing a static
> interceptor chain.


I'm not sure I follow. I'm reluctant to introduce some kind of dependency on
HTTP verbs into the core of CXF.

As I said in a previous mail, I don't really see how policies can
> be applied on a per operation level without allowing different
> interceptor chain (or all interceptors would have to check if
> they should be applied, which is the current case with the GET
> problem).
> Would it be too complex ? Or there is no real use case for that ?


I don't know that this is a per-operation issue.  We're trying to use the
same BindingOperation for both POST and GET, so I don't see how applying a
policy at that level would help. I do think we need to be able to apply
policies at the operation level though and we already have some hooks for
that. Namely message.getContextualProperty() which searches the message,
exchange, operation, operation, binding, etc.

Can you explain a little more what you mean?

On 12/15/06, Dan Diephouse <dan@envoisolutions.com> wrote:
> > On 12/7/06, James Mao <james.mao@iona.com> wrote:
> > >
> > >
> > > I'm OK with the changing the chain dynamically, they both works. if we
> > > change the chain dynamically, then for both the SOAP binding and XML
> > > binding and any other binding to filter the interceptors dynamically,
> i
> > > mean the maintenance cost is same. but this approach do have a
> benefit,
> > > the benefit is that all the isGET logic in the same place, if we want
> to
> > > add some configuration for this function, it'll be more easier. But
> the
> > > other side is, it'll be harder to change the chain if the interceptor
> is
> > > coarse-grained, that means we want some part of the logic of the
> > > inteceptor, but in some conditions we want to exclude the
> interceptors,
> > > but yes, you can break down the interceptors into pieces to work
> around
> > > the problem. So there's pros and cons.
> >
> >
> > Can you please justify the performance benefit of this if we go down
> this
> > route? As noted in the previous email if we have a dynamic interceptor
> > removal, than we still have problems if a user adds an interceptor and
> they
> > aren't aware they need to look for the isGET case.
> >
> > I think we should synthesize a document, and unless you can provide some
> > compelling performance reason I don't see any reason not too. You
> haven't
> > shown anything to back up your reasoning that there is a performance
> issue.
> >
> > - Dan
> >
> >
> > --
> > Dan Diephouse
> > Envoi Solutions
> > http://envoisolutions.com | http://netzooid.com/blog
> >
> >
>
>
> --
> Cheers,
> Guillaume Nodet
>



-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message