Avi,
Thinking about this a bit more, I decided what it is I found irksome
about Cedric's posting. It is not so much the fact that BEA provides
early access to EJB 2.0 draft specifications. If they want to provide
this, that's fine. If customers understand the issues involved, and
want to use it, that's fine.
What I find problematic is that a question was asked:
Q: Can I use a join in a finder method query.
And an answer was provided:
A: No, you can't, in EJB 1.1. However, you can in EJB 2.0.
This is completely incorrect. The correct answer is yes, you can use
joins in EJB 1.1 finder methods, but it is not standardized (along
with every other aspect of OR in EJB 1.1). In fact, I would bet that
joined queries are supported by every major EJB 1.1 CMP implementation,
with the exception of WebLogic's. I know, for example, that this
feature is supported by WebSphere, CocoBase, TOPLink, RI and BAS.
(Those happen to be the servers and OR mapping tools I know about.)
And here, Avi, you had a similar experience. You had a problem with
BEA's EJB 1.1 implementation: you were stuck with their pessimistic
locking model. Again, pessimistic locking is a limitation of WebLogic's
Entity support; it is not a limitation of the EJB 1.1 spec. And again,
pretty much every other EJB 1.1 product on the market is not hindered
by pessimistic locking. But again here, you moved to EJB 2.0 to get
optimistic locking, when this locking model has nothing whatsoever to
do with EJB 1.1 vs. EJB 2.0.
Of course, there is nothing wrong with moving to EJB 2.0. What I
am concerned about is if BEA starts telling customers that there are
limitations in EJB 1.1, and that they HAVE to move to EJB 2.0, when
in fact these limitations are not in EJB 1.1 (the spec), but rather
in BEA's implementation of EJB 1.1 (the product).
Given that EJB 1.1 is, at the current time, the latest official release
of EJB, it seems unreasonable for BEA to be promoting EJB 2.0 (the spec)
as a way to workaround limitations in their EJB 1.1 implementation
(the product).
-jkw
Avi Kivity wrote:
>
> >
> > > However, I truly believe that
> > > those who will have experimented with the EJB 2.0 preview
> > will have a big
> > > headstart when their company decides to switch over to EJB
> > 2.0 after the
> > > specification has been finalized.
> >
> > I would like to see some end customers comment on how useful this is
> > compared with the pain of rewriting code that they expected would
> > only require 'minor' changes.
> >
> >
> We moved to the EJB 2.0 implementation in WebLogic 5.1 (and now 6.0) but not
> for the API, we had problems with pessimistic locking that the 2.0 preview
> solved.
>
> In all, the changes from the 5.1 EJB 2.0 implementation to the 6.0 EJB 2.0
> implementation were minor (compared to the other aspects of the upgrade).
>
> The 1.1 -> 2.0 upgrade is admittedly difficult, but must be taken in any
> case. Some hacking with perl automated most of it.
>
> The WebLogic EJB implementation is *not* an area where I have complaints
> (but I would like to see finders-load-bean and CMR integrated!)
>
> - Avi
===========================================================================
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".
