Ted Neward wrote:
> [snip]
> That's why RMI servers, as a *general* rule, shouldn't be tied to servlets'
> lifecycles--you can't know when the servlet is there or not. Is this a
> problem *in practice*? Probably not, and having an RMI server object for
> displaying debugging/tracing messages to any attached RMI clients can be a
> very useful trick.
>
It may not be a problem "in practice" if your initial servlet container does
not destroy servlets on the fly. But what happens if this capability is added
to the next version, and your app breaks when you try to upgrade? Or when you
switch to a different servlet container later?
It is really sad to see people choose Java based solutions (at least in part)
because of the portability promise, and then program themselves into dependence
on the features of a particular environment. (Of course, they will probably
also blame this on Java instead of their own mistakes :-). In the case at
hand, there isn't even the excuse that it's not documented -- the right of a
servlet container to destroy servlets at will is very clearly documented, and
you ignore this at your peril.
>
> In some respects, though, for sophisticated object communication, you may be
> better off having the servlet communicate as a client to an external RMI
> server, which also communicates with another RMI client (i.e., the one you
> want to run). This way, the RMI server is always there, and the servlet,
> while it's up, can connect to it and both sides are guaranteed the entire
> communication path is good.
>
The portable solution to doing this is to make your RMI server objects
something other than servlets. To provide access to them, just stuff them into
the servlet context attributes of your application. You can still accomplish
the intent described above, but not risk the portability issues.
>
> Just a thought.
>
> Ted Neward
Craig McClanahan
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
