jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: Updated Client API and Interceptors/Filters proposal is available - please review

From: Guilherme Silveira <guilherme.silveira_at_caelum.com.br>
Date: Tue, 14 Jun 2011 11:59:02 -0300

I was avoiding getting into it, since the Factory/Client approach
always seems more natural for me. Including some of the reasons Bill
pointed out, and also those two, just generalizing a little bit:

> Its a bit weirder to proxy *any* abstract class.

> BTW, do you know how annoying it is that *any.java.basic.implementation.class.without.an.interface* is an
> abstract class?

Regards

Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/



On Tue, Jun 14, 2011 at 11:23 AM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> On 6/14/11 3:52 AM, Markus KARG wrote:
>>>>>>
>>>>>> On 06/13/2011 02:46 PM, Markus KARG wrote:
>>>>>>>
>>>>>>> For the topic of factories itself I share Bill's opinion that
>>>>>
>>>>> whenever possible we should use interfaces and do not provide
>>>>> implementations. As much as possible of the implementation should be
>>>
>>> in
>>>>>
>>>>> the sole hands of the vendors and not already pre-programmed by the
>>>>> spec. If using a ClientFactory is the solution, then we should
>>>
>>> provide
>>>>>
>>>>> one. It's just the cleaner approach.
>>>>>>
>>>>>> Can you please provide an example of constructing a client instance
>>>>>
>>>>> with the client factory you propose? Does your
>>>>>>
>>>>>> client factory have static methods? If yes, it must be at least an
>>>>>
>>>>> abstract class then, which means we are just moving
>>>>>>
>>>>>> the problem one level of indirection further.
>>>>>
>>>>> Exactly. It doesn't matter how many factory classes we create, we'll
>>>>> need an abstract class for the static methods at some point. Earlier
>>>>> feedback on the API was related to the number of classes; adding an
>>>>> extra level of indirection seems to go against that and without any
>>>>> clear benefits IMO.
>>>>>
>>>>
>>>> The clear benefit would be that if we move the problem to a single
>>>
>>> point
>>>>
>>>> then everything beyond that point can be decided by the implementor.
>>>
>>>  This is a valid point. The problem that I see is that in the absence
>>> of DI, you'd need to write something like this if you were to use
>>> RuntimeDelegate:
>>>
>>> Client c =
>>> RuntimeDelegate.getInstance().buildClientFactory().createClient();
>>>
>
> What's the big deal about having a ClientFactory class with static methods
> that delegate to RuntimeDelegate?
>
> public class ClientFactory
> {
>   public static Client client() {...}
>   public static Client client(ClientConfiguration config) {...}
> }
>
> My prediction is that you'll have to create  ClientFactory or ClientDelegate
> sometime in the future anyways especially if you want to ship separate
> client and server runtimes (and because RuntimeDelegate pulls in
> server-specific classes and interfaces).
>
>
>>>  At least if we follow the current model in which RuntimeDelegate does
>>> not have static methods. This seems a bit much to create an instance of
>>> Client.
>>
>> This is correct, but it is valid to do so. See, other Java EE APIs also
>> have
>> such complex initializations. When using JPA for example, one has to do:
>> Persistence.createEntityManagerFactory().createEntityManager().
>> Persistence
>> uses PersistenceProvider to delegate the factory creation to a third party
>> implementation. So we could reduce to that level of complexity by doing
>> something like this: Rest.createClientFactory().createClient() and let
>> Rest
>> use RuntimeDelegate to build the factory. If people accept this in JPA,
>> why
>> shouldn't they in JAX-RS?
>>
>
> JPA is a wonderful example.  In an application server, the Persistence class
> is never used and the EntityManagerFactory even more rarely. Usually proxied
> EntityManager implementations are injected.  I would expect the same for
> Client.   Its a bit weirder to proxy an abstract class.  In a pure client
> something like spring or guice might be used to inject the client instance.
>
> BTW, do you know how annoying it is that javax.ws.rs.core.Application is an
> abstract class?  I have had a few times where I wished to extend something
> else and have had to use delegation instead.  And I usually override its
> mundane implemention.  Its also a bitch to proxy this class.
>
>
>>
>> Interpreting the posts of Oracle members in the past days (at least to me)
>> it sounded more like convincing the EG of the existing proposal than
>> finding
>> an implementation for what the EG proposed. If this was not Oracle's
>> intention then everything is OK, at least for me, and I think for Bill
>> also.
>>
>
> Nah, they are doing a good job and you have to start somewhere. Remember
> they completely tore up their initial interceptor proposal based on my
> feedback.
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>