JavaScript container

[ant elder <an...@gmail.com>]

FYI, I've started porting the old JavaScript container to the new trunk
codebase in sca/containers/container.javascript. So far its just a copy of
the groovy container with the groovy specific bits changed to use Rhino.
There's still a fair bit to do  which I'll continue with (or if anyone else
wants to help?), but I've a few of questions:

I've had to use (and the groovy container does also) quite a lot of
@SuppressWarnings("unchecked"), eg in the JavaScriptComponent class. Is
there some things I can do with generics to avoid these?

In JavaScriptComponent getServiceInstance there's a TODO saying "this should
return a default service from a wire", whats the correct way to implement
that method? I've had to create a proxy which doesn't seem right.

With the new SPI there's still quite a lot of boiler plate code that needs
to be written to implement a container and a lot of common code btw
JavaScript and Groovy. How finished is the current SPI and can something be
done to make it simpler to implement common extension types?

   ...ant

Unchecked warnings: JavaScript container

[Jeremy Boynes <jb...@apache.org>]

On Jul 28, 2006, at 4:38 AM, ant elder wrote:
> I've had to use (and the groovy container does also) quite a lot of
> @SuppressWarnings("unchecked"), eg in the JavaScriptComponent  
> class. Is
> there some things I can do with generics to avoid these?

I think some of these can be removed if we change the signature of  
ScopeContainer.getInstance() to
    <T> T getInstance(AtomicComponent component)

which removes the need to cast the response. I'll give it a go and  
commit it if it works.
--
Jeremy


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org