1. For the code structure, we will create 2 sub packages for implementation of AS7, ironjacamar standalone separately. The most common functions will be abstracted to the package: org.jboss.jca.rhq.core,
And the build process will create 2 jars like:
- ironjacamar-rhq-plugin-as7.jar // used in AS 7
- ironjacamar-rhq-plugin-standalone.jar // used in ironjacamar standalone mode
except we can find a way to know which situation the current runtime environment is in.
That is the job of the Discover process - default being a discovery against an in-vm instance. I'll take a look at this soon.
2. If the org.jboss.jca.core.api.management.ManagementRepository can be transferred to RHQ plugin in all situations, we can use it directly without abstracting our own model for this RHQ plugin. This class is used only for RHQ to discover JCA resources.
ManagementRepository is the instance that lives in the same VM as the container, and will delegate all calls in-vm.
So in case of a plugin connecting to a remove instance you'll need a "proxy" to handle that communication:
In-VM:
------
RHQ Plugin -> Embedded discovery -> ManagementRepository
Remote VM:
----------
RHQ Plugin -> Remote discovery -> Network transport -> RemoteManagementRepository -> ManagementRepository
Of course we can have a facade for ManagementRepository in the plugin such that communication can be optimized in the remote scenario, since in some instances a query for configuration property names will limit network bandwidth.
The ManagementRepository should always delegate calls to dynamic attributes and operations. In most cases we can handle that by supplying a WeakReference to the actual object, and just call directly. We just need to expose the information we need in the right locations - like the .api...Pool class.
However, currently the focus on the purely embedded case - using IronJacamar/Embedded for testing, and IronJacamar/AS7 for real data.