This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

From my currently limited understanding of Spring and Acegi, I can't see how this kind of runtime configuration change can be made easily.

The best solution I can see is having the application's main context XML use:

<import resource="configuration_choices/authtype-beans.xml"/>

...and then in the configuration_choices directory we have authtype-beans.xml which is over-written by the configuration UI when the user changes the options, and contains only:

<import resource="authentication/jdbc-auth-beans.xml"/>

...if for example the user had chosen JDBC authentication.

This allows us to pre-ship bean configs for different config scenarios, without having to copy files / write out XML except for a trivial template-based XML file (shown above) that just has a single filename change in it.

I understand that reloading is slated for 1.3 - is there any clean solution for it now?

Using Spring in a shared hosting environment - a requirement for getting, for something like a free java CMS to get any kind of mass usage - means that we can't restart the container when we want to reload. Also we can't guarantee that we can force a reload our app either.

Comment

This discussion is very interesting because I was about to ask nearly the same question. Actually I'm currently working on sort of a Spring-based CMS (why mythical ?) and my problem right now is to allow for hot-pluggable modules as it is possible in PHP CMS's.
The way I see it, a module is made up of :
- Spring service classes
- Hibernate entity classes
- SQL database initialization scripts
- Miscellaneous XML configuration files (namely for Spring and Hibernate)
- possibly other files like the ones for the presentation layer.
And my big issue is with the first two types of files : is it possible with Spring (and by extension with Hibernate) to dynamically load java classes ? that is to say I want to be able to load a Spring bean factory description file at runtime.

That with the security configuration issue I hadn't even thought of, and possibly other configuration issues makes me wonder about the dynamic capabilities of Java in general, and Spring in particular. Am I right to worry about that ?

Comment

There has been lots of discussion around this. My impression (and I for one think a good idea) is that the Spring folks have been trying to avoid making Spring a heavyweight container (e.g. doing its own classloading and full life cycle management stuff). Although in one of the threads, IIRC, Rod Johnson did indicate that if a lot of users should ask for it, they'd consider it in future releases.

Comment

Well I miss a bit of experience to undestand all the issues but... isn't there a conceptual intermediate between the current lightweight architecture and a heavyweight one like the one of EJB's for example ? Because I love the lightweight aspect in Spring too and I didn't realize that what I need right now would require such a huge change in direction.
Do you suggest that the kind of things I'm talking about are possible with heavy weight containers like JBoss for example ?

Comment

I might be a bit dense today(or always) and still steaming from a couple of lost poker hands. I thought your "hot-pluggable modules" sounded pretty much like -- EARs. For Spring to be able to handle things like that, it sure gonna need its own classloader(s).

Comment

So i take it that a) this has not been implemented in Spring and that b) no one has found a clean solution?

Well, i'm also in the market for something like this. I would like to be able to modify a property (which i can off a pojo) and then persist it to the application context xml configuration, at runtime. This way, if the container (servlet) needs to be restarted, the persisted changes are picked up again.

Anyhow, i'm interested in finding out if anyone has something clean, meanwhile, i'll be working on a solution myself (as i'm sure all of you will). I'll post my results or at least what i did when i'm happy with a solution.

Thanks,
mig

Comment

One of the solutions I have found for runtime configuration information is to use a proxy and a custom TargetSource. So for each invocation of whatever services need that runtime configurable information, it will always fetch the latest choice.

You would load the application with your custom TargetSource which would be configured with all of your choices. In fact your TargetSource could enumerate the names of them for display.

Comment

Thanks for the suggestion. I haven't really gone into the AOP side of spring, however, now sounds like a good time to catch up on it. From reading some of spring's javadocs, it appears that I might be able to leverage the "HotSwappableTargetSource" (dunno, just shooting in the dark right now).

But thank you, i'll post back what i find out and hopefully, someone (as well as i) will benefit from all this