Re: OpenJPA status report for the Apache Board
Craig... I wanted to take a minute and thank you personally for putting this report together. I've been fairly absent from the project for the last month or two (company I was at shut its doors so I had to start a new gig and I'm finishing my basement at the same time), and would like to ramp up on it a bit more as time allows. At any rate, these types of things are not trivial and definitely not glorious work, so thanks for taking the time to throw it together. --Bryan Craig L Russell wrote: This is the OpenJPA status report for the board for the three month period ending Mar 2007. === OpenJPA === OpenJPA made good progress this quarter in all areas. The project has many active committers all driving toward improving functionality, stability, performance, and usability. OpenJPA has met all of the technical requirements for graduation from incubation, and is now waiting for the community to feel ready. It is not clear whether the destination should be a TLP or a sub-project of another. This discussion has not been started yet. Well, I guess it just has. Development Development continues on the 0.9.7 release, which will contain many bug fixes and performance improvements. Kevin Sutter has been volunteered to cut the release once we decide there is enough done on the list. The JSR 220 TCK was passed. JIRA now contains numerous proposed bug fixes and feature enhancements, tentatively assigned to release buckets. Infrastructure The project is running smoothly with all systems green. Community One new committer was added (Michael Dick). Three new PPMC members were added (Kevin Sutter, Marc Prud'hommeaux, and Abe White). Craig Russell DB PMC, OpenJPA PPMC [EMAIL PROTECTED] http://db.apache.org/jdo
accessing archived threads with Nabble
I just wanted to throw this up here real quick, because I noticed Marc gave the apache archives site in one of his vote tally threads for referencing (http://mail-archives.apache.org/mod_mbox/incubator-open-jpa-dev/). Someone has set this list up at Nabble. http://www.nabble.com/open-jpa-dev-f16309.html Nabble's format (basically forum-style) is incredibly better than apache's in terms of navigability, finding stuff, and just general ease of use. Thought it might be useful for folks to know about. --Bryan
Re: accessing archived threads with Nabble
No problem. I just thought I'd throw it up here in case it was unknown to anyone. Marc Prud'hommeaux wrote: I agree that Nabble is much more navigable. I've been linking to the mail-archives.apache.org archive just because all the examples I've seen of posting vote results seem to reference that site. On Feb 13, 2007, at 7:48 AM, Bryan Noll wrote: I just wanted to throw this up here real quick, because I noticed Marc gave the apache archives site in one of his vote tally threads for referencing (http://mail-archives.apache.org/mod_mbox/incubator-open-jpa-dev/). Someone has set this list up at Nabble. http://www.nabble.com/open-jpa-dev-f16309.html Nabble's format (basically forum-style) is incredibly better than apache's in terms of navigability, finding stuff, and just general ease of use. Thought it might be useful for folks to know about. --Bryan
Re: [VOTE] Move JPA API dependency from dev.java.net to geronimo version
+1 ...because of the compliance reasons you outlined. Michael Dick wrote: +1 On 2/10/07, Eddie O'Neil [EMAIL PROTECTED] wrote: +1 On 2/9/07, Craig L Russell [EMAIL PROTECTED] wrote: +1 My vote is as much related to dissatisfaction with the maven repo that is used by glassfish as with the time it takes to get anything done through official channels. Craig On Feb 8, 2007, at 9:41 PM, Marc Prud'hommeaux wrote: It turns out that the JPA API we've been building against (the one from https://maven-repository.dev.java.net/repository/ javax.persistence/jars/persistence-api-1.0.jar) is not actually the final version of the spec: there are some minor (and binary- compatible) changes (some annotations don't have runtime retention, for example), but they are enough to prevent us from passing all the compatibility tests we need. The Geronimo API jar (http://mirrors.ibiblio.org/pub/mirrors/maven2/ org/apache/geronimo/specs/geronimo-jpa_3.0_spec/geronimo- jpa_3.0_spec-1.0.jar) is compliant, as far as I can tell. How do people feel about changing the dependency from persistence- api-1.0.jar to geronimo-jpa_3.0_spec-1.0.jar? I've run through all our tests, and they pass with the Geronimo version. This would have the added advantage of unifying our spec jars to all be using the Geronimo versions. +1 indicates that you approve of the change -1 indicated that you disagree that the change should be made Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: Using _attributes
I don't feel pre-fixing with '_' for member level attributes is really
necessary, particularly if you're using an IDE. I can see how it would
help someone using only vi or emacs recognize what was what, but with
the color code and hotkeys and quick-clicking available in IDE's, it
just doesn't seem necessary.
Plus, Eclipse does the same thing you're describing in terms of
getter/setter generation. For instance...
private String _blah; // the following accessors were generated.
public String get_blah() {
return _blah;
}
public void set_blah(String _blah) {
this._blah = _blah;
}
I don't know whether IntelliJ figures this out or no.
Abe White wrote:
I think it could be nicer and a bit easier if OpenJPA was automatically
eliminating the first _ from attribute names to build its default coumn
names, don't you think?
The default column names are mandated by the JPA specification. And
unless you're using OpenJPA-specific mappings, you shouldn't have to
use OpenJPA-specific annotations just to rename columns. The JPA spec
includes standard annotations for naming the columns in all standard
mappings.
___
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: [VOTE] [SECOND ATTEMPT] publish openjpa 0.9.6-incubating release
+1 Marc Prud'hommeaux wrote: OpenJPA People- In accordance with the Incubating Releases guidelines at http://incubator.apache.org/incubation/Incubation_Policy.html#Releases , I'd like to take a third shot at making an OpenJPA release and start a vote on publishing a 0.9.6-incubating release of OpenJPA. The most recent vote failed due to some problems with the notice file and some source files that were missing license headers. The release candidate is at: http://people.apache.org/repo/m2-incubating-repository/org/apache/openjpa/openjpa-project/0.9.6-incubating/openjpa-project-0.9.6-incubating-binary.zip The GPG signature and MD5 checksums are at: http://people.apache.org/repo/m2-incubating-repository/org/apache/openjpa/openjpa-project/0.9.6-incubating/openjpa-project-0.9.6-incubating-binary.zip.asc http://people.apache.org/repo/m2-incubating-repository/org/apache/openjpa/openjpa-project/0.9.6-incubating/openjpa-project-0.9.6-incubating-binary.zip.md5 The sources, sources GPG signature and sources MD5 checksum are available at: http://people.apache.org/repo/m2-incubating-repository/org/apache/openjpa/openjpa-project/0.9.6-incubating/openjpa-project-0.9.6-incubating-source.zip http://people.apache.org/repo/m2-incubating-repository/org/apache/openjpa/openjpa-project/0.9.6-incubating/openjpa-project-0.9.6-incubating-source.zip.asc http://people.apache.org/repo/m2-incubating-repository/org/apache/openjpa/openjpa-project/0.9.6-incubating/openjpa-project-0.9.6-incubating-source.zip.md5 I have tagged the sources at: https://svn.apache.org/repos/asf/incubator/openjpa/tags/0.9.6-incubating/ Please vote to publish this incubating release on the project Web page: http://cwiki.apache.org/openjpa/downloads.html This vote will remain open until 6:00PM EST on Wednesday November 15th. A +1 indicates that you approve of the release, a -1 indicates a vote against making a release. I'll get the ball rolling by adding my own vote: +1
Re: openjpa.Id property
When I see 'AbsoluteUnitName'... I immediately think... I don't know what that means I guess I'd prefer to stick with terminology that I'm more familiar with (and I'm assuming users would be more familiar with it too). Again though... if you feel strongly about this... I'll defer... it's just a property name Craig L Russell wrote: So does it make sense to consider how Java has handled a similar concept: http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html#getAbsolutePath() Could we use some of the same terms, perhaps AbsoluteUnitName for the purpose you are proposing here, and not implement UnitName until someone asks for it? In the non-managed environment, I assume application-name and module-name are empty so the absolute unit name would be the same as the unit name? Craig On Nov 14, 2006, at 2:48 PM, Patrick Linskey wrote: So I'm having a bit of a hard time with this property setting. In many environments, it makes a lot of sense to line up the openjpa.PersistenceUnitName property with the setting in the persistence.xml file. However, in an appserver, that name might not be unique. We (BEA) sometimes need to be able to get the fully-qualified persistence unit name, which is probably most closely defined in a Java EE environment as application-name.module-name.persistence-unit-name or somesuch. But obviously, if I create a property called openjpa.PersistenceUnitName, people would (understandably) assume that the property should contain just persistence-unit-name, and not the fully-qualified beast. That's why I was thinking along the terms of 'Id' instead of 'PersistenceUnitName'. Do others agree that these concepts are not quite the same? If so, should I create a property for each (since PersistenceUnitName might be useful), or should I just create the ID-related one, since that's all I really need right now? -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: Thursday, November 09, 2006 4:50 PM To: open-jpa-dev@incubator.apache.org Subject: Re: openjpa.Id property Hi Patrick, I don't think there would be an issue with calling it unitName or persistenceUnitName, as in getUnitName() or getPersistenceUnitName(). It will be common for people to try to figure out what the Id property from a Configuration really means so the more help we give them the easier it will be to remember. openjpa.unitName openjpa.persistenceUnitName Maybe I'm missing something obvious... Craig On Nov 9, 2006, at 2:19 PM, Patrick Linskey wrote: Hi, It's useful in a number of places to get an identifier for a particular Configuration. For example, as we discussed a few months ago, it would be useful if the logging subsystem automatically wrote the persistence unit's ID along with log messages if no such ID was specified in the log configuration. Any objections to such an addition? In a JPA environment, this would correspond to the persistence unit's unitName attribute. Any suggestions for a better name than openjpa.Id for the property? This would result in an OpenJPAConfiguration.getId() method call that returned a String. -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. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: Localizer.forPackage() and startup time
+1. Seems right to have the 'slowness' occur on the unhappy path instead of the happy path. Craig L Russell wrote: +1 Seems like the right tradeoff. Craig On Nov 8, 2006, at 4:22 PM, Patrick Linskey wrote: Hi, I'm investigating ways to optimize startup time a bit, and one thing that I ran across is resource bundle overhead in calls to Localizer.forPackage() calls. I'm working on a patch that defers all of the Localizer.forPackage() overhead to the first use of the localizer, instead of eagerly looking for data. This will mean slightly more overhead on all Localizer method invocations, but localization generally only happens when writing log / error messages, so it seems like it's fair to increase the overhead in those situations in exchange for eliminating the overhead in normal usage (i.e., when the localizer is not used). Since we obtain Localizer instances statically, this should speed up the first load of any class that has a Localizer reference. What do others think about this tradeoff? -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. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: Welcome, Bryan
I appreciate the invite and look forward to contributing. --Bryan Craig L Russell wrote: Hi Bryan, Congratulations, and welcome to the committers on OpenJPA. I'm looking forward to your continued contributions. Craig On Nov 7, 2006, at 10:59 AM, Patrick Linskey wrote: Hi, Bryan Noll is now a committer on OpenJPA. Welcome, Bryan! -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. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: [VOTE] publish openjpa 0.9.5-incubating podling release
+1 ... sounds good to me Marc Prud'hommeaux wrote: OpenJPA People- In accordance with the Incubating Releases guidelines at http://incubator.apache.org/incubation/Incubation_Policy.html#Releases , I'd like to start a vote on publishing a 0.9.5-incubating release of OpenJPA. The release candidate is in my home directory at: http://people.apache.org/~mprudhom/openjpa/release-candidate/openjpa-project/0.9.5-incubating/openjpa-project-0.9.5-incubating.zip The MD5 sum for the file is 322b7af1b557fa8c3fae5dc539696f1a Please vote to publish this incubating release on the project Web page: http://cwiki.apache.org/openjpa/downloads.html (note: I had previously jumped the gun and updated the wiki with a link to that download ... David Blevins helpfully mentioned that that wasn't in accordance with ASF policies. I apologize)
[jira] Commented: (OPENJPA-13) GenerationType.IDENTITY problem with MS SQL Server
[
http://issues.apache.org/jira/browse/OPENJPA-13?page=comments#action_12439954 ]
Bryan Noll commented on OPENJPA-13:
---
So... after looking into this issue for a bit, the problem is this:
Assumptions:
-
Driver: jtds-1.2.jar
Column Type defined as: [ID] [int] IDENTITY (1, 1) NOT NULL
The ClassCastException is coming from this line of the generated code in the
PersistenceCapable class...
id = (Integer)pcStateManager.replaceObjectField(this, i);
As a result of the previous method call, we eventually arrive at the
'org.apache.openjpa.jdbc.sql.DBDictionary.getGeneratedKey' method, where there
is this line of code...
Object key = rs.getObject(1);
When examining this 'key' object at runtime, its type is java.math.BigDecimal,
so... the jtds driver is returning this '[int] IDENTITY (1, 1)' type as a
BigDecimal.
This problem does not occur when using a primitive 'int' as the type of the @Id
mapping because the
org.apache.openjpa.jdbc.meta.strats.PrimitiveFieldStrategy.setAutoAssignedValue
method simply up-casts the 'autoInc' value to a Number (legally because it is a
BigDecimal), and then calls the 'intValue' method (all of this inside the 'case
JavaTypes.INT' section of the switch statement). The corresponding class that
has the setAutoAssignedValue method for the non-primitive types is
HandlerFieldStrategy.
The same problem occurs with MySQL when attempting to use a 'java.lang.Integer'
as the type of the @Id field, because the value is returned by the driver as a
'java.lang.Long' (driver: mysql-connector-java-3.1.11.jar, colum type of
'int(11) - auto_increment'). This doesn't seem as hinky, because using a Long
as the @Id type seems more reasonable than having to use a primitive or a
BigDecimal.
I've thought of a couple of ways to go about resolving this, none of which I
really like, and am hoping one of the people more familiar with the code base
can point me in the right direction.
- Modify the bytecode enhancement so that it is try-catching for a
ClassCastException, then instead of casting, explicitly construct the wrapper
type that you need, in this case Integer, by casting to a Number, and then
calling methods on that.
- Override the getGeneratedKey method in the SQLServerDictionary class to
return a cast-safe value. Not good at all, because I don't see, as its modeled
now, that this object is capable of finding out at runtime in a dynamic way
what exactly it needs to return. As a hack, I had it return an Integer, but
that only worked because I knew the @Id field was mapped as an Integer.
- In the StateManager, add methods that correspond to the
replacePrimitiveField (replaceIntField gets called in the enhanced code when
the @Id type is int), such as replaceIntegerWrapperField,
replaceLongWrapperField, etc... instead of just having replaceObjectField.
- Maybe someone can point out somewhere in the object hierarchy (thinking
somewhere around HandlerFieldStrategy.setAutoAssignedValue) where we can get to
the information in the PersistenceCapable implementor using the fieldName or
index so we can find out what type it is supposed to be, and construct it there
from the BigDecimal (or whatever it is, Long with MySQL for instance).
- Don't change any code, and document somewhere what we know about what a
person can and cannot use for auto-increment @Id types for different databases.
This one seems good enough for MySQL.
Thoughts... suggestions?
GenerationType.IDENTITY problem with MS SQL Server
--
Key: OPENJPA-13
URL: http://issues.apache.org/jira/browse/OPENJPA-13
Project: OpenJPA
Issue Type: Bug
Components: jpa
Environment: Microsoft SQL Server 2000
Windows XP
Java SE 1.5
OpenJPA - source downloaded today (Aug 14, 2006)
Reporter: Megan
Priority: Critical
Cannot persist entity with identity column. To reproduce, create a simple
object with identity column
@Entity
@Table(name=JpaType)
public class JpaType implements Serializable
{
@Id
@GeneratedValue(strategy=GenerationType.IDENTITY)
@Column(name=Id)
private Integer id = null;
@Column(name=Name)
private String name = null;
public Integer getId() { return id; }
public String getName() { return name; }
public void setName(String name) { this.name = name; }
}
create table JpaType (
Id int identity(1, 1) not null
, Name varchar(50) null
, constraint JpaType_PK primary key (Id)
)
JpaType jpa = new JpaType();
jpa.setName(Test 1);
em.persist(jpa);
em.flush();
It works OK if I remove identity column (and set ID myself).
Stack trace
0|true|0.9.0 org.apache.openjpa.persistence.PersistenceException:
java.math.BigDecimal
at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1576
Re: [jira] Commented: (OPENJPA-13) GenerationType.IDENTITY problem with MS SQL Server
Abe, just did an 'svn up' (revision 453025) and don't see
HandlerStrategies in the list of updated files.
'svn log' on that file produces:
r438566 | pcl | 2006-08-30 11:53:55 -0600 (Wed, 30 Aug 2006) | 1 line
changed @since tags to disambiguate the Kodo information with future
releases of OpenJPA by adding a 0. to the beginning of each.
If you want to hop on the irc channel, maybe we can hash through this
quicker.
#openjpa
irc.freenode.net
Abe White (JIRA) wrote:
[ http://issues.apache.org/jira/browse/OPENJPA-13?page=comments#action_12439964 ]
Abe White commented on OPENJPA-13:
--
I just committed a possible fix for this issue by changing
HandlerStrategies.setAutoAssignedValue to conver the DB-produced auto-assigned
value to the Java type the field expects for the given column. Bryan, can you
test with your SQLServer and/or MySQL driver?
GenerationType.IDENTITY problem with MS SQL Server
--
Key: OPENJPA-13
URL: http://issues.apache.org/jira/browse/OPENJPA-13
Project: OpenJPA
Issue Type: Bug
Components: jpa
Environment: Microsoft SQL Server 2000
Windows XP
Java SE 1.5
OpenJPA - source downloaded today (Aug 14, 2006)
Reporter: Megan
Priority: Critical
Cannot persist entity with identity column. To reproduce, create a simple
object with identity column
@Entity
@Table(name=JpaType)
public class JpaType implements Serializable
{
@Id
@GeneratedValue(strategy=GenerationType.IDENTITY)
@Column(name=Id)
private Integer id = null;
@Column(name=Name)
private String name = null;
public Integer getId() { return id; }
public String getName() { return name; }
public void setName(String name) { this.name = name; }
}
create table JpaType (
Id int identity(1, 1) not null
, Name varchar(50) null
, constraint JpaType_PK primary key (Id)
)
JpaType jpa = new JpaType();
jpa.setName(Test 1);
em.persist(jpa);
em.flush();
It works OK if I remove identity column (and set ID myself).
Stack trace
0|true|0.9.0 org.apache.openjpa.persistence.PersistenceException:
java.math.BigDecimal
at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1576)
at
org.apache.openjpa.kernel.DelegatingBroker.flush(DelegatingBroker.java:927)
at
org.apache.openjpa.persistence.EntityManagerImpl.flush(EntityManagerImpl.java:421)
at mytest.domain.JpaTest.testJpa(JpaTest.java:30)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
at
org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
at
org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at
org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
at
org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
at
org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:71)
at
org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35)
at
org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
at
org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at
org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: java.lang.ClassCastException: java.math.BigDecimal
at mytest.domain.model.JpaType.pcReplaceField(JpaType.java)
at
org.apache.openjpa.kernel.StateManagerImpl.replaceField(StateManagerImpl.java:2824)
at
org.apache.openjpa.kernel.StateManagerImpl.storeObjectField(StateManagerImpl.java:2284)
at
org.apache.openjpa.kernel.StateManagerImpl.storeField(StateManagerImpl.java:2380)
at
org.apache.openjpa.kernel.StateManagerImpl.storeField(StateManagerImpl.java:723)
at
enhancement of persistent classes
Hello all... was on vacation for a bit... then the day job got in the way. Quick question for the folks more in the know than me. Reading this (http://people.apache.org/~mprudhom/openjpa/site/openjpa-project/manual/ref_guide_pc_enhance.html#ref_guide_pc_enhance_runtime_container), it seems like classes must be enhanced (either at build time or runtime) unless being deployed to a compliant EJB3 container, in which case that's part of the container's job. I just wanted to verify that I understand this correctly, and there's not some way to avoid having to enhance these things that I don't know about. I ask because you don't have to perform any kind of enhancement step in your build process when using Hibernate. I wouldn't be surprised if I'm missing something here, so if I said something stupid, please be gentle. Thanks... Bryan
Re: Data + Query cache
inline... Pinaki Poddar wrote: DataCache or L2 cache being a performance optimization feature not mandated by the spec, makes it a candidate for *not* being on by default. a) If the user explictly turns the feature on, it makes him/her aware of its advantages as well as behavioral difference e.g. refresh(). b) If the user turns it on and observes a performance improvement -- that makes the benefit of the feature obvious. c) It keeps the option of product level differentiation open On the other hand, if the feature is on by default what would be the likely reason to turn it off? Some JavaEE portal may then report how default behaviour of OpenJPA is not spec-compliant :( On performance front, initial results indicate that OpenJPA is significantly better than other alternatives against industry standard benchmarks -- so even leaving DataCache off would not give a reason to report otherwise. Wow... cool. Do you have or are you planning to make these 'initial results' available publicly? It would be handy for people to have that kind of information in their back pocket if they need it. Thanks... Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Marc Logemann [mailto:[EMAIL PROTECTED] Sent: Friday, August 25, 2006 10:18 AM To: open-jpa-dev@incubator.apache.org Subject: Re: Data + Query cache Hi, of course my intention wasnt to ask about kodo, but i was confused that a feature will be on by default that was formerly on sale. I will look into the packages to get an idea. The other question regarding the cache or a method like isCached() was to solve the issue that users could get irritated where the results come from. Without such a method, there is no way to solve the irritation for certain users then ;-) But the other thing is, if you dont turn it on by default, you can be sure to see a review that says that hibernate is faster by default on some JavaEE portal. -- regards Marc Logemann [blog] http://www.logemann.org [busn] http://www.logentis.de Am 25.08.2006 um 18:31 schrieb Patrick Linskey: (Performance pack is Kodo parlance, and this is a Kodo-related email.) Actually, we're getting rid of Performance Pack altogether, at long last, and replacing with a Professional Edition. (I never much liked the Performance Pack name, given that the other two were editions.) I don't remember the details of what lands where, but we aren't going to be selling things that are available in OpenJPA. You can get a feeling for what the JDO bindings for Kodo look like by taking a look at the openjpa-persistence and openjpa-persistence-jdbc modules in OpenJPA -- you'll notice that the bindings largely add spec behavior to the core kernel. So the features available in the core kernel are available to all bindings. -Patrick -- Patrick Linskey BEA Systems, Inc. -Original Message- From: Marc Logemann [mailto:[EMAIL PROTECTED] Sent: Friday, August 25, 2006 7:01 AM To: open-jpa-dev@incubator.apache.org Subject: Re: Data + Query cache Hi, does that mean that the performance pack gets obsolete or how do you want to control the cache then? It would be weird to sell the cache to JDO users while its free for JPA users right? -- regards Marc Logemann [blog] http://www.logemann.org [busn] http://www.logentis.de Am 24.08.2006 um 22:54 schrieb Abe White: How does the list feel about turning the L2 data and query caches on by default? Traditionally, Kodo always left them off by default, primarily because they required a performance pack license to run. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: status of OpenJPA documentation
I'm having a hard time tracking down the thread regarding the discussion about where the site and docs should be kept. Would someone mind replying with a URL? I'd like to first go catch up on that, and then maybe push for a decision from the community so we can move ahead. Thanks... Marc Prud'hommeaux wrote: Bryan- - If the only thing stopping this stuff from getting to a wiki is bandwidth of the current dev team, can someone point me in the right direction so I can run with it? I think that if Marc is willing to turn over his work in progress to you then you can run with it. Just see if what you intend is more or less permanent it belongs on the site, and work-in-progress-needing-interaction belongs on the wiki. My original idea was to generate the documentation from its current location (at openjpa-project/src/doc/manual/manual.xml), and generate the site and docs together using the mvn site process (the output of which can be seen at http://people.apache.org/~mprudhom/openjpa/site/ ). Other people suggested that we keep the site and docs in a separate, parallel Subversion directory, so I waited to do any further work until we had come to some consensus on how the project site and documentation should be handled. Everything that I've done is currently checked into Subversion, though. Any changes/additions to the docs can be made to openjpa-project/src/doc/manual/manual.xml , which I expect we will relocate to wherever we decide is the best place for it. On Aug 21, 2006, at 4:07 PM, Craig L Russell wrote: On Aug 21, 2006, at 6:53 AM, Bryan Noll wrote: Craig... You seem to be one of the resident experts on infra-related stuff. Can you comment on some of my questions in the mail? Thanks... Bryan Noll wrote: So... I realize that OpenJPA is super-new to Apache, and this is for sure the reason that the documentation is currently located at what appears to be a non-permanent place (http://people.apache.org/~mprudhom/openjpa/site/openjpa-project/manual/index.html). Yes, this is a non-permanent location. It's Marc's personal space in Apache land. - Is there a plan to migrate this stuff do a different location? (either http://wiki.apache.org/incubator/openjpa/ or http://cwiki.apache.org/confluence/display/openjpa/Index) I guess Marc knows best what the plans are. - Is cwiki.apache.org preferred to wiki.apache.org? Well, this is a personal preference, and it turns out that openjpa actually has empty home pages on both sites (I accidentally added some content to the cwiki which can be moved to the wiki). Personally, I'm not familiar with cwiki so I don't understand its advantages or modus operandi. Maybe someone in the group with more experience using these tools can comment. I didn't find that adding a new page was trivial (and no, I didn't rtfm). - There are certain resources that have bad links to non-existent locations in the current documentation. For instance: from here... (http://people.apache.org/~mprudhom/openjpa/site/openjpa-project/manual/jpa_tutorial.html#jpa_tutorial_files) trying to get to here... (http://people.apache.org/~mprudhom/openjpa/tutorial/persistence/AnimalMaintenance.java) Marc noted in a previous thread that, in this specific case, the tutorial files simply had not been committed to the apache repo yet. This is something I'm willing to prepare a patch for. I'd say that these should probably be moved to the site area parallel to trunk. There was an open question a while back on where the tutorials belonged (either in site or in each release branch plus trunk), and I don't know that we ever resolved this question. Not that the tutorial work is all that glorious, but it seems like something that would be good to have available for folks considering using OpenJPA who want to give the project the 15 minute sniff test. - My real motive in asking these questions is that I've run across some documentation that I'd like to add to, and wondered if/when it was going to make its way to a wiki so people can contribute. I think there's room for both site and wiki. I think there is a discussion on this topic in the archives. - If the only thing stopping this stuff from getting to a wiki is bandwidth of the current dev team, can someone point me in the right direction so I can run with it? I think that if Marc is willing to turn over his work in progress to you then you can run with it. Just see if what you intend is more or less permanent it belongs on the site, and work-in-progress-needing-interaction belongs on the wiki. Craig Thanks... Bryan Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: status of OpenJPA documentation
Thanks Craig for the link... So... having caught up on that thread, seems like the following are the key points: 1. People seem to like the easiness of wiki editing for the main site. (If wiki content is specific to a particular release, it would just be identified as such, much like this: http://geronimo.apache.org/documentation.html) 2. It is a good thing to keep the official documentation for a release with that release. This documentation should be changing less often than the stuff on the wiki, therefore the 'developery' approach of having to to subversion check ins to the manual.xml file is acceptable. Another example of the kind of content on this site would be the javadoc, as that is specific to each release, so http://issues.apache.org/jira/browse/OPENJPA-11 would have to be re-worked. 3. It would be good if one could navigate to the full set of release specific documentation from 'The Site'. Rationale for this provided by Craig here: *http://tinyurl.com/zbwz4* 4. Note: I'm throwing this one in - It would be good if their was some continuity in terms of look and feel when navigating to the maven generated (via 'maven site') release specific stuff from 'The Site'. I assume the same skin can be applied to both 'The Site' (current generated with ant via Anakia) and the version-specific Maven generated sites. Does this sound agreeable? Anyone like to add anything to it... or have any major issues with it? Thanks... Bryan Craig L Russell wrote: Hi Bryan, The thread named staging of site changes dated 25-July is the thread to which I referred. It has some expressed points of view but no conclusion. http://mail-archives.apache.org/mod_mbox/incubator-open-jpa-dev/200607.mbox/thread Craig On Aug 22, 2006, at 8:43 AM, Bryan Noll wrote: I'm having a hard time tracking down the thread regarding the discussion about where the site and docs should be kept. Would someone mind replying with a URL? I'd like to first go catch up on that, and then maybe push for a decision from the community so we can move ahead. Thanks... Marc Prud'hommeaux wrote: Bryan- - If the only thing stopping this stuff from getting to a wiki is bandwidth of the current dev team, can someone point me in the right direction so I can run with it? I think that if Marc is willing to turn over his work in progress to you then you can run with it. Just see if what you intend is more or less permanent it belongs on the site, and work-in-progress-needing-interaction belongs on the wiki. My original idea was to generate the documentation from its current location (at openjpa-project/src/doc/manual/manual.xml), and generate the site and docs together using the mvn site process (the output of which can be seen at http://people.apache.org/~mprudhom/openjpa/site/ ). Other people suggested that we keep the site and docs in a separate, parallel Subversion directory, so I waited to do any further work until we had come to some consensus on how the project site and documentation should be handled. Everything that I've done is currently checked into Subversion, though. Any changes/additions to the docs can be made to openjpa-project/src/doc/manual/manual.xml , which I expect we will relocate to wherever we decide is the best place for it. On Aug 21, 2006, at 4:07 PM, Craig L Russell wrote: On Aug 21, 2006, at 6:53 AM, Bryan Noll wrote: Craig... You seem to be one of the resident experts on infra-related stuff. Can you comment on some of my questions in the mail? Thanks... Bryan Noll wrote: So... I realize that OpenJPA is super-new to Apache, and this is for sure the reason that the documentation is currently located at what appears to be a non-permanent place (http://people.apache.org/~mprudhom/openjpa/site/openjpa-project/manual/index.html). Yes, this is a non-permanent location. It's Marc's personal space in Apache land. - Is there a plan to migrate this stuff do a different location? (either http://wiki.apache.org/incubator/openjpa/ or http://cwiki.apache.org/confluence/display/openjpa/Index) I guess Marc knows best what the plans are. - Is cwiki.apache.org preferred to wiki.apache.org? Well, this is a personal preference, and it turns out that openjpa actually has empty home pages on both sites (I accidentally added some content to the cwiki which can be moved to the wiki). Personally, I'm not familiar with cwiki so I don't understand its advantages or modus operandi. Maybe someone in the group with more experience using these tools can comment. I didn't find that adding a new page was trivial (and no, I didn't rtfm). - There are certain resources that have bad links to non-existent locations in the current documentation. For instance: from here... (http://people.apache.org/~mprudhom/openjpa/site/openjpa-project/manual/jpa_tutorial.html#jpa_tutorial_files
Re: Build data in built artifacts
I dorked with it some more, and got it to the point where it wrote out a properties file with the subversion revision info in it (a la David's example)... but then ran into a wall in terms of getting the scope of that property to hang around long enough to stuff it into. I hopped on the #maven irc at codehaus... and asked around... and it seems like it is simply not possible as of now. The only option I got was to manually create a MANIFEST.MF file that is under subversion control, then filter it so the correct value gets put in that way, but it seems cumbersome to me to have to manually maintain all those files. The next best thing would be to simply stuff a an openjpa-version.properties file in the jar that contains a line like: svn-revision=433722 Seems like a hack because its not actually going in the manifest where it would be ideal... but I guess the information is still there. I'm not sure I like either of those options... Marc Prud'hommeaux wrote: Bryan- FYI, I had played with this a little while ago ... I got the subversion revision number using the maven-antrun-plugin and xmlproperty task to parse the .svn/entries file, but I couldn't figure out how to pass the value of the property from the ant plugin to the global Maven properties so that it could be later embedded using the maven-jar-plugin. If you have any ideas on how to do this (maybe even by writing out a file from ant and reading it back in with Maven), that'd be great. This xmlproperty code that I wrote is actually still in the top-level pom.xml, it's just commented out. On Aug 14, 2006, at 2:14 PM, Bryan Noll wrote: Patrick... Looks like the OpenJPA version number is already getting tossed in there as: Implementation-Version: 0.9.0 We can stuff a subversion revision number in there by using 'maven-jar-plugin'... I just have to play with it a bit in order to get a latest and greatest rev number. Bryan Noll wrote: Lemme take a crack at it... Patrick Linskey wrote: Hi, I think it'd be nice if each of the modules could encode svn revision number and OpenJPA version number information into the built jars, presumably in a manifest entry. Does anyone have any knowledge about how to coerce this type of info into jars in a mvn environment? -Patrick
status of OpenJPA documentation
So... I realize that OpenJPA is super-new to Apache, and this is for sure the reason that the documentation is currently located at what appears to be a non-permanent place (http://people.apache.org/~mprudhom/openjpa/site/openjpa-project/manual/index.html). - Is there a plan to migrate this stuff do a different location? (either http://wiki.apache.org/incubator/openjpa/ or http://cwiki.apache.org/confluence/display/openjpa/Index) - Is cwiki.apache.org preferred to wiki.apache.org? - There are certain resources that have bad links to non-existent locations in the current documentation. For instance: from here... (http://people.apache.org/~mprudhom/openjpa/site/openjpa-project/manual/jpa_tutorial.html#jpa_tutorial_files) trying to get to here... (http://people.apache.org/~mprudhom/openjpa/tutorial/persistence/AnimalMaintenance.java) Marc noted in a previous thread that, in this specific case, the tutorial files simply had not been committed to the apache repo yet. This is something I'm willing to prepare a patch for. Not that the tutorial work is all that glorious, but it seems like something that would be good to have available for folks considering using OpenJPA who want to give the project the 15 minute sniff test. - My real motive in asking these questions is that I've run across some documentation that I'd like to add to, and wondered if/when it was going to make its way to a wiki so people can contribute. - If the only thing stopping this stuff from getting to a wiki is bandwidth of the current dev team, can someone point me in the right direction so I can run with it? Thanks... Bryan
Patch available checkbox in JIRA ...
I've seen a checkbox in JIRA before to indicate whether or not a patch is available... Geronimo comes to mind... is this something that can be had for OpenJPA as well?
Re: Patch available checkbox in JIRA ...
Indicates that someone has attached a patch to the jira which holds the resolution to it. I quick indicator for folks with commit privs to see that someone has something ready for them. Patrick Linskey wrote: I don't follow -- what does the patch-available checkbox indicate? -Patrick
[jira] Updated: (OPENJPA-14) PCEnhancer ant task requires openjpa jars to be on the system classpath or passed into ant with '-lib'
[ http://issues.apache.org/jira/browse/OPENJPA-14?page=all ] Bryan Noll updated OPENJPA-14: -- Attachment: OPENJPA-14.patch1 Attaching patch named: OPENJPA-14.patch1 So, the issue reported originally was not a problem with the code, but a known problem with ant, as can be seen here: http://ant.apache.org/faq.html#delegating-classloader-1.6 The real fix for this is better documentation, which I will throw together. I updated the 'no-product-derivations' in the 'openjpa-kernel/src/main/resources/org/apache/openjpa/conf/localizer.properties' file to provide a hint to people who would've run into the same issue I did. The rest of the patch is to deal with another issue in the same realm as this one, ant that is the fact that the PCEnhancerTask would throw a NPE if you didn't have 'META-INF/persistence.xml' on your system classpath, in $ANT_HOME/lib or supply the dir it was in via the 'ant -lib' argument. To resolve this, I created a new required attribute for the PCEnhancerTask, named 'configFile'... that allows the location of the config file to be declared when running the task. Please provide feedback on the patch if you think I didn't grasp the context of what was going on at a higher level and potentially screwed something else up. PCEnhancer ant task requires openjpa jars to be on the system classpath or passed into ant with '-lib' -- Key: OPENJPA-14 URL: http://issues.apache.org/jira/browse/OPENJPA-14 Project: OpenJPA Issue Type: Bug Components: lib Environment: Windows XP Reporter: Bryan Noll Assigned To: Bryan Noll Attachments: OPENJPA-14.patch1 Ideally, one should be able to run 'ant openjpac' (openjpac would be a target defined in the build script that would use the PCEnhancer task) without having to put the openjpa jars on the system classpath or having to pass them into ant vie the '-lib' argument. Currently this is not possible. The root of the issue can be seen from by looking at the public static String[] getImplementors(String serviceName, ClassLoader loader) method of the Services class. Basically, the call to loader = Thread.currentThread().getContextClassLoader(); returns a ClassLoader with the $ANT_HOME\lib\*.jar and $JAVA_HOME\lib\tools.jar in it... which obviously doesn't contain 'META-INF/services/org.apache.openjpa.conf.ProductDerivation' The exception seen when encountering this issue: java.lang.ExceptionInInitializerError at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:510) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:160) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:151) at org.apache.openjpa.ant.PCEnhancerTask.newConfiguration(PCEnhancerTask.java:77) at org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:170) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.Target.performTasks(Target.java:369) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216) at org.apache.tools.ant.Project.executeTarget(Project.java:1185) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40) at org.apache.tools.ant.Project.executeTargets(Project.java:1068) at org.apache.tools.ant.Main.runBuild(Main.java:668) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:251) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:72) Caused by: java.util.MissingResourceException: Your system is missing product derivations. Product derivations provide configuration options for supported data stores and specifications. You must have a META-INF/services/org.apache.openjpa.conf.ProductDerivation file in your classpath listing the available derivation classes, and some listed class must be instantiable. Typically this file is bundled as part of the distribution. Have you unbundled it, or unbundled its listed classes? at org.apache.openjpa.conf.ProductDerivations.clinit(ProductDerivations.java:53) ... 17 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OPENJPA-14) PCEnhancer ant task requires openjpa jars to be on the system classpath or passed into ant with '-lib'
[ http://issues.apache.org/jira/browse/OPENJPA-14?page=all ] Bryan Noll updated OPENJPA-14: -- Attachment: OPENJPA-14.patch2 Attaching patch named: OPENJPA-14.patch2 Ignore 'OPENJPA-14.patch1 ', I forgot to make the test class I added as part of it. That's the only difference between this one and that. PCEnhancer ant task requires openjpa jars to be on the system classpath or passed into ant with '-lib' -- Key: OPENJPA-14 URL: http://issues.apache.org/jira/browse/OPENJPA-14 Project: OpenJPA Issue Type: Bug Components: lib Environment: Windows XP Reporter: Bryan Noll Assigned To: Bryan Noll Attachments: OPENJPA-14.patch1, OPENJPA-14.patch2 Ideally, one should be able to run 'ant openjpac' (openjpac would be a target defined in the build script that would use the PCEnhancer task) without having to put the openjpa jars on the system classpath or having to pass them into ant vie the '-lib' argument. Currently this is not possible. The root of the issue can be seen from by looking at the public static String[] getImplementors(String serviceName, ClassLoader loader) method of the Services class. Basically, the call to loader = Thread.currentThread().getContextClassLoader(); returns a ClassLoader with the $ANT_HOME\lib\*.jar and $JAVA_HOME\lib\tools.jar in it... which obviously doesn't contain 'META-INF/services/org.apache.openjpa.conf.ProductDerivation' The exception seen when encountering this issue: java.lang.ExceptionInInitializerError at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:510) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:160) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:151) at org.apache.openjpa.ant.PCEnhancerTask.newConfiguration(PCEnhancerTask.java:77) at org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:170) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.Target.performTasks(Target.java:369) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216) at org.apache.tools.ant.Project.executeTarget(Project.java:1185) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40) at org.apache.tools.ant.Project.executeTargets(Project.java:1068) at org.apache.tools.ant.Main.runBuild(Main.java:668) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:251) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:72) Caused by: java.util.MissingResourceException: Your system is missing product derivations. Product derivations provide configuration options for supported data stores and specifications. You must have a META-INF/services/org.apache.openjpa.conf.ProductDerivation file in your classpath listing the available derivation classes, and some listed class must be instantiable. Typically this file is bundled as part of the distribution. Have you unbundled it, or unbundled its listed classes? at org.apache.openjpa.conf.ProductDerivations.clinit(ProductDerivations.java:53) ... 17 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-14) PCEnhancer ant task requires openjpa jars to be on the system classpath or passed into ant with '-lib'
[
http://issues.apache.org/jira/browse/OPENJPA-14?page=comments#action_12428817 ]
Bryan Noll commented on OPENJPA-14:
---
I thought about making it optional, but it just seemed odd to me that you'd
have to have 'META-INF/persistence.xml' in one of the places I mentioned
earlier...
1) system classpath
2)$ANT_HOME/lib
3) ant -lib dir_where_META_INF_is
4) I forgot about this before... but a 4th would be ${user.home}/.ant/lib
...in particular, the first two options seem like a round peg in a square hole.
Making it optional would be easy, but I just thought making it required would
save users the problem of having to get that on their classpath.
Maybe I'm not seeing the use case? Like I said though, changing it to optional
is trivial.
PCEnhancer ant task requires openjpa jars to be on the system classpath or
passed into ant with '-lib'
--
Key: OPENJPA-14
URL: http://issues.apache.org/jira/browse/OPENJPA-14
Project: OpenJPA
Issue Type: Bug
Components: lib
Environment: Windows XP
Reporter: Bryan Noll
Assigned To: Bryan Noll
Attachments: OPENJPA-14.patch1, OPENJPA-14.patch2
Ideally, one should be able to run 'ant openjpac' (openjpac would be a
target defined in the build script that would use the PCEnhancer task)
without having to put the openjpa jars on the system classpath or having to
pass them into ant vie the '-lib' argument. Currently this is not possible.
The root of the issue can be seen from by looking at the public static
String[] getImplementors(String serviceName, ClassLoader loader) method of
the Services class. Basically, the call to
loader = Thread.currentThread().getContextClassLoader();
returns a ClassLoader with the $ANT_HOME\lib\*.jar and
$JAVA_HOME\lib\tools.jar in it... which obviously doesn't contain
'META-INF/services/org.apache.openjpa.conf.ProductDerivation'
The exception seen when encountering this issue:
java.lang.ExceptionInInitializerError
at
org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:510)
at
org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:160)
at
org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:151)
at
org.apache.openjpa.ant.PCEnhancerTask.newConfiguration(PCEnhancerTask.java:77)
at
org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:170)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.Main.runBuild(Main.java:668)
at org.apache.tools.ant.Main.startAnt(Main.java:187)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:251)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:72)
Caused by: java.util.MissingResourceException: Your system is missing product
derivations. Product derivations provide configuration options for supported
data stores and specifications. You must have a
META-INF/services/org.apache.openjpa.conf.ProductDerivation file in your
classpath listing the available derivation classes, and some listed class
must be instantiable. Typically this file is bundled as part of the
distribution. Have you unbundled it, or unbundled its listed classes?
at
org.apache.openjpa.conf.ProductDerivations.clinit(ProductDerivations.java:53)
... 17 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (OPENJPA-14) PCEnhancer ant task requires openjpa jars to be on the system classpath or passed into ant with '-lib'
Saw this after I responded... I'll play around with it... Thanks... Abe White (JIRA) wrote: [ http://issues.apache.org/jira/browse/OPENJPA-14?page=comments#action_12428815 ] Abe White commented on OPENJPA-14: -- Note that we already have an available way to set the config file or resource location: any-openjpa-task config propertiesFile=.../ -- or -- config properties=.../ /any-openjpa-task The config element also lets you specify any property directly, like: config connectionURL=.../ This works b/c our AbstractTask has a createConfig() method that returns the Configuration instance (in this case, an OpenJPAConfiguration or JDBCConfiguration subclass instance depending on the task), so all bean methods are settable. The config element isn't required, but I agree with Patrick that it shouldn't be, given that we'll detect persistence.xml if it's available in the classpath. IMO, it would be better to fix the NPE to have a good error message than to require an explicit config file declaration. PCEnhancer ant task requires openjpa jars to be on the system classpath or passed into ant with '-lib' -- Key: OPENJPA-14 URL: http://issues.apache.org/jira/browse/OPENJPA-14 Project: OpenJPA Issue Type: Bug Components: lib Environment: Windows XP Reporter: Bryan Noll Assigned To: Bryan Noll Attachments: OPENJPA-14.patch1, OPENJPA-14.patch2 Ideally, one should be able to run 'ant openjpac' (openjpac would be a target defined in the build script that would use the PCEnhancer task) without having to put the openjpa jars on the system classpath or having to pass them into ant vie the '-lib' argument. Currently this is not possible. The root of the issue can be seen from by looking at the public static String[] getImplementors(String serviceName, ClassLoader loader) method of the Services class. Basically, the call to loader = Thread.currentThread().getContextClassLoader(); returns a ClassLoader with the $ANT_HOME\lib\*.jar and $JAVA_HOME\lib\tools.jar in it... which obviously doesn't contain 'META-INF/services/org.apache.openjpa.conf.ProductDerivation' The exception seen when encountering this issue: java.lang.ExceptionInInitializerError at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:510) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:160) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:151) at org.apache.openjpa.ant.PCEnhancerTask.newConfiguration(PCEnhancerTask.java:77) at org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:170) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.Target.performTasks(Target.java:369) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216) at org.apache.tools.ant.Project.executeTarget(Project.java:1185) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40) at org.apache.tools.ant.Project.executeTargets(Project.java:1068) at org.apache.tools.ant.Main.runBuild(Main.java:668) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:251) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:72) Caused by: java.util.MissingResourceException: Your system is missing product derivations. Product derivations provide configuration options for supported data stores and specifications. You must have a META-INF/services/org.apache.openjpa.conf.ProductDerivation file in your classpath listing the available derivation classes, and some listed class must be instantiable. Typically this file is bundled as part of the distribution. Have you unbundled it, or unbundled its listed classes? at org.apache.openjpa.conf.ProductDerivations.clinit(ProductDerivations.java:53) ... 17 more
[jira] Updated: (OPENJPA-14) PCEnhancer ant task requires openjpa jars to be on the system classpath or passed into ant with '-lib'
[ http://issues.apache.org/jira/browse/OPENJPA-14?page=all ] Bryan Noll updated OPENJPA-14: -- Attachment: OPENJPA-14.patch3 Attaching patch file: OPENJPA-14.patch3 Ignore patch1 and patch2 Thanks for pointing out the 'properties' and 'propertiesFile' values... that's exactly what I thought was missing and what I needed. The patch is a simple update to give someone a hint about where their jars need to go so they don't get the original MissingResourceException. PCEnhancer ant task requires openjpa jars to be on the system classpath or passed into ant with '-lib' -- Key: OPENJPA-14 URL: http://issues.apache.org/jira/browse/OPENJPA-14 Project: OpenJPA Issue Type: Bug Components: lib Environment: Windows XP Reporter: Bryan Noll Assigned To: Bryan Noll Attachments: OPENJPA-14.patch1, OPENJPA-14.patch2, OPENJPA-14.patch3 Ideally, one should be able to run 'ant openjpac' (openjpac would be a target defined in the build script that would use the PCEnhancer task) without having to put the openjpa jars on the system classpath or having to pass them into ant vie the '-lib' argument. Currently this is not possible. The root of the issue can be seen from by looking at the public static String[] getImplementors(String serviceName, ClassLoader loader) method of the Services class. Basically, the call to loader = Thread.currentThread().getContextClassLoader(); returns a ClassLoader with the $ANT_HOME\lib\*.jar and $JAVA_HOME\lib\tools.jar in it... which obviously doesn't contain 'META-INF/services/org.apache.openjpa.conf.ProductDerivation' The exception seen when encountering this issue: java.lang.ExceptionInInitializerError at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:510) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:160) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:151) at org.apache.openjpa.ant.PCEnhancerTask.newConfiguration(PCEnhancerTask.java:77) at org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:170) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.Target.performTasks(Target.java:369) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216) at org.apache.tools.ant.Project.executeTarget(Project.java:1185) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40) at org.apache.tools.ant.Project.executeTargets(Project.java:1068) at org.apache.tools.ant.Main.runBuild(Main.java:668) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:251) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:72) Caused by: java.util.MissingResourceException: Your system is missing product derivations. Product derivations provide configuration options for supported data stores and specifications. You must have a META-INF/services/org.apache.openjpa.conf.ProductDerivation file in your classpath listing the available derivation classes, and some listed class must be instantiable. Typically this file is bundled as part of the distribution. Have you unbundled it, or unbundled its listed classes? at org.apache.openjpa.conf.ProductDerivations.clinit(ProductDerivations.java:53) ... 17 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (OPENJPA-14) PCEnhancer ant task requires openjpa jars to be on the system classpath or passed into ant with '-lib'
PCEnhancer ant task requires openjpa jars to be on the system classpath or passed into ant with '-lib' -- Key: OPENJPA-14 URL: http://issues.apache.org/jira/browse/OPENJPA-14 Project: OpenJPA Issue Type: Bug Components: lib Environment: Windows XP Reporter: Bryan Noll Ideally, one should be able to run 'ant openjpac' (openjpac would be a target defined in the build script that would use the PCEnhancer task) without having to put the openjpa jars on the system classpath or having to pass them into ant vie the '-lib' argument. Currently this is not possible. The root of the issue can be seen from by looking at the public static String[] getImplementors(String serviceName, ClassLoader loader) method of the Services class. Basically, the call to loader = Thread.currentThread().getContextClassLoader(); returns a ClassLoader with the $ANT_HOME\lib\*.jar and $JAVA_HOME\lib\tools.jar in it... which obviously doesn't contain 'META-INF/services/org.apache.openjpa.conf.ProductDerivation' The exception seen when encountering this issue: java.lang.ExceptionInInitializerError at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:510) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:160) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:151) at org.apache.openjpa.ant.PCEnhancerTask.newConfiguration(PCEnhancerTask.java:77) at org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:170) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.Target.performTasks(Target.java:369) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216) at org.apache.tools.ant.Project.executeTarget(Project.java:1185) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40) at org.apache.tools.ant.Project.executeTargets(Project.java:1068) at org.apache.tools.ant.Main.runBuild(Main.java:668) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:251) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:72) Caused by: java.util.MissingResourceException: Your system is missing product derivations. Product derivations provide configuration options for supported data stores and specifications. You must have a META-INF/services/org.apache.openjpa.conf.ProductDerivation file in your classpath listing the available derivation classes, and some listed class must be instantiable. Typically this file is bundled as part of the distribution. Have you unbundled it, or unbundled its listed classes? at org.apache.openjpa.conf.ProductDerivations.clinit(ProductDerivations.java:53) ... 17 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (OPENJPA-14) PCEnhancer ant task requires openjpa jars to be on the system classpath or passed into ant with '-lib'
To whom it may concern... Can I request the necessary karma so that I can assign this issue to myself... or could someone please assign it to me? Thanks... Bryan Noll (JIRA) wrote: PCEnhancer ant task requires openjpa jars to be on the system classpath or passed into ant with '-lib' -- Key: OPENJPA-14 URL: http://issues.apache.org/jira/browse/OPENJPA-14 Project: OpenJPA Issue Type: Bug Components: lib Environment: Windows XP Reporter: Bryan Noll Ideally, one should be able to run 'ant openjpac' (openjpac would be a target defined in the build script that would use the PCEnhancer task) without having to put the openjpa jars on the system classpath or having to pass them into ant vie the '-lib' argument. Currently this is not possible. The root of the issue can be seen from by looking at the public static String[] getImplementors(String serviceName, ClassLoader loader) method of the Services class. Basically, the call to loader = Thread.currentThread().getContextClassLoader(); returns a ClassLoader with the $ANT_HOME\lib\*.jar and $JAVA_HOME\lib\tools.jar in it... which obviously doesn't contain 'META-INF/services/org.apache.openjpa.conf.ProductDerivation' The exception seen when encountering this issue: java.lang.ExceptionInInitializerError at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:510) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:160) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:151) at org.apache.openjpa.ant.PCEnhancerTask.newConfiguration(PCEnhancerTask.java:77) at org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:170) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.Target.performTasks(Target.java:369) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216) at org.apache.tools.ant.Project.executeTarget(Project.java:1185) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40) at org.apache.tools.ant.Project.executeTargets(Project.java:1068) at org.apache.tools.ant.Main.runBuild(Main.java:668) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:251) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:72) Caused by: java.util.MissingResourceException: Your system is missing product derivations. Product derivations provide configuration options for supported data stores and specifications. You must have a META-INF/services/org.apache.openjpa.conf.ProductDerivation file in your classpath listing the available derivation classes, and some listed class must be instantiable. Typically this file is bundled as part of the distribution. Have you unbundled it, or unbundled its listed classes? at org.apache.openjpa.conf.ProductDerivations.clinit(ProductDerivations.java:53) ... 17 more
Re: [jira] Commented: (OPENJPA-8) java.util.MissingResourceException: system is missing product derivations
So... before I got update the jira, I want to go make sure it's not
something stupid I'm doing.
Classpath defined like this in ant...
path id=project.classpath
pathelement location=${basedir}/lib/commons-collections-3.2.jar/
pathelement location=${basedir}/lib/commons-lang-2.1.jar/
pathelement location=${basedir}/lib/commons-logging-1.0.4.jar/
pathelement location=${basedir}/lib/commons-pool-1.3.jar/
pathelement location=${basedir}/lib/derby-10.1.3.1.jar/
pathelement
location=${basedir}/lib/geronimo-j2ee-connector_1.5_spec-1.0.1.jar/
pathelement
location=${basedir}/lib/geronimo-jms_1.1_spec-1.0.1.jar/
pathelement
location=${basedir}/lib/geronimo-jta_1.0.1B_spec-1.0.1.jar/
pathelement location=${basedir}/lib/openjpa-jdbc-0.9.0.jar/
pathelement location=${basedir}/lib/openjpa-jdbc-5-0.9.0.jar/
pathelement location=${basedir}/lib/openjpa-kernel-0.9.0.jar/
pathelement location=${basedir}/lib/openjpa-kernel-4-0.9.0.jar/
pathelement location=${basedir}/lib/openjpa-kernel-5-0.9.0.jar/
pathelement location=${basedir}/lib/openjpa-lib-0.9.0.jar/
pathelement
location=${basedir}/lib/openjpa-persistence-0.9.0.jar/
pathelement
location=${basedir}/lib/openjpa-persistence-jdbc-0.9.0.jar/
pathelement location=${basedir}/lib/openjpa-project-0.9.0.jar/
pathelement location=${basedir}/lib/openjpa-xmlstore-0.9.0.jar/
pathelement location=${basedir}/lib/persistence-api-1.0.jar/
pathelement location=${basedir}/lib/serp-1.11.0.jar/
/path
(have also tried it like)
path id=project.classpath
fileset dir=${basedir}/lib includes=*.jar/
/path
===
Task defined like...
taskdef name=openjpac
classname=org.apache.openjpa.ant.PCEnhancerTask
classpath refid=project.classpath /
/taskdef
Target defined like...
target name=enhance-src
openjpac
classpath refid=project.classpath/
fileset dir=.
include
name=${basedir}/src/main/java/tutorial/persistence/*.java /
/fileset
/openjpac
/target
and I still get that same MissingResourceException...
When digging into the Services.getImplementors(String serviceName,
ClassLoader loader) method, I print out all the URL's returned by a call
to URLClassLoader.getURLs, and it gives me the following:
file:/c:/tools/apache-ant-1.6.5/lib/ant-antlr.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-apache-bcel.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-apache-bsf.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-apache-log4j.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-apache-oro.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-apache-regexp.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-apache-resolver.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-commons-logging.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-commons-net.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-icontract.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-jai.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-javamail.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-jdepend.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-jmf.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-jsch.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-junit.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-launcher.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-netrexx.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-nodeps.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-starteam.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-stylebook.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-swing.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-trax.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-vaj.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-weblogic.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-xalan1.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant-xslp.jar
file:/c:/tools/apache-ant-1.6.5/lib/ant.jar
file:/c:/tools/apache-ant-1.6.5/lib/junit-3.8.1.jar
file:/c:/tools/apache-ant-1.6.5/lib/junit.jar
file:/c:/tools/apache-ant-1.6.5/lib/xercesImpl.jar
file:/c:/tools/apache-ant-1.6.5/lib/xml-apis.jar
file:/c:/tools/jdk1.5.0_06/lib/tools.jar
Obviously, the
'META-INF/services/org.apache.openjpa.conf.ProductDerivation' file is
not gonna be in any of those libraries.
What am I missing?
Neil Hornbeck (JIRA) wrote:
[ http://issues.apache.org/jira/browse/OPENJPA-8?page=comments#action_12427870 ]
Neil Hornbeck commented on OPENJPA-8:
-
Updated to revision 431325. I am now able to us the Enhancer from the command
line.
java.util.MissingResourceException: system is missing product derivations
-
Key: OPENJPA-8
URL: http://issues.apache.org/jira/browse/OPENJPA-8
Project: OpenJPA
Issue Type: Bug
Environment: Windows 2000, using ant build.
Reporter: Neil Hornbeck
Priority: Blocker
I am trying
[jira] Created: (OPENJPA-11) No Javadoc available on the website
No Javadoc available on the website --- Key: OPENJPA-11 URL: http://issues.apache.org/jira/browse/OPENJPA-11 Project: OpenJPA Issue Type: Task Components: docs Environment: a browser Reporter: Bryan Noll No Javadoc available on the website -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OPENJPA-11) No Javadoc available on the website
[ http://issues.apache.org/jira/browse/OPENJPA-11?page=all ] Bryan Noll updated OPENJPA-11: -- Attachment: javadoc.patch Modifications to the following files from the 'site' directory in svn (not the 'trunk'): xdocs/javadoc.xml docs/javadoc.html This patch (and subsequent tar.gz attachments) may be more than necessary. It contains updates necessary to include the javadoc for all of the following: openjpa-jdbc-5 openjpa-jdbc openjpa-kernel-4 openjpa-kernel-5 openjpa-kernel openjpa-lib openjpa-persistence openjpa-persistence-jdbc openjpa-xmlstore If it is not necessary to have all of those available on the site, I can re-work the patch and attachments. No Javadoc available on the website --- Key: OPENJPA-11 URL: http://issues.apache.org/jira/browse/OPENJPA-11 Project: OpenJPA Issue Type: Task Components: docs Environment: a browser Reporter: Bryan Noll Attachments: javadoc.patch No Javadoc available on the website -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OPENJPA-11) No Javadoc available on the website
[ http://issues.apache.org/jira/browse/OPENJPA-11?page=all ] Bryan Noll updated OPENJPA-11: -- Attachment: openjpa-javadocs.tar.gz Extract into the 'site/docs' directory. No Javadoc available on the website --- Key: OPENJPA-11 URL: http://issues.apache.org/jira/browse/OPENJPA-11 Project: OpenJPA Issue Type: Task Components: docs Environment: a browser Reporter: Bryan Noll Attachments: javadoc.patch, openjpa-javadocs.tar.gz No Javadoc available on the website -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OPENJPA-11) No Javadoc available on the website
[ http://issues.apache.org/jira/browse/OPENJPA-11?page=all ] Bryan Noll updated OPENJPA-11: -- Attachment: openjpa-javadocs-compressed.tar.gz Extract into the 'site/docs' directory. No Javadoc available on the website --- Key: OPENJPA-11 URL: http://issues.apache.org/jira/browse/OPENJPA-11 Project: OpenJPA Issue Type: Task Components: docs Environment: a browser Reporter: Bryan Noll Attachments: javadoc.patch, openjpa-javadocs-compressed.tar.gz, openjpa-javadocs.tar.gz No Javadoc available on the website -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Example files from tutorial in documentation - can't get 'em
I'll walk through these. If they will open source them, that's great... otherwise... I can write up something simple that hits on all the same basic pieces of functionality, and those can be what are used for the tutorial. Doesn't matter too much to me. I don't mean to harp on the whole thing too much, I just think it's a good idea to have a basic tutorial that's available for downloading for new users. --Bryan Patrick Linskey wrote: I'm around, too, but am traveling and working too much. Regarding tutorial: what do you think of the Kodo tutorial? I believe that we could convince BEA to contribute that code to OpenJPA if we'd like to use it as a starting point. You can get it in the Kodo 4.0 download: http://commerce.bea.com/showproduct.jsp?family=KODOmajor=4.0minor=0 -Patrick
openjpac for enhancing classes
Can anyone tell me where to acquire this 'openjpac' tool? I don't see it anywhere in the source or the zip files built by m2. Thanks... Bryan
Re: Example files from tutorial in documentation - can't get 'em
So... is there any way to get ahold of those tutorial files so I can mess around with them a touch. If there's anything at all I can do to help, please let me know. I'd like to be able to play with them if possible. Is anyone besides Marc reading this thread? Anyone out there? Bryan Noll wrote: OK If there's something I can do to help, please let me know... On 8/8/06, *Marc Prud'hommeaux* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Bryan- We just haven't yet gotten around to reviewing and converting the tutorial from the Kodo code base yet, or figuring out which module it should go into (or its own module). On Aug 8, 2006, at 6:07 AM, Bryan Noll wrote: OK... is there something I can do to help then? Is there something blocking them being checked in that I can do? Thanks... Marc Prud'hommeaux wrote: Bryan- Unfortunately, the tutorial files have yet to be committed to the OpenJPA repository, so currently the tutorial in the documentation snapshot is incomplete. On Aug 8, 2006, at 12:50 AM, Bryan Noll wrote: Hello all... I'm reading through the documentation a bit, and noticed that the sample files (http://people.apache.org/~mprudhom/openjpa/site/ http://people.apache.org/%7Emprudhom/openjpa/site/ openjpa-project/manual/jpa_tutorial.html#jpa_tutorial_files) that are part of 'The Pet Shop' tutorial in section 2.1.1 of the documentation are no longer available. eg... http://people.apache.org/~mprudhom/openjpa/tutorial/ http://people.apache.org/%7Emprudhom/openjpa/tutorial/ persistence/AnimalMaintenance.java gives me a 404 Can somebody help me with this? mprudhom maybe? Thanks... Bryan
Example files from tutorial in documentation - can't get 'em
Hello all... I'm reading through the documentation a bit, and noticed that the sample files (http://people.apache.org/~mprudhom/openjpa/site/openjpa-project/manual/jpa_tutorial.html#jpa_tutorial_files) that are part of 'The Pet Shop' tutorial in section 2.1.1 of the documentation are no longer available. eg... http://people.apache.org/~mprudhom/openjpa/tutorial/persistence/AnimalMaintenance.java gives me a 404 Can somebody help me with this? mprudhom maybe? Thanks... Bryan
