Strategy for refreshing changes in a sub-context?

[jones]

Hello,
I apologize if this is something basic that's in the doc or forum, but I've there just seem to be so many options and my small attempts at each have ended in failure.
Basically what I have is a large, 'complicated' Spring web application context that works wonderfully. I now have a requirement where I want to configure beans with SQL & HQL queries. These beans can be considered separate from my main Spring app context in that they have little or no dependencies on those other beans.
The problem I have is that, during development, I'm constantly changing these queries as I try different things, troubleshoot, etc. Right now, I have to restart the whole web app for any changes in a query to be used.

I've tried various methods of putting these query beans in their own context so that I could just refresh() that one context each time I made a change. I just can't seem to get it to work. It'll either refresh all my other contexts as well, or refresh nothing at all, etc. etc.

Without going through everything I've tried, I'm wondering if someone could just point me toward the right general strategy so I can focus on making one work.

In short, I currently have a single web application context. Everything is in there and working good. I'd like to pull out my query beans into their own context so that I can refresh my changes to that at will without affecting/refreshing the rest of the app. This one does not need to be a web context.

Could someone please point me in the right direction?
Thanks!

[Dave Syer]

The issue is probably that you have two conflicting requirements - the reloadable context must be isolated, but then nothing is aware of its beans. So maybe it looks a bit like this?

              main service context
                     /      \ 
  (reloadable child)    (servlet instance)

The reloadable child is nicely isolated, so you can reload him without any side effects. But no-one (important) knows about the beans in that context, e.g. the servlet instances cannot see them.

Why do you need your queries to be Spring beans? If they are just String literals you can reload them dynamically with a ReloadableResourceBundle. If they really need to be Spring beans you could try a scripted bean in groovy or jruby (see the <lang> namespace and dynamic language support).

[jones]

Hi David,
Thanks a bunch for you reply. Sorry if I don't speak Spring very well so sometimes I have a hard time illustrating what I'm trying to do. Looking at your diagram there, I'm not sure that's really what I'm after. I say that because, I believe I can make that reloadable-child context so that its bean factory is not dependent/aware of any beans in the main-service-context. In other words, as far as I'm concerned, this is almost two entirely different apps, with the exception that, some beans creates by the query-context do, internally (in code, rather than in bean factory), use beans managed by the main-context.

I tried something like this (at least tried to), but it wasn't loading my changes when I called refresh().

              main-service-context    context-with-queries
                          |
               (servlet instance)

You were also wondering if I really need these to be Spring managed. Yeah, they are actually quite a bit more than just straight query text. There is a lot of other wiring and bean creation going on in there. So, while just being able to refresh the the query expressions themselves would be a huge improvement over what I have now, ideally, I would be able to refresh that whole context when I add new beans, etc.

Anyway, you gave me some good ideas with the reloadable resource bundle and dynamic language as a last resort. The problem I have the the resource file is that my queries would be very hard to read if they were limited to single-line property entries. So, I read up on dynamic language support and that looks like a good possibility for being able to reload just the query part.