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