from:"Patrick Linskey"

[jira] Commented: (OPENJPA-235) SQL reordering to avoid non-nullable foreign key constraint violations

2007-05-25 Thread Patrick Linskey (JIRA)

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

Patrick Linskey commented on OPENJPA-235:
-

Hi,

Attach the patch to the JIRA and one of those of us with TCK access will run it
against the TCK.

SQL reordering to avoid non-nullable foreign key constraint violations
--

Key: OPENJPA-235
URL: https://issues.apache.org/jira/browse/OPENJPA-235
Project: OpenJPA
Issue Type: Improvement
Components: kernel
Reporter: Reece Garrett
Assigned To: Patrick Linskey
Fix For: 0.9.8

Attachments: openjpa-235-test.jar, sqlreorder.patch

OpenJPA does not do any SQL statement re-ordering in order to resolve foreign
key constraints. Instead, objects are always inserted in the order in which
the user persists the instances. When you persist in an order that would
violate foreign key constraints, OpenJPA attempts to insert null and then
update the foreign key value in a separate statement. If you use non-nullable
constraints, though, you must persist your objects in the correct order.
This improvement re-orders SQL statements as follows:
1. First, all insert statements execute. Inserts which have foreign keys with
non-nullable constraints execute AFTER the foreign keys which they depend on
have been inserted since no deferred update is possible.
2. Next, all update statements execute. No reordering is necessary.
3. Finally, all delete statements execute. Like inserts, deletes execute in
an order which does not violate non-nullable foreign key constraints.
If a circular foreign key reference is found during the re-ordering process
then re-ordering halts and the remaining unordered statements are left as is.
There is nothing that can be done about the circular reference (other than
fixing the schema) and the resulting SQL statements will not succeed.
The net effect is that users do not need to worry about the persistence order
of their objects regardless of non-nullable foreign key constraints. The only
class modified was
org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager. I have included a
patch which includes my modifications to OperationOrderUpdateManager and test
cases. The test cases I have provided fail on the current trunk but pass with
my modifications. I have also verified that I did not break anything by using
maven to run all test cases with my modifications in place.

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

[jira] Commented: (OPENJPA-242) JCache (JSR 107) support in the OpenJPA DataCache

2007-05-25 Thread Patrick Linskey (JIRA)


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

Patrick Linskey commented on OPENJPA-242:
-

With a small amount of work, we could abstract away the needs of QueryCache and 
DataCache such that you only needed to implement one interface to add support 
for a new cache. I prefer taking that approach, because the amount of work 
needed would then be pretty trivial, and that would benefit all configurations.

 JCache (JSR 107) support in the OpenJPA DataCache
 -

 Key: OPENJPA-242
 URL: https://issues.apache.org/jira/browse/OPENJPA-242
 Project: OpenJPA
  Issue Type: New Feature
  Components: datacache
Affects Versions: 0.9.0, 0.9.6, 0.9.7
Reporter: Marc Prud'hommeaux
Priority: Minor

 JSR 107 (JCache: http://jcp.org/en/jsr/detail?id=107 ) support would enable 
 OpenJPA to integrate its data cache with supporting products in a transparent 
 way. This would allow us to support the popular EHCache 1.3 and other JSR 107 
 compliant caching layers.

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

Re: Test failures

2007-05-24 Thread Patrick Linskey

)
 at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSe
t(AbstractDirectoryTestSuite.java:135)
 at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute
(AbstractDirectoryTestSuite.java:122)
 at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess
(SurefireBooter.java:225)
 at org.apache.maven.surefire.booter.SurefireBooter.main
(SurefireBooter.java:747)

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.




--
Patrick Linskey
202 669 5907

Re: Ready to move OpenJPA svn repository?

2007-05-22 Thread Patrick Linskey


Let's do it.

Once it's done, we should immediately do the restructuring of
directories that we discussed earlier.

-Patrick

On 5/22/07, Craig L Russell [EMAIL PROTECTED] wrote:

I think we're about ready to move the repository from https://
svn.apache.org/repos/asf/incubator/openjpa/ to https://svn.apache.org/
repos/asf/openjpa/

If you have changes in your local repository that you want to
preserve, you will need to do an svn switch to change your local repo
to the new location.

Any objections to making the switch? Any last minute changes you want
to commit?

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!






--
Patrick Linskey
202 669 5907

Re: How do we know the entity is successfully deployed on appserver

2007-05-22 Thread Patrick Linskey

It's up to each app server to decide how you can check the deployment status.

I think it'd be good, though, if OpenJPA had a setting or an API call
to ensure that everything was up and running once the factory was
created. Currently, that API call is:

emf.createEntityManager().close();

It'd be nice at least to provide either a declarative (setting)
approach for that, or an API that does just that but sounds a bit less
hacky. We could then potentially optimize the API at a later time.

-Patrick

On 5/22/07, Marina Vatkina [EMAIL PROTECTED] wrote:

Joshua,

If you deploy an application into an appserver, and your persistence.xml
contains the openjpa.jdbc.SynchronizeMappings property, the tables will be
created on the 1st emf.createEntityManager() call (or injection of EM that does
the same in the background), i.e. on every redeploy or server restart.

It's up to each app server to decide how you can check the deployment status.

Regards,
-marina

Kevin Sutter wrote:
Joshua,
Most definitely you can ask user questions on this list. Thanks for
posting.

OpenJPA provides the ability to autogenerate the database tables at runtime
via the SynchronizeMappings property in the persistence.xml. Here's an
example usage:

persistence-unit name=inheritance
classmy.persistence.tests.inheritance.RootEntity/class
classmy.persistence.tests.inheritance.LeafEntity/class
classmy.persistence.tests.inheritance.AbstractEntity/class
properties
property name=openjpa.ConnectionDriverName
value=org.apache.commons.dbcp.BasicDataSource/
property name=openjpa.ConnectionProperties
value=DriverClassName=org.apache.derby.jdbc.EmbeddedDriver

,Url=jdbc:derby:target/temp/play/play.test;create=true,MaxActive=100,MaxWait=1,TestOnBorrow=true/

property name=openjpa.jdbc.SynchronizeMappings
value=buildSchema(ForeignKeys=true)/
property name=openjpa.Log value=DefaultLevel=INFO/
/properties
/persistence-unit

On 5/11/07, Joshua Jackson [EMAIL PROTECTED] wrote:

Dear all,

How do I know whether an entity is successfully deployed on an
appserver? Usually I detect this by autogenerating tables in database.
Is there anyway I can autogenerate tables in database with OpenJPA?
I've searched in documentation but perhaps I have missed it when
reading it.

Last but not least, am I allowed to ask user questions in this list?
Since this is a dev list.

Thanks in advance

--
YM!: thejavafreak
Blog: http://www.nagasakti.or.id/roller/joshua/

--
Patrick Linskey
202 669 5907

[jira] Commented: (OPENJPA-130) Streaming LOB support

2007-05-21 Thread Patrick Linskey (JIRA)


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

Patrick Linskey commented on OPENJPA-130:
-

Ignacio Andreu will be working on this issue for the Google Summer of Code 
project. It would seem that JIRA only allows me to assign issues to committers, 
so I'm assigning it to myself to keep it out of the unassigned queue.

 Streaming LOB support
 -

 Key: OPENJPA-130
 URL: https://issues.apache.org/jira/browse/OPENJPA-130
 Project: OpenJPA
  Issue Type: New Feature
  Components: datacache, jdbc, jpa, kernel
Reporter: Patrick Linskey
 Assigned To: Patrick Linskey
 Fix For: 1.1.0


 BLOB and CLOB fields can only be mapped in their entirety in OpenJPA. It 
 would be nice to support fields of type java.io.InputStream (for BLOBs) and 
 java.io.Reader (for CLOBs).
 The usage pattern could look like so:
 @Entity
 public class Employee {
 ...
 private InputStream photoStream;
 public void setPhotoStream(InputStream in) {
 photoStream = in;
 }
 public InputStream getPhotoStream() {
 return photoStream;
 }
 }
 So, when the user wants to provide a stream, she will set the InputStream 
 field, and when the user wants to obtain a stream, she will use the field.
 The behavior of such an implementation would be a bit different than how 
 other fields work, in that if the user set the stream and then consumed it 
 within a single transaction, presumably no data would be written out to the 
 database at commit time. But that is the nature of streams.
 (FTR, I think that I stole this idea from an email Craig Russell sent out 
 years ago.)

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

[jira] Commented: (OPENJPA-243) IntelliJ IDEA plugin to integrate OpenJPA enhancer into build process

2007-05-21 Thread Patrick Linskey (JIRA)

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

Patrick Linskey commented on OPENJPA-243:
-

The plugin as of r540340 integrates the OpenJPA enhancer with IntelliJ IDEA's
build process.

It requires IntelliJ IDEA 7.0M1 or more recent. It also requires a recent build
of OpenJPA, due to classloader issues in the PCEnhancer. The plugin does not
currently validate that it has a satisfactory OpenJPA version.

The plugin does not bundle OpenJPA jars inside it; this is intentional. In
order to use the plugin, you must have OpenJPA in your module's classpath
(which is already a requirement for running any tests with OpenJPA). The plugin
will pick up the OpenJPA version in your module and use it. If OpenJPA is not
available in the classpath, the plugin should gracefully short-circuit.

The plugin will run the enhancer on all persistent types (@Entity,
@MappedSuperclass, @Embeddable) in certain of the persistence units in the
module being compiled. It will only run on persistence units that either do not
define a persistence provider or specify the OpenJPA persistence provider.

IntelliJ IDEA plugin to integrate OpenJPA enhancer into build process
-

Key: OPENJPA-243
URL: https://issues.apache.org/jira/browse/OPENJPA-243
Project: OpenJPA
Issue Type: New Feature
Components: kernel, third-party
Affects Versions: 0.9.0, 0.9.6, 0.9.7
Environment: IntelliJ IDEA 7.0M1, OpenJPA 0.9.8-SNAPSHOT
Reporter: Patrick Linskey
Assigned To: Patrick Linskey
Fix For: 0.9.8

Attachments: OpenJPA-0.1.zip

It would be nice if OpenJPA's enhancer could be automatically invoked when
compiling persistent types in IntelliJ IDEA.

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

[jira] Commented: (OPENJPA-243) IntelliJ IDEA plugin to integrate OpenJPA enhancer into build process

2007-05-21 Thread Patrick Linskey (JIRA)


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

Patrick Linskey commented on OPENJPA-243:
-

One missing instruction from the previous comment: the 0.1 plugin piggy-backs 
on top of the IntelliJ IDEA 7 JPA facet. So, you must have your module set up 
to use a JPA facet in order for the OpenJPA plugin to run on the classes in the 
module.

 IntelliJ IDEA plugin to integrate OpenJPA enhancer into build process
 -

 Key: OPENJPA-243
 URL: https://issues.apache.org/jira/browse/OPENJPA-243
 Project: OpenJPA
  Issue Type: New Feature
  Components: kernel, third-party
Affects Versions: 0.9.0, 0.9.6, 0.9.7
 Environment: IntelliJ IDEA 7.0M1, OpenJPA 0.9.8-SNAPSHOT
Reporter: Patrick Linskey
 Assigned To: Patrick Linskey
 Fix For: 0.9.8

 Attachments: OpenJPA-0.1.zip


 It would be nice if OpenJPA's enhancer could be automatically invoked when 
 compiling persistent types in IntelliJ IDEA.

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

Re: First post-graduation OpenJPA release

2007-05-20 Thread Patrick Linskey


It sounds like there are a bunch of new things that we'll be doing in
this process; maybe we should do a 0.9.8 first to get the various
artifacts all sorted out, and then do a 1.0?

-Patrick

On 5/20/07, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

that said, this is the OpenJPA project, and no matter what the state
of the infra move, anything that this group does now is independent
and disconnected from the incuabtor


On May 19, 2007, at 10:15 PM, Eddie O'Neil wrote:

  +1 -- assuming the code is ready to go, I agree that it's a good
 idea to go straight to 1.0.

  +1 as well to waiting until the TLP infrastructure is complete,
 which could take a week or more to unbrand from the Incubator, move
 the website content, etc.

 Eddie



 On 5/19/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:

 I personally lean towards just bumping it up to 1.0 and cutting a
 release as soon as possible after we complete the incubator-TLP
 process. A release number  1.0 suggests to so many people that a
 product is not production-ready, and OpenJPA is so mature and in use
 in so many mission-critical systems that I think we should just bump
 all the open issues to a 1.0.1 or 1.1 release and get a 1.0 release
 out in the public.



 On May 19, 2007, at 4:31 PM, Craig L Russell wrote:

  Hi,
 
  There's no urgency, but I think we should start discussing what our
  first release should be out of incubation.
 
  Let's take a look at the issues in JIRA and decide if we think that
  we're ready for a 1.0 release. If not, we can cut a 0.9.8 release
  and make a list of 1.0 bugs/features to follow.
 
  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!
 







--
Patrick Linskey
202 669 5907

Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)

2007-05-17 Thread Patrick Linskey

How hard is it to add a reflection/cglib type alternative to the upfront
bytecode generation (like hibernate does) to save us from the
development-time pain?

Not particularly hard. There are a few APIs that would break for some
cases, but it's even pretty straightforward to do a subclassing
approach for property-based access type without losing much
performance -- the only cost in that configuration is with
persistent-new instances.

-Patrick

On 5/17/07, James.Strachan [EMAIL PROTECTED] wrote:

Firstly before I start, openjpa is a great piece of software; I'm
particularly fond of the documentation and in particular the query language
parts. The CSS for the site is also awesome :)

However compared to hibernate, openjpa is still pretty painful to use from
an end users perspective and I don't think this should be the case; plus I
don't think it'll take much time to fix. While the pain is still fresh in my
mind I thought I'd post on how much more painful openjpa is to use in a
project. If you're short on time, the basic idea is its that bytecode post
processing stuff thats to blame :). Yes I know its probably faster that way
- its just so painful for Java programmers to work with. (And yes I know one
day we'll all have IDE plugins that hide the bytecode stuff etc etc).

So the first thing is having to mess with your build (ant or maven) to get
the post processing properly integrated. Depending on if you have persistent
entities in your main or test area this can often trip you up a little (as
it did me). I don't know about folks on this list but the whole idea of
having to mess with my maven build gives me the jitters :). When you get
that far the maven planets are aligned with openjpa, the next hurdle you
hit is how do you run stuff in your IDE. If like me you use IDEA and maven
2, the project gets auto-created by default for all projects you work on.
However these don't work when you use openjpa as you hit the dreaded 'cannot
function at all as you've not run the up front bytecode post processor you
dummy!' type error when trying to run stuff in your IDE.

So you then add the maven-generated classes to the front of the classpath in
your project. Hooray, after a day or two's work, you can now actually use
openjpa in your IDE and your build. YAY! The downside is that now when
navigating around your Java code, whenever you navigate into an entity bean,
IDEA shows you the bytecode - not the source code as its confused since the
bytecode generated stuff is different to the source code it knows about. So
now you're faced with a dilemma - choose between navigating nicely around
your source code - or being able to actually run/debug your application. I
won't even get into the refactoring pain or having to continuously run maven
builds while developing code to avoid getting code completion/compile errors
etc. (I prefer to keep in my IDE where possible).

Compare this whole malarkey with hibernate. You add hibernate to your pom,
generate your project and you're good to go. No messing with your project
build; no messing with some secret ninja IDE stuff to be able to actually
run debug your code while still being able to actually navigate the
source. It just works. Now it might work in a crappy slow way and openjpa
might be way way more efficient and powerful and whatnot - but I'd rather
have a cheap car that just works than a ferrari that you can only drive on a
tuesday if its sunny, but not too hot and refuses to even start if its wet.

FWIW I've just given up using openjpa for development; its just way too
painful. (I'm even hacking projects I work on so I use openjpa in the maven
build but explicitly switch to hibernate in development mode; yeah its more
work but at least I can use my IDE properly again).

I'm cool with putting post processing into the build system (though that
should really only be an optimisation); but please can we have some
inefficient but usable reflection/cglib type approach so folks can easily
switch from hibernate to openjpa (and stay there) without pulling out our
hair swearing too much - or sneaking back at the first opportunity to get
an easy life?

Please don't take this mail the wrong way - I truly want openjpa to be a
success, its a great piece of software. Its just a bit too hard to use out
of the box right now. I'd truly like it to be trivial to switch from
hibernate to openjpa and never have to go back.

How hard is it to add a reflection/cglib type alternative to the upfront
bytecode generation (like hibernate does) to save us from the
development-time pain?

--
James
---
http://macstrac.blogspot.com/

--
View this message in context:
http://www.nabble.com/the-pain-of-post-processing-bytecode-%28another-beg-for-a-simple-reflection-cglib-alternative-like-hibernate%29-tf3770760.html#a10660986
Sent from the open-jpa-dev mailing list archive at Nabble.com.

--
Patrick Linskey
202 669 5907

Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)

2007-05-17 Thread Patrick Linskey

.

 FWIW I've just given up using openjpa for development; its just way too
 painful. (I'm even hacking projects I work on so I use openjpa in the
 maven
 build but explicitly switch to hibernate in development mode; yeah its
 more
 work but at least I can use my IDE properly again).

 I'm cool with putting post processing into the build system (though that
 should really only be an optimisation); but please can we have some
 inefficient but usable reflection/cglib type approach so folks can easily
 switch from hibernate to openjpa (and stay there) without pulling out our
 hair  swearing too much - or sneaking back at the first opportunity to
 get
 an easy life?

 Please don't take this mail the wrong way - I truly want openjpa to be a
 success, its a great piece of software. Its just a bit too hard to use out
 of the box right now. I'd truly like it to be trivial to switch from
 hibernate to openjpa and never have to go back.

 How hard is it to add a reflection/cglib type alternative to the upfront
 bytecode generation (like hibernate does) to save us from the
 development-time pain?

 --
 James
 ---
 http://macstrac.blogspot.com/

 --
 View this message in context:
 
http://www.nabble.com/the-pain-of-post-processing-bytecode-%28another-beg-for-a-simple-reflection-cglib-alternative-like-hibernate%29-tf3770760.html#a10660986
 Sent from the open-jpa-dev mailing list archive at Nabble.com.






--
Patrick Linskey
202 669 5907

Re: Will reversemappingTask() generate EJB3 annotations?

2007-05-16 Thread Patrick Linskey


Also, FWIW, the BEA Workshop tool (eclipse-based) will
reverse-generate classes from a database as well, and supports putting
the metadata into annotations.

-Patrick

On 5/16/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:


That is correct: the reversemappingtool only currently supports
generating an orm.xml file. We would like to add support for
generating annotations someday, but it is not there yet.

Take a look at the reversemapping example in a recent openjpa
snapshot for an example of running the reversemappingtool from a
build.xml file.



On May 16, 2007, at 10:26 AM, Michael Dick wrote:

 That's what I've found too. The reversemapping tool will create new
 java
 files based on the database tables, and provide an orm.xml file. No
 annotations though.

 You can always add them based on the generated orm.xml file
 although that
 might be easier said than done if you have a lot of entities.

 -mike

 On 5/16/07, Phill Moran [EMAIL PROTECTED] wrote:

 I am not sure that it will annotate your exiting code but (I
 think) it
 will make
 an external mapping file for you or generate the annotated classes
 from
 the
 ground up. Check out the MappingTool class/docs

 -Original Message-
 From: linda rae [mailto:[EMAIL PROTECTED]
 Sent: May 16, 2007 8:58 AM
 To: open-jpa-dev@incubator.apache.org; open-jpa-
 [EMAIL PROTECTED]
 Subject: Will reversemappingTask() generate EJB3 annotations?

 I apologize if this question has been previously asked and
 answered.  I
 have
 googled for an answer with no luck.

 I have been requested to use OpenJPA on a project.  The tool appears
 straight
 forward and works well, I have ran the reverse engineering example
 on my
 own DB
 - it works great.  However... no EJB3 annotations were generated
 (@Entity,
 etc).


 What configuration option must I define to have the reversemapping
 tool
 generate
 an EJB3 EntityEJB?

 A short response would be great - any response would would really
 help (am
 I
 asking for something that does not exist?)

 Thank-you,

 Linda Rae








--
Patrick Linskey
202 669 5907

Re: Embedding OpenJPA

2007-05-16 Thread Patrick Linskey


That sounds like the right way to do it. So my container would, on
startup, instantiate OpenJPA's PersistenceProviderImpl, and invoke
createContainerEntityManagerFactory() with a PersistenceUnitInfo that I
implement?


Yes. Note that OpenJPA already has an PUInfo implementation that you
might want to take advantage of.


I can see that this gives me a great deal of control over classloading,
transactions, etc. But it looks like I still need to supply all managed
class names up front, and must refer to mapping information as file
references?


Not necessarily -- OpenJPA supports dynamically discovering new
classes as they are loaded, so you could certainly take advantage of
that.

Some things cannot be done until after OpenJPA has loaded a class. For
example, you cannot use a class's alais in a JPQL query until after
the class has been bootstrapped, and any named queries defined on the
class will not be visible until the class has been loaded.

I can't remember exactly how things work; it's possible that if you
list classes, then OpenJPA assumes that that is a complete list and
doesn't support lazy discovery of classes.


I am hoping for a way to enhance and register classes as appropriate at
ordinary classloading time, or if that isn't possible at least discover
the classes dynamically at deployment time. Generally I'm trying to
avoid using persistence.xml.


Why? Are you trying to reduce it's complexity, or just eliminate it
altogether? How do you propose having your users configure things like
OpenJPA logging or tuning options? If you're planning on
re-introducing a significant percentage of these things, then you
might want to consider just using persistence.xml, but limiting which
parts can be used.


Likewise the mapping information should only come from annotations on
the managed classes, but ideally through me such that certain things
can be changed on the fly (such as field value and type conversion etc.)


What degree of control do you want? Control over defaults etc., or the
ability to override what the user specified? You can get a pretty
complete amount of control by implementing a MappingFactory;
presumably your implementation would delegate to the normal mapping
factory.

-Patrick

On 5/16/07, Dennis Thrysøe [EMAIL PROTECTED] wrote:

Patrick Linskey wrote:
 This means that your container would be responsible for EntityManager
 lifecycle and potentially for transaction control. It also means that
 you'd interact with OpenJPA via the
 PersistenceProvider.createContainerEntityManagerFactory() API. In such
 a scenario, you (the container) would be responsible for providing a
 PersistenceUnitInfo (you might want to take advantage of OpenJPA's
 existing XML-processing support to help out with this).

That sounds like the right way to do it. So my container would, on
startup, instantiate OpenJPA's PersistenceProviderImpl, and invoke
createContainerEntityManagerFactory() with a PersistenceUnitInfo that I
implement?

I can see that this gives me a great deal of control over classloading,
transactions, etc. But it looks like I still need to supply all managed
class names up front, and must refer to mapping information as file
references?

I am hoping for a way to enhance and register classes as appropriate at
ordinary classloading time, or if that isn't possible at least discover
the classes dynamically at deployment time. Generally I'm trying to
avoid using persistence.xml.

Likewise the mapping information should only come from annotations on
the managed classes, but ideally through me such that certain things
can be changed on the fly (such as field value and type conversion etc.)

Is this possible? Perhaps by providing certain properties in the map
when obtaining an EntityManagerFactory? Or am I being too creative here?

-dennis
---
The information in this email is confidential and may be legally protected.





--
Patrick Linskey
202 669 5907

Re: Will reversemappingTask() generate EJB3 annotations?

2007-05-16 Thread Patrick Linskey


Would you guys be interested in getting donations in that area?


Certainly!


We do have our homegrown solution that does that (along with some other
goodies as well). It's currently based on our metadata representation
reverse-engineered from the database schema, it'd be nice (read: more
flexible and maintainable) to have it based on openjpa metadata and
integrated in openjpa itself for the community to use.


The basics could be implemented as a new subtype of
ReverseMappingTool.ReverseCodeGenerator that did more intelligent
things in the various field / method generators; ideally, we'd want to
provide options for things like leaving ORM metadata in XML but
putting @Entity and @Id etc. in classes, and obviously the ability to
not write any XML at all and put everything in annotations instead.

-Patrick

On 5/16/07, Gokhan Ergul [EMAIL PROTECTED] wrote:

Marc Prud'hommeaux wrote:

 That is correct: the reversemappingtool only currently supports
 generating an orm.xml file. We would like to add support for
 generating annotations someday, but it is not there yet.


Would you guys be interested in getting donations in that area? We do
have our homegrown solution that does that (along with some other
goodies as well). It's currently based on our metadata representation
reverse-engineered from the database schema, it'd be nice (read: more
flexible and maintainable) to have it based on openjpa metadata and
integrated in openjpa itself for the community to use.

Gokhan.








--
Patrick Linskey
202 669 5907

Re: JNDI lookup in OpenJPA.

2007-05-16 Thread Patrick Linskey


Hi,

Are you writing this in an EJB, or some other artifact type?

-Patrick

On 5/14/07, Murali [EMAIL PROTECTED] wrote:

Hi,

I am new to OpenJPA technology.

I am having problems while performing JNDI lookup for the bean resources to get 
the EntityManagerFactory instance.

I am trying to perform JNDI lookup operation to fetch the DataSource  
EntityManagerFactory instances to connect to the DataBase.

Following is the code snippet:

public static EntityManagerFactory  getOpenJPASessionFactory(String 
jndiSessionFactoryName)  throws DaoException {
EntityManagerFactory emFactory = null;
try {
   Context ctx = new InitialContext();
   emFactory = (EntityManagerFactory) ctx.lookup(jndiSessionFactoryName);
}catch (ClassCastException cce) {
   throw new DaoException(DaoConstants.OPENJPA_FACTORY_ERROR, cce);
} catch (NamingException ne) {
   throw new DaoException(DaoConstants.OPENJPA_FACTORY_ERROR, ne);
}
return emFactory;
}

When i try to get the EntityManager Instance from Factory instance, it says 
jndiSessionFactoryName is not bound, because of this i am not able to get the 
Datasource for performing the Database operations.

Following are the environment details:

Application Server: Jboss-4.0.4.GA
Operating System with version: Redhat Linux 4, with kernel version 2.6.9.42 
Elsmp
OpenJPA version: 0.9.7
JDK version: Jdk 1.5.0_07
Database: IBM DB2  version 9.1

Is there any interoperability issue of OpenJPA with Jboss-4.0.4.GA?
Do we have to upgrade to any newer version of Jboss ?

Please help me in this regard.

Thanks in advance.

Waiting for your response.

Regards,
Murali Krishna Adiraju.




--
Patrick Linskey
202 669 5907

Re: Using OpenJPA internal APIs to accessing meta-data for custom code generators

2007-05-15 Thread Patrick Linskey


Probably you should look at the AuxiliaryEnhancer in the PCEnhancer
class -- it gives you some hooks for doing further processing during
the OpenJPA enhancement process.


From there, you should look at ClassMetaData and MetaDataRepository.

That's got references to pretty much everything else you'll need.

-Patrick

On 5/15/07, Evan Ireland [EMAIL PROTECTED] wrote:

Folks,

I am exploring the idea of using OpenJPA internal APIs to obtain
meta-data from a persistence unit (e.g. JAR) for use in custom
code generation.

Since I'm a bit of a newbie to OpenJPA, it would be helpful if
someone could give me some starting pointers to save me a little
time.

Suppose I have the path to an O/S file (e.g. /mydevice/myentity.jar).

What would be the appropriate entry point into the OpenJPA APIs to
have it parse the deployment descriptor (if present) and combine
that meta data with the meta data collected from annotations?

What would be the appropriate entry point (I I were say to use
a visitor pattern) to 'visit' all the meta data thus obtained?

Finally, in regard to named queries, if the meta data indicates
a named query, what would be the appropriate API entry point to
obtain generated SQL for that query, without actually being
connected to a database (just from the meta data)?

Thanks in advance.





--
Patrick Linskey
202 669 5907

Re: Entity creation at Runtime

2007-05-14 Thread Patrick Linskey


Also, depending on how you have things configured, OpenJPA can lazily
discover classes for a given EntityManager. So, you shouldn't
necessarily need to re-initialize / reload anything in particular.

-Patrick

On 5/14/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:

James-

The CodeGenerator just generates .java file, so I don't think it will
be useful for your purposes.

Well, I suspect that if if you are currently generating classes using
CGLIB, then the easiest thing would be to just use CGLIB to add the
annotations as well.

Alternately, you could instead generate a separate orm.xml mapping
file conforming to the JPA specification, which would allow you to
define the mappings separately.



On May 14, 2007, at 11:18 AM, James Hang wrote:

 Thanks for the reply Marc.

 Is there a third party tool that can generate classes with
 annotations?
 Or is there something in OpenJPA that can do that?  I noticed a
 CodeGenerator class that can generate classes from metadata.  Can I
 use
 that?

 I'll take a look at the PCClassFileTransformer class like you
 suggested.

 Thanks for your help!

 James



 -Original Message-
 From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On
 Behalf Of
 Marc Prud'hommeaux
 Sent: Monday, May 14, 2007 10:30 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: Entity creation at Runtime

 James-

 It should be possible. The easiest way (and the most implementation-
 agnostic) would be to simply generate the classes with the
 appropriate mapping annotations, and then just load them at runtime.

 The somewhat tricky part would be to ensure they get enhanced by the
 system when they are loaded. You could just run the -
 javaagent:openjpa.jar flag with no arguments, and I believe it will
 scan all loaded classes for annotations, but that can slow things
 down quite a bit. A faster solution would be to run your generated
 classes through the enhancer.

 Take a look at the code for
 org.apache.openjpa.enhance.PCClassFileTransformer ... if you can't
 use that directly, then it might be good to use as a starting point.



 On May 14, 2007, at 10:00 AM, James Hang wrote:

 Hi,

 I'm curious if it's possible to create and map new entities at
 Runtime?
 We have an application which allows users to design new data
 models at
 runtime.  When new tables are being created in the database, we would
 like to make OpenJPA aware of them.  We are currently doing this in
 Hibernate by generating the POJO classes dynamically using CGLIB,
 adding
 dynamically generated xml mappings to the Hibernate runtime
 configuration and re-initializing the SessionFactory.  Is there a
 way to
 do something similar in OpenJPA?

 Thanks,

 James


 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.





--
Patrick Linskey
202 669 5907

Re: Embedding OpenJPA

2007-05-14 Thread Patrick Linskey


Hi Dennis,

If you don't want to use your Java EE's JPA integration features, you
might want to look at setting things up so that your content container
is generally a persistence container in the parlance of the JPA
spec.

This means that your container would be responsible for EntityManager
lifecycle and potentially for transaction control. It also means that
you'd interact with OpenJPA via the
PersistenceProvider.createContainerEntityManagerFactory() API. In such
a scenario, you (the container) would be responsible for providing a
PersistenceUnitInfo (you might want to take advantage of OpenJPA's
existing XML-processing support to help out with this).

The benefit of doing this is that it would provide the JPA consumers
(your internal team and extenders of your product) with runtime and
deployment semantics similar to what the JPA spec already does,
possibly with your own tweaks here and there to support additional
features.

-Patrick

On 5/14/07, Dennis Thrysøe [EMAIL PROTECTED] wrote:

Hello,

I'm planning on embedding OpenJPA in a server (which is running in a
J2EE environment). OpenJPA will run entirely within this server, and
together with added functionality implement a content container in
which entities can be depolyed, just as servlets can in a servlet container.

So, I was wondering if anybody here could help me get a little wiser on
OpenJPA. Does OpenJPA:

- Allow arbitrary instatiation and destruction, without requiring
anything directly from the J2EE framework?
- Allow dynamic deployment of Entities when they are loaded, or at
deployment time.
- Allow third parties (not the entity definitions) to define/override
things such as identity definition, field types (convert when
reading/writing etc.?

Any thoughts welcome.

-dennis
---
The information in this email is confidential and may be legally protected.





--
Patrick Linskey
202 669 5907

Re: What is the use of _impl and _fieldImpl in PCDataImpl class?

2007-05-14 Thread Patrick Linskey


They're used to store the data from OpenJPAStateManager.getImplData()
and getImplData(int  field).

Those impl data slots, in turn, are available for use by StoreManager
implementations for random bits of per-field or per-instance state
that doesn't fit elsewhere but is useful for the StoreManager
implementation.

This is similar to the 'intermediate data' concept, which you can see
in the get/set intermediate calls in that class.

OpenJPA uses intermediate data when it loads extra data from the
database that can be consumed later to materialize something, and impl
data for data that should be around for longer than just while the
field is not loaded.

For example, when OpenJPA loads an instance that has a -to-one
relation that is not eager, but not explicitly lazy, it will generate
SQL that selects the foreign key data for the relationship along with
the other primary-table data. That way, if you do lazily load the data
later, OpenJPA can go directly to cache, or at least bypass the join,
when loading the related data. That info is stored in an intermediate,
since either it or the relation itself can be loaded at any given
time.

Based no code analysis, it looks like OpenJPA only uses impl data for
BLOBs currently.\

-Patrick

On 5/14/07, Daniel Lee [EMAIL PROTECTED] wrote:

Hi,

I'm trying to understand OpenJPA open source code but having difficulties in
figuring out the use of _impl and _fieldImpl fields in PCDataImpl.  Could
someone help describe these 2 fields?  Many thanks in advance.

Tsunfang




--
Patrick Linskey
202 669 5907

OpenJPA meet-up at JavaOne?

2007-05-10 Thread Patrick Linskey


Hi,

After scheduling my third one-on-one meeting with an OpenJPA person
for this week, it just occurred to me that there are a lot of us in
town for JavaOne. Yes, I'm slow on the uptake sometimes.

Let's meet up this afternoon at the Thirsty Bear. How does 5:30pm sound?

In honor of the principle of freedom-as-in-beer, the first round will
be on BEA. As with all incubating projects, I'm hopeful that we can
establish a diversity in our round-sponsoring organization list.

-Patrick

--
Patrick Linskey
202 669 5907

Re: Accessing Trasaction or EnityManager in LifeCycle methods

2007-05-10 Thread Patrick Linskey


There is no JPA spec-mandated way to do this. In OpenJPA, you can do
the following:

EntityManager em = OpenJPAPersistence.getEntityManager(this);

Note that the JPA spec does not require that impls allow you to
operate on the EM during a callback. OpenJPA does allow this behavior.

You might also be interested in the OpenJPA transaction-level or
lifecycle-level callbacks. See the listener interfaces in
org.apache.openjpa.event. You can add these with a call to
OpenJPAEntityManager.addTransactionListener() and
OpenJPAEntityManager.addLifecycleListener().

-Patrick

On 5/10/07, Majeed Arni [EMAIL PROTECTED] wrote:




  If I have @PrePersist or @PreRemove, in the methods that gets called, how
can I access the Transaction object?

Example:

@PrePersist
public void prePersist()
{
 em.persist(anotherObj);   // How do I get access to em?
 
 }

Thanks for the help.
--
View this message in context: 
http://www.nabble.com/Accessing-Trasaction-or-EnityManager-in-LifeCycle-methods-tf3722974.html#a10417736
Sent from the open-jpa-dev mailing list archive at Nabble.com.





--
Patrick Linskey
202 669 5907

Re: [jira] Commented: (OPENJPA-236) No apparent way to generate all required SQL within a class derived from FullClassStrategy

2007-05-09 Thread Patrick Linskey


Have you confirmed with the customer that they must have one-sided
relations? It's possible that they won't really mind having extra
backpointers in their model.

-Patrick

On 5/9/07, David Ezzio [EMAIL PROTECTED] wrote:

Hi Abe,

I got a chuckle out of your solution, which, in a long tradition of good
engineering, changes the problem.

Unfortunately, customers are not always open to suggestions about how
their requirements can be modified.  So, I've changed the bug report to
a feature request, as it appears the issue is a limitation rather than a
bug.

Thanks,

David


Abe White wrote:
 It's possible that I'm stumbling around in the dark. If so, it
 would be
 great if you could shine a light on the issue.

 Just make it a two-sided relation, as is required by standard JPA.
 Problem solved.


 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.




--
Patrick Linskey
202 669 5907

Re: [VOTE RESULT] Packaging with maven

2007-05-09 Thread Patrick Linskey


Note that I only changed the artifact names, not the directory names
in which they reside. We can always start another vote on shuffling
around the directory names if people deem it a worthwhile endeavor.


I think that we should make the change, for the sake of reducing
future confusion. But we should probably just do it when we move out
of the incubator svn repo, since we'll presumably have to do other
changes at that time.

-Patrick

On 5/9/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:


With 5 +1 votes and no -1 or 0 votes, the proposal passes. I've gone
ahead and committed the patch for OPENJPA-194.

Note that I only changed the artifact names, not the directory names
in which they reside. We can always start another vote on shuffling
around the directory names if people deem it a worthwhile endeavor.



On May 6, 2007, at 2:27 PM, Marc Prud'hommeaux wrote:


 Poking around the ActiveMQ pom.xml files, I notice that you can
 have a different artifactId than the module name (i.e., directory)
 you are in. I hadn't known you could do this.

 Currently, our artifacts name are:

   trunk/pom.xml: openjpa
   trunk/openjpa-all/pom.xml: openjpa-all
   trunk/openjpa-project/pom.xml: openjpa-project

 We could change these to:

   trunk/pom.xml: openjpa-parent
   trunk/openjpa-all/pom.xml: openjpa
   trunk/openjpa-project/pom.xml: apache-openjpa

 I've tested this out, and it results in the openjpa aggregate jar
 being named openjpa-VERSION.jar, the dependency being simply
 named openjpa, and the assembly is named apache-openjpa-
 VERSION.zip. None of the directories needed to be renamed. I've
 attached the patch that does this to https://issues.apache.org/jira/
 browse/OPENJPA-194

 Since this will mess up people who currently have maven
 dependencies on OpenJPA (i.e., people who depend on openjpa-all
 will now need to depend on openjpa), we should probably get this
 hammered out before leaving incubation. So I've gone ahead and
 turned the [DISCUSS] into a [VOTE] to see if we should go ahead and
 do this.

 A vote of +1 means we should do the renaming, -1 means we should
 not, and 0 means don't care. The vote will remain open until
 Wednesday May 9th at 23:59 GMT.




 On May 4, 2007, at 6:55 AM, Michael Dick wrote:

 Some comments below

 On 5/4/07, Craig L Russell [EMAIL PROTECTED] wrote:

 I'd like reopen the discussion on how to package and name our
 artifacts. I think the current setup could be improved, to give a
 better experience for users who might not be using maven for
 dependency management. It's easy for us to change now before
 graduation because once we graduate, people will need to update
 their
 dependencies anyway so there are no backward compatibility issues.

 The name of the single jar that has all of the openjpa stuff in it
 except for the documentation and examples is currently called
 openjpa-
 all. This name is confusing because unless they RTFM, people don't
 really know that it's not all the code you need, just all the jpa
 code. So I'd like to call this artifact openjpa.


 +1

 But we already have a project with that name, and that project builds
 the distributions. So I'd rename the current openjpa to openjpa-
 dist.
 Its ultimate destination in the Apache mirror structure is under
 www.apache.org/dist/openjpa once we graduate, so having dist in the
 project name helps understanding that this project builds the
 artifacts that go into dist. Separate from the artifacts that are
 published via maven.


 +1

 Finally, the openjpa-all jar includes its subcomponents as
 dependencies. I think this is wrong, since you end up with a class
 path with openjpa-all.jar as well as openjpa-kernel.jar and all the
 others.


 I would like to change this too. I did a little experimenting and
 it looks
 like the dependencies aren't needed in openjpa-all, but they are
 needed for
 openjpa-project (to populate the lib directory). Moving the
 dependencies
 into openjpa-project should be safe.

 We're also going to need to change the deploy logic to strip out the
 -project suffix from the zip files. We've talked about it before
 when I was
 releasing 0.9.7 (and before that when Marc was working on 0.9.6),
 but I
 haven't had time to look into it. It should be fairly easy to make
 the
 change.


 Thoughts?

 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!



 -Michael Dick






--
Patrick Linskey
202 669 5907

Re: Caon openjpa work with Oracle View

2007-05-08 Thread Patrick Linskey


Yes and yes. IIRC, OpenJPA does not include views when
reverse-mapping, and for writes to happen correctly, of course the
views must be read-write.

-Patrick

On 5/8/07, yangdq [EMAIL PROTECTED] wrote:


Can OpenJPA work with Oracle Views directly, just like working with tables?

If yes, should we just treat the view name as a table name in the entity
annotation?
--
View this message in context: 
http://www.nabble.com/Caon-openjpa-work-with-Oracle-View-tf3710510.html#a10378604
Sent from the open-jpa-dev mailing list archive at Nabble.com.





--
Patrick Linskey
202 669 5907

Re: [VOTE] Packaging with maven

2007-05-07 Thread Patrick Linskey


directory, since I don't think Maven much cares what the name of the
directory in which the parent module resides (I doubt it even ever
looks at it). I.e., it would be located at http://svn.apache.org/


I think you're probably right -- currently, the dir is named 'trunk',
for example.


looks at it). I.e., it would be located at http://svn.apache.org/
repos/asf/openjpa/trunk/openjpa/openjpa.


Isn't that one too many 'openjpa' tokens? Couldn't it just be
http://svn.apache.org/repos/asf/openjpa/trunk/openjpa, instead of
http://svn.apache.org/repos/asf/openjpa/trunk/openjpa-all?

-Patrick

On 5/7/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:


Patrick raises a good point. Also, we might also be able to just have
the openjpa aggregate jar module be in a sub-directory named
openjpa without having to rename the parent module's enclosing
directory, since I don't think Maven much cares what the name of the
directory in which the parent module resides (I doubt it even ever
looks at it). I.e., it would be located at http://svn.apache.org/
repos/asf/openjpa/trunk/openjpa/openjpa.

How does that sound?



On May 7, 2007, at 9:15 AM, Patrick Linskey wrote:

 I think it makes sense to rename dirs as appropriate. Remember that
 once we graduate, we'll be moving repositories anyways, so it would
 seem like a good opportunity to make structural changes.

 -Patrick

 On 5/7/07, Michael Dick [EMAIL PROTECTED] wrote:
 +1

 What would the impact be if we renamed openjpa-all to openjpa?

 We could change our checkout instructions to read
 svn co http://svn.apache.org/repos/asf/incubator/openjpa/
 trunkopenjpa-parent
 and then the directories match the artifactId's in pom.xml.

 The only reason I think this is worth doing is to avoid confusion
 for new
 developers down the road. It's just one more thing that we have to
 remember
 and explain. Maybe there's an impact to changing the directory
 name that I
 missed though.

 -Mike

 On 5/6/07, Marc Prud'hommeaux [EMAIL PROTECTED]  wrote:
 
 
  Poking around the ActiveMQ pom.xml files, I notice that you can
 have
  a different artifactId than the module name (i.e., directory)
 you are
  in. I hadn't known you could do this.
 
  Currently, our artifacts name are:
 
 trunk/pom.xml: openjpa
 trunk/openjpa-all/pom.xml: openjpa-all
 trunk/openjpa-project/pom.xml: openjpa-project
 
  We could change these to:
 
 trunk/pom.xml: openjpa-parent
 trunk/openjpa-all/pom.xml: openjpa
 trunk/openjpa-project/pom.xml: apache-openjpa
 
  I've tested this out, and it results in the openjpa aggregate jar
  being named openjpa-VERSION.jar, the dependency being simply
 named
  openjpa, and the assembly is named apache-openjpa-VERSION.zip .
  None of the directories needed to be renamed. I've attached the
 patch
  that does this to https://issues.apache.org/jira/browse/OPENJPA-194
 
  Since this will mess up people who currently have maven
 dependencies
  on OpenJPA (i.e., people who depend on openjpa-all will now
 need to
  depend on openjpa), we should probably get this hammered out
 before
  leaving incubation. So I've gone ahead and turned the [DISCUSS]
 into
  a [VOTE] to see if we should go ahead and do this.
 
  A vote of +1 means we should do the renaming, -1 means we should
 not,
  and 0 means don't care. The vote will remain open until Wednesday
  May 9th at 23:59 GMT.
 
 
 
 
  On May 4, 2007, at 6:55 AM, Michael Dick wrote:
 
   Some comments below
  
   On 5/4/07, Craig L Russell [EMAIL PROTECTED]  wrote:
  
   I'd like reopen the discussion on how to package and name our
   artifacts. I think the current setup could be improved, to
 give a
   better experience for users who might not be using maven for
   dependency management. It's easy for us to change now before
   graduation because once we graduate, people will need to
 update their
   dependencies anyway so there are no backward compatibility
 issues.
  
   The name of the single jar that has all of the openjpa stuff
 in it
   except for the documentation and examples is currently called
   openjpa-
   all. This name is confusing because unless they RTFM, people
 don't
   really know that it's not all the code you need, just all the
 jpa
   code. So I'd like to call this artifact openjpa.
  
  
   +1
  
   But we already have a project with that name, and that project
 builds
   the distributions. So I'd rename the current openjpa to
 openjpa-dist.
   Its ultimate destination in the Apache mirror structure is under
   www.apache.org/dist/openjpa once we graduate, so having dist
 in the
   project name helps understanding that this project builds the
   artifacts that go into dist. Separate from the artifacts that
 are
   published via maven.
  
  
   +1
  
   Finally, the openjpa-all jar includes its subcomponents as
   dependencies. I think this is wrong, since you end up with a
 class
   path with openjpa-all.jar as well as openjpa-kernel.jar and
 all the
   others.
  
  
   I would like to change

Re: svn commit: r536001 - /incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/openjpa/enhance/PCEnhancer.java

2007-05-07 Thread Patrick Linskey


I needed it to get my IntelliJ plugin working. I probably could have
set the thread's context classloader, but it seemed like this was a
better fix.

-Patrick

On 5/7/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:


Out of curiosity, is there an existing problem that this fixes, or
did you just notice through code inspection they we weren't passing
the ClassLoader in places where it appeared we should?


On May 7, 2007, at 2:38 PM, [EMAIL PROTECTED] wrote:

 Author: pcl
 Date: Mon May  7 14:38:20 2007
 New Revision: 536001

 URL: http://svn.apache.org/viewvc?view=revrev=536001
 Log:
 Propagate the provided classloader further into the PCEnhancer call
 stack.

 Modified:
 incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
 openjpa/enhance/PCEnhancer.java






--
Patrick Linskey
202 669 5907

[jira] Commented: (OPENJPA-194) Correct suffixes of build artifacts to elimiate '-all' and '-project'

2007-05-06 Thread Patrick Linskey (JIRA)


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

Patrick Linskey commented on OPENJPA-194:
-

I think that it's more common to see things like 'openjpa-0.9.7-source.zip' 
than 'openjpa-source-0.9.7.zip', isn't it?

 Correct suffixes of build artifacts to elimiate '-all' and '-project'
 -

 Key: OPENJPA-194
 URL: https://issues.apache.org/jira/browse/OPENJPA-194
 Project: OpenJPA
  Issue Type: Sub-task
  Components: build / infrastructure
Affects Versions: 0.9.0, 0.9.6
Reporter: Marc Prud'hommeaux
 Assigned To: Marc Prud'hommeaux
Priority: Minor
 Fix For: 0.9.8

 Attachments: OpenJPA-194-1.patch.txt, OPENJPA-194.patch


 The aggregate jar that is built with OpenJPA is currently named 
 openjpa-all-0.9.7-VERSION.jar. It would be nice to change this to be just 
 openjpa-0.9.7-VERSION.jar.

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

Re: IntelliJ IDEA plugin

2007-05-05 Thread Patrick Linskey


I doubt it -- I'm doing some digging into various internal data structures.

-Patrick

On 5/5/07, Craig L Russell [EMAIL PROTECTED] wrote:

Hi Patrick,

Could you get IJ to open-source the required interfaces needed to
compile with? That would be the best option if you wanted to add it
to the OpenJPA project.

Craig

On May 4, 2007, at 4:02 PM, Patrick Linskey wrote:

 Hi,

 Earlier this week, I wrote a (very) basic OpenJPA / IntelliJ plugin.
 It automatically runs the enhancer on persistent types after
 compilation completes, for any persistence units that don't have a
 persistence provider declared or that declare OpenJPA as their
 persistence provider.

 Clearly, I'd like to make this available for IntelliJ users. Does
 anyone on this list have any experience with registering, deploying,
 and maintaining plugins via JetBrains' registry?

 Also, currently, the plugin includes the OpenJPA jars; I'd prefer if
 it depended on picking up the jars from the module's classpath, for a
 bunch of reasons. Does anyone have any experience with writing plugins
 that use classes defined in the module classpath?

 Finally, in order to build the sources, certain IntelliJ classes need
 to be in the classpath. Does anyone know of any Apache precedents for
 dealing with this type of situation?

 -Patrick

 --
 Patrick Linskey
 202 669 5907

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!






--
Patrick Linskey
202 669 5907

Re: [VOTE] Graduate from Incubation

2007-05-04 Thread Patrick Linskey


I see a discontinuity in calling the
project OpenJPA if in reality the project implements JDO and so forth.


I agree; there is a logical disconnection here.


If we can separate the engine from the API and make the API pluggable/selectable


The engine is very well-separated from the API as things stand now,
and the API is pluggable / selectable...


and the project is planning on implementing other APIs then a name change seems
reasonable as it would not be representative of what we are providing.


... however, currently, the OpenJPA project only supports JPA
bindings. I'd like to see other bindings for OpenJPA, but as things
stand right now, things happen to line up nicely.


If we are to go down this path then I would further suggest we separate the
engine and implementing APIS into separate jars/packages as it is wasteful an
potentially dangerous to package all implementations together.


This can actually be done today. The only distribution that the
OpenJPA community has published to date is a monolithic jar, but given
how the build process works today, it'd be fairly trivial to do
something else.

I don't think that we should change the name right now. We (the
OpenJPA community) have built a name around the community, and there
are currently no plans that I know of to add new APIs on top of
OpenJPA. I think that we can always change the name of the underlying
engine at a later time with minimal disruption.

If we do decide to change the name, I'd strongly suggest that we
create a TLP with some other more-flexible name, and then
simultaneously create a project within that TLP called 'OpenJPA',
which publishes a distribution that looks much like the current
incubating releases. Then, new API bindings could be started as
sub-projects within that TLP, rather than actually creating separate
projects.

-Patrick

On 5/4/07, Phill Moran [EMAIL PROTECTED] wrote:

Without getting any nastier let me explain. I see a discontinuity in calling the
project OpenJPA if in reality the project implements JDO and so forth.
If we can separate the engine from the API and make the API pluggable/selectable
and the project is planning on implementing other APIs then a name change seems
reasonable as it would not be representative of what we are providing.
If we are to go down this path then I would further suggest we separate the
engine and implementing APIS into separate jars/packages as it is wasteful an
potentially dangerous to package all implementations together.

That is all this little piece of the community has to say.

Phill

-Original Message-
From: Dain Sundstrom [mailto:[EMAIL PROTECTED]
Sent: May 4, 2007 2:50 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: [VOTE] Graduate from Incubation

On May 4, 2007, at 10:50 AM, Phill Moran wrote:

 Would we then not have to change the overall name from JPA to
 openPersistence or some such?

That would suck.  I see no reason we would have to change the name.  It is a
choice of the community.

 Why not let another project lift out the engine and adapt JDO/SDO/ETC
 and maybe we remerge the projects later.

I would hate to see a fork.

 Maybe this idea works if we can fully separate the API from the
 persistence engine as it does not make sense to go into production
 with several unused API being deployed.

It is already separated.

-dain





--
Patrick Linskey
202 669 5907

Re: [VOTE] Graduate from Incubation

2007-05-04 Thread Patrick Linskey


While we're on the topic, do you have any compelling new name ideas?
Clearly, if we had a new name handy, it could be advantageous to
create that TLP and then an OpenJPA subproject from the start. I don't
think that we should hold up the graduation for this, but it does seem
like the thing that's easier to do all at once.

-Patrick

On 5/4/07, Phill Moran [EMAIL PROTECTED] wrote:

I agree with you on the name change and the timing around it. My comments are
mainly directed towards holding a non-representative name if other APIs are
implemented.

A decision that can be made later along with any necessary re-packaging needs

Sincerely,
Phill

-Original Message-
From: Patrick Linskey [mailto:[EMAIL PROTECTED]
Sent: May 4, 2007 3:35 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: [VOTE] Graduate from Incubation

 I see a discontinuity in calling the
 project OpenJPA if in reality the project implements JDO and so forth.

I agree; there is a logical disconnection here.

 If we can separate the engine from the API and make the API
 pluggable/selectable

The engine is very well-separated from the API as things stand now, and the API
is pluggable / selectable...

 and the project is planning on implementing other APIs then a name
 change seems reasonable as it would not be representative of what we are
providing.

... however, currently, the OpenJPA project only supports JPA bindings. I'd like
to see other bindings for OpenJPA, but as things stand right now, things happen
to line up nicely.

 If we are to go down this path then I would further suggest we
 separate the engine and implementing APIS into separate jars/packages
 as it is wasteful an potentially dangerous to package all implementations
together.

This can actually be done today. The only distribution that the OpenJPA
community has published to date is a monolithic jar, but given how the build
process works today, it'd be fairly trivial to do something else.

I don't think that we should change the name right now. We (the OpenJPA
community) have built a name around the community, and there are currently no
plans that I know of to add new APIs on top of OpenJPA. I think that we can
always change the name of the underlying engine at a later time with minimal
disruption.

If we do decide to change the name, I'd strongly suggest that we create a TLP
with some other more-flexible name, and then simultaneously create a project
within that TLP called 'OpenJPA', which publishes a distribution that looks much
like the current incubating releases. Then, new API bindings could be started as
sub-projects within that TLP, rather than actually creating separate projects.

-Patrick

On 5/4/07, Phill Moran [EMAIL PROTECTED] wrote:
 Without getting any nastier let me explain. I see a discontinuity in
 calling the project OpenJPA if in reality the project implements JDO and so
forth.
 If we can separate the engine from the API and make the API
 pluggable/selectable and the project is planning on implementing other
 APIs then a name change seems reasonable as it would not be representative of
what we are providing.
 If we are to go down this path then I would further suggest we
 separate the engine and implementing APIS into separate jars/packages
 as it is wasteful an potentially dangerous to package all implementations
together.

 That is all this little piece of the community has to say.

 Phill

 -Original Message-
 From: Dain Sundstrom [mailto:[EMAIL PROTECTED]
 Sent: May 4, 2007 2:50 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: [VOTE] Graduate from Incubation

 On May 4, 2007, at 10:50 AM, Phill Moran wrote:

  Would we then not have to change the overall name from JPA to
  openPersistence or some such?

 That would suck.  I see no reason we would have to change the name.
 It is a choice of the community.

  Why not let another project lift out the engine and adapt
  JDO/SDO/ETC and maybe we remerge the projects later.

 I would hate to see a fork.

  Maybe this idea works if we can fully separate the API from the
  persistence engine as it does not make sense to go into production
  with several unused API being deployed.

 It is already separated.

 -dain




--
Patrick Linskey
202 669 5907





--
Patrick Linskey
202 669 5907

[jira] Assigned: (OPENJPA-235) SQL reordering to avoid non-nullable foreign key constraint violations

2007-05-04 Thread Patrick Linskey (JIRA)

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

Patrick Linskey reassigned OPENJPA-235:
---

Assignee: Patrick Linskey

SQL reordering to avoid non-nullable foreign key constraint violations
--

Key: OPENJPA-235
URL: https://issues.apache.org/jira/browse/OPENJPA-235
Project: OpenJPA
Issue Type: Improvement
Components: kernel
Reporter: Reece Garrett
Assigned To: Patrick Linskey
Fix For: 0.9.8

Attachments: sqlreorder.patch

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

[jira] Resolved: (OPENJPA-235) SQL reordering to avoid non-nullable foreign key constraint violations

2007-05-04 Thread Patrick Linskey (JIRA)

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

Patrick Linskey resolved OPENJPA-235.
-

Resolution: Fixed

SQL reordering to avoid non-nullable foreign key constraint violations
--

Key: OPENJPA-235
URL: https://issues.apache.org/jira/browse/OPENJPA-235
Project: OpenJPA
Issue Type: Improvement
Components: kernel
Reporter: Reece Garrett
Assigned To: Patrick Linskey
Fix For: 0.9.8

Attachments: sqlreorder.patch

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

IntelliJ IDEA plugin

2007-05-04 Thread Patrick Linskey


Hi,

Earlier this week, I wrote a (very) basic OpenJPA / IntelliJ plugin.
It automatically runs the enhancer on persistent types after
compilation completes, for any persistence units that don't have a
persistence provider declared or that declare OpenJPA as their
persistence provider.

Clearly, I'd like to make this available for IntelliJ users. Does
anyone on this list have any experience with registering, deploying,
and maintaining plugins via JetBrains' registry?

Also, currently, the plugin includes the OpenJPA jars; I'd prefer if
it depended on picking up the jars from the module's classpath, for a
bunch of reasons. Does anyone have any experience with writing plugins
that use classes defined in the module classpath?

Finally, in order to build the sources, certain IntelliJ classes need
to be in the classpath. Does anyone know of any Apache precedents for
dealing with this type of situation?

-Patrick

--
Patrick Linskey
202 669 5907

Re: [VOTE] Graduate from Incubation

2007-05-03 Thread Patrick Linskey


+1. Thanks for working with the board to get this put together.

-Patrick

On 5/3/07, Craig L Russell [EMAIL PROTECTED] wrote:

This vote is to send the attached draft board resolution to the
incubator for the purpose of graduation from the incubator to the
Apache OpenJPA project.

+1 We're ready; let's graduate

0 Don't care

-1 Let's wait

Establish the Apache OpenJPA project

WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the
Foundation's purpose to establish a Project, to be known as
Apache OpenJPA, related to the implementation of
object persistence, including, but not limited to,
Java Persistence API, for distribution at no charge to the
public;

NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), be and hereby is established pursuant to Bylaws
of the Foundation; and be it further

RESOLVED, that the OpenJPA PMC be and hereby is charged with
the creation and maintenance of Apache OpenJPA;
and be it further

RESOLVED, that the office of Vice President, Apache OpenJPA
be and
hereby is created, the person holding such office to serve at
the direction of the Board of Directors as the chair of the
OpenJPA PMC, and to have primary responsibility for
management of
the projects within the scope of responsibility of the Apache
OpenJPA
PMC; and be it further

RESOLVED, that the persons listed immediately below be and
hereby are appointed to serve as the initial members of the
OpenJPA PMC:

Eddie O'Neil[EMAIL PROTECTED]
Geir Magnusson Jr.  [EMAIL PROTECTED]
Brian McCallister   [EMAIL PROTECTED]
Patrick Linskey [EMAIL PROTECTED]
Craig Russell   [EMAIL PROTECTED]
Kevin Sutter[EMAIL PROTECTED]
Abe White   [EMAIL PROTECTED]
Marc Prud'hommeaux  [EMAIL PROTECTED]

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Craig Russell
be appointed to the office of Vice President, Apache OpenJPA,
to serve
in accordance with and subject to the direction of the Board of
Directors and the Bylaws of the Foundation until death,
resignation, retirement, removal or disqualification, or until
a successor is appointed; and be it further

RESOLVED, that the initial OpenJPA PMC be and hereby is tasked
with the migration and rationalization of the Apache Incubator
OpenJPA podling; and be it further

RESOLVED, that all responsibility pertaining to the Apache
Incubator OpenJPA podling and encumbered upon the Apache
Incubator
PMC are hereafter discharged.

Craig Russell
DB PMC, OpenJPA PPMC
[EMAIL PROTECTED] http://db.apache.org/jdo







--
Patrick Linskey
202 669 5907

Re: java.util.MissingResourceException: org.apache.openjpa.persistence.PersistenceProductDerivation:java.io.IOException

2007-05-02 Thread Patrick Linskey


Could you run ant with the '-e' option to get full stack traces?

Also, my guess would be that you've got some sort of security policy
prohibiting OpenJPA from reading resources.

-Patrick

On 5/1/07, Philippe Alexis [EMAIL PROTECTED] wrote:

 Hello Everyone,

 Here's what I'm getting when I follow the 5min quick start guide strictly,
 under both Eclipse 3.1.1 and 3.2,
 and under Ant on Cygwin, using jdk1.5.0_11-b03:

 
=

 Buildfile: D:\Programming\Java\openjpa-
 project-0.9.7-incubating\examples\hellojpa\build.xml
 compile:
 run:
  [java] java.lang.reflect.InvocationTargetException
  [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  [java] at sun.reflect.NativeMethodAccessorImpl.invoke(
 NativeMethodAccessorImpl.java:39)
  [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(
 DelegatingMethodAccessorImpl.java:25)
  [java] at java.lang.reflect.Method.invoke(Method.java:585)
  [java] at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(
 InstrumentationImpl.java:141)
  [java] Caused by: java.util.MissingResourceException:
 
org.apache.openjpa.persistence.PersistenceProductDerivation:java.io.IOException:
 org.xml.sax.SAXNotRecognizedException: Property:
 http://java.sun.com/xml/jaxp/properties/schemaLanguage
  [java] at org.apache.openjpa.lib.conf.ProductDerivations.reportErrors
 (ProductDerivations.java:326)
  [java] at org.apache.openjpa.lib.conf.ProductDerivations.load(
 ProductDerivations.java:316)
  [java] at org.apache.openjpa.lib.conf.ProductDerivations.loadDefaults
 (ProductDerivations.java:283)
  [java] at
 org.apache.openjpa.lib.conf.Configurations.populateConfiguration(
 Configurations.java:298)
  [java] FATAL ERROR in native method: processing of -javaagent failed
  [java] at org.apache.openjpa.enhance.PCEnhancerAgent.premain(
 PCEnhancerAgent.java:49)
  [java] ... 5 more
  [java] Exception in thread main

 BUILD FAILED
 D:\Programming\Java\openjpa-
 project-0.9.7-incubating\examples\build.xml:67: Java returned: 1

 Total time: 1 second

 
=


I'm not sure what I'm doing wrong. I'm still stuck in the starting block
here. It's probably related to some missing
XML file, I'd guess.. but the default download is self-contained with
everything required for the quickie included, isn't it?

J-Philippe.




--
Patrick Linskey
202 669 5907

Re: svn commit: r534623 - /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/SelectImpl.java

2007-05-02 Thread Patrick Linskey


A question:


+// bitSet indicating if an alias is removed from parent select
+// bit 0 : correspond to alias 0
+// bit 1 : correspond to alias 1, etc.
+// if the bit is set, the corresponding alias has been removed from parent
+// and recorded under subselect.
+private int _removedAliasFromParent = 0;


Why not use a BitSet? They're not that much more inefficient (esp
considering that these are pathways that only occur when going to the
database), and they don't have an upper bound of 32 like you'll see
with an int.

Also, where's the test case for this change?

-Patrick

On 5/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

Author: wisneskid
Date: Wed May  2 14:35:55 2007
New Revision: 534623

URL: http://svn.apache.org/viewvc?view=revrev=534623
Log:
Fix for issue OPENJPA-51. It should also resolve issue OPENJPA-173.

Modified:

incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/SelectImpl.java

Modified: 
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/SelectImpl.java
URL: 
http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/SelectImpl.java?view=diffrev=534623r1=534622r2=534623
==
--- 
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/SelectImpl.java
 (original)
+++ 
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/SelectImpl.java
 Wed May  2 14:35:55 2007
@@ -158,6 +158,13 @@
 // from select if this select selects from a tmp table created by another
 private SelectImpl _from = null;
 private SelectImpl _outer = null;
+
+// bitSet indicating if an alias is removed from parent select
+// bit 0 : correspond to alias 0
+// bit 1 : correspond to alias 1, etc.
+// if the bit is set, the corresponding alias has been removed from parent
+// and recorded under subselect.
+private int _removedAliasFromParent = 0;

 /**
  * Helper method to return the proper table alias for the given alias 
index.
@@ -1487,8 +1494,13 @@
 private void removeParentJoins(PathJoins pj) {
 if (_parent == null)
 return;
-if (_parent._joins != null  !_parent._joins.isEmpty())
-pj.joins().removeAll(_parent._joins.joins());
+if (_parent._joins != null  !_parent._joins.isEmpty()) {
+boolean removed = false;
+if (_removedAliasFromParent  0)
+removed = _parent._joins.joins().removeAll(pj.joins());
+if (!removed)
+pj.joins().removeAll(_parent._joins.joins());
+}
 if (!pj.isEmpty())
 _parent.removeParentJoins(pj);
 }
@@ -1897,9 +1909,15 @@
 }
 }
 if (!fromParent  _parent != null) {
-alias = _parent.findAlias(table, key, false, this);
-if (alias != null)
+boolean removeAliasFromParent = key.toString().contains(:);
+alias = _parent.findAlias(table, key, removeAliasFromParent, this);
+if (alias != null) {
+if (removeAliasFromParent) {
+recordTableAlias(table, key, alias);
+_removedAliasFromParent |= (1  alias.intValue());
+}
 return alias;
+}
 }
 if (_subsels != null) {
 SelectImpl sub;
@@ -1913,9 +1931,11 @@
 if (sub._tables != null)
 sub._tables.remove(alias);
 } else {
-alias = sub.findAlias(table, key, true, null);
-if (!fromParent  alias != null)
-recordTableAlias(table, key, alias);
+if (fromSub == null) {
+alias = sub.findAlias(table, key, true, null);
+if (!fromParent  alias != null)
+recordTableAlias(table, key, alias);
+}
 }
 }
 }






--
Patrick Linskey
202 669 5907

Re: java.lang.ClassNotFoundException

2007-05-01 Thread Patrick Linskey


Hi,


 [java] FATAL ERROR in native method: processing of -javaagent failed
 [java] at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(
InstrumentationImpl.java:165)
 [java] Exception in thread main


It looks like the root cause of the error is being consumed by ant. Do
you get more exceptions by running 'ant -e' instead of just 'ant'? The
'-e' option will tell ant to log errors more verbosely.

Also, it looks like an error is happening while running the OpenJPA
pre-processor on your classes. What happens if you run the
pre-processor before running your java command, rather than via the
-javaagent flag? To do this, run 'java
org.apache.openjpa.enhance.PCEnhancer' with your
META-INF/persistence.xml in the classpath, or specifying the file on
the command line with the '-properties' flag.

-Patrick

On 4/30/07, Philippe Alexis [EMAIL PROTECTED] wrote:

Hello Everyone,

Here's what I'm getting when I follow the 5min quick start guide strictly,
under both Eclipse 3.1.1 and 3.2,
and under Ant on Cygwin:

=
Buildfile: D:\Programming\Java\openjpa-
project-0.9.7-incubating\examples\hellojpa\build.xml
compile:
run:
 [java] java.lang.ClassNotFoundException: D:\Programming\Java\openjpa-
project-0.9.7-incubating\openjpa-0.9.7-incubating.jar
 [java] at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
 [java] at java.security.AccessController.doPrivileged(Native Method)
 [java] at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
 [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:290)
 [java] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:279)
 [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:236)
 [java] FATAL ERROR in native method: processing of -javaagent failed
 [java] at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(
InstrumentationImpl.java:165)
 [java] Exception in thread main

BUILD FAILED
D:\Programming\Java\openjpa-project-0.9.7-incubating\examples\build.xml:67:Java
returned: 1

Total time: 1 second
=


I'm not sure what I'm doing wrong. I'm stuck in the starting block here. How
do you guys do it?

J-Philippe.




--
Patrick Linskey
202 669 5907

RE: IRC

2007-04-30 Thread Patrick Linskey

Hi,

I am on the channel from time to time, but not regularly.

-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 30, 2007 7:04 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: IRC
 
 Does anyone actually monitor the IRC chat? I have logged on 
 the last few business days and received no responses. Should 
 I stick to emails as the preferred communications method?
 
 Phill
 
 

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: How to debug object retrieveal in JPA?

2007-04-30 Thread Patrick Linskey

It looks like this exception is different than the others; it looks like
this exception is actually being thrown, rather than being put into your
result list. Is that correct?

Is this something that you could package up as a test case? Also, I seem
to remember some sort of issue with overly-eager result list closing in
non-transactional environments in 0.9.6, but I can't find a related JIRA
issue. It's possible that moving up to 0.9.7 (released Friday;
http://cwiki.apache.org/openjpa/downloads.html) might get around the
problem.

-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 30, 2007 7:28 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: RE: How to debug object retrieveal in JPA?
 
 Anyone have any more suggestions on how to debug this? 
 
 -Original Message-
 From: Phill Moran [mailto:[EMAIL PROTECTED]
 Sent: April 26, 2007 11:20 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: RE: How to debug object retrieveal in JPA?
 
 I don't close it in anyway directly 
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 Sent: April 26, 2007 11:16 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: How to debug object retrieveal in JPA?
 
 Can it be that there is a glue code that closes EM in 
 between? Just a thought...
 
 -marina
 
 Phill Moran wrote:
  I had suspected the Locale so I made a set/getLocale that 
 communicate 
  in
 String.
  I figured that openJPA does not actually care how I implement.
  
  But for this run I removed it completely and did a clean 
 rebuild. Good 
  news and bad the exception changed:
  
  
  java.util.NoSuchElementException: The result list has been closed.
  at
  
 org.apache.openjpa.lib.rop.AbstractResultList.assertOpen(AbstractResul
  tList.java
  :91)
  at
  
 org.apache.openjpa.lib.rop.AbstractNonSequentialResultList.get(Abstrac
  tNonSequen
  tialResultList.java:68)
  at
  
 org.apache.openjpa.kernel.DelegatingResultList.get(DelegatingResultLis
  t.java:241
  )
  at
  
 ca.BidSpec.emall.user.PersonFactoryImpl.getLoginPersonValueObject(Pers
  onFactoryI
  mpl.java:99)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at
  
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
 orImpl.java:39)
  at
  
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
  orImpl.jav
  a:25)
  at java.lang.reflect.Method.invoke(Method.java:597)
  at
  
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflectio
  n(AopUtils
  .java:304)
  at
  
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoi
  npoint(Ref
  lectiveMethodInvocation.java:172)
  at
  
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(R
  eflectiveM
  ethodInvocation.java:139)
  at
  
 org.springframework.transaction.interceptor.TransactionInterceptor.inv
  oke(Transa
  ctionInterceptor.java:107)
  at
  
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(R
  eflectiveM
  ethodInvocation.java:161)
  at
  
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamic
  AopProxy.j
  ava:203)
  at $Proxy34.getLoginPersonValueObject(Unknown Source)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at
  
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
 orImpl.java:39)
  at
  
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
  orImpl.jav
  a:25)
  at java.lang.reflect.Method.invoke(Method.java:597)
  at
  
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflectio
  n(AopUtils
  .java:304)
  at
  
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoi
  npoint(Ref
  lectiveMethodInvocation.java:172)
  at
  
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(R
  eflectiveM
  ethodInvocation.java:139)
  at
  
 org.springframework.transaction.interceptor.TransactionInterceptor.inv
  oke(Transa
  ctionInterceptor.java:107)
  at
  
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(R
  eflectiveM
  ethodInvocation.java:161)
  at
  
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamic
  AopProxy.j
  ava:203)
  at $Proxy34.getLoginPersonValueObject(Unknown Source

RE: Deployment on JBoss

2007-04-30 Thread Patrick Linskey

What happens if you toss
'providerorg.apache.openjpa.persistence.PersistenceProviderImpl/provi
der' into your persistence.xml file?

-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: Matthieu Riou [mailto:[EMAIL PROTECTED] 
 Sent: Monday, April 30, 2007 9:05 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: Deployment on JBoss
 
 Hi guys,
 
 One of our users in ODE is trying to deploy on JBoss. There 
 seems to be some configuration problems, most probably 
 related to the presence of Hibernate in the server. He's 
 having the following stacktrace (I trimmed the non relevant bits):
 
 13:15:29,343 INFO  [STDOUT] ERROR - ODEServer.initDAO(413) | 
 Error instantiating  DAO Connection Factory class 
 org.apache.ode.dao.jpa.BPELDAO ConnectionFactoryImp l.
 javax.persistence.PersistenceException: Provider error. Provider:
 org.hibernate.
 ejb.HibernatePersistence
at 
 javax.persistence.Persistence.createFactory(Persistence.java:175)
at javax.persistence.Persistence.createEntityManagerFactory
 (Persistence.
 java:111)
at org.apache.ode.dao.jpa.BPELDAOConnectionFactoryImpl.init
 (BPELDAOConne
 ctionFactoryImpl.java:108)
at 
 org.apache.ode.il.dbutil.Database.createDaoCF(Database.java:267)
at org.apache.ode.axis2.ODEServer.initDAO(ODEServer.java:410)
at org.apache.ode.axis2.ODEServer.init(ODEServer.java:144)

 13:15:31,078 INFO  [STDOUT] ERROR - 
 StandardContext.loadOnStartup(4073) | Servle t /ode threw 
 load() exception
 java.lang.ClassCastException: org.hibernate.ejb.HibernatePersistence
at 
 javax.persistence.Persistence.createFactory(Persistence.java:169)
at javax.persistence.Persistence.createEntityManagerFactory
 (Persistence.
 java:111)
at org.apache.ode.dao.jpa.BPELDAOConnectionFactoryImpl.init
 (BPELDAOConne
 ctionFactoryImpl.java:108)
at 
 org.apache.ode.il.dbutil.Database.createDaoCF(Database.java:267)
at org.apache.ode.axis2.ODEServer.initDAO(ODEServer.java:410)
at org.apache.ode.axis2.ODEServer.init(ODEServer.java:144)
 
 As you can see there's a ClassCastException in 
 javax.persistence.Persistence.createFactory which is a bit 
 weird. Note that we instantiate the factory using a specific name:
 
 _emf = Persistence.createEntityManagerFactory(ode-dao, propMap);
 
 And that our persistence.xml *only* references the OpenJPA 
 persistence factory. I've looked at the sources of 
 Persistence.java in Glassfish but couldn't find the right 
 version that seems to be used here (the createFactory method 
 doesn't seem to exist anymore).
 
 I'm running out of ideas and thought the knowledgeable people 
 would probably know more about the JBoss environment. Any idea?
 
 Thanks!
 Matthieu
 

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: Deployment on JBoss

2007-04-30 Thread Patrick Linskey

 As you can see there's a ClassCastException in 
 javax.persistence.Persistence.createFactory which is a bit 
 weird. Note that we instantiate the factory using a specific name:

Aah, you had more content in your email. Of course.

 And that our persistence.xml *only* references the OpenJPA 
 persistence factory. I've looked at the sources of 

Sounds like you've already got the OpenJPA persistence provider listed.

 persistence factory. I've looked at the sources of 
 Persistence.java in Glassfish but couldn't find the right 
 version that seems to be used here (the createFactory method 
 doesn't seem to exist anymore).

What do you mean -- in what sense does that method not exist anymore?

 I'm running out of ideas and thought the knowledgeable people 
 would probably know more about the JBoss environment. Any idea?

IIRC, the JBoss folks were talking about using a Persistence class other
than the one from the RI, so they may have other behavior in their impl.
Certainly, if this is the case, it doesn't sound like their impl is
compliant with the spec, although I don't know what the status of the
CTS is wrt. loading other JPA impls. Also, I don't know what JBoss's
Java EE 5 status is.

-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: Matthieu Riou [mailto:[EMAIL PROTECTED] 
 Sent: Monday, April 30, 2007 9:05 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: Deployment on JBoss
 
 Hi guys,
 
 One of our users in ODE is trying to deploy on JBoss. There 
 seems to be some configuration problems, most probably 
 related to the presence of Hibernate in the server. He's 
 having the following stacktrace (I trimmed the non relevant bits):
 
 13:15:29,343 INFO  [STDOUT] ERROR - ODEServer.initDAO(413) | 
 Error instantiating  DAO Connection Factory class 
 org.apache.ode.dao.jpa.BPELDAO ConnectionFactoryImp l.
 javax.persistence.PersistenceException: Provider error. Provider:
 org.hibernate.
 ejb.HibernatePersistence
at 
 javax.persistence.Persistence.createFactory(Persistence.java:175)
at javax.persistence.Persistence.createEntityManagerFactory
 (Persistence.
 java:111)
at org.apache.ode.dao.jpa.BPELDAOConnectionFactoryImpl.init
 (BPELDAOConne
 ctionFactoryImpl.java:108)
at 
 org.apache.ode.il.dbutil.Database.createDaoCF(Database.java:267)
at org.apache.ode.axis2.ODEServer.initDAO(ODEServer.java:410)
at org.apache.ode.axis2.ODEServer.init(ODEServer.java:144)

 13:15:31,078 INFO  [STDOUT] ERROR - 
 StandardContext.loadOnStartup(4073) | Servle t /ode threw 
 load() exception
 java.lang.ClassCastException: org.hibernate.ejb.HibernatePersistence
at 
 javax.persistence.Persistence.createFactory(Persistence.java:169)
at javax.persistence.Persistence.createEntityManagerFactory
 (Persistence.
 java:111)
at org.apache.ode.dao.jpa.BPELDAOConnectionFactoryImpl.init
 (BPELDAOConne
 ctionFactoryImpl.java:108)
at 
 org.apache.ode.il.dbutil.Database.createDaoCF(Database.java:267)
at org.apache.ode.axis2.ODEServer.initDAO(ODEServer.java:410)
at org.apache.ode.axis2.ODEServer.init(ODEServer.java:144)
 
 As you can see there's a ClassCastException in 
 javax.persistence.Persistence.createFactory which is a bit 
 weird. Note that we instantiate the factory using a specific name:
 
 _emf = Persistence.createEntityManagerFactory(ode-dao, propMap);
 
 And that our persistence.xml *only* references the OpenJPA 
 persistence factory. I've looked at the sources of 
 Persistence.java in Glassfish but couldn't find the right 
 version that seems to be used here (the createFactory method 
 doesn't seem to exist anymore).
 
 I'm running out of ideas and thought the knowledgeable people 
 would probably know more about the JBoss environment. Any idea?
 
 Thanks!
 Matthieu
 

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: Deployment on JBoss

2007-04-30 Thread Patrick Linskey

I was suggesting to put it into the xml file, not to remove it. At the
time, I had only read the very beginning of your email. It's early still
in my time zone.

-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: Matthieu Riou [mailto:[EMAIL PROTECTED] 
 Sent: Monday, April 30, 2007 9:15 AM
 To: Patrick Linskey
 Cc: open-jpa-dev@incubator.apache.org
 Subject: Re: Deployment on JBoss
 
 It's hard for me to test as this is reported by one of our 
 users but I can ask him to try that. But wouldn't that result 
 in selecting the Hibernate implementation instead OpenJPA 
 (which we don't want)?
 
 Thanks,
 Matthieu
 
 
 On 4/30/07, Patrick Linskey [EMAIL PROTECTED] wrote:
 
   What happens if you toss
   
 'providerorg.apache.openjpa.persistence.PersistenceProviderI
 mpl/provi
   der' into your persistence.xml file?
   
   -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: Matthieu Riou [mailto: [EMAIL PROTECTED] 
 mailto:[EMAIL PROTECTED] ]
Sent: Monday, April 30, 2007 9:05 AM
To: open-jpa-dev@incubator.apache.org
Subject: Deployment on JBoss
   
Hi guys,
   
One of our users in ODE is trying to deploy on JBoss. There
seems to be some configuration problems, most probably
related to the presence of Hibernate in the server. He's 
having the following stacktrace (I trimmed the non 
 relevant bits):
   
13:15:29,343 INFO  [STDOUT] ERROR - ODEServer.initDAO(413) |
Error instantiating  DAO Connection Factory class
org.apache.ode.dao.jpa.BPELDAO ConnectionFactoryImp l.
javax.persistence.PersistenceException: Provider 
 error. Provider:
org.hibernate.
ejb.HibernatePersistence
   at
javax.persistence.Persistence.createFactory 
 (Persistence.java:175)
   at 
 javax.persistence.Persistence.createEntityManagerFactory
(Persistence.
java:111)
   at 
 org.apache.ode.dao.jpa.BPELDAOConnectionFactoryImpl.init
(BPELDAOConne 
ctionFactoryImpl.java:108)
   at

 org.apache.ode.il.dbutil.Database.createDaoCF(Database.java:267)
   at 
 org.apache.ode.axis2.ODEServer.initDAO(ODEServer.java:410)
   at 
 org.apache.ode.axis2.ODEServer.init(ODEServer.java:144)
   
13:15:31,078 INFO  [STDOUT] ERROR -
StandardContext.loadOnStartup(4073) | Servle t /ode threw
load() exception
java.lang.ClassCastException : 
 org.hibernate.ejb.HibernatePersistence
   at

 javax.persistence.Persistence.createFactory(Persistence.java:169)
   at 
 javax.persistence.Persistence.createEntityManagerFactory
(Persistence. 
java:111)
   at 
 org.apache.ode.dao.jpa.BPELDAOConnectionFactoryImpl.init
(BPELDAOConne
ctionFactoryImpl.java:108)
   at
org.apache.ode.il.dbutil.Database.createDaoCF 
 (Database.java:267)
   at 
 org.apache.ode.axis2.ODEServer.initDAO(ODEServer.java:410)
   at 
 org.apache.ode.axis2.ODEServer.init(ODEServer.java:144)
   
As you can see there's a ClassCastException in 
javax.persistence.Persistence.createFactory which is a bit
weird. Note that we instantiate the factory using a 
 specific name:
   
_emf = 
 Persistence.createEntityManagerFactory(ode-dao, propMap); 
   
And that our persistence.xml *only* references the OpenJPA
persistence factory. I've looked at the sources of
Persistence.java in Glassfish but couldn't find the right
version that seems to be used here (the createFactory method 
doesn't

RE: How to debug object retrieveal in JPA?

2007-04-30 Thread Patrick Linskey

Odd indeed. Can you post your named query definition?

-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 30, 2007 10:55 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: RE: How to debug object retrieveal in JPA?
 
 Hard to pull this little piece (of a much larger one) and 
 package it. Let me tool around some more and see if I can 
 uncover more. What is odd is not all my JPA classes have this 
 problem but all inherit from the same base and are fairly 
 similar. I will try commenting out parts of it and see if it 
 clears. IF not I will have to package and send along
 
 Phill
 
 -Original Message-
 From: Patrick Linskey [mailto:[EMAIL PROTECTED]
 Sent: April 30, 2007 1:45 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: RE: How to debug object retrieveal in JPA?
 
 Odd. Any chance of packaging it up and attaching it to a JIRA issue?
 
 -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 30, 2007 10:37 AM
  To: open-jpa-dev@incubator.apache.org
  Subject: RE: How to debug object retrieveal in JPA?
  
  I upgraded and result stayed the same. Also this is in a spring 
  transaction. In fact these are all part of JUnit tests.
  
  -Original Message-
  From: Patrick Linskey [mailto:[EMAIL PROTECTED]
  Sent: April 30, 2007 12:05 PM
  To: open-jpa-dev@incubator.apache.org
  Subject: RE: How to debug object retrieveal in JPA?
  
  It looks like this exception is different than the others; it looks 
  like this exception is actually being thrown, rather than being put 
  into your result list.
  Is that correct?
  
  Is this something that you could package up as a test case? 
  Also, I seem to remember some sort of issue with 
 overly-eager result 
  list closing in non-transactional environments in 0.9.6, 
 but I can't 
  find a related JIRA issue.
  It's possible that moving up to 0.9.7 (released Friday;
  http://cwiki.apache.org/openjpa/downloads.html) might get 
 around the 
  problem.
  
  -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 30, 2007 7:28 AM
   To: open-jpa-dev@incubator.apache.org
   Subject: RE: How to debug object retrieveal in JPA?
   
   Anyone have any more suggestions on how to debug this? 
   
   -Original Message-
   From: Phill Moran [mailto:[EMAIL PROTECTED]
   Sent: April 26, 2007 11:20 PM
   To: open-jpa-dev@incubator.apache.org
   Subject: RE: How to debug object retrieveal in JPA?
   
   I don't close it in anyway directly
   
   -Original Message-
   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
   Sent: April 26, 2007 11:16 PM
   To: open-jpa-dev@incubator.apache.org
   Subject: Re: How to debug object retrieveal in JPA?
   
   Can it be that there is a glue code that closes EM in
  between? Just a
   thought...
   
   -marina
   
   Phill Moran wrote:
I had suspected the Locale so I made a set/getLocale that
   communicate
in
   String.
I figured that openJPA does not actually care how I implement.

But for this run I removed it completely and did a clean
   rebuild. Good
news and bad the exception

RE: How to debug object retrieveal in JPA?

2007-04-30 Thread Patrick Linskey

Can you post the current full exception + any nested exceptions and
their nested exceptions and their nested exceptions and so on? I think
that that data is already in this thread, but I just want to confirm
that things are still the same as they were.

-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 30, 2007 11:13 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: RE: How to debug object retrieveal in JPA?
 
 Sure here it is and the sql it generates. BTW the SQL works 
 as I can execute it in MySQL query browser and get the record 
 back I am after. Does it matter that I am after a single 
 record? I don't specify the single records expected response 
 (since it could be larger but currently in test it is only 1)
 
 @NamedQuery(name = PersonFXStoreAndLogin, query = SELECT p 
 FROM Person p WHERE UPPER(p.store.name) = :storeName and 
 UPPER(p.loginName) = :loginName ORDER BY p.lastName, p.firstName) })
 
 SQL:
 37391  BidSpecPersistenceUnit  TRACE  [main] openjpa.jdbc.SQL 
 - t 2860004, conn
 24859001 executing prepstmnt 31775072 SELECT t0.id, t0.version, 
 24859001 t0.lastUpdated,
 t0.active, t0.activeFrom, t0.activeUntil, t0.created, 
 t0.displayName, t0.firstName, t0.lastLogin, t0.lastName, 
 t0.locale, t0.loginName, t0.middleName, t2.id, t2.version, 
 t2.lastUpdated, t2.description, t3.id, t3.version, 
 t3.lastUpdated, t3.description, t2.value, t4.id, t4.version, 
 t4.lastUpdated, t4.description, t4.categoryTypeFK, t4.value, 
 t1.id, t1.version, t1.lastUpdated, t1.created, 
 t1.description, t1.displayName, t1.name, t5.id, t5.version, 
 t5.lastUpdated, t5.description, t5.categoryTypeFK, t5.value, 
 t0.title, t0.visible FROM person t0 INNER JOIN manufacturer 
 t1 ON t0.manufacturerFK = t1.id LEFT OUTER JOIN category t2 
 ON t0.roleFK = t2.id LEFT OUTER JOIN category
 t4 ON t0.salutationFK = t4.id LEFT OUTER JOIN category t5 ON 
 t1.typeFK = t5.id LEFT OUTER JOIN categorytype t3 ON 
 t2.categoryTypeFK = t3.id WHERE
 (UPPER(t1.name) = ? AND UPPER(t0.loginName) = ?) ORDER BY 
 t0.lastName ASC, t0.firstName ASC [params=(String) BIDSPEC, 
 (String) PMORAN]
  
 The initial excpetion is :
 Error Exception occurred: com.sun.jdi.InvocationException 
 occurred invoking
 method..  
 
 Here is the method that causes the problem
   public Person getLoginPersonValueObject(String storeName, String
 loginName)
   throws PersonValueObjectNotFoundException,
 UserNotActiveException,
   UserNotFoundException {
   Query q =
 this.getEntityManager().createNamedQuery(PersonFXStoreAndLogin);
   q.setParameter(storeName, storeName.toUpperCase());
   q.setParameter(loginName, loginName.toUpperCase());
   ListPerson results = null;
   try {
   results = (ListPerson) q.getResultList();
   System.out.println(results.get(0));
   }
   catch(Exception e) {
   e.printStackTrace();
   }
   if (results.isEmpty()) {
   throw new UserNotFoundException(No 
 user found);
   }
   if (results.size()  1) {
   throw new PersonValueObjectNotFoundException(
   returned multiple 
 login name for same store. StoreName= + storeName
   + , 
 loginName= +
 loginName);
   }
   Person person = results.iterator().next();
   if (!person.isActive()) {
   throw new UserNotActiveException();
   }
   return person;
   }
 
 -Original Message-
 From: Patrick Linskey [mailto:[EMAIL PROTECTED]
 Sent: April 30, 2007 2:01 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: RE: How to debug object retrieveal in JPA?
 
 Odd indeed. Can you post your named query definition?
 
 -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

OpenJPA is an Implementation of the Java(TM) Persistence API

2007-04-30 Thread Patrick Linskey

Hi,

I'm happy to announce that OpenJPA 0.9.7 passes the JPA TCK! I'd like to
thank Marc Prud'hommeaux in particular, who made this happen in all
aspects: he worked with Sun to get access to the TCK, set up the
infrastructure to be able to run the TCK in a repeatable manner, made
the appropriate fixes to OpenJPA to get it to pass the TCK, and
coordinated with the people at Sun to get OpenJPA listed once 0.9.7 was
approved by the Incubator PMC.

According to Sun, we are now allowed to use the following tagline:

OpenJPA is an Implementation of the Java(TM) Persistence API

I will update our wiki to include this shortly.

-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.

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: How to debug object retrieveal in JPA?

2007-04-30 Thread Patrick Linskey

So I take it that you're no longer seeing the this result set has been
closed error. What changed in your setup since that error was
happening?

-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 30, 2007 12:07 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: RE: How to debug object retrieveal in JPA?
 
 This is all I get:
 
 0.9.7-incubating nonfatal general error
 org.apache.openjpa.persistence.PersistenceException: null
   at 
 org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:857)
   at 
 org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:756)
   at
 org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStore
 Manager.java:776)
   at
 org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult
 .java:257)
   at
 org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(Selec
 tImpl.java:2152)
   at
 org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult
 .java:251)
   at
 org.apache.openjpa.jdbc.kernel.InstanceResultObjectProvider.ge
 tResultObject(Inst
 anceResultObjectProvider.java:59)
   at
 org.apache.openjpa.lib.rop.WindowResultList.getInternal(Window
 ResultList.java:13
 1)
   at
 org.apache.openjpa.lib.rop.AbstractNonSequentialResultList.get
 (AbstractNonSequen
 tialResultList.java:72)
   at
 org.apache.openjpa.kernel.DelegatingResultList.get(DelegatingR
 esultList.java:244
 )
   at
 ca.BidSpec.emall.user.PersonFactoryImpl.getLoginPersonValueObj
 ect(PersonFactoryI
 mpl.java:99)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
 orImpl.java:39)
   at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
 odAccessorImpl.jav
 a:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingR
 eflection(AopUtils
 .java:304)
   at
 org.springframework.aop.framework.ReflectiveMethodInvocation.i
 nvokeJoinpoint(Ref
 lectiveMethodInvocation.java:172)
   at
 org.springframework.aop.framework.ReflectiveMethodInvocation.p
 roceed(ReflectiveM
 ethodInvocation.java:139)
   at
 org.springframework.transaction.interceptor.TransactionInterce
 ptor.invoke(Transa
 ctionInterceptor.java:107)
   at
 org.springframework.aop.framework.ReflectiveMethodInvocation.p
 roceed(ReflectiveM
 ethodInvocation.java:161)
   at
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(Jd
 kDynamicAopProxy.j
 ava:203)
   at $Proxy34.getLoginPersonValueObject(Unknown Source)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
 orImpl.java:39)
   at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
 odAccessorImpl.jav
 a:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingR
 eflection(AopUtils
 .java:304)
   at
 org.springframework.aop.framework.ReflectiveMethodInvocation.i
 nvokeJoinpoint(Ref
 lectiveMethodInvocation.java:172)
   at
 org.springframework.aop.framework.ReflectiveMethodInvocation.p
 roceed(ReflectiveM
 ethodInvocation.java:139)
   at
 org.springframework.transaction.interceptor.TransactionInterce
 ptor.invoke(Transa
 ctionInterceptor.java:107)
   at
 org.springframework.aop.framework.ReflectiveMethodInvocation.p
 roceed(ReflectiveM
 ethodInvocation.java:161)
   at
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(Jd
 kDynamicAopProxy.j
 ava:203)
   at $Proxy34.getLoginPersonValueObject(Unknown Source)
   at
 ca.BidSpec.testing.emall.UserFactoryTest.testDelete(UserFactor
 yTest.java:119)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
 orImpl.java:39)
   at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
 odAccessorImpl.jav
 a:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at junit.framework.TestCase.runTest(TestCase.java:168)
   at junit.framework.TestCase.runBare(TestCase.java:134)
   at
 org.springframework.test.ConditionalTestCase.runBare(Condition
 alTestCase.java:69
 )
   at
 org.springframework.test.annotation.AbstractAnnotationAwareTra

RE: How to debug object retrieveal in JPA?

2007-04-30 Thread Patrick Linskey

 ca.BidSpec.emall.user.Person.pcsetPhoneNumbers(Person.java:727)

I had read this and assumed that it was an OpenJPA-generated method, but
if so, there shouldn't be a line number. Did you reverse-compile your
classes at some point and change the synthetic interception methods?

-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: Abe White [mailto:[EMAIL PROTECTED] 
 Sent: Monday, April 30, 2007 12:22 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: How to debug object retrieveal in JPA?
 
 
  Caused by: java.lang.NullPointerException
  at java.util.ArrayList.addAll(ArrayList.java:472)
  at 
 ca.BidSpec.emall.user.Person.pcsetPhoneNumbers(Person.java:727)
  at ca.BidSpec.emall.user.Person.pcClearFields(Person.java)
  at ca.BidSpec.emall.user.Person.pcNewInstance(Person.java)
  at
  
 org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java:121)
 
 There you go.  OpenJPA is clearing the instance state as part 
 of its initialization routine, and that's causing a 
 NullPointerException in your setter at Person.java line 727.
 
 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: How to debug object retrieveal in JPA?

2007-04-30 Thread Patrick Linskey

 documentation states, the getters and setters used in 
 property access may appear with a pc prefix in stack traces 
 under OpenJPA.

Ah yes... I always forget about property access.

Phill: are you using property access? If so, can you post what you're
doing in your business logic in those methods? When using property
access, OpenJPA must use your setters and getters to access the
persistent state of your objects, so some of your business-level
invariants on the method arguments may not be adhered to by 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: Abe White [mailto:[EMAIL PROTECTED] 
 Sent: Monday, April 30, 2007 12:29 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: How to debug object retrieveal in JPA?
 
  ca.BidSpec.emall.user.Person.pcsetPhoneNumbers(Person.java:727)
 
  I had read this and assumed that it was an 
 OpenJPA-generated method, 
  but if so, there shouldn't be a line number. Did you 
 reverse-compile 
  your classes at some point and change the synthetic interception 
  methods?
 
 That is the original method with a new name.  As the 
 documentation states, the getters and setters used in 
 property access may appear with a pc prefix in stack traces 
 under OpenJPA.
 
 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: How to debug object retrieveal in JPA?

2007-04-30 Thread Patrick Linskey

 That is the original method with a new name.  As the 
 documentation states, the getters and setters used in 
 property access may appear with a pc prefix in stack traces 
 under OpenJPA.

What's the rationale behind this? It seems like this will inevitably
make debugging of problems more of a challenge, since the user's own
method names will no longer match up.

-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: Abe White [mailto:[EMAIL PROTECTED] 
 Sent: Monday, April 30, 2007 12:29 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: How to debug object retrieveal in JPA?
 
  ca.BidSpec.emall.user.Person.pcsetPhoneNumbers(Person.java:727)
 
  I had read this and assumed that it was an 
 OpenJPA-generated method, 
  but if so, there shouldn't be a line number. Did you 
 reverse-compile 
  your classes at some point and change the synthetic interception 
  methods?
 
 That is the original method with a new name.  As the 
 documentation states, the getters and setters used in 
 property access may appear with a pc prefix in stack traces 
 under OpenJPA.
 
 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: How to debug object retrieveal in JPA?

2007-04-30 Thread Patrick Linskey


Actually I am doing the clear, once I got rid of it the exception disappeared.
SO IMHO no bug


Good to hear, but I think that we could still do some work to make
this easier to debug, at the least.

And I'm still concerned about how you could ever get a list of
exceptions back from a query execution.

-Patrick

On 4/30/07, Phill Moran [EMAIL PROTECTED] wrote:

Actually I am doing the clear, once I got rid of it the exception disappeared.
SO IMHO no bug

Phill

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig Russell
Sent: April 30, 2007 5:08 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: How to debug object retrieveal in JPA?

IMHO, this is a bug in the generated code for pcNewInstance.

I don't understand why the pcNewInstance should ever call pcClearFields. It just
got finished creating a new instance, and it knows that all fields have been set
to their Java default values.
[That's why we require the user to specify a no-args constructor, so the
implementation doesn't have to initialize anything.] I don't think that calling
pcClearFields is warranted during this life cycle phase.

Craig

Caused by: java.lang.NullPointerException
at java.util.ArrayList.addAll(ArrayList.java:472)
at ca.BidSpec.emall.user.Person.pcsetPhoneNumbers(Person.java:727)
at ca.BidSpec.emall.user.Person.pcClearFields(Person.java)
at ca.BidSpec.emall.user.Person.pcNewInstance(Person.java)
at
org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java:121)


I had read this and assumed that it was an OpenJPA-generated method, but if so,
there shouldn't be a line number. Did you reverse-compile your classes at some
point and change the synthetic interception methods?

That is the original method with a new name.  As the documentation states, the
getters and setters used in property access may appear with a pc prefix in
stack traces under OpenJPA.





--
Patrick Linskey
202 669 5907

RE: new 'My Werawat' page

2007-04-28 Thread Patrick Linskey

Cool, thanks.

 To delete it, I went to the page, clicked Edit, then 
 clicked the link Remove Page.

Yeah, I tried that, but was told that I don't have permission. Hence the
email.

-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: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On 
 Behalf Of Marc Prud'hommeaux
 Sent: Saturday, April 28, 2007 10:58 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: new 'My Werawat' page
 
 
 I was able to delete it (I'm an administrator for 
 Confluence; I thought Patrick was as well).
 
 To delete it, I went to the page, clicked Edit, then 
 clicked the link Remove Page.
 
 
 
 On Apr 28, 2007, at 10:49 AM, Eddie O'Neil wrote:
 
   I'm not a cwiki expert by any stretch -- one thing to do 
 would be to 
  forward the username and page to infrastructure@ and ask them to 
  delete it.  Does anyone have permission to delete pages or is that 
  something we're missing right now?
 
  Eddie
 
 
  On 4/28/07, Patrick Linskey [EMAIL PROTECTED] wrote:
  Hey,
 
  Someone added a new page that seems to be spam, and I don't have 
  permissions in Confluence to delete it. Does anyone know how I get 
  such permission?
 
  The page in question is
  http://cwiki.apache.org/confluence/display/openjpa/My+Werawat
 
  -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.
 
  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: [DISCUSS] OpenJPA Graduation

2007-04-27 Thread Patrick Linskey

In terms of graduation, if we go the top-level route, I'd like to
propose Craig as the PMC chair. I think that he'd be a good fit since
he's quite active in the OpenJPA community, and also has a good deal of
knowledge about and experience within Apache. I think that he would do a
great job of continuing to represent Apache-isms to the OpenJPA
community and vice-versa.

-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 23, 2007 2:50 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: [DISCUSS] OpenJPA Graduation
 
 OpenJPA has done a great job of forming a diverse community 
 around a great code base whose IP has been reviewed and 
 approved for release, and we're now a well-functioning, 
 project in the incubator. So we are now at the stage when we 
 should think about when and how to leave the incubator and 
 graduate to the larger Apache community. The document at [1] 
 describes readiness to graduate.
 
 There are two courses for graduating projects: to become an 
 independent Apache TLP or to join an existing TLP as a 
 sub-project. I believe that OpenJPA should become its own TLP 
 for a few reasons: the community is already very diverse and 
 has established a good working style; and there is no 
 existing TLP upon which OpenJPA depends. There is some 
 synergy with the DB project but no dependency relationship.
 
 As a TLP, OpenJPA would operate independent from other TLPs 
 and be responsible to the Apache board. As a TLP, the OpenJPA 
 community would decide on offering committerships to the 
 project, and what and when to release, subject to the 
 regulations of the ASF.
 
 So what does everyone think?
 
 Craig
 
 [1] http://incubator.apache.org/incubation/
 Process_Description.html#Graduation
 
 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: SVN revision needed when checking in openjpa.jar

2007-04-27 Thread Patrick Linskey

(Moving a conversation about svn version data in the release to
open-jpa-dev)

To elaborate further, right now, I think that we use command-line
extraction of this data via some rather ugly mvn.

We certainly should be able to get the branch data (or at least the full
URL to the root directory). The full URL probably doesn't belong in the
version string, but probably does belong in the output of 'java
org.apache.openjpa.conf.OpenJPAVersion'.

I imagine that we could get better / more concise data if we used
JavaSVN or did some scripting or something.

Ideally, I'd love it if after graduation, our version IDs looked like
this:

Leading up to the hypothetical 1.3.2 release:

- If from a branch, openjpa-1.3.2-SNAPSHOT-branch-svn#

- If from trunk, openjpa-1.3.2-SNAPSHOT-svn#

- If from a release branch, openjpa-1.3.2

java org.apache.openjpa.conf.OpenJPAVersion would always include the
full URL to the base directory, and the corresponding svn number.

-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: David Ezzio [mailto:[EMAIL PROTECTED] 
 Sent: Friday, April 27, 2007 1:13 PM
 To: Patrick Linskey
 Cc: Marc Prud'hommeaux; /USER wls-ejb-dev
 Subject: Re: SVN revision needed when checking in openjpa.jar
 
 Hi Patrick,
 
 I'm not sure about that first number.  My visual SVN client 
 (SmartSVN) does not show any revisions associated with 
 directories.  I suspect that SVN is like P4 where directories 
 are artifacts of files and have no independent life of their 
 own.  Do you see a revision number associated with directories?
 
 In any case, it would be much clearer if the branch name was 
 inserted into the version info.  Can that be done?
 
 David
 
 Patrick Linskey wrote:
  The first number is the last revision of the top-level 
 directory itself.
  We don't change the top-level directory all that much, so 
 this info is 
  mostly useless.
  
  The second number (after the colon) is the last revision 
 number of the 
  svn repository as a whole (i.e., across all of 
 svn.apache.org, IIRC).
  
  If you see an 'M' after the second number, it means that there are 
  local changes. Release builds should not have this M there, ever.
  
  So, IOW, I don't think that we include branching info, although I 
  guess it can be inferred from the first number, since the top-level 
  dir will be different in a branch. So, from that data, we probably 
  have an approximation of the branch, and we know the 
 globally-unique 
  latest svn revision number from when the build happened.
  
  -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.

RE: [DISCUSS] OpenJPA Graduation

2007-04-27 Thread Patrick Linskey

 I second that vote, if you are not interested.

Just FTR, it's not so much that I'm not interested as much as I think
that I have much to learn in the ways of Apache before I'd be the best
PMC chair for our project.

-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: Kevin Sutter [mailto:[EMAIL PROTECTED] 
 Sent: Friday, April 27, 2007 1:23 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: [DISCUSS] OpenJPA Graduation
 
 Patrick,
 
 On 4/27/07, Patrick Linskey [EMAIL PROTECTED] wrote:
 
  In terms of graduation, if we go the top-level route, I'd like to 
  propose Craig as the PMC chair.
 
 
 I second that vote, if you are not interested.  Craig has 
 gotten us out of Apache hot water a few times with his 
 background on Apache-isms.  And, he has demonstrated his 
 overall technical knowledge in JPA and persistence issues, in 
 general.  I would think Craig would make an excellent PMC chair.
 
 Kevin
 
 I think that he'd be a good fit since
  he's quite active in the OpenJPA community, and also has a 
 good deal 
  of knowledge about and experience within Apache. I think 
 that he would 
  do a great job of continuing to represent Apache-isms to 
 the OpenJPA 
  community and vice-versa.
 
  -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 23, 2007 2:50 PM
   To: open-jpa-dev@incubator.apache.org
   Subject: [DISCUSS] OpenJPA Graduation
  
   OpenJPA has done a great job of forming a diverse 
 community around a 
   great code base whose IP has been reviewed and approved 
 for release, 
   and we're now a well-functioning, project in the incubator. So we 
   are now at the stage when we should think about when and how to 
   leave the incubator and graduate to the larger Apache 
 community. The 
   document at [1] describes readiness to graduate.
  
   There are two courses for graduating projects: to become an 
   independent Apache TLP or to join an existing TLP as a 
 sub-project. 
   I believe that OpenJPA should become its own TLP for a 
 few reasons: 
   the community is already very diverse and has established a good 
   working style; and there is no existing TLP upon which OpenJPA 
   depends. There is some synergy with the DB project but no 
 dependency 
   relationship.
  
   As a TLP, OpenJPA would operate independent from other 
 TLPs and be 
   responsible to the Apache board. As a TLP, the OpenJPA community 
   would decide on offering committerships to the project, 
 and what and 
   when to release, subject to the regulations of the ASF.
  
   So what does everyone think?
  
   Craig
  
   [1] http://incubator.apache.org/incubation/
   Process_Description.html#Graduation
  
   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.
 
 

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

FW: [VOTE] [RESULT] approve release of OpenJPA 0.9.7

2007-04-27 Thread Patrick Linskey

Congratulations, all!

Thanks, Michael, for making this happen. It's great to know that we've
now gone through a release driven by a non-BEA member of the community.

-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: Friday, April 27, 2007 1:21 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [VOTE] [RESULT] approve release of OpenJPA 0.9.7
 
 Vote results :
 
 Binding :
 Niclas Hedhman +1
 James Strachan +1
 Craig Russell + 1
 Eddie O'Neil +1
 
 Non Binding :
 Dain Sunstrom +1
 Patrick Linksey +1
 Kevin Sutter +1
 
 The vote passes with 4 IPMC +1 votes.
 
 I will prepare an announcement notice.
 
 Thank you for your support.
 
 -Michael Dick
 On 4/27/07, Eddie O'Neil [EMAIL PROTECTED] wrote:
 
+1 (binding)
 
Also, I'm all for requesting that incubating projects requesting 
  IPMC approval of a release provide a RAT report as well as 
  explanations for any missing license headers since that's a 
 focus of a 
  lot of the ensuing conversation about a release.
 
  Eddie
 
 
  On 4/26/07, Michael Dick [EMAIL PROTECTED] wrote:
   On 4/26/07, Noel J. Bergman [EMAIL PROTECTED] wrote:
   
 Also, it's probably worth pointing out that 
 schemas-doctype.rsrc 
 is OpenJPA IP, and not a redistribution of someone else's IP.
   
Ah, OK.  Hadn't seen this before I posted.
   
--- Noel
  
  
   In future releases I'll remember to clarify that 
   schemas-doctype.rsrc is OpenJPA's IP. I should have been 
 more clear 
   in the original email, now
  that
   I read it again I can see how it would cause confusion.
  
   --
   -Michael Dick
  
 
  
 -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

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] Resolved: (OPENJPA-226) Change openjpa.DetachState 'fgs' setting to 'fetch-groups'

2007-04-27 Thread Patrick Linskey (JIRA)


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

Patrick Linskey resolved OPENJPA-226.
-

Resolution: Fixed

 Change openjpa.DetachState 'fgs' setting to 'fetch-groups'
 --

 Key: OPENJPA-226
 URL: https://issues.apache.org/jira/browse/OPENJPA-226
 Project: OpenJPA
  Issue Type: Improvement
  Components: docs, kernel
Affects Versions: 0.9.0, 0.9.6, 0.9.7
Reporter: Patrick Linskey
 Assigned To: Patrick Linskey
Priority: Minor
 Fix For: 0.9.8

 Attachments: OPENJPA-226.patch


 The configuration setting openjpa.DetachState: fgs is a bit obtuse. It 
 would be nicer if this were openjpa.DetachState: fetch-groups.

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

[jira] Updated: (OPENJPA-230) Handle guaranteed delivery of Data Cache events on normal JVM termination using TCPRemoteCommitProvider

2007-04-27 Thread Patrick Linskey (JIRA)


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

Patrick Linskey updated OPENJPA-230:


Attachment: OPENJPA-230.patch

It'd be nice to not have to synchronize. What about if we made the threads 
non-daemon, and just call setRunning(false) instead? See attached 
(completely-untested) patch.

Also, I think that that boolean should be volatile to ensure thread-safety.

 Handle guaranteed delivery of Data Cache events on normal JVM termination 
 using TCPRemoteCommitProvider
 ---

 Key: OPENJPA-230
 URL: https://issues.apache.org/jira/browse/OPENJPA-230
 Project: OpenJPA
  Issue Type: Bug
  Components: kernel
Affects Versions: 0.9.0, 0.9.6, 0.9.7
Reporter: Vikram Bhatia
Priority: Minor
 Attachments: OPENJPA-230.patch, soln.diff


 When an application is commiting a transaction and then terminating, often 
 not all events regarding Data Cache are dispatched by the 
 TCPRemoteCommitProvider. It seems that the JVM on termination is not waiting 
 until TCPRemoteCommitProvider has dispatched all events regarding Data Cache. 
 In this way some cache synchronization is lost.

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

[jira] Updated: (OPENJPA-230) Handle guaranteed delivery of Data Cache events on normal JVM termination using TCPRemoteCommitProvider

2007-04-27 Thread Patrick Linskey (JIRA)


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

Patrick Linskey updated OPENJPA-230:


Attachment: OPENJPA-230.patch

Good point -- _keepRunning is a bit too abrupt.

How does this work?

 Handle guaranteed delivery of Data Cache events on normal JVM termination 
 using TCPRemoteCommitProvider
 ---

 Key: OPENJPA-230
 URL: https://issues.apache.org/jira/browse/OPENJPA-230
 Project: OpenJPA
  Issue Type: Bug
  Components: kernel
Affects Versions: 0.9.0, 0.9.6, 0.9.7
Reporter: Vikram Bhatia
Priority: Minor
 Attachments: OPENJPA-230.patch, OPENJPA-230.patch, reproducer.zip, 
 soln.diff


 When an application is commiting a transaction and then terminating, often 
 not all events regarding Data Cache are dispatched by the 
 TCPRemoteCommitProvider. It seems that the JVM on termination is not waiting 
 until TCPRemoteCommitProvider has dispatched all events regarding Data Cache. 
 In this way some cache synchronization is lost.

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

RE: Merge Detached Entity Problem

2007-04-27 Thread Patrick Linskey

That is an odd manifestation of the problem. Definitely worth
investigation.

-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: Jason Hanna [mailto:[EMAIL PROTECTED] 
 Sent: Friday, April 27, 2007 11:55 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: Merge Detached Entity Problem
 
 An update - I was not using the @Version annotation in my 
 item definition. After updating my class with the annotation 
 and adding additional database column, my original reported 
 problem disappears.
 
 My first read of the documentation led me to believe the 
 @Version annotation was a best practice, but not necessary.
 
 From the OpenJPA User's Guide, Section 1.4:
 
 ---start
 Note
 
 OpenJPA fully supports version fields, but does not require 
 them for concurrency detection. OpenJPA can maintain 
 surrogate version values or use state comparisons to detect 
 concurrent modifications. See Section 7,  Additional JPA 
 Mappings  in the Reference Guide.
 
 ---end
 
 I seem to have resolved my immediate issue, but perhaps 
 someone can set me straight on the expected behavior when the 
 @Version annotation is not present.
 
 Thanks,
 -jmh
 
 
 On 4/27/07, Jason Hanna [EMAIL PROTECTED] wrote:
  Hi All,
 
  I'm running into a problem developing a web application 
 that utilizes 
  JSF and JPA. Not sure if my problem is related to an 
 OpenJPA bug, or a 
  flaw in my approach. I'm hoping you can help.
 
  In my web application, a user selects an item to edit 
 from a table 
  of all available items. They are then directed to a page 
 containing a 
  form which allows them to modify the details of the item 
 they selected 
  (pretty standard web app stuff).
 
  Upon submission, the backing bean connected to this form 
 invokes the 
  update method of the item's data access object. The DAO in turn 
  creates and EntityManager from the EntityManagerFactory, starts a 
  transaction, merges the detached object, and commits the 
 transaction.
 
  If any value is modified on the item edit form, the 
 detached object is 
  merged and successfully committed. That's good. Now for the problem:
 
  If the detached object is NOT modifed (edit form submitted w/o any
  changes) the merge will fail on the EntityManager 
 transaction commit 
  with the following error:
 
  2|true|0.9.5-incubating
  org.apache.openjpa.persistence.RollbackException: 
 Optimistic locking 
  errors were detected when flushing to the data store.  The 
 following 
  objects may have been concurrently modified in another transaction:
  [com.coincident.green.beans.User-com.coincident.green.beans.User-1]
 
  I've read through the lifecycle management documentation 
 and don't see 
  why attempting to merge an unchanged detached entity would 
 result in 
  an exception.
 
  I could probably detect that no updates were made at my JSF managed 
  bean and avoid the merge operation altogether, but what 
 happens when 
  my item references other managed entities and I want to utilize 
  cascade merge?
 
  Hoping you all might have some thoughts. Here are a few 
 details about 
  my environment:
 
  Sun JDK 1.5.0_06
  Apache Tomcat 5.5.20
  MyFaces 1.1.3
  OpenJPA 0.9.5 (Packaged w/BEA Workship Studio and Kodo) 
 MySQL 5.0.27 
  (Community)
 
  Thanks! Please let me know if you require any more information.
 
  Regards,
  -jmh
 
  Jason M. Hanna
  President/Founder
  Coincident, 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.

RE: provide an actual JDBC connection?

2007-04-26 Thread Patrick Linskey

You can't provide a JDBC connection directly, but you can provide a
DataSource, which, in turn, can provide a connection.

-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: tbee [mailto:[EMAIL PROTECTED] 
 Sent: Thursday, April 26, 2007 2:10 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: provide an actual JDBC connection?
 
 
 Is it possible to provide an actual JDBC connection instead 
 of connect parameters?
 
 The business model I'm trying to construct will work inside 
 an existing application which does direct JDBC. There is 
 already a connection open and it would be a waste of resource 
 to have two. I can always hack together a special Driver for 
 this. Another solution would be to use the connection of OpenJPA.
 
 One concern: how many actual JDBC connections are opened 
 during a run. I assume that only one is opened and that the 
 JPA transaction concept is not directly related to the JDBC 
 transactions. That JDBC transactions are only used during a 
 JPA transaction's commit phase.
 --
 View this message in context: 
 http://www.nabble.com/provide-an-actual-JDBC-connection--tf365
0466.html#a10196861
 Sent from the open-jpa-dev mailing list archive at Nabble.com.
 
 

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: provide an actual JDBC connection?

2007-04-26 Thread Patrick Linskey

 
  Is it possible to provide an actual JDBC connection instead 
 of connect 
  parameters?
 
 You can supply the datasource instance in a 
 PersistenceUnitInfo, but I certainly hope you can't provide a 
 connection.

You can also specify a DataSource class name in the
openjpa.ConnectionFactory property; if it has a constructor that lines
up with the arguments you pass in the property value, OpenJPA will
construct it.

  The business model I'm trying to construct will work inside an 
  existing application which does direct JDBC. There is already a 
  connection open and it would be a waste of resource to have 
 two. I can 
  always hack together a special Driver for this. Another 
 solution would 
  be to use the connection of OpenJPA.
 
 Are you running inside a javaee app server?  (not standalone 
 tomcat) If so there's a very good chance that all the 
 connection handles obtained within the same jta transaction 
 actually use the same physical connection to the database.  
 Geronimo certainly does this.

If you just need to get OpenJPA's connection, you can do:

Connection c = (Connection) OpenJPAPersistence.cast(em).getConnection();

Do be careful to close that connection when you're done with it; OpenJPA
does reference-counting on connections to figure out when it's OK to
release connections (see below), and the getConnection() call counts. If
you do transactional work while using the connection, either don't close
the connection until after you call em.getTransaction().commit(), or set
your ConnectionRetainMode to 'transaction' or 'always'. This will ensure
that OpenJPA doesn't throw away the connection that you did your work
on.

  One concern: how many actual JDBC connections are opened 
 during a run. 
  I assume that only one is opened and that the JPA transaction
  concept is not
  directly related to the JDBC transactions. That JDBC 
 transactions are 
  only used during a JPA transaction's commit phase.

OpenJPA's behavior wrt. connections is controlled by the
openjpa.ConnectionRetainMode property. Briefly, by default, OpenJPA
holds onto connections for as short a time as possible, taking into
account things like flushes and datastore locking.

-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: David Jencks [mailto:[EMAIL PROTECTED] 
 Sent: Thursday, April 26, 2007 9:07 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: provide an actual JDBC connection?
 
 
 On Apr 26, 2007, at 2:10 AM, tbee wrote:
 
 
  Is it possible to provide an actual JDBC connection instead 
 of connect 
  parameters?
 
 You can supply the datasource instance in a 
 PersistenceUnitInfo, but I certainly hope you can't provide a 
 connection.
 
  The business model I'm trying to construct will work inside an 
  existing application which does direct JDBC. There is already a 
  connection open and it would be a waste of resource to have 
 two. I can 
  always hack together a special Driver for this. Another 
 solution would 
  be to use the connection of OpenJPA.
 
 Are you running inside a javaee app server?  (not standalone 
 tomcat) If so there's a very good chance that all the 
 connection handles obtained within the same jta transaction 
 actually use the same physical connection to the database.  
 Geronimo certainly does this.
 
  One concern: how many actual JDBC connections are opened 
 during a run. 
  I assume that only one is opened and that the JPA transaction
  concept is not
  directly related to the JDBC transactions. That JDBC 
 transactions are 
  only used during a JPA transaction's commit phase.
 
 If you use table based sequences and supply a 
 non-jta-datasource as  
 well as a jta datasource, typically 2 connections will be used.   
 However, if you are in an environment that does connection 
 pooling this won't make much difference.
 
 Hope this helps
 david jencks
 
 
  --
  View this message in context: http://www.nabble.com/provide-an-
  actual-JDBC-connection--tf3650466.html#a10196861
  Sent from the open-jpa-dev mailing list archive at Nabble.com.
 
 
 

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

RE: Open JPA error-Could not locate metadata for the class using alias

2007-04-26 Thread Patrick Linskey

 Many thanks Patrick!

You're welcome. 

FYI, once I commit a fix to OPENJPA-229, you'll be able to use the same
class names once again. Sorry about that bug.

-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: tbee [mailto:[EMAIL PROTECTED] 
 Sent: Thursday, April 26, 2007 1:54 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: RE: Open JPA error-Could not locate metadata for the 
 class using alias
 
 
 
 
 Patrick Linskey wrote:
  
  I think that if you do 1, 2, 3, 5, and 6, you should be in 
 good shape.
  
 
 This indeed seems to work!
 
 BTW, Toplink just now also had its lazy loading issue solved: 
 turns out @MappedSuperclass classes must be listed in the 
 persistence.xml.  The solution actually was unexpected, it 
 suddenly worked, after you told me to do add them for the 
 OpenJPA issue. You've solved two issues in one go! :-) 
 
 So now I'm suddenly from no working library to two. Now to 
 decide which one to use.
 
 Many thanks Patrick!
 --
 View this message in context: 
 http://www.nabble.com/Open-JPA-error-Could-not-locate-metadata
 -for-the-class-using-alias-tf3561516.html#a10196445
 Sent from the open-jpa-dev mailing list archive at Nabble.com.
 
 

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: How to debug object retrieveal in JPA?

2007-04-26 Thread Patrick Linskey

Could you post the full NPE? Is results null, or is the NPE coming from
within OpenJPA somewhere? OpenJPA shouldn't be returning a null
collection in any situation, I don't think.

One way to fish for causes of suspicious problems is to set the default
log level to TRACE:

property name=openjpa.Log value=DefaultLevel=TRACE/

This will generate tons of output, but the stuff towards the end might
provide something of value.

-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: Thursday, April 26, 2007 12:39 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: How to debug object retrieveal in JPA?
 
 Community,
 
 How does one go about debugging object retrieval/creation. I 
 continue to have exceptions and little to go on as far as the cause.
 The named JPQL is good since I know it generates a good sql 
 (can trace code and see it) . I know the sql is good as I can 
 copy/paste it into mysql query browser, execute and get the 
 correct data back. The problem is that these lines result in an NPE.
 
   Query q =
 this.getEntityManager().createNamedQuery(PersonFXStoreAndLogin);
   q.setParameter(storeName, storeName.toUpperCase());
   q.setParameter(loginName, loginName.toUpperCase());
   ListPerson results = null;
   try {
   results = (ListPerson) q.getResultList();
   System.out.println(results.size());
   }
   catch(Exception e) {
   e.printStackTrace();
   }
   if (results.isEmpty()) { - NPE thrown here
   throw new UserNotFoundException(No 
 user found);
   }
 Also the mappingTool validate seems to work fine. Of course 
 how would I know since I can find no description of what a 
 good one looks like but reading it (no
 exceptions) seem to make sense. 
 
 Any help would be much appreciated.
 
 Phill
 
 

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] Resolved: (OPENJPA-229) OpenJPA fails with MappedSuperclasses and Entities with the same short names

2007-04-26 Thread Patrick Linskey (JIRA)


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

Patrick Linskey resolved OPENJPA-229.
-

Resolution: Fixed

 OpenJPA fails with MappedSuperclasses and Entities with the same short names
 

 Key: OPENJPA-229
 URL: https://issues.apache.org/jira/browse/OPENJPA-229
 Project: OpenJPA
  Issue Type: Bug
  Components: kernel
Affects Versions: 0.9.0, 0.9.6, 0.9.7
 Environment: WindowsXP SP2 full updates 2007-04-25, Informix 10, Java 
 1.6.0
Reporter: Patrick Linskey
 Fix For: 0.9.8

 Attachments: OPENJPA-229.patch


 When running the test case from OPENJPA-228 (after a few modifications to get 
 it working), I get the exception included below. If I change the 'Article' 
 mapped superclass to be named 'ArticleBase', things work.
 It looks like this is happening because multiple classes are registering for 
 the same alias. We should change the enhancer to not register aliases for 
 mapped superclasses.
 Exception in thread main 0.0.0 nonfatal user error 
 org.apache.openjpa.persistence.ArgumentException: 0
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:805)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:766)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:762)
   at 
 org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:517)
   at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:230)
   at 
 org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:269)
   at nl.reinders.bm.BMTestOpenJPA.main(BMTestOpenJPA.java:41)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
 Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
   at org.apache.openjpa.jdbc.kernel.exps.PCPath.appendTo(PCPath.java:636)
   at 
 org.apache.openjpa.jdbc.kernel.exps.FilterValueImpl.appendTo(FilterValueImpl.java:62)
   at 
 org.apache.openjpa.jdbc.kernel.exps.FilterValueImpl.appendTo(FilterValueImpl.java:58)
   at 
 org.apache.openjpa.jdbc.sql.DBDictionary.appendCast(DBDictionary.java:2486)
   at 
 org.apache.openjpa.jdbc.sql.DBDictionary.comparison(DBDictionary.java:2443)
   at 
 org.apache.openjpa.jdbc.kernel.exps.CompareExpression.appendTo(CompareExpression.java:75)
   at 
 org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.buildWhere(SelectConstructor.java:238)
   at 
 org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.evaluate(SelectConstructor.java:79)
   at 
 org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.createWhereSelects(JDBCStoreQuery.java:330)
   at 
 org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeQuery(JDBCStoreQuery.java:169)
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:677)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:985)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:796)
   ... 11 more

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

RE: How to debug object retrieveal in JPA?

2007-04-26 Thread Patrick Linskey

 What is interesting is the line with a 1 (from 
 System.out.println(results.size())). What this represents is 
 the message that the result list is closed nothing else in 
 the trace. 
 
 So what causes the result list to be closed?

I don't follow -- I would assume that the '1' represents the numbers of
elements in the result list.

What happens if you change that to be 'System.out.println(results)'?

-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: Thursday, April 26, 2007 1:18 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: RE: How to debug object retrieveal in JPA?
 
 I did not mean it threw an NPE but I was left with a null 
 result list. 
 
 I have setup trace already and I actually get nothing back. 
 Here is the trace across the execution point
 
 13734  WARN   [main] openjpa.MetaData - Found duplicate query
 PersonFXLastFirst in class ca.BidSpec.emall.user.Person.  
 Ignoring.
 22594  TRACE  [main] openjpa.jdbc.SQL - t 31845311, conn 
 9575056 executing prepstmnt 31103354 SELECT t0.id, 
 t0.lastUpdated, t0.active, t0.activeFrom, t0.activeUntil, 
 t0.created, t0.displayName, t0.firstName, t0.lastLogin, 
 t0.lastName, t0.locale, t0.loginName, t0.middleName, t2.id, 
 t2.lastUpdated, t2.description, t3.id, t3.lastUpdated, 
 t3.description, t2.value, t4.id, t4.lastUpdated, 
 t4.description, t4.categoryTypeFK, t4.value, t1.id, 
 t1.lastUpdated, t1.created, t1.description, t1.displayName, 
 t1.name, t5.id, t5.lastUpdated, t5.description, 
 t5.categoryTypeFK, t5.value, t0.title, t0.visible FROM person 
 t0 INNER JOIN manufacturer t1 ON t0.manufacturerFK = t1.id 
 LEFT OUTER JOIN category t2 ON t0.roleFK = t2.id LEFT OUTER 
 JOIN category
 t4 ON t0.salutationFK = t4.id LEFT OUTER JOIN category t5 ON 
 t1.typeFK = t5.id LEFT OUTER JOIN categorytype t3 ON 
 t2.categoryTypeFK = t3.id WHERE
 (UPPER(t1.name) = ? AND UPPER(t0.loginName) = ?) ORDER BY 
 t0.lastName ASC, t0.firstName ASC [params=(String) BIDSPEC, 
 (String) PMORAN]
 22609  TRACE  [main] openjpa.jdbc.SQL - t 31845311, conn 
 9575056 [15 ms] spent
 27469  TRACE  [main] openjpa.jdbc.SQL - t 31845311, conn 
 9575056 executing prepstmnt 3888519 SELECT COUNT(*) FROM 
 person t0 INNER JOIN manufacturer t1 ON t0.manufacturerFK = 
 t1.id LEFT OUTER JOIN category t2 ON t0.roleFK = t2.id LEFT 
 OUTER JOIN category t4 ON t0.salutationFK = t4.id LEFT OUTER 
 JOIN category t5 ON t1.typeFK = t5.id LEFT OUTER JOIN 
 categorytype t3 ON t2.categoryTypeFK = t3.id WHERE 
 (UPPER(t1.name) = ? AND UPPER(t0.loginName) = ?) 
 [params=(String) BIDSPEC,
 (String) PMORAN]
 27469  TRACE  [main] openjpa.jdbc.SQL - t 31845311, conn 
 9575056 [0 ms] spent
 1
 [2007-04-26 16:07:36,125] INFO  
 ca.BidSpec.testing.emall.UserFactoryTest Rolled back 
 transaction after test execution 
 
 What is interesting is the line with a 1 (from 
 System.out.println(results.size())). What this represents is 
 the message that the result list is closed nothing else in 
 the trace. 
 
 So what causes the result list to be closed?
 
 Phill
 
 -Original Message-
 From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On 
 Behalf Of Marc Prud'hommeaux
 Sent: April 26, 2007 3:54 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: How to debug object retrieveal in JPA?
 
 Phill-
 
 The maximum verbosity of logging is obtained by specifying 
 the openjpa.Log
 property to DefaultLevel=TRACE.
 
 What is the full exception stack trace? We might be able to 
 help identify the problem. In any case OpenJPA should never 
 be throwing an NPE, so we should at least probably fix the 
 error message.
 
 
 On Apr 26, 2007, at 12:39 PM, Phill Moran wrote:
 
  Community,
 
  How does one go about debugging object retrieval/creation. 
 I continue 
  to have exceptions and little to go on as far as the cause.
  The named JPQL is good since I know it generates a good sql 
 (can trace 
  code and see it) . I know the sql is good as I can 
 copy/paste it into 
  mysql query browser, execute and get the correct data back. The 
  problem is that these lines result in an NPE.
 
  Query q =
  this.getEntityManager().createNamedQuery(PersonFXStoreAndLogin);
  q.setParameter(storeName, storeName.toUpperCase());
  q.setParameter(loginName, loginName.toUpperCase());
  ListPerson results = null;
  try {
  results = (ListPerson

RE: How to debug object retrieveal in JPA?

2007-04-26 Thread Patrick Linskey

So you're saying that the ResultList contains an Exception? Can you post
what you get if you do '((Exception) results.get(0)).printStackTrace()'?

-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: Thursday, April 26, 2007 1:44 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: RE: How to debug object retrieveal in JPA?
 
 Some more information on this exception
 
 Right after the execution the exception held inside the 
 result is com.sun.jdi.InvocationException occurred invoking 
 method... Can't seem to get more data out of it 
 
 Once the system.out is executed the exception changes to The 
 result list has been closed
 
 -Original Message-
 From: Phill Moran [mailto:[EMAIL PROTECTED]
 Sent: April 26, 2007 4:18 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: RE: How to debug object retrieveal in JPA?
 
 I did not mean it threw an NPE but I was left with a null 
 result list. 
 
 I have setup trace already and I actually get nothing back. 
 Here is the trace across the execution point
 
 13734  WARN   [main] openjpa.MetaData - Found duplicate query
 PersonFXLastFirst in class ca.BidSpec.emall.user.Person.  
 Ignoring.
 22594  TRACE  [main] openjpa.jdbc.SQL - t 31845311, conn 
 9575056 executing prepstmnt 31103354 SELECT t0.id, 
 t0.lastUpdated, t0.active, t0.activeFrom, t0.activeUntil, 
 t0.created, t0.displayName, t0.firstName, t0.lastLogin, 
 t0.lastName, t0.locale, t0.loginName, t0.middleName, t2.id, 
 t2.lastUpdated, t2.description, t3.id, t3.lastUpdated, 
 t3.description, t2.value, t4.id, t4.lastUpdated, 
 t4.description, t4.categoryTypeFK, t4.value, t1.id, 
 t1.lastUpdated, t1.created, t1.description, t1.displayName, 
 t1.name, t5.id, t5.lastUpdated, t5.description, 
 t5.categoryTypeFK, t5.value, t0.title, t0.visible FROM person 
 t0 INNER JOIN manufacturer t1 ON t0.manufacturerFK = t1.id 
 LEFT OUTER JOIN category t2 ON t0.roleFK = t2.id LEFT OUTER 
 JOIN category
 t4 ON t0.salutationFK = t4.id LEFT OUTER JOIN category t5 ON 
 t1.typeFK = t5.id LEFT OUTER JOIN categorytype t3 ON 
 t2.categoryTypeFK = t3.id WHERE
 (UPPER(t1.name) = ? AND UPPER(t0.loginName) = ?) ORDER BY 
 t0.lastName ASC, t0.firstName ASC [params=(String) BIDSPEC, 
 (String) PMORAN]
 22609  TRACE  [main] openjpa.jdbc.SQL - t 31845311, conn 
 9575056 [15 ms] spent
 27469  TRACE  [main] openjpa.jdbc.SQL - t 31845311, conn 
 9575056 executing prepstmnt 3888519 SELECT COUNT(*) FROM 
 person t0 INNER JOIN manufacturer t1 ON t0.manufacturerFK = 
 t1.id LEFT OUTER JOIN category t2 ON t0.roleFK = t2.id LEFT 
 OUTER JOIN category t4 ON t0.salutationFK = t4.id LEFT OUTER 
 JOIN category t5 ON t1.typeFK = t5.id LEFT OUTER JOIN 
 categorytype t3 ON t2.categoryTypeFK = t3.id WHERE 
 (UPPER(t1.name) = ? AND UPPER(t0.loginName) = ?) 
 [params=(String) BIDSPEC,
 (String) PMORAN]
 27469  TRACE  [main] openjpa.jdbc.SQL - t 31845311, conn 
 9575056 [0 ms] spent
 1
 [2007-04-26 16:07:36,125] INFO  
 ca.BidSpec.testing.emall.UserFactoryTest Rolled back 
 transaction after test execution 
 
 What is interesting is the line with a 1 (from 
 System.out.println(results.size())). What this represents is 
 the message that the result list is closed nothing else in 
 the trace. 
 
 So what causes the result list to be closed?
 
 Phill
 
 -Original Message-
 From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On 
 Behalf Of Marc Prud'hommeaux
 Sent: April 26, 2007 3:54 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: How to debug object retrieveal in JPA?
 
 Phill-
 
 The maximum verbosity of logging is obtained by specifying 
 the openjpa.Log
 property to DefaultLevel=TRACE.
 
 What is the full exception stack trace? We might be able to 
 help identify the problem. In any case OpenJPA should never 
 be throwing an NPE, so we should at least probably fix the 
 error message.
 
 
 On Apr 26, 2007, at 12:39 PM, Phill Moran wrote:
 
  Community,
 
  How does one go about debugging object retrieval/creation. 
 I continue 
  to have exceptions and little to go on as far as the cause.
  The named JPQL is good since I know it generates a good sql 
 (can trace 
  code and see it) . I know the sql is good as I can 
 copy/paste it into 
  mysql query browser, execute and get the correct data back. The 
  problem is that these lines result in an NPE.
 
  Query q =
  this.getEntityManager().createNamedQuery(PersonFXStoreAndLogin

RE: How to debug object retrieveal in JPA?

2007-04-26 Thread Patrick Linskey

 Can you post what you get if you do '((Exception) 
 results.get(0)).printStackTrace()'?

... so results.get(0) is returning a List? That's very odd. What if you
do:

System.out.println(results.get(0))?

If it is a List of Exceptions, what if you print out the stacks of the
exceptions in the list?

-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: Thursday, April 26, 2007 2:36 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: RE: How to debug object retrieveal in JPA?
 
 Can't cast List to Exception 
 
 -Original Message-
 From: Patrick Linskey [mailto:[EMAIL PROTECTED]
 Sent: April 26, 2007 5:00 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: RE: How to debug object retrieveal in JPA?
 
 So you're saying that the ResultList contains an Exception? 
 Can you post what you get if you do '((Exception) 
 results.get(0)).printStackTrace()'?
 
 -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: Thursday, April 26, 2007 1:44 PM
  To: open-jpa-dev@incubator.apache.org
  Subject: RE: How to debug object retrieveal in JPA?
  
  Some more information on this exception
  
  Right after the execution the exception held inside the result is 
  com.sun.jdi.InvocationException occurred invoking method... Can't 
  seem to get more data out of it
  
  Once the system.out is executed the exception changes to 
 The result 
  list has been closed
  
  -Original Message-
  From: Phill Moran [mailto:[EMAIL PROTECTED]
  Sent: April 26, 2007 4:18 PM
  To: open-jpa-dev@incubator.apache.org
  Subject: RE: How to debug object retrieveal in JPA?
  
  I did not mean it threw an NPE but I was left with a null 
 result list.
  
  I have setup trace already and I actually get nothing back. 
  Here is the trace across the execution point
  
  13734  WARN   [main] openjpa.MetaData - Found duplicate query
  PersonFXLastFirst in class ca.BidSpec.emall.user.Person.  
  Ignoring.
  22594  TRACE  [main] openjpa.jdbc.SQL - t 31845311, conn
  9575056 executing prepstmnt 31103354 SELECT t0.id,
  t0.lastUpdated, t0.active, t0.activeFrom, t0.activeUntil, 
 t0.created, 
  t0.displayName, t0.firstName, t0.lastLogin, t0.lastName, t0.locale, 
  t0.loginName, t0.middleName, t2.id, t2.lastUpdated, t2.description, 
  t3.id, t3.lastUpdated, t3.description, t2.value, t4.id, 
  t4.lastUpdated, t4.description, t4.categoryTypeFK, t4.value, t1.id, 
  t1.lastUpdated, t1.created, t1.description, t1.displayName, 
 t1.name, 
  t5.id, t5.lastUpdated, t5.description, t5.categoryTypeFK, t5.value, 
  t0.title, t0.visible FROM person t0 INNER JOIN manufacturer t1 ON 
  t0.manufacturerFK = t1.id LEFT OUTER JOIN category t2 ON 
 t0.roleFK = 
  t2.id LEFT OUTER JOIN category
  t4 ON t0.salutationFK = t4.id LEFT OUTER JOIN category t5 
 ON t1.typeFK 
  = t5.id LEFT OUTER JOIN categorytype t3 ON 
 t2.categoryTypeFK = t3.id 
  WHERE
  (UPPER(t1.name) = ? AND UPPER(t0.loginName) = ?) ORDER BY 
 t0.lastName 
  ASC, t0.firstName ASC [params=(String) BIDSPEC,
  (String) PMORAN]
  22609  TRACE  [main] openjpa.jdbc.SQL - t 31845311, conn
  9575056 [15 ms] spent
  27469  TRACE  [main] openjpa.jdbc.SQL - t 31845311, conn
  9575056 executing prepstmnt 3888519 SELECT COUNT(*) FROM
  person t0 INNER JOIN manufacturer t1 ON t0.manufacturerFK = 
 t1.id LEFT 
  OUTER JOIN category t2 ON t0.roleFK = t2.id LEFT OUTER JOIN category
  t4 ON t0.salutationFK = t4.id LEFT OUTER JOIN category t5 
 ON t1.typeFK 
  = t5.id LEFT OUTER JOIN categorytype t3 ON 
 t2.categoryTypeFK = t3.id 
  WHERE
  (UPPER(t1.name) = ? AND UPPER(t0.loginName) = ?)
  [params=(String) BIDSPEC,
  (String) PMORAN]
  27469  TRACE  [main] openjpa.jdbc.SQL - t 31845311, conn
  9575056 [0 ms] spent
  1
  [2007-04-26 16:07:36,125] INFO
  ca.BidSpec.testing.emall.UserFactoryTest

RE: How to debug object retrieveal in JPA?

2007-04-26 Thread Patrick Linskey

 Caused by: java.lang.NullPointerException
   at java.util.Locale.toLowerCase(Locale.java:1060)
   at java.util.Locale.convertOldISOCodes(Locale.java:1083)
   at java.util.Locale.init(Locale.java:272)
   at java.util.Locale.init(Locale.java:302)
   at ca.BidSpec.emall.user.Person.pcsetLocale(Person.java:375)
   at ca.BidSpec.emall.user.Person.pcClearFields(Person.java)
   at ca.BidSpec.emall.user.Person.pcNewInstance(Person.java)
   at
 org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java:117)

Now we're getting somewhere what happens if you remove the Locale
field from the Person class?

-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: Thursday, April 26, 2007 6:32 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: RE: How to debug object retrieveal in JPA?
 
 Run that config gives us this lovely message:
 
 0|false|0.9.6-incubating 
 org.apache.openjpa.persistence.PersistenceException:
 null
   at 
 org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:851)
   at 
 org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:748)
   at
 org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStore
 Manager.java:773)
   at
 org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult
 .java:254)
   at
 org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(Selec
 tImpl.java:2115)
   at
 org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult
 .java:248)
   at
 org.apache.openjpa.jdbc.kernel.InstanceResultObjectProvider.ge
 tResultObject(Inst
 anceResultObjectProvider.java:56)
   at
 org.apache.openjpa.lib.rop.WindowResultList.getInternal(Window
 ResultList.java:12
 8)
   at
 org.apache.openjpa.lib.rop.AbstractNonSequentialResultList.get
 (AbstractNonSequen
 tialResultList.java:69)
   at
 org.apache.openjpa.kernel.DelegatingResultList.get(DelegatingR
 esultList.java:241
 )
   at
 ca.BidSpec.emall.user.PersonFactoryImpl.getLoginPersonValueObj
 ect(PersonFactoryI
 mpl.java:99)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
 orImpl.java:39)
   at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
 odAccessorImpl.jav
 a:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingR
 eflection(AopUtils
 .java:304)
   at
 org.springframework.aop.framework.ReflectiveMethodInvocation.i
 nvokeJoinpoint(Ref
 lectiveMethodInvocation.java:172)
   at
 org.springframework.aop.framework.ReflectiveMethodInvocation.p
 roceed(ReflectiveM
 ethodInvocation.java:139)
   at
 org.springframework.transaction.interceptor.TransactionInterce
 ptor.invoke(Transa
 ctionInterceptor.java:107)
   at
 org.springframework.aop.framework.ReflectiveMethodInvocation.p
 roceed(ReflectiveM
 ethodInvocation.java:161)
   at
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(Jd
 kDynamicAopProxy.j
 ava:203)
   at $Proxy34.getLoginPersonValueObject(Unknown Source)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
 orImpl.java:39)
   at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
 odAccessorImpl.jav
 a:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingR
 eflection(AopUtils
 .java:304)
   at
 org.springframework.aop.framework.ReflectiveMethodInvocation.i
 nvokeJoinpoint(Ref
 lectiveMethodInvocation.java:172)
   at
 org.springframework.aop.framework.ReflectiveMethodInvocation.p
 roceed(ReflectiveM
 ethodInvocation.java:139)
   at
 org.springframework.transaction.interceptor.TransactionInterce
 ptor.invoke(Transa
 ctionInterceptor.java:107)
   at
 org.springframework.aop.framework.ReflectiveMethodInvocation.p
 roceed(ReflectiveM
 ethodInvocation.java:161)
   at
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(Jd
 kDynamicAopProxy.j
 ava:203)
   at $Proxy34.getLoginPersonValueObject(Unknown Source)
   at
 ca.BidSpec.testing.emall.UserFactoryTest.testDelete(UserFactor
 yTest.java:119)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method

RE: Open JPA error-Could not locate metadata for the class using alias

2007-04-25 Thread Patrick Linskey

I think that there were some JIRA issues with aliases in 0.9.6. I
thought that most of them had to do with orm.xml processing, but maybe
some of them were more low-level than that.

Could you try out the almost-final OpenJPA 0.9.7 bits instead? The
candidate (currently being voted on) is at
http://people.apache.org/~mikedd/staging-repository/org/apache/openjpa/o
penjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating-binary.
zip

If that doesn't work out, could you package up an example for us to try
out against the latest code?

-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: tbee [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, April 24, 2007 11:04 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: RE: Open JPA error-Could not locate metadata for the 
 class using alias
 
 
 
 
 Patrick Linskey wrote:
  
  What's the OpenJPA version in question?
  
 
 
 openjpa-project-0.9.6-incubating-binary
 --
 View this message in context: 
 http://www.nabble.com/Open-JPA-error-Could-not-locate-metadata
 -for-the-class-using-alias-tf3561516.html#a10174891
 Sent from the open-jpa-dev mailing list archive at Nabble.com.
 
 

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: Open JPA error-Could not locate metadata for the class using alias

2007-04-25 Thread Patrick Linskey

 What I'm wondering about: when running under Toplink there is 
 an output alias defaults to . Is there something that 
 Toplink assumes about this alias that actually should be 
 configured and where OpenJPA has problems with?

No... the alias should default to the short name of the class; that
behavior is defined in the spec.

 I can just upload file the example code? How to solve the 
 missing Informix database?

I don't think that uploading to this mailing list works; the easiest
thing to do is to create a JIRA issue and attach the jar / zip of the
problem there. If you'd rather not create a JIRA account, you can send
the code to pcl at apache dot org, and I'll attach it to a new issue for
the group's perusal.

-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: tbee [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, April 24, 2007 11:24 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: RE: Open JPA error-Could not locate metadata for the 
 class using alias
 
 
 
 
 Patrick Linskey wrote:
  
  Could you try out the almost-final OpenJPA 0.9.7 bits instead? The 
  candidate (currently being voted on) is at 
  
 http://people.apache.org/~mikedd/staging-repository/org/apache/openjpa
  /o 
  
 penjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubati
 ng-binary.
  zip
  
  If that doesn't work out, could you package up an example for us to 
  try out against the latest code?
  
 
 47  reinders  INFO   [main] openjpa.Runtime - Starting OpenJPA
 0.9.7-incubating
 172  reinders  INFO   [main] openjpa.jdbc.JDBC - Using 
 dictionary class
 org.apache.openjpa.jdbc.sql.InformixDictionary.
 Exception in thread main 0.9.7-incubating fatal user error
 org.apache.openjpa.persistence.ArgumentException: Could not 
 locate metadata for the class using alias Article. 
 Registered alias mappings:
 {Article=null}
 
 What I'm wondering about: when running under Toplink there is 
 an output alias defaults to . Is there something that 
 Toplink assumes about this alias that actually should be 
 configured and where OpenJPA has problems with?
 
 I can just upload file the example code? How to solve the 
 missing Informix database?
 --
 View this message in context: 
 http://www.nabble.com/Open-JPA-error-Could-not-locate-metadata
 -for-the-class-using-alias-tf3561516.html#a10175078
 Sent from the open-jpa-dev mailing list archive at Nabble.com.
 
 

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] Commented: (OPENJPA-228) Could not locate metadata for the class using alias

2007-04-25 Thread Patrick Linskey (JIRA)


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

Patrick Linskey commented on OPENJPA-228:
-

I haven't run it yet, but a couple of things look suspicious:

1. You've got multiple @Entity classes called Article. The spec says that if an 
entity name is not specified, the name defaults to the short name of the entity.

2. Given that you're listing your persistent types, you should also list the 
generated classes as well. I think that this shouldn't be causing this problem, 
but it feels like it's best practice to list all or none of the classes.

 Could not locate metadata for the class using alias
 ---

 Key: OPENJPA-228
 URL: https://issues.apache.org/jira/browse/OPENJPA-228
 Project: OpenJPA
  Issue Type: Bug
Affects Versions: 0.9.6, 0.9.7
 Environment: WindowsXP SP2 full updates 2007-04-25, Informix 10, Java 
 1.6.0
Reporter: Tom
 Attachments: bm.zip


 This: 
   List lArticles = lEntityManager.createQuery(select a from 
 Article a where a.iArticlenr  103).getResultList(); // where articlenr  103
 Results in:
 Exception in thread main 0.9.7-incubating fatal user error 
 org.apache.openjpa.persistence.ArgumentException: Could not locate metadata 
 for the class using alias Article. Registered alias mappings: 
 {Article=null}
   at 
 org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:348)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JPQLExpressionBuilder.java:167)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaData(JPQLExpressionBuilder.java:145)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:214)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:184)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(JPQLExpressionBuilder.java:177)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$500(JPQLExpressionBuilder.java:64)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.populate(JPQLExpressionBuilder.java:1671)
   at 
 org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:55)
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(ExpressionStoreQuery.java:148)
   at 
 org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:649)
   at 
 org.apache.openjpa.kernel.QueryImpl.compilationFromCache(QueryImpl.java:630)
   at 
 org.apache.openjpa.kernel.QueryImpl.compileForCompilation(QueryImpl.java:596)
   at 
 org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:658)
   at org.apache.openjpa.kernel.QueryImpl.getOperation(QueryImpl.java:1483)
   at 
 org.apache.openjpa.kernel.DelegatingQuery.getOperation(DelegatingQuery.java:123)
   at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:219)
   at 
 org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:269)
   at nl.reinders.bm.BMTestOpenJPA.main(BMTestOpenJPA.java:41)

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

RE: Open JPA error-Could not locate metadata for the class using alias

2007-04-25 Thread Patrick Linskey

Oh, and don't worry about the lack of the DB. We can probably
forward-generate a schema for Derby or somesuch that is good enough for
the purposes of tracking down this problem.

-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: tbee [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, April 24, 2007 11:24 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: RE: Open JPA error-Could not locate metadata for the 
 class using alias
 
 
 
 
 Patrick Linskey wrote:
  
  Could you try out the almost-final OpenJPA 0.9.7 bits instead? The 
  candidate (currently being voted on) is at 
  
 http://people.apache.org/~mikedd/staging-repository/org/apache/openjpa
  /o 
  
 penjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubati
 ng-binary.
  zip
  
  If that doesn't work out, could you package up an example for us to 
  try out against the latest code?
  
 
 47  reinders  INFO   [main] openjpa.Runtime - Starting OpenJPA
 0.9.7-incubating
 172  reinders  INFO   [main] openjpa.jdbc.JDBC - Using 
 dictionary class
 org.apache.openjpa.jdbc.sql.InformixDictionary.
 Exception in thread main 0.9.7-incubating fatal user error
 org.apache.openjpa.persistence.ArgumentException: Could not 
 locate metadata for the class using alias Article. 
 Registered alias mappings:
 {Article=null}
 
 What I'm wondering about: when running under Toplink there is 
 an output alias defaults to . Is there something that 
 Toplink assumes about this alias that actually should be 
 configured and where OpenJPA has problems with?
 
 I can just upload file the example code? How to solve the 
 missing Informix database?
 --
 View this message in context: 
 http://www.nabble.com/Open-JPA-error-Could-not-locate-metadata
 -for-the-class-using-alias-tf3561516.html#a10175078
 Sent from the open-jpa-dev mailing list archive at Nabble.com.
 
 

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: Open JPA error-Could not locate metadata for the class using alias

2007-04-25 Thread Patrick Linskey

 Could you elaborate?

You should put the @IdClass annotation in the same class as the @Id
fields are declared. So, in your example, in the @MappedSuperclass or
@Entity.

FYI, I just switched your classes back to using @MappedSuperclass -- the
subtypes were specified to use single-table inheritance, and table names
were also specified in the mapped superclasses, causing a mapping error.
I've had to make a couple of other changes to get things running; I'll
send more info soon.

-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: tbee [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, April 25, 2007 1:06 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: RE: Open JPA error-Could not locate metadata for the 
 class using alias
 
 
 
 
 Patrick Linskey wrote:
  
  Ok... the problem is that OpenJPA requires that you run the OpenJPA 
  class enhancer over your classes (or run in a container environment 
  such as an appserver or Spring, which can do 
 class-load-time processing).
  
  The other problem is that the error message is really bad, 
 in that it 
  doesn't suggest that as a cause, and in that the message 
  stringification is deferred, causing the Article=null 
 negative-cache misdirection.
  I've changed the error message and toString() logic.
  
  Meanwhile, I got the following when running the enhancer on your
  classes:
  
  0.0.0 fatal user error org.apache.openjpa.util.MetaDataException:
  nl.reinders.bm.generated.License.iLicensenr declares 
 generator name 
  licensenr, but uses the AUTO generation type.  The only valid 
  generator names under AUTO are uuid-hex and uuid-string.
  
  I changed the @GeneratedValue annotation to specify that it's using 
  the 'GenerationType.TABLE' strategy, but then I ran into 
 problems with 
  classes that had compound identity but didn't specify an @IdClass.
  
 
 
 Ok, the first part I get; actually very logical. 
 
 The generator I follow also, I should alter the RevEng to 
 generate type=table. Ok. But the compound identity I'm not 
 quite following. If all is well then I should be generating 
 *PK.java classes for tables with more than one field in the 
 PK and the corresponding @IdClass. Maybe the quick change to 
 @Entity extends @Entity has a bug, now that I think of it, 
 the @IdClass may refer to a PK class that actually is in the 
 generated package.
 Could you elaborate?
 
 --
 View this message in context: 
 http://www.nabble.com/Open-JPA-error-Could-not-locate-metadata
 -for-the-class-using-alias-tf3561516.html#a10176178
 Sent from the open-jpa-dev mailing list archive at Nabble.com.
 
 

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: Open JPA error-Could not locate metadata for the class using alias

2007-04-25 Thread Patrick Linskey

So, I got things working (well, to the point where the list.get(1) call
failed since my db was empty). I had to do the following to your code to
make things work:

1. changed back to @MappedSuperclass in generated dir

2. added all the superclasses to persistence.xml

3. commented out Zzzupdates -- GregorianCalendar is not a legal id type

4. renamed a bunch of columns and table names to not be reserved
keywords in Derby

5. fixed the GeneratedValue usage

6. renamed generated.Article to generated.ArticleBase

I think that if you do 1, 2, 3, 5, and 6, you should be in good shape.

FYI, I was getting a very cryptic error when the system had a
@MappedSuperclass called Article and an @Entity called Article. This is
a bug in OpenJPA -- mapped superclasses should not have aliases. You can
work around it by adding some postfix (as in ArticleBase) to all your
mapped superclasses. Certainly this is something that we should fix,
though.

-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: tbee [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, April 25, 2007 1:06 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: RE: Open JPA error-Could not locate metadata for the 
 class using alias
 
 
 
 
 Patrick Linskey wrote:
  
  Ok... the problem is that OpenJPA requires that you run the OpenJPA 
  class enhancer over your classes (or run in a container environment 
  such as an appserver or Spring, which can do 
 class-load-time processing).
  
  The other problem is that the error message is really bad, 
 in that it 
  doesn't suggest that as a cause, and in that the message 
  stringification is deferred, causing the Article=null 
 negative-cache misdirection.
  I've changed the error message and toString() logic.
  
  Meanwhile, I got the following when running the enhancer on your
  classes:
  
  0.0.0 fatal user error org.apache.openjpa.util.MetaDataException:
  nl.reinders.bm.generated.License.iLicensenr declares 
 generator name 
  licensenr, but uses the AUTO generation type.  The only valid 
  generator names under AUTO are uuid-hex and uuid-string.
  
  I changed the @GeneratedValue annotation to specify that it's using 
  the 'GenerationType.TABLE' strategy, but then I ran into 
 problems with 
  classes that had compound identity but didn't specify an @IdClass.
  
 
 
 Ok, the first part I get; actually very logical. 
 
 The generator I follow also, I should alter the RevEng to 
 generate type=table. Ok. But the compound identity I'm not 
 quite following. If all is well then I should be generating 
 *PK.java classes for tables with more than one field in the 
 PK and the corresponding @IdClass. Maybe the quick change to 
 @Entity extends @Entity has a bug, now that I think of it, 
 the @IdClass may refer to a PK class that actually is in the 
 generated package.
 Could you elaborate?
 
 --
 View this message in context: 
 http://www.nabble.com/Open-JPA-error-Could-not-locate-metadata
 -for-the-class-using-alias-tf3561516.html#a10176178
 Sent from the open-jpa-dev mailing list archive at Nabble.com.
 
 

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] Closed: (OPENJPA-228) Could not locate metadata for the class using alias

2007-04-25 Thread Patrick Linskey (JIRA)


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

Patrick Linskey closed OPENJPA-228.
---

Resolution: Fixed

Persistent classes were not enhanced prior to use. Added a better error message 
in r532273.

 Could not locate metadata for the class using alias
 ---

 Key: OPENJPA-228
 URL: https://issues.apache.org/jira/browse/OPENJPA-228
 Project: OpenJPA
  Issue Type: Bug
Affects Versions: 0.9.6, 0.9.7
 Environment: WindowsXP SP2 full updates 2007-04-25, Informix 10, Java 
 1.6.0
Reporter: Tom
 Attachments: bm.zip


 This: 
   List lArticles = lEntityManager.createQuery(select a from 
 Article a where a.iArticlenr  103).getResultList(); // where articlenr  103
 Results in:
 Exception in thread main 0.9.7-incubating fatal user error 
 org.apache.openjpa.persistence.ArgumentException: Could not locate metadata 
 for the class using alias Article. Registered alias mappings: 
 {Article=null}
   at 
 org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:348)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JPQLExpressionBuilder.java:167)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaData(JPQLExpressionBuilder.java:145)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:214)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:184)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(JPQLExpressionBuilder.java:177)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$500(JPQLExpressionBuilder.java:64)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.populate(JPQLExpressionBuilder.java:1671)
   at 
 org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:55)
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(ExpressionStoreQuery.java:148)
   at 
 org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:649)
   at 
 org.apache.openjpa.kernel.QueryImpl.compilationFromCache(QueryImpl.java:630)
   at 
 org.apache.openjpa.kernel.QueryImpl.compileForCompilation(QueryImpl.java:596)
   at 
 org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:658)
   at org.apache.openjpa.kernel.QueryImpl.getOperation(QueryImpl.java:1483)
   at 
 org.apache.openjpa.kernel.DelegatingQuery.getOperation(DelegatingQuery.java:123)
   at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:219)
   at 
 org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:269)
   at nl.reinders.bm.BMTestOpenJPA.main(BMTestOpenJPA.java:41)

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

[jira] Created: (OPENJPA-229) OpenJPA fails with MappedSuperclasses and Entities with the same short names

2007-04-25 Thread Patrick Linskey (JIRA)

OpenJPA fails with MappedSuperclasses and Entities with the same short names


 Key: OPENJPA-229
 URL: https://issues.apache.org/jira/browse/OPENJPA-229
 Project: OpenJPA
  Issue Type: Bug
Affects Versions: 0.9.6, 0.9.7
 Environment: WindowsXP SP2 full updates 2007-04-25, Informix 10, Java 
1.6.0
Reporter: Tom


This: 

List lArticles = lEntityManager.createQuery(select a from 
Article a where a.iArticlenr  103).getResultList(); // where articlenr  103

Results in:

Exception in thread main 0.9.7-incubating fatal user error 
org.apache.openjpa.persistence.ArgumentException: Could not locate metadata for 
the class using alias Article. Registered alias mappings: {Article=null}
at 
org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:348)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JPQLExpressionBuilder.java:167)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaData(JPQLExpressionBuilder.java:145)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:214)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:184)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(JPQLExpressionBuilder.java:177)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$500(JPQLExpressionBuilder.java:64)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.populate(JPQLExpressionBuilder.java:1671)
at 
org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:55)
at 
org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(ExpressionStoreQuery.java:148)
at 
org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:649)
at 
org.apache.openjpa.kernel.QueryImpl.compilationFromCache(QueryImpl.java:630)
at 
org.apache.openjpa.kernel.QueryImpl.compileForCompilation(QueryImpl.java:596)
at 
org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:658)
at org.apache.openjpa.kernel.QueryImpl.getOperation(QueryImpl.java:1483)
at 
org.apache.openjpa.kernel.DelegatingQuery.getOperation(DelegatingQuery.java:123)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:219)
at 
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:269)
at nl.reinders.bm.BMTestOpenJPA.main(BMTestOpenJPA.java:41)


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

[jira] Updated: (OPENJPA-229) OpenJPA fails with MappedSuperclasses and Entities with the same short names

2007-04-25 Thread Patrick Linskey (JIRA)


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

Patrick Linskey updated OPENJPA-229:


  Component/s: kernel
Fix Version/s: 0.9.8
  Description: 
When running the test case from OPENJPA-228 (after a few modifications to get 
it working), I get the exception included below. If I change the 'Article' 
mapped superclass to be named 'ArticleBase', things work.

It looks like this is happening because multiple classes are registering for 
the same alias. We should change the enhancer to not register aliases for 
mapped superclasses.

Exception in thread main 0.0.0 nonfatal user error 
org.apache.openjpa.persistence.ArgumentException: 0
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:805)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:766)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:762)
at 
org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:517)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:230)
at 
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:269)
at nl.reinders.bm.BMTestOpenJPA.main(BMTestOpenJPA.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
at org.apache.openjpa.jdbc.kernel.exps.PCPath.appendTo(PCPath.java:636)
at 
org.apache.openjpa.jdbc.kernel.exps.FilterValueImpl.appendTo(FilterValueImpl.java:62)
at 
org.apache.openjpa.jdbc.kernel.exps.FilterValueImpl.appendTo(FilterValueImpl.java:58)
at 
org.apache.openjpa.jdbc.sql.DBDictionary.appendCast(DBDictionary.java:2486)
at 
org.apache.openjpa.jdbc.sql.DBDictionary.comparison(DBDictionary.java:2443)
at 
org.apache.openjpa.jdbc.kernel.exps.CompareExpression.appendTo(CompareExpression.java:75)
at 
org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.buildWhere(SelectConstructor.java:238)
at 
org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.evaluate(SelectConstructor.java:79)
at 
org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.createWhereSelects(JDBCStoreQuery.java:330)
at 
org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeQuery(JDBCStoreQuery.java:169)
at 
org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:677)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:985)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:796)
... 11 more


  was:
This: 

List lArticles = lEntityManager.createQuery(select a from 
Article a where a.iArticlenr  103).getResultList(); // where articlenr  103

Results in:

Exception in thread main 0.9.7-incubating fatal user error 
org.apache.openjpa.persistence.ArgumentException: Could not locate metadata for 
the class using alias Article. Registered alias mappings: {Article=null}
at 
org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:348)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JPQLExpressionBuilder.java:167)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaData(JPQLExpressionBuilder.java:145)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:214)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:184)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(JPQLExpressionBuilder.java:177)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$500(JPQLExpressionBuilder.java:64)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.populate(JPQLExpressionBuilder.java:1671)
at 
org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:55)
at 
org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(ExpressionStoreQuery.java:148)
at 
org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:649)
at 
org.apache.openjpa.kernel.QueryImpl.compilationFromCache(QueryImpl.java:630)
at 
org.apache.openjpa.kernel.QueryImpl.compileForCompilation(QueryImpl.java:596)
at 
org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:658)
at org.apache.openjpa.kernel.QueryImpl.getOperation(QueryImpl.java:1483

RE: Possible problem with ddl with only a jta-datasource and sequences

2007-04-25 Thread Patrick Linskey

 That's why we have two datasources for an EMF. One is the 
 transactional datasource that gives you connections 
 automatically enlisted in your transactional EM; the other 
 gives you connections that are never enlisted and can be used 
 for nontransactional queries, nontransactional sequences etc. 
 The TSR is only of use for the enlisted datasource/connection.

That's one approach for out-of-band work. But, there are other ways to
do such work also, without requiring multiple datasources. For example,
suspending the current tx, starting a new one, doing the work,
committing, and resuming the old one is a workable solution, if you have
access to the tx.

-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: Wednesday, April 25, 2007 10:05 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: Possible problem with ddl with only a 
 jta-datasource and sequences
 
 
 On Apr 24, 2007, at 11:38 AM, Marc Prud'hommeaux wrote:
 
  David-
 
  Does this seem like a reasonable explanation?
 
  That sounds right to me.
 
  Note that if we ever update OpenJPA to depend solely on the 
  TransactionSynchronizationRegistry, then we won't be able 
 to do things 
  like suspending the transactions and resuming it later with the 
  jta-datasource.
 
 That's why we have two datasources for an EMF. One is the 
 transactional datasource that gives you connections 
 automatically enlisted in your transactional EM; the other 
 gives you connections that are never enlisted and can be used 
 for nontransactional queries, nontransactional sequences etc. 
 The TSR is only of use for the enlisted datasource/connection.
 
 Craig
 
 
  On Apr 24, 2007, at 10:52 AM, David Jencks wrote:
 
  Using derby, jta transactions (in geronimo), a table sequence, 
  autocreation of tables, and only a jta-datasource, I get errors 
  complaining that the sequence table doesn't exist.
 
  Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException:  
  Table/View 'OPENJPASEQ' does not exist. {SELECT 
 SEQUENCE_VALUE FROM 
  OPENJPASEQ WHERE ID = ? FOR UPDATE WITH RR} [code=2, 
 state=42X05]
 
  If I supply a non-jta-datasource everything works fine.
 
  My current theory about why this is happening is that the ddl to 
  create all the tables is executed in a connection from the jta- 
  datasource that's enrolled in a jta transaction.  Then we 
 go to get 
  an id from the sequence, the jta transaction is suspended, 
 and a new 
  tx is started, in which the ddl is not visible since the jta tx 
  wasn't committed. (apparently ddl in derby is transactional)
 
  Does this seem like a reasonable explanation?
 
  I'm going to look for a way to run the ddl inside a separate 
  transaction that can be committed, the same as how sequences work 
  without a non-jta-datasource.  One way to do this would be to
  package the work up in a Runnable and execute it in an   
  appropriate transactional environment.  It might be easier to 
  understand if the sequence code had a similar implementation.
 
  thanks
  david jencks
 
 
 
 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: More questions on runtime schema generation

2007-04-25 Thread Patrick Linskey

OpenJPA actually already has jar-scanning code. Try the following:

openjpa.jdbc.SynchronizeMappings:
buildSchema(files=path/to/file.jar;path/to/another-file.jar)

You can also specify 'resources' or 'URLs'.

These algorithms use
org.apache.openjpa.lib.meta.ClassAnnotationMetaDataFilter, which scans
bytes for specified annotations. IIRC, we looked at some Apache code
when implementing it; I can't remember if it was xbean code or not.

-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: David Jencks [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, April 25, 2007 12:42 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: More questions on runtime schema generation
 
 
 On Apr 25, 2007, at 12:26 PM, Patrick Linskey wrote:
 
  However IIUC this dissects the system property java.class.path and 
  only parses stuff on that.  This might be reasonable for a command 
  line tool (although I have some
  doubts) but it seems to me that for any other situation a 
 scan of the 
  provided classloader would be more appropriate.
  Is this reasonable?
 
  It is. Of course, there is no standard way to scan 
 classloaders. The 
  best I know of is to do:
 
  cls.getProtectionDomain().getCodeSource().getLocation()
 
  and then scan from that URL.
 
  Of course, this assumes that a) you have a class (not a 
 ClassLoader), 
  b) you have security privileges to get the protection 
 domain, and b) 
  the location is parsable and accessible.
 
  Is there some other way that you know of to scan a ClassLoader?
 
 I was going to steal code from xbean ClassFinder
 
 https://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/
 src/main/java/org/apache/xbean/finder/ClassFinder.java
 
 which works for jar files, which is all I'm interested in.  
 It locates the jar or directory or an exploded jar by looking 
 for all the META-INF resources in the classloader.  This 
 isn't exactly scanning a classloader but will be adequate for me.
 
 I don't suppose openjpa would be interested in using the 
 xbean-finder jar directly?  It only has 3 classes in it :-)  
 In particular ClassFinder is good at locating all the classes 
 with an annotation in a classloader.
 
 thanks
 david jencks
 
 
 
  Also, I would like to suggest a flag in the
  openjpa.jdbc.SynchronizeMappings=buildSchema(...) stuff to turn on 
  this eager scanning I'm trying to implement.  Does this seem 
  reasonable?
 
  It does.
 
  --
  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: David Jencks [mailto:[EMAIL PROTECTED]
  Sent: Wednesday, April 25, 2007 12:18 PM
  To: open-jpa-dev@incubator.apache.org
  Subject: More questions on runtime schema generation
 
  I'm working on modifications so that ddl can operate in a separate 
  transaction on a connection from the jta ds and I would 
 like to have 
  a complete scan and enhancement as soon as possible when 
 the EMF is 
  first accessed.  I have this working when the classes are listed 
  explicitly in the persistence.xml but not when they aren't.
 
  It looks like the relevant code is AbstractCFMetaDataFactory 
  getPersistentTypeNames
 
   if (names.isEmpty()  devpath)
   scan(new ClasspathMetaDataIterator(null, 
  newMetaDataFilter()),
   newClassArgParser(), names, false, null);
 
 
  However IIUC this dissects the system property java.class.path and 
  only parses stuff on that.  This might be reasonable for a command 
  line tool (although I have some
  doubts) but it seems to me that for any other situation a 
 scan of the 
  provided classloader would be more appropriate.
  Is this reasonable?
 
  Also, I would like to suggest a flag in the
  openjpa.jdbc.SynchronizeMappings=buildSchema(...) stuff to turn on 
  this eager scanning I'm trying to implement.  Does this seem 
  reasonable?
 
  thanks
  david jencks

[jira] Updated: (OPENJPA-229) OpenJPA fails with MappedSuperclasses and Entities with the same short names

2007-04-25 Thread Patrick Linskey (JIRA)


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

Patrick Linskey updated OPENJPA-229:


Attachment: OPENJPA-229.patch

This fixes the problem by changing the enhancer to not register aliases for 
types that are not mapped, as determined by a call to ClassMetaData.isMapped(). 
Thoughts?

 OpenJPA fails with MappedSuperclasses and Entities with the same short names
 

 Key: OPENJPA-229
 URL: https://issues.apache.org/jira/browse/OPENJPA-229
 Project: OpenJPA
  Issue Type: Bug
  Components: kernel
Affects Versions: 0.9.0, 0.9.6, 0.9.7
 Environment: WindowsXP SP2 full updates 2007-04-25, Informix 10, Java 
 1.6.0
Reporter: Patrick Linskey
 Fix For: 0.9.8

 Attachments: OPENJPA-229.patch


 When running the test case from OPENJPA-228 (after a few modifications to get 
 it working), I get the exception included below. If I change the 'Article' 
 mapped superclass to be named 'ArticleBase', things work.
 It looks like this is happening because multiple classes are registering for 
 the same alias. We should change the enhancer to not register aliases for 
 mapped superclasses.
 Exception in thread main 0.0.0 nonfatal user error 
 org.apache.openjpa.persistence.ArgumentException: 0
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:805)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:766)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:762)
   at 
 org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:517)
   at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:230)
   at 
 org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:269)
   at nl.reinders.bm.BMTestOpenJPA.main(BMTestOpenJPA.java:41)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
 Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
   at org.apache.openjpa.jdbc.kernel.exps.PCPath.appendTo(PCPath.java:636)
   at 
 org.apache.openjpa.jdbc.kernel.exps.FilterValueImpl.appendTo(FilterValueImpl.java:62)
   at 
 org.apache.openjpa.jdbc.kernel.exps.FilterValueImpl.appendTo(FilterValueImpl.java:58)
   at 
 org.apache.openjpa.jdbc.sql.DBDictionary.appendCast(DBDictionary.java:2486)
   at 
 org.apache.openjpa.jdbc.sql.DBDictionary.comparison(DBDictionary.java:2443)
   at 
 org.apache.openjpa.jdbc.kernel.exps.CompareExpression.appendTo(CompareExpression.java:75)
   at 
 org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.buildWhere(SelectConstructor.java:238)
   at 
 org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.evaluate(SelectConstructor.java:79)
   at 
 org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.createWhereSelects(JDBCStoreQuery.java:330)
   at 
 org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeQuery(JDBCStoreQuery.java:169)
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:677)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:985)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:796)
   ... 11 more

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

FW: [jira] Updated: (OPENJPA-229) OpenJPA fails with MappedSuperclasses and Entities with the same short names

2007-04-25 Thread Patrick Linskey

Any thoughts about this patch? It changes how @Embeddable and
@MappedSuperclass classes are enhanced.

-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: Patrick Linskey (JIRA) [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, April 25, 2007 2:40 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: [jira] Updated: (OPENJPA-229) OpenJPA fails with 
 MappedSuperclasses and Entities with the same short names
 
 
  [ 
 https://issues.apache.org/jira/browse/OPENJPA-229?page=com.atl
assian.jira.plugin.system.issuetabpanels:all-tabpanel ]
 
 Patrick Linskey updated OPENJPA-229:
 
 
 Attachment: OPENJPA-229.patch
 
 This fixes the problem by changing the enhancer to not 
 register aliases for types that are not mapped, as determined 
 by a call to ClassMetaData.isMapped(). Thoughts?
 
  OpenJPA fails with MappedSuperclasses and Entities with the 
 same short 
  names
  
 --
  --
 
  Key: OPENJPA-229
  URL: 
 https://issues.apache.org/jira/browse/OPENJPA-229
  Project: OpenJPA
   Issue Type: Bug
   Components: kernel
 Affects Versions: 0.9.0, 0.9.6, 0.9.7
  Environment: WindowsXP SP2 full updates 2007-04-25, 
 Informix 10, Java 1.6.0
 Reporter: Patrick Linskey
  Fix For: 0.9.8
 
  Attachments: OPENJPA-229.patch
 
 
  When running the test case from OPENJPA-228 (after a few 
 modifications to get it working), I get the exception 
 included below. If I change the 'Article' mapped superclass 
 to be named 'ArticleBase', things work.
  It looks like this is happening because multiple classes 
 are registering for the same alias. We should change the 
 enhancer to not register aliases for mapped superclasses.
  Exception in thread main 0.0.0 nonfatal user error 
 org.apache.openjpa.persistence.ArgumentException: 0
  at 
 org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:805)
  at 
 org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:766)
  at 
 org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:762)
  at 
 org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQu
 ery.java:517)
  at 
 org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:230)
  at 
 org.apache.openjpa.persistence.QueryImpl.getResultList(QueryIm
 pl.java:269)
  at nl.reinders.bm.BMTestOpenJPA.main(BMTestOpenJPA.java:41)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
 orImpl.java:39)
  at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
 odAccessorImpl.java:25)
  at java.lang.reflect.Method.invoke(Method.java:585)
  at 
  com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
  Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
  at 
 org.apache.openjpa.jdbc.kernel.exps.PCPath.appendTo(PCPath.java:636)
  at 
 org.apache.openjpa.jdbc.kernel.exps.FilterValueImpl.appendTo(F
 ilterValueImpl.java:62)
  at 
 org.apache.openjpa.jdbc.kernel.exps.FilterValueImpl.appendTo(F
 ilterValueImpl.java:58)
  at 
 org.apache.openjpa.jdbc.sql.DBDictionary.appendCast(DBDictiona
 ry.java:2486)
  at 
 org.apache.openjpa.jdbc.sql.DBDictionary.comparison(DBDictiona
 ry.java:2443)
  at 
 org.apache.openjpa.jdbc.kernel.exps.CompareExpression.appendTo
 (CompareExpression.java:75)
  at 
 org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.buildWhe
 re(SelectConstructor.java:238)
  at 
 org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.evaluate
 (SelectConstructor.java:79)
  at 
 org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.createWhereSelec
 ts(JDBCStoreQuery.java:330)
  at 
 org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeQuery(JDB
 CStoreQuery.java:169)
  at 
 org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecut
or.executeQuery(ExpressionStoreQuery.java:677)
  at 
 org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:985)
  at 
 org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:796)
  ... 11 more
 
 --
 This message is automatically generated by JIRA.
 -
 You can reply to this email to add a comment to the issue online.
 
 

Notice:  This email message, together with any attachments, may contain 
information  of  BEA

FW: [jira] Updated: (OPENJPA-226) Change openjpa.DetachState 'fgs' setting to 'fetch-groups'

2007-04-25 Thread Patrick Linskey

Any thoughts about this patch? It changes a configuration API, making
'fgs' a deprecated option.

-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: Patrick Linskey (JIRA) [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, April 24, 2007 7:26 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: [jira] Updated: (OPENJPA-226) Change 
 openjpa.DetachState 'fgs' setting to 'fetch-groups'
 
 
  [ 
 https://issues.apache.org/jira/browse/OPENJPA-226?page=com.atl
assian.jira.plugin.system.issuetabpanels:all-tabpanel ]
 
 Patrick Linskey updated OPENJPA-226:
 
 
 Attachment: OPENJPA-226.patch
 
 Here's a patch that does this. Thoughts?
 
  Change openjpa.DetachState 'fgs' setting to 'fetch-groups'
  --
 
  Key: OPENJPA-226
  URL: 
 https://issues.apache.org/jira/browse/OPENJPA-226
  Project: OpenJPA
   Issue Type: Improvement
   Components: docs, kernel
 Affects Versions: 0.9.0, 0.9.6, 0.9.7
 Reporter: Patrick Linskey
  Assigned To: Patrick Linskey
 Priority: Minor
  Fix For: 0.9.8
 
  Attachments: OPENJPA-226.patch
 
 
  The configuration setting openjpa.DetachState: fgs is a 
 bit obtuse. It would be nicer if this were 
 openjpa.DetachState: fetch-groups.
 
 --
 This message is automatically generated by JIRA.
 -
 You can reply to this email to add a comment to the issue online.
 
 

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: Possible problem with ddl with only a jta-datasource and sequences

2007-04-25 Thread Patrick Linskey

 If everyone has extra functionality why is it so hard to 
 come to a common set of features? There's no intrinsic value 
 in one app server giving access via Proprietary Interface 1 
 and another app server giving the same access via Proprietary 
 Interface 2.

I think that the issue at the time was that some people were unwilling
to expose begin / commit / rollback / suspend / resume APIs, but sadly
nobody (on either side of the debate) realized that a compromise
executeRunnableInNewTransaction(Runnable) would be acceptible all
around.

-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: Wednesday, April 25, 2007 3:48 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: Possible problem with ddl with only a 
 jta-datasource and sequences
 
 Hi Partick,
 
 On Apr 25, 2007, at 11:41 AM, Patrick Linskey wrote:
 
  That's why we have two datasources for an EMF. One is the 
  transactional datasource that gives you connections automatically 
  enlisted in your transactional EM; the other gives you connections 
  that are never enlisted and can be used for 
 nontransactional queries, 
  nontransactional sequences etc.
  The TSR is only of use for the enlisted datasource/connection.
 
  That's one approach for out-of-band work. But, there are 
 other ways to 
  do such work also, without requiring multiple datasources. For 
  example, suspending the current tx, starting a new one, doing the 
  work, committing, and resuming the old one is a workable 
 solution, if 
  you have access to the tx.
 
 My comment was that the two-datasource approach works for all 
 configurations that I know of, and doesn't depend on the 
 existence of mutliple non-standardized interfaces by which 
 the transaction service providers have granted grudging 
 access to their transaction control mechanism.
 
 There was agreement with TSR on the basic functionality that 
 all transaction service providers would support. Some vendors 
 pushed back when we tried to expand the functionality.
 
 If everyone has extra functionality why is it so hard to 
 come to a common set of features? There's no intrinsic value 
 in one app server giving access via Proprietary Interface 1 
 and another app server giving the same access via Proprietary 
 Interface 2.
 
 What we were able to get with TSR interface was agreement as 
 to how to deal with transaction-enlisted connections. Perhaps 
 we need to go back (Umbrella JSR for Java EE 6) and make a 
 bigger fuss over the additional needed functionality.
 
 Craig
 
  -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: Wednesday, April 25, 2007 10:05 AM
  To: open-jpa-dev@incubator.apache.org
  Subject: Re: Possible problem with ddl with only a
  jta-datasource and sequences
 
 
  On Apr 24, 2007, at 11:38 AM, Marc Prud'hommeaux wrote:
 
  David-
 
  Does this seem like a reasonable explanation?
 
  That sounds right to me.
 
  Note that if we ever update OpenJPA to depend solely on the
  TransactionSynchronizationRegistry, then we won't be able
  to do things
  like suspending the transactions and resuming it later with the
  jta-datasource.
 
  That's why we have two datasources for an EMF. One is the
  transactional datasource that gives you connections
  automatically enlisted in your transactional EM; the other
  gives you connections that are never enlisted and can be used
  for nontransactional queries, nontransactional sequences etc.
  The TSR is only of use for the enlisted datasource/connection.
 
  Craig
 
 
  On Apr 24, 2007, at 10:52 AM, David Jencks wrote:
 
  Using derby, jta transactions (in geronimo), a table sequence,
  autocreation of tables, and only a jta-datasource, I get errors
  complaining that the sequence

RE: More questions on runtime schema generation

2007-04-25 Thread Patrick Linskey

Inside an appserver, there are parts of the PersistenceUnitInfo
interface that are designed for the appserver to communicate jars to
scan to the persistence provider.

-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: Wednesday, April 25, 2007 3:55 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: More questions on runtime schema generation
 
 The general solution to this problem lies in a crisper 
 definition of classloader domains in the app server. IIUC, 
 each app server has its own policies in terms of where 
 various components get loaded and when.
 
 I think we need to engage the server spec team on this, 
 otherwise we will end up chasing multiple incompatible class 
 loader strategies, all of which turn out to be spec compliant.
 
 And for a first cut at reasonable we might ask the Spring 
 folks how they handle this.
 
 Craig
 
 On Apr 25, 2007, at 12:26 PM, Patrick Linskey wrote:
 
  However IIUC this dissects the system property java.class.path and 
  only parses stuff on that.  This might be reasonable for a command 
  line tool (although I have some
  doubts) but it seems to me that for any other situation a 
 scan of the 
  provided classloader would be more appropriate.
  Is this reasonable?
 
  It is. Of course, there is no standard way to scan 
 classloaders. The 
  best I know of is to do:
 
  cls.getProtectionDomain().getCodeSource().getLocation()
 
  and then scan from that URL.
 
  Of course, this assumes that a) you have a class (not a 
 ClassLoader), 
  b) you have security privileges to get the protection 
 domain, and b) 
  the location is parsable and accessible.
 
  Is there some other way that you know of to scan a ClassLoader?
 
  Also, I would like to suggest a flag in the
  openjpa.jdbc.SynchronizeMappings=buildSchema(...) stuff to turn on 
  this eager scanning I'm trying to implement.  Does this seem 
  reasonable?
 
  It does.
 
  --
  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: David Jencks [mailto:[EMAIL PROTECTED]
  Sent: Wednesday, April 25, 2007 12:18 PM
  To: open-jpa-dev@incubator.apache.org
  Subject: More questions on runtime schema generation
 
  I'm working on modifications so that ddl can operate in a separate 
  transaction on a connection from the jta ds and I would 
 like to have 
  a complete scan and enhancement as soon as possible when 
 the EMF is 
  first accessed.  I have this working when the classes are listed 
  explicitly in the persistence.xml but not when they aren't.
 
  It looks like the relevant code is AbstractCFMetaDataFactory 
  getPersistentTypeNames
 
   if (names.isEmpty()  devpath)
   scan(new ClasspathMetaDataIterator(null, 
  newMetaDataFilter()),
   newClassArgParser(), names, false, null);
 
 
  However IIUC this dissects the system property java.class.path and 
  only parses stuff on that.  This might be reasonable for a command 
  line tool (although I have some
  doubts) but it seems to me that for any other situation a 
 scan of the 
  provided classloader would be more appropriate.
  Is this reasonable?
 
  Also, I would like to suggest a flag in the
  openjpa.jdbc.SynchronizeMappings=buildSchema(...) stuff to turn on 
  this eager scanning I'm trying to implement.  Does this seem 
  reasonable?
 
  thanks
  david jencks
 
 
 
 
  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

[jira] Commented: (OPENJPA-219) Reflection: negative caching would be beneficial in redeployment scenarios

2007-04-24 Thread Patrick Linskey (JIRA)


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

Patrick Linskey commented on OPENJPA-219:
-

 another way to approach this would be not to cache at all,
 and just iterate over getDeclaredFields/Methods() looking for a match

Good point. That would certainly be a better approach. It looks like 
Class.getDeclaredFields() will be a bit slower, since more memory copying 
happens (the array is copied before being returned -- bummer that those APIs 
don't use collections), but that might not be noticeable in the benchmark.

 Reflection: negative caching would be beneficial in redeployment scenarios
 --

 Key: OPENJPA-219
 URL: https://issues.apache.org/jira/browse/OPENJPA-219
 Project: OpenJPA
  Issue Type: Bug
  Components: kernel
Affects Versions: 0.9.0, 0.9.6, 0.9.7
Reporter: Patrick Linskey
 Fix For: 0.9.8

 Attachments: OPENJPA-219.patch


 In a variety of situations, OpenJPA searches class hierarchies for fields. 
 These searches invoke Class.getDeclaredField() in order to find non-public 
 fields. This method throws an exception when it fails to find the specified 
 field, and the exception creation is, as ever, slow.
 It would be useful to create a static (and thus per-classloader) 
 MapWeakReferenceClass,CollectionString of fields known not to be 
 available in a given class.
 It may also be beneficial to maintain a cache of which fields *are* present 
 in a given class, but this issue is being filed as a result of a demonstrated 
 performance hit during deployment due to the lack of a negative cache. If we 
 obtain quantitative data indicating that a positive cache would be useful, we 
 might want to implement such a thing at that time.
 Trace 3 (2115 occurances): [excepti][00090] java/lang/NoSuchFieldException: 
 domainName
  at 
 java/lang/Class.getDeclaredField(Ljava/lang/String;I)Ljava/lang/reflect/Field;(Unknown
  Source)
  at 
 org/apache/openjpa/enhance/Reflection.findField(Ljava/lang/Class;Ljava/lang/String;Z)Ljava/lang/reflect/Field;(Reflection.java:101)
  at 
 org/apache/openjpa/util/ApplicationIds.toPKValues(Ljava/lang/Object;Lorg/apache/openjpa/meta/ClassMetaData;)[Ljava/lang/Object;
 (ApplicationIds.java:89)

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

RE: Open JPA error-Could not locate metadata for the class using alias

2007-04-24 Thread Patrick Linskey

Note that in OpenJPA, you could fully specify all your relations as
relations between the abstrat entity classes or mapped superclasses (so
AbstractPerson would have a reference to AbstractAddress, etc.) and then
narrow the types of the relations in the subclasses. This would allow
you to create something where your reverse-engineered classes fully
compiled on their own, and also would result in an efficient schema with
direct relations between the concrete subtypes.

-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: tbee [mailto:[EMAIL PROTECTED] 
 Sent: Friday, April 20, 2007 10:20 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: Open JPA error-Could not locate metadata for the 
 class using alias
 
 
 
 
 Marina Vatkina wrote:
  
  The spec defines the following limitations of a MappedSuperclass:
  
  2.1.9.2 Mapped Superclasses
  ...
  A mapped superclass, unlike an entity, is not queryable and 
 cannot be 
  passed as an argument to EntityManager or Query operations. 
 A mapped 
  superclass cannot be the target of a persistent relationship.
  
  
 
 Correct. It is not. All relations refer to the inheriting 
 classes. So even if the relation is defined in the 
 @MappedSuperclass, the result of the relation are the actual @Entity.
 
 I believe this approach is invaluable if you want to save 
 coding time: my reverse engineering class generates a JPA 
 MappedSuperclass based on the database and the actual Entity 
 class only contains the JPA table annotation and all business logic.
 
 Hibernate also has some trouble with this concept, but 
 Toplink works fine. I have an issue with lazy loading there, 
 but the approach is perfect.
 
 --
 View this message in context: 
 http://www.nabble.com/Open-JPA-error-Could-not-locate-metadata
 -for-the-class-using-alias-tf3561516.html#a10106645
 Sent from the open-jpa-dev mailing list archive at Nabble.com.
 
 

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: ClassTransformerOptions in persistence.xml properties?

2007-04-24 Thread Patrick Linskey

 Seems to me that something is wrong here.  Maybe the code in 
 PersistenceProviderImpl should be removing the property?  
 Maybe the ConfigurationProvider should know about the 
 property?  Maybe this is actually not something that should 
 be settable in persistence.xml?

#2. Thanks for pointing this out.

-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: David Jencks [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, April 24, 2007 10:21 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: ClassTransformerOptions in persistence.xml properties?
 
 After a lot of research I found that its possible to get 
 something like this into the persistence unit info properties
 
  openjpa.ClassTransformerOptions=ScanDevPath=true
 
 (expresses as part of a properties file rather than the 
 equivalent xml from persistence.xml)
 
 and that results in devScan == true in a bunch of method 
 calls in class transforming.  There's some code in 
 PersistenceProviderImpl that explicitly looks for this:
 
  String ctOpts = (String) Configurations.getProperty
  (CLASS_TRANSFORMER_OPTIONS, 
 pui.getProperties()); (lines 94-95)
 
 leading me to believe that this might be a reasonable thing 
 to try to do.
 
 However,  I get a lot of messages:
 
 08:43:22,636 WARN  [Runtime] The property named 
 openjpa.ClassTransformerOptions was not recognized and will 
 be ignored, although the name closely matches a valid 
 property called openjpa.ClassResolver.
 
 Seems to me that something is wrong here.  Maybe the code in 
 PersistenceProviderImpl should be removing the property?  
 Maybe the ConfigurationProvider should know about the 
 property?  Maybe this is actually not something that should 
 be settable in persistence.xml?
 
 thanks
 david jencks
 

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-219) Reflection: negative caching would be beneficial in redeployment scenarios

2007-04-24 Thread Patrick Linskey (JIRA)


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

Patrick Linskey reassigned OPENJPA-219:
---

Assignee: Patrick Linskey

 Reflection: negative caching would be beneficial in redeployment scenarios
 --

 Key: OPENJPA-219
 URL: https://issues.apache.org/jira/browse/OPENJPA-219
 Project: OpenJPA
  Issue Type: Bug
  Components: kernel
Affects Versions: 0.9.0, 0.9.6, 0.9.7
Reporter: Patrick Linskey
 Assigned To: Patrick Linskey
 Fix For: 0.9.8

 Attachments: OPENJPA-219-NoLeak.patch, OPENJPA-219.patch


 In a variety of situations, OpenJPA searches class hierarchies for fields. 
 These searches invoke Class.getDeclaredField() in order to find non-public 
 fields. This method throws an exception when it fails to find the specified 
 field, and the exception creation is, as ever, slow.
 It would be useful to create a static (and thus per-classloader) 
 MapWeakReferenceClass,CollectionString of fields known not to be 
 available in a given class.
 It may also be beneficial to maintain a cache of which fields *are* present 
 in a given class, but this issue is being filed as a result of a demonstrated 
 performance hit during deployment due to the lack of a negative cache. If we 
 obtain quantitative data indicating that a positive cache would be useful, we 
 might want to implement such a thing at that time.
 Trace 3 (2115 occurances): [excepti][00090] java/lang/NoSuchFieldException: 
 domainName
  at 
 java/lang/Class.getDeclaredField(Ljava/lang/String;I)Ljava/lang/reflect/Field;(Unknown
  Source)
  at 
 org/apache/openjpa/enhance/Reflection.findField(Ljava/lang/Class;Ljava/lang/String;Z)Ljava/lang/reflect/Field;(Reflection.java:101)
  at 
 org/apache/openjpa/util/ApplicationIds.toPKValues(Ljava/lang/Object;Lorg/apache/openjpa/meta/ClassMetaData;)[Ljava/lang/Object;
 (ApplicationIds.java:89)

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

[jira] Commented: (OPENJPA-219) Reflection: negative caching would be beneficial in redeployment scenarios

2007-04-24 Thread Patrick Linskey (JIRA)


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

Patrick Linskey commented on OPENJPA-219:
-

How does this compare to the leaky-patch version?

 Reflection: negative caching would be beneficial in redeployment scenarios
 --

 Key: OPENJPA-219
 URL: https://issues.apache.org/jira/browse/OPENJPA-219
 Project: OpenJPA
  Issue Type: Bug
  Components: kernel
Affects Versions: 0.9.0, 0.9.6, 0.9.7
Reporter: Patrick Linskey
 Fix For: 0.9.8

 Attachments: OPENJPA-219-NoLeak.patch, OPENJPA-219.patch


 In a variety of situations, OpenJPA searches class hierarchies for fields. 
 These searches invoke Class.getDeclaredField() in order to find non-public 
 fields. This method throws an exception when it fails to find the specified 
 field, and the exception creation is, as ever, slow.
 It would be useful to create a static (and thus per-classloader) 
 MapWeakReferenceClass,CollectionString of fields known not to be 
 available in a given class.
 It may also be beneficial to maintain a cache of which fields *are* present 
 in a given class, but this issue is being filed as a result of a demonstrated 
 performance hit during deployment due to the lack of a negative cache. If we 
 obtain quantitative data indicating that a positive cache would be useful, we 
 might want to implement such a thing at that time.
 Trace 3 (2115 occurances): [excepti][00090] java/lang/NoSuchFieldException: 
 domainName
  at 
 java/lang/Class.getDeclaredField(Ljava/lang/String;I)Ljava/lang/reflect/Field;(Unknown
  Source)
  at 
 org/apache/openjpa/enhance/Reflection.findField(Ljava/lang/Class;Ljava/lang/String;Z)Ljava/lang/reflect/Field;(Reflection.java:101)
  at 
 org/apache/openjpa/util/ApplicationIds.toPKValues(Ljava/lang/Object;Lorg/apache/openjpa/meta/ClassMetaData;)[Ljava/lang/Object;
 (ApplicationIds.java:89)

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

RE: Possible problem with ddl with only a jta-datasource and sequences

2007-04-24 Thread Patrick Linskey

 suspend/resume) and it has recently provided the means to 
 execute a Runnable in a new Tx (via the runUnderUOW feature)

Yay!

It should be very easy to restructure our existing code to move the
relevant logic to a Runnable.

-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: Kevin Sutter [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, April 24, 2007 2:18 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: Possible problem with ddl with only a 
 jta-datasource and sequences
 
 Patrick,
 
 On 4/24/07, Patrick Linskey [EMAIL PROTECTED] wrote:
 
   One way to do this would
   be to package the work up in a Runnable and execute it in an 
   appropriate transactional environment.  It might be easier to 
   understand if the sequence code had a similar implementation.
 
  We talked about this in a thread several months ago. I 
 think that the 
  conclusion was that it'd be neat to make our ManagedRuntime 
 interface 
  have a runInNewTransaction(Runnable) method, and to move 
 things to use 
  that instead of doing tx logic directly inside the sequence classes.
  This would be an easy change; the lack of a concrete need (i.e., a 
  server that both denied transactional control and provided 
 a means to 
  execute a Runnable in a new tx) prevented us from changing things 
  around.
 
 
 A concrete need is surfacing with WebSphere.  WebSphere 
 does not allow for direct transactional control (ie. 
 suspend/resume) and it has recently provided the means to 
 execute a Runnable in a new Tx (via the runUnderUOW
 feature).  Although WebSphere may be the exception to the 
 rule, we are planning on providing the mechanism so that 
 OpenJPA can play in this game.
 
 Kevin
 
 -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: David Jencks [mailto:[EMAIL PROTECTED]
   Sent: Tuesday, April 24, 2007 10:53 AM
   To: open-jpa-dev@incubator.apache.org
   Subject: Possible problem with ddl with only a jta-datasource and 
   sequences
  
   Using derby, jta transactions (in geronimo), a table sequence, 
   autocreation of tables, and only a jta-datasource, I get errors 
   complaining that the sequence table doesn't exist.
  
   Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException:
   Table/ View 'OPENJPASEQ' does not exist. {SELECT 
 SEQUENCE_VALUE FROM 
   OPENJPASEQ WHERE ID = ? FOR UPDATE WITH RR} [code=2, 
   state=42X05]
  
   If I supply a non-jta-datasource everything works fine.
  
   My current theory about why this is happening is that the ddl to 
   create all the tables is executed in a connection from the
   jta- datasource that's enrolled in a jta transaction.  
 Then we go to 
   get an id from the sequence, the jta transaction is 
 suspended, and a 
   new tx is started, in which the ddl is not visible since 
 the jta tx 
   wasn't committed. (apparently ddl in derby is transactional)
  
   Does this seem like a reasonable explanation?
  
   I'm going to look for a way to run the ddl inside a separate 
   transaction that can be committed, the same as how sequences work 
   without a non-jta-datasource.  One way to do this would be to 
   package the work up in a Runnable and execute it in an 
 appropriate 
   transactional environment.  It might be easier to 
 understand if the 
   sequence code had a similar implementation.
  
   thanks
   david jencks
  
  
 
  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

RE: Possible problem with ddl with only a jta-datasource and sequences

2007-04-24 Thread Patrick Linskey

 Can you ask the websphere team to support a Callable also, so 
 we can easily return a value or throw an exception from the 
 task?

Seems like for WAS's needs, just supporting Callable would be good
enough, no?

We need to use Runnable at the end of the day in ManagedRuntime, so that
things compile on 1.4.

-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: Dain Sundstrom [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, April 24, 2007 3:29 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: Possible problem with ddl with only a 
 jta-datasource and sequences
 
 On Apr 24, 2007, at 2:17 PM, Kevin Sutter wrote:
 
  Patrick,
 
  On 4/24/07, Patrick Linskey [EMAIL PROTECTED] wrote:
 
   One way to do this would
   be to package the work up in a Runnable and execute it in an 
   appropriate transactional environment.  It might be easier to 
   understand if the sequence code had a similar implementation.
 
  We talked about this in a thread several months ago. I 
 think that the 
  conclusion was that it'd be neat to make our 
 ManagedRuntime interface 
  have a runInNewTransaction(Runnable) method, and to move things to 
  use that instead of doing tx logic directly inside the sequence 
  classes.
  This would be an easy change; the lack of a concrete need (i.e., a 
  server that both denied transactional control and provided 
 a means to 
  execute a Runnable in a new tx) prevented us from changing things 
  around.
 
 
  A concrete need is surfacing with WebSphere.  WebSphere does not 
  allow for direct transactional control (ie. suspend/resume) 
 and it has 
  recently provided the means to execute a Runnable in a new 
 Tx (via the 
  runUnderUOW
  feature).  Although WebSphere may be the exception to the 
 rule, we are 
  planning on providing the mechanism so that OpenJPA can 
 play in this 
  game.
 
 Kevan,
 
 Can you ask the websphere team to support a Callable also, so 
 we can easily return a value or throw an exception from the 
 task?  It may also be important to runWithoutTx for databases 
 that don't support transactional DDL, but I suppose that 
 could be done with a new thread.
 
 -dain
 

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] Created: (OPENJPA-226) Change openjpa.DetachState 'fgs' setting to 'fetch-groups'

2007-04-24 Thread Patrick Linskey (JIRA)

Change openjpa.DetachState 'fgs' setting to 'fetch-groups'
--

 Key: OPENJPA-226
 URL: https://issues.apache.org/jira/browse/OPENJPA-226
 Project: OpenJPA
  Issue Type: Improvement
  Components: docs, kernel
Affects Versions: 0.9.6, 0.9.0, 0.9.7
Reporter: Patrick Linskey
 Assigned To: Patrick Linskey
Priority: Minor
 Fix For: 0.9.8


The configuration setting openjpa.DetachState: fgs is a bit obtuse. It would 
be nicer if this were openjpa.DetachState: fetch-groups.

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

RE: Set query params without TX?

2007-04-24 Thread Patrick Linskey

Why are you calling close() during createNamedQuery()?

Turns out that you need to do more work to ensure that the query doesn't
get closed until after it's been executed. This basically means that you
need to have a proxy EM that creates Query instances that have
references to the underlying active EM.

Alternately, I think that you can rely on OpenJPA's detach modes to do
this for you; instead of actually closing the EM, just tell OpenJPA to
handle detaching when outside a tx.

-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: Dain Sundstrom [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, April 24, 2007 7:03 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: Set query params without TX?
 
 java.lang.IllegalStateException
   at 
 org.apache.openjpa.kernel.BrokerImpl.free(BrokerImpl.java:4083)
   at 
 org.apache.openjpa.kernel.BrokerImpl.close(BrokerImpl.java:4013)
   at org.apache.openjpa.kernel.DelegatingBroker.close
 (DelegatingBroker.java:1284)
   at org.apache.openjpa.persistence.EntityManagerImpl.close
 (EntityManagerImpl.java:999)
   at org.apache.openejb.persistence.JtaEntityManager.closeIfNoTx
 (JtaEntityManager.java:87)
   at 
 org.apache.openejb.persistence.JtaEntityManager.createNamedQuery
 (JtaEntityManager.java:189)
   at org.apache.openejb.core.cmp.jpa.JpaCmpEngine.createNamedQuery
 (JpaCmpEngine.java:287)
   at org.apache.openejb.core.cmp.jpa.JpaCmpEngine.queryBeans
 (JpaCmpEngine.java:218)
   at org.apache.openejb.core.cmp.CmpContainer.findEJBObject
 (CmpContainer.java:718)
   at 
 org.apache.openejb.core.cmp.CmpContainer.invoke(CmpContainer.java: 
 286)
 
 -dain
 
 On Apr 24, 2007, at 3:07 PM, Marc Prud'hommeaux wrote:
 
  Dain-
 
  Can you send the embedded exception as well? That should 
 tell us who 
  closed the query, and it might give us a hint why...
 
 
  On Apr 24, 2007, at 3:03 PM, Dain Sundstrom wrote:
 
  I have some code that runs outside of a transaction which does 
  basically the following:
 
  Query query = entityManager.createNamedQuery(name)
  query.setParameter(1, foo);
  List results = query.getResultList();
 
  If I don't set the parameter the code works fine (assuming 
 the query 
  didn't need a parameter), but when I set the parameter, I get the 
  following exception:
 
  Caused by: 0.9.7-incubating-SNAPSHOT fatal user error
  org.apache.openjpa.persistence.InvalidStateException: The 
 context has 
  been closed.  The stack trace at which the context was 
 closed is held 
  in the embedded exception.
  FailedObject: java.lang.IllegalStateException
 at org.apache.openjpa.kernel.BrokerImpl.assertOpen
  (BrokerImpl.java:4283)
 at 
 org.apache.openjpa.kernel.QueryImpl.assertOpen(QueryImpl.java: 
  1613)
 at org.apache.openjpa.kernel.DelegatingQuery.assertOpen
  (DelegatingQuery.java:626)
 at org.apache.openjpa.persistence.QueryImpl.setParameter
  (QueryImpl.java:404)
 at org.apache.openjpa.persistence.QueryImpl.setParameter
  (QueryImpl.java:49)
 at org.apache.openejb.core.cmp.jpa.JpaCmpEngine.executeQuery
  (JpaCmpEngine.java:261)
 
  Is this supposed to work?  If not, maybe we should throw the 
  exception when getting the query.
 
  In the mean time I'll code around this.
 
  -dain
 
 
 

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] Updated: (OPENJPA-226) Change openjpa.DetachState 'fgs' setting to 'fetch-groups'

2007-04-24 Thread Patrick Linskey (JIRA)


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

Patrick Linskey updated OPENJPA-226:


Attachment: OPENJPA-226.patch

Here's a patch that does this. Thoughts?

 Change openjpa.DetachState 'fgs' setting to 'fetch-groups'
 --

 Key: OPENJPA-226
 URL: https://issues.apache.org/jira/browse/OPENJPA-226
 Project: OpenJPA
  Issue Type: Improvement
  Components: docs, kernel
Affects Versions: 0.9.0, 0.9.6, 0.9.7
Reporter: Patrick Linskey
 Assigned To: Patrick Linskey
Priority: Minor
 Fix For: 0.9.8

 Attachments: OPENJPA-226.patch


 The configuration setting openjpa.DetachState: fgs is a bit obtuse. It 
 would be nicer if this were openjpa.DetachState: fetch-groups.

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

RE: Artifact names

2007-04-24 Thread Patrick Linskey

Hmm. I wonder if we're really using Maven repositories correctly. Do we
need our dist to be in Maven at all?

I do think that we should have something that's easy to depend on that
pulls in the openjpa-persistence-jdbc module, without making people have
to know about that level of modularity detail.

-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: Eddie O'Neil [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, April 24, 2007 7:05 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: Artifact names
 
 
   +1 -- I'd prefer to have the binary / source uber-archives 
 outside of the Maven repro, though that's more due to 
 convention than anything else.
 
   I agree that it's not worth worrying about this for 0.9.7.
 
 Cheers,
 Eddie
 
 
 On 4/24/07, Michael Dick [EMAIL PROTECTED] wrote:
  I'm finally getting back to this thread, sorry for the delay.
 
  I got a similar answer from the maven mailing list. Their stance is 
  that the maven repository is for artifacts which are used by maven, 
  which wouldn't be the same as a final destination for our 
 distribution.
 
  I'm in favor of moving the source and binary archives to a 
 different 
  location, if there's a good spot available to us.  Does 
 anyone object 
  to putting the releases somewhere outside of a maven repository?
 
  I don't think this is urgent for the 0.9.7 release since we 
 can't get 
  rid of the ugly -project names now, but it might be nice to have a 
  solution for when OpenJPA graduates.
 
  On 4/12/07, Dain Sundstrom [EMAIL PROTECTED] wrote:
  
   In Geronimo, we publish to the maven repo as maven likes, 
 but when 
   we publish to the apache distribution mirrors (for website 
   downloads), we name the files as we like.
  
   -dain
  
   On Apr 11, 2007, at 8:34 AM, Michael Dick wrote:
  
Hi,
   
I'm hitting a bit of a snag with the staging repository for 
release 0.9.7.
Recently we made changes to remove -project from our 
 the zip file 
names. The problem is that the maven install and deploy goals 
ignore the names we provide and generate their own names ( 
openjpa-project-0.9.7-incubating-xxx.zip).
   
I searched through the [EMAIL PROTECTED] mailing list 
archives and it turns out this is a fairly common problem - 
usually resulting in a response of working as 
 designed.  Here's 
an example
http://www.nabble.com/Installation-and-deployment-
tf1449780s177.html#a3916784
   
Does anyone vehemently object to putting -project back into the 
names for the 0.9.7 release?
   
The only other way I know of to fix the names that get deployed 
would be to change the artifactId in the pom files (basically 
switch openjpa with openjpa-project). Switching the names will 
impact anyone who has a dependency on the base openjpa project. 
They'll have to update the version number anyway, but it will 
still be a little confusing if they used to depend on 
openjpa-0.9.6 and now they depend on openjpa-project-0.9.7.
   
Thanks,
   
--
-Michael Dick
  
  
 
 
  --
  -Michael Dick
 
 

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: Artifact names

2007-04-24 Thread Patrick Linskey

  I do think that we should have something that's easy to 
 depend on that 
  pulls in the openjpa-persistence-jdbc module, without making people 
  have to know about that level of modularity detail.
 
 Why can't they just depend on openjpa-all? That brings 
 everything in...

It's just a bit odd to have the '-all' bit in there. Is it possible to
make the top-level pom publish the same stuff that openjpa-all currently
does?

-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: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On 
 Behalf Of Marc Prud'hommeaux
 Sent: Tuesday, April 24, 2007 7:37 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: Artifact names
 
 
 On Apr 24, 2007, at 7:27 PM, Patrick Linskey wrote:
 
  Hmm. I wonder if we're really using Maven repositories correctly.  
  Do we
  need our dist to be in Maven at all?
 
 We don't need to. It was just easy to set up that way.
 
 
  I do think that we should have something that's easy to 
 depend on that 
  pulls in the openjpa-persistence-jdbc module, without making people 
  have to know about that level of modularity detail.
 
 Why can't they just depend on openjpa-all? That brings 
 everything in...
 
 
 
  -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: Eddie O'Neil [mailto:[EMAIL PROTECTED]
  Sent: Tuesday, April 24, 2007 7:05 PM
  To: open-jpa-dev@incubator.apache.org
  Subject: Re: Artifact names
 
 
+1 -- I'd prefer to have the binary / source 
 uber-archives outside 
  of the Maven repro, though that's more due to convention than 
  anything else.
 
I agree that it's not worth worrying about this for 0.9.7.
 
  Cheers,
  Eddie
 
 
  On 4/24/07, Michael Dick [EMAIL PROTECTED] wrote:
  I'm finally getting back to this thread, sorry for the delay.
 
  I got a similar answer from the maven mailing list. Their 
 stance is 
  that the maven repository is for artifacts which are used 
 by maven, 
  which wouldn't be the same as a final destination for our
  distribution.
 
  I'm in favor of moving the source and binary archives to a
  different
  location, if there's a good spot available to us.  Does
  anyone object
  to putting the releases somewhere outside of a maven repository?
 
  I don't think this is urgent for the 0.9.7 release since we
  can't get
  rid of the ugly -project names now, but it might be nice 
 to have a 
  solution for when OpenJPA graduates.
 
  On 4/12/07, Dain Sundstrom [EMAIL PROTECTED] wrote:
 
  In Geronimo, we publish to the maven repo as maven likes,
  but when
  we publish to the apache distribution mirrors (for website 
  downloads), we name the files as we like.
 
  -dain
 
  On Apr 11, 2007, at 8:34 AM, Michael Dick wrote:
 
  Hi,
 
  I'm hitting a bit of a snag with the staging repository for 
  release 0.9.7.
  Recently we made changes to remove -project from our
  the zip file
  names. The problem is that the maven install and deploy goals 
  ignore the names we provide and generate their own names ( 
  openjpa-project-0.9.7-incubating-xxx.zip).
 
  I searched through the [EMAIL PROTECTED] mailing list 
  archives and it turns out this is a fairly common problem - 
  usually resulting in a response of working as
  designed.  Here's
  an example
  http://www.nabble.com/Installation-and-deployment-
  tf1449780s177.html#a3916784
 
  Does anyone vehemently object to putting -project back into the 
  names for the 0.9.7 release?
 
  The only other way I know of to fix the names that get deployed 
  would be to change the artifactId in the pom files (basically 
  switch openjpa with openjpa-project). Switching the names will 
  impact anyone who has a dependency on the base openjpa project.
  They'll have to update the version number anyway, but it will 
  still be a little confusing if they used to depend on
  openjpa-0.9.6 and now

RE: Set query params without TX?

2007-04-24 Thread Patrick Linskey

Yep -- you've gotta keep it open. If you want to support any JPA impl,
you need to have an EM proxy (please please please make it a dynamic
proxy that implements all the interfaces that the proxied thing
implements).

If you're happy tying yourself to OpenJPA (or if you want to optimize
for OpenJPA), then you can use the openjpa.AutoDetach property to tell
OpenJPA how to handle non-transactional work. In that scenario, you can
keep a single EM per your delegating instance, and rely on OpenJPA to do
the transactional PC semantics.

-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: Dain Sundstrom [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, April 24, 2007 9:56 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: Set query params without TX?
 
 Man, I'm dumb.
 
 This code is the EntityManager wrapper for the Container 
 managed EMs (which I wrote so long ago don't remember it).  
 So how is this supposed to work in our container managed EM?  
 The method looks like
 this:
 
  public Query createNamedQuery(String name) {
  EntityManager entityManager = getEntityManager();
  try {
  return entityManager.createNamedQuery(name);
  } finally {
  closeIfNoTx(entityManager);
  }
  }
 
 So if there is no tx are we supposed to leave the 
 EntityManager open?  I'm confused because it seems like I'm 
 supposed to close the em, but if I do the I can't set 
 parameters on the query.
 
 -dain
 
 On Apr 24, 2007, at 7:31 PM, Patrick Linskey wrote:
 
   at org.apache.openjpa.persistence.EntityManagerImpl.close
  (EntityManagerImpl.java:999)
 
  3) OpenJPA calls em.close since there is no transaction, which I 
  think closes the query
 
   at org.apache.openejb.persistence.JtaEntityManager.closeIfNoTx
  (JtaEntityManager.java:87)
 
  2) OpenJPA calls closeIfNoTx
 
   at
  org.apache.openejb.persistence.JtaEntityManager.createNamedQuery
  (JtaEntityManager.java:189)
 
  1) OpenEJB calls createNamedQuery
 
   at org.apache.openejb.core.cmp.jpa.JpaCmpEngine.createNamedQuery
  (JpaCmpEngine.java:287)
 
  JtaEntityManager is one of your classes, not one of ours.  
  closeIfNoTx is
  your method, not ours. Punk.
 
  -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: Dain Sundstrom [mailto:[EMAIL PROTECTED]
  Sent: Tuesday, April 24, 2007 7:29 PM
  To: open-jpa-dev@incubator.apache.org
  Subject: Re: Set query params without TX?
 
  I am they, the one writing the cmp code in OpenEJB.
 
  On first read of the stack trace I thought as you that, I 
 was the one 
  close the entity manager, but on a second read I notice it was 
  OpenJPA calling closeIfNoTx that closes the broker.
 
  On Apr 24, 2007, at 7:02 PM, Dain Sundstrom wrote:
 
  java.lang.IllegalStateException
   at
  org.apache.openjpa.kernel.BrokerImpl.free(BrokerImpl.java:4083)
   at
  org.apache.openjpa.kernel.BrokerImpl.close(BrokerImpl.java:4013)
   at org.apache.openjpa.kernel.DelegatingBroker.close
  (DelegatingBroker.java:1284)
   at org.apache.openjpa.persistence.EntityManagerImpl.close
  (EntityManagerImpl.java:999)
 
  3) OpenJPA calls em.close since there is no transaction, which I 
  think closes the query
 
   at org.apache.openejb.persistence.JtaEntityManager.closeIfNoTx
  (JtaEntityManager.java:87)
 
  2) OpenJPA calls closeIfNoTx
 
   at
  org.apache.openejb.persistence.JtaEntityManager.createNamedQuery
  (JtaEntityManager.java:189)
 
  1) OpenEJB calls createNamedQuery
 
   at org.apache.openejb.core.cmp.jpa.JpaCmpEngine.createNamedQuery
  (JpaCmpEngine.java:287)
   at org.apache.openejb.core.cmp.jpa.JpaCmpEngine.queryBeans
  (JpaCmpEngine.java:218)
   at org.apache.openejb.core.cmp.CmpContainer.findEJBObject
  (CmpContainer.java:718)
   at org.apache.openejb.core.cmp.CmpContainer.invoke
  (CmpContainer.java:286)
 
  -dain
 
  On Apr 24

RE: [DISCUSS] OpenJPA Graduation

2007-04-23 Thread Patrick Linskey

I think that I'm about +0.5 for TLP graduation. It seems to make more
sense, and from what I understand, there is only a minimal amount of
additional work involved. As the +0.5 indicates, I could be swayed the
other direction though.

-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 23, 2007 4:35 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: [DISCUSS] OpenJPA Graduation
 
 
 On Apr 23, 2007, at 2:58 PM, Marc Prud'hommeaux wrote:
 
 
  I'm personally rather neutral on whether OpenJPA should be 
 a TLP vs. a 
  sub-project. TLP seems like it allows us more flexibility and 
  independence, so by default I would lean towards being a TLP.
 
 That's my main concern as well.
 
  However, I do notice that the DB TLP already holds other similar 
  projects (Torque, OJB, and Apache JDO), so I wonder if the Apache 
  board would ask questions about why they should be handled 
  differently.
 
 There have been discussions in Apache about umbrella projects 
 being undesirable, and the trend is toward breaking them up 
 where there is no interdependence. There have been concerns 
 expressed at the board level about DB becoming an umbrella 
 prokect [sic], and about if Geronimo is not to become an 
 umbrella. [1]
 
 There are benefits in having small projects being part of a 
 bigger TLP. There is no fixed overhead for a small project 
 to have a PMC chair to have to report status to the board, 
 maintain committers and PMC members lists, monitor board 
 meetings, monitor incubating projects, and monitor legal and 
 community issues for the board. I don't think OpenJPA should 
 try to avoid responsibility for these tasks.
 
 Craig
 
 [1] http://www.apache.org/foundation/records/minutes/2006/
 board_minutes_2006_01_18.txt
 
 
  On Apr 23, 2007, at 2:49 PM, Craig L Russell wrote:
 
  OpenJPA has done a great job of forming a diverse 
 community around a 
  great code base whose IP has been reviewed and approved 
 for release, 
  and we're now a well-functioning, project in the 
 incubator. So we are 
  now at the stage when we should think about when and how 
 to leave the 
  incubator and graduate to the larger Apache community. The 
 document 
  at [1] describes readiness to graduate.
 
  There are two courses for graduating projects: to become an 
  independent Apache TLP or to join an existing TLP as a 
 sub- project. 
  I believe that OpenJPA should become its own TLP for a few 
 reasons: 
  the community is already very diverse and has established a good 
  working style; and there is no existing TLP upon which OpenJPA 
  depends. There is some synergy with the DB project but no 
 dependency 
  relationship.
 
  As a TLP, OpenJPA would operate independent from other TLPs and be 
  responsible to the Apache board. As a TLP, the OpenJPA community 
  would decide on offering committerships to the project, 
 and what and 
  when to release, subject to the regulations of the ASF.
 
  So what does everyone think?
 
  Craig
 
  [1] http://incubator.apache.org/incubation/
  Process_Description.html#Graduation
 
  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!
 
 
 
 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: [jira] Commented: (OPENJPA-221) DerbyDictionary doesn't describe a working mapping for char fields.

2007-04-19 Thread Patrick Linskey

 I don't know how feasible it is, but maybe if openjpa can 
 detect that the column used to store a char is defined as SQL 
 CHAR(1) then the mapping to the database character is used. 
 And we can then depend on the database to signal that it's 
 unhappy with storing a char that doesn't fit.

Historically, our experience has been that:

1. Users tend to use a single format throughout their database, so a
per-configuration setting is Good Enough.

2. It's generally pretty uncommon to store char fields anyways.

-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: Wednesday, April 18, 2007 6:05 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: [jira] Commented: (OPENJPA-221) DerbyDictionary 
 doesn't describe a working mapping for char fields.
 
 First, let me observe that Java char is a single entity that 
 represents one of 65535 or so different items, more if you 
 are trying to represent characters in Chinese that require 
 Unicode-4 byte representation.
 
 Most databases treat CHAR(1) as a single byte, which is great 
 for ASCII 8 but woefully inadequate for representing Java char.
 
 1. For the best accuracy in all databases, mapping char to
 String.valueOf((int)char) is bound to be correct.
 
 2. But if the user wants to lose precision and save a few 
 bytes in the database, mapping directly from char to CHAR(1) is ideal.
 
 It doesn't seem to me that there is a single best solution 
 to this issue. Historically, Kodo mapped char to INTEGER or 
 VARCHAR column types and there is nothing intrinsically wrong 
 with this.
 
 On the other hand, if the column type is CHAR(1) there is no 
 way to represent any of the ASCII characters 0-9;a-z;A-Z so 
 there is something to be said for assuming a different 
 mapping in this case.
 
 I don't know how feasible it is, but maybe if openjpa can 
 detect that the column used to store a char is defined as SQL 
 CHAR(1) then the mapping to the database character is used. 
 And we can then depend on the database to signal that it's 
 unhappy with storing a char that doesn't fit.
 
 Craig
 
 On Apr 18, 2007, at 3:37 PM, Patrick Linskey wrote:
 
  Does that mean you store Strings as arrays of integers by 
 default for 
  the same reason?
 
  No.
 
  Why is this different?
 
  Because we've regularly run into problems with chars, and 
 have found 
  that mapping them as ints by default gets around the problems.
 
  There aren't any non-incubator openjpa releases yet, so I 
 don't see 
  the problem.
 
  Any other opinions?
 
  I'd also expect that for preexisting
  tables either an INTEGER or CHAR column would work.
 
  They do, as long as you configure things correctly.
 
  openjpa.Log: SQL=TRACE
 
  Where would I put this so I could see what the unit tests 
 were doing?
 
  What are the unit tests? Your tests, or the tests in the OpenJPA 
  project?
 
  For your tests, add a property name=openjpa.Log 
 value=SQL=TRACE/ 
  to your persistence unit. See 
  http://incubator.apache.org/openjpa/docs/latest/manual/
  manual.html#ref_g
  uide_logging.
 
  (1) is a lot more important, but changing the answer to 
 (2) is easier 
  and solves my immediate problem.
 
  I don't think that 1 is important, since you can trivially set 
  storeCharsAsNumbers to true. Ditto for 2.
 
  -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: David Jencks [mailto:[EMAIL PROTECTED]
  Sent: Wednesday, April 18, 2007 3:20 PM
  To: open-jpa-dev@incubator.apache.org
  Subject: Re: [jira] Commented: (OPENJPA-221) 
 DerbyDictionary doesn't 
  describe a working mapping for char fields.
 
 
  On Apr 18, 2007, at 11:12 AM, Patrick Linskey wrote:
 
  Hi,
 
 
  IIUC derby is a pure java db optimized for use with java
  and storing
  java primitive types basically using java serialization

RE: Help requested around rollback semantics

2007-04-19 Thread Patrick Linskey

 In generic JPA, the only way to deal with the situation you 
 describe would be to manually call EntityManager.refresh() on 
 each instance that was involved in the transaction so as to 
 ensure that it is up to date.

Actually, I think it's even tougher than this. I think that after
rollback, entities are in an 'error' state, and you really can't do much
of anything with them. I don't think that there's even a guarantee that
you can re-attach such instances.

I believe that in either a transactional or extended PC, instances are
detached into this error state after a rollback. So, I don't think that
you can actually call refresh() on them, per the spec.

-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: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On 
 Behalf Of Marc Prud'hommeaux
 Sent: Thursday, April 19, 2007 5:20 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: Help requested around rollback semantics
 
 David-
 
  So now what do I do? Is there a recommended approach for 
 dealing with 
  this? How does my application detect this in some global way, and 
  reloads from the persistence context all the instances it 
 was keeping 
  around?
 
 In my opinion, JPA is pretty weak when it comes to rollbacks. 
 This might be due to its legacy of being part of the EJB 
 spec, where individual entity instances typically aren't 
 accessible after a transaction has completed.
 
 In generic JPA, the only way to deal with the situation you 
 describe would be to manually call EntityManager.refresh() on 
 each instance that was involved in the transaction so as to 
 ensure that it is up to date.
 
 Fortunately, in OpenJPA you have a little more control over 
 the post- rollback behavior. You can use the 
 openjpa.RestoreState property to define what should be done 
 with that state of persistent instances after a rollback occurs. See:
 
http://incubator.apache.org/openjpa/docs/latest/manual/
 manual.html#ref_guide_pc_scos_restore
 
 
 
 
 On Apr 19, 2007, at 4:40 PM, David Van Couvering wrote:
 
  Hi, all.  I am hoping you can help me out here.  You don't have a  
  users list so I'm sending it to dev.
 
  I've been implementing some code against JPA and I was trying to  
  figure out how to handle a transaction rollback. I wasn't sure if  
  JPA is responsible for rolling back the state of any 
 objects in the  
  persistence context.
 
  The answer appears to be no, and I found this in the spec:
 
  ===
  3.3.2 Transaction Rollback
 
  For both transaction-scoped and extended persistence contexts,  
  transaction rollback causes all pre-existing managed instances and  
  removed instances[15] to become detached. The instances' 
 state will  
  be the state of the instances at the point at which the 
 transaction  
  was rolled back. Transaction rollback typically causes the  
  persistence context to be in an inconsistent state at the point of  
  rollback. In particular, the state of version attributes and  
  generated state (e.g., generated primary keys) may be 
 inconsistent.  
  Instances that were formerly managed by the persistence context  
  (including new instances that were made persistent in that  
  transaction) may therefore not be reusable in the same manner as  
  other detached objects-for example, they may fail when passed to  
  the merge operation.
  
 
  As an app writer, this statement is somewhat disconcerting.
 
  I was wondering if there is any guidance available for how I can  
  write an app against JPA that handles rollback correctly.
 
  I'm writing a controller that interacts with entity objects,  
  passing them around to various methods, storing them in member  
  variables, and so on. I don't want to detach them, because (a) it  
  is costly for me to copy all the data into a separate, detached  
  instance, and then during the merge operation to have them copied  
  back into the instance stored in the persistence context and (b) I  
  never know if I can access a field or relationship because I don't  
  know if the field or related instance has been loaded yet. When I  
  keep them attached, JPA takes care of this for me.
 
  Then let's say I perform a persist() operation and it fails and  
  rolls back. This means all my objects I've been passing around and  
  storing in various places are suddenly detached and may be in an  
  inconsistent state (which from the perspective of a program is the  
  same

1 2 3 4 5 6 >

1 - 100 of 569 matches

Mail list logo