Re: Re: [Webmacro-devel] WM-constructor

On Sat, 21 May 2005, Marc Palmer wrote:

| Keats Kirsch wrote:
| > It needs the servletContext *and* the classloader for the
| > servletContext.  WM can get both from the Servlet, which is why it was
| > done that way.  I don't think there is a guaranteed way to get the
| > servlet classloader from the servletContext.
| >
| > Let's not break all the old WM servlet code.  However if you want to be
| > explicitly pass in both arguments, I don't see any problem with that.
|
| Precisely what I was talking of doing. Breaking stuff is not going to
| happen :)

Good.

|
| However I am interested in any ideas for getting a reference to the web
| application's own ClassLoader from within a class that has no reference
| to the Serlvet, only the ServletContext.

Let at least, in any case, the Broker be highly extendable. I am not
completely happy with the "magic-ness" of template loading right now at
any rate, and would like this to be very pluggable. Also, the logging will
need to be changed at my code, because I want it to go to log4j. Last time
I was over this, I realized that I'd have to extend / replace Broker, and
a whole bunch of classes, to get this done. That was when I postponed this
to the 2.0 - and everybody knows where that have left me! ;)

Drop -every- final-modifyers. Let the javadoc tell any system developer
what is meant to be extended, and what is not - let it be a "contract"
which isn't enforced by final-nessing.

The point is that no-one may foresee which needs will arise in such
frameworks. I've -always- regretted at some point making a method final.
Suddenly you'd love to "hack just a little" at some method, and then call
super.method, or something similar. If it is final, the ONLY way you may
get around the problem, is to copy LARGE swathes of code, just becase
someone tried to outguess you on what you probably will and won't ever do.

 (This might already be the case, though - I just remember that at some
point things were way to final around WM)

Note that I don't mean that this goes for everything: APIs should be
thight to force users to use it in a proper way. However, the framework
itself shouldn't have much limits in what a systems developer are allowed
to do / extend.

|
| I suppose in theory you could use the (most/all deprecated) methods on
| ServletContext to iterate over the servlets and just grab any one and
| call getClass().getClassLoader() on it.
|
| Doesn't feel good though...

Drop the thought right away! They're -so- deprecated! I even believe they
return null now, and have done quite a while. Don't deprecate the good-ol
servlet-constructor either - I guess they have their place (although
they're unusable in Sun ONE thingy by default, due to the default SecMgr
settings in that thing).

But, at ANY RATE: DO GET THE 2.0 OUT, now!! I'd rather have it out -now-
than having any ServletContextBroker OR WHATEVER extra fixups. Pliz pliz
pliz, don't let it boil away (again) this time!!
  See, I even believe that this might be beneficial to WM: one may release
2.0.z's or 2.y's or whatnot - as long as there -is- a base that is out and
readily available.

-- 
Endre Stølsvik -  Endre@CoreTrek.[no|com]
   Work[+47 23100271] Mobile[+47 93054050] Fax[+47 23100299]



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id344&op=click