Jim,
Could you pls have a look and apply the attached patch.
Ta
Meeraj
-----Original Message-----
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 22:50
To: tuscany-dev@ws.apache.org
Subject: RE: WorkManager in JavaComponentBuilder
Jim,
I think it's ok, if I understand it right.
I think the Tuscany runtime components should only know about the
WorkScheduler abstraction. We will configure a Jsr237 or JCA work
scheduler based on the host environment and configure it with an
appropriate work manager provided by the host environment. If no work
managers are available, by default we will use the Jsr237WorkScheduler
configured with the ThreadPoolWorkManager.
BTW, If you are working on this tonight (or today for you), could you
pls remove the synchronized keyword from the ThreadPoolWorkManager
callback methods. The underlying collection I use for keeping track of
the listeners is thread-safe.
Ta
Meeraj
-----Original Message-----
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 21:56
To: tuscany-dev@ws.apache.org
Subject: Re: WorkManager in JavaComponentBuilder
Thanks Meeraj,
I forgot about the abstraction conversation about a week back...So I'm
just thinking about how to get this into a system service. What do you
think of this:
1. Add @Autowire to the Jsr237WorkScheduler constructor as in
@Constructor("workManager")
public Jsr237WorkScheduler(@Autowire WorkManager jsr237WorkManager) {
//...
}
2. Configure ThreadPoolWorkManager as a system service.
The runtime will autowire them together.
3. Have JavaComponentBuilder (or better, ComponentBuilderExtension) have
an autowire to WorkScheduler
For Step 1, we need to add the @Constructor tag for now - I need to make
a few changes to the annotation processing to allow just specifying
@Autowire on the param.
Jim
On Jul 15, 2006, at 1:41 PM, Meeraj Kunnumpurath wrote:
> Jim/Ignacio,
>
> There is abstract called WorkScheduler in the SPI, that hides whether
> you are using a JCA or commonj work manager. The two implementations
> are JcaWorkScheduler and Jsr237WorkScheduler. The Jsr237WorkScheduler
> can be injected with a ThreadPoolWorkManager. This way, depending on
> the host environment we can inject a work manager provided by the
> environment.
>
> Ta
> Meeraj
>
> -----Original Message-----
> From: Jim Marino [mailto:[EMAIL PROTECTED]
> Sent: 15 July 2006 21:38
> To: tuscany-dev@ws.apache.org
> Subject: Re: WorkManager in JavaComponentBuilder
>
> Forgot to mention (you may already know this):
>
> You can use Meeraj's work manager, ThreadPoolWorkManager, as the
> system service.
>
> Jim
>
>
> On Jul 15, 2006, at 1:34 PM, Jim Marino wrote:
>
>> Ignacio,
>>
>> Can you check the package name of WorkManager? It should be
>> commonj.work.WorkManager as opposed to
>> javax.resource.spi.work.WorkManager? Using comonj on my machine
>> compiles and runs.
>>
>> Once you get past that, you'll need to have the work manager system
>> service deployed as part of the runtime. Could you add this to the
>> system.scdl in the launcher project under ../main/resource/META-INF/
>> tuscany? Once you have changed JavaComponentBuilder to add the
>> autowire, the WorkManager should be picked up.
>>
>> If you could submit the changes as a patch, I'll add them to the
>> repo.
>>
>> Thanks,
>> Jim
>>
>>
>>
>> On Jul 15, 2006, at 12:43 PM, Ignacio Silva-Lepe wrote:
>>
>>> All I do is to run mvn from chianti/sca, after adding the autowire
>>> to
>
>>> JavaComponentBuilder
>>> ----- Original Message ----- From: "Jim Marino"
>>> <[EMAIL PROTECTED]>
>>> To: <tuscany-dev@ws.apache.org>
>>> Sent: Saturday, July 15, 2006 2:59 PM
>>> Subject: Re: WorkManager in JavaComponentBuilder
>>>
>>>
>>>>
>>>> On Jul 15, 2006, at 11:45 AM, Ignacio Silva-Lepe wrote:
>>>>
>>>>> To allow JavaAtomicComponent to create a new
>>>>> AsyncJavaTargetInvoker, it needs to supply the new target invoker
>>>>> with a work manager. My first try (which may not be the
>>>>> appropriate
>
>>>>> thing to do) was to get a work manager autowired into
>>>>> JavaComponentBuilder, which then passes it to JavaAtomicComponent.
>>>> That is how I would do it.
>>>>
>>>>> However when I do this I get a NoClassDefFoundError when the build
>
>>>>> tries to run the samples (local.wire, local.wire.cdi, calculator).
>
>>>>> I could add the dependency to each sample's pom.xml, which seems
>>>>> to
>
>>>>> eliminate the error sample by sample. Or I could add the
>>>>> dependency to the entire samples directory's pom.xml, which at
>>>>> the
>
>>>>> moment has no dependencies. Or I could just be doing the wrong
>>>>> thing and I should supply the work manager in some other way.
>>>>> Thoughts?
>>>>
>>>> The work manager dependency shouldn't be surfaced to the samples
>>>> since it is an implementation detail of the runtime. How are you
>>>> executing the samples? I'm wondering if the appropriate jars are
>>>> not
>
>>>> being put on the classpath?
>>>>
>>>> Jim
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> -
>>>> -
>>>> 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]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> This message has been checked for all email viruses by MessageLabs.
>
>
>
>
> *****************************************************
>
> You can find us at www.voca.com
>
> *****************************************************
> This communication is confidential and intended for the exclusive use
> of the addressee only. You should not disclose its contents to any
> other person.
> If you are not the intended recipient please notify the sender named
> above immediately.
>
> Registered in England, No 1023742,
> Registered Office: Voca Limited
> Drake House, Three Rivers Court,
> Homestead Road, Rickmansworth,
> Hertfordshire, WD3 1FX
>
>
> This message has been checked for all email viruses by MessageLabs.
>
> ---------------------------------------------------------------------
> 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]
This message has been checked for all email viruses by MessageLabs.
This message has been checked for all email viruses by MessageLabs.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message has been checked for all email viruses by MessageLabs.
This message has been checked for all email viruses by MessageLabs.Index: ThreadPoolWorkManager.java
===================================================================
--- ThreadPoolWorkManager.java (revision 422656)
+++ ThreadPoolWorkManager.java (working copy)
@@ -130,7 +130,7 @@
/*
* Method to indicate a work start.
*/
- private synchronized void workStarted(final DefaultWorkItem workItem,
final Work work) {
+ private void workStarted(final DefaultWorkItem workItem, final Work work) {
WorkListener listener = workItems.get(workItem);
if (listener != null) {
workItem.setStatus(WorkEvent.WORK_STARTED);
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
