On Feb 20, 2006, at 8:56 AM, hung tran wrote:
Hi Jim,
I hope this makes it clearer, otherwise i'll give it another shot :)
From: Jim Marino [EMAIL PROTECTED]
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: Re: dynamic invocation...again
Date: Fri, 17 Feb 2006 14:39:39 -0800
Hi Hung,
I'm not quite sure I follow...
On Feb 17, 2006, at 12:09 PM, hung tran wrote:
Hi Tuscans,
I had previously posted a question regarding dynamic invocation,
which i believe i didn't word clearly enough.
I would like to build a test tool, with a runtime piece sitting
as part of the container.
I assume here you want to have some type of code that sits
inside the runtime and performs some type of analysis. Could
you provide some use case so I understand better?
say you've developed a component and want to see that it works. To
do that at the very least, you'd need to create an entrypoint and
then some sort of client - a jsp for instance - to invoke it.
Well I'd like to simplify that, such that you could test the
component as you develop without having to build these extra
artifacts just to see if it works.
You don't need an entry point to invoke a component from a JSP (or
unit test, etc.) assuming the module context is set properly - just
use ModuleContext.locateService(). You can also use the
RuntimeContext and AggregateContext APIs (see the unit tests in core
for how that is done). There are some limitations with the latter
APIs, however:
- Currently, there is no API to dynamically navigate the aggregate
context hierarchy. You need to know the name of the aggregate context
when you call AggregateContext.getInstance(..). We could easily add
the ability to return the collection of child contexts.
- How one gets ahold of RuntimeContext will be depoyment platform
(e.g. Tomcat, Geronimo, etc.) specific.
So the most important part of this enablement is to be able to
invoke this particularcomponent. The best way I found to do this
is to (as you said) 'sit inside the runtime' and perform this
invocation. Since I'll only know of the component at runtime, I'll
need to dynamically obtain the service on that component. I
believe this can be best done if i'm inside the runtime.
There are several options here:
- You can have something that sits inside the deployment
environment but not inside RuntimeContext (the Tuscany runtime).
This just walks RuntimeContext and its aggregates.
- You develop a system component which sits in a system aggregate
in the runtime (see SystemAggregateContext) and provides the
monitoring facilities.
The goal is to be able to invoke any component in any module in any
(sub)system, so i'll need to invoke by name as rather than by
reference.
Could you elaborate what you mean by name vs. by reference
and give a use case here?
Well, currently when you look up a service, it would be casted to
an interface that is known,
then the desired method on that interface is called.
ie
HelloWorldService helloworldService = (HelloWorldService)
moduleContext.locateService(HelloWorldService);
helloworldService.getGreetings(world);
which is what i would call be reference.
With 'by name' I only know the string values of the service and the
operation, thus i won't be able to preform any casting. I guess it
would be similar to java reflection.
I would use the logical model to find out the service and then use
reflection to get at the method for the operation. This presumably
could be done with a DII, which we don't have yet in the spec. One
thing I don't want to do is cast from the business interface to the
DII since it would require proxies, mixins, or subclassing on
everything returned by locateService(..). I'd rather see a separate
API, or better, just use Java reflection.
As a part of the runtime, I assume I'll be granted access to
APIs not available to clients, thus my question is whether there
is currently a way for me to perform this action or is there
anything planned in the near future.
There are APIs that are not part of the SCA spec and we could
certainly add additional ones if appropriate. If we can pinpoint
the use cases, I can tell you if there are existing ones.
I'll need to be able to create objects in the context of the
desired module, as well as impersonate the module when invoking.
You can create components (actually InstanceContexts) in a
module (actually an AggregateContext) so this may be what you
need. What do you mean by impersonate?
By impersonating, i'm trying to say that when i'm invoking a
particular component in that module,
i get the same priviledges and resources as if I'm calling from
within the module.
Right now, there is nothing that inhibits locateService other than
needing to be in the correct classloader context (we still need to
add a mechanism for retrieving the classloader
