Comments inlined...
- Original Message -
From: Phill Moran [EMAIL PROTECTED]
To: open-jpa-dev@incubator.apache.org
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
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
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
+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
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
[
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
[
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?
[
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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-
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:
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
@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
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
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
[
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?
[
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
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
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
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),
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
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
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
--
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,
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
42 matches
Mail list logo
