openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <mprud...@apache.org>
Subject Re: AW: Forgot subject: Strange Could not locate metadata for the classError?
Date Fri, 23 Mar 2007 21:02:12 GMT
Hans-

I don't see how the error could be data-related.

One thing: if you are using the same EMF from multiple threads, do  
you have the "openjpa.Multithreaded" property explicitly set to  
"true" in your persistence.xml (or however you are configuring the  
EMF)? Failure to do this means that access to the broker is  
unsynchronized, and I can see how it might lead to a problem like this.



On Mar 23, 2007, at 11:46 AM, Hans J. Prueller wrote:

> hm.. sounds strange. could it bet he case that the error message  
> openjpa is
> printing is only a subsequent error of another one below/before?
>
> as the JNDI binding did not really work (as you can remember:  
> everytime I am
> accessing the EMF from JNDI it is initialized again and again) so I  
> did a
> quick-and-dirty solution for the PoC of OpenJPA integration: I  
> saved the EMF
> as a static field instead to JNDI, i.e. the first time it is  
> accessed it is
> created - then every client throughout my app should access the  
> same static
> EMF instance. As there is definitely only a single JVM this  
> shouldn't make
> problems I suggest...
>
> Additionally I did not see any data in the logs that is indicating  
> that a
> second EMF is initialized or sth. like that. The strange thing is  
> that it
> worked several invocations before and after .. could it be a data- 
> related
> problem? Anyway, I was not able to reproduce the error....
>
> Hans
>
>
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Marc Prud'hommeaux [mailto:mprudhomapache@gmail.com] Im  
>> Auftrag von
>> Marc Prud'hommeaux
>> Gesendet: Freitag, 23. März 2007 17:59
>> An: open-jpa-dev@incubator.apache.org
>> Betreff: Re: Forgot subject: Strange Could not locate metadata for  
>> the
>> classError?
>>
>> Hans-
>>
>> There are only two possible conditions in which I can see this
>> problem happening:
>>
>> 1. the class "com.lbslogics.ims.model.PositionLog" is not loadable in
>> the current environment's classloader.
>> 2. the PositionLog class was registered with the MetaDataRepository
>> during the lookup process.
>>
>> Since the same code has been executed hundreds of times via the MDB
>> prior to this error, neither of these seems very plausible. Are you
>> sure that the exact same EntityManagerFactory (in the same JVM) has
>> been used prior to this error to execute the same method? The fact
>> that it looks like we are parsing the query for the first time (since
>> it appears we are making a new internal parse compilation from it)
>> makes it look like that particular method has not yet been called for
>> that EntityManager's EntityManagerFactory.
>>
>> If this is something you can reproduce, it would be interesting if we
>> could see more logging output (enabled by setting the "kodo.Log"
>> property to "DefaultLevel=TRACE"), especially those messages that are
>> on the MetaData channel.
>>
>>
>>
>> On Mar 23, 2007, at 5:57 AM, Hans J. Prueller wrote:
>>
>>> full stack trace (up until application specific stuff) is:
>>>
>>> 2007-03-22 21:34:53,287 : SEVERE : WorkThread-2/34 : Logger.log :
>>> system exception in business method:
>>> <4|true|0.9.7-incubating-SNAPSHOT>
>>> org.apache.openjpa.persistence.ArgumentException: Could not locate
>>> metadata for the class using alias "PositionLog". Registered alias
>>> mappings: "{PositionLog=[class  
>>> com.lbslogics.ims.model.PositionLog]}"
>>> 	at
>>> org.apache.openjpa.meta.MetaDataRepository.getMetaData
>>> (MetaDataRepository.java:345)
>>> 	at
>>> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaDat 
>>> a(
>>> JPQLExpressionBuilder.java:164)
>>> 	at
>>> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMet 
>>> aD
>>> ata(JPQLExpressionBuilder.java:142)
>>> 	at
>>> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMet 
>>> aD
>>> ata(JPQLExpressionBuilder.java:211)
>>> 	at
>>> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMet 
>>> aD
>>> ata(JPQLExpressionBuilder.java:181)
>>> 	at
>>> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateTyp 
>>> e(
>>> JPQLExpressionBuilder.java:174)
>>> 	at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access
>>> $500(JPQLExpressionBuilder.java:61)
>>> 	at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder
>>> $ParsedJPQL.populate(JPQLExpressionBuilder.java:1668)
>>> 	at
>>> org.apache.openjpa.kernel.jpql.JPQLParser.populate 
>>> (JPQLParser.java:52)
>>> 	at
>>> org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilati 
>>> on
>>> (ExpressionStoreQuery.java:145)
>>> 	at
>>> org.apache.openjpa.datacache.QueryCacheStoreQuery.populateFromCompil 
>>> at
>>> ion(QueryCacheStoreQuery.java:237)
>>> 	at
>>> org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java: 
>>> 644)
>>> 	at
>>> org.apache.openjpa.kernel.QueryImpl.compilationFromCache
>>> (QueryImpl.java:625)
>>> 	at
>>> org.apache.openjpa.kernel.QueryImpl.compileForCompilation
>>> (QueryImpl.java:591)
>>> 	at
>>> org.apache.openjpa.kernel.QueryImpl.compileForExecutor
>>> (QueryImpl.java:653)
>>> 	at org.apache.openjpa.kernel.QueryImpl.compile(QueryImpl.java:560)
>>> 	at
>>> org.apache.openjpa.persistence.EntityManagerImpl.createNamedQuery
>>> (EntityManagerImpl.java:785)
>>> 	at
>>> org.apache.openjpa.persistence.EntityManagerImpl.createNamedQuery
>>> (EntityManagerImpl.java:62)
>>> 	at
>> com.lbslogics.ims.model.PositionLog.findById(PositionLog.java:175)
>>> 	at
>>> com.lbslogics.ims.persistence.ejb.EventBean.getPositionLog
>>> (EventBean.java:2875)
>>>          [ ... some more ]
>>>
>>> The corresponding EventBean is a SLSB (EJB2.1) and the method looks
>>> like
>>> that:
>>>
>>>         /**
>>> 	 *
>>> 	 * @return
>>> 	 */
>>> 	public PositionLog getPositionLog(final EntityManager em) {
>>> 		final PositionLog log = PositionLog.findById(em,
>> getPositionLogId
>>> ());
>>> 		return log;
>>> 	}
>>>
>>> and the Positionlog.findById is a static method which encapsulates
>>> some
>>> of the "technical work":
>>>
>>>         public static PositionLog findById(EntityManager em, Long
>>> plId)
>>> {
>>> 		Query q = em.createNamedQuery("PositionLog.byId");
>>> 		q.setParameter("id", plId);
>>>
>>> 		try {
>>> 			return (PositionLog) q.getSingleResult();
>>> 		} catch (javax.persistence.NoResultException e) {
>>> 			logger.finest("findById: did not find result for
> id=" +
>> plId);
>>> 			return null;
>>> 		}
>>> 	}
>>>
>>> This method or better the top-level entry point of this method is
>>> called
>>> several hundred times for different records, all invoked by a MDB.
>>> Could
>>> it be some concurrency issue because after several hundred  
>>> invocations
>>> only a single exception occured?
>>>
>>> Hans
>>>
>>> Am Freitag, den 23.03.2007, 05:48 -0700 schrieb Patrick Linskey:
>>>
>>>> Could you post the full stack trace, and maybe some code showing  
>>>> how
>>>> you're invoking the JPA APIs?
>>>>
>>>> -Patrick
>>>>
>


Mime
View raw message