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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
