1> readmes commit - I will wait and make it along with any other
changes in JIRA-1698 as we are still deciding which sample to use to
demo the feature of
JIRA-1698

2> There are 3 test cases in ConnectionTests, please see if you find
some other cases that can be included.

3> Using jboss jars - as these were available on mvn repo, I missed
the point of license, if license is the issue, then these can not be
used.

 TC has
(default)BasicDataSource - which does not support getConnection(id, pwd)
and
PerUserPoolDataSource, SharedPoolDataSource - which support
getConnection(id, pwd)

When trying to configure PerUserPoolDataSource, SharedPoolDataSource
with TC 6.0.14, was getting different errors, will see if can get this
working.

I am not doing any commits related to this JIRA, till 3> or some other
sample is formed, so all changes will go together.

Regards,
Amita

On Nov 6, 2007 11:06 PM, Luciano Resende <[EMAIL PROTECTED]> wrote:
> Comments inline :
>
> On 11/6/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> > changes done -
> >
> > 1) cleaned readme files using eclipse IDE html editor - samples, dbconfig
> Good, Thanks, please committ this, you don't have to wait anymore :)
>
> > 2) replaced MySQL with Derby
> Just want to make sure you have all the functionality you need in Derby...
>
> > 3) replaced sun provided JNDI jars with jboss jar - because - these are
> > available in mvn repos and only 3 are required in the build path
> > (jboss-common 3.2.3, jnp-client 4.0.2 and jnpserver 3.2.3  - total 350 KB)
>
> I downloaded the jars, but couldn't find any license files there.
> Also, JBOSS stuff tend to be LGPL and that is not ASF Friendly, so
> could you please point me to the proper license for these files ?
>
>
> > 4) added more test cases in ConnectionTests.java and removed 
> > sample-dataSource
> > 5) patch attached to JIRA-1698
> >
> > Please see if there are any problems in the above, else I will commit the
> > patch.
> > The bin size increase due to jboss jars is 350 KB and so it may be OK to
> > make it
> > as test cases instead of sample.
> >
>
>
> Well, in summary, it's lots of dependencies issues to demonstrate we
> now support authentication when retrieving the datasource
> connection... and based on the dependencies being dragged to DAS
> distro... I'm now inclined to have just a sample, or simpler, just
> document in the User Guide.
>
> BTW, I'll play with this over the weekend and try to make this working
> in TC with Companyweb... Maybe this is a simpler solution :)
>
>
> > Regards,
> > Amita
> >
> > On 11/5/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > >
> > > On 11/5/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I was trying to run the new DAS sample (dataSource) and I looks like
> > > > it requires MySQL in order to run the sample, this might not be the
> > > > best default configuration to require, as it requires lots of steps in
> > > > order to just try the sample ( e.g install MySQL), and it also makes it
> > > > difficult to test the sample during build. I'd like to suggest two
> > > > things for our DAS Sample applications :
> > > >
> > > > - Use Derby as the default database in a sample application
> > >
> > >
> > > Agree, done changes for this
> > >
> > > - Have a simple unit test to quickly check if the sample is working
> > > > (use htmlUnit for webapp)
> > >
> > >
> > > The jira has test cases for case which does not require external JNDI.
> > > Which JNDI jar is available
> > > as part of maven repo? I could not spot one and used sun's jars. As these
> > > can not get downloaded
> > > thru mvn build and need to be placed manually in the classpath, used
> > > sample instead of junit for
> > > testcase which requires JNDI. But if there is a maven repo based jar
> > > providing JNDI, the sample
> > > can be removed and instead junit cases can be added. Tried RootContext
> > > from Geronimo but it is
> > > read only.
> > >
> > > Also, I was wondering what we should use for demonstrating a specific
> > > > feature... I guess we might not need a new sample for every new
> > > > feature, this might increase the complexity of developing a new
> > > > feature, I guess a test case might be good enough.... and a sample
> > > > would be used more to demonstrate a bigger scenario or a how a set of
> > > > features work together...
> > > >
> > > > Thoughts ?
> > > >
> > > > --
> > > > Luciano Resende
> > > > Apache Tuscany Committer
> > > > http://people.apache.org/~lresende<http://people.apache.org/%7Elresende>
> > > > http://lresende.blogspot.com/
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> >
>
>
> --
>
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> 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