Unfortunately, there isn't really a good default for this piece of code
generation.  It varies depending on how people are using hibernate.  The
way it is now just happens to be the simplest solution.

I would assume that most projects that use hibernate have some sort of
utility class so they can access the hibernate session in a way that
depends on their environment(tomcat/jboss/spring/threadlocal pattern/...)

I was trying to think of a way we could generate the utility class to
access the session, but I think it might be overkill, and I am unsure if
it can be good enough to handle all the cases.  Something like

<hibernateDAO>
    <hibernateSession>
        <!-- pick one of the four options-->
        <spring />
        <threadLocal />
        <jboss
jndiName="&#34;java:/hibernate/HibernateSessionFactory&#34;" />
        <!--Where HibernateUtil must have static get/closeSession
methods-->
        <custom class="com.mycompany.util.HibernateUtil />
    </hibernateSession>
</hibernateDAO>

David, do you have any thoughts on this?  Are we approaching this
completely wrong?  Is there something that could be done on the hibernate
side to make a single entry point to obtaining a session factory no
matter what your environment is, that is somehow configured, something
like a SessionFactoryFactory


I am unsure when a bugfix release could be made available.

Ben

On Sun, 16 Jan 2005, Wouter Boers wrote:

> I can think of three ways to provide this funtionality:
>
> 1: Put it in the properties file as done now. The full name including the
> methods is then the only way since you never will know if getSession() is
> the correcy method. Disadvantage is that I somehow do not like this. It
> feels wrong. It'n not a property it's a method call which should in the
> ideal world be derived somehow (introspecion?).
>
> 2: put it in a merge file. In my opinion this is a cleaner sollution then
> the first but also splits the generation of the file. The merge then becomes
> a 'required' item. While as far as I have worked with the merge files, they
> are intended as an extension and thus provide additional functionality to
> middlegen. Not core functionality, like the hibernateDAO is.
>
> 3. Set it via the gui and store the setting in the prefs file. I put this
> file under version control so I can recreate the middle/xdoclet generation
> on the production system. The disadvantage is, that the default will, in
> most cases not work since they are not 'local' like the other settings
> stored in the prefs file.
>
> So taking everything in consideration, the third option would be my choice.
> What are your cons and pros?
>
> As for the fix in CVS, is there a bugfix release planned, like 2.1.1? I do
> not want to go into production with a CVS snapshot as you can understand.
> For development I can opf course live with it.
>
> Regards, Wouter
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Ben
> Litchfield
> Sent: 15 January 2005 03:42
> To: middlegen-user@lists.sourceforge.net
> Subject: Re: [Middlegen-user] Hibernate, dao and DBHelper class template
> error
>
>
>
>
>
> > I run the subtask hibernatDAO in the middlegen task. As mentioned before
> > on this list. You need to specify the variable "getHibernateSession" when
> > using hibernate 2.x. (I am using 2.1)
> >
> > <hibernateDAO getHibernateSession="${getHibernateSession}.getSession();"/>
> >
> > I have a few comments on the template.
> > First you need to specify the ';'. Which is not very need but okay.
>
> I would like to hear your comments on a better way to provide this
> functionality.  Would it be better as a merge file?
>
>
>
>
> > The second is that the template produces a java file that is incorrect.
>
> This was fixed in CVS a while back but has not been released yet.
>
> Ben
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> middlegen-user mailing list
> middlegen-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/middlegen-user
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> middlegen-user mailing list
> middlegen-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/middlegen-user
>


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
middlegen-user mailing list
middlegen-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/middlegen-user

Reply via email to