You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Alexander Saint Croix <sa...@gmail.com> on 2007/12/23 01:54:52 UTC

Resource elements in openejb.xml quietly remapping to Default JDBC Database?

Hi!

Good news.  With (lots of) Dain's help, I finally got my example
working.  We did, however, find what appears to be a bug and a
workaround for it.

I specify two <Resource> mappings in my openejb.xml file, which look like this:

<Resource id="myDataSource" type="DataSource">
    JdbcDriver com.mysql.jdbc.Driver
    JdbcUrl jdbc:mysql://localhost/corm
    UserName root
    Password n00p455wyrd
    JtaManaged true
</Resource>

<Resource id="myNonJtaDataSource" type="DataSource">
    JdbcDrive com.mysql.jdbc.Driver
    JdbcUrl jdbc:mysql://localhost/corm
    UserName root
    Password n00p455wyrd
    JtaManaged false
</Resource>

Then, in my persistence.xml file I reference these mappings, like so:

    <jta-data-source>java:openejb/Resource/myDataSource</jta-data-source>
    <non-jta-data-source>java:openejb/Resource/myNonJtaDataSource</non-jta-data-source>

Now, this all looks normal thus far, but when I boot Tomcat, my
openejb logs tell me the following:

...
2007-12-22 18:37:20,636 - INFO  - Configuring Service(id=myDataSource,
type=Resource, provider-id=Default JDBC Database)
2007-12-22 18:37:20,638 - INFO  - Configuring
Service(id=myNonJtaDataSource, type=Resource, provider-id=Default JDBC
Database)
...

This seems to indicate that the two resources are getting
automatically pointed at the Default JDBC Database.  On further
inspection, it turns out that the Default JDBC Database and Default
Unmanaged JDBC Database is listed as a <Connector> elements.  Dain's
writing more information about this in another thread on the dev list.
 I think that if the resources are going to get pointed elsewhere,
that should be obvious, or loudly noted somewhere.  I ended up
filtering down the logs with apple's log viewer to find that
reassignment.  Never would have found it otherwise.

So, I switched the Default JDBC Database <Connector> to a <Resource>
and changed its internals to point at MySQL instead of HSQLDB:

<Resource id="Default JDBC Database" >
    JdbcDriver com.mysql.jdbc.Driver
    JdbcUrl jdbc:mysql://localhost/corm
    UserName root
    Password n00p455wyrd
    JtaManaged true
</Resource>

And, for consistency, the unmanaged version:

<Resource id="Default Unmanaged JDBC Database">
    JdbcDriver com.mysql.jdbc.Driver
    JdbcUrl jdbc:mysql://localhost/corm
    UserName root
    Password n00p455wyrd
    JtaManaged false
</Resource>

Finally, I switch the persistence.xml to read:

    <jta-data-source>java:openejb/Resource/Default JDBC
Database</jta-data-source>
    <non-jta-data-source>java:openejb/Resource/Default Unmanaged JDBC
Database</non-jta-data-source>

And now, the app is pointing at the MySQL DataSource correctly.

Thanks, guys!
--
Alexander R. Saint Croix

Re: Resource elements in openejb.xml quietly remapping to Default JDBC Database?

Posted by Alexander Saint Croix <sa...@gmail.com>.
Happy to help, David ;-)
--
Alex



On Dec 22, 2007 11:01 PM, David Blevins <da...@visi.com> wrote:
>
> On Dec 22, 2007, at 6:28 PM, David Blevins wrote:
>
> > So fixed two things.  One, I fixed the tomcat servce-jar.xml so the
> > configuration you described above should work.  Two, I added
> > warnings on any properties that don't exist -- this should have been
> > there all along and will prevent any future situations where someone
> > is using a configuration flag that is actually doing nothing.
>
> FYI, added another nice feature that should have been there, case
> insensitive property names.  So "Username", "UserName" or "username"
> is totally fine.
>
> -David
>
>

Re: Resource elements in openejb.xml quietly remapping to Default JDBC Database?

Posted by David Blevins <da...@visi.com>.
On Dec 22, 2007, at 6:28 PM, David Blevins wrote:

> So fixed two things.  One, I fixed the tomcat servce-jar.xml so the  
> configuration you described above should work.  Two, I added  
> warnings on any properties that don't exist -- this should have been  
> there all along and will prevent any future situations where someone  
> is using a configuration flag that is actually doing nothing.

FYI, added another nice feature that should have been there, case  
insensitive property names.  So "Username", "UserName" or "username"  
is totally fine.

-David

Re: Resource elements in openejb.xml quietly remapping to Default JDBC Database?

Posted by David Blevins <da...@visi.com>.
On Dec 22, 2007, at 4:54 PM, Alexander Saint Croix wrote:

> I specify two <Resource> mappings in my openejb.xml file, which look  
> like this:
>
> <Resource id="myDataSource" type="DataSource">
...
> <Resource id="myNonJtaDataSource" type="DataSource">
...
> Now, this all looks normal thus far, but when I boot Tomcat, my
> openejb logs tell me the following:
>
> ...
> 2007-12-22 18:37:20,636 - INFO  - Configuring Service(id=myDataSource,
> type=Resource, provider-id=Default JDBC Database)
> 2007-12-22 18:37:20,638 - INFO  - Configuring
> Service(id=myNonJtaDataSource, type=Resource, provider-id=Default JDBC
> Database)
> ...
>
> This seems to indicate that the two resources are getting
> automatically pointed at the Default JDBC Database.

Correct.  This is the desired behavior.  You're essentially creating a  
new DataSource definition using the default values of "Default JDBC  
Database" + the values you've specified.

It should have worked and I've figured out why it didn't.  When I  
added support for the JtaManaged flag, I forgot to update the service- 
jar.xml we use in Tomcat.  It was still using the old DataSource  
factories and you weren't getting the non-jta-datasource you needed.   
You inadvertently fixed the issue by setting your Resource id to  
"Default Unmanaged JDBC Database" (setting provider="Default Unmanaged  
JDBC Database" would have also worked and allowed you to use any id  
you like).

So fixed two things.  One, I fixed the tomcat servce-jar.xml so the  
configuration you described above should work.  Two, I added warnings  
on any properties that don't exist -- this should have been there all  
along and will prevent any future situations where someone is using a  
configuration flag that is actually doing nothing.

Thank you *very* much for reporting the issue.


-David