Ron Yust wrote:
> Wow! No static methods/data, no file i/o, no threads, no sockets, no native
> code. Sounds like EJB is an unruly teenager about to take the family car
> out on a date. Geeesh, just neuter the EJB application! I may end up
> sticking with my trusty old RMI server.
Sounds pretty bleak, doesn't it? I think it shows the relative
immaturity of the EJB/J2EE architecture. Clearly the ability to
use parallelism (threads), I/O, etc. are useful. What's needed
are container-friendly ways to access them. This stuff just
isn't specified yet.
However, from my experience, we can actually get away with doing
many of the prohibited things *if* we can understand the reasons
they are prohibited and how we can safely work around them. I
posted some thread issues that can be worked around earlier, and
I just posted some static issues. But unfortunately, these
work arounds are not to spec and often depend on the specific
container implementation, so they are at risk for rework in the
future as things get more specified and mature.
An alternative approach is to know what the future J2EE specs
will add (like connectors), and build our own version of them
for now with an easy migration later. But this requires either
access to internal Sun resources or a crystal ball.
Life on the bleeding edge...
Paul
===========================================================================
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".
