JBAS-1974: Remote Connection Factory Usage

[weston.price]

TODO:

Refactor org.jboss.resource.adapter.jdbc.remote to

org.jboss.resource.adapter.remote (or something equivalent).

Refector the WrapperDataSourceService into something more generic. First off, change the name, in many ways it doesn't make a lot of sense. Maybe something along the lines of RemoteConnectionFactoryService.

Do we want to keep the relationship with the ConnectionFactoryBindingService, or do we want to break this out and create a RemoteConnectionFactoryBindingService, or even augment the existing ConnectionFactoryBindingService to allow for this capability?

As mentioned on JIRA, proxy generation should be allowed for all non-serializable types on the CF/Connection interface. The existing service has an example of doing this, and it shouldn't be too difficult to make this generic for any CF.

I think it is a good idea to tie client lease times to the client transaction timeout.

This issue actually in some ways ties into the new deployment stuff being that I am assuming we are going to use the same 'useJavaContext' mechanism for this.

If I missed anything, let me know.

[adrian.brock]

The remoteness should be an extension to the jndi binding.

i.e. Rather than binding the result of ManagedConnectionFactory.getConnectionFactory(...)
you bind a wrapper that understands how to do remote proxying,
including creating proxies for managed objects returned through those proxies.

It shouldn't be in the resource adapters at all.

[weston.price]

Got it.

How about org.jboss.resource.binding

Move the related artifacts we already have to this package and extend from there?

[adrian.brock]

I don't care what you call it.
I do care about that it lives in jboss-jca.jar rather than some.rar

[weston.price]

Coming along nicely, should be wrapped up, tested etc, etc mid next week.

[weston.price]

In thinking about this some more, augmenting the existing ConnectionFactoryBindingService should be the way to go with all the 'remote' stuff being handled by an internal object to which the MBean just delegates appropriately.

I had planned on making this a seperate MBean that gets generated at deployment time much in the manner of the original WrapperDataSourceService but this seems counterintuitive. As pointed out, this should be a part of the ConnectionFactoryBinding service being that it will be applicable to all ConnectionFactories, not just JDBC based resources.

The internal object will handle the invoke, binding etc, etc for remote enabled ConnectionFactories.

Also, I would like to add to the requirements that we allow for unbinding/binding remote CF's on the fly by setting the useJavaContext MBean attribute.

[weston.price]

Further enhancements:

Allow for configurable interceptors that are used when creating the proxy objects. This could be an attribute added to the *-ds.xml file that gets transformed into an array of Strings that are then set on the MBean. Further, an object to interceptors map like structure could be created as well.

[weston.price]

For the client side part of the requirement, I am planning on using JBossSerialization that will allow for the serialzing on non-serializable types. Does anyone see any issues with this up front before I go down this route?

[adrian.brock]

The -ds.xml should reference some kind of "shared" proxy factory config
rather than having all config inline.

[weston.price]

Excellent. I was heading down this route...thanks for verification.

[clebert.suconic]

For the client side part of the requirement, I am planning on using JBossSerialization that will allow for the serialzing on non-serializable types. Does anyone see any issues with this up front before I go down this route?

I don't know if this feature is planned to run on JVM 5, or JVM 1.4.

If JVM 1.4, JBossSerialization won't work on JRockit 1.4, due to a restriction on accessing the hooks I need.

I would need to create instances without using a constructor (I call them Ghost Constructors, don't know a better name), and a way to change final fields.

If you look at cruisecontrol for jboss-serialization we are testing on every VM 1.4+ expect JRockit.

There are no restrictions on JVM 5+.