Skip to main content

Unable to make Java2DB work.

6 replies [Last post]
notivago
Offline
Joined: 2004-04-05

Hello there guys,

I am trying to use the Java2DB feature in Glassfish V2 and so far I am unable to make it work.

This is how my persistence.xml looks like:

<br />
<?xml version="1.0" encoding="UTF-8"?></p>
<p>		jdbc/__default</p>
<p>

I have tried it without specifying the data source, with the default one and with the one I set up.
The the persistence unit and the persistence classes are bundled in cadastroEntities.jar file that goes on the root of the EAR bundle, I also have a EJB bundle that has only one do nothing SessionBean so that I can deploy the application, it is also on the root of the EAR bundle.

The database is running, the application gets deployed and no table is created: Follow the tail of the server.log after my last deploy:

<br />
[#|2008-06-04T16:45:43.792-0300|INFO|sun-appserver9.1|javax.enterprise.system.core|_ThreadID=17;_ThreadName=Thread-59;|About to load the system app: __ejb_container_timer_app|#]</p>
<p>[#|2008-06-04T16:45:44.708-0300|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=17;_ThreadName=Thread-59;jdbc/__TimerPool;|EJB5109:EJB Timer Service started successfully for datasource [jdbc/__TimerPool]|#]</p>
<p>[#|2008-06-04T16:45:44.709-0300|INFO|sun-appserver9.1|javax.enterprise.system.core.classloading|_ThreadID=17;_ThreadName=Thread-59;__ejb_container_timer_app;|LDR5010: All ejb(s) of [__ejb_container_timer_app] loaded successfully!|#]</p>
<p>[#|2008-06-04T16:45:44.775-0300|INFO|sun-appserver9.1|javax.enterprise.resource.corba|_ThreadID=17;_ThreadName=Thread-59;|POARemoteRefFactory checking if SFSBVersionPolicy need to be added|#]</p>
<p>[#|2008-06-04T16:45:44.776-0300|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=17;_ThreadName=Thread-59;|EJBSCLookup:: sc.getEjbContainerAvailabilityEnabledFromConfig() ==> false|#]</p>
<p>[#|2008-06-04T16:45:44.777-0300|INFO|sun-appserver9.1|javax.enterprise.resource.corba|_ThreadID=17;_ThreadName=Thread-59;|POARemoteRefFactory addSFSBVersionPolicy? false|#]</p>
<p>[#|2008-06-04T16:45:44.777-0300|INFO|sun-appserver9.1|javax.enterprise.resource.corba|_ThreadID=17;_ThreadName=Thread-59;|POARemoteRefFactory checking if SFSBVersionPolicy need to be added|#]</p>
<p>[#|2008-06-04T16:45:44.779-0300|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=17;_ThreadName=Thread-59;|EJBSCLookup:: sc.getEjbContainerAvailabilityEnabledFromConfig() ==> false|#]</p>
<p>[#|2008-06-04T16:45:44.780-0300|INFO|sun-appserver9.1|javax.enterprise.resource.corba|_ThreadID=17;_ThreadName=Thread-59;|POARemoteRefFactory addSFSBVersionPolicy? false|#]</p>
<p>[#|2008-06-04T16:45:44.798-0300|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=17;_ThreadName=Thread-59;|**RemoteBusinessJndiName: br.com.cleardesign.cadastro.GerenciamentoUsuario; remoteBusIntf: br.com.cleardesign.cadastro.GerenciamentoUsuario|#]</p>
<p>[#|2008-06-04T16:45:44.824-0300|INFO|sun-appserver9.1|javax.enterprise.system.core.classloading|_ThreadID=17;_ThreadName=Thread-59;Caldeirao;|LDR5010: All ejb(s) of [Caldeirao] loaded successfully!|#]<br />

I thank you for any help or insight on this,
Notivago.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
chris_delahunt
Offline
Joined: 2005-07-06

Hello Notivago,

I think there is some confusion. The tables get created when the EntityManager is first created, as that is when the persistence.xml gets loaded and all the information is available to determine what needs to be created and/or dropped. In a container, it has nothing to do with EJBs, it just happens that this is usually where EMs are injected to and used from. You can

In Java SE, this point is more apparent, as you have to explicitly create the EntityManager. In a container environment such as glassfish, things are more difficult to determine because the process is hidden by injection. Glassfish though will only create the EntityManager for your application if it is used. That means you can define as many as you want, but the container will not dedicate resources to them until they are actually used. This has nothing to do with EJBs; it just happens that this is usually where EMs are injected to and used from. You can access the EM from anywhere in your application using a lookup, which will cause it and the tables to be created.

Hope this helps explain what you are seeing.

Best Regards,
Chris

mzh777
Offline
Joined: 2005-06-07

Here is another Java2DB example used in testing GlassFish V2:
http://blogs.sun.com/quality/entry/configuring_java2db_with_glassfish

There are quite a lot of uses case in quality blogs:
http://blogs.sun.com/quality/

Please check and let us know your comments.

Thanks,
Ming

notivago
Offline
Joined: 2004-04-05

Hey Ming,

I just saw your post and the blog, but I think the core of the matter is that previous to this discussion I saw no indication that the declaration of the persistence unit on an EJB was mandatory for java2db to work, and in my opinion it should not be.

I don't see why toplink does not use the persistence.xml to find and create the data tables, it would be the logical step, instead of searching the EJBs for reference.

On top of that you tie the user to given examples or more extensive/complex coding to achieve the java2db deployment, when it is not really necessary.

As in my case, I build the project from the ground up, and the persistence in it's own jar, I don't see why it should be packaged with the EJB jar as its classes and persistence model can be reused elsewhere without EJBs, so I deployed it without anyone at first. As I was barred by the deployer that stated that at least one old style entity, EJB should be present in order for the ear to be valid, I wrote one dummy in an separate jar bundled in the ear.

And then it deployed without error, but also without activating the java2db. And no high quality blog did mention the fact that you must reference the persistence unit in at least one EJB.

Now, I know that no prodution application would go up without any EJB at all and that if the persistence unit is not referenced, it will not be used and thus it is useless to build the tables, but as I understand it the java2dp is meant to help during development, not to create the final DB schema, and thus it is conceivable that the persistence classes would be written first and the developers would like to see how the DB schema would be created previous to any EJB development.

[]s
Notivago.

mvatkina
Offline
Joined: 2005-04-04

It's a matter of opinion on what should happen if the PU is declared but not used. Imagine another scenario when you have more than one PU defined in your persistence.xml and you use only one of them? You might be surprised to have unused tables created or even worst PU loading fail because that other PU references a datasource that had not been even configured.

Regards,
-marina

Mitesh Meswani

Is your application actually referring to the PersistenceUnit as an
injection target or dependency? Glassfish only instantiates those PUs at
deployment (and hence calls java2db on them).

glassfish@javadesktop.org wrote:
> Hello there guys,
>
> I am trying to use the Java2DB feature in Glassfish V2 and so far I am unable to make it work.
>
> This is how my persistence.xml looks like:
> [code]
>
>
>
> jdbc/__default
>
>
>
>
>
> [/code]
>
> I have tried it without specifying the data source, with the default one and with the one I set up.
> The the persistence unit and the persistence classes are bundled in cadastroEntities.jar file that goes on the root of the EAR bundle, I also have a EJB bundle that has only one do nothing SessionBean so that I can deploy the application, it is also on the root of the EAR bundle.
>
> The database is running, the application gets deployed and no table is created: Follow the tail of the server.log after my last deploy:
> [code]
> [#|2008-06-04T16:45:43.792-0300|INFO|sun-appserver9.1|javax.enterprise.system.core|_ThreadID=17;_ThreadName=Thread-59;|About to load the system app: __ejb_container_timer_app|#]
>
> [#|2008-06-04T16:45:44.708-0300|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=17;_ThreadName=Thread-59;jdbc/__TimerPool;|EJB5109:EJB Timer Service started successfully for datasource [jdbc/__TimerPool]|#]
>
> [#|2008-06-04T16:45:44.709-0300|INFO|sun-appserver9.1|javax.enterprise.system.core.classloading|_ThreadID=17;_ThreadName=Thread-59;__ejb_container_timer_app;|LDR5010: All ejb(s) of [__ejb_container_timer_app] loaded successfully!|#]
>
> [#|2008-06-04T16:45:44.775-0300|INFO|sun-appserver9.1|javax.enterprise.resource.corba|_ThreadID=17;_ThreadName=Thread-59;|POARemoteRefFactory checking if SFSBVersionPolicy need to be added|#]
>
> [#|2008-06-04T16:45:44.776-0300|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=17;_ThreadName=Thread-59;|EJBSCLookup:: sc.getEjbContainerAvailabilityEnabledFromConfig() ==> false|#]
>
> [#|2008-06-04T16:45:44.777-0300|INFO|sun-appserver9.1|javax.enterprise.resource.corba|_ThreadID=17;_ThreadName=Thread-59;|POARemoteRefFactory addSFSBVersionPolicy? false|#]
>
> [#|2008-06-04T16:45:44.777-0300|INFO|sun-appserver9.1|javax.enterprise.resource.corba|_ThreadID=17;_ThreadName=Thread-59;|POARemoteRefFactory checking if SFSBVersionPolicy need to be added|#]
>
> [#|2008-06-04T16:45:44.779-0300|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=17;_ThreadName=Thread-59;|EJBSCLookup:: sc.getEjbContainerAvailabilityEnabledFromConfig() ==> false|#]
>
> [#|2008-06-04T16:45:44.780-0300|INFO|sun-appserver9.1|javax.enterprise.resource.corba|_ThreadID=17;_ThreadName=Thread-59;|POARemoteRefFactory addSFSBVersionPolicy? false|#]
>
> [#|2008-06-04T16:45:44.798-0300|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=17;_ThreadName=Thread-59;|**RemoteBusinessJndiName: br.com.cleardesign.cadastro.GerenciamentoUsuario; remoteBusIntf: br.com.cleardesign.cadastro.GerenciamentoUsuario|#]
>
> [#|2008-06-04T16:45:44.824-0300|INFO|sun-appserver9.1|javax.enterprise.system.core.classloading|_ThreadID=17;_ThreadName=Thread-59;Caldeirao;|LDR5010: All ejb(s) of [Caldeirao] loaded successfully!|#]
> [/code]
>
> I thank you for any help or insight on this,
> Notivago.
> [Message sent by forum member 'notivago' (notivago)]
>
> http://forums.java.net/jive/thread.jspa?messageID=278403
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

notivago
Offline
Joined: 2004-04-05

Thank you Mitesh!

It seems that it was the case, now that I have some real EJBs, the persistence is being created.

=D

[]s
Notivago.