[jira] [Commented] (OPENJPA-2766) Modularity support

[JIRA]

[ 
https://issues.apache.org/jira/browse/OPENJPA-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16736845#comment-16736845
 ] 

Francesco Chicchiriccò commented on OPENJPA-2766:
-

FYI, we have solved the current issue at Syncope by adding a specific 
[PersistenceUnitPostProcessor|https://github.com/apache/syncope/blob/master/core/persistence-jpa/src/main/java/org/apache/syncope/core/persistence/jpa/spring/MultiJarAwarePersistenceUnitPostProcessor.java]
 to Spring's {{EntityManagerFactory}} bean definition.

> Modularity support
> --
>
> Key: OPENJPA-2766
> URL: https://issues.apache.org/jira/browse/OPENJPA-2766
> Project: OpenJPA
>  Issue Type: New Feature
>Reporter: Matt Pavlovich
>Priority: Major
>
> Support modular organization of entities so that all entities do not need to 
> be contained in the same jar, or referenced in a single persistence.xml 
>  listing.
> Use cases:
> 1. Jar A contains entityA, Jar B contains entityB.  (EntityB may or may not 
> extend from entityA.)
> 2. Jar X contains persistence.xml defining the PU
> 3. Jar C contains entityC and a list of classes that extend entityA. Jar X 
> persistence unit should be able to persist entityC and its collection of 
> entityA, entityB.. etc
> Features:
> 1. Auto-classpath scanning (perhaps for persistence-fragment.xml.. then 
> enumerate)
> 2. Support manual registration and unregistration of entity classes (not just 
> class names) to support OSGi environments that have per-bundle classloaders 
> and deploy/undeploy support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OPENJPA-2766) Modularity support

[Romain Manni-Bucau (JIRA)]

[ 
https://issues.apache.org/jira/browse/OPENJPA-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16736850#comment-16736850
 ] 

Romain Manni-Bucau commented on OPENJPA-2766:
-

Well there are two things here - so likely multiple tickets:

1. enhancing the scanning to support the whole classpath in a pluggable fashion 
with xbean is doable but can't be the default since the server must do it in 
general (it already has the info and it must just reuse it instead of 
multiplying the scanners, this is what does tomee and jpa based apps). It also 
requires include/exclude/overlap-handling config in the unit (not an issue but 
just pointing it out) cause often in 3rd party some jpa entities hang and are 
not desired.
2. making it OSGi friendly is not about making the factory dynamic directly 
(openjpa being the impl) but making it a whiteboard. TomEE has something close 
with the reloadableentitymanagerfactory - 
https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/assembler/classic/ReloadableEntityManagerFactory.java
 - which can be imported (once cleaned) but I suspect for OSGi case you want to 
do it in aries jpa (http://aries.apache.org/modules/jpaproject.html) cause it 
is at the end quite specific to OSGi and its bundle lifecycle management

In other words I'm all fine to enhance 1 but I think, due to current asf state, 
2 belongs outside openjpa which would stay the core and spec impl and not the 
full OSGi integration.

Hope it makes more sense phrased this way

> Modularity support
> --
>
> Key: OPENJPA-2766
> URL: https://issues.apache.org/jira/browse/OPENJPA-2766
> Project: OpenJPA
>  Issue Type: New Feature
>Reporter: Matt Pavlovich
>Priority: Major
>
> Support modular organization of entities so that all entities do not need to 
> be contained in the same jar, or referenced in a single persistence.xml 
>  listing.
> Use cases:
> 1. Jar A contains entityA, Jar B contains entityB.  (EntityB may or may not 
> extend from entityA.)
> 2. Jar X contains persistence.xml defining the PU
> 3. Jar C contains entityC and a list of classes that extend entityA. Jar X 
> persistence unit should be able to persist entityC and its collection of 
> entityA, entityB.. etc
> Features:
> 1. Auto-classpath scanning (perhaps for persistence-fragment.xml.. then 
> enumerate)
> 2. Support manual registration and unregistration of entity classes (not just 
> class names) to support OSGi environments that have per-bundle classloaders 
> and deploy/undeploy support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OPENJPA-2766) Modularity support

[Mark Struberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/OPENJPA-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16736837#comment-16736837
 ] 

Mark Struberg commented on OPENJPA-2766:


[~romain.manni-bucau] I did use it, but it would see even more adoption if it 
would be part of OpenJPA. Or even part of the JPA specification. Gonna push for 
it.
Classpath scanning per the spec (and also in OpenJPA) only works IF the 
entities are in the very same jar like the persistence.xml. That's bad from a 
modularity perspective. It is also a problem if you have multiple 
PersistenceUnits with different Entities. The class scanning mechanism only 
works if there is exactly a single persistenceUnit.


> Modularity support
> --
>
> Key: OPENJPA-2766
> URL: https://issues.apache.org/jira/browse/OPENJPA-2766
> Project: OpenJPA
>  Issue Type: New Feature
>Reporter: Matt Pavlovich
>Priority: Major
>
> Support modular organization of entities so that all entities do not need to 
> be contained in the same jar, or referenced in a single persistence.xml 
>  listing.
> Use cases:
> 1. Jar A contains entityA, Jar B contains entityB.  (EntityB may or may not 
> extend from entityA.)
> 2. Jar X contains persistence.xml defining the PU
> 3. Jar C contains entityC and a list of classes that extend entityA. Jar X 
> persistence unit should be able to persist entityC and its collection of 
> entityA, entityB.. etc
> Features:
> 1. Auto-classpath scanning (perhaps for persistence-fragment.xml.. then 
> enumerate)
> 2. Support manual registration and unregistration of entity classes (not just 
> class names) to support OSGi environments that have per-bundle classloaders 
> and deploy/undeploy support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OPENJPA-2766) Modularity support

[Matt Pavlovich (JIRA)]

[ 
https://issues.apache.org/jira/browse/OPENJPA-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16736731#comment-16736731
 ] 

Matt Pavlovich commented on OPENJPA-2766:
-

Hi [~romain.manni-bucau] jar-file handling requires all jars to be named at 
compile time (ie.. allowing a 3rd party to extend an entity.. then add the jar 
into the runtime and have it be supported)

I put together an example and posted it to GitHub. For simplicity, I've added 
all the model-[a,b,c] jars into the same project. However, for the purposes of 
the feature request, consider that they are _not_ known at build time. How 
would this be supported by OpenJPA?

reference sample project: https://github.com/mattrpav/jpa-modular

Thanks!



> Modularity support
> --
>
> Key: OPENJPA-2766
> URL: https://issues.apache.org/jira/browse/OPENJPA-2766
> Project: OpenJPA
>  Issue Type: New Feature
>Reporter: Matt Pavlovich
>Priority: Major
>
> Support modular organization of entities so that all entities do not need to 
> be contained in the same jar, or referenced in a single persistence.xml 
>  listing.
> Use cases:
> 1. Jar A contains entityA, Jar B contains entityB.  (EntityB may or may not 
> extend from entityA.)
> 2. Jar X contains persistence.xml defining the PU
> 3. Jar C contains entityC and a list of classes that extend entityA. Jar X 
> persistence unit should be able to persist entityC and its collection of 
> entityA, entityB.. etc
> Features:
> 1. Auto-classpath scanning (perhaps for persistence-fragment.xml.. then 
> enumerate)
> 2. Support manual registration and unregistration of entity classes (not just 
> class names) to support OSGi environments that have per-bundle classloaders 
> and deploy/undeploy support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OPENJPA-2767) Incomplete ValueMapDiscriminatorStrategy cache

[Will Dazey (JIRA)]

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

Will Dazey updated OPENJPA-2767:

Attachment: OJ2767_2.2.x_v2.patch

> Incomplete ValueMapDiscriminatorStrategy cache 
> ---
>
> Key: OPENJPA-2767
> URL: https://issues.apache.org/jira/browse/OPENJPA-2767
> Project: OpenJPA
>  Issue Type: Bug
>Reporter: Will Dazey
>Assignee: Will Dazey
>Priority: Minor
> Fix For: 2.2.3
>
> Attachments: OJ2767_2.2.x_v2.patch
>
>
> There exists the possibility that the discriminator class cache in 
> ValueMapDiscriminatorStrategy was originally created before the server fully 
> loaded all classes. If this happens, the cache is incomplete and needs to be 
> rebuilt. A simple enough strategy would be to just try rebuilding the cache, 
> before giving up and throwing a CNFE, and check again.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OPENJPA-2767) Incomplete ValueMapDiscriminatorStrategy cache

[Will Dazey (JIRA)]

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

Will Dazey updated OPENJPA-2767:

Attachment: (was: OJ2767_2.2.x_v1.patch)

> Incomplete ValueMapDiscriminatorStrategy cache 
> ---
>
> Key: OPENJPA-2767
> URL: https://issues.apache.org/jira/browse/OPENJPA-2767
> Project: OpenJPA
>  Issue Type: Bug
>Reporter: Will Dazey
>Assignee: Will Dazey
>Priority: Minor
> Fix For: 2.2.3
>
> Attachments: OJ2767_2.2.x_v2.patch
>
>
> There exists the possibility that the discriminator class cache in 
> ValueMapDiscriminatorStrategy was originally created before the server fully 
> loaded all classes. If this happens, the cache is incomplete and needs to be 
> rebuilt. A simple enough strategy would be to just try rebuilding the cache, 
> before giving up and throwing a CNFE, and check again.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] end support for OpenJPA-1.x?

[Jody Grassel]

The repository branches will remain (ie, not deleted) if they are declared
EOL?

On Mon, Jan 7, 2019 at 4:05 PM Mark Struberg 
wrote:

> hi folks!
>
> I think the times of the 1.x rage of OpenJPA is over.
> This is our JPA-1.0 branch (JavaEE5).
> Wdyt about declaring it EOL and closing all the tickets for it?
>
> Of course OpenJPA-2.x and 3.x will continue to be active!
>
> LieGrue,
> strub
>

Re: [DISCUSS] end support for OpenJPA-1.x?

[Romain Manni-Bucau]

+1

Le lun. 7 janv. 2019 23:05, Mark Struberg  a
écrit :

> hi folks!
>
> I think the times of the 1.x rage of OpenJPA is over.
> This is our JPA-1.0 branch (JavaEE5).
> Wdyt about declaring it EOL and closing all the tickets for it?
>
> Of course OpenJPA-2.x and 3.x will continue to be active!
>
> LieGrue,
> strub
>

[DISCUSS] end support for OpenJPA-1.x?

[Mark Struberg]

hi folks!

I think the times of the 1.x rage of OpenJPA is over.
This is our JPA-1.0 branch (JavaEE5).
Wdyt about declaring it EOL and closing all the tickets for it?

Of course OpenJPA-2.x and 3.x will continue to be active!

LieGrue,
strub

[jira] [Resolved] (OPENJPA-1880) Unable to read Oracle XMLType columns

[Mark Struberg (JIRA)]

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

Mark Struberg resolved OPENJPA-1880.

Resolution: Won't Fix

We won't fix this in OpenJPA-1.3.x.

> Unable to read Oracle XMLType columns
> -
>
> Key: OPENJPA-1880
> URL: https://issues.apache.org/jira/browse/OPENJPA-1880
> Project: OpenJPA
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 1.3.0
>Reporter: Michael Dick
>Priority: Major
> Fix For: 1.3.0
>
>
> The testcase provided for OPENJPA-1874 cannot load an entity which contains 
> an Oracle XMLType column. The testcase works with OpenJPA 1.2.3, 2.0.2, and 
> 2.1.0 SNAPSHOTs, but some work needs to be done on 1.3.0-SNAPSHOT. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OPENJPA-2767) Incomplete ValueMapDiscriminatorStrategy cache

[Will Dazey (JIRA)]

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

Will Dazey updated OPENJPA-2767:

Description: 
There exists the possibility that the discriminator class cache in 
ValueMapDiscriminatorStrategy was originally created before the server fully 
loaded all classes. If this happens, the cache is incomplete and needs to be 
rebuilt. A simple enough strategy would be to just try rebuilding the cache, 
before giving up and throwing a CNFE, and check again.



  was:
There exists the possibility that the discriminator class cache in 
ValueMapDiscriminatorStrategy was originally created before the server fully 
loaded all classes. If this happens, the cache is incomplete and needs to be 
rebuilt. A simple enough strategy would be to just try rebuilding the cache 
before giving up and throwing a CNFE and check again.




> Incomplete ValueMapDiscriminatorStrategy cache 
> ---
>
> Key: OPENJPA-2767
> URL: https://issues.apache.org/jira/browse/OPENJPA-2767
> Project: OpenJPA
>  Issue Type: Bug
>Reporter: Will Dazey
>Assignee: Will Dazey
>Priority: Minor
> Fix For: 2.2.3
>
>
> There exists the possibility that the discriminator class cache in 
> ValueMapDiscriminatorStrategy was originally created before the server fully 
> loaded all classes. If this happens, the cache is incomplete and needs to be 
> rebuilt. A simple enough strategy would be to just try rebuilding the cache, 
> before giving up and throwing a CNFE, and check again.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OPENJPA-2767) Incomplete ValueMapDiscriminatorStrategy cache

[Will Dazey (JIRA)]

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

Will Dazey updated OPENJPA-2767:

Attachment: OJ2767_2.2.x_v1.patch

> Incomplete ValueMapDiscriminatorStrategy cache 
> ---
>
> Key: OPENJPA-2767
> URL: https://issues.apache.org/jira/browse/OPENJPA-2767
> Project: OpenJPA
>  Issue Type: Bug
>Reporter: Will Dazey
>Assignee: Will Dazey
>Priority: Minor
> Fix For: 2.2.3
>
> Attachments: OJ2767_2.2.x_v1.patch
>
>
> There exists the possibility that the discriminator class cache in 
> ValueMapDiscriminatorStrategy was originally created before the server fully 
> loaded all classes. If this happens, the cache is incomplete and needs to be 
> rebuilt. A simple enough strategy would be to just try rebuilding the cache, 
> before giving up and throwing a CNFE, and check again.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OPENJPA-2766) Modularity support

[Romain Manni-Bucau (JIRA)]

[ 
https://issues.apache.org/jira/browse/OPENJPA-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16736049#comment-16736049
 ] 

Romain Manni-Bucau commented on OPENJPA-2766:
-

Hi matt,

what is missing since jar-file is handled?

Side note: I added persistence-fragment.xml to TomEE and it never had been used 
so I'm not super motivated to add it in OpenJPA too.

About classpath scanning: this is already built-in 
(https://github.com/apache/openjpa/blob/08bb3a5a0e7573622aa6dc25763cb6513095093b/openjpa-kernel/src/main/java/org/apache/openjpa/meta/AbstractCFMetaDataFactory.java#L627)
About manual registration/unregistration: you can create multiple EM and hide 
them behind a facade (whiteboard) in OSGi, this is more reliable than 
adding/removing entities in the unit which can break the app quite easily IMHO.

Do you have some concrete example we can base the reflection upon?

> Modularity support
> --
>
> Key: OPENJPA-2766
> URL: https://issues.apache.org/jira/browse/OPENJPA-2766
> Project: OpenJPA
>  Issue Type: New Feature
>Reporter: Matt Pavlovich
>Priority: Major
>
> Support modular organization of entities so that all entities do not need to 
> be contained in the same jar, or referenced in a single persistence.xml 
>  listing.
> Use cases:
> 1. Jar A contains entityA, Jar B contains entityB.  (EntityB may or may not 
> extend from entityA.)
> 2. Jar X contains persistence.xml defining the PU
> 3. Jar C contains entityC and a list of classes that extend entityA. Jar X 
> persistence unit should be able to persist entityC and its collection of 
> entityA, entityB.. etc
> Features:
> 1. Auto-classpath scanning (perhaps for persistence-fragment.xml.. then 
> enumerate)
> 2. Support manual registration and unregistration of entity classes (not just 
> class names) to support OSGi environments that have per-bundle classloaders 
> and deploy/undeploy support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OPENJPA-2767) Incomplete ValueMapDiscriminatorStrategy cache

[Will Dazey (JIRA)]

Will Dazey created OPENJPA-2767:
---

 Summary: Incomplete ValueMapDiscriminatorStrategy cache 
 Key: OPENJPA-2767
 URL: https://issues.apache.org/jira/browse/OPENJPA-2767
 Project: OpenJPA
  Issue Type: Bug
Reporter: Will Dazey
Assignee: Will Dazey
 Fix For: 2.2.3


There exists the possibility that the discriminator class cache in 
ValueMapDiscriminatorStrategy was originally created before the server fully 
loaded all classes. If this happens, the cache is incomplete and needs to be 
rebuilt. A simple enough strategy would be to just try rebuilding the cache 
before giving up and throwing a CNFE and check again.





--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OPENJPA-2766) Modularity support

[Matt Pavlovich (JIRA)]

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

Matt Pavlovich updated OPENJPA-2766:

Description: 
Support modular organization of entities so that all entities do not need to be 
contained in the same jar, or referenced in a single persistence.xml  
listing.

Use cases:
1. Jar A contains entityA, Jar B contains entityB.  (EntityB may or may not 
extend from entityA.)
2. Jar X contains persistence.xml defining the PU
3. Jar C contains entityC and a list of classes that extend entityA. Jar X 
persistence unit should be able to persist entityC and its collection of 
entityA, entityB.. etc

Features:
1. Auto-classpath scanning (perhaps for persistence-fragment.xml.. then 
enumerate)
2. Support manual registration and unregistration of entity classes (not just 
class names) to support OSGi environments that have per-bundle classloaders and 
deploy/undeploy support.

  was:
Support modular organization of entities so that all entities do not need to be 
contained in the same jar, or referenced in a single persistence.xml  
listing.

Use cases:
1. Jar A contains entityA, Jar B contains entityB. Jar C contains 
persistence.xml defining the PU
2. EntityB may or may not extend from entityA

Features:
1. Auto-classpath scanning (perhaps for persistence-fragment.xml.. then 
enumerate)
2. Support manual registration and unregistration of entity classes (not just 
class names) to support OSGi environments that have per-bundle classloaders and 
deploy/undeploy support.


> Modularity support
> --
>
> Key: OPENJPA-2766
> URL: https://issues.apache.org/jira/browse/OPENJPA-2766
> Project: OpenJPA
>  Issue Type: New Feature
>Reporter: Matt Pavlovich
>Priority: Major
>
> Support modular organization of entities so that all entities do not need to 
> be contained in the same jar, or referenced in a single persistence.xml 
>  listing.
> Use cases:
> 1. Jar A contains entityA, Jar B contains entityB.  (EntityB may or may not 
> extend from entityA.)
> 2. Jar X contains persistence.xml defining the PU
> 3. Jar C contains entityC and a list of classes that extend entityA. Jar X 
> persistence unit should be able to persist entityC and its collection of 
> entityA, entityB.. etc
> Features:
> 1. Auto-classpath scanning (perhaps for persistence-fragment.xml.. then 
> enumerate)
> 2. Support manual registration and unregistration of entity classes (not just 
> class names) to support OSGi environments that have per-bundle classloaders 
> and deploy/undeploy support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OPENJPA-2766) Modularity support

[Matt Pavlovich (JIRA)]

Matt Pavlovich created OPENJPA-2766:
---

 Summary: Modularity support
 Key: OPENJPA-2766
 URL: https://issues.apache.org/jira/browse/OPENJPA-2766
 Project: OpenJPA
  Issue Type: New Feature
Reporter: Matt Pavlovich


Support modular organization of entities so that all entities do not need to be 
contained in the same jar, or referenced in a single persistence.xml  
listing.

Use cases:
1. Jar A contains entityA, Jar B contains entityB. Jar C contains 
persistence.xml defining the PU
2. EntityB may or may not extend from entityA

Features:
1. Auto-classpath scanning (perhaps for persistence-fragment.xml.. then 
enumerate)
2. Support manual registration and unregistration of entity classes (not just 
class names) to support OSGi environments that have per-bundle classloaders and 
deploy/undeploy support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: About JPA spec compliance

[Mark Struberg]

I've gradually improved our test coverage and internal code parts by adding 
docker profiles for multiple Databases over the last months.
I did add Oracle11_XE yesterday. Although the setup is not yet perfect we can 
at least run the tests now.

So basically everyone can now test against a bunch of different databases. 

The next step will be to include the JakartaEE JPA TCK.

And then we will know exactly what's missing.

LieGrue,
strub


> Am 07.01.2019 um 11:47 schrieb Francesco Chicchiriccò :
> 
> On 07/01/19 11:45, Romain Manni-Bucau wrote:
>> Hi Francesco,
>> 
>> I will not have much time these days to help very actively but i'd expose
>> it the other way around, more roadmap oriented:
>> 
>> OpenJPA 3.0.0: provides stored procedure support of JPA 2.1 etc...
>> 
>> cause structurally we are more about adding features one by one than saying
>> "we just miss X and Y" for now - which is fine IMHO but just trying to
>> explain why we must not reference ourself to JPA 2.2 completeness but more
>> on a kind of timeline.
> 
> I understand, that's fine; I would still need to fill up the statements above 
> for both 3.0.0 and 3.0.1: would you be able to provide those?
> 
> Regards.
> 
>> Le lun. 7 janv. 2019 à 11:43, Francesco Chicchiriccò 
>> a écrit :
>> 
>>> Hi all,
>>> a recent conversation on Twitter [1] with Oliver Drotbohm, Spring Data
>>> project lead, highlighted the need to clarify what is the JPA spec level
>>> implemented by the various OpenJPA releases; for such a purpose, [2] was
>>> opened.
>>> 
>>> I personally believe it is quite important to timely react, and I also
>>> offer my availability to align the various docs, if no one else steps
>>> in; for such a purpose, however, I would really appreciate some kind of
>>> draft statements like as follows:
>>> 
>>> * OpenJPA 2.x - fully implements JPA 2.0 specs, pass JPA TCK
>>> * OpenJPA 3.0.0 - depends on JPA 2.1 specs, JPA TCK not available at
>>> release time - missing JPA 2.1 features: A,B,C...
>>> * OpenJPA 3.0.1 - not released yet, depends on JPA 2.2 specs, JPA TCK
>>> compliance not yet verified - missing JPA 2.2 features: D,E,F...
>>> 
>>> WDYT?
>>> Regards.
>>> 
>>> [1] https://twitter.com/odrotbohm/status/1081713555290972160
>>> [2] https://issues.apache.org/jira/browse/OPENJPA-2765
> 
> -- 
> Francesco Chicchiriccò
> 
> Tirasa - Open Source Excellence
> http://www.tirasa.net/
> 
> Member at The Apache Software Foundation
> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
> http://home.apache.org/~ilgrosso/
> 

Re: About JPA spec compliance

[Romain Manni-Bucau]

Not sure I have the full vision but think we have a partial support of JPA
DDL (
https://github.com/apache/openjpa/commit/af8ea38f87a778401ca1c679f7087d3a0d5a52cc)
and the stored procedure support but not sure we have much more except
trivial things like result stream support (through getResultList().stream()
and not cursors)

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 7 janv. 2019 à 11:47, Francesco Chicchiriccò 
a écrit :

> On 07/01/19 11:45, Romain Manni-Bucau wrote:
> > Hi Francesco,
> >
> > I will not have much time these days to help very actively but i'd expose
> > it the other way around, more roadmap oriented:
> >
> > OpenJPA 3.0.0: provides stored procedure support of JPA 2.1 etc...
> >
> > cause structurally we are more about adding features one by one than
> saying
> > "we just miss X and Y" for now - which is fine IMHO but just trying to
> > explain why we must not reference ourself to JPA 2.2 completeness but
> more
> > on a kind of timeline.
>
> I understand, that's fine; I would still need to fill up the statements
> above for both 3.0.0 and 3.0.1: would you be able to provide those?
>
> Regards.
>
> > Le lun. 7 janv. 2019 à 11:43, Francesco Chicchiriccò <
> ilgro...@apache.org>
> > a écrit :
> >
> >> Hi all,
> >> a recent conversation on Twitter [1] with Oliver Drotbohm, Spring Data
> >> project lead, highlighted the need to clarify what is the JPA spec level
> >> implemented by the various OpenJPA releases; for such a purpose, [2] was
> >> opened.
> >>
> >> I personally believe it is quite important to timely react, and I also
> >> offer my availability to align the various docs, if no one else steps
> >> in; for such a purpose, however, I would really appreciate some kind of
> >> draft statements like as follows:
> >>
> >> * OpenJPA 2.x - fully implements JPA 2.0 specs, pass JPA TCK
> >> * OpenJPA 3.0.0 - depends on JPA 2.1 specs, JPA TCK not available at
> >> release time - missing JPA 2.1 features: A,B,C...
> >> * OpenJPA 3.0.1 - not released yet, depends on JPA 2.2 specs, JPA TCK
> >> compliance not yet verified - missing JPA 2.2 features: D,E,F...
> >>
> >> WDYT?
> >> Regards.
> >>
> >> [1] https://twitter.com/odrotbohm/status/1081713555290972160
> >> [2] https://issues.apache.org/jira/browse/OPENJPA-2765
>
> --
> Francesco Chicchiriccò
>
> Tirasa - Open Source Excellence
> http://www.tirasa.net/
>
> Member at The Apache Software Foundation
> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
> http://home.apache.org/~ilgrosso/
>
>

Re: About JPA spec compliance

[Francesco Chicchiriccò]

On 07/01/19 11:45, Romain Manni-Bucau wrote:

Hi Francesco,

I will not have much time these days to help very actively but i'd expose
it the other way around, more roadmap oriented:

OpenJPA 3.0.0: provides stored procedure support of JPA 2.1 etc...

cause structurally we are more about adding features one by one than saying
"we just miss X and Y" for now - which is fine IMHO but just trying to
explain why we must not reference ourself to JPA 2.2 completeness but more
on a kind of timeline.


I understand, that's fine; I would still need to fill up the statements 
above for both 3.0.0 and 3.0.1: would you be able to provide those?


Regards.


Le lun. 7 janv. 2019 à 11:43, Francesco Chicchiriccò 
a écrit :


Hi all,
a recent conversation on Twitter [1] with Oliver Drotbohm, Spring Data
project lead, highlighted the need to clarify what is the JPA spec level
implemented by the various OpenJPA releases; for such a purpose, [2] was
opened.

I personally believe it is quite important to timely react, and I also
offer my availability to align the various docs, if no one else steps
in; for such a purpose, however, I would really appreciate some kind of
draft statements like as follows:

* OpenJPA 2.x - fully implements JPA 2.0 specs, pass JPA TCK
* OpenJPA 3.0.0 - depends on JPA 2.1 specs, JPA TCK not available at
release time - missing JPA 2.1 features: A,B,C...
* OpenJPA 3.0.1 - not released yet, depends on JPA 2.2 specs, JPA TCK
compliance not yet verified - missing JPA 2.2 features: D,E,F...

WDYT?
Regards.

[1] https://twitter.com/odrotbohm/status/1081713555290972160
[2] https://issues.apache.org/jira/browse/OPENJPA-2765


--
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/

Re: About JPA spec compliance

[Romain Manni-Bucau]

Hi Francesco,

I will not have much time these days to help very actively but i'd expose
it the other way around, more roadmap oriented:

OpenJPA 3.0.0: provides stored procedure support of JPA 2.1 etc...

cause structurally we are more about adding features one by one than saying
"we just miss X and Y" for now - which is fine IMHO but just trying to
explain why we must not reference ourself to JPA 2.2 completeness but more
on a kind of timeline.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 7 janv. 2019 à 11:43, Francesco Chicchiriccò 
a écrit :

> Hi all,
> a recent conversation on Twitter [1] with Oliver Drotbohm, Spring Data
> project lead, highlighted the need to clarify what is the JPA spec level
> implemented by the various OpenJPA releases; for such a purpose, [2] was
> opened.
>
> I personally believe it is quite important to timely react, and I also
> offer my availability to align the various docs, if no one else steps
> in; for such a purpose, however, I would really appreciate some kind of
> draft statements like as follows:
>
> * OpenJPA 2.x - fully implements JPA 2.0 specs, pass JPA TCK
> * OpenJPA 3.0.0 - depends on JPA 2.1 specs, JPA TCK not available at
> release time - missing JPA 2.1 features: A,B,C...
> * OpenJPA 3.0.1 - not released yet, depends on JPA 2.2 specs, JPA TCK
> compliance not yet verified - missing JPA 2.2 features: D,E,F...
>
> WDYT?
> Regards.
>
> [1] https://twitter.com/odrotbohm/status/1081713555290972160
> [2] https://issues.apache.org/jira/browse/OPENJPA-2765
>
> --
> Francesco Chicchiriccò
>
> Tirasa - Open Source Excellence
> http://www.tirasa.net/
>
> Member at The Apache Software Foundation
> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
> http://home.apache.org/~ilgrosso/
>
>

About JPA spec compliance

[Francesco Chicchiriccò]

Hi all,
a recent conversation on Twitter [1] with Oliver Drotbohm, Spring Data 
project lead, highlighted the need to clarify what is the JPA spec level 
implemented by the various OpenJPA releases; for such a purpose, [2] was 
opened.


I personally believe it is quite important to timely react, and I also 
offer my availability to align the various docs, if no one else steps 
in; for such a purpose, however, I would really appreciate some kind of 
draft statements like as follows:


* OpenJPA 2.x - fully implements JPA 2.0 specs, pass JPA TCK
* OpenJPA 3.0.0 - depends on JPA 2.1 specs, JPA TCK not available at 
release time - missing JPA 2.1 features: A,B,C...
* OpenJPA 3.0.1 - not released yet, depends on JPA 2.2 specs, JPA TCK 
compliance not yet verified - missing JPA 2.2 features: D,E,F...


WDYT?
Regards.

[1] https://twitter.com/odrotbohm/status/1081713555290972160
[2] https://issues.apache.org/jira/browse/OPENJPA-2765

--
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/

[jira] [Updated] (OPENJPA-2765) Fix documentation of JPA spec compliance

[Oliver Drotbohm (JIRA)]

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

Oliver Drotbohm updated OPENJPA-2765:
-
Description: 
Depending on where you look, there's currently contradicting information about 
the JPA specification version compliance of OpenJPA.

- The [project homepage|http://openjpa.apache.org/] states 3.0 "targets" JPA 
2.1.
- The [3.0 
announcement|http://openjpa.apache.org/openjpa-3.0.x.html#OpenJPA-3.0.0] states 
3.0 is "based on" JPA 2.2.
- The [About section of the reference 
documentation|http://openjpa.apache.org/builds/3.0.0/apache-openjpa/docs/manual.html#openjpa_intro]
 states that 3.0 implements JPA 2.0.

It would be cool if this could be clarified. I assume the latter is just an 
oversight and a missing update. However it would also be cool if for the former 
two, it could be clarified what being "based on" and "targetting" actually 
means.

A [Twitter 
conversation|https://twitter.com/odrotbohm/status/1081713555290972160] seems to 
reveal that 3.0 *implements* 2.1 and has partial support for 2.2 features. 
Would be cool if that could be confirmed and documented accordingly, esp. which 
of the 2.2 features are supposed to work.

So to me it looks like follows:

- 2.x – implements JPA 2.0
- 3.0 – implements JPA 2.1, partial support for 2.2

The [Wikipedia page on JPA|https://en.wikipedia.org/wiki/Java_Persistence_API] 
could use an update on this as well. I can help with that, if you come to a 
decision what to phrase the current state of affairs.

Thanks and keep up the great work!

  was:
Depending on where you look, there's currently contradicting information about 
the JPA specification version compliance of OpenJPA.

- The [project homepage|http://openjpa.apache.org/] states 3.0 "targets" JPA 
2.1.
- The [3.0 
announcement|http://openjpa.apache.org/openjpa-3.0.x.html#OpenJPA-3.0.0] states 
3.0 is "based on" JPA 2.2.
- The [About section of the reference 
documentation|http://openjpa.apache.org/builds/3.0.0/apache-openjpa/docs/manual.html#openjpa_intro]
 states that 3.0 implements JPA 2.0.

It would be cool if this could be clarified. I assume the latter is just an 
oversight and a missing update. However it would also be cool if for the former 
two, it could be clarified what being "based on" and "targetting" actually 
means.

A [Twitter 
conversation|https://twitter.com/odrotbohm/status/1081713555290972160] seems to 
reveal that 3.0 *implements* 2.1 and has partial support for 2.2 features. 
Would be cool if that could be confirmed and documented accordingly, esp. which 
of the 2.2 features are supposed to work.

So to me it looks like follows:

- 2.x – implements JPA 2.0
- 3.0 – implements JPA 2.1, partial support for 2.2

The Wikipedia page on JPA could use an update on this as well. I can help with 
that, if you come to a decision what to phrase the current state of affairs.

Thanks and keep up the great work!


> Fix documentation of JPA spec compliance
> 
>
> Key: OPENJPA-2765
> URL: https://issues.apache.org/jira/browse/OPENJPA-2765
> Project: OpenJPA
>  Issue Type: Improvement
>Reporter: Oliver Drotbohm
>Priority: Major
>
> Depending on where you look, there's currently contradicting information 
> about the JPA specification version compliance of OpenJPA.
> - The [project homepage|http://openjpa.apache.org/] states 3.0 "targets" JPA 
> 2.1.
> - The [3.0 
> announcement|http://openjpa.apache.org/openjpa-3.0.x.html#OpenJPA-3.0.0] 
> states 3.0 is "based on" JPA 2.2.
> - The [About section of the reference 
> documentation|http://openjpa.apache.org/builds/3.0.0/apache-openjpa/docs/manual.html#openjpa_intro]
>  states that 3.0 implements JPA 2.0.
> It would be cool if this could be clarified. I assume the latter is just an 
> oversight and a missing update. However it would also be cool if for the 
> former two, it could be clarified what being "based on" and "targetting" 
> actually means.
> A [Twitter 
> conversation|https://twitter.com/odrotbohm/status/1081713555290972160] seems 
> to reveal that 3.0 *implements* 2.1 and has partial support for 2.2 features. 
> Would be cool if that could be confirmed and documented accordingly, esp. 
> which of the 2.2 features are supposed to work.
> So to me it looks like follows:
> - 2.x – implements JPA 2.0
> - 3.0 – implements JPA 2.1, partial support for 2.2
> The [Wikipedia page on 
> JPA|https://en.wikipedia.org/wiki/Java_Persistence_API] could use an update 
> on this as well. I can help with that, if you come to a decision what to 
> phrase the current state of affairs.
> Thanks and keep up the great work!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OPENJPA-2765) Fix documentation of JPA spec compliance

[Oliver Drotbohm (JIRA)]

Oliver Drotbohm created OPENJPA-2765:


 Summary: Fix documentation of JPA spec compliance
 Key: OPENJPA-2765
 URL: https://issues.apache.org/jira/browse/OPENJPA-2765
 Project: OpenJPA
  Issue Type: Improvement
Reporter: Oliver Drotbohm


Depending on where you look, there's currently contradicting information about 
the JPA specification version compliance of OpenJPA.

- The [project homepage|http://openjpa.apache.org/] states 3.0 "targets" JPA 
2.1.
- The [3.0 
announcement|http://openjpa.apache.org/openjpa-3.0.x.html#OpenJPA-3.0.0] states 
3.0 is "based on" JPA 2.2.
- The [About section of the reference 
documentation|http://openjpa.apache.org/builds/3.0.0/apache-openjpa/docs/manual.html#openjpa_intro]
 states that 3.0 implements JPA 2.0.

It would be cool if this could be clarified. I assume the latter is just an 
oversight and a missing update. However it would also be cool if for the former 
two, it could be clarified what being "based on" and "targetting" actually 
means.

A [Twitter 
conversation|https://twitter.com/odrotbohm/status/1081713555290972160] seems to 
reveal that 3.0 *implements* 2.1 and has partial support for 2.2 features. 
Would be cool if that could be confirmed and documented accordingly, esp. which 
of the 2.2 features are supposed to work.

So to me it looks like follows:

- 2.x – implements JPA 2.0
- 3.0 – implements JPA 2.1, partial support for 2.2

The Wikipedia page on JPA could use an update on this as well. I can help with 
that, if you come to a decision what to phrase the current state of affairs.

Thanks and keep up the great work!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OPENJPA-2761) problem inserting more than 4000 charcters in oracle XMLTYPE column

[Nezih BEN FREDJ (JIRA)]

[ 
https://issues.apache.org/jira/browse/OPENJPA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16735589#comment-16735589
 ] 

Nezih BEN FREDJ commented on OPENJPA-2761:
--

Our oracle server version is : 12.2.0.1

> problem inserting more than 4000 charcters in oracle XMLTYPE column
> ---
>
> Key: OPENJPA-2761
> URL: https://issues.apache.org/jira/browse/OPENJPA-2761
> Project: OpenJPA
>  Issue Type: Bug
>Affects Versions: 2.2.1, 2.4.3, 3.0.0
>Reporter: Nezih BEN FREDJ
>Assignee: Mark Struberg
>Priority: Blocker
> Attachments: XMLTypeTester.zip
>
>
> In attachement an eclipse project with a testcase showing the problem.
> my table is created with :
> CREATE TABLE Message (id NUMBER NOT NULL, 
> created TIMESTAMP, 
> message VARCHAR2(255), 
> XML_CONTENT XMLTYPE, 
> PRIMARY KEY (id));
> My jdbc4 driver version is 11.2.0.4 (ojdbc6.jar)
> I tried to follow instructions mentioned here with no success : 
> https://issues.apache.org/jira/browse/OPENJPA-1691?focusedCommentId=13086429=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13086429
> Thx



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)