Re: JCA Resource Adapter?
This is a great post, thanks for the details. More below... (I think this thread is going to go down in history as having the most usage of three letter abbreviations starting with J and ending with A) On Aug 9, 2006, at 6:22 PM, Patrick Linskey wrote: In the EJB3 spec, we defined a contract between the JPA impl and the "container" (EJB or otherwise), and we convinced the JTA team to add the TransactionSynchronizationRegistry interface. So, JTA + the JPA/container contract are the best way to use OpenJPA in a Java EE 5 environment. [...] For J2EE 1.4 apps, JCA does provide some theoretical utility for hooking into an appserver's standard JCA configuration mechanisms, and for getting registered in JNDI in a somewhat-standard way. [...] I guess that we need to decide what the story should be for deploying OpenJPA into a pre-Java EE 5 appserver. If we decide that JCA is that way, then maybe the best approach is for BEA to contribute the existing JCA wrappers around OpenJPA. OK. Here is the world from the Geronimo perspective. We've also noticed these shortcomings and have our own implementation of JTA which includes functionality *identical* to the TransactionSynchronizationRegistry, it's called our TransactionContextManager. It's essentially a bucket where we can put connections and cmp instance state and have it tracked with the transaction state. Our JCA implementation is fundamentally bound into this and things like our existing CMP support rely critically on it. I.e. our JCA implementation is bound into our extended JTA implementation as is our CMP implementation. All things coordinate through this extended JTA implementation. I think we have the functionality we need to do support JPA through JCA and our extended JTA, we're just one Resource Adapter and possibly a few customizations short. We definitely plan to readapt this functionality into the JEE 5 TransactionSynchronizationRegistry and so on, but for now that would be far harder. We're still J2EE 1.4 and are very much looking for a way to get OpenJPA in and usable now. I haven't seen the resource adapter code, but it may even be possible to cook up a wrapped version that even people using Geronimo 1.1 or 1.1.1 could use. -David Thoughts? -Patrick -- Patrick Linskey BEA Systems, Inc. -Original Message- From: Kevin Sutter [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2006 2:43 PM To: open-jpa-dev@incubator.apache.org Subject: JCA Resource Adapter? According to Section 3 (J2EE Tutorials, specifically 3.2 J2EE Installation Types), the recommended approach to using OpenJPA in a managed environment is via the JCA rar file: JCA: OpenJPA implements the JCA 1.0 spec, and the openjpa-persistence.rarfile that comes in the jca/persistence directory of the distribution can be installed as any other JCA connection resource. This is the preferred way to integrate OpenJPA into a pre-J2EE 5 environment. It allows for simple installation (usually involving uploading or copying openjpa-persistence.rar into the application server's deployment directory), and guided configuration on many appservers. Is this supposed to be part of the OpenJPA deliverable? I do not seem to building the .rar file, nor can I find any reference to the jca/persistence directory that is mentioned above. Should I open a JIRA bug for this? Thanks, Kevin __ _ 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: JCA Resource Adapter?
On 8/9/06, Patrick Linskey <[EMAIL PROTECTED]> wrote: Moving forward, JCA is unlikely to be the best way to integrate OpenJPA into a container. JCA does two things: it provides a framework for integrating transactional resources into a JTA environment, and it provides lifecycle / configuration / bootstrapping hooks. Sadly, it also suffers from some unfortunate weaknesses in how transaction semantics are defined that basically render it unusable for things like OpenJPA -- OpenJPA needs to be notified at certain phases in the lifecycle of a transaction, and those lifecycle points are not available in JCA. Agree. In the EJB3 spec, we defined a contract between the JPA impl and the "container" (EJB or otherwise), and we convinced the JTA team to add the TransactionSynchronizationRegistry interface. So, JTA + the JPA/container contract are the best way to use OpenJPA in a Java EE 5 environment. Agree. For J2EE 1.4 apps, JCA does provide some theoretical utility for hooking into an appserver's standard JCA configuration mechanisms, and for getting registered in JNDI in a somewhat-standard way. In any event, the JCA impl code is not currently part of the OpenJPA codebase; that's a bug in the docs. I guess that we need to decide what the story should be for deploying OpenJPA into a pre-Java EE 5 appserver. If we decide that JCA is that way, then maybe the best approach is for BEA to contribute the existing JCA wrappers around OpenJPA. Thoughts? Even with its short-comings, I liked the idea of wrappering OpenJPA as a JCA Resource Adapter for pre-Java EE 5 appservers. It seems a bit better than just using the standard Application-managed interfaces. And, since many of us have customers that are on pre-Java EE 5 appservers, it seems like a good alternative. -Patrick -- Patrick Linskey BEA Systems, Inc. > -Original Message- > From: Kevin Sutter [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 09, 2006 2:43 PM > To: open-jpa-dev@incubator.apache.org > Subject: JCA Resource Adapter? > > According to Section 3 (J2EE Tutorials, specifically 3.2 J2EE > Installation > Types), the recommended approach to using OpenJPA in a > managed environment > is via the JCA rar file: > > JCA: OpenJPA implements the JCA 1.0 spec, and the > openjpa-persistence.rarfile that comes in the > jca/persistence directory of the distribution can be > installed as any other > JCA connection resource. This is the preferred way to > integrate OpenJPA into > a pre-J2EE 5 environment. It allows for simple installation (usually > involving uploading or copying openjpa-persistence.rar into > the application > server's deployment directory), and guided configuration on > many appservers. > > Is this supposed to be part of the OpenJPA deliverable? I do > not seem to > building the .rar file, nor can I find any reference to the > jca/persistence > directory that is mentioned above. Should I open a JIRA bug for this? > > Thanks, > Kevin > ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Commented: (OPENJPA-10) persistence unit name should be default diagnostic context for standard OpenJPA log impl
[ http://issues.apache.org/jira/browse/OPENJPA-10?page=comments#action_12427071 ] Patrick Linskey commented on OPENJPA-10: To implement this, we will need to change LogFactoryImpl to check for a PU name during its configuration. This probably means making LogFactoryImpl implement Configurable, and then doing the appropriate processing at the right points in the Configurable's lifecycle. I do not know if the PU name is available directly from an OpenJPAConfiguration; we may need to do some work to register the PU name with the OpenJPAConfiguration, probably from PersistenceProviderImpl. > persistence unit name should be default diagnostic context for standard > OpenJPA log impl > > > Key: OPENJPA-10 > URL: http://issues.apache.org/jira/browse/OPENJPA-10 > Project: OpenJPA > Issue Type: Improvement >Reporter: Patrick Linskey >Priority: Minor > > OpenJPA's default logging implementation has a concept of a diagnostic > context, roughly stolen from log4j. The basic idea is that in a configuration > file, the user can specify a diagnostic context string that will be printed > out with each log message. The result is that if a user has multiple > EntityManagerFactories running in the same JVM, she can distinguish between > the different logging outputs, even if they all just go to stderr. > The JPA spec requires that persistence units are named uniquely. This > presents us with an opportunity: we could check for the existence of multiple > EMFs and, if found and the user did not specify a diagnostic context, > automatically set the logging diagnostic context based on the name of the > persistence unit. -- 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-10) persistence unit name should be default diagnostic context for standard OpenJPA log impl
persistence unit name should be default diagnostic context for standard OpenJPA log impl Key: OPENJPA-10 URL: http://issues.apache.org/jira/browse/OPENJPA-10 Project: OpenJPA Issue Type: Improvement Reporter: Patrick Linskey Priority: Minor OpenJPA's default logging implementation has a concept of a diagnostic context, roughly stolen from log4j. The basic idea is that in a configuration file, the user can specify a diagnostic context string that will be printed out with each log message. The result is that if a user has multiple EntityManagerFactories running in the same JVM, she can distinguish between the different logging outputs, even if they all just go to stderr. The JPA spec requires that persistence units are named uniquely. This presents us with an opportunity: we could check for the existence of multiple EMFs and, if found and the user did not specify a diagnostic context, automatically set the logging diagnostic context based on the name of the persistence unit. -- 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: JCA Resource Adapter?
Moving forward, JCA is unlikely to be the best way to integrate OpenJPA into a container. JCA does two things: it provides a framework for integrating transactional resources into a JTA environment, and it provides lifecycle / configuration / bootstrapping hooks. Sadly, it also suffers from some unfortunate weaknesses in how transaction semantics are defined that basically render it unusable for things like OpenJPA -- OpenJPA needs to be notified at certain phases in the lifecycle of a transaction, and those lifecycle points are not available in JCA. In the EJB3 spec, we defined a contract between the JPA impl and the "container" (EJB or otherwise), and we convinced the JTA team to add the TransactionSynchronizationRegistry interface. So, JTA + the JPA/container contract are the best way to use OpenJPA in a Java EE 5 environment. For J2EE 1.4 apps, JCA does provide some theoretical utility for hooking into an appserver's standard JCA configuration mechanisms, and for getting registered in JNDI in a somewhat-standard way. In any event, the JCA impl code is not currently part of the OpenJPA codebase; that's a bug in the docs. I guess that we need to decide what the story should be for deploying OpenJPA into a pre-Java EE 5 appserver. If we decide that JCA is that way, then maybe the best approach is for BEA to contribute the existing JCA wrappers around OpenJPA. Thoughts? -Patrick -- Patrick Linskey BEA Systems, Inc. > -Original Message- > From: Kevin Sutter [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 09, 2006 2:43 PM > To: open-jpa-dev@incubator.apache.org > Subject: JCA Resource Adapter? > > According to Section 3 (J2EE Tutorials, specifically 3.2 J2EE > Installation > Types), the recommended approach to using OpenJPA in a > managed environment > is via the JCA rar file: > > JCA: OpenJPA implements the JCA 1.0 spec, and the > openjpa-persistence.rarfile that comes in the > jca/persistence directory of the distribution can be > installed as any other > JCA connection resource. This is the preferred way to > integrate OpenJPA into > a pre-J2EE 5 environment. It allows for simple installation (usually > involving uploading or copying openjpa-persistence.rar into > the application > server's deployment directory), and guided configuration on > many appservers. > > Is this supposed to be part of the OpenJPA deliverable? I do > not seem to > building the .rar file, nor can I find any reference to the > jca/persistence > directory that is mentioned above. Should I open a JIRA bug for this? > > Thanks, > Kevin > ___ 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: openjpac for enhancing classes
'java org.apache.openjpa.enhance.PCEnhancer' At some point, this and other scripts will make their way into the openjpa-project directory, such that they land in a built distribution. -Patrick -- Patrick Linskey BEA Systems, Inc. > -Original Message- > From: Bryan Noll [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 09, 2006 3:59 PM > To: open-jpa-dev@incubator.apache.org > Subject: 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 > ___ 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.
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: JCA Resource Adapter?
It's funny you mention that, I bugged Patrick about it offline earlier this week. Same on me for not just hitting the list. I was thinking to use the JCA approach in Geronimo under the covers for the container-managed entitymanager functionality. -David On Aug 9, 2006, at 2:42 PM, Kevin Sutter wrote: According to Section 3 (J2EE Tutorials, specifically 3.2 J2EE Installation Types), the recommended approach to using OpenJPA in a managed environment is via the JCA rar file: JCA: OpenJPA implements the JCA 1.0 spec, and the openjpa-persistence.rarfile that comes in the jca/persistence directory of the distribution can be installed as any other JCA connection resource. This is the preferred way to integrate OpenJPA into a pre-J2EE 5 environment. It allows for simple installation (usually involving uploading or copying openjpa-persistence.rar into the application server's deployment directory), and guided configuration on many appservers. Is this supposed to be part of the OpenJPA deliverable? I do not seem to building the .rar file, nor can I find any reference to the jca/ persistence directory that is mentioned above. Should I open a JIRA bug for this? Thanks, Kevin
JCA Resource Adapter?
According to Section 3 (J2EE Tutorials, specifically 3.2 J2EE Installation Types), the recommended approach to using OpenJPA in a managed environment is via the JCA rar file: JCA: OpenJPA implements the JCA 1.0 spec, and the openjpa-persistence.rarfile that comes in the jca/persistence directory of the distribution can be installed as any other JCA connection resource. This is the preferred way to integrate OpenJPA into a pre-J2EE 5 environment. It allows for simple installation (usually involving uploading or copying openjpa-persistence.rar into the application server's deployment directory), and guided configuration on many appservers. Is this supposed to be part of the OpenJPA deliverable? I do not seem to building the .rar file, nor can I find any reference to the jca/persistence directory that is mentioned above. Should I open a JIRA bug for this? Thanks, Kevin
MappedSuperclasses
Can a MappedSuperclass extend an Entity? I've run into a problem during validation of a MappedSuperclass. I have an abstract class (AbstractEmployee) with the @Entity and @Id annotations. The MappedSuperclass (AbstractFullTimeEmployee) extends it. Finally a concrete entity class (FulltimeExemptEmployee) extends the MappedSuperclass. When the OpenJPA kernel validates the concrete class I get a warning like this : 2740 WARN [main] openjpa.Enhance - An exception was thrown while attempting to perform class file transformation on "mdd/entities/FullTimeExemptEmployee": <4|true|0.9.0> org.apache.openjpa.util.MetaDataException: Type "class mdd.entities.AbstractFullTimeEmployee" does not declare the same identity-type as its persistent superclass. at org.apache.openjpa.meta.ClassMetaData.validateIdentity( ClassMetaData.java:1642) . . . The identity type for MappedSuperclasses is set to ClassMetaData.ID_UNKNOWNin AnnotationPersistenceMetaDataParser.parseClassAnnotations(). Which seems to ensure that the identity type for a MappedSuperclass will never match the id type for its superclass (whenever the superclass has an ID). I don't see anything in the the spec that prevents this scenario, should this be valid? I know my example isn't the best, but I hope it at least helps to illustrate the issue. Thanks, -- -Michael Dick
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=KODO&major=4.0&minor=0 -Patrick
[jira] Created: (OPENJPA-9) PCEnhancer not processing multiple PU's defined within a single persistence.xml file
PCEnhancer not processing multiple PU's defined within a single persistence.xml file Key: OPENJPA-9 URL: http://issues.apache.org/jira/browse/OPENJPA-9 Project: OpenJPA Issue Type: Bug Components: jpa Reporter: Kevin Sutter >From a discussion with Patrick on the dev mailing list... = Me: According to the JPA spec, we can define multiple persistence-units in a single persistence.xml file. But, when I try to use this persistence.xml file as input to the PCEnhancer, it is only processing the first persistence-unit that is defined. I traced through the code and found that this is the case. When the persistence.xml file is processed, a "null" name is passed in for the desired persistence-unit (in the ConfigurationProviderImpl.load method) and, thus, only the first one defined is returned and used by the PCEnhancer. Patrick: IMO, the correct behavior should be: - PCEnhancer run with no arguments should load all the PUs in the classpath, find the OpenJPA (or unspecified) PUs, and run against all the classes defined by those PUs (including auto-scanning for PUs so configured). - The developer should not need to specify META-INF/persistence.xml when invoking the PCEnhancer. - We may want to provide a means to specify specific PUs to process. For example: java ...PCEnhancer -p META-INF/persistence.xml#foo or maybe just java ...PCEnhancer -p #foo for shorthand. Regardless, the current behavior seems wrong, and it seems that the best initial change would be to make PCEnhancer load all the PUs (the first bullet above), which means manually loading the META-INF/persistence.xml resources and finding the ones that are OpenJPA PUs, rather than relying on the javax.persistence.Persistence helper method to load them. = Writing this bug report so as not to lose track of this problem. -- 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
