> would there be any advantage in having a "proper"
> approach to logging events inside the persistence layer? (Beyond the
> present rudimentary approach of System.out.println() when
> hibernate.debug>0) We could pretty quickly rip out all the printlns and
> replace them with log4j, for example. But perhaps people are wishing they
> could see other kinds of information altogether.
In the system I've just begun using Hibernate with, we use our own event
logging system that's tightly integrated into the overall application, e.g.
things like document workflow are tracked via events in our logs. We'd
prefer not to have to use some other logging mechanism, so of course it
would be nice (but not essential) if we could supply a custom log object
which exposed logging interface(s) for Hibernate to use, so events would be
logged within our own system.
I haven't used log4j, so don't know how it might fit into this picture. If
you did use something like that, it would be nice if it were done in a
pluggable way. Hopefully that wouldn't require too much work.
BTW, (changing subject) today I wrote a little XSL template to generate Java
bean skeletons ("DTOs") from the Hibernate mapping XML. It needs a few
enhancements currently, but I'll clean it up and post it over the next few
days. I used Xalan so it should work directly with a standard Hibernate
distribution, without requiring any additional libraries.
I'm not sure that XSL is the best approach to this (Donnie mentioned using
Velocity), but it works and it's pretty small, since the XML handling is
implicit. I considered using JSP, but that would add a dependency which
seemed like overkill to me. Having some kind of template-like functionality
for the generated Java seems like a good idea, to support easy
customization, but XSL isn't the most transparent template environment
around.
Anton
|
