1 2 3 Previous Next 41 Replies Latest reply: Dec 14, 2004 5:25 PM by Adrian Brock RSS

TODO: ConnectionDefinitionDeployer - replace XSLSubDeployer

Adrian Brock Master

Replace the use of the XSLSubDeployer with a proper deloyer that takes
-ds.xml files and creates a meta data object like the RAR deployer.

There should be an option to create ConnectionFactories/DataSources by
passing the meta data object on a JMX operation.

Rename the class to ConnectionDefinitionDeployment rather than the
confusing org.jboss.resource.connectionmanager.RARDeployment

  • 1. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
    Steve Lewis Expert

    Would the meta data name be something like "ConnectionDefinitionMetaData"? Or actually that'd be for RARDeployer. What would the name be to replace XSLSubDeployer? ConnectionInstanceDeployment?

    Minimal methods of the metadata would be:

    importXml(Element)
    setClassLoader
    getClassLoader

    jndiName (get and set)
    connectionUrl
    driver-class
    securityDomain
    minPoolSize
    maxPoolSize
    adapterDisplayName

    Actually, since the root is "connection-factories" you could have more than one (meaning more than one MBean, one for each connection factory listed). So you either have a list of ConnectionInstanceMetaData or ConnectionInstanceMetaData has to allow for multiple definitions.

  • 2. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
    Adrian Brock Master

    I suppose ConnectionFactoryDeployer would be the most logical name.

    Forget about the xml format. We are interested in how you deploy a single
    ConnectionFactory and its associated connection manager, pool and jndi binding.

    In future there will be other things like the container definitions (interceptors),
    although these should be handled using aop.

    The XML is a convenience where you can deploy multiple connection factories
    (and mbeans) in the same file.

    Once we have the programmatic method from the metadata,
    the xml->metadata should be done in the same way as the RARDeployer,
    so we can handle different versions, not XSL.

    The different versions are important, e.g. we need backwards compatibility where
    the rar is identified using the 3.2 method (adapter-display-name) instead of the
    4.0 method (rar-name and connection-definition)

  • 3. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
    Steve Lewis Expert

    Right. That makes sense. It doesn't matter what the XML looks like as long as the metadata accurately describes the configuration options. XML is just a store of that.

    Is there a preferred JMX operation:

    "There should be an option to create
    ConnectionFactories/DataSources by
    passing the meta data object on a JMX operation."

    Does the MBean already exist or will it be a completely new MBean? I'll check out what MBeans exist for JCA currently.

  • 4. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
    Adrian Brock Master

    DataSources are just ConnectionFactories with some hard-wiring.
    See the xsl - if you can read xsl :-)

    You can actually configure a DataSource using the more long winded ConnectionFactory
    method!

    Most of the config is actually ManagedConnectionFactory properties.

    What the -ds.xml does is hide from you the target of the config
    (connectionmanager, connection factory, pool or binding).
    Presenting it as a flat configuration.

    The new deployer should do a similar thing.

    So it does make sense to provide the same simplified DataSource deployment
    on top of the ConnectionFactory deployment.

  • 5. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
    Adrian Brock Master

    If it already existed, this TODO would not.

  • 6. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
    Steve Lewis Expert

    "DataSources are just ConnectionFactories with some hard-wiring.
    See the xsl - if you can read xsl :-)"

    Yeah, I've looked at it before when I was doing my own adapter for LDAP. Basically it spits out a jboss-service.xml file, although the file isn't saved to disk, just used in memory to configure the settings.

    Okay, looking at the jboss-service.xml in jboss-jca.sar, I see RAR and XSLSubDeployer. So in place of those we'd have

    1. ConnectionDefinitionDeployment
    2. ConnectionFactoryDeployer

    Looking at the XSL, I see that for my ldap adapter, I did in fact use the more long-winded ConnectionFactory method.

  • 7. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
    Adrian Brock Master

    The RAR deployer is fine as it is.

    I suggested calling the replacement for the XSL deployer the ConnectionDefinitionDeployer
    because that is what jca 1.5 calls it.
    But ConnectionFactoryDeployer is more intuitive.

  • 8. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
    Steve Lewis Expert

    Oh! Okay. I got confused. I thought you were renaming RARDeployer and creating ConnectionFactoryDeployer.

    My mistake, thanks for clearing it up.

  • 9. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
    Steve Lewis Expert

    How does the XSLSubDeployer tell the MainDeployer that it's a necessary SubDeployer? I see the addDeployer(SubDeployer) but I don't see where it's called to add the XSL.

    I'm just tracing through the code of XSLSubDeployer starting with its createService() method, but I don't see how its init(DeploymentInfo) method is called. Does something else register XSLSubDeployer

    OH. There it is. Parent class SubDeployerSupport has the mainDeployer. Duh.

    RARDeployer extends SubDeployerSupport, so instead of using XSLSubDeployer we want ConnectionFactoryDeployer to extend SubDeployerSupport as well.

    Who creates a DeploymentInfo object? Is it something that is created when a file is found under the deploy directory?

    I'll keep looking :) Maybe I'm a masochist, but I'm actually enjoying this.

  • 10. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
    Steve Lewis Expert

    Okay, I see it now. I think I'm getting pretty close to start coding so XSLSubDeployer can be put to sleep. The major arc of the changes is making sense. I'm sure there will be some details I run into.

    Assuming someone wants to create a ConnectionFactory programmatically, can they call ConnectionFactoryDeployer.create()? Or will that totally mess up the JMX lifecycle? Do we only need to use init when we add the XML piece (when it's called by MainDeployer)?

    Still thinking.

  • 11. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
    Steve Lewis Expert

    I just looked at the CVS tree and there's stuff there already for metadata and deployment. Is there anything specific I need to look at in there, do you think? I don't want to duplicate whatever has been done.

    Is that stuff just 1.5, or both 1.5 and 1.0? Will this TODO help 1.0 and 1.5, or just 1.0?

  • 12. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
    Scott Stark Master

    Talking to yourself in a forum is a scary sign.

  • 13. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
    Adrian Brock Master

    Take a look at the deployment and metadata folders.
    deployment handles the subdeployer processing
    metadata handles the xml->metadata parsing

    The RARDeployer is an extension to SimpleSubDeployerSupport, it creates and
    manages the lifecycle of RARDeployment mbeans.

    We want something similar for connection factories.

    The DeploymentInfo is ignorable. I only use to gain access to the deployer,
    metadata and url. It can easily be factored out into the components and removed
    from the deployment layer.

    1) The aim is to be able to create a ConnectionFactoryDeployment with some metadata
    and that will do all the work of creating the other mbeans.
    2) On top of that you write the ConnectionFactoryDeployer for integration into JBoss
    along with xml->metadata parsing.
    3) DataSourceDeployment is just a specialization of ConnectionFactoryDeployment
    with some hardwiring.

  • 14. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
    Steve Lewis Expert

    "The DeploymentInfo is ignorable. I only use to gain access to the deployer,
    metadata and url. It can easily be factored out into the components and removed
    from the deployment layer."

    Yeah that makes sense. There's no need for JCA to know about the main deployments and how it does things.

    I'll look at those folders. It sounds like we want to have a

    ConnectionFactoryDeployment (similar to RARDeployment)
    ConnectionFactoryDeployer (similar to RARDeployer)
    DataSourceDeployment extends ConnectionFactoryDeployment with some magic pixie dust to hide the details.

    Thanks,

1 2 3 Previous Next