We successfully use IBM's VisualAge for Java with it's WebSphere test
environment, which allows us to test against multiple EJB servers running
in the IDE, and as code changes, there is no need to 'redeploy'. We just
change source, and as the EJB Servers use the IDE environment, they pick
up the new changes as we make them.

Having said this, it's not EJB 1.1, Servlet 2.2 or JSP 1.1 or J2EE
compliant. So that limits its usefulness.
--
dIon Gillard, Multitask Consulting
Work:      http://www.multitask.com.au
NetRexx: http://www.multitask.com.au/NetRexx.nsf
----- Forwarded by dIon Gillard/Multitask Consulting/AU on 12/07/00 09:40
-----
MI2: Strategies to reduce EJB development time?

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





Previous Document


Next Document
Return to View

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

Reply via email to