Thanks... will look into the filters - very new to Jersey...
Clarification.. All my Jersey resources have the following annotation:
@Produces({"application/json","application/xml"})
The Swing client will request XML and the web clients are free to choose
JSON
Although there maybe a slight benefit in terms of transfer efficiency using
JSON for the Swing APP given its more compact nature.
-A-
Paul Sandoz wrote:
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> 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-tp2724127p2725524.html
Sent from the Jersey mailing list archive at Nabble.com.