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 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#a10027914
Sent from the open-jpa-dev mailing list archive at Nabble.com.

Reply via email to