hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <>
Subject RE: 3rd party library classes as Hivemind services
Date Thu, 14 Oct 2004 15:31:54 GMT
I don't think it's so bad to provide a class/interface called something like
HibernateHelper which gives you all the common functionality that people use
all the time off the Session, but doesn't throw the HibernateExceptions.  I
did that in my example application and it turned out to work fairly nicely.
The interfaces DOES give you access to the Hibernate Session if you wish to
use it directly, but, as you pointed out, nobody does.  If a need comes up
to add a new method to the interface, it's usually trivial to do so. 

-----Original Message-----
From: Jean-Francois Poilpret [] 
Sent: Thursday, October 14, 2004 11:26 AM
Subject: 3rd party library classes as Hivemind services

Hello "Hiveminders",

While working on a generic Transaction Service framework, with particular
focus on Hibernate, I thought about the annoying problem of checked
exceptions thrown by almost all methods of all Hibernate classes. Having to
try/catch these exceptions again and again makes it boring to write DAO that
will eventually be hard to read just because of that.

My first idea about the problem was to do something like Spring does, ie
define an Hibernate "ersatz" (HibernateTemplate, a substitute wrapping most
commonly used methods), but I did not really adhere to such an idea since:
- it restricts the full view of Hibernate to developers (I know spring does
not prevent you from accessing directly all Hibernate stuff, but who does it
- it means that developers do not _really_ develop with Hibernate but with
Spring-integrated Hibernate through Spring classes

Then, I wondered if it would not be possible to do, for any DAO, something
- create a DAO interface with all necessary DAO methods with NO
- implement a DAO class that DOES NOT implement the DAO interface but has
the exact same list of public methods (exact means same name, same args
types, same return types), but each with a throws HibernateException clause.
In this case, the methods do not have to try/catch HibernateException and
their code is reduced to the bare minimum
- have some kind of "adapter" from the DAO interface to the DAO class, that
would catch all HibernateExceptions and replace them with "something else"
(unchecked exception)

After a few tests I could write a ServiceImplementationFactory that just
does that:
- instantiate a service implementation
- create an adapter (proxy) that implements a different interface and
delegates all method calls based on method name and args types, catches all
exceptions and uses an "ExceptionMapper" object to translate them to some
other exception that is thrown instead

As of today I have something that seems to work correctly (I did not fully
test it yet, yes I know, "my code sucks" as said somewhere on TSS ;-)).
It can be configured the same as Hivemind BuilderFactory (DI, autowire...)
and has extra parameters to configure the exception mapping (from/to pairs
of classes).

After that I realized that this could be used more generally (without
exception mapping) to be able to adapt classes that come from a 3rd-party
library which we do not have the source, and which do not implement any
interface. The trick would consist then in creating an interface that has
all public methods of that class and use that special factory, et voila!

I will put the current code soon on JIRA (on the bug regarding support for
classes without interfaces). Please do not hesitate to comment on this.

Some additional point then puzzled me (I come back to my DAO problem) from
the design viewpoint. Creating a DAO interface and a DAO class that do not
implement that interface kinda sucks right? In particular, even without
considering the design, but just the time to develop/test/debug such a DAO
(I do not even dare talk about evolutions...) it is easy to forget to code a
method in the DAO class that is in the DAO interface.
For now, I did not find any workaround to avoid this. Any ideas?
The best I could do (better than nothing) was to log warnings at service
construction time when the implementation class does not implement ALL
methods of the interface.

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message