openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marina Vatkina <Marina.Vatk...@Sun.COM>
Subject Re: AW: Forgot subject: Strange Could not locate metadata for the classError?
Date Fri, 23 Mar 2007 18:59:53 GMT
It looks very similar to what I saw yesterday, and I also couldn't reproduce it 
later.

-marina

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.getClassMetaData(
>>>JPQLExpressionBuilder.java:164)
>>>	at
>>>org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaD
>>>ata(JPQLExpressionBuilder.java:142)
>>>	at
>>>org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaD
>>>ata(JPQLExpressionBuilder.java:211)
>>>	at
>>>org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaD
>>>ata(JPQLExpressionBuilder.java:181)
>>>	at
>>>org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(
>>>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.populateFromCompilation
>>>(ExpressionStoreQuery.java:145)
>>>	at
>>>org.apache.openjpa.datacache.QueryCacheStoreQuery.populateFromCompilat
>>>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