Nabble - EclipseLink

Blaise:

I actually just stumbled upon the schema generation functionality.  I
will give that a try and see how far I get.

Thanks
Adam

Blaise Doughan wrote:

Hi Adam,

You are correct, the JAXB annotations will allow you to map the JPA
entity classes to XML.  This will require you only have one Java model.

You can generate an XML schema from annotated Java classes using the
generateSchema(SchemaOutputResolver) method on JAXBContext:

    * http://java.sun.com/javase/6/docs/api/javax/xml/bind/JAXBContext.html#generateSchema(javax.xml.bind.SchemaOutputResolver)

Using EclipseLink 2.0 JAXB you will also be able to:

    * Map bidirectional relationships using @XmlInverseReferece
    * Use composite keys in key based XML relationships
    * Map JPA entites with embedded key classes
    * Use the @XmlID annotation on non-String fields and Properties

-Blaise

Adam Stroud wrote:

Blaise:

Thanks for the reply.  I have not come across any issues yet as I have
just started development.  I am developing a RESTful web service that
will receive XML that will need to be mapped to JPA entities that will
be persisted.  My initial thought was to create an XSD to define the web
service traffic, and run JAXB over this to create Java classes.  I would
then define the entities to be persisted and manually write the code to
convert the XML to the entities.  This just didnt feel right so I
started to see if there was a better way.  It seems that the JAXB
annotations might be what I am looking for.  From what I have seen thus
far, I will be able to both marshal and unmarshal the XML into my
entities.  The only feature I would still like to have is the XSD.  It
does not look like I can generate an XSD from JAXB annotated classes.
So, if I want the XSD it looks like I need to maintain multiple models.
 Any other ideas?

Thanks
Adam

Blaise Doughan wrote:

Hi Adam,

My apologies for not getting back to the thread.  If you let me know the
issues you are encountering I will help you out.

You should be able to do this in one model.  Below is a link to an
example I am working on to do just what you are describing with the
EclipseLink 2.0 APIs:

    * http://wiki.eclipse.org/EclipseLink/Examples/MOXy/JPA

It is still a work in progress, some other things you will find useful:

    * /*Bidirectional Relationship Support*/
      Today we will be checking in an XMLInvereseReferenceMapping, this
      mapping will allow you map back pointers.
    * /*Composite Key Support*/
      EclipseLink 2.0 now supports composite keys on all the key based
      mappings.  I still need to update the example with this.

-Blaise

Adam Stroud wrote:

All:

I am developing an application that uses Eclipselink both JAXB (Moxy)
and JPA.  My question is what is the best way to go from my current
data model to entities and XML without maintaining three different
models.  I saw an earlier post to the mailing list here ->
http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg03473.html,
but it does not look like the examples referenced in the reply were
posted to the list.  Any input/guidance would be appreciated.

Thanks
Adam
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

Hi Gordon,

If the proposal includes a plan to introduce <name>.dir for every single jar file, then there are no substantial differences between these 2 options.

Thanks,
Edwin

-----Original Message-----
From: Gordon Yorke 
Sent: Friday, November 27, 2009 9:34 AM
To: Dev mailing list for Eclipse Persistence Services
Subject: Re: [eclipselink-dev] Expanding 'standards' for build files.

I prefer Eric's proposal for <name>.jar, <name>.lib and <name>.dir
--Gordon

Edwin Tang wrote:

Hi Eric,

This is great initiative.

Probably, instead of <name>.jar, <name>.lib and <name>.path, it could better that we have
<name>.dir: the location of a jar file
<name>.lib: a jar file name
<name>.path: a path element defined by <pathelement path="${<name>.dir}/${<name>.lib}"/>

The benifits of this option are:
1. Users have full flexibility to able to customize <name>.dir, <name>.lib, or both for every single jar file
2. Avoid the difficulty to choose a sound property name - <name>.jar or <name>.jarfile
3. Be consistent with the TopLink test/build naming conventions

Thanks,
Edwin

-----Original Message-----
From: Eric Gwin 
Sent: Thursday, November 26, 2009 8:06 AM
To: Dev mailing list for Eclipse Persistence Services
Subject: [eclipselink-dev] Expanding 'standards' for build files.

Hi,

I'm sending this out as a notification/proposal of some additional 
standard conventions I plan on adding to our build files after the branch.
     - properties ending in .jar define jarfile names only (no path)
     - properties ending in .lib are fully qualified jars (path and 
filename)
     - properties ending in .dir are directory paths
     - properties ending in .path are path refid names (classpath fragments)
     - targets beginning with test- are reserved for high level test 
targets,
       and are used in test results parsing
     - targets typically use the form <action>-<object>-<type> (ie. 
package-bundle-zip)

Some are clarifications of standards already in place, but not well 
publicized. However, with regard to .jar/.lib and .dir/.path there is no 
current standard, and properties are named and used in a fairly random 
mostly interchangeable way. There are many reasons this is becoming an 
issue now, but here are the biggest:
     - bugs requesting the use of minimal classpaths necessitate the 
need to individually
       define libraries. However, the build has multiple entry points so 
paths to those
       libraries are relative to the entry point. So the need to 
separate path from jar name.
     - adding individual libraries (rather than eclipselink.core.depend 
or eclipslink.oracle.depend
        which list them all) also creates a need to separately define 
directories and classpath subsets.

For the most part I've tried to keep the usage most prevalent for each 
postfix
 -.lib was mostly used to define full paths to jars, while .jar mostly 
defined jar names. However,
   there are also a few non-conformant properties (eclipselink.jar.name 
and .jarfile)
 -.dir really hasn't changed at all, but there were a few uses where it 
was a defining a pathref
 -.path is pretty much new old pathrefs were either .dir or .classpath

While I needed to implement these changes for the oracle modules for 
critical fixes in 2.0.0, I plan on implementing these changes across the 
board  after the branch and discussion has occurred.

Does anyone object to these standards, or have preferences other than 
what I plan to implement? I can see .jarfile being used as the standard 
postfix because the property can't easily be confused with a static 
usage of a jar, but it wasn't routinely used.

Comments? (If I hear nothing from you I will assume it is assent, and 
continue as outlined after the branch is complete.)

-Eric
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

Hi Yiping,

We did find the test error on other servers, but we haven't had time to fix it yet.

hm, this explains why we could not understand how the tests could pass on a different server :-)

Actually, the fix you are proposing does not work on NetWeaver either:

    /*
     * createNativeQuery(string) feature test
     *   tests that Query with Select SQL can be executed using getResultList() after it
     *   has run using executeUpdate()
     */
    public void testcreateNativeQueryWithSelectSQL() throws Exception {
        EntityManager em = createEntityManager();
        try{
            beginTransaction(em);
            Query query1 = em.createNativeQuery("Select * FROM CMP3_CUSTOMER");
            Query query2 = em.createNativeQuery("INSERT INTO CMP3_CUSTOMER (CUST_ID, NAME, CITY, CUST_VERSION) VALUES (1111, NULL, NULL, 1)");
            Query query3 = em.createNativeQuery("DELETE FROM CMP3_CUSTOMER WHERE (CUST_ID=1111)");

            Collection c1 = query1.getResultList();
            assertTrue("getResultList returned null ",c1!=null );

            // this may fail with some drivers
            int result = 0;
            try {
                result = query1.executeUpdate();
            } catch (RuntimeException ex) {
                rollbackTransaction(em);
                closeEntityManager(em);
                em = createEntityManager();
                beginTransaction(em);
            }

            query2.executeUpdate();  <----------

Query2 is still associated with the entity manager closed by the rollback.

Actually, I think the issue is the rollback in the catch block. We can just do without it:

    /*
     * createNativeQuery(string) feature test
     *   tests that Query with Select SQL can be executed using getResultList() after it
     *   has run using executeUpdate()
     */
    public void testcreateNativeQueryWithSelectSQL() throws Exception {
        EntityManager em = createEntityManager();
        try{
            beginTransaction(em);
            Query query1 = em.createNativeQuery("Select * FROM CMP3_CUSTOMER");
            Query query2 = em.createNativeQuery("INSERT INTO CMP3_CUSTOMER (CUST_ID, NAME, CITY, CUST_VERSION) VALUES (1111, NULL, NULL, 1)");
            Query query3 = em.createNativeQuery("DELETE FROM CMP3_CUSTOMER WHERE (CUST_ID=1111)");

            Collection c1 = query1.getResultList();
            assertTrue("getResultList returned null ",c1!=null );

            int result = 0;
            try {
                result = query1.executeUpdate();
            } catch (RuntimeException ex) {
                // this may fail with some drivers
            	assertTrue("transaction has been rolled back", isTransactionActive(em));
            }

            query2.executeUpdate();

In any case, I am opening a ticket for this issue:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=296340

-Adrian

---
Adrian Görler
SAP AG

Pflichtangaben/Mandatory Disclosure Statements: http://www.sap.com/company/legal/impressum.epx

-----Ursprüngliche Nachricht-----
Von: eclipselink-dev-bounces@... [eclipselink-dev-bounces@...] Im Auftrag von yiping zhao
Gesendet: Donnerstag, 26. November 2009 16:50
An: tom Ware
Cc: Dev mailing list for Eclipse Persistence Services
Betreff: Re: [eclipselink-dev] Error in EMQueryJUnitTestSuite.testcreateNativeQueryWithSelectSQL on SAP NetWeaver

Hi Tom,

We did find the test error on other servers, but we haven't had time to 
fix it yet. so the testcase needs to be fixed like:

// this may fail with some drivers
            int result = 0;
            try {
                result = query1.executeUpdate();
            } catch (RuntimeException ex) {
                rollbackTransaction(em);
                closeEntityManager(em);
                em = createEntityManager();
                beginTransaction(em);
            }

Yiping

On 11/26/2009 10:10 AM, Tom Ware wrote:

If the entity manager is transaction scoped, I think Sabine is right.  
The entity manager should be closed when the transaction either 
commits or rolls back.  I wonder why that is not happening on other 
servers.  (you'll notice query1.executeUpdate() is designed to fail)

-Tom

yiping zhao wrote:

Hi Sabine,

In the test framework, by default the entity manager is injected in 
sessionbean, it's transaction-scoped.

 >From the stacktrace, it looks like that there is issue when 
executing "result = query1.executeUpdate();", then somehow your SAP 
NetWeaver application server closes the entity manager, after that 
you get the exception "java.lang.IllegalStateException: Attempting to 
execute an operation on a closed EntityManager" when executing 
"query2.executeUpdate();", so this sounds like a server issue.

Yiping

On 11/26/2009 4:34 AM, Heider, Sabine wrote:

Hi Tom,

I'm not really familiar with the details of test framework either, 
but I guess the entity manager is taken from the TestRunnerBean:

@Stateless(name="TestRunner", mappedName="TestRunner")
@Remote(TestRunner.class)
@TransactionManagement(TransactionManagementType.BEAN)
public class TestRunnerBean implements TestRunner {
        /** The entity manager for the test is injected and passed 
to the test server platform. */
    @PersistenceContext
    private EntityManager entityManager;

    /** The entity manager factory for the test is injected and 
passed to the test server platform. */
    @PersistenceUnit
    private EntityManagerFactory entityManagerFactory;

So yes, it is transaction-scoped.
Best regards,
Sabine

-----Original Message-----
From: eclipselink-dev-bounces@... 
[eclipselink-dev-bounces@...] On Behalf Of Tom Ware
Sent: Mittwoch, 25. November 2009 14:07
To: Dev mailing list for Eclipse Persistence Services
Subject: Re: [eclipselink-dev] Error in 
EMQueryJUnitTestSuite.testcreateNativeQueryWithSelectSQL on SAP 
NetWeaver

Hi Sabine,

   I am not familiar with how the entity manager for the tests are 
created.  The part of the spec you are referring to is for 
Transaction-scoped entity managers.   Is the entity manager used in 
this test created in such a way that it will be transaction-scoped 
on all servers?

-Tom

Heider, Sabine wrote:

Hi,

I'd like to get your opinion on an error I get when running the JPA 
server tests inside an SAP NetWeaver application server (stack 
shortened, executed on current trunk):

java.lang.IllegalStateException: Attempting to execute an operation 
on a closed EntityManager.
at 
org.eclipse.persistence.internal.jpa.EntityManagerImpl.verifyOpen(EntityManagerImpl.java:1516) 

at 
org.eclipse.persistence.internal.jpa.EJBQueryImpl.executeUpdate(EJBQueryImpl.java:492) 

at 
org.eclipse.persistence.testing.tests.jpa.relationships.EMQueryJUnitTestSuite.testcreateNativeQueryWithSelectSQL(EMQueryJUnitTestSuite.java:121) 

at 
org.eclipse.persistence.testing.framework.junit.JUnitTestCase.runBareServer(JUnitTestCase.java:463) 

at 
org.eclipse.persistence.testing.framework.server.TestRunnerBean.runTest(TestRunnerBean.java:87) 

I run the test against a MySQL database. The MySQL driver throws an 
SQLException in EMQueryJUnitTestSuite line 114: Can not issue 
executeUpdate() for SELECTs.
Consequently, I end up in the catch block where the current 
transaction is rolled back.

Chapter 7.9.1 of the JPA specification says:
"After the JTA transaction has completed (either by transaction 
commit or rollback), The container
closes the entity manager by calling EntityManager.close."

Apparently, this is what the JPA container in NetWeaver does. With 
the closed entity manager, however, query2 becomes unusable.

In my opinion, it's an error of the test rather than of the JPA 
container, but I might be wrong. What do you think?

Thanks and best regards,
Sabine

*Sabine Heider
**SAP AG

*Pflichtangaben/Mandatory Disclosure Statements:
_http://www.sap.com/company/legal/impressum.epx_

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

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

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

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

Blaise:

Thanks for the reply.  I have not come across any issues yet as I have
just started development.  I am developing a RESTful web service that
will receive XML that will need to be mapped to JPA entities that will
be persisted.  My initial thought was to create an XSD to define the web
service traffic, and run JAXB over this to create Java classes.  I would
then define the entities to be persisted and manually write the code to
convert the XML to the entities.  This just didnt feel right so I
started to see if there was a better way.  It seems that the JAXB
annotations might be what I am looking for.  From what I have seen thus
far, I will be able to both marshal and unmarshal the XML into my
entities.  The only feature I would still like to have is the XSD.  It
does not look like I can generate an XSD from JAXB annotated classes.
So, if I want the XSD it looks like I need to maintain multiple models.
 Any other ideas?

Thanks
Adam

Blaise Doughan wrote:

Hi Adam,

My apologies for not getting back to the thread.  If you let me know the
issues you are encountering I will help you out.

You should be able to do this in one model.  Below is a link to an
example I am working on to do just what you are describing with the
EclipseLink 2.0 APIs:

    * http://wiki.eclipse.org/EclipseLink/Examples/MOXy/JPA

It is still a work in progress, some other things you will find useful:

    * /*Bidirectional Relationship Support*/
      Today we will be checking in an XMLInvereseReferenceMapping, this
      mapping will allow you map back pointers.
    * /*Composite Key Support*/
      EclipseLink 2.0 now supports composite keys on all the key based
      mappings.  I still need to update the example with this.

-Blaise

Adam Stroud wrote:

All:

I am developing an application that uses Eclipselink both JAXB (Moxy)
and JPA.  My question is what is the best way to go from my current
data model to entities and XML without maintaining three different
models.  I saw an earlier post to the mailing list here ->
http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg03473.html,
but it does not look like the examples referenced in the reply were
posted to the list.  Any input/guidance would be appreciated.

Thanks
Adam
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

Hi Tom,

I'm not really familiar with the details of test framework either, but I guess the entity manager is taken from the TestRunnerBean:

@Stateless(name="TestRunner", mappedName="TestRunner")
@Remote(TestRunner.class)
@TransactionManagement(TransactionManagementType.BEAN)
public class TestRunnerBean implements TestRunner {

    /** The entity manager for the test is injected and passed to the test server platform. */
    @PersistenceContext
    private EntityManager entityManager;

    /** The entity manager factory for the test is injected and passed to the test server platform. */
    @PersistenceUnit
    private EntityManagerFactory entityManagerFactory;

So yes, it is transaction-scoped. 

Best regards,
Sabine

-----Original Message-----
From: eclipselink-dev-bounces@... [eclipselink-dev-bounces@...] On Behalf Of Tom Ware
Sent: Mittwoch, 25. November 2009 14:07
To: Dev mailing list for Eclipse Persistence Services
Subject: Re: [eclipselink-dev] Error in EMQueryJUnitTestSuite.testcreateNativeQueryWithSelectSQL on SAP NetWeaver

Hi Sabine,

   I am not familiar with how the entity manager for the tests are created.  The 
part of the spec you are referring to is for Transaction-scoped entity managers. 
  Is the entity manager used in this test created in such a way that it will be 
transaction-scoped on all servers?

-Tom

Heider, Sabine wrote:

Hi,

I'd like to get your opinion on an error I get when running the JPA 
server tests inside an SAP NetWeaver application server (stack 
shortened, executed on current trunk):

java.lang.IllegalStateException: Attempting to execute an operation on a 
closed EntityManager.
at 
org.eclipse.persistence.internal.jpa.EntityManagerImpl.verifyOpen(EntityManagerImpl.java:1516)
at 
org.eclipse.persistence.internal.jpa.EJBQueryImpl.executeUpdate(EJBQueryImpl.java:492)
at 
org.eclipse.persistence.testing.tests.jpa.relationships.EMQueryJUnitTestSuite.testcreateNativeQueryWithSelectSQL(EMQueryJUnitTestSuite.java:121)
at 
org.eclipse.persistence.testing.framework.junit.JUnitTestCase.runBareServer(JUnitTestCase.java:463)
at 
org.eclipse.persistence.testing.framework.server.TestRunnerBean.runTest(TestRunnerBean.java:87)

I run the test against a MySQL database. The MySQL driver throws an 
SQLException in EMQueryJUnitTestSuite line 114: Can not issue 
executeUpdate() for SELECTs.
Consequently, I end up in the catch block where the current transaction 
is rolled back.

Chapter 7.9.1 of the JPA specification says:
"After the JTA transaction has completed (either by transaction commit 
or rollback), The container
closes the entity manager by calling EntityManager.close."

Apparently, this is what the JPA container in NetWeaver does. With the 
closed entity manager, however, query2 becomes unusable.

In my opinion, it's an error of the test rather than of the JPA 
container, but I might be wrong. What do you think?

Thanks and best regards,
Sabine

*Sabine Heider
**SAP AG

*Pflichtangaben/Mandatory Disclosure Statements:
_http://www.sap.com/company/legal/impressum.epx_

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

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

Nabble - EclipseLink

Check in Bug 269561 - jpa/customfeatures model failed with "org.eclipse.persistence.exceptions.ConversionException" on WebSphere 7.0.0.1

Re: multible fetch joins

Please Read - 2.0.0 RC Build today.

RE: Expanding 'standards' for build files.

bug 294044

Re: Expanding 'standards' for build files.

Re: Expanding 'standards' for build files.

Re: Moxy & JPA with Eclipselink

Re: Moxy & JPA with Eclipselink

Re: Moxy & JPA with Eclipselink

Re: Expanding 'standards' for build files.

Re: AW: Error in EMQueryJUnitTestSuite.testcreateNativeQueryWithSelectSQL on SAP NetWeaver

RE: Expanding 'standards' for build files.

AW: Error in EMQueryJUnitTestSuite.testcreateNativeQueryWithSelectSQL on SAP NetWeaver

Re: Expanding 'standards' for build files.

RE: Expanding 'standards' for build files.

Re: Moxy & JPA with Eclipselink

Re: multible fetch joins

Re: Discriminator and Inheritance.strategy

Re: Discriminator and Inheritance.strategy

Re: Discriminator and Inheritance.strategy

Use an entity as a discriminator column

Re: Discriminator and Inheritance.strategy

multible fetch joins

Discriminator and Inheritance.strategy

Re: Moxy & JPA with Eclipselink

Check in for Bug 296010 Getting nullpointer during starting of javax.persistence

EclipseLink 2.1.0 Feature Planning

EclipseLink 2.1.0 Feature Planning

BUILD STATUS:: trunk cb build has test failures!

Re: Error in EMQueryJUnitTestSuite.testcreateNativeQueryWithSelectSQL on SAP NetWeaver

Re: Error in EMQueryJUnitTestSuite.testcreateNativeQueryWithSelectSQL on SAP NetWeaver

Re: Error in EMQueryJUnitTestSuite.testcreateNativeQueryWithSelectSQL on SAP NetWeaver

Re: concat function within constructor expression fails

Expanding 'standards' for build files.