Ingo Schuster wrote:
> Hello
>
> In his book "Enterprise Java Computing" Govind Seshadri writes:
> "I would not recommend accessing an RMIlet using RMI clients due to
> servlet lifecycle issues." (By RMIlet he means a servlet implementing the
> Remote interface).
> Does anybody have an idea why you shouldn't access an servlet via RMI?
> What exactly does he mean by "lifecycle issues"?
>
The lifecycle issue is that a servlet container is free to start and stop an
instance of your servlet whenever it wants to, as long as it calls init() and
destroy() at the correct times. In the normal servlet container case, the
container will release its object references to the servlet instance, and
allow it to be garbage collected. If you've registered that same instance as
an RMI server object, there are still references to it within the RMI
implementation logic.
However, there is a more serious design issue with this approach. Servlets
are generally used to provide an HTTP-compatible interface to some underlying
business logic. Likewise, RMI server components are generally used to provide
an RMI-compatible interface to business logic. If you really need your
business logic accessible via both protocols, you should create a new object
that encapsulates that logic, and then use servlets and RMI server objects
that accept requests and utilize the shared business logic object behind the
scenes. Trying to make one object do to many things (in this case, act like a
servlet and an RMI server object) is creating needless complexity.
>
> Thanks,
> ingo.
>
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
