Paul Hodgetts wrote:
> So, yes, you do need to know about any classes that your EJB code will
> use. I'm not sure if this "blows reusability out of the water" or not,
> but that's for you to judge. What it means is that for a class library
> to be "compatible" with an EJB container, it needs to follow the same
> programming restrictions that our application code must. So the class
> library must be "certified" as "EJB compliant" - if we can use those
> terms (no, there is no official certification that I'm aware of).
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!
> For parallel processing, we don't have many options. AFAIK, the best
> option is to use JMS's message session pooling to process messages in
> parallel.
I don't understand. Surely invoking JMS in any fashion results in a new thread
being created. Is this thread creation "legal" because it is the container
vendor who has implemented it?
> This assumes the container actually implements JMS of course.
> Again, maybe someday we'll have some standard facilities for creating
> and managing container-compatible threads, but not yet.
The more I work with this specification, the more I dislike it.
Thanks for your informative and thoughtful reply.
Cheers,
Laird
===========================================================================
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".
