This could easly be addressed by introducing a new symbol for the path
to the application message catalog, which would allow an application
override. Please add an issue to JIRA.
On Tue, Jun 10, 2008 at 1:44 AM, Neeme Praks <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Tapestry5 is shaping up quite nicely, great work!
> As a result, I have chosen Tapestry 5 as the framework to build a new
> project on :-)
>
> Inevitably, there will be questions and here is mine:
> Is there some way to override application-wide message catalog location?
> The default is WEB-INF/<appname>.properties
>
> Why would I want to do that? Well, historically we have used Spring Web-MVC
> for our applications and there we stored the application message catalog in
> WEB-INF/messages/messages.properties and I would like to keep that location
> unchanged. Easier for our translators.
>
> As far as I can see in the source code, this location is pretty much
> hardcoded? org.apache.tapestry.services.TapestryModule has:
>
> public ComponentMessagesSource buildComponentMessagesSource(
> @ContextProvider
> AssetFactory contextAssetFactory,
>
> @Inject
> @Value("WEB-INF/${tapestry.app-name}.properties")
> String appCatalog)
> {
> ComponentMessagesSourceImpl service = new
> ComponentMessagesSourceImpl(contextAssetFactory
> .getRootResource(), appCatalog);
>
> updateListenerHub.addUpdateListener(service);
>
> return service;
> }
>
> As this location is hardcoded, I guess I have two options:
> * patch Tapestry to make it configurable
> * override the definition of ComponentMessagesSource with my own
> implementation (or just my own configuration)
>
> I guess the first option is a long-term solution and second is a short-term
> solution?
>
> I'm willing to investigate the possibility for patching Tapestry (any
> pointers are very welcome), but at the same time, I would also like to
> implement the short-term solution to solve the issue at hand.
>
> While investigating the possibility to override, I came across the
> following.
> On page http://tapestry.apache.org/tapestry5/tapestry-ioc/module.html
> it is written that:
> "Service ids must be unique; if another module contributes a service with
> the id "Indexer" (or any case variation thereof) a runtime exception will
> occur when the Registry is created."
>
> Does this mean that I cannot override the default ComponentMessagesSource
> service implementation?
>
> I hope I misunderstood something :-)
>
> And, while I'm already consuming airtime here: how can I override the
> default tapestry configuration mechanism with my own? So instead of taking
> parameters from web.xml, I can implement my own way of loading them (e.g.
> from properties file, from DB, etc).
>
> Rgds,
> Neeme
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
