You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by David Blevins <da...@visi.com> on 2008/05/21 05:12:02 UTC

EJB unit testing available

I just wanted to put this on everyone's radar in case it wasn't  
already known.  Those of you writing EJB applications run on Geronimo  
have an extra advantage that those applications can be easily unit  
tested by embedding the Geronimo EJB container (OpenEJB) into your  
test case.

This sort of in-container unit testing technique is something we've  
been innovating for a while and is likely to be a major addition to  
the EJB 3.1 specifications.  I strongly encourage anyone doing EJB  
development to check this out.  There are a number of examples  
available here: http://openejb.apache.org/examples.html

The net result of this is that you should be able to quickly unit test  
your ejbs in your build as you would test a plain java application.   
With good EJB unit tests you'll get much faster development, fewer  
build/deploy cycles, and be able to quickly catch basic deployment  
issues that stem from incorrect or non-compliant apps.

-David




RE: Openejb 3.0 : JUNIT with embedded Container can't commit Transaction

Posted by Jo...@bgs-ag.de.
One addtitional information:

If code is run inside the Geronimo 2.1.1 App.server, the used 
Entitymanager is: org.apache.geronimo.persistence.CMPEntityManagerTxScoped
If junit runs in embedded openejb the Entitymanager is: 
org.apache.openejb.persistence.JtaEntityManager

Is there a way to change this for embedded openejb?


-----------------------------------------------------------------------------

Hi All,

great Idea to do unit-testing using the embedded functions of openejb. So 
I tried... 

I have a JavaEE-5 application on Geronimo 2.1.1 with Postgres-DB. (Driver 
postgresql-8.2-508.jdbc3.jar). In Geronimo I defined a database pool with 
Pool-Type "TranQL XA Resource Adapter for PostgreSQL". I use Local Session 
Beans in General. The Application works quite well.

Thus I tried to do this with embedded openejb. After quite a few problems 
to set up the system, my JUNIT-Test works up to a certain step. It seems 
there is maybe an impact with the transaction - functionality. The 
transaction could not be comitted. I could imagine not the XA-Datasource 
is taken, but who knows??

openejb.conf:
...
  <SecurityService id="Default Security Service"/>
  <TransactionManager id="Default Transaction Manager"/> 
</openejb>


JUNIT-Testcase:
        public void setUp() throws Exception {
                Properties properties = new Properties();
                properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
 "org.apache.openejb.client.LocalInitialContextFactory");
 
                properties.put("openejb.home", 
"/home/user/workspace/VesuvUnit/openejb");
 
                properties.put("openejb.configuration", 
                  "/home/user/workspace/VesuvUnit/openejb/openejb.conf");

                ....
 
                properties.put("Postgres.postgres.vesuv", 
"new://Resource?type=DataSource");
                properties.put("Postgres.postgres.vesuv.JdbcDriver", 
"org.postgresql.Driver");
                properties.put("Postgres.postgres.vesuv.JdbcUrl", 
"jdbc:postgresql://localhost/bla");
                properties.put("Postgres.postgres.vesuv.UserName", "bla");
                properties.put("Postgres.postgres.vesuv.Password", "bla");
   ....

persistence.xml:
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
http://java.sun.com/xml/ns/persistence 
http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
        <persistence-unit name="VesuvPU">
                <description>Vesuv Application</description>
 
<provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
            <jta-data-source>Postgres.postgres.vesuv</jta-data-source>
            <class>
...
                <properties>
                    <property name="openjpa.jdbc.SynchronizeMappings" 
value="false" />
                <property name="openjpa.jdbc.Schema" value="vesuv" />
                </properties>
        </persistence-unit>
</persistence>


Lookup of the SessionBean works. Invoking the method is fine. 
SQL-Statements are done. But 

LOG:
[DEBUG] [BenutzerManagerImpl] >> Mandant: Mandant:Vesuv Servicestelle Id:1 
Kurzname: SS PersonFK:0 Tstaend:null
13:18:31,644 INFO  [Transaction] TX Required: Committing transaction 
org.apache.geronimo.transaction.manager.TransactionImpl@1579371
13:18:31,693 DEBUG [SQL] <t 15431769, conn 0> executing prepstmnt 31310826 
UPDATE vesuv.v_org_einheit 
...
13:18:31,702 DEBUG [SQL] <t 15431769, conn 0> [9 ms] spent
13:18:31,717 DEBUG [SQL] <t 15431769, conn 0> executing prepstmnt 23410971 
UPDATE vesuv.benutzer SET 
...
...
Caused by: <openjpa-1.0.1-r420667:592145 nonfatal store error> 
org.apache.openjpa.util.StoreException: FEHLER: kann eine Sicht nicht 
aktualisieren {prepstmnt 31310826 UPDATE vesuv.v_org_einheit SET 
beziehung_org_einheit_typ = ?, kurz_name = ?, name = ?, org_einheit_typ = 
?, person_fk = ?, rechtsform = ?, tstaend = ?, beziehung_org_einheit_fk = 
?, uebergeordnete_org_einheit_fk = ? WHERE id = ? [params=(null) null, 
(String) SS, (String) Vesuv Servicestelle, (String) SS, (long) 1, (String) 
SS, (Timestamp) 2008-05-26 10:10:43.96, (null) null, (null) null, (long) 
1]} [code=0, state=0A000]
FailedObject: 
...

The LOG-File is in German, therefore some translation: Sicht = View. The 
Update of the View-PAO does not work. Any suggestions ??? 

Thanx Josef
BGS Beratungsgesellschaft 
Software Systemplanung AG 
  
  
  
  
Niederlassung Rhein/Main 
Robert-Koch-Stra�e 41 
55129 Mainz 
Fon: +49 (0) 6131 / 914-0 
Fax: +49 (0) 6131 / 914-400 
www.bgs-ag.de 
Gesch�ftssitz Mainz 
Registergericht 
Amtsgericht Mainz 
HRB 62 50 
  
Aufsichtsratsvorsitzender 
Dr. Wolfgang Trommer 
Vorstand 
Hanspeter Gau 
Hermann Kiefer 
Nils Manegold 
Heinz-J�rg Zimmermann 


  

Re: Antwort: Re: Openejb 3.0 : JUNIT with embedded Container can't commit Transaction

Posted by David Blevins <da...@visi.com>.
On Jun 6, 2008, at 12:47 AM, Josef.Eisele@bgs-ag.de wrote:

> Hi David,
>
> thank you very much for your help. After adding the javaagent  
> everything
> worked fine. THANK YOU VERY MUCH!!!!!!!!!!

Fantastic, that's great!

> Now my next step is to implement JAAS-Container Security inside my
> JUNIT-Test. I will open a new thread for this.

Definitely, check out this example:

http://openejb.apache.org/3.0/testing-security-example.html

It has some clever techniques for testing various security constraints  
with zero setup required.

-David


Antwort: Re: Openejb 3.0 : JUNIT with embedded Container can't commit Transaction

Posted by Jo...@bgs-ag.de.
Hi David,

thank you very much for your help. After adding the javaagent everything 
worked fine. THANK YOU VERY MUCH!!!!!!!!!!

Now my next step is to implement JAAS-Container Security inside my 
JUNIT-Test. I will open a new thread for this.

Mit freundlichen Grüßen / Kind regards
Josef Eisele

Direkt: +49 (0) 6131 / 914-180




David Blevins <da...@visi.com> 
06.06.2008 01:46
Bitte antworten an
users@openejb.apache.org


An
users@openejb.apache.org
Kopie

Thema
Re: Openejb 3.0 : JUNIT with embedded Container can't commit Transaction






Hi Josef,

Couple questions.  What Java version are you using?  Are you setting "- 
javaagent:<path-to>/openejb-javaagent-3.0.jar" as part of the test 
parameters?  (an openjpa specific requirement)

Also, try is adjusting your test setup to the following.

     public void setUp() throws Exception {
         Properties properties = new Properties();
         properties.setProperty(Context.INITIAL_CONTEXT_FACTORY, 
"org.apache.openejb.client.LocalInitialContextFactory");
         properties.put("Postgres.postgres.vesuv", "new://Resource? 
type=DataSource");
         properties.put("Postgres.postgres.vesuv.JdbcDriver", 
"org.postgresql.Driver");
         properties.put("Postgres.postgres.vesuv.JdbcUrl", 
"jdbc:postgresql://localhost/bla");
         properties.put("Postgres.postgres.vesuv.UserName", "bla");
         properties.put("Postgres.postgres.vesuv.Password", "bla");
         ...
     }

I.e. with the OpenEJB home and openejb.conf file cut out.  We don't 
need the openejb.home for testing and 100% of the configuration we do 
need for testing can be supplied via the properties syntax you already 
have in your TestCase.  We use different "heavier" defaults (tx 
logging is enabled for example) if we determine we're running as a 
standalone server and setting an openejb.home to a directory 
containing a "conf/" directory is one way we determine that.

If you did want to declare your TransactionManager and SecurityService 
and more, you could do so in your test case as follows:

         properties.put("myTransactionManager", "new:// 
TransactionManager");
         properties.put("mySecurityService", "new://SecurityService");
         properties.put("myStatelessContainer", "new://Container? 
type=STATELESS");
         properties.put("myStatefulContainer", "new://Container? 
type=STATEFUL");

However we will automatically create all of these as needed so there's 
no reason to explicitly declare them unless you wish to override a 
value.

If you're comfortable posting your full log file output that can help 
too.

-David

On Jun 5, 2008, at 2:28 AM, Josef.Eisele@bgs-ag.de wrote:

> Hi All,
>
> great Idea to do unit-testing using the embedded functions of 
> openejb. So
> I tried...
>
> I have a JavaEE-5 application on Geronimo 2.1.1 with Postgres-DB. 
> (Driver
> postgresql-8.2-508.jdbc3.jar). In Geronimo I defined a database pool 
> with
> Pool-Type "TranQL XA Resource Adapter for PostgreSQL". I use Local 
> Session
> Beans in General. The Application works quite well.
>
> Thus I tried to do this with embedded openejb. After quite a few 
> problems
> to set up the system, my JUNIT-Test works up to a certain step. It 
> seems
> there is maybe an impact with the transaction - functionality. The
> transaction could not be comitted. I could imagine not the XA- 
> Datasource
> is taken, but who knows??
>
> openejb.conf:
> ...
>  <SecurityService id="Default Security Service"/>
>  <TransactionManager id="Default Transaction Manager"/>
> </openejb>
>
>
> JUNIT-Testcase:
>        public void setUp() throws Exception {
>                Properties properties = new Properties();
>                properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
> "org.apache.openejb.client.LocalInitialContextFactory");
>
>                properties.put("openejb.home",
> "/home/user/workspace/VesuvUnit/openejb");
>
>                properties.put("openejb.configuration",
>                  "/home/user/workspace/VesuvUnit/openejb/ 
> openejb.conf");
>
>                ....
>
>                properties.put("Postgres.postgres.vesuv",
> "new://Resource?type=DataSource");
>                properties.put("Postgres.postgres.vesuv.JdbcDriver",
> "org.postgresql.Driver");
>                properties.put("Postgres.postgres.vesuv.JdbcUrl",
> "jdbc:postgresql://localhost/bla");
>                properties.put("Postgres.postgres.vesuv.UserName", 
> "bla");
>                properties.put("Postgres.postgres.vesuv.Password", 
> "bla");
>   ....
>
> persistence.xml:
> <?xml version="1.0" encoding="UTF-8"?>
> <persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence 

> "
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
> xsi:schemaLocation="
> http://java.sun.com/xml/ns/persistence
> http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
>        <persistence-unit name="VesuvPU">
>                <description>Vesuv Application</description>
>
> <provider>org.apache.openjpa.persistence.PersistenceProviderImpl</ 
> provider>
>            <jta-data-source>Postgres.postgres.vesuv</jta-data-source>
>            <class>
> ...
>                <properties>
>                    <property name="openjpa.jdbc.SynchronizeMappings"
> value="false" />
>                <property name="openjpa.jdbc.Schema" value="vesuv" />
>                </properties>
>        </persistence-unit>
> </persistence>
>
>
> Lookup of the SessionBean works. Invoking the method is fine.
> SQL-Statements are done. But
>
> LOG:
> [DEBUG] [BenutzerManagerImpl] >> Mandant: Mandant:Vesuv 
> Servicestelle Id:1
> Kurzname: SS PersonFK:0 Tstaend:null
> 13:18:31,644 INFO  [Transaction] TX Required: Committing transaction
> org.apache.geronimo.transaction.manager.TransactionImpl@1579371
> 13:18:31,693 DEBUG [SQL] <t 15431769, conn 0> executing prepstmnt 
> 31310826
> UPDATE vesuv.v_org_einheit
> ...
> 13:18:31,702 DEBUG [SQL] <t 15431769, conn 0> [9 ms] spent
> 13:18:31,717 DEBUG [SQL] <t 15431769, conn 0> executing prepstmnt 
> 23410971
> UPDATE vesuv.benutzer SET
> ...
> ...
> Caused by: <openjpa-1.0.1-r420667:592145 nonfatal store error>
> org.apache.openjpa.util.StoreException: FEHLER: kann eine Sicht nicht
> aktualisieren {prepstmnt 31310826 UPDATE vesuv.v_org_einheit SET
> beziehung_org_einheit_typ = ?, kurz_name = ?, name = ?, 
> org_einheit_typ =
> ?, person_fk = ?, rechtsform = ?, tstaend = ?, 
> beziehung_org_einheit_fk =
> ?, uebergeordnete_org_einheit_fk = ? WHERE id = ? [params=(null) null,
> (String) SS, (String) Vesuv Servicestelle, (String) SS, (long) 1, 
> (String)
> SS, (Timestamp) 2008-05-26 10:10:43.96, (null) null, (null) null, 
> (long)
> 1]} [code=0, state=0A000]
> FailedObject:
> ...
>
> The LOG-File is in German, therefore some translation: Sicht = View. 
> The
> Update of the View-PAO does not work. Any suggestions ???
>
> Thanx Josef
> BGS Beratungsgesellschaft
> Software Systemplanung AG         Niederlassung Rhein/Main
> Robert-Koch-Straße 41
> 55129 Mainz
> Fon: +49 (0) 6131 / 914-0
> Fax: +49 (0) 6131 / 914-400
> www.bgs-ag.de Geschäftssitz Mainz
> Registergericht
> Amtsgericht Mainz
> HRB 62 50
>  Aufsichtsratsvorsitzender
> Dr. Wolfgang Trommer
> Vorstand
> Hanspeter Gau
> Hermann Kiefer
> Nils Manegold
> Heinz-Jörg Zimmermann
>



BGS Beratungsgesellschaft 
Software Systemplanung AG         Niederlassung Rhein/Main 
Robert-Koch-Straße 41 
55129 Mainz 
Fon: +49 (0) 6131 / 914-0 
Fax: +49 (0) 6131 / 914-400 
www.bgs-ag.de Geschäftssitz Mainz 
Registergericht 
Amtsgericht Mainz 
HRB 62 50 
  Aufsichtsratsvorsitzender 
Dr. Wolfgang Trommer 
Vorstand 
Hanspeter Gau 
Hermann Kiefer 
Nils Manegold 
Heinz-Jörg Zimmermann 


  

Re: Openejb 3.0 : JUNIT with embedded Container can't commit Transaction

Posted by David Blevins <da...@visi.com>.
Hi Josef,

Couple questions.  What Java version are you using?  Are you setting "- 
javaagent:<path-to>/openejb-javaagent-3.0.jar" as part of the test  
parameters?  (an openjpa specific requirement)

Also, try is adjusting your test setup to the following.

     public void setUp() throws Exception {
         Properties properties = new Properties();
         properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,  
"org.apache.openejb.client.LocalInitialContextFactory");
         properties.put("Postgres.postgres.vesuv", "new://Resource? 
type=DataSource");
         properties.put("Postgres.postgres.vesuv.JdbcDriver",  
"org.postgresql.Driver");
         properties.put("Postgres.postgres.vesuv.JdbcUrl",  
"jdbc:postgresql://localhost/bla");
         properties.put("Postgres.postgres.vesuv.UserName", "bla");
         properties.put("Postgres.postgres.vesuv.Password", "bla");
         ...
     }

I.e. with the OpenEJB home and openejb.conf file cut out.  We don't  
need the openejb.home for testing and 100% of the configuration we do  
need for testing can be supplied via the properties syntax you already  
have in your TestCase.  We use different "heavier" defaults (tx  
logging is enabled for example) if we determine we're running as a  
standalone server and setting an openejb.home to a directory  
containing a "conf/" directory is one way we determine that.

If you did want to declare your TransactionManager and SecurityService  
and more, you could do so in your test case as follows:

         properties.put("myTransactionManager", "new:// 
TransactionManager");
         properties.put("mySecurityService", "new://SecurityService");
         properties.put("myStatelessContainer", "new://Container? 
type=STATELESS");
         properties.put("myStatefulContainer", "new://Container? 
type=STATEFUL");

However we will automatically create all of these as needed so there's  
no reason to explicitly declare them unless you wish to override a  
value.

If you're comfortable posting your full log file output that can help  
too.

-David

On Jun 5, 2008, at 2:28 AM, Josef.Eisele@bgs-ag.de wrote:

> Hi All,
>
> great Idea to do unit-testing using the embedded functions of  
> openejb. So
> I tried...
>
> I have a JavaEE-5 application on Geronimo 2.1.1 with Postgres-DB.  
> (Driver
> postgresql-8.2-508.jdbc3.jar). In Geronimo I defined a database pool  
> with
> Pool-Type "TranQL XA Resource Adapter for PostgreSQL". I use Local  
> Session
> Beans in General. The Application works quite well.
>
> Thus I tried to do this with embedded openejb. After quite a few  
> problems
> to set up the system, my JUNIT-Test works up to a certain step. It  
> seems
> there is maybe an impact with the transaction - functionality. The
> transaction could not be comitted. I could imagine not the XA- 
> Datasource
> is taken, but who knows??
>
> openejb.conf:
> ...
>  <SecurityService id="Default Security Service"/>
>  <TransactionManager id="Default Transaction Manager"/>
> </openejb>
>
>
> JUNIT-Testcase:
>        public void setUp() throws Exception {
>                Properties properties = new Properties();
>                properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
> "org.apache.openejb.client.LocalInitialContextFactory");
>
>                properties.put("openejb.home",
> "/home/user/workspace/VesuvUnit/openejb");
>
>                properties.put("openejb.configuration",
>                  "/home/user/workspace/VesuvUnit/openejb/ 
> openejb.conf");
>
>                ....
>
>                properties.put("Postgres.postgres.vesuv",
> "new://Resource?type=DataSource");
>                properties.put("Postgres.postgres.vesuv.JdbcDriver",
> "org.postgresql.Driver");
>                properties.put("Postgres.postgres.vesuv.JdbcUrl",
> "jdbc:postgresql://localhost/bla");
>                properties.put("Postgres.postgres.vesuv.UserName",  
> "bla");
>                properties.put("Postgres.postgres.vesuv.Password",  
> "bla");
>   ....
>
> persistence.xml:
> <?xml version="1.0" encoding="UTF-8"?>
> <persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence 
> "
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
> xsi:schemaLocation="
> http://java.sun.com/xml/ns/persistence
> http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
>        <persistence-unit name="VesuvPU">
>                <description>Vesuv Application</description>
>
> <provider>org.apache.openjpa.persistence.PersistenceProviderImpl</ 
> provider>
>            <jta-data-source>Postgres.postgres.vesuv</jta-data-source>
>            <class>
> ...
>                <properties>
>                    <property name="openjpa.jdbc.SynchronizeMappings"
> value="false" />
>                <property name="openjpa.jdbc.Schema" value="vesuv" />
>                </properties>
>        </persistence-unit>
> </persistence>
>
>
> Lookup of the SessionBean works. Invoking the method is fine.
> SQL-Statements are done. But
>
> LOG:
> [DEBUG] [BenutzerManagerImpl] >> Mandant: Mandant:Vesuv  
> Servicestelle Id:1
> Kurzname: SS PersonFK:0 Tstaend:null
> 13:18:31,644 INFO  [Transaction] TX Required: Committing transaction
> org.apache.geronimo.transaction.manager.TransactionImpl@1579371
> 13:18:31,693 DEBUG [SQL] <t 15431769, conn 0> executing prepstmnt  
> 31310826
> UPDATE vesuv.v_org_einheit
> ...
> 13:18:31,702 DEBUG [SQL] <t 15431769, conn 0> [9 ms] spent
> 13:18:31,717 DEBUG [SQL] <t 15431769, conn 0> executing prepstmnt  
> 23410971
> UPDATE vesuv.benutzer SET
> ...
> ...
> Caused by: <openjpa-1.0.1-r420667:592145 nonfatal store error>
> org.apache.openjpa.util.StoreException: FEHLER: kann eine Sicht nicht
> aktualisieren {prepstmnt 31310826 UPDATE vesuv.v_org_einheit SET
> beziehung_org_einheit_typ = ?, kurz_name = ?, name = ?,  
> org_einheit_typ =
> ?, person_fk = ?, rechtsform = ?, tstaend = ?,  
> beziehung_org_einheit_fk =
> ?, uebergeordnete_org_einheit_fk = ? WHERE id = ? [params=(null) null,
> (String) SS, (String) Vesuv Servicestelle, (String) SS, (long) 1,  
> (String)
> SS, (Timestamp) 2008-05-26 10:10:43.96, (null) null, (null) null,  
> (long)
> 1]} [code=0, state=0A000]
> FailedObject:
> ...
>
> The LOG-File is in German, therefore some translation: Sicht = View.  
> The
> Update of the View-PAO does not work. Any suggestions ???
>
> Thanx Josef
> BGS Beratungsgesellschaft
> Software Systemplanung AG         Niederlassung Rhein/Main
> Robert-Koch-Straße 41
> 55129 Mainz
> Fon: +49 (0) 6131 / 914-0
> Fax: +49 (0) 6131 / 914-400
> www.bgs-ag.de Geschäftssitz Mainz
> Registergericht
> Amtsgericht Mainz
> HRB 62 50
>  Aufsichtsratsvorsitzender
> Dr. Wolfgang Trommer
> Vorstand
> Hanspeter Gau
> Hermann Kiefer
> Nils Manegold
> Heinz-Jörg Zimmermann
>


Openejb 3.0 : JUNIT with embedded Container can't commit Transaction

Posted by Jo...@bgs-ag.de.
Hi All,

great Idea to do unit-testing using the embedded functions of openejb. So 
I tried... 

I have a JavaEE-5 application on Geronimo 2.1.1 with Postgres-DB. (Driver 
postgresql-8.2-508.jdbc3.jar). In Geronimo I defined a database pool with 
Pool-Type "TranQL XA Resource Adapter for PostgreSQL". I use Local Session 
Beans in General. The Application works quite well.

Thus I tried to do this with embedded openejb. After quite a few problems 
to set up the system, my JUNIT-Test works up to a certain step. It seems 
there is maybe an impact with the transaction - functionality. The 
transaction could not be comitted. I could imagine not the XA-Datasource 
is taken, but who knows??

openejb.conf:
...
  <SecurityService id="Default Security Service"/>
  <TransactionManager id="Default Transaction Manager"/> 
</openejb>


JUNIT-Testcase:
        public void setUp() throws Exception {
                Properties properties = new Properties();
                properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
 "org.apache.openejb.client.LocalInitialContextFactory");
 
                properties.put("openejb.home", 
"/home/user/workspace/VesuvUnit/openejb");
 
                properties.put("openejb.configuration", 
                  "/home/user/workspace/VesuvUnit/openejb/openejb.conf");

                ....
 
                properties.put("Postgres.postgres.vesuv", 
"new://Resource?type=DataSource");
                properties.put("Postgres.postgres.vesuv.JdbcDriver", 
"org.postgresql.Driver");
                properties.put("Postgres.postgres.vesuv.JdbcUrl", 
"jdbc:postgresql://localhost/bla");
                properties.put("Postgres.postgres.vesuv.UserName", "bla");
                properties.put("Postgres.postgres.vesuv.Password", "bla");
   ....

persistence.xml:
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
http://java.sun.com/xml/ns/persistence 
http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
        <persistence-unit name="VesuvPU">
                <description>Vesuv Application</description>
 
<provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
            <jta-data-source>Postgres.postgres.vesuv</jta-data-source>
            <class>
...
                <properties>
                    <property name="openjpa.jdbc.SynchronizeMappings" 
value="false" />
                <property name="openjpa.jdbc.Schema" value="vesuv" />
                </properties>
        </persistence-unit>
</persistence>


Lookup of the SessionBean works. Invoking the method is fine. 
SQL-Statements are done. But 

LOG:
[DEBUG] [BenutzerManagerImpl] >> Mandant: Mandant:Vesuv Servicestelle Id:1 
Kurzname: SS PersonFK:0 Tstaend:null
13:18:31,644 INFO  [Transaction] TX Required: Committing transaction 
org.apache.geronimo.transaction.manager.TransactionImpl@1579371
13:18:31,693 DEBUG [SQL] <t 15431769, conn 0> executing prepstmnt 31310826 
UPDATE vesuv.v_org_einheit 
...
13:18:31,702 DEBUG [SQL] <t 15431769, conn 0> [9 ms] spent
13:18:31,717 DEBUG [SQL] <t 15431769, conn 0> executing prepstmnt 23410971 
UPDATE vesuv.benutzer SET 
...
...
Caused by: <openjpa-1.0.1-r420667:592145 nonfatal store error> 
org.apache.openjpa.util.StoreException: FEHLER: kann eine Sicht nicht 
aktualisieren {prepstmnt 31310826 UPDATE vesuv.v_org_einheit SET 
beziehung_org_einheit_typ = ?, kurz_name = ?, name = ?, org_einheit_typ = 
?, person_fk = ?, rechtsform = ?, tstaend = ?, beziehung_org_einheit_fk = 
?, uebergeordnete_org_einheit_fk = ? WHERE id = ? [params=(null) null, 
(String) SS, (String) Vesuv Servicestelle, (String) SS, (long) 1, (String) 
SS, (Timestamp) 2008-05-26 10:10:43.96, (null) null, (null) null, (long) 
1]} [code=0, state=0A000]
FailedObject: 
...

The LOG-File is in German, therefore some translation: Sicht = View. The 
Update of the View-PAO does not work. Any suggestions ??? 

Thanx Josef
BGS Beratungsgesellschaft 
Software Systemplanung AG         Niederlassung Rhein/Main 
Robert-Koch-Stra�e 41 
55129 Mainz 
Fon: +49 (0) 6131 / 914-0 
Fax: +49 (0) 6131 / 914-400 
www.bgs-ag.de Gesch�ftssitz Mainz 
Registergericht 
Amtsgericht Mainz 
HRB 62 50 
  Aufsichtsratsvorsitzender 
Dr. Wolfgang Trommer 
Vorstand 
Hanspeter Gau 
Hermann Kiefer 
Nils Manegold 
Heinz-J�rg Zimmermann 

  

Re: Antwort: EJB unit testing available

Posted by David Blevins <da...@visi.com>.
For those reading and future archive surfers... thread moved here:

http://www.nabble.com/Openejb-3.0-%3A-JUNIT-with-embedded-Container-can%27t-commit-Transaction-td17665820.html

On Jun 4, 2008, at 4:25 AM, Josef.Eisele@bgs-ag.de wrote:

>
> Hi David,
>
> great Idea to do unit-testing using the embedded functions of  
> openejb. So I tried...
>
> I have a JavaEE-5 application on Geronimo 2.1.1 with Postgres-DB.  
> (Driver postgresql-8.2-508.jdbc3.jar). In Geronimo I defined a  
> database pool with Pool-Type "TranQL XA Resource Adapter for  
> PostgreSQL". I use Local Sesscion Beans in General. The Application  
> works quite well.
>
> Thus I tried to do this with embedded openejb. After quite a few  
> problems to set up the system, my JUNIT-Test works up to a certain  
> step. It seems there is maybe an impact with the transaction -  
> functionality. The transaction could not be comitted. I could  
> imagine not the XA-Datasource is taken, but who knows??
>
> openejb.conf:
> ...
>   <SecurityService id="Default Security Service"/>
>   <TransactionManager id="Default Transaction Manager"/>
> </openejb>
>
>
> JUNIT-Testcase:
>         public void setUp() throws Exception {
>                 Properties properties = new Properties();
>                  
> properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
>                                  
> "org.apache.openejb.client.LocalInitialContextFactory");
>
>                 properties.put("openejb.home", "/home/user/workspace/ 
> VesuvUnit/openejb");
>
>                 properties.put("openejb.configuration",
>                   "/home/user/workspace/VesuvUnit/openejb/ 
> openejb.conf");
>
>                 ....
>
>                 properties.put("Postgres.postgres.vesuv", "new:// 
> Resource?type=DataSource");
>                 properties.put("Postgres.postgres.vesuv.JdbcDriver",  
> "org.postgresql.Driver");
>                 properties.put("Postgres.postgres.vesuv.JdbcUrl",  
> "jdbc:postgresql://localhost/bla");
>                 properties.put("Postgres.postgres.vesuv.UserName",  
> "bla");
>                 properties.put("Postgres.postgres.vesuv.Password",  
> "bla");
>    ....
>
> Lookup of the SessionBean works. Invoking the method is fine. SQL- 
> Statements are done. But
>
> LOG:
> [DEBUG] [BenutzerManagerImpl] >> Mandant: Mandant:Vesuv  
> Servicestelle Id:1 Kurzname: SS PersonFK:0 Tstaend:null
> 13:18:31,644 INFO  [Transaction] TX Required: Committing transaction  
> org.apache.geronimo.transaction.manager.TransactionImpl@1579371
> 13:18:31,693 DEBUG [SQL] <t 15431769, conn 0> executing prepstmnt  
> 31310826 UPDATE vesuv.v_org_einheit SET beziehung_org_einheit_typ  
> = ?, kurz_name = ?, name = ?, org_einheit_typ = ?, person_fk = ?,  
> rechtsform = ?, tstaend = ?, beziehung_org_einheit_fk = ?,  
> uebergeordnete_org_einheit_fk = ? WHERE id = ? [params=(null) null,  
> (String) SS, (String) Vesuv Servicestelle, (String) SS, (long) 1,  
> (String) SS, (Timestamp) 2008-05-26 10:10:43.96, (null) null, (null)  
> null, (long) 1]
> 13:18:31,702 DEBUG [SQL] <t 15431769, conn 0> [9 ms] spent
> 13:18:31,717 DEBUG [SQL] <t 15431769, conn 0> executing prepstmnt  
> 23410971 UPDATE vesuv.benutzer SET anzahl_anmeldeversuche = ?,  
> anzahl_anmeldungen = ?, benutzer_kennung = ?,  
> datum_letzte_passwort_aenderung = ?, email_anlage = ?, historie_fk  
> = ?, ist_gesperrt = ?, ist_gesperrt_seit = ?,  
> kostenbefreiung_online_auskunft = ?, letzte_benutzer_gruppe_fk = ?,  
> letzter_anmeldeversuch = ?, passwort_fehlversuche_zaehler = ?,  
> passwort_historie = ?, passwort_sha256hash = ?,  
> passwort_wechsel_erst_anmeldung = ?, person_info_fk = ?, sperrgrund  
> = ?, verknuepft_mit_fk = ?, zuletzt_angemeldet_am = ? WHERE id = ?  
> [params=(long) 0, (long) 0, (String) system, (Timestamp) 2008-05-26  
> 10:10:49.2, (boolean) false, (long) 3, (boolean) false, (Timestamp)  
> 2008-05-26 10:10:49.2, (boolean) false, (null) null, (Timestamp)  
> 2008-05-26 10:10:49.2, (long) 0, (String) keine Historie, (String)  
> 6ee4a469cd4e91053847f5d3fcb61dbcc91e8f0ef10be7748da4c4a1ba382d17,  
> (boolean) false, (long) 2, (String) keiner, (long) 0, (Timestamp)  
> 2008-05-26 10:10:49.2, (long) 8]
> 13:18:31,718 DEBUG [SQL] <t 15431769, conn 0> [1 ms] spent
> 13:18:31,719 DEBUG [SQL] <t 15431769, conn 0> executing prepstmnt  
> 8929602 UPDATE vesuv.v_gruppe_org_einheit SET gruppe_name = ?,  
> kurz_name = ?, name = ?, org_einheit_id = ?, org_einheit_typ = ?,  
> person_fk = ?, rechtsform = ? WHERE gruppe_id = ? [params=(String)  
> SystemManager, (String) SS, (String) Vesuv Servicestelle, (long) 1,  
> (String) SS, (long) 1, (String) SS, (long) 1]
> 13:18:31,721 DEBUG [SQL] <t 15431769, conn 0> [2 ms] spent
> 13:18:31,721 DEBUG [SQL] <t 15431769, conn 0> executing prepstmnt  
> 24403605 UPDATE vesuv.v_benutzer_gruppe SET  
> benutzer_gruppe_zuordnung_fk = ?, benutzer_kennung = ?, gruppe_name  
> = ? WHERE benutzer_gruppe_id = ? AND benutzer_id = ? [params=(long)  
> 1, (String) system, (String) SystemManager, (long) 1, (long) 8]
> 13:18:31,722 DEBUG [SQL] <t 15431769, conn 0> [1 ms] spent
> 13:18:31,737 DEBUG [Runtime] An exception occurred while ending the  
> transaction.  This exception will be re-thrown.
> <openjpa-1.0.1-r420667:592145 fatal store error>  
> org.apache.openjpa.util.StoreException: The transaction has been  
> rolled back.  See the nested exceptions for details on the errors  
> that occurred.
> ...
> Caused by: <openjpa-1.0.1-r420667:592145 nonfatal store error>  
> org.apache.openjpa.util.StoreException: FEHLER: kann eine Sicht  
> nicht aktualisieren {prepstmnt 31310826 UPDATE vesuv.v_org_einheit  
> SET beziehung_org_einheit_typ = ?, kurz_name = ?, name = ?,  
> org_einheit_typ = ?, person_fk = ?, rechtsform = ?, tstaend = ?,  
> beziehung_org_einheit_fk = ?, uebergeordnete_org_einheit_fk = ?  
> WHERE id = ? [params=(null) null, (String) SS, (String) Vesuv  
> Servicestelle, (String) SS, (long) 1, (String) SS, (Timestamp)  
> 2008-05-26 10:10:43.96, (null) null, (null) null, (long) 1]}  
> [code=0, state=0A000]
> FailedObject: org.apache.openjpa.enhance.de$nrw$hagen$ggrz$bv 
> $orgeinheit$db$VOrgEinheitPAO$pcsubclass- 
> de.nrw.hagen.ggrz.bv.orgeinheit.db.VOrgEinheitPAO-1
> ...
>
> The LOG-File is in German, therefore some translation: Sicht = View.  
> The Update of the View-PAO does not work. Any suggestions ???
>
> Thanx Josef
>
>
>
>
> David Blevins <da...@visi.com>
> 21.05.2008 05:12
> Bitte antworten an
> user@geronimo.apache.org
>
>
> An
> user@geronimo.apache.org
> Kopie
> Thema
> EJB unit testing available
>
>
>
>
>
> I just wanted to put this on everyone's radar in case it wasn't
> already known.  Those of you writing EJB applications run on Geronimo
> have an extra advantage that those applications can be easily unit
> tested by embedding the Geronimo EJB container (OpenEJB) into your
> test case.
>
> This sort of in-container unit testing technique is something we've
> been innovating for a while and is likely to be a major addition to
> the EJB 3.1 specifications.  I strongly encourage anyone doing EJB
> development to check this out.  There are a number of examples
> available here: http://openejb.apache.org/examples.html
>
> The net result of this is that you should be able to quickly unit test
> your ejbs in your build as you would test a plain java application.
> With good EJB unit tests you'll get much faster development, fewer
> build/deploy cycles, and be able to quickly catch basic deployment
> issues that stem from incorrect or non-compliant apps.
>
> -David
>
>
>
>
> BGS Beratungsgesellschaft
> Software Systemplanung AG
>
>
>
>
> Niederlassung Rhein/Main
> Robert-Koch-Straße 41
> 55129 Mainz
> Fon: +49 (0) 6131 / 914-0
> Fax: +49 (0) 6131 / 914-400
> www.bgs-ag.de
> Geschäftssitz Mainz
> Registergericht
> Amtsgericht Mainz
> HRB 62 50
>
> Aufsichtsratsvorsitzender
> Dr. Wolfgang Trommer
> Vorstand
> Hanspeter Gau
> Hermann Kiefer
> Nils Manegold
> Heinz-Jörg Zimmermann
>
>
>


Antwort: EJB unit testing available

Posted by Jo...@bgs-ag.de.
Hi David,

great Idea to do unit-testing using the embedded functions of openejb. So 
I tried... 

I have a JavaEE-5 application on Geronimo 2.1.1 with Postgres-DB. (Driver 
postgresql-8.2-508.jdbc3.jar). In Geronimo I defined a database pool with 
Pool-Type "TranQL XA Resource Adapter for PostgreSQL". I use Local 
Sesscion Beans in General. The Application works quite well.

Thus I tried to do this with embedded openejb. After quite a few problems 
to set up the system, my JUNIT-Test works up to a certain step. It seems 
there is maybe an impact with the transaction - functionality. The 
transaction could not be comitted. I could imagine not the XA-Datasource 
is taken, but who knows??

openejb.conf:
...
  <SecurityService id="Default Security Service"/>
  <TransactionManager id="Default Transaction Manager"/> 
</openejb>


JUNIT-Testcase:
        public void setUp() throws Exception {
                Properties properties = new Properties();
                properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
 "org.apache.openejb.client.LocalInitialContextFactory");
 
                properties.put("openejb.home", 
"/home/user/workspace/VesuvUnit/openejb");
 
                properties.put("openejb.configuration", 
                  "/home/user/workspace/VesuvUnit/openejb/openejb.conf");

                ....
 
                properties.put("Postgres.postgres.vesuv", 
"new://Resource?type=DataSource");
                properties.put("Postgres.postgres.vesuv.JdbcDriver", 
"org.postgresql.Driver");
                properties.put("Postgres.postgres.vesuv.JdbcUrl", 
"jdbc:postgresql://localhost/bla");
                properties.put("Postgres.postgres.vesuv.UserName", "bla");
                properties.put("Postgres.postgres.vesuv.Password", "bla");
   ....

Lookup of the SessionBean works. Invoking the method is fine. 
SQL-Statements are done. But 

LOG:
[DEBUG] [BenutzerManagerImpl] >> Mandant: Mandant:Vesuv Servicestelle Id:1 
Kurzname: SS PersonFK:0 Tstaend:null
13:18:31,644 INFO  [Transaction] TX Required: Committing transaction 
org.apache.geronimo.transaction.manager.TransactionImpl@1579371
13:18:31,693 DEBUG [SQL] <t 15431769, conn 0> executing prepstmnt 31310826 
UPDATE vesuv.v_org_einheit SET beziehung_org_einheit_typ = ?, kurz_name = 
?, name = ?, org_einheit_typ = ?, person_fk = ?, rechtsform = ?, tstaend = 
?, beziehung_org_einheit_fk = ?, uebergeordnete_org_einheit_fk = ? WHERE 
id = ? [params=(null) null, (String) SS, (String) Vesuv Servicestelle, 
(String) SS, (long) 1, (String) SS, (Timestamp) 2008-05-26 10:10:43.96, 
(null) null, (null) null, (long) 1]
13:18:31,702 DEBUG [SQL] <t 15431769, conn 0> [9 ms] spent
13:18:31,717 DEBUG [SQL] <t 15431769, conn 0> executing prepstmnt 23410971 
UPDATE vesuv.benutzer SET anzahl_anmeldeversuche = ?, anzahl_anmeldungen = 
?, benutzer_kennung = ?, datum_letzte_passwort_aenderung = ?, email_anlage 
= ?, historie_fk = ?, ist_gesperrt = ?, ist_gesperrt_seit = ?, 
kostenbefreiung_online_auskunft = ?, letzte_benutzer_gruppe_fk = ?, 
letzter_anmeldeversuch = ?, passwort_fehlversuche_zaehler = ?, 
passwort_historie = ?, passwort_sha256hash = ?, 
passwort_wechsel_erst_anmeldung = ?, person_info_fk = ?, sperrgrund = ?, 
verknuepft_mit_fk = ?, zuletzt_angemeldet_am = ? WHERE id = ? 
[params=(long) 0, (long) 0, (String) system, (Timestamp) 2008-05-26 
10:10:49.2, (boolean) false, (long) 3, (boolean) false, (Timestamp) 
2008-05-26 10:10:49.2, (boolean) false, (null) null, (Timestamp) 
2008-05-26 10:10:49.2, (long) 0, (String) keine Historie, (String) 
6ee4a469cd4e91053847f5d3fcb61dbcc91e8f0ef10be7748da4c4a1ba382d17, 
(boolean) false, (long) 2, (String) keiner, (long) 0, (Timestamp) 
2008-05-26 10:10:49.2, (long) 8]
13:18:31,718 DEBUG [SQL] <t 15431769, conn 0> [1 ms] spent
13:18:31,719 DEBUG [SQL] <t 15431769, conn 0> executing prepstmnt 8929602 
UPDATE vesuv.v_gruppe_org_einheit SET gruppe_name = ?, kurz_name = ?, name 
= ?, org_einheit_id = ?, org_einheit_typ = ?, person_fk = ?, rechtsform = 
? WHERE gruppe_id = ? [params=(String) SystemManager, (String) SS, 
(String) Vesuv Servicestelle, (long) 1, (String) SS, (long) 1, (String) 
SS, (long) 1]
13:18:31,721 DEBUG [SQL] <t 15431769, conn 0> [2 ms] spent
13:18:31,721 DEBUG [SQL] <t 15431769, conn 0> executing prepstmnt 24403605 
UPDATE vesuv.v_benutzer_gruppe SET benutzer_gruppe_zuordnung_fk = ?, 
benutzer_kennung = ?, gruppe_name = ? WHERE benutzer_gruppe_id = ? AND 
benutzer_id = ? [params=(long) 1, (String) system, (String) SystemManager, 
(long) 1, (long) 8]
13:18:31,722 DEBUG [SQL] <t 15431769, conn 0> [1 ms] spent
13:18:31,737 DEBUG [Runtime] An exception occurred while ending the 
transaction.  This exception will be re-thrown.
<openjpa-1.0.1-r420667:592145 fatal store error> 
org.apache.openjpa.util.StoreException: The transaction has been rolled 
back.  See the nested exceptions for details on the errors that occurred.
...
Caused by: <openjpa-1.0.1-r420667:592145 nonfatal store error> 
org.apache.openjpa.util.StoreException: FEHLER: kann eine Sicht nicht 
aktualisieren {prepstmnt 31310826 UPDATE vesuv.v_org_einheit SET 
beziehung_org_einheit_typ = ?, kurz_name = ?, name = ?, org_einheit_typ = 
?, person_fk = ?, rechtsform = ?, tstaend = ?, beziehung_org_einheit_fk = 
?, uebergeordnete_org_einheit_fk = ? WHERE id = ? [params=(null) null, 
(String) SS, (String) Vesuv Servicestelle, (String) SS, (long) 1, (String) 
SS, (Timestamp) 2008-05-26 10:10:43.96, (null) null, (null) null, (long) 
1]} [code=0, state=0A000]
FailedObject: 
org.apache.openjpa.enhance.de$nrw$hagen$ggrz$bv$orgeinheit$db$VOrgEinheitPAO$pcsubclass-de.nrw.hagen.ggrz.bv.orgeinheit.db.VOrgEinheitPAO-1
...

The LOG-File is in German, therefore some translation: Sicht = View. The 
Update of the View-PAO does not work. Any suggestions ??? 

Thanx Josef





David Blevins <da...@visi.com> 
21.05.2008 05:12
Bitte antworten an
user@geronimo.apache.org


An
user@geronimo.apache.org
Kopie

Thema
EJB unit testing available






I just wanted to put this on everyone's radar in case it wasn't 
already known.  Those of you writing EJB applications run on Geronimo 
have an extra advantage that those applications can be easily unit 
tested by embedding the Geronimo EJB container (OpenEJB) into your 
test case.

This sort of in-container unit testing technique is something we've 
been innovating for a while and is likely to be a major addition to 
the EJB 3.1 specifications.  I strongly encourage anyone doing EJB 
development to check this out.  There are a number of examples 
available here: http://openejb.apache.org/examples.html

The net result of this is that you should be able to quickly unit test 
your ejbs in your build as you would test a plain java application. 
With good EJB unit tests you'll get much faster development, fewer 
build/deploy cycles, and be able to quickly catch basic deployment 
issues that stem from incorrect or non-compliant apps.

-David





BGS Beratungsgesellschaft 
Software Systemplanung AG         Niederlassung Rhein/Main 
Robert-Koch-Stra�e 41 
55129 Mainz 
Fon: +49 (0) 6131 / 914-0 
Fax: +49 (0) 6131 / 914-400 
www.bgs-ag.de Gesch�ftssitz Mainz 
Registergericht 
Amtsgericht Mainz 
HRB 62 50 
  Aufsichtsratsvorsitzender 
Dr. Wolfgang Trommer 
Vorstand 
Hanspeter Gau 
Hermann Kiefer 
Nils Manegold 
Heinz-J�rg Zimmermann