well to give it a thought I had been initially evaluating both the inprise
and weblogic servers and the client code that I wrote for weblogic ran
perfectly in the inprise! in the server code I had to change the xml dds --
though the code I was testing was pretty simple -- but even if PRO is a noop
in WLS --- that should not be an issue as long as people use PRO.narrow isnt
it? even if I use the weblogic ismodified stuff --- thats purely deployment
stuff and will get ignored by other containers. whatever proprietary stuffs
weblogic provides are all dd props -- like the delay-update-till-tx etc --
so why should there be any problem?? I think if anyone knows the real
significance of the dd specific props in weblogic he/she can or will be
writing portable code.
in fact weblogic does not give any API level extension to the ejbs --
compare it with Powertier --they give atleast 10 powerful new methods to the
UserTransaction interface -- so if u use them in ur code then it dosent
become portable.
these are just my thoughts.
cheers
Anamitra
-----Original Message-----
From: Jonathan Weedon [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 01, 2000 5:05 PM
To: [EMAIL PROTECTED]
Subject: Re: PotableRemoteObject
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".
STATEMENT OF CONFIDENTIALITY. The information contained in this electronic
message and any attachments to this message are intended for the exclusive
use of the addressee(s) and may contain confidential or privileged
information. If you are not the intended recipient, please notify
USPowerSolutions Corporation immediately at (617) 547-3800, or at
[EMAIL PROTECTED], and destroy all copies of this message and any
attachments.
===========================================================================
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".
