On Oct 2, 2009, at 8:29 PM, Cemo Koc wrote:
>
> Ok I thought almos same... What about my last question
>
>
>> 3. I think that AnnotatedClassScanner
>> should be at jersey-core library. Because this class should have been
>> accessed from both Client Side and Server Side.
>
> In this case, our provider class will be in common library with
> entities and
> those other common things. However AnnotatedClassScanner is part of
> jersey-server library. If my client module has a depedency of this
> common
> library, it will have reference of jersey-server library. This class
> also
> should be part of jersey-core, shouldn't it?
>
I have so far been reluctant to have the client-side perform automatic
scanning, hence why this functionality is currently on available
within the jersey-server jar.
The main reason is when clients are used in servers the automatic
scanning by both could result in some confusion if components of the
latter are picked up unintentionally by the former.
However, there are probably ways to make such functionality opt-in
i.e. specific selection of a ClientConfig implementation.
Note that AnnotatedClassScanner is currently not part of the public API.
Craig logged an issue here:
https://jersey.dev.java.net/issues/show_bug.cgi?id=179
Feel free to add your thoughts to the issue as that will add more
weight to fix it.
Paul.
> Thanks
>
>
>
> Craig McClanahan wrote:
>>
>> Cemo Koc wrote:
>>> Hi all,
>>>
>>> I am very newbie to JAX-RS. I have read all spec and documentation
>>> since
>>> yesterday although dev.java.net has some serious issues.
>>>
>>> I have two different maven modules and each has different
>>> dependencies.
>>>
>>> Client side (com.x.y:client) has : jersey-client dependency
>>>
>>> [INFO] +- com.sun.jersey:jersey-client:jar:1.0.3.1:compile
>>> [INFO] | \- com.sun.jersey:jersey-core:jar:1.0.3.1:compile
>>> [INFO] | \- javax.ws.rs:jsr311-api:jar:1.0:compile
>>>
>>> Server side (com.x.y:server) has: jersey-server dependency and
>>> client
>>> dependency
>>> (Server side has resources.)
>>>
>>> [INFO] +- com.sun.jersey:jersey-server:jar:1.0.3.1:compile
>>> [INFO] | +- com.sun.jersey:jersey-core:jar:1.0.3.1:compile
>>> [INFO] | | \- javax.ws.rs:jsr311-api:jar:1.0:compile
>>> [INFO] | \- asm:asm:jar:3.1:compile
>>> [INFO] +- com.x.y:client:jar:2.3.7:compile
>>> [INFO] | \- com.sun.jersey:jersey-client:jar:1.0.1:compile
>>>
>>> 1. Is such implementation best practice in terms maven perspective?
>>>
>>> 2. This is about AnnotatedClassScanner which is used by our custom
>>> provider.
>>> Where my custom provider implementation should be? In my case it
>>> is at
>>> client side library because client side is referenced from Server
>>> side.
>>>
>>> 3. And If my implementation is right, I think that
>>> AnnotatedClassScanner
>>> should be at jersey-core library. Because this class should have
>>> been
>>> accessed from both Client Side and Server Side.
>>>
>>>
>> Why does your server module depend on the client module?
>>
>> When I have classes that are logically useful in both tiers (most
>> often,
>> the JAXB based model classes for my representations), I factor those
>> into a third "models" module that is then depended on by both
>> "server"
>> and "client". That could of course become a place for other shared
>> stuff, like providers that are needed at both ends. But this avoids
>> having your server drag in a bunch of stuff it doesn't otherwise need
>> (unless, of course, your server is a client for other services that
>> *it*
>> calls out to).
>>
>> Craig
>>> Thanks
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>>
>
> --
> View this message in context: http://n2.nabble.com/AnnotatedClassScanner-Best-Practice-tp3755924p3757025.html
> Sent from the Jersey mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>