So much talk and so few management API proposals...ok, lets give this a try
and see if we can get some quick discussion iterations and there's no
suggestions to ask the spec group what they think until there's a working
way to get at the names of the services in a module. I'll start this on
another thread.
...ant
On 5/31/06, Jim Marino < [EMAIL PROTECTED]> wrote:
I'd prefer we come up with a management API as that is the only
solution that will work properly. More comments inline
On May 31, 2006, at 1:25 AM, ant elder wrote:
> Coming up with a new management API sounds like it will take some
> time, I'd
> like to be able to get at the list of components today, and then
> change the
> code later when "The Spec Group" or whoever come up with an
> official API.
>
> Seems like there's three things that could be done:
>
> 1) Use the hack that casts to the internal AbstractCompositeContext
> and get
> the list from that
>
Besides being a horrible hack that we should not encourage users to
do, this is not going to work when we deploy to a managed environment
that enforces classloader visibility and security constraints
> 2) Put back the getMeteData method
>
Even if we did this, getMetaData will not accurately reflect the
state of the runtime
> 3) Add a new "getServiceNames" method to the
> org.osoa.sca.ModuleContextinterface which returns a list of the names
> that are valid for the
> locateService method, and implement getServiceNames in
> ModuleContextImpl.
>
I don't think we want to modify something in an official spec package
with additional proprietary extensions. Also, we should not put that
type of API on ModuleContext as it is not a typical thing application
code would do in the SCA programming model but should instead be
available through some other runtime API that is protected by
security mechanisms
> Any comments on your preferred approach or alternative suggestions?
>
My preferred approach is to design a management API incrementally
> Thanks,
>
> ...ant
>
> On 5/26/06, Jim Marino < [EMAIL PROTECTED] > wrote:
>>
>> Yea sorry got called into other things yesterday.
>>
>> We definitely don't want to cast like that since
>> AbstractCompositeContext is not a public API and it involves touching
>> internal structures. This use case brings up an interesting set of
>> issues. It sounds as if what you need is a management API. Related to
>> this, I don't think we should allow arbitrary client code to dig
>> around into a composite context since it's not really part of the SCA
>> programming model and, probably more importantly, it's a potential
>> security concern. So, we will probably need to define some security
>> mechanism. Also, what we probably want is access to runtime
>> artifacts, not what's in a particular SCDL, since the latter may not
>> be in sync with the current runtime state.
>>
>> Maybe we could use this to start a discussion of what type of
>> management API is needed?
>>
>> Jim
>>
>> On May 26, 2006, at 5:08 AM, ant elder wrote:
>>
>> > Never did get any answer on this. Having the class below in the
>> rhino
>> > container works as it uses the AbstractCompositeContext package
>> > name, but it
>> > seesm a bit hacky:
>> >
>> > package org.apache.tuscany.core.context.impl;
>> >
>> > public class ComponentNamesAccessor {
>> >
>> > public static Set<String> getComponentNames(ModuleContext
>> > moduleContext)
>> > {
>> > if (moduleContext instanceof AbstractCompositeContext) {
>> > Map<String, ScopeContext> x =
>> ((AbstractCompositeContext)
>> > moduleContext).scopeIndex;
>> > return x.keySet();
>> > }
>> > return null;
>> > }
>> >
>> > }
>> >
>> > ...ant
>> >
>> >
>> > On 5/24/06, ant elder <[EMAIL PROTECTED] > wrote:
>> >>
>> >> Jim, this would be unmanaged code, not in a component, so it
>> >> doesn't look
>> >> like there is any API for this. The idea of TUSCANY-417 is an
>> >> interactive
>> >> JavaScript shell along the lines of what Jeremy described as a
>> >> "first-class
>> >> client environment for JavaScript".
>> >>
>> >> ...ant
>> >>
>> >>
>> >> On 5/24/06, Jim Marino < [EMAIL PROTECTED]> wrote:
>> >> >
>> >> > Can you explain why you need the list of components? For managed
>> >> code
>> >> > (i.e. in a component) the spec defines a way to get the metadata
>> >> > associated with a module.
>> >> >
>> >> > Jim
>> >> >
>> >> > On May 24, 2006, at 1:30 AM, ant elder wrote:
>> >> >
>> >> > > I've a J2SE client that needs to get a list of all the
>> components
>> >> > > defined in
>> >> > > the current module, is that possible? There used to be the
>> >> getMetaData
>> >> > > method but thats been removed now. If there is no easy way
>> right
>> >> > > now could
>> >> > > i add something?
>> >> > >
>> >> > > ...ant
>> >> > >
>> >> >
>> >> >
>> >> >
>> >>
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >> >
>> >> >
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
