Nabble - OpenJPA Developers

[jira] Commented: (OPENJPA-1377) JPA property to enum conversion failure

2009-11-06T14:48:32Z

[ https://issues.apache.org/jira/browse/OPENJPA-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12774467#action_12774467 ]

Albert Lee commented on OPENJPA-1377:
-------------------------------------

Per spec:

3.6.1.1 Enabling Automatic Validation
The validation-mode element of the persistence.xml file determines whether the automatic
lifecycle event validation is in effect. The values of the validation-mode element are AUTO,
CALLBACK, NONE. The default validation mode is AUTO.

If the application creates the entity manager factory using the Persistence.createEntityManagerFactory
method, the validation mode can be specified using the javax.persistence.
validation.mode map key, which will override the value specified (or defaulted) in the
persistence.xml file. The map values for this key are "auto", "callback", "none"

Enum values are in upper case and corresponding properties are in lowercase. Need to convert to upper case before converting to its enum value.

> JPA property to enum conversion failure
> ---------------------------------------
>
> Key: OPENJPA-1377
> URL: https://issues.apache.org/jira/browse/OPENJPA-1377
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0-M3, 2.0.0
> Reporter: Albert Lee
> Assignee: Albert Lee
> Fix For: 2.0.0
>
>
> Exception occurred during JPA property to equivalent enum conversion:
> java.lang.IllegalArgumentException: No enum const class javax.persistence.ValidationMode.callback
> at java.lang.Enum.valueOf(Enum.java:196)
> at org.apache.openjpa.persistence.JPAProperties.getEnumValue(JPAProperties.java:156)
> at org.apache.openjpa.persistence.JPAProperties.getEnumValue(JPAProperties.java:147)
> at org.apache.openjpa.persistence.PersistenceUnitInfoImpl.fromUserProperties(PersistenceUnitInfoImpl.java:325)
> at org.apache.openjpa.persistence.PersistenceProductDerivation$ConfigurationParser.endElement(PersistenceProductDerivation.java:734)
> at org.apache.openjpa.lib.meta.XMLMetaDataParser.endElement(XMLMetaDataParser.java:456)
> at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.endElement(Unknown Source)
> at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
> at org.apache.openjpa.lib.meta.XMLMetaDataParser.parseNewResource(XMLMetaDataParser.java:393)
> at org.apache.openjpa.lib.meta.XMLMetaDataParser.parse(XMLMetaDataParser.java:334)
> at org.apache.openjpa.lib.meta.XMLMetaDataParser.parse(XMLMetaDataParser.java:311)
> at org.apache.openjpa.lib.meta.XMLMetaDataParser.parse(XMLMetaDataParser.java:284)
> at org.apache.openjpa.persistence.PersistenceProductDerivation$ConfigurationParser.parse(PersistenceProductDerivation.java:671)
> at org.apache.openjpa.persistence.PersistenceProductDerivation.parseResources(PersistenceProductDerivation.java:479)
> at org.apache.openjpa.persistence.PersistenceProductDerivation.load(PersistenceProductDerivation.java:449)
> at org.apache.openjpa.persistence.PersistenceProductDerivation.load(PersistenceProductDerivation.java:271)
> at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:83)
> at com.ibm.websphere.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:73)
> at com.ibm.websphere.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:43)
> at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:151)
> at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:59)
> at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:159)
> at suite.r80.base.jpaspec.validation.basic.JSE_BasicTest.setupTestEnvironmentModeBasicEMFPropOvrCallback(JSE_BasicTest.java:486)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1377) JPA property to enum conversion failure

2009-11-06T14:44:32Z

JPA property to enum conversion failure
---------------------------------------

Key: OPENJPA-1377
URL: https://issues.apache.org/jira/browse/OPENJPA-1377
Project: OpenJPA
Issue Type: Bug
Components: kernel
Affects Versions: 2.0.0-M3, 2.0.0
Reporter: Albert Lee
Assignee: Albert Lee
Fix For: 2.0.0

Exception occurred during JPA property to equivalent enum conversion:

java.lang.IllegalArgumentException: No enum const class javax.persistence.ValidationMode.callback
at java.lang.Enum.valueOf(Enum.java:196)
at org.apache.openjpa.persistence.JPAProperties.getEnumValue(JPAProperties.java:156)
at org.apache.openjpa.persistence.JPAProperties.getEnumValue(JPAProperties.java:147)
at org.apache.openjpa.persistence.PersistenceUnitInfoImpl.fromUserProperties(PersistenceUnitInfoImpl.java:325)
at org.apache.openjpa.persistence.PersistenceProductDerivation$ConfigurationParser.endElement(PersistenceProductDerivation.java:734)

at org.apache.openjpa.lib.meta.XMLMetaDataParser.endElement(XMLMetaDataParser.java:456)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaValidator.endElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
at org.apache.openjpa.lib.meta.XMLMetaDataParser.parseNewResource(XMLMetaDataParser.java:393)
at org.apache.openjpa.lib.meta.XMLMetaDataParser.parse(XMLMetaDataParser.java:334)
at org.apache.openjpa.lib.meta.XMLMetaDataParser.parse(XMLMetaDataParser.java:311)
at org.apache.openjpa.lib.meta.XMLMetaDataParser.parse(XMLMetaDataParser.java:284)
at org.apache.openjpa.persistence.PersistenceProductDerivation$ConfigurationParser.parse(PersistenceProductDerivation.java:671)
at org.apache.openjpa.persistence.PersistenceProductDerivation.parseResources(PersistenceProductDerivation.java:479)
at org.apache.openjpa.persistence.PersistenceProductDerivation.load(PersistenceProductDerivation.java:449)
at org.apache.openjpa.persistence.PersistenceProductDerivation.load(PersistenceProductDerivation.java:271)
at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:83)
at com.ibm.websphere.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:73)
at com.ibm.websphere.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:43)
at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:151)
at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:59)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:159)
at suite.r80.base.jpaspec.validation.basic.JSE_BasicTest.setupTestEnvironmentModeBasicEMFPropOvrCallback(JSE_BasicTest.java:486)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: version field dont work when used in the embeddable class

2009-11-05T09:13:10Z

In current openjpa implementation, version field in the embeddable is not supported. The rationale is embeddable is not an identifiable object, it can not be modified independently of its owning entity, so there is no need for the version field in the embeddable to keep track of its change. Also, unlike inheritance, the version field in the embeddable is not propogated to its owning entity. Think of an example of an entity which has many embeddable fields or a collection of embeddables, if every embeddable has its own version field, and if they are all propagated to the owning entity, the owning entity may end up with multiple version fields. which is not allowed.

----- Original Message ----
From: "[hidden email]" <[hidden email]>
To: [hidden email]
Sent: Thu, November 5, 2009 12:06:45 AM
Subject: version field dont work when used in the embeddable class

Hi
In my application I have an embeddable class that contain some common fields
including version field .when I put version field in the main class
everything is good and OpenJPA increment the version field value and throw
optimistic exception when concurrent write occur .But when I put the version
field on the embeddable class openJPA don’t do anything. Is this is a bug
in the OpenJPA ? or I am misusing the embeddable class?
Please help me
Thanks
Ahad Javadi

--
View this message in context: http://n2.nabble.com/version-field-dont-work-when-used-in-the-embeddable-class-tp3950794p3950794.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.

version field dont work when used in the embeddable class

2009-11-05T00:06:45Z

Hi
In my application I have an embeddable class that contain some common fields including version field .when I put version field in the main class everything is good and OpenJPA increment the version field value and throw optimistic exception when concurrent write occur .But when I put the version field on the embeddable class openJPA don’t do anything. Is this is a bug in the OpenJPA ? or I am misusing the embeddable class?
Please help me
Thanks
Ahad Javadi

[jira] Updated: (OPENJPA-1376) @GeneratedValue allocationSize incorrect implementation

2009-11-04T15:51:32Z

[ https://issues.apache.org/jira/browse/OPENJPA-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yves updated OPENJPA-1376:
--------------------------

Remaining Estimate: 8h (was: 0.13h)
Original Estimate: 8h (was: 0.13h)

> @GeneratedValue allocationSize incorrect implementation
> -------------------------------------------------------
>
> Key: OPENJPA-1376
> URL: https://issues.apache.org/jira/browse/OPENJPA-1376
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
> Affects Versions: 1.2.1, 2.0.0-M3
> Environment: All
> Reporter: Yves
> Priority: Critical
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> OpenJpa use allocationSize parameter on NativeJDBCSeq to set the sequence cache value.
> But one "JSR 220: Enterprise JavaBeansTM,Version 3.0" , the allocationSize is : "The amount to increment by when allocating sequence
> numbers from the sequence."
> Allocating is used to limit the number of access to the sequence or table not to set the sequence cache value !
> If allocationSize=50, the sequence need to be call one time on each 50 call on AbstractJDBCSeq.next().
> 1 call on AbstractJDBCSeq.next(). call the sequence or table
> 2 call : return previous value + 1;
> 3 call : return previous value + 2;
> ...
> 51 call :re-call the sequence
> 52 return previous value + 1
> ...

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1376) @GeneratedValue allocationSize incorrect implementation

2009-11-04T15:49:32Z

@GeneratedValue allocationSize incorrect implementation
-------------------------------------------------------

Key: OPENJPA-1376
URL: https://issues.apache.org/jira/browse/OPENJPA-1376
Project: OpenJPA
Issue Type: Bug
Components: jdbc
Affects Versions: 2.0.0-M3, 1.2.1
Environment: All
Reporter: Yves
Priority: Critical

OpenJpa use allocationSize parameter on NativeJDBCSeq to set the sequence cache value.

But one "JSR 220: Enterprise JavaBeansTM,Version 3.0" , the allocationSize is : "The amount to increment by when allocating sequence
numbers from the sequence."

Allocating is used to limit the number of access to the sequence or table not to set the sequence cache value !

If allocationSize=50, the sequence need to be call one time on each 50 call on AbstractJDBCSeq.next().

1 call on AbstractJDBCSeq.next(). call the sequence or table
2 call : return previous value + 1;
3 call : return previous value + 2;
...
51 call :re-call the sequence
52 return previous value + 1
...

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (OPENJPA-1375) OutOfMemory runs in container environment in a long stress run

2009-11-06T07:50:32Z

[ https://issues.apache.org/jira/browse/OPENJPA-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Albert Lee closed OPENJPA-1375.
-------------------------------

> OutOfMemory runs in container environment in a long stress run
> --------------------------------------------------------------
>
> Key: OPENJPA-1375
> URL: https://issues.apache.org/jira/browse/OPENJPA-1375
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 1.3.0, 2.0.0-M3
> Reporter: Albert Lee
> Assignee: Albert Lee
> Fix For: 1.3.0, 2.0.0
>
>
> Long stress run in the app server/container environment caused a OutOfMemoery exception with a heap dump that showed the following:
> FetchConfigurationImpl$ConfigurationState
> + WsJpaFetchConfigurationImpl
> + Array of Object
> + IdentityHashMap
> + EntityManagerImpl
> What happened is the container pooled the entity manager and clear the context when a transaction is completed. However the IdentityHashMap in EntityManagerImpl, which maps the fetch configuration to fetch plan, is not being flush/clear. This caused the growth of the IdentityHashMap and eventually the OOM in a long run.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OPENJPA-1375) OutOfMemory runs in container environment in a long stress run

2009-11-06T07:50:32Z

[ https://issues.apache.org/jira/browse/OPENJPA-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Albert Lee resolved OPENJPA-1375.
---------------------------------

Resolution: Fixed

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-1375) OutOfMemory runs in container environment in a long stress run

2009-11-05T14:31:32Z

[ https://issues.apache.org/jira/browse/OPENJPA-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Albert Lee updated OPENJPA-1375:
--------------------------------

Affects Version/s: 1.3.0
Fix Version/s: 1.3.0

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1375) OutOfMemory runs in container environment in a long stress run

2009-11-04T13:57:32Z

OutOfMemory runs in container environment in a long stress run
--------------------------------------------------------------

Key: OPENJPA-1375
URL: https://issues.apache.org/jira/browse/OPENJPA-1375
Project: OpenJPA
Issue Type: Bug
Components: kernel
Affects Versions: 2.0.0-M3
Reporter: Albert Lee
Assignee: Albert Lee
Fix For: 2.0.0

Long stress run in the app server/container environment caused a OutOfMemoery exception with a heap dump that showed the following:

FetchConfigurationImpl$ConfigurationState
+ WsJpaFetchConfigurationImpl
+ Array of Object
+ IdentityHashMap
+ EntityManagerImpl

What happened is the container pooled the entity manager and clear the context when a transaction is completed. However the IdentityHashMap in EntityManagerImpl, which maps the fetch configuration to fetch plan, is not being flush/clear. This caused the growth of the IdentityHashMap and eventually the OOM in a long run.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1374) Enable junits to be executed against an in-memory Derby 10.5.3.0 db

2009-11-04T13:02:33Z

Enable junits to be executed against an in-memory Derby 10.5.3.0 db
-------------------------------------------------------------------

Key: OPENJPA-1374
URL: https://issues.apache.org/jira/browse/OPENJPA-1374
Project: OpenJPA
Issue Type: Improvement
Components: build / infrastructure
Affects Versions: 2.0.0-M3
Reporter: Donald Woods
Assignee: Donald Woods
Priority: Minor
Fix For: 2.0.0-M4

Create a test profile that will enable the easy usage of an In-Memory Derby 10.5.3.0 DB for unit tests.
http://wiki.apache.org/db-derby/InMemoryBackEndPrimer
Initial testing on my Mac shows a 50% reduction in time to run the o-p-j bucket compared to the current test-derby profile....

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: cwiki problems?

2009-11-02T07:55:50Z

I opened INFRA-2302 for this....

-Donald

Donald Woods wrote:

> Several of us are trying to edit our OpenJPA space and keep getting the
> below message when we try to save a page edit. The weird thing, is we
> get a Confluence generated email to our commits@ list, but the changes
> are not reflected on the Confluence page.
>
>
> Proxy Error
>
> The proxy server received an invalid response from an upstream server.
> The proxy server could not handle the request POST
> /confluence/pages/doeditpage.action.
>
> Reason: Error reading from remote server
>
> Apache/2.2.13 (Unix) mod_ssl/2.2.13 OpenSSL/0.9.8g Server at
> cwiki.apache.org Port 80
>
>
> Any ideas?
>
>
> -Donald
>

cwiki problems?

2009-11-02T07:52:33Z

Several of us are trying to edit our OpenJPA space and keep getting the
below message when we try to save a page edit. The weird thing, is we
get a Confluence generated email to our commits@ list, but the changes
are not reflected on the Confluence page.

Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request POST
/confluence/pages/doeditpage.action.

Reason: Error reading from remote server

Apache/2.2.13 (Unix) mod_ssl/2.2.13 OpenSSL/0.9.8g Server at
cwiki.apache.org Port 80

Any ideas?

-Donald

[jira] Created: (OPENJPA-1373) OpenJPA 2.0 iteration 13 primary task

2009-11-02T07:12:59Z

OpenJPA 2.0 iteration 13 primary task
-------------------------------------

Key: OPENJPA-1373
URL: https://issues.apache.org/jira/browse/OPENJPA-1373
Project: OpenJPA
Issue Type: New Feature
Components: jpa
Affects Versions: 2.0.0-M4
Reporter: Jeremy Bauer
Assignee: Jeremy Bauer

This is the parent task for OpenJPA iteration 13. The iteration 13 development period is from Nov 2nd - Dec 4th. Features to be completed during this iteration must be assigned as a subtask to this task. The JPA 2.0 Roadmap [1] will contain iteration 12 features and tracking information.

[1] http://cwiki.apache.org/confluence/display/openjpa/JPA+2.0+Roadmap

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-1373) OpenJPA 2.0 iteration 13 primary task

2009-11-02T07:12:59Z

[ https://issues.apache.org/jira/browse/OPENJPA-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeremy Bauer updated OPENJPA-1373:
----------------------------------

Description:
This is the parent task for OpenJPA iteration 13. The iteration 13 development period is from Nov 2nd - Dec 4th. Features to be completed during this iteration must be assigned as a subtask to this task. The JPA 2.0 Roadmap [1] will contain iteration 13 features and tracking information.

[1] http://cwiki.apache.org/confluence/display/openjpa/JPA+2.0+Roadmap

was:
This is the parent task for OpenJPA iteration 13. The iteration 13 development period is from Nov 2nd - Dec 4th. Features to be completed during this iteration must be assigned as a subtask to this task. The JPA 2.0 Roadmap [1] will contain iteration 12 features and tracking information.

[1] http://cwiki.apache.org/confluence/display/openjpa/JPA+2.0+Roadmap

> OpenJPA 2.0 iteration 13 primary task
> -------------------------------------
>
> Key: OPENJPA-1373
> URL: https://issues.apache.org/jira/browse/OPENJPA-1373
> Project: OpenJPA
> Issue Type: New Feature
> Components: jpa
> Affects Versions: 2.0.0-M4
> Reporter: Jeremy Bauer
> Assignee: Jeremy Bauer
>
> This is the parent task for OpenJPA iteration 13. The iteration 13 development period is from Nov 2nd - Dec 4th. Features to be completed during this iteration must be assigned as a subtask to this task. The JPA 2.0 Roadmap [1] will contain iteration 13 features and tracking information.
> [1] http://cwiki.apache.org/confluence/display/openjpa/JPA+2.0+Roadmap

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-1372) Generating identifiers by using sequence table may fail during sequence table initialization

2009-10-31T14:29:59Z

[ https://issues.apache.org/jira/browse/OPENJPA-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Milosz Tylenda updated OPENJPA-1372:
------------------------------------

Attachment: TestSequenceGenerationOnMT.java
GeneratedIdObject.java

> Generating identifiers by using sequence table may fail during sequence table initialization
> --------------------------------------------------------------------------------------------
>
> Key: OPENJPA-1372
> URL: https://issues.apache.org/jira/browse/OPENJPA-1372
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc, kernel
> Affects Versions: 1.2.1, 2.0.0-M3
> Reporter: Milosz Tylenda
> Attachments: GeneratedIdObject.java, TestSequenceGenerationOnMT.java
>
>
> When sequence table does not exist and mutliple threads get EntityManagers from EntityManageFactory, an insert into sequence table may fail because of duplicate primary key value.
> EMF is created lazily by default and users reported various problems with concurrent initialization (e.g. failures in resolving aliases in JPQL queries, IIRC) of EMF. This issue might have the same roots.
> Issue and test case originally reported by Pinaki in OPENJPA-466.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1372) Generating identifiers by using sequence table may fail during sequence table initialization

2009-10-31T14:27:59Z

Generating identifiers by using sequence table may fail during sequence table initialization
--------------------------------------------------------------------------------------------

Key: OPENJPA-1372
URL: https://issues.apache.org/jira/browse/OPENJPA-1372
Project: OpenJPA
Issue Type: Bug
Components: jdbc, kernel
Affects Versions: 2.0.0-M3, 1.2.1
Reporter: Milosz Tylenda

When sequence table does not exist and mutliple threads get EntityManagers from EntityManageFactory, an insert into sequence table may fail because of duplicate primary key value.

EMF is created lazily by default and users reported various problems with concurrent initialization (e.g. failures in resolving aliases in JPQL queries, IIRC) of EMF. This issue might have the same roots.

Issue and test case originally reported by Pinaki in OPENJPA-466.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-1371) Insert is called instead of Update when merge() with derived Identity

2009-10-31T17:43:59Z

[ https://issues.apache.org/jira/browse/OPENJPA-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772296#action_12772296 ]

Fay Wang commented on OPENJPA-1371:
-----------------------------------

During merge, openjpa needs to retrieve id from the entity to decide whether this is a new entity or a detached one. If it thinks it is a new entity, an INSERT will be perform. Otherwise, an Update statement will be executed.
If (1) an entity has the compound primary key using IdClass, and
(2) some field in the IdClass is a derived identity from a OneToOne/ManyToOne field,
(3) that value in that field has not yet become managed (i.e., does not have the StateManagerImpl yet),
this field in the IdClass will not be populated, as the primary key of the OneToOne/ManyToOne field usually can not be fetched back without an associated StateManagerImpl, unless it has a single-value primary key.

Currently openjpa returns the null value for this field in the IdClass regardlessly in the above situation. The patch provides a relief when this derived identity-relation field has a single value primary key. It should fix the problem reported by Constantine. However, the limitation for nested/multi-level compound primary (e.g. Stock entity has compound primary key using IdClass, and some value in the idClass is a derived-identity relation field, ...) during merge remains.

> Insert is called instead of Update when merge() with derived Identity
> ---------------------------------------------------------------------
>
> Key: OPENJPA-1371
> URL: https://issues.apache.org/jira/browse/OPENJPA-1371
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0-M3
> Reporter: Fay Wang
> Fix For: 2.0.0-M3
>
>
> Insert is called instead of Update when merge() with derived Identity:

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-1371) Insert is called instead of Update when merge() with derived Identity

2009-10-30T16:36:59Z

[ https://issues.apache.org/jira/browse/OPENJPA-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772179#action_12772179 ]

Fay Wang commented on OPENJPA-1371:
-----------------------------------

The following test scenario is provided by Constantine Kulak <[hidden email]>:

There are three entities where PrognosisEntry has derived identity:

***** Source for Prognosis.java:

@Entity(name = "Prognosis")
@Table(name = "PROGNOSIS")
@IdClass(Prognosis.PrognosisId.class)
@Inheritance(strategy = InheritanceType.JOINED)
public class Prognosis {

protected List<PrognosisEntry> entries;
protected String station;
protected String type;

@OneToMany(targetEntity = PrognosisEntry.class, cascade = {CascadeType.MERGE}, mappedBy="prognosis", fetch=FetchType.EAGER)
public List<PrognosisEntry> getEntries() {
if (entries == null) {
entries = new ArrayList<PrognosisEntry>();
}
return this.entries;
}

public void setEntries(List<PrognosisEntry> entries) {
this.entries = entries;
}

@Id
@Column(name = "STATION")
public String getStation() {
return station;
}

public void setStation(String value) {
this.station = value;
}

@Id
@Column(name = "TYPE_")
public String getType() {
return type;
}

public void setType(String value) {
this.type = value;
}

public boolean equals(Object object) { ... }
public int hashCode() { ... }

public static class PrognosisId {
protected String station;
protected String type;

public String getStation() {
return station;
}

public void setStation(String value) {
this.station = value;
}

public String getType() {
return type;
}

public void setType(String value) {
this.type = value;
}

public boolean equals(Object object) { ... }
public int hashCode() { ... }
}
}

***** Source for PrognosisEntry.java:

@Entity(name = "PrognosisEntry")
@Table(name = "PROGNOSISENTRY")
@Inheritance(strategy = InheritanceType.JOINED)
@IdClass(PrognosisEntry.PrognosisEntryId.class)
public class PrognosisEntry {

protected String timestamp;
protected String localState;
protected Prognosis prognosis;

protected Stock stock;

@Id
@ManyToOne(targetEntity = Stock.class, cascade = { CascadeType.MERGE }, fetch = FetchType.EAGER)
public Stock getStock() {
return stock;
}

public void setStock(Stock stock) {
this.stock = stock;
}

@Id
@ManyToOne(targetEntity = Prognosis.class, cascade = { CascadeType.MERGE }, fetch = FetchType.EAGER)
public Prognosis getPrognosis() {
return prognosis;
}

public void setPrognosis(Prognosis prognosis) {
this.prognosis = prognosis;
}

@Column(name = "TIMESTAMP_", length = 255)
public String getTimestamp() {
return timestamp;
}

public void setTimestamp(String value) {
this.timestamp = value;
}

@Basic
@Column(name = "LOCALSTATE", length = 255)
public String getLocalState() {
return localState;
}

public void setLocalState(String value) {
this.localState = value;
}

public boolean equals(Object object) { ... }
public int hashCode() { ... }

public static class PrognosisEntryId {

protected Prognosis.PrognosisId prognosis;
protected String stock;

public String getStock() {
return stock;
}

public void setStock(String stock) {
this.stock = stock;
}

public Prognosis.PrognosisId getPrognosis() {
return prognosis;
}

public void setPrognosis(Prognosis.PrognosisId prognosis) {
this.prognosis = prognosis;
}

public boolean equals(Object object) { ... }
public int hashCode() { ... }
}
}

***** Source for Stock.java:

@Entity(name = "Stock")
@Table(name = "STOCK")
@Inheritance(strategy = InheritanceType.JOINED)
public class Stock {
protected String index;
protected String length;

@Id
@Column(name = "INDEX_")
public String getIndex() {
return index;
}

public void setIndex(String value) {
this.index = value;
}
@Basic
@Column(name = "LENGTH_", length = 255)
public String getLength() {
return length;
}

public void setLength(String value) {
this.length = value;
}

public boolean equals(Object object) { ... }
public int hashCode() { ... }
}

The test scenario:
(1) create a Prognosis entity with a list of PrognosisEntry.
(2) call em.merge(newEntity) and commit
(3) call em.clear()
(4) call em.merge(newEntity)

Step (4) generate insert statement to insert PrognosisEntry again, resulting in unique constraint violation from the database.

It appears that the ApplicationIds.create(pc, meta) where pc is PrognosisEntry, the oid does not have complete id values.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1371) Insert is called instead of Update when merge() with derived Identity

2009-10-30T15:51:59Z

Insert is called instead of Update when merge() with derived Identity
---------------------------------------------------------------------

Key: OPENJPA-1371
URL: https://issues.apache.org/jira/browse/OPENJPA-1371
Project: OpenJPA
Issue Type: Bug
Components: kernel
Affects Versions: 2.0.0-M3
Reporter: Fay Wang
Fix For: 2.0.0-M3

Insert is called instead of Update when merge() with derived Identity:

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OPENJPA-1370) JPA2 missing implementation for createNamedQuery(String name, Class resultClass)

2009-11-02T09:34:59Z

[ https://issues.apache.org/jira/browse/OPENJPA-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Catalina Wei resolved OPENJPA-1370.
-----------------------------------

Resolution: Fixed
Fix Version/s: 2.0.0

> JPA2 missing implementation for createNamedQuery(String name, Class<T> resultClass)
> -----------------------------------------------------------------------------------
>
> Key: OPENJPA-1370
> URL: https://issues.apache.org/jira/browse/OPENJPA-1370
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
> Affects Versions: 2.0.0
> Reporter: Catalina Wei
> Assignee: Catalina Wei
> Fix For: 2.0.0
>
>
> Missing implementation for createNamedQuery(String name, Class<T> resultClass), when attempted, it reports
> UnsupportedOperationException()

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1370) JPA2 missing implementation for createNamedQuery(String name, Class resultClass)

2009-10-30T13:41:59Z

JPA2 missing implementation for createNamedQuery(String name, Class<T> resultClass)
-----------------------------------------------------------------------------------

Key: OPENJPA-1370
URL: https://issues.apache.org/jira/browse/OPENJPA-1370
Project: OpenJPA
Issue Type: Bug
Components: jpa
Affects Versions: 2.0.0
Reporter: Catalina Wei
Assignee: Catalina Wei

Missing implementation for createNamedQuery(String name, Class<T> resultClass), when attempted, it reports
UnsupportedOperationException()

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1369) Junit test failures (mostly Criteria and Lockmgr) with HSQLDB

2009-10-30T08:35:59Z

Junit test failures (mostly Criteria and Lockmgr) with HSQLDB
-------------------------------------------------------------

Key: OPENJPA-1369
URL: https://issues.apache.org/jira/browse/OPENJPA-1369
Project: OpenJPA
Issue Type: Bug
Components: third-party
Affects Versions: 2.0.0-M4
Reporter: Donald Woods
Priority: Minor
Fix For: 2.0.0

Seeing lots of junit failures with HSQLDB 1.8.0.10, with a majority of them in the Criteria tests -

openjpa-persistence-jdbc - Tests run: 2181, Failures: 158, Errors: 17, Skipped: 0
openjpa-persistence-locking - Tests run: 179, Failures: 64, Errors: 32, Skipped: 0

Failed tests:
testLeftFetchJoin(org.apache.openjpa.persistence.criteria.TestFetchJoin)
testEmbeddableContainingRelationWithGeneratedKey(org.apache.openjpa.persistence.embed.TestEmbeddable)
testDateStringAsParameter(org.apache.openjpa.persistence.criteria.TestDateStringConversion)
testThrowsEntityExistsException(org.apache.openjpa.persistence.exception.TestException)
testBasicFieldsWithNonDefaultValue(org.apache.openjpa.persistence.criteria.TestQueryByExample)
testExcludeBasicFieldWithNonDefaultValue(org.apache.openjpa.persistence.criteria.TestQueryByExample)
testConcatSubStringFunc1(org.apache.openjpa.persistence.criteria.TestTypeSafeCondExpression)
testConcatSubStringFunc2(org.apache.openjpa.persistence.criteria.TestTypeSafeCondExpression)
testHandlerToHandlerMaps(org.apache.openjpa.persistence.relations.TestMapCollectionToBlob)
testKeyExpression(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testSubqueries2(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testSubqueries3(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testSubqueries4(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testSubqueries5(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testSubqueries6(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testFetchJoins(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testIndexExpression(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testExpressions(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testOrdering1(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testOrdering2(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testOrdering3(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testSimpleLeftJoin(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testMultiLevelJoins(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testJoinsNotPresentInWhereClause(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testJoinedPathInProjection(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testIsEmptyExpression(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testExpressionInProjection(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testIndexExpressionAndLietral(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testAggregateInProjection(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testExpression1(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testExpression3(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testSelectList1(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testConstructorInProjection(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testKeys1(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testKeys2(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testKeys3(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testKeys4(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testKeys5(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testKeys6(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testKeys7(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testKeys8(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testValues1(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testValues2(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testValues3(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testValue4(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testValues5(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testValues6(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testValues7(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testValue8(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testGetIdGeneratorSeqGen(org.apache.openjpa.persistence.generationtype.TestNativeSeqGenerator)
testIndex(org.apache.openjpa.persistence.criteria.TestStringCriteria)
testSum(org.apache.openjpa.persistence.criteria.TestStringCriteria)
testIsEmpty(org.apache.openjpa.persistence.criteria.TestStringCriteria)
testFetchJoins(org.apache.openjpa.persistence.criteria.TestStringCriteria)
testJoins1(org.apache.openjpa.persistence.criteria.TestStringCriteria)
testJoins2(org.apache.openjpa.persistence.criteria.TestStringCriteria)
testKey(org.apache.openjpa.persistence.criteria.TestStringCriteria)
testRestrictQueryResult(org.apache.openjpa.persistence.criteria.TestStringCriteria)
testExpressions(org.apache.openjpa.persistence.criteria.TestStringCriteria)
testSelectList(org.apache.openjpa.persistence.criteria.TestStringCriteria)
testSubquery2(org.apache.openjpa.persistence.criteria.TestStringCriteria)
testSubquery3(org.apache.openjpa.persistence.criteria.TestStringCriteria)
testSubquery4(org.apache.openjpa.persistence.criteria.TestStringCriteria)
testSubquery5(org.apache.openjpa.persistence.criteria.TestStringCriteria)
testSubquery6(org.apache.openjpa.persistence.criteria.TestStringCriteria)
testOrdering1(org.apache.openjpa.persistence.criteria.TestStringCriteria)
testOrdering2(org.apache.openjpa.persistence.criteria.TestStringCriteria)
testOrdering3(org.apache.openjpa.persistence.criteria.TestStringCriteria)
testSubquery01(org.apache.openjpa.persistence.criteria.TestSubqueries)
testSubquery02(org.apache.openjpa.persistence.criteria.TestSubqueries)
testSubquery03(org.apache.openjpa.persistence.criteria.TestSubqueries)
testSubquery04(org.apache.openjpa.persistence.criteria.TestSubqueries)
testSubquery05(org.apache.openjpa.persistence.criteria.TestSubqueries)
testSubquery06(org.apache.openjpa.persistence.criteria.TestSubqueries)
testSubquery07(org.apache.openjpa.persistence.criteria.TestSubqueries)
testSubquery08(org.apache.openjpa.persistence.criteria.TestSubqueries)
testSubquery09(org.apache.openjpa.persistence.criteria.TestSubqueries)
testSubquery10(org.apache.openjpa.persistence.criteria.TestSubqueries)
testSubquery11(org.apache.openjpa.persistence.criteria.TestSubqueries)
testSubquery12(org.apache.openjpa.persistence.criteria.TestSubqueries)
testSubquery13(org.apache.openjpa.persistence.criteria.TestSubqueries)
testSubquery14(org.apache.openjpa.persistence.criteria.TestSubqueries)
testSubquery15(org.apache.openjpa.persistence.criteria.TestSubqueries)
testSubquery16(org.apache.openjpa.persistence.criteria.TestSubqueries)
testSubquery17(org.apache.openjpa.persistence.criteria.TestSubqueries)
testSubquery18(org.apache.openjpa.persistence.criteria.TestSubqueries)
testSubquery19(org.apache.openjpa.persistence.criteria.TestSubqueries)
testSubquery20(org.apache.openjpa.persistence.criteria.TestSubqueries)
testSubquery21(org.apache.openjpa.persistence.criteria.TestSubqueries)
testSubqueries2(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubqueries3(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubqueries4(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubqueries4a(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubqueries4b(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubqueries4c(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubqueries4d(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubqueries4e(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubqueries5(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubqueries5a(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubqueries6(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubqueries6a(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubqueries6b(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubqueries6c(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubqueries6d(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubqueries6e(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubqueries6f(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubqueries6g(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubqueries6h(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testExist1b(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testNotExist1a(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubquery01(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubquery02(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubquery03(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubquery04(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubquery05(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubquery06(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubquery07(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubquery08(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubquery09(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubquery10(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubquery11(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubquery12(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubquery13(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubquery14(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubquery15(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubquery16(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubquery17(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubquery18(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubquery19(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubquery20(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubquery21(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubquery24(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSubquery25(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testCorrelatedNestedSubquery1(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testCorrelatedNestedSubquery1a(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testPluralCorrelatedJoin1(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testPluralCorrelatedJoin3(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testPluralCorrelatedJoin4(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testPluralCorrelatedJoin5(org.apache.openjpa.persistence.criteria.TestJPQLSubquery)
testSetAndListJoins(org.apache.openjpa.persistence.criteria.TestMetaModelTypesafeCriteria)
testLeftSetJoin(org.apache.openjpa.persistence.criteria.TestMetaModelTypesafeCriteria)
testFetchJoins(org.apache.openjpa.persistence.criteria.TestMetaModelTypesafeCriteria)
testKeyPathNavigation(org.apache.openjpa.persistence.criteria.TestMetaModelTypesafeCriteria)
testIndexExpression(org.apache.openjpa.persistence.criteria.TestMetaModelTypesafeCriteria)
testIsEmptyExpressionOnJoin(org.apache.openjpa.persistence.criteria.TestMetaModelTypesafeCriteria)
testFunctionalExpressionInProjection(org.apache.openjpa.persistence.criteria.TestMetaModelTypesafeCriteria)
testJoinAndIndexExpression(org.apache.openjpa.persistence.criteria.TestMetaModelTypesafeCriteria)
testAggregateExpressionInProjection(org.apache.openjpa.persistence.criteria.TestMetaModelTypesafeCriteria)
testKeyExpressionInSelectList(org.apache.openjpa.persistence.criteria.TestMetaModelTypesafeCriteria)
testConstructorInSelectList(org.apache.openjpa.persistence.criteria.TestMetaModelTypesafeCriteria)
testSubqueryWithExistsClause(org.apache.openjpa.persistence.criteria.TestMetaModelTypesafeCriteria)
testSubqueryWithAllClause(org.apache.openjpa.persistence.criteria.TestMetaModelTypesafeCriteria)
testCorrelatedSubqueryWithCount(org.apache.openjpa.persistence.criteria.TestMetaModelTypesafeCriteria)
testCorrelatedSubqueryWithJoin(org.apache.openjpa.persistence.criteria.TestMetaModelTypesafeCriteria)
testCorrelatedSubqueryWithAllClause(org.apache.openjpa.persistence.criteria.TestMetaModelTypesafeCriteria)
testOrderingByExpressionNotIncludedInSelection(org.apache.openjpa.persistence.criteria.TestMetaModelTypesafeCriteria)
testOrderingByExpressionIncludedInSelection(org.apache.openjpa.persistence.criteria.TestMetaModelTypesafeCriteria)
testOrderingWithNumericalExpressionInSelection(org.apache.openjpa.persistence.criteria.TestMetaModelTypesafeCriteria)
testGetLockMode(org.apache.openjpa.persistence.lockmgr.TestEmLockMode)
testRefreshReadPessimisticRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerRefreshPermutation)
testRefreshReadPessimisticWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerRefreshPermutation)
testRefreshReadPessimisticForceInc(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerRefreshPermutation)
testRefreshWritePessimisticRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerRefreshPermutation)
testRefreshWritePessimisticWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerRefreshPermutation)
testRefreshWritePessimisticForceInc(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerRefreshPermutation)
testRefreshPessimisticReadRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerRefreshPermutation)
testRefreshPessimisticReadWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerRefreshPermutation)
testRefreshPessimisticReadPessimisticRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerRefreshPermutation)
testRefreshPessimisticReadPessimisticWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerRefreshPermutation)
testRefreshPessimisticReadPessimisticForceInc(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerRefreshPermutation)
testRefreshPessimsiticWriteRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerRefreshPermutation)
testRefreshPessimsiticWriteWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerRefreshPermutation)
testRefreshPessimsiticWritePessimisticRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerRefreshPermutation)
testRefreshPessimsiticWritePessimisticWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerRefreshPermutation)
testRefreshPessimsiticWritePessimisticForceInc(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerRefreshPermutation)
testRefreshPessimsiticForceIncRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerRefreshPermutation)
testRefreshPessimsiticForceIncWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerRefreshPermutation)
testRefreshPessimsiticForceIncPessimisticRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerRefreshPermutation)
testRefreshPessimsiticForceIncPessimisticWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerRefreshPermutation)
testRefreshPessimsiticForceIncPessimisticForceInc(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerRefreshPermutation)
testFindReadPessimisticRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerFindPermutation)
testFindReadPessimisticWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerFindPermutation)
testFindReadPessimisticForceInc(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerFindPermutation)
testFindWritePessimisticRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerFindPermutation)
testFindWritePessimisticWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerFindPermutation)
testFindWritePessimisticForceInc(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerFindPermutation)
testFindPessimisticReadRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerFindPermutation)
testFindPessimisticReadWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerFindPermutation)
testFindPessimisticReadPessimisticRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerFindPermutation)
testFindPessimisticReadPessimisticWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerFindPermutation)
testFindPessimisticReadPessimisticForceInc(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerFindPermutation)
testFindPessimsiticWriteRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerFindPermutation)
testFindPessimsiticWriteWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerFindPermutation)
testFindPessimsiticWritePessimisticRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerFindPermutation)
testFindPessimsiticWritePessimisticWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerFindPermutation)
testFindPessimsiticWritePessimisticForceInc(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerFindPermutation)
testFindPessimsiticForceIncRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerFindPermutation)
testFindPessimsiticForceIncWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerFindPermutation)
testFindPessimsiticForceIncPessimisticRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerFindPermutation)
testFindPessimsiticForceIncPessimisticWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerFindPermutation)
testFindPessimsiticForceIncPessimisticForceInc(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerFindPermutation)
testLockReadPessimisticRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerLockPermutation)
testLockReadPessimisticWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerLockPermutation)
testLockReadPessimisticForceInc(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerLockPermutation)
testLockWritePessimisticRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerLockPermutation)
testLockWritePessimisticWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerLockPermutation)
testLockWritePessimisticForceInc(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerLockPermutation)
testLockPessimisticReadRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerLockPermutation)
testLockPessimisticReadWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerLockPermutation)
testLockPessimisticReadPessimisticRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerLockPermutation)
testLockPessimisticReadPessimisticWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerLockPermutation)
testLockPessimisticReadPessimisticForceInc(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerLockPermutation)
testLockPessimsiticWriteRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerLockPermutation)
testLockPessimsiticWriteWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerLockPermutation)
testLockPessimsiticWritePessimisticRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerLockPermutation)
testLockPessimsiticWritePessimisticWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerLockPermutation)
testLockPessimsiticWritePessimisticForceInc(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerLockPermutation)
testLockPessimsiticForceIncRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerLockPermutation)
testLockPessimsiticForceIncWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerLockPermutation)
testLockPessimsiticForceIncPessimisticRead(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerLockPermutation)
testLockPessimsiticForceIncPessimisticWrite(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerLockPermutation)
testLockPessimsiticForceIncPessimisticForceInc(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerLockPermutation)

Tests in error:
testFetchJoin(org.apache.openjpa.persistence.criteria.TestFetchJoin)
testDateString(org.apache.openjpa.persistence.criteria.TestDateStringConversion)
testQuery(org.apache.openjpa.persistence.relations.TestRelationFieldAsPrimaryKeyAndForeignKey)
testBasicFieldWithDefaultValueExcludedByDefaultStyle(org.apache.openjpa.persistence.criteria.TestQueryByExample)
testBasicFieldWithDefaultValueCanBeIncludedByStyle(org.apache.openjpa.persistence.criteria.TestQueryByExample)
testRelationFieldWithNonDefaultValue(org.apache.openjpa.persistence.criteria.TestQueryByExample)
testRelationFieldWithNullValueIncluded(org.apache.openjpa.persistence.criteria.TestQueryByExample)
testEmbeddedField(org.apache.openjpa.persistence.criteria.TestQueryByExample)
testSqlOrder(org.apache.openjpa.jdbc.kernel.TestNoForeignKeyViolation)
testLogicalPredicateAssociativity(org.apache.openjpa.persistence.criteria.TestCriteria)
testPessimisticLocking(org.apache.openjpa.persistence.kernel.TestPessimisticLocking)
testPessimisticLockingInternal(org.apache.openjpa.persistence.kernel.TestPessimisticLocking)
testConcatSubStringFunc(org.apache.openjpa.persistence.jpql.functions.TestEJBQLFunction)
testJoinKey(org.apache.openjpa.persistence.criteria.TestTypesafeCriteria)
testGeneratedAUTO(org.apache.openjpa.persistence.generationtype.TestMultipleSchemaNames)
testGeneratedTABLE(org.apache.openjpa.persistence.generationtype.TestMultipleSchemaNames)
testGeneratedIDENTITY(org.apache.openjpa.persistence.generationtype.TestMultipleSchemaNames)
testNormalUni1xmLock(org.apache.openjpa.persistence.lock.extended.Test1xmLockScope)
testExtendedUni1xmLock(org.apache.openjpa.persistence.lock.extended.Test1xmLockScope)
testNormalUni1xmEagerLock(org.apache.openjpa.persistence.lock.extended.Test1xmLockScope)
testExtendedUni1xmEagerLock(org.apache.openjpa.persistence.lock.extended.Test1xmLockScope)
testNormalUni1xmJTLock(org.apache.openjpa.persistence.lock.extended.Test1xmLockScope)
testExtendedUni1xmJTLock(org.apache.openjpa.persistence.lock.extended.Test1xmLockScope)
testNormalUni1xmJTEagerLock(org.apache.openjpa.persistence.lock.extended.Test1xmLockScope)
testExtendedUni1xmJTEagerLock(org.apache.openjpa.persistence.lock.extended.Test1xmLockScope)
testFindLockModeIsolations(org.apache.openjpa.persistence.lockmgr.TestEmLockMode)
testRefreshLockModeIsolations(org.apache.openjpa.persistence.lockmgr.TestEmLockMode)
testLockLockModeIsolations(org.apache.openjpa.persistence.lockmgr.TestEmLockMode)
testNormalBasicLock(org.apache.openjpa.persistence.lock.extended.TestBasicLockScope)
testExtendedBasicLock(org.apache.openjpa.persistence.lock.extended.TestBasicLockScope)
testNormalSecTableLock(org.apache.openjpa.persistence.lock.extended.TestBasicLockScope)
testExtendedSecTableLock(org.apache.openjpa.persistence.lock.extended.TestBasicLockScope)
testNormalSingleTableLock(org.apache.openjpa.persistence.lock.extended.TestBasicLockScope)
testExtendedlSingleTableLock(org.apache.openjpa.persistence.lock.extended.TestBasicLockScope)
testNormalJoinedLock(org.apache.openjpa.persistence.lock.extended.TestBasicLockScope)
testExtendedJoinedLock(org.apache.openjpa.persistence.lock.extended.TestBasicLockScope)
testNormalElementCollectionLock(org.apache.openjpa.persistence.lock.extended.TestBasicLockScope)
testExtendedElementCollectionLock(org.apache.openjpa.persistence.lock.extended.TestBasicLockScope)
testNormalElementCollectionEagerLock(org.apache.openjpa.persistence.lock.extended.TestBasicLockScope)
testExtendedElementCollectionEagerLock(org.apache.openjpa.persistence.lock.extended.TestBasicLockScope)
testNormalUni1x1Lock(org.apache.openjpa.persistence.lock.extended.Test1x1LockScope)
testExtendedUni1x1Lock(org.apache.openjpa.persistence.lock.extended.Test1x1LockScope)
testNormalUni1x1LazyLock(org.apache.openjpa.persistence.lock.extended.Test1x1LockScope)
testExtendedUni1x1LazyLock(org.apache.openjpa.persistence.lock.extended.Test1x1LockScope)
testNormalUni1x1JTLock(org.apache.openjpa.persistence.lock.extended.Test1x1LockScope)
testExtendedUni1x1JTLock(org.apache.openjpa.persistence.lock.extended.Test1x1LockScope)
testNormalUni1x1JTLazyLock(org.apache.openjpa.persistence.lock.extended.Test1x1LockScope)
testExtendedUni1x1JTLazyLock(org.apache.openjpa.persistence.lock.extended.Test1x1LockScope)
testFindNonVersionWithLock(org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerNonVersion)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OPENJPA-1368) Upgrade to HSQLDB 1.8.0.10 and in-memory db for unit tests

2009-10-30T09:09:59Z

[ https://issues.apache.org/jira/browse/OPENJPA-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Donald Woods resolved OPENJPA-1368.
-----------------------------------

Resolution: Fixed

Committed to 1.3.x and trunk

> Upgrade to HSQLDB 1.8.0.10 and in-memory db for unit tests
> ----------------------------------------------------------
>
> Key: OPENJPA-1368
> URL: https://issues.apache.org/jira/browse/OPENJPA-1368
> Project: OpenJPA
> Issue Type: Improvement
> Components: third-party
> Reporter: Donald Woods
> Assignee: Donald Woods
> Priority: Minor
> Fix For: 1.3.0, 2.0.0-M4
>
>
> Upgrade to HSQLDB 1.8.0.10, which is the latest release on the maven repos.
> Switch to in-memory db mode, from stand-alone db server mode for easier unit testing.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1368) Upgrade to HSQLDB 1.8.0.10 and in-memory db for unit tests

2009-10-30T07:56:59Z

Upgrade to HSQLDB 1.8.0.10 and in-memory db for unit tests
----------------------------------------------------------

Key: OPENJPA-1368
URL: https://issues.apache.org/jira/browse/OPENJPA-1368
Project: OpenJPA
Issue Type: Improvement
Components: third-party
Reporter: Donald Woods
Assignee: Donald Woods
Priority: Minor
Fix For: 1.3.0, 2.0.0-M4

Upgrade to HSQLDB 1.8.0.10, which is the latest release on the maven repos.
Switch to in-memory db mode, from stand-alone db server mode for easier unit testing.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1367) H2 Database Engine does support cross join

2009-10-30T06:00:59Z

H2 Database Engine does support cross join
------------------------------------------

Key: OPENJPA-1367
URL: https://issues.apache.org/jira/browse/OPENJPA-1367
Project: OpenJPA
Issue Type: Bug
Components: docs, jpa
Affects Versions: 2.0.0-M1, 1.2.1
Reporter: Thomas Mueller
Priority: Minor

The documentation says that the H2 database does not support cross joins:

http://openjpa.apache.org/builds/1.2.1/apache-openjpa-1.2.1/docs/manual/dbsupport_h2.html
http://openjpa.apache.org/builds/2.0.0-M3/apache-openjpa-2.0.0-M3/docs/manual/main.html

H2 does support cross join since a long time (I don't remember what version). See: http://www.h2database.com/html/grammar.html#table_expression (CROSS). A condition is not required for cross join.

I think the documentation should be changed, and probably the H2Dictionary should be changed as well (crossJoinClause = "CROSS JOIN"; requiresConditionForCrossJoin = false;).

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OPENJPA-1366) Remove need for an EMF from OpenJPAPersistenceUtil and TraversableResolverImpl

2009-10-30T11:04:59Z

[ https://issues.apache.org/jira/browse/OPENJPA-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Donald Woods resolved OPENJPA-1366.
-----------------------------------

Resolution: Fixed

committed to trunk as r831406

> Remove need for an EMF from OpenJPAPersistenceUtil and TraversableResolverImpl
> ------------------------------------------------------------------------------
>
> Key: OPENJPA-1366
> URL: https://issues.apache.org/jira/browse/OPENJPA-1366
> Project: OpenJPA
> Issue Type: Improvement
> Components: validation
> Affects Versions: 2.0.0-M3
> Reporter: Donald Woods
> Assignee: Donald Woods
> Priority: Minor
> Fix For: 2.0.0-M4
>
>
> As pointed out by Pinaki and confirmed by Jeremy, we don't need an EMF for the isLoaded() call.
> From Pinaki - We can answer isLoaded() without really asking every broker to llok up in its cache or something. If the given instance pc is PersitenceCapable and has a non-null StateManager -- it is managed by us. If the question is: is pc managed by a specific EMF e, then also we can navigate from pc->sm->broker->brokerfactory->emf and compare by reference with e.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Work started: (OPENJPA-1366) Remove need for an EMF from OpenJPAPersistenceUtil and TraversableResolverImpl

2009-10-30T09:21:59Z

[ https://issues.apache.org/jira/browse/OPENJPA-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on OPENJPA-1366 started by Donald Woods.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-1366) Remove need for an EMF from OpenJPAPersistenceUtil and TraversableResolverImpl

2009-10-29T14:05:59Z

[ https://issues.apache.org/jira/browse/OPENJPA-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Donald Woods updated OPENJPA-1366:
----------------------------------

Summary: Remove need for an EMF from OpenJPAPersistenceUtil and TraversableResolverImpl (was: Remove need for an EMF from OpenJPAPersistenceUtil.isLoaded() and TraversableResolverImpl)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1366) Remove need for an EMF from OpenJPAPersistenceUtil.isLoaded() and TraversableResolverImpl

2009-10-29T14:03:59Z

Remove need for an EMF from OpenJPAPersistenceUtil.isLoaded() and TraversableResolverImpl
-----------------------------------------------------------------------------------------

Key: OPENJPA-1366
URL: https://issues.apache.org/jira/browse/OPENJPA-1366
Project: OpenJPA
Issue Type: Improvement
Components: validation
Affects Versions: 2.0.0-M3
Reporter: Donald Woods
Assignee: Donald Woods
Priority: Minor
Fix For: 2.0.0-M4

As pointed out by Pinaki and confirmed by Jeremy, we don't need an EMF for the isLoaded() call.

From Pinaki - We can answer isLoaded() without really asking every broker to llok up in its cache or something. If the given instance pc is PersitenceCapable and has a non-null StateManager -- it is managed by us. If the question is: is pc managed by a specific EMF e, then also we can navigate from pc->sm->broker->brokerfactory->emf and compare by reference with e.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-1365) DISTINCT keyword has no effect with JOIN FETCH queries

2009-11-04T08:11:32Z

[ https://issues.apache.org/jira/browse/OPENJPA-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Dick updated OPENJPA-1365:
----------------------------------

Attachment: OPENJPA-1365-1.0.x-patch.txt

Attaching patch for 1.0.x. It requires the changes for OPENJPA-894 however.

both issues use the same testcase, and those are duplicated in the patch (I'll fix this when OPENJPA-894 is committed).

> DISTINCT keyword has no effect with JOIN FETCH queries
> ------------------------------------------------------
>
> Key: OPENJPA-1365
> URL: https://issues.apache.org/jira/browse/OPENJPA-1365
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa, query
> Affects Versions: 1.0.4, 1.2.2, 1.3.0, 2.0.0-M4
> Reporter: Michael Dick
> Assignee: Michael Dick
> Attachments: OPENJPA-1365-1.0.x-patch.txt
>
>
> This issue occurs if the proposed fix for OPENJPA-894 is in place. Without that fix there results of a JOIN FETCH are always distinct when obtained from the database or non-distinct when returned from the persistence context's L1 cache.
> I started a discussion on this topic on the dev mailing list. The entire thread can be seen on Nabble here : http://n2.nabble.com/How-should-we-handle-the-JPQL-DISTINCT-keyword-td3908400.html#a3908400

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1365) DISTINCT keyword has no effect with JOIN FETCH queries

2009-10-29T12:23:59Z

DISTINCT keyword has no effect with JOIN FETCH queries
------------------------------------------------------

Key: OPENJPA-1365
URL: https://issues.apache.org/jira/browse/OPENJPA-1365
Project: OpenJPA
Issue Type: Bug
Components: jpa, query
Affects Versions: 1.0.4, 1.2.2, 1.3.0, 2.0.0-M4
Reporter: Michael Dick
Assignee: Michael Dick

This issue occurs if the proposed fix for OPENJPA-894 is in place. Without that fix there results of a JOIN FETCH are always distinct when obtained from the database or non-distinct when returned from the persistence context's L1 cache.

I started a discussion on this topic on the dev mailing list. The entire thread can be seen on Nabble here : http://n2.nabble.com/How-should-we-handle-the-JPQL-DISTINCT-keyword-td3908400.html#a3908400

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Fixing OpenJPA 1.3.x compilation issues in JDK 1.6

2009-10-29T04:28:09Z

Hi Pinaki,

I found your commit
http://n2.nabble.com/svn-commit-r813149-in-openjpa-trunk-openjpa-jdbc-src-main-java-org-apache-openjpa-jdbc-kernel-openjp-td3615171.html#a3615171which
I think fix the compilation issues in JDK 1.6. Is that the case. Will
1.3.x compile with JDK 1.6 if I merge those changes to 1.3.x.

Thanks,
Milinda

------------------------------
Milinda Pathirage
Senior Software Engineer & Product Manager WSO2 BPS; http://wso2.org/bps
WSO2 Inc.; http://wso2.com
E-mail: [hidden email], [hidden email]
Web: http://mpathirage.com
Blog: http://blog.mpathirage.com

Re: OSGi Aware Persistence Provider implementation

2009-10-29T19:50:07Z

Hi Donald,

Thanks for the tips.

Milinda

On Fri, Oct 30, 2009 at 2:19 AM, Donald Woods <[hidden email]> wrote:

> There is also the Aries project over in the Apache Incubator, which is
> proposing to develop several of the upcoming OSGi JavaEE RFCs, along with
> the Blueprint application environment. I'm hoping that some of the RFC 143
> work is already done by that project and just waiting on the early access
> OSGi specs to be released before they can bring it into their svn repo and
> share it with us....
>
> http://incubator.apache.org/projects/aries.html
>
>
> -Donald
>
>
>
> Milinda Pathirage wrote:
>
>> Thanks Kevin for your answers. I'm using OpenJPA in Apache ODE which runs
>> in
>> a OSGi environment(WSO2 Carbon platform). I tried OpenJPA 2.0, but there
>> were some issues with ODE's JPA queries. I'll try to port current
>> implementation to work with OpenJPA 2.0. I also think that it's better if
>> we
>> can add OSGi support for OpenJPA 2.0 because I saw there are fixes in
>> Geranimo JPA spec jar for OSGi related issues. I'll create a patch for
>> OSGi
>> related class loading issues and attach it to a JIRA.
>>
>> Thanks in advance,
>> Milinda
>>
>>
>> On Thu, Oct 29, 2009 at 10:51 PM, Kevin Sutter <[hidden email]>
>> wrote:
>>
>> Hi Milinda,
>>> Yes, there is some interest in allowing OpenJPA usage in an OSGi
>>> container
>>> environment. It's just not a "full time job" for any of us at the
>>> moment...
>>>
>>> Porting the JDK 6 changes back to the 1.3.x release might cause some
>>> concern
>>> for those users of the 1.3.x branch. Many of the changes would now
>>> require
>>> the use of JDK 6 and we didn't want to force this onto the JPA 1.0 usage
>>> community. Thus, we limited the change to trunk for our JPA 2.0
>>> development
>>> [1].
>>>
>>> Is there any reason why your experimentation and changes couldn't be
>>> targeted for the JPA 2.0 implementation? I think you will find our
>>> current
>>> M3 driver is quite solid, especially as it pertains to existing JPA 1.0
>>> functionality. Thus, any current JPA 1.0 applications should run
>>> unchanged
>>> with a JPA 2.0 driver.
>>>
>>> Thanks,
>>> Kevin
>>>
>>> [1]
>>>
>>>
>>> http://n2.nabble.com/DISCUSS-Drop-build-support-for-Java-5-td2539470i20.html#a3554445
>>>
>>>
>>> On Thu, Oct 29, 2009 at 4:49 AM, Milinda Pathirage <
>>> [hidden email]> wrote:
>>>
>>> Hi all,
>>>> I have another question. Is there any plan for fixing OpenJPA 1.3.x
>>>> compilation failures in JDK 1.6
>>>>
>>>> Thanks
>>>> Milinda
>>>>
>>>> On Thu, Oct 29, 2009 at 3:00 PM, Milinda Pathirage <
>>>> [hidden email]> wrote:
>>>>
>>>> We are currently using OpenJPA 1.1.0 in equinox OSGi container by
>>>>>
>>>> making
>>>
>>>> it
>>>>
>>>>> a fragment of the bundle which use it to fix the issue of loading
>>>>> persistence.xml. Now we want to use OpenJPA in two different OSGi
>>>>>
>>>> bundles
>>>
>>>> and fragment hack will not work in this situation. Current 1.3.x
>>>>>
>>>> OpenJPA
>>>
>>>> implementation also doesn't support OSGi aware resource loading. We can
>>>>>
>>>> fix
>>>>
>>>>> this by following the method use by Eclipselink. In this method what we
>>>>>
>>>> have
>>>>
>>>>> to do is implement a OSGi aware Persistence Provider by extending the
>>>>> current Persistence Provider implementation and introduce bundle
>>>>>
>>>> activator
>>>>
>>>>> to register persistence provider service at bundle activation. This
>>>>>
>>>> will
>>>
>>>> not
>>>>
>>>>> break the existing functionality of OpenJPA in J2SE environment and
>>>>>
>>>> improve
>>>>
>>>>> the support for OSGi containers.
>>>>>
>>>>> Are there any plans to add OSGi support, if there any I would like to
>>>>>
>>>> help.
>>>>
>>>>> I'll provide a patch ASAP for this.
>>>>>
>>>>> Thanks
>>>>> Milinda
>>>>>
>>>>> --
>>>>> Milinda Pathirage
>>>>> Senior Software Engineer & Product Manager WSO2 BPS;
>>>>>
>>>> http://wso2.org/bps
>>>
>>>> WSO2 Inc.; http://wso2.com
>>>>> E-mail: [hidden email], [hidden email]
>>>>> Web: http://mpathirage.com
>>>>> Blog: http://blog.mpathirage.com
>>>>>
>>>>>
>>>>
>>>> --
>>>> Milinda Pathirage
>>>> Senior Software Engineer & Product Manager WSO2 BPS;
>>>> http://wso2.org/bps
>>>> WSO2 <http://wso2.org/bps%0AWSO2> Inc.; http://wso2.com
>>>> E-mail: [hidden email], [hidden email]
>>>> Web: http://mpathirage.com
>>>> Blog: http://blog.mpathirage.com
>>>>
>>>>
>>
>>
>>

--
Milinda Pathirage
Senior Software Engineer & Product Manager WSO2 BPS; http://wso2.org/bps
WSO2 Inc.; http://wso2.com
E-mail: [hidden email], [hidden email]
Web: http://mpathirage.com
Blog: http://blog.mpathirage.com

Re: OSGi Aware Persistence Provider implementation

2009-10-29T13:49:57Z

There is also the Aries project over in the Apache Incubator, which is
proposing to develop several of the upcoming OSGi JavaEE RFCs, along
with the Blueprint application environment. I'm hoping that some of the
RFC 143 work is already done by that project and just waiting on the
early access OSGi specs to be released before they can bring it into
their svn repo and share it with us....

http://incubator.apache.org/projects/aries.html

-Donald

Milinda Pathirage wrote:

> Thanks Kevin for your answers. I'm using OpenJPA in Apache ODE which runs in
> a OSGi environment(WSO2 Carbon platform). I tried OpenJPA 2.0, but there
> were some issues with ODE's JPA queries. I'll try to port current
> implementation to work with OpenJPA 2.0. I also think that it's better if we
> can add OSGi support for OpenJPA 2.0 because I saw there are fixes in
> Geranimo JPA spec jar for OSGi related issues. I'll create a patch for OSGi
> related class loading issues and attach it to a JIRA.
>
> Thanks in advance,
> Milinda
>
>
> On Thu, Oct 29, 2009 at 10:51 PM, Kevin Sutter <[hidden email]> wrote:
>
>> Hi Milinda,
>> Yes, there is some interest in allowing OpenJPA usage in an OSGi container
>> environment. It's just not a "full time job" for any of us at the
>> moment...
>>
>> Porting the JDK 6 changes back to the 1.3.x release might cause some
>> concern
>> for those users of the 1.3.x branch. Many of the changes would now require
>> the use of JDK 6 and we didn't want to force this onto the JPA 1.0 usage
>> community. Thus, we limited the change to trunk for our JPA 2.0
>> development
>> [1].
>>
>> Is there any reason why your experimentation and changes couldn't be
>> targeted for the JPA 2.0 implementation? I think you will find our current
>> M3 driver is quite solid, especially as it pertains to existing JPA 1.0
>> functionality. Thus, any current JPA 1.0 applications should run unchanged
>> with a JPA 2.0 driver.
>>
>> Thanks,
>> Kevin
>>
>> [1]
>>
>> http://n2.nabble.com/DISCUSS-Drop-build-support-for-Java-5-td2539470i20.html#a3554445
>>
>>
>> On Thu, Oct 29, 2009 at 4:49 AM, Milinda Pathirage <
>> [hidden email]> wrote:
>>
>>> Hi all,
>>> I have another question. Is there any plan for fixing OpenJPA 1.3.x
>>> compilation failures in JDK 1.6
>>>
>>> Thanks
>>> Milinda
>>>
>>> On Thu, Oct 29, 2009 at 3:00 PM, Milinda Pathirage <
>>> [hidden email]> wrote:
>>>
>>>> We are currently using OpenJPA 1.1.0 in equinox OSGi container by
>> making
>>> it
>>>> a fragment of the bundle which use it to fix the issue of loading
>>>> persistence.xml. Now we want to use OpenJPA in two different OSGi
>> bundles
>>>> and fragment hack will not work in this situation. Current 1.3.x
>> OpenJPA
>>>> implementation also doesn't support OSGi aware resource loading. We can
>>> fix
>>>> this by following the method use by Eclipselink. In this method what we
>>> have
>>>> to do is implement a OSGi aware Persistence Provider by extending the
>>>> current Persistence Provider implementation and introduce bundle
>>> activator
>>>> to register persistence provider service at bundle activation. This
>> will
>>> not
>>>> break the existing functionality of OpenJPA in J2SE environment and
>>> improve
>>>> the support for OSGi containers.
>>>>
>>>> Are there any plans to add OSGi support, if there any I would like to
>>> help.
>>>> I'll provide a patch ASAP for this.
>>>>
>>>> Thanks
>>>> Milinda
>>>>
>>>> --
>>>> Milinda Pathirage
>>>> Senior Software Engineer & Product Manager WSO2 BPS;
>> http://wso2.org/bps
>>>> WSO2 Inc.; http://wso2.com
>>>> E-mail: [hidden email], [hidden email]
>>>> Web: http://mpathirage.com
>>>> Blog: http://blog.mpathirage.com
>>>>
>>>
>>>
>>> --
>>> Milinda Pathirage
>>> Senior Software Engineer & Product Manager WSO2 BPS; http://wso2.org/bps
>>> WSO2 <http://wso2.org/bps%0AWSO2> Inc.; http://wso2.com
>>> E-mail: [hidden email], [hidden email]
>>> Web: http://mpathirage.com
>>> Blog: http://blog.mpathirage.com
>>>
>
>
>