avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Fedorenko <ifedore...@thinkdynamics.com>
Subject Re: JMX Integration
Date Sat, 21 Sep 2002 03:14:07 GMT
I am thinking about implementing this in a generic way, so 
(theoretically) block can access components deployed into Embeddor and 
(later) into any application deployed into phoenix. I think we already 
agreed that block developer will declare these external dependencies as 
any other dependency, however we did not talk about assebly.xml syntax 
that would support this. I see two slightly different solutions and need 
your help to choose one of them.

One option is to use block factory to define foreign blocks in 
assembly.xml and use these blocks as any other block. Emberddor would 
extend BlockFactory interface and phoenix would provide it as implicit 
"system-manager" factory (i.e. it does not need to be configured). For 
example,

<assembly>
<block name="system-manager" factoyr="phoenix-kernel"
   implementation="org.apache.avalon.phoenix.interfaces.SystemManager"/>
<block name="my-block" class="test.MyClass">
   <provide name="system-manager"
        role="org.apache.avalon.phoenix.interfaces.SystemManage"/>
</block>
</assembly>


Another option is to define new tag "foreign", "external" or something 
like that that could be used in place of "provide" tag. For example

<assembly>
<block name="my-block" class="test.MyClass">
   <foreign container="phoenix-kernel"
        role="org.apache.avalon.phoenix.interfaces.SystemManage"/>
</block>
</assembly>

In this case we will need to define new interface that will be 
implemented by all block containers and will provide access to blocks 
deployed into the containers.

So, what do you think?


Stephen McConnell wrote:
> 
> 
> Igor Fedorenko wrote:
> 
>>
>>
>> Nicola Ken Barozzi wrote:
>>
>>>
>>> Stephen McConnell wrote:
>>>
>>>>
>>>>
>>>> Peter Donald wrote:
>>>>
>>>>  >On Mon, 2 Sep 2002 02:45, Huw Roberts wrote:
>>>>  >
>>>>  >
>>>>  >>>>Rather than this I think I may prefer something simpler
- at least
>>>>  >>>>initially. Something like
>>>>  >>>>
>>>>  >>>>BlockContext.register( String topic, String name, Object
object )
>>>>  >>>>BlockContext.unregister( String topic, String name )
>>>>  >>>>
>>>>  >>>>Job jobOne = ... get the job somehow
>>>>  >>>>ctx.register( "jobs", jobOne.getName(), jobOne );
>>>>  >>>>...
>>>>  >>>>ctx.unregister( "jobs", jobOne.getName() );
>>>>  >>>>
>>>>  >>>>The reason for this is that then we don't have to expose

>>>> SystemManager
>>>>  >>>>to clients and thus we are free to evolve it as we see fit.

>>>> However it
>>>>  >>>>exposes all the information needed to manage object.
>>>>  >>>>Like?
>>>>  >>>>
>>>>  >>>>
>>>>  >>I have 3 issues:
>>>>  >>1) The ability to add more than one level of hierarchy beneath 
>>>> the blocks.
>>>>  >>2) Using an interface will make the client code cleaner and more

>>>> portable.
>>>>  >>3) Client code will be hooking into this, meaning we are 
>>>> committed to
>>>>  >>supporting it going forward.
>>>>  >>
>>>>  >>I can live with this for now, but i want to consider how it fits

>>>> into
>>>>  >>the longer term direction.  What I'd like to do, is add a
>>>>  >>ManagementContext interface to Framework, and then have 
>>>> SystemManager
>>>>  >>extend this.  That would be the first step towards making the
>>>>  >>functionality available in other containers.  Does that sound 
>>>> ok?  If
>>>>  >>so, how do we proceed in that direction?  If its not too big a deal
>>>>  >>maybe we could skip this intermediate step?
>>>>  >>
>>>>  >>
>>>>  >
>>>>  >I would still prefer to go with the
>>>>  >
>>>>  >BlockContext.register( String topic, String name, Object object )
>>>>  >BlockContext.unregister( String topic, String name )
>>>
>>>
>>>
>>>
>>> -1 a Context should never be used by a Container for its services.
>>> If it is used, it's basically giving a service to everyone without IoC.
>>>
>>>> >The reason is that we have discussed that feature in the past 
>>>> without  > really coming to any conclusion.
>>>>
>>>> Adding behaviour to an context implementation over and above the
>>>> framework defintion of context means that you are defining a
>>>> specilization of the Avalon Component Model for Phoenix.  Components
>>>> that include a dependency on that model are no longer portable.
>>>> Alternative solutions to introducing the functionality you are
>>>> describing is totally possible without introducing the complication
>>>> associated with BlockContext - i..e. use the context object to 
>>>> aquire an
>>>> abject implementing the interface the component needs, then apply
>>>> register/unregister against that interface, or, havbe the copmponent
>>>> declare a depedency on a registery service of some kind.
>>>
>>>
>>>
>>>
>>> I resist also this, since we are using services in a context, rather 
>>> than be given them by the Container.
>>>
>>> I have looked in the archives and seen that once upon a time, Context 
>>> was indeed used as a common service, and a common place to put services.
>>>
>>> I think that Context should never keep services where possible.
>>>
>>> For example, ServletContext is about instance data, not services.
>>>
>>>> This was discussed in respect to the shutdown request handler - this
>>>> requirement is no different.
>>>
>>>
>>
>> What if we provide instance of SystemManager via 
>> ServiceManager.lookup()? I would not bother getting block's management 
>> subcontext -- it does not map into anything in JMX anyways -- just put 
>> root system manager into appropriate ServiceManager instance.
>>
> 
> Sounds perfect - assuming that the component aquiring the SystemManager 
> declares this as a dependency.
> 
> Cheers, Steve.
> 

-- 
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.com


--
To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>


Mime
View raw message