Hello Berin!
I see lots of "Ok" from you and this definetely rises my spirits!
:-)
BL> I am rapidly reaching the point of Fortress being "Good Enough" for
BL> release. Unless you find any *bugs*, I suggest we hold off on the
BL> refactoring until after the release.
Here's what I think will be needed before release:
1) Patch #10 (a rewritten analog) is _definetely_ needed.
1.1) I see it like this: we always create a copy of
LifecycleExtensionManager in every container and add the
InstrumentableCreator to the copy (not to infect our parent
container).
1.2) And yes, I beleive we do need getChildContext() from that
patch badly too -- it is a means of allowing
containers to modify the context before handing it to
their children.
I will be able to send #10.1 tomorrow.
2)
Oh, one more thing we may want before release:
I've sent a mail to the list about teaching
ContextManager to alternatively create a Log4JLoggerManager
by duducting the type of the logger manager from the
logger manager configuration file.
I was asking in that mail how is it best to it.
2.1) One variant was to check the name of the root node in .xlog
and if it is log4j:configuration go for Log4JConfLoggerManager.
2.2) There was also an issue of automatically propagating
worker directory to Log4J configuration DOM tree if
there isn't one already.
I beleive that anyone including me might easily implement
2.1 (but I won't be able to test it :-(
I think this will significantly add value to Fortress.
As I have said I will be able to send 1.1, 1.2 and 2.1
tomorrow.
As for 2.2 I need at least an advice. (Or this may wait
until 1.0.1)
- Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
