>your particular situation, I don't think you need to shy away from using
>a singleton to implement a shared resource in a pre 2.1 environment.
I do not claim that it should be prohibited to use it. The subject of this thread
was why Sun has decided to re-educate us (using the QoW) on sharing
objects between servlets. The 'public static' Singleton pattern is the most
established 'antipattern' of servlet programming. Decide for yourself but be
aware of the fact that you are creating 'global variables' in a scope that is not
restricted to your own application. I do agree that it depends on the particular
context in which the servlet will be used (and how likely it is it will be reused
in another context).
The code of classes can always be borrowed. That is true. Only static code
can directly affect running application instances, though, and cause loss of
data or worse. If you get access to the same instance of the resource that
is used by another application, you may have obtained the access through
the constructor of a non-Singleton class (the constructor of a Singleton al-
ways being private), but the reference to the resource is definitely static.
This is one of the reasons why static code is bad coding style in servlets
(if loaded through etc...). Even if you have some brilliant authentication
mechanism for obtaining a reference to the Singleton, there may be some
other class in your application that will obtain it if instantiated with some
simple constructor.
>shareable resource. The security risk with singletons is to your own
>application; you are letting any application on the system get a
That is the most common risk. If you use code that is commonly available
(commercial libraries, code examples on the Internet) you may actually inter-
fere with other applications. This is by the way also an argument for using
Sun's package name convention (again depends on the particular context
etc...).
Alexander W. F. Boer
Dept. of Computer Science and Law,
University of Amsterdam, the Netherlands
email: [EMAIL PROTECTED]
----------
Van: Randy Belknap[SMTP:[EMAIL PROTECTED]]
Antwoord naar: A mailing list for discussion about Sun Microsystem's Java
Servlet API Technology.
Verzonden: Friday, October 08, 1999 9:16 PM
Aan: [EMAIL PROTECTED]
Onderwerp: Re: QoW - How can I share objects among servlets?
> But that does not solve the general
> problem: A system administrator cannot just put your jar file in the CLASSPATH
> and trust you if it contains suspicious 'static' code.
>
I'm not sure I see why static code is any worse a risk to the system
than non-static code. If a class is in the classpath you can still
instantiate it with 'new' and you will end up with access to the
shareable resource. The security risk with singletons is to your own
application; you are letting any application on the system get a
reference to the actual shared resource. If this isn't a problem in
your particular situation, I don't think you need to shy away from using
a singleton to implement a shared resource in a pre 2.1 environment.
___________________________________________________________________________
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
___________________________________________________________________________
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
