Hi,
I'm using the ReverseMappingTool to reverse an Oracle schema. When I do
this everything works great, except the entities it generates do not
include the actual table name. So, for example, if I've got a table
called DEPARTMENT_STORE it creates an entity like:
entity
This sounds like something that was fixed a while ago. What version
of OpenJPA are you using?
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries
I'm using 0.9.6. Isn't that the latest?
-Original Message-
From: Abe White [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 01, 2007 11:21 AM
To: open-jpa-dev@incubator.apache.org
Cc: Kennedy, Dan
Subject: Re: ReverseMappingTool doesn't include table/column names in
entities
This
That's the latest release, but it came out a few months ago. The 0.9.7
snapshot has a bunch of bugfixes etc.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may
[
https://issues.apache.org/jira/browse/OPENJPA-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469545
]
Dain Sundstrom commented on OPENJPA-123:
You can list excluded tests in the maven pom. If you are using
Does JPA or OpenJPA have support for what is called unknown primary
key in the EJB CMP 2.0 spec. An unknown primary key is the pk of an
entity bean that does not have a field (or abstract getter/setter)
for a primary key. Instead the framework adds a virtual field to the
bean that
Hi,
According to the discussion at
https://issues.apache.org/jira/browse/OPENJPA-123, it looks like
TestNG's concept of test groups could let us easily create tests that
are expected to fail, and exclude them from test runs until the
corresponding behavior is fixed / feature is implemented. What
[
https://issues.apache.org/jira/browse/OPENJPA-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Linskey updated OPENJPA-123:
I think that I prefer moving to TestNG; I like the idea of keeping the
information about
My only concern is IDE support and specifically the IDE I use
intellij. Does this work as a test case type in IntelliJ and Eclipse?
If so, I don't really care which framework we use.
-dain
On Feb 1, 2007, at 11:08 AM, Patrick Linskey wrote:
Hi,
According to the discussion at
I see that they have a plugin for Eclipse, but I haven't tried it yet. It
doesn't look like it supports IntelliJ. On the surface, the conversion and
usage looks doable and would satisfy the failed testcase problem.
My question is whether it's worth the effort. If we have a testcase that
has
On Feb 1, 2007, at 11:39 AM, Kevin Sutter wrote:
I see that they have a plugin for Eclipse, but I haven't tried it
yet. It
doesn't look like it supports IntelliJ. On the surface, the
conversion and
usage looks doable and would satisfy the failed testcase problem.
We can exclude tests
This looks good, but in my case I can't annotate the classes. Is
there a way to specify this via XML or a property?
-dain
On Feb 1, 2007, at 11:42 AM, Patrick Linskey wrote:
Yes, you can do this:
http://incubator.apache.org/openjpa/docs/latest/manual/
manual.html#ref_g
[
https://issues.apache.org/jira/browse/OPENJPA-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469562
]
Abe White commented on OPENJPA-119:
---
But, since I don't know how JDO is using the kernel, it's kind of difficult
This just in:
If I have to do it individually to files, is there some way to
ensure that
any text file checked it gets this property set? Otherwise, we're
bound to
forget to set it frequently.
Yes, it's a new feature in your ~/.subversion/config file, not yet
documented in the Book.
[
https://issues.apache.org/jira/browse/OPENJPA-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469565
]
Kevin Sutter commented on OPENJPA-119:
--
Sure, I can do the boolean parameter. I just thought a compile
I get tons of output from the tests. Is there a way to change the log
level to WARNING?
RTFM reference?
Thanks,
Craig
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
Cedric alleges that the IntelliJ integration is on par with JUnit in the
current version, and Hani claims that upcoming IntelliJs will have even
better support out-of-the-box.
Personally, I run the tests via Maven.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
mvn test -Dopenjpa.loglevel=WARN, I believe.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries
Here's a good article comparing TestNG with JUnit:
http://www-128.ibm.com/developerworks/java/library/j-cq08296/
IMO, the groups feature is nice, but isn't necessarily sufficient to
justify a lot of effort porting over tests (since we could always
just check a system property before
So for OpenJPA, the [auto-props] section should include the following as
well:
*.java: svn:eol-style=LF
*.properties: svn:eol-style=LF
*.xml: svn:eol-style=LF
I haven't tried this out yet, but TFM claims that those are the correct
values. Sadly, as far as I can tell, this cannot be used to
For what it's worth Marc is right. I've used testng via the surefire plugin
as a front end to running jUnit tests. In my case I just tried to get them
to run in parallel, but we should be able to use groups in the same manner.
On 2/1/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
Here's a
Sadly, not currently. OpenJPA domain model extensions are not currently
available in XML form. See OPENJPA-87 for a related issue.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with
Sadly, not currently. OpenJPA domain model extensions are not
currently
available in XML form. See OPENJPA-87 for a related issue.
While this is true, I believe if you just don't declare any @Id
fields we'll probably default to datastore identity automatically.
I upgraded to openjpa-0.9.7-incubating-SNAPSHOT and still get the same
results. By the way, thanks for your help so far.
-Original Message-
From: Patrick Linskey [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 01, 2007 1:09 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE:
I upgraded to openjpa-0.9.7-incubating-SNAPSHOT and still get the
same
results. By the way, thanks for your help so far.
I get table and column names when I run the tool. Are you sure you
aren't looking at old output? Can someone else attempt to reproduce
this problem?
[
https://issues.apache.org/jira/browse/OPENJPA-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Linskey resolved OPENJPA-37.
Resolution: Fixed
Added antlib files. Usage:
project
taskdef
Hi,
mvn test -Dopenjpa.loglevel=WARN
Thanks for that, Patrick. When I use this, two things happen, as
below. Using -Dopenjpa.Log=openjpa ( DefaultLevel=WARN ) turns off
the INFO logging messages from the [resources:resources] part of the
maven task. Apparently this isn't affected by the
Running mvn -Dopenjpa.Log=openjpa ( DefaultLevel=WARN ) -
Dopenjpa.loglevel=WARN install
seems to work to set the level in the two different maven tasks,
although I'm confused why there are two different properties used to
control the log messages.
Any ideas?
The -Dopenjpa.loglevel
Right. openjpa.loglevel=WARN is just converted to -
Dopenjpa.Log=DefaultLevel=WARN.
It'd be nice if you could just specify the latter from the console,
but unfortunately surefire doesn't propagate system properties
through to the forked Surefire test runner, so we need to special-
case
+ taskdef name=kodoc
classname=org.apache.openjpa.ant.PCEnhancerTask/
Shouldn't that be openjpac? Or maybe just enhance?
On Feb 1, 2007, at 2:03 PM, [EMAIL PROTECTED] wrote:
Author: pcl
Date: Thu Feb 1 14:03:31 2007
New Revision: 502374
URL:
[
https://issues.apache.org/jira/browse/OPENJPA-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469604
]
Craig Russell commented on OPENJPA-115:
---
Yes, null checking is an expected requirement when dealing with weak
:-) His past comes back to haunt him... :-) Nice catch, Marc.
On 2/1/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
+ taskdef name=kodoc
classname=org.apache.openjpa.ant.PCEnhancerTask/
Shouldn't that be openjpac? Or maybe just enhance?
On Feb 1, 2007, at 2:03 PM, [EMAIL
[
https://issues.apache.org/jira/browse/OPENJPA-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Sutter resolved OPENJPA-115.
--
Resolution: Fixed
Changes committed to SVN.
Bottleneck(s) with using OpenJPA in a
Good catch. I changed it to openjpac.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and
Actually, I think prefer enhance to openjpac, since if I
understand antlib taskdefs correctly, won't they be prefixed with
something like openjpa? If so, I think:
openjpa:enhance src=${src}/
it more descriptive than:
openjpa:openjpac src=${src}/
On Feb 1, 2007, at 3:04 PM,
They're only prefixed if you provide a URN for them when you include the
taskdef. But I'm open to either name.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may
Hi,
There's a bit of ambiguity in the spec about what should happen when an
exception is thrown from a callback.
I propose that we change OpenJPA's behavior to always wrap exceptions
thrown from callbacks in a RollbackException. Additionally, I propose
that if a callback is thrown from a direct
openjpac looks like open j pac to my eyes
-dain
On Feb 1, 2007, at 3:20 PM, Patrick Linskey wrote:
They're only prefixed if you provide a URN for them when you
include the
taskdef. But I'm open to either name.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
On Feb 1, 2007, at 3:27 PM, Patrick Linskey wrote:
3.5.6:
Lifecycle callback methods may throw runtime exceptions. A runtime
exception thrown by a callback method that executes within a
transaction
causes that transaction to be rolled back. No further lifecycle
callback
methods will be
3.5.6:
Lifecycle callback methods may throw runtime exceptions. A runtime
exception thrown by a callback method that executes within a
transaction
causes that transaction to be rolled back. No further lifecycle
callback
methods will be invoked after a runtime exception is
40 matches
Mail list logo
