this now works with the convention plugin(it didn't before) musachy
On Mon, Jul 13, 2009 at 10:47 AM, Musachy Barroso<musa...@gmail.com> wrote: > I added "struts.class.reloading.acceptClasses", so now I can make the > reloading class loader handle only action classes, so I don't get > ClassCastException(s) > > I also added support for the relative paths, @Dale, take it for a spin > and let me know how it works. > > musachy > > On Mon, Jul 13, 2009 at 9:29 AM, Musachy Barroso<musa...@gmail.com> wrote: >> I am thinking about adding another constant which holds a list of >> regex, which if set, will limit what classes can be loaded by the >> reloading classloader. The reason for this, is that I would like to >> limit the reloaded classes to just my actions. If the reloading class >> loader loads something that is not an action, there is a good chance >> that instance of that class will be casted to the same class loaded by >> the original class loader, which fails with a class cast exception. >> >> musachy >> >> On Mon, Jul 13, 2009 at 7:10 AM, Dale Newfield<d...@newfield.org> wrote: >>> Musachy Barroso wrote: >>>> >>>> I could test the path as an absolute path, if it exist, use it, >>>> otherwise try it as a relative path to context root, sounds good? >>> >>> Almost. The File interface can tell you whether or not a given instance >>> (path) isAbsolute(). Clearly if the (absolute or relative) file does not >>> exist it should not be loaded, but existence shouldn't help you decide which >>> way to interpret the path. >>> >>> This does bring up the question: If the given (.class or .jar) file does >>> not exist at deployment time, will creation of it/changes to it later >>> trigger reloading? Either way, just to avoid confusion that bit of info >>> should be added to the documentation. (Hrm--looking at >>> FilesystemAlterationListener and ClassReloadingXMLWebApplicationContext >>> suggests that if the file exists at deployment time we should notice in >>> onFileChange as you currently do, but if it did not exist (and we want to >>> support later adding of classes/jars) we could be paying attention to >>> onFileCreate/onDirectoryCreate events, too.) >>> >>> Oh, and once again: Musachy++ >>> >>> Lately it seems like Struts is improving more due to the heroic effort of a >>> few individuals than as a result of a community effort. (I have a feeling >>> that this has fairly consistently been the case throughout the lifetime of >>> struts v1 and v2.) I'm happy that struts is improving, so I'm not trying to >>> discourage heroic effort, but I'm wondering if anyone has any suggestions >>> for how to get more involvement? >>> >>> -Dale >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >> >> >> >> -- >> "Hey you! Would you help me to carry the stone?" Pink Floyd >> > > > > -- > "Hey you! Would you help me to carry the stone?" Pink Floyd > -- "Hey you! Would you help me to carry the stone?" Pink Floyd --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
