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)?


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to