Jason van Zyl <[EMAIL PROTECTED]> writes: > The tool was originally made a simple case tool, primarily to unify > configuration patterns and simple object mapping. Scarab and SourceCast are > using XML to serialize an object model?
SourceCast integration of Scarab replaces some of the core Valves, but needs the option of reusing them as well. What it boils down to is that classes from different packages need to be able to be mixed and matched. We have that now. > I object to having the simple behaviour removed. I am fully cognizant that > it is simple, I like that it's simple. More complicated behaviour can be > added but I'm trying to replicate the digester. If you need some serious > convoluted mapping than the digester should be used. I think a few simple > patterns will work though with the addition of the className search I think > configuration files will be much easier to deal with. I like simple too; simple behavior is back to stay. >>> I will put the behaviour back as I've already made changes to make the class >>> work with InputStreams so it can deal with resources in the filesystem and >>> the classpath. >> >> You regressed the classpath loading I'd already added. > > As I mentioned in the meeting we had the other day I want to use the > resources package to handle this. The application has to deal with how it > wants to search for resources and once the application determines where its > resources are the mapper can be used. That's fine, but it wasn't available when I did the work. I like the simplicity of the API which lets you specify a path and the the Mapper just works, resolving the path irregardless of whehter it's on the file system or in the classpath. I figured we'd usage the resources package internally (inside the Mapper) to achieve this. > The classpath loading works, but it doesn't work well when both file systems > and classpaths are used. Actually, it works fine. I tested both cases extensively. The order of loading is clearly documented -- I think that's where confusion could arise. Using a standard reasources package (internally or externally) ought to help address this issue. > I think the better approach is letting the application determine > where its resources are and give the mapper an inputstream. I think > having the logic in the mapper is wrong as when we add new places to > store the configuration the logic will have to be added to this > class. I would like all the I/O strategies to be localized in the > resources package. > > I realize the file approach on it's own is deficient. I probably should have > started with an inputstream and only used an inputstream but I made the > mistake of only using files. I poked in the resources package and will get > Turbine working from a WAR file and the filesystem today. InputStream only would be okay (definitely don't get rid of the String overload and leave the File overload), but you'll have to change some references in Turbine to keep things working (they were not changed when the classpath loading was removed). -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
