On 2/1/13 3:17 AM, Mark Thomas wrote:
> On 01/02/2013 01:13, Danny Coward wrote:
>> * Client API implementation bootstrapping
>> (http://java.net/jira/browse/WEBSOCKET_SPEC-83)
>>
>> Currently (as a stopgap) the ContainerProvider API has used an
>> undocumented system property to load the implementation class under
>> getWebSocketContainer(). Instead, I'm planning on switching this over to
>> use the ServiceLoader.load() mechanism. So provided the API classloader
>> can see a JAR containing the appropriate Manifest, the runtime will load
>> the implementation class. I don't think this should be controversial,
>> but I have a dim memory that this came up before, so I am putting it out
>> there in case I've missed something.
> I think I mentioned this before but I suggest looking at how the EL spec
> does this and using the same approach . It is the same situation (may be
> used stand-alone or in a container) and provides a way for multiple
> implementations to sit alongside one another and for the developer to
> choose which one they want to use.
Yes I remember that now, thanks. I think you mean:-
http://docs.oracle.com/javaee/6/api/javax/el/ExpressionFactory.html#newInstance%28%29
Thankfully, our situation is even a bit simpler, all we're trying to do
is get to the one and only implementation without having to hard code
the implementation classname in the API class, we don't need to select
from multiple implementations or pass properties into them.
So specifically, if we just use the Services API (as detailed in the JAR
specification) like this:
If a resource with the name of
|META-INF/services/javax.websocket.WebSocketContainer| exists, then its
first line, if present, is used as the UTF-8 encoded name of the
implementation class that will be instantiated (public no-args
constructor) for the getProvider() call.
- Danny
>
> Mark
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation