transporter connector/detector customization

[mazz]

TransporterServer currently creates its own MBeanServer, Connector and MulticastDetector.

I don't see a way for me to customize those (Connector lease period, Detector's multicast address, port, etc. etc.) nor can I use my own MBeanServer.

I can't subclass it because connector, server and detector are all private to TransporterServer.

I'm thinking TransporterServer should have some static create methods that take as parameters things like the MBeanServer where the services should be registered, a Connector to use and a Detector to use. That way, I can set up my own connector and detector and MBeanServer and just have TransporterServer use those.

Does this make sense?

[tom.elrod]

Sure. The transporter code needs a lot of work in this regard. Please open a jira issue for these.

Also, if you have the time, will get done faster if you help with the coding (I am pretty slammed for next 5 months). ;)

[mazz]

Let me just say this stuff is really cool :-)

Anyway, I already have remoting infrastructure in place (I have my own MBeanServer, Detector, Connector, etc. etc).

Looking at the code, it seems the main piece is TransporterHandler. All the server does it create the infrastructure (MBeanServer, Connector and if clustered Detector) and adds the handlers to the connector.

All the client does is (aside from infrastructure stuff again like setting up the Detector) is be a dynamic proxy that creates a NameBasedInvocation object and pass that over the wire.

When I say "all the client does" - not meant to be derogatory. On the contrary, the simplicity of this design is really extraordinary :-) I can't believe what little code there is that is needed.

Anyway, the point is, I think to answer my question about customizing the internal services - I can set them all up myself and just use TransporterHandler as my server invocation handler. I can create proxies myself that simply build the namebasedinvocation object and pass that via my own client.

Oh, and the handler is ridiculuously simple too. :-)

Nice job on all of this Tom and gang.

[mazz]

http://jira.jboss.com/jira/browse/JBREM-430

[tom.elrod]

Thanks. Started off as an example within remoting samples of how to build abstraction layer on top of core remoting. At that point, just threw it in as part of the core api itself (hence why all the config bells and whistles not added yet).

Seems like a lot of people are using transporter now (based on other forum posts), so I will try to add all those bells and whistles and would like to make it part of the api. Can translate as, would rather it be added to remoting api than you having to code it outside the api.

So will make a deal with you. If you keep adding the jira issues, I will try to knock them out.

[tom.elrod]

Have also added one for automatically exposing all the pojo target's interfaces - http://jira.jboss.com/jira/browse/JBREM-431.

[mazz]

The static members is going to be a pain to workaround.

If everything were member variables, just need to have protected methods, something like:

protected getMBeanServer()
{
 return MBeanServerFactory.createMBeanServer();
}

protected ObjectName getDetectorObjectName()
{
 return ObjectNameFactory.create("remoting:service=detector");
}

protected Detector getDetector()
{
 return new MulticastDetector();
}

protected Connector getConnector()
{
 return new Connector();
}

Then the main code just calls these getters - thus allowing subclasses to override these and be able to configure them as they want.

But, the detector and MBeanServer are static (I understand why - you only want one for all transport servers to use) and are accessed in some static methods. So this won't actually compile.

So, somehow have to work around that.