Distributed configuration of Spring Application context in a non-web Tapestry-ioc project

[Jonathan Barker]

Hi all,

We have created a stripped-down "tapestry-spring" project to allow us
to use Spring from within a Tapestry-ioc based non-web project. One
objective is to be able to drop in jars and not only have services and
configuration information from Tapestry modules picked up, but also
contribute locations of applicationContext files and have them
combined as well. This is comparable to specifying multiple files in
web.xml for a normal Tapestry-Spring web application.

We've hit analysis-paralyisis trying to figure out how to get the list
of Strings (ApplicationContext.xml fragment locations) available at
the right time. The comparable location for tapestry-spring seems to
be in SpringModuleDef in the method:

private ObjectCreator constructObjectCreatorForApplicationContext(
final ServiceBuilderResources resources, @Primary
ApplicationContextCustomizer customizer)

at the line:

WebApplicationContext context =
loader.initWebApplicationContext(servletContext);

By the time we hit this line, we need to have the contributions
available. Can a configuration built up from distributed contribute
methods be accessed/used at this point? How?


I've never quite been able to get away from Spring, because I
frequently have to deal with multiple databases, and I like their
transaction management. In the past few years, we've been using
Apache Camel extensively in web applications and non-web integration
projects. That's also been easier to achieve in Spring, but the
number of Camel processes I have running is going to get more
difficult to manage. We've built a tapestry-ioc integration for Camel
so we can do distributed contribution of routes, but we're bumping up
against this one issue.

Regards,
Jonathan

[Lance Java]

Considering this is a non-web project, I assume that WebApplicationContext
is not on the classpath. It seems that SpringModuleDef is not suitable for
you since it references ServletContext which I also assume is not on your
classpath.

[Lance Java]

It seems to me that SpringModuleDef needs to be refactored to support
non-web projects, possibly by the use of an ApplicationContextProvider or
similar service.

Post by Lance Java
Considering this is a non-web project, I assume that

WebApplicationContext is not on the classpath. It seems that
SpringModuleDef is not suitable for you since it references ServletContext
which I also assume is not on your classpath.

[Jonathan Barker]

At the moment, there is a dummy servlet context being provided. I
suggested keeping the code as close as possible to the original until
we had things working.

That being said, we have created our own SpringModuleDef in
anticipation of additional changes.

I'm accustomed to doing distributed contributions for service
configurations, but I don't see how to get at a configuration from
within the constructObjectCreatorForApplicationContext method.

Post by Lance Java
Considering this is a non-web project, I assume that WebApplicationContext
is not on the classpath. It seems that SpringModuleDef is not suitable for
you since it references ServletContext which I also assume is not on your
classpath.

[Lance Java]

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]

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 :-)

Post by Lance Java
The easiest way I can think of is to have an ApplicationContextProvider
service which is defined by your tapestry module.
@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.