Re: Open JPA error-Could not locate metadata for the class using alias
Marina Vatkina wrote: Do you have an orm.xml (or another mapping.xml file) that might override some information? Can it be that not all classes are on the classpath? Or can there be another persistence.xml or orm.xml on the classpath that can affect the results? As there are plenty of tests that test an entity that extend an abstract entity, it's most probably something in your configuration that causes the problem. BTW, what kind of error do you get with Toplink? The reverse engineering has always generated JPA classes, so there is no other type of persistence configuration file aside from the one persistence.xml file. In there I swap the provider tag in order to enable Toplink or OpenJPA. The properties section contains properties for both engines. Toplink requires a primary key to be present in the @Entity class: Entity class [class nl.reinders.bm.Relationcat] has no primary key specified. It should define either an @Id, @EmbeddedId or an @IdClass. One this the Toplink reported was very interesting in association with the OpenJPA problem: The alias name for the entity class [class nl.reinders.bm.Relationcat] is being defaulted to: Relationcat. Toplink decides to default an alias. The OpenJPA error is something about not being able to find a alias. What is it with this alias and do I need to specify it somewhere? -- View this message in context: http://www.nabble.com/Open-JPA-error-Could-not-locate-metadata-for-the-class-using-alias-tf3561516.html#a10174890 Sent from the open-jpa-dev mailing list archive at Nabble.com.
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.
RE: Open JPA error-Could not locate metadata for the class using alias
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
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-incubating-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.
RE: Open JPA error-Could not locate metadata for the class using alias
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] Created: (OPENJPA-228) Could not locate metadata for the class using alias
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
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
Patrick Linskey wrote: 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. Alrighty then: OPENJPA-228 This is the BM archive with @Entity extends @Entity instead of @Entity extends @MappedSuperclass. But I do not believe OpenJPA gets to that part, because that actually does not make a difference. -- View this message in context: http://www.nabble.com/Open-JPA-error-Could-not-locate-metadata-for-the-class-using-alias-tf3561516.html#a10175457 Sent from the open-jpa-dev mailing list archive at Nabble.com.
[jira] Commented: (OPENJPA-228) Could not locate metadata for the class using alias
[
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
Marina Vatkina wrote:
I don't see nl/reinders/bm/generated/... classes listed in
persistence.xml.
While the provider might find that a superclass is an entity, for a spec
compliant application, you must list all of them.
Ok...
classnl.reinders.bm.Contract/class
...
classnl.reinders.bm.Websort/class
classnl.reinders.bm.generated.Contract/class
...
classnl.reinders.bm.generated.Websort/class
No difference:
47 reinders INFO [main] openjpa.Runtime - Starting OpenJPA
0.9.7-incubating
156 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}
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)
How about there being two classes with the same shortname?
--
View this message in context:
http://www.nabble.com/Open-JPA-error-Could-not-locate-metadata-for-the-class-using-alias-tf3561516.html#a10175675
Sent from the open-jpa-dev mailing list archive at Nabble.com.
RE: Open JPA error-Could not locate metadata for the class using alias
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
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.
RE: Open JPA error-Could not locate metadata for the class using alias
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
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
[
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
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
[
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)
at
RE: Open JPA error-Could not locate metadata for the class using alias
Patrick Linskey wrote: So, I got things working This is good to hear! (And also that the @MappedSuperclass was the right way to go). I'm today not working on this project, so I'll work through the changes tomorrow first thing! -- View this message in context: http://www.nabble.com/Open-JPA-error-Could-not-locate-metadata-for-the-class-using-alias-tf3561516.html#a10177260 Sent from the open-jpa-dev mailing list archive at Nabble.com.
Re: Set query params without TX?
On Apr 24, 2007, at 10:35 PM, Patrick Linskey wrote: 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). That code is from my proxy. 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. I just might give that a try. If I want to have generic code, how am I supposed to implement the createNamedQuery method? Do I leave the EM open forever? That doesn't seem right. So when am I supposed to close the EM? -dain
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!
smime.p7s
Description: S/MIME cryptographic signature
Re: Cascade question (ver 0.96)
I think maybe the issue is a simple usage issue. If you already have a persistent StoreType instance, and you store a reference to it in a new Store instance, then when you persist the Store, the StoreType instance is simply used to provide a foreign key in the database. And if you have a detached Store instance and set the relationship to a detached StoreType instance, when you merge, the StoreType is again used as a reference to provide the foreign key. Are you using a persistent or detached StoreType as the reference in your Store? Because if you're using a new StoreType instance and there is already an instance of StoreType in the database, you will get an error. Craig On Apr 24, 2007, at 11:53 AM, Phill Moran wrote: That is my concern I should only have one copy of a storeType for many Store entries. So if I add a record on the one side (Store) of a one-to- many relationship and have a relation set to an existing Many side (StoreType) I don't want a new Many side record created as this would be a duplicate. It seems unless I specify a cascade.Merge/Persist on the relationship field I cannot persist a new Store with a relationship to a StoreType record even though the StoreType record exists and does not need merging/persisting. What I am looking to do is only persist data on the one side of the relationship and never the Many. Make sense or just crazy coding? Phill -Original Message- From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On Behalf Of Marc Prud'hommeaux Sent: April 24, 2007 2:23 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Cascade question (ver 0.96) Phill- The behaviour I am looking for is simply persist the relation (i.e. the link field) If you specify cascade=MERGE on the StoreType relation field, and you merge a Store instance for which the StoreType relation doesn't already exists, does it not persist the field as if it were new? That's the behavior I would expect... On Apr 23, 2007, at 9:55 PM, Phill Moran wrote: Here is a scenario that shows odd behaviour, I want to see if it is expected or not. The docs are not clear on it If I have a many to one relationship for objects Store to Store Type and I create a new Store and assign it to an existing Store type does this relationship have to have cascasdeType.persist set when I issue a merge on the new Store? I had recently removed this as I thought I did not want to create a duplicate Store Type whenever I added a new Store. It seems OpenJPA throws the attached exception when I only have CascadeType.Refresh set. Alternatively, this could just be a poorly worded exception/ documentation meaning OpenJPA would check for the existence of this Store Type and not actually persist it if it exists. The behaviour I am looking for is simply persist the relation (i.e. the link field) Thanks, Phill 4|false|0.9.6-incubating org.apache.openjpa.persistence.ArgumentException: Encountered new object ca.BidSpec.emall.categories.Category-105603b-508b-9c6-00f4-4031ba642 9 e3:0 in persistent field ca.BidSpec.emall.stores.Store.type of managed object [EMAIL PROTECTED] during attach. However, this field does not allow cascade attach. You cannot attach a reference to a new object without cascading. FailedObject: ca.BidSpec.emall.categories.Category-105603b-508b-9c6-00f4-4031ba6429 e 3:0 at org.apache.openjpa.kernel.AttachStrategy.getReference (AttachStrategy.java:272) at org.apache.openjpa.kernel.AttachStrategy.attachField (AttachStrategy.java:189) at org.apache.openjpa.kernel.VersionAttachStrategy.attach (VersionAttachStrategy.jav a:130) at org.apache.openjpa.kernel.AttachManager.attach(AttachManager.java: 236) at org.apache.openjpa.kernel.AttachManager.attach (AttachManager.java:97) at org.apache.openjpa.kernel.BrokerImpl.attach(BrokerImpl.java:3124) at org.apache.openjpa.kernel.DelegatingBroker.attach (DelegatingBroker.java:1120) at org.apache.openjpa.persistence.EntityManagerImpl.merge (EntityManagerImpl.java:59 1) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.jav a:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.orm.jpa.ExtendedEntityManagerCreator $ExtendedEntityManagerIn vocationHandler.invoke(ExtendedEntityManagerCreator.java:283) at $Proxy37.merge(Unknown Source) at ca.BidSpec.emall.persistence.JPAPersistenceFactory.merge (JPAPersistenceFactory.j ava:95) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.jav a:25)
SQL ordering and foreign key constraints
Hello, I came accross a problem where my foreign key constraints were being violated because of the SQL insertion order during merge operations. I am aware that OpenJPA does not do any SQLre-orderingto avoid violatingforeign key constraints, however, it was trivial to make the needed changes in org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.In the case of a row insertI iterate over all foreign keys defined in that row. If I find one that is new (needs to be persisted), has an auto-assigned primary key, and cannot be null (nullable=false) then I move the row to thebottom of the list so that it will be inserted after it's foreign keys. In the current code that determines whether a later update is needed for the foreign key I added a check to see if the foreign key's state manager had already been flushed. The net effect is that the insertionorder will stay the same unless a not-null constraint on a to-be-inserted foreign key exists. In which case, that row will be inserted after the foreign key it depends on. I am interested in submitting my changes as a patch but having seen comments that suggest this is not something on OpenJPA's roadmap am wondering if there would be any interest. -Reece
Re: Set query params without TX?
On Apr 25, 2007, at 10:22 AM, Patrick Linskey wrote: If I want to have generic code, how am I supposed to implement the createNamedQuery method? Do I leave the EM open forever? That doesn't seem right. So when am I supposed to close the EM? 1. Create an EM proxy. You've already got one, so we're good there. 2. The EM proxy should create a new EM for each persistence context. In a tx, that means that it hangs onto the EM for the duration of the tx. Outside a tx, that means that it keeps the EM open for the duration of each operation. For a find(), that's the duration of the stack execution. For a query, that means you need to create a Query proxy also, and hand off the EM created during createQuery() to the Query proxy. Then, the Query proxy is responsible for closing the EM after Query.getResultList() / Query.getSingleResult() is exectued. Ah. That is my problemo. Thanks, -dain
Re: Artifact names
+1 to all that. What JDO does is publish the non-maven artifacts to the dist/db directory (JDO is a db sub-project) and there is a script that allows us to use the mirrors to let folks get the binary or source download. And we publish the maven artifacts so that a user can just write a pom and five lines of code later maven will download the dependency tree. Sweet. Craig On Apr 25, 2007, at 7:07 AM, Eddie O'Neil wrote: While in incubation, the best place for non-Maven downloads is here: http://people.apache.org/dist/incubator/ Once out of incubation, the right place is here: http://www.apache.org/dist/ which ties an artifact into the mirroring system. Then, there's a particular way to format the project's download page in order to list all of the mirrors as download options for that artifact a la: http://struts.apache.org/download.cgi Eddie On 4/25/07, Michael Dick [EMAIL PROTECTED] wrote: On 4/24/07, Phill Moran [EMAIL PROTECTED] wrote: I don't think you want the tarball in maven. Personally I would not look for it there or go searching my local repo to open and get examples, docs etc. Can we keep the tarball on OpenJPA and the minimal compile an execution jar on Maven. Keep in mind that this jar is replicated on maven, corp repo then local repo - a lot of wasted space if not absolutely necessary. Phill I agree, if we put the tarball in a different location then we should remove it from the maven repository at the same time. It shouldn't be too tricky to separate the tarball generation from the normal build processing (in which case maven won't deploy the tarball). Assuming this is the right way to go, where would be put the tarball? -Original Message- From: Patrick Linskey [mailto:[EMAIL PROTECTED] Sent: April 24, 2007 10:49 PM To: open-jpa-dev@incubator.apache.org Subject: RE: Artifact names Personally, I think both are valuable as they serve different needs for different development environments. I agree completely. Just wondering if we should be publishing the tarball via mvn. -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:41 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Artifact names It's a fair question -- if you want people to be able to sync dependencies from Maven directly into their projects via pom.xml references, then the Maven repository is the way to go. If you want to distribute a single package that contains everything (binaries, docs, samples, etc) needed to get started with OpenJPA and doesn't require the user to use the Maven project model, then the source / binary zip archives are the way to go. Personally, I think both are valuable as they serve different needs for different development environments. Eddie On 4/24/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: 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
Re: Artifact names
Does anyone happen to know if there is a way to override the repository part of the distributionManagement section of the pom.xml? If we were able to do that, we could keep the individual jar artifacts deployed to the http://people.apache.org/repo/m2-snapshot- repository/org/apache/openjpa/ (so people can reference the individual artifacts as usual), but upload the artifacts from the openjpa-project sub-pom to a separate location? On Apr 25, 2007, at 10:29 AM, Craig L Russell wrote: +1 to all that. What JDO does is publish the non-maven artifacts to the dist/db directory (JDO is a db sub-project) and there is a script that allows us to use the mirrors to let folks get the binary or source download. And we publish the maven artifacts so that a user can just write a pom and five lines of code later maven will download the dependency tree. Sweet. Craig On Apr 25, 2007, at 7:07 AM, Eddie O'Neil wrote: While in incubation, the best place for non-Maven downloads is here: http://people.apache.org/dist/incubator/ Once out of incubation, the right place is here: http://www.apache.org/dist/ which ties an artifact into the mirroring system. Then, there's a particular way to format the project's download page in order to list all of the mirrors as download options for that artifact a la: http://struts.apache.org/download.cgi Eddie On 4/25/07, Michael Dick [EMAIL PROTECTED] wrote: On 4/24/07, Phill Moran [EMAIL PROTECTED] wrote: I don't think you want the tarball in maven. Personally I would not look for it there or go searching my local repo to open and get examples, docs etc. Can we keep the tarball on OpenJPA and the minimal compile an execution jar on Maven. Keep in mind that this jar is replicated on maven, corp repo then local repo - a lot of wasted space if not absolutely necessary. Phill I agree, if we put the tarball in a different location then we should remove it from the maven repository at the same time. It shouldn't be too tricky to separate the tarball generation from the normal build processing (in which case maven won't deploy the tarball). Assuming this is the right way to go, where would be put the tarball? -Original Message- From: Patrick Linskey [mailto:[EMAIL PROTECTED] Sent: April 24, 2007 10:49 PM To: open-jpa-dev@incubator.apache.org Subject: RE: Artifact names Personally, I think both are valuable as they serve different needs for different development environments. I agree completely. Just wondering if we should be publishing the tarball via mvn. -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:41 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Artifact names It's a fair question -- if you want people to be able to sync dependencies from Maven directly into their projects via pom.xml references, then the Maven repository is the way to go. If you want to distribute a single package that contains everything (binaries, docs, samples, etc) needed to get started with OpenJPA and doesn't require the user to use the Maven project model, then the source / binary zip archives are the way to go. Personally, I think both are valuable as they serve different needs for different development environments. Eddie On 4/24/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: 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,
RE: Possible problem with ddl with only a jta-datasource and sequences
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: Possible problem with ddl with only a jta-datasource and sequences
On 4/24/07, Patrick Linskey [EMAIL PROTECTED] wrote: 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? Unfortunately, I am just the messenger in this case. The WebSphere Transactions team has already designed and developed this Runnable solution and has made it available via a FixPack. So, it's cast in concrete now... :-) Kevin 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.
Re: Set query params without TX?
Is a query a one time use object? Meaning, I only get to call getResultList(), getSingleResult(), or executeUpdate() once and then I have to get a new instance. Also you stated: On Apr 24, 2007, at 10:35 PM, Patrick Linskey wrote: (please please please make it a dynamic proxy that implements all the interfaces that the proxied thing implements). When I first wrote the proxy, I tried to implement it using a dymanic proxy, but gave up after I discovered the extreme differences in the handling of the methods. Some methods require an active transaction, and some are fine without one, but you have to close the em in a finally block. The getQuery methods, need to have the Query object proxied, but only if there is no transaction. Some methods like joinTransaction(), close(), isOpen(), and getTransaction() just have custom rules. So I could easily create a dynamic proxy, but which strategy would I choose for the methods that are dyanmic (i.e., the extra methods not on the entity manager interface)? -dain
Re: Artifact names
I've been overriding the deployment location for the staging directory. I
thought I made the changes back to trunk, but I must have missed it, I just
added it back in.
The changes configure the deploy plugin to look for a
deploy.altRepositoryvariable, if it's found we'll deploy to that
location.
The variable can be added in ${M2_HOME}/settings.xml like this :
profiles
profile
idrelease/id
properties deploy.altRepository
people.apache.org::default::scp://people.apache.org/home/mikedd/public_html/staging-repository
/deploy.altRepository
/properties
/profile
/profiles
Run mvn -Prelease deploy and watch for scp and it will deploy to the
alternate location. If you just do the build from a subproject it should
work (haven't tried it though).
On 4/25/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
Does anyone happen to know if there is a way to override the
repository part of the distributionManagement section of the
pom.xml? If we were able to do that, we could keep the individual jar
artifacts deployed to the http://people.apache.org/repo/m2-snapshot-
repository/org/apache/openjpa/ (so people can reference the
individual artifacts as usual), but upload the artifacts from the
openjpa-project sub-pom to a separate location?
On Apr 25, 2007, at 10:29 AM, Craig L Russell wrote:
+1 to all that.
What JDO does is publish the non-maven artifacts to the dist/db
directory (JDO is a db sub-project) and there is a script that
allows us to use the mirrors to let folks get the binary or source
download. And we publish the maven artifacts so that a user can
just write a pom and five lines of code later maven will download
the dependency tree. Sweet.
Craig
On Apr 25, 2007, at 7:07 AM, Eddie O'Neil wrote:
While in incubation, the best place for non-Maven downloads is here:
http://people.apache.org/dist/incubator/
Once out of incubation, the right place is here:
http://www.apache.org/dist/
which ties an artifact into the mirroring system. Then, there's a
particular way to format the project's download page in order to list
all of the mirrors as download options for that artifact a la:
http://struts.apache.org/download.cgi
Eddie
On 4/25/07, Michael Dick [EMAIL PROTECTED] wrote:
On 4/24/07, Phill Moran [EMAIL PROTECTED] wrote:
I don't think you want the tarball in maven. Personally I would
not look
for it
there or go searching my local repo to open and get examples,
docs etc.
Can we
keep the tarball on OpenJPA and the minimal compile an
execution jar on
Maven.
Keep in mind that this jar is replicated on maven, corp repo
then local
repo - a
lot of wasted space if not absolutely necessary.
Phill
I agree, if we put the tarball in a different location then we
should remove
it from the maven repository at the same time. It shouldn't be
too tricky to
separate the tarball generation from the normal build processing
(in which
case maven won't deploy the tarball).
Assuming this is the right way to go, where would be put the
tarball?
-Original Message-
From: Patrick Linskey [mailto:[EMAIL PROTECTED]
Sent: April 24, 2007 10:49 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: Artifact names
Personally, I think both are valuable as they serve
different needs
for different development environments.
I agree completely. Just wondering if we should be publishing
the tarball
via
mvn.
-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:41 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Artifact names
It's a fair question -- if you want people to be able to sync
dependencies from Maven directly into their projects via pom.xml
references, then the Maven repository is the way to go.
If you want to distribute a single package that contains
everything
(binaries, docs, samples, etc) needed to get started with
OpenJPA and
doesn't require the user to use the Maven project model, then
the
source / binary zip archives are the way to go.
Personally, I think both are valuable as they serve
different needs
for different development environments.
Eddie
On 4/24/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
On Apr 24, 2007, at 7:27 PM,
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 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.
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
RE: More questions on runtime schema generation
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
Re: ApacheCon Europe
On 4/25/07, Patrick Linskey [EMAIL PROTECTED] wrote: Hey, Is anyone else going to be at ApacheCon next week? Marc Prud'hommeaux and I will both be there. cool :-) i'm there from saturday to saturday (see http://wiki.apache.org/apachecon/WhoArrivesWhen for more arrival times) if any committers are going to be in holland over the queensday weekend, it's worth subscribing to the private apache party list (you'll need to use your apache email address) - robert
[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.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
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'
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: Artifact names
On Apr 25, 2007, at 11:25 AM, Marc Prud'hommeaux wrote: Does anyone happen to know if there is a way to override the repository part of the distributionManagement section of the pom.xml? If we were able to do that, we could keep the individual jar artifacts deployed to the http://people.apache.org/repo/m2- snapshot-repository/org/apache/openjpa/ (so people can reference the individual artifacts as usual), but upload the artifacts from the openjpa-project sub-pom to a separate location? On Apr 25, 2007, at 10:29 AM, Craig L Russell wrote: +1 to all that. What JDO does is publish the non-maven artifacts to the dist/db directory (JDO is a db sub-project) and there is a script that allows us to use the mirrors to let folks get the binary or source download. And we publish the maven artifacts so that a user can just write a pom and five lines of code later maven will download the dependency tree. Sweet. Craig On Apr 25, 2007, at 7:07 AM, Eddie O'Neil wrote: While in incubation, the best place for non-Maven downloads is here: http://people.apache.org/dist/incubator/ Once out of incubation, the right place is here: http://www.apache.org/dist/ which ties an artifact into the mirroring system. Then, there's a particular way to format the project's download page in order to list all of the mirrors as download options for that artifact a la: http://struts.apache.org/download.cgi Eddie On 4/25/07, Michael Dick [EMAIL PROTECTED] wrote: On 4/24/07, Phill Moran [EMAIL PROTECTED] wrote: I don't think you want the tarball in maven. Personally I would not look for it there or go searching my local repo to open and get examples, docs etc. Can we keep the tarball on OpenJPA and the minimal compile an execution jar on Maven. Keep in mind that this jar is replicated on maven, corp repo then local repo - a lot of wasted space if not absolutely necessary. Phill I agree, if we put the tarball in a different location then we should remove it from the maven repository at the same time. It shouldn't be too tricky to separate the tarball generation from the normal build processing (in which case maven won't deploy the tarball). Assuming this is the right way to go, where would be put the tarball? -Original Message- From: Patrick Linskey [mailto:[EMAIL PROTECTED] Sent: April 24, 2007 10:49 PM To: open-jpa-dev@incubator.apache.org Subject: RE: Artifact names Personally, I think both are valuable as they serve different needs for different development environments. I agree completely. Just wondering if we should be publishing the tarball via mvn. -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:41 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Artifact names It's a fair question -- if you want people to be able to sync dependencies from Maven directly into their projects via pom.xml references, then the Maven repository is the way to go. If you want to distribute a single package that contains everything (binaries, docs, samples, etc) needed to get started with OpenJPA and doesn't require the user to use the Maven project model, then the source / binary zip archives are the way to go. Personally, I think both are valuable as they serve different needs for different development environments. Eddie On 4/24/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: 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
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 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
RE: Possible problem with ddl with only a jta-datasource and sequences
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
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 return this by email and then delete it. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
RE: More questions on runtime schema generation
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
