How long is your build->deploy->run cycle anyway. It takes me about 15-20
seconds from compile to app server running on a 300 MHz Pentium II notebook.
That's with Ejipt (now JRun 3). It takes longer (probably 60-90 seconds) with
Weblogic because of the long startup time. Is this too long?
I run the ejb server(s) in the IDE for debugging purposes. For tough coding
errors, it might take a few tries, but most of the time one or two cycles is
enough to get a new bean working. I've used JBuilder, Visual Age and
Codewarrior. I prefer Codewarrior because it doesn't use it's own classloader
and mostly doesn't get in the way. If you're spending all your time in the
compile->deploy->test->fix cycle, there may be some basic engineering issues
that need to be addressed.
Of course a good framework and persistence mapping tool go a long way to
reducing development time. The only real time in the server development time is
the business logic.
--Victor Langelo
Humphrey Sheil wrote:
> I've been trying to improve this for a while and I've come to the conclusion
> that beyond doing what I've listed below, there isn't anything else possible
> to reduce the net amount of development time required in the EJB world at
> present.
>
> So the problem is that our code->build->deploy->test cycle is taking too
> long, especially for impatient developers who are new to the distributed
> component model. We've been using javabeans / Servlets and jsps on
> e-commerce apps. prior to adopting a fully-fledged J2EE architecture and as
> you can all imagine, although it's not as powerful, it's a hell of a lot
> faster to develop in.
>
> Here are some of the things I've been looking into to mitigate the problem.
>
> 1. Hot deploy of EJBs when supported by app. servers. Instead of having to
> bounce the server, instead redeploy your EJBs.
>
> 2. Invest in an IDE with a dynamic class loader to reload changed classes
> (e.g. Visual Age).
>
> The problem with both approaches above is that any changes to either the
> home or remote interfaces (method names, params, throws clause etc.) or
> referenced support classes (usually value objects) means that you still need
> to stop, rebuild and restart. In my experience, this accounts for a large
> part of the time when I want to hot deploy anyway!
>
> Even given that I've met the restrictions above, if I want to be sure that
> an exception I'm getting is my fault and not the hot deploy feature or funky
> IDE classloader, I'll bypass them and bounce the server anyhow (do you have
> 100% faith in your hot deploy feature or IDE?)
>
> I'm not worried about having to hot deploy gracefully to a production system
> (that's a whole other problem in itself), my only concern is speeding up the
> development cycle.
>
> 3. Use jikes to reduce the build cycle time - I haven't seen any great
> reduction in time here.
>
> Are there any design patterns, rules of thumb, howtos etc. that I'm missing
> which are applicable here? I had thought of building business logic first
> as a regular Java class and then moving over to an EJB approach when the
> class does what I want, but I feel this will lead to headaches later on down
> the line as you have to add in the EJB plumbing (JNDI lookup, etc. etc.)
> Plus, divorcing what I want (business logic) from how I get it (the EJB
> model) doesn't make that much sense (at least not in our world at present).
>
> On the subject of IDEs, I've evaluated most if not all of the IDEs promising
> tight integration with various app. servers and I find them all unstable
> enough that when something goes funny in development (especially if I'm
> building on more than a couple of EJBs), the first thing I do is close down
> the IDE, bounce the app. server and start from basics myself so I don't
> think they're good enough to address this problem yet.
>
> I'm interested in hearing about other folks best practices on this subject.
>
> Humphrey
>
> PS If anybody else wants to get into the steel building market for peanuts
> let me know, I think we can beat the guy down if we go for a bulk purchasing
> strategy.
>
> ===========================================================================
> 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".
