Well, this reloadable config thing is bigger than I thought. Here's
the approach I've been playing with today: I'd appreciate some
feedback on possible approaches. I can certainly send code if I need
to.
I wrote a TilesFilter that does what TilesServlet currently does. That
seems to be working ok, but I agree with Craig that it might be better
as a listener. The filter should store the last modified dates of the
config files. When a request comes through it will compare the stored
dates to the actual dates of the files. If the files have changed
reload the whole DefinitionsFactory.
But, getting a list of config files is a somewhat non-trivial task.
The only place the list is stored is in I18nFactorySet and this is not
a complete list. I18nFactorySet stores a list of base names found in
web.xml. Then it does the business of figuring out what files actually
exist by appending locale information. And if I'm reading it right it
only does this for the locale of the current request. I'm not sure if
that could cause problems or not. But here's the options as I see
them.
1) Publish a new interface FileBasedDefinitionFactory that
I18nFactorySet implements. It would have a getFilenames() method that
would determine what the config file names are and return them. The
Filter would see if the DefinitionsFactory implements this interface
and, if so, do the work to determine if the definitions need to be
reloaded. Or, include an isStale() method on the interface and do all
that work internally.
2) This is the same as 1) but without the extra interface. Add an
accessor to the filenames List on I18nFactorySet. In the Filter, check
to see if the DefinitionsFactory is an I18nFactorySet. If so get the
list and check to see if any of the files have changed. If so reload
the config. I don't know if I like this approach because it pushes too
far down into I18nFactorySet.
3) In the Filter repeat the logic that determines what the filenames
are and check to see if any have changed. This is pretty hokey to me
simply because it's repeating logic, but it does keep everything away
from the existing DefinitionsFactory structure.
That leads me to my next thought. I wonder if the DefinitionsFactory
methodology could use some refactoring. My only real gripe about the
way it's currently structured is that there are some side-effects. To
create a definitions factory you have to pass in ServletContext and
request. Tiles will create and populate the factory *and* place it in
application scope. To me it might be cleaner if Tiles just created the
factory and let the caller place it in context or do whatever else
needs to be done. Plus, you have several different concerns taking
place in I18nFactorySet. It resolves files, does I18N, and parses XML.
IMO, it would be cleaner to separate out the primary interface, the
file navigation and I18N, and the XML parts. It seems like
DefinitionsFactory could just be an object graph and some other
component should be responsible for populating it with data.
Lastly is unit testing. I'm trying to write some unit tests for Tiles.
The project has a dependency on Struts 1.3. Is it acceptable to use
the mock objects from Struts in Tiles unit tests or should we write
separate ones? Does anyone have any idea how to test the
synchronization aspects of this piece?
Thanks,
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
