On Tue, 2008-03-25 at 13:22 +0100, Paul Sandoz wrote:
> On Mar 24, 2008, at 5:07 PM, Martin Grotzke wrote:
>
> > Hi Paul,
> >
> > On Tue, 2008-03-18 at 11:26 +0100, Paul Sandoz wrote:
> >> Hi Martin,
> >>
> >> In relation to this you might want to check out a blog comment
> >> from James:
> >>
> >> http://blogs.sun.com/sandoz/entry/
> >> integrating_jersey_and_spring_take#comment-1205397278000
> >>
> >> it is using the Spring auto-wiring feature (if a bean is not
> >> registered
> >> in the XML config). Perhaps this may do what you require without
> >> having
> >> to create your own annotation?
> > now I tried James' solution using autowiring. Besides that I
> > personally
> > don't like autowiring very much but prefer more explicit approaches, I
> > find it hard to decide if it might be critical/dangerous that also all
> > jersey components are created as spring beans. E.g. what happens if
> > these are created as proxies for some reason...
> >
>
> You mean a "man-in-the-middle" kind of attack? is it not up to the
> application developer/deployer to ensure things are configured
> correctly and securely?
Of course you always have to know what you're doing. But especially when
it comes to transparent (auto-) proxying the application developer is
not always completely aware if a class is proxied or not.
This is intrinsic to the "auto"-nature in auto-proxying - at shall be
transparent and you shouldn't be forced to have too much to do with it.
Though - IMHO the developer should _always_ exactly know what's
happening, so he/she should always know which beans are proxied when and
why.
But in practice I suspect that the auto/transparent/we-do-it-all-for-you
features are leading to less awareness.
So if I have the choice between a way that might pull in problems caused
by this and a way that cannot pull in problems with this I would choose
the latter one. I'd say this is simply more robust.
I hope I could express what I want to say :)
> > One question that I have: what is the implementation of inject(Object)
> > good for, which scenario shall be supported by this?
> >
>
> I anticipated that if the underlying ComponentProvider could not
> instantiate a class (e.g. per-request with a Jersey specific
> constructor) then Jersey could instantiate and then call
> ComponentProvider.inject. That was the intention, but i realized i
> forgot to put that in the Jersey code.
Sorry, I was referring to James' autowiring SpringComponentProvider
implementation of inject(Object), not the basic intention of it :)
Cheers,
Martin
>
> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>