RE: WorkManager in JavaComponentBuilder
Ta
-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 18 July 2006 07:03
To: tuscany-dev@ws.apache.org
Subject: Re: WorkManager in JavaComponentBuilder
I've applied the patch in 422953. Thanks Meeraj!
Jim
On Jul 17, 2006, at 2:25 AM, Meeraj Kunnumpurath wrote:
> 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:
>>>> Sent: Saturday, July 15, 2006 2:59 PM
>>>> Subject: Re: WorkManager in JavaComponentBuilder
>>>>
>>>>
>>>>&
Re: WorkManager in JavaComponentBuilder
I've applied the patch in 422953. Thanks Meeraj!
Jim
On Jul 17, 2006, at 2:25 AM, Meeraj Kunnumpurath wrote:
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:
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,
Re: WorkManager in JavaComponentBuilder
Hmm, yes I agree in abstracting out to WorkScheduler. But I still don't seem
to have all the pieces of the puzzle. I assume I still need to autowire (now
a WorkScheduler) to JavaComponentBuilder? And that I still need to modify
system.scdl (now with an instance of WorkScheduler, e.g.,
Jsr237WorkScheduler). I still don't get it to work.
- Original Message -
From: "Meeraj Kunnumpurath" <[EMAIL PROTECTED]>
To:
Sent: Monday, July 17, 2006 11:48 AM
Subject: RE: WorkManager in JavaComponentBuilder
Ignacio,
I think, the JavaComponentBuilder should be using an implementation of
the org.apache.tuscany.spi.services.work.WorkScheduler interface, rather
than the commonj WorkManager directly. This will allow us to switch to a
JCA, commonj or any other implementation that is available based on the
host in which tuscany runs.
For example a possible dependency hierarchy would be
JavaComponentBuilder -> Jsr237WorkScheduler -> ThreadPoolWorkManager
(This is using a commonj work scheduler using our own thread pool based
commonj work manager implementation. If the host system uses Geronimo
JCA work manager, this could be JavaComponentBuilder -> JcaWorkScheduler
-> GeronimoWorkManager. The gist is for the work scheduler to abstract
the work management implementation mechanism.
hth
Meeraj
-Original Message-
From: Ignacio Silva-Lepe [mailto:[EMAIL PROTECTED]
Sent: 17 July 2006 16:37
To: Tuscany Dev
Subject: Re: WorkManager in JavaComponentBuilder
I'm a bit confused by this. I added:
to system.scdl as per Jim's directions, did a mvn clean and mvn of sca
and nothing seems to be happening (I even do a mvn clean and mvn of the
top to no avail). Not sure whether or where I should be adding the code
below by Meeraj. Here's where I autowire into JavaComponentBuilder:
@Autowire
public void setWorkManager(WorkManager workManager) {
this.workManager = workManager;
}
Any ideas?
Thanks
- Original Message -
From: "Meeraj Kunnumpurath" <[EMAIL PROTECTED]>
To:
Sent: Saturday, July 15, 2006 4:45 PM
Subject: RE: WorkManager in JavaComponentBuilder
The injection sequence should be something like,
WorkManager workManager = new ThreadPoolWorkManager(10);
WorkScheduler workScheuler = new Jsr237WorkScheduler(workManager);
AsyncTargetInvoker invoker = new AsyncTargetInvoker(workScheuler); //
Sorry I don't know the signature for the constructor
As Jim rightly mentioned you need the commonj classes.
Ta
Meeraj
-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 21:42
To: tuscany-dev@ws.apache.org
Subject: RE: WorkManager in JavaComponentBuilder
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: WorkManager in JavaComponentBuilder
Yep will do. Give me a few hours to catch up on some stuff and I'll
check it in. Thanks!
Jim
On Jul 17, 2006, at 2:25 AM, Meeraj Kunnumpurath wrote:
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:
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
--
-
-
RE: WorkManager in JavaComponentBuilder
Ignacio,
I think, the JavaComponentBuilder should be using an implementation of
the org.apache.tuscany.spi.services.work.WorkScheduler interface, rather
than the commonj WorkManager directly. This will allow us to switch to a
JCA, commonj or any other implementation that is available based on the
host in which tuscany runs.
For example a possible dependency hierarchy would be
JavaComponentBuilder -> Jsr237WorkScheduler -> ThreadPoolWorkManager
(This is using a commonj work scheduler using our own thread pool based
commonj work manager implementation. If the host system uses Geronimo
JCA work manager, this could be JavaComponentBuilder -> JcaWorkScheduler
-> GeronimoWorkManager. The gist is for the work scheduler to abstract
the work management implementation mechanism.
hth
Meeraj
-Original Message-
From: Ignacio Silva-Lepe [mailto:[EMAIL PROTECTED]
Sent: 17 July 2006 16:37
To: Tuscany Dev
Subject: Re: WorkManager in JavaComponentBuilder
I'm a bit confused by this. I added:
to system.scdl as per Jim's directions, did a mvn clean and mvn of sca
and nothing seems to be happening (I even do a mvn clean and mvn of the
top to no avail). Not sure whether or where I should be adding the code
below by Meeraj. Here's where I autowire into JavaComponentBuilder:
@Autowire
public void setWorkManager(WorkManager workManager) {
this.workManager = workManager;
}
Any ideas?
Thanks
- Original Message -
From: "Meeraj Kunnumpurath" <[EMAIL PROTECTED]>
To:
Sent: Saturday, July 15, 2006 4:45 PM
Subject: RE: WorkManager in JavaComponentBuilder
The injection sequence should be something like,
WorkManager workManager = new ThreadPoolWorkManager(10);
WorkScheduler workScheuler = new Jsr237WorkScheduler(workManager);
AsyncTargetInvoker invoker = new AsyncTargetInvoker(workScheuler); //
Sorry I don't know the signature for the constructor
As Jim rightly mentioned you need the commonj classes.
Ta
Meeraj
-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 21:42
To: tuscany-dev@ws.apache.org
Subject: RE: WorkManager in JavaComponentBuilder
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
-
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]
Re: WorkManager in JavaComponentBuilder
I'm a bit confused by this. I added:
to system.scdl as per Jim's directions, did a mvn clean and mvn of sca and
nothing seems to be happening (I even do a mvn clean and mvn of the top to
no avail). Not sure whether or where I should be adding the code below by
Meeraj. Here's where I autowire into JavaComponentBuilder:
@Autowire
public void setWorkManager(WorkManager workManager) {
this.workManager = workManager;
}
Any ideas?
Thanks
- Original Message -
From: "Meeraj Kunnumpurath" <[EMAIL PROTECTED]>
To:
Sent: Saturday, July 15, 2006 4:45 PM
Subject: RE: WorkManager in JavaComponentBuilder
The injection sequence should be something like,
WorkManager workManager = new ThreadPoolWorkManager(10);
WorkScheduler workScheuler = new Jsr237WorkScheduler(workManager);
AsyncTargetInvoker invoker = new AsyncTargetInvoker(workScheuler); //
Sorry I don't know the signature for the constructor
As Jim rightly mentioned you need the commonj classes.
Ta
Meeraj
-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 21:42
To: tuscany-dev@ws.apache.org
Subject: RE: WorkManager in JavaComponentBuilder
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: WorkManager in JavaComponentBuilder
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:
>>> 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
>>>>
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:
>>> 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
>>>&
Re: WorkManager in JavaComponentBuilder
On Jul 15, 2006, at 1:45 PM, Meeraj Kunnumpurath wrote:
The injection sequence should be something like,
WorkManager workManager = new ThreadPoolWorkManager(10);
To have the runtime handler the above, we could do:
@Constructor("poolSize")
public ThreadPoolWorkManager(@Property int threadPoolSize) {
executor = Executors.newFixedThreadPool(threadPoolSize);
}
Then in the system scdl we would just configure a property named
"poolSize". This "should" work but I'm not sure if we support ints in
the config load phase. I need to step out for a while but I'll be
back later on if someone want to give this a try.
Jim
WorkScheduler workScheuler = new Jsr237WorkScheduler(workManager);
AsyncTargetInvoker invoker = new AsyncTargetInvoker(workScheuler); //
Sorry I don't know the signature for the constructor
As Jim rightly mentioned you need the commonj classes.
Ta
Meeraj
-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 21:42
To: tuscany-dev@ws.apache.org
Subject: RE: WorkManager in JavaComponentBuilder
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:
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 co
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:
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
RE: WorkManager in JavaComponentBuilder
The injection sequence should be something like, WorkManager workManager = new ThreadPoolWorkManager(10); WorkScheduler workScheuler = new Jsr237WorkScheduler(workManager); AsyncTargetInvoker invoker = new AsyncTargetInvoker(workScheuler); // Sorry I don't know the signature for the constructor As Jim rightly mentioned you need the commonj classes. Ta Meeraj -Original Message- From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] Sent: 15 July 2006 21:42 To: tuscany-dev@ws.apache.org Subject: RE: WorkManager in JavaComponentBuilder 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: >> 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 * Thi
RE: WorkManager in JavaComponentBuilder
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: >> 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]
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: 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]
Re: WorkManager in JavaComponentBuilder
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: 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]
Re: WorkManager in JavaComponentBuilder
All I do is to run mvn from chianti/sca, after adding the autowire to JavaComponentBuilder - Original Message - From: "Jim Marino" <[EMAIL PROTECTED]> To: 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]
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]
