From: "Joerg Pietschmann" <[EMAIL PROTECTED]> > 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.
Avalon can really help you here. If FOP is completely Avalonized, you can plug in you own implementations of logging or configuration Management without changing the core FOP code. Avalon gives you these services using interfaces; this way any implementation can be used. > > 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)? It automatically gets the possibility of using all Avalon services. Instead of explaining all possibilities, let me show you an example of the Avalon way. Let's say that you write your class: public class MyClass { public MyClass{} } Now you want it to get created and managed by Avalon. So you define it in a config file (or programmatically)and change it to: public class MyClass implements Component{ public MyClass{} } This way, when Avalon starts, it creates you class. Now you want it to get some configuration. public class MyClass implements Component, Configurable{ public MyClass{} public void configure(Configuration conf) { //use conf here } } The Configuration it gets is gotten from *any* class that uses that interface; Avalon will supply it to you. Now you know that your configuration can change, so you write: public class MyClass implements Component, Configurable, Reconfigurable{ public MyClass{} public void configure(Configuration conf) { //use conf here } public void reconfigure(Configuration conf) { //use conf here } } now you want to add some init code: public class MyClass implements Component, Configurable, Reconfigurable, Initializable{ public MyClass{} public void configure(Configuration conf) { //use conf here } public void reconfigure(Configuration conf) { //use conf here } public void initialize() { //initialization code } } now you want to add some lifecycle code: public class MyClass implements Component, Configurable, Reconfigurable, Initializable, Startable{ public MyClass{} public void configure(Configuration conf) { //use conf here } public void reconfigure(Configuration conf) { //use conf here } public void initialize() { //initialization code } public void start() { //start code } public void stop() { //stop code } } now you want to logging: public class MyClass implements Component, Configurable, Reconfigurable, Initializable, Startable, Loggable{ public MyClass{} public void configure(Configuration conf) { //use conf here } public void reconfigure(Configuration conf) { //use conf here } public void initialize() { //initialization code } public void start() { //start code } public void stop() { //stop code } public void getLogger(Logger logger) { //get logger here } } And so on. Avalon is the glue that ties all together. If you implement Composable, you get a ComponentManager that gives you other Avalon components managed in the same way. There are Avalon components for URI resolving, caching, storage, xslt, etc. All these components are accessed by an interface, so you can out any concrete impl behind. In fact, Composable has: public Component lookup(String role); Whatever you get must be cast to an interface. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]