Brent and Amita,

  If we make these updates and connectionInfo becomes XML elements rather
then XML Attributes, would this break backward compatibility and make all
applications to have  to update all DAS XML Config, is this right ? If this
is the case, is this acceptable ?

--
Luciano Resende
http://people.apache.org/~lresende

On 12/7/06, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:

Thank you Brent. I will work on all the below suggestions.

Some more questions:-
For each different database type, different connection properties may
be mandatory.
So, to support this in rdb-das J2SE connection support, if we know the
vendor, we can have programmatic control over which apis to invoke on
the datasource.

Also, when the JNDI datasource is defined through Tomcat or another
J2EE env. it is possible to configure different properties for same
and not just mandatory ones.
Shall the same approach be followed, in which case
ConnectionProperties will have place for all the mandatory + optional
properties. Or shall we just provide support for defining the
mandatory properties?

Also, in the current code, I have used EasyMock to define the
InitialContext. Is this the right way or need to go for defining
InitialContext using some other way?

Regards,
Amita

On 12/7/06, Brent Daniel <[EMAIL PROTECTED]> wrote:
> Luciano,
>
> I'm referring  to the changes to the DAS config model in Amita's patch.
>
> Brent
>
> On 12/6/06, Luciano Resende <[EMAIL PROTECTED]> wrote:
> > Hi Brent, are you recommending these changes in the SCDL ? Or in the
DAS
> > config itself to better handle other types of connections in J2SE
> > environments ?
> >
> > - Luciano
> >
> > On 12/6/06, Brent Daniel <[EMAIL PROTECTED]> wrote:
> > >
> > > Amita,
> > >
> > >   Thanks for working on this. One thing I would like to see is the
> > > DataSource properties seperated from the J2SE Connection properties.
> > > Maybe something like:
> > >
> > > <ConnectionInfo managedtx="true>
> > >    <DataSource jndiName="jdbc/myDataSource"/>
> > > </ConnectionInfo>
> > >
> > > or
> > >
> > > <ConnectionInfo>
> > >   <ConnectionProperties dataSourceClass="org.apache.myclass"/>
> > > </ConnectionInfo>
> > >
> > > The seperation just makes it clearer that your application should
use
> > > one or the other approaches.
> > >
> > > Also, are all of the properties you have added necessary? In
> > > particular, I'm not sure what we would use databaseVendor for since
it
> > > shouldn't have an effect on how we obtain the connection.
> > >
> > > I didn't look deeply enough to see if your code addresses this, but
if
> > > we're adding a password field we will need to have a way to
> > > encrypt/decrypt the field.
> > >
> > > Thanks,
> > > Brent
> > >
> > > On 12/6/06, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> > > > Hi Kevin, Luciano and All,
> > > > I tried to implement support for DAS config connection for J2SE
env.
> > > Please
> > > > see the attachment for what changes are done. Tried to modify
> config.xsdand
> > > > related code changes. Please let me know your feedback on this
> approach
> > > > and the alternative approaches.
> > > >
> > > > Can we have a discussion on same and also please let me know if I
can
> > > work
> > > > on this
> > > > JIRA.
> > > >
> > > > Regards,
> > > > Amita
> > > >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > > [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > > >
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > --
> > Luciano Resende
> > http://people.apache.org/~lresende
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Reply via email to