Hi!
Haven't read through EJB1.1 yet, but lets take a look at the "Changes"
section.
* "Allowed using java.lang.String as a primary key type."
This is great! No more pointless primary key string wrappers...
* "Added requirement for hashCode and equals for the primary key class."
I still wonder why this wasn't in EJB1.0. Must've been an oversight at
the time. Vendors, hands up: how many relied on this anyway?
* "Deprecated the package javax.ejb.deployment by replacing the
JavaBeans-based deployment descriptor with an XML-based deployment
descriptor."
This is so great. Since the EJB1.0 classes were buggy it was impossible
to take descriptors made with one server and put them into another. And
since some servers (you know who you are) even used their own descriptor
classes it was impossible even if they had been bugfree... XML is def.
the way to go.
* "Clarified that the enterprise bean class may have superclasses, and
that the business methods and the
various container callbacks can be implemented in the enterprise bean
class, or in any of its super-classes."
Again, great. Anyone who is serious about this stuff should make common
superclasses which hold generic code. It is very important for
maintenance and cod readability.
* "Fixed the example that illustrates the use of handles for session
objects. Serialized handles are not guar-anteed
to be deserializable in a different system, and therefore they cannot be
emailed."
Hm, what's this? Handles aren't deprecated??
* "Fix an error in the requirement for how a Container must deal with
inter-EJB invocations when both the
calling and called bean are in the same JVM. The correct requirement is
that the RMI semantics must be
ensured, and therefore the Container must not pass non-remote objects by
reference."
I guess the one who will suffer most from this is Weblogic/Tengah who
relies heavily on intra VM optimizations. There are pros and cons with
this kind of optimization, but as a whole I agree with the above
decision.
* "Changed the specification of the return value type of the
ejbCreate(...) methods for entities with
container-managed persistence. The previous specification required that
the ejbCreate methods are
defined as returning void. The new requirement is that the ejbCreate
methods be defined as return-ing
the primary key class type. The implementation of the ejbCreate method
should return null. This
change is to allow tools, if they wish, to create an entity bean with
bean-managed persistence by sub-classing
an original entity bean with container-managed persistence."
Aahh.. this is a goodie, and more important than what you might think.
My server, XS, actually was designed for this at first (i.e. subclassing
beans to provide CMP). It was only late in my implementation that I
realized that I needed the above to make it work. This addition will let
tool vendors make generic CMP managers that can be used with *any* EJB
container which is, of course, very good.
* "Support for entities has been made mandatory for the Container
Provider."
Great, fabulous and superb. :-) What's more to say?
* "Clarified what �proper transaction context� means in the Chapter on
entities."
This is good as it has been a FAQ on this list.
That's about it for now. All in all, EJB1.1 seems like a killer. Anyone
mention MTS and I will laugh loudly 8-)
/Rickard
--
Rickard �berg
Computer Science student@LiTH
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
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".
