Niclas,
I hope you have managed to get Magic working by now. :o)
Shouldn't be that hard.
Nope. I think you folks might have been thru the /magic/ puns.
The main issue here revolves around the suggested changes, and I want to kick
off a discussion of whether this is 'desirable'.
Gang,
Paul's changes can probably best be summarized as;
1. Moving any 'functional' code into POJOs, and have an Avalon wrapper to
maintain Avalon compatibility.
Err, introducing abstract parent classes to do the guts of the
component's work. Keeping the existing block class to adapt to Avalon
(this in itself keeps backwards compatability). Then introducing a
new/alternative CDI based entry point for the same abstract 'guts' class.
2. Introduction of the "No Logging Strategy" with a connection monitor, and
monitor adapters for Avalon and Commons-logging.
Again, the existing Avalon comp functions identically (hiding the
monitor). The CDI entry point diectly names the impl of the monitor to use.
We need to discuss if these are changes that are in line with the Avalon
direction and a way that should be supported, maintained and encouraged.
Personally, I have no strong opinion at this point in time, and would like the
folks to speak up. Preferably also the Excalibur camp...
You are quite correct. If we roll this foward some months in time, we
are likely to effect some of the same changes in Exclaibur. For now
though, this excercise targets only the parts of Cornerstone that
FtpServer and James use.
- Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
