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