Just to be clear, I am all for making the change to add the ability to
create separate instances, and will dive in with gusto.
I just want to explore the idea fully to make sure we don't do something
hasty. We have a good thing going here :)
I am having a busy week professionaly, so I ran out the clock this
mornning - I need to go. I should have responded last night better, but
was too occuppied benchmarking JSP vs Velocity. Velocity is faster, at
least w/ tomcat 3.2.x so far. More on that later.
My only thoughts so far, and this is more related to your Turbine
proposal rather than the issue in Velocity, is that it sounds like your
subapp architecture mimics the standard webapp architecture - for
example each has a classloader. I assume you do this because there is
no way to have a 'exoskeleton' in a normal servlet webapp architecture
where a set of common services are available to multiple webapps? I
think this is an interesting issue on it's own.
Also could each subapp be more contained? For example, it sounds like
each is a mini-turbine so could it manage it's own resources and such,
so they aren't depending upon the main turbine infrastructure to provide
template management? Since you are making hard partitions between the
subapps, it doesn't appear that anything is gained other than complexity
by making Mother Turbine do it instead of the subapp, since I would
guess that turbine's resource management would scale nicely down to the
subapp level. While this would solve the problem immediately (each
subapp would have their own Velocity instance because each has a
classloader), it would also remove any behavioral restrictions on the
subapps - they could do anything they wanted to wrt resource management.
Ok. Out of time. More tonight.
geir
Rafal Krzewski wrote:
>
> "Geir Magnusson Jr." wrote:
>
> > Yes. Let me ask a question.... What is the *real* problem? I suspect
> > it will be how to solve the problem of partitioning template sets apart
> > from one another for 'subapps' to avoid collisions....?
>
> Template name collisions can be avoided by putting them into different
> directories under the search path. That is easy to implement and would
> work well for many applications. However there are more things in
> Velocity
> that have global scope than just template names (used as keys in the
> cache):
> - Configuration settings that affect rendering (each subapp might wish
> to
> configure Vel bit differently)
> - VelociMacro libraries
> - Introspection cache (each subapp uses a separate classloader, thus
> they
> can use classes with same names but incompatible interfaces)
>
> The main idea behind subapps is that they will be developed separately
> and
> then assembled into a web application. Using separate Velocity engines
> by each of them would help to decouple the sub-applictions, and decrease
> neccessary communication between teams developing them.
>
> Rafal
>
> PS. Could you run the speed testing suite on the patched Vel, or tell me
> real quick how to do it?
>
> --
> Rafal Krzewski
> Senior Internet Developer
> mailto:[EMAIL PROTECTED]
> +48 22 8534830 http://e-point.pl
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
