On 11/9/12 5:08 PM, Danny Coward wrote:
> On 11/7/12 7:22 PM, Scott Ferguson wrote:
>>
> We have had feedback that developers like to be able to do
> programmatic endpoints as well as annotations, but I know some people
> would rather everything be only annotations.
>
> I'd like to keep the programmatic endpoints unless there is a strong
> reason or consensus in this group that they are a bad idea.
>
> As much as the EE programming model is focused around annotations
> nowadays, there are still many developers who prefer an API approach.
> I also think that allowing other websocket frameworks to layer on top
> of our standard Endpoint API is going to be a big plus. I'd rather
> than kind of invention happen on top of our APIs that away from them.
That's reasonable.
>
>>
>>> 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.
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
>