Yeah, as Jim says this is likely to stop working later when we tighten
up classloading and security - application code won't be able to see
the internal class to cross-cast and the calls should probably have a
security check on it.
To make this work longer term I think we should add some management
interfaces to the SPI package and commit to them longer term. We need
to put some thought into this though to make sure the management API
is compatible with JMX (specifically Open MBeans) and one of the
web-services management specs (e.g. WS-DM). Sounds like we need
another thread on that ...
I'd also suggest separating the shell from the Rhino container
implementation as we wouldn't want them to have the same permissions
and putting it in a separate codebase is an easy way to do that.
--
Jeremy
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]
