Hi Didier, > 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...)
?? It is the same scheme Fortress is using itself. It creates ContextManagementConstants as extension to ContainerManagementConstants. So, where is the difference? Now every developer can request an element from the context vital for the run-time of the component. Well, in the end I might not expose ServletConfig to the developer, but several special values from this context. But it helps me now running existing code :) BTW: What is the normal element used as key for the context? Such constants are used in Avalon code. > - How can you know the pParent context is a DefaultContext > without looking to > the source ?? Who has to know this? Anyone is just referencing Context! MyServletConfig is used in the same way as FortressConfig ... once to initialize the app. > - How do you manage the possibility for the FortressConfig > class interface to > evolve ? Well, this is the culprit <g> > 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 OK. There are advantages :) > > 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!!! :) Valid opinion <g> Regards, J�rg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
