RE: another shared classloader problem
Patrick Linskey wrote: Also, could you describe the use case where it makes sense to change an entity name in XML? To date, I've mostly been of the opinion that changing entity names in XML is a pretty bad thing, as it will cause any queries that relied on the annotation-specified (or default) entity names to break. Is there some use case that's been escaping me? Ah yes, I can see now that an annotation would be better for this. I just had all my metadata in XML. Isn't there an XML-metadata-complete attribute or something that might force you to use XML though? Roger -Patrick -Original Message- From: roger.keays [mailto:[EMAIL PROTECTED] Sent: Monday, April 16, 2007 5:27 PM To: open-jpa-dev@incubator.apache.org Subject: another shared classloader problem Hi all, I've come across another defect since moving openjpa to tomcat's shared/lib shared classloader. Unfortunately, try as I might, I can't reliably reproduce this one, so I'm posting the problem here in the hope that somebody might be able to offer some suggestions. The problem is that one of my entity classes seems to forget its name under certain situations. I have two entities: figbird.commerce.entities.Product, and gemstone.business.entities.Product. The former is mapped to the entity name 'FigbirdProduct' in the XML metadata and the latter defaults to 'Product'. The error message I see is: WARNING: An error occurred while parsing the query filter SELECT i FROM Product i WHERE i.code = :c. Error message: No field named code in class class figbird.commerce.entities.Product. 4|false|0.9.6-incubating org.apache.openjpa.persistence.ArgumentException: An error occurred while parsing the query filter SELECT i FROM Product i WHERE i.code = :c. Error message: No field named code in class class figbird.commerce.entities.Product. of course the field 'code' is on gemstone.b.e.Product (not figbird.c.e.Product) I would rename one of my classes and let it rest if it wasn't for the fact that worked fine with the webapp classloader, and only seems to break when some condition occurs. I've tried reproducing by * loading the server and forcing garbage collections * setting the DataCache and QueryCache size to 1, with 0 soft references * disabling the DataCache and QueryCache * restarting other webapps which use both entities but to no avail. Once this exception occurs, restarting the webapp doesn't resolve it. The whole server has to be restarted. Any suggestions are welcome. I'm using 0.9.6. Roger -- View this message in context: http://www.nabble.com/another-shared-classloader-problem-tf358 8152.html#a10027378 Sent from the open-jpa-dev mailing list archive at Nabble.com. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -- View this message in context: http://www.nabble.com/another-shared-classloader-problem-tf3588152.html#a10027665 Sent from the open-jpa-dev mailing list archive at Nabble.com.
RE: another shared classloader problem
Ah yes, I can see now that an annotation would be better for this. I just had all my metadata in XML. Isn't there an XML-metadata-complete attribute or something that might force you to use XML though? Yes, there is one of those. I guess it's necessary in that case. IMO, we shouldn't even have room in the XML document for the entity name, and it should be an annotation-only thing. Ah well. -Patrick -Original Message- From: roger.keays [mailto:[EMAIL PROTECTED] Sent: Monday, April 16, 2007 6:00 PM To: open-jpa-dev@incubator.apache.org Subject: RE: another shared classloader problem Patrick Linskey wrote: Also, could you describe the use case where it makes sense to change an entity name in XML? To date, I've mostly been of the opinion that changing entity names in XML is a pretty bad thing, as it will cause any queries that relied on the annotation-specified (or default) entity names to break. Is there some use case that's been escaping me? Ah yes, I can see now that an annotation would be better for this. I just had all my metadata in XML. Isn't there an XML-metadata-complete attribute or something that might force you to use XML though? Roger -Patrick -Original Message- From: roger.keays [mailto:[EMAIL PROTECTED] Sent: Monday, April 16, 2007 5:27 PM To: open-jpa-dev@incubator.apache.org Subject: another shared classloader problem Hi all, I've come across another defect since moving openjpa to tomcat's shared/lib shared classloader. Unfortunately, try as I might, I can't reliably reproduce this one, so I'm posting the problem here in the hope that somebody might be able to offer some suggestions. The problem is that one of my entity classes seems to forget its name under certain situations. I have two entities: figbird.commerce.entities.Product, and gemstone.business.entities.Product. The former is mapped to the entity name 'FigbirdProduct' in the XML metadata and the latter defaults to 'Product'. The error message I see is: WARNING: An error occurred while parsing the query filter SELECT i FROM Product i WHERE i.code = :c. Error message: No field named code in class class figbird.commerce.entities.Product. 4|false|0.9.6-incubating org.apache.openjpa.persistence.ArgumentException: An error occurred while parsing the query filter SELECT i FROM Product i WHERE i.code = :c. Error message: No field named code in class class figbird.commerce.entities.Product. of course the field 'code' is on gemstone.b.e.Product (not figbird.c.e.Product) I would rename one of my classes and let it rest if it wasn't for the fact that worked fine with the webapp classloader, and only seems to break when some condition occurs. I've tried reproducing by * loading the server and forcing garbage collections * setting the DataCache and QueryCache size to 1, with 0 soft references * disabling the DataCache and QueryCache * restarting other webapps which use both entities but to no avail. Once this exception occurs, restarting the webapp doesn't resolve it. The whole server has to be restarted. Any suggestions are welcome. I'm using 0.9.6. Roger -- View this message in context: http://www.nabble.com/another-shared-classloader-problem-tf358 8152.html#a10027378 Sent from the open-jpa-dev mailing list archive at Nabble.com. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -- View this message in context: http://www.nabble.com/another-shared-classloader-problem-tf358 8152.html#a10027665 Sent from the open-jpa-dev mailing list archive at Nabble.com. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: another shared classloader problem
Patrick Linskey wrote: Ah yes, I can see now that an annotation would be better for this. I just had all my metadata in XML. Isn't there an XML-metadata-complete attribute or something that might force you to use XML though? Yes, there is one of those. I guess it's necessary in that case. IMO, we shouldn't even have room in the XML document for the entity name, and it should be an annotation-only thing. Ah well. Hmmm... I've never done this in JPA, but I remember in JDO some people wanted to create mappings for classes that they didn't write themselves. That might be another use case for names in XML files. To fix my problem, I've just and renamed one of the classes, although I suspect there is (or was, in 0.9.6) a bug in there somewhere. Thanks for the ideas, Roger -Patrick -Original Message- From: roger.keays [mailto:[EMAIL PROTECTED] Sent: Monday, April 16, 2007 6:00 PM To: open-jpa-dev@incubator.apache.org Subject: RE: another shared classloader problem Patrick Linskey wrote: Also, could you describe the use case where it makes sense to change an entity name in XML? To date, I've mostly been of the opinion that changing entity names in XML is a pretty bad thing, as it will cause any queries that relied on the annotation-specified (or default) entity names to break. Is there some use case that's been escaping me? Ah yes, I can see now that an annotation would be better for this. I just had all my metadata in XML. Isn't there an XML-metadata-complete attribute or something that might force you to use XML though? Roger -Patrick -Original Message- From: roger.keays [mailto:[EMAIL PROTECTED] Sent: Monday, April 16, 2007 5:27 PM To: open-jpa-dev@incubator.apache.org Subject: another shared classloader problem Hi all, I've come across another defect since moving openjpa to tomcat's shared/lib shared classloader. Unfortunately, try as I might, I can't reliably reproduce this one, so I'm posting the problem here in the hope that somebody might be able to offer some suggestions. The problem is that one of my entity classes seems to forget its name under certain situations. I have two entities: figbird.commerce.entities.Product, and gemstone.business.entities.Product. The former is mapped to the entity name 'FigbirdProduct' in the XML metadata and the latter defaults to 'Product'. The error message I see is: WARNING: An error occurred while parsing the query filter SELECT i FROM Product i WHERE i.code = :c. Error message: No field named code in class class figbird.commerce.entities.Product. 4|false|0.9.6-incubating org.apache.openjpa.persistence.ArgumentException: An error occurred while parsing the query filter SELECT i FROM Product i WHERE i.code = :c. Error message: No field named code in class class figbird.commerce.entities.Product. of course the field 'code' is on gemstone.b.e.Product (not figbird.c.e.Product) I would rename one of my classes and let it rest if it wasn't for the fact that worked fine with the webapp classloader, and only seems to break when some condition occurs. I've tried reproducing by * loading the server and forcing garbage collections * setting the DataCache and QueryCache size to 1, with 0 soft references * disabling the DataCache and QueryCache * restarting other webapps which use both entities but to no avail. Once this exception occurs, restarting the webapp doesn't resolve it. The whole server has to be restarted. Any suggestions are welcome. I'm using 0.9.6. Roger -- View this message in context: http://www.nabble.com/another-shared-classloader-problem-tf358 8152.html#a10027378 Sent from the open-jpa-dev mailing list archive at Nabble.com. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -- View this message in context: http://www.nabble.com/another-shared-classloader-problem-tf358 8152.html#a10027665 Sent from the open-jpa-dev mailing list archive at Nabble.com. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message
