[
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