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

Reply via email to