On Oct 9, 2006, at 3:42 AM, ant elder wrote:
On 10/7/06, Jim Marino <[EMAIL PROTECTED]> wrote:
On Oct 7, 2006, at 10:42 AM, Jim Marino wrote:
>
> On Oct 7, 2006, at 7:22 AM, ant elder wrote:
>
>> This is all working quite well now so i'd like to move it from my
>> sandbox to
>> be with the other containers. BSF 2.4 has just come out and the
>> jar is
>> available from a proper maven repo and the script container
>> supports all the
>> SCA things like references, properties and async, also the
start of a
>> website page describing it which I'll move to the site once its a
>> bit more
>> done:
>> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/
>> container.script/doc/sca-java-container-script.xml
>>
>> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/
>> container.script/
>> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/
>> container.easy/
>>
> I'm fine with this as long as the name of "container.easy" can be
> changed to something that denotes it has to do with scripting,
> something like "container.bsf".
>
After looking at the code more instead of having something separate,
why wouldn't we look to see if we can merge the "easy container" into
the extension API? I'd like to get a clearer direction on this before
we move things around.
Specifically, I have a few questions related to this:
1. Is this container just for scripting? It appears not to be tied to
scripting
2. What value does this container provide over the extension API?
Does it automate certain coding tasks only relevant to a subset of
containers or all containers? Could we just merge such automation
with AtomicComponentExtension
3. There appears to be a bit of code duplication, some of which may
be a vestige from the Groovy container which needs to be refactored.
For example, AsyncInvoker. In a merge, maybe we could eliminate the
need for this?
Jim
Way back I was moaning about the complexity of the SPI and it was
suggested
having a separate extension project for a simplified SPI for
extensions with
simpler requirements.
Could you outline where you think core is too complex for "simple
requirements"? I'd like to get an extension into core. What I
specifically want to avoid is creating a parallel extension mechanism.
I can't find a link, maybe the 1st sandbox phone call
or an old IRC chat? Thats where this came from. Its not quite
finished yet,
there's some parts that could be simplified further. I'd also like
to do the
same thing for bindings but haven't got to that yet. This is not
necessarily
tied to only scripting containers but thats all we've tried it with
so far,
and as Venkat suggests there likely is a bit more work required to
make it
more generally useful. There probably are some parts that could be
moved to
existing SPI classes, but there are also parts that may be a bit
inflexible
to be made part of the general extension SPI. As you point out the
async bit
does seem pretty isolated so that probably could be easily moved
out. Given
we're trying to get an M2 release out real soon I'm not sure about
messing
with the existing SPI classes now. How about for now moving the
obvious bits
like async out but keeping the rest in say a separate
container.helperproject or in a separate SPI package like
org.apache.tuscany.spi.extension.container?
What parts are you suggesting to move up? I definitely do not want to
create another SPI package. Perhaps you could list the parts of the
classes you would move into a helper library as well as the areas
they are trying to simplify? This way we could decide whether the
core spi can be simplified directly? To start with, I assume the
following would not be included:
- AsyncTargetInvoker
- AsyncMonitor
- EasyInstanceFactory since that can be done using an ObjectFactory
Some specific questions I have are:
- How are script scopes handled? I'm assuming we want to have the
runtime manage statefull scripts, as we get that for free.
- I also noticed the scope is set by default to Module. The default
SCA Java is stateless. I agree module scope may be a better default
but do you think we should be consistent with other SCA language
specs here?
- EasyComponentType encapsulates another ComponentType. I would have
thought there would be an inheritance relationship. Was this because
we need a specialization of ComponentType to be created by the
generic side-file loader? If so, I think we should fix that in core.
- More generally on component types, I haven't been following the PHP
spec work but my understanding based on proposals from the people
working on it to the assembly group is that the trend is to move away
from having to author side-files and more towards code-level metadata
and defaults. Would we want to emphasize that? Maybe you could ping
Graham Charters who has been working on these issues?
- Do scripts need to be defined by the Java idl or could I use WSDL
or JSON or something else (assuming the proper extension)?
- What does EasyInstanceFactory.getResponseClasses(List<Class>
services) do?
- How are references handled? Can they be injected onto fields in
prototype-based languages?
I think the best way to figure out what would go into core versus an
extension library is to get a list of classes you propose moving into
core versus into the library. Does that work for you?
Jim
...ant
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
