Nabble - OpenJPA Users

Re: OpenJPA support for JPA 2.1: when?

2013-06-18T14:00:39Z

On Tue, Jun 18, 2013 at 12:34 PM, Pinaki Poddar <[hidden email]> wrote:

> While I will keep aside the later design principle for now, the former
> principle applies for the current topic. This forward-looking tendency can
> be observed when many "new" JPA features can be mapped onto "existing"
> OpenJPA features (FetchPlan being a notable example).
>
> So it does sound strange when we discuss about implementing JPA 2.1
> features
> as if the decision is subjected to someone asking for it.
>
> A Open Source group builds features not because a spec committee or a
> customer, but because , the members, as engineers, think that a feature
> will
> be useful -- today or tomorrow. Time may prove otherwise, but unless we
> carry that spirit of innovation backed by our love for a technology domain,
> we, as a group, will fall into the trap of factory-built, proprietary
> software that is so twentieth century.
>
> Yes, a popular spec like JPA can provide a guideline, but our decision of
> how to take OpenJPA forward should not depend on it.
>

I agree with you to a certain point, Pinaki. Yes, with open source, folks
are free to innovate and see what's valuable, but in the face of limited
resources, it does make sense that resources be assigned in order to
address those issues with the most votes. The thorn in the side of this
desire-ocracy is the need to implement the specification that, like it or
not, defines the minimum bar of entry of the space OpenJPA occupies. For
OpenJPA to remain competitive, it not only has to implement those features
that have been commoditized by the specification, but also innovate to
provide value above and beyond the specification.

I am pretty comfortable saying that most customers are going to expect
matter-of-factly that OpenJPA implement the latest version of JPA, with an
appropriate, but small, lag time after the specification's GA release,
which was in May 2013. Otherwise, OpenJPA is at a disadvantage in a
competitive situation versus other persistence implementations. Further,
it is usually those innovative features that tip an organization's decision
to use X or Y.

The various JPA implementations find themselves in the now-common dilemma
of having their features commoditized by the spec, which then puts pressure
on them to innovate. After a particular innovation (or set thereof) is
commonplace across implementations, it is standardized and commoditized,
and the cycle repeats. I see this a Good Thing.

Personally, I think all of the implementations should be striving to
implement JDO, since it is and always has been datastore-agnostic and there
is a significant NoSQL movement. Most of JPA's innovations have been
longstanding features of JDO for years, including fetch plans/entity
graphs. Contrary to what many think, JDO has continued undergoing active
development this whole time, and 3.1 is now beginning its release process.
I have long told customers that if their priority is have choice of
implementation, then go with JPA, but if their priority is choice of
datastore type, then go with JDO.

Hibernate, EclipseLink and Batoo may be conventionally thought of as
OpenJPA's competition, but forward thinkers should see DataNucleus as the
primary competition, especially as people continue to consider NoSQL
solutions.

In any case, OpenJPA must, IMHO, implement JPA 2.1 ASAP to be considered
legitimate in the space. Further, the roadmap should be to target JDO
compliance, as Pinaki alluded to in describing OpenJPA's datastore-agnostic
kernel (thanks to its predecessor, Kodo). I mean, seriously, the writing
is on the wall.

I guess I'm up to my $0.04 now... :)

-matthew

Re: OpenJPA support for JPA 2.1: when?

2013-06-18T10:34:30Z

Hi,

Matthew asks a pertinent question:
> When will OpenJPA support JPA 2.1?

Kevin's response is factual as well
> Pinaki has went so far to create a sandbox and start experimenting with an
> implementation. Again, he's a one-man show and can't do it all. Well, he
> probably could, but it would require a bit of work... :-)

I have done some analysis of the required changes to trunk to comply with JPA 2.1. And made some preliminary implementation work.

But, as Kevin observes, Open Source is *not* a one-man show. It thrives on voluntary participation, where *anyone* can contribute if they are passionate about what they do. Not because they belong to a club of one sort or other.

So for anyone reading this mail, you are welcome to express your wish to participate in OpenJPA community. You need not to be a member of any particular group or country, your only credential is you. You can write to me in confidence and I will organize the due process to welcome you in the fold.

Someone in this thread had raised a doubt about current active participation being dominated by the employees of a single company. But I can assure you based on my association with many of them, that they are excellent engineers who had earned the karma by their own merit and open-minded enough to welcome you irrespective of who pays your bill or which country you live.

-------------------------------------------------------------------------------------------------

About complying to a 2.1 JPA spec version, we should honor a pair of key principles that OpenJPA (or its predecessor Kodo) had always followed:
a) it is not driven by a de jure specification and aspires to stay ahead of the curve via innovative features (that perhaps no customer is asking for at that point of times)
b) its kernel is agnostic to datastore being of a particular kind (NoSQL enthusiasts should take note ;)

While I will keep aside the later design principle for now, the former principle applies for the current topic. This forward-looking tendency can be observed when many "new" JPA features can be mapped onto "existing" OpenJPA features (FetchPlan being a notable example).

So it does sound strange when we discuss about implementing JPA 2.1 features as if the decision is subjected to someone asking for it.

A Open Source group builds features not because a spec committee or a customer, but because , the members, as engineers, think that a feature will be useful -- today or tomorrow. Time may prove otherwise, but unless we carry that spirit of innovation backed by our love for a technology domain, we, as a group, will fall into the trap of factory-built, proprietary software that is so twentieth century.

Yes, a popular spec like JPA can provide a guideline, but our decision of how to take OpenJPA forward should not depend on it.

Pinaki Poddar
Chair, Apache OpenJPA Project

OneToMany Delete Order Problem

2013-06-18T10:19:00Z

I have a unidirectional one to many relationship defined but I am getting a foreign key constraint violation when attempting to run a delete on the entity. It appears the delete statements are not being issued in the correct order. The entity record is being deleted before the records with the foreign key references.

Is there any way to get them ordered properly? Configuration details follow..

OpenJPA 2.2.1-SNAPSHOT (Websphere Version)

Annotations on entity field

@OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER, orphanRemoval = true)
@JoinColumn(name = "ID_XXX", referencedColumnName = "ID_XXX", nullable = false)

Re: OpenJPA support for JPA 2.1: when?

2013-06-18T05:01:37Z

I'm not concerned about the fact that most OpenJPA committers are IBM
employees, but committership *is* de facto closed by the usual Apache
meritocracy principles.

If you don't get enough volunteers among Apache members for upgrading
OpenJPA to JPA 2.1, you might start thinking about making it easier
for people to contribute and/or become Apache members.

In the age of DVCS, contributing a feature to an open source project
should not be harder than creating an issue, forking a repository,
writing some code and submitting a pull request.

IMHO, Apache is more of a cathedral than a bazaar - for potential
contributors willing to code in their spare time, the entry barrier is
too high.

Best regards,
Harald

"Unwrapping" enhanced entity

2013-06-17T16:58:10Z

Hello,

I would like to pass an enhanced entity
(org.apache.openjpa.util.com$MyClass$0$proxy) to an 3rd party framework
that does some reflection stuff. In particular, that framework does
myEntity.getClass().getFields().

According to spec (read it someplace in oracle docs) - proxy shall
return a null array when getFields() is being invoked. This is also
happening in my case.

The 3rd party framework fails since it does not find any fields.

I am looking now for a good practice on how to "unwrap" the entity or
modify that 3rd party framework in a way that I get access to the
original field array of com.MyClass.

myEntity.getClass.getGenericSuperclass() returns the right type
(com.MyClass) but I am unsure on if and how to instrumentalize this.

I'd greatly appreciate any hints on this one.

kind regards
reinis

Re: OpenJPA support for JPA 2.1: when?

2013-06-17T08:14:17Z

Hi Glen

It's not bad that in this project participate people form IBM, it's bad
that there are not people from other companies. As far as I notice
people form Oracle haven't participated in this project since OpenJPA 1.x.

Java belongs to big companies and in my country is very rarely some
small company to use something written in Java except for products what
are ready for use in their business.

How is the situation in your country ?

Best regards
Georgi

On 06/17/2013 05:49 PM, Glen Mazza wrote:

> One concern I have for OpenJPA is that the vast majority of committers
> are IBM or Oracle people, which can give pause to people thinking about
> contributing (i.e., the impression that committership is closed to
> IBMers or Oracle people alone), that they may be better off submitting
> patches to another Apache project instead. Apache Xalan may have been in
> a similar situation in the past as virtually all committers were IBMers,
> causing one to think the project is a closed shop and not getting many
> external contributions or new people to help out as a result. Without an
> open community, you may not get the resources to implement JPA 2.1,
> similar to Xalan's resource problems in implementing XSLT 2.0 today.
>
> Glen
>
> On 06/13/2013 10:52 PM, Matthew Adams wrote:
>> responses inline...
>>
>> On Thu, Jun 13, 2013 at 2:27 PM, Kevin Sutter <[hidden email]> wrote:
>>
>>> Good question, Matthew. This has been brought up a couple of different
>>> times...
>>>
>>> http://openjpa.208410.n2.nabble.com/JPA-2-1-td7215602.html
>>>
>>> http://openjpa.208410.n2.nabble.com/DISCUSSION-JPA-2-1-spec-implementation-td7581978.html
>>>
>>>
>>> So, there's been some interest, but not an overwhelming interest. Not to
>>> the point of creating a team, figuring out the work effort, and
>>> divvying up
>>> the responsibilities. Contrast that with the JPA 2.0 development effort,
>>> and there was overwhelming community support and participation. So, I
>>> think there are a handful of us interested in a JPA 2.1
>>> implementation, but
>>> more participation is required.
>>>
>>> Pardon my surprise, but that sounds just plain bad. That kind of
>> sentiment threatens to scare users away, IMHO. I have always held OpenJPA
>> in high esteem as one of the major, credible implementations because it's
>> always been up to date WRT to the specs (and, let's not kid ourselves, it
>> hails from Kodo JDO). Frankly, the specs don't move very fast, and at
>> least previews of them are available well in advance of the actual GA
>> releases.
>>
>>
>>> Pinaki has went so far to create a sandbox and start experimenting
>>> with an
>>> implementation. Again, he's a one-man show and can't do it all. Well, he
>>> probably could, but it would require a bit of work... :-)
>>>
>>> https://svn.apache.org/repos/asf/openjpa/sandboxes/21
>>>
>>> Well, I would have expected a team of folks on this, not just one. After
>> all, Pinaki was arguing for expanded fetch plan capabilities in the JPA
>> expert group based on OpenJPA's current capabilities -- and rightfully
>> so,
>> I might add.
>>
>> Maybe we should resurrect that [DISCUSSION] topic
>>
>>
>> I think you should. Especially with any support customers you or the
>> OpenJPA project sponsors may have.
>>
>>
>>> but I'm curious what
>>> features of JPA 2.1 are of most interest to you? Or, is it just a matter
>>> of being consistent with the latest specification?
>>>
>>> One feature that's worth its development weight is fetch plans, which
>> OpenJPA, thanks to its current fetch plan implementation, can implement
>> fairly quickly. Further, OpenJPA's fetch plan support exceeds JPA's
>> requirement with fetch depth and recursion depth!
>>
>> Additionally, I just happen to be writing an advanced JPA course right
>> now,
>> and customers of this course want to use the JPA implementation in the
>> course that they have settled on in their organization. It just so
>> happens
>> that the maiden voyage of this course covers JPA 2.1 and is for a
>> customer
>> that is also an OpenJPA customer. And they're large. Now, I have to tell
>> them "Sorry, OpenJPA doesn't have plans to implement JPA 2.1". Can you
>> say, "Bye bye, customer"? EclipseLink & DataNucleus already implement
>> 2.1,
>> and Hibernate's implementation is in progress. If not for the technical
>> reasons I gave above, then the need to remain competitive should be
>> enough
>> to have you assemble a crack 2.1 team ASAP. Don't forget about BatooJPA
>> making noise (claiming top performance, although I take that with a few
>> grains of salt) and the NoSQL JPA implementations (DataNucleus, ObjectDB,
>> and Kundera), not to mention the Spring Data projects. Like it or not,
>> you
>> are beset on all sides with competition.
>>
>> Just my $0.02, which might just be worth around $0.029 with the interest
>> I've accumulated since working with JDO- & JPA-style lightweight
>> persistence since 1996 and with the expert groups since 2000.
>>
>> Thanks,
>>> Kevin
>>>
>>>
>>> On Thu, Jun 13, 2013 at 2:03 PM, Matthew Adams <[hidden email]
>>>> wrote:
>>>> When will OpenJPA support JPA 2.1?
>>>>
>>>> -matthew
>>>>
>>>> --
>>>> mailto:[hidden email] <[hidden email]>
>>>> skype:matthewadams12
>>>> googletalk:[hidden email]
>>>> http://matthewadams.me
>>>> http://www.linkedin.com/in/matthewadams
>>>>
>>
>>
>

Re: OpenJPA support for JPA 2.1: when?

2013-06-17T07:49:50Z

One concern I have for OpenJPA is that the vast majority of committers
are IBM or Oracle people, which can give pause to people thinking about
contributing (i.e., the impression that committership is closed to
IBMers or Oracle people alone), that they may be better off submitting
patches to another Apache project instead. Apache Xalan may have been
in a similar situation in the past as virtually all committers were
IBMers, causing one to think the project is a closed shop and not
getting many external contributions or new people to help out as a
result. Without an open community, you may not get the resources to
implement JPA 2.1, similar to Xalan's resource problems in implementing
XSLT 2.0 today.

Glen

On 06/13/2013 10:52 PM, Matthew Adams wrote:

> responses inline...
>
> On Thu, Jun 13, 2013 at 2:27 PM, Kevin Sutter <[hidden email]> wrote:
>
>> Good question, Matthew. This has been brought up a couple of different
>> times...
>>
>> http://openjpa.208410.n2.nabble.com/JPA-2-1-td7215602.html
>>
>> http://openjpa.208410.n2.nabble.com/DISCUSSION-JPA-2-1-spec-implementation-td7581978.html
>>
>> So, there's been some interest, but not an overwhelming interest. Not to
>> the point of creating a team, figuring out the work effort, and divvying up
>> the responsibilities. Contrast that with the JPA 2.0 development effort,
>> and there was overwhelming community support and participation. So, I
>> think there are a handful of us interested in a JPA 2.1 implementation, but
>> more participation is required.
>>
>> Pardon my surprise, but that sounds just plain bad. That kind of
> sentiment threatens to scare users away, IMHO. I have always held OpenJPA
> in high esteem as one of the major, credible implementations because it's
> always been up to date WRT to the specs (and, let's not kid ourselves, it
> hails from Kodo JDO). Frankly, the specs don't move very fast, and at
> least previews of them are available well in advance of the actual GA
> releases.
>
>
>> Pinaki has went so far to create a sandbox and start experimenting with an
>> implementation. Again, he's a one-man show and can't do it all. Well, he
>> probably could, but it would require a bit of work... :-)
>>
>> https://svn.apache.org/repos/asf/openjpa/sandboxes/21
>>
>> Well, I would have expected a team of folks on this, not just one. After
> all, Pinaki was arguing for expanded fetch plan capabilities in the JPA
> expert group based on OpenJPA's current capabilities -- and rightfully so,
> I might add.
>
> Maybe we should resurrect that [DISCUSSION] topic
>
>
> I think you should. Especially with any support customers you or the
> OpenJPA project sponsors may have.
>
>
>> but I'm curious what
>> features of JPA 2.1 are of most interest to you? Or, is it just a matter
>> of being consistent with the latest specification?
>>
>> One feature that's worth its development weight is fetch plans, which
> OpenJPA, thanks to its current fetch plan implementation, can implement
> fairly quickly. Further, OpenJPA's fetch plan support exceeds JPA's
> requirement with fetch depth and recursion depth!
>
> Additionally, I just happen to be writing an advanced JPA course right now,
> and customers of this course want to use the JPA implementation in the
> course that they have settled on in their organization. It just so happens
> that the maiden voyage of this course covers JPA 2.1 and is for a customer
> that is also an OpenJPA customer. And they're large. Now, I have to tell
> them "Sorry, OpenJPA doesn't have plans to implement JPA 2.1". Can you
> say, "Bye bye, customer"? EclipseLink & DataNucleus already implement 2.1,
> and Hibernate's implementation is in progress. If not for the technical
> reasons I gave above, then the need to remain competitive should be enough
> to have you assemble a crack 2.1 team ASAP. Don't forget about BatooJPA
> making noise (claiming top performance, although I take that with a few
> grains of salt) and the NoSQL JPA implementations (DataNucleus, ObjectDB,
> and Kundera), not to mention the Spring Data projects. Like it or not, you
> are beset on all sides with competition.
>
> Just my $0.02, which might just be worth around $0.029 with the interest
> I've accumulated since working with JDO- & JPA-style lightweight
> persistence since 1996 and with the expert groups since 2000.
>
> Thanks,
>> Kevin
>>
>>
>> On Thu, Jun 13, 2013 at 2:03 PM, Matthew Adams <[hidden email]
>>> wrote:
>>> When will OpenJPA support JPA 2.1?
>>>
>>> -matthew
>>>
>>> --
>>> mailto:[hidden email] <[hidden email]>
>>> skype:matthewadams12
>>> googletalk:[hidden email]
>>> http://matthewadams.me
>>> http://www.linkedin.com/in/matthewadams
>>>
>
>

Re: Help needed with "Fields 'xxx' are not a default persistent type" warning

2013-06-14T15:01:02Z

Found an answer to my question, apparently a minor bug in OpenJPA (
https://issues.apache.org/jira/browse/OPENJPA-2401), in which XML
configuration is not being consulted when deciding to print that warning
message.

Glen

On 06/13/2013 10:01 PM, Glen Mazza wrote:

> Hi, I'm new to OpenJPA (and JPA) and trying to create the
> entity-mapping XML files (classes are unannotated POJOs) for a simple
> parent-child database relationship[1] (parent is department, child is
> employees working at that department) Right now, here's what I have
> for the mapping files:[2] (classes are here: [3]).
>
> While my TestClass[4] (which accesses just the department table right
> now) runs fine I'm getting this warning message while running it:
> "2213 CompanyPU WARN [main] openjpa.Runtime - Fields "employees"
> are not a default persistent type, and do not have any annotations
> indicating their persistence strategy. They will be treated as
> non-persistent. If you intended for these fields to be persistent, be
> sure to annotate them appropriately. Otherwise annotate them with
> @Transient."
>
> Google is returning many examples of others with this error, but I'm
> still not sure what I'm doing wrong. In the department.orm.xml, I
> can't map "employees" as Transient because it is already mapped as
> <one-to-many/>, which is AFAICT the right mapping to do. Basically,
> what do I have to fix my department.orm.xml[2] (or Department.java
> class[3]) in order to get rid of the above warning message?
>
> Thanks,
> Glen
>
>
> [1]
> https://github.com/gmazza/blog-samples/blob/master/jpa_and_junit/src/main/config/create-database-derby.sql
> [2]
> https://github.com/gmazza/blog-samples/tree/master/jpa_and_junit/src/main/resources/entities
> [3]
> https://github.com/gmazza/blog-samples/tree/master/jpa_and_junit/src/main/java/entities
> [4]
> https://github.com/gmazza/blog-samples/blob/master/jpa_and_junit/src/main/java/TestClass.java
>

Re: OpenJPA support for JPA 2.1: when?

2013-06-14T14:16:44Z

Hi Kevin

I think that OpenJPA is great and the way it stuck to JPA 2.0 Standard
so quick was very good. As I am looking more and more into the JEE and
the desktop side of things is just as important to me, world it would be
great to keep the provider I know so well. I am may even be able to help
in the future as well as I once did before for some documentation and bugs.

I am definitely interested in helping if I can keep OpenJPA up to date.

Thanks

David
On 14/06/13 17:27, Kevin Sutter wrote:

> Hi Matthew,
> I greatly appreciate your insights. And, I'm 100% behind you on this.
> OpenJPA has a great, large set of users. We get feedback from all facets
> of the industry and we try to respond to the best of our ability. Like the
> squeaky wheel, we pay the most attention to those areas requesting
> attention. As you've seen, I have tried to generate and gauge interest in
> JPA 2.1. Mark has expressed some interest and, of course, Pinaki has.
> And, now your note is the strongest worded request for JPA 2.1. So, it's
> great to hear that there's finally some interest.
>
> This is totally different from the JPA 2.0 effort. When that one was
> discussed on the OpenJPA forums, there was much more interest from a
> development perspective with several individuals and teams stepping up --
> coding, testing, id, promotion, etc. For whatever reason, the interest in
> JPA 2.1 is not as strong. Since most of us have "day jobs" in addition to
> contributing to open-source, we have to pick what areas to focus on.
>
> If there is interest in kicking off a real development effort, then we
> should probably move this conversation to the dev mailing list and get the
> development community fired up.
>
> Anybody else have input?
>
> Kevin
>
>
> On Thu, Jun 13, 2013 at 9:52 PM, Matthew Adams <[hidden email]>wrote:
>
>> responses inline...
>>
>> On Thu, Jun 13, 2013 at 2:27 PM, Kevin Sutter <[hidden email]> wrote:
>>
>>> Good question, Matthew. This has been brought up a couple of different
>>> times...
>>>
>>> http://openjpa.208410.n2.nabble.com/JPA-2-1-td7215602.html
>>>
>>>
>> http://openjpa.208410.n2.nabble.com/DISCUSSION-JPA-2-1-spec-implementation-td7581978.html
>>> So, there's been some interest, but not an overwhelming interest. Not to
>>> the point of creating a team, figuring out the work effort, and divvying
>> up
>>> the responsibilities. Contrast that with the JPA 2.0 development effort,
>>> and there was overwhelming community support and participation. So, I
>>> think there are a handful of us interested in a JPA 2.1 implementation,
>> but
>>> more participation is required.
>>>
>>> Pardon my surprise, but that sounds just plain bad. That kind of
>> sentiment threatens to scare users away, IMHO. I have always held OpenJPA
>> in high esteem as one of the major, credible implementations because it's
>> always been up to date WRT to the specs (and, let's not kid ourselves, it
>> hails from Kodo JDO). Frankly, the specs don't move very fast, and at
>> least previews of them are available well in advance of the actual GA
>> releases.
>>
>>
>>> Pinaki has went so far to create a sandbox and start experimenting with
>> an
>>> implementation. Again, he's a one-man show and can't do it all. Well,
>> he
>>> probably could, but it would require a bit of work... :-)
>>>
>>> https://svn.apache.org/repos/asf/openjpa/sandboxes/21
>>>
>>> Well, I would have expected a team of folks on this, not just one. After
>> all, Pinaki was arguing for expanded fetch plan capabilities in the JPA
>> expert group based on OpenJPA's current capabilities -- and rightfully so,
>> I might add.
>>
>> Maybe we should resurrect that [DISCUSSION] topic
>>
>>
>> I think you should. Especially with any support customers you or the
>> OpenJPA project sponsors may have.
>>
>>
>>> but I'm curious what
>>> features of JPA 2.1 are of most interest to you? Or, is it just a matter
>>> of being consistent with the latest specification?
>>>
>>> One feature that's worth its development weight is fetch plans, which
>> OpenJPA, thanks to its current fetch plan implementation, can implement
>> fairly quickly. Further, OpenJPA's fetch plan support exceeds JPA's
>> requirement with fetch depth and recursion depth!
>>
>> Additionally, I just happen to be writing an advanced JPA course right now,
>> and customers of this course want to use the JPA implementation in the
>> course that they have settled on in their organization. It just so happens
>> that the maiden voyage of this course covers JPA 2.1 and is for a customer
>> that is also an OpenJPA customer. And they're large. Now, I have to tell
>> them "Sorry, OpenJPA doesn't have plans to implement JPA 2.1". Can you
>> say, "Bye bye, customer"? EclipseLink & DataNucleus already implement 2.1,
>> and Hibernate's implementation is in progress. If not for the technical
>> reasons I gave above, then the need to remain competitive should be enough
>> to have you assemble a crack 2.1 team ASAP. Don't forget about BatooJPA
>> making noise (claiming top performance, although I take that with a few
>> grains of salt) and the NoSQL JPA implementations (DataNucleus, ObjectDB,
>> and Kundera), not to mention the Spring Data projects. Like it or not, you
>> are beset on all sides with competition.
>>
>> Just my $0.02, which might just be worth around $0.029 with the interest
>> I've accumulated since working with JDO- & JPA-style lightweight
>> persistence since 1996 and with the expert groups since 2000.
>>
>> Thanks,
>>> Kevin
>>>
>>>
>>> On Thu, Jun 13, 2013 at 2:03 PM, Matthew Adams <[hidden email]
>>>> wrote:
>>>> When will OpenJPA support JPA 2.1?
>>>>
>>>> -matthew
>>>>
>>>> --
>>>> mailto:[hidden email] <[hidden email]>
>>>> skype:matthewadams12
>>>> googletalk:[hidden email]
>>>> http://matthewadams.me
>>>> http://www.linkedin.com/in/matthewadams
>>>>
>>
>>
>> --
>> mailto:[hidden email] <[hidden email]>
>> skype:matthewadams12
>> googletalk:[hidden email]
>> http://matthewadams.me
>> http://www.linkedin.com/in/matthewadams
>>

Re: OpenJPA support for JPA 2.1: when?

2013-06-14T09:27:59Z

Hi Matthew,
I greatly appreciate your insights. And, I'm 100% behind you on this.
OpenJPA has a great, large set of users. We get feedback from all facets
of the industry and we try to respond to the best of our ability. Like the
squeaky wheel, we pay the most attention to those areas requesting
attention. As you've seen, I have tried to generate and gauge interest in
JPA 2.1. Mark has expressed some interest and, of course, Pinaki has.
And, now your note is the strongest worded request for JPA 2.1. So, it's
great to hear that there's finally some interest.

This is totally different from the JPA 2.0 effort. When that one was
discussed on the OpenJPA forums, there was much more interest from a
development perspective with several individuals and teams stepping up --
coding, testing, id, promotion, etc. For whatever reason, the interest in
JPA 2.1 is not as strong. Since most of us have "day jobs" in addition to
contributing to open-source, we have to pick what areas to focus on.

If there is interest in kicking off a real development effort, then we
should probably move this conversation to the dev mailing list and get the
development community fired up.

Anybody else have input?

Kevin

On Thu, Jun 13, 2013 at 9:52 PM, Matthew Adams <[hidden email]>wrote:

> responses inline...
>
> On Thu, Jun 13, 2013 at 2:27 PM, Kevin Sutter <[hidden email]> wrote:
>
> > Good question, Matthew. This has been brought up a couple of different
> > times...
> >
> > http://openjpa.208410.n2.nabble.com/JPA-2-1-td7215602.html
> >
> >
> http://openjpa.208410.n2.nabble.com/DISCUSSION-JPA-2-1-spec-implementation-td7581978.html
> >
> > So, there's been some interest, but not an overwhelming interest. Not to
> > the point of creating a team, figuring out the work effort, and divvying
> up
> > the responsibilities. Contrast that with the JPA 2.0 development effort,
> > and there was overwhelming community support and participation. So, I
> > think there are a handful of us interested in a JPA 2.1 implementation,
> but
> > more participation is required.
> >
> > Pardon my surprise, but that sounds just plain bad. That kind of
> sentiment threatens to scare users away, IMHO. I have always held OpenJPA
> in high esteem as one of the major, credible implementations because it's
> always been up to date WRT to the specs (and, let's not kid ourselves, it
> hails from Kodo JDO). Frankly, the specs don't move very fast, and at
> least previews of them are available well in advance of the actual GA
> releases.
>
>
> > Pinaki has went so far to create a sandbox and start experimenting with
> an
> > implementation. Again, he's a one-man show and can't do it all. Well,
> he
> > probably could, but it would require a bit of work... :-)
> >
> > https://svn.apache.org/repos/asf/openjpa/sandboxes/21
> >
> > Well, I would have expected a team of folks on this, not just one. After
> all, Pinaki was arguing for expanded fetch plan capabilities in the JPA
> expert group based on OpenJPA's current capabilities -- and rightfully so,
> I might add.
>
> Maybe we should resurrect that [DISCUSSION] topic
>
>
> I think you should. Especially with any support customers you or the
> OpenJPA project sponsors may have.
>
>
> > but I'm curious what
> > features of JPA 2.1 are of most interest to you? Or, is it just a matter
> > of being consistent with the latest specification?
> >
> > One feature that's worth its development weight is fetch plans, which
> OpenJPA, thanks to its current fetch plan implementation, can implement
> fairly quickly. Further, OpenJPA's fetch plan support exceeds JPA's
> requirement with fetch depth and recursion depth!
>
> Additionally, I just happen to be writing an advanced JPA course right now,
> and customers of this course want to use the JPA implementation in the
> course that they have settled on in their organization. It just so happens
> that the maiden voyage of this course covers JPA 2.1 and is for a customer
> that is also an OpenJPA customer. And they're large. Now, I have to tell
> them "Sorry, OpenJPA doesn't have plans to implement JPA 2.1". Can you
> say, "Bye bye, customer"? EclipseLink & DataNucleus already implement 2.1,
> and Hibernate's implementation is in progress. If not for the technical
> reasons I gave above, then the need to remain competitive should be enough
> to have you assemble a crack 2.1 team ASAP. Don't forget about BatooJPA
> making noise (claiming top performance, although I take that with a few
> grains of salt) and the NoSQL JPA implementations (DataNucleus, ObjectDB,
> and Kundera), not to mention the Spring Data projects. Like it or not, you
> are beset on all sides with competition.
>
> Just my $0.02, which might just be worth around $0.029 with the interest
> I've accumulated since working with JDO- & JPA-style lightweight
> persistence since 1996 and with the expert groups since 2000.
>
> Thanks,
> > Kevin
> >
> >
> > On Thu, Jun 13, 2013 at 2:03 PM, Matthew Adams <[hidden email]
> > >wrote:
> >
> > > When will OpenJPA support JPA 2.1?
> > >
> > > -matthew
> > >
> > > --
> > > mailto:[hidden email] <[hidden email]>
> > > skype:matthewadams12
> > > googletalk:[hidden email]
> > > http://matthewadams.me
> > > http://www.linkedin.com/in/matthewadams
> > >
> >
>
>
>
> --
> mailto:[hidden email] <[hidden email]>
> skype:matthewadams12
> googletalk:[hidden email]
> http://matthewadams.me
> http://www.linkedin.com/in/matthewadams
>

Re: ClassCastException - org.apache.openjpa.util.IntId incompatible

2013-06-14T08:20:34Z

Thanks Kevin,

I tried setting the QuerySQLCache to false but that didn't seem to fix the issue. I am still seeing those exceptions.

Does it have to do anything with class loaders or maybe something with the way I currently have setup my parent-child relations

As mentioned before it works fine if there is just one record in my parent table, if more than one then I get the exception.

Here are my parent & child class

//Parent super class

@MappedSuperclass
@Inheritance(strategy=InheritanceType.TABLE_PER_CLASS)
@Access(AccessType.FIELD)
public abstract class TransactionQueue {

    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    @Column(name="TransactionID")
    private int transactionId;

.. other field omitted

}

//Parent class

@Entity
@Access(AccessType.FIELD)
public class OrderTransactionQueue extends TransactionQueue implements Serializable {
    private static final long serialVersionUID = 1L;

    @OneToMany(mappedBy="orderTransactionQueue", fetch=FetchType.EAGER, cascade=CascadeType.ALL,targetEntity=OrderTransaction.class)
    private List<OrderTransaction> orderTransactions;

}

//Child class
@Entity
@IdClass(OrderTransactionPK.class)
public class OrderTransaction implements Serializable {
    private static final long serialVersionUID = 1L;

    @Id
    @Column(name="OrderNum")
    private int orderNum;

    //bi-directional many-to-one association to OrderTransactionQueue
    @ManyToOne
    @JoinColumn(name="TransactionID")
    @Id
    private OrderTransactionQueue orderTransactionQueue;

}

//Child Id class
public class OrderTransactionPK implements Serializable {
    //default serial version id, required for serializable classes.
    private static final long serialVersionUID = 1L;

    private int orderNum;

    private int orderTransactionQueue;

}

Please, let me know if you need more information.

Thanks,

Javid

On Thu, Jun 13, 2013 at 2:36 PM, Kevin Sutter [via OpenJPA] <[hidden email]> wrote:

Since you are using WebSphere, I would also suggest opening a PMR for this
problem through the normal IBM support channels. If this question does
turn into something "real" and requires an iFix, then you'll need the PMR
and APAR to get the fix delivered anyway...

Since your query works some of the times and not others, my first guess is
that there might be an issue with the SQL cache. You can quickly verify
this by turning off the SQL cache via this property. If that works for
you, at least you have a workaround until a real fix can be determined.

<property name="openjpa.jdbc.QuerySQLCache" value="false">

There are other options with this Cache that might help you out. For
example, if turning off the Cache completely gets you around the problem,
then you could just turn it off for a specific query. Details can be found
in the documentation [1].

Hope this helps get you started.
Kevin

[1]
http://ci.apache.org/projects/openjpa/trunk/docbook/manual.html#ref_guide_cache_querysql

On Thu, Jun 13, 2013 at 1:12 PM, javid.alimohideen <
[hidden email]> wrote:

> Hi,
> I have web application running on Websphere v8.5, that uses a JPA project
> configured as utility project. The application suddenly started throwing
> ClassCastException when performing select query. I have pasted the
> exception
> stack trace. The weird things is it works sometime and at times I get this
> exception. Also, if the DB tables have just one record then everything
> works
> fine, if there are more than 1 record then I see this exception
>
> The entities have a OneToMany and ManyToOne relationships defined.
>
> Caused by: java.lang.ClassCastException: org.apache.openjpa.util.IntId
> incompatible with com.jpa.dom.transactionqueue.BlockTransactionQueue
> at
>
> com.jpa.dom.transactionqueue.BlockCompleteTransaction.pcReplaceField(BlockCompleteTransaction.java)
> at
>
> org.apache.openjpa.kernel.StateManagerImpl.replaceField(StateManagerImpl.java:3174)
> at
>
> org.apache.openjpa.kernel.StateManagerImpl.storeObjectField(StateManagerImpl.java:2602)
> at
>
> org.apache.openjpa.kernel.StateManagerImpl.storeObject(StateManagerImpl.java:2592)
> at
>
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.setMappedBy(JDBCStoreManager.java:476)
> at
>
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:402)
> at
>
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:304)
> at
>
> com.ibm.ws.persistence.jdbc.kernel.WsJpaJDBCStoreManager.initialize(WsJpaJDBCStoreManager.java:149)
> at
>
> org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:112)
> at
>
> org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
> at
> org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:1036)
> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:994)
>
> I can post any additional detail if needed. please, let me know.
>
> Thanks
>
>
>
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/ClassCastException-org-apache-openjpa-util-IntId-incompatible-tp7584145.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

If you reply to this email, your message will be added to the discussion below:
http://openjpa.208410.n2.nabble.com/ClassCastException-org-apache-openjpa-util-IntId-incompatible-tp7584145p7584159.html

To unsubscribe from ClassCastException - org.apache.openjpa.util.IntId incompatible, click here.
NAML

Re: [External] Re: OpenJPA Null Update

2013-06-14T06:44:47Z

You could set the property openjpa.DetachState(DetachedStateField=true). This
property will make our DetachedStateManager serializeable and then the JPA
runtime can 'track' a detached Entity. The only down side to this approach
is that the OpenJPA classes must be on the classpath of the client that
your Entities are being streamed to. I'll also note that this property is
important to be set prior to enhancement because it changes our enhanced
bytecode.

Let me know how it goes.

Thanks,
Rick

[1]
http://ci.apache.org/projects/openjpa/trunk/docbook/manual.html#ref_guide_detach_graph

On Fri, Jun 14, 2013 at 1:37 AM, Boblitz John <[hidden email]>wrote:

> Hello,
>
> I think that Chapter 12.1.2 in the Manual will help here.
>
> "When attaching null fields in these cases, OpenJPA cannot distinguish
> between a field that was unloaded and one that was
> intentionally set to null. In this case, OpenJPA will use the current
> detach state setting to determine how to handle null fields:
> fields that would have been included in the detached state are treated as
> loaded, and will in turn set the corresponding attached
> field to null."
>
> Regards,
> John
>
>
> > -----Original Message-----
> > From: Tibebu, Nebiyou [USA] [mailto:[hidden email]]
> > Sent: Friday, June 14, 2013 5:26 AM
> > To: [hidden email]
> > Subject: RE: [External] Re: OpenJPA Null Update
> >
> > Rick,
> >
> > Thank you for your help. Here is the scenario:
> >
> > 1. Get a persistent instance of an entity 2. Detach entity 3. Update
> values on
> > the entity with non-null values 4. One of these values will be a string
> value
> > with existing non-trivial data 5. Set the value on this field to null 6.
> Merge
> > entity 7. All other fields are updated except this value.
> >
> > Nebiyou Tibebu
> > ________________
> > Booz | Allen | Hamilton
> > 8283 Greensboro Dr, Mclean, VA 22102
> > [hidden email]
> > ________________________________________
> > From: Rick Curtis [[hidden email]]
> > Sent: Thursday, June 13, 2013 10:31 PM
> > To: [hidden email]
> > Subject: RE: [External] Re: OpenJPA Null Update
> >
> > Well, you are going to have to describe what your scenario is for any of
> us to
> > help you out.
> > On Jun 13, 2013 6:57 PM, "Tibebu, Nebiyou [USA]"
> > <[hidden email]>
> > wrote:
> >
> > > I am not getting any errors. It is just being ignored.
> > >
> > > Nebiyou Tibebu
> > > ________________
> > > Booz | Allen | Hamilton
> > > 8283 Greensboro Dr, Mclean, VA 22102
> > > [hidden email]
> > > ________________________________________
> > > From: Tibebu, Nebiyou [USA]
> > > Sent: Thursday, June 13, 2013 5:55 PM
> > > To: [hidden email]
> > > Subject: RE: [External] Re: OpenJPA Null Update
> > >
> > > Nebiyou Tibebu
> > > ________________
> > > Booz | Allen | Hamilton
> > > 8283 Greensboro Dr, Mclean, VA 22102
> > > [hidden email]
> > > ________________________________________
> > > From: Rick Curtis [[hidden email]]
> > > Sent: Thursday, June 13, 2013 5:12 PM
> > > To: users
> > > Subject: [External] Re: OpenJPA Null Update
> > >
> > > Are you getting an error or something... or is it just being ignored?
> > > If it is being ignored, can you better describe the scenario that
> > > you're running?
> > >
> > >
> > > On Thu, Jun 13, 2013 at 3:00 PM, Tibebu, Nebiyou [USA] <
> > > [hidden email]<mailto:[hidden email]>> wrote:
> > > I am unable to update Nullable VARCHAR columns in Mainframe DB2 to
> > NULL.
> > > Update to other values, including an empty string works fine. I would
> > > appreciate some assistance. This is in version 2.2.1.
> > >
> > > Nebiyou Tibebu
> > > Senior Consultant
> > > 13200 Woodland Park Rd,
> > > Herndon, VA 21071
> > > Email: [hidden email]<mailto:[hidden email]>
> > > Tel: (703) 377-5425<tel:%28703%29%20377-5425>
> > > Cell: (571) 422-5178<tel:%28571%29%20422-5178>
> > >
> > >
> > [http://www.soaschool.com/system/application/images/soacp_architect.jp
> > > g]
> > >
> > > Booz Allen Hamilton |
> > > http://www.boozallen.com<http://www.boozallen.com/
> > > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Rick Curtis
> > >
>

--
*Rick Curtis*

RE: @PrePersist callback and merge/persist behaviour

2013-06-14T06:04:32Z

Hello,

My apologies, I’ve removed the DetachedStateManager=true to property "openjpa.DetachState" in the previous unitary test (I've shrunk the unitary test too much) ….

You will now obtain the same errors as explained in my first mail.

I re-attach the whole unitary test...

All my apologies for the inconvenience,

Guillaume

MergePersistCallback-v2.zip (15K) Download Attachment

getDataStoreAction comes as empty String[] when caching is enabled

2013-06-14T01:20:54Z

I'm not sure if this is a bug or if my understanding of the way how it
should work is wrong. Maybe someone can help me out a little bit.

In an application (WebSphere 8.0.0.5, OpenJPA 2.1.2) I need to get the
generated native SQL String from an JPQL to manipulate it. It is working
great but when I activate the QueryCache (2nd level) the result is coming
as an empty string-array. I investigated a little bit in debugging and have
found this code in the kernel package:

QueryCacheExecuter#QueryCacheStoreQuery.getDataStoreActions(...): The
implementation of this method is quite simple:
return EMPTY_STRINGS;

:)

Maybe my way of thinking is wrong, but shouldn't there be the
implementation for returning the native query string? When I deactivate the
Cache the implementation of ExpressionStoreQuery is executed which is
working fine.

Regards
jens

RE: [External] Re: OpenJPA Null Update

2013-06-13T23:37:19Z

Hello,

I think that Chapter 12.1.2 in the Manual will help here.

"When attaching null fields in these cases, OpenJPA cannot distinguish between a field that was unloaded and one that was
intentionally set to null. In this case, OpenJPA will use the current detach state setting to determine how to handle null fields:
fields that would have been included in the detached state are treated as loaded, and will in turn set the corresponding attached
field to null."

Regards,
John

> -----Original Message-----
> From: Tibebu, Nebiyou [USA] [mailto:[hidden email]]
> Sent: Friday, June 14, 2013 5:26 AM
> To: [hidden email]
> Subject: RE: [External] Re: OpenJPA Null Update
>
> Rick,
>
> Thank you for your help. Here is the scenario:
>
> 1. Get a persistent instance of an entity 2. Detach entity 3. Update values on
> the entity with non-null values 4. One of these values will be a string value
> with existing non-trivial data 5. Set the value on this field to null 6. Merge
> entity 7. All other fields are updated except this value.
>
> Nebiyou Tibebu
> ________________
> Booz | Allen | Hamilton
> 8283 Greensboro Dr, Mclean, VA 22102
> [hidden email]
> ________________________________________
> From: Rick Curtis [[hidden email]]
> Sent: Thursday, June 13, 2013 10:31 PM
> To: [hidden email]
> Subject: RE: [External] Re: OpenJPA Null Update
>
> Well, you are going to have to describe what your scenario is for any of us to
> help you out.
> On Jun 13, 2013 6:57 PM, "Tibebu, Nebiyou [USA]"
> <[hidden email]>
> wrote:
>
> > I am not getting any errors. It is just being ignored.
> >
> > Nebiyou Tibebu
> > ________________
> > Booz | Allen | Hamilton
> > 8283 Greensboro Dr, Mclean, VA 22102
> > [hidden email]
> > ________________________________________
> > From: Tibebu, Nebiyou [USA]
> > Sent: Thursday, June 13, 2013 5:55 PM
> > To: [hidden email]
> > Subject: RE: [External] Re: OpenJPA Null Update
> >
> > Nebiyou Tibebu
> > ________________
> > Booz | Allen | Hamilton
> > 8283 Greensboro Dr, Mclean, VA 22102
> > [hidden email]
> > ________________________________________
> > From: Rick Curtis [[hidden email]]
> > Sent: Thursday, June 13, 2013 5:12 PM
> > To: users
> > Subject: [External] Re: OpenJPA Null Update
> >
> > Are you getting an error or something... or is it just being ignored?
> > If it is being ignored, can you better describe the scenario that
> > you're running?
> >
> >
> > On Thu, Jun 13, 2013 at 3:00 PM, Tibebu, Nebiyou [USA] <
> > [hidden email]<mailto:[hidden email]>> wrote:
> > I am unable to update Nullable VARCHAR columns in Mainframe DB2 to
> NULL.
> > Update to other values, including an empty string works fine. I would
> > appreciate some assistance. This is in version 2.2.1.
> >
> > Nebiyou Tibebu
> > Senior Consultant
> > 13200 Woodland Park Rd,
> > Herndon, VA 21071
> > Email: [hidden email]<mailto:[hidden email]>
> > Tel: (703) 377-5425<tel:%28703%29%20377-5425>
> > Cell: (571) 422-5178<tel:%28571%29%20422-5178>
> >
> >
> [http://www.soaschool.com/system/application/images/soacp_architect.jp
> > g]
> >
> > Booz Allen Hamilton |
> > http://www.boozallen.com<http://www.boozallen.com/
> > >
> >
> >
> >
> >
> >
> > --
> > Rick Curtis
> >

RE: [External] Re: OpenJPA Null Update

2013-06-13T20:25:42Z

Rick,

Thank you for your help. Here is the scenario:

1. Get a persistent instance of an entity
2. Detach entity
3. Update values on the entity with non-null values
4. One of these values will be a string value with existing non-trivial data
5. Set the value on this field to null
6. Merge entity
7. All other fields are updated except this value.

Nebiyou Tibebu
________________
Booz | Allen | Hamilton
8283 Greensboro Dr, Mclean, VA 22102
[hidden email]
________________________________________
From: Rick Curtis [[hidden email]]
Sent: Thursday, June 13, 2013 10:31 PM
To: [hidden email]
Subject: RE: [External] Re: OpenJPA Null Update

Well, you are going to have to describe what your scenario is for any of us
to help you out.
On Jun 13, 2013 6:57 PM, "Tibebu, Nebiyou [USA]" <[hidden email]>
wrote:

> I am not getting any errors. It is just being ignored.
>
> Nebiyou Tibebu
> ________________
> Booz | Allen | Hamilton
> 8283 Greensboro Dr, Mclean, VA 22102
> [hidden email]
> ________________________________________
> From: Tibebu, Nebiyou [USA]
> Sent: Thursday, June 13, 2013 5:55 PM
> To: [hidden email]
> Subject: RE: [External] Re: OpenJPA Null Update
>
> Nebiyou Tibebu
> ________________
> Booz | Allen | Hamilton
> 8283 Greensboro Dr, Mclean, VA 22102
> [hidden email]
> ________________________________________
> From: Rick Curtis [[hidden email]]
> Sent: Thursday, June 13, 2013 5:12 PM
> To: users
> Subject: [External] Re: OpenJPA Null Update
>
> Are you getting an error or something... or is it just being ignored? If
> it is being ignored, can you better describe the scenario that you're
> running?
>
>
> On Thu, Jun 13, 2013 at 3:00 PM, Tibebu, Nebiyou [USA] <
> [hidden email]<mailto:[hidden email]>> wrote:
> I am unable to update Nullable VARCHAR columns in Mainframe DB2 to NULL.
> Update to other values, including an empty string works fine. I would
> appreciate some assistance. This is in version 2.2.1.
>
> Nebiyou Tibebu
> Senior Consultant
> 13200 Woodland Park Rd,
> Herndon, VA 21071
> Email: [hidden email]<mailto:[hidden email]>
> Tel: (703) 377-5425<tel:%28703%29%20377-5425>
> Cell: (571) 422-5178<tel:%28571%29%20422-5178>
>
> [http://www.soaschool.com/system/application/images/soacp_architect.jpg]
>
> Booz Allen Hamilton | http://www.boozallen.com<http://www.boozallen.com/
> >
>
>
>
>
>
> --
> Rick Curtis
>

Re: OpenJPA support for JPA 2.1: when?

2013-06-13T19:52:35Z

responses inline...

On Thu, Jun 13, 2013 at 2:27 PM, Kevin Sutter <[hidden email]> wrote:

> Good question, Matthew. This has been brought up a couple of different
> times...
>
> http://openjpa.208410.n2.nabble.com/JPA-2-1-td7215602.html
>
> http://openjpa.208410.n2.nabble.com/DISCUSSION-JPA-2-1-spec-implementation-td7581978.html
>
> So, there's been some interest, but not an overwhelming interest. Not to
> the point of creating a team, figuring out the work effort, and divvying up
> the responsibilities. Contrast that with the JPA 2.0 development effort,
> and there was overwhelming community support and participation. So, I
> think there are a handful of us interested in a JPA 2.1 implementation, but
> more participation is required.
>
> Pardon my surprise, but that sounds just plain bad. That kind of

sentiment threatens to scare users away, IMHO. I have always held OpenJPA
in high esteem as one of the major, credible implementations because it's
always been up to date WRT to the specs (and, let's not kid ourselves, it
hails from Kodo JDO). Frankly, the specs don't move very fast, and at
least previews of them are available well in advance of the actual GA
releases.

> Pinaki has went so far to create a sandbox and start experimenting with an
> implementation. Again, he's a one-man show and can't do it all. Well, he
> probably could, but it would require a bit of work... :-)
>
> https://svn.apache.org/repos/asf/openjpa/sandboxes/21
>
> Well, I would have expected a team of folks on this, not just one. After
all, Pinaki was arguing for expanded fetch plan capabilities in the JPA
expert group based on OpenJPA's current capabilities -- and rightfully so,
I might add.

Maybe we should resurrect that [DISCUSSION] topic

I think you should. Especially with any support customers you or the
OpenJPA project sponsors may have.

> but I'm curious what
> features of JPA 2.1 are of most interest to you? Or, is it just a matter
> of being consistent with the latest specification?
>
> One feature that's worth its development weight is fetch plans, which
OpenJPA, thanks to its current fetch plan implementation, can implement
fairly quickly. Further, OpenJPA's fetch plan support exceeds JPA's
requirement with fetch depth and recursion depth!

Additionally, I just happen to be writing an advanced JPA course right now,
and customers of this course want to use the JPA implementation in the
course that they have settled on in their organization. It just so happens
that the maiden voyage of this course covers JPA 2.1 and is for a customer
that is also an OpenJPA customer. And they're large. Now, I have to tell
them "Sorry, OpenJPA doesn't have plans to implement JPA 2.1". Can you
say, "Bye bye, customer"? EclipseLink & DataNucleus already implement 2.1,
and Hibernate's implementation is in progress. If not for the technical
reasons I gave above, then the need to remain competitive should be enough
to have you assemble a crack 2.1 team ASAP. Don't forget about BatooJPA
making noise (claiming top performance, although I take that with a few
grains of salt) and the NoSQL JPA implementations (DataNucleus, ObjectDB,
and Kundera), not to mention the Spring Data projects. Like it or not, you
are beset on all sides with competition.

Just my $0.02, which might just be worth around $0.029 with the interest
I've accumulated since working with JDO- & JPA-style lightweight
persistence since 1996 and with the expert groups since 2000.

Thanks,

> Kevin
>
>
> On Thu, Jun 13, 2013 at 2:03 PM, Matthew Adams <[hidden email]
> >wrote:
>
> > When will OpenJPA support JPA 2.1?
> >
> > -matthew
> >
> > --
> > mailto:[hidden email] <[hidden email]>
> > skype:matthewadams12
> > googletalk:[hidden email]
> > http://matthewadams.me
> > http://www.linkedin.com/in/matthewadams
> >
>

--
mailto:[hidden email] <[hidden email]>
skype:matthewadams12
googletalk:[hidden email]
http://matthewadams.me
http://www.linkedin.com/in/matthewadams

RE: [External] Re: OpenJPA Null Update

2013-06-13T19:31:15Z

Well, you are going to have to describe what your scenario is for any of us
to help you out.
On Jun 13, 2013 6:57 PM, "Tibebu, Nebiyou [USA]" <[hidden email]>
wrote:

Re: Please vote to publish standard JPA 2.0 & 2.1 jars to Maven

2013-06-13T19:25:46Z

@Chris, that's the problem. There are many sources for these APIs, but no
"official" distro by the expert groups. Every API produced by the JCP
should be published to a Maven repository (preferably Central), with a
groupId of "javax.whatever" and and artifactId of "whatever-api". For
example, the JDO API & TCK has been in open source at Apache for many years
now. Anyone can grab the TCK and run their implementation against it to
confirm compliance, and while the RI, DataNucleus, is not at Apache, it is
still in open source under the Apache license.

@Kevin, I'm on the JPA expert group, too, but it hasn't seemed to do much
good. :) I'd like to see the XML schemas included with this jar so people
have them. I'd also give bonus points for proper OSGi manifest headers (as
JDO has been doing since 3.0.1).

-matthew

On Thu, Jun 13, 2013 at 2:44 PM, Chris Wolf <[hidden email]> wrote:

> The Apache Camel project gets them from the Geronimo project...
>
> <geronimo-jms-spec-version>1.1.1</geronimo-jms-spec-version>
> <geronimo-jpa2-spec-version>1.1</geronimo-jpa2-spec-version>
> <geronimo-jta-spec-version>1.1.1</geronimo-jta-spec-version>
>
> <dependency>
> <groupId>org.apache.geronimo.specs</groupId>
> <artifactId>geronimo-jms_1.1_spec</artifactId>
> <version>${geronimo-jms-spec-version}</version>
> </dependency>
> <dependency>
> <groupId>org.apache.geronimo.specs</groupId>
> <artifactId>geronimo-jpa_2.0_spec</artifactId>
> <version>${geronimo-jpa2-spec-version}</version>
> </dependency>
> <dependency>
> <groupId>org.apache.geronimo.specs</groupId>
> <artifactId>geronimo-jta_1.1_spec</artifactId>
> <version>${geronimo-jta-spec-version}</version>
> </dependency>
>
> On Thu, Jun 13, 2013 at 2:27 PM, Kevin Sutter <[hidden email]> wrote:
> > Right. Many groups require the individual API jar files instead of
> relying
> > on the humongous javaee-api jar. So, I still think this is a valid
> > request. I will keep pushing... :-)
> >
> > Kevin
> >
> >
> > On Thu, Jun 13, 2013 at 1:14 PM, Matthew Adams <[hidden email]
> >wrote:
> >
> >> It looks like the JEE 6 & 7 APIs, including JPA 2.0 & 2.1, were
> released,
> >> but I was more looking for an independent JPA jar.
> >>
> >>
> http://search.maven.org/#artifactdetails%7Cjavax%7Cjavaee-api%7C7.0%7Cjar
> >>
> >>
> http://search.maven.org/#artifactdetails%7Cjavax%7Cjavaee-api%7C6.0%7Cjar
> >>
> >>
> >>
> >> On Thu, Jun 13, 2013 at 12:47 PM, Kevin Sutter <[hidden email]>
> wrote:
> >>
> >> > Hi guys,
> >> > I just found the maven repo on java.net:
> >> > https://maven.java.net/index.html#nexus-search;quick~javax
> >> >
> >> > This looks to have the majority of the API jar files, except as you
> have
> >> > noted -- not javax.persistence.*...
> >> >
> >> > I'm a member of the JPA EG, so I'll post the question there as well.
> >> >
> >> > Thanks, Kevin
> >> >
> >> >
> >> > On Thu, Jun 13, 2013 at 10:15 AM, Kevin Sutter <[hidden email]>
> >> wrote:
> >> >
> >> > > Thanks for these pointers!
> >> > >
> >> > > Matthew, do you know if similar JIRAs are in place for the other
> JSRs?
> >> > > I've been looking for the API jars for several of the JSRs
> associated
> >> > with
> >> > > Java EE 7 and making them available via maven would be ideal.
> >> > >
> >> > > Thanks,
> >> > > Kevin
> >> > >
> >> > >
> >> > > On Thu, Jun 13, 2013 at 10:02 AM, Francesco Chicchiriccò <
> >> > > [hidden email]> wrote:
> >> > >
> >> > >> On 13/06/2013 16:55, Matthew Adams wrote:
> >> > >>
> >> > >>> Please vote for these enhancement requests to get official JPA API
> >> > Maven
> >> > >>> artifacts released.
> >> > >>> https://java.net/jira/browse/**JPA_SPEC-19<
> >> > https://java.net/jira/browse/JPA_SPEC-19>(for JPA 2.0)
> >> > >>> https://java.net/jira/browse/**JPA_SPEC-60<
> >> > https://java.net/jira/browse/JPA_SPEC-60>(for JPA 2.1)
> >> > >>>
> >> > >>
> >> > >> Done.
> >> > >> Regards.
> >> > >>
> >> > >> --
> >> > >> Francesco Chicchiriccò
> >> > >>
> >> > >> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> >> > >> http://people.apache.org/~**ilgrosso/<
> >> > http://people.apache.org/~ilgrosso/>
> >> > >>
> >> > >>
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> mailto:[hidden email] <[hidden email]>
> >> skype:matthewadams12
> >> googletalk:[hidden email]
> >> http://matthewadams.me
> >> http://www.linkedin.com/in/matthewadams
> >>
>

--
mailto:[hidden email] <[hidden email]>
skype:matthewadams12
googletalk:[hidden email]
http://matthewadams.me
http://www.linkedin.com/in/matthewadams

Help needed with "Fields 'xxx' are not a default persistent type" warning

2013-06-13T19:01:17Z

Hi, I'm new to OpenJPA (and JPA) and trying to create the entity-mapping
XML files (classes are unannotated POJOs) for a simple parent-child
database relationship[1] (parent is department, child is employees
working at that department) Right now, here's what I have for the
mapping files:[2] (classes are here: [3]).

While my TestClass[4] (which accesses just the department table right
now) runs fine I'm getting this warning message while running it:
"2213 CompanyPU WARN [main] openjpa.Runtime - Fields "employees" are
not a default persistent type, and do not have any annotations
indicating their persistence strategy. They will be treated as
non-persistent. If you intended for these fields to be persistent, be
sure to annotate them appropriately. Otherwise annotate them with
@Transient."

Google is returning many examples of others with this error, but I'm
still not sure what I'm doing wrong. In the department.orm.xml, I can't
map "employees" as Transient because it is already mapped as
<one-to-many/>, which is AFAICT the right mapping to do. Basically, what
do I have to fix my department.orm.xml[2] (or Department.java class[3])
in order to get rid of the above warning message?

Thanks,
Glen

[1]
https://github.com/gmazza/blog-samples/blob/master/jpa_and_junit/src/main/config/create-database-derby.sql
[2]
https://github.com/gmazza/blog-samples/tree/master/jpa_and_junit/src/main/resources/entities
[3]
https://github.com/gmazza/blog-samples/tree/master/jpa_and_junit/src/main/java/entities
[4]
https://github.com/gmazza/blog-samples/blob/master/jpa_and_junit/src/main/java/TestClass.java

RE: [External] Re: OpenJPA Null Update

2013-06-13T16:57:26Z

I am not getting any errors. It is just being ignored.

Nebiyou Tibebu
________________
Booz | Allen | Hamilton
8283 Greensboro Dr, Mclean, VA 22102
[hidden email]
________________________________________
From: Tibebu, Nebiyou [USA]
Sent: Thursday, June 13, 2013 5:55 PM
To: [hidden email]
Subject: RE: [External] Re: OpenJPA Null Update

Nebiyou Tibebu
________________
Booz | Allen | Hamilton
8283 Greensboro Dr, Mclean, VA 22102
[hidden email]
________________________________________
From: Rick Curtis [[hidden email]]
Sent: Thursday, June 13, 2013 5:12 PM
To: users
Subject: [External] Re: OpenJPA Null Update

Are you getting an error or something... or is it just being ignored? If it is being ignored, can you better describe the scenario that you're running?

On Thu, Jun 13, 2013 at 3:00 PM, Tibebu, Nebiyou [USA] <[hidden email]<mailto:[hidden email]>> wrote:
I am unable to update Nullable VARCHAR columns in Mainframe DB2 to NULL. Update to other values, including an empty string works fine. I would appreciate some assistance. This is in version 2.2.1.

Nebiyou Tibebu
Senior Consultant
13200 Woodland Park Rd,
Herndon, VA 21071
Email: [hidden email]<mailto:[hidden email]>
Tel: (703) 377-5425<tel:%28703%29%20377-5425>
Cell: (571) 422-5178<tel:%28571%29%20422-5178>

[http://www.soaschool.com/system/application/images/soacp_architect.jpg]

Booz Allen Hamilton | http://www.boozallen.com<http://www.boozallen.com/>

--
Rick Curtis

OpenJPA load error

2013-06-13T15:51:39Z

I have an application that has an Entity bean with a composite key represented as an EmbeddedId. It is 3 levels deep. The root object is merged.

The persistence process works fine in simple cases. But while testing with load runner, with 25 users, 15 second ramp up time, this entity causes a commit error. Subsequent to this load test, I am unable to merge this entity until I recycle the server. However, I am able to merge other entities.

This is against a DB2 Mainframe database. I am using OpenJPA 2.2.1.

Nebiyou Tibebu
________________
Booz | Allen | Hamilton
8283 Greensboro Dr, Mclean, VA 22102
[hidden email]

Re: JDK 1.7 seems to be causing an issue with latest snapshot

2013-06-13T15:15:31Z

I'm also having issue with 2.2.2

Re: OpenJPA Null Update

2013-06-13T14:12:46Z

Are you getting an error or something... or is it just being ignored? If it is being ignored, can you better describe the scenario that you're running?

On Thu, Jun 13, 2013 at 3:00 PM, Tibebu, Nebiyou [USA] <[hidden email]> wrote:

I am unable to update Nullable VARCHAR columns in Mainframe DB2 to NULL. Update to other values, including an empty string works fine. I would appreciate some assistance. This is in version 2.2.1.

Nebiyou Tibebu
Senior Consultant

13200 Woodland Park Rd,
Herndon, VA 21071

Email: [hidden email]

Tel: <a href="tel:%28703%29%20377-5425" value="+17033775425" target="_blank">(703) 377-5425

Cell: <a href="tel:%28571%29%20422-5178" value="+15714225178" target="_blank">(571) 422-5178

Booz Allen Hamilton | http://www.boozallen.com

--
Rick Curtis

OpenJPA Null Update

2013-06-13T13:00:01Z

I am unable to update Nullable VARCHAR columns in Mainframe DB2 to NULL. Update to other values, including an empty string works fine. I would appreciate some assistance. This is in version 2.2.1.

Nebiyou Tibebu

Senior Consultant

13200 Woodland Park Rd,

Herndon, VA 21071

Email: [hidden email]

Tel: (703) 377-5425

Cell: (571) 422-5178

Booz Allen Hamilton | http://www.boozallen.com

smime.p7s (18K) Download Attachment

Re: Please vote to publish standard JPA 2.0 & 2.1 jars to Maven

2013-06-13T12:44:17Z

The Apache Camel project gets them from the Geronimo project...

<geronimo-jms-spec-version>1.1.1</geronimo-jms-spec-version>
<geronimo-jpa2-spec-version>1.1</geronimo-jpa2-spec-version>
<geronimo-jta-spec-version>1.1.1</geronimo-jta-spec-version>

<dependency>
<groupId>org.apache.geronimo.specs</groupId>
<artifactId>geronimo-jms_1.1_spec</artifactId>
<version>${geronimo-jms-spec-version}</version>
</dependency>
<dependency>
<groupId>org.apache.geronimo.specs</groupId>
<artifactId>geronimo-jpa_2.0_spec</artifactId>
<version>${geronimo-jpa2-spec-version}</version>
</dependency>
<dependency>
<groupId>org.apache.geronimo.specs</groupId>
<artifactId>geronimo-jta_1.1_spec</artifactId>
<version>${geronimo-jta-spec-version}</version>
</dependency>

On Thu, Jun 13, 2013 at 2:27 PM, Kevin Sutter <[hidden email]> wrote:

> Right. Many groups require the individual API jar files instead of relying
> on the humongous javaee-api jar. So, I still think this is a valid
> request. I will keep pushing... :-)
>
> Kevin
>
>
> On Thu, Jun 13, 2013 at 1:14 PM, Matthew Adams <[hidden email]>wrote:
>
>> It looks like the JEE 6 & 7 APIs, including JPA 2.0 & 2.1, were released,
>> but I was more looking for an independent JPA jar.
>>
>> http://search.maven.org/#artifactdetails%7Cjavax%7Cjavaee-api%7C7.0%7Cjar
>>
>> http://search.maven.org/#artifactdetails%7Cjavax%7Cjavaee-api%7C6.0%7Cjar
>>
>>
>>
>> On Thu, Jun 13, 2013 at 12:47 PM, Kevin Sutter <[hidden email]> wrote:
>>
>> > Hi guys,
>> > I just found the maven repo on java.net:
>> > https://maven.java.net/index.html#nexus-search;quick~javax
>> >
>> > This looks to have the majority of the API jar files, except as you have
>> > noted -- not javax.persistence.*...
>> >
>> > I'm a member of the JPA EG, so I'll post the question there as well.
>> >
>> > Thanks, Kevin
>> >
>> >
>> > On Thu, Jun 13, 2013 at 10:15 AM, Kevin Sutter <[hidden email]>
>> wrote:
>> >
>> > > Thanks for these pointers!
>> > >
>> > > Matthew, do you know if similar JIRAs are in place for the other JSRs?
>> > > I've been looking for the API jars for several of the JSRs associated
>> > with
>> > > Java EE 7 and making them available via maven would be ideal.
>> > >
>> > > Thanks,
>> > > Kevin
>> > >
>> > >
>> > > On Thu, Jun 13, 2013 at 10:02 AM, Francesco Chicchiriccò <
>> > > [hidden email]> wrote:
>> > >
>> > >> On 13/06/2013 16:55, Matthew Adams wrote:
>> > >>
>> > >>> Please vote for these enhancement requests to get official JPA API
>> > Maven
>> > >>> artifacts released.
>> > >>> https://java.net/jira/browse/**JPA_SPEC-19<
>> > https://java.net/jira/browse/JPA_SPEC-19>(for JPA 2.0)
>> > >>> https://java.net/jira/browse/**JPA_SPEC-60<
>> > https://java.net/jira/browse/JPA_SPEC-60>(for JPA 2.1)
>> > >>>
>> > >>
>> > >> Done.
>> > >> Regards.
>> > >>
>> > >> --
>> > >> Francesco Chicchiriccò
>> > >>
>> > >> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
>> > >> http://people.apache.org/~**ilgrosso/<
>> > http://people.apache.org/~ilgrosso/>
>> > >>
>> > >>
>> > >
>> >
>>
>>
>>
>> --
>> mailto:[hidden email] <[hidden email]>
>> skype:matthewadams12
>> googletalk:[hidden email]
>> http://matthewadams.me
>> http://www.linkedin.com/in/matthewadams
>>

Re: ClassCastException - org.apache.openjpa.util.IntId incompatible

2013-06-13T12:35:42Z

Since you are using WebSphere, I would also suggest opening a PMR for this
problem through the normal IBM support channels. If this question does
turn into something "real" and requires an iFix, then you'll need the PMR
and APAR to get the fix delivered anyway...

Since your query works some of the times and not others, my first guess is
that there might be an issue with the SQL cache. You can quickly verify
this by turning off the SQL cache via this property. If that works for
you, at least you have a workaround until a real fix can be determined.

<property name="openjpa.jdbc.QuerySQLCache" value="false">

There are other options with this Cache that might help you out. For
example, if turning off the Cache completely gets you around the problem,
then you could just turn it off for a specific query. Details can be found
in the documentation [1].

Hope this helps get you started.
Kevin

[1]
http://ci.apache.org/projects/openjpa/trunk/docbook/manual.html#ref_guide_cache_querysql

On Thu, Jun 13, 2013 at 1:12 PM, javid.alimohideen <
[hidden email]> wrote:

> Hi,
> I have web application running on Websphere v8.5, that uses a JPA project
> configured as utility project. The application suddenly started throwing
> ClassCastException when performing select query. I have pasted the
> exception
> stack trace. The weird things is it works sometime and at times I get this
> exception. Also, if the DB tables have just one record then everything
> works
> fine, if there are more than 1 record then I see this exception
>
> The entities have a OneToMany and ManyToOne relationships defined.
>
> Caused by: java.lang.ClassCastException: org.apache.openjpa.util.IntId
> incompatible with com.jpa.dom.transactionqueue.BlockTransactionQueue
> at
>
> com.jpa.dom.transactionqueue.BlockCompleteTransaction.pcReplaceField(BlockCompleteTransaction.java)
> at
>
> org.apache.openjpa.kernel.StateManagerImpl.replaceField(StateManagerImpl.java:3174)
> at
>
> org.apache.openjpa.kernel.StateManagerImpl.storeObjectField(StateManagerImpl.java:2602)
> at
>
> org.apache.openjpa.kernel.StateManagerImpl.storeObject(StateManagerImpl.java:2592)
> at
>
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.setMappedBy(JDBCStoreManager.java:476)
> at
>
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:402)
> at
>
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:304)
> at
>
> com.ibm.ws.persistence.jdbc.kernel.WsJpaJDBCStoreManager.initialize(WsJpaJDBCStoreManager.java:149)
> at
>
> org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:112)
> at
>
> org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
> at
> org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:1036)
> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:994)
>
> I can post any additional detail if needed. please, let me know.
>
> Thanks
>
>
>
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/ClassCastException-org-apache-openjpa-util-IntId-incompatible-tp7584145.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: OpenJPA support for JPA 2.1: when?

2013-06-13T12:27:52Z

Good question, Matthew. This has been brought up a couple of different
times...

http://openjpa.208410.n2.nabble.com/JPA-2-1-td7215602.html
http://openjpa.208410.n2.nabble.com/DISCUSSION-JPA-2-1-spec-implementation-td7581978.html

So, there's been some interest, but not an overwhelming interest. Not to
the point of creating a team, figuring out the work effort, and divvying up
the responsibilities. Contrast that with the JPA 2.0 development effort,
and there was overwhelming community support and participation. So, I
think there are a handful of us interested in a JPA 2.1 implementation, but
more participation is required.

Pinaki has went so far to create a sandbox and start experimenting with an
implementation. Again, he's a one-man show and can't do it all. Well, he
probably could, but it would require a bit of work... :-)

https://svn.apache.org/repos/asf/openjpa/sandboxes/21

Maybe we should resurrect that [DISCUSSION] topic, but I'm curious what
features of JPA 2.1 are of most interest to you? Or, is it just a matter
of being consistent with the latest specification?

Thanks,
Kevin

On Thu, Jun 13, 2013 at 2:03 PM, Matthew Adams <[hidden email]>wrote:

> When will OpenJPA support JPA 2.1?
>
> -matthew
>
> --
> mailto:[hidden email] <[hidden email]>
> skype:matthewadams12
> googletalk:[hidden email]
> http://matthewadams.me
> http://www.linkedin.com/in/matthewadams
>

OpenJPA support for JPA 2.1: when?

2013-06-13T12:03:28Z

When will OpenJPA support JPA 2.1?

-matthew

--
mailto:[hidden email] <[hidden email]>
skype:matthewadams12
googletalk:[hidden email]
http://matthewadams.me
http://www.linkedin.com/in/matthewadams

Re: Please vote to publish standard JPA 2.0 & 2.1 jars to Maven

2013-06-13T11:27:18Z

Right. Many groups require the individual API jar files instead of relying
on the humongous javaee-api jar. So, I still think this is a valid
request. I will keep pushing... :-)

Kevin

On Thu, Jun 13, 2013 at 1:14 PM, Matthew Adams <[hidden email]>wrote:

> It looks like the JEE 6 & 7 APIs, including JPA 2.0 & 2.1, were released,
> but I was more looking for an independent JPA jar.
>
> http://search.maven.org/#artifactdetails%7Cjavax%7Cjavaee-api%7C7.0%7Cjar
>
> http://search.maven.org/#artifactdetails%7Cjavax%7Cjavaee-api%7C6.0%7Cjar
>
>
>
> On Thu, Jun 13, 2013 at 12:47 PM, Kevin Sutter <[hidden email]> wrote:
>
> > Hi guys,
> > I just found the maven repo on java.net:
> > https://maven.java.net/index.html#nexus-search;quick~javax
> >
> > This looks to have the majority of the API jar files, except as you have
> > noted -- not javax.persistence.*...
> >
> > I'm a member of the JPA EG, so I'll post the question there as well.
> >
> > Thanks, Kevin
> >
> >
> > On Thu, Jun 13, 2013 at 10:15 AM, Kevin Sutter <[hidden email]>
> wrote:
> >
> > > Thanks for these pointers!
> > >
> > > Matthew, do you know if similar JIRAs are in place for the other JSRs?
> > > I've been looking for the API jars for several of the JSRs associated
> > with
> > > Java EE 7 and making them available via maven would be ideal.
> > >
> > > Thanks,
> > > Kevin
> > >
> > >
> > > On Thu, Jun 13, 2013 at 10:02 AM, Francesco Chicchiriccò <
> > > [hidden email]> wrote:
> > >
> > >> On 13/06/2013 16:55, Matthew Adams wrote:
> > >>
> > >>> Please vote for these enhancement requests to get official JPA API
> > Maven
> > >>> artifacts released.
> > >>> https://java.net/jira/browse/**JPA_SPEC-19<
> > https://java.net/jira/browse/JPA_SPEC-19>(for JPA 2.0)
> > >>> https://java.net/jira/browse/**JPA_SPEC-60<
> > https://java.net/jira/browse/JPA_SPEC-60>(for JPA 2.1)
> > >>>
> > >>
> > >> Done.
> > >> Regards.
> > >>
> > >> --
> > >> Francesco Chicchiriccò
> > >>
> > >> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> > >> http://people.apache.org/~**ilgrosso/<
> > http://people.apache.org/~ilgrosso/>
> > >>
> > >>
> > >
> >
>
>
>
> --
> mailto:[hidden email] <[hidden email]>
> skype:matthewadams12
> googletalk:[hidden email]
> http://matthewadams.me
> http://www.linkedin.com/in/matthewadams
>

Re: Please vote to publish standard JPA 2.0 & 2.1 jars to Maven

2013-06-13T11:14:23Z

It looks like the JEE 6 & 7 APIs, including JPA 2.0 & 2.1, were released,
but I was more looking for an independent JPA jar.

http://search.maven.org/#artifactdetails%7Cjavax%7Cjavaee-api%7C7.0%7Cjar

http://search.maven.org/#artifactdetails%7Cjavax%7Cjavaee-api%7C6.0%7Cjar

On Thu, Jun 13, 2013 at 12:47 PM, Kevin Sutter <[hidden email]> wrote:

> Hi guys,
> I just found the maven repo on java.net:
> https://maven.java.net/index.html#nexus-search;quick~javax
>
> This looks to have the majority of the API jar files, except as you have
> noted -- not javax.persistence.*...
>
> I'm a member of the JPA EG, so I'll post the question there as well.
>
> Thanks, Kevin
>
>
> On Thu, Jun 13, 2013 at 10:15 AM, Kevin Sutter <[hidden email]> wrote:
>
> > Thanks for these pointers!
> >
> > Matthew, do you know if similar JIRAs are in place for the other JSRs?
> > I've been looking for the API jars for several of the JSRs associated
> with
> > Java EE 7 and making them available via maven would be ideal.
> >
> > Thanks,
> > Kevin
> >
> >
> > On Thu, Jun 13, 2013 at 10:02 AM, Francesco Chicchiriccò <
> > [hidden email]> wrote:
> >
> >> On 13/06/2013 16:55, Matthew Adams wrote:
> >>
> >>> Please vote for these enhancement requests to get official JPA API
> Maven
> >>> artifacts released.
> >>> https://java.net/jira/browse/**JPA_SPEC-19<
> https://java.net/jira/browse/JPA_SPEC-19>(for JPA 2.0)
> >>> https://java.net/jira/browse/**JPA_SPEC-60<
> https://java.net/jira/browse/JPA_SPEC-60>(for JPA 2.1)
> >>>
> >>
> >> Done.
> >> Regards.
> >>
> >> --
> >> Francesco Chicchiriccò
> >>
> >> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> >> http://people.apache.org/~**ilgrosso/<
> http://people.apache.org/~ilgrosso/>
> >>
> >>
> >
>

--
mailto:[hidden email] <[hidden email]>
skype:matthewadams12
googletalk:[hidden email]
http://matthewadams.me
http://www.linkedin.com/in/matthewadams

ClassCastException - org.apache.openjpa.util.IntId incompatible

2013-06-13T11:12:26Z

Hi,
I have web application running on Websphere v8.5, that uses a JPA project configured as utility project. The application suddenly started throwing ClassCastException when performing select query. I have pasted the exception stack trace. The weird things is it works sometime and at times I get this exception. Also, if the DB tables have just one record then everything works fine, if there are more than 1 record then I see this exception

The entities have a OneToMany and ManyToOne relationships defined.

Caused by: java.lang.ClassCastException: org.apache.openjpa.util.IntId incompatible with com.jpa.dom.transactionqueue.BlockTransactionQueue
at com.jpa.dom.transactionqueue.BlockCompleteTransaction.pcReplaceField(BlockCompleteTransaction.java)
at org.apache.openjpa.kernel.StateManagerImpl.replaceField(StateManagerImpl.java:3174)
at org.apache.openjpa.kernel.StateManagerImpl.storeObjectField(StateManagerImpl.java:2602)
at org.apache.openjpa.kernel.StateManagerImpl.storeObject(StateManagerImpl.java:2592)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.setMappedBy(JDBCStoreManager.java:476)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:402)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:304)
at com.ibm.ws.persistence.jdbc.kernel.WsJpaJDBCStoreManager.initialize(WsJpaJDBCStoreManager.java:149)
at org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:112)
at org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:1036)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:994)

I can post any additional detail if needed. please, let me know.

Thanks

Re: Please vote to publish standard JPA 2.0 & 2.1 jars to Maven

2013-06-13T10:47:54Z

Hi guys,
I just found the maven repo on java.net:
https://maven.java.net/index.html#nexus-search;quick~javax

This looks to have the majority of the API jar files, except as you have
noted -- not javax.persistence.*...

I'm a member of the JPA EG, so I'll post the question there as well.

Thanks, Kevin

On Thu, Jun 13, 2013 at 10:15 AM, Kevin Sutter <[hidden email]> wrote:

> Thanks for these pointers!
>
> Matthew, do you know if similar JIRAs are in place for the other JSRs?
> I've been looking for the API jars for several of the JSRs associated with
> Java EE 7 and making them available via maven would be ideal.
>
> Thanks,
> Kevin
>
>
> On Thu, Jun 13, 2013 at 10:02 AM, Francesco Chicchiriccò <
> [hidden email]> wrote:
>
>> On 13/06/2013 16:55, Matthew Adams wrote:
>>
>>> Please vote for these enhancement requests to get official JPA API Maven
>>> artifacts released.
>>> https://java.net/jira/browse/**JPA_SPEC-19<https://java.net/jira/browse/JPA_SPEC-19>(for JPA 2.0)
>>> https://java.net/jira/browse/**JPA_SPEC-60<https://java.net/jira/browse/JPA_SPEC-60>(for JPA 2.1)
>>>
>>
>> Done.
>> Regards.
>>
>> --
>> Francesco Chicchiriccò
>>
>> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
>> http://people.apache.org/~**ilgrosso/<http://people.apache.org/~ilgrosso/>
>>
>>
>

Re: XML ORM Mappings, where to define common Mapped Super Class?

2013-06-13T08:40:10Z

Rick, Thanks for the reply.
Yes, we did add all the mapping files to persistence.xml (including the one containing the mapped super class).

One of our application's requirement is to be able to query the physical field name of an attribute of the entity. We find that we were not able to get the meta for the mapped super class in JBoss without also adding in the persistence.xml the following line.

<class>a.b.c.OurMappedSuperclassName</class>

Regards,
Rohit

Re: Please vote to publish standard JPA 2.0 & 2.1 jars to Maven

2013-06-13T08:15:39Z

Thanks for these pointers!

Matthew, do you know if similar JIRAs are in place for the other JSRs?
I've been looking for the API jars for several of the JSRs associated with
Java EE 7 and making them available via maven would be ideal.

Thanks,
Kevin

On Thu, Jun 13, 2013 at 10:02 AM, Francesco Chicchiriccò <
[hidden email]> wrote:

> On 13/06/2013 16:55, Matthew Adams wrote:
>
>> Please vote for these enhancement requests to get official JPA API Maven
>> artifacts released.
>> https://java.net/jira/browse/**JPA_SPEC-19<https://java.net/jira/browse/JPA_SPEC-19>(for JPA 2.0)
>> https://java.net/jira/browse/**JPA_SPEC-60<https://java.net/jira/browse/JPA_SPEC-60>(for JPA 2.1)
>>
>
> Done.
> Regards.
>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~**ilgrosso/<http://people.apache.org/~ilgrosso/>
>
>