Re: [Webmacro-devel] I'm actually working on WM :) A locking question...

[Eric B. R. <eb...@tc...>]

I'm pretty pissed.  I spent about 30 minutes working on a response  
this morning and somehow it has mysteriously disappeared.  I thought  
I sent it, but I can find no trace of it in my Sent Items nor on this  
list.  Maybe OS X isn't so easy to use afterall!

Anyways, here's the abridged version...

> Once every time a not previously visited JSP page is compiled.

That's what I was expecting you to say.

> So you see it's using the ServletContext which if memory serves  
> correctly should be the same for every servlet... and yet we still  
> get N "WebMacro initializing" log outputs.

Apparently this isn't true.  The "Servlet22Broker" class caches  
instances in a central map key'd on ServletContext.  If you trace  
through the code you'll eventually find that it stores WeakReferences  
to the XXXBroker instances.

So either each JSP is getting its own, unique ServletContext or the  
WeakReferences are causing your previously-instantiated Broker  
instances to be gc'd too quickly.  I'm betting on the former.  I  
think ServletContext is per Servlet, not per "web-app".

We've written our own servlet engine/webserver here at TCDI and  
that's how we interpreted the jsdk spec.  Granted, our engine doesn't  
do JSP's, but still, a JSP is just a Servlet.

> The problem is that we cannot instantiate WM until we have a JSP  
> pageContext that is valid, as that is the only way we can get a  
> ServletContext so that WM uses a ServletBroker.

Right, and that is what sucks about the various ServletBrokers.   
Personally, I'd spend the extra time to construct a  
WebMacro.properties file that knows how to load templates from the  
same places as the ServletBrokers do.  The whole idea of storing  
templates inside WEB-INF/ is, imho, just plain silly.  Put 'em in  
your classpath (ie, in a .jar) or directly on the filesystem.

If you do this, you'll be able to create ONE WM instance that all  
your servlets and taglib instances can share.

> I'm pretty sure we can work around this with a simple concurrent  
> class - I just need to know which.

I think that's overkill and that you'd be happier with a non-servlet- 
based WM instance.

eric