date:20070410

You can hook the process-classes phase in maven for the openJPA enhance goal. SO
when ever you do a mvn package it enhances the classes. Works like a charm
outside of Eclipse. This use to work in eclipse and when I imported the project
into eclipse it stopped working. Just can't figure out why

-Original Message-
From: Rahul Thakur [mailto:[EMAIL PROTECTED] 
Sent: April 10, 2007 3:15 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Compiling (build all) in eclipse


Comments inlined...

- Original Message -
From: "Phill Moran" <[EMAIL PROTECTED]>
To: 
Sent: Tuesday, April 10, 2007 5:06 AM
Subject: RE: Compiling (build all) in eclipse


> Eclipse clean workspace
> Import Maven generate project (eclipse:eclispe)
> Build all
> --> Error

There is no enhancement being done here by the Enchancer, Eclipse is 
simply generating class files - I'd imagine that is causing the error.

>
> The same POM builds fine externally through mvn package

What do you mean that POM 'builds' fine through 'mvn package' - do you 
have the OpenJPA Maven plugin set up to enhance classes.

>
> Other interesting points:
> I was getting a NPE from maven build so I turn off the maven builder 
> but that
> had no effect.
> Have also tried clean then build all, and physically deleted all 
> resources
> All openJPAXXX jar are in the lib (repository)
>
> I am certain this is a configuration problem. Just not sure what
>
> Phill
>
> -Original Message-
> From: Patrick Linskey [mailto:[EMAIL PROTECTED]
> Sent: April 9, 2007 12:59 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: RE: Compiling (build all) in eclipse
>
> Hmm. It sounds like maybe the Persistable class hasn't been enhanced.
> It's a surprising error, but it looks like OpenJPA hasn't really 
> gotten into the
> loop at this point, which would explain why you're not seeing anything 
> more
> informative.
>
> Could this explain the situation?
>
> -Patrick
>
> --
> Patrick Linskey
> BEA Systems, Inc.
>
> ___
> Notice:  This email message, together with any attachments, may 
> contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and 
> affiliated
> entities,  that may be confidential,  proprietary,  copyrighted 
> and/or legally
> privileged, and is intended solely for the use of the individual or 
> entity named
> in this message. If you are not the intended recipient, and have 
> received this
> message in error, please immediately return this by email and then 
> delete it.
>
>> -Original Message-
>> From: Phill Moran [mailto:[EMAIL PROTECTED]
>> Sent: Monday, April 09, 2007 9:50 AM
>> To: open-jpa-dev@incubator.apache.org
>> Subject: Compiling (build all) in eclipse
>>
>> Troubles continue Any suggestions for this problem in eclipse???
>>
>> org.springframework.beans.factory.BeanCreationException:
>> Error creating bean
>> with name 'personFactory' defined in file
>> [C:\BidSpec\emall\development\emall\target\classes\application
>> Context.xml]:
>> Initialization of bean failed; nested exception is
>> java.lang.NoSuchMethodError:
>> ca.BidSpec.emall.persistence.Persistable.pcGetManagedFieldCount()I
>> Caused by: java.lang.NoSuchMethodError:
>> ca.BidSpec.emall.persistence.Persistable.pcGetManagedFieldCount()I
>> at ca.BidSpec.emall.stores.Store.(Store.java)
>> at java.lang.Class.forName0(Native Method)
>> at java.lang.Class.forName(Class.java:169)
>> at $Proxy26.(Unknown Source)
>> at
>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>> at
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeCo
>> nstructorAccessorI
>> mpl.java:39)
>> at
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Dele
>> gatingConstructorA
>> ccessorImpl.java:27)
>> at
>> java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>> at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:588)
>> at
>> org.springframework.aop.framework.JdkDynamicAopProxy.getProxy(
>> JdkDynamicAopProxy
>> .java:115)
>> at
>> org.springframework.aop.framework.ProxyFactory.getProxy(ProxyF
>> actory.java:110)
>> at
>> org.springframework.aop.framework.autoproxy.AbstractAutoProxyC
>> reator.createProxy
>> (AbstractAutoProxyCreator.java:401)
>> at
>> org.springframework.aop.framework.autoproxy.AbstractAutoProxyC
>> reator.postProcess
>> AfterInitialization(AbstractAutoProxyCreator.java:279)
>> at
>> org.springframework.beans.factory.support.AbstractAutowireCapa
>> bleBeanFactory.app
>> lyBeanPostProcessorsAfterInitialization(AbstractAutowireCapabl
>> eBeanFactory.java:
>> 318)
>> at
>> org.springframework.beans.factory.support.AbstractAutowireCapa
>> bleBeanFactory.ini
>> tializeBean(AbstractAutowireCapableBeanFactory.java:1119)
>> at
>> org.springframework.beans.factory.support.AbstractAutowireCapa
>> bleBeanFactory.cre
>> ateBean(AbstractAutowireCapableBeanFactory.java:431)
>> at
>> org.springframework.beans.factory.support.AbstractBeanFactory$
>> 1.getObjec

[jira] Created: (OPENJPA-212) Constructor expression permits no other expressions in SELECT clause

2007-04-10 Thread Jacek Laskowski (JIRA)

Constructor expression permits no other expressions in SELECT clause


 Key: OPENJPA-212
 URL: https://issues.apache.org/jira/browse/OPENJPA-212
 Project: OpenJPA
  Issue Type: Bug
  Components: query
Affects Versions: 0.9.7
Reporter: Jacek Laskowski


It seems that it's impossible to run a query with constructor expression beside 
other expressions in SELECT clause. Take a look at the following test that 
finishes with ClassCastException when the first element of resultQuery is 
returned (the 2nd line of the snippet).  Am I doing something plain wrong?

It doesn't work with Hibernate EntityManager 3.3.1, either yet TopLink 
Essentials 2.0 BUILD 40 runs fine.

  Query query = em.createQuery("SELECT NEW 
pl.jaceklaskowski.jpa.PewnaKlasa(p.nazwa, o.imie, o.nazwisko, o.numer), o, 
p.nazwa FROM Projekt p JOIN p.chair o");
  List resultQuery = query.getResultList();
  final Object[] firstElementInQueryResult = resultQuery.get(0);
  assert firstElementInQueryResult.length == 3;
  final Object firstElement = resultQuery.get(0)[0];
  assert firstElement instanceof PewnaKlasa;
  final Object secondElement = resultQuery.get(0)[1];
  assert secondElement instanceof Osoba;
  final Object thirdElement = resultQuery.get(0)[2];
  assert thirdElement instanceof String;

The exception is as follows (the line number is different though as the test 
above is incomplete - no class, imports and alike are shown):

java.lang.ClassCastException: pl.jaceklaskowski.jpa.PewnaKlasa
at 
pl.jaceklaskowski.jpa.OpenJPATest.testConstructorExpr(OpenJPATest.java:19)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

How to set the type of the DB-field using @Externalizer

2007-04-10 Thread Lukas Ruetz

Hello list!

I'm trying to use the @Externalizer annotation but have problems
with the resulting type of the DB-field - it's always a byte-array.

The following code is from the docs - the mapping-tool generates
a table with a field 'url' of type byte-array. I tried to add
the @Type annotation to state that I want a VARCHAR-field but the
type doesn't change.

@Entity
public class MyClass {

  @Persistent
  @Externalizer("toExternalForm")
  @Type(String.class)
  private URL url;

}

In my case I want to use this mechanism to store/retrieve date/time
values for Joda Objects which could be expressed in form of a timestamp
as long. But the same here - the DB-field is a byte-array.
@Persistent
@Externalizer("getMillis")
@Type(Long.class)
private DateMidnight_MyDate;

What do I miss?

I'm using 
openJPA 0.9.7-SNAPSHOT (2007-03-25)
postgresql-JDBC-8.1-408 (JDBC3)
Java 1.5
Postgres 8.1.5.

Thanks in advance
Lukas

Re: Unit testing

2007-04-10 Thread Kevin Sutter

Patrick,
I agree with your concern.  Early on, I was at fault a couple of times with
integrating changes without a corresponding unit testcase.  But, with
"gentle" reminders by the OpenJPA community, I've started to remember.  So,
as a start, I would challenge everyone to start monitoring the commits and
request appropriate unit tests if none were provided.  Either by replying to
openjpa-dev or directly to the JIRA issue.  Maybe with enough "public
reminders", we'll start to get the point across.

I do know that in some cases, creating a unit test for a specific bug is
easier said than done.  Since we are pulling OpenJPA into a larger product
(WebSphere in my case), some of the test scenarios that uncover a bug are
quite complicated and involved.  Creating an individual unit testcase to
reproduce the problem is more effort and when time is critical, we sometimes
go for the quick fix, ensure we don't regress, and integrate the change.
I'm not trying to justify the lack of unit tests for these situations, I'm
just explaining some background on why it happens once in a while.

As far as new "features" being integrated into OpenJPA, there should be no
excuse for lack of unit tests.  We need to provide repeatable testcases for
these new features.  If users are providing patches for these new features,
then it's easy to stop the commit until testcases are provided.  If new
features are committed without corresponding testcases, should we back out
the changes?  I know that's kind of extreme, but it would make a point.  Of
course, then we get into the feature vs bug fix discussion, but if everyone
works at providing unit tests, then it's a moot point.

Kevin

On 4/9/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:

> It should be part of the commit acceptance process.

I agree that it should be part of the process, but I hope that with
sufficient discipline and attention, we can avoid having to enforce this
via automated rules. I definitely make changes that don't merit unit
tests, such as changes to localized strings, null checks, build file
changes, etc.

-Patrick

--
Patrick Linskey
BEA Systems, Inc.

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

> -Original Message-
> From: Phill Moran [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 09, 2007 10:02 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: RE: Unit testing
>
> +1
> It should be part of the commit acceptance process. Otherwise
> OpenJPA will loose
> out to other ORM tools that will be perceived as less buggy.
> What is used for coverage monitoring, clover? We should also
> use checkstyle to
> give some insight into the code as well
>
> Phill
>
> -Original Message-
> From: Patrick Linskey [mailto:[EMAIL PROTECTED]
> Sent: April 9, 2007 12:51 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Unit testing
>
> Hi,
>
> I'm a bit concerned about the lack of unit tests being put
> into OpenJPA as new
> features are added. I understand that often, creating unit tests are
> anticlimactic compared to implementing the feature itself,
> but at least basic
> happy-path testing of new features is pretty essential if we
> want to avoid these
> types of problems. Code inspection is good but, Abe's good
> eyes aside, not as
> reliable as having a unit test that will start failing when a
> feature is broken.
>
> I try to write my test cases first, in a somewhat-modified
> TDD approach.
> I do this because a) I need some sort of harness to
> demonstrate the failure in
> order to isolate and resolve it, and b) I know that
> personally, I'm much more
> likely to write a test while the problem is still interesting
> than after it's
> resolved. In other words, I never (well, rarely) have a
> command-line harness
> that I throw together to demonstrate a problem. I try to
> always use a test case
> instead. This strategy means that the only test-related
> overhead is the effort
> involved to figure out how to programmatically test for failure.
>
> Also, I understand that some things are hard to test. Testing
> SQL or JDBC
> interactions is often percieved to be one of these things. In
> the Kodo codebase,
> we ended up creating various means to get around this; the
> SQLListenerTestCase
> is one such example. It turns out that by extending
> SQLListenerTestCase, it
> becomes trivial to check how much SQL was written and what
> the SQL looks like.
>
> Does anyone else have any thoughts about how to ensure that
> we develop test
> cases as needed?
>
> -Patrick
>
> --
> Patrick

Re: Unit testing

+1. We can do a better job of adding unit tests.

Is there a way to link automated checking with JIRA? For bugs, features, and
improvements we'll want new unit tests. For other changes that don't require
a JIRA report (build files, null checks etc) we won't require new tests.
I'm not sure whether this approach would work if the JIRA report was
resolved/closed without code changes (config issue, classpath problem, etc).

Even if we can't automate the checking with JIRA and svn I think this is a
good rule of thumb. Rather than policing every commit for unit tests we can
just check JIRA reports. It also allows some leeway if you were to commit
unit tests separately from the code changes. If you're reviewing the changes
based primarily on the commit email it might be easier to have them
separate.

On 4/10/07, Kevin Sutter <[EMAIL PROTECTED]> wrote:

Patrick,
I agree with your concern.  Early on, I was at fault a couple of times
with
integrating changes without a corresponding unit testcase.  But, with
"gentle" reminders by the OpenJPA community, I've started to
remember.  So,
as a start, I would challenge everyone to start monitoring the commits and
request appropriate unit tests if none were provided.  Either by replying
to
openjpa-dev or directly to the JIRA issue.  Maybe with enough "public
reminders", we'll start to get the point across.

I do know that in some cases, creating a unit test for a specific bug is
easier said than done.  Since we are pulling OpenJPA into a larger product
(WebSphere in my case), some of the test scenarios that uncover a bug are
quite complicated and involved.  Creating an individual unit testcase to
reproduce the problem is more effort and when time is critical, we
sometimes
go for the quick fix, ensure we don't regress, and integrate the change.
I'm not trying to justify the lack of unit tests for these situations, I'm
just explaining some background on why it happens once in a while.

As far as new "features" being integrated into OpenJPA, there should be no
excuse for lack of unit tests.  We need to provide repeatable testcases
for
these new features.  If users are providing patches for these new
features,
then it's easy to stop the commit until testcases are provided.  If new
features are committed without corresponding testcases, should we back out
the changes?  I know that's kind of extreme, but it would make a
point.  Of
course, then we get into the feature vs bug fix discussion, but if
everyone
works at providing unit tests, then it's a moot point.

Kevin

On 4/9/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:
>
> > It should be part of the commit acceptance process.
>
> I agree that it should be part of the process, but I hope that with
> sufficient discipline and attention, we can avoid having to enforce this
> via automated rules. I definitely make changes that don't merit unit
> tests, such as changes to localized strings, null checks, build file
> changes, etc.
>
> -Patrick
>
> --
> Patrick Linskey
> BEA Systems, Inc.
>
> ___
> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.
>
> > -Original Message-
> > From: Phill Moran [mailto:[EMAIL PROTECTED]
> > Sent: Monday, April 09, 2007 10:02 AM
> > To: open-jpa-dev@incubator.apache.org
> > Subject: RE: Unit testing
> >
> > +1
> > It should be part of the commit acceptance process. Otherwise
> > OpenJPA will loose
> > out to other ORM tools that will be perceived as less buggy.
> > What is used for coverage monitoring, clover? We should also
> > use checkstyle to
> > give some insight into the code as well
> >
> > Phill
> >
> > -Original Message-
> > From: Patrick Linskey [mailto:[EMAIL PROTECTED]
> > Sent: April 9, 2007 12:51 PM
> > To: open-jpa-dev@incubator.apache.org
> > Subject: Unit testing
> >
> > Hi,
> >
> > I'm a bit concerned about the lack of unit tests being put
> > into OpenJPA as new
> > features are added. I understand that often, creating unit tests are
> > anticlimactic compared to implementing the feature itself,
> > but at least basic
> > happy-path testing of new features is pretty essential if we
> > want to avoid these
> > types of problems. Code inspection is good but, Abe's good
> > eyes aside, not as
> > reliable as having a unit test that will start failing when a
> > feature is broken.
> >
> > I try to write my test cases first, in a somewhat-modified
> > TDD approach.
> > I do this because a) I need some sort of harness to
> > demonstrate the failure in
> > order to isolate and resolve it, and

RE: Unit testing

Via test coverage reports  would we not know what parts do not have
corresponding tests and through commit history we would know who added the
fix/feature. So before the next release we can gently remind the committers to
submit the missing test. 
This is likely to be only the occasional committer problem as a regular
committer would monitor the forward progress they would see that a test is
missing and could add it - sort of its own reminder.

Phill

-Original Message-
From: Michael Dick [mailto:[EMAIL PROTECTED] 
Sent: April 10, 2007 10:41 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Unit testing

+1. We can do a better job of adding unit tests.

Is there a way to link automated checking with JIRA? For bugs, features, and
improvements we'll want new unit tests. For other changes that don't require a
JIRA report (build files, null checks etc) we won't require new tests.
I'm not sure whether this approach would work if the JIRA report was
resolved/closed without code changes (config issue, classpath problem, etc).


Even if we can't automate the checking with JIRA and svn I think this is a good
rule of thumb. Rather than policing every commit for unit tests we can just
check JIRA reports. It also allows some leeway if you were to commit unit tests
separately from the code changes. If you're reviewing the changes based
primarily on the commit email it might be easier to have them separate.

On 4/10/07, Kevin Sutter <[EMAIL PROTECTED]> wrote:
>
> Patrick,
> I agree with your concern.  Early on, I was at fault a couple of times 
> with integrating changes without a corresponding unit testcase.  But, 
> with "gentle" reminders by the OpenJPA community, I've started to 
> remember.  So, as a start, I would challenge everyone to start 
> monitoring the commits and request appropriate unit tests if none were 
> provided.  Either by replying to openjpa-dev or directly to the JIRA 
> issue.  Maybe with enough "public reminders", we'll start to get the 
> point across.
>
> I do know that in some cases, creating a unit test for a specific bug 
> is easier said than done.  Since we are pulling OpenJPA into a larger 
> product (WebSphere in my case), some of the test scenarios that 
> uncover a bug are quite complicated and involved.  Creating an 
> individual unit testcase to reproduce the problem is more effort and 
> when time is critical, we sometimes go for the quick fix, ensure we 
> don't regress, and integrate the change.
> I'm not trying to justify the lack of unit tests for these situations, 
> I'm just explaining some background on why it happens once in a while.
>
> As far as new "features" being integrated into OpenJPA, there should 
> be no excuse for lack of unit tests.  We need to provide repeatable 
> testcases for these new features.  If users are providing patches for 
> these new features, then it's easy to stop the commit until testcases 
> are provided.  If new features are committed without corresponding 
> testcases, should we back out the changes?  I know that's kind of 
> extreme, but it would make a point.  Of course, then we get into the 
> feature vs bug fix discussion, but if everyone works at providing unit 
> tests, then it's a moot point.
>
> Kevin
>
> On 4/9/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:
> >
> > > It should be part of the commit acceptance process.
> >
> > I agree that it should be part of the process, but I hope that with 
> > sufficient discipline and attention, we can avoid having to enforce 
> > this via automated rules. I definitely make changes that don't merit 
> > unit tests, such as changes to localized strings, null checks, build 
> > file changes, etc.
> >
> > -Patrick
> >
> > --
> > Patrick Linskey
> > BEA Systems, Inc.
> >
> > 
> > ___
> > Notice:  This email message, together with any attachments, may 
> > contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  
> > affiliated entities,  that may be confidential,  proprietary,  
> > copyrighted  and/or legally privileged, and is intended solely for 
> > the use of the individual or entity named in this message. If you 
> > are not the intended recipient, and have received this message in 
> > error, please immediately return this by email and then delete it.
> >
> > > -Original Message-
> > > From: Phill Moran [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, April 09, 2007 10:02 AM
> > > To: open-jpa-dev@incubator.apache.org
> > > Subject: RE: Unit testing
> > >
> > > +1
> > > It should be part of the commit acceptance process. Otherwise 
> > > OpenJPA will loose out to other ORM tools that will be perceived 
> > > as less buggy.
> > > What is used for coverage monitoring, clover? We should also use 
> > > checkstyle to give some insight into the code as well
> > >
> > > Phill
> > >
> > > -Original Message-
> > > From: Patrick Linskey [mailto:[EMAIL PROTECTED]
> > > Sent: April 9, 2007 12:51 PM
>

Re: Unit testing

I think we need to take responsibility for this individually. Test  
coverage reports usually show woeful under-testing, so it's really up  
to the developer to know whether a test case is needed or not.


It might be necessary at times to commit an urgent fix without having  
a full test suite to prove that the fix works, but best practice is  
to provide a test case along with the fix. We could make a guideline  
that until a test case is checked in, the JIRA issue should remain  
open. And when reviewing others' work, the missing test case can be  
used as a reason to "un-resolve" an issue.


But I agree with Kevin that integrating new features without test  
cases is evil.


In my experience, reminders long after the issue is resolved don't  
really work that well.


Craig

On Apr 10, 2007, at 7:57 AM, Phill Moran wrote:


Via test coverage reports  would we not know what parts do not have
corresponding tests and through commit history we would know who  
added the
fix/feature. So before the next release we can gently remind the  
committers to

submit the missing test.
This is likely to be only the occasional committer problem as a  
regular
committer would monitor the forward progress they would see that a  
test is

missing and could add it - sort of its own reminder.

Phill

-Original Message-
From: Michael Dick [mailto:[EMAIL PROTECTED]
Sent: April 10, 2007 10:41 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Unit testing

+1. We can do a better job of adding unit tests.

Is there a way to link automated checking with JIRA? For bugs,  
features, and
improvements we'll want new unit tests. For other changes that  
don't require a

JIRA report (build files, null checks etc) we won't require new tests.
I'm not sure whether this approach would work if the JIRA report was
resolved/closed without code changes (config issue, classpath  
problem, etc).



Even if we can't automate the checking with JIRA and svn I think  
this is a good
rule of thumb. Rather than policing every commit for unit tests we  
can just
check JIRA reports. It also allows some leeway if you were to  
commit unit tests
separately from the code changes. If you're reviewing the changes  
based
primarily on the commit email it might be easier to have them  
separate.


On 4/10/07, Kevin Sutter <[EMAIL PROTECTED]> wrote:


Patrick,
I agree with your concern.  Early on, I was at fault a couple of  
times

with integrating changes without a corresponding unit testcase.  But,
with "gentle" reminders by the OpenJPA community, I've started to
remember.  So, as a start, I would challenge everyone to start
monitoring the commits and request appropriate unit tests if none  
were

provided.  Either by replying to openjpa-dev or directly to the JIRA
issue.  Maybe with enough "public reminders", we'll start to get the
point across.

I do know that in some cases, creating a unit test for a specific bug
is easier said than done.  Since we are pulling OpenJPA into a larger
product (WebSphere in my case), some of the test scenarios that
uncover a bug are quite complicated and involved.  Creating an
individual unit testcase to reproduce the problem is more effort and
when time is critical, we sometimes go for the quick fix, ensure we
don't regress, and integrate the change.
I'm not trying to justify the lack of unit tests for these  
situations,
I'm just explaining some background on why it happens once in a  
while.


As far as new "features" being integrated into OpenJPA, there should
be no excuse for lack of unit tests.  We need to provide repeatable
testcases for these new features.  If users are providing patches for
these new features, then it's easy to stop the commit until testcases
are provided.  If new features are committed without corresponding
testcases, should we back out the changes?  I know that's kind of
extreme, but it would make a point.  Of course, then we get into the
feature vs bug fix discussion, but if everyone works at providing  
unit

tests, then it's a moot point.

Kevin

On 4/9/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:



It should be part of the commit acceptance process.


I agree that it should be part of the process, but I hope that with
sufficient discipline and attention, we can avoid having to enforce
this via automated rules. I definitely make changes that don't merit
unit tests, such as changes to localized strings, null checks, build
file changes, etc.

-Patrick

--
Patrick Linskey
BEA Systems, Inc.


___
Notice:  This email message, together with any attachments, may
contain information  of  BEA Systems,  Inc.,  its subsidiaries  and
affiliated entities,  that may be confidential,  proprietary,
copyrighted  and/or legally privileged, and is intended solely for
the use of the individual or entity named in this message. If you
are not the intended recipient, and have received this message in
error, please immediately return thi

Re: How to set the type of the DB-field using @Externalizer

2007-04-10 Thread Abe White

> I'm trying to use the @Externalizer annotation but have problems
> with the resulting type of the DB-field - it's always a byte-array.

You shouldn't need the @Type annotation -- the type will be inferred  
from the return type of the externalizer method.  Are you dropping  
the database table in between attempts?  It's possible that if your  
first attempt resulted in a byte array column because of some  
misconfiguration, OpenJPA will think it is supposed to reuse that  
column on subsequent mapping attempts, because technically it can fit  
anything in a byte-array column.

Notice:  This email message, together with any attachments, may contain 
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
entities,  that may be confidential,  proprietary,  copyrighted  and/or legally 
privileged, and is intended solely for the use of the individual or entity 
named in this message. If you are not the intended recipient, and have received 
this message in error, please immediately return this by email and then delete 
it.

RE: Unit testing

+1
I like this idea you can't close the item without a test case. 

Phill

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: April 10, 2007 11:25 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Unit testing

I think we need to take responsibility for this individually. Test coverage
reports usually show woeful under-testing, so it's really up to the developer to
know whether a test case is needed or not.

It might be necessary at times to commit an urgent fix without having a full
test suite to prove that the fix works, but best practice is to provide a test
case along with the fix. We could make a guideline that until a test case is
checked in, the JIRA issue should remain open. And when reviewing others' work,
the missing test case can be used as a reason to "un-resolve" an issue.

But I agree with Kevin that integrating new features without test cases is evil.

In my experience, reminders long after the issue is resolved don't really work
that well.

Craig

On Apr 10, 2007, at 7:57 AM, Phill Moran wrote:

> Via test coverage reports  would we not know what parts do not have 
> corresponding tests and through commit history we would know who added 
> the fix/feature. So before the next release we can gently remind the 
> committers to submit the missing test.
> This is likely to be only the occasional committer problem as a 
> regular committer would monitor the forward progress they would see 
> that a test is missing and could add it - sort of its own reminder.
>
> Phill
>
> -Original Message-
> From: Michael Dick [mailto:[EMAIL PROTECTED]
> Sent: April 10, 2007 10:41 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: Unit testing
>
> +1. We can do a better job of adding unit tests.
>
> Is there a way to link automated checking with JIRA? For bugs, 
> features, and improvements we'll want new unit tests. For other 
> changes that don't require a JIRA report (build files, null checks 
> etc) we won't require new tests.
> I'm not sure whether this approach would work if the JIRA report was 
> resolved/closed without code changes (config issue, classpath problem, 
> etc).
>
>
> Even if we can't automate the checking with JIRA and svn I think this 
> is a good rule of thumb. Rather than policing every commit for unit 
> tests we can just check JIRA reports. It also allows some leeway if 
> you were to commit unit tests separately from the code changes. If 
> you're reviewing the changes based primarily on the commit email it 
> might be easier to have them separate.
>
> On 4/10/07, Kevin Sutter <[EMAIL PROTECTED]> wrote:
>>
>> Patrick,
>> I agree with your concern.  Early on, I was at fault a couple of 
>> times with integrating changes without a corresponding unit testcase.  
>> But, with "gentle" reminders by the OpenJPA community, I've started 
>> to remember.  So, as a start, I would challenge everyone to start 
>> monitoring the commits and request appropriate unit tests if none 
>> were provided.  Either by replying to openjpa-dev or directly to the 
>> JIRA issue.  Maybe with enough "public reminders", we'll start to get 
>> the point across.
>>
>> I do know that in some cases, creating a unit test for a specific bug 
>> is easier said than done.  Since we are pulling OpenJPA into a larger 
>> product (WebSphere in my case), some of the test scenarios that 
>> uncover a bug are quite complicated and involved.  Creating an 
>> individual unit testcase to reproduce the problem is more effort and 
>> when time is critical, we sometimes go for the quick fix, ensure we 
>> don't regress, and integrate the change.
>> I'm not trying to justify the lack of unit tests for these 
>> situations, I'm just explaining some background on why it happens 
>> once in a while.
>>
>> As far as new "features" being integrated into OpenJPA, there should 
>> be no excuse for lack of unit tests.  We need to provide repeatable 
>> testcases for these new features.  If users are providing patches for 
>> these new features, then it's easy to stop the commit until testcases 
>> are provided.  If new features are committed without corresponding 
>> testcases, should we back out the changes?  I know that's kind of 
>> extreme, but it would make a point.  Of course, then we get into the 
>> feature vs bug fix discussion, but if everyone works at providing 
>> unit tests, then it's a moot point.
>>
>> Kevin
>>
>> On 4/9/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:
>>>
 It should be part of the commit acceptance process.
>>>
>>> I agree that it should be part of the process, but I hope that with 
>>> sufficient discipline and attention, we can avoid having to enforce 
>>> this via automated rules. I definitely make changes that don't merit 
>>> unit tests, such as changes to localized strings, null checks, build 
>>> file changes, etc.
>>>
>>> -Patrick
>>>
>>> --
>>> Patrick Linskey
>>> BEA Systems, Inc.
>>>
>>> ___

RE: Unit testing

> I think we need to take responsibility for this individually. Test  
> coverage reports usually show woeful under-testing, so it's 
> really up  
> to the developer to know whether a test case is needed or not.

Currently, this will definitely be the case in OpenJPA, since the bulk
of the Kodo test cases were JDO-based, and we at BEA have not yet ported
them out to OpenJPA.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 10, 2007 8:25 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: Unit testing
> 
> I think we need to take responsibility for this individually. Test  
> coverage reports usually show woeful under-testing, so it's 
> really up  
> to the developer to know whether a test case is needed or not.
> 
> It might be necessary at times to commit an urgent fix 
> without having  
> a full test suite to prove that the fix works, but best practice is  
> to provide a test case along with the fix. We could make a guideline  
> that until a test case is checked in, the JIRA issue should remain  
> open. And when reviewing others' work, the missing test case can be  
> used as a reason to "un-resolve" an issue.
> 
> But I agree with Kevin that integrating new features without test  
> cases is evil.
> 
> In my experience, reminders long after the issue is resolved don't  
> really work that well.
> 
> Craig
> 
> On Apr 10, 2007, at 7:57 AM, Phill Moran wrote:
> 
> > Via test coverage reports  would we not know what parts do not have
> > corresponding tests and through commit history we would know who  
> > added the
> > fix/feature. So before the next release we can gently remind the  
> > committers to
> > submit the missing test.
> > This is likely to be only the occasional committer problem as a  
> > regular
> > committer would monitor the forward progress they would see that a  
> > test is
> > missing and could add it - sort of its own reminder.
> >
> > Phill
> >
> > -Original Message-
> > From: Michael Dick [mailto:[EMAIL PROTECTED]
> > Sent: April 10, 2007 10:41 AM
> > To: open-jpa-dev@incubator.apache.org
> > Subject: Re: Unit testing
> >
> > +1. We can do a better job of adding unit tests.
> >
> > Is there a way to link automated checking with JIRA? For bugs,  
> > features, and
> > improvements we'll want new unit tests. For other changes that  
> > don't require a
> > JIRA report (build files, null checks etc) we won't require 
> new tests.
> > I'm not sure whether this approach would work if the JIRA report was
> > resolved/closed without code changes (config issue, classpath  
> > problem, etc).
> >
> >
> > Even if we can't automate the checking with JIRA and svn I think  
> > this is a good
> > rule of thumb. Rather than policing every commit for unit tests we  
> > can just
> > check JIRA reports. It also allows some leeway if you were to  
> > commit unit tests
> > separately from the code changes. If you're reviewing the changes  
> > based
> > primarily on the commit email it might be easier to have them  
> > separate.
> >
> > On 4/10/07, Kevin Sutter <[EMAIL PROTECTED]> wrote:
> >>
> >> Patrick,
> >> I agree with your concern.  Early on, I was at fault a couple of  
> >> times
> >> with integrating changes without a corresponding unit 
> testcase.  But,
> >> with "gentle" reminders by the OpenJPA community, I've started to
> >> remember.  So, as a start, I would challenge everyone to start
> >> monitoring the commits and request appropriate unit tests if none  
> >> were
> >> provided.  Either by replying to openjpa-dev or directly 
> to the JIRA
> >> issue.  Maybe with enough "public reminders", we'll start 
> to get the
> >> point across.
> >>
> >> I do know that in some cases, creating a unit test for a 
> specific bug
> >> is easier said than done.  Since we are pulling OpenJPA 
> into a larger
> >> product (WebSphere in my case), some of the test scenarios that
> >> uncover a bug are quite complicated and involved.  Creating an
> >> individual unit testcase to reproduce the problem is more 
> effort and
> >> when time is critical, we sometimes go for the quick fix, ensure we
> >> don't regress, and integrate the change.
> >> I'm not trying to justify the lack of unit tests for these  
> >> situations,
> >> I'm just explaining some background on why it happens once in a  
> >> while.
> >>
> >> As far as new "features" being integr

Re: How to set the type of the DB-field using @Externalizer

2007-04-10 Thread Lukas Ruetz

Hi!

Am Dienstag, 10. April 2007 17:01 schrieb Abe White:
> > I'm trying to use the @Externalizer annotation but have problems
> > with the resulting type of the DB-field - it's always a byte-array.
>
> You shouldn't need the @Type annotation -- the type will be inferred
>
> from the return type of the externalizer method.  Are you dropping
> the database table in between attempts? It's possible that if your 
> first attempt resulted in a byte array column because of some
> misconfiguration, OpenJPA will think it is supposed to reuse that
> column on subsequent mapping attempts, because technically it can fit
> anything in a byte-array column.

I always drop the tables between my attempts. I have also tried to drop
the whole DB but that doesn't help.

for
 @Persistent
 @Externalizer("toString")
 private URI uri;

the mapping-tool prints out:
 "uri" has mapping 
strategy "org.apache.openjpa.jdbc.meta.strats.HandlerFieldStrategy"

There are no warning or erros that say that there's something wrong.
Here is my META-INF/persistence.xml :

http://java.sun.com/xml/ns/persistence"; version="1.0">
  
domain.JPATest

  
  
  
  
  

  


Anything else where I could look first?

Thanks
Lukas

[jira] Commented: (OPENJPA-201) Mapping Tool ignores the @JoinColumn annotation in a @ManyToOne mapping if the table argument is used

2007-04-10 Thread Abe White (JIRA)


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

Abe White commented on OPENJPA-201:
---

I'm sorry, but I don't understand what you're trying to accomplish.  You say 
that Winery maps to two tables, but I don't see any SecondaryTable defined for 
it.  You give the results of various annotations, but I don't know what the 
actual schema looks like or what relations you want mapped to what columns.

> Mapping Tool ignores the @JoinColumn annotation in a @ManyToOne mapping if 
> the table argument is used
> -
>
> Key: OPENJPA-201
> URL: https://issues.apache.org/jira/browse/OPENJPA-201
> Project: OpenJPA
>  Issue Type: Bug
> Environment: 0.9.7-incubating-SNAPSHOT
>Reporter: George Hongell
>Priority: Minor
> Attachments: Wine.java, Winery.java
>
>
> @Entity
> @Table(name="CxWine")
> public class Wine {
>   @Id
>   private Integer wineid;
> ...
>   @ManyToOne()
> @JoinColumn(name="NEW_WINERY_WINERYID", referencedColumnName="WINERYID",  
> table="cxWinery")
> //ignored @JoinColumn(name="NEW_WINERY_WINERYID", 
> referencedColumnName="WINERYID",  table="cxWinery")
> //ignored @JoinColumn(name="NEW_WINERY_WINERYID", 
> referencedColumnName="WINERYID",  table="cxWinery")
> //ignored  @JoinColumn(name="NEW_WINERY_WINERYID",  table="cxWINERY")
> //ok  @JoinColumn(name="NEW_WINERY_WINERYID", referencedColumnName="wineryid")
> //ok  @JoinColumn(name="NEW_WINERY_WINERYID")
>   private Winery winery;
> ...
> }
> generates
> 2744  cxwineTour  TRACE  [main] openjpa.jdbc.SQL -  98698722> executing stmnt 1325027066 CREATE TABLE CxWine (wineid INTEGER NOT 
> NULL, cost SMALLINT, description VARCHAR(254), minimumHoldYears INTEGER, 
> rating SMALLINT, stockCount INTEGER, type VARCHAR(20), version INTEGER, 
> alcoholPercent DOUBLE, ava VARCHAR(40), bottler VARCHAR(40), brandName 
> VARCHAR(40), labelWineClass VARCHAR(20), labelWineColor VARCHAR(20), 
> estateBottled SMALLINT, hasSulfites SMALLINT, labelid INTEGER, mlContents 
> INTEGER, qualityDesignation VARCHAR(40), vineyardName VARCHAR(40), vintage 
> TIMESTAMP, wineName VARCHAR(40), winery_wineryid INTEGER, PRIMARY KEY 
> (wineid))

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-91) java.lang.VerifyError on websphere after application reload

2007-04-10 Thread david zhang (JIRA)


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

david zhang commented on OPENJPA-91:


Hi, Patrick, what kind of DB2 driver info we should put into the config? DB2 
connection pool driver class name?

> java.lang.VerifyError on websphere after application reload
> ---
>
> Key: OPENJPA-91
> URL: https://issues.apache.org/jira/browse/OPENJPA-91
> Project: OpenJPA
>  Issue Type: Bug
> Environment: Using OpenJPA (openjpa-all-0.9.6-incubating.jar) in 
> Rational Developer 7 ( Websphere 6.1 test environment ) connected to Oracle 
> 9.2 database.
> OS: WinXP SP2
>Reporter: Anders Monrad
>Priority: Minor
> Fix For: 0.9.8
>
>
> Hi ..
> Not sure if this is a bug or just the way websphere reacts to openjpa. 
> I have a small test program using OpenJPA against an Oracle database. I am 
> running this program in the Websphere 6.1 test environment included with 
> Rational Developer 7. This is all working just fine. But when I make changes 
> to some ressource in the application, the chagnes are automatically published 
> to the test environment and the app is restarted. After this I get the 
> Exception below, whenever I try to access an EntityManager. 
> If I restart the entire server, the app is running fine again. So I guess 
> this is related to restarting the application.
> Caused by: java.lang.VerifyError: class loading constraint violated (class: 
> org/apache/openjpa/kernel/BrokerImpl method: 
> newQueryImpl(Ljava/lang/String;Lorg/apache/openjpa/kernel/StoreQuery;)Lorg/apache/openjpa/kernel/QueryImpl;)
>  at pc: 0
>   at java.lang.J9VMInternals.verifyImpl(Native Method)
>   at java.lang.J9VMInternals.verify(J9VMInternals.java:59)
>   at java.lang.J9VMInternals.initialize(J9VMInternals.java:120)
>   at java.lang.Class.forNameImpl(Native Method)
>   at java.lang.Class.forName(Class.java:131)
>   at 
> org.apache.openjpa.conf.OpenJPAConfigurationImpl.class$(OpenJPAConfigurationImpl.java:65)
>   at 
> org.apache.openjpa.conf.OpenJPAConfigurationImpl.(OpenJPAConfigurationImpl.java:182)
>   at 
> org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.(JDBCConfigurationImpl.java:110)
>   at 
> org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.(JDBCConfigurationImpl.java:100)
>   at 
> org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.(JDBCConfigurationImpl.java:91)
>   at 
> org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newInstance(JDBCBrokerFactory.java:55)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:615)
>   at org.apache.openjpa.kernel.Bootstrap.invokeFactory(Bootstrap.java:117)
>   at 
> org.apache.openjpa.kernel.Bootstrap.newBrokerFactory(Bootstrap.java:57)
>   at 
> org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:70)
>   at 
> org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:78)
>   at 
> javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:83)
>   at 
> javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:60)
>   at 
> util.EntityManagerFactoryHelper.getEntityManagerFactory(EntityManagerFactoryHelper.java:22)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-211) CLONE -java.lang.VerifyError on websphere 6.1 with Spring 2.0.3 and OpenJpa 0.96/0.97

2007-04-10 Thread david zhang (JIRA)


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

david zhang commented on OPENJPA-211:
-

Hi, Patrick, do you have any working persistence.xml with DB2 on WebSphere 6.1 
using DataSource? Getting all kind of IllegalArgumentException really frustrate 
me.

> CLONE -java.lang.VerifyError on websphere 6.1 with Spring 2.0.3 and OpenJpa 
> 0.96/0.97
> -
>
> Key: OPENJPA-211
> URL: https://issues.apache.org/jira/browse/OPENJPA-211
> Project: OpenJPA
>  Issue Type: Bug
>  Components: kernel
>Affects Versions: 0.9.6
> Environment: Using OpenJPA (openjpa-all-0.9.6-incubating.jar) in 
> Rational Developer 7 ( Websphere 6.1 test environment ) connected to DB2 V9.1.
> OS: WinXP SP2
>Reporter: david zhang
>Priority: Blocker
> Fix For: 0.9.8
>
> Attachments: applicationContext.xml, mytestdata.jar, persistence.xml
>
>
> Hi, if I use the OpenJPA shipped with Spring 2.0.3, I got the following error 
> when start application:
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'entityManagerFactory' defined in ServletContext resource 
> [/WEB-INF/applicationContext.xml]: Invocation of init method failed; nested 
> exception is java.lang.VerifyError: class loading constraint violated (class: 
> org/apache/openjpa/kernel/BrokerImpl method: 
> newQueryImpl(Ljava/lang/String;Lorg/apache/openjpa/kernel/StoreQuery;)Lorg/apache/openjpa/kernel/QueryImpl;)
>  at pc: 0
> Caused by: 
> java.lang.VerifyError: class loading constraint violated (class: 
> org/apache/openjpa/kernel/BrokerImpl method: 
> newQueryImpl(Ljava/lang/String;Lorg/apache/openjpa/kernel/StoreQuery;)Lorg/apache/openjpa/kernel/QueryImpl;)
>  at pc: 0
>   at java.lang.J9VMInternals.verifyImpl(Native Method)
>   at java.lang.J9VMInternals.verify(J9VMInternals.java:59)
>   at java.lang.J9VMInternals.initialize(J9VMInternals.java:120)
>   at java.lang.Class.forNameImpl(Native Method)
>   at java.lang.Class.forName(Class.java:131)
>   at 
> org.apache.openjpa.conf.OpenJPAConfigurationImpl.class$(OpenJPAConfigurationImpl.java:65)
>   at 
> org.apache.openjpa.conf.OpenJPAConfigurationImpl.(OpenJPAConfigurationImpl.java:182)
>   at 
> org.apache.openjpa.conf.OpenJPAConfigurationImpl.(OpenJPAConfigurationImpl.java:154)
>   at 
> org.apache.openjpa.conf.OpenJPAConfigurationImpl.(OpenJPAConfigurationImpl.java:145)
>   at 
> org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.(PersistenceProviderImpl.java:114)
>   at 
> org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.(PersistenceProviderImpl.java:106)
>   at 
> org.apache.openjpa.persistence.PersistenceProviderImpl.createContainerEntityManagerFactory(PersistenceProviderImpl.java:92)
>   at 
> org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:214)
>   at 
> org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:251)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1143)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1110)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:431)
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:254)
>   at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:144)
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:251)
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:163)
>   at 
> org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:244)
>   at 
> org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:233)
>   at 
> org.springframework.beans.factory.BeanFactoryUtils.beansOfTypeIncludingAncestors(BeanFactoryUtils.java:205)
>   at 
> org.springframework.beans.factory.BeanFactoryUtils.beanOfTypeIncludingAncestors(BeanFactoryUtils.java:292)
>   at 
> org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.findDefaultEntityManagerFactory(PersistenceAnnotationBeanPostProcessor.java:4

Re: [jira] Commented: (OPENJPA-91) java.lang.VerifyError on websphere after application reload

2007-04-10 Thread Don Brady


This has been commented on before.

You need to rerun the Enhancer on any Entity classes that are 
re-published and stop and start WebSphere.


It is best to turn off automatic publishing in WebSphere/RAD.

You can still run it in debug mode under RAD and change anything other 
than Entities without needing to restart.  I do this all the time.





Hi ..
Not sure if this is a bug or just the way websphere reacts to openjpa. 
I have a small test program using OpenJPA against an Oracle database. I am running this program in the Websphere 6.1 test environment included with Rational Developer 7. This is all working just fine. But when I make changes to some ressource in the application, the chagnes are automatically published to the test environment and the app is restarted. After this I get the Exception below, whenever I try to access an EntityManager. 
If I restart the entire server, the app is running fine again. So I guess this is related to restarting the application.

Caused by: java.lang.VerifyError: class loading constraint violated (class: 
org/apache/openjpa/kernel/BrokerImpl method: 
newQueryImpl(Ljava/lang/String;Lorg/apache/openjpa/kernel/StoreQuery;)Lorg/apache/openjpa/kernel/QueryImpl;)
 at pc: 0
at java.lang.J9VMInternals.verifyImpl(Native Method)
at java.lang.J9VMInternals.verify(J9VMInternals.java:59)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:120)
at java.lang.Class.forNameImpl(Native Method)
at java.lang.Class.forName(Class.java:131)
at 
org.apache.openjpa.conf.OpenJPAConfigurationImpl.class$(OpenJPAConfigurationImpl.java:65)
at 
org.apache.openjpa.conf.OpenJPAConfigurationImpl.(OpenJPAConfigurationImpl.java:182)
at 
org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.(JDBCConfigurationImpl.java:110)
at 
org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.(JDBCConfigurationImpl.java:100)
at 
org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.(JDBCConfigurationImpl.java:91)
at 
org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newInstance(JDBCBrokerFactory.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at org.apache.openjpa.kernel.Bootstrap.invokeFactory(Bootstrap.java:117)
at 
org.apache.openjpa.kernel.Bootstrap.newBrokerFactory(Bootstrap.java:57)
at 
org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:70)
at 
org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:78)
at 
javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:83)
at 
javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:60)
at 
util.EntityManagerFactoryHelper.getEntityManagerFactory(EntityManagerFactoryHelper.java:22)

@Column with precision and scale - how does it work?


Hi,

I wonder how I could restrict what values are inserted into a table
using @Column(precision=5, scale=2). When does it matter?

I'm using OpenJPA 0.9.7-SNAPSHOT with Derby and with the following:

   @Column(precision = 5, scale = 2)
   public double getPensja() {
   return pensja;
   }

OpenJPA executes the following CREATE

2969  derbyPU  TRACE  [main] openjpa.jdbc.SQL -  executing stmnt 23119024 CREATE TABLE Osoba (numer BIGINT
NOT NULL, dzienImienin TIMESTAMP, dzienUrodzin
TIMESTAMP, imie VARCHAR(255), kraj VARCHAR(255), nazwisko
VARCHAR(255), wersja INTEGER, pensja DOUBLE, tytul VARCHAR(255),
PRIMARY KEY (numer))

How could I restrict the precision and scale of the pensja field? Is
the columnDefinition attribute of @Column the last resort? When is the
others used? What databases are supported?

Jacek

--
Jacek Laskowski
http://www.JacekLaskowski.pl

Re: How to set the type of the DB-field using @Externalizer

2007-04-10 Thread Abe White

I can't reproduce this.  When I leave out the @Persistent annotation  
on the field or replace it with @Basic, I do indeed end up with a  
binary column.  But if I correctly include the @Persistent annotation  
along with the @Externalizer, I get a varchar column.  Can you narrow  
down your entity to the smallest possible class that exhibits the  
problem and post it to the list so we can try to reproduce the error?

Notice:  This email message, together with any attachments, may contain 
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
entities,  that may be confidential,  proprietary,  copyrighted  and/or legally 
privileged, and is intended solely for the use of the individual or entity 
named in this message. If you are not the intended recipient, and have received 
this message in error, please immediately return this by email and then delete 
it.

Re: PCEnhance


On 4/10/07, Phill Moran <[EMAIL PROTECTED]> wrote:

Through maven and eclipse. I have log level trace set in persistence.xml but
that has no impact. Maven is reporting that PCEnhance is returning non-zero and
no reason why. So trace is set on either CLI or maven (same thing really). I
don't remember seeing it anywhere in the docs from maven is it in Configuration
and what is the tag?


Use



in your persistence.xml file (I think SQL=TRACE is not necessary). I'm
using OpenJPA 0.9.7-SNAPSHOT's PCEnhancer from within M2 with
maven-antrun-plugin. It gives a lot of information, i.e.

[java] 62  derbyPU  TRACE  [main] openjpa.MetaData - Found 3
classes with metadata in 0 milliseconds.
[java] 62  derbyPU  TRACE  [main] openjpa.Tool - Enhancer running
on type "class pl.jaceklaskowski.jpa.entity.PracownikSpecjalny".
[java] 125  derbyPU  TRACE  [main] openjpa.MetaData - Loading
metadata for "class pl.jaceklaskowski.jpa.entity.PracownikSpecjalny"
under mode "[META]".
[java] 140  derbyPU  TRACE  [main] openjpa.MetaData - Parsing
class "pl.jaceklaskowski.jpa.entity.PracownikSpecjalny".
[java] 140  derbyPU  TRACE  [main] openjpa.MetaData - Parsing
package "pl.jaceklaskowski.jpa.entity.PracownikSpecjalny".
[java] 187  derbyPU  TRACE  [main] openjpa.MetaData - Generating
default metadata for type
"pl.jaceklaskowski.jpa.entity.PracownikSpecjalny".
[java] 187  derbyPU  TRACE  [main] openjpa.MetaData - Using
reflection for metadata generation.
[java] 218  derbyPU  TRACE  [main] openjpa.MetaData - Loading
metadata for "class pl.jaceklaskowski.jpa.entity.Osoba" under mode
"[META]".
[java] 218  derbyPU  TRACE  [main] openjpa.MetaData - Parsing
class "pl.jaceklaskowski.jpa.entity.Osoba".
...

Lots of information to digest.

Jacek

--
Jacek Laskowski
http://www.JacekLaskowski.pl

Re: Testing an OpenJPA module


On 4/10/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote:


Glad you got it fixed. It's annoying that
javax.persistence.Persistence doesn't provide more of a clue as to
why it failed.


I wonder what else you'd like to see other than what's already printed
out? It tells exactly why it's failed - "No Persistence provider for
EntityManager named ode-store" is just a JPA version of
"NoClassDefFoundError" in "pure" Java.

Jacek

--
Jacek Laskowski
http://www.JacekLaskowski.pl

Re: Can I reuse instances?


On Apr 9, 2007, at 5:44 PM, Craig L Russell wrote:


Hi Dain,

On Apr 9, 2007, at 11:10 AM, Dain Sundstrom wrote:


On Apr 8, 2007, at 1:56 PM, Craig L Russell wrote:


Hi Dain,

I haven't looked in detail at the life cycle of CMP beans in a  
couple of years, but in general you can't simply keep the state  
of the underlying Entities through the life cycle. CMP beans are  
pooled and reused in transaction contexts and you have to load  
the state at specific points in the life cycle.


It depends on the commit option the container is using.  In commit  
option A, you assume the cmp engine is the sole user of the  
database, so you don't need to load.  Normally people use commit  
option B where you keep instances activated with a specific  
primary key and reload the data in each tx.


Using the primary key stored in the CMP bean to do em.find at the  
appropriate time is the obvious way to take advantage of the em  
second level cache. To the extent that this is not efficient, we  
should fix it in the JPA layer not the CMP layer.


I would prefer to keep as much of the CMP stuff on the CMP side as  
possible so the JPA implementation can focus on JPA issues.   One  
of the assumption of JPA is that entities are light weight and  
cheap to create, so you take the safe route and construct a new  
one when every you need an instance.  In CMP the assumption is  
that entity instances are expensive to create, so less safe route  
and you pool them.  Reusing instances is really a CMP problem, but  
I don't think it can be implemented without the help of the JPA  
engine.


I'm afraid we're getting wrapped around the axle on definitions.  
Here's what I'm trying to get across:


CMP Entity Beans are expensive to create and there's a lot of  
required behavior to manage them. You pretty much have to implement  
the life cycle in the spec. It's your choice how to implement the  
"state" part of the beans. You can use wrappers around various  
kinds of state objects like ResultSet or generated classes that  
contain fields with the state.


Your implementation uses JPA Entities to hold the state. These JPA  
Entities are not at all specified by CMP Entity Beans. JPA Entities  
as cheap to create so all you need to do is hold on to the ids and  
when you need state from the database, ask JPA EntityManager for  
the state. If the state is already in the second level cache, this  
is very cheap to access.


In my implementation the CMP entity is the JPA entity.  They are the  
same object.  There are no "state holders".  We choose this design to  
easy the transition from CMP to JPA but has the drawback that we are  
completely reliant on the JPA implementation for instance management.


-dain

Re: @Column with precision and scale - how does it work?


I don't think Derby supports specifying the precision on type DOUBLE (maybe
other datbases do).

You should be able to specify the precision through the @Column annotation.
I believe @Column(columnDefinition="DECIMAL(5,2)") will work. I'm not sure
whether precision=x, scale=y with a type that maps to DECIMAL instead of
DOUBLE.


On 4/10/07, Jacek Laskowski < [EMAIL PROTECTED]> wrote:


Hi,

I wonder how I could restrict what values are inserted into a table
using @Column(precision=5, scale=2). When does it matter?

I'm using OpenJPA 0.9.7-SNAPSHOT with Derby and with the following:

@Column(precision = 5, scale = 2)
public double getPensja() {
return pensja;
}

OpenJPA executes the following CREATE

2969  derbyPU  TRACE  [main] openjpa.jdbc.SQL -  executing stmnt 23119024 CREATE TABLE Osoba (numer BIGINT
NOT NULL, dzienImienin TIMESTAMP, dzienUrodzin
TIMESTAMP, imie VARCHAR(255), kraj VARCHAR(255), nazwisko
VARCHAR(255), wersja INTEGER, pensja DOUBLE, tytul VARCHAR(255),
PRIMARY KEY (numer))

How could I restrict the precision and scale of the pensja field? Is
the columnDefinition attribute of @Column the last resort? When is the
others used? What databases are supported?

Jacek

--
Jacek Laskowski
http://www.JacekLaskowski.pl





--
-Michael Dick

Re: Testing an OpenJPA module

2007-04-10 Thread Marc Prud'hommeaux



Lot's of things could have gone wrong: there might be no META-INF/ 
persistence.xml file at all, it could have listed a missing provider  
class, or it could have a valid class, but one that had problems  
loading (due to a missing dependency).



On Apr 10, 2007, at 12:52 PM, Jacek Laskowski wrote:


On 4/10/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote:


Glad you got it fixed. It's annoying that
javax.persistence.Persistence doesn't provide more of a clue as to
why it failed.


I wonder what else you'd like to see other than what's already printed
out? It tells exactly why it's failed - "No Persistence provider for
EntityManager named ode-store" is just a JPA version of
"NoClassDefFoundError" in "pure" Java.

Jacek

--
Jacek Laskowski
http://www.JacekLaskowski.pl

Re: Can I reuse instances?


On Apr 9, 2007, at 12:41 PM, Patrick Linskey wrote:


you need an instance.  In CMP the assumption is that entity
instances
are expensive to create, so less safe route and you pool them.
Reusing instances is really a CMP problem, but I don't think it can
be implemented without the help of the JPA engine.


... but it's not the JPA-visible itself that is necessarily going  
to be

heavyweight, these days. Maybe the proxies shepherding the instance
through the CMP lifecycle will be heavyweight, or certain fields in  
the

instance sourced from JNDI.

My point is that if you're seeing a performance penalty from creating
the actual instances themselves, I'd be interested in knowing what it
is, because potentially we could address that problem directly. If the
penalty is some other parts of the instantiation process, or the
fetching of the data from the database, well, that could be less
resolvable.


When a CMP instance is created there are two callbacks  
setEntityContext (the entity now exists) and activate (the entity now  
has a primary key).  Both of these callbacks are allowed to lookup  
stuff in JNDI like EJBs and JDBC connections.  Some applications  
cache lots of data and some even cache data from databases.  So it  
could be very expensive.


For most apps, these callbacks are empty.

How are you coding the interaction between the (oh-so-wonderfully- 
named)

commit options and the JPA data cache?


I'm not because my implementation didn't work.  I tried to implement  
them by keeping cache of instances.  Then when an instance if  
fetched, I would check the global cache, and if there was an instance  
available, I would call merge.  Then if commit option B, I would do a  
refresh (reload?).  The problem was that merge returned a new  
instance making my global cache useless.


-dain

Three minor issues with the OpenJPA User's Guide.

2007-04-10 Thread Jesse Benson

Section 1.2 is as follows:

1.2. Final
Entity classes may not be final. No method of an entity class can be
final.

Note
OpenJPA supports final classes and final methods.

This wording is rather confusing. According to section 1. About This
Document, the document provides an overview of the JPA standard. If one
were to assume that the Notes are OpenJPA specific, and the rest is an
overview of the standard, this could be seen as the user's guide saying that
OpenJPA is breaking specs.

In section 2.12. Order By

OpenJPA expands the available ordering syntax. See ??? in the Reference
Guide for details.

In section 2. Entity Lifecycle Management

For a given entity A, the refresh method behaves as follows:
If A is a new entity, it is ignored. However, the remove
operation
cascades as defined below.
If A is an existing managed entity, its state is refreshed from
the
datastore.
If A is a removed entity, it is ignored.
If A is a detached entity, an IllegalArgumentException is
thrown.
The refresh operation recurses on all relation fields of A
whose cascades
include CascadeType.REFRESH.

The problem line is "If A is a new entity, it is ignored. However, the
remove operation cascades as defined below." This could be a copy and paste
mistake from the above discription of the remove method.
--
View this message in context:
http://www.nabble.com/Three-minor-issues-with-the-OpenJPA-User%27s-Guide.-tf3555411.html#a9927486
Sent from the open-jpa-dev mailing list archive at Nabble.com.

Re: Can I reuse instances?


Hi Dain,

On Apr 10, 2007, at 12:58 PM, Dain Sundstrom wrote:


On Apr 9, 2007, at 5:44 PM, Craig L Russell wrote:


Hi Dain,

On Apr 9, 2007, at 11:10 AM, Dain Sundstrom wrote:


On Apr 8, 2007, at 1:56 PM, Craig L Russell wrote:


Hi Dain,

I haven't looked in detail at the life cycle of CMP beans in a  
couple of years, but in general you can't simply keep the state  
of the underlying Entities through the life cycle. CMP beans are  
pooled and reused in transaction contexts and you have to load  
the state at specific points in the life cycle.


It depends on the commit option the container is using.  In  
commit option A, you assume the cmp engine is the sole user of  
the database, so you don't need to load.  Normally people use  
commit option B where you keep instances activated with a  
specific primary key and reload the data in each tx.


Using the primary key stored in the CMP bean to do em.find at  
the appropriate time is the obvious way to take advantage of the  
em second level cache. To the extent that this is not efficient,  
we should fix it in the JPA layer not the CMP layer.


I would prefer to keep as much of the CMP stuff on the CMP side  
as possible so the JPA implementation can focus on JPA issues.
One of the assumption of JPA is that entities are light weight  
and cheap to create, so you take the safe route and construct a  
new one when every you need an instance.  In CMP the assumption  
is that entity instances are expensive to create, so less safe  
route and you pool them.  Reusing instances is really a CMP  
problem, but I don't think it can be implemented without the help  
of the JPA engine.


I'm afraid we're getting wrapped around the axle on definitions.  
Here's what I'm trying to get across:


CMP Entity Beans are expensive to create and there's a lot of  
required behavior to manage them. You pretty much have to  
implement the life cycle in the spec. It's your choice how to  
implement the "state" part of the beans. You can use wrappers  
around various kinds of state objects like ResultSet or generated  
classes that contain fields with the state.


Your implementation uses JPA Entities to hold the state. These JPA  
Entities are not at all specified by CMP Entity Beans. JPA  
Entities as cheap to create so all you need to do is hold on to  
the ids and when you need state from the database, ask JPA  
EntityManager for the state. If the state is already in the second  
level cache, this is very cheap to access.


In my implementation the CMP entity is the JPA entity.  They are  
the same object.  There are no "state holders".


Now I understand. I don't think the design works, from lots of  
different perspectives.


We choose this design to easy the transition from CMP to JPA but  
has the drawback that we are completely reliant on the JPA  
implementation for instance management.


I don't think the design can work. The CMP protocol requires  
separating the CMP instance from its state. You are generating the  
CMP concrete implementation class as part of deployment, and the  
concrete class needs to contain state or a reference to state. My  
experience is that keeping state directly in the CMP bean isn't  
likely to work well.


Sorry for the distracting comments. I didn't imagine that you were  
trying to directly persist CMP beans.


Craig


-dain


Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!



smime.p7s
Description: S/MIME cryptographic signature

Re: @Column with precision and scale - how does it work?


On 4/10/07, Michael Dick <[EMAIL PROTECTED]> wrote:

I don't think Derby supports specifying the precision on type DOUBLE (maybe
other datbases do).


You're right - it doesn't.


You should be able to specify the precision through the @Column annotation.
I believe @Column(columnDefinition="DECIMAL(5,2)") will
work.


DECIMAL is a synonim of NUMERIC and either works well.


I'm not sure whether precision=x, scale=y with a type that maps to
DECIMAL instead of DOUBLE.


That's my question how OpenJPA recognizes whether the attributes
should be used or not. I don't think precision and scale are not used
at all.

Jacek

--
Jacek Laskowski
http://www.JacekLaskowski.pl

RE: PCEnhance

Thanks Jacek, I have that entry in there and believe the issue is with
Eclipse/my development environment. You see it is stopping the build process
before it gets to enhance as I get no messages from OpenJPA (or eclipse) at all.

This has been so frustrating that I have stopped trying to fix it and have moved
to using Maven to compile and test. It means I also lose the ability to trace
but I have not progressed my project in almost three weeks trying to solve
various stack issues. I have also posted a message in the eclipse forum but
there seems to be less attention paid to that one than this. When I figure it
out I will post the solution back to this forum for others to discover

Thanks again,

Phill

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek Laskowski
Sent: April 10, 2007 3:48 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: PCEnhance

On 4/10/07, Phill Moran <[EMAIL PROTECTED]> wrote:
> Through maven and eclipse. I have log level trace set in 
> persistence.xml but that has no impact. Maven is reporting that 
> PCEnhance is returning non-zero and no reason why. So trace is set on 
> either CLI or maven (same thing really). I don't remember seeing it 
> anywhere in the docs from maven is it in Configuration and what is the tag?

Use

in your persistence.xml file (I think SQL=TRACE is not necessary). I'm using
OpenJPA 0.9.7-SNAPSHOT's PCEnhancer from within M2 with maven-antrun-plugin. It
gives a lot of information, i.e.

 [java] 62  derbyPU  TRACE  [main] openjpa.MetaData - Found 3 classes with
metadata in 0 milliseconds.
 [java] 62  derbyPU  TRACE  [main] openjpa.Tool - Enhancer running on type
"class pl.jaceklaskowski.jpa.entity.PracownikSpecjalny".
 [java] 125  derbyPU  TRACE  [main] openjpa.MetaData - Loading metadata for
"class pl.jaceklaskowski.jpa.entity.PracownikSpecjalny"
under mode "[META]".
 [java] 140  derbyPU  TRACE  [main] openjpa.MetaData - Parsing class
"pl.jaceklaskowski.jpa.entity.PracownikSpecjalny".
 [java] 140  derbyPU  TRACE  [main] openjpa.MetaData - Parsing package
"pl.jaceklaskowski.jpa.entity.PracownikSpecjalny".
 [java] 187  derbyPU  TRACE  [main] openjpa.MetaData - Generating default
metadata for type "pl.jaceklaskowski.jpa.entity.PracownikSpecjalny".
 [java] 187  derbyPU  TRACE  [main] openjpa.MetaData - Using reflection for
metadata generation.
 [java] 218  derbyPU  TRACE  [main] openjpa.MetaData - Loading metadata for
"class pl.jaceklaskowski.jpa.entity.Osoba" under mode "[META]".
 [java] 218  derbyPU  TRACE  [main] openjpa.MetaData - Parsing class
"pl.jaceklaskowski.jpa.entity.Osoba".
...

Lots of information to digest.

Jacek

--
Jacek Laskowski
http://www.JacekLaskowski.pl

Re: PCEnhance


On 4/10/07, Phill Moran <[EMAIL PROTECTED]> wrote:


This has been so frustrating that I have stopped trying to fix it and have moved
to using Maven to compile and test. It means I also lose the ability to trace
but I have not progressed my project in almost three weeks trying to solve
various stack issues. I have also posted a message in the eclipse forum but
there seems to be less attention paid to that one than this. When I figure it
out I will post the solution back to this forum for others to discover


Why not to use the javaagent in Eclipse then and the PCEnhancer in
production? Run your apps in Eclipse with the following setting in the
VM arguments panel of the Run configuration of your choice.

-javaagent:c:/.m2/org/apache/openjpa/openjpa-all/0.9.7-incubating-SNAPSHOT/openjpa-all-0.9.7-incubating-SNAPSHOT.jar

You should change the path to your M2 repo, though.

Jacek

--
Jacek Laskowski
http://www.JacekLaskowski.pl

RE: Testing an OpenJPA module

2007-04-10 Thread Pinaki Poddar

The error message could have been more specific in the following way:
a) no META-INF/persistence.xml has not been found in classpath
b) META-INF/persistence.xml has been found but there is no 'ode-store'
unit defined in it.
c)  META-INF/persistence.xml has been found but provider can not be
loaded/invoked 

When I first encountered this error, my interpreation was (b) from the
way the message was worded.

Pinaki Poddar
BEA Systems
415.402.7317  

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek
Laskowski
Sent: Tuesday, April 10, 2007 2:52 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Testing an OpenJPA module

On 4/10/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote:
>
> Glad you got it fixed. It's annoying that 
> javax.persistence.Persistence doesn't provide more of a clue as to why

> it failed.

I wonder what else you'd like to see other than what's already printed
out? It tells exactly why it's failed - "No Persistence provider for
EntityManager named ode-store" is just a JPA version of
"NoClassDefFoundError" in "pure" Java.

Jacek

--
Jacek Laskowski
http://www.JacekLaskowski.pl

Notice:  This email message, together with any attachments, may contain 
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
entities,  that may be confidential,  proprietary,  copyrighted  and/or legally 
privileged, and is intended solely for the use of the individual or entity 
named in this message. If you are not the intended recipient, and have received 
this message in error, please immediately return this by email and then delete 
it.

Re: Testing an OpenJPA module


On 4/10/07, Pinaki Poddar <[EMAIL PROTECTED]> wrote:

The error message could have been more specific in the following way:
a) no META-INF/persistence.xml has not been found in classpath
b) META-INF/persistence.xml has been found but there is no 'ode-store'
unit defined in it.
c)  META-INF/persistence.xml has been found but provider can not be
loaded/invoked


Thanks! I've never thought about such an exhaustive list of possible
problems one might run into. Nice to keep it handy.


When I first encountered this error, my interpreation was (b) from the
way the message was worded.


Perhaps it's because I'm a mere developer so the only answer I'd have
given would've been c) yet I knew others were possible too (just I
don't see them so often).

Jacek

--
Jacek Laskowski
http://www.JacekLaskowski.pl

RE: Testing an OpenJPA module

2007-04-10 Thread Pinaki Poddar

> such an exhaustive list of possible problems one might run into. 
Murphy's law: 'If something can go wrong, it will".
Extension to Murphy's law: "Murphy was an optimist".
:)

Pinaki Poddar
BEA Systems
415.402.7317  

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek
Laskowski
Sent: Tuesday, April 10, 2007 4:00 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Testing an OpenJPA module

On 4/10/07, Pinaki Poddar <[EMAIL PROTECTED]> wrote:
> The error message could have been more specific in the following way:
> a) no META-INF/persistence.xml has not been found in classpath
> b) META-INF/persistence.xml has been found but there is no 'ode-store'
> unit defined in it.
> c)  META-INF/persistence.xml has been found but provider can not be 
> loaded/invoked

Thanks! I've never thought about such an exhaustive list of possible
problems one might run into. Nice to keep it handy.

> When I first encountered this error, my interpreation was (b) from the

> way the message was worded.

Perhaps it's because I'm a mere developer so the only answer I'd have
given would've been c) yet I knew others were possible too (just I don't
see them so often).

Jacek

--
Jacek Laskowski
http://www.JacekLaskowski.pl

Notice:  This email message, together with any attachments, may contain 
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
entities,  that may be confidential,  proprietary,  copyrighted  and/or legally 
privileged, and is intended solely for the use of the individual or entity 
named in this message. If you are not the intended recipient, and have received 
this message in error, please immediately return this by email and then delete 
it.

Re: Three minor issues with the OpenJPA User's Guide.

2007-04-10 Thread Kevin Sutter

Jesse,
Comments inline...

On 4/10/07, Jesse Benson <[EMAIL PROTECTED]> wrote:

Section 1.2 is as follows:

1.2. Final
Entity classes may not be final. No method of an entity class can
be final.

Note
OpenJPA supports final classes and final methods.

Actually, the way to look at this is that the "Notes" sections document
OpenJPA extensions to the spec, not breaking the spec. The spec states that
Entity classes and methods and persistent instance variables can not be
final. So, if you want your Entity classes to work with any CTS-compliant
JPA implementation, then they should not be final themselves nor have final
methods or persistent instance variables. But, OpenJPA allows for final
Entity classes and methods as an extension to the spec. If you rely on this
feature, then there is a good chance that your application will not work if
you attempt to use another JPA implementation. Unless someone disagrees, I
think this section is okay as is.

In section 2.12. Order By

OpenJPA expands the available ordering syntax. See ??? in the
Reference
Guide for details.

I'm assuming this should be referring to our Large Result Set capabilities.
I will update the documentation to point at the LRS section of the Reference
Guide, unless someone has another idea of what the ???'s refer to.

In section 2. Entity Lifecycle Management

For a given entity A, the refresh method behaves as follows:
If A is a new entity, it is ignored. However, the remove
operation
cascades as defined below.
If A is an existing managed entity, its state is refreshed
from the
datastore.
If A is a removed entity, it is ignored.
If A is a detached entity, an IllegalArgumentException is
thrown.
The refresh operation recurses on all relation fields of A
whose cascades
include CascadeType.REFRESH.

Correct, looks like a cut-and-paste problem. I will update this when I do
the LRS update.

Thanks for catching these!
Kevin

View this message in context:
http://www.nabble.com/Three-minor-issues-with-the-OpenJPA-User%27s-Guide.-tf3555411.html#a9927486
Sent from the open-jpa-dev mailing list archive at Nabble.com.

Re: Testing an OpenJPA module


FYI, Persistence is an open source project at Glassfish.

Anyone, even an OpenJPA contributor, who wants to contribute to the  
project for example to improve the error messages, is welcome to look  
at the sources and provide a patch. I know people who will be happy  
to commit usability patches. ;-)


Craig

On Apr 10, 2007, at 1:54 PM, Pinaki Poddar wrote:


The error message could have been more specific in the following way:
a) no META-INF/persistence.xml has not been found in classpath
b) META-INF/persistence.xml has been found but there is no 'ode-store'
unit defined in it.
c)  META-INF/persistence.xml has been found but provider can not be
loaded/invoked

When I first encountered this error, my interpreation was (b) from the
way the message was worded.


Pinaki Poddar
BEA Systems
415.402.7317


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek
Laskowski
Sent: Tuesday, April 10, 2007 2:52 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Testing an OpenJPA module

On 4/10/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote:


Glad you got it fixed. It's annoying that
javax.persistence.Persistence doesn't provide more of a clue as to  
why



it failed.


I wonder what else you'd like to see other than what's already printed
out? It tells exactly why it's failed - "No Persistence provider for
EntityManager named ode-store" is just a JPA version of
"NoClassDefFoundError" in "pure" Java.

Jacek

--
Jacek Laskowski
http://www.JacekLaskowski.pl

Notice:  This email message, together with any attachments, may  
contain information  of  BEA Systems,  Inc.,  its subsidiaries   
and  affiliated entities,  that may be confidential,  proprietary,   
copyrighted  and/or legally privileged, and is intended solely for  
the use of the individual or entity named in this message. If you  
are not the intended recipient, and have received this message in  
error, please immediately return this by email and then delete it.


Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!



smime.p7s
Description: S/MIME cryptographic signature

Re: Three minor issues with the OpenJPA User's Guide.

2007-04-10 Thread Abe White

>>
>> OpenJPA expands the available ordering syntax. See ??? in the
>> Reference
>> Guide for details.
>
>
> I'm assuming this should be referring to our Large Result Set  
> capabilities.

LRS capabilities don't affect OrderBy.  The note should be removed --  
OpenJPA does not expand the OrderBy syntax.  (Kodo does, and I  
believe this is an accidental holdover from Kodo.)

Notice:  This email message, together with any attachments, may contain 
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
entities,  that may be confidential,  proprietary,  copyrighted  and/or legally 
privileged, and is intended solely for the use of the individual or entity 
named in this message. If you are not the intended recipient, and have received 
this message in error, please immediately return this by email and then delete 
it.

Re: Three minor issues with the OpenJPA User's Guide.

2007-04-10 Thread Kevin Sutter

On 4/10/07, Abe White <[EMAIL PROTECTED]> wrote:

>>
>> OpenJPA expands the available ordering syntax. See ??? in the
>> Reference
>> Guide for details.
>
>
> I'm assuming this should be referring to our Large Result Set
> capabilities.

LRS capabilities don't affect OrderBy.  The note should be removed --
OpenJPA does not expand the OrderBy syntax.  (Kodo does, and I
believe this is an accidental holdover from Kodo.)

Ahhh... okay.  Thanks for the clarification.  I will just remove the
reference.

RE: Can I reuse instances?

> Your implementation uses JPA Entities to hold the state. These JPA  
> Entities are not at all specified by CMP Entity Beans. JPA Entities  
> as cheap to create so all you need to do is hold on to the ids and  
> when you need state from the database, ask JPA EntityManager for the  
> state. If the state is already in the second level cache, this is  
> very cheap to access.

I imagine that it's also possible that Dain's CMP entity beans are
themselves the JPA entities, rather than beans that delegate on to a JPA
entity.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: Monday, April 09, 2007 5:45 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: Can I reuse instances?
> 
> Hi Dain,
> 
> On Apr 9, 2007, at 11:10 AM, Dain Sundstrom wrote:
> 
> > On Apr 8, 2007, at 1:56 PM, Craig L Russell wrote:
> >
> >> Hi Dain,
> >>
> >> I haven't looked in detail at the life cycle of CMP beans in a  
> >> couple of years, but in general you can't simply keep the 
> state of  
> >> the underlying Entities through the life cycle. CMP beans are  
> >> pooled and reused in transaction contexts and you have to 
> load the  
> >> state at specific points in the life cycle.
> >
> > It depends on the commit option the container is using.  In commit  
> > option A, you assume the cmp engine is the sole user of the  
> > database, so you don't need to load.  Normally people use commit  
> > option B where you keep instances activated with a specific 
> primary  
> > key and reload the data in each tx.
> >
> >> Using the primary key stored in the CMP bean to do em.find at the  
> >> appropriate time is the obvious way to take advantage of the em  
> >> second level cache. To the extent that this is not efficient, we  
> >> should fix it in the JPA layer not the CMP layer.
> >
> > I would prefer to keep as much of the CMP stuff on the CMP side as  
> > possible so the JPA implementation can focus on JPA issues.   One  
> > of the assumption of JPA is that entities are light weight and  
> > cheap to create, so you take the safe route and construct a 
> new one  
> > when every you need an instance.  In CMP the assumption is that  
> > entity instances are expensive to create, so less safe route and  
> > you pool them.  Reusing instances is really a CMP problem, but I  
> > don't think it can be implemented without the help of the 
> JPA engine.
> 
> I'm afraid we're getting wrapped around the axle on definitions.  
> Here's what I'm trying to get across:
> 
> CMP Entity Beans are expensive to create and there's a lot of  
> required behavior to manage them. You pretty much have to implement  
> the life cycle in the spec. It's your choice how to implement the  
> "state" part of the beans. You can use wrappers around various kinds  
> of state objects like ResultSet or generated classes that contain  
> fields with the state.
> 
> Your implementation uses JPA Entities to hold the state. These JPA  
> Entities are not at all specified by CMP Entity Beans. JPA Entities  
> as cheap to create so all you need to do is hold on to the ids and  
> when you need state from the database, ask JPA EntityManager for the  
> state. If the state is already in the second level cache, this is  
> very cheap to access.
> 
> Craig
> >
> > -dain
> >
> >
> 
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:[EMAIL PROTECTED]
> P.S. A good JDO? O, Gasp!
> 
> 

Notice:  This email message, together with any attachments, may contain 
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
entities,  that may be confidential,  proprietary,  copyrighted  and/or legally 
privileged, and is intended solely for the use of the individual or entity 
named in this message. If you are not the intended recipient, and have received 
this message in error, please immediately return this by email and then delete 
it.

Re: @Column with precision and scale - how does it work?

I'm sorry, I misunderstood your question.

I'm afraid I don't know how we determine when to apply the scale and
precision.

In this case the value should be ignored, since there's no way to set it on
the column. If the attribute was of type BigDecimal then I think the
precision and scale should apply.

The catch here is that it looks like we're mapping BigDecimal to DOUBLE so
that won't work. I'll have to take a closer look to determine where that
mapping occurs, and what the correct mapping(s) should be.

Would you mind opening a JIRA report for the problem?
http://issues.apache.org/jira/browse/OPENJPA

-Mike

On 4/10/07, Jacek Laskowski <[EMAIL PROTECTED]> wrote:

On 4/10/07, Michael Dick <[EMAIL PROTECTED]> wrote:
> I don't think Derby supports specifying the precision on type DOUBLE
(maybe
> other datbases do).

You're right - it doesn't.

> You should be able to specify the precision through the @Column
annotation.
> I believe @Column(columnDefinition="DECIMAL(5,2)") will
> work.

DECIMAL is a synonim of NUMERIC and either works well.

> I'm not sure whether precision=x, scale=y with a type that maps to
> DECIMAL instead of DOUBLE.

That's my question how OpenJPA recognizes whether the attributes
should be used or not. I don't think precision and scale are not used
at all.

Jacek

--
Jacek Laskowski
http://www.JacekLaskowski.pl

[jira] Commented: (OPENJPA-211) CLONE -java.lang.VerifyError on websphere 6.1 with Spring 2.0.3 and OpenJpa 0.96/0.97

2007-04-10 Thread david zhang (JIRA)


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

david zhang commented on OPENJPA-211:
-

After fix all the problem, now the application get this error:
[4/10/07 17:56:26:046 EDT] 0026 Runtime   I 
org.apache.openjpa.lib.log.CommonsLogFactory$LogAdapter info Starting OpenJPA 
0.0.0
[4/10/07 17:56:26:109 EDT] 0026 JDBC  I 
org.apache.openjpa.lib.log.CommonsLogFactory$LogAdapter info Using dictionary 
class "org.apache.openjpa.jdbc.sql.DB2Dictionary".
[4/10/07 17:56:26:171 EDT] 0026 ServletWrappe E   SRVE0068E: Uncaught 
exception thrown in one of the service methods of the servlet: mytest. 
Exception thrown : org.springframework.web.util.NestedServletException: Request 
processing failed; nested exception is <4|false|0.0.0> 
org.apache.openjpa.persistence.TransactionRequiredException: Unable to 
determine identity of the current WebSphere managed transaction. Please ensure 
that your are running the application from within WebSphere Application Server 
(version 5.0.2 or newer).
Caused by: <4|false|0.0.0> 
org.apache.openjpa.persistence.TransactionRequiredException: Unable to 
determine identity of the current WebSphere managed transaction. Please ensure 
that your are running the application from within WebSphere Application Server 
(version 5.0.2 or newer).
at 
org.apache.openjpa.ee.WASManagedRuntime$WASTransaction.getStatus(WASManagedRuntime.java:106)
at 
org.apache.openjpa.kernel.AbstractBrokerFactory.syncWithManagedTransaction(AbstractBrokerFactory.java:601)
at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:292)
at 
org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:165)
at 
org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:139)
at 
org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:187)
at 
com.ibm.ws.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:17)
at 
com.ibm.ws.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:8)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at 
org.springframework.orm.jpa.AbstractEntityManagerFactoryBean$ManagedEntityManagerFactoryInvocationHandler.invoke(AbstractEntityManagerFactoryBean.java:376)
at $Proxy25.createEntityManager(Unknown Source)
at 
org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke(SharedEntityManagerCreator.java:168)
at $Proxy26.find(Unknown Source)
at 
com.dztest.jpa.dao.JpaRestaurantDao.findById(JpaRestaurantDao.java:29)
at 
com.dztest.services.RestaurantServiceImpl.getRestaurant(RestaurantServiceImpl.java:15)
at com.dztest.web.actions.TestAction.showRestaurant(TestAction.java:19)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at 
org.springframework.web.servlet.mvc.multiaction.MultiActionController.invokeNamedMethod(MultiActionController.java:434)
at 
org.springframework.web.servlet.mvc.multiaction.MultiActionController.handleRequestInternal(MultiActionController.java:372)
at 
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
at 
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
at 
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:819)
at 
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:754)
at 
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:399)
at 
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:354)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at 
com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:989)
at 
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:501)
at 
com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:464)
at com.ibm.ws.webcontainer.webapp.WebApp.h

Re: @Column with precision and scale - how does it work?

According to the Persistence specification, the @Column annotation says:

int precision (Optional) The precision for a decimal (exact
numeric)column.(Appliesonlyifadecimalcolumn is used.)
0 (Value must be set by
developer.)
int scale (Optional) The scale for a decimal (exact
numeric)column.(Appliesonlyifadecimalcolumn is used.)
0
[sic]

So unless you are using an exact numeric type for your column  
(NUMERIC or DECIMAL) a JPA provider should simply ignore the type.

The intent of this part of the specification is not to provide some  
field-level behavior, for example to convert the data on its way to  
or from the database, but simply to give the provider some  
information that would allow it to create a reasonable column type  
for schema creation.

Craig

On Apr 10, 2007, at 2:59 PM, Michael Dick wrote:

I'm sorry, I misunderstood your question.

I'm afraid I don't know how we determine when to apply the scale and
precision.

In this case the value should be ignored, since there's no way to  
set it on

the column. If the attribute was of type BigDecimal then I think the
precision and scale should apply.

The catch here is that it looks like we're mapping BigDecimal to  
DOUBLE so
that won't work. I'll have to take a closer look to determine where  
that

mapping occurs, and what the correct mapping(s) should be.

Would you mind opening a JIRA report for the problem?
http://issues.apache.org/jira/browse/OPENJPA

-Mike

On 4/10/07, Jacek Laskowski <[EMAIL PROTECTED]> wrote:

On 4/10/07, Michael Dick <[EMAIL PROTECTED]> wrote:
> I don't think Derby supports specifying the precision on type  
DOUBLE

(maybe
> other datbases do).

You're right - it doesn't.

> You should be able to specify the precision through the @Column
annotation.
> I believe @Column(columnDefinition="DECIMAL(5,2)") will
> work.

DECIMAL is a synonim of NUMERIC and either works well.

> I'm not sure whether precision=x, scale=y with a type that maps to
> DECIMAL instead of DOUBLE.

That's my question how OpenJPA recognizes whether the attributes
should be used or not. I don't think precision and scale are not used
at all.

Jacek

--
Jacek Laskowski
http://www.JacekLaskowski.pl

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature

Re: svn commit: r527320 [1/2] - in /incubator/openjpa/branches/0.9.7-incubating: ./ openjpa-all/ openjpa-examples/ openjpa-integration/ openjpa-integration/examples/ openjpa-integration/tck/ openjpa-j


Hi Mike,

Did you accidentally remove the licenses from the xml files???

Craig

On Apr 10, 2007, at 2:59 PM, [EMAIL PROTECTED] wrote:

Modified: incubator/openjpa/branches/0.9.7-incubating/openjpa- 
examples/pom.xml
URL: http://svn.apache.org/viewvc/incubator/openjpa/branches/0.9.7- 
incubating/openjpa-examples/pom.xml? 
view=diff&rev=527320&r1=527319&r2=527320
== 

--- incubator/openjpa/branches/0.9.7-incubating/openjpa-examples/ 
pom.xml (original)
+++ incubator/openjpa/branches/0.9.7-incubating/openjpa-examples/ 
pom.xml Tue Apr 10 14:59:02 2007

@@ -1,22 +1,4 @@
-
-
-http://maven.apache.org/POM/4.0.0";
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
- xsi:schemaLocation="http://maven.apache.org/POM/4.0.0  
http://maven.apache.org/maven-v4_0_0.xsd";>
+http://maven.apache.org/POM/4.0.0";  
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";  
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http:// 
maven.apache.org/maven-v4_0_0.xsd">

 4.0.0
 org.apache.openjpa
 openjpa-examples
@@ -27,7 +9,7 @@
 
 org.apache.openjpa
 openjpa
-0.9.7-incubating-SNAPSHOT
+0.9.7-incubating


Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!



smime.p7s
Description: S/MIME cryptographic signature

Re: svn commit: r527320 [2/2] - in /incubator/openjpa/branches/0.9.7-incubating: ./ openjpa-all/ openjpa-examples/ openjpa-integration/ openjpa-integration/examples/ openjpa-integration/tck/ openjpa-j

This checkin looks like a line ending mismatch. All xml files should  
be specified as eol-style native.


Craig

On Apr 10, 2007, at 2:59 PM, [EMAIL PROTECTED] wrote:

Modified: incubator/openjpa/branches/0.9.7-incubating/openjpa- 
project/pom.xml
URL: http://svn.apache.org/viewvc/incubator/openjpa/branches/0.9.7- 
incubating/openjpa-project/pom.xml? 
view=diff&rev=527320&r1=527319&r2=527320
== 

--- incubator/openjpa/branches/0.9.7-incubating/openjpa-project/ 
pom.xml (original)
+++ incubator/openjpa/branches/0.9.7-incubating/openjpa-project/ 
pom.xml Tue Apr 10 14:59:02 2007


Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!



smime.p7s
Description: S/MIME cryptographic signature

Re: How to set the type of the DB-field using @Externalizer

2007-04-10 Thread Lukas Ruetz

Hello!

Am Dienstag, 10. April 2007 19:17 schrieb Abe White:
> I can't reproduce this.  When I leave out the @Persistent annotation
> on the field or replace it with @Basic, I do indeed end up with a
> binary column.  But if I correctly include the @Persistent annotation
> along with the @Externalizer, I get a varchar column.  Can you narrow
> down your entity to the smallest possible class that exhibits the
> problem and post it to the list so we can try to reproduce the error?

Finally it works. After I've reduced the project to one class with
one field and using derby as DB the problem was still the same. So
I found the problem in the ant-file that did the enhance and mapping
tasks.
But I don't understand the problem - maybe you have an explaination.
The problem was the entry '' in
the element . After I removed this line in both tasks it worked.

Here is the ant-file:
---

JPA test


  
  


  


   
   

  



  
  


  


   
   

  


---

my classpath is:
lib/commons-collections-3.2.jar
lib/commons-lang-2.1.jar
lib/commons-logging-1.0.4.jar
lib/commons-pool-1.3.jar
lib/derby-10.2.2.0.jar
lib/geronimo-j2ee-connector_1.5_spec-1.0.1.jar
lib/geronimo-jms_1.1_spec-1.0.1.jar
lib/geronimo-jpa_3.0_spec-1.0.jar
lib/geronimo-jta_1.0.1B_spec-1.0.1.jar
lib/openjpa-all-0.9.7-incubating-SNAPSHOT.jar
lib/postgresql-8.1-408.jdbc3.jar
lib/serp-1.11.0.jar

Thanks for your help
Lukas

[jira] Created: (OPENJPA-213) @Column with precision and scale should result in NUMERIC(precision, scale)

2007-04-10 Thread Jacek Laskowski (JIRA)

@Column with precision and scale should result in NUMERIC(precision, scale)
---

 Key: OPENJPA-213
 URL: https://issues.apache.org/jira/browse/OPENJPA-213
 Project: OpenJPA
  Issue Type: Improvement
  Components: jpa
Affects Versions: 0.9.7
Reporter: Jacek Laskowski


@Column provides the precision and scale attributes, but there's no (easy) way 
to figure out how it affects the way OpenJPA works if any. It looks like 
OpenJPA reads the type of a persistent field and when it's double it maps it to 
DOUBLE in Derby regardless of the other attributes. When precision and scale 
are specified, a DDL should use NUMERIC(precision, scale) or its synonim - 
DECIMAL(precision, scale).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: @Column with precision and scale - how does it work?


On 4/10/07, Michael Dick <[EMAIL PROTECTED]> wrote:


Would you mind opening a JIRA report for the problem?
http://issues.apache.org/jira/browse/OPENJPA


https://issues.apache.org/jira/browse/OPENJPA-213

Jacek

--
Jacek Laskowski
http://www.JacekLaskowski.pl

Re: svn commit: r527320 [1/2] - in /incubator/openjpa/branches/0.9.7-incubating: ./ openjpa-all/ openjpa-examples/ openjpa-integration/ openjpa-integration/examples/ openjpa-integration/tck/ openjpa-j

Hi Craig,

Well I didn't intentionally remove them :-). It looks like they were removed
by the maven plugin and this is one of the automated commits that it does.
Looks like another gotcha with the tool.

I'm going to rollback the changes again and see if I can fix the endline and
the copyright problems. For the time being I'll leave the artifacts on
people.apache.org/~mikedd.  There should be another set of commits coming
through later tonight tonight.

Thanks for noticing the copyright problem.

On 4/10/07, Craig L Russell <[EMAIL PROTECTED]> wrote:

Hi Mike,

Did you accidentally remove the licenses from the xml files???

Craig

On Apr 10, 2007, at 2:59 PM, [EMAIL PROTECTED] wrote:

> Modified: incubator/openjpa/branches/0.9.7-incubating/openjpa-
> examples/pom.xml
> URL: http://svn.apache.org/viewvc/incubator/openjpa/branches/0.9.7-
> incubating/openjpa-examples/pom.xml?
> view=diff&rev=527320&r1=527319&r2=527320
> ==
> 
> --- incubator/openjpa/branches/0.9.7-incubating/openjpa-examples/
> pom.xml (original)
> +++ incubator/openjpa/branches/0.9.7-incubating/openjpa-examples/
> pom.xml Tue Apr 10 14:59:02 2007
> @@ -1,22 +1,4 @@
> -
> -
> -http://maven.apache.org/POM/4.0.0";
> - xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> - xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> +http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://
> maven.apache.org/maven-v4_0_0.xsd">
>  4.0.0
>  org.apache.openjpa
>  openjpa-examples
> @@ -27,7 +9,7 @@
>  
>  org.apache.openjpa
>  openjpa
> -0.9.7-incubating-SNAPSHOT
> +0.9.7-incubating

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

--
-Michael Dick

RE: svn commit: r527320 [1/2] - in /incubator/openjpa/branches/0.9.7-incubating: ./ openjpa-all/ openjpa-examples/ openjpa-integration/ openjpa-integration/examples/ openjpa-integration/tck/ openjpa-j

Speaking of licenses, I just went through trunk to look for files that
don't contain the URL of the license file. I got the following:

./openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/H2Dictionary.ja
va
./openjpa-jdbc/src/main/resources/META-INF/services/org.apache.openjpa.l
ib.conf.ProductDerivation
./openjpa-jdbc/src/main/resources/org/apache/openjpa/jdbc/meta/java-keyw
ords.rsrc
./openjpa-jdbc/src/main/resources/org/apache/openjpa/jdbc/schema/schemas
-doctype.rsrc
./openjpa-jdbc/src/main/resources/org/apache/openjpa/jdbc/sql/sql-keywor
ds.rsrc
./openjpa-kernel/src/main/java/org/apache/openjpa/conf/BrokerValue.java
./openjpa-kernel/src/main/java/org/apache/openjpa/enhance/Reflection.jav
a
./openjpa-kernel/src/main/java/org/apache/openjpa/kernel/FinalizingBroke
rImpl.java
./openjpa-kernel/src/main/resources/META-INF/services/org.apache.openjpa
.kernel.exps.ExpressionParser
./openjpa-persistence/src/main/resources/META-INF/services/javax.persist
ence.spi.PersistenceProvider
./openjpa-persistence/src/main/resources/META-INF/services/org.apache.op
enjpa.lib.conf.ProductDerivation
./openjpa-persistence/src/main/resources/org/apache/openjpa/persistence/
orm-xsd.rsrc
./openjpa-persistence/src/main/resources/org/apache/openjpa/persistence/
persistence-xsd.rsrc
./openjpa-persistence-jdbc/src/main/resources/META-INF/services/org.apac
he.openjpa.lib.conf.ProductDerivation

Some of these files are formats / get parsed in ways that do not allow
comments, but certainly all of the Java files should have licenses in
them. I would just add the license headers in myself, except that then
you'd need to patch your branch; can you add the headers to the files in
this list that support comments?

There were also 22 files in openjpa-*/src/test directories that don't
have the headers. I'm assuming that when we package up the source, we
don't include the test classes, and am therefore leaving those files
out.

Thanks,

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 10, 2007 3:26 PM
> To: open-jpa-dev@incubator.apache.org
> Cc: open-jpa-commits@incubator.apache.org
> Subject: Re: svn commit: r527320 [1/2] - in 
> /incubator/openjpa/branches/0.9.7-incubating: ./ openjpa-all/ 
> openjpa-examples/ openjpa-integration/ 
> openjpa-integration/examples/ openjpa-integration/tck/ 
> openjpa-jdbc-5/ openjpa-jdbc/ openjpa-kernel-5/ openjpa-kernel/ 
> 
> Hi Mike,
> 
> Did you accidentally remove the licenses from the xml files???
> 
> Craig
> 
> On Apr 10, 2007, at 2:59 PM, [EMAIL PROTECTED] wrote:
> 
> > Modified: incubator/openjpa/branches/0.9.7-incubating/openjpa- 
> > examples/pom.xml
> > URL: http://svn.apache.org/viewvc/incubator/openjpa/branches/0.9.7- 
> > incubating/openjpa-examples/pom.xml? 
> > view=diff&rev=527320&r1=527319&r2=527320
> > 
> ==
>  
> > 
> > --- incubator/openjpa/branches/0.9.7-incubating/openjpa-examples/ 
> > pom.xml (original)
> > +++ incubator/openjpa/branches/0.9.7-incubating/openjpa-examples/ 
> > pom.xml Tue Apr 10 14:59:02 2007
> > @@ -1,22 +1,4 @@
> > -
> > -
> > -http://maven.apache.org/POM/4.0.0";
> > - xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > - xsi:schemaLocation="http://maven.apache.org/POM/4.0.0  
> > http://maven.apache.org/maven-v4_0_0.xsd";>
> > +http://maven.apache.org/POM/4.0.0";  
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";  
> > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http:// 
> > maven.apache.org/maven-v4_0_0.xsd">
> >  4.0.0
> >  org.apache.openjpa
> >  openjpa-examples
> > @@ -27,7 +9,7 @@
> >  
> >  org.apache.openjpa
> >  openjpa
> > -0.9.7-incubating-SNAPSHOT
> > +0.9.7-incubating
> 
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:[EMAIL PROTECTED]
> P.S. A good JDO? O, Gasp!
> 
> 

Notice:  This email message, together with any attachments, may contain 
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
entities,  that may be confidential,  proprietary,  copyrighted  and/or legally 
privileged, and is intended solely for the use of the individual or entity 
named in this message. If you are not the intended recipient, and have received 
this message in error, please immediately r

[jira] Commented: (OPENJPA-212) Constructor expression permits no other expressions in SELECT clause

2007-04-10 Thread Patrick Linskey (JIRA)


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

Patrick Linskey commented on OPENJPA-212:
-

You don't have a test case handy for this by any chance, do you?

> Constructor expression permits no other expressions in SELECT clause
> 
>
> Key: OPENJPA-212
> URL: https://issues.apache.org/jira/browse/OPENJPA-212
> Project: OpenJPA
>  Issue Type: Bug
>  Components: query
>Affects Versions: 0.9.7
>Reporter: Jacek Laskowski
>
> It seems that it's impossible to run a query with constructor expression 
> beside other expressions in SELECT clause. Take a look at the following test 
> that finishes with ClassCastException when the first element of resultQuery 
> is returned (the 2nd line of the snippet).  Am I doing something plain wrong?
> It doesn't work with Hibernate EntityManager 3.3.1, either yet TopLink 
> Essentials 2.0 BUILD 40 runs fine.
>   Query query = em.createQuery("SELECT NEW 
> pl.jaceklaskowski.jpa.PewnaKlasa(p.nazwa, o.imie, o.nazwisko, o.numer), o, 
> p.nazwa FROM Projekt p JOIN p.chair o");
>   List resultQuery = query.getResultList();
>   final Object[] firstElementInQueryResult = resultQuery.get(0);
>   assert firstElementInQueryResult.length == 3;
>   final Object firstElement = resultQuery.get(0)[0];
>   assert firstElement instanceof PewnaKlasa;
>   final Object secondElement = resultQuery.get(0)[1];
>   assert secondElement instanceof Osoba;
>   final Object thirdElement = resultQuery.get(0)[2];
>   assert thirdElement instanceof String;
> The exception is as follows (the line number is different though as the test 
> above is incomplete - no class, imports and alike are shown):
> java.lang.ClassCastException: pl.jaceklaskowski.jpa.PewnaKlasa
> at 
> pl.jaceklaskowski.jpa.OpenJPATest.testConstructorExpr(OpenJPATest.java:19)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-91) java.lang.VerifyError on websphere after application reload

2007-04-10 Thread Patrick Linskey (JIRA)


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

Patrick Linskey commented on OPENJPA-91:


> Hi, Patrick, what kind of DB2 driver info we should put into the config? 
> DB2 connection pool driver class name?

It depends on how you want the configuration to be structured. If you already 
have a data source defined within the application server, then you should 
provide its JNDI name. Otherwise, you can either provide direct connection URL 
/ driver name / user credential information to OpenJPA, or provide a pooling 
data source configuration.

> java.lang.VerifyError on websphere after application reload
> ---
>
> Key: OPENJPA-91
> URL: https://issues.apache.org/jira/browse/OPENJPA-91
> Project: OpenJPA
>  Issue Type: Bug
> Environment: Using OpenJPA (openjpa-all-0.9.6-incubating.jar) in 
> Rational Developer 7 ( Websphere 6.1 test environment ) connected to Oracle 
> 9.2 database.
> OS: WinXP SP2
>Reporter: Anders Monrad
>Priority: Minor
> Fix For: 0.9.8
>
>
> Hi ..
> Not sure if this is a bug or just the way websphere reacts to openjpa. 
> I have a small test program using OpenJPA against an Oracle database. I am 
> running this program in the Websphere 6.1 test environment included with 
> Rational Developer 7. This is all working just fine. But when I make changes 
> to some ressource in the application, the chagnes are automatically published 
> to the test environment and the app is restarted. After this I get the 
> Exception below, whenever I try to access an EntityManager. 
> If I restart the entire server, the app is running fine again. So I guess 
> this is related to restarting the application.
> Caused by: java.lang.VerifyError: class loading constraint violated (class: 
> org/apache/openjpa/kernel/BrokerImpl method: 
> newQueryImpl(Ljava/lang/String;Lorg/apache/openjpa/kernel/StoreQuery;)Lorg/apache/openjpa/kernel/QueryImpl;)
>  at pc: 0
>   at java.lang.J9VMInternals.verifyImpl(Native Method)
>   at java.lang.J9VMInternals.verify(J9VMInternals.java:59)
>   at java.lang.J9VMInternals.initialize(J9VMInternals.java:120)
>   at java.lang.Class.forNameImpl(Native Method)
>   at java.lang.Class.forName(Class.java:131)
>   at 
> org.apache.openjpa.conf.OpenJPAConfigurationImpl.class$(OpenJPAConfigurationImpl.java:65)
>   at 
> org.apache.openjpa.conf.OpenJPAConfigurationImpl.(OpenJPAConfigurationImpl.java:182)
>   at 
> org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.(JDBCConfigurationImpl.java:110)
>   at 
> org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.(JDBCConfigurationImpl.java:100)
>   at 
> org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.(JDBCConfigurationImpl.java:91)
>   at 
> org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newInstance(JDBCBrokerFactory.java:55)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:615)
>   at org.apache.openjpa.kernel.Bootstrap.invokeFactory(Bootstrap.java:117)
>   at 
> org.apache.openjpa.kernel.Bootstrap.newBrokerFactory(Bootstrap.java:57)
>   at 
> org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:70)
>   at 
> org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:78)
>   at 
> javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:83)
>   at 
> javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:60)
>   at 
> util.EntityManagerFactoryHelper.getEntityManagerFactory(EntityManagerFactoryHelper.java:22)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-211) CLONE -java.lang.VerifyError on websphere 6.1 with Spring 2.0.3 and OpenJpa 0.96/0.97

2007-04-10 Thread Patrick Linskey (JIRA)


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

Patrick Linskey commented on OPENJPA-211:
-

Sadly, I'm not really up-to-speed on the WebSphere integration stuff in 
OpenJPA. Maybe Mike or David or Kevin have some suggestions?

> CLONE -java.lang.VerifyError on websphere 6.1 with Spring 2.0.3 and OpenJpa 
> 0.96/0.97
> -
>
> Key: OPENJPA-211
> URL: https://issues.apache.org/jira/browse/OPENJPA-211
> Project: OpenJPA
>  Issue Type: Bug
>  Components: kernel
>Affects Versions: 0.9.6
> Environment: Using OpenJPA (openjpa-all-0.9.6-incubating.jar) in 
> Rational Developer 7 ( Websphere 6.1 test environment ) connected to DB2 V9.1.
> OS: WinXP SP2
>Reporter: david zhang
>Priority: Blocker
> Fix For: 0.9.8
>
> Attachments: applicationContext.xml, mytestdata.jar, persistence.xml
>
>
> Hi, if I use the OpenJPA shipped with Spring 2.0.3, I got the following error 
> when start application:
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'entityManagerFactory' defined in ServletContext resource 
> [/WEB-INF/applicationContext.xml]: Invocation of init method failed; nested 
> exception is java.lang.VerifyError: class loading constraint violated (class: 
> org/apache/openjpa/kernel/BrokerImpl method: 
> newQueryImpl(Ljava/lang/String;Lorg/apache/openjpa/kernel/StoreQuery;)Lorg/apache/openjpa/kernel/QueryImpl;)
>  at pc: 0
> Caused by: 
> java.lang.VerifyError: class loading constraint violated (class: 
> org/apache/openjpa/kernel/BrokerImpl method: 
> newQueryImpl(Ljava/lang/String;Lorg/apache/openjpa/kernel/StoreQuery;)Lorg/apache/openjpa/kernel/QueryImpl;)
>  at pc: 0
>   at java.lang.J9VMInternals.verifyImpl(Native Method)
>   at java.lang.J9VMInternals.verify(J9VMInternals.java:59)
>   at java.lang.J9VMInternals.initialize(J9VMInternals.java:120)
>   at java.lang.Class.forNameImpl(Native Method)
>   at java.lang.Class.forName(Class.java:131)
>   at 
> org.apache.openjpa.conf.OpenJPAConfigurationImpl.class$(OpenJPAConfigurationImpl.java:65)
>   at 
> org.apache.openjpa.conf.OpenJPAConfigurationImpl.(OpenJPAConfigurationImpl.java:182)
>   at 
> org.apache.openjpa.conf.OpenJPAConfigurationImpl.(OpenJPAConfigurationImpl.java:154)
>   at 
> org.apache.openjpa.conf.OpenJPAConfigurationImpl.(OpenJPAConfigurationImpl.java:145)
>   at 
> org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.(PersistenceProviderImpl.java:114)
>   at 
> org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.(PersistenceProviderImpl.java:106)
>   at 
> org.apache.openjpa.persistence.PersistenceProviderImpl.createContainerEntityManagerFactory(PersistenceProviderImpl.java:92)
>   at 
> org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:214)
>   at 
> org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:251)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1143)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1110)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:431)
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:254)
>   at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:144)
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:251)
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:163)
>   at 
> org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:244)
>   at 
> org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:233)
>   at 
> org.springframework.beans.factory.BeanFactoryUtils.beansOfTypeIncludingAncestors(BeanFactoryUtils.java:205)
>   at 
> org.springframework.beans.factory.BeanFactoryUtils.beanOfTypeIncludingAncestors(BeanFactoryUtils.java:292)
>   at 
> org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.findDefaultEntityManagerFactory(PersistenceAnnotationBeanPostProcessor.java:411)
>   at 
> org.s

Re: svn commit: r527320 [1/2] - in /incubator/openjpa/branches/0.9.7-incubating: ./ openjpa-all/ openjpa-examples/ openjpa-integration/ openjpa-integration/examples/ openjpa-integration/tck/ openjpa-j


I'll add the urls and licenses to the branch.  With a little luck we can
apply the same patch to trunk and save some effort. Maybe that's overly
optimistic thinking on my part though.

On 4/10/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:


Speaking of licenses, I just went through trunk to look for files that
don't contain the URL of the license file. I got the following:

./openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/H2Dictionary.ja
va
./openjpa-jdbc/src/main/resources/META-INF/services/org.apache.openjpa.l
ib.conf.ProductDerivation
./openjpa-jdbc/src/main/resources/org/apache/openjpa/jdbc/meta/java-keyw
ords.rsrc
./openjpa-jdbc/src/main/resources/org/apache/openjpa/jdbc/schema/schemas
-doctype.rsrc
./openjpa-jdbc/src/main/resources/org/apache/openjpa/jdbc/sql/sql-keywor
ds.rsrc
./openjpa-kernel/src/main/java/org/apache/openjpa/conf/BrokerValue.java
./openjpa-kernel/src/main/java/org/apache/openjpa/enhance/Reflection.jav
a
./openjpa-kernel/src/main/java/org/apache/openjpa/kernel/FinalizingBroke
rImpl.java
./openjpa-kernel/src/main/resources/META-INF/services/org.apache.openjpa
.kernel.exps.ExpressionParser
./openjpa-persistence/src/main/resources/META-INF/services/javax.persist
ence.spi.PersistenceProvider
./openjpa-persistence/src/main/resources/META-INF/services/org.apache.op
enjpa.lib.conf.ProductDerivation
./openjpa-persistence/src/main/resources/org/apache/openjpa/persistence/
orm-xsd.rsrc
./openjpa-persistence/src/main/resources/org/apache/openjpa/persistence/
persistence-xsd.rsrc
./openjpa-persistence-jdbc/src/main/resources/META-INF/services/org.apac
he.openjpa.lib.conf.ProductDerivation

Some of these files are formats / get parsed in ways that do not allow
comments, but certainly all of the Java files should have licenses in
them. I would just add the license headers in myself, except that then
you'd need to patch your branch; can you add the headers to the files in
this list that support comments?

There were also 22 files in openjpa-*/src/test directories that don't
have the headers. I'm assuming that when we package up the source, we
don't include the test classes, and am therefore leaving those files
out.

Thanks,

-Patrick

--
Patrick Linskey
BEA Systems, Inc.

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 10, 2007 3:26 PM
> To: open-jpa-dev@incubator.apache.org
> Cc: open-jpa-commits@incubator.apache.org
> Subject: Re: svn commit: r527320 [1/2] - in
> /incubator/openjpa/branches/0.9.7-incubating: ./ openjpa-all/
> openjpa-examples/ openjpa-integration/
> openjpa-integration/examples/ openjpa-integration/tck/
> openjpa-jdbc-5/ openjpa-jdbc/ openjpa-kernel-5/ openjpa-kernel/
>
> Hi Mike,
>
> Did you accidentally remove the licenses from the xml files???
>
> Craig
>
> On Apr 10, 2007, at 2:59 PM, [EMAIL PROTECTED] wrote:
>
> > Modified: incubator/openjpa/branches/0.9.7-incubating/openjpa-
> > examples/pom.xml
> > URL: http://svn.apache.org/viewvc/incubator/openjpa/branches/0.9.7-
> > incubating/openjpa-examples/pom.xml?
> > view=diff&rev=527320&r1=527319&r2=527320
> >
> ==
> 
> > 
> > --- incubator/openjpa/branches/0.9.7-incubating/openjpa-examples/
> > pom.xml (original)
> > +++ incubator/openjpa/branches/0.9.7-incubating/openjpa-examples/
> > pom.xml Tue Apr 10 14:59:02 2007
> > @@ -1,22 +1,4 @@
> > -
> > -
> > -http://maven.apache.org/POM/4.0.0";
> > - xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > - xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > http://maven.apache.org/maven-v4_0_0.xsd";>
> > +http://maven.apache.org/POM/4.0.0";
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://
> > maven.apache.org/maven-v4_0_0.xsd">
> >  4.0.0
> >  org.apache.openjpa
> >  openjpa-examples
> > @@ -27,7 +9,7 @@
> >  
> >  org.apache.openjpa
> >  openjpa
> > -0.9.7-incubating-SNAPSHOT
> > +0.9.7-incubating
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:[EMAIL PROTECTED]
> P.S. A good JDO? O, Gasp!
>
>

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or

Re: OPENJPA-182: reuse Connection constants or create our own?

2007-04-10 Thread Marina Vatkina

One note of caution about using enums - there can be a problem in passing enums 
from a client to a server using RMI-IIOP serialiazation - see GlassFish issue 
https://glassfish.dev.java.net/issues/show_bug.cgi?id=193 for some details.


regards,
-marina

Abe White wrote:

I think that JDBCFetchPlan should take a Java 5 enum, and
JDBCFetchConfiguration should use the Connection values.



Certainly JDBCFetchConfiguration should use the Connection values.  I  
personally have never had a problem with symbolic constants for  
settings, but enums for the FetchPlan are cool too.  So long as the  
JPA QueryImpl parses the enum value and its string form correctly  
when using it as a hint.


Notice:  This email message, together with any attachments, may contain 
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
entities,  that may be confidential,  proprietary,  copyrighted  and/or legally 
privileged, and is intended solely for the use of the individual or entity 
named in this message. If you are not the intended recipient, and have received 
this message in error, please immediately return this by email and then delete 
it.

RE: svn commit: r527320 [1/2] - in /incubator/openjpa/branches/0.9.7-incubating: ./ openjpa-all/ openjpa-examples/ openjpa-integration/ openjpa-integration/examples/ openjpa-integration/tck/ openjpa-j

I'm optimistic that after we cut the release, we can just do a bulk
integ to trunk.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -Original Message-
> From: Michael Dick [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 10, 2007 4:29 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: svn commit: r527320 [1/2] - in 
> /incubator/openjpa/branches/0.9.7-incubating: ./ openjpa-all/ 
> openjpa-examples/ openjpa-integration/ 
> openjpa-integration/examples/ openjpa-integration/tck/ 
> openjpa-jdbc-5/ openjpa-jdbc/ openjpa-kernel-5/ openjpa-ker
> 
> I'll add the urls and licenses to the branch.  With a little 
> luck we can
> apply the same patch to trunk and save some effort. Maybe 
> that's overly
> optimistic thinking on my part though.
> 
> On 4/10/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:
> >
> > Speaking of licenses, I just went through trunk to look for 
> files that
> > don't contain the URL of the license file. I got the following:
> >
> > 
> ./openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/H2Dic
> tionary.ja
> > va
> > 
> ./openjpa-jdbc/src/main/resources/META-INF/services/org.apache
> .openjpa.l
> > ib.conf.ProductDerivation
> > 
> ./openjpa-jdbc/src/main/resources/org/apache/openjpa/jdbc/meta
> /java-keyw
> > ords.rsrc
> > 
> ./openjpa-jdbc/src/main/resources/org/apache/openjpa/jdbc/sche
> ma/schemas
> > -doctype.rsrc
> > 
> ./openjpa-jdbc/src/main/resources/org/apache/openjpa/jdbc/sql/
> sql-keywor
> > ds.rsrc
> > 
> ./openjpa-kernel/src/main/java/org/apache/openjpa/conf/BrokerV
> alue.java
> > 
> ./openjpa-kernel/src/main/java/org/apache/openjpa/enhance/Refl
> ection.jav
> > a
> > 
> ./openjpa-kernel/src/main/java/org/apache/openjpa/kernel/Final
> izingBroke
> > rImpl.java
> > 
> ./openjpa-kernel/src/main/resources/META-INF/services/org.apac
> he.openjpa
> > .kernel.exps.ExpressionParser
> > 
> ./openjpa-persistence/src/main/resources/META-INF/services/jav
> ax.persist
> > ence.spi.PersistenceProvider
> > 
> ./openjpa-persistence/src/main/resources/META-INF/services/org
> .apache.op
> > enjpa.lib.conf.ProductDerivation
> > 
> ./openjpa-persistence/src/main/resources/org/apache/openjpa/pe
> rsistence/
> > orm-xsd.rsrc
> > 
> ./openjpa-persistence/src/main/resources/org/apache/openjpa/pe
> rsistence/
> > persistence-xsd.rsrc
> > 
> ./openjpa-persistence-jdbc/src/main/resources/META-INF/service
> s/org.apac
> > he.openjpa.lib.conf.ProductDerivation
> >
> > Some of these files are formats / get parsed in ways that 
> do not allow
> > comments, but certainly all of the Java files should have 
> licenses in
> > them. I would just add the license headers in myself, 
> except that then
> > you'd need to patch your branch; can you add the headers to 
> the files in
> > this list that support comments?
> >
> > There were also 22 files in openjpa-*/src/test directories 
> that don't
> > have the headers. I'm assuming that when we package up the 
> source, we
> > don't include the test classes, and am therefore leaving those files
> > out.
> >
> > Thanks,
> >
> > -Patrick
> >
> > --
> > Patrick Linskey
> > BEA Systems, Inc.
> >
> > 
> __
> _
> > Notice:  This email message, together with any attachments, 
> may contain
> > information  of  BEA Systems,  Inc.,  its subsidiaries  and 
>  affiliated
> > entities,  that may be confidential,  proprietary,  
> copyrighted  and/or
> > legally privileged, and is intended solely for the use of 
> the individual
> > or entity named in this message. If you are not the 
> intended recipient,
> > and have received this message in error, please immediately 
> return this
> > by email and then delete it.
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > > Sent: Tuesday, April 10, 2007 3:26 PM
> > > To: open-jpa-dev@incubator.apache.org
> > > Cc: open-jpa-commits@incubator.apache.org
> > > Subject: Re: svn commit: r527320 [1/2] - in
> > > /incubator/openjpa/branches/0.9.7-incubating: ./ openjpa-all/
> > > openjpa-examples/ openjpa-integration/
> > > openjpa-integration/examples/ openjpa-integration/tck/
> > > openjpa-jdbc-5/ openjpa-jdbc/ openjpa-kernel-5/ openjpa-kernel/
> > >
> > > Hi Mike,
> > >
> > > Did you accidentally remove the licenses from the xml files???
> > >
> > > Craig
> > >
> > > On Apr 10, 2007, at 2:59 PM, [EMAIL PROTECTED] wrote:
> > >
> > > > Modified: incubator/openjpa/branches/0.9.7

RE: OPENJPA-182: reuse Connection constants or create our own?

Fascinating. Happily, as it turns out, we never compare these things
directly; instead, we extract a value from the enums and use that. The
value is populated in the enum constructor:

public enum IsolationLevel {
DEFAULT(-1),
NONE(Connection.TRANSACTION_NONE),
READ_UNCOMMITTED(Connection.TRANSACTION_READ_UNCOMMITTED),
READ_COMMITTED(Connection.TRANSACTION_READ_COMMITTED),
REPEATABLE_READ(Connection.TRANSACTION_REPEATABLE_READ),
SERIALIZABLE(Connection.TRANSACTION_SERIALIZABLE);

private final int _connectionConstant;

private IsolationLevel(int connectionConstant) {
_connectionConstant = connectionConstant;
}

protected int getConnectionConstant() {
return _connectionConstant;
}
}

Do you know if the getConnectionConstant() method would return the same
value for different instances of the "same" module?

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 10, 2007 4:39 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: OPENJPA-182: reuse Connection constants or 
> create our own?
> 
> One note of caution about using enums - there can be a 
> problem in passing enums 
> from a client to a server using RMI-IIOP serialiazation - see 
> GlassFish issue 
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=193 for 
> some details.
> 
> regards,
> -marina
> 
> Abe White wrote:
> >>I think that JDBCFetchPlan should take a Java 5 enum, and
> >>JDBCFetchConfiguration should use the Connection values.
> > 
> > 
> > Certainly JDBCFetchConfiguration should use the Connection 
> values.  I  
> > personally have never had a problem with symbolic constants for  
> > settings, but enums for the FetchPlan are cool too.  So 
> long as the  
> > JPA QueryImpl parses the enum value and its string form correctly  
> > when using it as a hint.
> > 
> > Notice:  This email message, together with any attachments, 
> may contain information  of  BEA Systems,  Inc.,  its 
> subsidiaries  and  affiliated entities,  that may be 
> confidential,  proprietary,  copyrighted  and/or legally 
> privileged, and is intended solely for the use of the 
> individual or entity named in this message. If you are not 
> the intended recipient, and have received this message in 
> error, please immediately return this by email and then delete it.
> 
> 

Notice:  This email message, together with any attachments, may contain 
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
entities,  that may be confidential,  proprietary,  copyrighted  and/or legally 
privileged, and is intended solely for the use of the individual or entity 
named in this message. If you are not the intended recipient, and have received 
this message in error, please immediately return this by email and then delete 
it.

Re: OPENJPA-182: reuse Connection constants or create our own?

2007-04-10 Thread Marina Vatkina

It should be ok anyway in the same VM. Unfortunately I had conflicting messages 
on weather it's the name or the ordinal that is guaranteed to work across the 
VMs :(.


-marina

Patrick Linskey wrote:

Fascinating. Happily, as it turns out, we never compare these things
directly; instead, we extract a value from the enums and use that. The
value is populated in the enum constructor:

public enum IsolationLevel {
DEFAULT(-1),
NONE(Connection.TRANSACTION_NONE),
READ_UNCOMMITTED(Connection.TRANSACTION_READ_UNCOMMITTED),
READ_COMMITTED(Connection.TRANSACTION_READ_COMMITTED),
REPEATABLE_READ(Connection.TRANSACTION_REPEATABLE_READ),
SERIALIZABLE(Connection.TRANSACTION_SERIALIZABLE);

private final int _connectionConstant;

private IsolationLevel(int connectionConstant) {
_connectionConstant = connectionConstant;
}

protected int getConnectionConstant() {
return _connectionConstant;
}
}

Do you know if the getConnectionConstant() method would return the same
value for different instances of the "same" module?

-Patrick

Re: Testing an OpenJPA module

2007-04-10 Thread Marina Vatkina

It's pretty much defined by the spec that Persistence class just delegates to 
the providers to do the work and has no way to report the errors:


7.2 Bootstrapping in Java SE Environments

The Persistence bootstrap class will locate all of the persistence providers 
<...> and call createEntityManagerFactory() on them in turn until an appropriate

backing provider returns an EntityManagerFactory.
<...>
If a provider does not qualify as the provider for the named persistence unit, 
it must return null when createEntityManagerFactory is invoked on it.


regards,
-marina

Craig L Russell wrote:

FYI, Persistence is an open source project at Glassfish.

Anyone, even an OpenJPA contributor, who wants to contribute to the  
project for example to improve the error messages, is welcome to look  
at the sources and provide a patch. I know people who will be happy  to 
commit usability patches. ;-)


Craig

On Apr 10, 2007, at 1:54 PM, Pinaki Poddar wrote:


The error message could have been more specific in the following way:
a) no META-INF/persistence.xml has not been found in classpath
b) META-INF/persistence.xml has been found but there is no 'ode-store'
unit defined in it.
c)  META-INF/persistence.xml has been found but provider can not be
loaded/invoked

When I first encountered this error, my interpreation was (b) from the
way the message was worded.


Pinaki Poddar
BEA Systems
415.402.7317


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek
Laskowski
Sent: Tuesday, April 10, 2007 2:52 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Testing an OpenJPA module

On 4/10/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote:



Glad you got it fixed. It's annoying that
javax.persistence.Persistence doesn't provide more of a clue as to  why




it failed.



I wonder what else you'd like to see other than what's already printed
out? It tells exactly why it's failed - "No Persistence provider for
EntityManager named ode-store" is just a JPA version of
"NoClassDefFoundError" in "pure" Java.

Jacek

--
Jacek Laskowski
http://www.JacekLaskowski.pl

Notice:  This email message, together with any attachments, may  
contain information  of  BEA Systems,  Inc.,  its subsidiaries   and  
affiliated entities,  that may be confidential,  proprietary,   
copyrighted  and/or legally privileged, and is intended solely for  
the use of the individual or entity named in this message. If you  are 
not the intended recipient, and have received this message in  error, 
please immediately return this by email and then delete it.



Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

RE: OPENJPA-182: reuse Connection constants or create our own?

As long as any given enum instance that corresponds to a
theoretically-unique enum value has internally-consistent state, we
should be in good shape. IOW, if the enum constructors are called
appropriately or internal state is otherwise maintained, then things
should work out fine.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 10, 2007 4:56 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: OPENJPA-182: reuse Connection constants or 
> create our own?
> 
> It should be ok anyway in the same VM. Unfortunately I had 
> conflicting messages 
> on weather it's the name or the ordinal that is guaranteed to 
> work across the 
> VMs :(.
> 
> -marina
> 
> Patrick Linskey wrote:
> > Fascinating. Happily, as it turns out, we never compare these things
> > directly; instead, we extract a value from the enums and 
> use that. The
> > value is populated in the enum constructor:
> > 
> > public enum IsolationLevel {
> > DEFAULT(-1),
> > NONE(Connection.TRANSACTION_NONE),
> > READ_UNCOMMITTED(Connection.TRANSACTION_READ_UNCOMMITTED),
> > READ_COMMITTED(Connection.TRANSACTION_READ_COMMITTED),
> > REPEATABLE_READ(Connection.TRANSACTION_REPEATABLE_READ),
> > SERIALIZABLE(Connection.TRANSACTION_SERIALIZABLE);
> > 
> > private final int _connectionConstant;
> > 
> > private IsolationLevel(int connectionConstant) {
> > _connectionConstant = connectionConstant;
> > }
> > 
> > protected int getConnectionConstant() {
> > return _connectionConstant;
> > }
> > }
> > 
> > Do you know if the getConnectionConstant() method would 
> return the same
> > value for different instances of the "same" module?
> > 
> > -Patrick
> > 
> 
> 

Notice:  This email message, together with any attachments, may contain 
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
entities,  that may be confidential,  proprietary,  copyrighted  and/or legally 
privileged, and is intended solely for the use of the individual or entity 
named in this message. If you are not the intended recipient, and have received 
this message in error, please immediately return this by email and then delete 
it.

[jira] Assigned: (OPENJPA-213) @Column with precision and scale should result in NUMERIC(precision, scale)

2007-04-10 Thread Michael Dick (JIRA)


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

Michael Dick reassigned OPENJPA-213:


Assignee: Michael Dick

> @Column with precision and scale should result in NUMERIC(precision, scale)
> ---
>
> Key: OPENJPA-213
> URL: https://issues.apache.org/jira/browse/OPENJPA-213
> Project: OpenJPA
>  Issue Type: Improvement
>  Components: jpa
>Affects Versions: 0.9.7
>Reporter: Jacek Laskowski
> Assigned To: Michael Dick
>
> @Column provides the precision and scale attributes, but there's no (easy) 
> way to figure out how it affects the way OpenJPA works if any. It looks like 
> OpenJPA reads the type of a persistent field and when it's double it maps it 
> to DOUBLE in Derby regardless of the other attributes. When precision and 
> scale are specified, a DDL should use NUMERIC(precision, scale) or its 
> synonim - DECIMAL(precision, scale).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Can I reuse instances?



On Apr 10, 2007, at 1:24 PM, Craig L Russell wrote:


Hi Dain,

On Apr 10, 2007, at 12:58 PM, Dain Sundstrom wrote:


On Apr 9, 2007, at 5:44 PM, Craig L Russell wrote:


Hi Dain,

On Apr 9, 2007, at 11:10 AM, Dain Sundstrom wrote:


On Apr 8, 2007, at 1:56 PM, Craig L Russell wrote:


Hi Dain,

I haven't looked in detail at the life cycle of CMP beans in a  
couple of years, but in general you can't simply keep the state  
of the underlying Entities through the life cycle. CMP beans  
are pooled and reused in transaction contexts and you have to  
load the state at specific points in the life cycle.


It depends on the commit option the container is using.  In  
commit option A, you assume the cmp engine is the sole user of  
the database, so you don't need to load.  Normally people use  
commit option B where you keep instances activated with a  
specific primary key and reload the data in each tx.


Using the primary key stored in the CMP bean to do em.find at  
the appropriate time is the obvious way to take advantage of  
the em second level cache. To the extent that this is not  
efficient, we should fix it in the JPA layer not the CMP layer.


I would prefer to keep as much of the CMP stuff on the CMP side  
as possible so the JPA implementation can focus on JPA issues.
One of the assumption of JPA is that entities are light weight  
and cheap to create, so you take the safe route and construct a  
new one when every you need an instance.  In CMP the assumption  
is that entity instances are expensive to create, so less safe  
route and you pool them.  Reusing instances is really a CMP  
problem, but I don't think it can be implemented without the  
help of the JPA engine.


I'm afraid we're getting wrapped around the axle on definitions.  
Here's what I'm trying to get across:


CMP Entity Beans are expensive to create and there's a lot of  
required behavior to manage them. You pretty much have to  
implement the life cycle in the spec. It's your choice how to  
implement the "state" part of the beans. You can use wrappers  
around various kinds of state objects like ResultSet or generated  
classes that contain fields with the state.


Your implementation uses JPA Entities to hold the state. These  
JPA Entities are not at all specified by CMP Entity Beans. JPA  
Entities as cheap to create so all you need to do is hold on to  
the ids and when you need state from the database, ask JPA  
EntityManager for the state. If the state is already in the  
second level cache, this is very cheap to access.


In my implementation the CMP entity is the JPA entity.  They are  
the same object.  There are no "state holders".


Now I understand. I don't think the design works, from lots of  
different perspectives.


We choose this design to easy the transition from CMP to JPA but  
has the drawback that we are completely reliant on the JPA  
implementation for instance management.


I don't think the design can work. The CMP protocol requires  
separating the CMP instance from its state. You are generating the  
CMP concrete implementation class as part of deployment, and the  
concrete class needs to contain state or a reference to state. My  
experience is that keeping state directly in the CMP bean isn't  
likely to work well.


Sorry for the distracting comments. I didn't imagine that you were  
trying to directly persist CMP beans.


I can assure the design "works".

-dain

RE: Testing an OpenJPA module

2007-04-10 Thread Pinaki Poddar

 > provide a patch.
Will such a patch be given to Glassfish project? 
But some kind of committer-level privilege will be required, i suppose.

have added few more informative messages to distinguish between
different ways persistence unit creation/ lookup can fail. 
please advise on how to proceed on contributing a patch.   

Pinaki Poddar
BEA Systems
415.402.7317  

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, April 10, 2007 4:14 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Testing an OpenJPA module

FYI, Persistence is an open source project at Glassfish.

Anyone, even an OpenJPA contributor, who wants to contribute to the
project for example to improve the error messages, is welcome to look at
the sources and provide a patch. I know people who will be happy to
commit usability patches. ;-)

Craig

On Apr 10, 2007, at 1:54 PM, Pinaki Poddar wrote:

> The error message could have been more specific in the following way:
> a) no META-INF/persistence.xml has not been found in classpath
> b) META-INF/persistence.xml has been found but there is no 'ode-store'
> unit defined in it.
> c)  META-INF/persistence.xml has been found but provider can not be
> loaded/invoked
>
> When I first encountered this error, my interpreation was (b) from the
> way the message was worded.
>
>
> Pinaki Poddar
> BEA Systems
> 415.402.7317
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek
> Laskowski
> Sent: Tuesday, April 10, 2007 2:52 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: Testing an OpenJPA module
>
> On 4/10/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote:
>>
>> Glad you got it fixed. It's annoying that
>> javax.persistence.Persistence doesn't provide more of a clue as to  
>> why
>
>> it failed.
>
> I wonder what else you'd like to see other than what's already printed
> out? It tells exactly why it's failed - "No Persistence provider for
> EntityManager named ode-store" is just a JPA version of
> "NoClassDefFoundError" in "pure" Java.
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.JacekLaskowski.pl
>
> Notice:  This email message, together with any attachments, may  
> contain information  of  BEA Systems,  Inc.,  its subsidiaries   
> and  affiliated entities,  that may be confidential,  proprietary,   
> copyrighted  and/or legally privileged, and is intended solely for  
> the use of the individual or entity named in this message. If you  
> are not the intended recipient, and have received this message in  
> error, please immediately return this by email and then delete it.

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

Notice:  This email message, together with any attachments, may contain 
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
entities,  that may be confidential,  proprietary,  copyrighted  and/or legally 
privileged, and is intended solely for the use of the individual or entity 
named in this message. If you are not the intended recipient, and have received 
this message in error, please immediately return this by email and then delete 
it.

Float primary key?