[jira] Resolved: (OPENJPA-23) -418 sqlexception using DB2 and EJB QL with SQRT or MOD
[
https://issues.apache.org/jira/browse/OPENJPA-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marc Prud'hommeaux resolved OPENJPA-23.
---
Resolution: Fixed
Assignee: Marc Prud'hommeaux
I am fairly certain this was fixed a while ago (around change #497715).
-418 sqlexception using DB2 and EJB QL with SQRT or MOD
---
Key: OPENJPA-23
URL: https://issues.apache.org/jira/browse/OPENJPA-23
Project: OpenJPA
Issue Type: Bug
Reporter: David Wisneski
Assigned To: Marc Prud'hommeaux
Fix For: 0.9.7
generated SQL is missing CAST function to indicate type of ?
EJB QL : select e from EmpBean e where mod(e.empid,5)=0
DB2 SQL error: SQLCODE: -418, SQLSTATE: 42610, SQLERRMC: null {prepstmnt
1046232668
SELECT t0.empid, t0.bonus, t1.deptno, t1.budget, t1.name, t0.execLevel,
t0.hireDate, t0.hireTime, t0.hireTimestamp,
t0.home, t0.isManager, t0.name, t0.salary, t0.work FROM EmpBean t0 LEFT OUTER
JOIN DeptBean t1 ON t0.dept_deptno = t1.deptno
WHERE (MOD(t0.empid, ?) = ?)
db2 sql compiler is not able to resolve type of expression (MOD(t0.empid, ?)
= ?. This expression should be
MOD(t0.empid, cast((?) as integer) ) = ?.or
MOD(t0.empid, 5) = 0
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (OPENJPA-81) Bad error message when trying to query a Collection relation using dot notation
Patrick, I'm a little confused with all of these updates you are doing with the JIRA Issues. Most of the updates are related to specifying a Fix Version of 0.9.7. Does this mean you are planning on having all of these Issues resolved for 0.9.7? Or, do you think this field specifies which version needs to be fixed? There is also an Affected Version field, which in my mind, would more closely relate to that idea. Maybe I'm just not familiar enough with the JIRA usage, but if you could explain the reasoning behind these changes, that would be great. Thanks. Kevin On 2/28/07, Patrick Linskey (JIRA) [EMAIL PROTECTED] wrote: [ https://issues.apache.org/jira/browse/OPENJPA-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] Patrick Linskey updated OPENJPA-81: --- Fix Version/s: 0.9.7 Bad error message when trying to query a Collection relation using dot notation --- Key: OPENJPA-81 URL: https://issues.apache.org/jira/browse/OPENJPA-81 Project: OpenJPA Issue Type: Improvement Components: diagnostics, query Environment: openJPA 0.9.7 MySQL 5.0.15 Reporter: Jakob Braeuchi Priority: Minor Fix For: 0.9.7 the query over the 1:n relationship 'katergorien' em.createQuery(select distinct k from KategorieGruppe k + where k.kategorien.bezeichnung like ?1 + order by k.bezeichnung asc); uses a wrong alias t2 in the generated SQL: SELECT DISTINCT t0.id, t0.bezeichnung FROM ekv2kategoriegruppe t0 INNER JOIN ekv2kategorie t1 ON t0.id = t1.idGruppe WHERE (t2.bezeichnung LIKE ? ESCAPE '\\') ORDER BY t0.bezeichnung ASC [params=(String) F%] Unknown column 't2.bezeichnung' in 'where clause' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: OpenJPA Transaction configuration
If you set the version field of an instance to a non-default value, OpenJPA assumes the instance was detached, or that you're actively trying to make it behave as a detached instance. ___ 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: OpenJPA Transaction configuration
Here is a link to the source (and no version field): There is a version field in there. How are you invoking the non-default constructor? As Abe mentioned, if your version field is set to a value other than the Java default (0 in this case), OpenJPA will assume that the instance is detached. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Matthieu Riou [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 28, 2007 9:51 PM To: Patrick Linskey Cc: open-jpa-dev@incubator.apache.org Subject: Re: OpenJPA Transaction configuration Here is a link to the source (and no version field): http://svn.apache.org/repos/asf/incubator/ode/trunk/dao-jpa/sr c/main/java/org/apache/ode/dao/jpa/ProcessDAOImpl.java How can I try to change the default detach manager? Which one should I use instead? Thanks! Matthieu On 2/28/07, Patrick Linskey [EMAIL PROTECTED] wrote: Can you post the source for ProcessDAOImpl? Also, are there any other OpenJPA properties in your configuration? Finally, I'm assuming that you're using a somewhat-current 0.9.7-SNAPSHOT. Correct me if I'm wrong. But shouldn't I worry about the fact that a brand new instance is detached? I could be wrong but it looks like it's more a symptom of I believe that you should. I think I remember reading something about this recently, but I don't remember the details. My suspicion is that you don't have an @Version field, and you're using the default detach manager. IIRC, this combination leaves OpenJPA with no way to detect a detached object vs. a new object, and we default to detached. I thought that we had improved the docs around this at the least; certainly, it'd be good to figure out your particulars and make sure that this is clearer for others. (IIRC, the default detach manager uses a heuristic on the value in the version field to determine whether an instance is new or detached. OpenJPA supports more flexible detach managers that can do fun things like providing useful errors when attempting to navigate past the end of a detached object graph, and fine-grained tracking of changes made while detached. But it's not serialization-compatible with the unenhanced code, meaning that you need to put the enhanced classes into your client tier, which I think that we decided was a bad default.) -Patrick -- Patrick Linskey BEA Systems, Inc. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Matthieu Riou [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 28, 2007 7:50 PM To: Pinaki Poddar Cc: open-jpa-dev@incubator.apache.org mailto:open-jpa-dev@incubator.apache.org Subject: Re: OpenJPA Transaction configuration Thanks! But shouldn't I worry about the fact that a brand new instance is detached? I could be wrong but it looks like it's more a symptom of something wrong in my configuration, no? On 2/28/07, Pinaki Poddar [EMAIL PROTECTED] wrote: instead of _em.persist(ret); try _em.merge(ret); as ret is detached instance rather than new. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Matthieu Riou [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 28, 2007 6:29 PM To: open-jpa-dev@incubator.apache.org Subject: OpenJPA Transaction configuration Hi, I'm going back at the OpenJPA
RE: svn commit: r513183 - in /incubator/openjpa/trunk: openjpa-kernel/src/main/java/org/apache/openjpa/conf/ openjpa-lib/src/main/java/org/apache/openjpa/lib/conf/ openjpa-persistence/src/main/java/or
The difference is that in an appserver environment, this will return a
non-finalizing EM by default, but in a Java SE environment, it will
return a finalizing EM by default. See the last bit of my last comment
in OPENJPA-160.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 28, 2007 10:42 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: svn commit: r513183 - in
/incubator/openjpa/trunk:
openjpa-kernel/src/main/java/org/apache/openjpa/conf/
openjpa-lib/src/main/java/org/apache/openjpa/lib/conf/
openjpa-persistence/src/main/java/org/apache/openjpa/persistence/
Hi Patrick,
I don't quite understand the code that follows. What is the
difference between this code and simply defaulting the value to non-
finalizing impl?
Craig
On Feb 28, 2007, at 10:31 PM, [EMAIL PROTECTED] wrote:
PersistenceUnitInfo pui, Map m) {
PersistenceProductDerivation pd = new
PersistenceProductDerivation();
try {
+// if the BrokerImpl hasn't been specified,
switch to the
+// non-finalizing one, since anything claiming
to be a
container
+// should be doing proper resource management.
+if (!Configurations.containsProperty(BrokerValue.KEY,
+pui.getProperties())
+ !Configurations.containsProperty
(BrokerValue.KEY, m)) {
+m.put(BrokerValue.KEY,
BrokerValue.NON_FINALIZING_ALIAS);
+}
+
ConfigurationProvider cp = pd.load(pui, m);
if (cp == null)
return null;
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: [jira] Updated: (OPENJPA-81) Bad error message when trying to query a Collection relation using dot notation
Patrick, Sounds good. I like the aggressive schedule idea. I hope we can pull it off... :-) Kevin On 3/1/07, Patrick Linskey [EMAIL PROTECTED] wrote: My understanding is that Fix Version(s) captures both the version that something is scheduled to be fixed in (for unresolved issues) and the version that something actually was fixed in (for resolved issues). Affected Version(s) identifies the versions that the issue is present in. So, I spent some time yesterday afternoon doing JIRA triage. My goals were to put together something of a reasonable-if-aggressive schedule for 0.9.7 (presumably the next release), and to adjust priorities according to the JIRA definitions. As ever, those changes aren't set in stone; they're just what I thought looked reasonable. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Kevin Sutter [mailto:[EMAIL PROTECTED] Sent: Thursday, March 01, 2007 4:55 AM To: open-jpa-dev@incubator.apache.org Subject: Re: [jira] Updated: (OPENJPA-81) Bad error message when trying to query a Collection relation using dot notation Patrick, I'm a little confused with all of these updates you are doing with the JIRA Issues. Most of the updates are related to specifying a Fix Version of 0.9.7. Does this mean you are planning on having all of these Issues resolved for 0.9.7? Or, do you think this field specifies which version needs to be fixed? There is also an Affected Version field, which in my mind, would more closely relate to that idea. Maybe I'm just not familiar enough with the JIRA usage, but if you could explain the reasoning behind these changes, that would be great. Thanks. Kevin On 2/28/07, Patrick Linskey (JIRA) [EMAIL PROTECTED] wrote: [ https://issues.apache.org/jira/browse/OPENJPA-81?page=com.atla ssian.jira.plugin.system.issuetabpanels:all-tabpanel] Patrick Linskey updated OPENJPA-81: --- Fix Version/s: 0.9.7 Bad error message when trying to query a Collection relation using dot notation -- - Key: OPENJPA-81 URL: https://issues.apache.org/jira/browse/OPENJPA-81 Project: OpenJPA Issue Type: Improvement Components: diagnostics, query Environment: openJPA 0.9.7 MySQL 5.0.15 Reporter: Jakob Braeuchi Priority: Minor Fix For: 0.9.7 the query over the 1:n relationship 'katergorien' em.createQuery(select distinct k from KategorieGruppe k + where k.kategorien.bezeichnung like ?1 + order by k.bezeichnung asc); uses a wrong alias t2 in the generated SQL: SELECT DISTINCT t0.id, t0.bezeichnung FROM ekv2kategoriegruppe t0 INNER JOIN ekv2kategorie t1 ON t0.id = t1.idGruppe WHERE (t2.bezeichnung LIKE ? ESCAPE '\\') ORDER BY t0.bezeichnung ASC [params=(String) F%] Unknown column 't2.bezeichnung' in 'where clause' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: possible to write a JPA Query to that filters both an Entity and its relationship entities?
Hi Pinaki, On Feb 26, 2007, at 10:01 AM, Pinaki Poddar wrote: Respected Sir, Sorry to disagree. If you fetch Department instances, I think you always want the _employees collection to contain all the related Employees. You never want a filtered collection unless you provide a filter via some Java behavior. I agree that department.getEmployees() must return all the employees. However, i was considering the state of a Department instance in memory that has just been selected by a query. Which of the native (String/int etc.) field values are populated and which of its related objects are instantiated is controlled by the currently active fetch plan (if not explicitly then at least implicitly by 'default' fetch group). Right. If the application accesses any unrealized field of this 'partially filled' department, then that field is populated irrespective of whether it is in active fetch group or not via a new, separate database access call. Right. In a sense, the fetch plan determines a 'partial' view of the 'complete' department -- both in terms of its native state and its relations -- as and when it appears for the first time in memory. In fact, if the department instance leaves the managed environment via detachment at that point -- the detached department in a remote process will only have this partially filled 'view'. And, of course, the application can explictly load any unrealized state of the partial view via any getter method. Right. I was trying to draw an equivalence/parallel of this normal fetch behavior to the use case where a owner object has a high, multi-cardinalty relationship but only wants a subset of the elements of that relationship. In such a scheme, the traversal on a fetch path relation (which is now a binary decision) can be further adorned to support a predicate i.e. Query query = // a JPQL query that selects a Department based on some critria query.getFetchPlan().addField(employees, yearsOfSevice10); Department dept = query.getSingleResult(); // dept will be constructed in memory with a collection of Employees with yearsOfService10 The standard way to get the employees with the filter you show is to explicitly return the employee instances. The query language does not accommodate returning the collection as a result value. One of the reasons to exclude this is to disambiguate the result collection as being filtered or not. Disallowing return values of collection types neatly avoids the issue. dept.getEmployees(); // now the dept will load a collection of all Employees Right. And you can also envision filtering the collection directly via non- standard techniques. Given the collection, that might not be fully instantiated, you can pass that collection to a proprietary method that does the filtering in the database. Of course, the suggested alternative approach where the application explictly constructs this partial/filtered multi-cardinality relatinship by choosing the elements via query is feasible and available right now with current features. Right. Craig Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, February 23, 2007 8:32 PM To: open-jpa-dev@incubator.apache.org Subject: Re: possible to write a JPA Query to that filters both an Entity and its relationship entities? On Feb 23, 2007, at 7:49 PM, Pinaki Poddar wrote: One way to realize a owner object with a partially filled multi-cardinality relationship is to expand fetchplan concept. For example, if we consider a Department of 100 Employees of which only 20 are oldtimers, then a query can select the particular Department from the datastore but to realize that Department as a Java object in memory with only 20 senior Employees in _employees collection will need to tune the fetch plan acconrdingly. In JDO, fetch plan is specified to certain details to extract a subset of native states and subset of relationships. JPA does not yet specify fetch plan, but OpenJPA does via @FetchGroup extension. However currently, no filtering criterion is applied to filter the content while a particular relationship path is traversed. It is a all-or-nothing affair. Either Department is fetched with all its 100 Employees or the Employees relation is not traversed at all. The only control available now is to specify which native states and relationship will be considered for fetching and in case of recursive relationship how many times a particular relation path will be traversed. Essentially query and fecth paths are working in conjunction -- query selects the root object and fetch plan decides which subset of the closure of this root object is realized in memory. It will surely be a useful feature to consider expanding fetch plan with filtering criteria. Sorry to disagree. If you fetch Department instances, I think you always want the _employees collection to contain all
[jira] Commented: (OPENJPA-20) Query can return embeddable class
[ https://issues.apache.org/jira/browse/OPENJPA-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477043 ] Craig Russell commented on OPENJPA-20: -- I agree with Marc that it's a bug in the doc. The doc could also be reworded like Embedded classes cannot be used as the first entity in the FROM clause of a query. They can only be returned by projecting from an entity that embeds them. Query can return embeddable class - Key: OPENJPA-20 URL: https://issues.apache.org/jira/browse/OPENJPA-20 Project: OpenJPA Issue Type: Bug Components: docs Reporter: David Wisneski Priority: Minor part 2 , chapter 4 of user manual on Entity, states that embeddable classes are never returned from a query. This is not true as in the query select e.address from EmpBean e address could be defined as as embeddable class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r513183 - in /incubator/openjpa/trunk: openjpa-kernel/src/main/java/org/apache/openjpa/conf/ openjpa-lib/src/main/java/org/apache/openjpa/lib/conf/ openjpa-persistence/src/main/java/or
Hi Patrick,
I'm trying to understand how the code knows it's running in an
appserver environment...
Thanks,
Craig
On Mar 1, 2007, at 7:52 AM, Patrick Linskey wrote:
The difference is that in an appserver environment, this will return a
non-finalizing EM by default, but in a Java SE environment, it will
return a finalizing EM by default. See the last bit of my last comment
in OPENJPA-160.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
__
_
Notice: This email message, together with any attachments, may
contain
information of BEA Systems, Inc., its subsidiaries and
affiliated
entities, that may be confidential, proprietary, copyrighted
and/or
legally privileged, and is intended solely for the use of the
individual
or entity named in this message. If you are not the intended
recipient,
and have received this message in error, please immediately return
this
by email and then delete it.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 28, 2007 10:42 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: svn commit: r513183 - in
/incubator/openjpa/trunk:
openjpa-kernel/src/main/java/org/apache/openjpa/conf/
openjpa-lib/src/main/java/org/apache/openjpa/lib/conf/
openjpa-persistence/src/main/java/org/apache/openjpa/persistence/
Hi Patrick,
I don't quite understand the code that follows. What is the
difference between this code and simply defaulting the value to non-
finalizing impl?
Craig
On Feb 28, 2007, at 10:31 PM, [EMAIL PROTECTED] wrote:
PersistenceUnitInfo pui, Map m) {
PersistenceProductDerivation pd = new
PersistenceProductDerivation();
try {
+// if the BrokerImpl hasn't been specified,
switch to the
+// non-finalizing one, since anything claiming
to be a
container
+// should be doing proper resource management.
+if (!Configurations.containsProperty(BrokerValue.KEY,
+pui.getProperties())
+ !Configurations.containsProperty
(BrokerValue.KEY, m)) {
+m.put(BrokerValue.KEY,
BrokerValue.NON_FINALIZING_ALIAS);
+}
+
ConfigurationProvider cp = pd.load(pui, m);
if (cp == null)
return null;
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!
smime.p7s
Description: S/MIME cryptographic signature
Re: [jira] Updated: (OPENJPA-81) Bad error message when trying to query a Collection relation using dot notation
On Mar 1, 2007, at 7:55 AM, Patrick Linskey wrote: My understanding is that Fix Version(s) captures both the version that something is scheduled to be fixed in (for unresolved issues) and the version that something actually was fixed in (for resolved issues). Affected Version(s) identifies the versions that the issue is present in. This is how other projects use these two fields, and seems reasonable to me. So, I spent some time yesterday afternoon doing JIRA triage. My goals were to put together something of a reasonable-if-aggressive schedule for 0.9.7 (presumably the next release), and to adjust priorities according to the JIRA definitions. As ever, those changes aren't set in stone; they're just what I thought looked reasonable. I agree. It should give us a way to quickly see what remains to be done. You can ask JIRA to give you a list of unresolved issues for a release. And when we get closer to a release, we can always remove items that seem to be out of scope of the release for whatever reason. Craig -Patrick -- Patrick Linskey BEA Systems, Inc. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Kevin Sutter [mailto:[EMAIL PROTECTED] Sent: Thursday, March 01, 2007 4:55 AM To: open-jpa-dev@incubator.apache.org Subject: Re: [jira] Updated: (OPENJPA-81) Bad error message when trying to query a Collection relation using dot notation Patrick, I'm a little confused with all of these updates you are doing with the JIRA Issues. Most of the updates are related to specifying a Fix Version of 0.9.7. Does this mean you are planning on having all of these Issues resolved for 0.9.7? Or, do you think this field specifies which version needs to be fixed? There is also an Affected Version field, which in my mind, would more closely relate to that idea. Maybe I'm just not familiar enough with the JIRA usage, but if you could explain the reasoning behind these changes, that would be great. Thanks. Kevin On 2/28/07, Patrick Linskey (JIRA) [EMAIL PROTECTED] wrote: [ https://issues.apache.org/jira/browse/OPENJPA-81?page=com.atla ssian.jira.plugin.system.issuetabpanels:all-tabpanel] Patrick Linskey updated OPENJPA-81: --- Fix Version/s: 0.9.7 Bad error message when trying to query a Collection relation using dot notation -- - Key: OPENJPA-81 URL: https://issues.apache.org/jira/browse/OPENJPA-81 Project: OpenJPA Issue Type: Improvement Components: diagnostics, query Environment: openJPA 0.9.7 MySQL 5.0.15 Reporter: Jakob Braeuchi Priority: Minor Fix For: 0.9.7 the query over the 1:n relationship 'katergorien' em.createQuery(select distinct k from KategorieGruppe k + where k.kategorien.bezeichnung like ?1 + order by k.bezeichnung asc); uses a wrong alias t2 in the generated SQL: SELECT DISTINCT t0.id, t0.bezeichnung FROM ekv2kategoriegruppe t0 INNER JOIN ekv2kategorie t1 ON t0.id = t1.idGruppe WHERE (t2.bezeichnung LIKE ? ESCAPE '\\') ORDER BY t0.bezeichnung ASC [params=(String) F%] Unknown column 't2.bezeichnung' in 'where clause' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
RE: svn commit: r513183 - in /incubator/openjpa/trunk: openjpa-kernel/src/main/java/org/apache/openjpa/conf/ openjpa-lib/src/main/java/org/apache/openjpa/lib/conf/ openjpa-persistence/src/main/java/or
The diff email didn't include enough context for you. This is in the
createContainerEntityManagerFactory() method. It's my contention that
createContainerEntityManagerFactory() will only be invoked by things
that intend to close resources properly.
-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, March 01, 2007 10:38 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: svn commit: r513183 - in
/incubator/openjpa/trunk:
openjpa-kernel/src/main/java/org/apache/openjpa/conf/
openjpa-lib/src/main/java/org/apache/openjpa/lib/conf/
openjpa-persistence/src/main/java/org/apache/openjpa/persistence/
Hi Patrick,
I'm trying to understand how the code knows it's running in an
appserver environment...
Thanks,
Craig
On Mar 1, 2007, at 7:52 AM, Patrick Linskey wrote:
The difference is that in an appserver environment, this
will return a
non-finalizing EM by default, but in a Java SE environment, it will
return a finalizing EM by default. See the last bit of my
last comment
in OPENJPA-160.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
__
_
Notice: This email message, together with any attachments, may
contain
information of BEA Systems, Inc., its subsidiaries and
affiliated
entities, that may be confidential, proprietary, copyrighted
and/or
legally privileged, and is intended solely for the use of the
individual
or entity named in this message. If you are not the intended
recipient,
and have received this message in error, please immediately return
this
by email and then delete it.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 28, 2007 10:42 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: svn commit: r513183 - in
/incubator/openjpa/trunk:
openjpa-kernel/src/main/java/org/apache/openjpa/conf/
openjpa-lib/src/main/java/org/apache/openjpa/lib/conf/
openjpa-persistence/src/main/java/org/apache/openjpa/persistence/
Hi Patrick,
I don't quite understand the code that follows. What is the
difference between this code and simply defaulting the
value to non-
finalizing impl?
Craig
On Feb 28, 2007, at 10:31 PM, [EMAIL PROTECTED] wrote:
PersistenceUnitInfo pui, Map m) {
PersistenceProductDerivation pd = new
PersistenceProductDerivation();
try {
+// if the BrokerImpl hasn't been specified,
switch to the
+// non-finalizing one, since anything claiming
to be a
container
+// should be doing proper resource management.
+if (!Configurations.containsProperty(BrokerValue.KEY,
+pui.getProperties())
+ !Configurations.containsProperty
(BrokerValue.KEY, m)) {
+m.put(BrokerValue.KEY,
BrokerValue.NON_FINALIZING_ALIAS);
+}
+
ConfigurationProvider cp = pd.load(pui, m);
if (cp == null)
return null;
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: svn commit: r513183 - in /incubator/openjpa/trunk: openjpa-kernel/src/main/java/org/apache/openjpa/conf/ openjpa-lib/src/main/java/org/apache/openjpa/lib/conf/ openjpa-persistence/src/main/java/or
On Mar 1, 2007, at 11:01 AM, Patrick Linskey wrote:
The diff email didn't include enough context for you. This is in the
createContainerEntityManagerFactory() method. It's my contention that
createContainerEntityManagerFactory() will only be invoked by things
that intend to close resources properly.
Cool. Thanks,
Craig
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
__
_
Notice: This email message, together with any attachments, may
contain
information of BEA Systems, Inc., its subsidiaries and
affiliated
entities, that may be confidential, proprietary, copyrighted
and/or
legally privileged, and is intended solely for the use of the
individual
or entity named in this message. If you are not the intended
recipient,
and have received this message in error, please immediately return
this
by email and then delete it.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 01, 2007 10:38 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: svn commit: r513183 - in
/incubator/openjpa/trunk:
openjpa-kernel/src/main/java/org/apache/openjpa/conf/
openjpa-lib/src/main/java/org/apache/openjpa/lib/conf/
openjpa-persistence/src/main/java/org/apache/openjpa/persistence/
Hi Patrick,
I'm trying to understand how the code knows it's running in an
appserver environment...
Thanks,
Craig
On Mar 1, 2007, at 7:52 AM, Patrick Linskey wrote:
The difference is that in an appserver environment, this
will return a
non-finalizing EM by default, but in a Java SE environment, it will
return a finalizing EM by default. See the last bit of my
last comment
in OPENJPA-160.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
__
_
Notice: This email message, together with any attachments, may
contain
information of BEA Systems, Inc., its subsidiaries and
affiliated
entities, that may be confidential, proprietary, copyrighted
and/or
legally privileged, and is intended solely for the use of the
individual
or entity named in this message. If you are not the intended
recipient,
and have received this message in error, please immediately return
this
by email and then delete it.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 28, 2007 10:42 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: svn commit: r513183 - in
/incubator/openjpa/trunk:
openjpa-kernel/src/main/java/org/apache/openjpa/conf/
openjpa-lib/src/main/java/org/apache/openjpa/lib/conf/
openjpa-persistence/src/main/java/org/apache/openjpa/persistence/
Hi Patrick,
I don't quite understand the code that follows. What is the
difference between this code and simply defaulting the
value to non-
finalizing impl?
Craig
On Feb 28, 2007, at 10:31 PM, [EMAIL PROTECTED] wrote:
PersistenceUnitInfo pui, Map m) {
PersistenceProductDerivation pd = new
PersistenceProductDerivation();
try {
+// if the BrokerImpl hasn't been specified,
switch to the
+// non-finalizing one, since anything claiming
to be a
container
+// should be doing proper resource management.
+if (!Configurations.containsProperty(BrokerValue.KEY,
+pui.getProperties())
+ !Configurations.containsProperty
(BrokerValue.KEY, m)) {
+m.put(BrokerValue.KEY,
BrokerValue.NON_FINALIZING_ALIAS);
+}
+
ConfigurationProvider cp = pd.load(pui, m);
if (cp == null)
return null;
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!
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
