Hello John,
Tuesday, May 08, 2001, 3:31:08 AM, you wrote:
JM> There are proposals in the works regarding separating the namespace for
JM> multiple applications to run under within one Turbine instance (servlet
JM> context). I am not sure of the utility of allowing modules from many
JM> applications to be included in one application. It does not seem worth
JM> the effort involved for the majority of cases where this is not
JM> required. You can of course write your own AssemblerBrokers, they are
JM> pluggable.
This problem was raised several times from different people.
We've met this problem and solved it by implementing our own
AssemblerBroker with a few additional classes.
Here is the general idea of our multi application support over
Turbine:
- "Application" is a set of turbine modules.
- Application can be responsible for some module types.
- Application can set another application to be responsible for some
module types. Thus there are responsibility hierarchy between
applications.
- Some restriction mechanism exists: application from low level can
not control responsibility of its parents.
This is helpful in some cases, where for example you want layout
and navigations to be from core application "A" which uses
screens from external application "B". And you do not want
application "B" to change the layout of the core.
- There are TR.props entries that describes application's specific
properties in the form:
application.<app_id>.<prop_name>=<prop_value>
There are module.packages property for each application.
- There is object TurbineApplication, that holds information about
application such as app_id, description and all its properties from
TR.props.
Application can provide its own implementation of TurbineApplication
object.
- There is ExecEnvironment object that holds information about which
application is responsible for which module type. Also it knows
which application and which module is active at the present moment.
- There is TurbineAppManager service, that is responsible for creating
and holding TurbineApplication objects and also manages current
ExecEnvironment.
- There are module factories that are used by AssemblerBroker. This
factories use ExecEnvironment to get information about responsible
applications. This is how factory knows where to load module from.
As a result, we can have several applications. Each can be responsible
for different module type. It is not necessary for application to be
aware about such "multi application environment". Naming restriction
problem is solved. Applications dynamically can call modules from another
applications. Thus they can form responsibility hierarchy, which creates module
inheritance (if module can not be found in some application, it will
be looked in its parents).
All this was done without patching turbine. Currently we are testing
this approach. If all this makes sense, it can be integrated to
turbine itself. In this case we should do some work to change it
from "our specific" to "turbine common" and it will take some time.
/ Shamil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
