[jira] [Commented] (OPENJPA-1991) Support ROW_NUMBER pagination on MS SQL Server 2005

2013-10-04 Thread Vermeulen (JIRA)

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

Vermeulen commented on OPENJPA-1991:


This definitely has my vote. When I use setMaxResults the generated SQL doesn't 
even use TOP and fetches all results and filters in memory. A not very optional 
workaround I can use is selecting id's first using setMaxResults and then 
select the entities with these id's. This means all id's are still fetched, but 
in my use case performance is acceptable.

> Support ROW_NUMBER pagination on MS SQL Server 2005
> ---
>
> Key: OPENJPA-1991
> URL: https://issues.apache.org/jira/browse/OPENJPA-1991
> Project: OpenJPA
>  Issue Type: Improvement
>  Components: jdbc
>Affects Versions: 2.1.0
>Reporter: Maia Kozheva
> Attachments: SQLServer2005Dictionary.java
>
>
> The current implementation of SQLServerDictionary in OpenJPA only supports 
> pagination based on TOP (offset+limit), which fetches more rows than 
> necessary and thus degrades performance in comparison to DBMSes that support 
> both limit and offset specification, like MySQL.
> SQL Server 2005 supports a ROW_NUMBER function that can be used to restrict 
> the result list to the necessary slice, taking both limit and offset into 
> account. I would like OpenJPA to support this syntax.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Issue Comment Deleted] (OPENJPA-1991) Support ROW_NUMBER pagination on MS SQL Server 2005

2013-10-04 Thread Vermeulen (JIRA)

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

Vermeulen updated OPENJPA-1991:
---

Comment: was deleted

(was: This definitely has my vote. When I use setMaxResults the generated SQL 
doesn't even use TOP and fetches all results and filters in memory. A not very 
optional workaround I can use is selecting id's first using setMaxResults and 
then select the entities with these id's. This means all id's are still 
fetched, but in my use case performance is acceptable.)

> Support ROW_NUMBER pagination on MS SQL Server 2005
> ---
>
> Key: OPENJPA-1991
> URL: https://issues.apache.org/jira/browse/OPENJPA-1991
> Project: OpenJPA
>  Issue Type: Improvement
>  Components: jdbc
>Affects Versions: 2.1.0
>Reporter: Maia Kozheva
> Attachments: SQLServer2005Dictionary.java
>
>
> The current implementation of SQLServerDictionary in OpenJPA only supports 
> pagination based on TOP (offset+limit), which fetches more rows than 
> necessary and thus degrades performance in comparison to DBMSes that support 
> both limit and offset specification, like MySQL.
> SQL Server 2005 supports a ROW_NUMBER function that can be used to restrict 
> the result list to the necessary slice, taking both limit and offset into 
> account. I would like OpenJPA to support this syntax.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (OPENJPA-2283) Upgrade to ASM 4 dependency

2013-10-04 Thread Romain Manni-Bucau (JIRA)

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

Romain Manni-Bucau commented on OPENJPA-2283:
-

Can't it be fixed with:


static {
// try the "real" asm first, then the others
tryClass("org.objectweb.asm.");
tryClass("org.apache.xbean.asm4.");
tryClass("org.apache.xbean.asm.");
tryClass("org.springframework.asm.");

// get needed stuff
try {
COMPUTE_FRAMES = cwClass.getField("COMPUTE_FRAMES").getInt(null);
classReaderAccept = crClass.getMethod("accept", findClassVisitor(), 
int.class);
classReaderConstructor = crClass.getConstructor(InputStream.class);
classWriterConstructor = cwClass.getConstructor(int.class);
classWritertoByteArray = cwClass.getMethod("toByteArray");
} catch (Exception e) {
throw new 
IllegalStateException(_loc.get("static-asm-exception").getMessage(), e);
}
}

private static Class findClassVisitor() throws ClassNotFoundException {
final String cwName = cwClass.getName();
return cwClass.getClassLoader().loadClass(cwName.substring(0, 
cwName.length() - "ClassWriter".length()) + "ClassVisitor");
}

> Upgrade to ASM 4 dependency
> ---
>
> Key: OPENJPA-2283
> URL: https://issues.apache.org/jira/browse/OPENJPA-2283
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: Enhance
>Affects Versions: 2.3.0
>Reporter: Kevin Sutter
> Fix For: 2.3.0
>
>
> OpenJPA currently has a dependency on ASM 3.2 for some post-enhancement 
> processing to fix up the stack map tables (Java 7 requirement).  The latest 
> release of ASM is 4.1, which just came out last week.  The immediate need is 
> to move up to ASM 4.0.  We can entertain 4.1 at a later date.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Comment Edited] (OPENJPA-2283) Upgrade to ASM 4 dependency

2013-10-04 Thread Romain Manni-Bucau (JIRA)

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

Romain Manni-Bucau edited comment on OPENJPA-2283 at 10/4/13 2:36 PM:
--

Can't it be fixed with:

{code}
static {
// try the "real" asm first, then the others
tryClass("org.objectweb.asm.");
tryClass("org.apache.xbean.asm4.");
tryClass("org.apache.xbean.asm.");
tryClass("org.springframework.asm.");

// get needed stuff
try {
COMPUTE_FRAMES = cwClass.getField("COMPUTE_FRAMES").getInt(null);
classReaderAccept = crClass.getMethod("accept", findClassVisitor(), 
int.class);
classReaderConstructor = crClass.getConstructor(InputStream.class);
classWriterConstructor = cwClass.getConstructor(int.class);
classWritertoByteArray = cwClass.getMethod("toByteArray");
} catch (Exception e) {
throw new 
IllegalStateException(_loc.get("static-asm-exception").getMessage(), e);
}
}

private static Class findClassVisitor() throws ClassNotFoundException {
final String cwName = cwClass.getName();
return cwClass.getClassLoader().loadClass(cwName.substring(0, 
cwName.length() - "ClassWriter".length()) + "ClassVisitor");
}
{code}


was (Author: romain.manni-bucau):
Can't it be fixed with:


static {
// try the "real" asm first, then the others
tryClass("org.objectweb.asm.");
tryClass("org.apache.xbean.asm4.");
tryClass("org.apache.xbean.asm.");
tryClass("org.springframework.asm.");

// get needed stuff
try {
COMPUTE_FRAMES = cwClass.getField("COMPUTE_FRAMES").getInt(null);
classReaderAccept = crClass.getMethod("accept", findClassVisitor(), 
int.class);
classReaderConstructor = crClass.getConstructor(InputStream.class);
classWriterConstructor = cwClass.getConstructor(int.class);
classWritertoByteArray = cwClass.getMethod("toByteArray");
} catch (Exception e) {
throw new 
IllegalStateException(_loc.get("static-asm-exception").getMessage(), e);
}
}

private static Class findClassVisitor() throws ClassNotFoundException {
final String cwName = cwClass.getName();
return cwClass.getClassLoader().loadClass(cwName.substring(0, 
cwName.length() - "ClassWriter".length()) + "ClassVisitor");
}

> Upgrade to ASM 4 dependency
> ---
>
> Key: OPENJPA-2283
> URL: https://issues.apache.org/jira/browse/OPENJPA-2283
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: Enhance
>Affects Versions: 2.3.0
>Reporter: Kevin Sutter
> Fix For: 2.3.0
>
>
> OpenJPA currently has a dependency on ASM 3.2 for some post-enhancement 
> processing to fix up the stack map tables (Java 7 requirement).  The latest 
> release of ASM is 4.1, which just came out last week.  The immediate need is 
> to move up to ASM 4.0.  We can entertain 4.1 at a later date.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (OPENJPA-2283) Upgrade to ASM 4 dependency

2013-10-04 Thread Mark Struberg (JIRA)

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

Mark Struberg commented on OPENJPA-2283:


+1. but we should change the lookup order as we don't know whether the 'native' 
ASM stuff is 'good enough' for us (means ASM3++).

As alternative, we might also think about forcing the dependency to xbean-asm4.
I would actually even prefer this to the other options. once there is a non 
compat change in asm, the xbean team will shade to a different package again. 
Thus xbean-asm4 can co-exist beside any other ASM version without interference.

> Upgrade to ASM 4 dependency
> ---
>
> Key: OPENJPA-2283
> URL: https://issues.apache.org/jira/browse/OPENJPA-2283
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: Enhance
>Affects Versions: 2.3.0
>Reporter: Kevin Sutter
> Fix For: 2.3.0
>
>
> OpenJPA currently has a dependency on ASM 3.2 for some post-enhancement 
> processing to fix up the stack map tables (Java 7 requirement).  The latest 
> release of ASM is 4.1, which just came out last week.  The immediate need is 
> to move up to ASM 4.0.  We can entertain 4.1 at a later date.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Comment Edited] (OPENJPA-2283) Upgrade to ASM 4 dependency

2013-10-04 Thread Mark Struberg (JIRA)

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

Mark Struberg edited comment on OPENJPA-2283 at 10/4/13 3:13 PM:
-

 +1
 but we should change the lookup order as we don't know whether the 'native' 
ASM stuff is 'good enough' for us (means ASM3++).

As alternative, we might also think about forcing the dependency to xbean-asm4.
I would actually even prefer this to the other options. once there is a non 
compat change in asm, the xbean team will shade to a different package again. 
Thus xbean-asm4 can co-exist beside any other ASM version without interference.


was (Author: struberg):
+1. but we should change the lookup order as we don't know whether the 'native' 
ASM stuff is 'good enough' for us (means ASM3++).

As alternative, we might also think about forcing the dependency to xbean-asm4.
I would actually even prefer this to the other options. once there is a non 
compat change in asm, the xbean team will shade to a different package again. 
Thus xbean-asm4 can co-exist beside any other ASM version without interference.

> Upgrade to ASM 4 dependency
> ---
>
> Key: OPENJPA-2283
> URL: https://issues.apache.org/jira/browse/OPENJPA-2283
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: Enhance
>Affects Versions: 2.3.0
>Reporter: Kevin Sutter
> Fix For: 2.3.0
>
>
> OpenJPA currently has a dependency on ASM 3.2 for some post-enhancement 
> processing to fix up the stack map tables (Java 7 requirement).  The latest 
> release of ASM is 4.1, which just came out last week.  The immediate need is 
> to move up to ASM 4.0.  We can entertain 4.1 at a later date.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (OPENJPA-2283) Upgrade to ASM 4 dependency

2013-10-04 Thread Romain Manni-Bucau (JIRA)

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

Romain Manni-Bucau commented on OPENJPA-2283:
-

If openjpa switch to xbean-asm4 we'd need to support a tomee-asm (not exiting 
today) since openjpa can be provided in webapps and we don't want to conflict 
with it (why xbean-asm was created). So ok to change the order, -1 to depend 
explicitely on the shade.

> Upgrade to ASM 4 dependency
> ---
>
> Key: OPENJPA-2283
> URL: https://issues.apache.org/jira/browse/OPENJPA-2283
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: Enhance
>Affects Versions: 2.3.0
>Reporter: Kevin Sutter
> Fix For: 2.3.0
>
>
> OpenJPA currently has a dependency on ASM 3.2 for some post-enhancement 
> processing to fix up the stack map tables (Java 7 requirement).  The latest 
> release of ASM is 4.1, which just came out last week.  The immediate need is 
> to move up to ASM 4.0.  We can entertain 4.1 at a later date.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (OPENJPA-2283) Upgrade to ASM 4 dependency

2013-10-04 Thread Kevin Sutter (JIRA)

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

Kevin Sutter commented on OPENJPA-2283:
---

I agree with Romain -- no change to the asm dependency itself.

> Upgrade to ASM 4 dependency
> ---
>
> Key: OPENJPA-2283
> URL: https://issues.apache.org/jira/browse/OPENJPA-2283
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: Enhance
>Affects Versions: 2.3.0
>Reporter: Kevin Sutter
> Fix For: 2.3.0
>
>
> OpenJPA currently has a dependency on ASM 3.2 for some post-enhancement 
> processing to fix up the stack map tables (Java 7 requirement).  The latest 
> release of ASM is 4.1, which just came out last week.  The immediate need is 
> to move up to ASM 4.0.  We can entertain 4.1 at a later date.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (OPENJPA-2283) Upgrade to ASM 4 dependency

2013-10-04 Thread Romain Manni-Bucau (JIRA)

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

Romain Manni-Bucau commented on OPENJPA-2283:
-

PS: i just tested with asm 4.1 as dependency and openjpa-persistence-jdbc tests 
are passing.

> Upgrade to ASM 4 dependency
> ---
>
> Key: OPENJPA-2283
> URL: https://issues.apache.org/jira/browse/OPENJPA-2283
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: Enhance
>Affects Versions: 2.3.0
>Reporter: Kevin Sutter
> Fix For: 2.3.0
>
>
> OpenJPA currently has a dependency on ASM 3.2 for some post-enhancement 
> processing to fix up the stack map tables (Java 7 requirement).  The latest 
> release of ASM is 4.1, which just came out last week.  The immediate need is 
> to move up to ASM 4.0.  We can entertain 4.1 at a later date.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (OPENJPA-2283) Upgrade to ASM 4 dependency

2013-10-04 Thread Romain Manni-Bucau (JIRA)

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

Romain Manni-Bucau commented on OPENJPA-2283:
-

just talked with Mark on IRC about it, since openjpa depends on asm java 7 
features and tomee doesn't care about xbean-asm4 in the apps we can test 
xbean-asm4 first and avoid issues this way. so changing my -1 in +1 (sorry for 
the noise)


> Upgrade to ASM 4 dependency
> ---
>
> Key: OPENJPA-2283
> URL: https://issues.apache.org/jira/browse/OPENJPA-2283
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: Enhance
>Affects Versions: 2.3.0
>Reporter: Kevin Sutter
> Fix For: 2.3.0
>
>
> OpenJPA currently has a dependency on ASM 3.2 for some post-enhancement 
> processing to fix up the stack map tables (Java 7 requirement).  The latest 
> release of ASM is 4.1, which just came out last week.  The immediate need is 
> to move up to ASM 4.0.  We can entertain 4.1 at a later date.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (OPENJPA-2283) Upgrade to ASM 4 dependency

2013-10-04 Thread Mark Struberg (JIRA)

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

Mark Struberg commented on OPENJPA-2283:


to make this more clear: for now we let the reflection stuff as is, but we only 
change the lookup order to check for xbean-asm4 first, then the rest.

{code}
tryClass("org.apache.xbean.asm4.");
tryClass("org.apache.xbean.asm.");
tryClass("org.objectweb.asm.");
tryClass("org.springframework.asm.");
{code}

The argument is that we know that xbean-asm4 is perfect, xbean-asm3 is still 
good enough, but org.objectweb.asm could even be ASM-2 and older. So if anyone 
ships his webapp with ASM-2 as dependency, we still would take xbean-asm4 if 
available (e.g. in Geronimo or TomEE).

> Upgrade to ASM 4 dependency
> ---
>
> Key: OPENJPA-2283
> URL: https://issues.apache.org/jira/browse/OPENJPA-2283
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: Enhance
>Affects Versions: 2.3.0
>Reporter: Kevin Sutter
> Fix For: 2.3.0
>
>
> OpenJPA currently has a dependency on ASM 3.2 for some post-enhancement 
> processing to fix up the stack map tables (Java 7 requirement).  The latest 
> release of ASM is 4.1, which just came out last week.  The immediate need is 
> to move up to ASM 4.0.  We can entertain 4.1 at a later date.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (OPENJPA-2283) Upgrade to ASM 4 dependency

2013-10-04 Thread Rick Curtis (JIRA)

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

Rick Curtis commented on OPENJPA-2283:
--

Hey Romain -- 

Your proposed change doesn't fix my problem...my guess is that the problem is 
somehow related to :

// ClassWriter.getCommonSuperClass uses TCCL
Thread.currentThread().setContextClassLoader(bc.getClassLoader());

> Upgrade to ASM 4 dependency
> ---
>
> Key: OPENJPA-2283
> URL: https://issues.apache.org/jira/browse/OPENJPA-2283
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: Enhance
>Affects Versions: 2.3.0
>Reporter: Kevin Sutter
> Fix For: 2.3.0
>
>
> OpenJPA currently has a dependency on ASM 3.2 for some post-enhancement 
> processing to fix up the stack map tables (Java 7 requirement).  The latest 
> release of ASM is 4.1, which just came out last week.  The immediate need is 
> to move up to ASM 4.0.  We can entertain 4.1 at a later date.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (OPENJPA-2283) Upgrade to ASM 4 dependency

2013-10-04 Thread Mark Struberg (JIRA)

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

Mark Struberg commented on OPENJPA-2283:


Rick, are you able to provide a small test?

> Upgrade to ASM 4 dependency
> ---
>
> Key: OPENJPA-2283
> URL: https://issues.apache.org/jira/browse/OPENJPA-2283
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: Enhance
>Affects Versions: 2.3.0
>Reporter: Kevin Sutter
> Fix For: 2.3.0
>
>
> OpenJPA currently has a dependency on ASM 3.2 for some post-enhancement 
> processing to fix up the stack map tables (Java 7 requirement).  The latest 
> release of ASM is 4.1, which just came out last week.  The immediate need is 
> to move up to ASM 4.0.  We can entertain 4.1 at a later date.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (OPENJPA-2283) Upgrade to ASM 4 dependency

2013-10-04 Thread Romain Manni-Bucau (JIRA)

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

Romain Manni-Bucau commented on OPENJPA-2283:
-

@Rick: how to reproduce it?

> Upgrade to ASM 4 dependency
> ---
>
> Key: OPENJPA-2283
> URL: https://issues.apache.org/jira/browse/OPENJPA-2283
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: Enhance
>Affects Versions: 2.3.0
>Reporter: Kevin Sutter
> Fix For: 2.3.0
>
>
> OpenJPA currently has a dependency on ASM 3.2 for some post-enhancement 
> processing to fix up the stack map tables (Java 7 requirement).  The latest 
> release of ASM is 4.1, which just came out last week.  The immediate need is 
> to move up to ASM 4.0.  We can entertain 4.1 at a later date.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (OPENJPA-2283) Upgrade to ASM 4 dependency

2013-10-04 Thread Rick Curtis (JIRA)

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

Rick Curtis updated OPENJPA-2283:
-

Attachment: openjpa-2283.problem.patch

Running with java7 --

.../openjpa-parent> mvn clean install

It *should* blow up while enhancing openjpa-persistence-jdbc.

> Upgrade to ASM 4 dependency
> ---
>
> Key: OPENJPA-2283
> URL: https://issues.apache.org/jira/browse/OPENJPA-2283
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: Enhance
>Affects Versions: 2.3.0
>Reporter: Kevin Sutter
> Fix For: 2.3.0
>
> Attachments: openjpa-2283.problem.patch
>
>
> OpenJPA currently has a dependency on ASM 3.2 for some post-enhancement 
> processing to fix up the stack map tables (Java 7 requirement).  The latest 
> release of ASM is 4.1, which just came out last week.  The immediate need is 
> to move up to ASM 4.0.  We can entertain 4.1 at a later date.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (OPENJPA-2283) Upgrade to ASM 4 dependency

2013-10-04 Thread Kevin Sutter (JIRA)

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

Kevin Sutter commented on OPENJPA-2283:
---

I still don't agree with the change in ordering.  We define our specific 
dependencies via the pom.  Right now, we require ASM 3.2.  We're looking to 
upgrade that to 4.0 or 4.1.  Our code should be treating the "real" ASM as our 
preferred choice, not some shaded version provided by another project.  A 
project that we have no dependencies on.

> Upgrade to ASM 4 dependency
> ---
>
> Key: OPENJPA-2283
> URL: https://issues.apache.org/jira/browse/OPENJPA-2283
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: Enhance
>Affects Versions: 2.3.0
>Reporter: Kevin Sutter
> Fix For: 2.3.0
>
> Attachments: openjpa-2283.problem.patch
>
>
> OpenJPA currently has a dependency on ASM 3.2 for some post-enhancement 
> processing to fix up the stack map tables (Java 7 requirement).  The latest 
> release of ASM is 4.1, which just came out last week.  The immediate need is 
> to move up to ASM 4.0.  We can entertain 4.1 at a later date.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (OPENJPA-1607) Using unidirectional one-to-many target foreign key throws exception

2013-10-04 Thread Reinis Vicups (JIRA)

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

Reinis Vicups commented on OPENJPA-1607:


Working with openjpa-2.3.0-SNAPSHOT and getting this error UNLESS

if I substitute @JoinColumn with 
@org.apache.openjpa.persistence.jdbc.ElementJoinColumn this particular 
exception goes away!

> Using unidirectional one-to-many target foreign key throws exception
> 
>
> Key: OPENJPA-1607
> URL: https://issues.apache.org/jira/browse/OPENJPA-1607
> Project: OpenJPA
>  Issue Type: Bug
>Affects Versions: 2.0.0-beta3
>Reporter: Oliver Ringel
> Attachments: openjpa-1607.tar
>
>
> Using this simple unidirectional relationship
> @OneToMany
> @JoinColumn(name = "DEPARTMENT_ID")
> private Set employees;
> causes to the following exception
>  
> org.apache.openjpa.persistence.ArgumentException: You have supplied columns 
> for "com.example.Department.employees", but this mapping cannot have columns 
> in this context.
> Unidirectional one-to-many target foreign key relationship should be 
> supported in JPA 2.0.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (OPENJPA-2283) Upgrade to ASM 4 dependency

2013-10-04 Thread Mark Struberg (JIRA)

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

Mark Struberg commented on OPENJPA-2283:


Kevin, if you take org.objectweb.asm as default, then you risk to get into deep 
troubles. There was a reason that there is a shaded version of asm used in 
OpenEJB, Geronimo, OpenWebBeans, Spring, etc. All those projects basically got 
to a point where they were broken sometimes because they use plain ASM.

The reason is that ASM folks changed their API over time and introduced 
backward incompatibilities. But they didn't change the package names. 
So whenever a custom WAR or EAR deployed in the container of your choice brings 
an own ASM version, then you can never be sure that it is compatible with 
OpenJPA! And I really don't like to render OpenJPA useless only because some 
customer projects bring an old ASM version as dependency.

Of course, I can see your point with ASM3 as primary target, thus I'd suggest 
to set the ordering as following:

# xbean-asm3
# xbean-asm4
# asm-spring
# asm native

> Upgrade to ASM 4 dependency
> ---
>
> Key: OPENJPA-2283
> URL: https://issues.apache.org/jira/browse/OPENJPA-2283
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: Enhance
>Affects Versions: 2.3.0
>Reporter: Kevin Sutter
> Fix For: 2.3.0
>
> Attachments: openjpa-2283.problem.patch
>
>
> OpenJPA currently has a dependency on ASM 3.2 for some post-enhancement 
> processing to fix up the stack map tables (Java 7 requirement).  The latest 
> release of ASM is 4.1, which just came out last week.  The immediate need is 
> to move up to ASM 4.0.  We can entertain 4.1 at a later date.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (OPENJPA-1794) Result of aggregate function MAX is 0 on empty table (instead of NULL).

2013-10-04 Thread ASF subversion and git services (JIRA)

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

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

Commit 1529241 from [~jpaheath] in branch 'openjpa/branches/2.1.x'
[ https://svn.apache.org/r1529241 ]

OPENJPA-1794: Return null, rather than 0, on MAX function - back ported to 
2.1.x Jeremy Bauer's commit to trunk.

> Result of aggregate function MAX is 0 on empty table (instead of NULL).
> ---
>
> Key: OPENJPA-1794
> URL: https://issues.apache.org/jira/browse/OPENJPA-1794
> Project: OpenJPA
>  Issue Type: Bug
>  Components: query
>Affects Versions: 2.0.0
>Reporter: Vera Filippova
>Assignee: Jeremy Bauer
> Fix For: 2.2.3
>
> Attachments: OPENJPA-1794.patch
>
>
> Below is a snippet of a test case... the max should be null, but is zero.
> Object count = em.createQuery("Select count(p.pk) from Entity1 p 
> where 1=1").getSingleResult();
> Object max = em.createQuery("Select max(p.pk) from Entity1 p 
> where 1=1").getSingleResult();
> System.out.println("count:"+count+ " max:"+max);
> > count:0 max:0



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (OPENJPA-2283) Upgrade to ASM 4 dependency

2013-10-04 Thread Kevin Sutter (JIRA)

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

Kevin Sutter commented on OPENJPA-2283:
---

Mark, okay, I give...  :-)  I just talked with Rick and he convinced me this 
was okay.  I have always struggled with this change since I was wondering why 
would we (OpenJPA) be checking for these alternate packages, when we don't have 
a direct dependency on them.  But, this is for application server environments 
like you said.  Environments where there might be multiple versions of ASM 
(both app server and application), and OpenJPA needs to use the "right one".  
In OpenJPA's premier app server (WebSphere), we can determine which ASM to use 
based on the classloader "magic".  But, that ability is not always available in 
every environment.  So, I'm good with this ordering change.

But, since we're re-looking at this change due to the ASM 4 upgrade, should the 
xbean-asm4 be first in the list?  I know that differs from my earlier comment, 
but now that I understand why you want the xbean shaded jars first, it would 
seem logical to have xbean-asm4 first.

> Upgrade to ASM 4 dependency
> ---
>
> Key: OPENJPA-2283
> URL: https://issues.apache.org/jira/browse/OPENJPA-2283
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: Enhance
>Affects Versions: 2.3.0
>Reporter: Kevin Sutter
> Fix For: 2.3.0
>
> Attachments: openjpa-2283.problem.patch
>
>
> OpenJPA currently has a dependency on ASM 3.2 for some post-enhancement 
> processing to fix up the stack map tables (Java 7 requirement).  The latest 
> release of ASM is 4.1, which just came out last week.  The immediate need is 
> to move up to ASM 4.0.  We can entertain 4.1 at a later date.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (OPENJPA-1794) Result of aggregate function MAX is 0 on empty table (instead of NULL).

2013-10-04 Thread ASF subversion and git services (JIRA)

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

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

Commit 1529267 from [~jpaheath] in branch 'openjpa/branches/2.2.1.x'
[ https://svn.apache.org/r1529267 ]

OPENJPA-1794: Return null, rather than 0, on MAX function - back ported to 
2.2.1.x Jeremy Bauer's commit to trunk.

> Result of aggregate function MAX is 0 on empty table (instead of NULL).
> ---
>
> Key: OPENJPA-1794
> URL: https://issues.apache.org/jira/browse/OPENJPA-1794
> Project: OpenJPA
>  Issue Type: Bug
>  Components: query
>Affects Versions: 2.0.0
>Reporter: Vera Filippova
>Assignee: Jeremy Bauer
> Fix For: 2.2.3
>
> Attachments: OPENJPA-1794.patch
>
>
> Below is a snippet of a test case... the max should be null, but is zero.
> Object count = em.createQuery("Select count(p.pk) from Entity1 p 
> where 1=1").getSingleResult();
> Object max = em.createQuery("Select max(p.pk) from Entity1 p 
> where 1=1").getSingleResult();
> System.out.println("count:"+count+ " max:"+max);
> > count:0 max:0



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (OPENJPA-2414) FinderCache does not consider active Fetch Groups/FetchPlan added Fields

2013-10-04 Thread Jody Grassel (JIRA)

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

Jody Grassel commented on OPENJPA-2414:
---

An update will be coming soon, adding a Compatibilty option that can turn off 
the changes introduced by this JIRA.

> FinderCache does not consider active Fetch Groups/FetchPlan added Fields
> 
>
> Key: OPENJPA-2414
> URL: https://issues.apache.org/jira/browse/OPENJPA-2414
> Project: OpenJPA
>  Issue Type: Bug
>  Components: kernel
>Affects Versions: 2.3.0, 2.2.3
>Reporter: Jody Grassel
>Assignee: Jody Grassel
> Fix For: 2.1.2, 2.3.0, 2.2.1.1, 2.2.3
>
>
> The FinderCache retains a Map, associating a ClassMapping with a FinderQuery. 
>  However, this cache does not factor in the characteristics of the FetchPlan 
> that was active when a mapping is created, nor does it factor them to 
> determine if a cache hit is appropriate.  This causes the find() operation to 
> perform the same SQL as the first time it was executed, regardless of changes 
> to the active FetchPlan afterwards.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (OPENJPA-1794) Result of aggregate function MAX is 0 on empty table (instead of NULL).

2013-10-04 Thread ASF subversion and git services (JIRA)

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

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

Commit 1529273 from [~jpaheath] in branch 'openjpa/branches/2.2.x'
[ https://svn.apache.org/r1529273 ]

OPENJPA-1794: Return null, rather than 0, on MAX function - back ported to 
2.2.x Jeremy Bauer's commit to trunk.

> Result of aggregate function MAX is 0 on empty table (instead of NULL).
> ---
>
> Key: OPENJPA-1794
> URL: https://issues.apache.org/jira/browse/OPENJPA-1794
> Project: OpenJPA
>  Issue Type: Bug
>  Components: query
>Affects Versions: 2.0.0
>Reporter: Vera Filippova
>Assignee: Jeremy Bauer
> Fix For: 2.2.3
>
> Attachments: OPENJPA-1794.patch
>
>
> Below is a snippet of a test case... the max should be null, but is zero.
> Object count = em.createQuery("Select count(p.pk) from Entity1 p 
> where 1=1").getSingleResult();
> Object max = em.createQuery("Select max(p.pk) from Entity1 p 
> where 1=1").getSingleResult();
> System.out.println("count:"+count+ " max:"+max);
> > count:0 max:0



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (OPENJPA-2414) FinderCache does not consider active Fetch Groups/FetchPlan added Fields

2013-10-04 Thread ASF subversion and git services (JIRA)

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

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

Commit 1529292 from [~fyrewyld] in branch 'openjpa/branches/2.1.x'
[ https://svn.apache.org/r1529292 ]

OPENJPA-2414: FinderCache does not consider active Fetch Groups/FetchPlan added 
Fields

> FinderCache does not consider active Fetch Groups/FetchPlan added Fields
> 
>
> Key: OPENJPA-2414
> URL: https://issues.apache.org/jira/browse/OPENJPA-2414
> Project: OpenJPA
>  Issue Type: Bug
>  Components: kernel
>Affects Versions: 2.3.0, 2.2.3
>Reporter: Jody Grassel
>Assignee: Jody Grassel
> Fix For: 2.1.2, 2.3.0, 2.2.1.1, 2.2.3
>
>
> The FinderCache retains a Map, associating a ClassMapping with a FinderQuery. 
>  However, this cache does not factor in the characteristics of the FetchPlan 
> that was active when a mapping is created, nor does it factor them to 
> determine if a cache hit is appropriate.  This causes the find() operation to 
> perform the same SQL as the first time it was executed, regardless of changes 
> to the active FetchPlan afterwards.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (OPENJPA-1794) Result of aggregate function MAX is 0 on empty table (instead of NULL).

2013-10-04 Thread ASF subversion and git services (JIRA)

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

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

Commit 1529340 from [~jpaheath] in branch 'openjpa/branches/2.2.1.x'
[ https://svn.apache.org/r1529340 ]

OPENJPA-1794: Return null, rather than 0, on MAX function - fixed previous 
2.2.1.x commit.

> Result of aggregate function MAX is 0 on empty table (instead of NULL).
> ---
>
> Key: OPENJPA-1794
> URL: https://issues.apache.org/jira/browse/OPENJPA-1794
> Project: OpenJPA
>  Issue Type: Bug
>  Components: query
>Affects Versions: 2.0.0
>Reporter: Vera Filippova
>Assignee: Jeremy Bauer
> Fix For: 2.2.3
>
> Attachments: OPENJPA-1794.patch
>
>
> Below is a snippet of a test case... the max should be null, but is zero.
> Object count = em.createQuery("Select count(p.pk) from Entity1 p 
> where 1=1").getSingleResult();
> Object max = em.createQuery("Select max(p.pk) from Entity1 p 
> where 1=1").getSingleResult();
> System.out.println("count:"+count+ " max:"+max);
> > count:0 max:0



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (OPENJPA-1794) Result of aggregate function MAX is 0 on empty table (instead of NULL).

2013-10-04 Thread ASF subversion and git services (JIRA)

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

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

Commit 1529343 from [~jpaheath] in branch 'openjpa/branches/2.2.x'
[ https://svn.apache.org/r1529343 ]

OPENJPA-1794: Return null, rather than 0, on MAX function - fixed previous 
2.2.x commit.

> Result of aggregate function MAX is 0 on empty table (instead of NULL).
> ---
>
> Key: OPENJPA-1794
> URL: https://issues.apache.org/jira/browse/OPENJPA-1794
> Project: OpenJPA
>  Issue Type: Bug
>  Components: query
>Affects Versions: 2.0.0
>Reporter: Vera Filippova
>Assignee: Jeremy Bauer
> Fix For: 2.2.3
>
> Attachments: OPENJPA-1794.patch
>
>
> Below is a snippet of a test case... the max should be null, but is zero.
> Object count = em.createQuery("Select count(p.pk) from Entity1 p 
> where 1=1").getSingleResult();
> Object max = em.createQuery("Select max(p.pk) from Entity1 p 
> where 1=1").getSingleResult();
> System.out.println("count:"+count+ " max:"+max);
> > count:0 max:0



--
This message was sent by Atlassian JIRA
(v6.1#6144)