Peter Donald wrote:
On Sun, 12 May 2002 09:51, Stephen McConnell wrote:
Just a note that I think that we will sooner or later have to deal with* lifecycle "style": Is it poolable, is it re-entrant, is it threadsafe, is singlethreaded etc
the pooled concept at the framework - by the addition of a specific
interface for a Pool,
Thats how it used to be back a while ago. We used to have Poolable and Pool interface inside the framework proper. Thankfully that got moved out.
or, elimination of pooling notions at the level of ServiceManager and ComponentManager.
+1
Thats my preference as well. (But we know that this is am emotive topic!).
* context: - Context Class - Entrys in Context (both name of entry and type of entry)
I'm assuming you mean something along the lines of excalibur.context.ContextUtility (which I'm using within Merlin). It handles the above but the javadoc really needs some work.
Very similar. However it needs to be more like J2EE <resource-ref/> in that we can map arbitrary types into context. In particular I would like to be able to map objects of type MBeanServer into context.
I also plan to use the converter architecture (in excalibur now, previously of myrmidon) to help with populating the context. Basically converter architecture tries to convert from one type to another type.
Can you give me some liks/references etc. to <resource-ref/> and the converter stuff
Before answering the above, I'll go into a more detail concerning MerlinI was going to try address it in a global manner first but if you want me to make it possible for you to overide default behaviour with CascadingConfigurerr then it should be relatively easy. Just say the word.
configuration semantics.
...snip...
There you go again ... snipping the best bits of my emails! :-)
sounds interesting - I will have a further look. I am not sure thats the right way to go with all phoenix but it should be possible to enable by just writing a new Deployer. Wait till next weekend (after I put through all changes I proposed) and hopefully it will be much easier to enable this sort of thing.
No problem.
Currently it is a PITA because we are supporting a bunch of deprecated deployment formats (and thus need similar code in multiple places). After this is all cleaned up it should be much easier to do.
For completeness, there are two other .xinfo additions that should be
noted. Firstly, there is the introduction of the name attribute on the
block element.
+1
Secondly, Merlin supports a <context> declarations within a .xinfo which is handled by the ContextUtility class.
+1 to idea but I want to play with concept a bit more because I need other things to be placed in context that wont be supported by current ContextUtil.
Agreed.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
