Jeremias Maerki <[EMAIL PROTECTED]> wrote: > Ok, I think that can be done, even when using Avalon in FOP. You propose > (I think) that we could provide an Avalon-Wrapper around FOP,
Thanks for the help. Some comments on the concerns: I'm forced to use JDK 1.3 with JAXP1.1 and proprietary extensions for logging and configuration management (and other stuff i'll ignore now). I have to use the proprietary API to retrieve configurable options and want to feed them to a FOP instance. It's not easy for me to deploy a config file, nor do i want to. My purposes would be served best if there were a processor class which took all configuration options as a Properties bundle or through some generic interface like Transformer does. An avalon component class encapsulating the simple processor class (or derived, for possible performance gains) could use this interface to pass options read from a config file, command line options or whatever. > but it > could also be the other way around. I'm sure that Avalon will not stand > in the way if we provide a simple interface similar to what you proposed. Well, adding is easier than subtracting. Apart from the interface, i don't want to have FOP looking around for files (URIs are ok, if i could supply code to resolve them). Can somebody explain to me what could be gained if the processor was an avalon component by default (other than easy integration into the avalon framework, of course)? Regards J.Pietschmann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
