You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Thomas Vandahl <tv...@apache.org> on 2008/12/08 22:29:10 UTC
Loaders, AssemblerFactories etc.
Hi folks,
I'm currently trying to understand the structure of the Turbine modules.
As far as I understand, the way is as follows:
- The loader checks for the module in its cache (if so configured)
- If not found, the AssemblerBrokerService is consulted for an instance
of the module
- This in turn requests a factory to generate the instance.
In the middle of this process the TemplateService and a couple of
mappers are involved. Some of them provide their own caching in addition
to the loaders.
Could some kind soul of the senior developers please shed some light on
the reasons for this design. Something obvious I have missed?
If there is consent, I'd propose to clean this up a bit and to let the
factories do all the work. Would that sound insane to anyone?
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
AW: Loaders, AssemblerFactories etc.
Posted by Juergen Hoffmann <ho...@apache.org>.
Damn Keyboard Shortcuts ;)
Here ist he url
http://svn.apache.org/viewvc/turbine/core/branches/TURBINE_2_3_BRANCH/src/ja
va/org/apache/turbine/services/jsonrpc/
Kind regards
Juergen
> -----Ursprüngliche Nachricht-----
> Von: Scott Eade [mailto:seade@backstagetech.com.au]
> Gesendet: Dienstag, 9. Dezember 2008 06:00
> An: Turbine Developers List
> Betreff: Re: Loaders, AssemblerFactories etc.
>
> Thomas Vandahl wrote:
> > Hi folks,
> >
> > I'm currently trying to understand the structure of the Turbine
> modules.
> > As far as I understand, the way is as follows:
> >
> > - The loader checks for the module in its cache (if so configured)
> > - If not found, the AssemblerBrokerService is consulted for an
> instance
> > of the module
> > - This in turn requests a factory to generate the instance.
> >
> > In the middle of this process the TemplateService and a couple of
> > mappers are involved. Some of them provide their own caching in
> addition
> > to the loaders.
> >
> > Could some kind soul of the senior developers please shed some light
> on
> > the reasons for this design. Something obvious I have missed?
> >
> Um, you are probably the person with the most knowledge of the inner
> workings of Turbine that is active on this list.
> > If there is consent, I'd propose to clean this up a bit and to let
> the
> > factories do all the work. Would that sound insane to anyone?
> >
> Consistency is good. I trust your judgement.
>
> I suggest that any further work we do be limited to the trunk and
> fulcrum (though I will commit my JSON patch to the 2.3 branch).
>
> Scott
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Loaders, AssemblerFactories etc.
Posted by Thomas Vandahl <tv...@apache.org>.
Thomas Vandahl wrote:
> Second step of reorganization:
> - Loaders are still there
> - AssemblerFactory extends Loader now, I'm planning to merge the two at
> least for the existing implementations
> - The AssemblerFactories got a getLoader() method which allows to
> retrieve Loaders and cache sizes only by specifying the module NAME.
> - The AssemblerBrokerService now has a method getLoader(type).
> - In the TemplateService this allows to query the AssemblerBrokerService
> for configured module types.
Next step:
- Loaders can be queried by name and are cached by the
AssemblerBrokerService.
- Where possible, static calls to XXLoader.getInstance() have been
replaced by calls of the AssemblerBrokerService.
- The pipeline initialization has been shifted in Turbine.java because
the valves need services now and the service initialization happened
after the pipeline. I could not find any implications with this but I
may have missed something.
- Would it be useful to initialize a valve automatically when adding it
to the pipeline via addValve()?
> - The TemplateService needs a lot of adjustments to overcome the
> hard-coded seven module types -> next step.
This still remains.
Please review (and comment!)
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Loaders, AssemblerFactories etc.
Posted by Thomas Vandahl <tv...@apache.org>.
Thomas Vandahl wrote:
> Now, first step. Currently, all the loaders have their own caching. I
> propose to shift the cache into the AssemblerBrokerService. That would
> mean a common cache for all types of modules, where the key would
> consist of the module type, a colon and the name of the module like in
> "action:LoginUser". All exception handling would be concentrated at one
> place and the loaders could go in the next step.
Done.
Second step of reorganization:
- Loaders are still there
- AssemblerFactory extends Loader now, I'm planning to merge the two at
least for the existing implementations
- The AssemblerFactories got a getLoader() method which allows to
retrieve Loaders and cache sizes only by specifying the module NAME.
- The AssemblerBrokerService now has a method getLoader(type).
- In the TemplateService this allows to query the AssemblerBrokerService
for configured module types.
- The TemplateService needs a lot of adjustments to overcome the
hard-coded seven module types -> next step.
Please review.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Loaders, AssemblerFactories etc.
Posted by Thomas Vandahl <tv...@apache.org>.
Scott Eade wrote:
>> Could some kind soul of the senior developers please shed some light on
>> the reasons for this design. Something obvious I have missed?
>>
> Um, you are probably the person with the most knowledge of the inner
> workings of Turbine that is active on this list.
Thank you for your confidence. If you agree I'll just use this thread to
document my ideas and I hope I can be followed :-) Just veto as you see
fit. I'll try to proceed carefully. I'd appreciate any comments.
Now, first step. Currently, all the loaders have their own caching. I
propose to shift the cache into the AssemblerBrokerService. That would
mean a common cache for all types of modules, where the key would
consist of the module type, a colon and the name of the module like in
"action:LoginUser". All exception handling would be concentrated at one
place and the loaders could go in the next step.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
AW: Loaders, AssemblerFactories etc.
Posted by Jürgen Hoffmann <ho...@ellumination.de>.
Hi Scott,
your JSON Patch should still be inside the branch. Could you please double
check?
> -----Ursprüngliche Nachricht-----
> Von: Scott Eade [mailto:seade@backstagetech.com.au]
> Gesendet: Dienstag, 9. Dezember 2008 06:00
> An: Turbine Developers List
> Betreff: Re: Loaders, AssemblerFactories etc.
>
> Thomas Vandahl wrote:
> > Hi folks,
> >
> > I'm currently trying to understand the structure of the Turbine
> modules.
> > As far as I understand, the way is as follows:
> >
> > - The loader checks for the module in its cache (if so configured)
> > - If not found, the AssemblerBrokerService is consulted for an
> instance
> > of the module
> > - This in turn requests a factory to generate the instance.
> >
> > In the middle of this process the TemplateService and a couple of
> > mappers are involved. Some of them provide their own caching in
> addition
> > to the loaders.
> >
> > Could some kind soul of the senior developers please shed some light
> on
> > the reasons for this design. Something obvious I have missed?
> >
> Um, you are probably the person with the most knowledge of the inner
> workings of Turbine that is active on this list.
> > If there is consent, I'd propose to clean this up a bit and to let
> the
> > factories do all the work. Would that sound insane to anyone?
> >
> Consistency is good. I trust your judgement.
>
> I suggest that any further work we do be limited to the trunk and
> fulcrum (though I will commit my JSON patch to the 2.3 branch).
>
> Scott
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Loaders, AssemblerFactories etc.
Posted by Scott Eade <se...@backstagetech.com.au>.
Thomas Vandahl wrote:
> Hi folks,
>
> I'm currently trying to understand the structure of the Turbine modules.
> As far as I understand, the way is as follows:
>
> - The loader checks for the module in its cache (if so configured)
> - If not found, the AssemblerBrokerService is consulted for an instance
> of the module
> - This in turn requests a factory to generate the instance.
>
> In the middle of this process the TemplateService and a couple of
> mappers are involved. Some of them provide their own caching in addition
> to the loaders.
>
> Could some kind soul of the senior developers please shed some light on
> the reasons for this design. Something obvious I have missed?
>
Um, you are probably the person with the most knowledge of the inner
workings of Turbine that is active on this list.
> If there is consent, I'd propose to clean this up a bit and to let the
> factories do all the work. Would that sound insane to anyone?
>
Consistency is good. I trust your judgement.
I suggest that any further work we do be limited to the trunk and
fulcrum (though I will commit my JSON patch to the 2.3 branch).
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org