Re: Composite classpaths, was: How to use extensions with the standalone launcher?
On Jul 31, 2006, at 1:56 PM, Jeremy Boynes wrote: On Jul 30, 2006, at 6:33 PM, Jim Marino wrote: On Jul 30, 2006, at 5:21 PM, Jeremy Boynes wrote: On Jul 30, 2006, at 2:55 PM, ant elder wrote: What about the dependencies of the extension? It looks like right now all the dependency jars still have to go in the boot directory and only the extension in the extension directory. Is that what you intend? The spec does not define way to specify the classpath for a composite so for now everything has to be bundled in it on in a parent classloader (and the boot classloader is the parent to the each of the extension composites). The jar classpath will still work so if you provide a Class-Path entry in the manifest dependencies specified there should be found. Longer term I think we need a way to define a classpath in the composite. I had a quick discussion a while ago with Oisin about using a Maven repository to hold SCA artifacts and perhaps we can use that here. I can think of two ways we could allow users to do this: For system services I think this is fine but I wouldn't want to require this of applications. I don't see the distinction here. We are saying that system services are just composites and this is a way of associating resources with a composite (specifically Java class files) - why would there be any difference? An end user application developer could write some type of library that gets reused by different composites. We should have a mechanism that supports this without resorting to maven. I think we should have some type of resolver abstraction, one implementation being a maven downloader. There are a couple of other options we could also provide, based off of OSGi semantics: 1. Allow a jar to specify its dependencies using pure OSGi manifest entries when the composite is packaged as a bundle and deployed to an OSGI environment 2. Allow the SCDL to specify dependencies using OSGI semantics. These would then be baked down to whatever packaging the host environment supported, perhaps through a pre-deploy step 3.As part of #2, have a way to specify a maven bundle and have the pre-deployer pul it from maven and repackage it. Generally I don't like pre-packagers but that may be the price people have to pay for deploying on host environments with problematic classloading semantics - e.g. J2EE app servers. In an OSGi or jar launcher environment, things should just work without a predeploy step. These seem like alternatives. If the user wants to use OSGi semantics then this would be a way to support them. However, there are a lot of things out there that do not have OSGi manifests and we need to be able to support them two. That's what #2 would be used for as it is not dependent on OSGi artifacts such as bundles. A SCDL artifact would specify the dependencies and they could be resolved to whatever physical packaging the host platform supports/ Also, these only work if the composite is packaged as a bundle and I think that it's important to allow people to deploy composites that are simple XML SCDL files (no archive involved). That means we need a way in the SCDL to be able to specify what the dependencies are. #2 could also work with a file system through some type of custom resolver mentioned above. Jim -- 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]
Re: SCA Tools
On Jul 31, 2006, at 10:16 PM, Venkata Krishnan wrote: Hi Jeremy / Jim / Rick / Ant and others What is the decision about the sca-tools that existed in M1? Do we plan to make it a part of the current Tuscany-Java as well? I think tooling in general is a good thing to have (as long as it's not required). There is another thread where David Wheeler was talking about samples around the Axis2 binding. Wouldn't the sca tools, Java2WSDL WSDL2Java get to be used there? I'm not really sure. Maybe David could describe what he has further? Thanks - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Karma for Brent
+1 -- Pete
Re: SCA Tools
Jim :-))).. Please help me understand the scope of not required. If something is not required then why have it in the first place? Are these things no longer relevant to the current Tuscany-Java? Thanks - Venkat On 8/1/06, Jim Marino [EMAIL PROTECTED] wrote: On Jul 31, 2006, at 10:16 PM, Venkata Krishnan wrote: Hi Jeremy / Jim / Rick / Ant and others What is the decision about the sca-tools that existed in M1? Do we plan to make it a part of the current Tuscany-Java as well? I think tooling in general is a good thing to have (as long as it's not required). There is another thread where David Wheeler was talking about samples around the Axis2 binding. Wouldn't the sca tools, Java2WSDL WSDL2Java get to be used there? I'm not really sure. Maybe David could describe what he has further? Thanks - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't do multiple import.sdo's
Hi Elizabeth, do you have a test case for this and I'll take a look. Regards, Kelvin. On 31/07/06, Elizabeth DeLouise [EMAIL PROTECTED] wrote: A problem I came across (not sure if it's on my end or Tuscany's), was that I could not have more than one import.sdo wsdlLocation=... tag in my sca.module file. If import.sdo is used more than once, only the first wsdl specified is used to register sdo types. The hack I came up with is to copy-paste the type definitions from one wsdl into another, and declare them like this: module import.sdo wsdlLocation=File1.wsdl / import.wsdl wsdlLocation=File2.wsdl / import.wsdl wsdlLocation=File1.wsdl / /module File1 contains type definitions from both File1 and File2. Both files must still be imported using import.wsdl for this to work, and using import.wsdlmore than once IS successful. Big Bank appears to use 2 import.wsdl tags, as well as import.sdo factory=com.bigbank.account.AccountFactory / import.sdo factory=net.x.webservice.WebserviceFactory / I'm not sure if this gets around the problem of registering SDO types or not. Does anyone have any thoughts on why import.sdo can only be used once? -- Best Regards Kelvin Goodson
[jira] Commented: (TUSCANY-587) WSDL XSD is read incorrectly.
[ http://issues.apache.org/jira/browse/TUSCANY-587?page=comments#action_12424809 ] Geoff Winn commented on TUSCANY-587: I'm working on this. WSDL XSD is read incorrectly. - Key: TUSCANY-587 URL: http://issues.apache.org/jira/browse/TUSCANY-587 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: All platforms Reporter: Geoff Winn When SDO for C++ reads the WSDL XSD (http://scemas.xmlsoap.org/wsdl/2003-02-11.xsd) some properties that are in fact many valued are identified in the internal model as single valued. -- 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: problem running supplychain sample from the command line
Hi, The readme on the supply chain example seems to be a bit out-of-date. Could someone pls direct me to how to run the sample? Ta Meeraj -Original Message- From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] Sent: 31 July 2006 18:35 To: tuscany-dev@ws.apache.org Subject: RE: problem running supplychain sample from the command line Jeremy, Don't worry, I have found the readme. I will take a look. Ta Meeraj -Original Message- From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] Sent: 31 July 2006 18:24 To: tuscany-dev@ws.apache.org Subject: RE: problem running supplychain sample from the command line How do I run the sample from the command line? -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 31 July 2006 16:29 To: tuscany-dev@ws.apache.org Subject: problem running supplychain sample from the command line When I run the sample from the command line one of two things seem to happen: it either hangs before exiting or it throws an IllegalStateException: jeremy-boynes-computer:/tmp/foo jboynes$ java -jar bin/launcher.jar -- classpath ~/.m2/repository/org/apache/tuscany/samples/sca/sample- supplychain/1.0-SNAPSHOT/sample-supplychain-1.0-SNAPSHOT.jar Main thread Thread[main,5,main] Work thread Thread[pool-1-thread-1,5,main] - Order, submitted, fulfilled, shipped HANGS HERE ^C jeremy-boynes-computer:/tmp/foo jboynes$ java -jar bin/launcher.jar -- classpath ~/.m2/repository/org/apache/tuscany/samples/sca/sample- supplychain/1.0-SNAPSHOT/sample-supplychain-1.0-SNAPSHOT.jar Main thread Thread[main,5,main] java.lang.IllegalStateException: Scope not running [6] at org.apache.tuscany.core.component.scope.AbstractScopeContainer.checkInit (AbstractScopeContainer.java:106) at org.apache.tuscany.core.component.scope.ModuleScopeContainer.getInstance Wrapper(ModuleScopeContainer.java:98) at org.apache.tuscany.core.component.scope.AbstractScopeContainer.getInstan ce(AbstractScopeContainer.java:87) at org.apache.tuscany.core.implementation.PojoAtomicComponent.getTargetInst ance(PojoAtomicComponent.java:105) at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.getInstanc e(JavaTargetInvoker.java:52) at org.apache.tuscany.core.wire.PojoTargetInvoker.invokeTarget (PojoTargetInvoker.java:33) at org.apache.tuscany.core.implementation.java.AsyncJavaTargetInvoker.acces s$301(AsyncJavaTargetInvoker.java:37) at org.apache.tuscany.core.implementation.java.AsyncJavaTargetInvoker $1.run(AsyncJavaTargetInvoker.java:76) at org.apache.tuscany.core.services.work.jsr237.Jsr237WorkScheduler $Jsr237Work.run(Jsr237WorkScheduler.java:210) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWorkM anager$DecoratingWork.run(ThreadPoolWorkManager.java:203) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask (ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:613) I'm guessing that this is some kind of race condition in the work manager. All the tests pass for me (both the ones in core and the one from the supplychain module) but something's not quite right. -- 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] 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: JBI Component for Tuscany
I've had a look at this code now I think we should be able to get it going on the new code base, so I'll start trying to port it over. Thanks for the offer to help, I'm going to need that, and from anyone else who's interested if this binding is to become a part of Tuscany, not only help with the code, but also things like testing, samples, documentation, website updates etc. ...ant On 7/27/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Cool, thx. I'm ready to help in any way I can, so if you have any question on the component or JBI in general, feel free to ask :) Cheers, Guillaume Nodet ant elder wrote: Bringing this into Tuscany sounds really good to me and I'd like to help you do it. I'll go have a look at whats needed to get your current code working with the current Tuscany code... ...ant On 7/27/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Hi, Tuscany and ServiceMix teams ! Some months ago, I have started to develop an SCA JBI Component based on Tuscany. At last ApacheCon EU, I met with Jeremy Boynes (and other Tuscany members) and we talked about working on a better Tuscany integration with ServiceMix, by combining the effort of both communities. We decided to bring that on the devs list, so here it is. First, let me expose for the Tuscany teams who are not familiar with JBI, what a Service Engine provides, and briefly outline how it works. When developing a JBI application, you need: * JBI components (Binding Components or Service Engines) * JBI Service Assemblies Components are installed on the JBI container and act themselves as containers. BCs' role is to communicate with services or clients outside the JBI bus by using a known protocol; this includes HTTP, HTTP+SOAP, JMS, JMS+SOAP, etc... SEs on the other side, are meant to provide the business logic: they are routers, transformers, services, orchestration and they are not tied to any protocol. Service Assemblies (SA) are composed of one or more Service Unit (SU), each SU being targeted to a known component. The component is fully responsible for handling the SU deployment which content is not specified (it will be different from one component to another). Components are thus containers because they will host deployments of several SUs. For Tuscany, the component would be a Service Engine, and I think Service Unit will be SCA modules. The component is responsible for * deploy and manage SU lifecycles * accepting JBI exchanges from the JBI container and process them The current component already handle service unit deployment, but the message exchange processing need to be enhanced / rewritten to provide bi-directional access to the JBI bus. From my understanding of Tuscany, this represent a binding (which is the main thing to complete). The current one uses JAXB2 for the marshalling layer, but maybe you will want to switch to SDO (I choose JAXB2 because I was familiar with it). I would also propose that this JBI component may be better hosted at Tuscany instead of ServiceMix, as a JBI component only relies on the JBI spec, but it will be highly dependant on Tuscany. I found hard to keep on with Tuscany changes during the past months, given the all the refactoring that occured. The code is available at http://svn.apache.org/viewvc/incubator/servicemix/trunk/servicemix-sca/ -- Cheers, Guillaume Nodet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JBI Component for Tuscany
Hi Ant, I can help you wherever you might need an additional hand (in testing, samples, documentation, website updates etc.). - Venkat On 8/1/06, ant elder [EMAIL PROTECTED] wrote: I've had a look at this code now I think we should be able to get it going on the new code base, so I'll start trying to port it over. Thanks for the offer to help, I'm going to need that, and from anyone else who's interested if this binding is to become a part of Tuscany, not only help with the code, but also things like testing, samples, documentation, website updates etc. ...ant On 7/27/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Cool, thx. I'm ready to help in any way I can, so if you have any question on the component or JBI in general, feel free to ask :) Cheers, Guillaume Nodet ant elder wrote: Bringing this into Tuscany sounds really good to me and I'd like to help you do it. I'll go have a look at whats needed to get your current code working with the current Tuscany code... ...ant On 7/27/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Hi, Tuscany and ServiceMix teams ! Some months ago, I have started to develop an SCA JBI Component based on Tuscany. At last ApacheCon EU, I met with Jeremy Boynes (and other Tuscany members) and we talked about working on a better Tuscany integration with ServiceMix, by combining the effort of both communities. We decided to bring that on the devs list, so here it is. First, let me expose for the Tuscany teams who are not familiar with JBI, what a Service Engine provides, and briefly outline how it works. When developing a JBI application, you need: * JBI components (Binding Components or Service Engines) * JBI Service Assemblies Components are installed on the JBI container and act themselves as containers. BCs' role is to communicate with services or clients outside the JBI bus by using a known protocol; this includes HTTP, HTTP+SOAP, JMS, JMS+SOAP, etc... SEs on the other side, are meant to provide the business logic: they are routers, transformers, services, orchestration and they are not tied to any protocol. Service Assemblies (SA) are composed of one or more Service Unit (SU), each SU being targeted to a known component. The component is fully responsible for handling the SU deployment which content is not specified (it will be different from one component to another). Components are thus containers because they will host deployments of several SUs. For Tuscany, the component would be a Service Engine, and I think Service Unit will be SCA modules. The component is responsible for * deploy and manage SU lifecycles * accepting JBI exchanges from the JBI container and process them The current component already handle service unit deployment, but the message exchange processing need to be enhanced / rewritten to provide bi-directional access to the JBI bus. From my understanding of Tuscany, this represent a binding (which is the main thing to complete). The current one uses JAXB2 for the marshalling layer, but maybe you will want to switch to SDO (I choose JAXB2 because I was familiar with it). I would also propose that this JBI component may be better hosted at Tuscany instead of ServiceMix, as a JBI component only relies on the JBI spec, but it will be highly dependant on Tuscany. I found hard to keep on with Tuscany changes during the past months, given the all the refactoring that occured. The code is available at http://svn.apache.org/viewvc/incubator/servicemix/trunk/servicemix-sca/ -- Cheers, Guillaume Nodet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tuscany weekly IRC chat log (July-31-2006)
Here's the IRC log from yesterdays scheduled chat.
The main things talked about were what happened with Tuscany at OSCON (the
talk was ok, not so many at the BOF). That Tuscany has a new website was
mentioned (go have a look!). Most of the rest of chat was about modularity
and releases related to this email thread:
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05658.html
I think it sounds like most agree a single monolithic download of everything
and all the dependencies could get real big. I think there was some
agreement that being able to build individual parts or specific
distributions from a src release would be good. Hard to summarize what else
was said on this, probably best to go read the chat and emails.
(other discussions were going on before and after this scheduled chat, i'll
get summaries of those posted in separate emails)
jboynes it's 8:30 - how about we pick this up after?
ant componentType [{http://www.osoa.org/xmlns/sca/1.0}componentType]
* kgoodson_away is now known as kgoodson
ant sure ok , if there's other things to talk about
jboynes just wanted to give others a chance :-)
jboynes there's stuff like comments from oscon
jboynes there's a couple of mail threads
jboynes the website went live
jboynes anything else interesting happening?
ant well no one is speaking up ... getting some
extensions/containers/bindings to go is top of my list right now
lresende it would be great if we could hear little bit from the folks that
went to OSCON
cr22rc yup
ant also how about what to do about Tomcat or Jetty as thats come up on a
few threads now
jboynes I'd say it was a fairly quiet conference
jboynes lots of talk about open source; a lot of the technical stuff was
on stuff like Rub
jboynes Ruby
jboynes there were about 80-100 people in our session
lresende 80-100 is a good size for OSCON size ?
jboynes our BOFs were quiet - just a couple of people from outside the
project
jboynes the room was about 2/3 full which isn't bad I think
kgoodson hi, sorry, was on the 'phone, my perspective was that the people
I met were more interested in programming language advancements (ruby,
rails, ...) than broader programming architectures
* Venkat has quit IRC (Read error: 110 (Connection timed out))
jboynes yeah
jboynes It was also quieter than I have seen in the past
ant I have to go right on 5:30, if oscon is done could we move on to the
next topic?
lresende yes
ant great stuff with the new website rick and everyone involved
jboynes I have a spec call at 9 so may be a little distracted as well
cr22rc many contributers
cr22rc sorry did not get it up for oscon
jboynes thanks for doing it
ant lresende has mentioned it on our blog so some people will notice
ant which of the open email threads did you want to discuss Jeremy? or can
i start asking more extension questions now?
jboynes we need to keep updating the website - keeping the content fresh
jboynes what about the modularity thread?
cr22rc change the background color ? :-)
kgoodson i plan to expand the SDO java stuff as my next activity, i'm
just trying to complete a paper on SDO as soon as I can, and I expect that
work to produce some useful material for the website
jboynes any thoughts on modularity?
ant ok, with having more separate releases isn't the incubator voting
going to be an issue?
* halehM has joined #tuscany
jboynes maybe - I think it will depend on how much and how often
jboynes if we get the legal issues sorted out then it really comes down to
our mentors
lresende so, with this modularity, you want to acomplish components
releases ? like SCA releases not together with SDO releases ?
ant the C++ M1 took ages and only happened when I went bothering people.
If we have even a few more individual releases for Java
modules/distributions I think it will get real hard to get the votes
jboynes I'm not sure the two are directly related
jboynes C++ and Java that is
lresende ok
ant yes
lresende btw, did we get the C++ M1 released ? i don't see it mentioned on
the website... (download page)... and if so, i wan to post a note on the
blog as well...
ant (opps, wrong window sorry)
jboynes just done today
lresende i see, thanks...
cr22rc by more modular are we talking also breaking sca down more ?
webservices ajax bindings tomcat, standalone ?
jboynes both - proposal 1 was to allow separate releases of sdo, das, sca,
etc.
jboynes proposal 2 was to support breaking down sca
cr22rc proposal 1 seems ok to me but sca might still have sdo and das in
it ? or you want to keep it totally seperate?
jboynes no, I think sca could include those
halehM It would be a good idea to have the 3 separated
jboynes or perhaps the sdo databinding part of sca would include sdo
jboynes but I don't want sdo have to wait for sca or vice versa
cr22rc IMO I think proposal 1 sounds good something I thought we'd always
mature to anyway.
* Venkat has joined #tuscany
jboynes any other thoughts?
* kg has joined #tuscany
* kgoodson has quit IRC (Chatzilla 0.9.73 [Firefox
Re: Karma for Brent
+1 Besides working in general on DAS, Brent helped out a lot with DAS issues with getting Big Bank running for M1. Kevin Williams wrote: I would like to recommend Brent for committership. Brent has made invaluable contributions to the DAS and has been a consistent provider of quality patches since the inception of this project. Here is my +1 for Brent. --Kevin - 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]
[jira] Created: (TUSCANY-588) Update site for C++ M1 release
Update site for C++ M1 release -- Key: TUSCANY-588 URL: http://issues.apache.org/jira/browse/TUSCANY-588 Project: Tuscany Issue Type: New Feature Components: Website Affects Versions: Cpp-M1 Reporter: Pete Robbins Assigned To: Pete Robbins Fix For: Cpp-M1 -- 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: problem running supplychain sample from the command line
There were actually two symptoms: sometimes I would get this exception, sometimes it would just hang after printing the messages (which I think Rick mentioned as well). -- Jeremy On Aug 1, 2006, at 5:30 AM, Meeraj Kunnumpurath wrote: Thanks, I have managed reproduce the problem reported by Jeremy, java.lang.IllegalStateException: Scope not running [6] at org.apache.tuscany.core.component.scope.AbstractScopeContainer.checkIn it (AbstractScopeContainer.java:106) at org.apache.tuscany.core.component.scope.ModuleScopeContainer.getInstan ce Wrapper(ModuleScopeContainer.java:98) at org.apache.tuscany.core.component.scope.AbstractScopeContainer.getInst an ce(AbstractScopeContainer.java:87) at org.apache.tuscany.core.implementation.PojoAtomicComponent.getTargetIn st ance(PojoAtomicComponent.java:105) at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.getInsta nc e(JavaTargetInvoker.java:52) at org.apache.tuscany.core.wire.PojoTargetInvoker.invokeTarget (PojoTargetIn voker.java:33) at org.apache.tuscany.core.implementation.java.AsyncJavaTargetInvoker.acc es s$301(AsyncJavaTargetInvoker.java:37) at org.apache.tuscany.core.implementation.java.AsyncJavaTargetInvoker $1.run (AsyncJavaTargetInvoker.java:76) at org.apache.tuscany.core.services.work.jsr237.Jsr237WorkScheduler $Jsr237W ork.run(Jsr237WorkScheduler.java:210) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWor kM anager$DecoratingWork.run(ThreadPoolWorkManager.java:203) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask (ThreadPoolExecuto r.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.ja va:675) at java.lang.Thread.run(Thread.java:595) Ta Meeraj -Original Message- From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] Sent: 01 August 2006 13:20 To: tuscany-dev@ws.apache.org Subject: RE: problem running supplychain sample from the command line Ta -Original Message- From: Rick [mailto:[EMAIL PROTECTED] Sent: 01 August 2006 13:19 To: tuscany-dev@ws.apache.org Subject: Re: problem running supplychain sample from the command line Hello, Not an expert on this particular demo, but I just checked in a bat file run.bat that seems to run it for me. This is the output I see: E:\dev\tuscany\java\samples\sca\supplychain Main thread Thread[main,5,main] Work thread Thread[pool-1-thread-1,5,main] - Order, submitted, fulfilled, shipped It hangs for me though at the end and I think there is an issue that may have fixed since I last did an update. The bat file could be easily converted to a linux shell script. Just haven't fired up my linux box yet. Anyway hope this helps out. Meeraj Kunnumpurath wrote: Hi, The readme on the supply chain example seems to be a bit out-of-date. Could someone pls direct me to how to run the sample? Ta Meeraj -Original Message- From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] Sent: 31 July 2006 18:35 To: tuscany-dev@ws.apache.org Subject: RE: problem running supplychain sample from the command line Jeremy, Don't worry, I have found the readme. I will take a look. Ta Meeraj -Original Message- From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] Sent: 31 July 2006 18:24 To: tuscany-dev@ws.apache.org Subject: RE: problem running supplychain sample from the command line How do I run the sample from the command line? -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 31 July 2006 16:29 To: tuscany-dev@ws.apache.org Subject: problem running supplychain sample from the command line When I run the sample from the command line one of two things seem to happen: it either hangs before exiting or it throws an IllegalStateException: jeremy-boynes-computer:/tmp/foo jboynes$ java -jar bin/ launcher.jar -- classpath ~/.m2/repository/org/apache/tuscany/samples/sca/sample- supplychain/1.0-SNAPSHOT/sample-supplychain-1.0-SNAPSHOT.jar Main thread Thread[main,5,main] Work thread Thread[pool-1-thread-1,5,main] - Order, submitted, fulfilled, shipped HANGS HERE ^C jeremy-boynes-computer:/tmp/foo jboynes$ java -jar bin/ launcher.jar -- classpath ~/.m2/repository/org/apache/tuscany/samples/sca/sample- supplychain/1.0-SNAPSHOT/sample-supplychain-1.0-SNAPSHOT.jar Main thread Thread[main,5,main] java.lang.IllegalStateException: Scope not running [6] at org.apache.tuscany.core.component.scope.AbstractScopeContainer.checkI n it (AbstractScopeContainer.java:106) at org.apache.tuscany.core.component.scope.ModuleScopeContainer.getInsta n ce Wrapper(ModuleScopeContainer.java:98) at org.apache.tuscany.core.component.scope.AbstractScopeContainer.getIns t an ce(AbstractScopeContainer.java:87) at org.apache.tuscany.core.implementation.PojoAtomicComponent.getTargetI n st ance(PojoAtomicComponent.java:105) at
Re: SCA Tools
On Aug 1, 2006, at 12:43 AM, Venkata Krishnan wrote: Jim :-))).. Please help me understand the scope of not required. If something is not required then why have it in the first place? Are these things no longer relevant to the current Tuscany-Java? Jim is echoing a goal that SCA should be simple enough to use and configure that additional tooling should not be required. For example, I should be able to look at a SCDL file and understand what it is doing, or I should be able to work with simple Java classes and have the runtime figure out what to do. That's not to say that tooling cannot help - a specialized tool can make that SCDL file easier to view or edit, an IDE can make editing Java easier. But tools should be there to assist rather than be required because the underlying technology is so complex. Take for example, java2wsdl. If I am a simple Java developer, there is a good chance I do not know WSDL and have no interest in being forced to learn it. But the machinery here needs WSDL to interoperate with other systems. We can put WSDL in the user's face by having a tool that generates WSDL that they need to run as part of a build; alternatively, we can have the runtime handle all the WSDL stuff under the covers leaving the user in their Java comfort-zone. I think the latter is better, although we will still need the tool for those users who do want to use WSDL explicitly. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Karma for Brent
+1 On Monday July 31 2006 11:57 pm, Kevin Williams wrote: I would like to recommend Brent for committership. Brent has made invaluable contributions to the DAS and has been a consistent provider of quality patches since the inception of this project. Here is my +1 for Brent. --Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 F:781-902-8001 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Karma for Raymond
+1 On Monday July 31 2006 10:18 pm, Jim Marino wrote: I'd like to propose we make Raymond a committer. Normally, I would list some of the things a candidate has done for the community but with Raymond he has done so much I wouldn't know where to begin. So, here's my +1 form making Raymond a committer. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 F:781-902-8001 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Karma for Brent
+1 from me. Jim On Jul 31, 2006, at 8:57 PM, Kevin Williams wrote: I would like to recommend Brent for committership. Brent has made invaluable contributions to the DAS and has been a consistent provider of quality patches since the inception of this project. Here is my +1 for Brent. --Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Composite classpaths, was: How to use extensions with the standalone launcher?
On Jul 31, 2006, at 11:42 PM, Jim Marino wrote:
An end user application developer could write some type of library
that gets reused by different composites. We should have a
mechanism that supports this without resorting to maven. I think we
should have some type of resolver abstraction, one implementation
being a maven downloader.
I agree.
We need an abstraction for dependent artifact and a way of locating
and resolving them; using a Maven repository would be one concrete
implementation of that abstraction.
There are a couple of other options we could also provide, based
off of OSGi semantics:
1. Allow a jar to specify its dependencies using pure OSGi
manifest entries when the composite is packaged as a bundle and
deployed to an OSGI environment
2. Allow the SCDL to specify dependencies using OSGI semantics.
These would then be baked down to whatever packaging the host
environment supported, perhaps through a pre-deploy step
3.As part of #2, have a way to specify a maven bundle and have
the pre-deployer pul it from maven and repackage it.
Generally I don't like pre-packagers but that may be the price
people have to pay for deploying on host environments with
problematic classloading semantics - e.g. J2EE app servers. In an
OSGi or jar launcher environment, things should just work without
a predeploy step.
These seem like alternatives. If the user wants to use OSGi
semantics then this would be a way to support them. However, there
are a lot of things out there that do not have OSGi manifests and
we need to be able to support them two.
That's what #2 would be used for as it is not dependent on OSGi
artifacts such as bundles. A SCDL artifact would specify the
dependencies and they could be resolved to whatever physical
packaging the host platform supports/
This seems like it can be implemented on top of a repository for OSGi
artifacts or a repository of Maven artifacts - this sounds good.
Also, these only work if the composite is packaged as a bundle and
I think that it's important to allow people to deploy composites
that are simple XML SCDL files (no archive involved). That means
we need a way in the SCDL to be able to specify what the
dependencies are.
#2 could also work with a file system through some type of custom
resolver mentioned above.
So the key here is the abstraction for artifact resolution. The
interface I had proposed before was:
interface CompositeRepository {
URL locate(String name);
URL locate(String groupId, String artifactId, String version,
String identifier);
}
We probably need to extend this to capture the formal concept of an
Artifact so I would recast this as:
class Artifact {
String group; // a conceptual grouping of artifacts such
as publisher
String name;// the name of the artifact
String version; // the version of the artifact
String classifier; // a classifier such as hardware platform or
language
boolean optional; // whether the artifact is required
}
class ResolvedArtifact extends Artifact {
URL url;// a URL where the artifact can be obtained
(typically a file: URL)
CollectionResolvedArtifact dependencies; // list of
dependencies the artifact has
}
interface ArtifactRepository {
ResolvedArtifact resolve(String name); // lookup based on a
simple string supplied by the user
ResolvedArtifact resolve(Artifact artifact); // lookup based on
explicit information
}
I think this is general enough to cover both Maven and OSGi artifact
naming schemes (and hopefully more).
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Karma for Raymond
+1 - looking forward to having him on board. -- Jeremy On Jul 31, 2006, at 7:18 PM, Jim Marino wrote: I'd like to propose we make Raymond a committer. Normally, I would list some of the things a candidate has done for the community but with Raymond he has done so much I wouldn't know where to begin. So, here's my +1 form making Raymond a committer. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 Test generator
Venkata: I was planning on at least using the WSDL2Java M1 tool to generate the java interface, but I'm not sure of the value beyond that. Ant: To generate the dummy data, The code in 419 definitly looks like it can be of alot of use. Thanks. -David On 8/1/06, ant elder [EMAIL PROTECTED] wrote: Hi David, yes this sounds like something that could be useful. How do you plan on generating the dummy data? There's already some code for this that Venkat has done for creating empty XML instances from a WSDL, see TUSCANY-419, hopefully you'll be able to reuse and enhance that code. ...ant On 7/31/06, David Wheeler [EMAIL PROTECTED] wrote: Hi, I've been working, with Raymond's help, on a system to generate a test based around a given wsdl. The system would generate not just classes, but dummy data to be sent using SCA axis bindings. Checking that the data was successfully bounced from client to server and back. Does this sound like a good idea? Thoughts? -David Wheeler.
XPath 2.0 engine?
The recursive changes include support for complex properties accessed via XPath 2.0 expressions and the only XPath 2.0 engine I have found is Saxon (http://saxon.sourceforge.net) - others such as the one in the JRE and Jaxen only seem to support XPath 1.0. I have a couple of concerns over Saxon due to the MPL license and the dual-licensing they use to support a commercial implementation - does anyone know of an alternative? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Karma for Raymond
+1 On 7/31/06, Jim Marino [EMAIL PROTECTED] wrote: I'd like to propose we make Raymond a committer. Normally, I would list some of the things a candidate has done for the community but with Raymond he has done so much I wouldn't know where to begin. So, here's my +1 form making Raymond a committer. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Webservice via Axis2 in Tomcat.
I'm ok with that. I just thought we may want ones without axis. But I'll put it in the others, if I hear nothing different. Jeremy Boynes wrote: Can we just add the binding to the existing distros? -- Jeremy On Aug 1, 2006, at 9:19 AM, Rick wrote: I'm currently in the process of trying to get running a service using the Axis2 web service binding in Tomcat environment. The approach I'm taking is to create a new distro based off of Ken Tam's web one and add the current Axis 2.0 binding. I've revived the Hellowordlws from M1 sample and fixed up the SCDL. Seem reasonable ? This may not be the end all but I'm hoping it will get some web services support reasonably soon. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Webservice via Axis2 in Tomcat.
How about the JavaScript container be included by default as well then? Would make it easier to run samples but this brings up all the kitchen sink distro type questions being discussed on the modularity thread. ...ant On 8/1/06, cr22rc [EMAIL PROTECTED] wrote: I'm ok with that. I just thought we may want ones without axis. But I'll put it in the others, if I hear nothing different. Jeremy Boynes wrote: Can we just add the binding to the existing distros? -- Jeremy On Aug 1, 2006, at 9:19 AM, Rick wrote: I'm currently in the process of trying to get running a service using the Axis2 web service binding in Tomcat environment. The approach I'm taking is to create a new distro based off of Ken Tam's web one and add the current Axis 2.0 binding. I've revived the Hellowordlws from M1 sample and fixed up the SCDL. Seem reasonable ? This may not be the end all but I'm hoping it will get some web services support reasonably soon. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Introspection of JavaScript components
I've had a go at adding support for introspection of JavaScript components
and wondered if anyone had any comments.
As JavaScript is untyped and doesn't have the concept of annotations its not
possible to have this work as well as with Java components. How I've done it
is to have the script define a object named SCA which defines the component
configuration.
There's a sample introspectable script at:
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/containers/container.javascript/src/test/resources/org/apache/tuscany/container/javascript/function/IntrospectableHelloWorld.js
There'd be nested objects defining any references and properties, and WSDL
interfaces could be described something like:
SCA = {
'wsdlServiceName' : 'myservice'
'wsdlPortName' : 'myPort'
}
Comments? I think this makes script components simpler than using the
.componentType side file, but what do others think?
...ant
Re: Webservice via Axis2 in Tomcat.
I mostly agree, but one of the big benefits for Web services is the JavaScript E4X support. With that and when TUSCANY-419 and the magic databinding stuff is done this is going to make JavaScript components really really useful to use with WS i think. All the old WS debates about databindings and XML to Java mappings disappear as XML becomes really easy. ...ant On 8/1/06, Jeremy Boynes [EMAIL PROTECTED] wrote: I think there's a difference. Web services play a prominent role in the SCA specs and are likely to be used by most people which makes a good case for including them in distributions by default. The JavaScript stuff, although useful, is not something covered by the spec at all and is likely to be used by a different audience. For those, I would suggest that we should create a new distribution, one aimed at people doing REST, JSON, JavaScript stuff; that may or may not include web services depending on what users want. That would give us three distributions: * standalone environment * web-app environment with web services * web-app environment with JS-type stuff -- Jeremy On Aug 1, 2006, at 9:57 AM, ant elder wrote: How about the JavaScript container be included by default as well then? Would make it easier to run samples but this brings up all the kitchen sink distro type questions being discussed on the modularity thread. ...ant On 8/1/06, cr22rc [EMAIL PROTECTED] wrote: I'm ok with that. I just thought we may want ones without axis. But I'll put it in the others, if I hear nothing different. Jeremy Boynes wrote: Can we just add the binding to the existing distros? -- Jeremy On Aug 1, 2006, at 9:19 AM, Rick wrote: I'm currently in the process of trying to get running a service using the Axis2 web service binding in Tomcat environment. The approach I'm taking is to create a new distro based off of Ken Tam's web one and add the current Axis 2.0 binding. I've revived the Hellowordlws from M1 sample and fixed up the SCDL. Seem reasonable ? This may not be the end all but I'm hoping it will get some web services support reasonably soon. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Tools
Hi Jeremy / Jim, first thanks for those answers. I am able to understand your perspectives. But just that one more question. If we do not generate a WSDL what do we publish for clients who which to connect to this component's service? How would client applications know about the service's interfaces and semantics? Thanks - Venkat On 8/1/06, Jim Marino [EMAIL PROTECTED] wrote: On Aug 1, 2006, at 7:27 AM, Jeremy Boynes wrote: On Aug 1, 2006, at 12:43 AM, Venkata Krishnan wrote: Jim :-))).. Please help me understand the scope of not required. If something is not required then why have it in the first place? Are these things no longer relevant to the current Tuscany-Java? Jim is echoing a goal that SCA should be simple enough to use and configure that additional tooling should not be required. For example, I should be able to look at a SCDL file and understand what it is doing, or I should be able to work with simple Java classes and have the runtime figure out what to do. In the spec group we called this type of user the notepad developer. I think this is an important goal for Tuscany as well. For the SCDL I would probably go further and say in most cases it should be trivial to hand-edit. That's not to say that tooling cannot help - a specialized tool can make that SCDL file easier to view or edit, an IDE can make editing Java easier. But tools should be there to assist rather than be required because the underlying technology is so complex. Take for example, java2wsdl. If I am a simple Java developer, there is a good chance I do not know WSDL and have no interest in being forced to learn it. But the machinery here needs WSDL to interoperate with other systems. We can put WSDL in the user's face by having a tool that generates WSDL that they need to run as part of a build; alternatively, we can have the runtime handle all the WSDL stuff under the covers leaving the user in their Java comfort- zone. I think the latter is better, although we will still need the tool for those users who do want to use WSDL explicitly. Both cases I think are important to support (hence not required), although I think we should make more effort on the latter since, as Jeremy said, most users probably don't have a need to see the WSDL in bottom-up approaches. For top-down development, we will need to support dealing with WSDL but should make that as straightforward as possible. On the general question of whether to have something if it is not required, I imagine most extensions in Tuscany will follow this pattern. Jim -- 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]
[ANNOUNCE] Tuscany C++ Milestone 1 Release
The Apache Tuscany community is pleased to announce its first C++ milestone release. -- Pete Congratulations! We hope to follow this up soon with a PHP SDO release exploiting the latest C++ code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Introspection of JavaScript components
This looks cool.
Graham Charters has been looking at similar things for a PHP
programming model - if you haven't had chance yet you should sync up
with him.
--
Jeremy
On Aug 1, 2006, at 10:08 AM, ant elder wrote:
I've had a go at adding support for introspection of JavaScript
components
and wondered if anyone had any comments.
As JavaScript is untyped and doesn't have the concept of
annotations its not
possible to have this work as well as with Java components. How
I've done it
is to have the script define a object named SCA which defines the
component
configuration.
There's a sample introspectable script at:
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/
containers/container.javascript/src/test/resources/org/apache/
tuscany/container/javascript/function/IntrospectableHelloWorld.js
There'd be nested objects defining any references and properties,
and WSDL
interfaces could be described something like:
SCA = {
'wsdlServiceName' : 'myservice'
'wsdlPortName' : 'myPort'
}
Comments? I think this makes script components simpler than using the
.componentType side file, but what do others think?
...ant
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Introspection of JavaScript components
Yea this is definitely simpler than a side file. I came across this
but never tried it out a few years back:
http://dotnetjunkies.com/WebLog/anoras/archive/2004/08/09/21502.aspx
Apparently it provides a way to introspect the script to retrieve
Javadoc style annotations but the way you have may be better and
simpler.
Jim
On Aug 1, 2006, at 10:08 AM, ant elder wrote:
I've had a go at adding support for introspection of JavaScript
components
and wondered if anyone had any comments.
As JavaScript is untyped and doesn't have the concept of
annotations its not
possible to have this work as well as with Java components. How
I've done it
is to have the script define a object named SCA which defines the
component
configuration.
There's a sample introspectable script at:
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/
containers/container.javascript/src/test/resources/org/apache/
tuscany/container/javascript/function/IntrospectableHelloWorld.js
There'd be nested objects defining any references and properties,
and WSDL
interfaces could be described something like:
SCA = {
'wsdlServiceName' : 'myservice'
'wsdlPortName' : 'myPort'
}
Comments? I think this makes script components simpler than using the
.componentType side file, but what do others think?
...ant
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to use extensions with the standalone launcher?
FWIW, I think I've been running into a problem at build time because of this exact issue. There's a bit of code in the javascript sample HelloWorldTestCase.java test that gathers up all of the META-INF/sca/default.scdl resources it can find. The test then throws away the first resource in the enumeration assuming it's the application's default.scdl and not the extension's default.scdl. ant elder wrote: I guess it somehow needs to find the URL to the default.scdl for the JavaScript extension, but thats just in a jar on the classpath and there's lots of default.scdl resources on the class path so how does it know which is the JavaScript one? And the once it has that URL it isn't real obvious (to me) how you could use that from the testcase to get the extension registered with the runtime. ...ant While the build generally succeeds, every once in a while the test fails with an UnrecognizedElementException on implementation.js. I added a System.out.println to the test to show which of the resources was thrown away in the following code snippet and found that the extension scdl can be discarded instead of the application scdl. (I'm assuming this is because enumeration that comes back from getResources doesn't have a specfied order.) At this point I guess I have to wonder if the name used for the extensions' scdl should be something different from the default application scdl name? It seems like it might be nice to do something like gather up like all of the visible META-INF/sca/extension.scdl resources and add them to the runtime as extensions. I don't believe this would be at odds with the current extensions mechanism in the DirectoryScanExtender if it went after extension.scdl instead of default.scdl. Just a thought. -- Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 Test generator
David, Axis2's WSDL2Java has an option to generate a junit test case. We could make sure that it works now and enhance that as appropriate. -- dims On 8/1/06, David Wheeler [EMAIL PROTECTED] wrote: Venkata: I was planning on at least using the WSDL2Java M1 tool to generate the java interface, but I'm not sure of the value beyond that. Ant: To generate the dummy data, The code in 419 definitly looks like it can be of alot of use. Thanks. -David On 8/1/06, ant elder [EMAIL PROTECTED] wrote: Hi David, yes this sounds like something that could be useful. How do you plan on generating the dummy data? There's already some code for this that Venkat has done for creating empty XML instances from a WSDL, see TUSCANY-419, hopefully you'll be able to reuse and enhance that code. ...ant On 7/31/06, David Wheeler [EMAIL PROTECTED] wrote: Hi, I've been working, with Raymond's help, on a system to generate a test based around a given wsdl. The system would generate not just classes, but dummy data to be sent using SCA axis bindings. Checking that the data was successfully bounced from client to server and back. Does this sound like a good idea? Thoughts? -David Wheeler. -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Tools
On Aug 1, 2006, at 10:24 AM, Venkata Krishnan wrote: Hi Jeremy / Jim, first thanks for those answers. I am able to understand your perspectives. But just that one more question. If we do not generate a WSDL what do we publish for clients who which to connect to this component's service? In most cases (i.e. communication within an SCA system) we may never need to generate WSDL. In some cases we may not be able to at all, e.g. for local services which are not bound by WSDL constraints. That said, when publishing a service over a web service binding for consumption by a client outside an SCA system, we will likely have to generate a WSDL. For most cases, the runtime should be able to handle this generation transparently to users or be able to accept a WSDL in a top-down scenario. How would client applications know about the service's interfaces and semantics? It depends. If it is a client using SCA, then it resorts to whatever the interface language is - e.g. Java interfaces. Under the covers, it is up to the binding extension to sort things out. Jim Thanks - Venkat On 8/1/06, Jim Marino [EMAIL PROTECTED] wrote: On Aug 1, 2006, at 7:27 AM, Jeremy Boynes wrote: On Aug 1, 2006, at 12:43 AM, Venkata Krishnan wrote: Jim :-))).. Please help me understand the scope of not required. If something is not required then why have it in the first place? Are these things no longer relevant to the current Tuscany-Java? Jim is echoing a goal that SCA should be simple enough to use and configure that additional tooling should not be required. For example, I should be able to look at a SCDL file and understand what it is doing, or I should be able to work with simple Java classes and have the runtime figure out what to do. In the spec group we called this type of user the notepad developer. I think this is an important goal for Tuscany as well. For the SCDL I would probably go further and say in most cases it should be trivial to hand-edit. That's not to say that tooling cannot help - a specialized tool can make that SCDL file easier to view or edit, an IDE can make editing Java easier. But tools should be there to assist rather than be required because the underlying technology is so complex. Take for example, java2wsdl. If I am a simple Java developer, there is a good chance I do not know WSDL and have no interest in being forced to learn it. But the machinery here needs WSDL to interoperate with other systems. We can put WSDL in the user's face by having a tool that generates WSDL that they need to run as part of a build; alternatively, we can have the runtime handle all the WSDL stuff under the covers leaving the user in their Java comfort- zone. I think the latter is better, although we will still need the tool for those users who do want to use WSDL explicitly. Both cases I think are important to support (hence not required), although I think we should make more effort on the latter since, as Jeremy said, most users probably don't have a need to see the WSDL in bottom-up approaches. For top-down development, we will need to support dealing with WSDL but should make that as straightforward as possible. On the general question of whether to have something if it is not required, I imagine most extensions in Tuscany will follow this pattern. Jim -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to use extensions with the standalone launcher?
On Aug 1, 2006, at 11:28 AM, Matthew Sykes wrote: FWIW, I think I've been running into a problem at build time because of this exact issue. There's a bit of code in the javascript sample HelloWorldTestCase.java test that gathers up all of the META-INF/sca/default.scdl resources it can find. The test then throws away the first resource in the enumeration assuming it's the application's default.scdl and not the extension's default.scdl. I think this is problematic - putting all the runtime code on the application classpath is asking for trouble. ant elder wrote: I guess it somehow needs to find the URL to the default.scdl for the JavaScript extension, but thats just in a jar on the classpath and there's lots of default.scdl resources on the class path so how does it know which is the JavaScript one? And the once it has that URL it isn't real obvious (to me) how you could use that from the testcase to get the extension registered with the runtime. ...ant While the build generally succeeds, every once in a while the test fails with an UnrecognizedElementException on implementation.js. I added a System.out.println to the test to show which of the resources was thrown away in the following code snippet and found that the extension scdl can be discarded instead of the application scdl. (I'm assuming this is because enumeration that comes back from getResources doesn't have a specfied order.) At this point I guess I have to wonder if the name used for the extensions' scdl should be something different from the default application scdl name? It seems like it might be nice to do something like gather up like all of the visible META-INF/sca/ extension.scdl resources and add them to the runtime as extensions. I don't believe this would be at odds with the current extensions mechanism in the DirectoryScanExtender if it went after extension.scdl instead of default.scdl. I don't think we want different types of composite for extensions and other things. We're trying to add extensions into test cases without defining an extension mechanism so it's not surprising things are not working properly. Perhaps we should back up a little and think about what we are trying to achieve. Putting a user hat on, here are the things that I would like to do: 1) Unit test a component without needing any SCA runtime infrastructure. I don't need Tuscany classes on the classpath to compile my component and I don't want to pollute my test environment with them. All I should need is my code and my test framework (for example, TestNG). 2) Function test a component in the SCA runtime. I have installed and configured Tuscany somewhere, adding in the extensions that I need. I want to test code as if it was running in that environment. Ideally I would like the runtime to boot quickly inside my test client but I would also like to be able to deploy the component to an already running environment. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to use extensions with the standalone launcher?
How about until we have a way to do extensions properly to fix the problem Matthew is seeing the testcase could determine which is the application default.scdl by seeing if the resource URL starts with the current working directory which it can get from System.getProperty(user.dir)? ...ant On 8/1/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Aug 1, 2006, at 11:28 AM, Matthew Sykes wrote: FWIW, I think I've been running into a problem at build time because of this exact issue. There's a bit of code in the javascript sample HelloWorldTestCase.java test that gathers up all of the META-INF/sca/default.scdl resources it can find. The test then throws away the first resource in the enumeration assuming it's the application's default.scdl and not the extension's default.scdl. I think this is problematic - putting all the runtime code on the application classpath is asking for trouble. ant elder wrote: I guess it somehow needs to find the URL to the default.scdl for the JavaScript extension, but thats just in a jar on the classpath and there's lots of default.scdl resources on the class path so how does it know which is the JavaScript one? And the once it has that URL it isn't real obvious (to me) how you could use that from the testcase to get the extension registered with the runtime. ...ant While the build generally succeeds, every once in a while the test fails with an UnrecognizedElementException on implementation.js. I added a System.out.println to the test to show which of the resources was thrown away in the following code snippet and found that the extension scdl can be discarded instead of the application scdl. (I'm assuming this is because enumeration that comes back from getResources doesn't have a specfied order.) At this point I guess I have to wonder if the name used for the extensions' scdl should be something different from the default application scdl name? It seems like it might be nice to do something like gather up like all of the visible META-INF/sca/ extension.scdl resources and add them to the runtime as extensions. I don't believe this would be at odds with the current extensions mechanism in the DirectoryScanExtender if it went after extension.scdl instead of default.scdl. I don't think we want different types of composite for extensions and other things. We're trying to add extensions into test cases without defining an extension mechanism so it's not surprising things are not working properly. Perhaps we should back up a little and think about what we are trying to achieve. Putting a user hat on, here are the things that I would like to do: 1) Unit test a component without needing any SCA runtime infrastructure. I don't need Tuscany classes on the classpath to compile my component and I don't want to pollute my test environment with them. All I should need is my code and my test framework (for example, TestNG). 2) Function test a component in the SCA runtime. I have installed and configured Tuscany somewhere, adding in the extensions that I need. I want to test code as if it was running in that environment. Ideally I would like the runtime to boot quickly inside my test client but I would also like to be able to deploy the component to an already running environment. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build and distribution modularity
Maybe we should take a conservative approach initially (and this is probably something similar to #3, #4). As long as milestones are not too infrequent then I think we can release the three subprojects on the same schedule. Users should be able to easily pull SCA , SDO and DAS components independently from a distribution. Also, it does not seem too much an inconvenience for those interested in working from the head to pull and build the entire project. --Kevin Rick wrote: In theory I like what you're saying Jeremy, but in reality I'm kinding of siding with Ant concerns. Not sure how it will scale as we add may extensions and all the possible combinations. Also all the distros add administration, documentation, issue tracking etc. I certainly can see a separate SDO and possibly a separate DAS distro as I can see the use case for that and it easily explained to the end user why they are a separate distro for them. With regard to SCA I think a goal of building them separately is good, having some test that just run with each extension is good. But maybe for the SCA distro it would be easier to have the full always the full distro and some how configure to only deploy and run the pieces and parts the user wants? ant elder wrote: I like proposals 3 and 4 - it should be easy to build a distribution and we need to test it properly - +1! And having some sort of daily build would be great whatever ends up happening here. In general the idea of having something more than a single monolithic distribution sounds good, I've a few concerns (version incompatibilities, hard for newbies to choose a distribution, some things may become 2nd class parts of the Tuscany) which I'll leave till there's more detail, but one big problem I can see is that having lots of separate module/distribution releases is will make it _really_ hard to get all the release votes through the incubator PMC. Wont that be a bit unworkable while we're still incubating? ...ant On 7/29/06, Jeremy Boynes [EMAIL PROTECTED] wrote: We've talked about this in the past on several threads but I would like to bring this to conclusion. We've had a couple of issues recently where bits of the build were failing due to environmental issues (e.g. java.net repo availability, xerces versions on some JRE) and we are about to start adding more dependencies with the integration of the Axis2 module, the JSON modules, web containers, etc. which will make this worse. I want to try and sum up here where we are at and make some proposals for going forward. == Proposal 1: Support independent build and distributions at the top level Rationale: Users interested in different technologies such as SCA and SDO do not want to have to build all of them together. This also gives a false impression that there are strong dependencies between them. What this means: Structure the build such that someone can check out any directory under java and build it on its own. For example, if I check out just sdo I would expect the build to work from that directory. All dependencies (e.g. on spec) would be resolved through the mvn repository. This will require each technology to upload unstable artifacts (aka SNAPSHOTs) to the mvn repository on some periodic basis. These are not releases and do not need to be voted on. Each technology will produce their own distribution. This may be a user-installable distro (e.g. for sca or sdo) or may just be a set of jars to be published in the mvn repo (e.g. for spec). == Proposal 2: Break sca down into runtime libraries, distributions and extensions Rationale: SCA involves a lot of different technologies and runs in a large set of environments that are not applicable to all users. We will not be able to keep all of this in sync all the time. What this means: The runtime is structured as a set of libraries that provide the fabric for wiring services together. These libraries are used by a number of host environments to create running SCA containers (e.g. the launcher uses them to provide a command-line client environment, the servlet launcher uses them to provide a webapp based environment, the test harness provides an environment around JUnit, ...). The interface to those libraries is defined by the spi and proposed api modules. Modifications to the implementation of those libraries should not be visible to the hosts or extensions that use them. We can build and distribute (through mvn) these libraries separately from the things that are using them. Users want distributions to be something that they can download, install and use for some purpose. We will build distributions with such a purpose in mind and include within them everything that a user would need to achieve it. For example, one purpose might be a client- side install so we would include within that the minimal runtime plus commonly used client bindings (e.g. web services); another purpose might be for building web
Re: Webservice via Axis2 in Tomcat.
It seems like having the build infrastructure make it really easy to configure what components go into a distro would help us iterate our way to the right number and makeup of distros. While the POM and project structure manipulation required right now isn't particularly difficult, it could probably be a lot easier -- I'm thinking of some mechanism where the POM dependency and assembly descriptor XML fragments associated with each extension can be kept with the extension, and the distro description just has to reference extensions by name. Does that make any sense? On 8/1/06, Jeremy Boynes [EMAIL PROTECTED] wrote: There is also the bridge scenario where people are using JSON to talk to Ajax clients for the UI but want to access back-end services that are using SOAP/HTTP or SOAP/JMS (or XML over JMS ...). I think this is why we need a spectrum of distros determined by user scenarios. By the time we throw everything in that anyone might want to use then the kitchen sink variety will be huge, giving a false sense of complexity that will put people off and will be a nightmare to release as it will require syncing up all the plugins. The other extreme is a minimalist one with nothing in it but which allows/ requires people to figure out and add in function that they need. I don't think either of these is ideal. What I've been proposing is a set of distros based on common runtime platforms that people will use. The ones so far are a standalone (J2SE) platform and a web-app (J2EE) platform; there's been some discussion of a Tomcat platform (i.e. Tomcat + SCA enhancements) like M1, and another would be a Celtix platform. These are somewhat exclusionary - for example, we will not need to include the Tomcat integration code on non-Tomcat platforms, it's just not relevant. I think users will use these differently, for example, using the standalone one as a client, Tomcat for web-app development or Celtix for integration. The different usage patterns will show us which extensions are relevant for that pattern and we can include those in the distro (reducing the number of things users need to add or remove). -- Jeremy On Aug 1, 2006, at 10:16 AM, ant elder wrote: I mostly agree, but one of the big benefits for Web services is the JavaScript E4X support. With that and when TUSCANY-419 and the magic databinding stuff is done this is going to make JavaScript components really really useful to use with WS i think. All the old WS debates about databindings and XML to Java mappings disappear as XML becomes really easy. ...ant On 8/1/06, Jeremy Boynes [EMAIL PROTECTED] wrote: I think there's a difference. Web services play a prominent role in the SCA specs and are likely to be used by most people which makes a good case for including them in distributions by default. The JavaScript stuff, although useful, is not something covered by the spec at all and is likely to be used by a different audience. For those, I would suggest that we should create a new distribution, one aimed at people doing REST, JSON, JavaScript stuff; that may or may not include web services depending on what users want. That would give us three distributions: * standalone environment * web-app environment with web services * web-app environment with JS-type stuff -- Jeremy On Aug 1, 2006, at 9:57 AM, ant elder wrote: How about the JavaScript container be included by default as well then? Would make it easier to run samples but this brings up all the kitchen sink distro type questions being discussed on the modularity thread. ...ant On 8/1/06, cr22rc [EMAIL PROTECTED] wrote: I'm ok with that. I just thought we may want ones without axis. But I'll put it in the others, if I hear nothing different. Jeremy Boynes wrote: Can we just add the binding to the existing distros? -- Jeremy On Aug 1, 2006, at 9:19 AM, Rick wrote: I'm currently in the process of trying to get running a service using the Axis2 web service binding in Tomcat environment. The approach I'm taking is to create a new distro based off of Ken Tam's web one and add the current Axis 2.0 binding. I've revived the Hellowordlws from M1 sample and fixed up the SCDL. Seem reasonable ? This may not be the end all but I'm hoping it will get some web services support reasonably soon. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Scope factory initialization: svn commit: r427726 [1/2] ...
Ken,
I think the factories should wait until their init method is called
otherwise they are registering before they have finished being
initialized. This also allows a this reference to leak before the
object has finished being constructed (i.e. it could be invoked
before it is fully instantiated). This problem is in all the recent
scope factory changes.
Will this fix the issue Ant mentioned yesterday where leaving off
@Scope(MODULE) gave a NPE?
--
Jeremy
public class ModuleScopeObjectFactory implements
ObjectFactoryModuleScopeContainer {
+
+public ModuleScopeObjectFactory(@Autowire ScopeRegistry registry) {
+registry.registerFactory(Scope.MODULE, this);
+}
+
+@Init(eager = true)
+public void init() {
+}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn:ignore ..., was: svn commit: r427726 [1/2]
And please set the svn:ignore property for bigbank Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Is there an import.wsdl function in the new code base?
Is there an import.wsdl function or anything similar for defining wsdl files in scdl implemented yet in the new code base? ...ant
Re: Karma for Raymond
Jim Marino wrote: I'd like to propose we make Raymond a committer. Normally, I would list some of the things a candidate has done for the community but with Raymond he has done so much I wouldn't know where to begin. So, here's my +1 form making Raymond a committer. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +1 from me! -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Scope factory initialization: svn commit: r427726 [1/2] ...
I was seeing a ScopeNotFoundException rather than an NPE I think, but
yeah, it happened when a component defaulted to STATELESS scope (in
the absence of an @Scope(MODULE)). I talked with Jim and we came to
this fix together.
Just so's I understand what you're saying -- the problems you're
describing are theoretical at this point, right? Because the current
scope factories are trivial in their construction (ie, the ctors
don't do anything, nor do the init methods), any races between
ctor/init completion other code calling into the factory aren't
actually a problem (given the super class's ctor will always be
completed).
That said, agree the code should always do the right thing :) My
understanding of component instantiation is ctor followed by init
method -- so we could store the injected ScopeFactory in the ctor and
do the register call in the init, and then clear the injected
ScopeFactory reference (avoiding circular references). Is that what
you're suggesting by waiting until their init method is called ?
Jim I also discussed a more complex solution involving making the
scope registry watch for newly created scope factories and register
them, but given the seriousness of the problem, having some solution
checked in seemed expedient.
BTW, does @Init work with inheritance? Ie, if my super-class has a
method marked @Init, will that method get called before my @Init
method?
On 8/1/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
Ken,
I think the factories should wait until their init method is called
otherwise they are registering before they have finished being
initialized. This also allows a this reference to leak before the
object has finished being constructed (i.e. it could be invoked
before it is fully instantiated). This problem is in all the recent
scope factory changes.
Will this fix the issue Ant mentioned yesterday where leaving off
@Scope(MODULE) gave a NPE?
--
Jeremy
public class ModuleScopeObjectFactory implements
ObjectFactoryModuleScopeContainer {
+
+public ModuleScopeObjectFactory(@Autowire ScopeRegistry registry) {
+registry.registerFactory(Scope.MODULE, this);
+}
+
+@Init(eager = true)
+public void init() {
+}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn:ignore ..., was: svn commit: r427726 [1/2]
done, thanks for the reminder On 8/1/06, Jeremy Boynes [EMAIL PROTECTED] wrote: And please set the svn:ignore property for bigbank Thanks -- 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]
Re: Scope factory initialization: svn commit: r427726 [1/2] ...
On Aug 1, 2006, at 5:29 PM, Ken Tam wrote:
I was seeing a ScopeNotFoundException rather than an NPE I think, but
yeah, it happened when a component defaulted to STATELESS scope (in
the absence of an @Scope(MODULE)). I talked with Jim and we came to
this fix together.
Just so's I understand what you're saying -- the problems you're
describing are theoretical at this point, right? Because the current
scope factories are trivial in their construction (ie, the ctors
don't do anything, nor do the init methods), any races between
ctor/init completion other code calling into the factory aren't
actually a problem (given the super class's ctor will always be
completed).
That said, agree the code should always do the right thing :) My
understanding of component instantiation is ctor followed by init
method -- so we could store the injected ScopeFactory in the ctor and
do the register call in the init, and then clear the injected
ScopeFactory reference (avoiding circular references). Is that what
you're suggesting by waiting until their init method is called ?
Jim I also discussed a more complex solution involving making the
scope registry watch for newly created scope factories and register
them, but given the seriousness of the problem, having some solution
checked in seemed expedient.
BTW, does @Init work with inheritance? Ie, if my super-class has a
method marked @Init, will that method get called before my @Init
method?
Yea I think having the registration done in init() is better due to
an escaping this reference. @Init will be called after the ctor is
and all injection performed so it's safe to do that.
Jim
On 8/1/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
Ken,
I think the factories should wait until their init method is called
otherwise they are registering before they have finished being
initialized. This also allows a this reference to leak before the
object has finished being constructed (i.e. it could be invoked
before it is fully instantiated). This problem is in all the recent
scope factory changes.
Will this fix the issue Ant mentioned yesterday where leaving off
@Scope(MODULE) gave a NPE?
--
Jeremy
public class ModuleScopeObjectFactory implements
ObjectFactoryModuleScopeContainer {
+
+public ModuleScopeObjectFactory(@Autowire ScopeRegistry
registry) {
+registry.registerFactory(Scope.MODULE, this);
+}
+
+@Init(eager = true)
+public void init() {
+}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build and distribution modularity
Proposal 1: Support independent build and distributions at the top level Rationale: Users interested in different technologies such as SCA and SDO do not want to have to build all of them together. This also gives a false impression that there are strong dependencies between them. What this means: Structure the build such that someone can check out any directory under java and build it on its own. For example, if I check out just sdo I would expect the build to work from that directory. All dependencies (e.g. on spec) would be resolved through the mvn repository. This will require each technology to upload unstable artifacts (aka SNAPSHOTs) to the mvn repository on some periodic basis. These are not releases and do not need to be voted on. Each technology will produce their own distribution. This may be a user-installable distro (e.g. for sca or sdo) or may just be a set of jars to be published in the mvn repo (e.g. for spec). +1 on independent top-level build/distros, we already have no small amount of confusion in the community at large regarding dependencies between SCA SDO. Proposal 2: Break sca down into runtime libraries, distributions and extensions Rationale: SCA involves a lot of different technologies and runs in a large set of environments that are not applicable to all users. We will not be able to keep all of this in sync all the time. What this means: The runtime is structured as a set of libraries that provide the fabric for wiring services together. These libraries are used by a number of host environments to create running SCA containers (e.g. the launcher uses them to provide a command-line client environment, the servlet launcher uses them to provide a webapp based environment, the test harness provides an environment around JUnit, ...). The interface to those libraries is defined by the spi and proposed api modules. Modifications to the implementation of those libraries should not be visible to the hosts or extensions that use them. We can build and distribute (through mvn) these libraries separately from the things that are using them. In principal I think I agree with the intentions here, but I'm not so clear on what it really means in practice. For example: The interface to those libraries is defined by the spi and proposed api modules. Modifications to the implementation of those libraries should not be visible to the hosts or extensions that use them. As I understand it, today this is definitely not true -- hosts such as the Launcher and SCATestCase are strongly coupled to implementation classes coming out of the runtime libraries via their system.scdls. It seems like changing this would imply that the the runtime libraries would include a core set of system SCDL definitions that would be leveraged by all hosts, and any host that wanted finer-grained control would continue to remain tightly coupled? Also not sure how this would work for extensions -- since so many of the SPI elements are abstract classes and not just interfaces, it seems it would be hard to keep impl changes in such classes from being visible to extensions. Users want distributions to be something that they can download, install and use for some purpose. We will build distributions with such a purpose in mind and include within them everything that a user would need to achieve it. For example, one purpose might be a client- side install so we would include within that the minimal runtime plus commonly used client bindings (e.g. web services); another purpose might be for building web applications so we would produce a distribution aimed to support web server functions (which may or may not include a server platform); another might be as a service intermediary which may have a very rich set of bindings. All distributions will support some form of extension mechanism that allows users to add functionality by installing extension modules. These modules will be released and distributed separately. Some may be included by default in some distributions (e.g. web services). +1 to this philosophy of distros. In particular, I think we want to have a system where getting and installing extensions is super-easy a la maven plugins or ant tasks -- no one really worries about whether extensions to those programs ship with the default distro, since it's so easy to add them afterwards. Ant's earlier concern that not being in a distro might make an extension 2nd class is definitely something we want to avoid, but I think the right way to do that is to make post-facto inclusion really easy rather than including more extensions by default. Proposal 3: It should be easy to build a distribution (including everything that is in it). Rationale: We want to be able to build these things easily. +1, how can anyone argue with making something easy :) I need to spend more time understanding what's possible here before I have a lot more to say.. Proposal 4: We need a test suite for each distribution that
JAX-WS RI binding
I'm about to start working on a binding for the Sun JAX-WS RI, akin to the Celtix Axis2 bindings. Anyone else interested, please chime in! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Scope factory initialization: svn commit: r427726 [1/2] ...
On Aug 1, 2006, at 5:29 PM, Ken Tam wrote: I was seeing a ScopeNotFoundException rather than an NPE I think, but yeah, it happened when a component defaulted to STATELESS scope (in the absence of an @Scope(MODULE)). I talked with Jim and we came to this fix together. OK - thanks for fixing this. Just so's I understand what you're saying -- the problems you're describing are theoretical at this point, right? Because the current scope factories are trivial in their construction (ie, the ctors don't do anything, nor do the init methods), any races between ctor/init completion other code calling into the factory aren't actually a problem (given the super class's ctor will always be completed). I don't think so - once you call register, another thread could call the registry which may invoke you before the constructor had completed. There were some changes to how object construction worked in the 1.5 memory model so this may not be an issue any more. That said, agree the code should always do the right thing :) My understanding of component instantiation is ctor followed by init method -- so we could store the injected ScopeFactory in the ctor and do the register call in the init, and then clear the injected ScopeFactory reference (avoiding circular references). Is that what you're suggesting by waiting until their init method is called ? Yes. Jim I also discussed a more complex solution involving making the scope registry watch for newly created scope factories and register them, but given the seriousness of the problem, having some solution checked in seemed expedient. Agreed. Jim, Sebastien and I had discussed mapped multiplicity references before as well. The application here would be the registry having a multiplicity reference of type Map whose members would be automatically managed by the fabric. As eligible services came online (based on rules associated with the reference) their key would be extracted and they would be inserted in the Map. BTW, does @Init work with inheritance? Ie, if my super-class has a method marked @Init, will that method get called before my @Init method? I believe there can only be one method marked @Init across the implementation and its superclasses. Normal Java method overriding is followed (so if you override it your declared method will be called and it is your responsibility to call the superclass method that you override). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn:ignore ..., was: svn commit: r427726 [1/2]
On Aug 1, 2006, at 5:44 PM, Ken Tam wrote: done, thanks for the reminder Thanks - now we can both remind Jim the next time he forgets ;-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CI, was: Build and distribution modularity
Splitting into a different thread On Aug 1, 2006, at 6:07 PM, Ken Tam wrote: Proposal 4: We need a test suite for each distribution that mirrors user experience Rationale: When a user installs a distribution it's helpful if it works. ... We can't do this every time we build as not everyone will have access to every environment. Instead we use a CI framework such as Continuum that can build or download a distro and exercise it on a variety of platforms. Any failures get converted to high-priority JIRA issues. Last time I was involved in this sort of thing around Beehive, the ASF did not really support any kind of CI infrastructure for its projects. Has that changed? Might we persuade a company or two to pony up a machine on the internet? I really like CI, though most of my experience is with cruise control rather than continuum. I spoke with Dims in the spring about doing nightly builds using the zone available to the webservices project and he was OK with it. The only issue was that publishing to the snapshot repo required someone's private key to be stored on the machine. Raymond got the build running under Continuum on his desktop so it is feasible. We may be able to use some of the GBuild infrastructure from Geronimo. I'm willing to open up a dedicated server for folk to use as well. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there an import.wsdl function in the new code base?
On Aug 1, 2006, at 4:49 PM, ant elder wrote: Is there an import.wsdl function or anything similar for defining wsdl files in scdl implemented yet in the new code base? IIRC the spec group had murmured something about using the WSDL2.0 wsdlLocation attribute e.g. interface.wsdl wsdli:wsdlLocation=someURI/ and I think the InterfaceWSDLLoader supports that. One problem we ran into with import.wsdl was that the definition was shared and reused. However, different places in the configuration had different annotations and extensions in their version of the WSDL document. Hence the desire to be able to specify the actual instance where it was used. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build and distribution modularity
On Aug 1, 2006, at 6:07 PM, Ken Tam wrote: Proposal 1: Support independent build and distributions at the top level Rationale: Users interested in different technologies such as SCA and SDO do not want to have to build all of them together. This also gives a false impression that there are strong dependencies between them. What this means: Structure the build such that someone can check out any directory under java and build it on its own. For example, if I check out just sdo I would expect the build to work from that directory. All dependencies (e.g. on spec) would be resolved through the mvn repository. This will require each technology to upload unstable artifacts (aka SNAPSHOTs) to the mvn repository on some periodic basis. These are not releases and do not need to be voted on. Each technology will produce their own distribution. This may be a user-installable distro (e.g. for sca or sdo) or may just be a set of jars to be published in the mvn repo (e.g. for spec). +1 on independent top-level build/distros, we already have no small amount of confusion in the community at large regarding dependencies between SCA SDO. Proposal 2: Break sca down into runtime libraries, distributions and extensions Rationale: SCA involves a lot of different technologies and runs in a large set of environments that are not applicable to all users. We will not be able to keep all of this in sync all the time. What this means: The runtime is structured as a set of libraries that provide the fabric for wiring services together. These libraries are used by a number of host environments to create running SCA containers (e.g. the launcher uses them to provide a command-line client environment, the servlet launcher uses them to provide a webapp based environment, the test harness provides an environment around JUnit, ...). The interface to those libraries is defined by the spi and proposed api modules. Modifications to the implementation of those libraries should not be visible to the hosts or extensions that use them. We can build and distribute (through mvn) these libraries separately from the things that are using them. In principal I think I agree with the intentions here, but I'm not so clear on what it really means in practice. For example: The interface to those libraries is defined by the spi and proposed api modules. Modifications to the implementation of those libraries should not be visible to the hosts or extensions that use them. As I understand it, today this is definitely not true -- hosts such as the Launcher and SCATestCase are strongly coupled to implementation classes coming out of the runtime libraries via their system.scdls. It seems like changing this would imply that the the runtime libraries would include a core set of system SCDL definitions that would be leveraged by all hosts, and any host that wanted finer-grained control would continue to remain tightly coupled? I'm not sure there is an easy way around this. Most of the dependencies are on things like loaders and builders. If we keep these in system composite scdls, there is at least some level of loose coupling since the dependency is on the composite component and not its implementation (i.e. loaders and builders). I think we want to keep things as flexible as possible since a custom launcher may just want to prune everything down, perhaps not even having loaders and instead using some other config mechanism. That said, I still think we leak classes from core into some of the extension modules (particularly around wires) so we may want to keep an eye on that and create some kind of test harness for extension builders to stop this from happening. Also not sure how this would work for extensions -- since so many of the SPI elements are abstract classes and not just interfaces, it seems it would be hard to keep impl changes in such classes from being visible to extensions. Users want distributions to be something that they can download, install and use for some purpose. We will build distributions with such a purpose in mind and include within them everything that a user would need to achieve it. For example, one purpose might be a client- side install so we would include within that the minimal runtime plus commonly used client bindings (e.g. web services); another purpose might be for building web applications so we would produce a distribution aimed to support web server functions (which may or may not include a server platform); another might be as a service intermediary which may have a very rich set of bindings. All distributions will support some form of extension mechanism that allows users to add functionality by installing extension modules. These modules will be released and distributed separately. Some may be included by default in some distributions (e.g. web services). +1 to this philosophy of distros. In particular, I think we want to have a system where getting and installing
Re: JAX-WS RI binding
How about moral support - I'm swamped ;-) Seriously, you may want to sync with Jervis since he mentioned reusing some pieces across Axis2 and Celtix. Jim On Aug 1, 2006, at 6:23 PM, Ken Tam wrote: I'm about to start working on a binding for the Sun JAX-WS RI, akin to the Celtix Axis2 bindings. Anyone else interested, please chime in! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn:ignore ..., was: svn commit: r427726 [1/2]
On Aug 1, 2006, at 7:00 PM, Jim Marino wrote: Yea for some reason it's not picking it up on my machine. Have any idea what may be happening since you have the same box as me? I don't think it does it automatically - I always have to set it manually before checking in. I typically do an svn st before committing just to make sure that there is nothing missing. It doesn't always work - for example, if you've cleaned there won't be a target directory which is a common indicator that svn:ignore is not set. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to use extensions with the standalone launcher?
Hi Jeremy, Why not name them as extension.scdl. Though for most parts they might be treated as any other scdl some where we treat them a little differently as in adding them to extensions and so on. Infact a solution developer could develop some extensions and applications and keep them all bundled together. When deployed the SCA runtime is able to understand which ones are application scdls and which ones are extensions scdls and treats them accordingly. That way the SCA installation directories can be left alone i.e. the user need not drop the extension jars in a predefined dir. and so on. Also am curious about the name 'default.scdl'. Why 'default'? Is it to imply that these scdls will be automatically picked up and deployed? So can I give other names to my scdls and if so is there a programming model to explicitly mention about them or load them? Thanks - Venkat On 8/2/06, ant elder [EMAIL PROTECTED] wrote: How about until we have a way to do extensions properly to fix the problem Matthew is seeing the testcase could determine which is the application default.scdl by seeing if the resource URL starts with the current working directory which it can get from System.getProperty(user.dir)? ...ant On 8/1/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Aug 1, 2006, at 11:28 AM, Matthew Sykes wrote: FWIW, I think I've been running into a problem at build time because of this exact issue. There's a bit of code in the javascript sample HelloWorldTestCase.java test that gathers up all of the META-INF/sca/default.scdl resources it can find. The test then throws away the first resource in the enumeration assuming it's the application's default.scdl and not the extension's default.scdl. I think this is problematic - putting all the runtime code on the application classpath is asking for trouble. ant elder wrote: I guess it somehow needs to find the URL to the default.scdl for the JavaScript extension, but thats just in a jar on the classpath and there's lots of default.scdl resources on the class path so how does it know which is the JavaScript one? And the once it has that URL it isn't real obvious (to me) how you could use that from the testcase to get the extension registered with the runtime. ...ant While the build generally succeeds, every once in a while the test fails with an UnrecognizedElementException on implementation.js. I added a System.out.println to the test to show which of the resources was thrown away in the following code snippet and found that the extension scdl can be discarded instead of the application scdl. (I'm assuming this is because enumeration that comes back from getResources doesn't have a specfied order.) At this point I guess I have to wonder if the name used for the extensions' scdl should be something different from the default application scdl name? It seems like it might be nice to do something like gather up like all of the visible META-INF/sca/ extension.scdl resources and add them to the runtime as extensions. I don't believe this would be at odds with the current extensions mechanism in the DirectoryScanExtender if it went after extension.scdl instead of default.scdl. I don't think we want different types of composite for extensions and other things. We're trying to add extensions into test cases without defining an extension mechanism so it's not surprising things are not working properly. Perhaps we should back up a little and think about what we are trying to achieve. Putting a user hat on, here are the things that I would like to do: 1) Unit test a component without needing any SCA runtime infrastructure. I don't need Tuscany classes on the classpath to compile my component and I don't want to pollute my test environment with them. All I should need is my code and my test framework (for example, TestNG). 2) Function test a component in the SCA runtime. I have installed and configured Tuscany somewhere, adding in the extensions that I need. I want to test code as if it was running in that environment. Ideally I would like the runtime to boot quickly inside my test client but I would also like to be able to deploy the component to an already running environment. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
