Hi Jo,
We plan to move the jersey-server-linking into the stable area by
september, probably merged with the jersey-server, but i think i may
tackle this next week.
I am not aware of any general framework to help map dto to jaxb
objects and handle the URI construction. NetBeans can generate JAX-RS
resource classes and JAXB beans from entity beans but it does not
round trip, it is generated once and the developer has to maintain the
code afterwards. IMHO this is a serious pain point for developers and
we don't currently have a good solution.
It's hard to do something like Rail's ActiveRecord in Java. IMHO the
less code the better. I do wonder if there is some sort of reflection-
based approach to dto/+JPA annotations and provide a generated
classes or instances, perhaps that could be augmented with additional
XML e.g. to support hypermedia-based actions. Often i would have
thought there is a lot of commonality between the dto and JAXB bean,
so info could be shared, and for keys you may want to translate these
into URIs. Off the top of my head i wonder if Project Lombok could
help (byte code weaving).
Tough problem and i do not have any clear ideas, not sure if anyone
has done anything, but i suspect there is room for some innovative
solutions.
Paul.
On Aug 6, 2010, at 5:49 PM, Jo Størset wrote:
> Hi,
>
> I'm evaluating possible solutions for a new web service api we need
> to make. Initially it will have to be a somewhat rpc-ish api (we're
> targetting existing j2me/gprs clients), but I hope to make it so
> that we can evolve it into something more restish as we go along.
>
> My main concern right now is how to handle the mapping between the
> domain and the representations, with the added complexity of things
> like generated urls. Earlier this year, there was a thread on rest-
> discuss, which overall seemed to lean towards something like:
>
> 25. feb. 2010 kl. 20.37, Craig McClanahan [1]:
>
>> When using JAX-RS, I'm finding myself more and more often building a
>> set of JAXB annotated classes that directly represent my resources,
>> separate from the classes that might represent my domain tier (with,
>> perhaps, JPA or Hibernate annotations on them).
>
> My own experience has been something of the same (or rather, trying
> the one model approach has proven difficult :) , but I am wondering
> if someone had more practical experiences/solutions to share for
> such a solution?
>
> Let's take an example. Say you want some simple jaxb model where
> elements with generated urls will be reused in different
> representations:
>
> <activity>
> <person>
> <orgUnit href="some url generated with jersey" />
> </person>
> </activity>
>
> <orgUnits>
> <orgUnit href="same url generated with jersey" />
> </orgUnit>
>
> So, I want some kind of service layer responsible for doing the
> mapping to/from a domain model to the jaxb resource model creating
> this xml. I would want this layer to be reasonably clean, without
> too much manual handling (or else changes quickly become difficult),
> but it has to solve a somewhat complex set of tasks:
>
> - mapping between models where the dto/jaxb objects and the domain
> objects are not similar (not one-to-one).
> - keeping track of objects that need things like urls generated and
> inserted at the appropriate place.
> - modular, so the same object mapping can be reused in different
> representations
>
> I could try to roll my own little framework helping with these
> tasks, but it would obviously be much better if there already are
> good solutions out there. What do others do, have you found good
> framework support for this?
>
> And, while waiting for jersey-server-linking to be ready for
> primetime (can we expect it to be promoted from experimental soon?),
> I'm also contemplating how to elegantly handle the generation of
> urls. The last time I as working with jersey, I rolled my own
> annotations similar to jersey-server-linking, but would like to
> avoid it if possible. Any ideas?
>
> [1] http://tech.groups.yahoo.com/group/rest-discuss/message/14914
>
> That will have to do for the weekend :)
> Jo
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>