Re: Getting list of components in a module

Wed, 31 May 2006 07:42:03 -0700

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]























					Reply via email to