On 6/13/01 8:00 AM, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
> 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.
Actually the turbine services are availble to a subapp
in the little application service for turbine that I
play with.
>
> 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?
It may eventually evolve to something like this. It is very possible
that a subapp could have it's own set of services too, but not
with the way the turbine services work right now.
> 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,
Again, not completely possible right now given Turbines current
service setup. The eventual goal is full containment for sure.
Other than Turbines logic for the view, almost all functionality
is derived from services. So with some changes to the services
and possibly making the view logic a service, full containment
is fully possible. But this will take some time :-)
> 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.
Yup.
> 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
--
jvz.
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
