Hi again J�rg, Your solution is nice but i can see some design trade-offs : - First you expose the ServletConfig object to your component developper on top of the Context interface (and require a *i-dont-know-where-to-put-it* key constant...) - How can you know the pParent context is a DefaultContext without looking to the source ?? - How do you manage the possibility for the FortressConfig class interface to evolve ?
With my solution you just don't make any such assumptions other than: - FortressConfig have a constructor that takes a Context so my wrapper for Fortress can use it - I can make a ContextWrapper that implements the Context interface so that i do not have any impact on the Fortress point of view - I don't expose the ServletConfig to the component developper but remain at the framework level > BTW: If any of the committers approve this as "good solution" I may add > this to the wiki. I understand, that such a beast is normally not > necessary, since anything could normally be initialized using a normal > configuration. However, in triggered environments like a webapp or a > plug-in, such "additional" context information may be necessary. Not commiter but do not approve!!! :) Cheers, A+. Didier. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
