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
RE: Subject: [VOTE] promote Chianti revolution to main trunk
Rick, I have held back from this discussion as I am not as actively involved with Tuscany as most of you, though I do keep a keen eye on what is happening. There are a lot of us who are watching the evolution of SCA with a great deal of interest and especially Tuscany, with it being the only significant OSS effort going on in realising an SCA implementation. I fully back what you have mentioned in your email. Unfortunately those who have been involved actively in the discussion are the ones who were the most active in contributing to the M1 release and who can play a significant role in taking SCA forward. I think everyone needs to work together on a single source tree to implement the scenarios that have been agreed for the roadmap. Ta Meeraj -Original Message- From: Rick [mailto:[EMAIL PROTECTED] Sent: 14 July 2006 17:33 To: tuscdev Subject: Subject: [VOTE] promote Chianti revolution to main trunk Hello fellow committers, Last week I was on vacation and felt for sure that when I got back I'd see a unified direction for the Java Tuscany SCA code base. I've held back discussing any of this for a while because I didn't want to add any more fuel to the fire. I now feel I have to speak up: to be honest about this, I was really disheartened that it has came to pass that we as a community so soon moved to having to fall back on The Rules for Revolutionaries. While this seems to be acceptable path for a Apache project, I don't feel that makes right for Tuscany. I think there is a fundamental difference in the stages of projects that followed that route and the stage that Tuscany currently is at and survived as a project.. Many of these projects were fairly mature, they had a much larger pool of core developers to draw on both sides, they had a much larger user base, and for the most part they were based on mature specifications. I agree that in some stages in the life time of a project a revolution is desperately needed to bring about innovation. I don't think this is the case for Tuscany, I honestly don't think Tuscany is at the stage where it can quite honestly survive such a split and still gain traction in gaining commiters and users. I'd really like to request that we as a community once again focus not as much on the technology which both branches have merit, but consider the Tuscany project as a whole will be better served if we make a decision on which will be the future today. Thus I'm requesting as has been asked before if we can't take a vote on one and once again move forward together as one. Specifcly: I would like to propose that we make the chanti tree the main trunk and turn the current trunk into a maintainance branch. The chianti code would be moved to tuscany/java and would be the main development tree moving forward; the existing trunk would be moved to branches/M1. Please vote if you agree with this proposal - as a policy vote, at least 3 +1s and more +1's than -1's would be needed to do this This is my +1 for this. Thanks Rick - 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: Component start order
Are you thinking of something that may cause complications with this approach? No, dependencies was the first the first thing that popped into my mind when Jeremy mentioned sort order. As you suggested, dependencies will have to override sort order. -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 14 July 2006 21:18 To: tuscany-dev@ws.apache.org Subject: Re: Component start order On Jul 14, 2006, at 1:13 PM, Meeraj Kunnumpurath wrote: First, eagerness is associated with the scope, not an initializer callback, IMO. Jim, would this mean there would be another annotation for initialization callbacks? I think it would just be @Init, but with no attributes Also, what are the implications of start order on component dependencies and wirings? That's a good question. I think dependencies override start order such that when we initialize a component, we perform a depth-first traversal of dependencies, instantiating them regardless of start level. Are you thinking of something that may cause complications with this approach? Jim Many thanks Meeraj -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 14 July 2006 21:05 To: tuscany-dev@ws.apache.org Subject: Re: Component start order On Jul 14, 2006, at 12:43 PM, Jeremy Boynes wrote: The Java implementation model allows components to designate that they are eager init which means that they will be initialized when the composite they are in is started rather than on first use. One problem that I ran into with the extension stuff is that the specification does not say or even allow a user to say in which order the components will be started. One option would be to follow a lexical convention and say that components will be started in the order that they appear in the SCDL. I have a few reservations about this: * users may have other criteria for laying out the file (for example grouping components together) * this can be confusing in the presence of include elements - users may want to group components together in an include that would fit in different places in the start order This can also be dangerous if a tool doesn't preserve the exact order or someone inadvertently changes something. Instead I'd like to propose we support an init-level indicator like the run level from Unix systems. Components would be started in ascending order of the init level they provided. This could be done as an attribute on the component element, something like: component name=start2nd initLevel=20 ... component name=start1st initLevel=10 ... This would also allow us to eagerly initialize components without having to use an @Init annotation. I'm wondering if specifying the start level in SCDL is crossing semantics with eager init... As background, one thing I was planning on proposing to the spec was moving eager init off of @Init and onto @Scope for couple of reasons. First, eagerness is associated with the scope, not an initializer callback, IMO. The second reason is that it avoids a problem I've been noticing lately where I want to eager init something but I don't need an initializer callback, and I am forced to add an empty method just to get the component to be instantiated eagerly. Couple that with constructor-based injection, and I think it is better to but things on @Scope. What if we said eager init is a component type concept and is true or false (specified on @Scope)? Then, run level is the SCDL configuration of eager init. So, a component would be eager initialized based on the component type info and would be done so in the order specified by the SCDL runlevel attribute. If no runlevel attribute were present, we would default it to some level (maybe 100). Also, I think we should have a default runlevel attribute on composites as well that applies to all children. This may be implicit in the above since composites are just components. Jim Seem reasonable? -- Jeremy - 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
Chianti - build error
Hi, I have been trying in vain to build chianti for the last couple of days :-( it consistently fails at the same place. I tried clearing my sandbox and maven repo and trying to download the dependency on which it is failing manually, no luck. I would appreciate it someone had any useful pointer, [INFO] [jar:jar] [INFO] Building jar: C:\tuscany\sandbox\chianti\sca\databinding\databinding-castor\target\dat abinding-castor-1.0-chianti-SNAPSHOT.jar [INFO] [install:install] [INFO] Installing C:\tuscany\sandbox\chianti\sca\databinding\databinding-castor\target\dat abinding-castor-1.0-chianti-SNAPSHOT.jar to c:\tuscany\maven-repo\org\apache\tuscany\databin ding\databinding-castor\1.0-chianti-SNAPSHOT\databinding-castor-1.0-chia nti-SNAPSHOT.jar [INFO] [INFO] Building Tuscany JAXB Data Binding [INFO]task-segment: [install] [INFO] Downloading: https://maven-repository.dev.java.net/repository/com.sun.tools.xjc.maven 2/poms/maven-jaxb-plugin-1.0.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: com.sun.tools.xjc.maven2:maven-jaxb-plugin Reason: Error getting POM for 'com.sun.tools.xjc.maven2:maven-jaxb-plugin' from the repository: Error transferring file com.sun.tools.xjc.maven2:maven-jaxb-plugin:pom:1.0 from the specified remote repositories: ibiblio (http://www.ibiblio.org/maven2), central (http://repo1.maven.org/maven2), java.net (https://maven-repository.dev.java.net/repository) Ta Meeraj * 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: Chianti, was: Rules for Revolutionaries [was: M2]
Jeremy, Sorry, I might have missed some previous emails. I am getting the following error consistently with the build, [INFO] [INFO] Building Tuscany JAXB Data Binding [INFO]task-segment: [install] [INFO] Downloading: https://maven-repository.dev.java.net/repository/com.sun.tools.xjc.maven 2/poms/maven-jaxb-plugin-1.0.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: com.sun.tools.xjc.maven2:maven-jaxb-plugin Reason: Error getting POM for 'com.sun.tools.xjc.maven2:maven-jaxb-plugin' from the repository: Error transferring file com.sun.tools.xjc.maven2:maven-jaxb-plugin:pom:1.0 from the specified remote repositories: ibiblio (http://www.ibiblio.org/maven2), central (http://repo1.maven.org/maven2), java.net (https://maven-repository.dev.java.net/repository) Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 11 July 2006 23:33 To: tuscany-dev@ws.apache.org Subject: Re: Chianti, was: Rules for Revolutionaries [was: M2] On Jul 11, 2006, at 2:27 PM, Jeremy Boynes wrote: On Jul 10, 2006, at 9:33 AM, Sam Ruby wrote: One thing that is decidedly NOT OK is to include a version number in the name, as it causes friction. Hence, I'd suggest that core2 immediately get renamed to something that neither reflects the term core or the number 2. To resolve this I propose that we move the code from my sandbox to its own location based on a codename. Once I get the build issues resolved, I plan to move the tree from sandbox/jboynes to sandbox/chianti and will rename the core2 module back to core This should now be complete - if you cd to sandbox and svn up chianti you should get a buildable tree. I changed the artifact versions to 1.0-chianti-SNAPSHOT - the 1.0 is only there to keep maven happy by starting the version with a number. -- Jeremy - 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: Chianti, was: Rules for Revolutionaries [was: M2]
No luck, Jeremy. I don't even have com/sun/tools under my Maven repo. I am going to try manually downloading those files. -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 12 July 2006 02:06 To: tuscany-dev@ws.apache.org Subject: Re: Chianti, was: Rules for Revolutionaries [was: M2] On Jul 11, 2006, at 5:30 PM, Meeraj Kunnumpurath wrote: Thanks Raymond. I tried the build around four or five times. I shall try a few more times. I wiped the Sun plugin from my repo $ rm -rf ~/.m2/repository/com/sun/tools and tried rebuilding the databinding-jaxb module and everything worked fine (it was a little slow downloading). It may just have been a hiccup on the java.net repo - are you having any better luck now? -- Jeremy - 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: Chianti, was: Rules for Revolutionaries [was: M2]
Jeremy, I can't find the required version of the plugin on the java.net repo? Is it version 1.0 or 2.0EA3? Ta Meeraj -Original Message- From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] Sent: 12 July 2006 02:13 To: tuscany-dev@ws.apache.org Subject: RE: Chianti, was: Rules for Revolutionaries [was: M2] No luck, Jeremy. I don't even have com/sun/tools under my Maven repo. I am going to try manually downloading those files. -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 12 July 2006 02:06 To: tuscany-dev@ws.apache.org Subject: Re: Chianti, was: Rules for Revolutionaries [was: M2] On Jul 11, 2006, at 5:30 PM, Meeraj Kunnumpurath wrote: Thanks Raymond. I tried the build around four or five times. I shall try a few more times. I wiped the Sun plugin from my repo $ rm -rf ~/.m2/repository/com/sun/tools and tried rebuilding the databinding-jaxb module and everything worked fine (it was a little slow downloading). It may just have been a hiccup on the java.net repo - are you having any better luck now? -- Jeremy - 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] 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]
RE: Host API, was: Support for callbacks
Jeremy, This maps on quite well with some of the other implementations I have seen. For example, in Mule they have the concept of connectors that provide transport level abstractions which are decoupled from the UMOs (a.k.a services). Mule uses its own message routing mechanism to associate a connector to a service (I assume in the SCA world this would be a binding to a reference). I think this is also very similar in the JBI world as well, where the NMR decouples the binding components from the service engine components. Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 10 July 2006 16:15 To: tuscany-dev@ws.apache.org Subject: Host API, was: Support for callbacks On Jul 10, 2006, at 7:53 AM, Jim Marino wrote: On Jul 10, 2006, at 7:40 AM, Jeremy Boynes wrote: On Jul 10, 2006, at 7:19 AM, Jim Marino wrote: 2. We need to get the host API supporting callbacks. The reference would use the host API to register itself as a listener with a binding as opposed to talking directly with the binding. This will allow us to decouple the callback infrastructure from particular bindings. Jeremy may have some thoughts on this. I would have though that the reference would register with the binding rather than the host. After all the reference is bound on the outbound side so is coupled to the binding at that point; wouldn't the inbound side just be the reverse? Wouldn't the reference (composite reference) use the host api to register with the binding transport? I may not have worded things clear enough. This way we separate the protocol binding and callback mechanisms from the particular transport (e.g. Jetty)? In my mind, the host API is a low-level API that allows Tuscany services to connect to physical things in the host environment; examples for physical things would be sockets or things layered on top of sockets (such as servlets, mail-lets, JMS message listeners), threads, timers, etc. The host API would be bridged to a managed environment such as a J2EE server or could be implemented by other low-level Tuscany services such as a Jetty transport or ActiveMQ message broker to provide a standalone environment. Think of it as a host abstraction layer. Things that represent Tuscany or SCA services would sit at a level above that. So, for example, a HTTP transport would sit at this level and would use the host API to register for inbound HTTP requests or to make outbound HTTP requests; a SOAP protocol handler would sit on top of the HTTP transport, a WebService binding would sit on top of a SOAP protocol handler, and so forth. This is a system connection level. The associated between a reference and a binding is a Tuscany concept rather than a physical one so in my mind that would be a connection at the system level rather than at the host level. We still get the decoupling from the physical side (e.g. from Jetty vs. Tomcat) but it's through the stack that the binding is using rather than at the host level. This also means that the reference would be abstracted from the details of the binding (e.g. which SOAP stack, which databinding, which transport). -- Jeremy - 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]
[jira] Updated: (TUSCANY-527) First cut of the work scheduler implementation
[ http://issues.apache.org/jira/browse/TUSCANY-527?page=all ] Meeraj Kunnumpurath updated TUSCANY-527: Attachment: jsr237.jar Jeremy, I can't find it on the Maven repo. I have attached the one I used. This was built from the source files I got from one of the vendors around a year ago. Ta Meeraj First cut of the work scheduler implementation -- Key: TUSCANY-527 URL: http://issues.apache.org/jira/browse/TUSCANY-527 Project: Tuscany Type: New Feature Components: Java SCA Core Reporter: Meeraj Kunnumpurath Assignee: Jeremy Boynes Priority: Trivial Attachments: jsr237.jar, workmanager.jar First-cut of the work scheduler implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Test
Apologies, this is a test message. For some reason, the mail server seems to be blocking my messages as spam. * 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.
[jira] Created: (TUSCANY-527) First cut of the work scheduler implementation
First cut of the work scheduler implementation -- Key: TUSCANY-527 URL: http://issues.apache.org/jira/browse/TUSCANY-527 Project: Tuscany Type: New Feature Components: Java SCA Core Reporter: Meeraj Kunnumpurath Priority: Trivial Attachments: workmanager.jar First-cut of the work scheduler implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-527) First cut of the work scheduler implementation
[ http://issues.apache.org/jira/browse/TUSCANY-527?page=all ] Meeraj Kunnumpurath updated TUSCANY-527: Attachment: workmanager.jar First cut of the work scheduler implementation -- Key: TUSCANY-527 URL: http://issues.apache.org/jira/browse/TUSCANY-527 Project: Tuscany Type: New Feature Components: Java SCA Core Reporter: Meeraj Kunnumpurath Priority: Trivial Attachments: workmanager.jar First-cut of the work scheduler implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Support for callbacks
Jim, Are you ok for me to start looking at the work manager implementation? Once I get a better understanding around the requirements of callbacks, I can try to give some input on that as well. Ta Meeraj -Original Message- From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 16:39 To: tuscany-dev@ws.apache.org Subject: RE: Support for callbacks I have got an implementation based on Doug Lea's concurrent utilities (JDK 1.4), I think this can be ported to use Java 5 concurrent libraries. If you don't mind, I can start looking at this. -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 16:12 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks On Jul 6, 2006, at 8:04 AM, Meeraj Kunnumpurath wrote: Good point. I think a similar mechanism may be o.k. as long as we clean up properly when the request ends or the thread is reclaimed (e.g. in case of failure where the callback never hapens). Perhaps we could use the WorkArea API for this? Were you thinking of something in particular? Have you looked at any commonj work manager (JSR-237) implementations? Yep that's what I was thinking of with the WorkArea stuff. Right now we reused Geronimo's WorkManager impl for the async dispatching but it drags in a lot of dependencies for what it does. I was thinking we could just write a thin implementation of WorkManager using the JDK 5 concurrency libraries and eliminate the dependencies. When we run in a managed environment, we could swap implementations since the WorkManager is set up as a system service. I haven't had time to look at doing this so if anyone is interested (as well as joining in on the callback work), it would be great. Jim M -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 16:01 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks Hi Ignacio, Sorry about the delay...Comments inline. I've also added some scenarios to the wiki so feel free to add your thoughts to them. Jim On Jul 5, 2006, at 2:07 PM, Ignacio Silva-Lepe wrote: Hi Jim, Sorry about the disconnect, I was out Monday and yesterday. I'll be sure to attend the IRC chat tomorrow. In the meantime, some more quick comments. - Original Message - snip/ If I understand correctly, would a system service transport use a low level communication mechanism, like a socket for instance? This does not seem like an appropriate approach for a local scenario, Right, for the local scenario, I was thinking the callback instance would be put on the thread local context and the proxy would access it from there as opposed to going out over a socket and back in through a listener. Basically, it would be an optimization of the remote case. I think we can further optimize things depending on scopes, e.g. if the callback scope is module, we could possibly avoid threadlocal storage and have the proxy hold on to an instance directly. Pointing at the callback instance directly from the proxy would eliminate invocation chains and the ability to add interceptors to them, wouldn't it? Yea the proxy should probably point back to the Component and not the instance directly unless there is an optimized case where no interceptors were present. Once the proxy points to Component, it can call getInboundWire(String serviceName) which will return the invocation chain that will dispatch to the correct instance. In the case of an AtomicComponent, when the end of the chain is reached, the target invoker will delegate to the scope container which will return the right instance. Also, I'm not sure using a thread local in the core is a good idea if an intention is to allow the core to be embeddable in, for instance, a managed environment, as thread local does not necessarily mix well with thread pools. Good point. I think a similar mechanism may be o.k. as long as we clean up properly when the request ends or the thread is reclaimed (e.g. in case of failure where the callback never hapens). Perhaps we could use the WorkArea API for this? Were you thinking of something in particular? Jim snip/ - 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
RE: Support for callbacks
Ok, Jeremy. Ta -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 07 July 2006 14:33 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks On Jul 7, 2006, at 2:45 AM, Meeraj Kunnumpurath wrote: Jim, Are you ok for me to start looking at the work manager implementation? Once I get a better understanding around the requirements of callbacks, I can try to give some input on that as well. Meeraj, please do, this would be a good thing to have. -- Jeremy - 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: Support for callbacks
Ignacio, I have a couple of questions. Sorry, I may be talking rubbish without any context. I think for local callbacks to happen asynchronously a work manager based approach may be appropriate. However, on other scenarios, wouldn't the callback implementation be specific to the binding. For example, with a JMS binding, it could be something using replyTo and correlation id headers. I think the key would be to define the right abstractions for callbacks in general and have binding specific realisations. Also, we may find other use cases for using a work manager for deferred executions. Do we have any view on how the runtime can use a work manager from a managed environment when Tuscany is run in a managed environment. I think app servers that support work managers, may be making them available through the JNDI namespace or something else. I would appreciate if you could point me to any more info on the callback discussion, if available, in addition to the email thread that has been running. Many thanks Meeraj -Original Message- From: Ignacio Silva-Lepe [mailto:[EMAIL PROTECTED] Sent: 07 July 2006 14:57 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks I too think that having a work manager implementation that minimizes dependencies (e.g., Geronimo's) is a useful thing to have. Wrt using a work manager in the support for callbacks, we should just make sure that we are ok with the overall architecture first. At his point, it looks like the local case could use a work manager, but not necessarily the remote case. I am working on a couple of scenarios (of the technology kind, as Jim refers to them) that illustrate the main steps so that we can get a better idea of how the architecture can fit in support for callbacks in general. - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, July 07, 2006 9:32 AM Subject: Re: Support for callbacks On Jul 7, 2006, at 2:45 AM, Meeraj Kunnumpurath wrote: Jim, Are you ok for me to start looking at the work manager implementation? Once I get a better understanding around the requirements of callbacks, I can try to give some input on that as well. Meeraj, please do, this would be a good thing to have. -- Jeremy - 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: Support for callbacks
ok -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 07 July 2006 15:46 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks On Jul 7, 2006, at 7:37 AM, Meeraj Kunnumpurath wrote: Jeremy, Should this go into sca/core. Also, have you got any suggestions on what package this should go in? I would suggest putting the API in o.a.t.spi.services.work and the impl in o.a.t.core.services.work Work for you? -- Jeremy - 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: Support for callbacks
JSR-237 was not part of 1.4 True, I don't think it is part of JEE 5 either. Weblogic 9.1 does provide an implementation though. I don't think we should provide a full implementation of 237 I have an implementation that supports local work using concurrent utilities (Doug Lea), I can port it to use the Java 5 API. It would be good to make the API similar enough to javax.resource and 237 so that we can provide version that delegate through to implementations provided by a managed environment. I will have a look at the JCA work manager API and see what commonalities we can abstract. Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 07 July 2006 15:41 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks On Jul 7, 2006, at 7:13 AM, Meeraj Kunnumpurath wrote: Also, we may find other use cases for using a work manager for deferred executions. Do we have any view on how the runtime can use a work manager from a managed environment when Tuscany is run in a managed environment. I think app servers that support work managers, may be making them available through the JNDI namespace or something else. It's going to depend on the app server :-( In J2EE1.4, app servers were required to provide a work manager to connectors through the javax.resource API; the one we are using from Geronimo is the one they use to support that. JSR-237 was not part of 1.4 although some of the major vendors did provide implementations; I am not sure how portable they are. I don't think we should provide a full implementation of 237 but something similar but lighter weight (for example, I don't think we will need remote work, we may not need transactional work). It would be good to make the API similar enough to javax.resource and 237 so that we can provide version that delegate through to implementations provided by a managed environment. -- Jeremy - 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]
FW: Support for callbacks
Jeremy, Ok, having a brief look at the JCA work manager API, these are my thoughts 1. The high-level API are very similar, a manager and optional support for listeners for callbacks 2. There are subtle differences between the actual semantics of work allocation. JCA work manager supports both blocking (doWork), asynchronous (scheduleWork) , blocking start/asynchronous completion (startWork), whereas a JSR 237 it is always asynchronous (scheduleWork). JSR 237 supports a different semantic for blocking calls using wautForAll and waitForAny. Do you have any thoughts on what features you want to support in the API. Ta Meeraj -Original Message- From: Meeraj Kunnumpurath Sent: 07 July 2006 15:55 To: 'tuscany-dev@ws.apache.org' Subject: RE: Support for callbacks JSR-237 was not part of 1.4 True, I don't think it is part of JEE 5 either. Weblogic 9.1 does provide an implementation though. I don't think we should provide a full implementation of 237 I have an implementation that supports local work using concurrent utilities (Doug Lea), I can port it to use the Java 5 API. It would be good to make the API similar enough to javax.resource and 237 so that we can provide version that delegate through to implementations provided by a managed environment. I will have a look at the JCA work manager API and see what commonalities we can abstract. Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 07 July 2006 15:41 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks On Jul 7, 2006, at 7:13 AM, Meeraj Kunnumpurath wrote: Also, we may find other use cases for using a work manager for deferred executions. Do we have any view on how the runtime can use a work manager from a managed environment when Tuscany is run in a managed environment. I think app servers that support work managers, may be making them available through the JNDI namespace or something else. It's going to depend on the app server :-( In J2EE1.4, app servers were required to provide a work manager to connectors through the javax.resource API; the one we are using from Geronimo is the one they use to support that. JSR-237 was not part of 1.4 although some of the major vendors did provide implementations; I am not sure how portable they are. I don't think we should provide a full implementation of 237 but something similar but lighter weight (for example, I don't think we will need remote work, we may not need transactional work). It would be good to make the API similar enough to javax.resource and 237 so that we can provide version that delegate through to implementations provided by a managed environment. -- Jeremy - 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: Support for callbacks
That sounds ok. -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 07 July 2006 17:27 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks On Jul 7, 2006, at 9:04 AM, Meeraj Kunnumpurath wrote: Jeremy, Ok, having a brief look at the JCA work manager API, these are my thoughts 1. The high-level API are very similar, a manager and optional support for listeners for callbacks 2. There are subtle differences between the actual semantics of work allocation. JCA work manager supports both blocking (doWork), asynchronous (scheduleWork) , blocking start/asynchronous completion (startWork), whereas a JSR 237 it is always asynchronous (scheduleWork). JSR 237 supports a different semantic for blocking calls using wautForAll and waitForAny. Do you have any thoughts on what features you want to support in the API. We know we need async so that is probably the best place to start. If people need sync then they can support it with a blocking listener; if enough people need sync then we can add that to the API later (to allow passthrough to JCA which may be more efficient). Sound reasonable? -- Jeremy PS I'm on IRC if that helps (irc.freenode.net#tuscany) - 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: Support for callbacks
Thanks Jim. I have had a discussion with Jeremy on this as well. Hopefully I should have something done by the weekend. M -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 07 July 2006 18:09 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks Certainly. Feel free to jump in on anything you would like. Input on callbacks would be welcome as well. Jim On Jul 7, 2006, at 2:45 AM, Meeraj Kunnumpurath wrote: Jim, Are you ok for me to start looking at the work manager implementation? Once I get a better understanding around the requirements of callbacks, I can try to give some input on that as well. Ta Meeraj -Original Message- From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 16:39 To: tuscany-dev@ws.apache.org Subject: RE: Support for callbacks I have got an implementation based on Doug Lea's concurrent utilities (JDK 1.4), I think this can be ported to use Java 5 concurrent libraries. If you don't mind, I can start looking at this. -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 16:12 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks On Jul 6, 2006, at 8:04 AM, Meeraj Kunnumpurath wrote: Good point. I think a similar mechanism may be o.k. as long as we clean up properly when the request ends or the thread is reclaimed (e.g. in case of failure where the callback never hapens). Perhaps we could use the WorkArea API for this? Were you thinking of something in particular? Have you looked at any commonj work manager (JSR-237) implementations? Yep that's what I was thinking of with the WorkArea stuff. Right now we reused Geronimo's WorkManager impl for the async dispatching but it drags in a lot of dependencies for what it does. I was thinking we could just write a thin implementation of WorkManager using the JDK 5 concurrency libraries and eliminate the dependencies. When we run in a managed environment, we could swap implementations since the WorkManager is set up as a system service. I haven't had time to look at doing this so if anyone is interested (as well as joining in on the callback work), it would be great. Jim M -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 16:01 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks Hi Ignacio, Sorry about the delay...Comments inline. I've also added some scenarios to the wiki so feel free to add your thoughts to them. Jim On Jul 5, 2006, at 2:07 PM, Ignacio Silva-Lepe wrote: Hi Jim, Sorry about the disconnect, I was out Monday and yesterday. I'll be sure to attend the IRC chat tomorrow. In the meantime, some more quick comments. - Original Message - snip/ If I understand correctly, would a system service transport use a low level communication mechanism, like a socket for instance? This does not seem like an appropriate approach for a local scenario, Right, for the local scenario, I was thinking the callback instance would be put on the thread local context and the proxy would access it from there as opposed to going out over a socket and back in through a listener. Basically, it would be an optimization of the remote case. I think we can further optimize things depending on scopes, e.g. if the callback scope is module, we could possibly avoid threadlocal storage and have the proxy hold on to an instance directly. Pointing at the callback instance directly from the proxy would eliminate invocation chains and the ability to add interceptors to them, wouldn't it? Yea the proxy should probably point back to the Component and not the instance directly unless there is an optimized case where no interceptors were present. Once the proxy points to Component, it can call getInboundWire(String serviceName) which will return the invocation chain that will dispatch to the correct instance. In the case of an AtomicComponent, when the end of the chain is reached, the target invoker will delegate to the scope container which will return the right instance. Also, I'm not sure using a thread local in the core is a good idea if an intention is to allow the core to be embeddable in, for instance, a managed environment, as thread local does not necessarily mix well with thread pools. Good point. I think a similar mechanism may be o.k. as long as we clean up properly when the request ends or the thread is reclaimed (e.g. in case of failure where the callback never hapens). Perhaps we could use the WorkArea API for this? Were you thinking of something in particular? Jim snip/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe
RE: Do we plan to move to JUnit 4.1?
I have been looking at TestNG lately. It is lot better than Junit 3.8.1. However, I think lot of those features are incorporated in Junit 4.0. I am not sure about the Maven support for TestNG. -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 02:10 To: tuscany-dev@ws.apache.org Subject: Re: Do we plan to move to JUnit 4.1? On Jul 5, 2006, at 5:05 PM, Raymond Feng wrote: I'm wondering if we plan to move to JUnit 4.1? I see more flexibilities and simplicities offered by JUnit 4.x. Now I can also use the wizards from Eclipse 3.2 to take advantage of it. Do we see any issues? I understand Junit 4.x requires JDK 5. I'm not sure if maven 2.0.4 supports it. We had a look at junit 4 back in Sep but stayed with 3.8.1 due to the lack of maven support. Can you find out if that has changed? If it has it might be worth upgrading. -- Jeremy - 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: Support for callbacks
I have got an implementation based on Doug Lea's concurrent utilities (JDK 1.4), I think this can be ported to use Java 5 concurrent libraries. If you don't mind, I can start looking at this. -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 16:12 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks On Jul 6, 2006, at 8:04 AM, Meeraj Kunnumpurath wrote: Good point. I think a similar mechanism may be o.k. as long as we clean up properly when the request ends or the thread is reclaimed (e.g. in case of failure where the callback never hapens). Perhaps we could use the WorkArea API for this? Were you thinking of something in particular? Have you looked at any commonj work manager (JSR-237) implementations? Yep that's what I was thinking of with the WorkArea stuff. Right now we reused Geronimo's WorkManager impl for the async dispatching but it drags in a lot of dependencies for what it does. I was thinking we could just write a thin implementation of WorkManager using the JDK 5 concurrency libraries and eliminate the dependencies. When we run in a managed environment, we could swap implementations since the WorkManager is set up as a system service. I haven't had time to look at doing this so if anyone is interested (as well as joining in on the callback work), it would be great. Jim M -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 16:01 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks Hi Ignacio, Sorry about the delay...Comments inline. I've also added some scenarios to the wiki so feel free to add your thoughts to them. Jim On Jul 5, 2006, at 2:07 PM, Ignacio Silva-Lepe wrote: Hi Jim, Sorry about the disconnect, I was out Monday and yesterday. I'll be sure to attend the IRC chat tomorrow. In the meantime, some more quick comments. - Original Message - snip/ If I understand correctly, would a system service transport use a low level communication mechanism, like a socket for instance? This does not seem like an appropriate approach for a local scenario, Right, for the local scenario, I was thinking the callback instance would be put on the thread local context and the proxy would access it from there as opposed to going out over a socket and back in through a listener. Basically, it would be an optimization of the remote case. I think we can further optimize things depending on scopes, e.g. if the callback scope is module, we could possibly avoid threadlocal storage and have the proxy hold on to an instance directly. Pointing at the callback instance directly from the proxy would eliminate invocation chains and the ability to add interceptors to them, wouldn't it? Yea the proxy should probably point back to the Component and not the instance directly unless there is an optimized case where no interceptors were present. Once the proxy points to Component, it can call getInboundWire(String serviceName) which will return the invocation chain that will dispatch to the correct instance. In the case of an AtomicComponent, when the end of the chain is reached, the target invoker will delegate to the scope container which will return the right instance. Also, I'm not sure using a thread local in the core is a good idea if an intention is to allow the core to be embeddable in, for instance, a managed environment, as thread local does not necessarily mix well with thread pools. Good point. I think a similar mechanism may be o.k. as long as we clean up properly when the request ends or the thread is reclaimed (e.g. in case of failure where the callback never hapens). Perhaps we could use the WorkArea API for this? Were you thinking of something in particular? Jim snip/ - 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
Extensions and new architecture
Hi, I have been away from the list for a few weeks. I am back on now looking at things in general. Before I disappeared, I was looking at the Groovy container and spaces binding. I would like to continue working on them. I think Jim has refactored the Groovy container in the sandbox to fit in with the new extension model. Should all the new extensions (containers, bindings etc) be written according to the extension model (I am assuming the new extension model is still in the sandbox). I am also interested in knowing whether anyone is working on asynchronous bindings? Many thanks Meeraj * 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: Extensions and new architecture
Thanks for the quick reply, Jim. I will go through the email in detail and respond. Ta Meeraj -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 04 July 2006 10:02 To: tuscany-dev@ws.apache.org Subject: Re: Extensions and new architecture Hi Meeraj, It's good to see we didn't scare you off quite yet ;-) Comments inline. On Jul 4, 2006, at 1:26 AM, Meeraj Kunnumpurath wrote: Hi, I have been away from the list for a few weeks. I am back on now looking at things in general. Before I disappeared, I was looking at the Groovy container and spaces binding. I would like to continue working on them. Great I think Jim has refactored the Groovy container in the sandbox to fit in with the new extension model. Should all the new extensions (containers, bindings etc) be written according to the extension model (I am assuming the new extension model is still in the sandbox). As some background, we currently have two proposals on the table for moving forward (you're welcome to add a third if you have ideas): 1. Move the sandbox code (core2) to trunk (or even a branch) and take that as a basis for moving forward. The sandbox code incorporates some things from M1 but is a very significant refactor to better accomodate changes to the SCA spec and issues we encountered with M1. As part of this move, we would refactor for modularity and simplification where appropriate. A set of overview slides on the spec changes as well as core2 can be found here: http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/doc/ 2. Start afresh and merge pieces of M1 and core2 one step at a time according to a set of use cases, starting with simple ones first (e.g. bootstrap a component) I won't go into the pros and cons of each approach since there has been a number of emails on the list related to those. We already have quite a bit of work going on in core2 and some have started to jump in with extensions to it (Spring, Celtix, the Groovy container you donated, data transformation, conversational support and callbacks, OSGi deployment, etc.). I'd be more than happy to assist if you're interested. In terms of the technical status of core2, we're still bringing up the end-to-end operation of the runtime, which should not be too much longer (I've got it running on my machine but need to clean up some code before checkin). All of the major subsystems are in place and operational and we have one example (eager init), so it's a matter of connecting one more piece. We are unfortunately sorely lacking in documentation so I'm willing to provide as much direct assistance as you need if you would like to work on core2. We have started a scenarios page on the wiki so you may want to also look at that as well as add to it with things you believe are interesting and/or would like to work on: http://wiki.apache.org/ws/Tuscany/TuscanyJava/Scenarios Also, since we are in the process of gaining consensus, it would be good if you had an opinion on either of the two approaches (or an alternative) I am also interested in knowing whether anyone is working on asynchronous bindings? I think that would be a really good thing to work on. Again, if you would like to do it in core2, I'm more than happy to help. Perhaps adding something to the wiki with your thoughts would be a good way to start the process? If you've made it to this point in the message, I hope you're not scared off! It would be great to hear more of your input. Jim Many thanks Meeraj * 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]
RE: Question on java generics
Raymond,
You can get the type of T if you have a parameterized field of a generic
type. Some thing like this,
import java.lang.reflect.Field;
import java.lang.reflect.ParameterizedType;
public class TestT {
private TestString myField;
/**
* @param args
*/
public static void main(String[] args) throws Exception {
Field field = Test.class.getDeclaredField(myField);
ParameterizedType parameterizedType =
(ParameterizedType)field.getGenericType();
System.err.println(parameterizedType.getActualTypeArguments()[0]);
}
}
Ta
Meeraj
-Original Message-
From: Yang ZHONG [mailto:[EMAIL PROTECTED]
Sent: 28 June 2006 01:19
To: tuscany-dev@ws.apache.org
Subject: Re: Question on java generics
1) No. T is erasable.
2) If myClass is a class or generic type, you should be able to new
TestmyClass.
On the other hand, if myClass is a pointer/variable, no you can't
new TestmyClass
On 6/27/06, Raymond Feng [EMAIL PROTECTED] wrote:
Generics gurus,
Assuming I have the following class:
public class TestT {
...
}
1) Is there a way to get the Class object for T in class Test? I know
T.class is illegal.
2) Can I create the an instance of Test using a Class object myClass.
I know new TestmyClass is not valid.
Thanks,
Raymond
--
Yang ZHONG
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: Question on java generics
I don't think you can get the instance type information from within the class as it is erased by the compiler. -Original Message- From: Yang ZHONG [mailto:[EMAIL PROTECTED] Sent: 28 June 2006 18:22 To: tuscany-dev@ws.apache.org Subject: Re: Question on java generics Given CollectionString strings = ...; CollectionInteger integers = ...; According to Java language spec, this is true: strings.getClass() == integers.getClass() After all, Java doesn't generate .class files for EACH parametization/instantiation like C++. It seems impossible to get the parameter type from strings.getClass(). HOWEVER, what I have been discussing and what I guessed Raymond originally wanted is INSTANCE type. For DECLARATION type, it's different, as Meeraj ponited out, you can get field DECLARATION type. As for class itself, I guess parametized info may be available as super type DECLARATION. It'll be very interesting if template/generic INSTANTIATION info can be found given only one .class file each type. On 6/28/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On 6/28/06, Meeraj Kunnumpurath [EMAIL PROTECTED] wrote: Raymond, You can get the type of T if you have a parameterized field of a generic type. Some thing like this, snip/ I think you can also get the parameterized type information from Class itself. Jim was doing some introspection like this to help with registration callbacks - have a look in BuilderRegistryImpl#register. -- Jeremy -- Yang ZHONG 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: support on WebLogic and WebSphere?
Jim, I din't think WLS 8.1 is certified for Java 5. Ta Meeraj - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Subject: Re: support on WebLogic and WebSphere? Date: Fri, 2 Jun 2006 09:42:00 -0700 Hi Andrew, Doesn't the new version of WAS 6 support JDK5 (I thought I just saw an announcement about this)? WebLogic 9 requires JDK5 and I believe WebLogic 8.1 can run on JDK5. Jim On Jun 2, 2006, at 1:13 AM, Andrew Borley wrote: Hi, There may be an issue with JDK versions - Tuscany M1 pre-reqs Java 5 whereas Websphere 6.x runs on Java 1.4. There may well be ways to get around this, and I'm not sure what version Weblogic runs on, but it may be a stumbling block. If anyone wants to try it out and let us know that would be really useful info. Cheers Andrew On 6/1/06, Jim Marino [EMAIL PROTECTED] wrote: Hi John, Tuscany M1 should be able to run in any Servlet container. We have done a deep integration with Tomcat for an out-of-the-box experience. Moving forward, we plan to support additional platforms. If you really want to deploy to WebLogic or Websphere, the easiest mechanism would be to use Servlet filters. The tricky part is going to be placing third-party jars such as Axis in the right classloader. If you are interested in this, I could provide help to you on WebLogic or general J2EE things (others I am sure can help out on specific Websphere issues). Barring that, at some point we'll also provide easier deployment on Websphere and WebLogic in the future. Jim On Jun 1, 2006, at 8:41 AM, Langley, John wrote: This is a cross post from the tuscany-user mailing list... where it seemed to get no answer. I suspect the developers here would know off the top of their heads about the practicality of running Tuscany M1 release in either Weblogic 9.x or WebSphere 6.x Another interesting digression would be a brief comparison of how SCA is supported today in WebSphere with what Tuscany is providing. Thanks in advance, sorry if I missed these factoids somewhere else. Langley -Original Message- From: Langley, John [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 31, 2006 8:55 AM To: tuscany-user@ws.apache.org Subject: support on WebLogic and WebSphere? Hello, I'm a newbie who's quite interested in the potential of Tuscany but my constraints for adoption is that there is support on WebLogic and WebSphere servers. Has anyone gotten Tuscany code working on 9.x Weblogic or 6.x WebSphere? Thanks in advance for insights and opinions... Langley - 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] -- Cheers, Andrew Borley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- ___ Search for businesses by name, location, or phone number. -Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Support for asynchronous non-blocking calls available in the sandbox
Jean, I am not sure what state is this in now. I have been working on a spaces binding for asynchronous calls. I am also interested in looking at JMS binding. I would appreciate it, if you could please share your thoughts on this. Thanks Meeraj -Original Message- From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED] Sent: 25 April 2006 16:39 To: tuscany-dev@ws.apache.org Subject: Support for asynchronous non-blocking calls available in the sandbox I checked a first implementation of support for async non-blocking calls in the sandbox. Directory sandbox/sebastien/java/sca/async contains the runtime code, sandbox/sebastien/java/samples/helloworldasync contains an asynchronous variation of the helloworld sample. More details about how this code works are in http://issues.apache.org/jira/browse/TUSCANY-223. Could people in the group please take a look and see if you're (reasonably) happy with this initial implementation? If there's no objection I'd like to move this to the sca/core project in the next couple of days. There are still some limitations and temporary workarounds in this code, I'm probably going to need help to go from there and improve this initial implementation. I'm also looking for a better sample than helloworld to demonstrate the async capability... Anybody interested in helping with this? -- Jean-Sebastien 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: ConfigurationLoadException: Unrecognized element .............. for a new binding type
You need to register the qualified name for the binding with the Stax
loader registry.
-Original Message-
From: Rashmi Hunt [mailto:[EMAIL PROTECTED]
Sent: 01 June 2006 14:50
To: tuscany-dev@ws.apache.org
Subject: ConfigurationLoadException: Unrecognized element
.. for a new binding type
I am implementing a new binding type say xxx. Calling this binding as
xxx from here onwards.
1) I have created a schema for this new binding (XSD) under
tuscany-model project, under resources\model directory along with other
binding schema.
The new binding schema looks like
schema xmlns=http://www.w3.org/2001/XMLSchema; xmlns:sca=
http://www.osoa.org/xmlns/sca/0.9; xmlns:sdo=commonj.sdo/xml
targetNamespace=http://www.osoa.org/xmlns/sca/0.9;
elementFormDefault=qualified
include schemaLocation=sca-core.xsd/ element name=binding.xxx
type=sca:xxxBinding
substitutionGroup=sca:binding sdo:name=bindingXxx/ complexType
name=XXXBinding
complexContent
extension base=sca:Binding
sequence
any namespace=##other processContents=lax minOccurs=0
maxOccurs=unbounded/
/sequence
attribute name=yyy type=anyURI use=required/
anyAttribute namespace=##any processContents=lax/
/extension
/complexContent
/complexType
/schema
yyy is the additional attribute needed for this binding.
2) I have implemented code for this new binding in a new project
tuscany-binding-xxx. This project implements code for
assembly/assembly.impl/builder/config/externalService/loader/util.
Correct system.fragment exists as well.
3) After building the projects, when I run a test module with this new
binding, I get ConfigurationLoaderException when I try to create new
TuscanyRuntime
4) Here is the new binding used in External Service in my sca.module
file
externalService name=CandidateCheck
interface.java interface=com.app.jobbank.CandidateCheck/
binding.xxx yyy=test/CandidateCheck/
/externalService
5) Seems like the new binding schema ( which is under model project) is
not recognized by SCA runtime.
Am I missing something here? Help is appreciated.
Full exception trace :-
Exception in thread main
org.apache.tuscany.core.config.ConfigurationLoadException: Unrecognized
element [{http://www.osoa.org/xmlns/sca/0.9}binding.xxx]
at org.apache.tuscany.core.loader.impl.StAXLoaderRegistryImpl.load(
StAXLoaderRegistryImpl.java:62)
at org.apache.tuscany.core.loader.assembly.ExternalServiceLoader.load(
ExternalServiceLoader.java:57)
at org.apache.tuscany.core.loader.assembly.ExternalServiceLoader.load(
ExternalServiceLoader.java:1)
at org.apache.tuscany.core.loader.impl.StAXLoaderRegistryImpl.load(
StAXLoaderRegistryImpl.java:66)
at
org.apache.tuscany.core.loader.assembly.CompositeLoader.loadComposite(
CompositeLoader.java:43)
at org.apache.tuscany.core.loader.assembly.ModuleLoader.load(
ModuleLoader.java:41)
at org.apache.tuscany.core.loader.assembly.ModuleLoader.load(
ModuleLoader.java:1)
at org.apache.tuscany.core.loader.impl.StAXLoaderRegistryImpl.load(
StAXLoaderRegistryImpl.java:66)
at
org.apache.tuscany.core.config.impl.StAXModuleComponentConfigurationLoad
erImpl.loadModule
(StAXModuleComponentConfigurationLoaderImpl.java:51)
at
org.apache.tuscany.core.config.impl.AbstractModuleComponentConfiguration
Loader.loadModuleComponent
(AbstractModuleComponentConfigurationLoader.java:142)
at
org.apache.tuscany.core.config.impl.AbstractModuleComponentConfiguration
Loader.loadModuleComponent
(AbstractModuleComponentConfigurationLoader.java:132)
at
org.apache.tuscany.core.config.impl.AbstractModuleComponentConfiguration
Loader.loadModuleComponent
(AbstractModuleComponentConfigurationLoader.java:100)
at
org.apache.tuscany.core.client.TuscanyRuntime.init(TuscanyRuntime.java
:103)
at
org.apache.tuscany.core.client.TuscanyRuntime.init(TuscanyRuntime.java
:67)
at
com.app.jobbank.JobBankServiceClient.main(JobBankServiceClient.java:31)
Regards
Rashmi
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: ConfigurationLoadException: Unrecognized element .............. for a new binding type
This is from the spaces binding I have been working on,
/**
*
* Copyright 2006 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.tuscany.binding.spaces.loader;
import javax.xml.namespace.QName;
import javax.xml.stream.XMLStreamReader;
import org.apache.tuscany.binding.spaces.assembly.SpacesBinding;
import org.apache.tuscany.core.loader.LoaderContext;
import org.apache.tuscany.core.loader.StAXElementLoader;
import org.apache.tuscany.core.loader.StAXLoaderRegistry;
import org.apache.tuscany.core.system.annotation.Autowire;
import org.osoa.sca.annotations.Destroy;
import org.osoa.sca.annotations.Init;
import org.osoa.sca.annotations.Scope;
/**
* Loader for spaces binding information.
*
*/
@Scope(MODULE)
public class SpacesBindingLoader implements
StAXElementLoaderSpacesBinding {
/** Namespace used for the JavaSpaces binding */
public static final QName BINDING_SPACES = new
QName(http://org.apache.tuscany/xmlns/spaces/0.9;, binding.spaces);
/** Stax loader registry that is injected in */
protected StAXLoaderRegistry registry;
/**
* Injection method for the Stax loader registry.
*
* @param registry
*Stax loader registry.
*/
@Autowire
public void setRegistry(StAXLoaderRegistry registry) {
this.registry = registry;
}
/**
* Lifecycle method when the component is started.
*/
@Init(eager = true)
public void start() {
registry.registerLoader(BINDING_SPACES, this);
}
/**
* Lifecycle method when the component is stopped.
*/
@Destroy
public void stop() {
registry.unregisterLoader(BINDING_SPACES, this);
}
/**
* Creates the binding model object for JavaSpaces binding.
*/
@SuppressWarnings(deprecation)
public SpacesBinding load(XMLStreamReader reader, LoaderContext
loaderContext) {
long timeout = Long.parseLong(reader.getAttributeValue(null,
timeout));
return new SpacesBinding(timeout);
}
}
This is the excerpt from the system.fragment file,
component
name=org.apache.tuscany.binding.spaces.loader.SpacesBindingLoader
tuscany:implementation.system
class=org.apache.tuscany.binding.spaces.loader.SpacesBindingLoader/
/component
Ta
Meeraj
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy
Boynes
Sent: 01 June 2006 15:15
To: tuscany-dev@ws.apache.org
Subject: Re: ConfigurationLoadException: Unrecognized element
.. for a new binding type
On 6/1/06, Meeraj Kunnumpurath [EMAIL PROTECTED] wrote:
You need to register the qualified name for the binding with the Stax
loader registry.
Meeraj is spot on. We don't register loaders based on XML schema.
Instead each one needs to register with the LoaderRegistry for the
elements it can handle. There is some info on this on the wiki:
http://wiki.apache.org/ws/Tuscany/TuscanyJava/Extending/StAXLoading
One thing that's missing from the page is that for this to work the
class must be MODULE scoped (otherwise the @Init method won't be fired
early enough). I'll add an update for that later today.
--
Jeremy
-
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: [jira] Commented: (TUSCANY-435) Spaces binding for SCA
Thanks Ant. I have got the POM done. I am just making sure I have got all the runtime dependencies. I will write up some simple instructions to run this using one of the spaces implementations (I have tested it with the JINI starter kit) and try to submit it by COP today. I may start looking at a JMS binding over the weekend. A one-way asynchronous single-argument invocation model for entry points and asynchronous services shouldn't be difficult to implement. I was wondering whether there was any lead from the spec perspective for using bindings over asynchronous transports like JMS? Thanks Meeraj -Original Message- From: ant elder (JIRA) [mailto:[EMAIL PROTECTED] Sent: 31 May 2006 10:01 To: tuscany-dev@ws.apache.org Subject: [jira] Commented: (TUSCANY-435) Spaces binding for SCA [ http://issues.apache.org/jira/browse/TUSCANY-435?page=comments#action_12 414005 ] ant elder commented on TUSCANY-435: --- This looks interesting. You've put a couple of TODO comments for the POM and instructions, should I wait for these before committing this somewhere? I can help with the POM if you don't know maven but some simple instructions on setting up JINI would be good so i can do a quick test. There was someone on the mailing list months ago talking about a JMS binding but nothing ever seems to have come of that, and there's been no other mention on the mailing list of a JMS binding since then. ...ant Spaces binding for SCA -- Key: TUSCANY-435 URL: http://issues.apache.org/jira/browse/TUSCANY-435 Project: Tuscany Type: New Feature Reporter: Meeraj Kunnumpurath Attachments: binding.spaces.jar First cut of the spaces binding for entry points and extrenal services. Assumptions: All operations are one way and single arguments. TODO: 1. POM to be updated to include JINI and spaces dependencies 2. Add instructions for running the sample using JINI starter kit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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]
[jira] Created: (TUSCANY-435) Spaces binding for SCA
Spaces binding for SCA -- Key: TUSCANY-435 URL: http://issues.apache.org/jira/browse/TUSCANY-435 Project: Tuscany Type: New Feature Reporter: Meeraj Kunnumpurath First cut of the spaces binding for entry points and extrenal services. Assumptions: All operations are one way and single arguments. TODO: 1. POM to be updated to include JINI and spaces dependencies 2. Add instructions for running the sample using JINI starter kit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-365) Java SCA Container for Ruby
[ http://issues.apache.org/jira/browse/TUSCANY-365?page=comments#action_12383377 ] Meeraj Kunnumpurath commented on TUSCANY-365: - Is it worth looking at having a generic JSR-223 container. Java SCA Container for Ruby --- Key: TUSCANY-365 URL: http://issues.apache.org/jira/browse/TUSCANY-365 Project: Tuscany Type: New Feature Versions: Java-Mx Reporter: Srikanth Bhattiprolu Priority: Minor Attachments: bsf.jar, jruby.jar, tuscany-container-ruby.zip This is the Ruby Container for Tuscany. I just copied the complete Groovy code, change the references to Ruby and update the Script.java file to call the Ruby scripts instead. The scripts are invoked using the BSF support provided by JRuby. Srikanth -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-317) Java SCA Groovy Container
[ http://issues.apache.org/jira/browse/TUSCANY-317?page=all ] Meeraj Kunnumpurath updated TUSCANY-317: Attachment: container.groovy.zip Refactored to use the extension support classes from core. Ta Java SCA Groovy Container - Key: TUSCANY-317 URL: http://issues.apache.org/jira/browse/TUSCANY-317 Project: Tuscany Type: New Feature Versions: Java-Mx Reporter: Meeraj Kunnumpurath Assignee: Jean-Sebastien Delfino Priority: Minor Fix For: Java-Mx Attachments: container.groovy.zip, container.groovy.zip SCA Container for running Groovy scripts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-317) Java SCA Groovy Container
[ http://issues.apache.org/jira/browse/TUSCANY-317?page=comments#action_12378841 ] Meeraj Kunnumpurath commented on TUSCANY-317: - Seems to be wrong version of asm, if you have asm 2.2 higher up in the classpath, the test seems to be working. Ta Java SCA Groovy Container - Key: TUSCANY-317 URL: http://issues.apache.org/jira/browse/TUSCANY-317 Project: Tuscany Type: New Feature Reporter: Meeraj Kunnumpurath Assignee: Jean-Sebastien Delfino Priority: Minor Attachments: container.groovy.zip SCA Container for running Groovy scripts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-329) Simplified extension API improvements
[ http://issues.apache.org/jira/browse/TUSCANY-329?page=all ] Meeraj Kunnumpurath updated TUSCANY-329: Attachment: GroovyImplementationLoader.java This is the groovy implementation loader now loos like. Simplified extension API improvements - Key: TUSCANY-329 URL: http://issues.apache.org/jira/browse/TUSCANY-329 Project: Tuscany Type: Improvement Components: Java SCA Core Versions: M1 Reporter: ant elder Assignee: Jim Marino Fix For: M1 Attachments: AbstractImplementationLoader.java, GroovyImplementationLoader.java The work to create simple APIs for adding extensions has made some of the work required to add an extension much simpler, but there's still things that can be simplfied further for container extensions for new component types. The relevant classes are the ContextFactory, ComponentContext, and TargetInvoker which have a non trivial amount of code and its virtually identical for most simple components. A ComponentTargetInvoker would also be almost identical to the o.a.t.c.extension.ExternalServiceTargetInvoker. Code for these classes already exists in the Java container, it just needs to be refactored a little to be generic and moved to the o.a.t.c.extension package. Be really great if we could get this done before M1 so we have stable extension APIs for people to work with. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Eclipse code style templates
Hi, Could someone pls point me to the Eclipse code style templates for Tuscany? Ta Meeraj * 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.
[jira] Updated: (TUSCANY-317) Java SCA Groovy Container
[ http://issues.apache.org/jira/browse/TUSCANY-317?page=all ] Meeraj Kunnumpurath updated TUSCANY-317: Attachment: container.groovy.zip Jean, I have attached the first cut of all the source files. I have been building from Eclipse, haven't got any of the Maven build files yet. I am using Groovy 1.0 latest release and runtime you need antlr 2.7.5 as well. Sorry, I didn't have any of the Eclipse code style and format templates for Tuscany, hence the source files may be formatted incorrectly. Ta Meeraj Java SCA Groovy Container - Key: TUSCANY-317 URL: http://issues.apache.org/jira/browse/TUSCANY-317 Project: Tuscany Type: New Feature Reporter: Meeraj Kunnumpurath Assignee: Jean-Sebastien Delfino Priority: Minor Attachments: container.groovy.zip SCA Container for running Groovy scripts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-329) Simplified extension API improvements
[ http://issues.apache.org/jira/browse/TUSCANY-329?page=comments#action_12378405 ] Meeraj Kunnumpurath commented on TUSCANY-329: - I noticed this working on the Groovy container. There was significant code duplication in the extension classes for component context, context factory builder and implementation builder. Thanks Meeraj Simplified extension API improvements - Key: TUSCANY-329 URL: http://issues.apache.org/jira/browse/TUSCANY-329 Project: Tuscany Type: Improvement Components: Java SCA Core Versions: M1 Reporter: ant elder Assignee: Jim Marino Priority: Critical Fix For: M1 The work to create simple APIs for adding extensions has made some of the work required to add an extension much simpler, but there's still things that can be simplfied further for container extensions for new component types. The relevant classes are the ContextFactory, ComponentContext, and TargetInvoker which have a non trivial amount of code and its virtually identical for most simple components. A ComponentTargetInvoker would also be almost identical to the o.a.t.c.extension.ExternalServiceTargetInvoker. Code for these classes already exists in the Java container, it just needs to be refactored a little to be generic and moved to the o.a.t.c.extension package. Be really great if we could get this done before M1 so we have stable extension APIs for people to work with. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: [jira] Commented: (TUSCANY-329) Simplified extension API improvements
Thanks Jim. I didn't notice the support classes in common. I will have a look at it today. -Original Message- From: Jim Marino (JIRA) [mailto:[EMAIL PROTECTED] Sent: 08 May 2006 13:38 To: tuscany-dev@ws.apache.org Subject: [jira] Commented: (TUSCANY-329) Simplified extension API improvements [ http://issues.apache.org/jira/browse/TUSCANY-329?page=comments#action_12 378410 ] Jim Marino commented on TUSCANY-329: Hi Meeraj, The doc on this is still lacking but did you notice the support classes in extensions under core? These handle many of the common cases? Also, I'm currently doing some work in the sandbox on simplifying the extension API further some your feedback on improvements to the extisting API (it's still very rough) would be great to hear. Thanks, Jim Simplified extension API improvements - Key: TUSCANY-329 URL: http://issues.apache.org/jira/browse/TUSCANY-329 Project: Tuscany Type: Improvement Components: Java SCA Core Versions: M1 Reporter: ant elder Assignee: Jim Marino Priority: Critical Fix For: M1 The work to create simple APIs for adding extensions has made some of the work required to add an extension much simpler, but there's still things that can be simplfied further for container extensions for new component types. The relevant classes are the ContextFactory, ComponentContext, and TargetInvoker which have a non trivial amount of code and its virtually identical for most simple components. A ComponentTargetInvoker would also be almost identical to the o.a.t.c.extension.ExternalServiceTargetInvoker. Code for these classes already exists in the Java container, it just needs to be refactored a little to be generic and moved to the o.a.t.c.extension package. Be really great if we could get this done before M1 so we have stable extension APIs for people to work with. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira 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.
Groovy Container
Hi, I have written a Groovy container for Tuscany. Is it worth submitting? Kind regards Meeraj -- ___ Search for businesses by name, location, or phone number. -Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10
[jira] Created: (TUSCANY-317) Java SCA Groovy Container
Java SCA Groovy Container - Key: TUSCANY-317 URL: http://issues.apache.org/jira/browse/TUSCANY-317 Project: Tuscany Type: New Feature Reporter: Meeraj Kunnumpurath Priority: Minor SCA Container for running Groovy scripts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Insufficient space in perm gen
Hi, Has anyone noticed out of memory error in the build due to insufficient perm gen space? Ta Meeraj * 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.
RE: Insufficient space in perm gen
Ta -Original Message- From: Rick Rineholt [mailto:[EMAIL PROTECTED] Sent: 03 May 2006 10:28 To: tuscany-dev@ws.apache.org Subject: Re: Insufficient space in perm gen Hello, Here is some previous information on the mailing list http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg02130.html AccountServiceImpl Meeraj Kunnumpurath wrote: Hi, Has anyone noticed out of memory error in the build due to insufficient perm gen space? Ta Meeraj * 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. This message has been checked for all email viruses by MessageLabs. This message has been checked for all email viruses by MessageLabs.
RE: Location of sca.module
Does the first way of packaging outlined above meet your needs? I think it is a sensible way of packaging in the interim. However, as you mentioned there should be a more robust deployment model in the long term and it should be driven from a specification perspective rather than treated as an implementation issue. We also need to look into how SCA deployment model can work together with J2EE packaging and deployment model. if you would like to help for Tuscany, just jump in by proposing some ideas to the list Thanks, I would definitely like to. I am familiarising myself with the codebase and running the sample apps. Once I am familiar with the stuff, I wouldn't mind helping out with docs, clearing compiler warnings etc, if you don't mind. We use Mule quite a bit at work and one of the things I find quite good with Mule is the ease of switching between different transports. Though, Mule's way of doing things in a loosely coupled manner on a SEDA-based model is quite elegant, in scenarios where you need strong typing we end up building custom stuff on top of Mule using dynamic proxies that expose strong interfaces and abstracts the interactions with the Mule event bus. This is one thing I quite like in SCA, the way it supports interface-based interactions. Ta Meeraj -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 01 May 2006 22:51 To: tuscany-dev@ws.apache.org Subject: Re: Location of sca.module J2EE deployment integration was one of the to-do items for the spec group (it hasn't been done yet). In terms of the scenario you outlined, I think it would be cleaner to package fragments in the jar files and the sca.module file in the war. This means there is one module per war but I think that is the cleanest approach (and it's what we support with Tomcat) since modules are generally things that are evolved and deployed together, it avoids having to deal with child classloaders, and it makes mapping module components to URIs much easier. Longer term I don't think this will provide a very robust deployment model for the scenarios SCA is designed for and we have been looking at OSGi as a more flexible mechanism. I'm planning to do an OSGi integration when we finish up with the JavaOne release if you are interested. I believe others are interested in deploying to Geronimo so we will need to figure out a broader J2EE deployment story sometime soon (if you would like to help for Tuscany, just jump in by proposing some ideas to the list). Does the first way of packaging outlined above meet your needs? Jim On May 1, 2006, at 1:46 PM, meeraj kunnumpurath wrote: Thanks Jim. I was also thinking about how an SCA deployment unit would be loaded within the context of a J2EE container. For example, if two module JAR files are included in the WEB-INF\lib directory of a WAR file, then would we need to child classloaders to the WAR classloader responsible for loading each of the SCA modules. Or is there a different behaviour expected in terms of classloader hierarchy as part of the SCA runtime? Also, does SCA assembly model define how SCA modules are expected to be deployed in a J2EE environment? Ta Meeraj - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Subject: Re: Location of sca.module Date: Mon, 1 May 2006 13:14:55 -0700 There should be one module file per deployment unit. To get the intended behavior I believe you want (i.e. a module definition composed of a number of fragments), use sca.fragment files and places them in the classpath as they will be merged during load. On a file system, the directories would just need to be on the classpath. That said, the SCA deployment story needs a lot of work (some of which is currently underway). Having only one top-level sca.module file per deployment unit is a good thing since the URI is defined there. I'm not too keen on the classpath merge with multiple fragments and we've discussed a plan to move to more of an include style (i.e. sca.module can include a bunch of fragments or fragments can include themselves into a module). Let me know if you run into issues with the existing approach or have ideas on making things better. Jim On May 1, 2006, at 7:44 AM, meeraj kunnumpurath wrote: Hi, Could someone please shed some light on the expected behaviour when more than one sca.module file is found within the scope of the thread context classloader? The spec requires a packaged module JAR file to have exactly one sca.module file at the root. Would this require each module JAR to be loaded by its own classloader. Also, how would this work if the deployemnt unit is a folder in the file- system? Thanks in advance Meeraj -- ___ Search for businesses by name, location, or phone number. -Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com
Re: Location of sca.module
Thanks Jim. I was also thinking about how an SCA deployment unit would be loaded within the context of a J2EE container. For example, if two module JAR files are included in the WEB-INF\lib directory of a WAR file, then would we need to child classloaders to the WAR classloader responsible for loading each of the SCA modules. Or is there a different behaviour expected in terms of classloader hierarchy as part of the SCA runtime? Also, does SCA assembly model define how SCA modules are expected to be deployed in a J2EE environment? Ta Meeraj - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Subject: Re: Location of sca.module Date: Mon, 1 May 2006 13:14:55 -0700 There should be one module file per deployment unit. To get the intended behavior I believe you want (i.e. a module definition composed of a number of fragments), use sca.fragment files and places them in the classpath as they will be merged during load. On a file system, the directories would just need to be on the classpath. That said, the SCA deployment story needs a lot of work (some of which is currently underway). Having only one top-level sca.module file per deployment unit is a good thing since the URI is defined there. I'm not too keen on the classpath merge with multiple fragments and we've discussed a plan to move to more of an include style (i.e. sca.module can include a bunch of fragments or fragments can include themselves into a module). Let me know if you run into issues with the existing approach or have ideas on making things better. Jim On May 1, 2006, at 7:44 AM, meeraj kunnumpurath wrote: Hi, Could someone please shed some light on the expected behaviour when more than one sca.module file is found within the scope of the thread context classloader? The spec requires a packaged module JAR file to have exactly one sca.module file at the root. Would this require each module JAR to be loaded by its own classloader. Also, how would this work if the deployemnt unit is a folder in the file- system? Thanks in advance Meeraj -- ___ Search for businesses by name, location, or phone number. -Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/ default.asp?SRC=lycos10 -- ___ Search for businesses by name, location, or phone number. -Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10
