RE: [Hibernate] lost exception
> In SessionFactoryImpl, the catch clause which throws a > MappingException with the message "Could not instantiate > persister class:..." (line 180 in v1.1.4b) discards the > more detailed exception it receives (e). .. > I found that the exception that was discarded read "Could not > find a setter for..." My description above is inaccurate: the actual discarded exception is a java.lang.reflect.InvocationTargetException, and its "target" variable contains the MappingException with the message "Could not find a setter for...". So simply adding "+ e.toString()" or similar doesn't help the situation. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Failure to lazily initialize a collection
A few more details on the exception: The session is still open when I try to access the lazily initialized collection. The code is as simple as this: Gene gene = (Gene)session.load(DbGene.class, "PA6222"); Set refSeqs = gene.getReferenceSequences(); Iterator it = refSeqs.iterator(); Which triggers the exception. The NPE in the CVS build looks like a bug in the new locking code, but that doesn't explain why I'm getting this exception with the 1.1.4b build. Here's the mapping I'm using for the set: Anyone have any idea what the problem might be? Thanks, -Mark --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] lost exception
In SessionFactoryImpl, the catch clause which throws a MappingException with the message "Could not instantiate persister class:..." (line 180 in v1.1.4b) discards the more detailed exception it receives (e). In my case, I did something dumb - adding a new key column to a table without adding the corresponding getter/setter - and then had to figure out what "Could not instantiate persister class..." was trying to tell me. Via debugging, I found that the exception that was discarded read "Could not find a setter for..." which would have been a lot more helpful, especially while suffering from a case of lamebrain... Not sure what the Hibernate-appropriate fix should be - the ideal solution in this kind of case, IMO, would be to throw a chained exception (like the JDK 1.4 feature), so that exception context is not lost. Is Hibernate using anything like that? I haven't noticed. If not, just tacking the exception strings together would work in this case. Anton --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Failure to lazily initialize a collection
Mark Woon wrote: Here's the mapping I'm using for the set: And if I change it to lazy="false," I get: java.lang.NullPointerException at cirrus.hibernate.LockMode.greaterThan(LockMode.java:30) at cirrus.hibernate.impl.SessionImpl.lock(SessionImpl.java:1121) at cirrus.hibernate.impl.SessionImpl.doLoad(SessionImpl.java:1412) at cirrus.hibernate.impl.SessionImpl.doLoadByClass(SessionImpl.java:1314) at cirrus.hibernate.impl.SessionImpl.internalLoadOneToOne(SessionImpl.java:1273) at cirrus.hibernate.type.OneToOneType.resolveIdentifier(OneToOneType.java:68) at cirrus.hibernate.impl.SessionImpl.initializeEntity(SessionImpl.java:1456) at cirrus.hibernate.loader.Loader.doFind(Loader.java:144) at cirrus.hibernate.loader.Loader.loadCollection(Loader.java:448) at cirrus.hibernate.loader.CollectionLoader.initialize(CollectionLoader.java:67) at cirrus.hibernate.impl.SessionImpl.initialize(SessionImpl.java:) at cirrus.hibernate.collections.PersistentCollection.getInitialValue(PersistentCollection.java:69) at cirrus.hibernate.type.PersistentCollectionType.getCollection(PersistentCollectionType.java:69) at cirrus.hibernate.type.PersistentCollectionType.resolveIdentifier(PersistentCollectionType.java:198) at cirrus.hibernate.impl.SessionImpl.initializeEntity(SessionImpl.java:1456) at cirrus.hibernate.loader.Loader.doFind(Loader.java:171) at cirrus.hibernate.loader.Loader.loadEntity(Loader.java:435) at cirrus.hibernate.loader.EntityLoader.load(EntityLoader.java:61) at cirrus.hibernate.persister.EntityPersister.load(EntityPersister.java:406) at cirrus.hibernate.impl.SessionImpl.doLoad(SessionImpl.java:1440) at cirrus.hibernate.impl.SessionImpl.doLoadByClass(SessionImpl.java:1314) at cirrus.hibernate.impl.SessionImpl.load(SessionImpl.java:1253) at misc.Test.test(Test.java:61) at misc.Test.main(Test.java:40) With the 1.1.4b build I get: cirrus.hibernate.TransientObjectException: You tried to lock a transient instance at cirrus.hibernate.impl.SessionImpl.lock(SessionImpl.java:1113) at cirrus.hibernate.impl.SessionImpl.doLoad(SessionImpl.java:1404) at cirrus.hibernate.impl.SessionImpl.doLoadByClass(SessionImpl.java:1306) at cirrus.hibernate.impl.SessionImpl.internalLoadOneToOne(SessionImpl.java:1265) at cirrus.hibernate.type.OneToOneType.resolveIdentifier(OneToOneType.java:68) at cirrus.hibernate.impl.SessionImpl.initializeEntity(SessionImpl.java:1448) at cirrus.hibernate.loader.Loader.doFind(Loader.java:144) at cirrus.hibernate.loader.Loader.loadCollection(Loader.java:448) at cirrus.hibernate.loader.CollectionLoader.initialize(CollectionLoader.java:67) at cirrus.hibernate.impl.SessionImpl.initialize(SessionImpl.java:2213) at cirrus.hibernate.collections.PersistentCollection.getInitialValue(PersistentCollection.java:69) at cirrus.hibernate.type.PersistentCollectionType.getCollection(PersistentCollectionType.java:69) at cirrus.hibernate.type.PersistentCollectionType.resolveIdentifier(PersistentCollectionType.java:198) at cirrus.hibernate.impl.SessionImpl.initializeEntity(SessionImpl.java:1448) at cirrus.hibernate.loader.Loader.doFind(Loader.java:171) at cirrus.hibernate.loader.Loader.loadEntity(Loader.java:435) at cirrus.hibernate.loader.EntityLoader.load(EntityLoader.java:61) at cirrus.hibernate.persister.EntityPersister.load(EntityPersister.java:666) at cirrus.hibernate.impl.SessionImpl.doLoad(SessionImpl.java:1432) at cirrus.hibernate.impl.SessionImpl.doLoadByClass(SessionImpl.java:1306) at cirrus.hibernate.impl.SessionImpl.load(SessionImpl.java:1245) at misc.Test.test(Test.java:61) at misc.Test.main(Test.java:40) BTW, all this works with 1.3! -Mark --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Looking for Volunteers
Ace! Thanks Jon ... looking forward :) - Original Message - From: "Jon Lipsky" <[EMAIL PROTECTED]> To: "Gavin King" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, October 12, 2002 2:04 AM Subject: Re: [Hibernate] Looking for Volunteers > Hi Gavin, > > I spent a few hours today working on this, and I think I have it about > finished. > > - It can now handle two columns with the same name in different tables. > - It now will work for both Oracle and Ansi style joins > - It works for insert, update, and load by primary key. > > All I have left to do is finish the "select" code, and then I'll submit it > for you to play around with. Right now, the code for generating the selects > is about finished, all I have left to do is to figure out how to get the > portion of the select statement needed to load the MultipleTableEntity in > sync with the rest (Right now the alias names don't match up.) > > I'll won't be able to continue working on this until Monday, so don't expect > anything before then. > > Jon... > > > - Original Message - > From: "Gavin King" <[EMAIL PROTECTED]> > To: "Jon Lipsky" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Friday, October 11, 2002 9:27 AM > Subject: Re: [Hibernate] Looking for Volunteers > > > > I'm pre-warning you that this will be a bit involved, Jon - and you will > > probably have to change the Loadable interface, refactoring some stuff > thats > > currently done in the Loader hierarchy onto the EntityPersister > classes. > > > > I don't have an existing testcase, but if you add a many-to-one > association > > to some class in Multi.hbm.xml, that will be enough. > > > > MultiTableEntityPersister implements table-per-subclass persistence. > > EntityPersister implements the old-style persistence. > > > > Currently MultiTableEntityPersister is a valid implementation of > operations > > from ClassPersister and Queryable but *not* of all operations defined on > > Loadable. ie. MultiTableEntityPersister defines the operations needed by > > SimpleEntityLoader but not by OuterJoinLoader. > > > > At the moment, I am generating SQL along the lines of: > > > > select > > t.id as id1, t.clazz as clazz1, t.prop as prop1, > > t1.subprop as subprop1 > > from roottable t > > left outer join subtable t1 > > on t.id = t1.id > > > > for the _query_ stuff. That will have to change in a couple of ways: > > > > (1) it doesn't handle the case of two columns with the same name in > > different tables > > (2) it shouldnt always be an outerjoin really sometimes it should be > > just a join > > > > but thats enough to get us started. Baby steps. So if you generate > something > > similar for outerjoin loading, we will be in business. > > > > P.S. I just noticed that because MultiTableEntityPersister doesn't support > > outerjoin loading, it also can't be loaded by CollectionLoader or > > EntityLoader. So this is an important thing to finish. > > > > > > - Original Message - > > From: "Jon Lipsky" <[EMAIL PROTECTED]> > > To: "Gavin King" <[EMAIL PROTECTED]> > > Sent: Friday, October 11, 2002 4:34 PM > > Subject: Re: [Hibernate] Looking for Volunteers > > > > > > > Hi Gavin, > > > > > > Not a problem. If you can point me to a valid test case for this, I'd > be > > > more than willing to make sure the outer join fetching works. > > > > > > Jon... > > > > > > > > > - Original Message - > > > From: "Gavin King" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Wednesday, October 09, 2002 6:56 PM > > > Subject: [Hibernate] Looking for Volunteers > > > > > > > > > > Okay, I finally have something concrete for normalized > > > (table-per-subclass) > > > > mappings. I went down a couple of wrong paths before I decided on the > > best > > > > approach (a completely new implementation of ClassPersister). > > > > > > > > I can save/load/update/delete instances already. > > > > > > > > We need (in order of importance): > > > > > > > > * SchemaExport support (and proper support in the mapping document) > > > > * Query language integration (the hard bit) > > > > * Support for outerjoin fetching > > > > * Support for versioning (easy) > > > > * support for native id-generation (not very hard) > > > > > > > > If anyone wants to help out with any of these problems, I would very > > much > > > > appreciate it. > > > > > > > > ( In particular, since Jon Lipsky understands the outerjoin fetching > > code, > > > > maybe he would have a look at that stuff? ) > > > > > > > > I'm perhaps being slightly over-eager here, since I still need to > rework > > > the > > > > map package part of this; what I've got there now is kludge. But I > will > > do > > > > that (and finish it) tomorrow. When I do that, it will knock the top > > item > > > > off the list by side-effect and make the other items doable. > > > > > > > > Anyway, if anyone can spare the time, please stick your hand up and I > > will > > > > point in right direction > > > > > > > >
[Hibernate] support for dynabeans
Hi All! I'd like to implement a new feature in Hibernate, but I dont know how to start best. I would like to be able to map classes that dont really exist as javaclass, but use a dynabean instead http://www.apache.org/~jvanzyl/jakarta-commons/beanutils/apidocs/org/apache/commons/beanutils/DynaBean.html (or a map). All seems to be quite easy, refactor all stuff that loads and initializes a bean to a pluggable factory, and there if the loading of the class fails just create or initialize a Dynabean or Map (or maybe a HibernateGenericValueHolder) instead. The only problem is: The Hibernate API :) Session.load, Session.update, etc all get a java.lang.Class Argument. Do you think it would be possible to add functions that get a classname as String instead? Maybe the functions that take a string as argument should always use Holders instead of beans. I realize that this would be big changes, but if you think that this would be a good idea, I would just go ahead and try to implement it. The inspiration to this comes from the ofbiz entity engine, which always uses generic holders instead of Beans, which i dont really like, but its really nice for some usecases, e.g. letting your user add colums to a table at runtime without restarting the server. I recognize that i could dynamically generate a bean with bcel, but once that bean is loaded i cant add properties to it, so I'd really prefer a map. regards chris --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Failure to lazily initialize a collection
I think I've fixed this problem now. (But I did it without first reproducing the bug.) Mark, would you do me a favor, please: (1) check the fix works (2) add a regression test to FooBarTest that Thanks Gavin - Original Message - From: "Mark Woon" <[EMAIL PROTECTED]> Cc: "Hibernate Mailing List" <[EMAIL PROTECTED]> Sent: Saturday, October 12, 2002 11:28 AM Subject: Re: [Hibernate] Failure to lazily initialize a collection > Mark Woon wrote: > > > Here's the mapping I'm using for the set: > > > > > lazy="true" cascade="all"> > > > > > class="org.pharmgen.db.DbReferenceSequence" /> > > > > > And if I change it to lazy="false," I get: > > java.lang.NullPointerException > at cirrus.hibernate.LockMode.greaterThan(LockMode.java:30) > at cirrus.hibernate.impl.SessionImpl.lock(SessionImpl.java:1121) > at cirrus.hibernate.impl.SessionImpl.doLoad(SessionImpl.java:1412) > at > cirrus.hibernate.impl.SessionImpl.doLoadByClass(SessionImpl.java:1314) > at > cirrus.hibernate.impl.SessionImpl.internalLoadOneToOne(SessionImpl.java:1273 ) > at > cirrus.hibernate.type.OneToOneType.resolveIdentifier(OneToOneType.java:68) > at > cirrus.hibernate.impl.SessionImpl.initializeEntity(SessionImpl.java:1456) > at cirrus.hibernate.loader.Loader.doFind(Loader.java:144) > at cirrus.hibernate.loader.Loader.loadCollection(Loader.java:448) > at > cirrus.hibernate.loader.CollectionLoader.initialize(CollectionLoader.java:67 ) > at > cirrus.hibernate.impl.SessionImpl.initialize(SessionImpl.java:) > at > cirrus.hibernate.collections.PersistentCollection.getInitialValue(Persistent Collection.java:69) > at > cirrus.hibernate.type.PersistentCollectionType.getCollection(PersistentColle ctionType.java:69) > at > cirrus.hibernate.type.PersistentCollectionType.resolveIdentifier(PersistentC ollectionType.java:198) > at > cirrus.hibernate.impl.SessionImpl.initializeEntity(SessionImpl.java:1456) > at cirrus.hibernate.loader.Loader.doFind(Loader.java:171) > at cirrus.hibernate.loader.Loader.loadEntity(Loader.java:435) > at cirrus.hibernate.loader.EntityLoader.load(EntityLoader.java:61) > at > cirrus.hibernate.persister.EntityPersister.load(EntityPersister.java:406) > at cirrus.hibernate.impl.SessionImpl.doLoad(SessionImpl.java:1440) > at > cirrus.hibernate.impl.SessionImpl.doLoadByClass(SessionImpl.java:1314) > at cirrus.hibernate.impl.SessionImpl.load(SessionImpl.java:1253) > at misc.Test.test(Test.java:61) > at misc.Test.main(Test.java:40) > > With the 1.1.4b build I get: > > cirrus.hibernate.TransientObjectException: You tried to lock a transient > instance > at cirrus.hibernate.impl.SessionImpl.lock(SessionImpl.java:1113) > at cirrus.hibernate.impl.SessionImpl.doLoad(SessionImpl.java:1404) > at > cirrus.hibernate.impl.SessionImpl.doLoadByClass(SessionImpl.java:1306) > at > cirrus.hibernate.impl.SessionImpl.internalLoadOneToOne(SessionImpl.java:1265 ) > at > cirrus.hibernate.type.OneToOneType.resolveIdentifier(OneToOneType.java:68) > at > cirrus.hibernate.impl.SessionImpl.initializeEntity(SessionImpl.java:1448) > at cirrus.hibernate.loader.Loader.doFind(Loader.java:144) > at cirrus.hibernate.loader.Loader.loadCollection(Loader.java:448) > at > cirrus.hibernate.loader.CollectionLoader.initialize(CollectionLoader.java:67 ) > at > cirrus.hibernate.impl.SessionImpl.initialize(SessionImpl.java:2213) > at > cirrus.hibernate.collections.PersistentCollection.getInitialValue(Persistent Collection.java:69) > at > cirrus.hibernate.type.PersistentCollectionType.getCollection(PersistentColle ctionType.java:69) > at > cirrus.hibernate.type.PersistentCollectionType.resolveIdentifier(PersistentC ollectionType.java:198) > at > cirrus.hibernate.impl.SessionImpl.initializeEntity(SessionImpl.java:1448) > at cirrus.hibernate.loader.Loader.doFind(Loader.java:171) > at cirrus.hibernate.loader.Loader.loadEntity(Loader.java:435) > at cirrus.hibernate.loader.EntityLoader.load(EntityLoader.java:61) > at > cirrus.hibernate.persister.EntityPersister.load(EntityPersister.java:666) > at cirrus.hibernate.impl.SessionImpl.doLoad(SessionImpl.java:1432) > at > cirrus.hibernate.impl.SessionImpl.doLoadByClass(SessionImpl.java:1306) > at cirrus.hibernate.impl.SessionImpl.load(SessionImpl.java:1245) > at misc.Test.test(Test.java:61) > at misc.Test.main(Test.java:40) > > > BTW, all this works with 1.3! > > -Mark > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > hibernate-devel mailing list > [EMAIL PROTECTED] > https://li
