At 08:33 AM 6/24/2002 +0200, you wrote:
>FOP, for example, is used in Cocoon and it's very likely that we're
>going to adopt Avalon patterns in the redesign phase we're currently in.
>In fact, we already use the logger abstraction and more is to come.
good to hear!
>Let's say Cocoon chooses one version of Avalon, will we be stuck with it
>if we want to stay compatible with them or will there be a need to write
>an adapter in between?
Well there will be an adapter/compatability layer between A4 and A5 (if it
ever exists) so you will never need to wite that bit of code. You may need
to invoke it though.
>Will we be forced to move to a new version if
>Cocoon moves on? Could very well be. What about having different
>versions of avalon-framework.jar in one VM?
They will be in different packages so it will be possible to have both A4
and A5 in same JVM with zero hassles.
>Of course, Framework is very stable, but even then, discussions about A5
>make me somewhat unsure.
Don't worry - this sort of discussion pops up every 3 months or so but it
is rare that anything drastic changes. Sometimes we just add more javadocs
to our code or on some occasions we add another parrallel set of
interfaces. ie LogEnabled grew as we didn't want to tightly bind to LogKit,
ServiceManager grew because we don't like Component marker interface etc.
There has only ever been one backwards incompatible change and that was
change in serialized format of DefaultConfiguration object. However this
should not have broken anything because DefaultConfiguration could not be
serialized anyway (due to a bug on our part).
I
>think it's all about reusability as you gathered yourselves. FOP is a
>reusable component and will (after the redesign) probably have two APIs,
>one simple one with little to no direct dependency to Avalon, the other
>low-level API will probably be Avalon-based.
Thast the way I would do it aswell.
>But if Avalon is used we're
>using one version. What if a user of FOP someone wants/needs to use a
>different version of Avalon?
If A5 eventuates it will be possible via a compatability layer so in theory
all should be good. However to ensure this is the case I would encourage
you to;
* Use ServiceManager interface rather than ComponentManager (And don't use
Component marker interface)
* Use LogEnabled rather than Loggable to aquire Loggers
* Don't use ServiceManager.release()
If you do the above then everything should be forward compatible. One thing
you may want to also do if you can is avoid the marker interfaces like
ThreadSafe etc.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
