[jboss-jira] [JBoss JIRA] Commented: (JBREM-496) restructure service providers for remoting

[Tom Elrod (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBREM-496?page=comments#action_12339411 ] 
            
Tom  Elrod commented on JBREM-496:
----------------------------------

Remoting will now load client and server invoker (transport) implementations within the InvokerRegistry using factories.  The factory class to be loaded will always be either TransportClientFactory (for loading client invoker) or TransportServerFactory (for loading server invoker).  These classes must implement org.jboss.remoting.transport.ClientFactory and org.jboss.remoting.transport.ServerFactory interfaces respectively.  The package under which the TransportClientFactory and TransportServerFactory will always start with org.jboss.test.remoting.transport, then the transport protocol type.  For example, the 'socket' transport factories can be found under org.jboss.remoting.transport.socket.TransportClientFactory and org.jboss.remoting.transport.socket.TransportServerFactory.

The API for org.jboss.remoting.transport.ClientFactory is:

   public ClientInvoker createClientInvoker(InvokerLocator locator, Map config) throws IOException;
   public boolean supportsSSL();

The API for org.jboss.remoting.transport.ServerFactory is:

   public ServerInvoker createServerInvoker(InvokerLocator locator, Map config) throws IOException;
   public boolean supportsSSL();

An example of a transport client factory for the socket transport (org.jboss.remoting.transport.socket.TransportClientFactory) is:

public class TransportClientFactory implements ClientFactory
{
   public ClientInvoker createClientInvoker(InvokerLocator locator, Map config)
         throws IOException
   {
      return new SocketClientInvoker(locator, config);
   }

   public boolean supportsSSL()
   {
      return false;
   }
}

The packages used within the factory does not matter as long as they are on the classpath.  Note that the transport factories are only loaded upon request for that protocol.  Also, the client and server factories have been separated so that only the one requested is loaded (and thus the corresponding classes needed for that invoker implementation).  So if only ask for a particular client transport invoker, only those classes are loaded and the ones needed for the server are not required to be on the classpath.

> restructure service providers for remoting
> ------------------------------------------
>
>                 Key: JBREM-496
>                 URL: http://jira.jboss.com/jira/browse/JBREM-496
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: general
>    Affects Versions: 2.0.0.Beta2 (Boon)
>            Reporter: Tom  Elrod
>         Assigned To: Tom  Elrod
>             Fix For: 2.0.0.CR1 (Boon)
>
>
> Need a way to package and identify transport implementations for remoting.  The idea is that anyone would be able to create their own transport implementation and drop it in and be "deployed" (where deployed means can just automatically discovered and used during runtime).  
> A few ideas of how to do this are:
> 1. Use service provider from jar metadata - http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service%20Provider
> (e.g. URL[] urls = new Class().getResources("META-INF/services/org.jboss.remoting/Transport") ; )
> 2. Follow jndi pattern for package name.
> (e.g. org.jboss.remoting.plugins.http.TransportFactory).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira