On 7/29/05, Greg Reddin <[EMAIL PROTECTED]> wrote: > 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. >
I like the idea of having an interface that a DefinitionFactory could implement to say it knows how to do the reload thing (coupled with some of the refactoring you discuss below). However, I would recommend *not* limiting reload support to a file based environment. As long as the definitions factory deals with URLs to the configuration resources (haven't looked if that is actually true for Tiles, but it ought to be), then you can use URL.openConnection() method to open a URLConnection to it ... then call getLastModified() there to determine the date/time that this resource was last modified. > 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. > That seems like a reasonable refactoring. It would also mean you could invoke the configuration reading process without disrupting the currently running application, and then replace the existing definitions factory instance when you're ready to. > 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? > Are you talking about "sandbox/tiles" (the Standalone Tiles implementation)? If so, I mentioned in a previous message that the test classes with Struts dependencies were mistakenly copied, and should be eliminated. It probably makes sense for us to coalesce on a mock objects library for this purpose (Shale has one too, that defines the basic servlet stuff + JSF stuff that wouldn't be needed for testing Tiles). Craig > Thanks, > Greg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
