I'm working on an app with some special needs, primarily that the persistent objects do not have empty constructors (and never will). The hibernate manual states over and over that all persistent classes must have an empty constructor. IMHO, such a fatal limitation must be treated with disgust and hacked immediately :-)

Initially I solved this by creating my own Interceptor class and an instantiate() method. Very simple to do. You simply add the attribute access="MyInterceptorClass" to all your properties et al. (you do use an auto-generator, of course:-?). Then you just write your instantiate() method to call your constructor with the proper arguments.

I started with default-lazy="false". (I read everything in on startup.) Unfortunately, anytime I tried to read a complex object, hibernate would create a sql monstrosity to instantiate every reachable object from the one object I was reading. Reading one class literally caused a 100+ table join sql string that was 34K long. Obviously that approach failed.

So I went to default-lazy="true". This caused different problems. The CGLIB implementation ignores the custom Interceptor.instantiate() method and attempts its own instantiation on the CGLIBSubclass using an empty constructor: CGLIBLazyInitializer.getProxy() -> proxy = (HibernateProxy) factory.newInstance();
This causes a fatal error, as there is no empty constructor in the CGLIBSubclass. IMHO, the hibernate integration with CGLIB should not be doing this, but c'est la guerre.

So I'm stuck. I can't use lazy and I can't not use lazy.

Time to hack the hibernate source. Override the factory.newInstance() method in CGLIBLazyInitializer.getProxy() and call the Interceptor.instantiate() method as it should. This works. Voila, we've worked around the "empty constructor" problem.

For people who cannot provide empty constructors, this might be sufficient. I can't speak for this in general, because I only use a very limited portion of hibernate's capabilities.

------
I actually want to do away with the CGLIB entirely. Even though I now use lazy reads, I "immediately" do away with the proxies. I've got it working in my app, but my approach is only elegant insofar as a neat "hackaround". I'd prefer to override more of Hibernate and replace the creation of proxies completely. There are some old threads discussing "extension points" for Tuplizers, EntityModes et al. but they appear not to have made it into the release.

http://forum.hibernate.org/viewtopic.ph ... t=tuplizer

http://forum.hibernate.org/viewtopic.ph ... t=tuplizer
(Note: This one uses the undocumented "tuplizer" element in the hibernate-mapping. I've verified this element doesn't blow up the parser, but I have not explored its use and web discussion is less than slim. Has anyone pursued this?)

-----
P.S. Am I the only one frustrated by the downside of the forum rating system? If you have a useful tip you've figured out, there is no incentive to share it since all you're going to do is waste one of your points...like I just did.

as far as useful tips go, it's intended that they go on the wiki, and not on the forum.

what constructor do you call instead of the empty constructor ?

(the rest of your posting looks like you are misusing hibernate la 'grande ;)

>what constructor do you call instead of the empty constructor ?

public PersistentObj(MySpecialObject1 o1, MySpecialObject2 o2) {}

The details don't matter, besides the fact that public PersistentObj() {} makes no sense in my domain and is not allowed. I couldn't even provide one without causing an Exception.

...Ok, ok, its a distributed system and every object must have a "creator" and "owner", supplied at instantiation time. You literally can't do anything with an object until it has a creator and owner.

(This decision was made from expertise, not poor developer skills, btw, not that that should make any difference.)

>(the rest of your posting looks like you are misusing hibernate la 'grande ;)

Must be a communication issue :-) Bear in mind I've spent the last few weeks overcoming one issue after another in order to make hibernate work with my system. Slow slogging. The near-fatal problem was lack of support for list-to-list, but the rest has simply been me needing to do things in a way that no one else apparently does. I am definitely using hibernate in ways in which the designers never intended.

>as far as useful tips go, it's intended that they go on the wiki, and not on the forum.

Ah. Ok. Thanks. I've just been finding much more useful information in the forums, so I figured this is where it should go.

Tuplizers are in 3.1 (I believe since rc1). They are discussed in the 3.1 documentation (granted it is light) and even have some tests in the test suite specifically as an extension point (for example http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate3/test/org/hibernate/test/dynamicentity/tuplizer/ ).

While Tuplizers themselves are very mature (they grew out of refactorings to Persisters), Tuplizers as an extension point are very immature, but the intent is exactly the type of things you are trying. Unfortunately noone using the tuplizer extensions is actually creating jira issues for the stuff they find (sorry I don't have time to scour the forums for potential bug reports to add to jira myself). Bottom line is that Tuplizers are definitely the way to achieve what you want, but expect to run into bugs; please just report them so I can fix them ;)