Hi Peter,
I see the pattern now.
EventsConverter.getEntities() and getReferences() have 0 usages. What
purpose is served by these functions ?
There is already Event class that provides complete JAXB representation
for <event>. Do I really need to create a new class ?
-Arun
Peter Liu wrote:
> Hi Arun,
>
> BTW, the jaxb classes for the references are designed to be modified by
> the users to include additional information
> other than the id. For example, in your case, there should be an
> EventRefConverter jaxb class. You can simply
> add addition getters to serialize more information back. Think of it as
> returning a preview of the actual resource.
>
> Also, as Nam mentioned, we did talk about enhancing the code generation
> to support what you suggested.
> However, we are trying to figure out how to implement behaviors in the
> jaxb classes to allow dynamically
> changing the amount of information that gets serialized back. If you
> know of any way, please let us know.
>
> Thanks.
>
> Peter
>
> Nam Nguyen wrote:
>> Paul Sandoz wrote:
>>> Hi Arun,
>>>
>>> I assume you are referring to the NetBeans RESTful database plugin?
>>>
>>> I do not know of such an option.
>> We discussed about this but it was dropped because of other higher
>> priority. I just file this issue to keep track:
>> http://www.netbeans.org/issues/show_bug.cgi?id=124611
>>>
>>> If such a feature were supported i think it would also require a
>>> paging mechanism, for example using a query parameter (with a default
>>> number of entries embedded in the representation so that the size of
>>> the representation does not become too large).
>> This is already implemented by Peter. For example:
>> http://localhost:8085/WebApplication9//resources/customers/?start=0&max=10
>>
>>> Potentially another feature is to only return a partial set of
>>> informtion for each entry rather than a complete embedded
>>> representation i.e. just enough important information for a client to
>>> make a decision whether they need to get the whole representation
>>> from the URI.
>> We also discuss about this more flexible option. This might requires
>> some JAX-B support for dynamic list of properties and attribute during
>> marshaling. Or, we might have to provide some custom marshaller.
>>>
>>> Note that HTTP pipelining and caching can make also things reasonably
>>> efficient, but it will still involve a latency to report not modified
>>> responses. But IIRC caching support is yet to be implemented.
>>>
>>> Paul.
>>>
>>> Arun Gupta wrote:
>>>> A Jersey endpoint return results like:
>>>>
>>>> -- cut here --
>>>> -
>>>> <events
>>>> uri="http://localhost:8080/WebApplication2/resources/events/">
>>>> -
>>>> <eventRef
>>>> uri="http://localhost:8080/WebApplication2/resources/events/1/">
>>>> <id>1</id>
>>>> </eventRef>
>>>> -
>>>> <eventRef
>>>> uri="http://localhost:8080/WebApplication2/resources/events/2/">
>>>> <id>2</id>
>>>> </eventRef>
>>>> -
>>>> <eventRef
>>>> uri="http://localhost:8080/WebApplication2/resources/events/3/">
>>>> <id>3</id>
>>>> </eventRef>
>>>> -
>>>> <eventRef
>>>> uri="http://localhost:8080/WebApplication2/resources/events/4/">
>>>> <id>4</id>
>>>> -- cut here --
>>>>
>>>> Is there an option (that can be configured on the endpoint or passed
>>>> as parameters to the URL) such that the result contains all the
>>>> resources instead of reference to the resources ?
>>>>
>>>> -Arun
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>
--
Application Platform, Sun Microsystems, Inc.
Blog: http://blogs.sun.com/arungupta