You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2006/05/24 10:30:35 UTC
Getting list of components in a module
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
Re: Getting list of components in a module
Posted by Jeremy Boynes <jb...@apache.org>.
On 5/24/06, ant elder <an...@gmail.com> wrote:
> Its for this: http://issues.apache.org/jira/browse/TUSCANY-417. Which would
> be based on the Rhino shell: http://www.mozilla.org/rhino/shell.html, which
> to quote from that site provides "... an interactive environment for
> exploratory programming.".
>
> Ideally the shell environment would be configured automatically from the SCA
> config so you can do something like the following without having to do
> explicit locateService calls:
>
> js> print(Helloworld.getGreetings("ant"));
> hellp ant
> js>
>
Would it be possible to promote this further and have a first-class
client environment for JavaScript? In this environment there would be
pure JavaScript objects representing references to other services; for
example, in your example above "Helloworld" would be a JavaScript
object implementing the service interface.
In this mode, there would be no need for the application code to
access the list of components, they would just be there ready to be
used. Each object would be the JavaScript equivalent of the proxies
that are injected into a Java component to represent its references.
I would imagine this would be the same as the model used inside a
browser, just using its native JS implementation rather than Rhino.
Actually, this could be start of a JavaScript Client/Implementation
spec - would you be interested in proposing it to the spec
collaboration?
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Getting list of components in a module
Posted by ant elder <an...@gmail.com>.
Its for this: http://issues.apache.org/jira/browse/TUSCANY-417. Which would
be based on the Rhino shell: http://www.mozilla.org/rhino/shell.html, which
to quote from that site provides "... an interactive environment for
exploratory programming.".
Ideally the shell environment would be configured automatically from the SCA
config so you can do something like the following without having to do
explicit locateService calls:
js> print(Helloworld.getGreetings("ant"));
hellp ant
js>
...ant
On 5/24/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> On 5/24/06, ant elder <an...@gmail.com> 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?
>
> The spec and programming model try to discourage that kind of
> operation. The main reason for this is that it is transferring control
> from SCA back into the application which means you lose many of the
> benefits at the core of SCA itself.
>
> For example, one of the most common reasons something wants a list of
> components is so that it can perform routing decisions. This bypasses
> the SCA wiring model used to assemble the different services together.
> It means that you need to change the application code when the wiring
> requirements change.
>
> It was these kind of issues that led to the spec folks wanting to
> reconsider the metadata story which is why getMetaData() went away.
> Until that's worked out I wouldn't be in favour of adding it back it.
>
> Having said that, there may be other ways to achieve the larger
> purpose here. Could you provide some more information on what led to
> this need and perhaps folks here could suggest an alternative?.
>
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Getting list of components in a module
Posted by Jeremy Boynes <jb...@apache.org>.
On 5/24/06, ant elder <an...@gmail.com> 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?
The spec and programming model try to discourage that kind of
operation. The main reason for this is that it is transferring control
from SCA back into the application which means you lose many of the
benefits at the core of SCA itself.
For example, one of the most common reasons something wants a list of
components is so that it can perform routing decisions. This bypasses
the SCA wiring model used to assemble the different services together.
It means that you need to change the application code when the wiring
requirements change.
It was these kind of issues that led to the spec folks wanting to
reconsider the metadata story which is why getMetaData() went away.
Until that's worked out I wouldn't be in favour of adding it back it.
Having said that, there may be other ways to achieve the larger
purpose here. Could you provide some more information on what led to
this need and perhaps folks here could suggest an alternative?.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Getting list of components in a module
Posted by Paul Fremantle <pz...@gmail.com>.
Well the good news is that this is the only change in the spec classes
between the published 0.9 and the M1 release. On the other it seems odd to
just have the one change. It really doesn't seem worth removing one method
on one class and therefore not being compliant with the 0.9 spec. On the
other hand I still support the M1 release - its certainly not worth holding
it up for.
Paul
On 5/26/06, Paul Fremantle <pz...@gmail.com> wrote:
>
> Wouldn't it be better to wait till the spec is updated?
> If you are publishing a release that doesn't match the spec won't that
> confuse people?
>
> Paul
>
>
> On 5/26/06, Jeremy Boynes <jb...@apache.org> wrote:
> >
> > Sebastien removed it back in Feb (r379362) as the whole view of
> > metadata in the spec was fuzzy and going to be reviewed (which has not
> > happened yet).
> >
> > --
> > Jeremy
> >
> > On 5/26/06, Paul Fremantle < pzfreo@gmail.com> wrote:
> > > On 5/24/06, ant elder <an...@gmail.com> 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.
> > >
> > >
> > > Removed from where?
> > >
> > > Paul
> > >
> > > --
> > > Paul Fremantle
> > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > >
> > > http://bloglines.com/blog/paulfremantle
> > > paul@wso2.com
> > >
> > > "Oxygenating the Web Service Platform", www.wso2.com
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
> --
>
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
Re: Getting list of components in a module
Posted by Paul Fremantle <pz...@gmail.com>.
Wouldn't it be better to wait till the spec is updated?
If you are publishing a release that doesn't match the spec won't that
confuse people?
Paul
On 5/26/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> Sebastien removed it back in Feb (r379362) as the whole view of
> metadata in the spec was fuzzy and going to be reviewed (which has not
> happened yet).
>
> --
> Jeremy
>
> On 5/26/06, Paul Fremantle <pz...@gmail.com> wrote:
> > On 5/24/06, ant elder <an...@gmail.com> 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.
> >
> >
> > Removed from where?
> >
> > Paul
> >
> > --
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >
> > http://bloglines.com/blog/paulfremantle
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
Re: Getting list of components in a module
Posted by Jeremy Boynes <jb...@apache.org>.
Sebastien removed it back in Feb (r379362) as the whole view of
metadata in the spec was fuzzy and going to be reviewed (which has not
happened yet).
--
Jeremy
On 5/26/06, Paul Fremantle <pz...@gmail.com> wrote:
> On 5/24/06, ant elder <an...@gmail.com> 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.
>
>
> Removed from where?
>
> Paul
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Getting list of components in a module
Posted by Paul Fremantle <pz...@gmail.com>.
On 5/24/06, ant elder <an...@gmail.com> 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.
Removed from where?
Paul
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
Re: Getting list of components in a module
Posted by ant elder <an...@gmail.com>.
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 < jmarino@myromatours.com> 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 < jmarino@myromatours.com > 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 <ant.elder@gmail.com > 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 < jmarino@myromatours.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> >> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >> >
> >> >> >
> >> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Getting list of components in a module
Posted by Jim Marino <jm...@myromatours.com>.
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 <jm...@myromatours.com> 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 <an...@gmail.com> 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 <jm...@myromatours.com> 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: tuscany-dev-unsubscribe@ws.apache.org
>> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >> >
>> >> >
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Getting list of components in a module
Posted by ant elder <an...@gmail.com>.
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
2) Put back the getMeteData method
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.
Any comments on your preferred approach or alternative suggestions?
Thanks,
...ant
On 5/26/06, Jim Marino <jm...@myromatours.com> 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 <an...@gmail.com> 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 <jm...@myromatours.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >
> >> >
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Getting list of components in a module
Posted by Jeremy Boynes <jb...@apache.org>.
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 <jm...@myromatours.com> 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 <an...@gmail.com> 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 <jm...@myromatours.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >
> >> >
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Getting list of components in a module
Posted by Jim Marino <jm...@myromatours.com>.
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 <an...@gmail.com> 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 <jm...@myromatours.com> 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: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>> >
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Getting list of components in a module
Posted by ant elder <an...@gmail.com>.
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 <an...@gmail.com> 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 <jm...@myromatours.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
Re: Getting list of components in a module
Posted by ant elder <an...@gmail.com>.
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 <jm...@myromatours.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Getting list of components in a module
Posted by Jim Marino <jm...@myromatours.com>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org