(Sorry for the dupe, Miroslav. I didn't hit reply-all on the first one.)
ParamConverter doesn't work for collections or, more generally, wrapper
classes. Consider the following resource method:
Name getBestName(@QueryParam("name") ImmutableList<Name> names);
I can write a ParamConverter to convert strings to and from Name instances,
which is *awesome*, but I'm totally out of luck for handling the
ImmutableList portion of this. Support for Optional instances is in a
similar situation, where I want to pass an empty Optional if the param is
missing or an Optional with the first passed value if one exists.
On Wed, Jul 3, 2013 at 6:48 AM, Miroslav Fuksa <miroslav.fuksa_at_oracle.com>wrote:
> Hi,
>
> see comments inline.
>
> Mira
>
>
> On 07/02/2013 10:40 PM, Coda Hale wrote:
>
> Thanks for the advice!
>
> I ended up adding support for Optional return types with a
> MessageBodyWriter using an injected Provider, as you suggested.
>
> that's good.
>
>
> I was thinking about using a ModelProcessor to wrap invocation, but
> attempting to copy everything seems daunting.
>
> You are right, using model processors is really not so nice solution. You
> will be able to use monitoring events after they are added to Jersey.
> Currently I do not know about any good workaround.
>
>
> Another thing I can't figure out with Jersey 2 is how to add support for
> third-party collection parameters or collection-like classes like Optional.
> Any suggestions?
>
> I am not sure what you mean. How would would you like to support it? Do
> you mean that you would like to use it as parameters of resource methods?
> If yes, then check javax.ws.rs.ext.ParamConverter from JAX-RS spec.
>
>
> These are blockers for me upgrading my web framework, Dropwizard, to
> Jersey 2.
>
> On Tuesday, July 2, 2013, Miroslav Fuksa wrote:
>
>> Hi,
>>
>> sorry for the late answer and thanks for details.
>>
>> We are adding a support for listening to events of request processing
>> life cycles. The user should be able to register a custom provider that
>> will receive events when new request comes, matching is performed, resource
>> method is executed, resource method is finished, etc. We will also use it
>> to expose some monitoring statistics.
>>
>> This might solve your first use case (monitoring elapsed time) and maybe
>> also third use case with hibernate. This is not a solution for you second
>> use case. However, I think the correct solution should be what you are
>> trying to implement with filter and MessageBodyWriter. Or even
>> MessageBodyWriter should be enough. Could you please send us more details
>> about problems you have with your implementation? Maybe using
>> javax.inject.Provider might solve your problem. It means you will inject
>> MessageBodyWorkers into your MessageBodyWriter using:
>>
>> @Inject
>> Provider<MessageBodyWorkers> mbwProvider;
>> ...
>>
>> mbwProvider.get().writeTo(....)...
>>
>> Thanks
>> Mira
>>
>> On 07/02/2013 12:22 AM, Coda Hale wrote:
>>
>> Any ideas?
>>
>>
>> On Tue, Jun 18, 2013 at 9:04 AM, Coda Hale <coda.hale_at_gmail.com> wrote:
>>
>> I have more than a few use cases. :)
>>
>> First, I have an implementation which records the elapsed time spent
>> inside the resource method using my Metrics library. I haven't found a way
>> of doing this which allows me to directly observe the method invocation.
>>
>> Second, I have an implementation which, if the resource method returns
>> a Guava Optional without a value, returns a 404. Otherwise, it passes the
>> Optional's value to the MessageBodyWriter. I tried writing a filter for
>> this, but then Jersey refuses the resource method because
>> Optional<Whatever> doesn't have a MessageBodyWriter. I tried writing a
>> MessageBodyWriter, but trying to inject the MessageBodyWorkers equivalent
>> was producing dependency cycles in HK2.
>>
>> Third, I have an implementation which wraps the resource method
>> invocation in a Hibernate unit of work. Like the first example, this needs
>> to directly wrap the invocation.
>>
>> Any advice is appreciated, thank you.
>>
>>
>> On Tue, Jun 18, 2013 at 8:18 AM, Marek Potociar <
>> marek.potociar_at_oracle.com> wrote:
>>
>> Hi,
>>
>> We have not ported this API to Jersey 2.0 yet. We would like to first
>> understand the use cases where the API is used and see if there is perhaps
>> a better way of solving those. Can you please share more details about you
>> use case?
>>
>> Many thanks,
>> Marek
>>
>>
>> On Jun 15, 2013, at 1:52 AM, Coda Hale <coda.hale_at_gmail.com> wrote:
>>
>> I'm trying to find the best way of porting
>> ResourceMethodDispatchAdapter implementations, but coming up a bit short.
>>
>> Any suggestions?
>>
>> --
>> Coda Hale
>> http://codahale.com
>>
>>
>>
>>
>>
>
> --
> Coda Hale
> http://codahale.com
>
>
>
--
Coda Hale
http://codahale.com