David Jencks wrote: > 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. More or less. ;-)
> > 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". I'll keep both mcf class (with XAManagedConnectionFactory as a default) and optional <xa-datasource-class> for now. We can drop <xa-datasource-class> later. > > 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. Let's start with something simple (i.e working solution for RARDeployment and no fancy xst) and add features as we need them later. > Did you come up with some corrections for the current jboss 4 .xsl? If so > could you apply them? Well, almost. I was going to commit my changes but noticed something I was not sure about. It looks like BaseWrapperManagedConnectionFactory hierarchy has too many "connection properties" members and they are confused with each other. For example, XAManagedConnectionFactory uses (never initialized!) "connectionProps" to match identical connections but xaProps to create datasource. Am I missing somethig? > > 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
