For those of you with the ability to build XDoclet from CVS, I've generated a couple of changes that you might be interested. They were added within the last hour, and I'm interested in feedback to get them dialed in. I'll have some forthcoming documents better describing the use of this stuff if people like it.
Most of these changes were made with an eye toward using Hibernate with EJB. I've recently (the last week or so) been cutting off of entity beans with value objects and starting to use Hibernate with POJOs instead. I think the J2EE container is still very useful, but like many, have narrowed my use of EJB down to stateless session beans for scalable business logic. In the process of getting started, I've found it surprisingly difficult to "let go of the crutches" that are provided when using CMP, such as automatic table creation on deployment. So one fix tries to make that easier. This is provided with a <factoryclass/> subtask to the HibernateDoclet task. The generated class substitutes for using a properties file, and forms a Facade around the SessionFactory. Using this allows you to add POJOs to your build, start your application, and have them automatically included. Because the persistent classes are declared inline, it makes quick startup easier since there are no pesky classpaths to worry about with the hibernate.properties file. And if you ever need to migrate to using an mbean service down the road, a very easy switch inside the generated class allows you to do that. [Note that <factoryclass/> is useful in many environments, not just EJBs...] The other fixes address the fact that stateless session beans are often not so demanding that they require all the services that the container provides. If your SLSBs *could* run in the web container, but you want to maintain the flexibility of using session beans down the road when scalable deployment becomes an issue, I've made changes to the EJBDoclet <utilobject/> subtask such that the util object will generate dynamic proxies for the home and object interfaces, allowing your object to act like an EJB without using RMI. So you can build your application with your business objects coded as SLSBs, but access them without requiring an EJB container. The goal with this is that you can develop faster -- no more waiting for the EJB container to reload your jar. You don't even have to run inside JBoss any more! If your development environment supports embedded tomcat, it should be possible to run directly inside that. You also get the (somewhat dangerous) benefit that classloader issues between the web and ejb tier are avoided, which seem to bite me for five hours a month. [Note YMMV!! Avoiding addressing classloader issues until the last minute like this may have some nasty surprises in store for you when you realize some of the mistakes you made in your architecture. Be careful, but enjoy the ride...] These changes are "first draft" and in need of review. Please post and I'll do my best to respond. You need not focus on the XDoclet templates (they are difficult for some), just on what is generated or what parameters you would like to see to the generated code would be helpful. Thanks to Gavin and company for the making any of this worthwhile and of course to the XDoclet team for a great tool to build this stuff into. Enjoy! -b ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
