openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hans J. Prueller" <hans.pruel...@gmx.net>
Subject AW: Forgot subject: Strange Could not locate metadata for the classError?
Date Fri, 23 Mar 2007 18:46:48 GMT
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