[EJBs] Development Problems.

[John]

I though I'd post some of my findings in learning EJBs to see how they
compare to other people's.

I installed J2EE and Appserver 8, and worked through the tutorial on
EJBs without any problems. I then spent a few days getting a different
database working with the tutorial example: time consuming but it worked.

Where I came unstuck was when I started trying out some of my own
examples. Examples that I had checked time and again compiled fine,
deployed fine, then threw horrendous cryptic JDO exceptions. Eventually,
by a process of elimination, errors could be isolated to specific
aspects of the design, but it seems impossible to narrow problem
characteristics to more than "that design doesn't work".

A particularly time-consuming problem seems to be that when you make
changes to code, recompile and update the files in deploytool, remnants
of older versions seem to drift around in the deployment descriptors ..
so you have to redo the whole project from scratch in deploy tool.

These factors lead me to seriously question the feasibility of using
EJBs to deploy anything other than trivial projects (purely on
development time). The main contributing factors seem to be (1) an
inability to accurately diagnose/identify problems and (2)
labour-intensive rebuilds after each change.

I can't help feeling that managing persistence using session beans and
JDBC is the only real option until this technology matures a bit. I will
probably spend a couple of days seeing if using Pointbase rather than
MaxDB allows me to attribute (1) to MaxDB, but if it doesn't, I think
I'll have to give up on EJBs (a shame since they seem like a good idea).

I hope that someone feels I've just given perfectly good products an
unjustified slagging. Your recommendations / experiences may be able to
get me back on track!

John

 

[Bryce]

These factors lead me to seriously question the feasibility of using
EJBs to deploy anything other than trivial projects (purely on
development time). The main contributing factors seem to be (1) an
inability to accurately diagnose/identify problems and (2)
labour-intensive rebuilds after each change.

Modularize and test in isolation. EJB's can be tested using Cactus.
Session Beans can be tested using Cactus and Mocked EJBs. Its really
not that difficult, and many large scale projects have been completed
and implemented.

I can't help feeling that managing persistence using session beans and
JDBC is the only real option until this technology matures a bit. I will
probably spend a couple of days seeing if using Pointbase rather than
MaxDB allows me to attribute (1) to MaxDB, but if it doesn't, I think
I'll have to give up on EJBs (a shame since they seem like a good idea).

The option you give above is a viable option. I've used both Entity
Beans and DAOs (Hibernate and home grown DAOs, see DAO pattern).

 

[Sudsy]

John wrote:

A particularly time-consuming problem seems to be that when you make
changes to code, recompile and update the files in deploytool, remnants
of older versions seem to drift around in the deployment descriptors ..
so you have to redo the whole project from scratch in deploy tool.

Can't disagree with you here. It took me a fair bit of trial-and-error
to create an environment (using ant, natch) which would deploy my
applications consistently. Then Eclipse came along and made it all
easy...
Teething pains are not a good justification for throwing everything
away.

These factors lead me to seriously question the feasibility of using
EJBs to deploy anything other than trivial projects (purely on
development time). The main contributing factors seem to be (1) an
inability to accurately diagnose/identify problems and (2)
labour-intensive rebuilds after each change.

I have to disagree. With WebSpere I was able to replace only those
classes which had been modified: I didn't have to rebuild the EAR
every time.
As to problem diagnosis, I just don't see those kinds of problems.
Debugging by looking at stack traces, output from printlns, or real-
time using something like Eclipse, while challenging at times, is not
impossible. It can be tricky when exceptions get wrapped and you have
to weed through the chain to find the original exception...

I can't help feeling that managing persistence using session beans and
JDBC is the only real option until this technology matures a bit.

I strongly disagree here. There are just too many "special cases" in
the popular RDBMSs which JDBC SQL would have to reflect. I'd rather
leverage the efforts of others to simplify my programming/maintenance.
I use entity EJBs whenever possible. It might take a bit more effort
up-front but that gets repaid if you have to deploy to multiple
platforms.
So it's challenging; so what? That's why they pay us the big bucks,
right? (chortle!)