On Mar 25, 2008, at 2:14 PM, Martin Grotzke wrote:
> 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 :)
>
Yes, i better understand your concern.
Paul.
>>> 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
>>