Nabble - Eclipse Technology

RE: Test EntityManagerJUnitTestSuite.testSetRollbackOnly on NetWeaver: Problem with JTA/non-JTA data sources

2009-12-08T00:57:28Z

Hi,

does anyone have an opinion on the error described below?

I’m under the impression that EclipseLink behaves incorrectly in this situation, but it could also be that there is a problem with our application server that I would have to follow on.

Thanks and best regards,

Sabine

From: eclipselink-dev-bounces@... [mailto:eclipselink-dev-bounces@...] On Behalf Of Heider, Sabine
Sent: Dienstag, 1. Dezember 2009 12:39
To: Dev mailing list for Eclipse Persistence Services
Subject: [eclipselink-dev] Test EntityManagerJUnitTestSuite.testSetRollbackOnly on NetWeaver: Problem with JTA/non-JTA data sources

Hi all,

when running on the NetWeaver server, the test EntityManagerJUnitTestSuite.testSetRollbackOnly fails with the following assertion error:

junit.framework.AssertionFailedError: eName was 'testRefreshRemoved' but expected '1259661366483'

at junit.framework.Assert.fail(Assert.java:47)

at junit.framework.Assert.assertTrue(Assert.java:20)

at org.eclipse.persistence.testing.tests.jpa.advanced.EntityManagerJUnitTestSuite.testSetRollbackOnly(EntityManagerJUnitTestSuite.java:994)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)

at junit.framework.TestCase.runTest(TestCase.java:168)

at junit.framework.TestCase.runBare(TestCase.java:134)

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

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

What the test basically does is that it executes the following steps inside a single JTA transaction:

update some test data and flush the changes to the database
provoke an OptimisticLockException so that the current transaction is marked for rollback
read the test data updated in step 1) and assert that the changes are there

Step 3) fails on NetWeaver – the query can still be executed but it returns the unmodified (i.e. committed) data.

I did some debugging and found out that step 1) uses the data source from PersistenceUnitInfo. getJtaDataSource(), while in step 3) the data source is obtained from PersistenceUnitInfo. getNonJtaDataSource(). Thus we ended up with two different connections, and as transaction isolation TRANSACTION_READ_COMMITTED is used we don’t see the uncommitted changes from the flush operation before.

It seems wrong to me that EclipseLink uses the non-JTA data source in that situation, but I’m unable to decide whether it is a general problem or rather caused by some peculiarity of our server. What happens on different application servers?

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

From forum: EclipseLink - Dev

AW: EntityManagerJUnitTestSuite.testLockWithJoinedInheritanceStrategy:NPE

2009-12-08T00:40:17Z

Hi Andrei,

the fix fixes the issue I observed.

Thanks a lot!

-Adrian

=======

Adrian Görler
SAP AG

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

-----Ursprüngliche Nachricht-----
Von: Andrei Ilitchev [mailto:andrei.ilitchev@...]
Gesendet: Montag, 7. Dezember 2009 23:29
An: Goerler, Adrian
Cc: Dev mailing list for Eclipse Persistence Services
Betreff: Re: [eclipselink-dev]EntityManagerJUnitTestSuite.testLockWithJoinedInheritanceStrategy:NPE

Hi Adrian,

I apologize for the delay.

I still don't understand why (and if) the password becomes corrupted.

Could you please try applying the patch in Bug 297137 - Passing the same
user/password to both createEMF and createEM causes EM to open new
connection
https://bugs.eclipse.org/bugs/show_bug.cgi?id=297137

Thanks,

Andrei
----- Original Message -----
From: "Goerler, Adrian" <adrian.goerler@...>
To: "Andrei Ilitchev" <andrei.ilitchev@...>
Cc: "Dev mailing list for Eclipse Persistence Services"
<eclipselink-dev@...>
Sent: Wednesday, December 02, 2009 3:05 AM
Subject: AW:
[eclipselink-dev]EntityManagerJUnitTestSuite.testLockWithJoinedInheritanceStrategy:NPE

Hi Andrei,

I was a bit short in my explanation:

testEMCloseAndOpen and testEMFactoryCloseAndOpen use the DriverWrapper. The
DriverWrapper seems to be a JDBC driver that registers with the
java.sql.DriverManager. It accepts just the same URLs as the MySQL Driver
but is chained after the MySQL driver.

testEMCloseAndOpen and testEMFactoryCloseAndOpen reset the DriverWrapper
after usage setting the driverName of the wrapped driver to null.

In testLockWithJoinedInheritanceStrategy it is attempted to create a
connection. But for the some reason, the password encoding is broken and it
is attempted to connect to the MySQL driver using an encoded password, which
fails with an SQLException. Now the java.sql.DriverManager tries the next
driver registered (the DriverWrapper), which throws the NPE as the
driverName is null.

If I do not run testEMCloseAndOpen and testEMFactoryCloseAndOpen but only
testNoPersistOnFlushProperties and testLockWithJoinedInheritanceStrategy, I
don't get the NPE in the driver wrapper but only the causing SQL Exception:

Internal Exception: java.sql.SQLException: Access denied for user
'me'@'localhost' (using password: YES)
Error Code: 1045
at
org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:324)
at
org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:319)
at
org.eclipse.persistence.sessions.DefaultConnector.connect(DefaultConnector.java:138)
at
org.eclipse.persistence.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:162)
at
org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.connectInternal(DatasourceAccessor.java:327)
at
org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.connectInternal(DatabaseAccessor.java:294)
at
org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.connect(DatasourceAccessor.java:415)
at
org.eclipse.persistence.sessions.server.ConnectionPool.buildConnection(ConnectionPool.java:155)
at
org.eclipse.persistence.sessions.server.ConnectionPool.acquireConnection(ConnectionPool.java:97)
at
org.eclipse.persistence.sessions.server.ServerSession.acquireClientConnection(ServerSession.java:241)
at
org.eclipse.persistence.sessions.server.ClientSession.basicBeginTransaction(ClientSession.java:130)
at
org.eclipse.persistence.internal.sessions.AbstractSession.beginTransaction(AbstractSession.java:580)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.beginTransaction(UnitOfWorkImpl.java:546)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabase(UnitOfWorkImpl.java:1346)
at
org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.commitToDatabase(RepeatableWriteUnitOfWork.java:547)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabaseWithChangeSet(UnitOfWorkImpl.java:1510)
at
org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.commitRootUnitOfWork(RepeatableWriteUnitOfWork.java:200)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitAndResume(UnitOfWorkImpl.java:1131)
at
org.eclipse.persistence.internal.jpa.transaction.EntityTransactionImpl.commitInternal(EntityTransactionImpl.java:84)
at
org.eclipse.persistence.internal.jpa.transaction.EntityTransactionImpl.commit(EntityTransactionImpl.java:63)
at
org.eclipse.persistence.testing.framework.junit.JUnitTestCase.commitTransaction(JUnitTestCase.java:267)
at
org.eclipse.persistence.testing.tests.jpa.advanced.EntityManagerJUnitTestSuite.testLockWithJoinedInheritanceStrategy(EntityManagerJUnitTestSuite.java:1919)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at
org.eclipse.persistence.testing.framework.junit.JUnitTestCase.runBare(JUnitTestCase.java:428)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.sql.SQLException: Access denied for user 'me'@'localhost'
(using password: YES)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1055)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3536)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3468)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:917)
at com.mysql.jdbc.MysqlIO.secureAuth411(MysqlIO.java:3974)
at com.mysql.jdbc.MysqlIO.doHandshake(MysqlIO.java:1282)
at
com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2142)
at com.mysql.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:773)
at com.mysql.jdbc.JDBC4Connection.<init>(JDBC4Connection.java:46)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:406)
at
com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:352)
at
com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:282)
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:154)
<----- this is atempted with the wrong password
at
org.eclipse.persistence.sessions.DefaultConnector.connect(DefaultConnector.java:98)
... 38 more

So, strictly speaking it is not a repro for the NPE but for the cause of the
NPE. Strange that it is working on your side. Sabine is observing the same
issue.

Best regards,

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@...
[mailto:eclipselink-dev-bounces@...] Im Auftrag von Andrei Ilitchev
Gesendet: Dienstag, 1. Dezember 2009 18:00
An: Dev mailing list for Eclipse Persistence Services
Betreff: Re:
[eclipselink-dev]EntityManagerJUnitTestSuite.testLockWithJoinedInheritanceStrategy:
NPE

Hi Adrian,

DriverWrapper class that appears on the stack is a test helper class that
currently used only in two EntitymanagerJUnitTsetSuite tests:
testEMCloseAndOpen and testEMFactoryCloseAndOpen.

These two tests use DriverWrapper to simulate dropped connections:
HashMap properties = new
HashMap(JUnitTestCaseHelper.getDatabaseProperties());
properties.put(PersistenceUnitProperties.JDBC_DRIVER,
DriverWrapper.class.getName());
properties.put(PersistenceUnitProperties.JDBC_URL,
DriverWrapper.codeUrl(originalConnectionString));
getEntityManagerFactory(properties);

I can't explain how DriverWrapper would show up when none of these two tests
have run (your reproducing the problem with just two tests).

However if one or both these tests have run before,
it is possible that the JDBC_DRIVER and JDBC_URL they provided are still
used by the factory
(though each of the two tests supposed to clean up after themselves).

You could comment out testEMCloseAndOpen and testEMFactoryCloseAndOpen -
that should remove any usage of DriverWrapper.

But to get to the bottom of it we need to figure out why the factory (or the
server session owned by the factory) is not properly cleaned up of
DriverWrapper.

I can't reproduce the problem so far.

Thanks,

Andrei

----- Original Message -----
From: "Goerler, Adrian" <adrian.goerler@...>
To: "tom Ware" <tom.ware@...>
Cc: "Dev mailing list for Eclipse Persistence Services"
<eclipselink-dev@...>
Sent: Tuesday, December 01, 2009 11:26 AM
Subject: AW:
[eclipselink-dev]EntityManagerJUnitTestSuite.testLockWithJoinedInheritanceStrategy:
NPE

Hi Tom, all,

I have correctly set the driver name in test.properties.

The issue is something different. This is what I have found out so far:

EntityManagerJUnitTestSuite.testLockWithJoinedInheritanceStrategy is the
only test failing for me.

I can reproduce the issue by reducing the testsuite as follows:

public static Test suite() {
TestSuite suite = new TestSuite();
suite.setName("EntityManagerJUnitTestSuite");

suite.addTest(new
EntityManagerJUnitTestSuite("testNoPersistOnFlushProperties"));

suite.addTest(new
EntityManagerJUnitTestSuite("testLockWithJoinedInheritanceStrategy"));

return suite;
}

It appears that the database passwords are kept in some encrypted form and
that the test "testNoPersistOnFlushProperties" confuses the encryption
somehow.

"testLockWithJoinedInheritanceStrategy" then fails to create a connection as
it attempts to use an encrypted password to connect.

Anyone any idea on this?

-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@...
[mailto:eclipselink-dev-bounces@...] Im Auftrag von Tom Ware
Gesendet: Dienstag, 1. Dezember 2009 15:14
An: Dev mailing list for Eclipse Persistence Services
Betreff: Re: [eclipselink-dev]
EntityManagerJUnitTestSuite.testLockWithJoinedInheritanceStrategy: NPE

Hi Adrian,

It looks like driverName is null in the call:

driver = (Driver)Class.forName(driverName, true,
Thread.currentThread().getContextClassLoader()).newInstance();

Driver name should come from a file called test.properties. There are
test.properties files in <base>/jpa/eclipselink.jpa.test and
<base>/foundation/eclipselink.core.test. Depending on whether you are
running
the jpa tests or the core tests, those files will be used to get the driver
name. To override those files, put a file called test.properties in your
<user-home> directory and override any settings you need to override.

-Tom

Goerler, Adrian wrote:

> Hi,
>
> executing the JPA LRG tests on MySQL, I am observing the following issue
> with EntityManagerJUnitTestSuite.testLockWithJoinedInheritanceStrategy:
>
> Exception Description: DriverWrapper: failed to instantiate null
> Internal Exception: java.lang.NullPointerException
>
> Local Exception Stack:
> Exception [EclipseLink-0] (Eclipse Persistence Services -
> 2.0.0.qualifier):
> org.eclipse.persistence.testing.framework.TestProblemException
> Exception Description: DriverWrapper: failed to instantiate null
> Internal Exception: java.lang.NullPointerException
> at
> org.eclipse.persistence.testing.framework.DriverWrapper.getDriver(DriverWrapper.java:191)
> at
> org.eclipse.persistence.testing.framework.DriverWrapper.connect(DriverWrapper.java:226)
> at java.sql.DriverManager.getConnection(DriverManager.java:582)
> at java.sql.DriverManager.getConnection(DriverManager.java:154)
> at
> org.eclipse.persistence.sessions.DefaultConnector.connect(DefaultConnector.java:98)
> at
> org.eclipse.persistence.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:162)
> at
> org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.connectInternal(DatasourceAccessor.java:327)
> at
> org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.connectInternal(DatabaseAccessor.java:294)
> at
> org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.connect(DatasourceAccessor.java:415)
> at
> org.eclipse.persistence.sessions.server.ConnectionPool.buildConnection(ConnectionPool.java:155)
> at
> org.eclipse.persistence.sessions.server.ConnectionPool.acquireConnection(ConnectionPool.java:97)
> at
> org.eclipse.persistence.sessions.server.ServerSession.acquireClientConnection(ServerSession.java:241)
> at
> org.eclipse.persistence.sessions.server.ClientSession.basicBeginTransaction(ClientSession.java:130)
> at
> org.eclipse.persistence.internal.sessions.AbstractSession.beginTransaction(AbstractSession.java:580)
> at
> org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.beginTransaction(UnitOfWorkImpl.java:546)
> at
> org.eclipse.persistence.queries.ObjectLevelReadQuery.executeDatabaseQuery(ObjectLevelReadQuery.java:973)
> at
> org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:675)
> at
> org.eclipse.persistence.queries.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:958)
> at
> org.eclipse.persistence.queries.ReadObjectQuery.execute(ReadObjectQuery.java:399)
> at
> org.eclipse.persistence.queries.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:1021)
> at
> org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2863)
> at
> org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1225)
> at
> org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1207)
> at
> org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1167)
> at
> org.eclipse.persistence.internal.jpa.EntityManagerImpl.executeQuery(EntityManagerImpl.java:733)
> at
> org.eclipse.persistence.internal.jpa.EntityManagerImpl.lock(EntityManagerImpl.java:1495)
> at
> org.eclipse.persistence.testing.tests.jpa.advanced.EntityManagerJUnitTestSuite.testLockWithJoinedInheritanceStrategy(EntityManagerJUnitTestSuite.java:1943)
> at
> org.eclipse.persistence.testing.framework.junit.JUnitTestCase.runBare(JUnitTestCase.java:428)
> at
> org.eclipse.persistence.testing.framework.TestExecutor.execute(TestExecutor.java:248)
> at
> org.eclipse.persistence.testing.framework.TestModel.execute(TestModel.java:208)
> at
> org.eclipse.persistence.testing.framework.TestCollection.run(TestCollection.java:313)
> Caused by: java.lang.NullPointerException
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:247)
> at
> org.eclipse.persistence.testing.framework.DriverWrapper.getDriver(DriverWrapper.java:189)
>
> So far, I have not been able to hunt it down.
>
> Is anyone observing this also or knows how to fix this?
>
> -Adrian
>
>
> *Adrian Görler
> **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

From forum: EclipseLink - Dev

How can I register a servlet to receive and handle the path like "/*"?

2009-12-08T00:08:40Z

Hello All.

When I convert a httpservlet to a bundle,I found that the first param of Httpservice.registerServlet method does not support the path define like "/*",but I want to achieve this functionality ,what should I do?

Thanks All.

2009-12-08

fox

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

From forum: Equinox - Dev

Version numbers?

2009-12-07T22:47:24Z

Greg, should I move all of Photran's plug-in and feature version numbers
in HEAD to 6.0? And/or should I move the branch versions to 5.1?

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

From forum: Eclipse Parallel Tools - Dev

Please fix soon ObjectLevelReadQuery.CheckCacheOnly do not return new registered object present in the UOW

2009-12-07T20:32:44Z

Please fix soon ObjectLevelReadQuery.CheckCacheOnly do not return new registered object present in the UOW.

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

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

From forum: EclipseLink - Dev

Re: eclipselink-users Digest, Vol 28, Issue 16

2009-12-07T19:19:22Z

Thanks, Michael and Guy, for your pointers on the criteria queries. It has worked for me. Cheers.

--- On Mon, 12/7/09, eclipselink-users-request@... <eclipselink-users-request@...> wrote:

From: eclipselink-users-request@... <eclipselink-users-request@...>
Subject: eclipselink-users Digest, Vol 28, Issue 16
To: eclipselink-users@...
Date: Monday, December 7, 2009, 12:00 PM

Send eclipselink-users mailing list submissions to
    eclipselink-users@...

To subscribe or unsubscribe via the World Wide Web, visit
    https://dev.eclipse.org/mailman/listinfo/eclipselink-users
or, via email, send a message with subject or body 'help' to
    eclipselink-users-request@...

You can reach the person managing the list at
    eclipselink-users-owner@...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of eclipselink-users digest..."

Today's Topics:

   1. Re: question on Criteria API (Guy Pelletier)
   2. RE: EclipseLink 1.2 Planning (Douglas Clarke)

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

Message: 1
Date: Mon, 7 Dec 2009 07:58:59 -0500
From: "Guy Pelletier" <guy.pelletier@...>
Subject: Re: [eclipselink-users] question on Criteria API
To: "EclipseLink User Discussions" <eclipselink-users@...>
Message-ID: <2825CBEC5A5D4FC79B3E32AE2C59976A@...>
Content-Type: text/plain; charset="iso-8859-1"

Doug,

You can find more documentation on the model generation here:

http://wiki.eclipse.org/UserGuide/JPA/Using_the_Canonical_Model_Generator_%28ELUG%29

Cheers,
Guy
----- Original Message -----
From: Michael O'Brien
To: EclipseLink User Discussions
Sent: Monday, December 07, 2009 2:37 AM
Subject: Re: [eclipselink-users] question on Criteria API

Doug,
Hi,
1) Here is an example generation of "_" java files without corresponding compiled class files (-proc:only) - placed at the cmd root
Depending on your IDE, you will be able to automatically generate these as long as the services file is in your classpath.
javac -processor org.eclipse.persistence.internal.jpa.modelgen.CanonicalModelProcessor -proc:only -classpath lib/eclipselink.jar;lib/javax.persistence_2.0_preview.jar;punit src/org/eclipse/persistence/testing/models/jpa/metamodel/*.java
....
Note: Building metadata class for round element: org.eclipse.persistence.testing.models.jpa.metamodel.ArrayProcessor
....

2) CriteriaBuilder is the new replacement rename for QueryBuilder in the Oct 2009 API version of JSR-317.
The specification was modified around 7 Oct to use CriteriaBuilder - see the latest PFD version of the spec when it arrives on the JSR site as it started on 22 Sept and has not reached a finish date yet as the final approval ballot was marked on 30 Nov - I would expect it out shortly.
Because of this, on the JSR-317 site - PFD-2 version from 31 Aug 2009 is still listing QueryBuilder as the interface in section 6.3.1 p.199 - this will change.
http://jcp.org/aboutJava/communityprocess/pfd/jsr317/index2.html

I checked with my Metamodel issue notes and found the following switch in our codebase...

   /trunk/jpa/plugins/javax.persistence/src/javax/persistence/criteria/QueryBuilder.java 5483 deleted
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=5483
   /trunk/jpa/plugins/javax.persistence/src/javax/persistence/criteria/CriteriaBuilder.java 5488   (+1456) new
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=5488
https://bugs.eclipse.org/bugs/show_bug.cgi?id=291598

   thank you
   /michael

Daoqi(Doug) Yang wrote:
I just downloaded EclipseLink 2.0.0 RC1 and have two questions on the Criteria API:

1) Where can I find the documentation on how to generate the static canonical metamodel classes?

2) This version of EclipseLink still has CriteriaBuilder, vs. QueryBuilder as in the JPA 2.0 spec. When will this be changed?

Thanks.

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

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

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://dev.eclipse.org/mailman/private/eclipselink-users/attachments/20091207/8c554089/attachment.html

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

Message: 2
Date: Mon, 7 Dec 2009 07:57:51 -0800 (PST)
From: Douglas Clarke <DOUGLAS.CLARKE@...>
Subject: RE: [eclipselink-users] EclipseLink 1.2 Planning
To: EclipseLink User Discussions <eclipselink-users@...>
Message-ID: <b8e97235-9f90-4285-844c-36001ede5977@default>
Content-Type: text/plain; charset=Windows-1252

Please make sure you add yourself to the cc list of bugs your are interested in so we can discuss the enhancements within the bug and you are notified of changes made to the bug.

Doug

-----Original Message-----
From: Tim Hollosy [mailto:hollosyt@...]
Sent: December 4, 2009 11:37 PM
To: EclipseLink User Discussions
Subject: Re: [eclipselink-users] EclipseLink 1.2 Planning

I voted for the Validation Support bug. I believe Hibernate already
supports this, I'd like to see EclipseLink stay ahead there.

./tch

On Fri, Dec 4, 2009 at 8:27 PM, Samba <saasira@...> wrote:

> Hi Doug/Peter,
>
>     I would want to see the bugs listed below getiing fixed in eclipselink
> 2.1.
>
> Bug 260258 - Add SessionBroker support
> Bug 280949 - Proposed Incubator: Add Data Partitioning Support
> Bug 241698 - Add Validation Support
> Further, I would also like to see a pluggable cache implementaion support in
> eclipselink 2.1, for which I could not find any bugzilla entry.
>
>    These are the features that Hibernate has but eclipselink does not have;
> of course, the feature set of eclipselink is so vast but it is always to
> good to have
>    more features, provided people need those features.
>
>    I'm interested in contributing to the Bug 280949 if you can give me a few
> pointers.
>
> Thanks and Regards,
> Samba
>
> On Tue, Dec 1, 2009 at 7:46 AM, Douglas Clarke <DOUGLAS.CLARKE@...>
> wrote:
>
>>
>> EclipseLink Users, Contributors, and Committers,
>>
>> We are wrapping up EclipseLink 2.0 now and need to start working towards
>> EclipseLink 2.1 which will be our Helios release in June. We have
>> accomplished a lot in the last year around standards delivering the
>> reference implementation of SDO 2.1.1 and now JPA 2.0 as well as addressing
>> JAXB 2.1 compliance and many advanced capabilities in all areas of the
>> project. Over the next 2 weeks we need to formalize our 2.1 themes and
>> requirements. Peter and I have started a wiki page for this purpose:
>>
>> http://wiki.eclipse.org/EclipseLink/Development/2.1
>>
>> We are asking all interested parties to help us shape what is coming in
>> the 2.1 release as well as future releases by participating in the process.
>> Please make sure your issues and enhancement requests are captured in bugs
>> with clear descriptions and actionable outcomes. We will be basing our work
>> for this next cycle on the themes we agree upon in an upcoming committer
>> meeting as well as the bug backlog in bugzilla. Make sure if you want an
>> issue addressed that you vote for the bug and/or start a thread on the forum
>> to discuss how the project should address your requirements so that others
>> can become aware of the issue and the bug number so they can vote as well.
>>
>> As always, bugs with patches supplied will be prioritized as we greatly
>> appreciate the additional effort it takes to contribute. All feedback on
>> this process and the project in general is appreciated.
>>
>> Cheers,
>>
>> Doug Clarke & Peter Krogh
>> EclipseLink Project Leads
>> _______________________________________________
>> eclipselink-users mailing list
>> eclipselink-users@...
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>
>>
>
>
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@...
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>
>
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

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

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

End of eclipselink-users Digest, Vol 28, Issue 16
*************************************************

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

From forum: EclipseLink - Users

Re: ECF OSU CVS repo to Git migration

2009-12-07T14:45:43Z

Markus we get an error with this path when trying to access from eclipse.
Cannot access /home/gitcvs/CVSROOT

We dont see a CVSROOT under /home/gitcvs/
-ted

On Mon, Dec 7, 2009 at 11:17 AM, Markus Alexander Kuppe
<ecf-dev_eclipse.org@...> wrote:

> On 12/07/2009 06:22 PM, Markus Alexander Kuppe wrote:
>
>> [3] :pserver:anonymous@...:62401/gitcvs
>
> This must read: :pserver:anonymous@...:62401/home/gitcvs
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@...
> https://dev.eclipse.org/mailman/listinfo/ecf-dev
>

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

From forum: Eclipse ECF - Dev

Re: EntityManagerJUnitTestSuite.testLockWithJoinedInheritanceStrategy:NPE

2009-12-07T14:28:31Z

Hi Adrian,

I apologize for the delay.

I still don't understand why (and if) the password becomes corrupted.

Could you please try applying the patch in Bug 297137 - Passing the same
user/password to both createEMF and createEM causes EM to open new
connection
https://bugs.eclipse.org/bugs/show_bug.cgi?id=297137

Thanks,

Andrei
----- Original Message -----
From: "Goerler, Adrian" <adrian.goerler@...>
To: "Andrei Ilitchev" <andrei.ilitchev@...>
Cc: "Dev mailing list for Eclipse Persistence Services"
<eclipselink-dev@...>
Sent: Wednesday, December 02, 2009 3:05 AM
Subject: AW:
[eclipselink-dev]EntityManagerJUnitTestSuite.testLockWithJoinedInheritanceStrategy:NPE

Hi Andrei,

I was a bit short in my explanation:

testEMCloseAndOpen and testEMFactoryCloseAndOpen use the DriverWrapper. The
DriverWrapper seems to be a JDBC driver that registers with the
java.sql.DriverManager. It accepts just the same URLs as the MySQL Driver
but is chained after the MySQL driver.

testEMCloseAndOpen and testEMFactoryCloseAndOpen reset the DriverWrapper
after usage setting the driverName of the wrapped driver to null.

In testLockWithJoinedInheritanceStrategy it is attempted to create a
connection. But for the some reason, the password encoding is broken and it
is attempted to connect to the MySQL driver using an encoded password, which
fails with an SQLException. Now the java.sql.DriverManager tries the next
driver registered (the DriverWrapper), which throws the NPE as the
driverName is null.

If I do not run testEMCloseAndOpen and testEMFactoryCloseAndOpen but only
testNoPersistOnFlushProperties and testLockWithJoinedInheritanceStrategy, I
don't get the NPE in the driver wrapper but only the causing SQL Exception:

Internal Exception: java.sql.SQLException: Access denied for user
'me'@'localhost' (using password: YES)
Error Code: 1045
at
org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:324)
at
org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:319)
at
org.eclipse.persistence.sessions.DefaultConnector.connect(DefaultConnector.java:138)
at
org.eclipse.persistence.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:162)
at
org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.connectInternal(DatasourceAccessor.java:327)
at
org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.connectInternal(DatabaseAccessor.java:294)
at
org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.connect(DatasourceAccessor.java:415)
at
org.eclipse.persistence.sessions.server.ConnectionPool.buildConnection(ConnectionPool.java:155)
at
org.eclipse.persistence.sessions.server.ConnectionPool.acquireConnection(ConnectionPool.java:97)
at
org.eclipse.persistence.sessions.server.ServerSession.acquireClientConnection(ServerSession.java:241)
at
org.eclipse.persistence.sessions.server.ClientSession.basicBeginTransaction(ClientSession.java:130)
at
org.eclipse.persistence.internal.sessions.AbstractSession.beginTransaction(AbstractSession.java:580)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.beginTransaction(UnitOfWorkImpl.java:546)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabase(UnitOfWorkImpl.java:1346)
at
org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.commitToDatabase(RepeatableWriteUnitOfWork.java:547)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabaseWithChangeSet(UnitOfWorkImpl.java:1510)
at
org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.commitRootUnitOfWork(RepeatableWriteUnitOfWork.java:200)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitAndResume(UnitOfWorkImpl.java:1131)
at
org.eclipse.persistence.internal.jpa.transaction.EntityTransactionImpl.commitInternal(EntityTransactionImpl.java:84)
at
org.eclipse.persistence.internal.jpa.transaction.EntityTransactionImpl.commit(EntityTransactionImpl.java:63)
at
org.eclipse.persistence.testing.framework.junit.JUnitTestCase.commitTransaction(JUnitTestCase.java:267)
at
org.eclipse.persistence.testing.tests.jpa.advanced.EntityManagerJUnitTestSuite.testLockWithJoinedInheritanceStrategy(EntityManagerJUnitTestSuite.java:1919)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at
org.eclipse.persistence.testing.framework.junit.JUnitTestCase.runBare(JUnitTestCase.java:428)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.sql.SQLException: Access denied for user 'me'@'localhost'
(using password: YES)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1055)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3536)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3468)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:917)
at com.mysql.jdbc.MysqlIO.secureAuth411(MysqlIO.java:3974)
at com.mysql.jdbc.MysqlIO.doHandshake(MysqlIO.java:1282)
at
com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2142)
at com.mysql.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:773)
at com.mysql.jdbc.JDBC4Connection.<init>(JDBC4Connection.java:46)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:406)
at
com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:352)
at
com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:282)
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:154)
<----- this is atempted with the wrong password
at
org.eclipse.persistence.sessions.DefaultConnector.connect(DefaultConnector.java:98)
... 38 more

So, strictly speaking it is not a repro for the NPE but for the cause of the
NPE. Strange that it is working on your side. Sabine is observing the same
issue.

Best regards,

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@...
[mailto:eclipselink-dev-bounces@...] Im Auftrag von Andrei Ilitchev
Gesendet: Dienstag, 1. Dezember 2009 18:00
An: Dev mailing list for Eclipse Persistence Services
Betreff: Re:
[eclipselink-dev]EntityManagerJUnitTestSuite.testLockWithJoinedInheritanceStrategy:
NPE

Hi Adrian,

DriverWrapper class that appears on the stack is a test helper class that
currently used only in two EntitymanagerJUnitTsetSuite tests:
testEMCloseAndOpen and testEMFactoryCloseAndOpen.

These two tests use DriverWrapper to simulate dropped connections:
HashMap properties = new
HashMap(JUnitTestCaseHelper.getDatabaseProperties());
properties.put(PersistenceUnitProperties.JDBC_DRIVER,
DriverWrapper.class.getName());
properties.put(PersistenceUnitProperties.JDBC_URL,
DriverWrapper.codeUrl(originalConnectionString));
getEntityManagerFactory(properties);

I can't explain how DriverWrapper would show up when none of these two tests
have run (your reproducing the problem with just two tests).

However if one or both these tests have run before,
it is possible that the JDBC_DRIVER and JDBC_URL they provided are still
used by the factory
(though each of the two tests supposed to clean up after themselves).

You could comment out testEMCloseAndOpen and testEMFactoryCloseAndOpen -
that should remove any usage of DriverWrapper.

But to get to the bottom of it we need to figure out why the factory (or the
server session owned by the factory) is not properly cleaned up of
DriverWrapper.

I can't reproduce the problem so far.

Thanks,

Andrei

----- Original Message -----
From: "Goerler, Adrian" <adrian.goerler@...>
To: "tom Ware" <tom.ware@...>
Cc: "Dev mailing list for Eclipse Persistence Services"
<eclipselink-dev@...>
Sent: Tuesday, December 01, 2009 11:26 AM
Subject: AW:
[eclipselink-dev]EntityManagerJUnitTestSuite.testLockWithJoinedInheritanceStrategy:
NPE

Hi Tom, all,

I have correctly set the driver name in test.properties.

The issue is something different. This is what I have found out so far:

EntityManagerJUnitTestSuite.testLockWithJoinedInheritanceStrategy is the
only test failing for me.

I can reproduce the issue by reducing the testsuite as follows:

public static Test suite() {
TestSuite suite = new TestSuite();
suite.setName("EntityManagerJUnitTestSuite");

suite.addTest(new
EntityManagerJUnitTestSuite("testNoPersistOnFlushProperties"));

suite.addTest(new
EntityManagerJUnitTestSuite("testLockWithJoinedInheritanceStrategy"));

return suite;
}

It appears that the database passwords are kept in some encrypted form and
that the test "testNoPersistOnFlushProperties" confuses the encryption
somehow.

"testLockWithJoinedInheritanceStrategy" then fails to create a connection as
it attempts to use an encrypted password to connect.

Anyone any idea on this?

-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@...
[mailto:eclipselink-dev-bounces@...] Im Auftrag von Tom Ware
Gesendet: Dienstag, 1. Dezember 2009 15:14
An: Dev mailing list for Eclipse Persistence Services
Betreff: Re: [eclipselink-dev]
EntityManagerJUnitTestSuite.testLockWithJoinedInheritanceStrategy: NPE

Hi Adrian,

It looks like driverName is null in the call:

driver = (Driver)Class.forName(driverName, true,
Thread.currentThread().getContextClassLoader()).newInstance();

Driver name should come from a file called test.properties. There are
test.properties files in <base>/jpa/eclipselink.jpa.test and
<base>/foundation/eclipselink.core.test. Depending on whether you are
running
the jpa tests or the core tests, those files will be used to get the driver
name. To override those files, put a file called test.properties in your
<user-home> directory and override any settings you need to override.

-Tom

Goerler, Adrian wrote:

From forum: EclipseLink - Dev

Re: Helios and PTP 3.0/Photran 5.0 branch

2009-12-07T13:39:13Z

> Surprisingly, Photran HEAD works fine with Eclipse 3.6M3 and CDT HEAD.

I opened https://bugs.eclipse.org/297130 for Helios support in Photran.

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

From forum: Eclipse Parallel Tools - Dev

Re: release status

2009-12-07T13:37:37Z

>>> Why do I see a new menu "Refactor" with one entry "(Debugging)"?

> Ok. Can you open a bug on it?

https://bugs.eclipse.org/297128

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

From forum: Eclipse Parallel Tools - Dev

Re: Bug 269969 - Oracle should outerjoin in thefromclause by default.

2009-12-07T13:02:20Z

Checked into trunk (2.0.1). Reviewed by James.

----- Original Message -----

From: andrei.ilitchev@...

To: eclipselink-dev@...

Sent: Monday, November 30, 2009 1:54 PM

Subject: Re: [eclipselink-dev] Bug 269969 - Oracle should outerjoin in thefromclause by default.

The patch was updated (only DatabasePlatform and derived from it classes differ form the ones in the previous patch) Please see details in the bug.

----- Original Message -----

From: andrei.ilitchev@...

To: eclipselink-dev@...

Sent: Wednesday, November 25, 2009 2:45 PM

Subject: [eclipselink-dev] Bug 269969 - Oracle should outerjoin in the fromclause by default.

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

The patch is ready. Please send feedback.

Thanks,

Andrei

_______________________________________________
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

From forum: EclipseLink - Dev

Issue deleting entity with references to them selves

2009-12-07T12:49:49Z

I have an entity with a Many to One relationship to it self (but there are no instances of an entity referring to itself). When I try deleting the table contents I get complaints about the constraint. I thought that defining the relation as CascadeType.ALL would take care of it but that's not the case.

Here's the entity (see the relationship in bold):

/*
* To change this template, choose Tools | Templates
* and open the template in the editor.
*/
package com.bluecubs.xinco.core.server.persistence;

import com.bluecubs.xinco.core.server.AuditedEntityListener;
import com.bluecubs.xinco.core.server.XincoAuditedObject;
import java.io.Serializable;
import java.util.List;
import javax.persistence.Basic;
import javax.persistence.CascadeType;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.EntityListeners;
import javax.persistence.FetchType;
import javax.persistence.Id;
import javax.persistence.JoinColumn;
import javax.persistence.ManyToOne;
import javax.persistence.NamedQueries;
import javax.persistence.NamedQuery;
import javax.persistence.OneToMany;
import javax.persistence.Table;

/**
*
* @author Javier A. Ortiz Bultrón <javier.ortiz.78@...>
*/
@Entity
@Table(name = "xinco_core_node")
@EntityListeners(AuditedEntityListener.class)
@NamedQueries({
@NamedQuery(name = "XincoCoreNode.findAll", query = "SELECT x FROM XincoCoreNode x"),
@NamedQuery(name = "XincoCoreNode.findById", query = "SELECT x FROM XincoCoreNode x WHERE x.id = :id"),
@NamedQuery(name = "XincoCoreNode.findByDesignation", query = "SELECT x FROM XincoCoreNode x WHERE x.designation = :designation"),
@NamedQuery(name = "XincoCoreNode.findByStatusNumber", query = "SELECT x FROM XincoCoreNode x WHERE x.statusNumber = :statusNumber")})
public class XincoCoreNode extends XincoAuditedObject implements Serializable {

private static final long serialVersionUID = 1L;
@Id
@Basic(optional = false)
@Column(name = "id", nullable = false)
private Integer id;
@Basic(optional = false)
@Column(name = "designation", nullable = false, length = 255)
private String designation;
@Basic(optional = false)
@Column(name = "status_number", nullable = false)
private int statusNumber;
@JoinColumn(name = "xinco_core_language_id", referencedColumnName = "id", nullable = false)
@ManyToOne(optional = false, fetch = FetchType.LAZY)
private XincoCoreLanguage xincoCoreLanguageId;
@OneToMany(cascade = CascadeType.ALL, mappedBy = "xincoCoreNodeId", fetch = FetchType.LAZY)
private List<XincoCoreNode> xincoCoreNodeList;
@JoinColumn(name = "xinco_core_node_id", referencedColumnName = "id")
@ManyToOne(fetch = FetchType.LAZY, cascade = CascadeType.ALL)
private XincoCoreNode xincoCoreNodeId;
@OneToMany(cascade = CascadeType.ALL, mappedBy = "xincoCoreNodeId", fetch = FetchType.LAZY)
private List<XincoCoreAce> xincoCoreAceList;
@OneToMany(cascade = CascadeType.ALL, mappedBy = "xincoCoreNodeId", fetch = FetchType.LAZY)
private List<XincoCoreData> xincoCoreDataList;

public XincoCoreNode() {
}

public XincoCoreNode(Integer id) {
this.id = id;
}

public XincoCoreNode(Integer id, String designation, int statusNumber) {
this.id = id;
this.designation = designation;
this.statusNumber = statusNumber;
}

public Integer getId() {
return id;
}

public void setId(Integer id) {
this.id = id;
}

public String getDesignation() {
return designation;
}

public void setDesignation(String designation) {
this.designation = designation;
}

public int getStatusNumber() {
return statusNumber;
}

public void setStatusNumber(int statusNumber) {
this.statusNumber = statusNumber;
}

public XincoCoreLanguage getXincoCoreLanguageId() {
return xincoCoreLanguageId;
}

public void setXincoCoreLanguageId(XincoCoreLanguage xincoCoreLanguageId) {
this.xincoCoreLanguageId = xincoCoreLanguageId;
}

public List<XincoCoreNode> getXincoCoreNodeList() {
return xincoCoreNodeList;
}

public void setXincoCoreNodeList(List<XincoCoreNode> xincoCoreNodeList) {
this.xincoCoreNodeList = xincoCoreNodeList;
}

public XincoCoreNode getXincoCoreNodeId() {
return xincoCoreNodeId;
}

public void setXincoCoreNodeId(XincoCoreNode xincoCoreNodeId) {
this.xincoCoreNodeId = xincoCoreNodeId;
}

public List<XincoCoreAce> getXincoCoreAceList() {
return xincoCoreAceList;
}

public void setXincoCoreAceList(List<XincoCoreAce> xincoCoreAceList) {
this.xincoCoreAceList = xincoCoreAceList;
}

public List<XincoCoreData> getXincoCoreDataList() {
return xincoCoreDataList;
}

public void setXincoCoreDataList(List<XincoCoreData> xincoCoreDataList) {
this.xincoCoreDataList = xincoCoreDataList;
}

@Override
public int hashCode() {
int hash = 0;
hash += (id != null ? id.hashCode() : 0);
return hash;
}

@Override
public boolean equals(Object object) {
// TODO: Warning - this method won't work in the case the id fields are not set
if (!(object instanceof XincoCoreNode)) {
return false;
}
XincoCoreNode other = (XincoCoreNode) object;
if ((this.id == null && other.id != null) || (this.id != null && !this.id.equals(other.id))) {
return false;
}
return true;
}

@Override
public String toString() {
return "com.bluecubs.xinco.core.server.persistence.XincoCoreNode[id=" + id + "]";
}
}

Any help/idea is welcomed!

Thanks in advance!

Javier A. Ortiz Bultrón
Quality Assurance Engineer
B.Braun Medical, Inc.
972-466-5076 Phone

********************************************************************************
The information contained in this communication is confidential, may be
attorney-client privileged, may constitute inside information, and is intended
only for the use of the addressee. It is the property of the company of the
sender of this e-mail. Unauthorized use, disclosure, or copying of this
communication or any part thereof is strictly prohibited and may be unlawful.
If you have received this communication in error, please notify us immediately
by return e-mail and destroy this communication and all copies thereof,
including all attachments.
********************************************************************************


_______________________________________________

eclipselink-users mailing list

eclipselink-users@...

https://dev.eclipse.org/mailman/listinfo/eclipselink-users
From forum: EclipseLink - Users

Bug 296524 - Four JPA tests failed on Spring against SQLServer2008 with NPE and AssertionFailedError

2009-12-07T12:48:03Z

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

Checked into trunk the (test only) fix.

Thanks,

Andrei

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

From forum: EclipseLink - Dev

Re: Re: Bug 296606 - issues with ElementCollections

2009-12-07T12:34:11Z

Checked into trunk (2.0.1). Reviewed by James.

----- Original Message -----

From: andrei.ilitchev@...

To: eclipselink-dev@...

Sent: Monday, December 07, 2009 1:47 PM

Subject: [eclipselink-dev] Re: Bug 296606 - issues with ElementCollections

The new patch that fixes collection members' updates has been added to the bug.

----- Original Message -----

From: andrei.ilitchev@...

To: eclipselink-dev@...

Sent: Thursday, December 03, 2009 1:30 PM

Subject: Bug 296606 - issues with ElementCollections

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

The fix for the bug is ready. Please send feedback.

Thanks,

Andrei

_______________________________________________
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

From forum: EclipseLink - Dev

Re: Re: Bug 296606 - issues with ElementCollections

2009-12-07T12:33:57Z

Checked into trunk (2.0.1). Reviewed by James.

----- Original Message -----

From: andrei.ilitchev@...

To: eclipselink-dev@...

Sent: Monday, December 07, 2009 1:47 PM

Subject: [eclipselink-dev] Re: Bug 296606 - issues with ElementCollections

The new patch that fixes collection members' updates has been added to the bug.

----- Original Message -----

From: andrei.ilitchev@...

To: eclipselink-dev@...

Sent: Thursday, December 03, 2009 1:30 PM

Subject: Bug 296606 - issues with ElementCollections

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

The fix for the bug is ready. Please send feedback.

Thanks,

Andrei

_______________________________________________
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

From forum: EclipseLink - Dev

Re: Helios and PTP 3.0/Photran 5.0 branch

2009-12-07T11:33:34Z

> Jeff, as Photran is likely to be the most impacted by this, you probably need to get Eclipse 3.6/CDT 7.0 installed and take a look asap.

Surprisingly, Photran HEAD works fine with Eclipse 3.6M3 and CDT HEAD.

The hardest part was getting Eclipse 3.6M3 to launch on Windows. It was
giving me "JVM Terminated: Error Code -1", and the only way I could
solve that was to remove "--launcher.XXMaxPermSize 256m" from the
eclipse.ini file. I'd be curious to know if anyone else runs into this
same problem. I'm running Sun Java SE 1.6.0_17 (32-bit) on WinXP.

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

From forum: Eclipse Parallel Tools - Dev

Re: ECF OSU CVS repo to Git migration

2009-12-07T11:17:41Z

On 12/07/2009 06:22 PM, Markus Alexander Kuppe wrote:

> [3] :pserver:anonymous@...:62401/gitcvs

This must read: :pserver:anonymous@...:62401/home/gitcvs
_______________________________________________
ecf-dev mailing list
ecf-dev@...
https://dev.eclipse.org/mailman/listinfo/ecf-dev

From forum: Eclipse ECF - Dev

Re: Helios and PTP 3.0/Photran 5.0 branch

2009-12-07T11:07:37Z

Branching completed.
Greg

On Dec 7, 2009, at 11:55 AM, Greg Watson wrote:

> We need to begin preparation for the 4.0/6.0 release to coincide with the Helios release next June. In particular, we need to be part of the M4 build at the end of this week.
>
> I'm planning to create a ptp_3_0/photran_5_0 branch today. HEAD will then become 4.0/6.0.
>
> Jeff, as Photran is likely to be the most impacted by this, you probably need to get Eclipse 3.6/CDT 7.0 installed and take a look asap.
>
> If anyone has any problems with this, let me know.
>
> Greg_______________________________________________
> ptp-dev mailing list
> ptp-dev@...
> https://dev.eclipse.org/mailman/listinfo/ptp-dev

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

From forum: Eclipse Parallel Tools - Dev

Re: Bug 296606 - issues with ElementCollections

2009-12-07T10:47:42Z

The new patch that fixes collection members' updates has been added to the bug.

----- Original Message -----

From: andrei.ilitchev@...

To: eclipselink-dev@...

Sent: Thursday, December 03, 2009 1:30 PM

Subject: Bug 296606 - issues with ElementCollections

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

The fix for the bug is ready. Please send feedback.

Thanks,

Andrei

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

From forum: EclipseLink - Dev

Re: link-local-messaging-client into ECF

2009-12-07T10:44:06Z

Hi Roland and Markus,

Roland Matha wrote:
> Hi Markus,
> No my implementation is not publicly available already, but I try to write a
> plugin for eclipse/ecf to make it available.
>

We should be able help with this. Our resources are extremely limited,
but we certainly will help to the degree possible...at least with
answering questions.

If you are willing to contribute to ECF project (i.e. under EPL) then it
can/would soon be distributed in ECF itself.

Thanks...and inadvance!

Scott

> Roland
>
> Zitat von Markus Alexander Kuppe <ecf-dev_eclipse.org@...>:
>
>
>> On 12/07/2009 12:18 AM, Roland Matha wrote:
>>
>>> Hi Folks,
>>> In the last weeks i wrote a link-local-messaging-client that works fine. I
>>>
>> will
>>
>>> ask if someone can help me to integrate it yet into the ECF.
>>> Is already a help for me, when I know which interfaces must be implemented.
>>>
>> Hi Roland,
>>
>> I'm not an expert on the EF messaging API, but I'd like to see shared
>> editing use link-local-messaging underneath. Is you implementation
>> publicly available already?
>>
>> Markus
>> _______________________________________________
>> ecf-dev mailing list
>> ecf-dev@...
>> https://dev.eclipse.org/mailman/listinfo/ecf-dev
>>
>>
>
>
>
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@...
> https://dev.eclipse.org/mailman/listinfo/ecf-dev
>

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

From forum: Eclipse ECF - Dev

Re: rest API work

2009-12-07T10:01:57Z

Hi Andre,

I need to clarify my last post. This should be the code snippet (the
comment in my previoius post about creating a new HttpClient for every
request was incorrect):

protected HttpClient getHttpClientForCall(HttpMethod httpMethod,
IRemoteCall call, IRestCallable callable) {
return httpClient;
}

Scott

Scott Lewis wrote:

> <
> protected HttpClient getHttpClientForCall(HttpMethod httpMethod,
> IRemoteCall call, IRestCallable callable) {
> // By default, create a new HttpClient instance for every
> request. return httpClient;
> }
>
> The intention is that subclasses can override this behavior if they
> wish...e.g. to reuse an HttpClient for all calls. This change is now
> committed to HEAD.
>
> Now the question is: what should the default behavior be in
> RestClientService? (i.e. a separate HttpClient for each call, or one
> that is shared for all calls)? My initial inclination was that the
> default should be a new HttpClient for each call (i.e.
> creating/returning a new one each time getHttpClientForCall is
> called), but I think upon reflection that having an HttpClient that is
> reused for each call is probably a better default...and so I've
> changed the default implementation in RestClientService to reuse the
> httpClient (created upon construction) for each call. Subclasses may
> override this behavior simply by implementing getHttpClientForCall in
> a different manner (i.e. returning a new HttpClient for each instance).
>
>>
>>>
>>>> - - I need to be able to elaborate on the specific HTTP error.In some
>>>> cases my REST service answers 404 to signal me that there's no
>>>> information present. I'll have to react by not showing any information
>>>> for this call. On the other hand I'd have to popup an error for any
>>>> other error that may occur (authentication, transport etc.). I'd
>>>> suggest
>>>> to pass an IStatus to the ECFException instead of a plain string. I'll
>>>> then be able to fetch it's code.
>>>>
>>> The newly revised RestClientContainer and RestClientService classes
>>> can/would/do allow subclassing to implement alternative strategies for
>>> particular rest APIs...e.g. for handling http responses in custom ways
>>> for a particular rest api. That is, it's intended that for *some*
>>> rest
>>> clients, subclasses of RestClientContainer and RestClientService might
>>> be created to customize the runtime behavior (since rest is more a
>>> family of protocols than it is a single protocol).
>>> In addition, it's possible that we could introduce some more
>>> flexibility
>>> into these classes....e.g. RestClientService...through some
>>> generalization of the protected and public methods...or by introducing
>>> interfaces for delegation.
>>>
>>>
>>
>> sound good! I'll catch up with the latest incarnation and try to
>> subclass to get what I need.
>> On the other hand, I wonder here too, if there's any good reason to
>> deliberately loose the error code. What do I miss?
>>
>
> I've introduced an new class: RestException that provides access to
> the error code. This is/also been committed to HEAD. It allows
> receivers/handlers of the RestException to get at the error code if
> they wish.
>
>> Hi Scott, Hi Holger
>>
>> sorry, for being too quick with my posts. I guess your API suggests to
>> subclass IRestCallable and augment it to have request entities.
>> Am I right?
>
> Well, unfortunately I don't think subclassing RestCallable will
> properly do the trick WRT request entities...so we probably need to
> figure out how to allow people to specify a RequestEntity for post
> parameter in some way that is not yet in the API. I removed it from
> the old API for simplicity...but I think I forgot to put it back in.
>
> I agree that there should be some way of specifying that a
> RequestEntity is to be used for post requests, but I'm not clear on
> the 'best' or 'clearest' way to represent it in the API. Any
> thoughts/comments would be appreciated...and we will get it back in
> there.
>
> Scott
>
>> Thanks + Cheers!
>> André
>>
>> - --
>> André Dietisheim
>> Head of Eclipse Development
>>
>> Puzzle ITC GmbH
>> www.puzzle.ch
>>
>> Telefon +41 31 370 22 00
>> Fax +41 31 370 22 01
>> Mobile +41 76 423 03 02
>>
>> Abonnieren Sie unsere News:
>> <http://www.puzzle.ch/follow-us>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iEYEARECAAYFAksdATMACgkQxpTsx9UecrlGngCfVWbkXAoSOUedFUHbH+c76lVc
>> wkcAoMgac8zsfzvsauVVCdXaMFkYGrW4
>> =joLo
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> ecf-dev mailing list
>> ecf-dev@...
>> https://dev.eclipse.org/mailman/listinfo/ecf-dev
>>
>
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@...
> https://dev.eclipse.org/mailman/listinfo/ecf-dev

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

From forum: Eclipse ECF - Dev

Re: rest API work

2009-12-07T09:56:24Z

Hi Andre,

Andre Dietisheim wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Scott
>
>
>> This can/could be fairly easily done (i.e make it an option to create a
>> new HttpClient or reuse an existing one), but it would be an addition.
>> Please open an enhancement request to this effect (i.e. 'reuse
>> httpclient for rest calls' or something like that), and we'll get to it.
>>
>
> I filed a new bugzilla entry:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=297062
>
> I wonder if there's any good reason to create a new instance on each
> call. What prohibits ECF to reuse a httpClient instance? Do I miss
> something?
> Just tell me wich solution you'll opt for and I'll be glad to provider a
> patch.
>

Hi Andre.

I had originally intended to allow subclasses (of RestClientService
class) to override the creation of HttpClient instances (one per
call)...but this was mistakenly left out (i.e. HttpClient httpClient =
new HttpClient). So, to make it possible for subclasses of
RestClientService to override the default behavior I introduced a new
protected method:

protected HttpClient getHttpClientForCall(HttpMethod httpMethod,
IRemoteCall call, IRestCallable callable) {
// By default, create a new HttpClient instance for every request.
return httpClient;
}

The intention is that subclasses can override this behavior if they
wish...e.g. to reuse an HttpClient for all calls. This change is now
committed to HEAD.

Now the question is: what should the default behavior be in
RestClientService? (i.e. a separate HttpClient for each call, or one
that is shared for all calls)? My initial inclination was that the
default should be a new HttpClient for each call (i.e.
creating/returning a new one each time getHttpClientForCall is called),
but I think upon reflection that having an HttpClient that is reused for
each call is probably a better default...and so I've changed the default
implementation in RestClientService to reuse the httpClient (created
upon construction) for each call. Subclasses may override this behavior
simply by implementing getHttpClientForCall in a different manner (i.e.
returning a new HttpClient for each instance).

>
>>
>>> - - I need to be able to elaborate on the specific HTTP error.In some
>>> cases my REST service answers 404 to signal me that there's no
>>> information present. I'll have to react by not showing any information
>>> for this call. On the other hand I'd have to popup an error for any
>>> other error that may occur (authentication, transport etc.). I'd suggest
>>> to pass an IStatus to the ECFException instead of a plain string. I'll
>>> then be able to fetch it's code.
>>>
>>>
>> The newly revised RestClientContainer and RestClientService classes
>> can/would/do allow subclassing to implement alternative strategies for
>> particular rest APIs...e.g. for handling http responses in custom ways
>> for a particular rest api. That is, it's intended that for *some* rest
>> clients, subclasses of RestClientContainer and RestClientService might
>> be created to customize the runtime behavior (since rest is more a
>> family of protocols than it is a single protocol).
>> In addition, it's possible that we could introduce some more flexibility
>> into these classes....e.g. RestClientService...through some
>> generalization of the protected and public methods...or by introducing
>> interfaces for delegation.
>>
>>
>
> sound good! I'll catch up with the latest incarnation and try to
> subclass to get what I need.
> On the other hand, I wonder here too, if there's any good reason to
> deliberately loose the error code. What do I miss?
>

I've introduced an new class: RestException that provides access to the
error code. This is/also been committed to HEAD. It allows
receivers/handlers of the RestException to get at the error code if they
wish.

> Hi Scott, Hi Holger
>
> sorry, for being too quick with my posts. I guess your API suggests to
> subclass IRestCallable and augment it to have request entities.
> Am I right?

Well, unfortunately I don't think subclassing RestCallable will properly
do the trick WRT request entities...so we probably need to figure out
how to allow people to specify a RequestEntity for post parameter in
some way that is not yet in the API. I removed it from the old API for
simplicity...but I think I forgot to put it back in.

I agree that there should be some way of specifying that a RequestEntity
is to be used for post requests, but I'm not clear on the 'best' or
'clearest' way to represent it in the API. Any thoughts/comments would
be appreciated...and we will get it back in there.

Scott

> Thanks + Cheers!
> André
>
> - --
> André Dietisheim
> Head of Eclipse Development
>
> Puzzle ITC GmbH
> www.puzzle.ch
>
> Telefon +41 31 370 22 00
> Fax +41 31 370 22 01
> Mobile +41 76 423 03 02
>
> Abonnieren Sie unsere News:
> <http://www.puzzle.ch/follow-us>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAksdATMACgkQxpTsx9UecrlGngCfVWbkXAoSOUedFUHbH+c76lVc
> wkcAoMgac8zsfzvsauVVCdXaMFkYGrW4
> =joLo
> -----END PGP SIGNATURE-----
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@...
> https://dev.eclipse.org/mailman/listinfo/ecf-dev
>

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

From forum: Eclipse ECF - Dev

RE: [eclipselink-users] EclipseLink 2.1 Planning

2009-12-07T09:27:34Z

This is actually EclipseLink 2.1 planning and not 1.2 as originally noted in the subject.

Doug

-----Original Message-----
From: Douglas Clarke
Sent: November 30, 2009 9:17 PM
To: Eclipselink-Dev (E-mail); Eclipselink-Users (E-mail)
Subject: [eclipselink-users] EclipseLink 1.2 Planning

EclipseLink Users, Contributors, and Committers,

We are wrapping up EclipseLink 2.0 now and need to start working towards EclipseLink 2.1 which will be our Helios release in June. We have accomplished a lot in the last year around standards delivering the reference implementation of SDO 2.1.1 and now JPA 2.0 as well as addressing JAXB 2.1 compliance and many advanced capabilities in all areas of the project. Over the next 2 weeks we need to formalize our 2.1 themes and requirements. Peter and I have started a wiki page for this purpose:

http://wiki.eclipse.org/EclipseLink/Development/2.1

We are asking all interested parties to help us shape what is coming in the 2.1 release as well as future releases by participating in the process. Please make sure your issues and enhancement requests are captured in bugs with clear descriptions and actionable outcomes. We will be basing our work for this next cycle on the themes we agree upon in an upcoming committer meeting as well as the bug backlog in bugzilla. Make sure if you want an issue addressed that you vote for the bug and/or start a thread on the forum to discuss how the project should address your requirements so that others can become aware of the issue and the bug number so they can vote as well.

As always, bugs with patches supplied will be prioritized as we greatly appreciate the additional effort it takes to contribute. All feedback on this process and the project in general is appreciated.

Cheers,

Doug Clarke & Peter Krogh

EclipseLink Project Leads

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

From forum: EclipseLink - Dev

RE: EclipseLink 2.1 Planning

2009-12-07T09:27:34Z

This is actually EclipseLink 2.1 planning and not 1.2 as originally noted in the subject.

Doug

-----Original Message-----
From: Douglas Clarke
Sent: November 30, 2009 9:17 PM
To: Eclipselink-Dev (E-mail); Eclipselink-Users (E-mail)
Subject: [eclipselink-users] EclipseLink 1.2 Planning

EclipseLink Users, Contributors, and Committers,

We are wrapping up EclipseLink 2.0 now and need to start working towards EclipseLink 2.1 which will be our Helios release in June. We have accomplished a lot in the last year around standards delivering the reference implementation of SDO 2.1.1 and now JPA 2.0 as well as addressing JAXB 2.1 compliance and many advanced capabilities in all areas of the project. Over the next 2 weeks we need to formalize our 2.1 themes and requirements. Peter and I have started a wiki page for this purpose:

http://wiki.eclipse.org/EclipseLink/Development/2.1

We are asking all interested parties to help us shape what is coming in the 2.1 release as well as future releases by participating in the process. Please make sure your issues and enhancement requests are captured in bugs with clear descriptions and actionable outcomes. We will be basing our work for this next cycle on the themes we agree upon in an upcoming committer meeting as well as the bug backlog in bugzilla. Make sure if you want an issue addressed that you vote for the bug and/or start a thread on the forum to discuss how the project should address your requirements so that others can become aware of the issue and the bug number so they can vote as well.

As always, bugs with patches supplied will be prioritized as we greatly appreciate the additional effort it takes to contribute. All feedback on this process and the project in general is appreciated.

Cheers,

Doug Clarke & Peter Krogh

EclipseLink Project Leads

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

From forum: EclipseLink - Users

ECF OSU CVS repo to Git migration

2009-12-07T09:22:54Z

Hi all,

given that the foundation has chosen Git as a successor to CVS and
started to offer read-only Git repos already, probably makes us want to
convert our non-EPLed code repo located at OSU to Git as well [1]. Thus
I've begun to mirror ecf1 to Github [2]. If you wanna start right away
with git, you'll have to let me know your Github username so I can add
you as a collaborator. Alternatively you can fork the project and send
out pull requests.
However contrary to the foundation's setup it's it's not a pick and
chose as we can continue to use the CVS repo [4]. Unfortunately this
change requires one to set CVS_SERVER="git-cvsserver" if "ext" or
"extssh" is to be used as well as to relocate your existing CVS repos
due to a different path (a detailed manual how to use git-cvsserver is
part of the man page [4].
For the moment the old CVS repo is still online at the original URL
(which is _not_ mirrored) until I get a positive feedback that
git-cvsserver works flawlessly (or that everybody has migrated to Github).

Markus

[1] :pserver:anonymous@...:/ecf
[2] http://github.com/lemmy/ecf-nonepl
[3] :pserver:anonymous@...:62401/gitcvs
[4] http://www.kernel.org/pub/software/scm/git/docs/git-cvsserver.html
_______________________________________________
ecf-dev mailing list
ecf-dev@...
https://dev.eclipse.org/mailman/listinfo/ecf-dev

From forum: Eclipse ECF - Dev

Re: link-local-messaging-client into ECF

2009-12-07T09:10:53Z

Hi Markus,
No my implementation is not publicly available already, but I try to write a
plugin for eclipse/ecf to make it available.

Roland

Zitat von Markus Alexander Kuppe <ecf-dev_eclipse.org@...>:

> On 12/07/2009 12:18 AM, Roland Matha wrote:
> > Hi Folks,
> > In the last weeks i wrote a link-local-messaging-client that works fine. I
> will
> > ask if someone can help me to integrate it yet into the ECF.
> > Is already a help for me, when I know which interfaces must be implemented.
>
> Hi Roland,
>
> I'm not an expert on the EF messaging API, but I'd like to see shared
> editing use link-local-messaging underneath. Is you implementation
> publicly available already?
>
> Markus
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@...
> https://dev.eclipse.org/mailman/listinfo/ecf-dev
>

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

From forum: Eclipse ECF - Dev

Re: rest API work

2009-12-07T09:02:34Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Scott, Hi Holger

sorry, for being too quick with my posts. I guess your API suggests to
subclass IRestCallable and augment it to have request entities.
Am I right?

Greets + Thanks
André

Andre Dietisheim wrote:

> Hi Scott, Hi Holger
>
> I'm currently catching up with the latest incarnation of the ECF REST
> API. I noticed that you removed the possibility to include request
> entities that was present in the former version (parameter's gone in the
> RestCall and RestCallFactory).
> IMHO request entites are quite common to post calls. How do you suggest
> to deal with them? Subclass the factory?
>
> Greetings + Thanks
> André
>
> Scott Lewis wrote:
>> Hi Folks,
>
>> As per bug [1] there's been some work on simplifying Holger's most
>> excellent REST API (as well as better leveraging the ECF remote services
>> API). These refactorings have now been released to head. See [2] for
>> up-to-date javadocs, and [3] for access to the source code. See
>> particularly the test code in org.eclipse.ecf.tests.remoteservice.rest
>> for usage examples...but more example code is coming. If others use the
>> API and have example code, as usual all contributions will be
>> appreciated. As well, it would be great to integrate this API into
>> TweetHub for accessing the twitter service sometime soon.
>
>> With the improved integration with ECF remote services, it's now easily
>> possible to expose an arbitrary rest-based service as an ECF remote
>> service. (e.g. twitter...or your favorite rest-based service). It's
>> *not* necessary to have the service be exposed via an ECF-based
>> server/service (that is, any rest-based serviced can be accessed as a
>> remote service).
>
>> We also have IP approval to use and distribute the json.org JSON parser
>> implementation, so that those rest services that use json as the
>> resource representation can parse JSON resources. The json.org parser
>> is now a bundle included in our dev.eclipse.org build: org.json.
>> Eventually, this bundle will probably move to Orbit, but in the mean
>> time we will build it and deploy it with ECF.
>
>> Any thoughts/comments appreciated.
>
>> Scott
>
>> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=294774
>> [2] http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/
>> (org.eclipse.ecf.remoteservice.rest.* packages)
>> [3] http://wiki.eclipse.org/REST_abstraction_for_ECF
>> _______________________________________________
>> ecf-dev mailing list
>> ecf-dev@...
>> https://dev.eclipse.org/mailman/listinfo/ecf-dev
>
>

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

- --
André Dietisheim
Head of Eclipse Development

Puzzle ITC GmbH
www.puzzle.ch

Telefon +41 31 370 22 00
Fax +41 31 370 22 01
Mobile +41 76 423 03 02

Abonnieren Sie unsere News:
<http://www.puzzle.ch/follow-us>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksdNSoACgkQxpTsx9UecrmtCgCfU5ChG1XvYce+4fMosPZC6QUV
4fQAnjxuK9DWP1rPDwyGSX9zMPsIr4kD
=afkh
-----END PGP SIGNATURE-----
_______________________________________________
ecf-dev mailing list
ecf-dev@...
https://dev.eclipse.org/mailman/listinfo/ecf-dev

From forum: Eclipse ECF - Dev

Re: link-local-messaging-client into ECF

2009-12-07T09:00:12Z

On 12/07/2009 12:18 AM, Roland Matha wrote:
> Hi Folks,
> In the last weeks i wrote a link-local-messaging-client that works fine. I will
> ask if someone can help me to integrate it yet into the ECF.
> Is already a help for me, when I know which interfaces must be implemented.

Hi Roland,

I'm not an expert on the EF messaging API, but I'd like to see shared
editing use link-local-messaging underneath. Is you implementation
publicly available already?

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

From forum: Eclipse ECF - Dev

Re: Remote services and the Enterprise Early Draft

2009-12-07T09:00:02Z

On 12/05/2009 04:24 PM, Bryan Hunt wrote:
> Hi Scott,
>
> What are your plans relative the the new specs around remote services in the Enterprise Early Draft? Who is going to implement the new discovery spec? Will that live as part of ECF, or be part of Gemini? Depending on the timeframe and my personal schedule, I may be interested in working on this.

Hi Bryan,

I'd be interested to collaboratively work with you on the discovery
portion of remote services. Why not start off with a bug to sketch out a
possible design?

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

From forum: Eclipse ECF - Dev

Helios and PTP 3.0/Photran 5.0 branch

2009-12-07T08:55:27Z

We need to begin preparation for the 4.0/6.0 release to coincide with the Helios release next June. In particular, we need to be part of the M4 build at the end of this week.

I'm planning to create a ptp_3_0/photran_5_0 branch today. HEAD will then become 4.0/6.0.

Jeff, as Photran is likely to be the most impacted by this, you probably need to get Eclipse 3.6/CDT 7.0 installed and take a look asap.

If anyone has any problems with this, let me know.

Greg_______________________________________________
ptp-dev mailing list
ptp-dev@...
https://dev.eclipse.org/mailman/listinfo/ptp-dev

From forum: Eclipse Parallel Tools - Dev

Re: rest API work

2009-12-07T08:48:05Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Scott, Hi Holger

I'm currently catching up with the latest incarnation of the ECF REST
API. I noticed that you removed the possibility to include request
entities that was present in the former version (parameter's gone in the
RestCall and RestCallFactory).
IMHO request entites are quite common to post calls. How do you suggest
to deal with them? Subclass the factory?

Greetings + Thanks
André

Scott Lewis wrote:

> Hi Folks,
>
> As per bug [1] there's been some work on simplifying Holger's most
> excellent REST API (as well as better leveraging the ECF remote services
> API). These refactorings have now been released to head. See [2] for
> up-to-date javadocs, and [3] for access to the source code. See
> particularly the test code in org.eclipse.ecf.tests.remoteservice.rest
> for usage examples...but more example code is coming. If others use the
> API and have example code, as usual all contributions will be
> appreciated. As well, it would be great to integrate this API into
> TweetHub for accessing the twitter service sometime soon.
>
> With the improved integration with ECF remote services, it's now easily
> possible to expose an arbitrary rest-based service as an ECF remote
> service. (e.g. twitter...or your favorite rest-based service). It's
> *not* necessary to have the service be exposed via an ECF-based
> server/service (that is, any rest-based serviced can be accessed as a
> remote service).
>
> We also have IP approval to use and distribute the json.org JSON parser
> implementation, so that those rest services that use json as the
> resource representation can parse JSON resources. The json.org parser
> is now a bundle included in our dev.eclipse.org build: org.json.
> Eventually, this bundle will probably move to Orbit, but in the mean
> time we will build it and deploy it with ECF.
>
> Any thoughts/comments appreciated.
>
> Scott
>
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=294774
> [2] http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/
> (org.eclipse.ecf.remoteservice.rest.* packages)
> [3] http://wiki.eclipse.org/REST_abstraction_for_ECF
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@...
> https://dev.eclipse.org/mailman/listinfo/ecf-dev

- --
André Dietisheim
Head of Eclipse Development

Puzzle ITC GmbH
www.puzzle.ch

Telefon +41 31 370 22 00
Fax +41 31 370 22 01
Mobile +41 76 423 03 02

Abonnieren Sie unsere News:
<http://www.puzzle.ch/follow-us>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksdMcUACgkQxpTsx9Uecrl7eQCeKMtX45zyMfBASrlwqqm27Iho
vOsAnRUfJUMpNNomk0i6/m95FAPhOX0g
=bgZX
-----END PGP SIGNATURE-----
_______________________________________________
ecf-dev mailing list
ecf-dev@...
https://dev.eclipse.org/mailman/listinfo/ecf-dev

From forum: Eclipse ECF - Dev

Re: AW: running [criteria] server tests on server with JPA 1.0 container

2009-12-07T08:09:44Z

Hi Adrian,

I have asked that the testing issues be included in the EclipseLink 2.1
planning. Hopefully we can have a discussion about this in planning meeting for
2.1.

-Tom

Goerler, Adrian wrote:

> Hi Tom,
>
> the eclipselink.jpa.wdf.tests are basically 1.0 tests. We used to execute them on the NetWeaver Server through a proprietary framework which is not open source. The mechanism for server-testing used for eclipselink.jpa.tests won't work out of the box as the WDF tests don't extend TestCase and we hence can't override the runBare method.
>
> But I'm confident that we'd find some way to execute them on the server.
>
> Before we do so, however, I think we should take care that the eclipselink.jpa.wdf.tests are executed standalone regularly in order to avoid regressions (there are already some). Shaun suggested that we could include them into the JPA-LRG test set, e.g..
>
> Adrian Görler
> SAP AG
>
> Pflichtangaben/Mandatory Disclosure Statements: http://www.sap.com/company/legal/impressum.epx
>
>
> -----Ursprüngliche Nachricht-----
> Von: eclipselink-dev-bounces@... [mailto:eclipselink-dev-bounces@...] Im Auftrag von Tom Ware
> Gesendet: Montag, 7. Dezember 2009 15:07
> An: Dev mailing list for Eclipse Persistence Services
> Betreff: Re: [eclipselink-dev] running [criteria] server tests on server with JPA 1.0 container
>
> Hi Adrian,
>
> This is an issue that we need to address. I believe there are two things we
> need to do to address this.
>
> 1. For each supported application server, we need to figure out what
> configuration options we can use to deploy a JPA 2.0 application, likely an
> application-managed one. (i.e. Is there a way the application and the server
> can be configured to avoid things like JPA 1.0 injection so that the JPA
> annotations and API can be used by users) We then need to make the necessary
> changes to our test framework to allow those configurations to work. We have
> already started working looking for configuration options on WebLogic and have
> had some success. We should start that work for other servers as well.
>
> 2. We need a JPA 1.0 regression test framework. Candidates for that test
> framework are the EclipseLink 1.1.x test framework and possibly the new
> eclipselink.jpa.wdf.test classes. I am not particularly familiar with the
> eclipselink.jpa.wdf.test classes. Do you know if they can be configured to do
> JPA 1.0 testing on the server?
>
> -Tom
>
> Goerler, Adrian wrote:
>> Hi,
>>
>> we are attempting to run the JPA server tests on NetWeaver 7.1, which
>> has a JPA 1.0 container. The container sees JPA 1.0 jars and wraps
>> entity managers with a JPA 1.0 interface.
>>
>> Now, the criteria tests are failing as they attempt to invoke the
>> getCriteriaBuilder method, which does not exist in JPA 1.0.
>>
>> There is a check in the CriteriaServerTestSuite.suite method, which
>> should prevent the tests from being executed:
>>
>> *public* *static* Test suite() {
>> TestSuite suite = *new* TestSuite();
>> suite.setName("Criteria ServerTestSuite");
>> >>>> *if* (! JUnitTestCase./isJPA10/()) {
>> suite.addTest(AdvancedCompositePKJunitTest./suite/());
>> suite.addTest(AdvancedCriteriaQueryTestSuite./suite/());
>> suite.addTest(AdvancedQueryTestSuite./suite/());
>> suite.addTest(JUnitCriteriaSimpleTestSuite./suite/());
>> suite.addTest(JUnitCriteriaUnitTestSuite./suite/());
>>
>> suite.addTest(org.eclipse.persistence.testing.tests.jpa.criteria.metamodel.JUnitCriteriaSimpleTestSuite./suite/());
>>
>> }
>> *return* suite;
>> }
>>
>>
>> However, the check is executed on the client side, which sees JPA 2 and
>> hence JUnitTestCase./isJPA10/() returns false on the client.
>> Consequently, the criteria tests are executed and fail on NetWeaver.
>>
>>
>> The situation raises some questions:
>>
>>
>> * How should we deal with the particular case of the criteria queries?
>>
>> * Should we alter the JUnitTestCase./isJPA10/()method so that it
>> checks on the server side?
>> * Should we shift the JUnitTestCase./isJPA10/() method to the 200
>> individual tests?
>>
>> * How should we deal with 1.0 containers in general?
>>
>> * Should we indicate the JPA container version in the
>> <server>.properties files and check for it (e.g. in build.xml or
>> at runtime)?
>>
>> * How can we make visible that tests are not skipped on a server
>> with JPA 1.0 container?
>>
>>
>>
>> -Adrian
>>
>> ---
>>
>> *Adrian Görler
>> **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

From forum: EclipseLink - Dev

Re: PTP 3.0/Photran 5.0 release now available

2009-12-07T08:06:17Z

The release is build 200912042036. I've also tagged it as PTP_3_0.

Greg

On Dec 5, 2009, at 12:10 PM, Orion Poplawski wrote:

> On 12/05/2009 08:12 AM, Greg Watson wrote:
>> We are very pleased to announce the combined release of PTP 3.0 and Photran 5.0. This release includes a wide variety of improvements to the core platform, as well as incorporating Fortran language support for the first time. Other improvements include enhancements to the External Tools Framework, bug fixes and improvements to the Remote Development Tools, and a new MPI analysis tool called In-situ Partial Analysis.
>>
>> The 3.0 release is available for download from http://eclipse.org/ptp/downloads.php
>>
>> More details on the new features are available at http://wiki.eclipse.org/PTP/new_and_noteworthy/3.0.0
>>
>> Detailed release notes are available from http://wiki.eclipse.org/PTP/release_notes/3.0
>>
>> Help for installing and using Photran is available from http://wiki.eclipse.org/PTP/photran/documentation
>>
>> Thanks for the hard work from everyone who contributed to making this release a success!
>>
>> Greg_______________________________________________
>> ptp-dev mailing list
>> ptp-dev@...
>> https://dev.eclipse.org/mailman/listinfo/ptp-dev
>
> So, what cvs tag corresponds to the 3.0 release? I'd like to suggest that releases get tagged with a release tag as well (e.g. ptp_3_0_0).
>
> Thanks!
>
> --
> Orion Poplawski
> Technical Manager 303-415-9701 x222
> NWRA/CoRA Division FAX: 303-415-9702
> 3380 Mitchell Lane orion@...
> Boulder, CO 80301 http://www.cora.nwra.com
> _______________________________________________
> ptp-dev mailing list
> ptp-dev@...
> https://dev.eclipse.org/mailman/listinfo/ptp-dev

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

From forum: Eclipse Parallel Tools - Dev

RE: EclipseLink 1.2 Planning

2009-12-07T07:57:51Z

Please make sure you add yourself to the cc list of bugs your are interested in so we can discuss the enhancements within the bug and you are notified of changes made to the bug.

Doug

-----Original Message-----
From: Tim Hollosy [mailto:hollosyt@...]
Sent: December 4, 2009 11:37 PM
To: EclipseLink User Discussions
Subject: Re: [eclipselink-users] EclipseLink 1.2 Planning

I voted for the Validation Support bug. I believe Hibernate already
supports this, I'd like to see EclipseLink stay ahead there.

./tch

On Fri, Dec 4, 2009 at 8:27 PM, Samba <saasira@...> wrote:

> Hi Doug/Peter,
>
>     I would want to see the bugs listed below getiing fixed in eclipselink
> 2.1.
>
> Bug 260258 - Add SessionBroker support
> Bug 280949 - Proposed Incubator: Add Data Partitioning Support
> Bug 241698 - Add Validation Support
> Further, I would also like to see a pluggable cache implementaion support in
> eclipselink 2.1, for which I could not find any bugzilla entry.
>
>    These are the features that Hibernate has but eclipselink does not have;
> of course, the feature set of eclipselink is so vast but it is always to
> good to have
>    more features, provided people need those features.
>
>    I'm interested in contributing to the Bug 280949 if you can give me a few
> pointers.
>
> Thanks and Regards,
> Samba
>
> On Tue, Dec 1, 2009 at 7:46 AM, Douglas Clarke <DOUGLAS.CLARKE@...>
> wrote:
>
>>
>> EclipseLink Users, Contributors, and Committers,
>>
>> We are wrapping up EclipseLink 2.0 now and need to start working towards
>> EclipseLink 2.1 which will be our Helios release in June. We have
>> accomplished a lot in the last year around standards delivering the
>> reference implementation of SDO 2.1.1 and now JPA 2.0 as well as addressing
>> JAXB 2.1 compliance and many advanced capabilities in all areas of the
>> project. Over the next 2 weeks we need to formalize our 2.1 themes and
>> requirements. Peter and I have started a wiki page for this purpose:
>>
>> http://wiki.eclipse.org/EclipseLink/Development/2.1
>>
>> We are asking all interested parties to help us shape what is coming in
>> the 2.1 release as well as future releases by participating in the process.
>> Please make sure your issues and enhancement requests are captured in bugs
>> with clear descriptions and actionable outcomes. We will be basing our work
>> for this next cycle on the themes we agree upon in an upcoming committer
>> meeting as well as the bug backlog in bugzilla. Make sure if you want an
>> issue addressed that you vote for the bug and/or start a thread on the forum
>> to discuss how the project should address your requirements so that others
>> can become aware of the issue and the bug number so they can vote as well.
>>
>> As always, bugs with patches supplied will be prioritized as we greatly
>> appreciate the additional effort it takes to contribute. All feedback on
>> this process and the project in general is appreciated.
>>
>> Cheers,
>>
>> Doug Clarke & Peter Krogh
>> EclipseLink Project Leads
>> _______________________________________________
>> eclipselink-users mailing list
>> eclipselink-users@...
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>
>>
>
>
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@...
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>
>

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

From forum: EclipseLink - Users

Q: FetchPan Extension and JPQL Query Cache

2009-12-07T07:48:33Z

Committers,

I have been working with some customers on the http://wiki.eclipse.org/EclipseLink/Development/Incubator/Extensions/FetchPlan extension incubator. This functionality uses a QueryRedirector to post process a query forcing specified relationships to be instantiated so that the resulting entities are available to serialize with the required depth of relationships. The extension also stores the FetchPlan within the native query using its properties.

The challenge I am running into is that our JPQL based query cache stores native queries based on the JPQL string used to create them. If you then modify the state of the native query by unwrapping it from the JPA query instance you are in fact modifying the cached native query. This means that the subsequent EntityManager.createQuery("...") calls with the same JPQL string will get the cached native query with the previous configurations applied which means we are leaking config between query executions.

Before filing bugs on the issue I wanted to figure out who knows this code best and can help me work-around it effectively in the shipped versions and what we should be doing going forward.

Q1: Is there a way to avoid using the query cache when requesting the query's creation?

Q2: Is there a recommended way to avoid corrupting the query cache when modifying the native query?

Doug

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

From forum: EclipseLink - Dev