On Oct 11, 2006, at 6:00 AM, ant elder wrote:
This is ending up all talk and no action
I don't see it that way. I think we are trying to arrive at the right
thing to do...I've asked specific questions that I'd like to get
answers to before I feel comfortable moving this out of the sandbox.
I'll list them again here, and perhaps you could respond inline?
Based on my current understanding of the code, I have also outlined
the path I think we should take for incorporating this into core.
- 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?
- 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?
- 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
Based on my current understanding, my recommendation would be to do
the following:
1. AsyncInvoker.java
- Script containers should extend from an SPI class
2. AsyncMonitor.java
- Script containers should define their own logging interface.
Having one interface with no implementation seems valueless
3. EasyComponent.java
- I believe this to be adding a "context" object for references and
properties. How does this play with a scripting programming model
that uses DI? My recommendation would be to document this as an
implementation pattern
4. EasyComponentBuilder.java
- Ditto from EasyComponent
5. EasyComponentType.java
- I'd like to fix the core component loading problem. I think we can
also move the lifecycle scope method to ComponentType (also moving it
from PojoComponentType)
6. EasyComponentTypeLoader.java
- If do change 5, we don't need this anymore
7. EasyInstanceFactory.java
- Should be replaced by ObjectFactory from SPI
8. EasyImplementation.java
- If we do change 7, I don't think we need this. Each implementation
type should define their own model object anyway so we can track
types during the build phase (this is important). Having a generic
implementation representation with no specialization will occlude
specifics related to types.
9. EasyImplementationLoader.java
- Ditto for the above
10. EasyInstance.java
- I'm not sure if this is needed anymore. The operations which may
be done on a script instance seem specific to the script type to me
11. EasyInvoker.java
- I'm also not sure if this is needed anymore.
So, based on this, I would:
1. Fix AsyncInvoker
2. Modify the ComponentType signature to include lifecycle scope
3. Fix the component type loading problem
I believe that would be the best way to get this moved out of the
sandbox. Based on the answers to the questions above, I may be
missing something and we can revist. I'm happy to volunteer and do
the work. What do you think?
Jim
so I'm going to again suggest just
moving it now, pulling the bits into core as discussed and you've said
you'll help with, and then seeing whats left and decide what to do
with that
then.
...ant
On 10/11/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>> I took a closer look at the ComponentType encapsulation
problem. The
>> problem resides in the fact that the generic component type
element
>> loader creates a generic component type as the component type side
>> file is processed. What should happen is that the component type
>> should be created by the implementation loader (e.g.
>> PojoComponentType, or maybe ScriptComponentType) and passed
into the
>> loader. The load method on StAXElementLoader would need to be
changed
>> to:
>>
>> load(CompositeComponent parent, ModelObject object,
XMLStreamReader
>> reader, DeploymentContext deploymentContext) would
>>
>> Where "object" was a model object the loader would populate or
null,
>> in which case the loader would be responsible for creating one.
>
>
> +1. So when object is null there simply no specialized component
> type and
> just the base would do. Right ?
>
Yep
> In
>> the case of custom component types, the implementation loader
would
>> create a subclass of ComponentType and pass it back into the
loader
>> registry. A script component type loader would then be responsible
>> for introspecting the custom component type side file.
>
>
> Here again is there a way where the custom component type loaders
> are only
> called for extensions i.e. only for those elements that are not
> known to the
> base ComponentType. This way we can avoid duplication of how the
> common
> stuff of properties / references / services get loaded. Am I off
> track ?
>
I don't quite follow, can you point me to code that illustrates the
problem? AtomicComponent implementations always need to deal with
wires and properties being handed to them by the wiring fabric as
they need to choose an injection implementation strategy.
> Without this, we can't properly support scopes in side files so I'd
>> like to get this fix in.
>
> Not only for the scopes. We are not able to get the basic sidefile
> stuff up
> in Pojo - meaning today if we wanted to try out Pojo implementation
> of a
> component with side files, we will end up in exceptions.
Yes componentType side files are broken for POJOs as well but the fix
I outlined will address that as well
---------------------------------------------------------------------
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]
