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: <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.
<patch.txt>
---------------------------------------------------------------------
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]
