Thanks, Sebastian. Now I understand your JAX-RS idea. It's interesting
and looks like a good candidate for JSONB 2.0.
CDI injection in adapters can be added to this version. We are
investigating it now.
-- Dmitry
On 29.1.2016 22:18, Sebastian Daschner wrote:
> 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"
> }
>
> 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.
>
>
> 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
>