It's a very interesting thread actually. The ideal is: hide any aspect of the ugly EJB object model/life cycle methods. In reality: We just hide some life cycle methods; your code is still polluted by EJB stuff. At least we handle CMP1.1/2.0 differences atm for you and so forth.
I'm dreaming of a day when we can just define a simple interface and a simple implementation class for session/entity/whatever, without any EJB specific methods there in your interface or implementation code, and let xdoclet generate appropriate subclass with appropriate implementation of those ugly methods for you. You know, I'm thinking about a bridge between EJB/JDO/JavaBean! Code it as you're coding a simple JavaBean, let xdoclet turn it into an EJB session/entity bean or a JDO PC class. I can't make it clearer than this: EJB is not a very good model/framework, we hear many complaints about it everyday, so it's a dream come true to make it a "code generation level implementation detail", but still give you enough rope to hang yourself with whatever EJB trick you want to apply. EJB/JDO/JavaBean differences set aside, the constant change in EJB spec is itself a very good reason to make the dependency to the technology less and less. It's a very interesting project of its own, and if done properly I would call it a "breakthrough" really! Unfortunately I'm too busy to spent time on it myself, but if you can convince Sun or any of the big companies to support me to do the research then I'll think about it ;-) Ara. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:xdoclet-user- > [EMAIL PROTECTED]] On Behalf Of Matt Goodall > Sent: Monday, July 08, 2002 9:06 PM > To: [EMAIL PROTECTED] > Subject: RE: [Xdoclet-user] Session bean subclasses? > > Hi all, > > I've just been reading this thread. Paul, I agree that the business and > technical contract do some mixed up here but I think the answer you're > looking for is ... make the class you wrote abstract. That way, you don't > have to implement the EJB lifecycle methods; xdoclet will take care of > them > for you in its subclass. > > This may be a bit simplistic but in my eyes, xdoclet simply saves you a > bit > of tedious coding by implementing the lifecylce methods for you in the > subclass that actually gets deployed. Note that if you do want to get > involved in the EJB lifecycle then simply implement the method(s) and > xdoclet's implementation of the same method(s) will call you. > > Hope this helps. > > Cheers, Matt > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Paul > > Cantrell > > Sent: 08 July 2002 17:20 > > To: [EMAIL PROTECTED] > > Subject: Re: [Xdoclet-user] Session bean subclasses? > > > > > > >>> It separates the business contract from the technical > > >>> contract, so you don't have ejbActivate, ejbPassivate etc. > > >>> cluttering up your code > > >> > > >> If I leave those methods out, it complains that my class isn't > > >> implementing the SessionBean interface. If I don't implement > > >> that interface, ejbdoclet passes over my session bean entirely. > > > > > > So you give xdoclet an ordinary class and expect a session bean > > > subclass? > > > > No, no, I don't expect that. I understand perfectly well why > > it's looking for the session bean interface. > > > > My question is (still): what good does the subclass do? It does > > *not* separate the business methods from the "technical" > > methods -- if I implement the SessionBean interface, I need to > > have ejbActive and friends cluttering up my code, as you put it. > > > > How can I rephrase this question so it makes sense? It is a Catch-22: > > > > no "implements SessionBean" => xdoclet doesn't generate a subclass > > "implements SessionBean" => subclass is useless > > > > Paul > > > > _____________________________________________________________________ > > "At the level of bits, censorship and digital-rights management are > > technologically identical." Hal R. Varian, _The New York Times_ > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Oh, it's good to be a geek. > > http://thinkgeek.com/sf > > _______________________________________________ > > Xdoclet-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/xdoclet-user > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Oh, it's good to be a geek. > http://thinkgeek.com/sf > _______________________________________________ > Xdoclet-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-user ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
