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".
