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]
