>>
>>>
>>>> 2) Remove the ContainerProvider API and use the Java SE standard
>>>> ServiceLoader mechanism instead:
>>>> http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html
>>>
>>> That would be an unusual change. JCache, for example, has a
>>> javax.cache.Caching class that's like the current ContainerProvider.
>>> It uses ServiceLoader internally, but doesn't ask the application to
>>> use ServiceLoader itself. I'm pretty sure the new CDI draft added a
>>> similar CDI class. The Caching/CDI/ContainerProvider model is pretty
>>> much used everywhere else in the Java specs that I've worked with.
>> Absolutely, there are many specs that take this approach of a
>> bootstrap class, but many of them (like JCache) predate JDK 6 when
>> ServiceLoader was added. I can't find the CDI proposal - do you have
>> a pointer ?
>
> Actually, JCache is new. Since it's been in JSR-pre-draft-land for 10
> years, the finally-published draft uses JDK 6 :)
>
> I could only find the CDI description in the CDI PDF. The JSR download
> doesn't seem to have JavaDocs. The text is 11.3.1:
>
> 11.3.1. Obtaining a reference to the CDI container
>
> Portable extensions sometimes interact directly with the container
> via programmatic API call. The abstract
> javax.enterprise.inject.spi.CDI provides access to the BeanManager
> as well providing lookup of bean instances.
>
> public abstract class CDI<T> implements Instance<T> {
> public static <T> CDI<T> current() { ... }
> public abstract BeanManager getBeanManager();
> }
>
> A portable extension may obtain a reference to the current container
> by calling CDI.current().
> When CDI.current() is called, the first
> javax.enterprise.inject.spi.CDIProvider is loaded, and the
> CDIProvider.getCDI() method called. If no providers are available an
> IllegalStateException is thrown.
>
> public interface CDIProvider {
> public <T> CDI<T> getCDI();
> }
>
>>
>> Its not really a big deal, but this was the kind of case
>> ServiceLoader was trying to address, and it does remove an awkward
>> dependency between an API class and the implementation.
>
> Yep. I'm just observing it's unusual, not that it's a bad idea. I'm
> not sure if it's bad or good.
>
> A minus with using the ServiceLoader directly is that it's a slight
> pain to get an instance because the application would need to iterate
> over ServiceLoader itself, and do the error checking for missing
> provider, instead of just calling ContainerProvider.getServer(), which
> is easy.
OK that's true.
Well, then I propose we just stick with the ContainerProvider idea now:
it does the job it needs to. I think we will need separate facade
classes for client and server.
- Danny
>
> In any case, if there is a typed facade, it should certainly use
> ServiceLoader underneath.
>
>>
>> The alternative of course is to use @Inject to inject the *Container,
>> but then we are left with the issue of non-CDI containers.
>
> Right. We do need something.
>
> -- Scott
>>
>> - Danny
>>
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation