On Jul 29, 2005, at 6:16 PM, Craig McClanahan wrote:
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.
Ok, I'll dig into it this weekend and see if I can figure something out. Thanks for the tip on URLConnection as well. I was trying to figure out how to do that.
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.
Exactly.
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).
Yes, I deleted that test case in my directory and was working up some new ones to test the changes I was making. I'm trying to figure out if there's a good way to simulate changes to the config files in a unit test to verify the reloading functionality. I'd also like to test the synchronization work that will be needed.
Thanks, Greg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
