You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2006/10/07 16:22:52 UTC
Re: Refactoring commonality amongst Script containers in Java SCA
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/
...ant
On 9/13/06, ant elder <an...@gmail.com> wrote:
>
> The problem with the generic script container which is using BSF is that
> its quite limited as to what it can do with introspection. For example, I'm
> don't think it can get at the attr_writer variables in Ruby so it can't
> support Ruby introspection the way the C++ Ruby container does, and there's
> probably similar problems with other languages. I also couldn't see how to
> get it to work with scopes properly without using a new BSFManager for each
> instance which means recompiling the script for each instance which is a
> bit inefficient. So at least for now I think it is useful to keep the
> langauge specific containers (i've just added a rhino one to the sandbox).
>
> What i'd like to do now is just implement a few containers and get support
> for all the things like scopes, lifecycle, async, properties and references
> working so we can clearly see what code can be made common. If you'd like to
> do Ruby or add support for something like async or component lifecylces that
> would be great.
>
> ...ant
>
> On 9/13/06, Venkata Krishnan <fo...@gmail.com> wrote:
> >
> > Hi Ant,
> >
> > Sequel to our last chat over IRC I took a look at your Sandbox. I am
> > able
> > to understand all of what you have done there. A couple of thoughts /
> > questions ...
> > - So would it be that we just have this one 'ScriptContainer' that will
> > take
> > care of javascript, ruby, groovy.
> > - Would it be good to have a Script Registry (like the wsdl registry and
> > so
> > on) that would have compiled scripts. So given a script source one can
> > get
> > a BSFEngine from the registry. But then what about the context info
> > (properties and references) - how do we set them in a 'flyweight' way?
> > - What do we do about introspectable component type info? Should we
> > have an
> > interface for which we will have implementations for various script
> > types?
> >
> > Please let me know your thoughts on the next steps with the Sandbox
> > stuff
> > and what I can help you out with?
> >
> > Thanks
> >
> > - Venkat
> >
> >
>
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Jim...
Here is whatever I know of this...
To start with, yes this is just for the script containers
When we were doing the containers for scripting, we found that we were just
copying a basic framework of common code across containers and then
specializing parts that were very specific to the scripting language in
question.
For example the Javascript and Ruby containers will look just about the same
but for the parts where the bridges - Rhino and JRuby come in. The specific
parts typically come in where these bridges have to be invoked to compile
the given script and create an instance of it, to transform data objects
from Java to Script objects during function invocation.
But for this, there is a whole lot of other things that are pretty much
common which has been factored into 'easy'. This factoring is aimed only
accelerate the development of a subset of containers - those that are
related to scripting as they all share the common feature of having to
specify the script, having to load and compile the script thro appropriate
bridges and so on.
I am not sure if this commonality is wide enough to be taken further up into
AutomicComponentExtension level. Anyways will wait for Ant to bring in his
view as the originator of this
Thanks
- Venkat
Thanks
- Venkat
On 10/8/06, Jim Marino <jm...@myromatours.com> 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
>
>
> > Jim
> >
> >> ...ant
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by Jim Marino <jm...@myromatours.com>.
On Oct 25, 2006, at 8:02 AM, ant elder wrote:
> Comments in line...
>
> ...ant
>
> On 10/11/06, Jim Marino <jm...@myromatours.com> wrote:
> <snip>
>
> - How are script scopes handled? I'm assuming we want to have the
>> runtime manage statefull scripts, as we get that for free.
>
>
> agree
>
> - 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?
>
>
> AFAICT most people think module is a better default and I think thats
> especially so for scripting languages, so while there is no spec for
> scripting languages I'd prefer to use a default that works well
> with them.
> Maybe the Java spec people should revisit the decision to use
> stateless as
> their default?
I've made this argument on several occasions to the spec group but I
haven't been successful in convincing people. I'll give it another
try though since I agree module scope is a better default
(interestingly in Srping the "singleton" equivalent is the default).
>
> - 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?
>
>
> Yes definitely! If you trawl back through the archives we've already
> discussed doing this, its something I think is really important to
> get done.
> Wasn't possible in the M2 time frame unfortunately , I'm planning
> on trying
> to get it done for M3.
>
> - Do scripts need to be defined by the Java idl or could I use WSDL
>> or JSON or something else (assuming the proper extension)?
>
>
> They shouldn't be restricted to Java IDL, WSDL works as well, eg with
> JavaScript/E4X, and I mentioned a while back wanting an SMD IDL
> for JSON
> and JavaScript but that was before we had the IDL extension story
> sortted
> out - another thing for M3.
>
JSON would be interesting.
>
>> - What does EasyInstanceFactory.getResponseClasses(List<Class>
>> services) do?
>
>
> It was so the response from a script call which may be of unknown
> type can
> be coerced to the expected type. Now that we have the databinding
> framework
> this needs to be revisited as part of the larger work of
> integrating the
> databinding framework with the script language containers.
>
Ah ok
> - How are references handled? Can they be injected onto fields in
>> prototype-based languages?
>
>
> Not presently for JavaScript (not sure about Ruby, Venkat?) and it
> wont be
> possible with the script container using BSF for JavaScript either
> due to a
> limitation with the bsf engine. Thats fixed in BSF v3 though which is
> another thing I would like to look at in M3.
>
I think that would be good to do.
Jim
> ...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by ant elder <an...@gmail.com>.
Comments in line...
...ant
On 10/11/06, Jim Marino <jm...@myromatours.com> wrote:
<snip>
- How are script scopes handled? I'm assuming we want to have the
> runtime manage statefull scripts, as we get that for free.
agree
- 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?
AFAICT most people think module is a better default and I think thats
especially so for scripting languages, so while there is no spec for
scripting languages I'd prefer to use a default that works well with them.
Maybe the Java spec people should revisit the decision to use stateless as
their default?
- 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?
Yes definitely! If you trawl back through the archives we've already
discussed doing this, its something I think is really important to get done.
Wasn't possible in the M2 time frame unfortunately , I'm planning on trying
to get it done for M3.
- Do scripts need to be defined by the Java idl or could I use WSDL
> or JSON or something else (assuming the proper extension)?
They shouldn't be restricted to Java IDL, WSDL works as well, eg with
JavaScript/E4X, and I mentioned a while back wanting an SMD IDL for JSON
and JavaScript but that was before we had the IDL extension story sortted
out - another thing for M3.
> - What does EasyInstanceFactory.getResponseClasses(List<Class>
> services) do?
It was so the response from a script call which may be of unknown type can
be coerced to the expected type. Now that we have the databinding framework
this needs to be revisited as part of the larger work of integrating the
databinding framework with the script language containers.
- How are references handled? Can they be injected onto fields in
> prototype-based languages?
Not presently for JavaScript (not sure about Ruby, Venkat?) and it wont be
possible with the script container using BSF for JavaScript either due to a
limitation with the bsf engine. Thats fixed in BSF v3 though which is
another thing I would like to look at in M3.
...ant
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by Jim Marino <jm...@myromatours.com>.
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 <jm...@myromatours.com> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by ant elder <an...@gmail.com>.
This is ending up all talk and no action 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 <jm...@myromatours.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by Jim Marino <jm...@myromatours.com>.
>> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
A few comments inline
Thanks
- Venkat
On 10/11/06, Jim Marino <jm...@myromatours.com> wrote:
>
>
> On Oct 10, 2006, at 7:53 AM, ant elder wrote:
>
> > I'd be really happy for all those to become part of the core, but
> > I'm not
> > sure I see how all that remains will be a few three-line
> > statements. How
> > about I move this to a container-helper as I suggested before, we
> > pull all
> > the bits out and do the refactoring and before we cut M2 see whats
> > left and
> > if there really is nothing much left just doc it otherwise re-
> > evaluate then
> > what to do with what remains?
> 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 ?
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 ?
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.
In addition, I'd like to get duplicate code
> taken care of (AsyncTargetInvoker, EasyInstanceFactory). I'm willing
> to take this on and help out since I think this is important we clear
> up. Also, I still believe once we take care of these issues we
> probably won't need a separate extension library.
>
> One issue is this does affect the SPI and I think we need to assess
> the risk of these changes on getting the release out. If people are
> o.k. with me doing these changes, I'll jump in and make them. If it
> poses too much risk, I suggest we consider branching. Thoughts?
>
> Jim
>
>
> >
> > ...ant
> >
> > On 10/10/06, Jim Marino <jm...@myromatours.com> wrote:
> >>
> >> 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 <jm...@myromatours.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by ant elder <an...@gmail.com>.
Thats an excellent idea. I think there are still parts of this that could be
made significantly easier by altering the SPI but I'll be happy to have them
in utility jar for now. I'll go do this.
...ant
On 11/9/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> How about adding a scripting utility jar? This would be an additional
> jar that contained utility classes relevant to scripting extensions
> that they could all refer too, avoiding duplication but not putting
> too much implementation in the SPI itself (which I think we all agree
> should be avoided).
>
> --
> Jeremy
>
> On Nov 8, 2006, at 4:04 PM, Jim Marino wrote:
>
> >
> > On Nov 8, 2006, at 2:08 PM, ant elder wrote:
> >
> >> This hasn't entirely turned out as I was expecting. This container
> >> now looks
> >> remarkably similar to the other existing ones,
> > I see this as a good sign...to me it means we are arriving at an SPI
> >> I thought we were trying to
> >> refactor out the common parts to come up with an easier container
> >> SPI?
> > Yes and I couldn't find much to factor into the kernel. However, I
> > did factor things out that were redundant with the later.
> >> Lets
> >> take MissingSideFileException as an example, that could be reused
> >> by many
> >> container extensions so could be in a container SPI couldn't it?
> >>
> > MissingSideFileException could be moved up. However, I would be
> > very cautious about moving implementation classes. There is always
> > a trade-off in SPI design between providing out-of-the-box
> > implementations versus too tightly coupling extensions to the
> > containers they are extending. If there are too many implementation
> > classes in an SPI, it will render the latter inflexible and it will
> > be difficult to evolve in a backward compatible way in the future.
> > For example, we can take a few specifics:
> >
> > 1. ScriptComponentBuilder. Injecting of properties is specific to
> > the implementation type. One thing that we could potentially change
> > is having scope containers passed in. We should think about this.
> >
> > 2. ScriptComponentTypeLoader. How a component type side file is
> > resolved for an implementation type is specific to it. Providing
> > utility classes for trivial operations such as reading streams will
> > just complicate the SPI needlessly.
> >
> > 3. ScriptImplementationLoader. Pretty much the same comments as for
> > ScriptComponentTypeLoader.
> >
> > One thing that could be simplified in the extension (as I mentioned
> > previously) is ScriptInstance could be removed altogether. What do
> > you think?
> >
> > Perhaps I'm just not seeing what could be moved up. Could you
> > elaborate on the specifics?
> >
> > Jim
> >
> >
> >
> >> ...ant
> >>
> >> On 11/4/06, Jim Marino < jmarino@myromatours.com> wrote:
> >>>
> >>> O.K., I committed the refactor to container.script with the follow
> >>> changes:
> >>>
> >>> 1. Fixed the project so it builds again :-) (it is not part of the
> >>> default build)
> >>>
> >>> 2. Removed the need for Async target invokers based on core changes
> >>>
> >>> 3. Remove ComponentType hack as that has been fixed in core
> >>>
> >>> 4. Changes to better leverage SPI
> >>> - Removal of all the "helper" classes. I was able to
> >>> factor these
> >>> out by using stuff from SPI, class hierarchy simplifications, e.g.
> >>> ScriptImplementation
> >>> - Scripts now instantiated in the build phase as opposed to
> >>> loading
> >>> - Stronger typing of errors, e.g. MissingSideFileException
> >>> - Use of ObjectFactory for creating Script instances
> >>>
> >>> 5. Fix issue where mutable properties were not thread-safe (i.e.
> >>> instances were shared across implementation instances).
> >>>
> >>> 6. Remove dependency on core impl classes and cleanup some of the
> >>> unit tests
> >>>
> >>> 7. Fix checkstyle warnings and PMD failures
> >>>
> >>> 8. Add license file
> >>>
> >>> 9 Use a config class for creating a ScriptComponent as that takes a
> >>> number of constructor parameters
> >>>
> >>>
> >>> There are also some things that could be done as potential
> >>> improvements:
> >>>
> >>> 1. Better test quality.
> >>> - There are no real tests involving invocations and wires
> >>> to and
> >>> from scripts. This could be set up with EasyMock in a pretty
> >>> straightforward way without the need for SCATestCase
> >>> - Likewise for properties, we should test accessing
> >>> properties
> >>> from within a script.
> >>>
> >>> 2. Support for scopes other than module.
> >>>
> >>> 3. Some of the class hierarchies seem like they could be simplified,
> >>> flattened, or removed. For example, ScriptInstance and its
> >>> implementation could potentially be removed completely and just have
> >>> the ScriptComponent return the BSF engine (ScriptTargetInvoker would
> >>> need to be changed for this to carry additional information).
> >>>
> >>>
> >>> Jim
> >>>
> >>> On Oct 31, 2006, at 3:05 AM, ant elder wrote:
> >>>
> >>> > No go for it, that would be great!
> >>> >
> >>> > ...ant
> >>> >
> >>> > On 10/31/06, Jim Marino < jmarino@myromatours.com> wrote:
> >>> >>
> >>> >> So do you mind if I make the changes?
> >>> >>
> >>> >> Jim
> >>> >>
> >>> >> On Oct 31, 2006, at 1:02 AM, ant elder wrote:
> >>> >>
> >>> >> > No, tied up on M2 things, i doubt I'll have time for this
> >>> till M2
> >>> >> > is done.
> >>> >> >
> >>> >> > ...ant
> >>> >> >
> >>> >> > On 10/31/06, Jim Marino <jm...@myromatours.com> wrote:
> >>> >> >>
> >>> >> >> Any luck in making these changes?
> >>> >> >>
> >>> >> >> Jim
> >>> >> >>
> >>> >> >> On Oct 26, 2006, at 8:30 AM, Jim Marino wrote:
> >>> >> >>
> >>> >> >> >>
> >>> >> >> >>
> >>> >> >> >> As you don't like the easy SPI extension I've got rid of
> >>> the
> >>> >> easy
> >>> >> >> >> extension
> >>> >> >> >> dependency of the script container. I've moved the script
> >>> >> >> >> container into
> >>> >> >> >> trunk as it was going stale and i want to start using and
> >>> >> >> >> improving it. It
> >>> >> >> >> still uses some of the easy classes which are in a helper
> >>> >> package
> >>> >> >> >> now, i'll
> >>> >> >> >> get rid of them as we clean things up. I saw you've done
> >>> >> some core
> >>> >> >> >> changes
> >>> >> >> >> for the componentType problem, thanks, I'll go look at how
> >>> >> to use
> >>> >> >> >> that for
> >>> >> >> >> this (and the other script containers) and change the
> >>> code as
> >>> >> >> >> appropriate.
> >>> >> >> >> You said you'd take on getting the things like the async
> >>> >> code into
> >>> >> >> >> the spi
> >>> >> >> >> to avoid all that duplicate code so would you like to go
> >>> >> ahead and
> >>> >> >> >> do that
> >>> >> >> >> now? (or I can do it if you like).
> >>> >> >> > O.K. I committed the changes. There is no need to handle
> >>> >> message id
> >>> >> >> > correlation as the wiring fabric (specifically
> >>> >> >> > TargetInvokerExtension) does it automatically. You should be
> >>> >> able
> >>> >> >> > to delete AsyncMonitor and the async target invoker. You
> >>> will
> >>> >> also
> >>> >> >> > need to change some of the signatures of the builders to
> >>> pass
> >>> >> in a
> >>> >> >> > WorkContext and ExectionMonitor (these are autowired to
> >>> >> >> > ComponentBuilderExtension). I made some basic changes the
> >>> the
> >>> >> >> > script container to pass tests but you will probably need
> >>> to do
> >>> >> >> > some more (limited) refactoring to get it fully
> >>> operational. I
> >>> >> >> > fixed the Groovy container so you can use that as an
> >>> example.
> >>> >> (BTW,
> >>> >> >> > as a side note, container.script is not part of the build by
> >>> >> >> default).
> >>> >> >> >
> >>> >> >> > The other changes to make are to create a script
> >>> >> specialization of
> >>> >> >> > ComponentType in the loader and use ObjectFactory for
> >>> creating
> >>> >> >> > instances.
> >>> >> >> >
> >>> >> >> >> Once the componentType and async changes
> >>> >> >> >> are done I/we can look at the next things to simplify and
> >>> >> once all
> >>> >> >> >> that
> >>> >> >> >> refactoring is done I'll look at what remains in the helper
> >>> >> >> >> package and see
> >>> >> >> >> if there are still things I think could be simplified.
> >>> >> >> >>
> >>> >> >> > If you can make those changes, we can take another pass
> >>> over the
> >>> >> >> > helper classes and see what is left.
> >>> >> >> >
> >>> >> >> > Jim
> >>> >> >> >
> >>> >> >> >> ...ant
> >>> >> >> >
> >>> >> >> >
> >>> >> >> >
> >>> >> >>
> >>> >>
> >>> --------------------------------------------------------------------
> >>> -
> >>> >> >> > To unsubscribe, e-mail: tuscany-dev-
> >>> unsubscribe@ws.apache.org
> >>> >> >> > For additional commands, e-mail: tuscany-dev-
> >>> help@ws.apache.org
> >>> >> >> >
> >>> >> >>
> >>> >> >>
> >>> >> >>
> >>> >>
> >>> --------------------------------------------------------------------
> >>> -
> >>> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> >> >> For additional commands, e-mail: tuscany-dev-
> >>> help@ws.apache.org
> >>> >> >>
> >>> >> >>
> >>> >>
> >>> >>
> >>> >>
> >>> --------------------------------------------------------------------
> >>> -
> >>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>> >>
> >>> >>
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>
> >>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by Jeremy Boynes <jb...@apache.org>.
How about adding a scripting utility jar? This would be an additional
jar that contained utility classes relevant to scripting extensions
that they could all refer too, avoiding duplication but not putting
too much implementation in the SPI itself (which I think we all agree
should be avoided).
--
Jeremy
On Nov 8, 2006, at 4:04 PM, Jim Marino wrote:
>
> On Nov 8, 2006, at 2:08 PM, ant elder wrote:
>
>> This hasn't entirely turned out as I was expecting. This container
>> now looks
>> remarkably similar to the other existing ones,
> I see this as a good sign...to me it means we are arriving at an SPI
>> I thought we were trying to
>> refactor out the common parts to come up with an easier container
>> SPI?
> Yes and I couldn't find much to factor into the kernel. However, I
> did factor things out that were redundant with the later.
>> Lets
>> take MissingSideFileException as an example, that could be reused
>> by many
>> container extensions so could be in a container SPI couldn't it?
>>
> MissingSideFileException could be moved up. However, I would be
> very cautious about moving implementation classes. There is always
> a trade-off in SPI design between providing out-of-the-box
> implementations versus too tightly coupling extensions to the
> containers they are extending. If there are too many implementation
> classes in an SPI, it will render the latter inflexible and it will
> be difficult to evolve in a backward compatible way in the future.
> For example, we can take a few specifics:
>
> 1. ScriptComponentBuilder. Injecting of properties is specific to
> the implementation type. One thing that we could potentially change
> is having scope containers passed in. We should think about this.
>
> 2. ScriptComponentTypeLoader. How a component type side file is
> resolved for an implementation type is specific to it. Providing
> utility classes for trivial operations such as reading streams will
> just complicate the SPI needlessly.
>
> 3. ScriptImplementationLoader. Pretty much the same comments as for
> ScriptComponentTypeLoader.
>
> One thing that could be simplified in the extension (as I mentioned
> previously) is ScriptInstance could be removed altogether. What do
> you think?
>
> Perhaps I'm just not seeing what could be moved up. Could you
> elaborate on the specifics?
>
> Jim
>
>
>
>> ...ant
>>
>> On 11/4/06, Jim Marino < jmarino@myromatours.com> wrote:
>>>
>>> O.K., I committed the refactor to container.script with the follow
>>> changes:
>>>
>>> 1. Fixed the project so it builds again :-) (it is not part of the
>>> default build)
>>>
>>> 2. Removed the need for Async target invokers based on core changes
>>>
>>> 3. Remove ComponentType hack as that has been fixed in core
>>>
>>> 4. Changes to better leverage SPI
>>> - Removal of all the "helper" classes. I was able to
>>> factor these
>>> out by using stuff from SPI, class hierarchy simplifications, e.g.
>>> ScriptImplementation
>>> - Scripts now instantiated in the build phase as opposed to
>>> loading
>>> - Stronger typing of errors, e.g. MissingSideFileException
>>> - Use of ObjectFactory for creating Script instances
>>>
>>> 5. Fix issue where mutable properties were not thread-safe (i.e.
>>> instances were shared across implementation instances).
>>>
>>> 6. Remove dependency on core impl classes and cleanup some of the
>>> unit tests
>>>
>>> 7. Fix checkstyle warnings and PMD failures
>>>
>>> 8. Add license file
>>>
>>> 9 Use a config class for creating a ScriptComponent as that takes a
>>> number of constructor parameters
>>>
>>>
>>> There are also some things that could be done as potential
>>> improvements:
>>>
>>> 1. Better test quality.
>>> - There are no real tests involving invocations and wires
>>> to and
>>> from scripts. This could be set up with EasyMock in a pretty
>>> straightforward way without the need for SCATestCase
>>> - Likewise for properties, we should test accessing
>>> properties
>>> from within a script.
>>>
>>> 2. Support for scopes other than module.
>>>
>>> 3. Some of the class hierarchies seem like they could be simplified,
>>> flattened, or removed. For example, ScriptInstance and its
>>> implementation could potentially be removed completely and just have
>>> the ScriptComponent return the BSF engine (ScriptTargetInvoker would
>>> need to be changed for this to carry additional information).
>>>
>>>
>>> Jim
>>>
>>> On Oct 31, 2006, at 3:05 AM, ant elder wrote:
>>>
>>> > No go for it, that would be great!
>>> >
>>> > ...ant
>>> >
>>> > On 10/31/06, Jim Marino < jmarino@myromatours.com> wrote:
>>> >>
>>> >> So do you mind if I make the changes?
>>> >>
>>> >> Jim
>>> >>
>>> >> On Oct 31, 2006, at 1:02 AM, ant elder wrote:
>>> >>
>>> >> > No, tied up on M2 things, i doubt I'll have time for this
>>> till M2
>>> >> > is done.
>>> >> >
>>> >> > ...ant
>>> >> >
>>> >> > On 10/31/06, Jim Marino <jm...@myromatours.com> wrote:
>>> >> >>
>>> >> >> Any luck in making these changes?
>>> >> >>
>>> >> >> Jim
>>> >> >>
>>> >> >> On Oct 26, 2006, at 8:30 AM, Jim Marino wrote:
>>> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> As you don't like the easy SPI extension I've got rid of
>>> the
>>> >> easy
>>> >> >> >> extension
>>> >> >> >> dependency of the script container. I've moved the script
>>> >> >> >> container into
>>> >> >> >> trunk as it was going stale and i want to start using and
>>> >> >> >> improving it. It
>>> >> >> >> still uses some of the easy classes which are in a helper
>>> >> package
>>> >> >> >> now, i'll
>>> >> >> >> get rid of them as we clean things up. I saw you've done
>>> >> some core
>>> >> >> >> changes
>>> >> >> >> for the componentType problem, thanks, I'll go look at how
>>> >> to use
>>> >> >> >> that for
>>> >> >> >> this (and the other script containers) and change the
>>> code as
>>> >> >> >> appropriate.
>>> >> >> >> You said you'd take on getting the things like the async
>>> >> code into
>>> >> >> >> the spi
>>> >> >> >> to avoid all that duplicate code so would you like to go
>>> >> ahead and
>>> >> >> >> do that
>>> >> >> >> now? (or I can do it if you like).
>>> >> >> > O.K. I committed the changes. There is no need to handle
>>> >> message id
>>> >> >> > correlation as the wiring fabric (specifically
>>> >> >> > TargetInvokerExtension) does it automatically. You should be
>>> >> able
>>> >> >> > to delete AsyncMonitor and the async target invoker. You
>>> will
>>> >> also
>>> >> >> > need to change some of the signatures of the builders to
>>> pass
>>> >> in a
>>> >> >> > WorkContext and ExectionMonitor (these are autowired to
>>> >> >> > ComponentBuilderExtension). I made some basic changes the
>>> the
>>> >> >> > script container to pass tests but you will probably need
>>> to do
>>> >> >> > some more (limited) refactoring to get it fully
>>> operational. I
>>> >> >> > fixed the Groovy container so you can use that as an
>>> example.
>>> >> (BTW,
>>> >> >> > as a side note, container.script is not part of the build by
>>> >> >> default).
>>> >> >> >
>>> >> >> > The other changes to make are to create a script
>>> >> specialization of
>>> >> >> > ComponentType in the loader and use ObjectFactory for
>>> creating
>>> >> >> > instances.
>>> >> >> >
>>> >> >> >> Once the componentType and async changes
>>> >> >> >> are done I/we can look at the next things to simplify and
>>> >> once all
>>> >> >> >> that
>>> >> >> >> refactoring is done I'll look at what remains in the helper
>>> >> >> >> package and see
>>> >> >> >> if there are still things I think could be simplified.
>>> >> >> >>
>>> >> >> > If you can make those changes, we can take another pass
>>> over the
>>> >> >> > helper classes and see what is left.
>>> >> >> >
>>> >> >> > Jim
>>> >> >> >
>>> >> >> >> ...ant
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >>
>>> >>
>>> --------------------------------------------------------------------
>>> -
>>> >> >> > To unsubscribe, e-mail: tuscany-dev-
>>> unsubscribe@ws.apache.org
>>> >> >> > For additional commands, e-mail: tuscany-dev-
>>> help@ws.apache.org
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >> >>
>>> >>
>>> --------------------------------------------------------------------
>>> -
>>> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> >> >> For additional commands, e-mail: tuscany-dev-
>>> help@ws.apache.org
>>> >> >>
>>> >> >>
>>> >>
>>> >>
>>> >>
>>> --------------------------------------------------------------------
>>> -
>>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>> >>
>>> >>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by Jim Marino <jm...@myromatours.com>.
On Nov 8, 2006, at 2:08 PM, ant elder wrote:
> This hasn't entirely turned out as I was expecting. This container
> now looks
> remarkably similar to the other existing ones,
I see this as a good sign...to me it means we are arriving at an SPI
> I thought we were trying to
> refactor out the common parts to come up with an easier container SPI?
Yes and I couldn't find much to factor into the kernel. However, I
did factor things out that were redundant with the later.
> Lets
> take MissingSideFileException as an example, that could be reused
> by many
> container extensions so could be in a container SPI couldn't it?
>
MissingSideFileException could be moved up. However, I would be very
cautious about moving implementation classes. There is always a trade-
off in SPI design between providing out-of-the-box implementations
versus too tightly coupling extensions to the containers they are
extending. If there are too many implementation classes in an SPI, it
will render the latter inflexible and it will be difficult to evolve
in a backward compatible way in the future. For example, we can take
a few specifics:
1. ScriptComponentBuilder. Injecting of properties is specific to the
implementation type. One thing that we could potentially change is
having scope containers passed in. We should think about this.
2. ScriptComponentTypeLoader. How a component type side file is
resolved for an implementation type is specific to it. Providing
utility classes for trivial operations such as reading streams will
just complicate the SPI needlessly.
3. ScriptImplementationLoader. Pretty much the same comments as for
ScriptComponentTypeLoader.
One thing that could be simplified in the extension (as I mentioned
previously) is ScriptInstance could be removed altogether. What do
you think?
Perhaps I'm just not seeing what could be moved up. Could you
elaborate on the specifics?
Jim
> ...ant
>
> On 11/4/06, Jim Marino < jmarino@myromatours.com> wrote:
>>
>> O.K., I committed the refactor to container.script with the follow
>> changes:
>>
>> 1. Fixed the project so it builds again :-) (it is not part of the
>> default build)
>>
>> 2. Removed the need for Async target invokers based on core changes
>>
>> 3. Remove ComponentType hack as that has been fixed in core
>>
>> 4. Changes to better leverage SPI
>> - Removal of all the "helper" classes. I was able to
>> factor these
>> out by using stuff from SPI, class hierarchy simplifications, e.g.
>> ScriptImplementation
>> - Scripts now instantiated in the build phase as opposed to
>> loading
>> - Stronger typing of errors, e.g. MissingSideFileException
>> - Use of ObjectFactory for creating Script instances
>>
>> 5. Fix issue where mutable properties were not thread-safe (i.e.
>> instances were shared across implementation instances).
>>
>> 6. Remove dependency on core impl classes and cleanup some of the
>> unit tests
>>
>> 7. Fix checkstyle warnings and PMD failures
>>
>> 8. Add license file
>>
>> 9 Use a config class for creating a ScriptComponent as that takes a
>> number of constructor parameters
>>
>>
>> There are also some things that could be done as potential
>> improvements:
>>
>> 1. Better test quality.
>> - There are no real tests involving invocations and wires
>> to and
>> from scripts. This could be set up with EasyMock in a pretty
>> straightforward way without the need for SCATestCase
>> - Likewise for properties, we should test accessing
>> properties
>> from within a script.
>>
>> 2. Support for scopes other than module.
>>
>> 3. Some of the class hierarchies seem like they could be simplified,
>> flattened, or removed. For example, ScriptInstance and its
>> implementation could potentially be removed completely and just have
>> the ScriptComponent return the BSF engine (ScriptTargetInvoker would
>> need to be changed for this to carry additional information).
>>
>>
>> Jim
>>
>> On Oct 31, 2006, at 3:05 AM, ant elder wrote:
>>
>> > No go for it, that would be great!
>> >
>> > ...ant
>> >
>> > On 10/31/06, Jim Marino < jmarino@myromatours.com> wrote:
>> >>
>> >> So do you mind if I make the changes?
>> >>
>> >> Jim
>> >>
>> >> On Oct 31, 2006, at 1:02 AM, ant elder wrote:
>> >>
>> >> > No, tied up on M2 things, i doubt I'll have time for this
>> till M2
>> >> > is done.
>> >> >
>> >> > ...ant
>> >> >
>> >> > On 10/31/06, Jim Marino <jm...@myromatours.com> wrote:
>> >> >>
>> >> >> Any luck in making these changes?
>> >> >>
>> >> >> Jim
>> >> >>
>> >> >> On Oct 26, 2006, at 8:30 AM, Jim Marino wrote:
>> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> As you don't like the easy SPI extension I've got rid of the
>> >> easy
>> >> >> >> extension
>> >> >> >> dependency of the script container. I've moved the script
>> >> >> >> container into
>> >> >> >> trunk as it was going stale and i want to start using and
>> >> >> >> improving it. It
>> >> >> >> still uses some of the easy classes which are in a helper
>> >> package
>> >> >> >> now, i'll
>> >> >> >> get rid of them as we clean things up. I saw you've done
>> >> some core
>> >> >> >> changes
>> >> >> >> for the componentType problem, thanks, I'll go look at how
>> >> to use
>> >> >> >> that for
>> >> >> >> this (and the other script containers) and change the
>> code as
>> >> >> >> appropriate.
>> >> >> >> You said you'd take on getting the things like the async
>> >> code into
>> >> >> >> the spi
>> >> >> >> to avoid all that duplicate code so would you like to go
>> >> ahead and
>> >> >> >> do that
>> >> >> >> now? (or I can do it if you like).
>> >> >> > O.K. I committed the changes. There is no need to handle
>> >> message id
>> >> >> > correlation as the wiring fabric (specifically
>> >> >> > TargetInvokerExtension) does it automatically. You should be
>> >> able
>> >> >> > to delete AsyncMonitor and the async target invoker. You will
>> >> also
>> >> >> > need to change some of the signatures of the builders to pass
>> >> in a
>> >> >> > WorkContext and ExectionMonitor (these are autowired to
>> >> >> > ComponentBuilderExtension). I made some basic changes the the
>> >> >> > script container to pass tests but you will probably need
>> to do
>> >> >> > some more (limited) refactoring to get it fully
>> operational. I
>> >> >> > fixed the Groovy container so you can use that as an example.
>> >> (BTW,
>> >> >> > as a side note, container.script is not part of the build by
>> >> >> default).
>> >> >> >
>> >> >> > The other changes to make are to create a script
>> >> specialization of
>> >> >> > ComponentType in the loader and use ObjectFactory for
>> creating
>> >> >> > instances.
>> >> >> >
>> >> >> >> Once the componentType and async changes
>> >> >> >> are done I/we can look at the next things to simplify and
>> >> once all
>> >> >> >> that
>> >> >> >> refactoring is done I'll look at what remains in the helper
>> >> >> >> package and see
>> >> >> >> if there are still things I think could be simplified.
>> >> >> >>
>> >> >> > If you can make those changes, we can take another pass
>> over the
>> >> >> > helper classes and see what is left.
>> >> >> >
>> >> >> > Jim
>> >> >> >
>> >> >> >> ...ant
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >>
>> ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> >> > For additional commands, e-mail: tuscany-dev-
>> help@ws.apache.org
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by ant elder <an...@gmail.com>.
This hasn't entirely turned out as I was expecting. This container now looks
remarkably similar to the other existing ones, I thought we were trying to
refactor out the common parts to come up with an easier container SPI? Lets
take MissingSideFileException as an example, that could be reused by many
container extensions so could be in a container SPI couldn't it?
...ant
On 11/4/06, Jim Marino < jmarino@myromatours.com> wrote:
>
> O.K., I committed the refactor to container.script with the follow
> changes:
>
> 1. Fixed the project so it builds again :-) (it is not part of the
> default build)
>
> 2. Removed the need for Async target invokers based on core changes
>
> 3. Remove ComponentType hack as that has been fixed in core
>
> 4. Changes to better leverage SPI
> - Removal of all the "helper" classes. I was able to factor these
> out by using stuff from SPI, class hierarchy simplifications, e.g.
> ScriptImplementation
> - Scripts now instantiated in the build phase as opposed to
> loading
> - Stronger typing of errors, e.g. MissingSideFileException
> - Use of ObjectFactory for creating Script instances
>
> 5. Fix issue where mutable properties were not thread-safe (i.e.
> instances were shared across implementation instances).
>
> 6. Remove dependency on core impl classes and cleanup some of the
> unit tests
>
> 7. Fix checkstyle warnings and PMD failures
>
> 8. Add license file
>
> 9 Use a config class for creating a ScriptComponent as that takes a
> number of constructor parameters
>
>
> There are also some things that could be done as potential improvements:
>
> 1. Better test quality.
> - There are no real tests involving invocations and wires to and
> from scripts. This could be set up with EasyMock in a pretty
> straightforward way without the need for SCATestCase
> - Likewise for properties, we should test accessing properties
> from within a script.
>
> 2. Support for scopes other than module.
>
> 3. Some of the class hierarchies seem like they could be simplified,
> flattened, or removed. For example, ScriptInstance and its
> implementation could potentially be removed completely and just have
> the ScriptComponent return the BSF engine (ScriptTargetInvoker would
> need to be changed for this to carry additional information).
>
>
> Jim
>
> On Oct 31, 2006, at 3:05 AM, ant elder wrote:
>
> > No go for it, that would be great!
> >
> > ...ant
> >
> > On 10/31/06, Jim Marino < jmarino@myromatours.com> wrote:
> >>
> >> So do you mind if I make the changes?
> >>
> >> Jim
> >>
> >> On Oct 31, 2006, at 1:02 AM, ant elder wrote:
> >>
> >> > No, tied up on M2 things, i doubt I'll have time for this till M2
> >> > is done.
> >> >
> >> > ...ant
> >> >
> >> > On 10/31/06, Jim Marino <jm...@myromatours.com> wrote:
> >> >>
> >> >> Any luck in making these changes?
> >> >>
> >> >> Jim
> >> >>
> >> >> On Oct 26, 2006, at 8:30 AM, Jim Marino wrote:
> >> >>
> >> >> >>
> >> >> >>
> >> >> >> As you don't like the easy SPI extension I've got rid of the
> >> easy
> >> >> >> extension
> >> >> >> dependency of the script container. I've moved the script
> >> >> >> container into
> >> >> >> trunk as it was going stale and i want to start using and
> >> >> >> improving it. It
> >> >> >> still uses some of the easy classes which are in a helper
> >> package
> >> >> >> now, i'll
> >> >> >> get rid of them as we clean things up. I saw you've done
> >> some core
> >> >> >> changes
> >> >> >> for the componentType problem, thanks, I'll go look at how
> >> to use
> >> >> >> that for
> >> >> >> this (and the other script containers) and change the code as
> >> >> >> appropriate.
> >> >> >> You said you'd take on getting the things like the async
> >> code into
> >> >> >> the spi
> >> >> >> to avoid all that duplicate code so would you like to go
> >> ahead and
> >> >> >> do that
> >> >> >> now? (or I can do it if you like).
> >> >> > O.K. I committed the changes. There is no need to handle
> >> message id
> >> >> > correlation as the wiring fabric (specifically
> >> >> > TargetInvokerExtension) does it automatically. You should be
> >> able
> >> >> > to delete AsyncMonitor and the async target invoker. You will
> >> also
> >> >> > need to change some of the signatures of the builders to pass
> >> in a
> >> >> > WorkContext and ExectionMonitor (these are autowired to
> >> >> > ComponentBuilderExtension). I made some basic changes the the
> >> >> > script container to pass tests but you will probably need to do
> >> >> > some more (limited) refactoring to get it fully operational. I
> >> >> > fixed the Groovy container so you can use that as an example.
> >> (BTW,
> >> >> > as a side note, container.script is not part of the build by
> >> >> default).
> >> >> >
> >> >> > The other changes to make are to create a script
> >> specialization of
> >> >> > ComponentType in the loader and use ObjectFactory for creating
> >> >> > instances.
> >> >> >
> >> >> >> Once the componentType and async changes
> >> >> >> are done I/we can look at the next things to simplify and
> >> once all
> >> >> >> that
> >> >> >> refactoring is done I'll look at what remains in the helper
> >> >> >> package and see
> >> >> >> if there are still things I think could be simplified.
> >> >> >>
> >> >> > If you can make those changes, we can take another pass over the
> >> >> > helper classes and see what is left.
> >> >> >
> >> >> > Jim
> >> >> >
> >> >> >> ...ant
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >> >
> >> >>
> >> >>
> >> >>
> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >>
> >> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by Jim Marino <jm...@myromatours.com>.
O.K., I committed the refactor to container.script with the follow
changes:
1. Fixed the project so it builds again :-) (it is not part of the
default build)
2. Removed the need for Async target invokers based on core changes
3. Remove ComponentType hack as that has been fixed in core
4. Changes to better leverage SPI
- Removal of all the "helper" classes. I was able to factor these
out by using stuff from SPI, class hierarchy simplifications, e.g.
ScriptImplementation
- Scripts now instantiated in the build phase as opposed to loading
- Stronger typing of errors, e.g. MissingSideFileException
- Use of ObjectFactory for creating Script instances
5. Fix issue where mutable properties were not thread-safe (i.e.
instances were shared across implementation instances).
6. Remove dependency on core impl classes and cleanup some of the
unit tests
7. Fix checkstyle warnings and PMD failures
8. Add license file
9 Use a config class for creating a ScriptComponent as that takes a
number of constructor parameters
There are also some things that could be done as potential improvements:
1. Better test quality.
- There are no real tests involving invocations and wires to and
from scripts. This could be set up with EasyMock in a pretty
straightforward way without the need for SCATestCase
- Likewise for properties, we should test accessing properties
from within a script.
2. Support for scopes other than module.
3. Some of the class hierarchies seem like they could be simplified,
flattened, or removed. For example, ScriptInstance and its
implementation could potentially be removed completely and just have
the ScriptComponent return the BSF engine (ScriptTargetInvoker would
need to be changed for this to carry additional information).
Jim
On Oct 31, 2006, at 3:05 AM, ant elder wrote:
> No go for it, that would be great!
>
> ...ant
>
> On 10/31/06, Jim Marino <jm...@myromatours.com> wrote:
>>
>> So do you mind if I make the changes?
>>
>> Jim
>>
>> On Oct 31, 2006, at 1:02 AM, ant elder wrote:
>>
>> > No, tied up on M2 things, i doubt I'll have time for this till M2
>> > is done.
>> >
>> > ...ant
>> >
>> > On 10/31/06, Jim Marino <jm...@myromatours.com> wrote:
>> >>
>> >> Any luck in making these changes?
>> >>
>> >> Jim
>> >>
>> >> On Oct 26, 2006, at 8:30 AM, Jim Marino wrote:
>> >>
>> >> >>
>> >> >>
>> >> >> As you don't like the easy SPI extension I've got rid of the
>> easy
>> >> >> extension
>> >> >> dependency of the script container. I've moved the script
>> >> >> container into
>> >> >> trunk as it was going stale and i want to start using and
>> >> >> improving it. It
>> >> >> still uses some of the easy classes which are in a helper
>> package
>> >> >> now, i'll
>> >> >> get rid of them as we clean things up. I saw you've done
>> some core
>> >> >> changes
>> >> >> for the componentType problem, thanks, I'll go look at how
>> to use
>> >> >> that for
>> >> >> this (and the other script containers) and change the code as
>> >> >> appropriate.
>> >> >> You said you'd take on getting the things like the async
>> code into
>> >> >> the spi
>> >> >> to avoid all that duplicate code so would you like to go
>> ahead and
>> >> >> do that
>> >> >> now? (or I can do it if you like).
>> >> > O.K. I committed the changes. There is no need to handle
>> message id
>> >> > correlation as the wiring fabric (specifically
>> >> > TargetInvokerExtension) does it automatically. You should be
>> able
>> >> > to delete AsyncMonitor and the async target invoker. You will
>> also
>> >> > need to change some of the signatures of the builders to pass
>> in a
>> >> > WorkContext and ExectionMonitor (these are autowired to
>> >> > ComponentBuilderExtension). I made some basic changes the the
>> >> > script container to pass tests but you will probably need to do
>> >> > some more (limited) refactoring to get it fully operational. I
>> >> > fixed the Groovy container so you can use that as an example.
>> (BTW,
>> >> > as a side note, container.script is not part of the build by
>> >> default).
>> >> >
>> >> > The other changes to make are to create a script
>> specialization of
>> >> > ComponentType in the loader and use ObjectFactory for creating
>> >> > instances.
>> >> >
>> >> >> Once the componentType and async changes
>> >> >> are done I/we can look at the next things to simplify and
>> once all
>> >> >> that
>> >> >> refactoring is done I'll look at what remains in the helper
>> >> >> package and see
>> >> >> if there are still things I think could be simplified.
>> >> >>
>> >> > If you can make those changes, we can take another pass over the
>> >> > helper classes and see what is left.
>> >> >
>> >> > Jim
>> >> >
>> >> >> ...ant
>> >> >
>> >> >
>> >> >
>> >>
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >> >
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by ant elder <an...@gmail.com>.
No go for it, that would be great!
...ant
On 10/31/06, Jim Marino <jm...@myromatours.com> wrote:
>
> So do you mind if I make the changes?
>
> Jim
>
> On Oct 31, 2006, at 1:02 AM, ant elder wrote:
>
> > No, tied up on M2 things, i doubt I'll have time for this till M2
> > is done.
> >
> > ...ant
> >
> > On 10/31/06, Jim Marino <jm...@myromatours.com> wrote:
> >>
> >> Any luck in making these changes?
> >>
> >> Jim
> >>
> >> On Oct 26, 2006, at 8:30 AM, Jim Marino wrote:
> >>
> >> >>
> >> >>
> >> >> As you don't like the easy SPI extension I've got rid of the easy
> >> >> extension
> >> >> dependency of the script container. I've moved the script
> >> >> container into
> >> >> trunk as it was going stale and i want to start using and
> >> >> improving it. It
> >> >> still uses some of the easy classes which are in a helper package
> >> >> now, i'll
> >> >> get rid of them as we clean things up. I saw you've done some core
> >> >> changes
> >> >> for the componentType problem, thanks, I'll go look at how to use
> >> >> that for
> >> >> this (and the other script containers) and change the code as
> >> >> appropriate.
> >> >> You said you'd take on getting the things like the async code into
> >> >> the spi
> >> >> to avoid all that duplicate code so would you like to go ahead and
> >> >> do that
> >> >> now? (or I can do it if you like).
> >> > O.K. I committed the changes. There is no need to handle message id
> >> > correlation as the wiring fabric (specifically
> >> > TargetInvokerExtension) does it automatically. You should be able
> >> > to delete AsyncMonitor and the async target invoker. You will also
> >> > need to change some of the signatures of the builders to pass in a
> >> > WorkContext and ExectionMonitor (these are autowired to
> >> > ComponentBuilderExtension). I made some basic changes the the
> >> > script container to pass tests but you will probably need to do
> >> > some more (limited) refactoring to get it fully operational. I
> >> > fixed the Groovy container so you can use that as an example. (BTW,
> >> > as a side note, container.script is not part of the build by
> >> default).
> >> >
> >> > The other changes to make are to create a script specialization of
> >> > ComponentType in the loader and use ObjectFactory for creating
> >> > instances.
> >> >
> >> >> Once the componentType and async changes
> >> >> are done I/we can look at the next things to simplify and once all
> >> >> that
> >> >> refactoring is done I'll look at what remains in the helper
> >> >> package and see
> >> >> if there are still things I think could be simplified.
> >> >>
> >> > If you can make those changes, we can take another pass over the
> >> > helper classes and see what is left.
> >> >
> >> > Jim
> >> >
> >> >> ...ant
> >> >
> >> >
> >> >
> >> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by Jim Marino <jm...@myromatours.com>.
So do you mind if I make the changes?
Jim
On Oct 31, 2006, at 1:02 AM, ant elder wrote:
> No, tied up on M2 things, i doubt I'll have time for this till M2
> is done.
>
> ...ant
>
> On 10/31/06, Jim Marino <jm...@myromatours.com> wrote:
>>
>> Any luck in making these changes?
>>
>> Jim
>>
>> On Oct 26, 2006, at 8:30 AM, Jim Marino wrote:
>>
>> >>
>> >>
>> >> As you don't like the easy SPI extension I've got rid of the easy
>> >> extension
>> >> dependency of the script container. I've moved the script
>> >> container into
>> >> trunk as it was going stale and i want to start using and
>> >> improving it. It
>> >> still uses some of the easy classes which are in a helper package
>> >> now, i'll
>> >> get rid of them as we clean things up. I saw you've done some core
>> >> changes
>> >> for the componentType problem, thanks, I'll go look at how to use
>> >> that for
>> >> this (and the other script containers) and change the code as
>> >> appropriate.
>> >> You said you'd take on getting the things like the async code into
>> >> the spi
>> >> to avoid all that duplicate code so would you like to go ahead and
>> >> do that
>> >> now? (or I can do it if you like).
>> > O.K. I committed the changes. There is no need to handle message id
>> > correlation as the wiring fabric (specifically
>> > TargetInvokerExtension) does it automatically. You should be able
>> > to delete AsyncMonitor and the async target invoker. You will also
>> > need to change some of the signatures of the builders to pass in a
>> > WorkContext and ExectionMonitor (these are autowired to
>> > ComponentBuilderExtension). I made some basic changes the the
>> > script container to pass tests but you will probably need to do
>> > some more (limited) refactoring to get it fully operational. I
>> > fixed the Groovy container so you can use that as an example. (BTW,
>> > as a side note, container.script is not part of the build by
>> default).
>> >
>> > The other changes to make are to create a script specialization of
>> > ComponentType in the loader and use ObjectFactory for creating
>> > instances.
>> >
>> >> Once the componentType and async changes
>> >> are done I/we can look at the next things to simplify and once all
>> >> that
>> >> refactoring is done I'll look at what remains in the helper
>> >> package and see
>> >> if there are still things I think could be simplified.
>> >>
>> > If you can make those changes, we can take another pass over the
>> > helper classes and see what is left.
>> >
>> > Jim
>> >
>> >> ...ant
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by ant elder <an...@gmail.com>.
No, tied up on M2 things, i doubt I'll have time for this till M2 is done.
...ant
On 10/31/06, Jim Marino <jm...@myromatours.com> wrote:
>
> Any luck in making these changes?
>
> Jim
>
> On Oct 26, 2006, at 8:30 AM, Jim Marino wrote:
>
> >>
> >>
> >> As you don't like the easy SPI extension I've got rid of the easy
> >> extension
> >> dependency of the script container. I've moved the script
> >> container into
> >> trunk as it was going stale and i want to start using and
> >> improving it. It
> >> still uses some of the easy classes which are in a helper package
> >> now, i'll
> >> get rid of them as we clean things up. I saw you've done some core
> >> changes
> >> for the componentType problem, thanks, I'll go look at how to use
> >> that for
> >> this (and the other script containers) and change the code as
> >> appropriate.
> >> You said you'd take on getting the things like the async code into
> >> the spi
> >> to avoid all that duplicate code so would you like to go ahead and
> >> do that
> >> now? (or I can do it if you like).
> > O.K. I committed the changes. There is no need to handle message id
> > correlation as the wiring fabric (specifically
> > TargetInvokerExtension) does it automatically. You should be able
> > to delete AsyncMonitor and the async target invoker. You will also
> > need to change some of the signatures of the builders to pass in a
> > WorkContext and ExectionMonitor (these are autowired to
> > ComponentBuilderExtension). I made some basic changes the the
> > script container to pass tests but you will probably need to do
> > some more (limited) refactoring to get it fully operational. I
> > fixed the Groovy container so you can use that as an example. (BTW,
> > as a side note, container.script is not part of the build by default).
> >
> > The other changes to make are to create a script specialization of
> > ComponentType in the loader and use ObjectFactory for creating
> > instances.
> >
> >> Once the componentType and async changes
> >> are done I/we can look at the next things to simplify and once all
> >> that
> >> refactoring is done I'll look at what remains in the helper
> >> package and see
> >> if there are still things I think could be simplified.
> >>
> > If you can make those changes, we can take another pass over the
> > helper classes and see what is left.
> >
> > Jim
> >
> >> ...ant
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by Jim Marino <jm...@myromatours.com>.
Any luck in making these changes?
Jim
On Oct 26, 2006, at 8:30 AM, Jim Marino wrote:
>>
>>
>> As you don't like the easy SPI extension I've got rid of the easy
>> extension
>> dependency of the script container. I've moved the script
>> container into
>> trunk as it was going stale and i want to start using and
>> improving it. It
>> still uses some of the easy classes which are in a helper package
>> now, i'll
>> get rid of them as we clean things up. I saw you've done some core
>> changes
>> for the componentType problem, thanks, I'll go look at how to use
>> that for
>> this (and the other script containers) and change the code as
>> appropriate.
>> You said you'd take on getting the things like the async code into
>> the spi
>> to avoid all that duplicate code so would you like to go ahead and
>> do that
>> now? (or I can do it if you like).
> O.K. I committed the changes. There is no need to handle message id
> correlation as the wiring fabric (specifically
> TargetInvokerExtension) does it automatically. You should be able
> to delete AsyncMonitor and the async target invoker. You will also
> need to change some of the signatures of the builders to pass in a
> WorkContext and ExectionMonitor (these are autowired to
> ComponentBuilderExtension). I made some basic changes the the
> script container to pass tests but you will probably need to do
> some more (limited) refactoring to get it fully operational. I
> fixed the Groovy container so you can use that as an example. (BTW,
> as a side note, container.script is not part of the build by default).
>
> The other changes to make are to create a script specialization of
> ComponentType in the loader and use ObjectFactory for creating
> instances.
>
>> Once the componentType and async changes
>> are done I/we can look at the next things to simplify and once all
>> that
>> refactoring is done I'll look at what remains in the helper
>> package and see
>> if there are still things I think could be simplified.
>>
> If you can make those changes, we can take another pass over the
> helper classes and see what is left.
>
> Jim
>
>> ...ant
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by Jim Marino <jm...@myromatours.com>.
>
>
> As you don't like the easy SPI extension I've got rid of the easy
> extension
> dependency of the script container. I've moved the script container
> into
> trunk as it was going stale and i want to start using and improving
> it. It
> still uses some of the easy classes which are in a helper package
> now, i'll
> get rid of them as we clean things up. I saw you've done some core
> changes
> for the componentType problem, thanks, I'll go look at how to use
> that for
> this (and the other script containers) and change the code as
> appropriate.
> You said you'd take on getting the things like the async code into
> the spi
> to avoid all that duplicate code so would you like to go ahead and
> do that
> now? (or I can do it if you like).
O.K. I committed the changes. There is no need to handle message id
correlation as the wiring fabric (specifically
TargetInvokerExtension) does it automatically. You should be able to
delete AsyncMonitor and the async target invoker. You will also need
to change some of the signatures of the builders to pass in a
WorkContext and ExectionMonitor (these are autowired to
ComponentBuilderExtension). I made some basic changes the the script
container to pass tests but you will probably need to do some more
(limited) refactoring to get it fully operational. I fixed the Groovy
container so you can use that as an example. (BTW, as a side note,
container.script is not part of the build by default).
The other changes to make are to create a script specialization of
ComponentType in the loader and use ObjectFactory for creating
instances.
> Once the componentType and async changes
> are done I/we can look at the next things to simplify and once all
> that
> refactoring is done I'll look at what remains in the helper package
> and see
> if there are still things I think could be simplified.
>
If you can make those changes, we can take another pass over the
helper classes and see what is left.
Jim
> ...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by ant elder <an...@gmail.com>.
On 10/10/06, Jim Marino <jm...@myromatours.com> wrote:
>
>
> On Oct 10, 2006, at 7:53 AM, ant elder wrote:
>
> > I'd be really happy for all those to become part of the core, but
> > I'm not
> > sure I see how all that remains will be a few three-line
> > statements. How
> > about I move this to a container-helper as I suggested before, we
> > pull all
> > the bits out and do the refactoring and before we cut M2 see whats
> > left and
> > if there really is nothing much left just doc it otherwise re-
> > evaluate then
> > what to do with what remains?
> 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. 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.
>
> Without this, we can't properly support scopes in side files so I'd
> like to get this fix in. In addition, I'd like to get duplicate code
> taken care of (AsyncTargetInvoker, EasyInstanceFactory). I'm willing
> to take this on and help out since I think this is important we clear
> up. Also, I still believe once we take care of these issues we
> probably won't need a separate extension library.
>
> One issue is this does affect the SPI and I think we need to assess
> the risk of these changes on getting the release out. If people are
> o.k. with me doing these changes, I'll jump in and make them. If it
> poses too much risk, I suggest we consider branching. Thoughts?
>
> Jim
As you don't like the easy SPI extension I've got rid of the easy extension
dependency of the script container. I've moved the script container into
trunk as it was going stale and i want to start using and improving it. It
still uses some of the easy classes which are in a helper package now, i'll
get rid of them as we clean things up. I saw you've done some core changes
for the componentType problem, thanks, I'll go look at how to use that for
this (and the other script containers) and change the code as appropriate.
You said you'd take on getting the things like the async code into the spi
to avoid all that duplicate code so would you like to go ahead and do that
now? (or I can do it if you like). Once the componentType and async changes
are done I/we can look at the next things to simplify and once all that
refactoring is done I'll look at what remains in the helper package and see
if there are still things I think could be simplified.
...ant
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by Jim Marino <jm...@myromatours.com>.
On Oct 10, 2006, at 7:53 AM, ant elder wrote:
> I'd be really happy for all those to become part of the core, but
> I'm not
> sure I see how all that remains will be a few three-line
> statements. How
> about I move this to a container-helper as I suggested before, we
> pull all
> the bits out and do the refactoring and before we cut M2 see whats
> left and
> if there really is nothing much left just doc it otherwise re-
> evaluate then
> what to do with what remains?
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. 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.
Without this, we can't properly support scopes in side files so I'd
like to get this fix in. In addition, I'd like to get duplicate code
taken care of (AsyncTargetInvoker, EasyInstanceFactory). I'm willing
to take this on and help out since I think this is important we clear
up. Also, I still believe once we take care of these issues we
probably won't need a separate extension library.
One issue is this does affect the SPI and I think we need to assess
the risk of these changes on getting the release out. If people are
o.k. with me doing these changes, I'll jump in and make them. If it
poses too much risk, I suggest we consider branching. Thoughts?
Jim
>
> ...ant
>
> On 10/10/06, Jim Marino <jm...@myromatours.com> wrote:
>>
>> 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 <jm...@myromatours.com> 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: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by ant elder <an...@gmail.com>.
I'd be really happy for all those to become part of the core, but I'm not
sure I see how all that remains will be a few three-line statements. How
about I move this to a container-helper as I suggested before, we pull all
the bits out and do the refactoring and before we cut M2 see whats left and
if there really is nothing much left just doc it otherwise re-evaluate then
what to do with what remains?
...ant
On 10/10/06, Jim Marino <jm...@myromatours.com> wrote:
>
> 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 <jm...@myromatours.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by Jim Marino <jm...@myromatours.com>.
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 <jm...@myromatours.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by Jim Marino <jm...@myromatours.com>.
On Oct 9, 2006, at 3:42 AM, ant elder wrote:
> On 10/7/06, Jim Marino <jm...@myromatours.com> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by ant elder <an...@gmail.com>.
On 10/7/06, Jim Marino <jm...@myromatours.com> 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. 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?
...ant
...ant
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by Jim Marino <jm...@myromatours.com>.
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
> Jim
>
>> ...ant
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Refactoring commonality amongst Script containers in Java SCA
Posted by Jim Marino <jm...@myromatours.com>.
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".
Jim
> ...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org