[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tapestry-user
Subject:    Re: Distributed configuration of Spring Application context in a non-web Tapestry-ioc project
From:       Jonathan Barker <jonathan.theitguy () gmail ! com>
Date:       2014-10-22 2:55:19
Message-ID: CAOTv+9W1wB=JhixbD=YXYnC4-KtrVrL4rnFj02Bxt6o6Y8u2Qg () mail ! gmail ! com
[Download RAW message or body]

Thanks. We'll explore that path.

The intention is to get rid of the servlet api dependency.  The
approach has been: take something that works, and make as few changes
as possible to get something else that works, then go from there.

Ultimately, we want tapestry-ioc-spring.  As a matter of fact, that's
what we are calling the project :-)


On Tue, Oct 21, 2014 at 9:37 PM, Lance Java <lance.java@googlemail.com> wrote:
> The easiest way I can think of is to have an ApplicationContextProvider
> service which is defined by your tapestry module.
>
> eg:
> @UsesOrderedConfiguration(String.class)
> public interface ApplicationContextProvider {
> ApplicationContext getApplicationContext();
> }
>
> Then, in your custom SpringModuleDef you'll call
> ServiceBuilderResources.getService(ApplicationContextProvider.class) to get
> an ApplicationContext instance.
>
> You could then have use distributed configuration to define the app context
> files for the OrderedConfiguration.
>
> As I said earlier, I think this highlights a bigger problem that you need
> the servlet api on your classpath for a non-web app. Perhaps
> tapestry-spring needs to be split into tapestry-ioc-spring and
> tapestry-spring.



-- 
Jonathan Barker
ITStrategic

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]