-
1. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
spiritualmechanic May 26, 2004 10:39 PM (in response to adrian.brock)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 May 26, 2004 11:03 PM (in response to adrian.brock)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
spiritualmechanic May 26, 2004 11:08 PM (in response to adrian.brock)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 May 26, 2004 11:54 PM (in response to adrian.brock)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 May 26, 2004 11:56 PM (in response to adrian.brock)If it already existed, this TODO would not.
-
6. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
spiritualmechanic May 27, 2004 7:46 AM (in response to adrian.brock)"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 May 27, 2004 8:22 AM (in response to adrian.brock)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
spiritualmechanic May 27, 2004 8:58 AM (in response to adrian.brock)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
spiritualmechanic May 27, 2004 10:43 PM (in response to adrian.brock)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
spiritualmechanic May 27, 2004 11:25 PM (in response to adrian.brock)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
spiritualmechanic May 27, 2004 11:38 PM (in response to adrian.brock)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
starksm64 May 28, 2004 12:03 AM (in response to adrian.brock)Talking to yourself in a forum is a scary sign.
-
13. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
adrian.brock May 28, 2004 5:57 AM (in response to adrian.brock)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
spiritualmechanic May 28, 2004 9:32 AM (in response to adrian.brock)"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,