2016-01-29 22:18 GMT+01:00 Sebastian Daschner <java_at_sebastian-daschner.de>:
> Thanks for the quick response. Inline:
>
> 1)
>
> I don't fully understand your point. Can you please explain your example
> in more details. What is the result of link deserialization?
>
>
> The idea is to enable Hypermedia in JSON responses via URIs. Something
> like:
>
> {
> "isbn": "1-1234-5678",
> "name": "Java",
> "author": "Duke",
> "_books": http://api.example.com/books",
> "_self": "http://api.example.com/books/1234"
> <http://api.example.com/books/1234>
> }
>
> with the URIs included in that Book POJO enabled by annotations.
>
> Given following JAX-RS resource:
>
> @Path("books")
> public class BooksResource {
>
> @GET
> public List<Book> getBooks() {...}
>
> @GET
> @Path("{id}")
> public Book getBook(@PathParam...) {}
> }
>
> And links to this resource would be accessed via annotations (e.g.
> "JsonbResourceLink") in the Book class (inspired by JAX-RS's UriBuilder):
>
> public class Book {
>
> @JsonbIgnore
> private String id;
> private String isbn;
> ...
> @JsonbProperty("_books")
> @JsonbResourceLink(resource = BooksResource.class, method = "getBooks")
> private URI books;
> }
>
>
> Even more helpful would be the replacement with path params with
> properties of that Book POJO.
> Romain, I fully agree with you that this is a rather complex functionality!
>
> ...
> @JsonbProperty("_self")
> @JsonbResourceLink(resource = BooksResource.class, method = "getBook",
> properties = {"id"})
> private URI self;
>
> For the "properties" functionality there a certainly several different
> possible approaches.
> Either something like "use the value of the named property and replace the
> path params", or an approach with nested annotations, like they are heavily
> used in JPA:
> @JsonbResourceLink(resource =..., method=..., properties =
> {_at_JsonbProperty("id") /* with will take the property already identified as
> JSONB property (either with getter/setter or public field, according to the
> spec, etc.) */}
>
> Another approach could also reuse some EL functionality for this: "${
> object.nestedValue.something.id}" -- this is just brainstorming now.
>
> So what do you think?
>
>
> 2)
>
> Adapters are changed. They are similar to JAXB adapters now.
>
>
> Great!
>
>
> 3)
>
> This is a good point. I am not sure that this is a spec related though. I
> would leave it up to implementations.
>
>
> Wouldn't it be the best thing (for users) to require in the specification
> that as soon as CDI is supported by the implementation it is also forced to
> support the injection of CDI managed beans into adapters?
> For instance Bean Validation requires CDI integration for
> ConstraintValidators (Section 10.3., JSR 349).
> IMO it would be hard to develop portable applications if CDI integration
> is only optional (or actually vendor specific) for implementations.
>
>
There are 2 points to enable it:
- adding close()/release() method the Jsonb API
- adding at least a "factory" API for adapters (class -> Instance { T
get(); void release(); } to allow CDI/spring/other integration
>
> Cheers,
> Sebastian
>
>
>
> On 01/29/2016 05:45 PM, Dmitry Kornilov wrote:
>
> Hi Sebastian!
>
> On 29.1.2016 09:08, Sebastian Daschner wrote:
>
> Hi experts,
>
> Thanks for the work done so far.
>
> I have some comments / questions on the Early Draft.
>
>
> 1) As Section 1.2 states JAX-RS should be integrated with JSONB. Are
> there already plans in which functionality such an integration will cover?
>
> It would be very helpful for enabling Hypermedia in JSON responses to
> have the possibility to create URIs to JAX-RS resources -- ideally via
> annotations.
>
> For example JAX-RS's UriBuilder [1] provides helpful functionality to
> create URIs. Do you think it's feasible to add something like
> @JsonbResourceLink(<jaxrs-resource-class>.class, "methodName") -- idally
> with the possibility to replace path params with properties of the POJO?
>
> I don't fully understand your point. Can you please explain your example
> in more details. What is the result of link deserialization?
>
> 2) JsonbAdapter has parameterized methods rather than JsonbAdapter
> itself being a parameterized type (as it is for JAXB's XmlAdapter). What
> were the ideas behind this?
>
> While implementing some examples I noticed that it would be helpful to
> have concrete types of both the ValueType and the BoundType in the
> method bodies, otherwise the Object's have to be casted. Or am I missing
> something here?
>
> Adapters are changed. They are similar to JAXB adapters now.
> Ex: Adapter<From, To>
>
> 3) Are there discussions to enable CDI integration for JsonbAdapters?
> IMO a drawback of JAXB's XmlAdapter was not to be able to inject CDI
> managed beans.
>
> We often had the situation in projects that we wanted to deserialize
> some primitive into a more complex object using logic from existing JEE
> components.
>
> This is a good point. I am not sure that this is a spec related though. I
> would leave it up to implementations.
>
> 4) Is there a roadmap for an early version of the RI? Btw, I would be
> glad to contribute if there is a need for more workforce...
>
> Thanks for offering. We have enough resources for now. We are very close
> to a first RI alpha at the moment. Currently it's a part of EclipseLink
> project. You can check it out from:
> git.eclipse.org/gitroot/eclipselink/eclipselink.runtime.git
>
> It's in jsonb directory.
>
> Thanks,
> Dmitry Kornilov
>
>
>