Nabble - OpenJPA Developers

[jira] [Updated] (OPENJPA-2387) Schema name is incorrectly included in length of Sequence name.

2013-05-24T09:58:20Z

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

Heath Thomann updated OPENJPA-2387:
-----------------------------------

Attachment: OPENJPA-2387-2.2.1.x.patch

Providing a patch to resolve the issue.

Thanks,

Heath

> Schema name is incorrectly included in length of Sequence name.
> ---------------------------------------------------------------
>
> Key: OPENJPA-2387
> URL: https://issues.apache.org/jira/browse/OPENJPA-2387
> Project: OpenJPA
> Issue Type: Bug
> Components: sql
> Affects Versions: 2.3.0, 2.2.2, 2.2.1.1
> Reporter: Heath Thomann
> Assignee: Heath Thomann
> Attachments: OPENJPA-2387-2.2.1.x.patch
>
>
> Take the following entity definition:
> @Entity @Table(name="LONG_NAME_ENTITY")
> @SequenceGenerator(name="longSequenceNameSequence",sequenceName="A_TWENTY_NINE_CHAR_LENGTH_SEQ")
> public class LongSequenceNameEntity implements Serializable
> As can be seen, a Sequence is defined with a name which is 29 characters long. On a Database such as Oracle which has a 30 character limit on sequence names, among others names, this sequence is perfectly legal. However, when a schema name is tacked onto this by OpenJPA, OpenJPA code incorrectly counts the characters of the schema in the length of the sequence name. As such, the following exception will occur:
> Caused by: <openjpa-2.2.1.1-SNAPSHOT-r422266:1445654M nonfatal user error> org.apache.openjpa.persistence.ArgumentException: Sequence name "HTHOMANN.A_TWENTY_NINE_CHAR_LENGTH_SEQ" is 38-character long. The database allows maximum 30-character for a sequence name.
> at org.apache.openjpa.jdbc.sql.DBDictionary.checkNameLength(DBDictionary.java:5358)
> at org.apache.openjpa.jdbc.sql.DBDictionary.commonCreateAlterSequenceSQL(DBDictionary.java:3492)
> at org.apache.openjpa.jdbc.sql.DBDictionary.getAlterSequenceSQL(DBDictionary.java:3469)
> The DBDictionary.checkNameLength in this case is counting the characters of the schema name, and sequence name. The length of the schema name should not be included in the length of the sequence.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OPENJPA-2387) Schema name is incorrectly included in length of Sequence name.

2013-05-24T09:56:19Z

> Schema name is incorrectly included in length of Sequence name.
> ---------------------------------------------------------------
>
> Key: OPENJPA-2387
> URL: https://issues.apache.org/jira/browse/OPENJPA-2387
> Project: OpenJPA
> Issue Type: Bug
> Components: sql
> Affects Versions: 2.3.0, 2.2.2, 2.2.1.1
> Reporter: Heath Thomann
> Assignee: Heath Thomann
>
> Take the following entity definition:
> @Entity @Table(name="LONG_NAME_ENTITY")
> @SequenceGenerator(name="longSequenceNameSequence",sequenceName="A_TWENTY_NINE_CHAR_LENGTH_SEQ")
> public class LongSequenceNameEntity implements Serializable
> As can be seen, a Sequence is defined with a name which is 29 characters long. On a Database such as Oracle which has a 30 character limit on sequence names, among others names, this sequence is perfectly legal. However, when a schema name is tacked onto this by OpenJPA, OpenJPA code incorrectly counts the characters of the schema in the length of the sequence name. As such, the following exception will occur:
> Caused by: <openjpa-2.2.1.1-SNAPSHOT-r422266:1445654M nonfatal user error> org.apache.openjpa.persistence.ArgumentException: Sequence name "HTHOMANN.A_TWENTY_NINE_CHAR_LENGTH_SEQ" is 38-character long. The database allows maximum 30-character for a sequence name.
> at org.apache.openjpa.jdbc.sql.DBDictionary.checkNameLength(DBDictionary.java:5358)
> at org.apache.openjpa.jdbc.sql.DBDictionary.commonCreateAlterSequenceSQL(DBDictionary.java:3492)
> at org.apache.openjpa.jdbc.sql.DBDictionary.getAlterSequenceSQL(DBDictionary.java:3469)
> The DBDictionary.checkNameLength in this case is counting the characters of the schema name, and sequence name. The length of the schema name should not be included in the length of the sequence.

[jira] [Created] (OPENJPA-2387) Schema name is incorrectly included in length of Sequence name.

2013-05-24T09:38:20Z

Heath Thomann created OPENJPA-2387:
--------------------------------------

Summary: Schema name is incorrectly included in length of Sequence name.
Key: OPENJPA-2387
URL: https://issues.apache.org/jira/browse/OPENJPA-2387
Project: OpenJPA
Issue Type: Bug
Components: sql
Affects Versions: 2.2.2, 2.3.0, 2.2.1.1
Reporter: Heath Thomann
Assignee: Heath Thomann

Take the following entity definition:

@Entity @Table(name="LONG_NAME_ENTITY")
@SequenceGenerator(name="longSequenceNameSequence",sequenceName="A_TWENTY_NINE_CHAR_LENGTH_SEQ")
public class LongSequenceNameEntity implements Serializable

As can be seen, a Sequence is defined with a name which is 29 characters long. On a Database such as Oracle which has a 30 character limit on sequence names, among others names, this sequence is perfectly legal. However, when a schema name is tacked onto this by OpenJPA, OpenJPA code incorrectly counts the characters of the schema in the length of the sequence name. As such, the following exception will occur:

Caused by: <openjpa-2.2.1.1-SNAPSHOT-r422266:1445654M nonfatal user error> org.apache.openjpa.persistence.ArgumentException: Sequence name "HTHOMANN.A_TWENTY_NINE_CHAR_LENGTH_SEQ" is 38-character long. The database allows maximum 30-character for a sequence name.
at org.apache.openjpa.jdbc.sql.DBDictionary.checkNameLength(DBDictionary.java:5358)
at org.apache.openjpa.jdbc.sql.DBDictionary.commonCreateAlterSequenceSQL(DBDictionary.java:3492)
at org.apache.openjpa.jdbc.sql.DBDictionary.getAlterSequenceSQL(DBDictionary.java:3469)

The DBDictionary.checkNameLength in this case is counting the characters of the schema name, and sequence name. The length of the schema name should not be included in the length of the sequence.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: differents constraints?

2013-05-23T12:50:47Z

> Ignoring our old constraints we are all green.

Not sure I follow. Who or what is ignoring the old constraints? And,
whatever process this is, you are green with the 2.3.0-SNAPSHOT?

> The diff between both generation are constraints which are not exactly
the
same (one got a derby "reference" in the constraint where the other
generation ignored it)

Sorry, I'm not following this either, Romain. Can you narrow down the EJB3
test to produce the issue? I'm just now following what changed where and
what's not working with 2.3.0-SNAPSHOT.

Thanks, Kevin

On Thu, May 23, 2013 at 9:05 AM, Romain Manni-Bucau
<[hidden email]>wrote:

> that's an ejb 3 test playing with derived id. We kept the database used
> with openjpa 2.2.0 upgrading the library to 2.3.0-SNAPSHOT and saw the
> failure at this moment.
>
> Ignoring our old constraints we are all green.
>
> The diff between both generation are constraints which are not exactly the
> same (one got a derby "reference" in the constraint where the other
> generation ignored it)
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>
>
>
> 2013/5/23 Kevin Sutter <[hidden email]>
>
> > Hi Romain,
> > Nothing is jumping out at me... What "TomEE TCK" are you referring to?
> We
> > run the JPA 2.0 TCK on every branch (including trunk) and the logs are
> all
> > clean as of May 21. (It looks like there was a comm problem with
> > communicating with svn last night, so that TCK run didn't kick off.)
> >
> > You also indicated that the ddl for altering the table constraints didn't
> > get generated with trunk? I'm not aware of any changes in our mapping
> tool
> > that would have changed that behavior. Are you starting with a fresh
> > database? Or, are you running with the same derby database that was used
> > for the 2.2.0 run?
> >
> > We'll probably need more investigation on what exactly is different
> between
> > your 2.2.0 test runs and the trunk test runs.
> >
> > Thanks,
> > Kevin
> >
> >
> > On Thu, May 23, 2013 at 7:14 AM, Romain Manni-Bucau
> > <[hidden email]>wrote:
> >
> > > Hi guys,
> > >
> > > on TomEE TCKs we were used to get some SQL constraints on a derby
> > database
> > > like:
> > >
> > > ALTER TABLE A ADD CONSTRAINT C FOREIGN KEY (ID) REFERENCES B (ID);
> > >
> > > or the almost same with composed keys (string, string).
> > >
> > > Basically all was green with openjpa 2.2.0 but since openjpa
> > 2.3.0-SNAPSHOT
> > > we get exceptions because of these constraints. Moreover the ddl
> doesn't
> > > generate them.
> > >
> > > Here the exception:
> > >
> > > Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: DELETE on
> > > table 'X' caused a violation of foreign key constraint 'C' for key
> > > (aaa,bbb). The statement has been rolled back. {prepstmnt 450145810
> > DELETE
> > > FROM X WHERE KEY1 = ? AND KEY2 = ?} [code=-1, state=23503]
> > > at
> > >
> > >
> >
> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:219)
> > > at
> > >
> > >
> >
> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:195)
> > > at
> > >
> > >
> >
> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$1000(LoggingConnectionDecorator.java:59)
> > > at
> > >
> > >
> >
> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeUpdate(LoggingConnectionDecorator.java:1134)
> > > at
> > >
> > >
> >
> org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:275)
> > > at
> > >
> > >
> >
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement.executeUpdate(JDBCStoreManager.java:1792)
> > > at
> > >
> > >
> >
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.executeUpdate(PreparedStatementManagerImpl.java:268)
> > > at
> > >
> > >
> >
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:119)
> > >
> > >
> > > Anything known changed? Is it a regression?
> > >
> > > *Romain Manni-Bucau*
> > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > > *Blog: **http://rmannibucau.wordpress.com/*<
> > > http://rmannibucau.wordpress.com/>
> > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > *Github: https://github.com/rmannibucau*
> > >
> >
>

[jira] [Created] (OPENJPA-2386) Support for JAVA 8

2013-05-23T09:06:20Z

Kevin Sutter created OPENJPA-2386:
-------------------------------------

Summary: Support for JAVA 8
Key: OPENJPA-2386
URL: https://issues.apache.org/jira/browse/OPENJPA-2386
Project: OpenJPA
Issue Type: Improvement
Components: build / infrastructure, Enhance, jpa
Affects Versions: 2.3.0
Reporter: Kevin Sutter

A few different aspects exist for the support of Java 8. The first being tolerance of the Java 8 runtime. If OpenJPA and the application are built and enhanced with Java 7 (or Java 6), then will these class files execute in a Java 8 environment? My assumption is "yes" since this would be consistent with our initial experiences with Java 7. But, some testing will be required to verify this.

The next aspect is the building of the application Entities with Java 8. Building and enhancing Java Entity class files with Java 8 looks to be hazardous... The first indication is that ASM doesn't seem to handle the Java 8 class file format. And, if ASM doesn't handle it, then I'm sure that Serp doesn't handle it either. Now, whether our use of ASM as a post-processor for Serp will suffice this time around, I have no idea.

This brings back the question of dropping Serp support altogether and going the ASM route (http://openjpa.208410.n2.nabble.com/DISCUSS-Java7-and-Serp-td6951682.html). I know there's been some interest in this in the past.

A longer-term aspect is when do we actually build OpenJPA with Java 8 and take advantage (exploit) of the new features. I think we have a long ways before we have to cross that hurdle. When we start developing JPA 2.1, we'll probably have to upgrade our build process to use Java 7. So, we're probably on the same type of cycle for Java 8 for building OpenJPA (when it's required by Java EE 8).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: differents constraints?

2013-05-23T07:05:11Z

that's an ejb 3 test playing with derived id. We kept the database used
with openjpa 2.2.0 upgrading the library to 2.3.0-SNAPSHOT and saw the
failure at this moment.

Ignoring our old constraints we are all green.

The diff between both generation are constraints which are not exactly the
same (one got a derby "reference" in the constraint where the other
generation ignored it)

*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*

2013/5/23 Kevin Sutter <[hidden email]>

> Hi Romain,
> Nothing is jumping out at me... What "TomEE TCK" are you referring to? We
> run the JPA 2.0 TCK on every branch (including trunk) and the logs are all
> clean as of May 21. (It looks like there was a comm problem with
> communicating with svn last night, so that TCK run didn't kick off.)
>
> You also indicated that the ddl for altering the table constraints didn't
> get generated with trunk? I'm not aware of any changes in our mapping tool
> that would have changed that behavior. Are you starting with a fresh
> database? Or, are you running with the same derby database that was used
> for the 2.2.0 run?
>
> We'll probably need more investigation on what exactly is different between
> your 2.2.0 test runs and the trunk test runs.
>
> Thanks,
> Kevin
>
>
> On Thu, May 23, 2013 at 7:14 AM, Romain Manni-Bucau
> <[hidden email]>wrote:
>
> > Hi guys,
> >
> > on TomEE TCKs we were used to get some SQL constraints on a derby
> database
> > like:
> >
> > ALTER TABLE A ADD CONSTRAINT C FOREIGN KEY (ID) REFERENCES B (ID);
> >
> > or the almost same with composed keys (string, string).
> >
> > Basically all was green with openjpa 2.2.0 but since openjpa
> 2.3.0-SNAPSHOT
> > we get exceptions because of these constraints. Moreover the ddl doesn't
> > generate them.
> >
> > Here the exception:
> >
> > Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: DELETE on
> > table 'X' caused a violation of foreign key constraint 'C' for key
> > (aaa,bbb). The statement has been rolled back. {prepstmnt 450145810
> DELETE
> > FROM X WHERE KEY1 = ? AND KEY2 = ?} [code=-1, state=23503]
> > at
> >
> >
> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:219)
> > at
> >
> >
> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:195)
> > at
> >
> >
> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$1000(LoggingConnectionDecorator.java:59)
> > at
> >
> >
> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeUpdate(LoggingConnectionDecorator.java:1134)
> > at
> >
> >
> org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:275)
> > at
> >
> >
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement.executeUpdate(JDBCStoreManager.java:1792)
> > at
> >
> >
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.executeUpdate(PreparedStatementManagerImpl.java:268)
> > at
> >
> >
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:119)
> >
> >
> > Anything known changed? Is it a regression?
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
>

Re: differents constraints?

2013-05-23T06:55:29Z

Hi Romain,
Nothing is jumping out at me... What "TomEE TCK" are you referring to? We
run the JPA 2.0 TCK on every branch (including trunk) and the logs are all
clean as of May 21. (It looks like there was a comm problem with
communicating with svn last night, so that TCK run didn't kick off.)

You also indicated that the ddl for altering the table constraints didn't
get generated with trunk? I'm not aware of any changes in our mapping tool
that would have changed that behavior. Are you starting with a fresh
database? Or, are you running with the same derby database that was used
for the 2.2.0 run?

We'll probably need more investigation on what exactly is different between
your 2.2.0 test runs and the trunk test runs.

Thanks,
Kevin

On Thu, May 23, 2013 at 7:14 AM, Romain Manni-Bucau
<[hidden email]>wrote:

> Hi guys,
>
> on TomEE TCKs we were used to get some SQL constraints on a derby database
> like:
>
> ALTER TABLE A ADD CONSTRAINT C FOREIGN KEY (ID) REFERENCES B (ID);
>
> or the almost same with composed keys (string, string).
>
> Basically all was green with openjpa 2.2.0 but since openjpa 2.3.0-SNAPSHOT
> we get exceptions because of these constraints. Moreover the ddl doesn't
> generate them.
>
> Here the exception:
>
> Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: DELETE on
> table 'X' caused a violation of foreign key constraint 'C' for key
> (aaa,bbb). The statement has been rolled back. {prepstmnt 450145810 DELETE
> FROM X WHERE KEY1 = ? AND KEY2 = ?} [code=-1, state=23503]
> at
>
> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:219)
> at
>
> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:195)
> at
>
> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$1000(LoggingConnectionDecorator.java:59)
> at
>
> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeUpdate(LoggingConnectionDecorator.java:1134)
> at
>
> org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:275)
> at
>
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement.executeUpdate(JDBCStoreManager.java:1792)
> at
>
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.executeUpdate(PreparedStatementManagerImpl.java:268)
> at
>
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:119)
>
>
> Anything known changed? Is it a regression?
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>

[jira] [Closed] (OPENJPA-2385) PrePersist/PreUpdate not invoked

2013-05-23T06:25:21Z

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

Guillaume Chauvet closed OPENJPA-2385.
--------------------------------------

Resolution: Not A Problem

I found my error for this unitary test : just remove "final" to the @PrePersist method....

> PrePersist/PreUpdate not invoked
> --------------------------------
>
> Key: OPENJPA-2385
> URL: https://issues.apache.org/jira/browse/OPENJPA-2385
> Project: OpenJPA
> Issue Type: Bug
> Affects Versions: 2.2.0, 2.2.1, 2.2.2, 2.2.3
> Reporter: Guillaume Chauvet
> Attachments: OPENJPA-2385.zip
>
>
> In the OpenJPA user manual, section 3.1 " Callback Methods" we read this :
> PrePersist: Methods marked with this annotation will be invoked before an object is persisted. This could be used for assigning primary key values to persistent objects. This is equivalent to the XML element tag pre-persist.
> But this is not the behavior obtained.

differents constraints?

2013-05-23T05:14:43Z

Hi guys,

on TomEE TCKs we were used to get some SQL constraints on a derby database
like:

ALTER TABLE A ADD CONSTRAINT C FOREIGN KEY (ID) REFERENCES B (ID);

or the almost same with composed keys (string, string).

Basically all was green with openjpa 2.2.0 but since openjpa 2.3.0-SNAPSHOT
we get exceptions because of these constraints. Moreover the ddl doesn't
generate them.

Here the exception:

Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: DELETE on
table 'X' caused a violation of foreign key constraint 'C' for key
(aaa,bbb). The statement has been rolled back. {prepstmnt 450145810 DELETE
FROM X WHERE KEY1 = ? AND KEY2 = ?} [code=-1, state=23503]
at
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:219)
at
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:195)
at
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$1000(LoggingConnectionDecorator.java:59)
at
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeUpdate(LoggingConnectionDecorator.java:1134)
at
org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:275)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement.executeUpdate(JDBCStoreManager.java:1792)
at
org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.executeUpdate(PreparedStatementManagerImpl.java:268)
at
org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:119)

Anything known changed? Is it a regression?

*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*

[jira] [Updated] (OPENJPA-2385) PrePersist/PreUpdate not invoked

2013-05-23T02:51:19Z

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

Guillaume Chauvet updated OPENJPA-2385:
---------------------------------------

Attachment: OPENJPA-2385.zip

Attached, please find a unitary test that reproduce the issue.

[jira] [Created] (OPENJPA-2385) PrePersist/PreUpdate not invoked

2013-05-23T02:31:20Z

Guillaume Chauvet created OPENJPA-2385:
------------------------------------------

Summary: PrePersist/PreUpdate not invoked
Key: OPENJPA-2385
URL: https://issues.apache.org/jira/browse/OPENJPA-2385
Project: OpenJPA
Issue Type: Bug
Affects Versions: 2.2.2, 2.2.1, 2.2.0, 2.2.3
Reporter: Guillaume Chauvet

In the OpenJPA user manual, section 3.1 " Callback Methods" we read this :
PrePersist: Methods marked with this annotation will be invoked before an object is persisted. This could be used for assigning primary key values to persistent objects. This is equivalent to the XML element tag pre-persist.

But this is not the behavior obtained.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OPENJPA-2384) Rendering criteria query to JPQL-like string ignores multiple GROUP BY clauses

2013-05-22T10:43:20Z

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

Pinaki Poddar resolved OPENJPA-2384.
------------------------------------

Resolution: Fixed

see revision r1456576 (that was not referred to an issue).

> Rendering criteria query to JPQL-like string ignores multiple GROUP BY clauses
> ------------------------------------------------------------------------------
>
> Key: OPENJPA-2384
> URL: https://issues.apache.org/jira/browse/OPENJPA-2384
> Project: OpenJPA
> Issue Type: Bug
> Reporter: Pinaki Poddar
> Assignee: Pinaki Poddar
> Priority: Minor
> Fix For: 2.3.0
>
>

[jira] [Commented] (OPENJPA-2384) Rendering criteria query to JPQL-like string ignores multiple GROUP BY clauses

2013-05-22T10:41:28Z

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

Pinaki Poddar commented on OPENJPA-2384:
----------------------------------------

this issue was fixed with following revision without a JIRA.

r1456576 | ppoddar | 2013-03-14 10:59:17 -0700 (Thu, 14 Mar 2013) | 1 line

Simple change to stringify a collection of values with proper spaces

[jira] [Created] (OPENJPA-2384) Rendering criteria query to JPQL-like string ignores multiple GROUP BY clauses

2013-05-22T10:41:20Z

Pinaki Poddar created OPENJPA-2384:
--------------------------------------

Summary: Rendering criteria query to JPQL-like string ignores multiple GROUP BY clauses
Key: OPENJPA-2384
URL: https://issues.apache.org/jira/browse/OPENJPA-2384
Project: OpenJPA
Issue Type: Bug
Reporter: Pinaki Poddar
Assignee: Pinaki Poddar
Priority: Minor
Fix For: 2.3.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: release 2.3.x

2013-05-22T09:06:35Z

no since it was fixed on trunk

*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*

2013/5/22 Pinaki Poddar <[hidden email]>

> > the criteria api bug where only a single groupby or having was used (", "
> was missing when the jpql was created)
>
> did you file a JIRA?
>
>
>
> -----
> Pinaki Poddar
> Chair, Apache OpenJPA Project
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/release-2-3-x-tp7583967p7583996.html
> Sent from the OpenJPA Developers mailing list archive at Nabble.com.
>

Re: release 2.3.x

2013-05-22T09:04:07Z

> the criteria api bug where only a single groupby or having was used (", " was missing when the jpql was created)

did you file a JIRA?

Pinaki Poddar
Chair, Apache OpenJPA Project

[jira] [Commented] (OPENJPA-2373) MapsId in a Child entity to a Parent entity using auto-assigned identity fails with duplicte INSERT SQL

2013-05-21T16:44:20Z

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

ASF subversion and git services commented on OPENJPA-2373:
----------------------------------------------------------

Commit 1485013 from hthomann
[ https://svn.apache.org/r1485013 ]

OPENJPA-2373: Made a test case update given identity auto generated ids do not work so well for some databases.

> MapsId in a Child entity to a Parent entity using auto-assigned identity fails with duplicte INSERT SQL
> --------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-2373
> URL: https://issues.apache.org/jira/browse/OPENJPA-2373
> Project: OpenJPA
> Issue Type: Bug
> Affects Versions: 2.0.0, 2.0.1, 2.1.1, 2.2.1
> Reporter: Pinaki Poddar
> Assignee: Pinaki Poddar
> Fix For: 2.3.0
>
> Attachments: graycol.gif
>
>
> A MapsId annotation in entity C (child) annotates a field p of type P (parent). P uses auto-generated identity.
> P-C is a bidirectional parent-child relationship.
>
> During flush sequence, A row is created for P and flushed for the database to assign an identity. When C is flushed, it wrongly creates a row for P again while handling the field p that points to parent.
> Of course, the commit breaks with a DuplicateKeyException on P's table.

[jira] [Commented] (OPENJPA-2373) MapsId in a Child entity to a Parent entity using auto-assigned identity fails with duplicte INSERT SQL

2013-05-21T16:40:21Z

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

ASF subversion and git services commented on OPENJPA-2373:
----------------------------------------------------------

Commit 1485012 from hthomann
[ https://svn.apache.org/r1485012 ]

OPENJPA-2373: Made a test case update given identity auto generated ids do not work so well for some databases.

[jira] [Commented] (OPENJPA-2373) MapsId in a Child entity to a Parent entity using auto-assigned identity fails with duplicte INSERT SQL

2013-05-21T16:28:20Z

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

ASF subversion and git services commented on OPENJPA-2373:
----------------------------------------------------------

Commit 1485011 from hthomann
[ https://svn.apache.org/r1485011 ]

OPENJPA-2373: Made a test case update given identity auto generated ids do not work so well for some databases.

[jira] [Commented] (OPENJPA-2373) MapsId in a Child entity to a Parent entity using auto-assigned identity fails with duplicte INSERT SQL

2013-05-21T16:24:21Z

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

ASF subversion and git services commented on OPENJPA-2373:
----------------------------------------------------------

Commit 1485010 from hthomann
[ https://svn.apache.org/r1485010 ]

OPENJPA-2373: Made a test case update given identity auto generated ids do not work so well for some databases.

Re: release 2.3.x

2013-05-21T06:23:36Z

that's this commit
https://mail-archives.apache.org/mod_mbox/openjpa-commits/201303.mbox/%3C20130314175917.E7B1823888E7@...%3E

no idea if a jira is linked or not :(

*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*

2013/5/21 Kevin Sutter <[hidden email]>

> HI Romain,
> Sorry, I'm a little slow this morning... :-)
>
> "Should be the same..." Same as what? The JIRA I found related to the
> Criteria API and GroupBy processing was still open with no commits to trunk
> or any other release. So, that JIRA didn't fix your issue... Do you know
> if there was a specific JIRA for this issue? Or, was it a case that you
> just ran into this issue, tried it on trunk, and the problem no longer
> existed? If that's the case, then I'll probably need more detail from you
> on the specific scenario you were running so that we might narrow down
> which JIRA helped you for this particular case.
>
> Thanks again,
> Kevin
>
>
> On Mon, May 20, 2013 at 2:25 PM, Romain Manni-Bucau
> <[hidden email]>wrote:
>
> > Should be the same, i got the issue on an app and checked out trunk and
> saw
> > it was fixed.
> > Le 20 mai 2013 21:24, "Kevin Sutter" <[hidden email]> a écrit :
> >
> > > Romain,
> > > I guess I wasn't clairvoyant... :-) The ASM one was easy to find.
> But,
> > > the one I was thinking of for the Criteria bug is still open, so I
> doubt
> > > that's the one you were referring to. Can you look up the JIRA you
> were
> > > referring to? Thanks!
> > >
> > > Kevin
> > >
> > >
> > > On Mon, May 20, 2013 at 12:54 PM, Kevin Sutter <[hidden email]>
> > wrote:
> > >
> > > > Thanks, Romain. I am familiar with the items you referenced.
> > > >
> > > >
> > > > On Mon, May 20, 2013 at 12:44 PM, Romain Manni-Bucau <
> > > > [hidden email]> wrote:
> > > >
> > > >> basically 2 features (if you need jira number just ask i'll try to
> > find
> > > >> them back):
> > > >>
> > > >> - ASM "facade" to be able to use xbean asm shade instead of asm.jar
> > > >> (blocking for tomee if not in the box)
> > > >> - the criteria api bug where only a single groupby or having was
> used
> > > (",
> > > >> "
> > > >> was missing when the jpql was created)
> > > >>
> > > >> *Romain Manni-Bucau*
> > > >> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > > >> *Blog: **http://rmannibucau.wordpress.com/*<
> > > >> http://rmannibucau.wordpress.com/>
> > > >> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > >> *Github: https://github.com/rmannibucau*
> > > >>
> > > >>
> > > >>
> > > >> 2013/5/20 Kevin Sutter <[hidden email]>
> > > >>
> > > >> > Hi Romain,
> > > >> > We currently don't have any plans for cutting a 2.3.0 release...
> A
> > > few
> > > >> of
> > > >> > us actually discussed it a couple of weeks back, but we didn't
> come
> > up
> > > >> with
> > > >> > enough "features" to warrant a 2.3.0 release. Do you have a list
> of
> > > the
> > > >> > JIRAs that you have an interest in?
> > > >> >
> > > >> > If there are other users of trunk that would like to see a 2.3.0
> > > >> release,
> > > >> > please voice your interest.
> > > >> >
> > > >> > Thanks,
> > > >> > Kevin
> > > >> >
> > > >> >
> > > >> > On Mon, May 20, 2013 at 9:50 AM, Romain Manni-Bucau
> > > >> > <[hidden email]>wrote:
> > > >> >
> > > >> > > Hi guys,
> > > >> > >
> > > >> > > any plan to release 2.3.0?
> > > >> > >
> > > >> > > basically i'd like to get rid of openejb shade for next tomee
> > > release
> > > >> > (and
> > > >> > > some other fixes in 2.3.x would be great to integrate).
> > > >> > >
> > > >> > > I updated tomee snapshot to use the openjpa snapshot to see if
> we
> > > have
> > > >> > any
> > > >> > > side effect but having some inputs to know if a release could be
> > > done
> > > >> > soon
> > > >> > > would be great.
> > > >> > >
> > > >> > > *Romain Manni-Bucau*
> > > >> > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > > >> > > *Blog: **http://rmannibucau.wordpress.com/*<
> > > >> > > http://rmannibucau.wordpress.com/>
> > > >> > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > >> > > *Github: https://github.com/rmannibucau*
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>

Re: release 2.3.x

2013-05-21T06:15:59Z

HI Romain,
Sorry, I'm a little slow this morning... :-)

"Should be the same..." Same as what? The JIRA I found related to the
Criteria API and GroupBy processing was still open with no commits to trunk
or any other release. So, that JIRA didn't fix your issue... Do you know
if there was a specific JIRA for this issue? Or, was it a case that you
just ran into this issue, tried it on trunk, and the problem no longer
existed? If that's the case, then I'll probably need more detail from you
on the specific scenario you were running so that we might narrow down
which JIRA helped you for this particular case.

Thanks again,
Kevin

On Mon, May 20, 2013 at 2:25 PM, Romain Manni-Bucau
<[hidden email]>wrote:

> Should be the same, i got the issue on an app and checked out trunk and saw
> it was fixed.
> Le 20 mai 2013 21:24, "Kevin Sutter" <[hidden email]> a écrit :
>
> > Romain,
> > I guess I wasn't clairvoyant... :-) The ASM one was easy to find. But,
> > the one I was thinking of for the Criteria bug is still open, so I doubt
> > that's the one you were referring to. Can you look up the JIRA you were
> > referring to? Thanks!
> >
> > Kevin
> >
> >
> > On Mon, May 20, 2013 at 12:54 PM, Kevin Sutter <[hidden email]>
> wrote:
> >
> > > Thanks, Romain. I am familiar with the items you referenced.
> > >
> > >
> > > On Mon, May 20, 2013 at 12:44 PM, Romain Manni-Bucau <
> > > [hidden email]> wrote:
> > >
> > >> basically 2 features (if you need jira number just ask i'll try to
> find
> > >> them back):
> > >>
> > >> - ASM "facade" to be able to use xbean asm shade instead of asm.jar
> > >> (blocking for tomee if not in the box)
> > >> - the criteria api bug where only a single groupby or having was used
> > (",
> > >> "
> > >> was missing when the jpql was created)
> > >>
> > >> *Romain Manni-Bucau*
> > >> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > >> *Blog: **http://rmannibucau.wordpress.com/*<
> > >> http://rmannibucau.wordpress.com/>
> > >> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > >> *Github: https://github.com/rmannibucau*
> > >>
> > >>
> > >>
> > >> 2013/5/20 Kevin Sutter <[hidden email]>
> > >>
> > >> > Hi Romain,
> > >> > We currently don't have any plans for cutting a 2.3.0 release... A
> > few
> > >> of
> > >> > us actually discussed it a couple of weeks back, but we didn't come
> up
> > >> with
> > >> > enough "features" to warrant a 2.3.0 release. Do you have a list of
> > the
> > >> > JIRAs that you have an interest in?
> > >> >
> > >> > If there are other users of trunk that would like to see a 2.3.0
> > >> release,
> > >> > please voice your interest.
> > >> >
> > >> > Thanks,
> > >> > Kevin
> > >> >
> > >> >
> > >> > On Mon, May 20, 2013 at 9:50 AM, Romain Manni-Bucau
> > >> > <[hidden email]>wrote:
> > >> >
> > >> > > Hi guys,
> > >> > >
> > >> > > any plan to release 2.3.0?
> > >> > >
> > >> > > basically i'd like to get rid of openejb shade for next tomee
> > release
> > >> > (and
> > >> > > some other fixes in 2.3.x would be great to integrate).
> > >> > >
> > >> > > I updated tomee snapshot to use the openjpa snapshot to see if we
> > have
> > >> > any
> > >> > > side effect but having some inputs to know if a release could be
> > done
> > >> > soon
> > >> > > would be great.
> > >> > >
> > >> > > *Romain Manni-Bucau*
> > >> > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > >> > > *Blog: **http://rmannibucau.wordpress.com/*<
> > >> > > http://rmannibucau.wordpress.com/>
> > >> > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > >> > > *Github: https://github.com/rmannibucau*
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>

Re: release 2.3.x

2013-05-20T12:25:40Z

Should be the same, i got the issue on an app and checked out trunk and saw
it was fixed.
Le 20 mai 2013 21:24, "Kevin Sutter" <[hidden email]> a écrit :

> Romain,
> I guess I wasn't clairvoyant... :-) The ASM one was easy to find. But,
> the one I was thinking of for the Criteria bug is still open, so I doubt
> that's the one you were referring to. Can you look up the JIRA you were
> referring to? Thanks!
>
> Kevin
>
>
> On Mon, May 20, 2013 at 12:54 PM, Kevin Sutter <[hidden email]> wrote:
>
> > Thanks, Romain. I am familiar with the items you referenced.
> >
> >
> > On Mon, May 20, 2013 at 12:44 PM, Romain Manni-Bucau <
> > [hidden email]> wrote:
> >
> >> basically 2 features (if you need jira number just ask i'll try to find
> >> them back):
> >>
> >> - ASM "facade" to be able to use xbean asm shade instead of asm.jar
> >> (blocking for tomee if not in the box)
> >> - the criteria api bug where only a single groupby or having was used
> (",
> >> "
> >> was missing when the jpql was created)
> >>
> >> *Romain Manni-Bucau*
> >> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> >> *Blog: **http://rmannibucau.wordpress.com/*<
> >> http://rmannibucau.wordpress.com/>
> >> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> >> *Github: https://github.com/rmannibucau*
> >>
> >>
> >>
> >> 2013/5/20 Kevin Sutter <[hidden email]>
> >>
> >> > Hi Romain,
> >> > We currently don't have any plans for cutting a 2.3.0 release... A
> few
> >> of
> >> > us actually discussed it a couple of weeks back, but we didn't come up
> >> with
> >> > enough "features" to warrant a 2.3.0 release. Do you have a list of
> the
> >> > JIRAs that you have an interest in?
> >> >
> >> > If there are other users of trunk that would like to see a 2.3.0
> >> release,
> >> > please voice your interest.
> >> >
> >> > Thanks,
> >> > Kevin
> >> >
> >> >
> >> > On Mon, May 20, 2013 at 9:50 AM, Romain Manni-Bucau
> >> > <[hidden email]>wrote:
> >> >
> >> > > Hi guys,
> >> > >
> >> > > any plan to release 2.3.0?
> >> > >
> >> > > basically i'd like to get rid of openejb shade for next tomee
> release
> >> > (and
> >> > > some other fixes in 2.3.x would be great to integrate).
> >> > >
> >> > > I updated tomee snapshot to use the openjpa snapshot to see if we
> have
> >> > any
> >> > > side effect but having some inputs to know if a release could be
> done
> >> > soon
> >> > > would be great.
> >> > >
> >> > > *Romain Manni-Bucau*
> >> > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> >> > > *Blog: **http://rmannibucau.wordpress.com/*<
> >> > > http://rmannibucau.wordpress.com/>
> >> > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> >> > > *Github: https://github.com/rmannibucau*
> >> > >
> >> >
> >>
> >
> >
>

Re: release 2.3.x

2013-05-20T12:23:40Z

Romain,
I guess I wasn't clairvoyant... :-) The ASM one was easy to find. But,
the one I was thinking of for the Criteria bug is still open, so I doubt
that's the one you were referring to. Can you look up the JIRA you were
referring to? Thanks!

Kevin

On Mon, May 20, 2013 at 12:54 PM, Kevin Sutter <[hidden email]> wrote:

> Thanks, Romain. I am familiar with the items you referenced.
>
>
> On Mon, May 20, 2013 at 12:44 PM, Romain Manni-Bucau <
> [hidden email]> wrote:
>
>> basically 2 features (if you need jira number just ask i'll try to find
>> them back):
>>
>> - ASM "facade" to be able to use xbean asm shade instead of asm.jar
>> (blocking for tomee if not in the box)
>> - the criteria api bug where only a single groupby or having was used (",
>> "
>> was missing when the jpql was created)
>>
>> *Romain Manni-Bucau*
>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
>> *Blog: **http://rmannibucau.wordpress.com/*<
>> http://rmannibucau.wordpress.com/>
>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>> *Github: https://github.com/rmannibucau*
>>
>>
>>
>> 2013/5/20 Kevin Sutter <[hidden email]>
>>
>> > Hi Romain,
>> > We currently don't have any plans for cutting a 2.3.0 release... A few
>> of
>> > us actually discussed it a couple of weeks back, but we didn't come up
>> with
>> > enough "features" to warrant a 2.3.0 release. Do you have a list of the
>> > JIRAs that you have an interest in?
>> >
>> > If there are other users of trunk that would like to see a 2.3.0
>> release,
>> > please voice your interest.
>> >
>> > Thanks,
>> > Kevin
>> >
>> >
>> > On Mon, May 20, 2013 at 9:50 AM, Romain Manni-Bucau
>> > <[hidden email]>wrote:
>> >
>> > > Hi guys,
>> > >
>> > > any plan to release 2.3.0?
>> > >
>> > > basically i'd like to get rid of openejb shade for next tomee release
>> > (and
>> > > some other fixes in 2.3.x would be great to integrate).
>> > >
>> > > I updated tomee snapshot to use the openjpa snapshot to see if we have
>> > any
>> > > side effect but having some inputs to know if a release could be done
>> > soon
>> > > would be great.
>> > >
>> > > *Romain Manni-Bucau*
>> > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
>> > > *Blog: **http://rmannibucau.wordpress.com/*<
>> > > http://rmannibucau.wordpress.com/>
>> > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>> > > *Github: https://github.com/rmannibucau*
>> > >
>> >
>>
>
>

[jira] [Updated] (OPENJPA-2171) asm should be optional

2013-05-20T12:17:15Z

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

Kevin Sutter updated OPENJPA-2171:
----------------------------------

Labels: 2.3.0-candidate (was: )

> asm should be optional
> ----------------------
>
> Key: OPENJPA-2171
> URL: https://issues.apache.org/jira/browse/OPENJPA-2171
> Project: OpenJPA
> Issue Type: Improvement
> Reporter: Romain Manni-Bucau
> Assignee: Mark Struberg
> Labels: 2.3.0-candidate
> Fix For: 2.3.0
>
> Attachments: ASM.patch
>
>
> openjpa uses since some versions asm but in tomee for instance we use a shade (through the xbean one org.apache.xbean:xbean-asm-shaded to avoid classloading/version issues with webapps/applications.
> it can be nice if openjpa can provide us an issue to this because we really don't want to provide asm in our binaries.
> solutions can be to use the xbean shade, give us an interface to implement or to try several implementation (xbean shade, asm,...) by reflection

Re: release 2.3.x

2013-05-20T10:54:47Z

Thanks, Romain. I am familiar with the items you referenced.

On Mon, May 20, 2013 at 12:44 PM, Romain Manni-Bucau
<[hidden email]>wrote:

> basically 2 features (if you need jira number just ask i'll try to find
> them back):
>
> - ASM "facade" to be able to use xbean asm shade instead of asm.jar
> (blocking for tomee if not in the box)
> - the criteria api bug where only a single groupby or having was used (", "
> was missing when the jpql was created)
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>
>
>
> 2013/5/20 Kevin Sutter <[hidden email]>
>
> > Hi Romain,
> > We currently don't have any plans for cutting a 2.3.0 release... A few
> of
> > us actually discussed it a couple of weeks back, but we didn't come up
> with
> > enough "features" to warrant a 2.3.0 release. Do you have a list of the
> > JIRAs that you have an interest in?
> >
> > If there are other users of trunk that would like to see a 2.3.0 release,
> > please voice your interest.
> >
> > Thanks,
> > Kevin
> >
> >
> > On Mon, May 20, 2013 at 9:50 AM, Romain Manni-Bucau
> > <[hidden email]>wrote:
> >
> > > Hi guys,
> > >
> > > any plan to release 2.3.0?
> > >
> > > basically i'd like to get rid of openejb shade for next tomee release
> > (and
> > > some other fixes in 2.3.x would be great to integrate).
> > >
> > > I updated tomee snapshot to use the openjpa snapshot to see if we have
> > any
> > > side effect but having some inputs to know if a release could be done
> > soon
> > > would be great.
> > >
> > > *Romain Manni-Bucau*
> > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > > *Blog: **http://rmannibucau.wordpress.com/*<
> > > http://rmannibucau.wordpress.com/>
> > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > *Github: https://github.com/rmannibucau*
> > >
> >
>

Re: release 2.3.x

2013-05-20T10:44:35Z

basically 2 features (if you need jira number just ask i'll try to find
them back):

- ASM "facade" to be able to use xbean asm shade instead of asm.jar
(blocking for tomee if not in the box)
- the criteria api bug where only a single groupby or having was used (", "
was missing when the jpql was created)

*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*

2013/5/20 Kevin Sutter <[hidden email]>

> Hi Romain,
> We currently don't have any plans for cutting a 2.3.0 release... A few of
> us actually discussed it a couple of weeks back, but we didn't come up with
> enough "features" to warrant a 2.3.0 release. Do you have a list of the
> JIRAs that you have an interest in?
>
> If there are other users of trunk that would like to see a 2.3.0 release,
> please voice your interest.
>
> Thanks,
> Kevin
>
>
> On Mon, May 20, 2013 at 9:50 AM, Romain Manni-Bucau
> <[hidden email]>wrote:
>
> > Hi guys,
> >
> > any plan to release 2.3.0?
> >
> > basically i'd like to get rid of openejb shade for next tomee release
> (and
> > some other fixes in 2.3.x would be great to integrate).
> >
> > I updated tomee snapshot to use the openjpa snapshot to see if we have
> any
> > side effect but having some inputs to know if a release could be done
> soon
> > would be great.
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
>

Re: release 2.3.x

2013-05-20T10:40:17Z

Hi Romain,
We currently don't have any plans for cutting a 2.3.0 release... A few of
us actually discussed it a couple of weeks back, but we didn't come up with
enough "features" to warrant a 2.3.0 release. Do you have a list of the
JIRAs that you have an interest in?

If there are other users of trunk that would like to see a 2.3.0 release,
please voice your interest.

Thanks,
Kevin

On Mon, May 20, 2013 at 9:50 AM, Romain Manni-Bucau
<[hidden email]>wrote:

> Hi guys,
>
> any plan to release 2.3.0?
>
> basically i'd like to get rid of openejb shade for next tomee release (and
> some other fixes in 2.3.x would be great to integrate).
>
> I updated tomee snapshot to use the openjpa snapshot to see if we have any
> side effect but having some inputs to know if a release could be done soon
> would be great.
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>

release 2.3.x

2013-05-20T07:50:33Z

Hi guys,

any plan to release 2.3.0?

basically i'd like to get rid of openejb shade for next tomee release (and
some other fixes in 2.3.x would be great to integrate).

I updated tomee snapshot to use the openjpa snapshot to see if we have any
side effect but having some inputs to know if a release could be done soon
would be great.

*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*

[jira] [Commented] (OPENJPA-1979) Regression for non-standard joins with constant column values

2013-05-19T11:03:16Z

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

ASF subversion and git services commented on OPENJPA-1979:
----------------------------------------------------------

Commit 1484326 from hthomann
[ https://svn.apache.org/r1484326 ]

OPENJPA-1979: Regression for non-standard joins with constant column values - back ported to 2.2.x Pinaki Poddar's trunk changes.

> Regression for non-standard joins with constant column values
> --------------------------------------------------------------
>
> Key: OPENJPA-1979
> URL: https://issues.apache.org/jira/browse/OPENJPA-1979
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc, kernel
> Affects Versions: 2.0.0-M1, 2.0.0
> Reporter: Pinaki Poddar
> Assignee: Pinaki Poddar
> Fix For: 2.3.0
>
> Attachments: OPENJPA-1979.patch.1.txt, Test-1979.zip
>
>
> The non-standard join can use constant column values by enclosing them in single-quote character. This behavior is regressed. The likely cause of this regression is new delimiting support for schema elements introduced in JPA 2.0. The constant column value used to be detected during schema definition based on the assumption of the name being enclosed in single-quote. Due to introduction of delimiting capability, the constant value is now enclosed in double-quote followed by a single-quote.
> The visible effect is failure to define schema for non-standard join with constant values.

[jira] [Commented] (OPENJPA-2373) MapsId in a Child entity to a Parent entity using auto-assigned identity fails with duplicte INSERT SQL

2013-05-19T11:03:16Z

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

ASF subversion and git services commented on OPENJPA-2373:
----------------------------------------------------------

Commit 1484325 from hthomann
[ https://svn.apache.org/r1484325 ]

OPENJPA-2373: MapsId in a Child entity to a Parent entity using auto-assigned identity fails with duplicte INSERT SQL - back ported to 2.2.x Pinaki Poddar's trunk changes.

[jira] [Commented] (OPENJPA-1979) Regression for non-standard joins with constant column values

2013-05-19T10:55:15Z

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

ASF subversion and git services commented on OPENJPA-1979:
----------------------------------------------------------

Commit 1484322 from hthomann
[ https://svn.apache.org/r1484322 ]

OPENJPA-1979: Regression for non-standard joins with constant column values - back ported to 2.2.1.x Pinaki Poddar's trunk changes.

[jira] [Commented] (OPENJPA-2373) MapsId in a Child entity to a Parent entity using auto-assigned identity fails with duplicte INSERT SQL

2013-05-19T10:41:15Z

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

ASF subversion and git services commented on OPENJPA-2373:
----------------------------------------------------------

Commit 1484320 from hthomann
[ https://svn.apache.org/r1484320 ]

OPENJPA-2373: MapsId in a Child entity to a Parent entity using auto-assigned identity fails with duplicte INSERT SQL - back ported to 2.2.1.x Pinaki Poddar's trunk changes.

[jira] [Commented] (OPENJPA-1979) Regression for non-standard joins with constant column values

2013-05-19T10:07:16Z

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

ASF subversion and git services commented on OPENJPA-1979:
----------------------------------------------------------

Commit 1484313 from hthomann
[ https://svn.apache.org/r1484313 ]

OPENJPA-1979: Regression for non-standard joins with constant column values - back ported to 2.1.x Pinaki Poddar's trunk changes.

[jira] [Commented] (OPENJPA-2373) MapsId in a Child entity to a Parent entity using auto-assigned identity fails with duplicte INSERT SQL

2013-05-19T08:45:16Z

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

ASF subversion and git services commented on OPENJPA-2373:
----------------------------------------------------------

Commit 1484300 from hthomann
[ https://svn.apache.org/r1484300 ]

OPENJPA-2373: MapsId in a Child entity to a Parent entity using auto-assigned identity fails with duplicte INSERT SQL - back ported to 2.1.x Pinaki Poddar's trunk changes.