I looked at this some more and I think we can make a change in core
to support loading of custom component types. This will allow us to
get rid of having to use encapsulation for component types. Also, the
async invoker should move into an extension class in core. Finally, I
think ObjectFactory can replace EasyInstanceFactory. Given this, the
classes that remain are:
- EasyComponent
-EasyComponentBuilder
-EasyImplementation
-EasyImplementationBuilder
- EasyInvoker
Assuming we make the above mentioned change in core, most of the
above code contains "template" code that would have to be integrated
with container-specific code (e.g. handling of references). Given
that, would it be better to just document these code snippets in the
extension documentation as they are generally three-line statements?
I may be missing some extra functionality so please let me know.
Jim
On Oct 9, 2006, at 11:47 AM, Jim Marino wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
