Hu, The container generated code shouldn't be touched. If it's not working then it needs reporting altho obviously determining that it's a vendor problem may not be simple given the myriad of code generated ;-(
Just a few observations about EJB : - I agree with a lot of your comments. EJB seems unnecessarily complex and yeah the spec reads like a legal document. Hell it's 572 pages long !! - the deployment cycle is hopeless. You can speed things up by either setting up an Ant task to batch up your deployment but you still have to set all the attributes on the Deployment Descriptor. M$ would make this cleaner by just right mouse clicking an EJB and setting the properties tab. - because you are moving the stuff from an IDE to app server there is still the issue of environmental variables, classes etc which can screw things up in the deploy - some IDE's do make deployment easier especially if the app server is the IDE's vendor - debugging wise some IDE's can run an app server copy in its environment eg. VAJ and WebSphere The bottom line is the Sun have released a spec that's meant to be open. They've tried to set everything up using descriptors to be more flexible. Flexibility can cause complexity and it's up to vendors to make it easier. The debugging can be very painful unless you have one of these fab IDE's. Without wanting to incur the wrath of other subscribers I reckon M$ could do a better job at making it easier (even Ed Roman's EJB vs. .Net paper sometime ago acknowledged that M$ do make good integrated development environments).. I agree that it's messy and should be better but we have to live with it (including what I consider the hash they have made with the EJB 2.0 persistence model). Eddie ========================= At 03:40 PM 31/01/2002, you wrote: >I think we just have a fundamental philosophical disagreement here. I don't >want to see the code/classes the container generates. Likewise, if I'm using >some library I could care less about the implementation. Isn't that the >point? > >----- Original Message ----- >From: "Hu Shih" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Wednesday, January 30, 2002 6:44 PM >Subject: Re: [EJB-INT] EJB Development Cycle > > > > Thanks for your thoughts. I have a few comments. > > > > > > >I know this wasn't written to me, but thought I'd offer my thoughts (o: > > > > I'm hoping that my discussion will not be a simple howling of a frustrated > > developer, but a call for someone (a container provider) to address issues > > which I think are key to EJB's success. > > > > > > >yes, its different to writing client-side code, which is what it sounds > > >like you are comparing it to. Without wanting to seem rude, > > >I'm wondering if you've had experience with servlets, or other components > > >that require a container. I was working on servlets prior > > >to ejb, so the requirement of a container seemed natural, although I can > > >see how if one was writing swing apps, then it might seem > > >very odd. > > > > Yes. I have done a fair amount of servlet development, where the servlet > > code interacts with database through JDBC. In fact, at the moment, I am > > trying to convert some of this code over to J2EE. Instead of using JDBC, > > use CMP (to maximize portability and to take advantage of the industry > > standard). > > > > Here is what I see. With servlet and JSP, the interaction of the > > 'container' and my code is rather simple. I have an array of name-value > > pairs coming in and an output stream for return. > > > > When I debug my servlet code through the debugger, I see a few stack >frames > > that I can't recognize, but rarely do I have to understand what they do. > > > > Similarly, with a Swing app, you would see a few stack frames for event > > dispatching, but you wouldn't care much about its implementation. > > > > Not so with EJB/CMP. Much of most important work is happening inside the > > generated classes. I need to figure out, fine tune, and change what >happens > > when the transient data is written to database. > > > > > > >thats the idea. you said before that you didn't like the idea of >debugging > > >the MFC framework... > > > > Well, actually I think you mistook my point. I was stating that the fact > > that MFC gave me source made it possible for me to use MFC. Otherwise, I > > would have been hopelessly lost and would not have completed my previous > > project using MFC. > > > > > > >generated classes to be like the framework - you shouldn't need to worry > > >about them. essentially, you write the business logic (the > > >bean class) tell the container what to expose (home and component > > >interfaces) and the container will plug it all together. > > > > Again, the difference is this: MFC worked with me. The source was there. > > Enough documentation (though some improvement was desired) was available. > > Even when doc wasn't there, there was code. When necessary, we even > > overrode parts of MFC to suit our needs. This is not possible with EJB > > (especially CMP). > > > > To summarize, problems I see with EJB (esp CMP) are as follows: > > > > - No code. Not enough document. I keep looking through the spec, which > > reads like some legal document. I'm supposed to look at the spec and jump > > to the container provider's doc to put them together and make some sense. > > This is proving to be quite time-consuming and many times unclear. As an > > example, just look at the confusion around "deferred database update" >e-mail > > thread in this distribution list. > > > > - The bulk of really interesting and relevant code is generated during > > deployment time and not supposed to be seen by the developer. Instead of > > working with me, the system is telling me "get off my turf". I am not > > supposed to care how things are persisted. This is either naivete or > > arrogance. > > > > - I'm not supposed to touch (for the most part, I'm not allowed) the > > generated stuff. If I try to customize or tweak the stuff, I'm now > > committing a mortal sin. They'll tell you, "you are breaking >portability." > > But, I don't care about portability. I want my application to work. >That's > > all I care for now! > > > > - (Though a minor point, it's related to the above) Each deployment cycle >in > > my case is generating many tens of mega bytes of jar and ear files. I > > haven't figure out the legal way to clean these out. One time, I made a > > mistake of removing some of these that the system was still using. The > > result was a mess. I realize I need to update proper XML files, >.properties > > files... > > > > Even with all the benefits of EJB, things just shouldn't be this >cumbersome, > > difficult, and cultish. Perhaps, I will learn all these in time and they > > will become a job security for me, but aren't we simple ignoring developer > > productivity too much here? > > > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > > >=========================================================================== > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the >body > > of the message "signoff EJB-INTEREST". For general help, send email to > > [EMAIL PROTECTED] and include in the body of the message "help". > > > > > >=========================================================================== >To unsubscribe, send email to [EMAIL PROTECTED] and include in the body >of the message "signoff EJB-INTEREST". For general help, send email to >[EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
