It seems to me that it's not a common case at all
Of course it's not that common. If it were, maybe someone else would have solved this problem by now :-).
My use case is as follows: I need to add behavior to a Session's save, update, saveOrUpdate methods. As things stand, I can implement Session, wrap the original Session and delegate to it:
public class MySession implements Session {
private Session originalSession;
public MySession(Session session) {
originalSession = session;
}
public Serializable save(Object obj) { // Do something before saving ... Serializable id = originalSession.save(obj); // Do something else after saving ... return id; } }
The problem is that "obj" might have a cascading relationship with other objects, in which case the "save" method of the original Session will call SessionImpl.save instead of my overridden method, so I won't have a chance to execute my extra code before and after saving.
> I'm intend believe it > has more drawbacks to "pollute" the public API with such a need than > stay that way.
I don't mean to pollute the public API in any way. ConfigurationImpl might read a configuration parameter with the name of the class to use instead of SessionFactoryImpl and fall back to SessionFactoryImpl if there's no such parameter. It would impact only the implementation of *Impl classes.
Ugo
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
