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