Peter Donald wrote:

>On Sun, 12 May 2002 09:51, Stephen McConnell wrote:
>
>>>* lifecycle "style": Is it poolable, is it re-entrant, is it threadsafe,
>>>is singlethreaded etc
>>>
>>Just a note that I think that we will sooner or later have to deal with
>>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

>  
>
>>>I 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.
>>>
>>Before answering the above, I'll go into a more detail concerning Merlin
>>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]>

Reply via email to