<snip> > >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.
array of name-value pairs? you mean from the HttpServletRequest object right? which servlet container are you using? > 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. Whilst I agree with some of what you are saying (see below), I'll try to draw an analogy here. In servlets, almost every request wants to get the request parameters, so the servlet container provides the code that does this. This is (I assume) the code you are referring to above when you say you see stack frames that you dont recognize. with entity beans, the task of mapping a flat bean to a flat table, is pretty much always the same. you have inserts, updates and deletes. so in CMP - this is the code that is going on. but there is a lot more involved, than simply reading out a few key-value pairs from a steam. THe real problem, is when you start about fine tuning. this is _completely_ container dependnant, and any tuning you do on one container, will not be directly portable to another (although other containers may provide the same tuning options, you'll at least need to create another config file). for example, it would be entirely possible for a container to allow the deployer to specify the SQL that is used to load a CMP EB, and so on. but it wouldn't neccessarily be portable. > >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. yes - I did mistake your point, sorry (o: > >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). I think with Weblogic you can get the generated source code, just as Jasper (the jsp engine for tomcat and jetty, and possibly others) allows you to see code generated from JSPs. But I have to say, I personally do not favour this approach. > 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. I agree, the spec is hard to read. but the servlet spec isn't much better. I would suggest that you might find the servlet spec easier to read because you know servlets. whilst I dont know the 600 odd pages of the ejb2 spec off the top of my head, I do feel comfortable reading it, but only because I feel comfortable with the architecture as a whole. If the spec was my first introduction to EJB, I doubt that I would have ever got anywhere. > - 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 think you can care, but you dont do it in the code. you do it in container specific config files. I haven't worked with the RI, so cant comment here, but working with JBoss or Weblogic, its a matter of knowing which config file does what, and tweaking what you can there. Things like lazy loading, and group loading are supported (in those two containers), if thats what you're looking for. > - 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! If the container wont let you do enought with CMP, and you want more control, then step into BMP. that way you get the best of both worlds. or - if you want container specific stuff, you need a container specific list. > - (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... agreed - again, container specific, and very hard. JBoss does an exceptional job of making this easy. I think the new JRun beta is apparently putting work in this area too. > 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? I've never used CORBA, but had lunch with a guy this week who was an old CORBA developer, and is 6 months into EJBs, and says he loves it. EJBs gives you a lot, but what you should be asking is "do I need that lot", because as you say - its not completely free - as nothing is (o: cheesr dim (who is feeling very talkative :) =========================================================================== 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".
