I think we'll have to agree to disagree.

Every EJB server vendor offers container-specific options.  Using a
cast instead instead of PRO.narrow is a WebLogic-specific option.

I recommend to BEA WebLogic Server users that they use PRO.narrow in
their beans for portability reasons.

BEA does not in any way require that users write non-portable EJBs.
IMHO, this is what is important.

Admittedly, the EJB sample code in some of our older releases did not
correctly use PRO.narrow.  To my knowledge, this has been corrected in
WLS 5.1.

-- Rob

Rob Woollen
Senior Software Engineer
BEA WebLogic
[EMAIL PROTECTED]



On Fri, Sep 01, 2000 at 02:04:45PM -0700, Jonathan Weedon wrote:
> Rob,
>
> Maybe my mind works differently, but to me, the two statements:
>
>         "BEA does not encourage users to write non-portable code."
>
> and:
>
>         "In our RMI/T3 implementation, PRO.narrow is a no-op."
>
> are contradictory.  To me, making PRO.narrow a no-op encourages
> users to write non-portable code.
>
> Again, that's why we decided to NOT make the "magic" casting
> capability the default.  If we had done otherwise, as does
> WebLogic with T3, it would encourage people to write non-portable
> code.  I would bet that well over half of all WebLogic users
> have portability bugs in their EJBs, due to the fact that there
> are no PRO.narrows where there should be, according to the EJB
> specification.  I'd even bet that over half of the example code
> that BEA ships and/or uses in its training material is
> incorrect in this regard.  Certainly, we have seen our share of
> ex-BEA users who were chagrined to discover that all the code
> they were writing against WebLogic was not actually portable.
>
> Just my opinion, of course...
>
> -jkw
>
> Rob Woollen wrote:
> >
> > On Fri, Sep 01, 2000 at 11:43:06AM -0700, Jonathan Weedon wrote:
> >
> > [SNIPPED good PRO.narrow discussion ]
> >
> > > One last note: two version of our product implemented the "magic
> > > stub" behavior required to avoid narrows.  The more recent is the
> > > current release, which has a runtime flag which can be set to avoid
> > > the necessity of using PRO.narrows.  We did not enable this flag by
> > > default, as we felt this would encourage users to write non-portable
> > > code, a la WebLogic.  But VBJ 4.1 now has this capability, as does
> > > IAS 4.1.
> > >
> >
> > BEA does not encourage users to write non-portable code.  Using
> > PRO.narrow works fine in WebLogic Server.  In our RMI/T3
> > implementation, PRO.narrow is a no-op.
> >
> > -- Rob
> >
> > Rob Woollen
> > Senior Software Engineer
> > BEA WebLogic
> > [EMAIL PROTECTED]
> >
> > ===========================================================================
> > 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".
>
> ===========================================================================
> 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".

===========================================================================
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".

Reply via email to