users@jersey.java.net

Re: [Jersey] Jersey Client/Server WADL

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Mon, 27 Apr 2009 13:32:12 +0200

Hi,

I would avoid client generation of stub code and instead utilize the
Jersey client API.

On Apr 27, 2009, at 12:43 PM, aloleary wrote:

>
> Thanks good to hear on right track...
>
> I am also currently investigating whether to make the JAXB Beans ==
> JPA
> Entities and have one "source" of shared data ... from an XML and
> Persistence point of view...
>
> The Swing client has an embedded JavaDB database for an offline
> "cache" of
> the information so essentially using the same (or pretty similar) JPA
> entities again so essentially I have the following:
>
> Client:
> Swing<-->JPA<-->XML<-->JERSEY_CLIENT<-->JSON<-->
>
                                        ^
                                         |
                                     JAXB?

BTW it is also possible to plugin a client side caching mechanism
within the Jersey client API as a filter. Basically the filter can
check the database before making a request (i.e. a simple/local HTTP
cache). A developer was utilizing a similar technique to cache JAXB
beans, rather than the bytes of XML documents, to avoid parsing/
marshalling.

IMHO there is no point using JSON if you do not require it. For your
case the client requesting XML is fine. For browsers JSON is better
i.e. the client can ask for the most appropriate format for its
purposes.


> [Over Internet (https+basic_auth)]
>
> Server:
> <-->JSON<-->JERSEY_SERVER<-->XML<-->JPA<-->DB
>
> Something I would like from performance/memory point of view is to
> go from
> DB to JSON/XML without hydrating everything into lists of java
> objects first
> which are then converted via JAXB but I dont see a fast way of doing
> that
> right now..
>

Caching can help performance, either HTTP caching or using something
like Ehcache. So can supporting Last-Modified or ETags.

I suspect there is probably a high-level way to integrate Ehcache
without affecting the developer code too much.

Paul.



>
> Felipe Gaścho wrote:
>>
>>> 2: Is this a "sane" approach ?
>>
>> This is a nice approach.. I am using it and so far I have high
>> performance and scalability..
>>
>> about the client side, you can use the Jersey client API.. nice and
>> easy..
>>
>> * the test framework of Jersey is also very nice, but I am using EJBs
>> in the server side, so I lost my chance to adopt it :) Grizzly fail
>> to
>> inject the EJBs and the rest interface throws a null pointer
>> exception
>> ,............
>>
>> ---------------------------------------------------------------------
>> 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/Jersey-Client-Server-WADL-tp2724127p2725301.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
>