I have checked in my changes -- fixed XAManagedConnectionFactory, DataSourceTemplate.xsl as well as example oracle-xa-ds.xml. I decided not to implement oracle specific mcf now but may reconsider it later. I also renamed *.java files with "preprocessor" markup into *.jpp.
David Jencks wrote: > On 2002.08.29 08:10:08 -0400 Igor Fedorenko wrote: > >>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. > > > Right, this is what we need until we have vendor-specific wrappers. > >>>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. > > > Good idea. > >>>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? > > > I think I made some mistakes about this. I won't have time to look at it > until at least later today, if you want to commit what you have so far that > would prevent me from breaking what you've changed already. If you want to > figure it out, please go ahead. > > thanks > david jencks > >>>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
