Mario Ivankovits wrote:
If this might make a serious problem in your environment, please let me know.
Received three misgivings - how bad :-(
Tim Reilly wrote:
No - digester is much more than just an xml-parser. It automates the process of reading the xml and build the necessary java object(s). xml attributes/element data is set on those using reflection.My personal thought on this is that 200+K is a lot. Is something like osjava's gj-xml sufficient?
Any change to the configuration file could easily be mapped to the according java object.
Paul Smith wrote:
For sure it might not be much work to modify the current parsing, but with every new option the code gets larger and larger, and every line of code is simple copy&past - with some minor modification so that it cant be reused.it does seem like a large dependancy just to parse a single configuration file. Is it much work to modify the current parsing class to include the new element support?
My experience is to leave such a way of how the code goes as early as possible, as it is much more work if this is done if it is too late.
Anthony Goubard wrote:
Note that it would increase the size of vfs from about 200K to 400K.
Those 200K you only have if you do not use any of the ftp,http,... libraries.
Is there a way to keep the old manual xml parsing even is not attached to the code in case someone doesn't want ot use <globals> , he would then need to change a bit of code and recompiles vfs.
Gotcha! This brings me back to the idea to how vfs works - try to see if a class is available and configure the system accordingly.
What do you think about making these dependencies optional.
If digester&beanutils are available, vfs will use them and you could use the new <globals> sections, else you are stick to the old parsing with their limitations (which might get more and more in the future).
In the case of "globals" it could be possible to set them from within the application as long as init() on the FilesystemManager wasnt called. If one use VFS.getInstance() then this might not be possible, but it is not much work to instanciate the StandardFilesystemManager directly instead.
To create really small distributions i recommend to have a look at a jar-builder which is able to find and jar only needet classes.
-- Mario
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
