On Mon, 2004-09-06 at 20:11, William I. Zumwalt wrote: > When I did ejb's by hand, I had three files ... > > MyRemote.java > MyHome.java > MyBean.java > > ... now using xdoclet, I have 6, > > My.java > MyBMP.java > MyData.java > MyHome.java > MyLocalHome.java > MyRemote.java. > > ... and that's not including the MyPK.java which I'm > trying to get working ... so I'm thoroughly confused. > Why all these files? Where can I read up on all these > files cause I don't see any of this in the ejb books I > have.
XDoclet lets you write beans that just contain your business logic (the interesting bits you care about) from the various lifecycle methods mandated by the spec (boring bits you don't care about so long as they work ;-)) To facilitate this, you create an abstract bean class, then it creates a subclass adding in the rest - this would be MyBMP, MyCMP or MySession depending on whether you're looking at a session EJB, a BMP entity EJB or a CMP entity EJB (there may even be another one for message driven beans, but I've not tried one recently). The remote & home interfaces you're already familiar with. MyLocalHome and MyLocal are local equivalents (called directly without the overheads of marshalling & unmarshalling remote calls "over the wire") that were introduced with EJB 2.0. MyData relates to entity EJBs only and is a state holder, a.k.a. Data Object, a.k.a. Data Transfer Object, a.k.a. Value Object (though XDoclet also has a more flexible version of this which would be called MyValueObject). Instead of making many calls to an entity EJB to set various fields (which has a high overhead, especially with remote interfaces) you can make one call that returns an object containing all the fields' values, make the changes in that local copy, then make one call to write all the changes back to the EJB. Two network round trips instead of many. Of course, with local interfaces this isn't such a problem, but DTOs are still a useful pattern e.g. for passing the values between the EJB & web tiers of you application. MyPK is only needed if you have a composite primary key for your EJB. It's a javabean, similar to the MyData object, but containing just the key fields. If your EJBs only have a single primary key field, then you should specify that with the @ejb.bean primkey-field parameter instead, and you don't need to generate a PK class. If you're using BMP entity EJBs, there may also be a DAO (data access object, not to be confused with the data object above) that lets you separate out all the JDBC stuff from the EJB itself (which it does as an interface, allowing you to plug in different implementations at runtime in case you need different code for specific databases). > And I have a questions a bit offtopic from the above. > I've seen so many examples of people making their ejb > abstract. How is that used? Do you treat it any > differetnly than a normal abstract class, meaning, > something other than derive another ejb from it? Yes, > I'm not very experienced w/ ejb's. There's two possible questions there, depending on what exactly you mean by "abstract". With CMP entity beans, you have to declare the class abstract anyway as all the getter & setter methods must (per the spec) be abstract as the container will implement them. With XDoclet, because it will generate a subclass (which is specified as the "implementation class" in the DD) for the lifecycle methods, you can declare your bean class abstract for the other beans types too. However, with entity beans, you might have a (conceptually) abstract "bean" from which you derive others e.g. an "abstract" AnimalBean, and "concrete" PenguinBean & DragonBean that derive from it. With CMP, even those subclasses would be abstract classes, but you'd lookup instances of them. The AnimalBean may or may not be truly abstract depending on whether or not looking up an AnimalBean instance (which might be either) is required or meaningful. That would determine whether you'd also want to generate the various classes for AnimalBean too, or just use it as a base class for your PenguinBean and DragonBean to extend. Inheritance of EJBs soon gets complicated, though, since you have to worry about whether the home/remote/pk/etc. also inherit from the Animal ones and whether there should be inherited finders in the home interfaces that take an AnimalPK etc. And a bunch of similar issues. At this point, people usually give up and switch from entity EJBs to Hibernate or some other Object-Relational Mapping tool instead. It's bad enough coping with O-R mismatch problems without having to worry about half a dozen related classes/interfaces as well... > Any help much appreciated. I suspect you're now twice as confused as when I started. Sorry! Andrew. ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
