"Laird J. Nelson" wrote:
>
> [...]
>
> Bleagh. So my group's work for the past half year or so--on developing reusable
> plain-Java services that we hoped could be used by any application, EJB-based
> ones included--cannot now be called from our beans, because it creates and
> works with threads. Oh sigh. Our centralized logging service, for example,
> now violates EJB policy on two fronts: it uses the java.io package *and*
> creates threads. Silly us, thinking that we could use those features which the
> JDKSE gives us for free!
I have watched this so many times... when developers first truly realize
what
they can't do in an EJB environment. If it weren't so frustrating, it
would be
comical... like watching every skiier coming down the hill wipe out on
the same
icy stretch. The reaction is almost univerally the same... "bleagh" as
you put it.
But I think the longer you work with EJB, the more you grok why these
restrictions
are in place and the more you come to think that the EJB specification
writers
did the right thing. An EJB server *has* to be able to control its
environment,
to include all resource utilization. Stability, security, and
scalability demand
it. And the EJB specification writers had to enable vendors to offer
advanced
products based on the specification (eg, EJB implemented *in* a
database, or a
multi-VM shared-memory approach, etc.)... some of which are incompatible
with
threads or file I/O.
But I am guessing that whatever EJB server you are using, you can bend
the
rules to a degree. There is usually a way to get around the
restrictions, as
long as you can live with the "less than portable" nature of your code.
-eric
===========================================================================
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".
