unfortunately, that's just the problem. that's what i'd like to
do, but the implementation classes are instantiated two levels down:
TopServlet makes newInstance() of FirstClass which makes
newInstance() of SecondClass which makes newInstance() of
ImplementationClass
all three of TopServlet, FirstClass, and SecondClass are "frozen" in
the sense that if they are changed, it ripples through lots of
implementation and worker classes, not just mine. not an option to
modify the class interface.
in particular, the implementation classes are created in classes which are
not servlets, nor are their containing classes.
it's in these implementation classes, which do all of the work one
generally sees in servlets, that the ServletContext would be
valuable. but the original designers, all gone to other bit buckets,
chose to disengage the servlet classes from implementation ones. this is
seen in the use of dynamic object creation. normally, this is a
'good thing'; i'm not so sure it is when dealing with servlets.
what got me curious about the situation is that, from lexical scoping
and address space points of view, a contained class is just
like a method in a class, which can see and manipulate instance variables
of its containing class. all of this stuff is contained in the
address space of the originating servlet. the methods of a contained
class can see the instance variables [a ServletContext instance, in
this case] of everything 'above' it in the containment hierarchy.
certainly, the symbol table is visible. put another way, i know
who made me; i know the object in which i exist. and so on up the line.
apparently, the java specification does not allow that visibility to be
acted on; although i've not found any discussion of it, nor have i spent
much time thinking about any negative implications. must be some.
since i can trace my parentage, logically, the following is true:
ImplementationClass.getCreator(getCreator(...)).getServletContext().getAttri
bute("somethingCool")
because it resolves to:
TopServlet.getServletContext().getAttribute("somethingCool")
if there were a getCreator method.
robert young
-----Original Message-----
From: A mailing list for discussion about Sun Microsystem's Java Servlet
API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of
Matthias Carlsson
Sent: Thursday, October 19, 2000 02:47 PM
To: [EMAIL PROTECTED]
Subject: SV: ServletContext & newInstance
I've never tried what you explain, but can't you pass the servlet's
ServletContext as a parameter when creating your worker (and implentation)
classes?
Like, set your worker classes to receive a ServletContext interface in it's
constructor and then create the worker class inside the servlet by doing
something like this:
Worker worker = new Worker(this.getServletContext());
[ Matthias Carlsson ]
[ Programmer (Java, CGI/Perl, Javascript, HTML) ] [ Web Designer ]
[ E-Mail : [EMAIL PROTECTED] ] [ ICQ: 1430647 ]
[ http://home1.swipnet.se/~w-18931/programming/ ]
> -----Ursprungligt meddelande-----
> Fr�n: A mailing list for discussion about Sun Microsystem's Java Servlet
> API Technology. [mailto:[EMAIL PROTECTED]]F�r robert young
> Skickat: den 18 oktober 2000 17:37
> Till: [EMAIL PROTECTED]
> �mne: ServletContext & newInstance
>
>
> the system with which i am working was designed such that
> the servlets in the code base do little but instantiate
> 'worker' classes. these are created dynamically using
> newInstance(). then the actual implementation classes are
> instantiated [with newInstance()] by these objects.
>
> it would be really useful to stuff stuff into the ServletContext,
> from the implementation classes. ServletContext is, i think,
> visible to the implementation classes at runtime, since they are
> created in the scope of the originating servlet. or not?
>
> i've not found any syntax that will compile. is there any
> way to reference the ServletContext in this scenario?
>
> thanx,
> robert young
>
> __________________________________________________________________
> _________
> 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
___________________________________________________________________________
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
