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.j...@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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
