Hu Shih wrote: > > Please forgive my frustrated tone, but > <snip> > > EJB changed all this. They stuck a rather long, tedious, and often painful > deployment phase right between compile and test-run, often breaking the > development cycle with 10 to 20 minute breaks.
I agree - the J2EE RI deploytool is brain-dead. The value it adds should be considered as development, and the jar-ifying and installing into a server should be quick, automatic, and a separate step. My approach is to run each EJB I develop through a code-generating tool (deploytool, ejbdoclet, etc) a few times until I'm sure I'm specifying the right options. Then I unjar its output, put the text files (ejb-jar.xml etc) into the development source tree and never use the tool for that EJB again. For the actual deployment I write a .cmd (Windows) file to compile the java code, jar everything together again and deploy the result - other people use ant to make this even quicker and easier. Now simple coding bug fixes can be turned around in under a minute. More serious bugs that affect multiple source files are harder of course but that is the nature of distributed application development. > Debugging such a deployed app is a nightmare. Because EJB (especially CMP) > generate so many classes and because so many of these are system generated > stuff, I have very little idea what's going on or what I have done wrong. One advantage of the above approach is that you do learn what all the files are and how they interrelate. This makes it a bit slower to begin with, but your ability to fix hard problems later in the cycle is magnified greatly. > Also, so much information that are important to developers are hidden away > from them in multi-level jars/ears/wars, etc. (and these things are > humongous). And, why so many classes? When running, I see over 4 classes > generated for each EJB bean. This is excess and debugging nightmare! If you follow the above approach you will soon be able to answer your own question as to why these files are necessary (BTW, not all app servers have so many). Your criticism that many EJB development approaches seem to force you to regenerate all these classes for EVERY minor coding change is entirely valid. <snip> > Developers are an impatient and controlling bunch. Java has been good > because it gives speed of development and gives enough control for > developers. In my opinion, EJB is going backwards (the wrong direction). > Is there an effort to address these? Or, is it that to be an EJB developer, > you have to take all this willingly and gladly? No we shouldn't take it gladly. But there are ways to solve the problems. Not one universally accepted way, so you have to find an approach that suits you. cheers... Ian ======================================== Ian McCallion Alexis Systems Limited Romsey, UK Tel: +44 1794 514883 Fax: +44 1794 501692 ======================================== =========================================================================== 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".
