JBAS-1437 RARMetaDataRepository

[weston.price]

After much wailing and gnashing of teeth...it begins.

The plan is to maintain, the repository, the mapping between the ConnectorMetaData and it's associated ManagedConnectionFactorys and ActivationSpecs. This is going to put a fire under getting a real metamodel for the *-ds.xml deployments. A majority of this work has already been done in JBossXB but I am not wild about it.

The repository will of course help with

1) Recovery
2) Management
3) Overall manageabilty when we move over the MC based JCA stuff

[weston.price]

This is working in 'rough draft' at this point and coupled with the new programmatic deployment (JBAS-1425) goes a long way toward eliminating the XSL deployer all together. One 'hack' that I did put in was to set the JNDI name in the ManagedConnectionFactory on deployment. This makes resolving an entry in the repository much easier if multiple connection definitions exist in the repository (eg our JDBC adapters). I can't see anything necessarily wrong with doing this as it's simply a mechanism to avoid failing on a deployment when the RAR can't be guessed.

[weston.price]

Also, with the new Repository we should rethink deployment of MessageEndpoints as ActivationSpecs are also in the repository. This should make this cleaner and less hackish and will allow us to get away from having to provide a RAR name in most cases.

[weston.price]

Issue:

The old method of deployment used the RAR->MCF (via the OldRARDeployment attribute) dependency to force the MCF to wait for the RAR to be deployed prior to the MCF entering the start/stop lifecycle. Without this explicit dependency I am running into the case where the *-ds.xml file gets parsed and all the MBeans get created prior to the RAR being deployed.

Assuming that one of the reasons for repository is to remove the requirement to specify the RAR name in the *-ds.xml, jboss.xml or jboss-service.xml file, this would seem to be problematic due to the inherent dependency between them.

I am not sure the real value of this anyway as you would expect a deployment type of MCF, listener, AdminObject to specify to which RAR it belonged.

Obviously this is not the only reason for the repository, but I can't quite see how we can get away with getting rid of the RAR names from our deployments.

[adrian.brock]

Obviously this is not the only reason for the repository, but I can't quite see how we can get away with getting rid of the RAR names from our deployments.

If you are doing this in two phases (parse/runtime) it should be automatic?

The parsing stage populates the repository, the runtime stage (the actual
construction/configuration of the MBeans/Pojos) should have all the parsed rar information
in the repository by then?

What you really need is something I've not yet done in the MC
which is the "write your own dependency".
Basically allowing users to define and implement their own DependencyItem.

You can sort of already do it with a bit of hacky code.
e.g. for MBeans you can subclass ServiceDependencyMetaData
to implement something more dynamic in the visitor callback
but you need to update the ServiceMetaData by hand with your new dependency.

But what I'd really like is for the dependencies to support wildcards, e.g.

<mbean code="MCF">
 <depends xmlns="urn:jboss-jca:5.0" rar-name="some.rar"/>
</mbean>

Where urn:jboss-jca:5.0:depends will unmarshal to a dependency implementation
that knows how to look at the rar metadata repository at runtime.

The attributes of this dependency could then have all the query parameters
we'd like to support for looking up implementations, e.g. give me a rar that supports
JmsXA outbound (not such the hardwired rar name).

If nothing supports it (yet), you just return false from isResolved() in your
DependencyItem implementtaion.

[weston.price]

If you are doing this in two phases (parse/runtime) it should be automatic?

The parsing stage populates the repository, the runtime stage (the actual
construction/configuration of the MBeans/Pojos) should have all the parsed rar information
in the repository by then?

No, that's the issue. The ManagedConnectionFactory deployer is being invoked before the RAR deployer, as a result, the ConnectorMetaData hasn't been added to the repository yet. The 'hack' in place right now is to establish the dependency via the ServiceDependencyMetaData. This is basically just emulating the OldRARDeployment mess from the XSL deployer which is what I am trying to move away from. This of course *works* but it suffers from the same failings as the old implementation.

Of course, it does actually solve the programmatic part, just the dependencies need to be reconsidered in the context of the MC. I will take a look at the visitor callback.

[adrian.brock]

If you are doing this in two phases (parse/runtime) it should be automatic?

The parsing stage populates the repository, the runtime stage (the actual
construction/configuration of the MBeans/Pojos) should have all the parsed rar information
in the repository by then?

No, that's the issue.

You missed the point.

The logic should be something like:
1a) Parse the MCF xml
1b) Parse the rar xml
2a) Deploy the mcf (create mbean/pojo metadata)
2b) Deploy the rar (create mbean/pojo metadata)
3a) Create the mcf object (callback from the MC when dependencies are satisified)
3b) Create the rar object (-""-)

(1) is the parsing stage of deployment
(2) is the post parsing or "real deployer" stage of deployment

Within each category it doesn't matter in which order things get done
because stage (1) fills the repository and stage (2) references it.

All you need is for stage (2) to look at the data from (1)
so you can decide what name to put in the dependency.

It is only in stage (3) - construction of the MBean/POJOs that you are
actually going to have wired objects.

[weston.price]

Ok. Let me put this a different way:

I have a working implementation of the ManagedConnectionFactoryParser and the ManagedConnectionFactoryDeployer. The repository is also set up and working to contain all the metadata that is being constructed on the deployment chain.

I also have a working implementation where I can construct the MCF/Pool/Binding etc. Right now all I do is simply emulate what the XSL deployer does in setting the appropriate MBean attributes that allows the

org.jboss.resource.connectionmanager.RARDeployment

to start, create the ManagedConnectionFactory, set the properties and associate the MCF with the ResourceAdapter (if it supports it). The Pool, CM ,Binding all other MBeans that may arbitrarily appear in the *-ds.xml file follow in the same manner.

It's at this point I am not clear on your vision for doing this differently. The whole 'guess the RAR' thing to me seems to be unnecessarily complicated and I am not quite sure of the point being that a JCA deployment MCF, ActivationSpec, AdminObject should always know to what RAR it belongs.

If something above doesn't appeal to you (as I am sure it doesn't) don't hesitate letting me know in that warm and loving way of yours ;-)

[adrian.brock]

The whole 'guess the RAR' thing to me seems to be unnecessarily complicated and I am not quite sure of the point being that a JCA deployment MCF, ActivationSpec, AdminObject should always know to what RAR it belongs.

The basic feature is you just tell it the name. i.e. the ObjectName or name
in the microcontainer as a dependency.
e.g. rar-name in the -ds.xml or resource-adapter-name in jboss.xml

This doesn't require anything new and should just work like the old stuff.

But if you want to "guess" the rar to use from properties
e.g. Who implements the message listener for inbound (don't specify the rar name)
then you are going to need what I described above.

Stage (1) parsing - populate the rar repository
Stage (2) "real deployer" - resolve the dependency name from the properties
(once you know all the rar parsing has been done)
Stage (3) runtime - only start when the dependency exists (the rar is deployed)

The other stuff I described just turns stages 2 and 3 into one stage
with a custom dependency implementation.

To emulate the old stuff, stage 2 is a no-op. You've been told the dependency name
in the xml (or it is hardwired in the xslt :-).

[weston.price]

The basic feature is you just tell it the name. i.e. the ObjectName or name
in the microcontainer as a dependency.
e.g. rar-name in the -ds.xml or resource-adapter-name in jboss.xml

Whew. Ok, this makes sense then as it is what I am already doing ;-)

But if you want to "guess" the rar to use from properties
e.g. Who implements the message listener for inbound (don't specify the rar name)
then you are going to need what I described above.

I don't ;-) Unless I actually see a need.

Stage (1) parsing - populate the rar repository
Stage (2) "real deployer" - resolve the dependency name from the properties
(once you know all the rar parsing has been done)
Stage (3) runtime - only start when the dependency exists (the rar is deployed)

Yep, cool. This is what is already in place I just didn't convey it well enough.

[adrian.brock]

If something above doesn't appeal to you (as I am sure it doesn't) don't hesitate letting me know in that warm and loving way of yours ;-)

Maybe I should just put smilies on the end of every sentence?

[weston.price]

Maybe I should just put smilies on the end of every sentence?

I got a few more suggestions about where you can put things ;-)

[weston.price]

Prior to the TCK mess starting up I was nearing completion on both the Repository and the Programmatic Deployment stuff. To recap:

1) New JAXP based parser was created to handle parsing the *-ds.xml file format

2)RARMetaDataRepository was constructed to hold RAR, MCF, ActivationSpec and AdminObject metadata

3)Two new deployers (ManagedConnectionFactoryDeployer and ManagedConnectionFactoryParserDeployer) were created.

4)The RARDeployment MBean (the older guy) was refactored as a DynamicMBean that takes the MetaData as a value to it's constructor. In this manner. Nice thing is all those attributes that were previously null in the JMX console now actually show something useful ;-)


The only real drawback I can see in this approach is the JAXP parsing stuff. Clearly this is not the most elegant way to go, but I wanted something that was fast, independent and portable. Introducting a DataBinding mechanism at a later time is no big deal since the parser is injected into the ParserDeployer via the MC.

[weston.price]

I should have mentioned that the new deployers/MBean etc can happily exist side by side with the XSL deployer and older MBeans. Obviously the two deployers can't be run simultaneously, but you can simply swap them out if necessary.

[weston.price]

Thinking about this a bit more, I wonder if it makes sense to 'aspectize' the parsing of the *-ds.xml file. Ideally we want the ability to be able to plug-n-play various pieces of the parsing and to be able to easily extend the parsing when new elements/changes to the *-ds.xml format come along. Also, we may want to replace the *-ds.xml file format all together at some point. Effectively this would be just taking what's in the JAXP based parser now and breaking it up into a parsing chain.