Re: Loading relations

[Mark Struberg]

Can you probably create a small sample project with the entities + a small unit 
test?
That way we can make sure to really talk about exactly the same scenario.

txs and LieGrue,
strub

> Am 23.03.2023 um 18:16 schrieb Marco DE BOOIJ :
> 
> I searched on the web but cannot filter out the solution. I get pointed to 
> Spring and Hibernate but I am only interested in the solution with OpenJPA.
> I have a table in which I store the taxonomy tree. The key is the TAXON_ID 
> and it is linked with its parent through the PARENT_ID. I created the 
> following DTO named TaxonDto (I left out the fields that are of no 
> importance):
> 
>   @Column(name="PARENT_ID")
>   private Long  parentId;
>   @Column(name="RANG", length=3, nullable=false)
>   private Stringrang;
>   @Id
>   @GeneratedValue(strategy=GenerationType.IDENTITY)
>   @Column(name="TAXON_ID", nullable=false, unique=true, updatable=false)
>   private Long  taxonId;
> 
>   @OneToMany(cascade=CascadeType.ALL, fetch=FetchType.EAGER, 
> targetEntity=TaxonnaamDto.class, orphanRemoval=true)
>   @JoinColumn(name="TAXON_ID", nullable=false, updatable=false, 
> insertable=true)
>   @MapKey(name="taal")
>   private Map taxonnamen  = new HashMap<>();
> 
>   @OneToOne(cascade=CascadeType.ALL, fetch=FetchType.LAZY, 
> targetEntity=TaxonDto.class, orphanRemoval=true)
>   @JoinColumn(name="PARENT_ID", referencedColumnName="TAXON_ID", 
> updatable=false, insertable=false)
>   private TaxonDto  parent;
> 
> My problem lies in the @OneToOne. I did a test with FetchType.EAGER but then 
> the size of the returned data is 3x bigger as with LAZY since I get all 
> parents below the taxon. What I want is that the parent is fetched when the 
> rang is a specific value namely 'oso'. I can live with a solution where the 
> parent is not recursivly filled, the parent of the parent in this DTO must be 
> null.
> 
> Is this possible and if so how can I do this? I have seen discriminators, 
> fetchgroup and subclass DTO but it leaves me clueless.
> 

Re: OpenJPA 3.2.0 with Java 16

[Mark Struberg]

Hi Rob! 

It's even a bit more complicated. During the javax -> jakarta spec migration we 
found a few javax packages which will remain in the JDK and thus remain to keep 
the javax package name. The javax.transaction.xa is one of those. It is also 
not part of the official jakarta jta packages. Thus I'd say we should also 
remove this package from the geronimo specs jar and roll a new release. Just 
checked that the xa package is also part of Java 17 still.

LieGrue,
strub



> Am 28.09.2021 um 18:11 schrieb Rob Scala :
> 
> Hi Everyone,
> 
> I hope I have the right mailing list.
> 
> I'm working on upgrading from java 8 to java 16, and updating dependencies in 
> the process.  My project is modular.  I hit a stumbling block with a split 
> package:
> 
> module X reads package javax.transaction.xa from both 
> org.apache.geronimo.specs.geronimo.jta.spec and java.transaction.xa
> 
> where X is a lot of different modules, including apache commons, awssdk, 
> jersey, etc.
> 
> I understand that this error is caused by a core java module 
> (java.transaction.xa) and a geronimo.jta module both containing classes in 
> the packate "javax.transaction.xa".  That is not allowed in modular projects. 
>  Since the geronimo module is required by OpenJPA, I tried excluding the core 
> java module, but that didn't work, and I don't know if it even should work.
> 
> Has anyone used OpenJPA in a modular project?  Is there a solution for this?
> 
> Thanks a bunch!
> 
> Rob Scala
> 

Re: please help with untime trouble while loading XML (org.xml.sax.SAXException)

[Mark Struberg]

Hi! Does it help if you remove it for now? Should not go grab some xsd from 
remote somewhere tbh.
If we do, then it's a bug!

LieGrue,
strub

> Am 15.03.2021 um 19:21 schrieb Patrice Duroux :
> 
> 
> Hi,
> 
> For the past few weeks, OpenJPA has not been able to systematically
> iniitialize loading the persistence.xml file or to perform the classes
> enhancement due to problem accessing the .xsd files on the Oracle server.
> Is there a way to avoid that? Embedding the required .xsd files as Java
> resources?
> Inactivating this SAX validation using a property?
> 
> Many thanks,
> Patrice
> 
> 
> 
> --
> Sent from: http://openjpa.208410.n2.nabble.com/OpenJPA-Users-f208411.html

Re: CriteriaUpdate/CriteriaDelete support?

[Mark Struberg]

Hi Pawel, thanks for the report. 

I hope I find some time to address that soonish.
Did you create a ticket for it already?

txs and LieGrue,
strub


> Am 24.12.2020 um 09:57 schrieb Pawel Veselov :
> 
> Hello.
> 
> I was rather excited when I saw the statement on
> http://openjpa.apache.org/ that 3.x releases "target" the 2.2 JPA
> Spec, but are *compatible* with specs 2.1 and below specs, sort of
> reading it as 3.x supporting 2.2 spec.
> 
> My excitement was crushed with a rather heavy boulder once I saw that
> the criteria builder simply throws an unsupported operation exception
> in methods to create criteria update/delete objects.
> 
> How far away is OpenJPA from implementing the full 2.2 spec,
> especially these update/delete criteria support?
> 
> -- 
> With best of best regards
> Pawel S. Veselov

[ANN] Apache OpenJPA-3.1.2 released

[Mark Struberg]

The Apache OpenJPA team is pleased to announce the release of Apache OpenJPA 
3.1.2!

Apache OpenJPA is a Java Persistence API implementation project at The Apache 
Software Foundation.
It can be used as a stand-alone POJO persistence layer or integrated into any 
Java EE compliant container and many other lightweight frameworks, such as 
Tomcat and Spring.

The 3.x releases targetting the JSR-338 Java Persistence 2.2 specification is 
our most current production ready release. It is fully backward compatible 
compatible to our JPA 2.1, 2.0 and 1.0 releases.

The release is available through the official Apache Maven Central repository 
and on our download page
https://openjpa.apache.org/downloads.html

The full change log is available here:
https://openjpa.apache.org/openjpa-3.1.x.html

We welcome your help and feedback. For more information on how to report
problems, and to get involved, visit the project website at

https://openjpa.apache.org/


The Apache OpenJPA Team

Re: Delimited identifiers issue

[Mark Struberg]

Hi Xavier!

I'd need to debug through this!

Can you probably share how you created the Entities and the database?
Do you create the DB manually or via OpenJPA?
Is there an explicit name in the @Column annotation or the orm?

In other words: for reproducing the problem we need to know pretty much exactly 
how your situation looks like.

Txs and LieGrue,
strub


> Am 19.05.2020 um 11:55 schrieb Xavier Baqués :
> 
> Hi,
> 
> Adding more context information, my use case is that I am trying to upgrade
> from MySQL 5.7.27 to MySQL 8 but in MySQL 8 there are new reserved words
> which collide with column names I am using on my tables. That is why I need
> to be able to delimit column names.
> 
> I tried to delimit column names in both MySQL 5 and MySQL 8 and got the
> same error message described in my previous email.
> 
> 
> 
> Thanks,
> 
> Xavier Baques
> 
> Software Engineer
> 
> --
> 
>  
> 
> 
> EMAIL: x...@streamsets.com
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Tue, May 19, 2020 at 11:40 AM Xavier Baqués  wrote:
> 
>> Hi,
>> 
>> Sorry to bother you again but I've been trying to find a solution for
>> above issue but still couldn't find a way to make it work.
>> 
>> Any suggestions on what I could do to make it work?
>> 
>> 
>> Thanks,
>> 
>> Xavier Baques
>> 
>> Software Engineer
>> 
>> --
>> 
>>  
>> 
>> 
>> EMAIL: x...@streamsets.com
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Wed, May 13, 2020 at 7:08 PM Xavier Baqués  wrote:
>> 
>>> Hi,
>>> 
>>> I am using OpenJPA with Delimited identifiers enabled through the orm.xml
>>> file, I am able to create the database schema and I can see debugging that
>>> table columns are correctly delimited with double quotes in Table object,
>>> however, when I ask EntityManager to create a query it loads the table
>>> metadata into the Table object without columns being delimited, only table
>>> name is delimited. As the columns in table metadata are not delimited, when
>>> the JPQL is parsed an exception is thrown because it cannot find delimited
>>> column names (they are correctly delimited from the corresponding Entity
>>> object) in table metadata (in this case the Table object that gets created
>>> from the table metadata does not have the column names delimited).
>>> 
>>> Is there any way to fix that by changing the configuration and make
>>> Delimited identifiers work correctly?
>>> 
>>> System information:
>>> 
>>> OpenJPA version: 2.4.3
>>> MySQL version: 5.7.27
>>> 
>>> Stack trace of the error:
>>> 
>>> 
>>> org.apache.openjpa.persistence.ArgumentException:
>>> "com.streamsets.apps.pipelinestore.backend.bean.TestInfo.description"
>>> declares column ""DESCRIPTION"", but this column does not exist in table
>>> ""TEST_INFO"".
>>> at
>>> org.apache.openjpa.jdbc.meta.MappingInfo.mergeColumn(MappingInfo.java:692)
>>> at
>>> org.apache.openjpa.jdbc.meta.MappingInfo.createColumns(MappingInfo.java:593)
>>> at
>>> org.apache.openjpa.jdbc.meta.ValueMappingInfo.getColumns(ValueMappingInfo.java:178)
>>> at
>>> org.apache.openjpa.jdbc.meta.strats.StringFieldStrategy.map(StringFieldStrategy.java:84)
>>> at
>>> org.apache.openjpa.jdbc.meta.FieldMapping.setStrategy(FieldMapping.java:148)
>>> at
>>> org.apache.openjpa.jdbc.meta.RuntimeStrategyInstaller.installStrategy(RuntimeStrategyInstaller.java:81)
>>> at
>>> org.apache.openjpa.jdbc.meta.FieldMapping.resolveMapping(FieldMapping.java:498)
>>> at
>>> org.apache.openjpa.jdbc.meta.FieldMapping.resolve(FieldMapping.java:463)
>>> at
>>> org.apache.openjpa.jdbc.meta.ClassMapping.resolveNonRelationMappings(ClassMapping.java:921)
>>> at
>>> org.apache.openjpa.jdbc.meta.ClassMapping.resolveMapping(ClassMapping.java:858)
>>> at org.apache.openjpa.meta.ClassMetaData.resolve(ClassMetaData.java:1813)
>>> at
>>> org.apache.openjpa.meta.MetaDataRepository.processBuffer(MetaDataRepository.java:829)
>>> at
>>> org.apache.openjpa.meta.MetaDataRepository.resolveMapping(MetaDataRepository.java:784)
>>> at
>>> org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.java:664)
>>> at
>>> org.apache.openjpa.meta.MetaDataRepository.getMetaDataInternal(MetaDataRepository.java:418)
>>> at
>>> org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:389)
>>> at
>>> org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:472)
>>> at
>>> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JPQLExpressionBuilder.java:177)
>>> at
>>> org.apac

Re: PESSMISTIC_READ takes out exclusive lock on Postgres

[Mark Struberg]

Hi Pawel!

Would need to dig deeper. Can you possibly please create a JIRA ticket for 
OPENJPA?
So we can better track this!

Thanks!

LieGrue,
strub


> Am 20.02.2020 um 18:22 schrieb Pawel Veselov :
> 
> Hello.
> 
> I've found out that using PESSIMISTIC_READ on an entity with postgres
> uses 'for update' lock, which is actually exclusive.
> 
> I understand JPA specification says that it's permissible to do that,
> but I really need a shared lock for what I'm trying to achieve.
> 
> Is it possible to control somehow? I've had to resolve to using native
> queries, and I'd like to avoid this as much as possible...
> 
> Thank you!
>  Pawel.
> 
> -- 
> With best of best regards
> Pawel S. Veselov

Re: mysql @Column unique

[Mark Struberg]

Do you have an example code somewhere?

LieGrue,
strub


> Am 04.11.2019 um 16:46 schrieb Matthew Broadhead 
> :
> 
> i am using  value="buildSchema(ForeignKeys=true)" /> to generate the MySQL tables based 
> on the entities.
> 
> however @Column(unique = true) does not seem to have flaged the field as 
> unique

Re: Detach on cascade turns on phatonmly

[Mark Struberg]

Ouch, I see what you mean. 
This is about the _default_ compat option.

I gonna investigate - thanks!


LieGrue,
strub

> Am 22.07.2019 um 15:11 schrieb Pawel Veselov :
> 
> Hello Mark.
> 
> I'm afraid you misunderstand the problem. Have you looked at the changes I
> made?
> There is no shared use for the entities between threads. We don't modify
> the compat options directly, OpenJPA does that.
> The problem is in OpenJPA changing compatibility variables (for cascading
> operations), and that those variables are near global,
> which causes other threads to behave differently and unexpectedly. Plus,
> restoring the state has a race condition, causing
> the wrong compat settings to get stuck.
> 
> -- Pawel.
> 
> 
> On Thu, Jul 18, 2019 at 9:30 AM Mark Struberg 
> wrote:
> 
>> Hi Pawel!
>> 
>> I fear you are hitting a rather lightly used path in OpenJPA.
>> Although I wonder why you can hit a race condition?
>> An EntityManager - and thus it's entities - are intended to be accessed
>> only from a single thread at a time.
>> Storing entities in a shared cache or whatever concurrently used object is
>> always a bad idea.
>> 
>> Can you probably shade a light on why you need those compat modes in the
>> first place?
>> Usually one doesn't need it if the app is properly designed.
>> Are you probably working on an ancient legacy code. And in that case, what
>> patterns do they use to work with JPA?
>> 
>> txs and LieGrue,
>> strub
>> 
>> 
>>> Am 12.07.2019 um 15:37 schrieb Pawel Veselov :
>>> 
>>> Hello.
>>> 
>>> https://issues.apache.org/jira/browse/OPENJPA-2792
>>> 
>>> Has took me a while to track down, and leaves quite unpleasant surprises,
>>> as your entities become detached without warning, which leads to phantom
>>> NPEs at places you never expect to happen.
>>> 
>>> --
>>> With best of best regards
>>> Pawel S. Veselov
>> 
>> 
> 
> -- 
> With best of best regards
> Pawel S. Veselov

Re: Detach on cascade turns on phatonmly

[Mark Struberg]

Hi Pawel!

I fear you are hitting a rather lightly used path in OpenJPA.
Although I wonder why you can hit a race condition?
An EntityManager - and thus it's entities - are intended to be accessed only 
from a single thread at a time.
Storing entities in a shared cache or whatever concurrently used object is 
always a bad idea.

Can you probably shade a light on why you need those compat modes in the first 
place?
Usually one doesn't need it if the app is properly designed.
Are you probably working on an ancient legacy code. And in that case, what 
patterns do they use to work with JPA?

txs and LieGrue,
strub


> Am 12.07.2019 um 15:37 schrieb Pawel Veselov :
> 
> Hello.
> 
> https://issues.apache.org/jira/browse/OPENJPA-2792
> 
> Has took me a while to track down, and leaves quite unpleasant surprises,
> as your entities become detached without warning, which leads to phantom
> NPEs at places you never expect to happen.
> 
> -- 
> With best of best regards
> Pawel S. Veselov

Re: using different datasource during junit tests

[Mark Struberg]

You can provide a map to 
javax.persistence.Persistence#createEntityManagerFactory(String pu, Map 
properties);
That way you can define the Driver, jdbc user + pwc, url, etc

That way you don't need anything in your persistence.xml.

If you use CDI you can create a producer for it or use the one from DeltaSpike.
Or you use TomEE where you can do the same. You can pass a property map to 
DeltaSpike CdiCtrl boot(Map):
https://github.com/apache/deltaspike/blob/master/deltaspike/cdictrl/api/src/main/java/org/apache/deltaspike/cdise/api/CdiContainer.java#L58

LieGrue,
strub

> Am 13.02.2019 um 17:10 schrieb Francesco Chicchiriccò :
> 
> On 13/02/19 15:04, Matthew Broadhead wrote:
>> i am trying to test some business logic that depends heavily on the results 
>> of calls to entitymanager.  i would like to keep the persistence.xml exactly 
>> as it is in the main project but basically load in a different database 
>> underneath.  is there a way to initialise the entitymanager and point it to 
>> a development database for the duration of the tests?
> 
> Hi Matthew,
> I normally do as you require above, but with some Spring ORM support, not 
> sure it fits with your scenario; if so, I can point you to some working 
> samples.
> 
> Regards.
> 
> -- 
> 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: @Converter(autoApply=true)

[Mark Struberg]

 Hi Rob!
Thanks for your example!
I'll gonna check your sample and try to get it working.It's likely not working 
in 3.0.0 right now, but we try to fix it for 3.0.1.
What you can do in the meantime is to use a ValueHandler instead. 
This is the OpenJPA specific version which predates the JPA @Converter logic.
rsandtner/openjpa-converter

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
rsandtner/openjpa-converter

Contribute to rsandtner/openjpa-converter development by creating an account on 
GitHub.
 |

 |

 |




LieGrue,strub

On Wednesday, 6 February 2019, 22:05:48 CET, Robert Scala 
 wrote:  
 
 Hello,

I'm trying OpenJPA 3.0.0 so I can use the AttributeConverter annotation.

But I'm having problems.  My converter is simple:

import javax.persistence.AttributeConverter;
import javax.persistence.Converter;

@Converter(autoApply = true)
public class StringInternConverter implements AttributeConverter
{
     @Override
     public String convertToDatabaseColumn(String attribute)
     {
     return attribute;
     }

     @Override
     public String convertToEntityAttribute(String dbData)
     {
     return dbData != null ? dbData.intern(): null;
     }
}

The problem is that I can't get JPA to see this converter.  When I add 
it to persistence.xml like this:

     
com.be.db.jpa.StringInternConverter

The enhancer complains that it StringInternConverter "does not have 
persistence metadata".

Is there a trick to get this to work?

Thanks,

Rob


-- 
Rob Scala
Buyers Edge, Inc.
351 North Frontage Road, Suite A210
New London, CT 06320
Phone: (860) 865-2127
  

Re: OpenJPA issues black hole

[Mark Struberg]

Not yet but it‘s on my list!
And please keep reminding me! Tryind to do it this week!

LieGrue,
Dtrub

> Am 20.01.2019 um 23:43 schrieb Pawel Veselov :
> 
> Mark,
> 
> Entschuldigung for the nagging, any luck? :)
> 
>> On Tue, Jan 1, 2019 at 11:08 PM Mark Struberg  
>> wrote:
>> 
>> Sorry Pavel, right now sitting over a nasty glitch in a few of our unit 
>> tests.After that I'll run through your tickets.
>> LieGrue,strub
>> 
>>On Monday, 31 December 2018, 05:08:06 CET, Pawel Veselov 
>>  wrote:
>> 
>> Hello.
>> 
>> I've been using OpenJPA for a while, and I'd like to understand what's
>> going on with the bug fixing process.
>> 
>> Over the course of time, I have filed a few bugs. I'm only going to
>> concentrate on ones that we had to fix ourselves:
>> OPENJPA-2733
>> OPENJPA-2735
>> OPENJPA-2736
>> OPENJPA-2749
>> 
>> Explanation of what the problem is, and the attempt to patch is
>> provided for each one of those. There was absolutely no activity from
>> the development team on any of those.
>> 
>> There hasn't been any release activity for a while as well. Now I see
>> that 2.4.3 and 3.0.0 have we been released. That's great, but do they
>> address any of the problems we have? It's not that easy to find out,
>> and considering the bug activity, I would expect they aren't.
>> 
>> My question is then simply - what do I need to do to be heard? AFAIK I
>> do a good amount of pre-work for determining the test cases, the root
>> causes, and fixes suggestions, for the development team to be able to
>> include this. Obviously, I don't understand OpenJPA code enough to
>> know whether my fixes are correct, but that's why I leave it for the
>> development team to close.

[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

Re: deleting openjpa_sequence_table

[Mark Struberg]

Hi Matthew!

As Craig already explained they contain the hightest value for a specified 
index.
Of course only if no Database Sequence got used!
The reason to use this over a Sequence is to have a database independent 
counter which is fully portable.

There are also multiple 'modes' for the sequence to operate!
I personally prefer the counter by table.

In your persistence.xml you might probably have something like the following in 
your  section:



openjpa.Sequence determines the strategy to use plus the details. 'class-table' 
will create 1 row per @Entity basically.

You can read more over here:
https://openjpa.apache.org/builds/3.0.0/apache-openjpa/docs/ref_guide_sequence.html


So in hindsight dealing with the openjpa_sequence values might be your least 
problematic issue.
The more problematic one might be that you have to re-assign new primary keys 
to your migrated data.

Consider you have an @Entity Customer. Then both or your databases to merge 
might have a Customer with the id=1. And 2 customers with id=2, etc.
That means merging them together will create a unique key violation. 

One strategy is to leave one db as is and update the other one.
If you e.g. have 18572 customers in database_A. Then you could update all your 
customers in database_B to be 1+id. Means your customer with id=1 in 
database_B will get id=11, etc. And of course you will have to update all 
the 1:n referencing tables as well. So e.g. update all Address entries to have 
a customerid=customerid+10; 
You might need to drop/disable all foreign-key indexes before you start doing 
this update and then activate them again after all is done. 
And of course this can only be done while there is no moving target. That means 
you have to stop operation on your db. If this is not possible then you might 
want to do this with 'filtered tx-logs'. But that is WAY more effort...

After that you can merge both without a conflict.

Do others have a better idea?

LieGrue,
strub



> Am 05.01.2019 um 01:04 schrieb Craig Russell :
> 
> It might be best to inspect the tables and merge them when you merge the 
> databases. IIRC they hold the highest keys that have been used and simply 
> dropping them might introduce errors.
> 
> Craig
> 
>> On Jan 4, 2019, at 5:40 AM, Matthew Broadhead 
>>  wrote:
>> 
>> i am about to merge a few databases.  each database has an 
>> openjpa_sequence_table.  do i just drop these tables?
> 
> Craig L Russell
> c...@apache.org
> 

Re: openjpa indexes

[Mark Struberg]

 The generator happens in the MappingTool. This is the top-level.Probably the 
best guess is to set a breakpoint in  DBDictionary#getCreateIndexSQLThe 
DBDictionary (and it's respecive subclasses) is where all the adopting to 
different databases happens.
LieGrue,strub

On Tuesday, 18 December 2018, 03:53:51 CET, Maxim Solodovnik 
 wrote:  
 
 Unfortunately I was unable to find where this magic happens :(
can someone from devs can point me to the right direction?

On Sat, 15 Dec 2018 at 16:58, Matthew Broadhead
 wrote:

> i am using mysql
>
> On 15/12/2018 09:35, Maxim Solodovnik wrote:
> > Indicies seems to be auto-created on
> > @Id, @PrimaryKeyJoinColumn and @JoinColumn
> >
> > just have tested with MySql DB Index seems not being created
> > will try to debug
> >
> >
> > On Thu, 13 Dec 2018 at 23:33, Matthew Broadhead
> >  wrote:
> >
> >> i saw a similar example but was hoping the index could be automatically
> >> created.  some indexes are automatically created but seeingly not
> others.
> >> i tried the annotations as in the example and the index is never
> >> created.  here is what i have added to my class
> >> @Entity
> >> @Table(name = "billentry", indexes = {
> >>          @Index(name = "I_BLLNTRY_SECTION", columnList =
> >> "BILLSECTION_ID", unique = false),
> >>          @Index(name = "I_BLLNTRY_BILLTEMPLATEENTRY", columnList =
> >> "btentryid", unique = false) })
> >> public class BillEntry implements Serializable {
> >>      private static final long serialVersionUID = 1L;
> >>
> >>      @Id
> >>      @GeneratedValue(strategy = GenerationType.IDENTITY)
> >>      private Long id;
> >>
> >>      @Version
> >>      private Long version;
> >>
> >>      @ManyToOne
> >>      private BillSection billSection;
> >>
> >>      @ManyToOne
> >>      @Column(name = "btentryid")
> >>      private BillTemplateEntry billTemplateEntry;
> >>
> >> On 12/12/2018 02:34, Maxim Solodovnik wrote:
> >>> This might help for the latest OpenJpa (it should have partial 2.1
> >>> compatibility)
> >>> https://stackoverflow.com/a/22658951/3571661
> >>>
> >>> On Wed, 12 Dec 2018 at 01:17, Matthew Broadhead
> >>>  wrote:
> >>>
>  recently had an application running slowly and had to manually add an
>  index.  but openjpa seemed to create all the other indexes
> >> automatically.
>  my structure was like
>  Bill
>  has a collection of
>  BillMoney
>  has a collection of
>  BillSection
>  has a collection of
>  BillEntry
> 
>  BillMoney was automatically created with index I_BLLMONY_BILL which
>  related to the Bill id
>  BillSection was automatically created with index I_BLLSCTN_BILLMONEY
>  which related to the BillMoney section
>  But BillEntry did not have an index.
> 
>  BillEntry was a pre existing table so could that have something to do
>  with it?  is there any way to force indexes to be created?
> 
> >>
>
>

-- 
WBR
Maxim aka solomax
  

Re: OpenJPA issues black hole

[Mark Struberg]

 Sorry Pavel, right now sitting over a nasty glitch in a few of our unit 
tests.After that I'll run through your tickets.
LieGrue,strub

On Monday, 31 December 2018, 05:08:06 CET, Pawel Veselov 
 wrote:  
 
 Hello.

I've been using OpenJPA for a while, and I'd like to understand what's
going on with the bug fixing process.

Over the course of time, I have filed a few bugs. I'm only going to
concentrate on ones that we had to fix ourselves:
OPENJPA-2733
OPENJPA-2735
OPENJPA-2736
OPENJPA-2749

Explanation of what the problem is, and the attempt to patch is
provided for each one of those. There was absolutely no activity from
the development team on any of those.

There hasn't been any release activity for a while as well. Now I see
that 2.4.3 and 3.0.0 have we been released. That's great, but do they
address any of the problems we have? It's not that easy to find out,
and considering the bug activity, I would expect they aren't.

My question is then simply - what do I need to do to be heard? AFAIK I
do a good amount of pre-work for determining the test cases, the root
causes, and fixes suggestions, for the development team to be able to
include this. Obviously, I don't understand OpenJPA code enough to
know whether my fixes are correct, but that's why I leave it for the
development team to close.

Thank you,
  Pawel.
  

Re: OpenJPA2.3.0 - Fail to find object with multiple collection + reverse mapping of polymorphic objects + EAGER-FETCHING

[Mark Struberg]

 do you mind to share the entities?
LieGrue,strub

On Friday, 2 November 2018, 12:31:20 CET, Stephane Passignat 
 wrote:  
 
 Hello,

When a class (Product) have 2 collections (I only checked with reversed 
mapping) of concrete objects (one of MecanicalFeature and one of 
ElectricalFeature) inheriting from a common class (Feature), finding an 
existing Product fails (return null).

Here is a class diagram : 
http://www.plantuml.com/plantuml/png/SoWkIImgAStDuKhEIImkLWWeoayfJIw1yjnI4qjAYrAXFD_KvCIypEJ475HXrvpKv98YP74kT9KAkherTd3J81fmIaET01IqKr3IKbB0CCnAGIaN9bQiXA4UOZoQXbIm85I7GsfU2j3B

Here is the ER diagram
http://www.plantuml.com/plantuml/png/RSvFIyCm60Rm-_ifNkTb0SVk4iF6ia9FokpE8pNlR31fI_v0Y_ZTLLhR2iijvFSyUNOXAX-Jit2dwMfgmgXAI-kEuPjL8M27dEEwUBZFiltFOIZ4H5jldFBzvOFwtm0l1K-Yuzia-BQSsRNnPDxhYPa5Cm8gemaTnQhHORY4I9wQsBSK08OzBwTdUJuK33y1__sRImPV8ygE--9yEjv6Y39_FG0kv_pLNeQMCO-RZS3nvN4rawTShc17jKxEVWC0


The entityManager.find generates the following SQL (I replaced useless columns 
by *) :
SELECT t0.*,
      t3.*
FROM Product t0
      LEFT OUTER JOIN Feature t3 ON t0.id = t3.PRODUCT_ID
WHERE (t3.disc IS NULL OR t3.disc IN ('Mecanical'))
  AND t0.id = 0
ORDER BY t3.PRODUCT_ID ASC

The eager fetching on those collections consider only one collection or only 
one type of concrete class. A solution would be to have, in the IN clause the 
list of all possible subtypes of all collections mapped on the target table 
(‘Mecanical’, ‘Electrical’).


Regards,


Provenance : Courrier pour 
Windows 10
  

Re: Primary key string ids are stripped

[Mark Struberg]

 'not able to find it right after'
+1 to what Matthew said. We need a bit more info.
Say you have the following code:
Customer c = new Customer();c.setName("Bla");em.persist(c);Long id = c.getId();
is this about what you did?
Plus: what enhancement strategy do you use? And what @GenerationType if any on 
the @Id?

There are now so many different scenarios out there that it might be better if 
you could provide parts of your code in a sample.
LieGrue,strub

On Friday, 26 October 2018, 09:55:37 CEST, Matthew Broadhead 
 wrote:  
 
 can you give a small example?  do you mean when the field annotated @Id 
is a String then find returns null?

On 25/10/2018 02:34, Pawel Veselov wrote:
> Hello.
>
> I just found out, the hard way, that OpenJPA strips the string entity
> IDs when doing find().
> It doesn't strip those values when saving entities with corresponding
> primary keys.
> Is there a particular reason for this? It sounds weird to create an
> entity with primary key "0\t", but then not be able to find it right
> after
>
> Thank you,
>    Pawel.

  

[ANNOUNCE] master branch in GIT

[Mark Struberg]

Good morning!

As previously discussed: I now created a master branch which will contain the 
ongoing work in Apache OpenJPA 3.x.
The 'trunk' git branch is now defunct and only kept for historical reasons. 
I'll add a small note in the README.

Please check out the master branch for futher work!

Oh and a reminder again:
To get the most recent OpenJPA code just use

$> git clone https://gitbox.apache.org/repos/asf/openjpa.git.


LieGrue,
strub

[ANNOUNCE] The Apache OpenJPA source code repository has been switched to GIT

[Mark Struberg]

Good afternoon!
Our main source repo is now hosted via GIT
> Chris Thistlethwaite added a comment - Just now > SVN marked read only, 
> git.apache.org updated, migrated to gitbox.
>
> Go through any setup on https://gitbox.apache.org/setup/
>
> Your remotes are now:
> 
> https://gitbox.apache.org/repos/asf/openjpa.git
> or
> https://github.com/apache/openjpa.git 

LieGrue and have fun,strub

Re: clone object

[Mark Struberg]

In practice this is likelymuch more complicated. Where are the boundaries?
If you have a Person which has a relation to a Company, then I assume you do 
not want to also clone the whole Company, right? ;)
But of course, the n Address rows probably should get cloned?

Do you see what I mean? This is imo all depending on your exact intention and 
the tables in question.

LieGrue,
strub


> Am 27.07.2018 um 16:08 schrieb Matthew Broadhead 
> :
> 
> i have a complicated object with a large number of children, each child 
> possibly having their own large number of children.  what would be great in 
> OpenJPA is if you could, say, detach an object and run a command which would 
> null all @Id and @Version fields in the detached Object and all its 
> descendants.  i suppose it has to be done manually though...
> 
> On 27/07/18 15:52, Albert Lee wrote:
>> If the java object implements Serializable or Clonable, you can
>> writeObject/readObject to clone to a new entity.  The new object will be
>> detached and you can reset the id and version as you wish.
>> 
>> 
>> On Fri, Jul 27, 2018 at 8:39 AM, Matthew Broadhead <
>> matthew.broadh...@nbmlaw.co.uk.invalid> wrote:
>> 
>>> i don't think it would clear the id and version fields?  do you mean using
>>> SerializationUtils clone?
>>> https://commons.apache.org/proper/commons-lang/apidocs/org/
>>> apache/commons/lang3/SerializationUtils.html
>>> 
>>> 
>>> On 27/07/18 15:09, Albert Lee wrote:
>>> 
 If the entity is serializable have you try writing it out and read it back
 to a new object?
 
 On Fri, Jul 27, 2018, 6:05 AM Matthew Broadhead
  wrote:
 
 is there a way to deep clone a JPA object automatically?  i.e. to copy
> all the parameters and children but clear the id and version fields?
> 
> i saw that it is possible to do em.detach(object); and then reset the id
> and version but by the time i have done that i may as well have written
> a full copy function.
> 
> 
>> 
> 

Re: native query

[Mark Struberg]

puh, cannot answer out of my head, but will write a unit test to dig.
Might help if you could provide a sample which also runs against EclipseLink 
and Hibernate.
After all this is also about interoperability.

LieGrue,
strub

> Am 07.09.2017 um 18:56 schrieb Matthew Broadhead 
> :
> 
> hi i tried this but it seems to just hang.  is this not supported?
> 
> private void updateAutoIncrement(int currentId) {
>   Query q = em.createNativeQuery("ALTER TABLE test auto_increment = ?;");
>   q.setParameter(1, (currentId + 2));
>   q.executeUpdate();
> }

[ANNOUNCE] Welcome Will Dazey as OpenJPA committer!

[Mark Struberg]

Good morning ladies and gents!

I'm glad to announce that Will has accepted our invitation to join the Apache 
OpenJPA project as a new committer!

Will did already ship great patches and we are sure he will be a great addition 
to our team.

Welcome Will!

the Apache OpenJPA PMC

:wq

[ANNOUNCE] Welcome Jody Grassel as Apache OpenJPA PMC member

[Mark Struberg]

Good afternoon ladies and gents!


Jody Grassel has been involved with OpenJPA for many years.
Based on that, the Apache OpenJPA project is glad to announce that Jody has 
accepted our invitation to join the OpenJPA Project Management Committee!

Welcome Jody!

best regards,
the Apache OpenJPA community

Re: JPA criteria

[Mark Struberg]

Hi!

You mind to send a patch?

txs and LieGrue,
strub


> Am 21.07.2017 um 23:50 schrieb Matthew Broadhead 
> :
> 
> Hi Rob,
> 
> yes thanks in the end i did this
> Join detail = entity.join(EntityZ_.details);
> 
> the documentation page linked in my first email 
> (https://openjpa.apache.org/builds/2.4.2/apache-openjpa/docs/jpa_overview_criteria.html)
>  is for 2.4.2 which is what i am using bundled in TomEE 7.0.3.   the examples 
> on the page should be updated to reflect what we are saying here?
> 
> Matt
> 
> On 21/07/2017 19:32, Rob Scala wrote:
>> Matthew,
>> 
>> I haven't done this yet, but the documentation states that join returns a 
>> Join object, not a Root.  I think in your case, it returns a 
>> Join.
>> 
>> Where does the documentation need to be updated?
>> 
>> Rob
>> 
>> 
>> On 07/21/2017 12:50 PM, Matthew Broadhead wrote:
>>> Thanks Rob, this works:
>>> criteriaQuery.where(criteriaBuilder.equal(entity.get(EntityZ_.id), 
>>> entityId));
>>>  maybe the documentation needs updating?
>>> 
>>> 
>>> 
>>> On 21/07/2017 12:49, Rob Scala wrote:
 
 Matthew,
 
 On your second point, expression methods (equal, gt, etc) belong to the 
 CriteriaBuilder, not to the expressions.
 
 cb.equal(exp1, exp2)
 
 http://docs.oracle.com/javaee/7/api/javax/persistence/criteria/CriteriaBuilder.html
  
 
 Rob
 
 
 On 07/21/2017 05:03 AM, Matthew Broadhead wrote:
> Following the example on page 
> https://openjpa.apache.org/builds/2.4.2/apache-openjpa/docs/jpa_overview_criteria.html
> 
> CriteriaBuilder criteriaBuilder = em.getCriteriaBuilder();
> CriteriaQuery criteriaQuery = 
> criteriaBuilder.createQuery(EntityZ.class);
> Root entity = criteriaQuery.from(EntityZ.class);
> Root detail = entity.join(entity.get(EntityZ_.details));
> 
> results in
> 
> Type mismatch: cannot convert from Expression> to 
> SingularAttribute
> 
> also is there a typo?
> 
> qdef.where(customer.get(Customer_.name).equal("John 
> Doe").and(order.get(Order_.status).equal(OrderStatus.DELIVERED).not())); 
> 
> there is no such function as equal?  should it be equals? also in my case:
> 
> criteriaQuery.where(entity.get(EntityZ_.id).equals(entityId));
> 
> results in:
> 
> The method where(Expression) in the type CriteriaQuery 
> is not applicable for the arguments (boolean)
 
 -- 
 *Rob Scala*
 Director of Information Technology
 Buyers Edge, Inc
 351 N. Frontage Road, Suite A210
 New London, CT 06320
 Phone - 860-865-2127
 Fax - 860-701-0576
>>> 
> 

Re: Problem with EntityExistsException

[Mark Struberg]

Hi Malte!

puh, that's a pretty tricky puzzler.

You flush and detach. At this point the 'data' instance has the information 
that it got inserted. 
Since the entity got detached it also has no further information that the 
transaction got rolled back.
So technically I can understand what happens.

I also do not think this is ruled out by the spec. Otoh it's surely also not 
defined that it should work.
So my guess is that you are hitting a rather unspecified area of JPA.

What if you just move the detach to a finally block?
Would that probably solve your problem?

LieGrue,
strub
 
> Am 24.04.2017 um 17:55 schrieb Malte :
> 
> Hello all!
> 
> In a special situation, I'll get a wrong EntityExistsException.
> 
> I've extract the problem to a simple project (attached).
> 
> I do this:
>try {
>  entManager.persist(data);
>  entManager.flush();
>  entManager.detach(data);
> 
>  doOtherDBCallsWithError();
> 
>  entManager.getTransaction().commit();
>} catch (Exception e) {
>   entManager.getTransaction().rollback();
> 
>   entManager.getTransaction().begin();
>   entManager.persist(data);
>   entManager.getTransaction().commit();
>} 
> 
> If doOtherDBCallsWithError throws an Exception, it is not possible to persist 
> the object in the catch-block. The second persists throws 
> "org.apache.openjpa.persistence.EntityExistsException: Attempt to persist 
> detached object "de.test.model.Test-1".  If this is a new instance, make sure 
> any version and/or auto-generated primary key fields are null/default when 
> persisting." If I use merge instead, the object will also not persist. If I 
> remove the detach, everything works.
> 
> Is this a bug or is the call order persist-flush-detach-commit against the 
> specification?
> 
> Best regards,
> Malte
> 

Re: JPA 2.1

[Mark Struberg]

Hi Charlie!

trunk is targetting JPA-2.1 but we still have quite a bit to go until we are 
spec compliant.

LieGrue,
strub

> Am 10.02.2017 um 15:02 schrieb Charlie Mordant :
> 
> Hi best ORM mapper implementers!
> 
> I caught some mailing list mails which spoke about 2.1 implementation on
> the way. What's the current status?
> Spring 5 forces 2.1 compliance as a prerequisite so it should be nice to
> have a 2.1 support (also, I really dislike Hibernate as an orm, OpenJPA is
> far more bullet proof IMHO).
> 
> Best regards,
> 
> -- 
> Charlie Mordant
> 
> Full OSGI/EE stack made with Karaf:
> https://github.com/OsgiliathEnterprise/net.osgiliath.parent

Re: java.lang.NoSuchMethodError: ....AggregationEntity.pcGetManagedFieldCount()

[Mark Struberg]

Maybe you have an import of a class which doesn't exist?

Did you try to debug into and do a Class.forName in the debugger?
It also might be something missing by the annotations.

Just a first guess. 

LIeGrue,
strub


> Am 03.02.2017 um 20:17 schrieb Pachler, Uwe :
> 
> Hi, 
> 
> I'm facing a nasty issue with my freshly refactored entity class hierarchy 
> (things did work before):
> 
> openjpa.MetaData - The class "com.mycompany.FamilyAggregationEntity" listed 
> in the openjpa.MetaDataFactory configuration property could not be loaded by 
> org.apache.openejb.arquillian.openejb.SWClassLoader@5b408dc3; ignoring.
> 2091  corbox_appgateway  TRACE  [main] openjpa.MetaData - 
> java.lang.NoSuchMethodError: 
> de.datagroup.corbox.appgateway.bizimpl.db.entities.AggregationEntity.pcGetManagedFieldCount()Ijava.lang.NoSuchMethodError:
>  
> de.datagroup.corbox.appgateway.bizimpl.db.entities.AggregationEntity.pcGetManagedFieldCount()I
>   at 
> de.datagroup.corbox.appgateway.bizimpl.db.entities.ManagedCustomersFamilyAggregationEntity.(ManagedCustomersFamilyAggregationEntity.java)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> org.apache.openjpa.meta.MetaDataRepository.classForName(MetaDataRepository.java:1559)
>   at 
> org.apache.openjpa.meta.MetaDataRepository.loadPersistentTypesInternal(MetaDataRepository.java:1535)
>   at 
> org.apache.openjpa.meta.MetaDataRepository.loadPersistentTypes(MetaDataRepository.java:1513)
>   at 
> org.apache.openjpa.kernel.AbstractBrokerFactory.loadPersistentTypes(AbstractBrokerFactory.java:279)
>   at 
> org.apache.openjpa.kernel.AbstractBrokerFactory.initializeBroker(AbstractBrokerFactory.java:235)
>   at 
> org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:211)
>   at 
> org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:154)
>   at 
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:226)
>   at 
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:59)
>   at 
> org.apache.openejb.assembler.classic.ReloadableEntityManagerFactory.createEntityManager(ReloadableEntityManagerFactory.java:178)
>   at 
> org.apache.openejb.persistence.JtaEntityManagerRegistry.getEntityManager(JtaEntityManagerRegistry.java:130)
>   at 
> org.apache.openejb.persistence.JtaEntityManager.getEntityManager(JtaEntityManager.java:145)
>   at 
> org.apache.openejb.persistence.JtaEntityManager.typedProxyIfNoTx(JtaEntityManager.java:382)
>   at 
> org.apache.openejb.persistence.JtaEntityManager.createNamedQuery(JtaEntityManager.java:430)
> 
> The entity class in question does appear in the list printed by OpenJPA  as 
> 'persistend type name' before the exception happens:
> 
> 2043  corbox_appgateway  TRACE  [main] openjpa.MetaData - 
> parsePersistentTypeNames() found [... com.mycompany.FamilyAggregationEntity 
> ...]
> 
> I have a hierarchy of entity classes, like this:
> 
> @Entity
> @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
> public abstract class AggregationEntity implements Aggregation, Serializable {
> ..
> }
> 
> @Entity
> @Table(name="...")
> @NamedQueries({
> ...
> })
> public class FamilyAggregationEntity extends AggregationEntity {
> ..
> }
> 
> There are other entity subclasses of AggregationEntity, and these were 
> present and working before adding FamilyAggregationEntity..
> 
> I also tried @MappedSuperclass on AggregationEntity instead of 
> @Entity/@Inheritance (which is probably better JPA-standards-wise), but that 
> didn't help either...
> 
> Any ideas greatly appreciated.
> 
> Thanks,
> 
> Uwe
> 

Re: Request for gradle equivalent to ant script for Enahncer

[Mark Struberg]

Roberto, do you mind to probably contribute this to the OpenJPA project?
Could make a nice addition alongside the openjpa-maven-plugin!

txs and LieGrue,
strub

> Am 18.01.2017 um 16:13 schrieb Roberto Cortez :
> 
> Hi Vardhaman,
> Sorry for this late response.
> I've been working on a OpenJPA Gradle plugin, and I was only able to release 
> it in the last couple of days. Here is the link for 
> it:https://github.com/radcortez/openjpa-gradle-plugin
> 
> Please, let me know how it works out for you.
> Cheers,Roberto 
> 
>On Monday, January 9, 2017 4:25 PM, vardhaman narasagoudar 
>  wrote:
> 
> 
> Dear Team,
> 
> Good day,
> 
> Does any one has compiled JPA pojo using Enhancer on gradle for tomcat, If
> yes, can they share the sample or equivalent to ant which is present in the
> site,
> 
> Looking forward for your valuable suggestion.
> 
> -- 
> Thanks & Regards
> Vardhaman B.N
> 9945840928
> 
> 

[ANNOUNCE] Welcome Christian Schneider as new OpenJPA committer

[Mark Struberg]

Good evening!

The OpenJPA community is happy to announce that Christan Schneider will join 
the project as committer.
Christian is an OSGi Expert and especially intersted to smoothen the experience 
of running OpenJPA in Camel, Karaf, etc.

Welcome on board, Christian!

your OpenJPA team

Re: fetching associations

[Mark Struberg]

Hi Matthew!

EclipseLink seems to open a new connection for lazy loading by using a new 
temporary EntityManager and Transaction. And no XA transaction afaik. 
Of course this is by far not a portable behaviour as neither Hibernate nor 
OpenJPA support this. I also have no clue how it behaves in case of an 
OptimisticLockException. I mean the lazy loading can literally happen a few 
minutes later...

Whether to go back to EclipseLink is a question on how your whole application 
looks like. You did use a non-portable feature and of course it is now a bit 
harder to switch providers. But it's not impossible. 
The usual solution is to keep the EntityManager open for the whole request. 
How big is your app and how old is the codebase? 
Do you use XA or resource-local?
Does it use many EJBs or do you already mainly use CDI? 

In case of the later you can use a @RequestScoped EntityManager + DeltaSpike 
@Transactional for example.
https://deltaspike.apache.org/documentation/jpa.html

Sample code
With XA (JTA):
https://github.com/struberg/lightweightEE/blob/jtacdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/tools/EntityManagerProducer.java#L35
https://github.com/struberg/lightweightEE/blob/jtacdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/impl/EmployeeServiceImpl.java
https://github.com/struberg/lightweightEE/blob/jtacdi11/backend-api/src/main/resources/META-INF/persistence.xml#L9
https://github.com/struberg/lightweightEE/blob/jtacdi11/gui/src/main/tomee/conf/tomee.xml

With ResourceLocal:
https://github.com/struberg/lightweightEE/blob/cdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/tools/EntityManagerProducer.java
https://github.com/struberg/lightweightEE/blob/cdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/impl/EmployeeServiceImpl.java
https://github.com/struberg/lightweightEE/blob/cdi11/backend/src/main/resources/persistence-CaroLine.properties
https://github.com/struberg/lightweightEE/blob/cdi11/backend-api/src/main/resources/META-INF/persistence.xml


I also wrote a few blog posts which might help you understand this topic, e.g.
https://struberg.wordpress.com/2015/04/21/transaction-and-exception-handling-in-ejbs-and-javaee7-transactional/

Of course the entitymanager-per-request pattern also has a few limitations, 
e.g. if cannot lazy load data in subsequent responses (data has to be rendered 
during the initial request).
But it's rather easy to prevent such a scenario. Usually you will only use 
Entities in CRUD dialogues anyway.
I would e.g. _not_ use the entities in DataTables on a search dialogue. In that 
case I'd rather use a dedicated list item via SELECT NEW. This is much faster, 
has way less memory overhead and also will prevent you from a lot optimistic 
locking pain.

Feel free to ask more questions, this is a rather complex and often not well 
enough understood topic.

LieGrue,
strub




> Am 14.11.2016 um 20:12 schrieb Matthew Broadhead 
> :
> 
> so if the managedbean is not an ejb anymore and therefore the transaction is 
> closed how does it work for eclipselink?  do they use some magic?  are there 
> any plans for implementing this "feature" in the future?  after spending a 
> few months migrating to myfaces and openjpa on the suggestion of romain i now 
> find that openjpa cannot lazy load entities from jsf which is fairly 
> disappointing to say the least.  is my best route to go back to eclipselink?
> 
> On 09/11/2016 17:40, Mark Struberg wrote:
>> Oki all clear. The internal EntityManager will get closed when you leave the 
>> outer @Stateless method.
>> @Stateless EJBSs really are nothing else than beans with an interceptor 
>> which opens and commits the transaction and EntityManager on the outermost 
>> EJB level.
>> 
>> Since the @ManagedBean is not an EJB anymore you don't have any transaction 
>> nor EntityManager open anymore in your render_response phase in JSF. Which 
>> means that OpenJPA cannot provide lazyloading for you.
>> 
>> I personally prefer to use the entitymanager-per-request patter and using 
>> CDI with a @RequestScoped EntityManager. But that might be a bigger change 
>> in architecture for you.
>> Other options are:
>> 
>> * touching the required bits in your DAO
>> 
>> * using eager fetching
>> * using a fetch-plan
>> * using DTOs
>> 
>> LieGrue,
>> strub
>> 
>> 
>> 
>> 
>> 
>>> On Wednesday, 9 November 2016, 17:31, Matthew Broadhead 
>>>  wrote:
>>>> sorry for the delay in replying i was very busy
>>> as a simple example there is a generic Dao class to return the results
>>> of a namedquery
>>> @Stateless
>>> public class DAO {
>>>  @PersistenceContext(unitName = "widgetDat

Re: fetching associations

[Mark Struberg]

Oki all clear. The internal EntityManager will get closed when you leave the 
outer @Stateless method.
@Stateless EJBSs really are nothing else than beans with an interceptor which 
opens and commits the transaction and EntityManager on the outermost EJB level.

Since the @ManagedBean is not an EJB anymore you don't have any transaction nor 
EntityManager open anymore in your render_response phase in JSF. Which means 
that OpenJPA cannot provide lazyloading for you.

I personally prefer to use the entitymanager-per-request patter and using CDI 
with a @RequestScoped EntityManager. But that might be a bigger change in 
architecture for you.
Other options are: 

* touching the required bits in your DAO

* using eager fetching
* using a fetch-plan
* using DTOs

LieGrue,
strub





> On Wednesday, 9 November 2016, 17:31, Matthew Broadhead 
>  wrote:
> > sorry for the delay in replying i was very busy
> 
> as a simple example there is a generic Dao class to return the results 
> of a namedquery
> @Stateless
> public class DAO {
>  @PersistenceContext(unitName = "widgetDataSource")
>  private EntityManager em;
>  
>  @SuppressWarnings("unchecked")
>  public  List namedFind(Class clazz, String 
> query) {
>  return em.createNamedQuery(query, clazz).getResultList();
>  }
>  
> }
> call the namedFind from another stateless
> @Stateless
> public class WidgetDAO {
>  @EJB
>  private DAO dao;
>  ...
>  public List findAll() {
>  return dao.namedFind(Widget.class, "Widget.findAll");
>  }
>  
> }
> this is loaded into a managedbean
> @ManagedBean
> @ViewScoped
> public class WidgetBean {
>  @EJB
>  private WidgetDAO widgetDao;
>  private List widgetList;
>  public void onload(){
>  setWigdetList(widgetDao.fildAll());
>  }
>  ...setter getter of widgetList
> }
> which is supposed to display in jsf
> 
> http://www.w3.org/1999/xhtml";
>  xmlns:h="http://java.sun.com/jsf/html";
>  xmlns:ui="http://java.sun.com/jsf/facelets";
>  xmlns:f="http://java.sun.com/jsf/core";
>  template="/WEB-INF/include/layout.xhtml">
>  ...
>   value="#{widgetBean.widgetList}">
>   value="#{widget.subWidgets}">
>  ...where are the sub widgets?
>  
>  
> 
> 
> Like i say if i loop through the widgets (or maybe the subwidgets as 
> well) it then loads in the JSF.  so it lazy loads in java but not in 
> JSF.  should i change to eager when i generate the entities or is there 
> something else i can do?  is it supposed to work the same as eclipselink?
> 
> 
> On 02/11/2016 08:06, Mark Struberg wrote:
>>  Hi Matthew!
>> 
>>  Now I'm back on my notebook.
>>  What transaction mechanism are you using? JTA or ResourceLocal?
>>  And what technology to control the transactions? EJBs? CDI? Spring?
>> 
>>  It boils down to be more a question about appliction architecture than 
> about OpenJPA, but still very important to cover. So just go ahead, I'm 
> pretty sure we can help you.
>> 
>>  LieGrue,
>>  strub
>> 
>>>  Am 24.10.2016 um 10:34 schrieb Matthew Broadhead 
> :
>>> 
>>>  HI, I am using TomEE 7.0.1 and I just switched from Plume to Plus. I 
> was using eclipselink and now I am converting to OpenJPA.  When I fetch a set 
> of 
> entities and then try to iterate through their associations in JSF the list 
> is 
> empty.  in eclipselink they were populated by default.  if i loop through the 
> entities in Java before displaying in JSF then they are populated (i guess 
> they 
> get lazy loaded).  is there a setting that needs to be changed?  like 
> generating 
> with all associations as eager or setting a flag in persistence.xml?  what 
> would 
> give the same default as eclipselink? seemed like an easy question but i 
> could 
> not find anything by searching.
> 

Re: fetching associations

[Mark Struberg]

Hi Matthew!

Now I'm back on my notebook. 
What transaction mechanism are you using? JTA or ResourceLocal?
And what technology to control the transactions? EJBs? CDI? Spring?

It boils down to be more a question about appliction architecture than about 
OpenJPA, but still very important to cover. So just go ahead, I'm pretty sure 
we can help you.

LieGrue,
strub

> Am 24.10.2016 um 10:34 schrieb Matthew Broadhead 
> :
> 
> HI, I am using TomEE 7.0.1 and I just switched from Plume to Plus. I was 
> using eclipselink and now I am converting to OpenJPA.  When I fetch a set of 
> entities and then try to iterate through their associations in JSF the list 
> is empty.  in eclipselink they were populated by default.  if i loop through 
> the entities in Java before displaying in JSF then they are populated (i 
> guess they get lazy loaded).  is there a setting that needs to be changed?  
> like generating with all associations as eager or setting a flag in 
> persistence.xml?  what would give the same default as eclipselink? seemed 
> like an easy question but i could not find anything by searching.

Re: fetching associations

[Mark Struberg]

Hi! 
I sounds like you did hit the classic lazy loading issue. eclipselink opens a 
connection again, but this is not specced. In Hibernate you will end up with a 
LazyInitializationException.
It's not an OpenJPA issue but the way transactions work in JavaEE by default.
For JSF I recommend to not use EJB transactions but a @RequestScoped 
EntityManager producer in CDI together with Apache DeltaSpike @Transactional.

Can add links later when on notebook.

lieGrue,
Strub

> Am 27.10.2016 um 21:07 schrieb gilbertoca :
> 
> I'm not entirely sure, but you need to make the enhancement of the entities
> [1].
> 
> Regards,
> 
> Gilberto
> 
> [1]
> https://openjpa.apache.org/builds/2.4.1/apache-openjpa/docs/manual.html#ref_guide_pc_enhance
> 
> 
> 
> --
> View this message in context: 
> http://openjpa.208410.n2.nabble.com/fetching-associations-tp7589828p7589836.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: OpenJPA and TomEE 7.0.1 - 2.1 spec

[Mark Struberg]

Hi Gilbert!

the JPA-2.1 Converters are definitely on our List and we would be glad if you 
would join us with the effort to implement this feature (and others).
 
I personally didn’t yet miss this feature because the JPA-2.1 Converters are a 
bit limited to be honest.
I’d rather use the OpenJPA ValueHandlers, because they also allow you a much 
more fine grained control over how it should look in the DataBase as well.

Our ASF colleague Reinhard did write a sample on GitHub. 
We should probably use this to improve our documentation. 

https://github.com/rsandtner/openjpa-converter/tree/master/src

Would be great if could tell us what you think about it!

txs LieGrue,
strub

> Am 20.10.2016 um 15:00 schrieb gilbertoca :
> 
> Hello everyone. I hope you're having a good day. 
> 
> I'm TomEE 7 user, mainly of the amazing tomee-embedded-maven-plugin.
> Following the Romain Manni-Bucau advice from this discussion about the setup
> of Hibernate and Eclipselink setup [1], I would like to offer my help on
> OpenJPA 2.1 development. Right now my requirement is converters for
> javax.time and schema-generation. 
> I've never helped directly an open source project, just reporting issues and
> fixing some docs. I think mentoring and guideline will be needed.
> So, I want to help!
> 
> Regards,
> 
> Gilberto
> 
> https://twitter.com/Gilberto_gca
> blog.gilbertoca.com
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://openjpa.208410.n2.nabble.com/OpenJPA-and-TomEE-7-0-1-2-1-spec-tp7589826.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: Null field not persisted for Dates

[Mark Struberg]

Hi Vincenzo!

No worries, your english is fine. 

The writeExternal is invoked to serialize away the entity. Whether the receiver 
side gets just the normal entity fields (unenhanced so to say) or also the 
_loaded and _dirty fields is a question of the configuration. 

I usually use the following setup:
https://github.com/struberg/lightweightEE/blob/master/backend-api/src/main/resources/META-INF/persistence.xml#L26

Together with the openjpa-maven-plugin to enhance the classes at build time
https://github.com/struberg/lightweightEE/blob/master/backend-api/pom.xml#L66
I should clean up the connection section config. That's a left over from many 
years back. But it should basically work.

I've wrote up a bit about enhancement strategies many years ago, maybe it helps:
https://struberg.wordpress.com/2012/01/08/jpa-enhancement-done-right/


Do you have a small sample which we can use to reproduce the problem?

txs and LieGrue,
strub





> On Saturday, 15 October 2016, 19:25, Vincenzo D'Aniello 
>  wrote:
> > Hi, i've set this property in the persistence unit:
> 
>  value="loaded(DetachedStateField=true)"/> 
> 
> but when the entity object try to be detached, an exception
> NoSuchMethodException is thrown because openjpa try to execute the
> writeExternal method on the entity class object.
> 
> I have not understand abaut enhancer, Enhancement. There is a complete
> example how do remote ejb call with ejb entity beans?
> 
> I use Tomee 1.7.4 naturally with openejb, openjpa, sorry for my english.
> 
> 
> 
> --
> View this message in context: 
> http://openjpa.208410.n2.nabble.com/Null-field-not-persisted-for-Dates-tp5993519p7589809.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> 

Re: trying to run JPA Console inside Intellij IDEA results in this....

[Mark Struberg]

oh another thing which makes me curious. 

IIRC then we only use the 
ProxySetupStateManager.java:230in case of subclassing if the entities did not 
get properly enhanced at all.

This means you are not using build-time enhancement and also no javaagent.

Can you please check the classfile?

$> javap -c target/classes/de/netversys/domain/Distribution.class | less


And check whether the class has a PersistenceCapable interface in the bytecode.

LieGrue,
strub




> On Thursday, 22 September 2016, 8:02, Mark Struberg 
>  wrote:
> > Yes, it contains the number of the field it has problems with as int.
> 
> Counting of fields start with the uppermost entity class. The fild numbers 
> get 
> generated during enhancement.
> 
> LieGrue,
> Strub
> 
> 
>>  Am 21.09.2016 um 23:25 schrieb Marc Logemann 
> :
>> 
>>  And when u look at the stacktrace on this line:
>> 
>>  at de.netversys.domain.Distribution.pcProvideField(Distribution.java)
>> 
>>  you see a method which wouldnt be there if the class is not enhanced right?
>> 
>>  2016-09-21 22:00 GMT+02:00 Mark Struberg :
>>>  MappedSuperclasses should not be any problem. At least if it got 
> enhanced as well. Are you missing this probably?
>>> 
>>>  LieGrue,
>>>  strub
>>> 
>>> 
>>> 
>>>  On Wednesday, 21 September 2016, 21:57, Marc Logemann 
>  wrote>
>>>  >Hi,
>>>  >
>>>  >
>>>  >yeah. Every entity extends AbstractEntity which is a 
> MappedSuperclass.
>>>  >
>>>  >
>>>  >2016-09-21 20:15 GMT+02:00 Mark Struberg 
> :
>>>  >
>>>  >Hi Marc!
>>>  >>
>>>  >>Is the entity Distribution part of a supertype/subtype 
> constellation aka inheritance?
>>>  >>Does this class 'extends' something? And where do these 
> classes reside?
>>>  >>
>>>  >>
>>>  >>LieGrue,
>>>  >>strub
>>>  >>
>>>  >>
>>>  >>
>>>  >>
>>>  >>
>>>  >>
>>>  >>> On Wednesday, 21 September 2016, 18:27, Marc Logemann 
>  wrote:
>>>  >>> > can somebody hint me where i need to look out for? 
> Quite weird message
>>>  >>>
>>>  >>>
>>>  >>> [2016-09-21 18:24:13]  fatal user error>
>>>  >>> org.apache.openjpa. persistence.ArgumentException: Errors 
> encountered while
>>>  >>> resolving metadata.  See nested exceptions for details.
>>>  >>> [2016-09-21 18:24:13] java.lang.RuntimeException:
>>>  >>> 
>>>  >>> org.apache.openjpa. persistence. PersistenceException: 
> Unexpected attribute
>>>  >>> type "int" for persistence-capable class
>>>  >>> "de.netversys.domain. Distribution"
>>>  >>> is detected. If the entity is packaged in a jar file, this 
> may be caused by
>>>  >>> one or more inherited class of the entity not being 
> packaged in the same
>>>  >>> jar file. Please check all inherited class(es) are 
> packaged in the same jar
>>>  >>> file.
>>>  >>> at
>>>  >>> org.apache.openjpa.meta. ProxySetupStateManager. 
> providedIntField( ProxySetupStateManager.java: 230)
>>>  >>> at de.netversys.domain. Distribution.pcProvideField( 
> Distribution.java)
>>>  >>> at
>>>  >>> org.apache.openjpa.meta. ProxySetupStateManager. 
> setProxyData( ProxySetupStateManager.java: 62)
>>>  >>> at
>>>  >>> org.apache.openjpa.meta. ClassMetaData.resolveMeta( 
> ClassMetaData.java:1927)
>>>  >>> at org.apache.openjpa.meta. ClassMetaData.resolve( 
> ClassMetaData.java:1808)
>>>  >>> at
>>>  >>> org.apache.openjpa.meta. MetaDataRepository. 
> processBuffer( MetaDataRepository.java:829)
>>>  >>> at
>>>  >>> org.apache.openjpa.meta. MetaDataRepository. resolveMeta( 
> MetaDataRepository.java:726)
>>>  >>> at
>>>  >>> org.apache.openjpa.meta. MetaDataRepository.resolve( 
> MetaDataRepository.java:650)
>>>  >>> at
>>>  >>> org.apache.openjpa.meta. MetaDataRepository. 
> getMetaDataInternal( MetaDataRepository.java:418)
>>>  >>> at
>>>  >>> org.apache.openjpa.meta. MetaDataRepository. getMetaData( 
> MetaDataRepository.java:389)
>>>  >&

Re: trying to run JPA Console inside Intellij IDEA results in this....

[Mark Struberg]

Yes, it contains the number of the field it has problems with as int.

Counting of fields start with the uppermost entity class. The fild numbers get 
generated during enhancement.

LieGrue,
Strub

> Am 21.09.2016 um 23:25 schrieb Marc Logemann :
> 
> And when u look at the stacktrace on this line:
> 
> at de.netversys.domain.Distribution.pcProvideField(Distribution.java)
> 
> you see a method which wouldnt be there if the class is not enhanced right?
> 
> 2016-09-21 22:00 GMT+02:00 Mark Struberg :
>> MappedSuperclasses should not be any problem. At least if it got enhanced as 
>> well. Are you missing this probably?
>> 
>> LieGrue,
>> strub
>> 
>> 
>> 
>> On Wednesday, 21 September 2016, 21:57, Marc Logemann 
>>  wrote>
>> >Hi,
>> >
>> >
>> >yeah. Every entity extends AbstractEntity which is a MappedSuperclass.
>> >
>> >
>> >2016-09-21 20:15 GMT+02:00 Mark Struberg :
>> >
>> >Hi Marc!
>> >>
>> >>Is the entity Distribution part of a supertype/subtype constellation aka 
>> >>inheritance?
>> >>Does this class 'extends' something? And where do these classes reside?
>> >>
>> >>
>> >>LieGrue,
>> >>strub
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>> On Wednesday, 21 September 2016, 18:27, Marc Logemann 
>> >>>  wrote:
>> >>> > can somebody hint me where i need to look out for? Quite weird 
>> >>> > message
>> >>>
>> >>>
>> >>> [2016-09-21 18:24:13] 
>> >>> org.apache.openjpa. persistence.ArgumentException: Errors encountered 
>> >>> while
>> >>> resolving metadata.  See nested exceptions for details.
>> >>> [2016-09-21 18:24:13] java.lang.RuntimeException:
>> >>> 
>> >>> org.apache.openjpa. persistence. PersistenceException: Unexpected 
>> >>> attribute
>> >>> type "int" for persistence-capable class
>> >>> "de.netversys.domain. Distribution"
>> >>> is detected. If the entity is packaged in a jar file, this may be caused 
>> >>> by
>> >>> one or more inherited class of the entity not being packaged in the same
>> >>> jar file. Please check all inherited class(es) are packaged in the same 
>> >>> jar
>> >>> file.
>> >>> at
>> >>> org.apache.openjpa.meta. ProxySetupStateManager. providedIntField( 
>> >>> ProxySetupStateManager.java: 230)
>> >>> at de.netversys.domain. Distribution.pcProvideField( Distribution.java)
>> >>> at
>> >>> org.apache.openjpa.meta. ProxySetupStateManager. setProxyData( 
>> >>> ProxySetupStateManager.java: 62)
>> >>> at
>> >>> org.apache.openjpa.meta. ClassMetaData.resolveMeta( 
>> >>> ClassMetaData.java:1927)
>> >>> at org.apache.openjpa.meta. ClassMetaData.resolve( 
>> >>> ClassMetaData.java:1808)
>> >>> at
>> >>> org.apache.openjpa.meta. MetaDataRepository. processBuffer( 
>> >>> MetaDataRepository.java:829)
>> >>> at
>> >>> org.apache.openjpa.meta. MetaDataRepository. resolveMeta( 
>> >>> MetaDataRepository.java:726)
>> >>> at
>> >>> org.apache.openjpa.meta. MetaDataRepository.resolve( 
>> >>> MetaDataRepository.java:650)
>> >>> at
>> >>> org.apache.openjpa.meta. MetaDataRepository. getMetaDataInternal( 
>> >>> MetaDataRepository.java:418)
>> >>> at
>> >>> org.apache.openjpa.meta. MetaDataRepository. getMetaData( 
>> >>> MetaDataRepository.java:389)
>> >>> at
>> >>> org.apache.openjpa.meta. MetaDataRepository. getMetaData( 
>> >>> MetaDataRepository.java:472)
>> >>> at
>> >>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder. getClassMetaData( 
>> >>> JPQLExpressionBuilder.java: 175)
>> >>> at
>> >>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder. 
>> >>> resolveClassMetaData( JPQLExpressionBuilder.java: 151)
>> >>> at
>> >>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder. 
>> >>> getCandidateMetaData( JPQLExpressionBuilder.java: 241)
>> >>> at
>> >>> org.apache.ope

Re: trying to run JPA Console inside Intellij IDEA results in this....

[Mark Struberg]

MappedSuperclasses should not be any problem. At least if it got enhanced as 
well. Are you missing this probably?

LieGrue,
strub



On Wednesday, 21 September 2016, 21:57, Marc Logemann  
wrote>
>Hi,
>
>
>yeah. Every entity extends AbstractEntity which is a MappedSuperclass.
>
>
>2016-09-21 20:15 GMT+02:00 Mark Struberg :
>
>Hi Marc!
>>
>>Is the entity Distribution part of a supertype/subtype constellation aka 
>>inheritance?
>>Does this class 'extends' something? And where do these classes reside?
>>
>>
>>LieGrue,
>>strub
>>
>>
>>
>>
>>
>>
>>> On Wednesday, 21 September 2016, 18:27, Marc Logemann 
>>>  wrote:
>>> > can somebody hint me where i need to look out for? Quite weird message
>>>
>>>
>>> [2016-09-21 18:24:13] 
>>> org.apache.openjpa. persistence.ArgumentException: Errors encountered while
>>> resolving metadata.  See nested exceptions for details.
>>> [2016-09-21 18:24:13] java.lang.RuntimeException:
>>> 
>>> org.apache.openjpa. persistence. PersistenceException: Unexpected attribute
>>> type "int" for persistence-capable class
>>> "de.netversys.domain. Distribution"
>>> is detected. If the entity is packaged in a jar file, this may be caused by
>>> one or more inherited class of the entity not being packaged in the same
>>> jar file. Please check all inherited class(es) are packaged in the same jar
>>> file.
>>> at
>>> org.apache.openjpa.meta. ProxySetupStateManager. providedIntField( 
>>> ProxySetupStateManager.java: 230)
>>> at de.netversys.domain. Distribution.pcProvideField( Distribution.java)
>>> at
>>> org.apache.openjpa.meta. ProxySetupStateManager. setProxyData( 
>>> ProxySetupStateManager.java: 62)
>>> at
>>> org.apache.openjpa.meta. ClassMetaData.resolveMeta( ClassMetaData.java:1927)
>>> at org.apache.openjpa.meta. ClassMetaData.resolve( ClassMetaData.java:1808)
>>> at
>>> org.apache.openjpa.meta. MetaDataRepository. processBuffer( 
>>> MetaDataRepository.java:829)
>>> at
>>> org.apache.openjpa.meta. MetaDataRepository. resolveMeta( 
>>> MetaDataRepository.java:726)
>>> at
>>> org.apache.openjpa.meta. MetaDataRepository.resolve( 
>>> MetaDataRepository.java:650)
>>> at
>>> org.apache.openjpa.meta. MetaDataRepository. getMetaDataInternal( 
>>> MetaDataRepository.java:418)
>>> at
>>> org.apache.openjpa.meta. MetaDataRepository. getMetaData( 
>>> MetaDataRepository.java:389)
>>> at
>>> org.apache.openjpa.meta. MetaDataRepository. getMetaData( 
>>> MetaDataRepository.java:472)
>>> at
>>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder. getClassMetaData( 
>>> JPQLExpressionBuilder.java: 175)
>>> at
>>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder. 
>>> resolveClassMetaData( JPQLExpressionBuilder.java: 151)
>>> at
>>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder. 
>>> getCandidateMetaData( JPQLExpressionBuilder.java: 241)
>>> at
>>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder. 
>>> getCandidateMetaData( JPQLExpressionBuilder.java: 211)
>>> at
>>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder. getCandidateType( 
>>> JPQLExpressionBuilder.java: 204)
>>> at
>>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder. access$200( 
>>> JPQLExpressionBuilder.java:79)
>>> at
>>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder$ ParsedJPQL.populate( 
>>> JPQLExpressionBuilder.java: 2426)
>>> at org.apache.openjpa.kernel. jpql.JPQLParser.populate( JPQLParser.java:60)
>>> at
>>> org.apache.openjpa.kernel. ExpressionStoreQuery. populateFromCompilation( 
>>> ExpressionStoreQuery.java:162)
>>> at org.apache.openjpa.kernel. QueryImpl.newCompilation( QueryImpl.java:672)
>>> at
>>> org.apache.openjpa.kernel. QueryImpl. compilationFromCache( 
>>> QueryImpl.java:653)
>>> at
>>> org.apache.openjpa.kernel. QueryImpl. compileForCompilation( 
>>> QueryImpl.java:619)
>>> at
>>> org.apache.openjpa.kernel. QueryImpl.compileForExecutor( QueryImpl.java:681)
>>> at org.apache.openjpa.kernel. QueryImpl.compile(QueryImpl. java:588)
>>> at
>>> org.apache.openjpa. persistence.EntityManagerImpl. 
>>> createQuery(EntityManagerImpl. java:996)
>>> at
>>> org.apache.openjpa. persistence.EntityManagerImpl. 
>>> createQuery(EntityManagerImpl. java:978)
>>> at
>>> org.apache.openjpa. persistence.EntityManagerImpl. 
>>> createQuery(EntityManagerImpl. java:101)
>>> at
>>> com.intellij.jpa.remote.impl. RemoteEntityManagerImpl. createQuery( 
>>> RemoteEntityManagerImpl.java: 39)
>>>
>>
>
>
>

Re: trying to run JPA Console inside Intellij IDEA results in this....

[Mark Struberg]

Hi Marc!

Is the entity Distribution part of a supertype/subtype constellation aka 
inheritance?
Does this class 'extends' something? And where do these classes reside?


LieGrue,
strub





> On Wednesday, 21 September 2016, 18:27, Marc Logemann 
>  wrote:
> > can somebody hint me where i need to look out for? Quite weird message
> 
> 
> [2016-09-21 18:24:13] 
> org.apache.openjpa.persistence.ArgumentException: Errors encountered while
> resolving metadata.  See nested exceptions for details.
> [2016-09-21 18:24:13] java.lang.RuntimeException:
> 
> org.apache.openjpa.persistence.PersistenceException: Unexpected attribute
> type "int" for persistence-capable class 
> "de.netversys.domain.Distribution"
> is detected. If the entity is packaged in a jar file, this may be caused by
> one or more inherited class of the entity not being packaged in the same
> jar file. Please check all inherited class(es) are packaged in the same jar
> file.
> at
> org.apache.openjpa.meta.ProxySetupStateManager.providedIntField(ProxySetupStateManager.java:230)
> at de.netversys.domain.Distribution.pcProvideField(Distribution.java)
> at
> org.apache.openjpa.meta.ProxySetupStateManager.setProxyData(ProxySetupStateManager.java:62)
> at
> org.apache.openjpa.meta.ClassMetaData.resolveMeta(ClassMetaData.java:1927)
> at org.apache.openjpa.meta.ClassMetaData.resolve(ClassMetaData.java:1808)
> at
> org.apache.openjpa.meta.MetaDataRepository.processBuffer(MetaDataRepository.java:829)
> at
> org.apache.openjpa.meta.MetaDataRepository.resolveMeta(MetaDataRepository.java:726)
> at
> org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.java:650)
> at
> org.apache.openjpa.meta.MetaDataRepository.getMetaDataInternal(MetaDataRepository.java:418)
> at
> org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:389)
> at
> org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:472)
> at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JPQLExpressionBuilder.java:175)
> at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaData(JPQLExpressionBuilder.java:151)
> at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:241)
> at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:211)
> at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(JPQLExpressionBuilder.java:204)
> at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$200(JPQLExpressionBuilder.java:79)
> at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.populate(JPQLExpressionBuilder.java:2426)
> at org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:60)
> at
> org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(ExpressionStoreQuery.java:162)
> at org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:672)
> at
> org.apache.openjpa.kernel.QueryImpl.compilationFromCache(QueryImpl.java:653)
> at
> org.apache.openjpa.kernel.QueryImpl.compileForCompilation(QueryImpl.java:619)
> at
> org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:681)
> at org.apache.openjpa.kernel.QueryImpl.compile(QueryImpl.java:588)
> at
> org.apache.openjpa.persistence.EntityManagerImpl.createQuery(EntityManagerImpl.java:996)
> at
> org.apache.openjpa.persistence.EntityManagerImpl.createQuery(EntityManagerImpl.java:978)
> at
> org.apache.openjpa.persistence.EntityManagerImpl.createQuery(EntityManagerImpl.java:101)
> at
> com.intellij.jpa.remote.impl.RemoteEntityManagerImpl.createQuery(RemoteEntityManagerImpl.java:39)
> 

[ANNOUNCE] Welcome Francesco Chicchiriccò as new OpenJPA PMC member

[Mark Struberg]

Good evening!

Please welcome Francesco Chicchiriccò as new Apache OpenJPA PMC member!

Francesco, txs for helping to push OpenJPA forward!

best regards,

the OpenJPA team

Re: weird bug with order by (2.4.1)

[Mark Struberg]

Oki, thanks for the feedback!
The reason I did ask was to know whether we introduced a regression.
If you found that it worked in older versions then please let us know. 


> ORDER BY t0.oid DESC, t24.distribution_oid ASC

Looking at your query it seems to me that those 2 columns contain the same 
values?
t0 is the table 'distribution' and t24.distribution_oid is most likely a FK 
pointing to t0. Is that correct?
In that case t0.oid and t24.distribution_oid will always be the same values? or 
is there some left outer with other id's? Is there inheritance involved 
somewhere?


LieGrue,
strub


On Sunday, 11 September 2016, 3:37, Marc Logemann  
wrote:
>
>I recently migrated to 2.4.1 from 2.4.0 because of this bug. So negative on 
>this one.
>
>
>In the meantime i discovered why MariaDB has index problems. Its not because 
>of the second order parameter, but because of the second order parameter which 
>is the same field in a different table but with ASC order. The ASC is the 
>thing but of course the second parameter shouldnt be there at all.
>
>
>I suspect its because of the "join fetch". Just for the record, of course i 
>dont use @OrderBy on the relation. If i do it on the 1:n relation in question, 
>i get this: ORDER BY t0.oid DESC, t24.distribution_oid ASC,  
>t24.distribution_oid ASC LIMIT ?, ?
>
>
>Perhaps i try to downgrade a bit more because i am quite sure that this 
>problem is new somehow i did another upgrade from an older version to 
>2.4.0 a few weeks ago.
>
>
>regards
>marc
>
>
>
>
>2016-09-10 9:48 GMT+02:00 Mark Struberg :
>
>Hi Marc!
>>
>>Can you please try with 2.4.0?
>>Is the generated query the same or without the column?
>>
>>LieGrue,
>>strub
>>
>>
>>
>>
>>
>>On Saturday, 10 September 2016, 2:14, Marc Logemann  
>>wrote:
>>
>>
>>>
>>>
>>>Hi,
>>>
>>>i suspect i found a bug which has bad consequences on MariaDB not using an
>>>index anymore. Lets take this JPAQL:
>>>
>>>select d from Distribution d join fetch d.distributionContainerList where
>>>d.client = ?1 and d.deleted = ?2 order by d.oid desc
>>>
>>>My Distribution entity is quite big when it comes to 1:n relations and
>>>stuff. So i wont get into the details here, but this  JPAQL will result in
>>>the following SQL (compressed because too big otherwise):
>>>
>>>SELECT t0.oid, t0.jpaversion, t0.created, t0.createdby, ...
>>>FROM distribution t0 LEFT OUTER JOIN dist_altfrom t1 ON t0.altfrom_oid
>>>= t1.oid
>>>LEFT OUTER JOIN clients t3 ON t0.client_oid = t3.oid LEFT OUTER
>>>JOIN
>>>cmrcarrier t17 ON t0.cmrcarrier_oid = t17.oid LEFT OUTER JOIN
>>>countries
>>>t20 ON t0.empf_country = t20.isocode2 LEFT OUTER JOIN users t21 ON
>>>t0.user_oid = t21.oid INNER JOIN dist_container t24 ON t0.oid =
>>>t24.distribution_oid LEFT OUTER JOIN countries t2 ON t1.country =
>>>t2.isocode2 LEFT OUTER JOIN address t4 ON t3.address_oid = t4.oid
>>>LEFT
>>>OUTER JOIN bankaccount t6 ON t3.bankaccount_oid = t6.oid LEFT OUTER
>>>JOIN communication t7 ON t3.communication_oid = t7.oid LEFT OUTER
>>>JOIN
>>>persons t8 ON t3.cperson_oid = t8.oid LEFT OUTER JOIN bankaccount
>>>t10
>>>ON t3.nnbankaccount_oid = t10.oid LEFT OUTER JOIN workplaces t11 ON
>>>t3.workplaceoid = t11.oid LEFT OUTER JOIN address t18 ON
>>>t17.address_oid = t18.oid LEFT OUTER JOIN communication t19 ON
>>>t17.communication_oid = t19.oid LEFT OUTER JOIN persons t22 ON
>>>t21.person_oid = t22.oid LEFT OUTER JOIN workplaces t23 ON
>>>t21.workplaceoid = t23.oid LEFT OUTER JOIN distribution t25 ON
>>>t24.old_distribution_oid = t25.oid LEFT OUTER JOIN countries t5 ON
>>>t4.country_id = t5.isocode2 LEFT OUTER JOIN communication t9 ON
>>>t8.communication_oid = t9.oid LEFT OUTER JOIN balance t12 ON
>>>t11.balance = t12.oid LEFT OUTER JOIN balance t13 ON t11.balance2 =
>>>t13.oid LEFT OUTER JOIN clients t14 ON t11.client_oid = t14.oid
>>>LEFT
>>>OUTER JOIN printer t15 ON t11.labelprinter = t15.oid LEFT OUTER
>>>JOIN
>>>printer t16 ON t11.laserprinter = t16.oid
>>>WHERE (t0.client_oid = ? AND t0.deleted = ?)
>>>ORDER BY t0.oid DESC, t24.distribution_oid ASC LIMIT ?, ?
>>>
>>>
>>>Just look at the order by clause in the SQL. It correctly used t0.oid
>>>because JPAQL said so. But why on earth is there another order clause with
>>>the field "t24.distribution_oid" ?? This is a back reference for a 1:n
>>>relation from Table "dist_container" back to "distribution".
>>>
>>>The real problem is: as soon as there is another sorting parameter from a
>>>joined table, MariaDB doesnt use my ForeignKey Index anymore and does a
>>>FULL-Scan on the t24 table, which is pretty heavy on a multi million
>>>records table. When i leave out that ugly t24.distribution_oid ordering
>>>field, everything is fast and ok.
>>>
>>>Can anyone explain to me how this ordering field gets into the picture?
>>>
>>>thanks
>>>marc
>>>
>>>
>>>
>>
>
>
>

Re: weird bug with order by (2.4.1)

[Mark Struberg]

Hi Marc!

Can you please try with 2.4.0?
Is the generated query the same or without the column?

LieGrue,
strub




On Saturday, 10 September 2016, 2:14, Marc Logemann  
wrote:


>
>
>Hi,
>
>i suspect i found a bug which has bad consequences on MariaDB not using an
>index anymore. Lets take this JPAQL:
>
>select d from Distribution d join fetch d.distributionContainerList where
>d.client = ?1 and d.deleted = ?2 order by d.oid desc
>
>My Distribution entity is quite big when it comes to 1:n relations and
>stuff. So i wont get into the details here, but this  JPAQL will result in
>the following SQL (compressed because too big otherwise):
>
>SELECT t0.oid, t0.jpaversion, t0.created, t0.createdby, ...
>FROM distribution t0 LEFT OUTER JOIN dist_altfrom t1 ON t0.altfrom_oid
>= t1.oid
>LEFT OUTER JOIN clients t3 ON t0.client_oid = t3.oid LEFT OUTER
>JOIN
>cmrcarrier t17 ON t0.cmrcarrier_oid = t17.oid LEFT OUTER JOIN
>countries
>t20 ON t0.empf_country = t20.isocode2 LEFT OUTER JOIN users t21 ON
>t0.user_oid = t21.oid INNER JOIN dist_container t24 ON t0.oid =
>t24.distribution_oid LEFT OUTER JOIN countries t2 ON t1.country =
>t2.isocode2 LEFT OUTER JOIN address t4 ON t3.address_oid = t4.oid
>LEFT
>OUTER JOIN bankaccount t6 ON t3.bankaccount_oid = t6.oid LEFT OUTER
>JOIN communication t7 ON t3.communication_oid = t7.oid LEFT OUTER
>JOIN
>persons t8 ON t3.cperson_oid = t8.oid LEFT OUTER JOIN bankaccount
>t10
>ON t3.nnbankaccount_oid = t10.oid LEFT OUTER JOIN workplaces t11 ON
>t3.workplaceoid = t11.oid LEFT OUTER JOIN address t18 ON
>t17.address_oid = t18.oid LEFT OUTER JOIN communication t19 ON
>t17.communication_oid = t19.oid LEFT OUTER JOIN persons t22 ON
>t21.person_oid = t22.oid LEFT OUTER JOIN workplaces t23 ON
>t21.workplaceoid = t23.oid LEFT OUTER JOIN distribution t25 ON
>t24.old_distribution_oid = t25.oid LEFT OUTER JOIN countries t5 ON
>t4.country_id = t5.isocode2 LEFT OUTER JOIN communication t9 ON
>t8.communication_oid = t9.oid LEFT OUTER JOIN balance t12 ON
>t11.balance = t12.oid LEFT OUTER JOIN balance t13 ON t11.balance2 =
>t13.oid LEFT OUTER JOIN clients t14 ON t11.client_oid = t14.oid
>LEFT
>OUTER JOIN printer t15 ON t11.labelprinter = t15.oid LEFT OUTER
>JOIN
>printer t16 ON t11.laserprinter = t16.oid
>WHERE (t0.client_oid = ? AND t0.deleted = ?)
>ORDER BY t0.oid DESC, t24.distribution_oid ASC LIMIT ?, ?
>
>
>Just look at the order by clause in the SQL. It correctly used t0.oid
>because JPAQL said so. But why on earth is there another order clause with
>the field "t24.distribution_oid" ?? This is a back reference for a 1:n
>relation from Table "dist_container" back to "distribution".
>
>The real problem is: as soon as there is another sorting parameter from a
>joined table, MariaDB doesnt use my ForeignKey Index anymore and does a
>FULL-Scan on the t24 table, which is pretty heavy on a multi million
>records table. When i leave out that ugly t24.distribution_oid ordering
>field, everything is fast and ok.
>
>Can anyone explain to me how this ordering field gets into the picture?
>
>thanks
>marc
>
>
>

Re: Open JPA: MetaDataException After upgrading to Open JPA 2.4.1 & Java 8

[Mark Struberg]

Do you probably have a sample application or anything you can share e.g. on 
github?

txs and LieGrue,
strub


> Am 24.08.2016 um 16:50 schrieb chris666 :
> 
> I upgraded my java app to Open JPA 2.4.1 & Java 8 & im getting the error
> below. Previously I was on Open JPA 2.2.2 & Java 7. Note, the error text
> "target does not exist in table" is not true, that field is in the table.
> 
> Any thoughts?
> 
> 
> 
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:720)
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
> org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:99)
> org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:280)
> org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> org.springframework.aop.framework.adapter.MethodBeforeAdviceInterceptor.invoke(MethodBeforeAdviceInterceptor.java:52)
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> org.springframework.cache.interceptor.CacheInterceptor$1.invoke(CacheInterceptor.java:52)
> org.springframework.cache.interceptor.CacheAspectSupport.invokeOperation(CacheAspectSupport.java:345)
> org.springframework.cache.interceptor.CacheAspectSupport.execute(CacheAspectSupport.java:414)
> org.springframework.cache.interceptor.CacheAspectSupport.execute(CacheAspectSupport.java:327)
> org.springframework.cache.interceptor.CacheInterceptor.invoke(CacheInterceptor.java:61)
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:655)
> com.test.app.DataBCImpl$$EnhancerBySpringCGLIB$$1735a68a.getTblPpwsUserGroupDtls()
> com.test.app.common.RoleMapperGrantedAuthorityFactory.createGrantedAuthority(RoleMapperGrantedAuthorityFactory.java:36)
> waffle.spring.WindowsAuthenticationToken.(WindowsAuthenticationToken.java:84)
> waffle.spring.NegotiateSecurityFilter.doFilter(NegotiateSecurityFilter.java:108)
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
> org.springframework.security.web.csrf.CsrfFilter.doFilterInternal(CsrfFilter.java:100)
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
> org.springframework.security.web.header.HeaderWriterFilter.doFilterInternal(HeaderWriterFilter.java:66)
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
> org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:56)
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:105)
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:214)
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:177)
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:262)
> 
> 
> 
> --
> View this message in context: 
> http://openjpa.208410.n2.nabble.com/Open-JPA-MetaDataException-After-upgrading-to-Open-JPA-2-4-1-Java-8-tp7589507.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: OptimisticLock on Partitioned tables

[Mark Struberg]

Hi Andrej!

I will try to give it a look in the following week.
Please ping back if there is no visible progress.


LieGrue,
strub


> On Wednesday, 24 August 2016, 3:10, Andrej Badinka 
>  wrote:
> > Hi all, I created an issue in openjpa jira: 
> https://issues.apache.org/jira/browse/OPENJPA-2639 but it has no attention 
> for 
> about 4 month.
> 
> I am not sure if there is missing the demo app, as I think that the case is 
> pretty descriptive and simple:
> The db returns 0 rows affected, but openjpa awaits 1 row affected.
> 
> Is there a chance that it will get some attention, or could someone verify if 
> it 
> is invalid?
> From the posgre mailing list attached to the issue it sounds like the 
> behaviour 
> of returning 0 rows is common.
> 
> Thanks and sorry for my bad English :).
> 
> S pozdravom / Best regards
> 
> Ing. Andrej Badinka
> 
> Programátor SW aplikácií
> 
> Tel: +421 2 3278 
> 
> 
> [InterWay]
> 
> InterWay, a.s.
> 
> Sídlo:
> 
> Stará Vajnorská 21, 831 04 Bratislava
> 
> Prevádzka:
> 
> Bratislavská 29, 010 01, 
> Žilina
> 
> Web:
> 
> www.interway.sk
> 
> Ak si tento e-mail nevytlačíte, pomôžete chrániť životné prostredie.
> Please consider your environmental responsibility before printing this e-mail.
> 

Re: JPA 2.1 Support

[Mark Struberg]

You are welcome, and good to have you on board!

I’m sure there are tons of interesting pieces you could help if you like to.

Feel free to drop a mail whenever you need help with building etc.
Many of the parts should already be documented on http://openjpa.apache.org but 
sometimes it’s not as easy to find as it should be.
Feedback about missing documentation is also highly appreciated.

txs and LieGrue,
strub



> Am 18.08.2016 um 17:58 schrieb Roberto Cortez :
> 
> Hi Mark,
> Great! Happy to hear that. 
> Good point. I believe I'm not subscribed. Already requested it, waiting for 
> the email.
> Thank you.
> Cheers,Roberto
>  From: Mark Struberg 
> To: users@openjpa.apache.org 
> Sent: Wednesday, August 17, 2016 11:35 PM
> Subject: Re: JPA 2.1 Support
> 
> Roberto, are you also subscribed to dev @ openjpa.apache.org?
> We will follow up over there.
> 
> txs and LieGrue,
> strub
> 
> 
> 
>> Am 18.08.2016 um 07:27 schrieb Mark Struberg :
>> 
>> Yes yes yes yes. 
>> 
>> So where do we start?
>> 
>> We have a branch, done by Romain mostly, with lots of 2.1 groundwork.
>> We have the jpa spec jar over in Geronimo. We need to make sure it's api 
>> compat with the official jar.
>> 
>> And then we need a strategy when we like to move this to trunk and move the 
>> current trunk to a maintenance branch.
>> 
>> LieGrue,
>> Strub
>> 
>> 
>>> Am 18.08.2016 um 02:50 schrieb Roberto Cortez :
>>> 
>>> Hi,
>>> Sorry for bringing this up again. I would like to know what are the plans 
>>> to move OpenJPA to be JPA 2.1 compliant, if any?
>>> I don't expect it to fall on my lap and I'm happy to contribute to the 
>>> efforts. I've started some work on it, and even got some feedback at start, 
>>> but at the moment seems halted.
>>> Here is some of my work to support standard JPA 2.1 Schema 
>>> generation:https://issues.apache.org/jira/browse/OPENJPA-2554
>>> 
>>> Is there any interest in making this part of the project?
>>> Thank you.
>>> Cheers,Roberto
>> 
> 
> 

[ANNOUNCE] SVN trunk is now OpenJPA-3.0.0!

[Mark Struberg]

Good evening!

To clear the road for adressing JPA-2.1 we moved the current work from trunk to 
branches/2.4.x and upgraded trunk to version 3.0.0!

Please take care where you commit things and for now also plz commit fixes to 
at least trunk and 2.4.x.

Fixes which are important for even older branches (e.g. 2.2.x) should only be 
ported back _after_ getting the OK from the corresponding branch owner. 


Next steps: 
* Romain will merge his work done in the 2.1 branch over to trunk
* We need to update the site
* And then we need to do the rest ;)

txs and LieGrue,
strub

Re: JPA 2.1 Support

[Mark Struberg]

Roberto, are you also subscribed to dev @ openjpa.apache.org?
We will follow up over there.

txs and LieGrue,
strub


 
> Am 18.08.2016 um 07:27 schrieb Mark Struberg :
> 
> Yes yes yes yes. 
> 
> So where do we start?
> 
> We have a branch, done by Romain mostly, with lots of 2.1 groundwork.
> We have the jpa spec jar over in Geronimo. We need to make sure it's api 
> compat with the official jar.
> 
> And then we need a strategy when we like to move this to trunk and move the 
> current trunk to a maintenance branch.
> 
> LieGrue,
> Strub
> 
> 
>> Am 18.08.2016 um 02:50 schrieb Roberto Cortez :
>> 
>> Hi,
>> Sorry for bringing this up again. I would like to know what are the plans to 
>> move OpenJPA to be JPA 2.1 compliant, if any?
>> I don't expect it to fall on my lap and I'm happy to contribute to the 
>> efforts. I've started some work on it, and even got some feedback at start, 
>> but at the moment seems halted.
>> Here is some of my work to support standard JPA 2.1 Schema 
>> generation:https://issues.apache.org/jira/browse/OPENJPA-2554
>> 
>> Is there any interest in making this part of the project?
>> Thank you.
>> Cheers,Roberto
> 

Re: JPA 2.1 Support

[Mark Struberg]

Yes yes yes yes. 

So where do we start?

We have a branch, done by Romain mostly, with lots of 2.1 groundwork.
We have the jpa spec jar over in Geronimo. We need to make sure it's api compat 
with the official jar.

And then we need a strategy when we like to move this to trunk and move the 
current trunk to a maintenance branch.

LieGrue,
Strub


> Am 18.08.2016 um 02:50 schrieb Roberto Cortez :
> 
> Hi,
> Sorry for bringing this up again. I would like to know what are the plans to 
> move OpenJPA to be JPA 2.1 compliant, if any?
> I don't expect it to fall on my lap and I'm happy to contribute to the 
> efforts. I've started some work on it, and even got some feedback at start, 
> but at the moment seems halted.
> Here is some of my work to support standard JPA 2.1 Schema 
> generation:https://issues.apache.org/jira/browse/OPENJPA-2554
> 
> Is there any interest in making this part of the project?
> Thank you.
> Cheers,Roberto

Re: Open JPA Entity Loading issue due to failure in Enhancing at run time.

[Mark Struberg]

Did you enlist the classes in persistence.xml?
Please try to enlist all of them as  items and also please add
true
to your persistence.xml.
Worth a try. Without a sample project we can just try to narrow down the 
problematic zone.


Reason I'm asking is that the 'auto-pickup' is per JPA spec only working for 
the 'persistence root' of a project. Means the very same JAR where 
persistence.xml and all the entities are located in. For example if you have 
some of the entities in another jar then the entity auto-detection is not 
portably guaranteed to work anymore.


And I have not much clue how that is supposed to work in OSGi environments like 
Apache Camel (JBoss Fuse is more or less just a pre-packaged distribution of 
Apache Camel afaik). 

Fortunately we have a few Camel folks around here, maybe this sounds familiar 
to one of them?

txs and LieGrue,
strub




> On Monday, 16 May 2016, 9:11, Senthil Kumar Sekar 
>  wrote:
> > 
> Hi Strub,
>   We have multiple bundles deployed in which dao is  a 
> separate 
> bundle and the entities are not duplicated.
> 
> xx-ds --> dao bundle
> xx depends on xx-ds
> 
> Thanks.
> 
> Regards
> Senthil Kumar Sekar
> 
> 
> From: Loganathan, Senthil 
> Sent: Thursday, May 12, 2016 12:13 PM
> To: Mark Struberg; users@openjpa.apache.org; Senthil Kumar Sekar
> Cc: openjpa-dev
> Subject: RE: Open JPA Entity Loading issue due to failure in Enhancing at run 
> time.
> 
> Hi Strub,
> 
> We have the entities listed in one bundle and is part of single jar file.
> Thanks.
> 
> -Original Message-
> From: Mark Struberg [mailto:strub...@yahoo.de]
> Sent: Thursday, May 12, 2016 2:23 PM
> To: users@openjpa.apache.org
> Cc: openjpa-dev; Loganathan, Senthil
> Subject: Re: Open JPA Entity Loading issue due to failure in Enhancing at run 
> time.
> 
> Do you have the same entities in multiple EARs or WARs on the same server?
> I got similar sounding issues on servers which did not properly isolate the 
> JPA 
> Metadata caches between different apps.
> Trying to understand your exact scenario is imo the first step.
> 
> LieGrue,
> strub
> 
> 
>>  Am 12.05.2016 um 05:09 schrieb Senthil Kumar Sekar 
> :
>> 
>> 
>> 
>>  Hello Team,
>>We have been using openjpa - 2.4.0 for our application data 
> access layer which will be deployed in Jboss Fuse 6.2.1.
>>  We have persistence xml where all the entities are declared.
>> 
>>  Very Frequently that we are facing the below issue and had to restart the 
> container multiple to get the issue resolved.
>> 
>>  java.lang.reflect.UndeclaredThrowableException
>> at com.sun.proxy.$Proxy29.createQuery(Unknown Source)
>> at 
> com.mysema.query.jpa.impl.AbstractJPAQuery.createQuery(AbstractJPAQuery.java:127)[744:com.mysema.querydsl.jpa:3.6.3]
>>
>>  Caused by: java.lang.reflect.UndeclaredThrowableException
>> at com.sun.proxy.$Proxy103.createQuery(Unknown Source)
>> ... 67 more
>>  Caused by: java.lang.reflect.InvocationTargetException
>> at sun.reflect.GeneratedMethodAccessor112.invoke(Unknown Source)
>> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_79]
>> at java.lang.reflect.Method.invoke(Method.java:606)[:1.7.0_79]
>> at 
> org.apache.aries.jpa.container.impl.EntityManagerProxyFactory$EMHandler.invoke(EntityManagerProxyFactory.java:31)
>> ... 68 more
>>  Caused by: 
>>  org.apache.openjpa.persistence.ArgumentException: An error occurred
>>  while parsing the query filter "select cETAssignmentException_ from 
> CETAssignmentException cETAssignmentException_ where 
> lower(cETAssignmentException_.id.officeCode) = ?1 and 
> lower(cETAssignmentException_.id.businessSegmentCode) = ?2". Error message: 
> The name "CETAssignmentException" is not a recognized entity or 
> identifier. Perhaps you meant CDDCaseLocation, which is a close match. Known 
> entity names: [IndividualReferencesAsu, RmaExcllist, 
> WbSanctionsQuestionnaire, 
> IndividualAsu, SpeDocumentsChecklist, Property, MvSciClientGrpInfo, 
> CddAdditionalDetails, CopiFatcaSubownersInfo, DocumentTemplate, 
> ClientBranchOffices, RoccoDecisionReportPK, CddCaseActorsPK, DdCase, 
> ClientIndividualReln, EcddSciCasePublish, ForeignExchange, CaseDetail, 
> CopiFatcaTaxInfo, NorkomTxn, CopiFatcaDocument, ClientGroup, 
> ClientIndividual, 
> OpaScreen, Country, MvSciClientInfo, IndividualNorkom, CddRisks, 
> IndividualNorkomAsu, ClientOfficeProducts, CddCaseAuditPK, AtfF

Re: Open JPA Entity Loading issue due to failure in Enhancing at run time.

[Mark Struberg]

Do you have the same entities in multiple EARs or WARs on the same server?
I got similar sounding issues on servers which did not properly isolate the JPA 
Metadata caches between different apps.
Trying to understand your exact scenario is imo the first step.

LieGrue,
strub


> Am 12.05.2016 um 05:09 schrieb Senthil Kumar Sekar 
> :
> 
> 
> 
> Hello Team,
>   We have been using openjpa – 2.4.0 for our application data 
> access layer which will be deployed in Jboss Fuse 6.2.1.
> We have persistence xml where all the entities are declared.
> 
> Very Frequently that we are facing the below issue and had to restart the 
> container multiple to get the issue resolved.
> 
> java.lang.reflect.UndeclaredThrowableException
>at com.sun.proxy.$Proxy29.createQuery(Unknown Source)
>at 
> com.mysema.query.jpa.impl.AbstractJPAQuery.createQuery(AbstractJPAQuery.java:127)[744:com.mysema.querydsl.jpa:3.6.3]
>   ….
> Caused by: java.lang.reflect.UndeclaredThrowableException
>at com.sun.proxy.$Proxy103.createQuery(Unknown Source)
>... 67 more
> Caused by: java.lang.reflect.InvocationTargetException
>at sun.reflect.GeneratedMethodAccessor112.invoke(Unknown Source)
>at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_79]
>at java.lang.reflect.Method.invoke(Method.java:606)[:1.7.0_79]
>at 
> org.apache.aries.jpa.container.impl.EntityManagerProxyFactory$EMHandler.invoke(EntityManagerProxyFactory.java:31)
>... 68 more
> Caused by:  
> org.apache.openjpa.persistence.ArgumentException: An error occurred while 
> parsing the query filter "select cETAssignmentException_
> from CETAssignmentException cETAssignmentException_
> where lower(cETAssignmentException_.id.officeCode) = ?1 and 
> lower(cETAssignmentException_.id.businessSegmentCode) = ?2". Error message: 
> The name "CETAssignmentException" is not a recognized entity or identifier. 
> Perhaps you meant CDDCaseLocation, which is a close match. Known entity 
> names: [IndividualReferencesAsu, RmaExcllist, WbSanctionsQuestionnaire, 
> IndividualAsu, SpeDocumentsChecklist, Property, MvSciClientGrpInfo, 
> CddAdditionalDetails, CopiFatcaSubownersInfo, DocumentTemplate, 
> ClientBranchOffices, RoccoDecisionReportPK, CddCaseActorsPK, DdCase, 
> ClientIndividualReln, EcddSciCasePublish, ForeignExchange, CaseDetail, 
> CopiFatcaTaxInfo, NorkomTxn, CopiFatcaDocument, ClientGroup, 
> ClientIndividual, OpaScreen, Country, MvSciClientInfo, IndividualNorkom, 
> CddRisks, IndividualNorkomAsu, ClientOfficeProducts, CddCaseAuditPK, 
> AtfFieldsMaster, CddDdrBasedRouting, PreScreening, CddCasePK, 
> MvSciClientOrgInfo, WorkflowState, RoccoRequest, RoccoRequestAuditPK, Risks, 
> MvSciClientAddrInfo, GaProductTransaction, ClientDocuments, Bba, 
> ClientBranch, ClientNorkomPK, ClientISIC, MvSciArmCodeInfo, DDCCountries, 
> Client, GroupNorkom, IndividualClientReln, Ga, OPARuleBases, 
> CDDWorkflowState, SubReasonCodes, MoneyMarket, OpaError, DefenceGoodsStatus, 
> CDDStateMachine, LegalConstitution, ReasonCodes, RoccoRequestAudit, Address, 
> BranchNorkom, FiDocumentsChecklist, CopiFatcaStatusInfo, CddCase, Cdd, 
> CddPepSummary, Bonds, BbaDocumentsChecklist, ClientOffice, CDDCaseLocation, 
> MvSciEmpInfo, GaDocumentChecklist, TaskBasedReasonCodes, BranchAddress, 
> DgStatusDecisionMatrix, CashEquities, IndividualReferences, EcddSciPublish, 
> CddCaseAudit, BusinessSubSegment, OPACases, ClientIndividualRelnPK, 
> IndividualReferencesAsuPK, Product, ClientNorkom, BusinessSegment, 
> DocumentCategory, CoDocumentsChecklist, CddCaseAuditSubReasons, 
> IndividualClientRelnAsu, TaskBasedReasonCodesPK, CustomerCountryRisk, 
> PreScreeningComment, BbaRiskQuestion, IndividualDocuments, FormButton, 
> Documents, BbaAdditionalDetails, ClientType, GuarantorNorkomPK, 
> AnticipatedTransaction, CddPepDetail, GoodsType, CddCaseActors, 
> GuarantorNorkom, CddCountryRisk, CountryOffices, CopiFatca, 
> CddWorkflowReassignment, Norkom, Deferral, DocumentsUpload, 
> ClientTriggerEvents, CopiFatcaStatus, Gic, BusinessSubSegmentPK, 
> ParentGroupDetails, MvSciClientCoreInfo, RequestMap, CddRiskQuestions, 
> DefenceGoods, OPADecisionReport, AtfRequestTxn, Individual, ReviewCases, 
> MvSciArmLocation, DefenceGoodsDecision, ClientIndividualPK, 
> RoccoDecisionReport, IndividualPK, CddTaskAction, PreScreeningRef, 
> ClientGuarantor, Derivative]
>at 
> org.apache.openjpa.kernel.exps.AbstractExpressionBuilder.parseException(AbstractExpressionBuilder.java:118)[848:org.apache.openjpa:2.4.0]
>at 
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JPQLExpressionBuilder.java:193)[848:org.apache.openjpa:2.4.0]
>at 
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaData(JPQLExpressionBuilder.java:166)[848:org.apache.openjpa:2.4.0]
> 
> Looks like the entity CETAssignmentException is not in the open-jpa list 
> which is us

[ANNOUNCE] Welcome Francesco Chicchiriccò as Apache OpenJPA committer

[Mark Struberg]

Good morning!

The Apache OpenJPA PMC is happy to announce that Francesco Chicchiriccò will 
join the project as a new committer!

Welcome to OpenJPA, Francesco!


the OpenJPA PMC

Re: UUID generators worth the effort?

[Mark Struberg]

For the application it's a String. JPA doesn't need to know whether this String 
represents a uuid or a random number you did yourself. It just needs to be 
unique!

LieGrue,
strub






> On Tuesday, 12 April 2016, 17:08, Francesco Chicchiriccò 
>  wrote:
> > On 12/04/2016 16:11, Mark Struberg wrote:
>>>  you are not interested in making the approach below more general -
>>  'not interested' is not the right word. Not on my personal list of 
> important things for me personal - but happy to get patches!
> 
> Sure :-)
> But then I need some hint in finding how to recognize when the mapped 
> field is java.util.UUID (rather than String).
> 
>>>  4. I have opened OPENJPA2640 and provided a patch
>>  Thanks a lot, trying to get around it the next days. Feel free to poke me 
> for it ;)
> 
> Perfect, thanks.
> Regards.
> 
> 
>>>  On Tuesday, 12 April 2016, 15:51, Francesco Chicchiriccò 
>  wrote:
>>>>  Hi Mark,
>>>  with reference to my 4 questions below:
>>> 
>>>  1. I have experimented that, even though UUIDType4HexSeq provides a
>>>  static getInstance() method, it is not called with my use case, so I am
>>>  fine with my UUIDGenerator's constructor being invoked twice (e.g. 
> one
>>>  time for each entity)
>>> 
>>>  2. I have been able to translate the sequence generator definition to
>>>  orm.xml
>>> 
>>>  3. I understand that since "some DBs are not really working with 
> it",
>>>  you are not interested in making the approach below more general -
>>>  that's fine, we are going to use it anyway, for the DBs we support
>>> 
>>>  4. I have opened OPENJPA2640 and provided a patch, please take a look -
>>>  incidentally, I have noticed that 2.4.1 appears as unreleased in JIRA
>>> 
>>>  Regards.
>>> 
>>> 
>>>  On 12/04/2016 09:22, Mark Struberg wrote:
>>>>Hi Francesco!
>>>> 
>>>>I usually let the PK be a String and create the UUID myself in 
> Java.
>>>> 
>>>>The 'uuid' generator is a nice feature but it's not 
> portable.
>>>> 
>>>>And that might be the reason why some DBs are not really working 
> with it -
>>>  it's simply not that frequently used.
>>>> 
>>>>There are 3 ways to create the UUID.
>>>> 
>>>>a.) In the default ct. That might trigger a tad too often and 
> might slow
>>>  down selects, etc.
>>>>b.) Lazily in getId(). If null -> create a new UUID
>>>>c.) Via an own ct which takes the UUID pk. You basically create 
> the ID in
>>>  your business layer.
>>>>I mostly use c) if I need a UUID pk.
>>>> 
>>>>LieGrue,
>>>>strub
>>>> 
>>>> 
>>>> 
>>>> 
>>>>>On Monday, 11 April 2016, 9:02, Francesco Chicchiriccò
>>>   wrote:
>>>>>>Hi all,
>>>>>I went further and built a sample POC [10] which mimics the 
> essentials
>>>>>from Syncope.
>>>>> 
>>>>>I have defined an UUIDGenerator implementing Seq (and relying 
> on [3]
>>>  for
>>>>>UUID generation), and declared it via
>>>>> 
>>>>>@SequenceGenerator(name = "uuid", sequenceName =
>>>>>   
> "net.tirasa.ilgrosso.uuidpoc.openjpa.UUIDGenerator()")
>>>>> 
>>>>>in the @MappedSuperclass of both JPA entities available, plus 
> defined
>>>>> 
>>>>>  @Id
>>>>>  @GeneratedValue(strategy = GenerationType.SEQUENCE, 
> generator =
>>>>>"uuid")
>>>>>  private UUID id;
>>>>> 
>>>>>in both entities.
>>>>> 
>>>>>I have also extended the H2Dictionary to support the native 
> UUID type
>>>>>(without such extension, the id column would have had type 
> BLOB).
>>>>> 
>>>>>All this above seems to work - at least for the simple JUnit 
> test case
>>>>>provided; I have some questions, though:
>>>>> 
>>>>>1. I have experimented that UUIDGenerator is instantiated 
> twice: would
>>>>>it be possible to defined it as singleton - as it happens for
>>>  OpenJPA's
>>>>>UUIDType4HexSeq?
>&g

Re: UUID generators worth the effort?

[Mark Struberg]

> you are not interested in making the approach below more general - 

'not interested' is not the right word. Not on my personal list of important 
things for me personal - but happy to get patches!

> 4. I have opened OPENJPA2640 and provided a patch
Thanks a lot, trying to get around it the next days. Feel free to poke me for 
it ;)

txs and LieGrue,
strub




> On Tuesday, 12 April 2016, 15:51, Francesco Chicchiriccò 
>  wrote:
> > Hi Mark,
> with reference to my 4 questions below:
> 
> 1. I have experimented that, even though UUIDType4HexSeq provides a 
> static getInstance() method, it is not called with my use case, so I am 
> fine with my UUIDGenerator's constructor being invoked twice (e.g. one 
> time for each entity)
> 
> 2. I have been able to translate the sequence generator definition to 
> orm.xml
> 
> 3. I understand that since "some DBs are not really working with it", 
> you are not interested in making the approach below more general - 
> that's fine, we are going to use it anyway, for the DBs we support
> 
> 4. I have opened OPENJPA2640 and provided a patch, please take a look - 
> incidentally, I have noticed that 2.4.1 appears as unreleased in JIRA
> 
> Regards.
> 
> 
> On 12/04/2016 09:22, Mark Struberg wrote:
>>  Hi Francesco!
>> 
>>  I usually let the PK be a String and create the UUID myself in Java.
>> 
>>  The 'uuid' generator is a nice feature but it's not portable.
>> 
>>  And that might be the reason why some DBs are not really working with it - 
> it's simply not that frequently used.
>> 
>> 
>>  There are 3 ways to create the UUID.
>> 
>>  a.) In the default ct. That might trigger a tad too often and might slow 
> down selects, etc.
>>  b.) Lazily in getId(). If null -> create a new UUID
>>  c.) Via an own ct which takes the UUID pk. You basically create the ID in 
> your business layer.
>> 
>>  I mostly use c) if I need a UUID pk.
>> 
>>  LieGrue,
>>  strub
>> 
>> 
>> 
>> 
>>>  On Monday, 11 April 2016, 9:02, Francesco Chicchiriccò 
>  wrote:
>>>>  Hi all,
>>>  I went further and built a sample POC [10] which mimics the essentials
>>>  from Syncope.
>>> 
>>>  I have defined an UUIDGenerator implementing Seq (and relying on [3] 
> for
>>>  UUID generation), and declared it via
>>> 
>>>  @SequenceGenerator(name = "uuid", sequenceName =
>>>  "net.tirasa.ilgrosso.uuidpoc.openjpa.UUIDGenerator()")
>>> 
>>>  in the @MappedSuperclass of both JPA entities available, plus defined
>>> 
>>>@Id
>>>@GeneratedValue(strategy = GenerationType.SEQUENCE, generator =
>>>  "uuid")
>>>private UUID id;
>>> 
>>>  in both entities.
>>> 
>>>  I have also extended the H2Dictionary to support the native UUID type
>>>  (without such extension, the id column would have had type BLOB).
>>> 
>>>  All this above seems to work - at least for the simple JUnit test case
>>>  provided; I have some questions, though:
>>> 
>>>  1. I have experimented that UUIDGenerator is instantiated twice: would
>>>  it be possible to defined it as singleton - as it happens for 
> OpenJPA's
>>>  UUIDType4HexSeq?
>>> 
>>>  2. How would the @SequenceGenerator annotation translates to orm.xml?
>>>  I've attempted the bare translation but it did not work.
>>> 
>>>  3. The extended logic I have put in my H2Dictionary looks quite poor 
> for
>>>  the general case - even though good enough for my specific use case:
>>> 
>>>@Override
>>>public String getTypeName(final Column col) {
>>>return col.getType() == Types.BLOB && 
> (col.isPrimaryKey() ||
>>>  col.isForeignKey())
>>>? "UUID"
>>>: super.getTypeName(col);
>>>}
>>> 
>>>  How much difficult would be to make it proper, e.g. recognize when the
>>>  class field is java.util.UUID? I'll need such extension for MySQL,
>>>  MariaDB, PostgreSQL, MS SQL Server and Oracle dictionaries.
>>> 
>>>  4. I am used to rely on openjpa-maven-plugin to generate the
>>>  database.sql file; how can I configure it to use my H2Dictionary, and
>>>  not the default?
>>> 
>>>  Thanks for your support.
>>>  Regards.
>>> 
>>>  On 04/04/2016 10:49, Francesco

Re: UUID generators worth the effort?

[Mark Struberg]

Hi Francesco!

I usually let the PK be a String and create the UUID myself in Java. 

The 'uuid' generator is a nice feature but it's not portable. 

And that might be the reason why some DBs are not really working with it - it's 
simply not that frequently used.


There are 3 ways to create the UUID. 

a.) In the default ct. That might trigger a tad too often and might slow down 
selects, etc.
b.) Lazily in getId(). If null -> create a new UUID
c.) Via an own ct which takes the UUID pk. You basically create the ID in your 
business layer.

I mostly use c) if I need a UUID pk.

LieGrue,
strub




> On Monday, 11 April 2016, 9:02, Francesco Chicchiriccò  
> wrote:
> > Hi all,
> I went further and built a sample POC [10] which mimics the essentials 
> from Syncope.
> 
> I have defined an UUIDGenerator implementing Seq (and relying on [3] for 
> UUID generation), and declared it via
> 
> @SequenceGenerator(name = "uuid", sequenceName = 
> "net.tirasa.ilgrosso.uuidpoc.openjpa.UUIDGenerator()")
> 
> in the @MappedSuperclass of both JPA entities available, plus defined
> 
>  @Id
>  @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = 
> "uuid")
>  private UUID id;
> 
> in both entities.
> 
> I have also extended the H2Dictionary to support the native UUID type 
> (without such extension, the id column would have had type BLOB).
> 
> All this above seems to work - at least for the simple JUnit test case 
> provided; I have some questions, though:
> 
> 1. I have experimented that UUIDGenerator is instantiated twice: would 
> it be possible to defined it as singleton - as it happens for OpenJPA's 
> UUIDType4HexSeq?
> 
> 2. How would the @SequenceGenerator annotation translates to orm.xml? 
> I've attempted the bare translation but it did not work.
> 
> 3. The extended logic I have put in my H2Dictionary looks quite poor for 
> the general case - even though good enough for my specific use case:
> 
>  @Override
>  public String getTypeName(final Column col) {
>  return col.getType() == Types.BLOB && (col.isPrimaryKey() || 
> col.isForeignKey())
>  ? "UUID"
>  : super.getTypeName(col);
>  }
> 
> How much difficult would be to make it proper, e.g. recognize when the 
> class field is java.util.UUID? I'll need such extension for MySQL, 
> MariaDB, PostgreSQL, MS SQL Server and Oracle dictionaries.
> 
> 4. I am used to rely on openjpa-maven-plugin to generate the 
> database.sql file; how can I configure it to use my H2Dictionary, and 
> not the default?
> 
> Thanks for your support.
> Regards.
> 
> On 04/04/2016 10:49, Francesco Chicchiriccò wrote:
>>  Hi all,
>>  in Syncope we are currently discussing [1] the option to replace our 
>>  table generators-based id strategy to something else, based on UUID, 
>>  which seem to offer several advantages.
>> 
>>  I have found [2], but I would rather prefer to generated UUID values 
>>  manually (via [3] which seems to offer better performance and more 
>>  features than the standard JDK's).
>> 
>>  In order to do so, I would replace the current
>> 
>>  @Id
>>  private Long id;
>> 
>>  public Long getKey() {
>>  return id;
>>  }
>> 
>>  in  [4], backed by [5], with something like as
>> 
>>  @Id
>>  private UUID id;
>> 
>>  public UUID getKey() {
>>synchronized(this) {
>>  if (key == null) {
>>key = ... // generate via JUG [3]
>>  }
>>}
>>return key;
>>  }
>> 
>>  As Syncope supports several DBMSes, I would also like to empower the 
>>  underlying capabilities for storing such values:
>> 
>>   * UUID Type for PostgreSQL [6]
>>   * UNIQUEIDENTIFIER for SQL Server [7]
>>   * RAW(16) for Oracle [8]
>>   * BINARY(16) with some optimizations for MySQL / MariaDB [9] or 
>>  vanilla with H2
>> 
>>  Do you have any suggestion about:
>> 
>>   (a) the way how I am planning to support UUID generation
>>   (b) the cleanest way to support DBMS differences (extending the 
>>  respective DB dictionaries?)
>> 
>>  TIA
>>  Regards.
>> 
>>  [1] http://markmail.org/message/fhdrwerdwdm3opdx
>>  [2] 
>> 
> http://openjpa.apache.org/builds/2.4.1/apache-openjpa/docs/jpa_overview_meta_field.html#jpa_overview_meta_gen
>>  [3] https://github.com/cowtowncoder/java-uuid-generator
>>  [4] 
>> 
> https://github.com/apache/syncope/blob/master/core/persistence-jpa/src/main/java/org/apache/syncope/core/persistence/jpa/entity/user/JPAUser.java
>>  [5] 
>> 
> https://github.com/apache/syncope/blob/master/core/persistence-jpa/src/main/resources/META-INF/spring-orm.xml#L87-L94
>>  [6] http://www.postgresql.org/docs/9.3/static/datatype-uuid.html
>>  [7] 
>>  http://wiki.ispirer.com/sqlways/sql-server/data-types/uniqueidentifier
>>  [8] 
>> 
> http://docs.oracle.com/cd/B28359_01/server.111/b28286/functions175.htm#SQLRF51816
>>  [9] https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/
> [10] https://github.com/ilgrosso/OpenJPAUUIDPOC
> 
> 
> -- 
> Francesco Chicchiriccò
> 
> Tir

Re: Wrong order for delete of child when deleting parent

[Mark Struberg]

You might also do a normal em.remove() in the right order manually. Most 
probably no need to use a native query.

LieGrue,
strub






> On Monday, 4 April 2016, 19:44, tvogel  wrote:
> > I don't have a solution but a workaround.  In my service layer, I wrote
> native sql queries to handle the delete manually.
> Tim
> 
> 
> 
> --
> View this message in context: 
> http://openjpa.208410.n2.nabble.com/Wrong-order-for-delete-of-child-when-deleting-parent-tp7589053p7589070.html
> 
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> 

Re: Wrong order for delete of child when deleting parent

[Mark Struberg]

Actually I'm not sure and to be honest I don't think it's solved. 

But it's much easier if we have a sample for 2.4.1 than for an old version.
I'd like to work on this in the mainstream version. 

If the fix is easy then we might think about backporting if necessary.
If we get a sample then it might get fixed with the next mainstream release 
(2.4.2)

LieGrue,
strub





> On Monday, 4 April 2016, 9:40, Datin Benoit 
>  wrote:
> > Hi all,
> 
> Do you mean this bug is resolved in 2.4.1 ?
> In 2014, I have been faced with a similar problem as the one described below 
> and 
> the OPENJPA-1936
> 
> https://issues.apache.org/jira/browse/OPENJPA-1936
> 
> 
> 
> -Original Message-
> From: Mark Struberg [mailto:strub...@yahoo.de.INVALID] 
> Sent: dimanche 3 avril 2016 12:56
> To: users@openjpa.apache.org
> Subject: Re: Wrong order for delete of child when deleting parent
> 
> Can you please try upgrading to 2.4.1?
> If you get the same issue in the newest version then it's much easier for us 
> to reproduce.
> 
> 
> It would also help if you could provide a sample project which at least 
> contains 
> the entity constellation in question. It's much easier to discuss about such 
> things in code than in mail ;)
> 
> txs and LieGrue,
> strub
> 
> 
>>  Am 30.03.2016 um 19:33 schrieb tvogel :
>> 
>>  The order of deletes for OpenJPA 2.3.x are happening in the wrong 
>>  order and I can't figure out why.
>> 
>>  Given these JPA mappings
>> 
>> // grandparent
>> @Entity
>> @Table(name = "three_phase_motor_input")
>> public class ThreePhaseMotorInput implements IThreePhaseMotorInput, 
>>  Serializable {
>> @Id
>> @GeneratedValue(strategy = GenerationType.IDENTITY)
>> private Long id;
>> @Version
>> private Integer version;
>> 
>> @OneToOne(orphanRemoval = true, cascade = CascadeType.ALL, 
>>  optional = true, targetEntity = UnapprovedThreePhaseMotor.class)
>> @JoinColumn(name = "unapproved_id")
>> private IThreePhaseMotor unapprovedMotor;
>> 
>> // parent
>> @Entity
>> @Table(name = "unapproved_three_phase_motor")
>> public class UnapprovedThreePhaseMotor extends ThreePhaseMotor {
>> @OneToMany(orphanRemoval = true, cascade = CascadeType.ALL, 
>>  fetch = FetchType.LAZY, targetEntity = UnapprovedThreePhaseWire.class)
>> @JoinColumn(name = "motor_id", referencedColumnName = 
> "id", 
>>  nullable =
>>  false)
>> @OrderColumn(name = "idx")
>> private List wires;
>> 
>> 
>> // child - Abstract
>> @MappedSuperclass
>> @Access(AccessType.FIELD)
>> public abstract class ThreePhaseWire implements IThreePhaseWire, 
>>  Serializable {
>> @Id
>> @GeneratedValue(strategy = GenerationType.IDENTITY)
>> private Long id;
>> 
>> // child concrete
>> @Entity
>> @Table(name = "unapproved_three_phase_wire")
>> public class UnapprovedThreePhaseWire extends ThreePhaseWire {
>> 
>> 
>>  Order of SQL statements in log file when setting unapprovedMotor in 
>>  grandparent to null
>> 
>>  572353115 UPDATE three_phase_motor_input SET status = ?, version = 
>>  ?, approved_id = ?, unapproved_id = ? WHERE id = ? AND version = ?
>>  [params=(int) 1, (int) 8, (null) null, (null) null, (long) 896, (int) 7]
>>  1683522521 DELETE FROM unapproved_three_phase_motor WHERE id = ? 
>>  AND version = ? [params=(long) 209938, (int) 1]
>>  446470297 DELETE FROM unapproved_three_phase_wire WHERE id = ?
>>  [params=(long) 1394]
>> 
>>  This causes a foreign key constraint error since the child still 
>>  exists when the parent delete statement is executed.
>> 
>> 
>> 
>> 
>>  --
>>  View this message in context: 
>>  http://openjpa.208410.n2.nabble.com/Wrong-order-for-delete-of-child-wh
>>  en-deleting-parent-tp7589053.html Sent from the OpenJPA Users mailing 
>>  list archive at Nabble.com.
> 

Re: Wrong order for delete of child when deleting parent

[Mark Struberg]

Can you please try upgrading to 2.4.1?
If you get the same issue in the newest version then it's much easier for us to 
reproduce.


It would also help if you could provide a sample project which at least 
contains the entity constellation in question. It's much easier to discuss 
about such things in code than in mail ;)

txs and LieGrue,
strub


> Am 30.03.2016 um 19:33 schrieb tvogel :
> 
> The order of deletes for OpenJPA 2.3.x are happening in the wrong order and I
> can't figure out why.
> 
> Given these JPA mappings
> 
>// grandparent
>@Entity
>@Table(name = "three_phase_motor_input")
>public class ThreePhaseMotorInput implements IThreePhaseMotorInput,
> Serializable {
>@Id
>@GeneratedValue(strategy = GenerationType.IDENTITY)
>private Long id;
>@Version
>private Integer version;
> 
>@OneToOne(orphanRemoval = true, cascade = CascadeType.ALL, optional =
> true, targetEntity = UnapprovedThreePhaseMotor.class)
>@JoinColumn(name = "unapproved_id")
>private IThreePhaseMotor unapprovedMotor;
> 
>// parent
>@Entity
>@Table(name = "unapproved_three_phase_motor")
>public class UnapprovedThreePhaseMotor extends ThreePhaseMotor {
>@OneToMany(orphanRemoval = true, cascade = CascadeType.ALL, fetch =
> FetchType.LAZY, targetEntity = UnapprovedThreePhaseWire.class)
>@JoinColumn(name = "motor_id", referencedColumnName = "id", nullable =
> false)
>@OrderColumn(name = "idx")
>private List wires;
> 
> 
>// child - Abstract
>@MappedSuperclass
>@Access(AccessType.FIELD)
>public abstract class ThreePhaseWire implements IThreePhaseWire,
> Serializable {
>@Id
>@GeneratedValue(strategy = GenerationType.IDENTITY)
>private Long id;
> 
>// child concrete
>@Entity
>@Table(name = "unapproved_three_phase_wire")
>public class UnapprovedThreePhaseWire extends ThreePhaseWire {
> 
> 
> Order of SQL statements in log file when setting unapprovedMotor in
> grandparent to null
> 
> 572353115 UPDATE three_phase_motor_input SET status = ?, version = ?,
> approved_id = ?, unapproved_id = ? WHERE id = ? AND version = ?
> [params=(int) 1, (int) 8, (null) null, (null) null, (long) 896, (int) 7]
> 1683522521 DELETE FROM unapproved_three_phase_motor WHERE id = ? AND
> version = ? [params=(long) 209938, (int) 1]
> 446470297 DELETE FROM unapproved_three_phase_wire WHERE id = ?
> [params=(long) 1394]
> 
> This causes a foreign key constraint error since the child still exists when
> the parent delete statement is executed.
>
> 
> 
> 
> --
> View this message in context: 
> http://openjpa.208410.n2.nabble.com/Wrong-order-for-delete-of-child-when-deleting-parent-tp7589053.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: @sqlresultsetmapping columns

[Mark Struberg]

How does your source code look like?
Maybe the problem is not in the orm.xml but in how you created your combined pk?

LieGrue,
strub


> Am 24.02.2016 um 22:43 schrieb ram :
> 
> Hi,i have an entity called order which contains 10 columns and also 
> has embeded id(composite key)  coulmns which contains 5 fields in entity 
> order.
> 
>  i was trying to build sql resultsetmapping in orm.xml
> 
> 
> 
>  result-set-mapping="OrderQueryResultSetMapping">  
>   entity-class="order">  
>   
>column="column_3" />  
>  
> 
> i don't have issues in query execution, but getting error in 
> sqlResultSetMapping.   i am getting the following error.
> 
> Exception in thread "main"  error> org.apache.openjpa.persistence.PersistenceException: 
> [jcc][t4][10145][10897][3.58.81] Invalid parameter 0: Parameter index is out 
> of range. ERRORCODE=-4461, SQLSTATE=42815
> 
> can we do this kind of mapping? if so, how do client knows what are the 
> columns are populated for Order entity as part of this query.
> 
> 

Fwd: [VOTE] Release OpenJPA-2.4.1

[Mark Struberg]

FYI, VOTE on OpenJPA-2.4.1 is ongoing. 

happy to get some feedback from users as well!

LieGrue,
strub

> Anfang der weitergeleiteten Nachricht:
> 
> Von: Mark Struberg 
> Betreff: [VOTE] Release OpenJPA-2.4.1
> Datum: 15. Februar 2016 um 09:17:25 MEZ
> An: openjpa-dev 
> Antwort an: d...@openjpa.apache.org
> 
> Good morning!
> 
> OpenJPA-2.4.1 is a maintenance release of the JPA-2.0 version of OpenJPA.
> 
> 
> 
> The staging repository is
> https://repository.apache.org/content/repositories/orgapacheopenjpa-1001/
> 
> The source and binary distributions can be found here:
> https://repository.apache.org/content/repositories/orgapacheopenjpa-1001/org/apache/openjpa/apache-openjpa/2.4.1/
> 
> The SVN tag is
> https://svn.apache.org/repos/asf/openjpa/tags/2.4.1/
> 
> 
> 
> My signature key can be found in 
> https://svn.apache.org/repos/asf/openjpa/KEYS
> 
> 
> The following bugs got fixed
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310351&version=12332295
> 
> Bug
> 
>   • [OPENJPA-2341] - OpenJPA ignores custom field strategies globally 
> defined in persistence.xml
>   • [OPENJPA-2517] - Incorrect the time unit of query timeout value.
>   • [OPENJPA-2539] - JPQL interpret wrongly for inner join table (without 
> mapped relation)
>   • [OPENJPA-2582] - openjpa bundle module leaks jest dependencies
>   • [OPENJPA-2586] - Incorrect relationship data returned when QueryCache 
> and FetchPlans are used.
>   • [OPENJPA-2596] - schema-delta generation (sqlAction=refresh) drops 
> columns if they have an alternative typeName
>   • [OPENJPA-2597] - HsqlDictionary considers NUMERIC/DECIMAL as a 
> fixedSizeTypeNameSet
>   • [OPENJPA-2600] - finally remove NullSafeConcurrentHashMap and 
> SizedConcurrentHashMap
>   • [OPENJPA-2601] - 'hint' element in orm:xml is ignored
>   • [OPENJPA-2603] - Merging an unmanaged entity multiple (3) times leads 
> to an exception.
>   • [OPENJPA-2605] - DelegatingConnection.unwrap() doesn't adhere to 
> java.sql.Wrapper.unwrap() contract
>   • [OPENJPA-2609] - Sporadic ClassCastException occurs under heavy load 
> when QuerySQLCache is enabled.
>   • [OPENJPA-2616] - Update Commons Collections to 3.2.2
>   • [OPENJPA-2617] - blacklist 
> org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan
>  in our custom ObjectInputStreams
>   • [OPENJPA-2626] - isEnhanced doesn't support java 8 bytecode
> Improvement
> 
>   • [OPENJPA-2602] - OracleDictionary uses reflection way too often
>   • [OPENJPA-2607] - Import range for javax.transaction is to small
>   • [OPENJPA-2623] - Switch to Java5 mojo annotations
>   • [OPENJPA-2627] - Create an option to disable column type checking 
> errors during schema validation.
> Test
> 
>   • [OPENJPA-2595] - upgrade test framework from junit-3 to junit 4
> 
> If there are other tickets resolved in 2.4.1 which are not yet set to 
> resolved then please set them to resolved in 2.4.1 in Jira and ping me. Gonna 
> update this list as needed.
> 
> 
> Please VOTE
> 
> [+1] Yea, let’s ship it
> [+0] Meh, don’t care
> [-1] Stop, there is a ${blocker issue}
> 
> 
> txs and LieGrue,
> strub
> 
> 
> 

Re: Project activity

[Mark Struberg]

Oh and yet another tip:

$> mvn clean install -Dsurefire.excludes.locking=**/*

as documented in openjpa-project/BUILDING.txt
This heavily reduced build time as it skips all the timeout tests where we need 
to sleep 2 minutes for each test which alone takes >30 mins overall.

LieGrue,
strub


> Am 16.01.2016 um 09:47 schrieb Mark Struberg :
> 
> Btw quick tip for creating patches. Please always create the patch directly 
> from the project root. Makes it a bit easier to apply.
> 
> txs and LieGrue,
> strub
> 
> 
>> Am 16.01.2016 um 09:43 schrieb Mark Struberg :
>> 
>> I hope to find a bit time next week to merge over all the stuff from trunk 
>> into the JPA-2.1 feature branch.
>> If anyone is interested to help then go on and shout out. I’ll try to apply 
>> as fast as I can ;)
>> 
>> LieGrue,
>> strub
>> 
>>> Am 15.01.2016 um 14:53 schrieb RadeMartinovic :
>>> 
>>> So, this looks more like management problem then problem with the devs not
>>> willing to push JPA 2.1 forward.
>>> 
>>> Would it help if you ask ASF to help you with the management part?
>>> 
>>> 
>>> 
>>> --
>>> View this message in context: 
>>> http://openjpa.208410.n2.nabble.com/Project-activity-tp7588789p7588816.html
>>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>> 
> 

Re: Project activity

[Mark Struberg]

Btw quick tip for creating patches. Please always create the patch directly 
from the project root. Makes it a bit easier to apply.

txs and LieGrue,
strub


> Am 16.01.2016 um 09:43 schrieb Mark Struberg :
> 
> I hope to find a bit time next week to merge over all the stuff from trunk 
> into the JPA-2.1 feature branch.
> If anyone is interested to help then go on and shout out. I’ll try to apply 
> as fast as I can ;)
> 
> LieGrue,
> strub
> 
>> Am 15.01.2016 um 14:53 schrieb RadeMartinovic :
>> 
>> So, this looks more like management problem then problem with the devs not
>> willing to push JPA 2.1 forward.
>> 
>> Would it help if you ask ASF to help you with the management part?
>> 
>> 
>> 
>> --
>> View this message in context: 
>> http://openjpa.208410.n2.nabble.com/Project-activity-tp7588789p7588816.html
>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> 

Re: Project activity

[Mark Struberg]

I hope to find a bit time next week to merge over all the stuff from trunk into 
the JPA-2.1 feature branch.
If anyone is interested to help then go on and shout out. I’ll try to apply as 
fast as I can ;)

LieGrue,
strub

> Am 15.01.2016 um 14:53 schrieb RadeMartinovic :
> 
> So, this looks more like management problem then problem with the devs not
> willing to push JPA 2.1 forward.
> 
> Would it help if you ask ASF to help you with the management part?
> 
> 
> 
> --
> View this message in context: 
> http://openjpa.208410.n2.nabble.com/Project-activity-tp7588789p7588816.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: Project activity

[Mark Struberg]

Romain started the JPA-2.1 work but we might need a bit more hands on that. 

I will also come back to openjpa in a few weeks (need to finish some other 
projects) and can put some time into it again.

LieGrue,
strub


> Am 13.01.2016 um 14:43 schrieb RadeMartinovic :
> 
> I fear that project has slowed down considerably.
> 
> I remember back in 2014 and 2015 that there were pleads from project members
> for more community involvement. In days when they were racing toward JPA 2.0
> OpenJPA was the second implementation in the world to support all the
> features fully - and mostly because most of those were already there in
> OpenJPA or were easy to implement. 
> 
> It just seems that there is waning interest in OpenJPA.
> 
> 
> 
> --
> View this message in context: 
> http://openjpa.208410.n2.nabble.com/Project-activity-tp7588789p7588807.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: Is OpenJPA 2.4.0 is released or not

[Mark Struberg]

Should be resolved now. Can you please try it out?

txs and LieGrue,
strub

> Am 13.10.2015 um 09:26 schrieb Mark Struberg :
> 
> And thanks for all the reporting you do - that is equally important as well!
> 
> Will try to fix the other links as well and ping back in the evening.
> 
> txs and LieGrue,
> strub
> 
>> Am 13.10.2015 um 07:32 schrieb Boblitz John :
>> 
>> Hello,
>> 
>> The download page now contains the links.
>> 
>> I was able to download the binary.
>> 
>> The Source downloads did not work.
>> 
>> HTTP link responds with NOT FOUND - url mirror/. not found on server
>> FTP link responds with Failed to open file
>> 
>> I can not reach all of the HTTP sites due to a local firewall - but it seems 
>> that the source download page is bugged.
>> 
>> 
>> Thanks for the hard work you are doing!
>> 
>> John
>> 
>>> -Original Message-
>>> From: Mark Struberg [mailto:strub...@yahoo.de]
>>> Sent: Montag, 12. Oktober 2015 22:42
>>> To: users@openjpa.apache.org
>>> Subject: Re: Is OpenJPA 2.4.0 is released or not
>>> 
>>> fixed as well now. Can you please verify?
>>> 
>>> txs and LieGrue,
>>> strub
>>> 
>>>> Am 12.10.2015 um 14:23 schrieb Henno Vermeulen
>>> :
>>>> 
>>>> You're right, I don't see 2.4.0 listed on this page either:
>>>> http://openjpa.apache.org/downloads.html
>>>> 
>>>> Henno
>>>> 
>>>> -Oorspronkelijk bericht-
>>>> Van: Maxim Solodovnik [mailto:solomax...@gmail.com]
>>>> Verzonden: maandag 12 oktober 2015 14:00
>>>> Aan: users@openjpa.apache.org
>>>> Onderwerp: Re: Is OpenJPA 2.4.0 is released or not
>>>> 
>>>> same for us,
>>>> 
>>>> openjpa 2.4.0 available on maven central
>>>> 
>>>> On Mon, Oct 12, 2015 at 5:58 PM, Boblitz John
>>>> 
>>>> wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> Maybe I'm just blind, but I do not see a link for 2.4.0 on the
>>>>> download page (http://openjpa.apache.org/downloads.html).
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> John
>>>>> 
>>>>>> -Original Message-
>>>>>> From: Mark Struberg [mailto:strub...@yahoo.de]
>>>>>> Sent: Mittwoch, 30. September 2015 20:41
>>>>>> To: users@openjpa.apache.org
>>>>>> Subject: Re: Is OpenJPA 2.4.0 is released or not
>>>>>> 
>>>>>> Hi Henno,
>>>>>> big thanks for doing the tests and also for giving us the feedback!
>>>>>> We also use 2.4.0 in production already without any issues - well,
>>>>>> at
>>>>> least
>>>>>> without any regressions ;)
>>>>>> 
>>>>>> LieGrue,
>>>>>> strub
>>>>>> 
>>>>>> 
>>>>>>> Am 21.09.2015 um 09:44 schrieb Henno Vermeulen
>>>>>> :
>>>>>>> 
>>>>>>> The documentation does list 2.4.0 as a release so I think they just
>>>>> forgot to
>>>>>> update the downloads page!
>>>>>>> I'm no OpenJPA committer, perhaps they can give the "official"
>>>>>>> answer,
>>>>> but
>>>>>> here's our practical answer:
>>>>>>> 
>>>>>>> We are using OpenJPA for a few years now. I can confirm from our
>>>>>> experience that the enhancer for OpenJPA 2.3.0 is not able to
>>>>>> enhance classes that are compiled with Java 8. It should be possible
>>>>>> to compile
>>>>> with
>>>>>> Java 7 and use a Java 8 runtime, but we haven't tried this.
>>>>>>> 
>>>>>>> We have been using 2.4.0 with Java 7 in production (around 20
>>>>>>> users)
>>>>> for
>>>>>> quite a few months. We have very thorough tests that use OpenJPA and
>>>>>> the actual database. All of them were passing on 2.3.0 and Java 7
>>>>>> and are now passing on 2.4.0 with either Java 7 or 8, so for us
>>>>>> there are no new
>>>>> bugs in
>>>>>> 2.4.0 on top of Java 8.
>>>>>>&

Re: Is OpenJPA 2.4.0 is released or not

[Mark Struberg]

And thanks for all the reporting you do - that is equally important as well!

Will try to fix the other links as well and ping back in the evening.

txs and LieGrue,
strub

> Am 13.10.2015 um 07:32 schrieb Boblitz John :
> 
> Hello,
> 
> The download page now contains the links.
> 
> I was able to download the binary.
> 
> The Source downloads did not work.
> 
> HTTP link responds with NOT FOUND - url mirror/. not found on server
> FTP link responds with Failed to open file
> 
> I can not reach all of the HTTP sites due to a local firewall - but it seems 
> that the source download page is bugged.
> 
> 
> Thanks for the hard work you are doing!
> 
> John
> 
>> -Original Message-
>> From: Mark Struberg [mailto:strub...@yahoo.de]
>> Sent: Montag, 12. Oktober 2015 22:42
>> To: users@openjpa.apache.org
>> Subject: Re: Is OpenJPA 2.4.0 is released or not
>> 
>> fixed as well now. Can you please verify?
>> 
>> txs and LieGrue,
>> strub
>> 
>>> Am 12.10.2015 um 14:23 schrieb Henno Vermeulen
>> :
>>> 
>>> You're right, I don't see 2.4.0 listed on this page either:
>>> http://openjpa.apache.org/downloads.html
>>> 
>>> Henno
>>> 
>>> -Oorspronkelijk bericht-
>>> Van: Maxim Solodovnik [mailto:solomax...@gmail.com]
>>> Verzonden: maandag 12 oktober 2015 14:00
>>> Aan: users@openjpa.apache.org
>>> Onderwerp: Re: Is OpenJPA 2.4.0 is released or not
>>> 
>>> same for us,
>>> 
>>> openjpa 2.4.0 available on maven central
>>> 
>>> On Mon, Oct 12, 2015 at 5:58 PM, Boblitz John
>>> 
>>> wrote:
>>> 
>>>> Hello,
>>>> 
>>>> Maybe I'm just blind, but I do not see a link for 2.4.0 on the
>>>> download page (http://openjpa.apache.org/downloads.html).
>>>> 
>>>> Regards,
>>>> 
>>>> John
>>>> 
>>>>> -Original Message-
>>>>> From: Mark Struberg [mailto:strub...@yahoo.de]
>>>>> Sent: Mittwoch, 30. September 2015 20:41
>>>>> To: users@openjpa.apache.org
>>>>> Subject: Re: Is OpenJPA 2.4.0 is released or not
>>>>> 
>>>>> Hi Henno,
>>>>> big thanks for doing the tests and also for giving us the feedback!
>>>>> We also use 2.4.0 in production already without any issues - well,
>>>>> at
>>>> least
>>>>> without any regressions ;)
>>>>> 
>>>>> LieGrue,
>>>>> strub
>>>>> 
>>>>> 
>>>>>> Am 21.09.2015 um 09:44 schrieb Henno Vermeulen
>>>>> :
>>>>>> 
>>>>>> The documentation does list 2.4.0 as a release so I think they just
>>>> forgot to
>>>>> update the downloads page!
>>>>>> I'm no OpenJPA committer, perhaps they can give the "official"
>>>>>> answer,
>>>> but
>>>>> here's our practical answer:
>>>>>> 
>>>>>> We are using OpenJPA for a few years now. I can confirm from our
>>>>> experience that the enhancer for OpenJPA 2.3.0 is not able to
>>>>> enhance classes that are compiled with Java 8. It should be possible
>>>>> to compile
>>>> with
>>>>> Java 7 and use a Java 8 runtime, but we haven't tried this.
>>>>>> 
>>>>>> We have been using 2.4.0 with Java 7 in production (around 20
>>>>>> users)
>>>> for
>>>>> quite a few months. We have very thorough tests that use OpenJPA and
>>>>> the actual database. All of them were passing on 2.3.0 and Java 7
>>>>> and are now passing on 2.4.0 with either Java 7 or 8, so for us
>>>>> there are no new
>>>> bugs in
>>>>> 2.4.0 on top of Java 8.
>>>>>> 
>>>>>> We actually started using Java 8 in production since this weekend,
>>>>>> due
>>>> to
>>>>> extensive testing I'm confident everything works fine. I can't yet
>>>>> say
>>>> whether
>>>>> lambdas inside entities are working correctly, but I don't see why
>>>>> they shouldn't.
>>>>>> 
>>>>>> In short: I would say it's safe to use OpenJPA 2.4.0 and it won't
>>>>>> be a
>>>&

Re: Is OpenJPA 2.4.0 is released or not

[Mark Struberg]

fixed as well now. Can you please verify?

txs and LieGrue,
strub

> Am 12.10.2015 um 14:23 schrieb Henno Vermeulen :
> 
> You're right, I don't see 2.4.0 listed on this page either: 
> http://openjpa.apache.org/downloads.html
> 
> Henno
> 
> -Oorspronkelijk bericht-
> Van: Maxim Solodovnik [mailto:solomax...@gmail.com] 
> Verzonden: maandag 12 oktober 2015 14:00
> Aan: users@openjpa.apache.org
> Onderwerp: Re: Is OpenJPA 2.4.0 is released or not
> 
> same for us,
> 
> openjpa 2.4.0 available on maven central
> 
> On Mon, Oct 12, 2015 at 5:58 PM, Boblitz John 
> wrote:
> 
>> Hello,
>> 
>> Maybe I'm just blind, but I do not see a link for 2.4.0 on the 
>> download page (http://openjpa.apache.org/downloads.html).
>> 
>> Regards,
>> 
>> John
>> 
>>> -Original Message-
>>> From: Mark Struberg [mailto:strub...@yahoo.de]
>>> Sent: Mittwoch, 30. September 2015 20:41
>>> To: users@openjpa.apache.org
>>> Subject: Re: Is OpenJPA 2.4.0 is released or not
>>> 
>>> Hi Henno,
>>> big thanks for doing the tests and also for giving us the feedback!
>>> We also use 2.4.0 in production already without any issues - well, 
>>> at
>> least
>>> without any regressions ;)
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>>> Am 21.09.2015 um 09:44 schrieb Henno Vermeulen
>>> :
>>>> 
>>>> The documentation does list 2.4.0 as a release so I think they 
>>>> just
>> forgot to
>>> update the downloads page!
>>>> I'm no OpenJPA committer, perhaps they can give the "official" 
>>>> answer,
>> but
>>> here's our practical answer:
>>>> 
>>>> We are using OpenJPA for a few years now. I can confirm from our
>>> experience that the enhancer for OpenJPA 2.3.0 is not able to 
>>> enhance classes that are compiled with Java 8. It should be possible 
>>> to compile
>> with
>>> Java 7 and use a Java 8 runtime, but we haven't tried this.
>>>> 
>>>> We have been using 2.4.0 with Java 7 in production (around 20 
>>>> users)
>> for
>>> quite a few months. We have very thorough tests that use OpenJPA and 
>>> the actual database. All of them were passing on 2.3.0 and Java 7 
>>> and are now passing on 2.4.0 with either Java 7 or 8, so for us 
>>> there are no new
>> bugs in
>>> 2.4.0 on top of Java 8.
>>>> 
>>>> We actually started using Java 8 in production since this weekend, 
>>>> due
>> to
>>> extensive testing I'm confident everything works fine. I can't yet 
>>> say
>> whether
>>> lambdas inside entities are working correctly, but I don't see why 
>>> they shouldn't.
>>>> 
>>>> In short: I would say it's safe to use OpenJPA 2.4.0 and it won't 
>>>> be a
>> barrier
>>> to adopt Java 8.
>>>> If you encounter other barriers for Java 8 adoption, consider
>> compiling with
>>> Java 7 but running with a recent Java 8 JRE.
>>>> 
>>>> Henno Vermeulen
>>>> 
>>>> -Oorspronkelijk bericht-
>>>> Van: Talden [mailto:tal...@gmail.com]
>>>> Verzonden: vrijdag 18 september 2015 5:00
>>>> Aan: users@openjpa.apache.org
>>>> Onderwerp: Is OpenJPA 2.4.0 is released or not
>>>> 
>>>> OpenJPA 2.4.0 appears to be available on MavenCentral (Dated
>> 2015-04-20)
>>>> 
>>>> 
>>> http://search.maven.org/#artifactdetails|org.apache.openjpa|openjpa|2.4.
>>> 0|bundle
>>>> 
>>>> In mailing list archives there's a call to vote (With votes up to
>>>> 2015-04-24)
>>>> 
>>>> http://openjpa.208410.n2.nabble.com/VOTE-Release-Apache-OpenJPA-2-
>>> 4-0-tt7587965.html#none
>>>> 
>>>> But on the OpenJPA apache site the releases include only 2.3.0
>>>> 
>>>> 
>>>> Is 2.4.0 officially released?
>>>> 
>>>> Is the April 20th 2015 artefact in Maven Central (that pre-dates 
>>>> the
>> vote) a
>>> safe and valid build for production purposes?
>>>> 
>>>> Am I correct that this version is required to enhance classes in a
>> Java8
>>> runtime? A Java8 migration is highly desirable but wonder if OpenJPA
>> will be
>>> a barrier.
>>>> 
>>>> If 2.4.0 was not officially released, is there a release coming?
>>>> 
>>>> --
>>>> Aaron Scott-Boddendijk
>> 
>> 
> 
> 
> --
> WBR
> Maxim aka solomax

Re: OpenJPA openjpa-maven-plugin version 2.2.3 missing in maven central

[Mark Struberg]

Hi Tom!

openjpa-2.2.3 is simply not yet released.

The latest released JPA-2.0 compatible version is 2.4.0. 
It should contain all the fixes from 2.2.3 plus new features (e.g. 
BooleanRepresentation) and further bug fixes.

LieGrue,
strub



> Am 02.10.2015 um 22:46 schrieb tom.edwards 
> :
> 
> I guess I should actually mention that all maven dependencies for OpenJPA
> 2.2.3 do not exist in maven central.  I did try to grab the latest and
> build, but it seems that what is on the 2.2.x branch has the version set to
> 2.2.3-SNAPSHOT.
> 
> 
> 
> --
> View this message in context: 
> http://openjpa.208410.n2.nabble.com/OpenJPA-openjpa-maven-plugin-version-2-2-3-missing-in-maven-central-tp7588565p7588566.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: Is OpenJPA 2.4.0 is released or not

[Mark Struberg]

Hi Henno, 
big thanks for doing the tests and also for giving us the feedback!
We also use 2.4.0 in production already without any issues - well, at least 
without any regressions ;)

LieGrue,
strub


> Am 21.09.2015 um 09:44 schrieb Henno Vermeulen :
> 
> The documentation does list 2.4.0 as a release so I think they just forgot to 
> update the downloads page!
> I'm no OpenJPA committer, perhaps they can give the "official" answer, but 
> here's our practical answer:
> 
> We are using OpenJPA for a few years now. I can confirm from our experience 
> that the enhancer for OpenJPA 2.3.0 is not able to enhance classes that are 
> compiled with Java 8. It should be possible to compile with Java 7 and use a 
> Java 8 runtime, but we haven't tried this.
> 
> We have been using 2.4.0 with Java 7 in production (around 20 users) for 
> quite a few months. We have very thorough tests that use OpenJPA and the 
> actual database. All of them were passing on 2.3.0 and Java 7 and are now 
> passing on 2.4.0 with either Java 7 or 8, so for us there are no new bugs in 
> 2.4.0 on top of Java 8.
> 
> We actually started using Java 8 in production since this weekend, due to 
> extensive testing I'm confident everything works fine. I can't yet say 
> whether lambdas inside entities are working correctly, but I don't see why 
> they shouldn't.
> 
> In short: I would say it's safe to use OpenJPA 2.4.0 and it won't be a 
> barrier to adopt Java 8. 
> If you encounter other barriers for Java 8 adoption, consider compiling with 
> Java 7 but running with a recent Java 8 JRE. 
> 
> Henno Vermeulen
> 
> -Oorspronkelijk bericht-
> Van: Talden [mailto:tal...@gmail.com] 
> Verzonden: vrijdag 18 september 2015 5:00
> Aan: users@openjpa.apache.org
> Onderwerp: Is OpenJPA 2.4.0 is released or not
> 
> OpenJPA 2.4.0 appears to be available on MavenCentral (Dated 2015-04-20)
> 
> http://search.maven.org/#artifactdetails|org.apache.openjpa|openjpa|2.4.0|bundle
> 
> In mailing list archives there's a call to vote (With votes up to
> 2015-04-24)
> 
> http://openjpa.208410.n2.nabble.com/VOTE-Release-Apache-OpenJPA-2-4-0-tt7587965.html#none
> 
> But on the OpenJPA apache site the releases include only 2.3.0
> 
> 
> Is 2.4.0 officially released?
> 
> Is the April 20th 2015 artefact in Maven Central (that pre-dates the vote) a 
> safe and valid build for production purposes?
> 
> Am I correct that this version is required to enhance classes in a Java8 
> runtime? A Java8 migration is highly desirable but wonder if OpenJPA will be 
> a barrier.
> 
> If 2.4.0 was not officially released, is there a release coming?
> 
> --
> Aaron Scott-Boddendijk

Re: Is OpenJPA 2.4.0 is released or not

[Mark Struberg]

I fixed the most important links now. 
Can you plz check if it’s ok now?
And thanks for reporting it - this is important feedback as I’m most times too 
busy and forget about those things ;)

If you still miss something then plz ping me and I try to fix it as well.

txs and LieGrue,
strub



> Am 30.09.2015 um 16:55 schrieb Mark Struberg :
> 
> working on this now.
> Will keep you updated.
> 
> LieGrue,
> strub
> 
> 
>> Am 21.09.2015 um 23:06 schrieb Talden :
>> 
>> The OpenJPA pages on apache.org (http://openjpa.apache.org/) are the
>> obvious standouts.
>> 
>> They still suggest the latest stable is 2.3.0 and say things like "The
>> upcoming 2.4 release (trunk) is based off of the 2.3.x branch and will
>> contain some additional features (TBD)"
>> 
>> --
>> Aaron Scott-Boddendijk
>> 
>> On Tue, Sep 22, 2015 at 2:24 AM, Mark Struberg  wrote:
>> 
>>> It is officially released. Maybe I/we forgot to update some site still?
>>> 
>>> Just point me to the page you are missing something on and I gonna fix it.
>>> 
>>> txs and LieGrue,
>>> strub
>>> 
>>> 
>>>> Am 21.09.2015 um 09:44 schrieb Henno Vermeulen :
>>>> 
>>>> The documentation does list 2.4.0 as a release so I think they just
>>> forgot to update the downloads page!
>>>> I'm no OpenJPA committer, perhaps they can give the "official" answer,
>>> but here's our practical answer:
>>>> 
>>>> We are using OpenJPA for a few years now. I can confirm from our
>>> experience that the enhancer for OpenJPA 2.3.0 is not able to enhance
>>> classes that are compiled with Java 8. It should be possible to compile
>>> with Java 7 and use a Java 8 runtime, but we haven't tried this.
>>>> 
>>>> We have been using 2.4.0 with Java 7 in production (around 20 users) for
>>> quite a few months. We have very thorough tests that use OpenJPA and the
>>> actual database. All of them were passing on 2.3.0 and Java 7 and are now
>>> passing on 2.4.0 with either Java 7 or 8, so for us there are no new bugs
>>> in 2.4.0 on top of Java 8.
>>>> 
>>>> We actually started using Java 8 in production since this weekend, due
>>> to extensive testing I'm confident everything works fine. I can't yet say
>>> whether lambdas inside entities are working correctly, but I don't see why
>>> they shouldn't.
>>>> 
>>>> In short: I would say it's safe to use OpenJPA 2.4.0 and it won't be a
>>> barrier to adopt Java 8.
>>>> If you encounter other barriers for Java 8 adoption, consider compiling
>>> with Java 7 but running with a recent Java 8 JRE.
>>>> 
>>>> Henno Vermeulen
>>>> 
>>>> -Oorspronkelijk bericht-
>>>> Van: Talden [mailto:tal...@gmail.com]
>>>> Verzonden: vrijdag 18 september 2015 5:00
>>>> Aan: users@openjpa.apache.org
>>>> Onderwerp: Is OpenJPA 2.4.0 is released or not
>>>> 
>>>> OpenJPA 2.4.0 appears to be available on MavenCentral (Dated 2015-04-20)
>>>> 
>>>> 
>>> http://search.maven.org/#artifactdetails|org.apache.openjpa|openjpa|2.4.0|bundle
>>>> 
>>>> In mailing list archives there's a call to vote (With votes up to
>>>> 2015-04-24)
>>>> 
>>>> 
>>> http://openjpa.208410.n2.nabble.com/VOTE-Release-Apache-OpenJPA-2-4-0-tt7587965.html#none
>>>> 
>>>> But on the OpenJPA apache site the releases include only 2.3.0
>>>> 
>>>> 
>>>> Is 2.4.0 officially released?
>>>> 
>>>> Is the April 20th 2015 artefact in Maven Central (that pre-dates the
>>> vote) a safe and valid build for production purposes?
>>>> 
>>>> Am I correct that this version is required to enhance classes in a Java8
>>> runtime? A Java8 migration is highly desirable but wonder if OpenJPA will
>>> be a barrier.
>>>> 
>>>> If 2.4.0 was not officially released, is there a release coming?
>>>> 
>>>> --
>>>> Aaron Scott-Boddendijk
>>> 
>>> 
> 

Re: Is OpenJPA 2.4.0 is released or not

[Mark Struberg]

working on this now.
Will keep you updated.

LieGrue,
strub


> Am 21.09.2015 um 23:06 schrieb Talden :
> 
> The OpenJPA pages on apache.org (http://openjpa.apache.org/) are the
> obvious standouts.
> 
> They still suggest the latest stable is 2.3.0 and say things like "The
> upcoming 2.4 release (trunk) is based off of the 2.3.x branch and will
> contain some additional features (TBD)"
> 
> --
> Aaron Scott-Boddendijk
> 
> On Tue, Sep 22, 2015 at 2:24 AM, Mark Struberg  wrote:
> 
>> It is officially released. Maybe I/we forgot to update some site still?
>> 
>> Just point me to the page you are missing something on and I gonna fix it.
>> 
>> txs and LieGrue,
>> strub
>> 
>> 
>>> Am 21.09.2015 um 09:44 schrieb Henno Vermeulen :
>>> 
>>> The documentation does list 2.4.0 as a release so I think they just
>> forgot to update the downloads page!
>>> I'm no OpenJPA committer, perhaps they can give the "official" answer,
>> but here's our practical answer:
>>> 
>>> We are using OpenJPA for a few years now. I can confirm from our
>> experience that the enhancer for OpenJPA 2.3.0 is not able to enhance
>> classes that are compiled with Java 8. It should be possible to compile
>> with Java 7 and use a Java 8 runtime, but we haven't tried this.
>>> 
>>> We have been using 2.4.0 with Java 7 in production (around 20 users) for
>> quite a few months. We have very thorough tests that use OpenJPA and the
>> actual database. All of them were passing on 2.3.0 and Java 7 and are now
>> passing on 2.4.0 with either Java 7 or 8, so for us there are no new bugs
>> in 2.4.0 on top of Java 8.
>>> 
>>> We actually started using Java 8 in production since this weekend, due
>> to extensive testing I'm confident everything works fine. I can't yet say
>> whether lambdas inside entities are working correctly, but I don't see why
>> they shouldn't.
>>> 
>>> In short: I would say it's safe to use OpenJPA 2.4.0 and it won't be a
>> barrier to adopt Java 8.
>>> If you encounter other barriers for Java 8 adoption, consider compiling
>> with Java 7 but running with a recent Java 8 JRE.
>>> 
>>> Henno Vermeulen
>>> 
>>> -Oorspronkelijk bericht-
>>> Van: Talden [mailto:tal...@gmail.com]
>>> Verzonden: vrijdag 18 september 2015 5:00
>>> Aan: users@openjpa.apache.org
>>> Onderwerp: Is OpenJPA 2.4.0 is released or not
>>> 
>>> OpenJPA 2.4.0 appears to be available on MavenCentral (Dated 2015-04-20)
>>> 
>>> 
>> http://search.maven.org/#artifactdetails|org.apache.openjpa|openjpa|2.4.0|bundle
>>> 
>>> In mailing list archives there's a call to vote (With votes up to
>>> 2015-04-24)
>>> 
>>> 
>> http://openjpa.208410.n2.nabble.com/VOTE-Release-Apache-OpenJPA-2-4-0-tt7587965.html#none
>>> 
>>> But on the OpenJPA apache site the releases include only 2.3.0
>>> 
>>> 
>>> Is 2.4.0 officially released?
>>> 
>>> Is the April 20th 2015 artefact in Maven Central (that pre-dates the
>> vote) a safe and valid build for production purposes?
>>> 
>>> Am I correct that this version is required to enhance classes in a Java8
>> runtime? A Java8 migration is highly desirable but wonder if OpenJPA will
>> be a barrier.
>>> 
>>> If 2.4.0 was not officially released, is there a release coming?
>>> 
>>> --
>>> Aaron Scott-Boddendijk
>> 
>> 

Re: Is OpenJPA 2.4.0 is released or not

[Mark Struberg]

It is officially released. Maybe I/we forgot to update some site still?

Just point me to the page you are missing something on and I gonna fix it.

txs and LieGrue,
strub


> Am 21.09.2015 um 09:44 schrieb Henno Vermeulen :
> 
> The documentation does list 2.4.0 as a release so I think they just forgot to 
> update the downloads page!
> I'm no OpenJPA committer, perhaps they can give the "official" answer, but 
> here's our practical answer:
> 
> We are using OpenJPA for a few years now. I can confirm from our experience 
> that the enhancer for OpenJPA 2.3.0 is not able to enhance classes that are 
> compiled with Java 8. It should be possible to compile with Java 7 and use a 
> Java 8 runtime, but we haven't tried this.
> 
> We have been using 2.4.0 with Java 7 in production (around 20 users) for 
> quite a few months. We have very thorough tests that use OpenJPA and the 
> actual database. All of them were passing on 2.3.0 and Java 7 and are now 
> passing on 2.4.0 with either Java 7 or 8, so for us there are no new bugs in 
> 2.4.0 on top of Java 8.
> 
> We actually started using Java 8 in production since this weekend, due to 
> extensive testing I'm confident everything works fine. I can't yet say 
> whether lambdas inside entities are working correctly, but I don't see why 
> they shouldn't.
> 
> In short: I would say it's safe to use OpenJPA 2.4.0 and it won't be a 
> barrier to adopt Java 8. 
> If you encounter other barriers for Java 8 adoption, consider compiling with 
> Java 7 but running with a recent Java 8 JRE. 
> 
> Henno Vermeulen
> 
> -Oorspronkelijk bericht-
> Van: Talden [mailto:tal...@gmail.com] 
> Verzonden: vrijdag 18 september 2015 5:00
> Aan: users@openjpa.apache.org
> Onderwerp: Is OpenJPA 2.4.0 is released or not
> 
> OpenJPA 2.4.0 appears to be available on MavenCentral (Dated 2015-04-20)
> 
> http://search.maven.org/#artifactdetails|org.apache.openjpa|openjpa|2.4.0|bundle
> 
> In mailing list archives there's a call to vote (With votes up to
> 2015-04-24)
> 
> http://openjpa.208410.n2.nabble.com/VOTE-Release-Apache-OpenJPA-2-4-0-tt7587965.html#none
> 
> But on the OpenJPA apache site the releases include only 2.3.0
> 
> 
> Is 2.4.0 officially released?
> 
> Is the April 20th 2015 artefact in Maven Central (that pre-dates the vote) a 
> safe and valid build for production purposes?
> 
> Am I correct that this version is required to enhance classes in a Java8 
> runtime? A Java8 migration is highly desirable but wonder if OpenJPA will be 
> a barrier.
> 
> If 2.4.0 was not officially released, is there a release coming?
> 
> --
> Aaron Scott-Boddendijk

Re: Incorrect import range for javax.transaction makes openjpa incompatible to jta 1.2

[Mark Struberg]

Hi Christian!

JPA-2.0 is specified to use JTA-1.1.
Otoh there are just a few additional Classes in there and the rest remained 
unchanged.
Thus it’s imo fine to include this in the import definition.

I have a few more things on my list which I like to ship anyway, so I can do a 
2.4.1 release in the next 2 weeks.
Please add a patch to the jira. Gonna apply it.

LieGrue,
strub



> Am 20.08.2015 um 11:24 schrieb Christian Schneider :
> 
> We recently updated karaf to use jta 1.2 as it provides a standard 
> @Transactional annotation for usage in user code.
> 
> The problem is that openjpa does not work with jta 1.2. As far as I can tell 
> the issue is only an incorrect import range.
> I opened an issue for this but got no response till now:
> https://issues.apache.org/jira/browse/OPENJPA-2607
> 
> There is also a much older issue to create a karaf feature file during the 
> openjpa build:
> https://issues.apache.org/jira/browse/OPENJPA-2465
> 
> As we just released karaf 4.0.1 it will take about a month till the next 
> bugfix release. We need new openjpa releases with at least the first issue 
> solved. Until then openjpa will not work correctly in karaf with aries 
> transaction 1.1.x.
> 
> I can do the work of creating the patches or github pull requests if you 
> prefer.
> 
> Christian
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Open Source Architect
> http://www.talend.com
> 

Re: Question regarding "constant" parameter replacement in JPQL

[Mark Struberg]

Oh gosh, just found the following which gets executed _every_ time:

private static boolean isOraclePreparedStatement(Statement stmnt) {
try {
return Class.forName("oracle.jdbc.OraclePreparedStatement").
isInstance(stmnt);
} catch (Exception e) {
return false;
}
}

Please tell me I’m wrong, but we do a Class.forName for _every_ setString on an 
nchar, etc field?
Imo we can easily improve this by doing the Class.forName and getField just 
once and store it.
There is even a bit more reflection stuff which could get cached imo.

Will create a separate jira for it.

LieGrue,
strub

> Am 20.07.2015 um 16:58 schrieb Kariem Hussein :
> 
> Hi (again),
> 
> I've asked the same question on StackOverflow [1] and was pointed to a
> similar question [2] and actually found the well-hidden option to change
> this behavior by setting the hint UseLiteralInSql to true [3].
> 
> It seems to work, when I set this on the javax.persistence.Query, but it
> does not work, when I set the appropriate hint in orm.xml:
> 
>
>  
>select p
>from Person p
>where p.type = 'V'
>  
>  
>
> 
> Something wrong with this, or is there a limitation I am running into?
> 
> Thank you very much,
> Kariem
> 
> 
> [1] How can I prevent OpenJPA from replacing “constant” parameters in my
> queries?
> http://stackoverflow.com/questions/31516813
> 
> [2] jpa namedquery with literals changed to prepared statement
> http://stackoverflow.com/questions/28317482
> 
> [3] Javadoc org.apache.openjpa.kernel.QueryHints.HINT_USE_LITERAL_IN_SQL
> http://openjpa.apache.org/builds/2.4.0/apidocs/org/apache/openjpa/kernel/QueryHints.html#HINT_USE_LITERAL_IN_SQL
> 
> On Thu, Jul 16, 2015 at 2:30 PM, Kariem Hussein 
> wrote:
> 
>> Hi there,
>> 
>> I am in the process of migrating a big (old) code base from JPA 1 with
>> Hibernate 3.3 to JPA 2 with OpenJPA. I've had a problem with a query that
>> used to work in the old version and now does not and I wanted to know
>> whether my reasoning is correct.
>> 
>> I have already reduced the problem description to the minimal and I hope I
>> did not lose relevant pieces of information on the way.
>> 
>> Given this table in Oracle
>> 
>>create table PERSON (
>>  id char(10) not null,
>>  type char(3) not null,
>>  primary key (id)
>>)
>> 
>> There are a lot of rows with in total three different types "WTW", "WAI",
>> "V" (to be honest, I don't know what they stand for). However, we have an
>> entity to work with this table:
>> 
>>@Entity
>>public class Person {
>>   String id;
>>   String type;
>>}
>> 
>> The following query is used in the application from an orm.xml file:
>> 
>>
>>  
>>select p
>>from Person p
>>where p.type = 'V'
>>  
>>
>> 
>> As the `type` field is `char(3)`, Oracle will store `V   ` ('V' followed
>> by two spaces) for the string "V".
>> 
>> In Hibernate, I did not have a problem with this query, but with OpenJPA,
>> there is some magic performance improvement on this query that reduces the
>> number of queries by normalizing permutations -- at least that is what I
>> think why my query was translated this way -- which results in the
>> following SQL being sent to the DB
>> 
>>select p.id, p.type
>>from PERSON p
>>where p.type = ?
>> 
>> The "constant" parameter for `type` in my query was replaced with an SQL
>> parameter and the OpenJPA log shows that "V" is passed as value. I believe
>> that because of this replacement I do not get any results anymore.
>> 
>> It works if I do one of the following
>> 
>> - (a) Adapt the JPQL query to `where p.type = 'V  '`, effectively knowing
>> about the underlying `char(3)` field.
>> - (b) Use a native query. OpenJPA will then not try to "improve" my query
>> in a way that changes its semantics.
>> 
>> Is there something I can do to improve this behavior in JPA? Is there any
>> benefit in replacing a "constant" parameter in a named query that is only
>> used in this way (there are no permutations).
>> 
>> Shouldn't the parameter be converted correctly (including padding) into
>> the DB type? Is this a bug, or do I have to specify some kind of hint?
>> 
>> 
>> Thank you for your comments,
>> Kariem
>> 
>> 

Re: Service returns object, but nothing is received unless toString is called!

[Mark Struberg]

Probably some lazy loading which hits you?
When does the EntityManager get closed? You do not touch anything from the 
entity before the EntityManager gets closed? In that case this might be 
perfectly covered by the JPA spec.

Which form of enhancement do you use? build-time, classtransformer via 
javaagent or subclassing?
Can you check in the debugger which StateManager is in the entity instance? 
DetachStateManager or StateManagerImpl?

LieGrue,
strub


> Am 04.07.2015 um 11:07 schrieb Jim Talbut :
> 
> Hi,
> 
> I have this class:
> @Transactional
> @Component
> public class ProjectTransactionsImpl implements ProjectTransactions {
> 
>@SuppressWarnings("constantname")
>private static final Logger logger = 
> LoggerFactory.getLogger(ProjectTransactionsImpl.class);
> 
>@Autowired
>private ProviderService providerService;
> 
>@Override
>public Provider findProvider(String providerId) {
>Provider provider = providerService.find(providerId);
>logger.debug("Returning: {}", provider.getClass());
>return provider;
>}
> }
> 
> And a unit test calling it like this:
> @RunWith(SpringJUnit4ClassRunner.class)
> @ContextConfiguration(locations = {"file:src/test/resources/testContext.xml"})
> @TransactionConfiguration(transactionManager = "transactionManager", 
> defaultRollback = false)
> public class MigrateProjects extends AbstractMigrationClass {
> 
>private static final Logger logger = 
> LoggerFactory.getLogger(MigrateProjects.class);
> 
>@Autowired
>private ProjectTransactions trans;
> 
>private int projectsAdded = 0;
>private final Map providerProjectCountBefore = new 
> HashMap<>();
> 
>@Test
>public void test1() throws Exception {
>logger.debug("Getting provider");
>Provider provider = trans.findProvider("GTI");
>logger.debug("Returned: {}", provider);
>}
> }
> 
> Using OpenJPA 2.4.0 with Spring 4.1.7.RELEASE.
> 
> The log shows this:
> 09:56:52.913 [main] DEBUG c.g.e.a.t.MigrateProjects - 
> [MigrateProjects.java(54) MigrateProjects::test1] Getting provider
> 09:56:52.914 [main] DEBUG c.g.e.a.t.ProjectTransactionsImpl - 
> [ProjectTransactionsImpl.java(41) ProjectTransactionsImpl::findProvider] 
> Returning: class com.groupgti.esb.assessments.model.jpaimpl.ProviderImpl
> 09:56:52.915 [main] DEBUG c.g.e.a.t.MigrateProjects - 
> [MigrateProjects.java(56) MigrateProjects::test1] Returned: null
> 
> So I had an object in the call to findProvider, but it has become null by the 
> time if gets to the call site.
> If I change the logging line in findProvider to:
>logger.debug("Returning: {}", provider);
> Then I get this:
> 09:59:44.234 [main] DEBUG c.g.e.a.t.MigrateProjects - 
> [MigrateProjects.java(54) MigrateProjects::test1] Getting provider
> 09:59:44.235 [main] DEBUG c.g.e.a.t.ProjectTransactionsImpl - 
> [ProjectTransactionsImpl.java(41) ProjectTransactionsImpl::findProvider] 
> Returning: ProviderImpl{id=8, providerId=GTI, projects=20, 
> maintenanceWindows=0, textBlocks=0}
> 09:59:44.238 [main] DEBUG c.g.e.a.t.MigrateProjects - 
> [MigrateProjects.java(56) MigrateProjects::test1] Returned: 
> ProviderImpl{id=8, providerId=GTI, projects=20, maintenanceWindows=0, 
> textBlocks=0}
> 
> So if I log the object it gets output, but if I don't I get null.
> I can't debug this because the act of debugging makes it work!
> 
> If I change the logging line to:
>provider.getProjects();
> Just to prove I've really got an object and to ensure that a collection gets 
> loaded.
> Then I get:
> 10:01:37.101 [main] DEBUG c.g.e.a.t.MigrateProjects - 
> [MigrateProjects.java(54) MigrateProjects::test1] Getting provider
> 10:01:37.109 [main] DEBUG c.g.e.a.t.MigrateProjects - 
> [MigrateProjects.java(56) MigrateProjects::test1] Returned: null
> 
> If I change the logging line to:
>provider.toString();
> Then it works again:
> 10:03:09.843 [main] DEBUG c.g.e.a.t.MigrateProjects - 
> [MigrateProjects.java(54) MigrateProjects::test1] Getting provider
> 10:03:09.847 [main] DEBUG c.g.e.a.t.MigrateProjects - 
> [MigrateProjects.java(56) MigrateProjects::test1] Returned: 
> ProviderImpl{id=8, providerId=GTI, projects=20, maintenanceWindows=0, 
> textBlocks=0}
> 
> So something in toString seems to be making it work.
> The toString() implementation isn't very complicated:
>@Override
>public String toString() {
>try {
>return "ProviderImpl{" + "id=" + id + ", providerId=" + providerId 
> + ", projects=" + projects.size() + ", maintenanceWindows=" + 
> maintenanceWindows.size()
>+ ", textBlocks=" + textBlocks.size() + '}';
>} catch (NullPointerException ex) {
>return null;
>}
>}
> It's not hitting any NPE because it is returning a correct string.
> 
> Can anyone shed some light on what is happening here?
> Or suggest some approach I can take to debug it?
> 
> Thanks
> 
> Jim
> 

Re: Mapping a Join Table with Additional Columns

[Mark Struberg]

Why don’t you use a @ManyToMany relation?

LieGrue,
strub


> Am 26.04.2015 um 17:57 schrieb Marco de Booij :
> 
> I use Tomee 1.7.1 with openjpa version openjpa-2.4.0-nonfinal-1598334-r422266.
> 
> I have an entity auteurs and an entity boek. They have a ManyToMany relation 
> through the entity auteurs_boeken. In this entity there is a field type to 
> define the type of the relation (writer, illustrations, ...). I followed the 
> https://en.wikibooks.org/wiki/Java_Persistence/ManyToMany page and came up 
> with the following classes (left out all constructors, getters, and setters):
> 
> =
> @Entity
> @Table(name="AUTEURS", schema="BYBLOS")
> public class AuteurDto
>extends Dto implements Comparable, Cloneable {
>  private static final  long  serialVersionUID  = 1L;
> 
>  @Id
>  @GeneratedValue(strategy=GenerationType.IDENTITY)
>  @Column(name="AUTEUR_ID", nullable=false, unique=true)
>  private LongauteurId;
>  @Column(name="NAAM", length=100, nullable=false)
>  private String  naam;
>  @Column(name="VOORNAAM", length=100)
>  private String  voornaam;
> 
>  @OneToMany(cascade=CascadeType.ALL, fetch=FetchType.LAZY, mappedBy="auteur")
>  private List boeken;
> }
> 
> =
> @Entity
> @Table(name="BOEKEN", schema="BYBLOS")
> public class BoekDto extends Dto implements Comparable, Cloneable {
>  private static final  long  serialVersionUID  = 1L;
> 
>  @Id
>  @GeneratedValue(strategy=GenerationType.IDENTITY)
>  @Column(name="BOEK_ID", nullable=false, unique=true)
>  private LongboekId;
>  @Column(name="DEEL", precision=5, scale=0)
>  private Integer deel;
>  @Column(name="DRUK", precision=3, scale=0)
>  private Integer druk;
>  @Column(name="ISBN", length=13)
>  private String  isbn;
>  @Column(name="JAAR_UITGAVE", precision=4, scale=0)
>  private Integer jaarUitgave;
>  @Column(name="SUBDEEL", length=2)
>  private String  subdeel;
>  @Column(name="TAAL", length=2, nullable=false)
>  private String  taal;
>  @Column(name="TITEL", length=100, nullable=false)
>  private String  titel;
> 
>  @OneToOne(cascade=CascadeType.ALL, fetch=FetchType.LAZY)
>  @JoinColumn(name="SERIE_ID", nullable=false, updatable=false)
>  private SerieDto  serie;
> 
>  @OneToMany(mappedBy="boek", fetch=FetchType.LAZY)
>  private List auteurs;
> }
> 
> =
> @Entity
> @Table(name="AUTEURS_BOEKEN", schema="BYBLOS")
> @IdClass(AuteurBoekPK.class)
> public class AuteurBoekDto
>extends Dto implements Comparable, Cloneable {
>  private static final  long  serialVersionUID  = 1L;
> 
>  @Id
>  private LongauteurId;
>  @Id
>  private LongboekId;
>  @Column(name="AUTEUR_TYPE", nullable=false, length=1)
>  private String  auteurType;
> 
>  @ManyToOne
>  @PrimaryKeyJoinColumn(name="AUTEUR_ID", referencedColumnName="auteurId")
>  private AuteurDto auteur;
>  @ManyToOne
>  @PrimaryKeyJoinColumn(name="BOEK_ID", referencedColumnName="boekId")
>  private BoekDto   boek;
> }
> 
> When I fetch the boeken from within the AuteurDto I get the message:
>  
> org.apache.openjpa.persistence.ArgumentException: 
> "eu.debooy.byblos.domain.AuteurBoekDto.auteur" defines a target of "auteurId" 
> for column "AUTEUR_ID", but that target does not exist in table 
> "BYBLOS.AUTEURS".
> I have the same problem on the BoekDto. BoekDto has a OneToOne relation with 
> SerieDto and when I read the boeken from there I get the correct boeken so I 
> guess that the problem lies with my implementation of the ManyToMany. Can 
> someone show me the way to the correct implementation?
> 
> Regards,
> 
> Marco

Re: [VOTE] Release Apache OpenJPA-2.4.0

[Mark Struberg]

Hi Marc!

Sorry, not yet JPA-2.1 :(
But the good news is that we are moving again ;)

I personally would really like to address JPA-2.1 in the next moths, but first 
I like to clean up a few old technical debts. 
We probably can do a parallel stream where we tackle the most important 
features of JPA-2.1. But that needs some additional hands. For this to happen I 
would also first try to make it easier to write openjpa unit tests. That would 
easy contribution quite a bit.

LieGrue,
strub



> Am 23.04.2015 um 18:50 schrieb Marc Logemann :
> 
> Hi,
> 
> hoped for JPA 2.1 compliance..
> 
> 
> 
> 2015-04-19 17:03 GMT+02:00 Mark Struberg :
> 
>> It’s a great pleasure to call a VOTE for releasing Apache OpenJPA-2.4.0.
>> 
>> OpenJPA-2.4.0 implements the JPA-2.0 specification.
>> 
>> The staging repository can be found here:
>> https://repository.apache.org/content/repositories/orgapacheopenjpa-1000/
>> 
>> The Release Notes can be found in the file
>> openjpa-project/RELEASE_NOTES.html and online under:
>> 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310351&version=12325298
>> 
>> The SVN source TAG is (1674626):
>> https://svn.apache.org/repos/asf/openjpa/tags/openjpa-parent-2.4.0/
>> 
>> The source release can be found here:
>> 
>> https://repository.apache.org/content/repositories/orgapacheopenjpa-1000/org/apache/openjpa/openjpa-parent/2.4.0/openjpa-parent-2.4.0-source-release.zip
>> 
>> The binary release is here:
>> 
>> https://repository.apache.org/content/repositories/orgapacheopenjpa-1000/org/apache/openjpa/apache-openjpa/2.4.0/apache-openjpa-2.4.0-binary.zip
>> 
>> My Key can be found here
>> https://svn.apache.org/repos/asf/openjpa/KEYS
>> 
>> 
>> The VOTE will be open for 72 hours.
>> [+1] approve
>> [+0] meh, don’t care
>> [-1] stop, I’ve found a ${fish} in there
>> 
>> 
>> txs and LieGrue,
>> your OpenJPA team

Re: criteria API generates a parameter for literal in group by but does not provide the value

[Mark Struberg]

Yes, we still have to get the docs and site done.
Txs for your unit test. Will try to give it a run in the next 2 days.

LieGrue,
strub



> Am 23.04.2015 um 16:07 schrieb Henno Vermeulen :
> 
> Sorry, I haven't looked at the code base, I'm still an OpenJPA "user" not a 
> developer.
> 
> I submitted a unit test in the bug report OPENJPA-2578 criteria API "group 
> by" creates SQL with a parameter for a literal but does not provide it's 
> value. (Requires a trivial adjustment to be an official OpenJPA unit test).
> 
> The workaround works for me but I guess this should still be fixed because 
> that forces you to use the mentioned query hint and OpenJPA 2.4.0 when using 
> boolean literals.
> 
> I downloaded OpenJPA 2.4.0 today through Maven although the website doesn't 
> yet show it as released.
> Now I can move forwards to using Java 8. Good to see that all of my existing 
> (Java 7) tests that passed on 2.3.0 also pass in 2.4.0.
> 
> Henno
> 
> 
> -Oorspronkelijk bericht-
> Van: Rick Curtis [mailto:curti...@gmail.com] 
> Verzonden: donderdag 23 april 2015 15:42
> Aan: users
> Onderwerp: Re: criteria API generates a parameter for literal in group by but 
> does not provide the value
> 
>> Shall I report this as a bug or am I doing something wrong in my code?
> I vote bug
> 
> On Thu, Apr 23, 2015 at 6:43 AM, Mark Struberg  wrote:
> 
>> Thanks Henno!
>> 
>> Not quite sure if this workaround is good enough or whether we should 
>> try to solve this properly.
>> I plan to do a follow up release for 2.4.0 rather soonish. So thanks 
>> for your test case.
>> 
>> Did you already look at the OpenJPA codebase? Are you interested in 
>> turning this sample code into a unit test?
>> 
>> 
>> txs and LieGrue,
>> strub
>> 
>> 
>> 
>>> Am 23.04.2015 um 12:32 schrieb Henno Vermeulen :
>>> 
>>> One addition (my question is still open).
>>> 
>>> I can confirm that a valid workaround for this problem is to use
>> setHint("openjpa.hint.UseLiteralInSQL", "true") and updating to 
>> OpenJPA
>> 2.4.0 which is available in Maven central since a few days.
>>> 
>>> Henno
>>> 
>>> -Oorspronkelijk bericht-
>>> Van: Henno Vermeulen [mailto:he...@huizemolenaar.nl]
>>> Verzonden: donderdag 23 april 2015 11:49
>>> Aan: users@openjpa.apache.org
>>> Onderwerp: criteria API generates a parameter for literal in group 
>>> by
>> but does not provide the value
>>> 
>>> Hello,
>>> 
>>> I have a query created using the criteria API where I group by an
>> expression that contains a small calculation using literal values.
>>> 
>>> OpenJPA generates the correct SQL but does not provide the value of 
>>> the
>> generated parameter in the group by clause. The query fails with a SQL 
>> exception "The value is not set for the parameter number 9.".
>>> 
>>> I can reproduce the issue with a minimal example. Suppose we have a
>> person class with integer age and length columns and we wish to select 
>> the average length grouped by the person's age / 10:
>>> 
>>>   CriteriaBuilder cb = em.getCriteriaBuilder();
>>>   CriteriaQuery query =
>> cb.createQuery(Double.class);
>>>   Root person = 
>>> query.from(Person.class);
>>> 
>>>   Expression averageLength =
>> cb.avg(person. get("length"));
>>>   CriteriaQuery select =
>> query.select(averageLength);
>>> 
>>>   select.groupBy(cb.quot(person.
>> get("age"), cb.literal(10)));
>>>   // optional where, useful to ensure 
>>> parameters
>> are logged
>>>   select.where(cb.gt(person. 
>>> get("age"),
>> cb.literal(20)));
>>> 
>>>   System.out.println("result: " +
>> em.createQuery(query).getResultList());
>>> 
>>> Whe running this query with trace and displaying parameters on I get:
>>> 
>>> 1067  testPU  TRACE  [main] openjpa.Query - Executing query: Query:
>> org.apache.openjpa.kernel.QueryImpl@be4f81; candidate class: class 
>> entities.Person; query: null
>>> 1108  testPU  TRACE  [main] openjpa.jdbc.SQL - >> 7326702>
>> executing prepstmnt 26531336 SELECT AVG(t0.length) FROM Person t0 
>> WHERE (t0.age > ?) GROUP BY (t0.age / ?) [params=(int) 20]
>>> 
>>> You can clearly see that the query has two parameter placeholders 
>>> but
>> only one value is provided.
>>> Shall I report this as a bug or am I doing something wrong in my code?
>>> 
>>> (As a workaround I can call setHint("openjpa.hint.UseLiteralInSQL",
>> "true") on em.createQuery(query). This doesn't work in my application 
>> because there is a bug where boolean literals aren't correctly handled:
>> https://issues.apache.org/jira/browse/OPENJPA-2534. I think this is 
>> solved in the upcoming release.)
>>> 
>>> Thank you,
>>> Henno
>>> 
>> 
>> 
> 
> 
> --
> *Rick Curtis*

Re: criteria API generates a parameter for literal in group by but does not provide the value

[Mark Struberg]

Thanks Henno!

Not quite sure if this workaround is good enough or whether we should try to 
solve this properly.
I plan to do a follow up release for 2.4.0 rather soonish. So thanks for your 
test case.

Did you already look at the OpenJPA codebase? Are you interested in turning 
this sample code into a unit test?


txs and LieGrue,
strub



> Am 23.04.2015 um 12:32 schrieb Henno Vermeulen :
> 
> One addition (my question is still open).
> 
> I can confirm that a valid workaround for this problem is to use 
> setHint("openjpa.hint.UseLiteralInSQL", "true") and updating to OpenJPA 2.4.0 
> which is available in Maven central since a few days.
> 
> Henno
> 
> -Oorspronkelijk bericht-
> Van: Henno Vermeulen [mailto:he...@huizemolenaar.nl] 
> Verzonden: donderdag 23 april 2015 11:49
> Aan: users@openjpa.apache.org
> Onderwerp: criteria API generates a parameter for literal in group by but 
> does not provide the value
> 
> Hello,
> 
> I have a query created using the criteria API where I group by an expression 
> that contains a small calculation using literal values.
> 
> OpenJPA generates the correct SQL but does not provide the value of the 
> generated parameter in the group by clause. The query fails with a SQL 
> exception "The value is not set for the parameter number 9.".
> 
> I can reproduce the issue with a minimal example. Suppose we have a person 
> class with integer age and length columns and we wish to select the average 
> length grouped by the person's age / 10:
> 
>CriteriaBuilder cb = em.getCriteriaBuilder();
>CriteriaQuery query = 
> cb.createQuery(Double.class);
>Root person = query.from(Person.class);
> 
>Expression averageLength = 
> cb.avg(person. get("length"));
>CriteriaQuery select = 
> query.select(averageLength);
> 
>select.groupBy(cb.quot(person. get("age"), 
> cb.literal(10)));
>// optional where, useful to ensure parameters are 
> logged
>select.where(cb.gt(person. get("age"), 
> cb.literal(20)));
> 
>System.out.println("result: " + 
> em.createQuery(query).getResultList());
> 
> Whe running this query with trace and displaying parameters on I get:
> 
> 1067  testPU  TRACE  [main] openjpa.Query - Executing query: Query: 
> org.apache.openjpa.kernel.QueryImpl@be4f81; candidate class: class 
> entities.Person; query: null
> 1108  testPU  TRACE  [main] openjpa.jdbc.SQL -  
> executing prepstmnt 26531336 SELECT AVG(t0.length) FROM Person t0 WHERE 
> (t0.age > ?) GROUP BY (t0.age / ?) [params=(int) 20]
> 
> You can clearly see that the query has two parameter placeholders but only 
> one value is provided.
> Shall I report this as a bug or am I doing something wrong in my code?
> 
> (As a workaround I can call setHint("openjpa.hint.UseLiteralInSQL", "true") 
> on em.createQuery(query). This doesn't work in my application because there 
> is a bug where boolean literals aren't correctly handled: 
> https://issues.apache.org/jira/browse/OPENJPA-2534. I think this is solved in 
> the upcoming release.)
> 
> Thank you,
> Henno
> 

Re: [VOTE] [RESULT] Release Apache OpenJPA-2.4.0

[Mark Struberg]

Hi!

The VOTE did pass with the following:

+1: Romain (nonbinding), Kevin, Rick, Albert, Mark (nonbinding)
No -1 nor +1

Will propagate the artifacts.

LieGrue,
strub



> Am 19.04.2015 um 17:03 schrieb Mark Struberg :
> 
> It’s a great pleasure to call a VOTE for releasing Apache OpenJPA-2.4.0.
> 
> OpenJPA-2.4.0 implements the JPA-2.0 specification.
> 
> The staging repository can be found here:
> https://repository.apache.org/content/repositories/orgapacheopenjpa-1000/
> 
> The Release Notes can be found in the file openjpa-project/RELEASE_NOTES.html 
> and online under:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310351&version=12325298
> 
> The SVN source TAG is (1674626):
> https://svn.apache.org/repos/asf/openjpa/tags/openjpa-parent-2.4.0/
> 
> The source release can be found here:
> https://repository.apache.org/content/repositories/orgapacheopenjpa-1000/org/apache/openjpa/openjpa-parent/2.4.0/openjpa-parent-2.4.0-source-release.zip
> 
> The binary release is here:
> https://repository.apache.org/content/repositories/orgapacheopenjpa-1000/org/apache/openjpa/apache-openjpa/2.4.0/apache-openjpa-2.4.0-binary.zip
> 
> My Key can be found here 
> https://svn.apache.org/repos/asf/openjpa/KEYS
> 
> 
> The VOTE will be open for 72 hours.
> [+1] approve
> [+0] meh, don’t care
> [-1] stop, I’ve found a ${fish} in there
> 
> 
> txs and LieGrue,
> your OpenJPA team

Re: [VOTE] Release Apache OpenJPA-2.4.0

[Mark Struberg]

+1 nonbinding

So we _still_ miss at least 1 binding vote…

LieGrue,
strub


> Am 19.04.2015 um 17:03 schrieb Mark Struberg :
> 
> It’s a great pleasure to call a VOTE for releasing Apache OpenJPA-2.4.0.
> 
> OpenJPA-2.4.0 implements the JPA-2.0 specification.
> 
> The staging repository can be found here:
> https://repository.apache.org/content/repositories/orgapacheopenjpa-1000/
> 
> The Release Notes can be found in the file openjpa-project/RELEASE_NOTES.html 
> and online under:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310351&version=12325298
> 
> The SVN source TAG is (1674626):
> https://svn.apache.org/repos/asf/openjpa/tags/openjpa-parent-2.4.0/
> 
> The source release can be found here:
> https://repository.apache.org/content/repositories/orgapacheopenjpa-1000/org/apache/openjpa/openjpa-parent/2.4.0/openjpa-parent-2.4.0-source-release.zip
> 
> The binary release is here:
> https://repository.apache.org/content/repositories/orgapacheopenjpa-1000/org/apache/openjpa/apache-openjpa/2.4.0/apache-openjpa-2.4.0-binary.zip
> 
> My Key can be found here 
> https://svn.apache.org/repos/asf/openjpa/KEYS
> 
> 
> The VOTE will be open for 72 hours.
> [+1] approve
> [+0] meh, don’t care
> [-1] stop, I’ve found a ${fish} in there
> 
> 
> txs and LieGrue,
> your OpenJPA team

[VOTE] Release Apache OpenJPA-2.4.0

[Mark Struberg]

It’s a great pleasure to call a VOTE for releasing Apache OpenJPA-2.4.0.

OpenJPA-2.4.0 implements the JPA-2.0 specification.

The staging repository can be found here:
https://repository.apache.org/content/repositories/orgapacheopenjpa-1000/

The Release Notes can be found in the file openjpa-project/RELEASE_NOTES.html 
and online under:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310351&version=12325298

The SVN source TAG is (1674626):
https://svn.apache.org/repos/asf/openjpa/tags/openjpa-parent-2.4.0/

The source release can be found here:
https://repository.apache.org/content/repositories/orgapacheopenjpa-1000/org/apache/openjpa/openjpa-parent/2.4.0/openjpa-parent-2.4.0-source-release.zip

The binary release is here:
https://repository.apache.org/content/repositories/orgapacheopenjpa-1000/org/apache/openjpa/apache-openjpa/2.4.0/apache-openjpa-2.4.0-binary.zip

My Key can be found here 
https://svn.apache.org/repos/asf/openjpa/KEYS


The VOTE will be open for 72 hours.
[+1] approve
[+0] meh, don’t care
[-1] stop, I’ve found a ${fish} in there


txs and LieGrue,
your OpenJPA team

Re: Which version of JPA (2.0 or 2.1) does openjpa 2.4 support?

[Mark Struberg]

> OK, so can I suggest that the web page needs updating as it is currently
> misleading.

Oh, thanks for the pointer!

> Also why do you suppose that Eclipse seems to think that the openjpa
> jar file in tomee contains a 2.1 JPA implementation rather than a 2.0 one?
> It is resisting me trying to "downgrade" JPA support to 2.0 with the
> 2.4 jar installed.


Hmm, that’s weird indeed. But I guess this has more to do with Eclipse than 
with openjpa.

LieGrue,
strub




> Am 06.04.2015 um 13:15 schrieb David Goodenough 
> :
> 
> OK, so can I suggest that the web page needs updating as it is currently
> misleading.
> 
> Also why do you suppose that Eclipse seems to think that the openjpa
> jar file in tomee contains a 2.1 JPA implementation rather than a 2.0 one?
> It is resisting me trying to "downgrade" JPA support to 2.0 with the
> 2.4 jar installed.
> 
> David
> 
> On Monday 06 April 2015 12:17:00 Mark Struberg wrote:
>> Hi!
>> 
>> openjpa-2.4.0 is indeed targetting JPA-2.0.
>> 
>> I personally would like to  target JPA-2.1 soon, but before that I would
>> love to see a few cleanup efforts being done. E.g. cleaning up our bytecode
>> parts and move all to xbean-asm5-shaded.
>> 
>> LieGrue,
>> strub
>> 
>>> Am 06.04.2015 um 11:15 schrieb David Goodenough
>>> :
>>> 
>>> According to:-
>>> 
>>> http://openjpa.apache.org/jpa-2.1-development-process.html
>>> 
>>> openjpa 2.4 is the release that should implement JPA 2.1.  But I am told
>>> on the tomee mailing list that although tomee 2.0 included an
>>> openjpa 2.4 snapshot it does not support jpa 2.1.
>>> 
>>> I am confused, can someone enlighten me.
>>> 
>>> David
> 

Re: Which version of JPA (2.0 or 2.1) does openjpa 2.4 support?

[Mark Struberg]

Hi!

openjpa-2.4.0 is indeed targetting JPA-2.0.

I personally would like to  target JPA-2.1 soon, but before that I would love 
to see a few cleanup efforts being done.
E.g. cleaning up our bytecode parts and move all to xbean-asm5-shaded.

LieGrue,
strub


> Am 06.04.2015 um 11:15 schrieb David Goodenough 
> :
> 
> According to:-
> 
> http://openjpa.apache.org/jpa-2.1-development-process.html
> 
> openjpa 2.4 is the release that should implement JPA 2.1.  But I am told
> on the tomee mailing list that although tomee 2.0 included an
> openjpa 2.4 snapshot it does not support jpa 2.1.
> 
> I am confused, can someone enlighten me.
> 
> David

Re: Java 8/Java 7 end of life

[Mark Struberg]

TomEE uses trunk builds.
2.3.x is not really used anymore.
Guess we should really establish a more feature driven release policy. 
Currently it is really product driven. This is fine for 2.2.x but I think this 
doesn’t scale well for future releases.

LieGrue,
strub


> Am 10.03.2015 um 14:40 schrieb Rick Curtis :
> 
> I don't think my previous comment was entirely correct.
> 
>> OpenJPA 2.3.x and trunk should be functional with java8, but I don't
> think you can build OpenJPA with java8.
> Java 8 works with 2.2.x and trunk. I can't say for certain about the 2.3.x
> branch... that is maintained by the TomEE folks and I can't recall which
> changes they did / didn't pull in to support Java 8.
> 
> Thanks,
> Rick
> 
> On Tue, Mar 10, 2015 at 3:31 AM, Henno Vermeulen 
> wrote:
> 
>> Hal Hildebrand wrote:
>>> I can certainly confirm that OpenJPA runs on java 8.  And even
>>> compiles when using source 1.7, target 1.7.
>> 
>> Thank you Hal, that is some very useful information! It gives a solution
>> to possible future security issues due to using an outdated VM.
>> 
>> (I already tried using the released version 2.3.0 of OpenJPA with Java 8.
>> Compiling works ok but enhancing the entities failed with some error
>> message.)
>> 
>> Henno
>> 
>> 
>> -Oorspronkelijk bericht-
>> Van: Rick Curtis [mailto:curti...@gmail.com]
>> Verzonden: maandag 9 maart 2015 19:30
>> Aan: users
>> Onderwerp: Re: Java 8/Java 7 end of life
>> 
>> Hal -
>> 
>> What are you seeing for problems? We've done some amount of testing Entity
>> enhancement when using java 8 language features.
>> 
>> Thanks,
>> Rick
>> 
>> On Mon, Mar 9, 2015 at 10:46 AM, Hal Hildebrand 
>> wrote:
>> 
>>> No.
>>> 
 On Mar 9, 2015, at 8:44 AM, Boblitz John 
>>> wrote:
 
 Hello,
 
 Does the Byte Code Enhancement work when compiled for 1.8?
 
 Thanks & Regards,
 
 John Boblitz
 
 
> -Original Message-
> From: Hal Hildebrand [mailto:hal.hildebr...@me.com]
> Sent: Montag, 9. März 2015 16:21
> To: users@openjpa.apache.org
> Subject: Re: Java 8/Java 7 end of life
> 
> I can certainly confirm that OpenJPA runs on java 8.  And even
> compiles when using source 1.7, target 1.7.  Byte code enhancement
> works fine on
>>> the
> code when compiled in that fashion.
> 
>> On Mar 9, 2015, at 6:06 AM, Rick Curtis  wrote:
>> 
>> OpenJPA 2.3.x and trunk should be functional with java8, but I
>> don't think you can build OpenJPA with java8.
>> 
>> On Mon, Mar 9, 2015 at 3:52 AM, Henno Vermeulen
>> 
>> wrote:
>> 
>>> Hello,
>>> 
>>> AFAIK, OpenJPA still doesn't work with Java 8. Are there any
>>> plans of fixing this soon? Perhaps OpenJPA committers could give
>>> this some more priority?
>>> 
>>> Oracle public support for Java 7 will end after April this year,
>>> see http://www.oracle.com/technetwork/java/javase/eol-135779.html
>>> If I understand well, this means that security issues in Oracle's
>>> Java 7 runtime will no longer be fixed so that an application
>>> using OpenJPA on Java 7 will become more and more vulnerable over
>> time.
>>> 
>>> The ticket for Java 8 was last updated in October 2014:
>>> https://issues.apache.org/jira/browse/OPENJPA-2386
>>> 
>>> Regards,
>>> Henno Vermeulen
>>> 
>> 
>> 
>> 
>> --
>> *Rick Curtis*
 
>>> 
>>> 
>> 
>> 
>> --
>> *Rick Curtis*
>> 
> 
> 
> 
> -- 
> *Rick Curtis*

Re: OpenJPA support for JPA 2.1: when?

[Mark Struberg]

I definitely like to start working on OpenJPA again.
Just give me a week to again do a 'warm up'.
It's really needed to dig into the code for a week or so before you start to 
hack. There are just so many layers of indirection which you need to understand 
and you possibly can break...


My current customer has a few issues with OpenJPA which I need to fix now. This 
has nothing to do with JPA-2.1 but of course is a good trigger to start again.

LieGrue,
strub





> On Wednesday, 7 January 2015, 23:29, Roberto Cortez 
>  wrote:
> > Hi everyone,
> I've done some draft work to support Schema Generation of JPA 2.1. It's 
> far from over, still needs a lot of polishing but I would love some feedback 
> before moving forward:
> https://github.com/radcortez/openjpa21/commit/8fc4e306ca7e8dc73737a506768269097289abf4
> 
> Thank you!
> Cheers,Roberto
>   From: Roberto Cortez 
> 
> To: "users@openjpa.apache.org"  
> Sent: Tuesday, December 30, 2014 1:58 AM
> Subject: Re: OpenJPA support for JPA 2.1: when?
>   
> Hi guys,
> Started some work on the schema generation 
> features:https://issues.apache.org/jira/browse/OPENJPA-2554
> 
> Would love some feedback to check if I'm in the right track. Thank you.
> Cheers,Roberto
>   From: Pinaki Poddar 
> 
> 
> To: users@openjpa.apache.org 
> Sent: Friday, December 12, 2014 7:20 PM
> Subject: Re: OpenJPA support for JPA 2.1: when?
>   
> May of JPA 2.1 have been developed on the branch Kevin had mentioned. As it
> was quite a while I had looked at beautiful OpenJPA code (i am now a FOB in
> the wobbly-goobly-gook Python/Shell Script world filled with super-wizards
> :), the exact features I had implemented on that branch escapes me.
> 
> The essentials are
> 1. Stored Procedure support was well-cooked as it required new
> constructs/concepts in OpenJPA
> 2. Many low-hanging features that had been part of OpenJPA in alternative
> form are adapted to JPA 2.1 form
> 
> Will take a look when i get some free time. 
> 
> Any new or old committers ready to contribute to OpenJPA are welcome to
> offer a hand to drive these prototypes to completion. 
> 
> 
> 
> 
> 
> -
> Pinaki Poddar
> Chair, Apache OpenJPA Project
> --
> View this message in context: 
> http://openjpa.208410.n2.nabble.com/OpenJPA-support-for-JPA-2-1-when-tp7584157p7587494.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> 

Re: Auditor issue after upgrading to OpenJPA 2.3.0

[Mark Struberg]

No worries. I am currently tweaking my slides for a 3 days workshop next week.
After that I have time to look at this stuff.

Reminds me that I still need to merge a few commits from 2.3.0 to trunk + ship 
the site build :/

LieGrue,
strub




- Original Message -
> From: Rick Curtis 
> To: users 
> Cc: Mark Struberg 
> Sent: Thursday, 5 December 2013, 15:35
> Subject: Re: Auditor issue after upgrading to OpenJPA 2.3.0
> 
> Mark --
> 
> I'll also note that I'm having problems with the changes that were done 
> for
> OPENJPA-2437 with some internal tests. My test failures are different than
> Harald's though.
> 
> It's a long story as to why the problem wasn't uncovered earlier but I 
> hope
> to get time to look at it later today or tomorrow.
> 
> 
> 
> On Thu, Dec 5, 2013 at 8:16 AM, Harald Wellmann 
> wrote:
> 
>>  Please see https://issues.apache.org/jira/browse/OPENJPA-2464. There's 
> a
>>  test case attached.
>> 
>>  Best regards,
>>  Harald
>> 
>> 
>>  2013/11/27 Mark Struberg 
>> 
>>  > This is not known, but we moved the invocation of the auditing 
> mechanism
>>  > around a bit.
>>  > There must be a JIRA which is tagged as 2.3.1.
>>  >
>>  > Please create a new JIRA for it and we will take a look.
>>  >
>>  > LieGrue,
>>  > strub
>>  >
>>  >
>>  >
>>  > >
>>  > > From: Harald Wellmann 
>>  > >To: users@openjpa.apache.org
>>  > >Sent: Wednesday, 27 November 2013, 15:52
>>  > >Subject: Auditor issue after upgrading to OpenJPA 2.3.0
>>  > >
>>  > >
>>  > >After upgrading from OpenJPA 2.2.2 to 2.3.0, one of my regression 
> tests
>>  > >fails since Auditor.audit() delivers too many objects. In 
> particular,
>>  > after
>>  > >changing a given field from x to y, some of the updated objects 
> occur
>>  > >twice, with the surplus occurrence reporting the field as changed 
> from y
>>  > to
>>  > >y.
>>  > >
>>  > >Is this a known issue?
>>  > >
>>  > >The changes affect an embeddable type which occurs twice in a 
> given
>>  > entity:
>>  > >
>>  > >@Entity
>>  > >@Auditable
>>  > >public class Container {
>>  > >
>>  > >   @AttributeOverrides(...)
>>  > >   private Item leftItem;
>>  > >
>>  > >   @AttributeOverrides(...)
>>  > >   private Item rightItem;
>>  > >}
>>  > >
>>  > >@Embeddable
>>  > >@Auditable(values = { AuditableOperation.UPDATE })
>>  > >public class Item {
>>  > >}
>>  > >
>>  > >Best regards,
>>  > >Harald
>>  > >
>>  > >
>>  > >
>>  >
>> 
> 
> 
> 
> -- 
> *Rick Curtis*
>

Re: Auditor issue after upgrading to OpenJPA 2.3.0

[Mark Struberg]

This is not known, but we moved the invocation of the auditing mechanism around 
a bit.
There must be a JIRA which is tagged as 2.3.1.

Please create a new JIRA for it and we will take a look.

LieGrue,
strub



>
> From: Harald Wellmann 
>To: users@openjpa.apache.org 
>Sent: Wednesday, 27 November 2013, 15:52
>Subject: Auditor issue after upgrading to OpenJPA 2.3.0
> 
>
>After upgrading from OpenJPA 2.2.2 to 2.3.0, one of my regression tests
>fails since Auditor.audit() delivers too many objects. In particular, after
>changing a given field from x to y, some of the updated objects occur
>twice, with the surplus occurrence reporting the field as changed from y to
>y.
>
>Is this a known issue?
>
>The changes affect an embeddable type which occurs twice in a given entity:
>
>@Entity
>@Auditable
>public class Container {
>
>   @AttributeOverrides(...)
>   private Item leftItem;
>
>   @AttributeOverrides(...)
>   private Item rightItem;
>}
>
>@Embeddable
>@Auditable(values = { AuditableOperation.UPDATE })
>public class Item {
>}
>
>Best regards,
>Harald
>
>
>

AW: Re: OpenJPA 2.3.0-SNAPSHOT sources not available in maven

[Mark Struberg]

please note that trunk got moved to 2.0.4-SNAPSHOT.

LG,
strub




--
Albert Lee schrieb am Di., 19. Nov 2013 00:49 MEZ:

>Nightly build can be found in
>http://openjpa.apache.org/downloads-nightly.html
>
>I followed the 
>apache-openjpa-2.3.0-SNAPSHOT-source.ziplink
>and I was able to download
>
>https://repository.apache.org/snapshots/org/apache/openjpa/apache-openjpa/2.3.0-SNAPSHOT/apache-openjpa-2.3.0-20131024.064931-148-source.zip
>
>
>
>On Mon, Nov 18, 2013 at 4:06 PM, Reinis Vicups  wrote:
>
>> Hi,
>>
>> I see that openjpa-2.3.0-20131024.064931-148-sources.jar-not-available.
>>
>> Is there a way to somehow access and bind openjpa sources in maven?
>>
>> thx
>> reinis
>>
>
>
>
>-- 
>Albert Lee.

Re: Vote for standard JPA jar in maven

[Mark Struberg]

I was speaking about javax.* apis in general. 
JPA2.x are EPL, but JPA1 is CDDL, isn't?

In any case I prefer having our own IP clean spec jars.  It's just so much 
easier to not having to check the licenses each time.

LieGrue,
strub




>
> From: Rick Curtis 
>To: users ; Mark Struberg  
>Sent: Friday, 15 November 2013, 18:15
>Subject: Re: Vote for standard JPA jar in maven
> 
>
>
>> CDDL is still not perfect and some apis are even LGPL (which is a complete 
>>no-go).
>
>
>CDDL? I thought that the javax.persistence files are EPL?
>
>
>
>On Fri, Nov 15, 2013 at 1:30 AM, Mark Struberg  wrote:
>
>The problem is usually not vendor neutrality but the license.
>>CDDL is still not perfect and some apis are even LGPL (which is a complete 
>>no-go).
>>
>>Thus using our very own clean room engineered org.apache.geronimo.spec.* API 
>>jars is still the safest bet.
>>
>>LieGrue,
>>strub
>>
>>
>>
>>
>>
>>- Original Message -
>>> From: Matthew Adams 
>>> To: users@openjpa.apache.org; kundera-disc...@googlegroups.com
>>> Cc:
>>> Sent: Thursday, 14 November 2013, 17:47
>>> Subject: Vote for standard JPA jar in maven
>>>
>>> Please vote for this issue, requesting that a standard, vendor-neutral JPA
>>> jar be published.
>>>
>>> https://java.net/jira/browse/JPA_SPEC-60
>>>
>>> -matthew
>>>
>>
>
>
>
>-- 
>Rick Curtis
>
>
>

Re: Vote for standard JPA jar in maven

[Mark Struberg]

The problem is usually not vendor neutrality but the license.
CDDL is still not perfect and some apis are even LGPL (which is a complete 
no-go).

Thus using our very own clean room engineered org.apache.geronimo.spec.* API 
jars is still the safest bet.

LieGrue,
strub




- Original Message -
> From: Matthew Adams 
> To: users@openjpa.apache.org; kundera-disc...@googlegroups.com
> Cc: 
> Sent: Thursday, 14 November 2013, 17:47
> Subject: Vote for standard JPA jar in maven
> 
> Please vote for this issue, requesting that a standard, vendor-neutral JPA
> jar be published.
> 
> https://java.net/jira/browse/JPA_SPEC-60
> 
> -matthew
> 

Re: Immutable list in entity

[Mark Struberg]

Lists we get from query.getResultList() are of course immutable. 

But if I have an entity which has a @ElementCollection or a @OneToMany 
List then those imo should be mutable. Regardless whether in 
attached or detached state..

It is obvious for @ElementCollections but also for e.g. @OneToMany with 
CascadeType.ALL.

Otherwise entityManager.merge() would not make much sense imo...

I was always under the impression that this works perfectly fine, even in 
detached state. We do not exchange the lists in those entities when we perform 
a detachment afaik. We only change the StateManager to a DetachedStateManager, 
but thats's it basically.

LieGrue,
strub




>
> From: Rick Curtis 
>To: users  
>Sent: Tuesday, 22 October 2013, 18:30
>Subject: Re: Immutable list in entity
> 
>
>I don't have a solid answer, but have found a number of posts throughout
>the years on markmail[1]. I'm just heading out to lunch, but I'll read
>through those sometime later today.
>
>[1] http://openjpa.markmail.org/search/?q=%22Result+lists+are+read+only%22
>
>
>
>On Tue, Oct 22, 2013 at 11:05 AM, José Luis Cetina wrote:
>
>> Sorry about String immutable, let my explain me.
>>
>>  (The entities is just an example for demostrate this)
>>
>> @Entity
>> private MyClass implements Serializable{
>>
>> private String name="old value";
>> @ManyToOne
>> private List products;
>> // getters and setters..
>> }
>>
>> Example 1
>> 1. Get MyClass entity in a managedbean from and ejb (ejb use a query and
>> the products attribute is null because is LAZY LOADING).
>> 2. inside of the managedbean try to set a new value for name
>> myClass.setName("new value); //the value is refreshed from "old value" to
>> the new value "new value"
>> 3. inside of the managedbean try to set a new list of products like:
>>     List myNewList = new ArrayList(new Product());
>>     //then try to set this new list to the entity, remeber that we are in
>> the managedbean and the entity is detached
>>     myClass.setProducts(myNewList); // here i set the new list but no
>> matter what list of product i set to my entity the list of product remains
>> null, like if the list is like readonly
>>     myClass.getProducts().size();//i get a nullpointer here
>>
>> Example 2
>> 1. Get MyClass entity in a managedbean from and ejb (ejb use a query and
>> the products attribute contains N elements (IS NOT EMPTY OR NULL) because
>> is EAGER LOADING).
>> 2. inside of the managedbean try to set a new value for name
>> myClass.setName("new value);  //the value is refreshed from "old value" to
>> the new value "new value"
>> 3. inside of the managedbean try to clear the list of the entity you get an
>> exception
>>     myClass.getProducts().clear(); // here i get an exception "Result lists
>> are read only"
>>
>>
>> I cannot find anywhere in the specification like "results lists have to be
>> readonly and other values not".
>>
>> This is why i asked "the list values have to be immutables in an entity
>> even when the entity is detached?"
>>
>>
>> Then i ask again, why list are read only and any other value not?
>>
>>
>>
>>
>> 2013/10/22 Albert Lee 
>>
>> > String type is immutable, meaning if you are holding on a reference to
>> it,
>> > it will never be changed even it is "modified" since a new
>> object/reference
>> > will be created.
>> >
>> > List type is not immutable, regardless of if it is used in an JPA Entity,
>> > either managed or detached.
>> >
>> > Not sure exactly what you are looking for but an example may be helpful
>> > here.
>> >
>> >
>> >
>> > On Tue, Oct 22, 2013 at 9:27 AM, José Luis Cetina > > >wrote:
>> >
>> > > Hi, i want to know if the default openjpa behavior about list
>> attributes
>> > in
>> > > an entity
>> > >
>> > > When i retrieve and entity (that has list values) and detached it from
>> em
>> > > and then return (from ejb) to my web tier (jsf app), the list values
>> are
>> > > immutable but other object are mutables like strings, I cannot find in
>> > the
>> > > specification if this is the expected behavior, the list values have to
>> > be
>> > > immutables in an entity even when the entity is detached?
>> > >
>> > > Thanks
>> > >
>> >
>> >
>> >
>> > --
>> > Albert Lee.
>> >
>>
>>
>>
>> --
>> ---
>> *SCJA. José Luis Cetina*
>> ---
>>
>
>
>
>-- 
>*Rick Curtis*
>
>

Re: OpenJPA 2.3.0 Release

[Mark Struberg]

will try to find out what the underlying problem is.

LieGrue,
strub





>
> From: Rick Curtis 
>To: users  
>Cc: Mark Struberg  
>Sent: Friday, 4 October 2013, 16:24
>Subject: Re: OpenJPA 2.3.0 Release
> 
>
>Mark -
>
>I reopened OPENJPA-2171 yesterday as I think we need to get that
>straightened out before we cut another release. Please take a look if you
>get a chance.
>
>Thanks,
>Rick
>
>
>
>On Wed, Oct 2, 2013 at 9:11 AM, Kevin Sutter  wrote:
>
>> Hi Mark,
>> My original proposal [1] was to cut this OpenJPA 2.3.0 release and then do
>> JPA 2.1 in trunk.  Trunk would become 3.0.0-SNAPSHOT.  We do have an
>> existing JPA 2.1 sandbox, but we would merge the work that Pinaki has done
>> into trunk -- after we cut off the 2.3.0 release.  That would be the plan
>> anyway.
>>
>> Kevin
>>
>> [1]
>>
>> http://openjpa.208410.n2.nabble.com/JPA-2-1-Development-Kickoff-td7584933.html
>>
>>
>> On Wed, Oct 2, 2013 at 12:58 AM, Mark Struberg  wrote:
>>
>> > Well, actually the most important thing in this release is the ASM4 fix.
>> > I plan to do much more releases on a much tighter schedule. We should get
>> > out bugfixes much quicker imo.
>> >
>> > I suspect that JPA-2.1 work is done in a branch for now and will finally
>> > end up being a 3.0.x release, right?
>> > Just for me to understand how much work is done in which place...
>> >
>> > LieGrue,
>> > strub
>> >
>> >
>> >
>> >
>> > - Original Message -
>> > > From: Kevin Sutter 
>> > > To: users@openjpa.apache.org; Mark Struberg ;
>> > d...@openjpa.apache.org
>> > > Cc:
>> > > Sent: Monday, 30 September 2013, 18:31
>> > > Subject: Re: OpenJPA 2.3.0 Release
>> > >
>> > > I think we need to get this out to the dev community as well...  Have
>> you
>> > > done any triage on the existing JIRAs for any show-stoppers?
>> > >
>> > > Thanks,
>> > > Kevin
>> > >
>> > >
>> > > On Sat, Sep 28, 2013 at 7:22 AM, Mark Struberg 
>> > wrote:
>> > >
>> > >>  I've now created the 2.3.x branch for preparing the release.
>> > >>  If you find any showstoppers in trunk then please think about pinging
>> > me.
>> > >>
>> > >>  LieGrue,
>> > >>  strub
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>  - Original Message -
>> > >>  > From: Kevin Sutter 
>> > >>  > To: users@openjpa.apache.org; Mark Struberg 
>> > >>  > Cc:
>> > >>  > Sent: Monday, 23 September 2013, 14:57
>> > >>  > Subject: Re: OpenJPA 2.3.0 Release
>> > >>  >
>> > >>  >T hanks, Mark.
>> > >>  >
>> > >>  > Here's a starting point for our release process:
>> > >>  > http://openjpa.apache.org/release-management.html
>> > >>  >
>> > >>  > The steps you are interested in are under the Apache Nexus Release
>> > >>  > process:
>> > >>  >
>> > >>
>> >
>> http://openjpa.apache.org/apache-nexus-release-process-(1.2.x-2.1.x).html
>> > >>  >
>> > >>  > Good luck!  There are several people that have done Apache OpenJPA
>> > >>  releases
>> > >>  > recently, so hopefully you'll get the assistance you need.  But, I
>> > > do
>> > >>  know
>> > >>  > at least one of them is busy with JavaOne this week...
>> > >>  >
>> > >>  > Kevin
>> > >>  >
>> > >>  >
>> > >>  > On Sun, Sep 22, 2013 at 9:33 AM, Mark Struberg
>> > > 
>> > >>  wrote:
>> > >>  >
>> > >>  >>  I can kick off all the maven parts of the release.
>> > >>  >>
>> > >>  >>  I'm not sure what else do we need in terms of readme and JISA
>> > > release
>> > >>  >>  notes housekeeping?
>> > >>  >>  Is there a wiki page or any other documentation about it
>> > > somewhere?
>> > >>  >>
>> > >>  >>  From my experience as Release Manager in other Apache projects I
>> &

Re: OpenJPA 2.3.0 Release

[Mark Struberg]

Well, actually the most important thing in this release is the ASM4 fix.
I plan to do much more releases on a much tighter schedule. We should get out 
bugfixes much quicker imo.

I suspect that JPA-2.1 work is done in a branch for now and will finally end up 
being a 3.0.x release, right?
Just for me to understand how much work is done in which place...

LieGrue,
strub




- Original Message -
> From: Kevin Sutter 
> To: users@openjpa.apache.org; Mark Struberg ; 
> d...@openjpa.apache.org
> Cc: 
> Sent: Monday, 30 September 2013, 18:31
> Subject: Re: OpenJPA 2.3.0 Release
> 
> I think we need to get this out to the dev community as well...  Have you
> done any triage on the existing JIRAs for any show-stoppers?
> 
> Thanks,
> Kevin
> 
> 
> On Sat, Sep 28, 2013 at 7:22 AM, Mark Struberg  wrote:
> 
>>  I've now created the 2.3.x branch for preparing the release.
>>  If you find any showstoppers in trunk then please think about pinging me.
>> 
>>  LieGrue,
>>  strub
>> 
>> 
>> 
>> 
>>  - Original Message -
>>  > From: Kevin Sutter 
>>  > To: users@openjpa.apache.org; Mark Struberg 
>>  > Cc:
>>  > Sent: Monday, 23 September 2013, 14:57
>>  > Subject: Re: OpenJPA 2.3.0 Release
>>  >
>>  >T hanks, Mark.
>>  >
>>  > Here's a starting point for our release process:
>>  > http://openjpa.apache.org/release-management.html
>>  >
>>  > The steps you are interested in are under the Apache Nexus Release
>>  > process:
>>  >
>>  http://openjpa.apache.org/apache-nexus-release-process-(1.2.x-2.1.x).html
>>  >
>>  > Good luck!  There are several people that have done Apache OpenJPA
>>  releases
>>  > recently, so hopefully you'll get the assistance you need.  But, I 
> do
>>  know
>>  > at least one of them is busy with JavaOne this week...
>>  >
>>  > Kevin
>>  >
>>  >
>>  > On Sun, Sep 22, 2013 at 9:33 AM, Mark Struberg 
> 
>>  wrote:
>>  >
>>  >>  I can kick off all the maven parts of the release.
>>  >>
>>  >>  I'm not sure what else do we need in terms of readme and JISA 
> release
>>  >>  notes housekeeping?
>>  >>  Is there a wiki page or any other documentation about it 
> somewhere?
>>  >>
>>  >>  From my experience as Release Manager in other Apache projects I 
> would
>>  >>  have the following tasks on my TODO list. And some of them need
>>  community
>>  >>  involvement prior to starting the actual release process
>>  >>
>>  >>  * go through all open JIRA issues which have 2.3 as target 
> release.
>>  There
>>  >>  might be some of them which already got released. Then do the 
> same for
>>  all
>>  >>  open issues which show no apparent target version.
>>  >>  * Check all resolved issues and file them into release notes.
>>  >>  * pick some low hanging fruits in terms of open tasks and resolve 
> them
>>  if
>>  >>  possible.
>>  >>  * run the TCK. As the current 2.3.0-SNAPSHOT is daily run by the 
> TomEE
>>  >>  build, I assume this is already covered. Please not that while 
> I'm JCP
>>  >>  member, I have not yet filed any JPA TCK NDA. So I cannot check 
> this
>>  myself
>>  >>  * create a 2.3.x maintenance branch.
>>  >>
>>  >>  Any other tasks prior to firing up mvn release:prepare?
>>  >>
>>  >>
>>  >>  LieGrue,
>>  >>  strub
>>  >>
>>  >>
>>  >>
>>  >>
>>  >>  - Original Message -
>>  >>  > From: Kevin Sutter 
>>  >>  > To: users@openjpa.apache.org
>>  >>  > Cc:
>>  >>  > Sent: Saturday, 21 September 2013, 23:10
>>  >>  > Subject: Re: OpenJPA 2.3.0 Release
>>  >>  >
>>  >>  > Hi Matias,
>>  >>  > Yes, we have plans for a 2.3.0 release.  I just don't 
> know the
>>  > exact
>>  >>  dates
>>  >>  > yet.  We need to cut a "final" major release for 
> the JPA 2.0
>>  > level of
>>  >>  > functionality before we kick off the JPA 2.1 development 
> activities.
>>  > I'm
>>  >>  > drafting a note to solicit for volunteers for this 
> activity.  I would
>>  >>  hope
>>  >>  > that this 2.3.0 release could be something th

Re: Entitiy not enhanced

[Mark Struberg]

If you like to use build time enhancement and use Apache Maven, then I suggest 
to use the openjpa-maven-plugin.

You can find a sample usage of it here:

https://github.com/struberg/lightweightEE/blob/master/backend-api/pom.xml

I've also written a small blog post about how the different JPA strageties and 
enhancement work and some of the pros and cons of each approach [1]. I must 
admit that the deploy time enhancement got better in the meantime, but I still 
prefer build-time enhancement as it gives me consistent behaviour even in my 
tests (which you can use liberty or Apache TomEE for with either Arquillian or 
DeltaSpike CdiCtrl [2])

LieGrue,
strub


[1] http://struberg.wordpress.com/2012/01/08/jpa-enhancement-done-right/
[2] 
http://struberg.wordpress.com/2012/03/27/unit-testing-strategies-for-cdi-based-projects/



- Original Message -
> From: Leonardo K. Shikida 
> To: users@openjpa.apache.org
> Cc: d...@openjpa.apache.org
> Sent: Wednesday, 25 September 2013, 17:38
> Subject: Re: Entitiy not enhanced
> 
> Hi
> 
> I could not make the runtime enhancement work for me too, so I am manually
> enhancing during build time with a simple script.
> 
>     public static void main(String[] args) {
> 
>         Collection files = FileUtils.listFiles(new
> File(baseClassDir), null, true);
>         for(File file:files){
>             String[] a = new String[3];
>             a[0] = "-d";
>             a[1] = baseClassDir;
>             a[2] = file.getAbsolutePath();
>             org.apache.openjpa.enhance.PCEnhancer.main(a);
>         }
>     }
> 
> I've also noticed some strange behaviour using java 7, specifically, both
> IBM and Oracle JVM 7 didn't enhance the source code, but only Oracle
> crashed my tomEE+ server when that happened ;-)
> 
> Just in case...
> 
> good luck
> 
> Leo
> 
> 
> []
> 
> Leo
> 
> 
> On Wed, Sep 25, 2013 at 12:15 PM, Divya K Konoor 
> wrote:
> 
>> 
>> 
>>  Hi,
>> 
>>  I tried by manually adding the java agent in my jvm options  -javaagent:/
>>  apache-openjpa-2.2.2/lib/openjpa-all-2.2.2.jar following examples 5.2 and
>>  5.3 under section 2.3 at
>> 
>> 
> http://openjpa.apache.org/builds/2.1.1/apache-openjpa/docs/ref_guide_pc_enhance.html#ref_guide_pc_enhance_build
>>  .
>> 
>>   But even that hasn't helped .I still get the entity not enhanced 
> problem.
>> 
>>  Regards
>>  Divya
>> 
>> 
>> 
>>  From:   Divya K Konoor/India/IBM
>>  To:    users-h...@openjpa.apache.org, dev-h...@openjpa.apache.org,
>>  Date:   09/25/2013 07:19 PM
>>  Subject:        Entitiy not enhanced
>> 
>> 
>>  Hi,
>> 
>>  I use a container (Webshphere liberty that internally uses openjpa). I have
>>  multiple OSGi persistence bundles .Each has its own persistence unit ; all
>>  of these talk to the same database.The JPA entities bundled within each
>>  persistence bundle is defined under the  tag of 
> the
>>  persistence.xml. Some of these entities have relationship or dependency on
>>  the entities bundled with another persistence bundle in which case the
>>  dependent entities are added in the  tag of the former's
>>  persistence.xml
>> 
>>  I see the following error message when I start my liberty server:
>> 
>>  This configuration disallows runtime optimization, but the following listed
>>  types were not enhanced at build time or at class load time with a
>>  javaagent: "
>> 
>>  [err] 
>>  org.apache.openjpa.persistence.ArgumentException: The type "class
>>  com.xxx.ProbeConfiguration" has not been enhanced.
>>  [err]   at org.apache.openjpa.meta.ClassMetaData.resolveMeta
>>  (ClassMetaData.java:1827)
>>  [err]   at org.apache.openjpa.meta.ClassMetaData.resolve
>>  (ClassMetaData.java:1801)
>>  [err]   at org.apache.openjpa.meta.MetaDataRepository.processBuffer
>>  (MetaDataRepository.java:826)
>>  [err]   at org.apache.openjpa.meta.MetaDataRepository.resolveMeta
>>  (MetaDataRepository.java:723)
>>  [err]   at org.apache.openjpa.meta.MetaDataRepository.resolve
>>  (MetaDataRepository.java:647)
>>  [err]   at
>>  org.apache.openjpa.meta.MetaDataRepository.getMetaDataInternal
>>  (MetaDataRepository.java:415)
>>  [err]   at org.apache.openjpa.meta.MetaDataRepository.getMetaData
>>  (MetaDataRepository.java:388)
>>  [err]   at org.apache.openjpa.meta.MetaDataRepository.resolveAll
>>  (MetaDataRepository.java:1990)
>>  [err]   at
>>  org.apache.openjpa.meta.MetaDataRepository.getQueryMetaDataInternal
>>  (MetaDataRepository.java:1968)
>>  [err]   at org.apache.openjpa.meta.MetaDataRepository.getQueryMetaData
>>  (MetaDataRepository.java:1955)
>>  [err]   at
>>  org.apache.openjpa.persistence.EntityManagerImpl.createNamedQuery
>>  (EntityManagerImpl.java:102
>> 
>>  There is a brief mention of this here (but it doesn't explain why):
>> 
>> 
>> 
> http://pic.dhe.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=%2Fcom.ibm.websphere.ejbfep.multiplatform.doc%2Finfo%2Fae%2Fae%2Ftejb_jpatroubleshoot.html
>> 
>>  I was under the impression that openjpa does runtime enhancement on all JPA
>>  entities th

Re: OpenJPA 2.3.0 Release

[Mark Struberg]

I've now created the 2.3.x branch for preparing the release.
If you find any showstoppers in trunk then please think about pinging me.

LieGrue,
strub




- Original Message -
> From: Kevin Sutter 
> To: users@openjpa.apache.org; Mark Struberg 
> Cc: 
> Sent: Monday, 23 September 2013, 14:57
> Subject: Re: OpenJPA 2.3.0 Release
> 
>T hanks, Mark.
> 
> Here's a starting point for our release process:
> http://openjpa.apache.org/release-management.html
> 
> The steps you are interested in are under the Apache Nexus Release
> process:
> http://openjpa.apache.org/apache-nexus-release-process-(1.2.x-2.1.x).html
> 
> Good luck!  There are several people that have done Apache OpenJPA releases
> recently, so hopefully you'll get the assistance you need.  But, I do know
> at least one of them is busy with JavaOne this week...
> 
> Kevin
> 
> 
> On Sun, Sep 22, 2013 at 9:33 AM, Mark Struberg  wrote:
> 
>>  I can kick off all the maven parts of the release.
>> 
>>  I'm not sure what else do we need in terms of readme and JISA release
>>  notes housekeeping?
>>  Is there a wiki page or any other documentation about it somewhere?
>> 
>>  From my experience as Release Manager in other Apache projects I would
>>  have the following tasks on my TODO list. And some of them need community
>>  involvement prior to starting the actual release process
>> 
>>  * go through all open JIRA issues which have 2.3 as target release. There
>>  might be some of them which already got released. Then do the same for all
>>  open issues which show no apparent target version.
>>  * Check all resolved issues and file them into release notes.
>>  * pick some low hanging fruits in terms of open tasks and resolve them if
>>  possible.
>>  * run the TCK. As the current 2.3.0-SNAPSHOT is daily run by the TomEE
>>  build, I assume this is already covered. Please not that while I'm JCP
>>  member, I have not yet filed any JPA TCK NDA. So I cannot check this myself
>>  * create a 2.3.x maintenance branch.
>> 
>>  Any other tasks prior to firing up mvn release:prepare?
>> 
>> 
>>  LieGrue,
>>  strub
>> 
>> 
>> 
>> 
>>  - Original Message -
>>  > From: Kevin Sutter 
>>  > To: users@openjpa.apache.org
>>  > Cc:
>>  > Sent: Saturday, 21 September 2013, 23:10
>>  > Subject: Re: OpenJPA 2.3.0 Release
>>  >
>>  > Hi Matias,
>>  > Yes, we have plans for a 2.3.0 release.  I just don't know the 
> exact
>>  dates
>>  > yet.  We need to cut a "final" major release for the JPA 2.0 
> level of
>>  > functionality before we kick off the JPA 2.1 development activities.  
> I'm
>>  > drafting a note to solicit for volunteers for this activity.  I would
>>  hope
>>  > that this 2.3.0 release could be something that one of our committers
>>  could
>>  > pickup rather quickly...
>>  >
>>  > Kevin
>>  >
>>  >
>>  > On Mon, Aug 26, 2013 at 1:12 PM, Matias G
>>  > wrote:
>>  >
>>  >>  Hi,
>>  >>
>>  >>  I was wondering if anyone knows whether the 2.3.0 is planned and 
> what
>>  would
>>  >>  the expected timeframe for that? I am very interested in the fix 
> for
>>  one
>>  >>  particular issue 
> (https://issues.apache.org/jira/browse/OPENJPA-2318)
>>  >>  which
>>  >>  was solved just a few days ago.
>>  >>
>>  >>  I upgraded to 2.3.0-SNAPSHOT and it works for me, but would find 
> it
>>  really
>>  >>  helpful to know if there is a final release planned so I can in 
> turn
>>  plan
>>  >>  in advance for how long I could expect to keep using snapshot 
> versions.
>>  >>
>>  >>  I looked at previous release dates and found they've happened
>>  >>  February-November-April, so I don't know if the next one 
> would be
>>  > happening
>>  >>  this year. In my search through the site I could not find info on
>>  future
>>  >>  releases.
>>  >>
>>  >>  If anyone can point me to the right resource/person/information, 
> many
>>  >>  thanks.
>>  >>
>>  >>  Matias
>>  >>
>>  >
>> 
>

Re: OpenJPA 2.3.0 Release

[Mark Struberg]

I can kick off all the maven parts of the release. 

I'm not sure what else do we need in terms of readme and JISA release notes 
housekeeping?
Is there a wiki page or any other documentation about it somewhere?

From my experience as Release Manager in other Apache projects I would have the 
following tasks on my TODO list. And some of them need community involvement 
prior to starting the actual release process

* go through all open JIRA issues which have 2.3 as target release. There might 
be some of them which already got released. Then do the same for all open 
issues which show no apparent target version.
* Check all resolved issues and file them into release notes.
* pick some low hanging fruits in terms of open tasks and resolve them if 
possible.
* run the TCK. As the current 2.3.0-SNAPSHOT is daily run by the TomEE build, I 
assume this is already covered. Please not that while I'm JCP member, I have 
not yet filed any JPA TCK NDA. So I cannot check this myself
* create a 2.3.x maintenance branch.

Any other tasks prior to firing up mvn release:prepare?


LieGrue,
strub




- Original Message -
> From: Kevin Sutter 
> To: users@openjpa.apache.org
> Cc: 
> Sent: Saturday, 21 September 2013, 23:10
> Subject: Re: OpenJPA 2.3.0 Release
> 
> Hi Matias,
> Yes, we have plans for a 2.3.0 release.  I just don't know the exact dates
> yet.  We need to cut a "final" major release for the JPA 2.0 level of
> functionality before we kick off the JPA 2.1 development activities.  I'm
> drafting a note to solicit for volunteers for this activity.  I would hope
> that this 2.3.0 release could be something that one of our committers could
> pickup rather quickly...
> 
> Kevin
> 
> 
> On Mon, Aug 26, 2013 at 1:12 PM, Matias G 
> wrote:
> 
>>  Hi,
>> 
>>  I was wondering if anyone knows whether the 2.3.0 is planned and what would
>>  the expected timeframe for that? I am very interested in the fix for one
>>  particular issue (https://issues.apache.org/jira/browse/OPENJPA-2318)
>>  which
>>  was solved just a few days ago.
>> 
>>  I upgraded to 2.3.0-SNAPSHOT and it works for me, but would find it really
>>  helpful to know if there is a final release planned so I can in turn plan
>>  in advance for how long I could expect to keep using snapshot versions.
>> 
>>  I looked at previous release dates and found they've happened
>>  February-November-April, so I don't know if the next one would be 
> happening
>>  this year. In my search through the site I could not find info on future
>>  releases.
>> 
>>  If anyone can point me to the right resource/person/information, many
>>  thanks.
>> 
>>  Matias
>> 
>

Re: Why is parent version incremented on update of child entity?

[Mark Struberg]

This happens most times if you have Cascade.PERSIST enabled. This makes your 
1:n list a 'part' of your 'main entity'. The idea is that once you change a 
part of your logical area you need to prevent concurring changes on the whole 
area. Otherwise consistency cannot get guaranteed. Thus a touch on the 'main 
entity' gets performed to ensure an OptimisticLockingException in case someone 
else tries to change the 'logic area' at the same time. 

Think about a Customer with 1:n Address entries. Imagine what would happen if 2 
independent users would add the same address? This would not result in a db 
constraint error but still the logical consistency of the Customer entry would 
be broken! By touching the parent entity this can be detected and would lead to 
optimistic locking.

LieGrue,
strub




- Original Message -
> From: mwalter 
> To: users@openjpa.apache.org
> Cc: 
> Sent: Monday, December 10, 2012 4:40 PM
> Subject: Why is parent version incremented on update of child entity?
> 
> I found out that on update of a child entity the parent version field is
> incremented as well. Is this default behaviour? Is it possible to change the
> increment strategy somehow so that the parent version does not change?
> 
> I'm using OpenJPA 1.2.3 (WebSphere V7), LockManager is set to 
> "version".
> 
> Thanks for any help and/or explanation!
> 
> 
> 
> --
> View this message in context: 
> http://openjpa.208410.n2.nabble.com/Why-is-parent-version-incremented-on-update-of-child-entity-tp7582115.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> 

Re: maven-openjpa-plugin ClassLoader issues?

[Mark Struberg]

No, this works perfectly over here. You do not need to add any dependency at 
all!
The only stuff I had to add is cobertura if you use code coverage reporting. 
The reason is that cobertura enhances the classes with it's own interceptors 
and openjpa fails to enhance if it cannot find those classes.

LieGrue,
strub




- Original Message -
> From: andyatmiami 
> To: users@openjpa.apache.org
> Cc: 
> Sent: Thursday, August 30, 2012 7:46 PM
> Subject: Re: maven-openjpa-plugin ClassLoader issues?
> 
> I guess my issue is that behavior is NOT happening - the compile classpath is
> NOT being added to the plugin - and I have to manually add all dependencies.
> 
> Has anyone heard of this happening?
> 
> 
> 
> --
> View this message in context: 
> http://openjpa.208410.n2.nabble.com/maven-openjpa-plugin-ClassLoader-issues-tp7580984p7580987.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>