Thanks! This looks good. Do you have Oracle working with the new xa wrapper?
david jencks On 2002.08.29 16:51:45 -0400 Igor Fedorenko wrote: > 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 > > ------------------------------------------------------- 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
