I think there are several related issues here... I hope I'm not confusing things further.
1. I think we agree on vendor specific ManagedConnectionFactory implementations wrapping vendors' XADataSource implementations, with customized XAResource wrappers. 2. It is not really essential for deployment (see below), but I would like each one to have a spec-compliant ra.xml describing its capabilities (mostly what config-properties it supports). If you write the oracle mcf I'll write the ra.xml for it;-) 3. I like your idea of directly transforming the *-xa-ds.xml into the needed mbean config. We don't need any "target identifier" other than the mcf class: the datasource class will be determined by the return of mcf.createConnectionFactory. With this, we don't need the "old-rar-deployment". This does enable a generic .xsl script, but it has a couple of possible problems: no default values are possible, and the specification of which driver is made by giving a jboss class name. A layer of indirection might be a good idea. We could also include a table-like structure for each "name" of defaults. In jboss 3.2 and possibly 4 it will be easiest to start by modifying org.jboss.resource.connectionmanager.RARDeployment to accept the mcf class as an attribute and not require the old-rar-deployment. In jboss 4 it is possible to dispense entirely with org.jboss.resource.connectionmanager.RARDeployment by generating xmbean configuration and deploying the mcf directly as an mbean. maybe this should wait until we have the solution working for org.jboss.resource.connectionmanager.RARDeployment. Did you come up with some corrections for the current jboss 4 .xsl? If so could you apply them? thanks david jencks On 2002.08.27 17:28:32 -0400 Igor Fedorenko wrote: > David Jencks wrote: > > On 2002.08.27 09:19:04 -0400 Igor Fedorenko wrote: > > > [skipped] > > >> > >>How do I deploy rm specific wrapper? Am I right that there is a > >>prototype RARDeployment instance > >>(jboss.jca:service=RARDeployment,name=JBoss JDBC XATransaction > >>ResourceAdapter) that defines wrapper to be used? Should I deploy such > >>prototype for each resource manager or it is better to get rid of > >>prototype and provide all necesary info in -ds.xml? > > > > > > I'm thinking: > > > > 1. write OracleManagedConnectionFactory extending > > XAManagedConnectionFactory, with all the properties the Oracle > XADataSource > > has exposed as mcf properties > > > > 2. write a ra.xml for it, listing the config-properties with, if > > appropriate, default values > > > > 3. modify connector/build.xml to package this into a oracle-xa-jdbc.rar > > > > 4. modify the xsl to process an oracle-xa-datasource element, so it > will > > process exactly the config properties available for the oracle wrapper. > > > > The mbean naming is too confusing at the moment, there are 2 things > > claiming to be RARDeployments. One of them basically holds the ra.xml > from > > the .rar, the other should be called a ManagedConnectionFactory. In > fact > > the second can be an actual managed connectin factory instance deployed > as > > an xmbean. > > > > Is this any clearer? Please ask if you have more questions. > I am new to this JCA stuff and it looks too complicated to me. Would not > it be easier to have only one RARDeployment that gets all necessary > parameters from *-ds.xml file? Keep in mind that we are talking > specifically about JDBC XA connection factories, so we can provide all > reasonable defaults with xslt template. For example, oracle-xa-ds.xml > would look like > > <datasources> > <xa-datasource> > <jndi-name>OracleDS</jndi-name> > <display-name>JBoss JDBC XATransaction ResourceAdapter</display-name> > <managedconnectionfactory-class> > org.jboss.resource.adapter.jdbc.xa.oracle.OracleXAManagedConnectionFactory > </managedconnectionfactory-class> > <xa-datasource-class> > org.jboss.resource.adapter.jdbc.xa.oracle.OracleXADataSource > </xa-datasource-class> > <xa-datasource-property name="URL"> > jdbc:oracle:oci8:@tc</xa-datasource-property> > <xa-datasource-property name="User"> > scott > </xa-datasource-property> > <xa-datasource-property name="Password"> > tiger > </xa-datasource-property> > </xa-datasource> > </datasources> > > Note that this way we can have generic xslt script (i.e. no vendor > specific tags) and keep all rm specific logic in wrapped factories. > > -- > Igor Fedorenko > Think smart. Think automated. Think Dynamics. > www.thinkdynamics.com > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Jabber - The world's fastest growing > real-time communications platform! Don't just IM. Build it in! > http://www.jabber.com/osdn/xim > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ------------------------------------------------------- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
