RE: Binding for a transport
Hi Rajith, If you use Celtix binding, you can utilize all bindings supported by Celtix, including JMS, check out Celtix website for supported bindings and future roadmap: http://celtix.objectweb.org/. The helloworld-jms sample in Tuscany M1 release shows this ability. Cheers, Jervis -Original Message- From: Rajith Attapattu [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2006 2:19 AM To: tuscany-dev@ws.apache.org Subject: Re: Binding for a transport Hi All, After looking at the code I found that tuscany has bindings for WebServices, RMI and JBI. According to the SCA spec it also talks about bindings for transports like JMS (or have I misunderstood it?) Is there an effort to do such thing? Or is there a concept of Binding an EntryPoint to a transport? or should it be more of a high level thing such as WS, JBI, JCA or RMI? Some clarification is greatly appreciated. Regards, Rajith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Do we need SDO annotations in the SCDL XSDs?
Thanks Fuhwei, that's a great help. It should be fairly simple to change the C++ code to use the same logic (I hope!). Cheers, On 08/08/06, Fuhwei Lwo [EMAIL PROTECTED] wrote: I just verified how SDO Java implementation works using your example below. First, it checks whether myElem.1 is a valid property name. If yes, getString() would return the value of myElem.1 otherwise it treats myElem.1 as an XPath string. Fuhwei Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: I think the problem is that you can define an elements in a type such as: This would lead to properties on the SDO type named myElem (which is many-valued) and myElem.1. So, when I code xxx-getCString(myElem.1); does that return value index 1 from myElem or the single valued property myElem.1. I think that is why we decided to disallow dots in property names. Cheers, Pete, I believe that an XPath implementation needs to support this, and this is actually independent of SDO as dots are allowed in XSD element names. You would just escape the dot, like this: xxx-getCString(myElem%2E1). Would that work for SDO as well? How is our XPath support implemented? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: Running calculator test case inside Eclipse
Hi,
Why is it mandatory that the launcher should be loaded from a jar file ?
I also faced the same problem while tryin the samples sometime back.
This could be fixed if you make your sample dependant on the jar file
rather than a project level dependancy.
Another question I had is, inside the launcher, can we return null
instead of throwing an IllegalStateException if launcher is not loaded
from a jar file ? ie to modify the code as :
if (!jar.equals(url.getProtocol())) {
//throw new IllegalStateException(Must be run from a jar: + url);
return null;
}
Regards,
jojo.
On 8/9/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
The purpose of RuntimeInfo is to provide information about the runtime:
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200607.mbox/%
[EMAIL PROTECTED]
and see the JavaDoc at
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/spi/src/
main/java/org/apache/tuscany/spi/services/info/RuntimeInfo.java
The extension mechanism uses this to locate the directory to scan but
that is a feature of the DirectoryScanExtender and not RuntimeInfo.
--
Jeremy
On Aug 8, 2006, at 5:12 PM, Raymond Feng wrote:
Hi,
If I run the Calculator test case inside Eclipse without setting
the tuscany.installDirectory system property, I get the following
exception.
java.lang.IllegalStateException: Must be run from a jar: file:/C:/
Tuscany/Apache/java/sca/core/target/classes/org/apache/tuscany/core/
launcher/Launcher.class
at org.apache.tuscany.core.launcher.Launcher.getInstallDirectory
(Launcher.java:175)
at org.apache.tuscany.core.launcher.Launcher.bootRuntime
(Launcher.java:105)
at org.apache.tuscany.test.SCATestCase.setUp(SCATestCase.java:52)
at calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:32)
at junit.framework.TestCase.runBare(TestCase.java:125)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run
(JUnit3TestReference.java:128)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run
(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests
(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests
(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run
(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main
(RemoteTestRunner.java:196)
Can we relax this constraint? I checked the references to
RuntimeInfo.getInstallDirectory() and found out it's only used to
deploy extensions. We also have a TODO in the code saying do we
want to support unpacked directories as extensions?.
For the RuntimeInfo interface, is it designed to provide the
install directory or a list of URLs representing extension SCDLs
(by reading the code, this is how the interface is used today)? If
it's the later case, I think we should have the following
RuntimeInfo interface:
public interface RuntimeInfo {
public ListURL getInstalledExtensions();
}
Any thoughts?
Thanks,
Raymond
-
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]
--
Warm regards,
jojo.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axiom and classloaders, was: svn commit: r429905
Are u folks using latest Axis2 SVN? -- dims On 8/9/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Aug 8, 2006, at 8:38 PM, cr22rc wrote: If we can find another way without applying our private changes to Axis I'm perfectly fine by that. Have any detailed suggestion off hand? Looks like the problem may lie in o.a.axiom.om.util.StAXUtils - can you confirm that where you were getting the problem? If so, I would suggest we take this to the Axiom list. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
separate SDO Java distribution
Hi, I'm looking at some pom.xml files, particularly the ones for java sca distributions, to try to work out what additions would be needed to permit building a separate sdo java distribution. I can see the general pattern, but if anyone has any pointers to good documentation or has any suggestions before I get too deep into this I'd much appreciate them. Kelvin
Re: Axiom and classloaders, was: svn commit: r429905
FWIW: Here is a stack trace. Exception in thread main javax.xml.stream.FactoryConfigurationError: Provider com.bea.xml.stream.MXParserFactory not found at javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:72) at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:176) at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:92) at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:136) at org.apache.axiom.om.util.StAXUtils.getXMLInputFactory(StAXUtils.java:35) at org.apache.axiom.om.util.StAXUtils.createXMLStreamReader(StAXUtils.java:59) at org.apache.axis2.deployment.DescriptionBuilder.buildOM(DescriptionBuilder.java:81) at org.apache.axis2.deployment.AxisConfigBuilder.populateConfig(AxisConfigBuilder.java:63) at org.apache.tuscany.binding.axis2.util.TuscanyAxisConfigurator.getConfigurationContext(TuscanyAxisConfigurator.java:72) at org.apache.tuscany.binding.axis2.Axis2Reference.createServiceClient(Axis2Reference.java:102) at org.apache.tuscany.binding.axis2.Axis2Reference.init(Axis2Reference.java:74) at org.apache.tuscany.binding.axis2.Axis2BindingBuilder.build(Axis2BindingBuilder.java:52) at org.apache.tuscany.core.builder.BuilderRegistryImpl.build(BuilderRegistryImpl.java:141) at org.apache.tuscany.core.implementation.composite.CompositeBuilder.build(CompositeBuilder.java:94) at org.apache.tuscany.core.builder.BuilderRegistryImpl.build(BuilderRegistryImpl.java:99) at org.apache.tuscany.core.deployer.DeployerImpl.build(DeployerImpl.java:125) at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:91) at org.apache.tuscany.core.launcher.Launcher.bootApplication(Launcher.java:175) at org.apache.tuscany.core.launcher.MainLauncher.boot(MainLauncher.java:139) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.launcher.MainLauncherBooter.main(MainLauncherBooter.java:67) Jeremy Boynes wrote: On Aug 8, 2006, at 8:38 PM, cr22rc wrote: If we can find another way without applying our private changes to Axis I'm perfectly fine by that. Have any detailed suggestion off hand? Looks like the problem may lie in o.a.axiom.om.util.StAXUtils - can you confirm that where you were getting the problem? If so, I would suggest we take this to the Axiom list. -- 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: Axiom and classloaders, was: svn commit: r429905
We are building with Axis 2.0 version 1.0 release. Davanum Srinivas wrote: Are u folks using latest Axis2 SVN? -- dims On 8/9/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Aug 8, 2006, at 8:38 PM, cr22rc wrote: If we can find another way without applying our private changes to Axis I'm perfectly fine by that. Have any detailed suggestion off hand? Looks like the problem may lie in o.a.axiom.om.util.StAXUtils - can you confirm that where you were getting the problem? If so, I would suggest we take this to the Axiom list. -- 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: Axiom and classloaders, was: svn commit: r429905
Checked in the fix from Jeremy. Please pick up the nighty later today. thanks, dims On 8/9/06, Rick [EMAIL PROTECTED] wrote: We are building with Axis 2.0 version 1.0 release. Davanum Srinivas wrote: Are u folks using latest Axis2 SVN? -- dims On 8/9/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Aug 8, 2006, at 8:38 PM, cr22rc wrote: If we can find another way without applying our private changes to Axis I'm perfectly fine by that. Have any detailed suggestion off hand? Looks like the problem may lie in o.a.axiom.om.util.StAXUtils - can you confirm that where you were getting the problem? If so, I would suggest we take this to the Axiom list. -- 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] -- 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: Axiom and classloaders, was: svn commit: r429905
Thanks Dims. I saw the fixes (r427662) for classloader issues with Spring as well - Rick, I think perhaps we should be using a SNAPSHOT of axis for this as well. -- Jeremy On Aug 9, 2006, at 7:07 AM, Davanum Srinivas wrote: Checked in the fix from Jeremy. Please pick up the nighty later today. thanks, dims On 8/9/06, Rick [EMAIL PROTECTED] wrote: We are building with Axis 2.0 version 1.0 release. Davanum Srinivas wrote: Are u folks using latest Axis2 SVN? -- dims On 8/9/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Aug 8, 2006, at 8:38 PM, cr22rc wrote: If we can find another way without applying our private changes to Axis I'm perfectly fine by that. Have any detailed suggestion off hand? Looks like the problem may lie in o.a.axiom.om.util.StAXUtils - can you confirm that where you were getting the problem? If so, I would suggest we take this to the Axiom list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Inheriting Wiring infrastructure
Hello Jims (Venkata, and everyone else struggling with bindings, etc.) I have an OSGi binding implementation that's sort of working now (I can run the SupplyChain example in equinox, repackaged into a couple of bundles, etc). There's a binding.osgi that allows me to expose SCA services as OSGi services, and there's an implementation.osgi that allows me to consume OSGi services as SCA components. I'm sure it's not perfect, but it's a start. :-) I've also got some OSGi-specific implementations of some of the boot-strappy classes for dealing with classloader issues and some manager code that allows sca applications (packaged as bundles) to run in separate contexts. I'd like to provide this code to Tuscany and help complete the implementation. How would you like me to proceed? Do you have time to look at it and point out where I've gone astray? Thanks, Joel Hawkins -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 08, 2006 10:31 PM To: tuscany-dev@ws.apache.org Subject: Re: Inheriting Wiring infrastructure On Aug 8, 2006, at 10:38 AM, Venkata Krishnan wrote: Hi Jim / Jeremy / Axis2 Celtix binding folks Continuing with the simple RMI Binding that I am working on... here are the things that I have done to move it forward in steps... (from a null inbound wire to being able to host the RMI Service. Now I am on the path to invoking the service). Here is what I have done in the RMIBindingBuilder.build method: - - created the inbound and outbound wires - set up anInbound and Outbound Invocations chain for these wires resp. - set up a Java target invoker on the InboundWire (did not understand this as I expected that this should be set onto the outbound wire) You should only need to create the target invoker for the reference and not the service side (the target invoker is responsible for dispatching on a service). The invoker itself is cached on the target side and sent down the invocation chain with the message, pulled off by the final interceptor and invoked. This process is described in the slides under /doc. The reason for this is so target invokers can be optimized to avoid resolution on every invoke when the source of a wire is of the same or lesser scope than the target (e.g. request-- request; request--module). - Now I am stuck with Interceptors... it seems like the outbound wire need to be configured with interceptor. This seems to be little tricky as I must create MessageChannels and so on... any suggestions on how I could do this? Yes it's very tricky, particularly with callbacks ;-) The connector handles this so the extension developer should not need to worry. Axis2 and Celtix folks, how have you guys done this?If this is not the way to do this, what else is? If you give me until tomorrow, I'll check a sample binding in of how to do this. I also have some related changes I want to discuss pertaining to the Wire Service and how wires are produced so I'll post in a related email. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: separate SDO Java distribution
On Aug 9, 2006, at 5:30 AM, kelvin goodson wrote: Hi, I'm looking at some pom.xml files, particularly the ones for java sca distributions, to try to work out what additions would be needed to permit building a separate sdo java distribution. I can see the general pattern, but if anyone has any pointers to good documentation or has any suggestions before I get too deep into this I'd much appreciate them. I would think that you just need to duplicate something like the sca distribution modules which really just use the maven-assembly-plugin to create the distribution archives. Good documentation is relative - what there is is here: http://maven.apache.org/plugins/maven-assembly-plugin/ If you know what you would like the distro bundle to look like (e.g. just bin and lib directories or do you need more) then I'm happy to help with setting up the assembly definition. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Account request for new Tuscany committer: Kelvin Goodson
Hi, just to check in case this is slowing the process up, it appears that ant had adhered to the prescribed format in his note; did the fact that you posted a link to the format suggest that there was something he hadn't done right? Regards, Kelvin. On 07/08/06, Eran Chinthaka [EMAIL PROTECTED] wrote: Hi Ant, Its better to cc this email to the new committer as well. The format for this email can be found here (http://www.apache.org/dev/pmc.html#newcommitter) -- Chinthaka ant elder wrote: Tuscany has voted in Kelvin as a committer, could an account be created for him please. Preferred userid: kelvin Full name: Kelvin James Goodson Forwarding email: [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] Requested Karma for: ws ws-tuscany ICLA has been submitted and now appears on http://people.apache.org/~jim/committers.html http://people.apache.org/%7Ejim/committers.html Vote result 9 +1 votes and no -1s: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200608.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200608.mbox/[EMAIL PROTECTED] Thanks! ...ant
[C++] SCA restructuring for modularity extensibility
Hi All, As well as the assembly model changes (for the 0.95 spec) that Sebastien is heroically getting though at the moment, would it be worth starting to think about restructuring the SCACPP codebase? It strikes me that we need to make Tuscany more modular than it currently is, to help with understandibility and maintainability, and we also need to be thinking about the extensibility story (which itself instructs how we need to modularize things). There are lots of areas where we should bring in the ability for users and developers to extend SCACPP: Service Extensions (aka Entrypoints in old-speak) The current service binding (WS/Axis2C) essentially acts like a local client, bootstrapping the runtime, finding the service and invoking the appropriate operation - will all service extensions want to act in this way? In this case, Axis is calling Tuscany, so we configure Axis to be able to find Tuscany but not the other way round - will other service extensions need Tuscany to call back into the service extension? If so, do we want to do this dynamically or via compile-time linking? Reference Extensions (aka External Services in old-speak) Reference extensions will need to be dynamically found and invoked, so we will probably need some kind of Tuscany runtime configuration side file that points at the library ( perhaps has some configuration parameters, etc). We could statically link, but then we would be forcing extension authors to recompile the whole of SCACPP. Component Language Extensions I put some info up about this on the wiki, but rereading it after my holiday and it's a tad unclear! Do we want to call components in other languages via proxy code generated with SCAGEN? Will we want to generate wrapper code in the other language, so that calling a component reference works like a normal language call? Can we avoid the SCAGEN development step? How will we map data types from C++ to the language and back again? Assembly Model Extensions We need to allow people to add their own binding.xxx element (or implementation.xxx, etc) to the sca.module (now sca.composite) file and have Tuscany use the extension when it reads it. Data Binding Extensions Allow other types of data to be passed between components and between composites. I think at the moment we only allow C++ primitives and SDO data objects. We will need to define SPIs for each of these areas - for Service and Reference extensions we can probably base it on the WS entrypoint and external service support in the current codebase, but the others will need more thinking about. I've veered off into extensibility here, without talking much about restructuring - does anyone have any good ideas about where things should go or how to make the code more modular? Cheers Andy
Re: Inheriting Wiring infrastructure
On Aug 9, 2006, at 7:35 AM, Hawkins, Joel wrote: Hello Jims (Venkata, and everyone else struggling with bindings, etc.) I have an OSGi binding implementation that's sort of working now (I can run the SupplyChain example in equinox, repackaged into a couple of bundles, etc). There's a binding.osgi that allows me to expose SCA services as OSGi services, and there's an implementation.osgi that allows me to consume OSGi services as SCA components. I'm sure it's not perfect, but it's a start. :-) Sounds like a pretty good start :-) I've also got some OSGi-specific implementations of some of the boot-strappy classes for dealing with classloader issues and some manager code that allows sca applications (packaged as bundles) to run in separate contexts. :-) I'd like to provide this code to Tuscany and help complete the implementation. How would you like me to proceed? Do you have time to look at it and point out where I've gone astray? Thank you. If you can create a JIRA and attach what you have as a patch or zip archive I would suggest we check this in to the trunk but do not include in the main build just yet. This sounds like a cool and valuable contribution. Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Big Bank Sample
Hi, Does anyone know the current status of the Big Bank Sample, specifically what is still required to get the sample up and running on the latest Tuscany code. We have a few resources here that can help with this effort. We're not too familiar with the new recursive model, but we're willing to learn if someone wants to help guide us. Thanks, Kapil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Account request for new Tuscany committer: Kelvin Goodson
Nope. does not slow anything down :) On 8/9/06, kelvin goodson [EMAIL PROTECTED] wrote: Hi, just to check in case this is slowing the process up, it appears that ant had adhered to the prescribed format in his note; did the fact that you posted a link to the format suggest that there was something he hadn't done right? Regards, Kelvin. On 07/08/06, Eran Chinthaka [EMAIL PROTECTED] wrote: Hi Ant, Its better to cc this email to the new committer as well. The format for this email can be found here (http://www.apache.org/dev/pmc.html#newcommitter) -- Chinthaka ant elder wrote: Tuscany has voted in Kelvin as a committer, could an account be created for him please. Preferred userid: kelvin Full name: Kelvin James Goodson Forwarding email: [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] Requested Karma for: ws ws-tuscany ICLA has been submitted and now appears on http://people.apache.org/~jim/committers.html http://people.apache.org/%7Ejim/committers.html Vote result 9 +1 votes and no -1s: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200608.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200608.mbox/[EMAIL PROTECTED] Thanks! ...ant -- 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: Big Bank Sample
Hi all, I would like to join the tuscany effort also, would this be a good starting point? I'd appreciate any guidance you coule provide. Thanks! Jeff -Original Message- From: Kapil Katyal [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2006 9:50 AM To: tuscany-dev@ws.apache.org Subject: Big Bank Sample Hi, Does anyone know the current status of the Big Bank Sample, specifically what is still required to get the sample up and running on the latest Tuscany code. We have a few resources here that can help with this effort. We're not too familiar with the new recursive model, but we're willing to learn if someone wants to help guide us. Thanks, Kapil - 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: Big Bank Sample
One thing we are looking for is real-world applications of SCA - things that can show off what Tuscany can do. If you have any applications in mind they would be welcome. These could be variants on the BigBank theme (say a Ajax front end) or something completely different. -- Jeremy On Aug 9, 2006, at 8:10 AM, Guo, Jeffrey wrote: Hi all, I would like to join the tuscany effort also, would this be a good starting point? I'd appreciate any guidance you coule provide. Thanks! Jeff -Original Message- From: Kapil Katyal [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2006 9:50 AM To: tuscany-dev@ws.apache.org Subject: Big Bank Sample Hi, Does anyone know the current status of the Big Bank Sample, specifically what is still required to get the sample up and running on the latest Tuscany code. We have a few resources here that can help with this effort. We're not too familiar with the new recursive model, but we're willing to learn if someone wants to help guide us. Thanks, Kapil - 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: Axiom and classloaders, was: svn commit: r429905
Per jumping to SNAPSHOTS of Axis 2.0 builds: Dims, any thoughts where you think Axis 2.0 is in the life cycle of the next release? Are things fairly stable ? I seen some talk on the mailing list about release 1.1 but I didn't get a good feel for any specific target date. Jeremy Boynes wrote: Thanks Dims. I saw the fixes (r427662) for classloader issues with Spring as well - Rick, I think perhaps we should be using a SNAPSHOT of axis for this as well. -- Jeremy On Aug 9, 2006, at 7:07 AM, Davanum Srinivas wrote: Checked in the fix from Jeremy. Please pick up the nighty later today. thanks, dims On 8/9/06, Rick [EMAIL PROTECTED] wrote: We are building with Axis 2.0 version 1.0 release. Davanum Srinivas wrote: Are u folks using latest Axis2 SVN? -- dims On 8/9/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Aug 8, 2006, at 8:38 PM, cr22rc wrote: If we can find another way without applying our private changes to Axis I'm perfectly fine by that. Have any detailed suggestion off hand? Looks like the problem may lie in o.a.axiom.om.util.StAXUtils - can you confirm that where you were getting the problem? If so, I would suggest we take this to the Axiom list. - 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: Axiom and classloaders, was: svn commit: r429905
My best guess is end of this month... -- dims On 8/9/06, Rick [EMAIL PROTECTED] wrote: Per jumping to SNAPSHOTS of Axis 2.0 builds: Dims, any thoughts where you think Axis 2.0 is in the life cycle of the next release? Are things fairly stable ? I seen some talk on the mailing list about release 1.1 but I didn't get a good feel for any specific target date. Jeremy Boynes wrote: Thanks Dims. I saw the fixes (r427662) for classloader issues with Spring as well - Rick, I think perhaps we should be using a SNAPSHOT of axis for this as well. -- Jeremy On Aug 9, 2006, at 7:07 AM, Davanum Srinivas wrote: Checked in the fix from Jeremy. Please pick up the nighty later today. thanks, dims On 8/9/06, Rick [EMAIL PROTECTED] wrote: We are building with Axis 2.0 version 1.0 release. Davanum Srinivas wrote: Are u folks using latest Axis2 SVN? -- dims On 8/9/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Aug 8, 2006, at 8:38 PM, cr22rc wrote: If we can find another way without applying our private changes to Axis I'm perfectly fine by that. Have any detailed suggestion off hand? Looks like the problem may lie in o.a.axiom.om.util.StAXUtils - can you confirm that where you were getting the problem? If so, I would suggest we take this to the Axiom list. - 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] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SDO for PHP release 1.0.3 has shipped using Tuscany C++ SDO
We've just shipped this new release of SDO for PHP, based on the Tuscany C++ SDO M1 release. This is the first time the PHP implementation has used the Tuscany code, and it's looking good. Thanks, guys! Original Message Subject: [ANNOUNCEMENT] sdo-1.0.3 (stable) Released. Date: 9 Aug 2006 10:54:01 - From: [EMAIL PROTECTED] (PECL Announce) To: PECL developers list [EMAIL PROTECTED] Newsgroups: php.pecl.dev The new PECL package sdo-1.0.3 (stable) has been released at http://pecl.php.net/. Release notes - Compatibility with Tuscany C++/SDO M1 release and some bug fixes over 1.0.2 - Update the base C++/SDO implementation to be the Tuscany CPP Milestone 1 release: cpp-0.1.incubating-M1 - Tested with Linux AMD 64-bit architecture - new 3-argument version of SDO_DAS_XML::createDocument() allows an SDO_DAS_XML_Document to be created from an SDO - fix defect 7878 Silent failure with malformed SQL - fix defect 7879 Improve error message in SDO_DAS_Relational_DatabaseHelper:executeStatement - fix defect 8280 Remove spaces from source files - fix defect 8300 Optimistic concurrency failure - fix defect 8374 Exception hierarchy (temporary fix) Package Info - Service Data Objects (SDOs) enable PHP applications to work with data from different sources (like a database query, an XML file, or a spreadsheet) using a single interface. Related Links - Package home: http://pecl.php.net/package/sdo Changelog: http://pecl.php.net/package-changelog.php?package=sdo Download: http://pecl.php.net/get/sdo-1.0.3.tgz Authors - Caroline Maynard [EMAIL PROTECTED] (lead) Graham Charters (lead) Matthew Peters [EMAIL PROTECTED] (lead) Simon Laws (lead) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] SCA restructuring for modularity extensibility
Thanks for bringing this up Andy. I think there are a few separate topics in this note and they probably need their own thread for discussion but this is a good starting point. I certainly would like to restructure the code and src tree structure a little and this is a great time to do it having just released the M1 and as we are starting to implement the 0.95 spec model. The existing code is still based around what I would call a prototype implementation. I'll come back with some more comments/detail on what you have below. We may also like to think about build and test while we are at it and what src tree layout would help us to build e.g. core or model separately and unit test them. Cheers, On 09/08/06, Andrew Borley [EMAIL PROTECTED] wrote: Hi All, As well as the assembly model changes (for the 0.95 spec) that Sebastien is heroically getting though at the moment, would it be worth starting to think about restructuring the SCACPP codebase? It strikes me that we need to make Tuscany more modular than it currently is, to help with understandibility and maintainability, and we also need to be thinking about the extensibility story (which itself instructs how we need to modularize things). There are lots of areas where we should bring in the ability for users and developers to extend SCACPP: Service Extensions (aka Entrypoints in old-speak) The current service binding (WS/Axis2C) essentially acts like a local client, bootstrapping the runtime, finding the service and invoking the appropriate operation - will all service extensions want to act in this way? In this case, Axis is calling Tuscany, so we configure Axis to be able to find Tuscany but not the other way round - will other service extensions need Tuscany to call back into the service extension? If so, do we want to do this dynamically or via compile-time linking? Reference Extensions (aka External Services in old-speak) Reference extensions will need to be dynamically found and invoked, so we will probably need some kind of Tuscany runtime configuration side file that points at the library ( perhaps has some configuration parameters, etc). We could statically link, but then we would be forcing extension authors to recompile the whole of SCACPP. Component Language Extensions I put some info up about this on the wiki, but rereading it after my holiday and it's a tad unclear! Do we want to call components in other languages via proxy code generated with SCAGEN? Will we want to generate wrapper code in the other language, so that calling a component reference works like a normal language call? Can we avoid the SCAGEN development step? How will we map data types from C++ to the language and back again? Assembly Model Extensions We need to allow people to add their own binding.xxx element (or implementation.xxx, etc) to the sca.module (now sca.composite) file and have Tuscany use the extension when it reads it. Data Binding Extensions Allow other types of data to be passed between components and between composites. I think at the moment we only allow C++ primitives and SDO data objects. We will need to define SPIs for each of these areas - for Service and Reference extensions we can probably base it on the WS entrypoint and external service support in the current codebase, but the others will need more thinking about. I've veered off into extensibility here, without talking much about restructuring - does anyone have any good ideas about where things should go or how to make the code more modular? Cheers Andy -- Pete
Re: Inheriting Wiring infrastructure
On Aug 9, 2006, at 7:46 AM, Jeremy Boynes wrote: On Aug 9, 2006, at 7:35 AM, Hawkins, Joel wrote: Hello Jims (Venkata, and everyone else struggling with bindings, etc.) I have an OSGi binding implementation that's sort of working now (I can run the SupplyChain example in equinox, repackaged into a couple of bundles, etc). There's a binding.osgi that allows me to expose SCA services as OSGi services, and there's an implementation.osgi that allows me to consume OSGi services as SCA components. I'm sure it's not perfect, but it's a start. :-) Sounds like a pretty good start :-) I've also got some OSGi-specific implementations of some of the boot-strappy classes for dealing with classloader issues and some manager code that allows sca applications (packaged as bundles) to run in separate contexts. :-) I'd like to provide this code to Tuscany and help complete the implementation. How would you like me to proceed? Do you have time to look at it and point out where I've gone astray? Thank you. If you can create a JIRA and attach what you have as a patch or zip archive I would suggest we check this in to the trunk but do not include in the main build just yet. This sounds like a cool and valuable contribution. Yea that would be great. If you can do that, I'll go in and clean out the old equinox project shell I started a while back. Good to hear from you again too. Jim 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: SDO Samples
Robbie and I discussed on the 'phone my comments so far on the samples in the attached spreadsheet. I'm pasting the contents below for generality too. (I'm hoping that these will paste back into the bookmarks view of your eclipse environment Robbie.)
A couple of points that we thought might be worth picking out are1) how best in general to ensure that the user has a good experience with regards to class path and resource finding issues when first running these samples. Currently Robbies top level program has source code comments on how to ensure the class path is right, but its not only jars that need to be on the class path, but resources such as the xml and xsd files. I had to fix up my environment before I could get it running. I guess we should be catering for the lowest common denominator here, and assuming only a shell/command window + a jvm. Any thoughts on packaging of these samples would be welcome?
2) Robbie's sample has a top level manager which will step by step execute all the samples. Many editors and SDKs will interpret strings of a certain format as links into the code (e.g. when an exception prints to the console you can often click on a line in the exception and jump to the text in the code). I suggested printing such a link from the main() methods of each sample program, to allow the user when stepping through the sequence of programs to jump to the code of the sample they are running,
e.g.private static void defineCompanyTypes() throws Exception {System.out.println(Defining Types using XSD);System.out.println(org.apache.tuscany.samples.sdo.otherSources.CreateCompany.defineCompanyTypes
(CreateCompany.java:60));.any comments?
Description
Resource
Path
Location
SAMPLES: fragile, requires careful set
up, does this work on the command line
CreateDataObjectFromXsdAndXmlFiles.java
sample-sdo/src/main/java/org/apache/tuscany/samples/sdo/specCodeSnippets
line 67
SAMPLES ;-)
ExecuteSamples.java
samples-20060808/src/main/java/org/apache/tuscany/samples/sdo
line 52
SAMPLES: are these relative links
fragile, is there any robust way to
ensure these work across environments
SdoSampleConstants.java
samples-20060808/src/main/java/org/apache/tuscany/samples/sdo
line 30
SAMPLES: including ...
ExecuteSamples.java
samples-20060808/src/main/java/org/apache/tuscany/samples/sdo
line 61
SAMPLES: maintenance issue -- point to
web doc for instructions?
ExecuteSamples.java
samples-20060808/src/main/java/org/apache/tuscany/samples/sdo
line 35
SAMPLES: sp (is pp in snipets uk
english?) + others
ExecuteSamples.java
samples-20060808/src/main/java/org/apache/tuscany/samples/sdo
line 59
SAMPLES: i don't understand your comment. Is there a bug?
CreateCompany.java
samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/otherSources
line 161
SAMPLES:
seems odd for a sample to have main at the bottom
CreateCompany.java
samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/otherSources
line 98
SAMPLES:
would be nice to have some confirmation that the file was saved at the
location
PurchaseOrderCmdLine.java
samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/otherSources
line 63
SAMPLES: * @see
COMPANY_GENERATED_XML ???
CreateCompany.java
samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/otherSources
line 42
SAMPLES: CR causes
exception, null input or other error
input should be == 1 (with bad input message?)
PurchaseOrderCmdLine.java
samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/otherSources
line 120
SAMPLES: should the @link do something
here?
CreatePurchaseOrder.java
samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/otherSources
line 52
SAMPLES: sp
CreateCompany.java
samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/otherSources
line 40
SAMPLES: SP
PurchaseOrderCmdLine.java
samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/otherSources
line 324
SAMPLES: SP
ReadPurchaseOrder.java
samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/otherSources
line 50
SAMPLES: suggest including interpretable
link
CreateCompany.java
samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/otherSources
line 60
SAMPLES: what is the source of this
sample? can we ref it?
CreateCompany.java
samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/otherSources
line 18
SAMPLES:
I think rjm is filling out this test case --- check
AccessDataObjectUsingValidXPath.java
samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/specCodeSnippets
line 62
On 08/08/06, Robbie Minshall
[EMAIL PROTECTED] wrote:
Hi.I made an update ( updated overview for javadoc ) for the SDO Samples.There are still a few toDo's here that I am going to work on when I findsome time tomorrow ( namely a
[jira] Created: (TUSCANY-610) Initial OSGi support effort
Initial OSGi support effort --- Key: TUSCANY-610 URL: http://issues.apache.org/jira/browse/TUSCANY-610 Project: Tuscany Issue Type: New Feature Environment: Equinox implementation of OSGi Reporter: Joel Hawkins Attachments: OSGI-SCA.zip An initial implementation of an OSGi binding for exposing SCA services as OSGi services. An initial implementation of an OSGi implementation for reusing OSGi services as SCA atomic components An OSGi-aware bootstrap environment (which can probably be reduced a bit) A repackaging of some of the SupplyChain example There's one class derived from an EPL-copyrighted class - I left the EPL copyright intact. The zip contains the samples, the OSGi binding, and a patch for the core. Most of the patch is the OSGi launcher code. I don't think it belongs in the core, but that's where I had it while developing. The only other bit in the patch is a change of two of the Defaultbootstrapper's fields from private to protected. Also, some of the OSGi packaging for existing jars (spi, commands, etc) aren't part of the zip. Not sure how you want to deal with the repackaging issue. -- 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: Inheriting Wiring infrastructure
JIRA is in. Looking forward to working with Tuscany - lots to learn! Cheers, Joel -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2006 11:53 AM To: tuscany-dev@ws.apache.org Subject: Re: Inheriting Wiring infrastructure On Aug 9, 2006, at 7:46 AM, Jeremy Boynes wrote: On Aug 9, 2006, at 7:35 AM, Hawkins, Joel wrote: Hello Jims (Venkata, and everyone else struggling with bindings, etc.) I have an OSGi binding implementation that's sort of working now (I can run the SupplyChain example in equinox, repackaged into a couple of bundles, etc). There's a binding.osgi that allows me to expose SCA services as OSGi services, and there's an implementation.osgi that allows me to consume OSGi services as SCA components. I'm sure it's not perfect, but it's a start. :-) Sounds like a pretty good start :-) I've also got some OSGi-specific implementations of some of the boot-strappy classes for dealing with classloader issues and some manager code that allows sca applications (packaged as bundles) to run in separate contexts. :-) I'd like to provide this code to Tuscany and help complete the implementation. How would you like me to proceed? Do you have time to look at it and point out where I've gone astray? Thank you. If you can create a JIRA and attach what you have as a patch or zip archive I would suggest we check this in to the trunk but do not include in the main build just yet. This sounds like a cool and valuable contribution. Yea that would be great. If you can do that, I'll go in and clean out the old equinox project shell I started a while back. Good to hear from you again too. Jim 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] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[C++] A portable build system?
I'm still in the process of (re)learning C++ and related GCC automake, configure etc. so maybe this is a dumb question.. but would there be any way to make our builds portable between Linux and Windows, instead of using completely different build systems, i.e. Automake on Linux and VC++ on Windows? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-608) DAS diagrams don't show up in IE
[ http://issues.apache.org/jira/browse/TUSCANY-608?page=all ] Rick Rineholt resolved TUSCANY-608. --- Resolution: Fixed Simply applied the patch supplied. DAS diagrams don't show up in IE Key: TUSCANY-608 URL: http://issues.apache.org/jira/browse/TUSCANY-608 Project: Tuscany Issue Type: Bug Components: Website Reporter: Brent Daniel Attachments: lresende.patch.tuscany608.txt The images on 'http://incubator.apache.org/tuscany/das_index.html' don't show up in internet explorer. Firefox seems fine. The two image tags affected are: img src=./images/das_class_diagram.jpg width= height= align=middle usemap= / img src=./images/sdo_das_sm.jpg width= height= align=middle usemap= / It looks like IE is interpreting the empty width and height attributes as meaning the image is 0x0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-254) Add -interfaceDataObject codegen option to generate interfaces that extend SDO DataObject interface
[ http://issues.apache.org/jira/browse/TUSCANY-254?page=all ] Kapil Katyal updated TUSCANY-254: - Attachment: Tuscany254.patch Here is a patch to resolve this JIRA, can someone please review and apply this fix? Add -interfaceDataObject codegen option to generate interfaces that extend SDO DataObject interface --- Key: TUSCANY-254 URL: http://issues.apache.org/jira/browse/TUSCANY-254 Project: Tuscany Issue Type: Improvement Components: Java SDO Tools Environment: All Reporter: Dan Murphy Priority: Minor Fix For: Java-Mx Attachments: Tuscany254.patch The current Java generator generates POJO style java interfaces, if a developer need to use SDO methods then they need to explicitly cast to a DataObject. This wouold be unnecessary and result in better code if the generated classed extended DataObject. This could be acheived by adding a -interfaceDataObject flag to the generator... -- 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: Account request for new Tuscany committer: Kelvin Goodson
kelvin goodson wrote: Hi, just to check in case this is slowing the process up, it appears that ant had adhered to the prescribed format in his note; did the fact that you posted a link to the format suggest that there was something he hadn't done right? It was not a major mistake as such :). He hadn't cc'ed the mail to the committer who was voted in. Thats it. No this won't slow down the process, except that the committer doesn't know when his account is created. -- Chinthaka signature.asc Description: OpenPGP digital signature
Refactoring wire building: svn commit: r430113
A quick explanation of the commits I'm doing and as follow-up to some of the wiring questions... I'm in the process of working on a sample binding which I will commit later today. As part of this, I want to move wiring completely into the wire service and out of the builders. To do this, I needed to move callback-related information from the Java model extensions up to the generic model. After this is complete, the builders will not need knowledge of the wiring mechanism, although Service, Component, and Reference implementation will still need to know how to deal with a wire. Basically, as the builder registry processes the model, it will call out to the wire service to create the appropriate wire types for the SCAObject it is currently evaluating. The wire service will in turn delegate to the policy registry to decorate the wire with appropriate policy interceptors and handlers. After returning, the builder registry will provide the SCAObject with the newly created wire. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Big Bank Sample
Hi Jeremy I'd be interested in working on some variation of BigBank or maybe a new sample scenarion that would use a Ajax front end. Do you have any toughts on possible scenarios, or areas you would like to exercise in this ajax sampleotherwise I could think of something... - Luciano On 8/9/06, Jeremy Boynes [EMAIL PROTECTED] wrote: One thing we are looking for is real-world applications of SCA - things that can show off what Tuscany can do. If you have any applications in mind they would be welcome. These could be variants on the BigBank theme (say a Ajax front end) or something completely different. -- Jeremy On Aug 9, 2006, at 8:10 AM, Guo, Jeffrey wrote: Hi all, I would like to join the tuscany effort also, would this be a good starting point? I'd appreciate any guidance you coule provide. Thanks! Jeff -Original Message- From: Kapil Katyal [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2006 9:50 AM To: tuscany-dev@ws.apache.org Subject: Big Bank Sample Hi, Does anyone know the current status of the Big Bank Sample, specifically what is still required to get the sample up and running on the latest Tuscany code. We have a few resources here that can help with this effort. We're not too familiar with the new recursive model, but we're willing to learn if someone wants to help guide us. Thanks, Kapil - 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] -- - Luciano Resende SOA Opensource - Apache Tuscany -
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
Do you have time to chat some time today or tomorrow about where we are on wiring, callbacks via references (local and remote), and conversational support? I'm available for the next 1.5 hrs today and all day tomorrow (except for a 1-2pm EDT mandatory meeting). - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, August 08, 2006 12:03 PM Subject: Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks Yea for me too ;-). Do you want to take a look? I also posted a message describing some of the changes I made. Also, for next steps, we'll need to get this working with References (we only have component-to-component callbacks). Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Big Bank Sample
On Aug 9, 2006, at 12:29 PM, Luciano Resende wrote: Hi Jeremy I'd be interested in working on some variation of BigBank or maybe a new sample scenarion that would use a Ajax front end. Do you have any toughts on possible scenarios, or areas you would like to exercise in this ajax sampleotherwise I could think of something... I have this belief that SCA would make a good platform for building the server-side handlers for Ajax components. In that mode, the presentation side is done in the browser and the UI widgets make calls to the server consuming services just like anything else. This is a fine-grained, close-coupled service architecture between the browser and the host server. A simple scenario to demonstrate this would be to supplement a traditional JSP UI with one based on Ajax. For example, suppose we have an application with a set of services that provide its business logic that get called from server-based UI code (JSP, Struts, Spring, something) - this would be the traditional (dumb-browser) model. We then supplement that with an Ajax front-end which replaces the UI code with client-side JavaScript but leaves *all* the business logic unchanged. This shows how easy it is to implement this class of application on top of a service-based architecture. One way would be to take an application like MyValue, separate the UI from the services and then add the JS client code. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Initial support for new composite model, was: Switching C++ runtime to new composite model
I'll take a look at the windows side of things. Cheers, On 09/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Pete Robbins wrote: So are you changing the loader to load the schema from xsd/new instead of xsd? Personally I would just go for it and check in the new xsds as we need to get this working anyway. Cheers, So I just went for it and made a set of changes to provide an initial - minimal - support for the 0.95 composite assembly model and checked in these changes earlier this morning. Here's a quick summary of changes: - most Module, EntryPoint, ExternalService have been renamed to Composite, Service, Reference - build descriptors and scripts updated and working - on Linux only - new XSDs for the composite model - the ModelLoader ported to the new XSDs - application packaging structure changed to use composites to describe subsystems - Calculator sample ported to the composite model and working - BigBank sample ported to the composite and one inch from working Obvious limitations: - includes are not supported, we are scanning for composite files right now, this should be changed to use include - properties not really supported, I couldn't figure out to get the defaultValue from the XML element content - it's just my ignorance of the SDO APIs and I think I'll never get how the SDO Sequence actually works :) - no recursion / support for nested composites, this will require some code restructuring but is not needed by the samples - the application packaging story still based on the old structure from M1 (a subsystems and composites directory), we may want to start a design discussion to see where we want to take this. To summarize, this is just a first step... there is a lot to do to provide complete support. Support for includes and properties would be great to have... Also I am still not able to test on Windows, I'm not sure how to refactor the Windows build scripts and VC projects. Is anybody interested in helping with the code changes and/or the Windows integration? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: [C++] Do we need SDO annotations in the SCDL XSDs?
Good! because the SDO XPath code looks a bit messy :-( Cheers, On 09/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Pete Robbins wrote: I'll take a look at the XPath stuff in SDO and see if we can avoid the annotations for the new assembly model schema. It may not be simple so we may have to annotate the schema to start with and fix this later. Cheers, OK, let me know. If it turns out that we need the annotations to start with as a workaround to this issue with dots, then no problem I'll add them. Thanks. Interesting how sometimes expected design issues turn into non-issues once you actually write code :) I tried to use the XSDs without annotations, and... everything works! This is because the ModelLoader works with the base XSD complex types and substitution groups, which contain no dots in their names. We never do DataObject.get(interface.cpp) for example, we only do DataObject.get(interface)... So there was no problem after all :) we don't need any annotations in the SCDL XSDs. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: [C++] A portable build system?
I believe automake can run on Windows using some linux portability layer (I forget what it's called). I'll need to look into it some more. We should also see what other Apache c/C++ projects use. On 09/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I'm still in the process of (re)learning C++ and related GCC automake, configure etc. so maybe this is a dumb question.. but would there be any way to make our builds portable between Linux and Windows, instead of using completely different build systems, i.e. Automake on Linux and VC++ on Windows? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: Inheriting Wiring infrastructure
On Aug 9, 2006, at 9:32 AM, Hawkins, Joel wrote: JIRA is in. Looking forward to working with Tuscany - lots to learn! Thanks - quite a lot there, may take some time to grok it all. One immediate question though. Apache cannot accept EPL licensed items in source form due to the downstream requirements. How complex is the code in question and could you provide a description that would allow someone who has not seen it to re-implement under ASL (i.e. a work that was not a derivative)? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Booting an SCA app without creating an scdl file
I'm trying to dynamically define a service based on an interface and I was wondering, Is there currently a way to pass the description of an SCA application directly rather than passing the information through the defualt.scdl? -David W
OSGI headers, was: Using osgi plugin to generate manifests
Joel With your knowledge of OSGi, is this header set reasonable or are there others we should be adding? -- Jeremy On Jul 21, 2006, at 3:33 PM, Jeremy Boynes wrote: On Jul 21, 2006, at 3:25 PM, Raymond Feng wrote: Several questions: 1) What's going to happen if a 3rd party dependency is not OSGi bundled? 2) How does it deal with Require-Bundle? It seems that it can populate Import-Package automatically. 3) Can you post a sample MANIFEST.MF generated by the plugin? Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: jboynes Build-Jdk: 1.5.0_06 Extension-Name: sca-api-r0.95 Specification-Title: API classes for the Service Component Architecture Specification-Vendor: The Apache Software Foundation Implementation-Vendor: The Apache Software Foundation Implementation-Title: sca-api-r0.95 Implementation-Version: 1.0-SNAPSHOT Export-Package: org.osoa.sca.annotations, org.osoa.sca Bundle-Version: 1.0.SNAPSHOT Bundle-Vendor: The Apache Software Foundation Bundle-Name: SCA API Bundle-Classpath: . Bundle-Localization: plugin Bundle-Description: API classes for the Service Component Architecture Bundle-SymbolicName: org.osoa.sca I found this document useful: http://docs.safehaus.org/display/ OSGI/OSGi+Plugin+for+Maven+2.0 That's as much as I know as well. - 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]
Binding extension example
I've checked in an example of a simple binding (r430211) that demonstrates creating services and references. For references, the binding just echoes a single param back to the client. Related to this, I've also completed a series of commits that move application wiring from the responsibility of the builders to initiate up into the builder registry which delegates to the system wire service. Once a Service, Reference, or Component is created and returned from a builder, the builder registry will invoke the wire service to create the appropriate inbound and outbound wires. These wires will then be injected into the Service, Reference or Component. At a later point, the connector will bridge outbound (source) to inbound (target) wires. Services and References will generally not need to do anything other than hold onto the wires (implemented as a convenience by the extension base classes), but components are responsible for implementing a strategy for injecting them onto implementation instances as the latter are requested. In the case of Java, this involves delegating back to the wire service to create a proxy fronting the wire and implementing the appropriate reference interface. This proxy will be injected onto an implementation instance as it is created. BPEL or an other implementation type may do something entirely different and maybe not even use proxies. Certain types of composite components may need to manually bridge Services to targets. For example, a Spring composite is opaque to the SCA wiring fabric in that its beans are not visible as components. The Spring builder is responsible for delegating to the builder registry to create a service which it then must provide with a target invoker capable of dispatching into the Spring application context and to a target bean. This can be viewed as the SCA wiring mechanism delegating to Spring for internal wiring. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Refactoring of Service Contracts
Currently we use java.lang.Method to represent operations in the runtime. It has been brought up by various people that this is not ideal, for example, in dealing with E4X, data binding, and proxying strategies that do not rely on reflection. It has also been an issue with callbacks as we are having to imbed knowledge of Java annotations related to asynchrony into the connector. Instead, I think we need to have a general base representation of operations and service contracts in general. One of the original problems we encountered that forced us to move from a neutral representation to java.lang.Method was the complexity of dealing with the model when code needed to map from the general representation to the specific operation, e.g. a method on a class. This can probably be alleviated by using the pattern we have adopted with the current model where a base class is extended with one that provides a more specific representation, for example JavaMappedProperty, JavaMappedReference, and JavaMappedService. Similarly, we could do something to the effect of JavaMappedServiceContract. Another issue that has come up is representation of data binding types for parameters. We could perhaps have a generic representation of an operation, Operation, that has a getParameterTypes() which returns a collection of Class elements. The actual class elements would correspond to type system of the specific data binding used. Now that the wiring has been moved completely into the wire service and we are working on a number of extension types, I believe it would be a good time to get this figured out. Thoughts? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Booting an SCA app without creating an scdl file
Hi David, Yes, you should be able to do this, although you may need to create your own Bootstrapper implementation as opposed to DefaultBootstrapper. Depending on what you want to do, you can either create an in memory representation of the model, passing it to the Deployer system service or you can create one of the subclasses of SCAObject and pass it to CompositeComponent.register() if you want to avoid the model altogether and do something like PicoContainer (http://www.picocontainer.org/). If you opt for the latter you will be responsible for wiring. The above assumes you want to essentially create a custom runtime distribution. If your goal is to dynamically bind something from some type of instrumentation, then that would best be done through a management API that hasn't been defined but which people have talked about. The custom runtime option will likely not work from application code as the system classloaders are isolated. Also, in Dependency Injection-based systems, I generally find dynamic binding to be an anti-pattern that is best avoided through configuration. Perhaps you could detail a little more what you are trying to do? Also, if you wanted to talk about a potential management API, I know several of us would be interested. Jim On Aug 9, 2006, at 2:49 PM, David Wheeler wrote: I'm trying to dynamically define a service based on an interface and I was wondering, Is there currently a way to pass the description of an SCA application directly rather than passing the information through the defualt.scdl? -David W - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-607) Provide automated tomcat integration for DAS Samples
[ http://issues.apache.org/jira/browse/TUSCANY-607?page=all ] Kevin Williams closed TUSCANY-607. -- Resolution: Fixed verified with revision: 430224 Provide automated tomcat integration for DAS Samples Key: TUSCANY-607 URL: http://issues.apache.org/jira/browse/TUSCANY-607 Project: Tuscany Issue Type: Improvement Components: Java DAS Samples Affects Versions: Java-M2 Reporter: Luciano Resende Priority: Critical Attachments: lresende.patch.08082006.txt This would allow a user to create a tomcat distribution with all necessary dependencies and databases to run DAS samples applications. This will also be used by the automated tests that will verify the proper running of the DAS Sample Applications. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-440) Automate DAS Stand alone sample
[ http://issues.apache.org/jira/browse/TUSCANY-440?page=all ] Kevin Williams closed TUSCANY-440. -- Resolution: Duplicate Fixed as part of TUSCANY-607 Automate DAS Stand alone sample --- Key: TUSCANY-440 URL: http://issues.apache.org/jira/browse/TUSCANY-440 Project: Tuscany Issue Type: Bug Components: Java DAS Samples Affects Versions: Java-Mx Reporter: Kevin Williams Fix For: Java-Mx Attachments: TUSCANY-440.zip The stand-alone DAS sample is built and deployed as part of running mvn from java/testing/tomcat. An automated test should also be run as part of this task to exercise the sample. The addition of an htmlunit test case similar to the one found under java/testing/tomcat/bigbank should suffice. -- 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]
Add Luciano to JIRA system
Jeremy, Can you please add Luciano to the JIRA system so that he can assign himself issues? Thanks, --Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Add Luciano to JIRA system
Added to tuscany-developers -- Jeremy On Aug 9, 2006, at 8:50 PM, Kevin Williams wrote: Jeremy, Can you please add Luciano to the JIRA system so that he can assign himself issues? Thanks, --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: Refactoring of Service Contracts
On Aug 9, 2006, at 8:16 PM, Jim Marino wrote:
Another issue that has come up is representation of data binding
types for parameters. We could perhaps have a generic
representation of an operation, Operation, that has a
getParameterTypes() which returns a collection of Class elements.
The actual class elements would correspond to type system of the
specific data binding used.
I was chatting with Raymond at OSCON about metadata for the data
binding framework and I think that is relevant here. We talked about
representing the data being bound using three pieces of information:
* the physical Java class in use in the runtime
* a logical identifier for the data type
* metadata defining the association between the two
The physical class is Java because the runtime is written in Java so
we need to pass around Java Objects. In terms of data binding this
would be the Class of the actual object that was passed to the
binding framework. This may be a user supplied Object, but may also
be some other representation of it such as a DataObject, a Document,
an XMLStreamReader or an InputStream.
The logical identifier is used to describe the data that is
represented by the physical object. If the type scheme is Java then
this would be the same Class as that used for the physical type. For
XML type schemes this would be something like the QName of the type.
This is used so that we know the type of object the user is passing
even when that is not apparent from the physical form - for example,
it would provide information about what ca be read from a stream.
The metadata adds more information about the object that can provide
hints about the format that would factor into the binding frameworks
choice of technology. For example, it may provide the size on a
stream which might be used by the framework to decide between a
technology that would pull the stream content into memory for random
access vs. one that would keep it on the stream or spool it to disk.
It may also provide user hints - for example, that although the user
had specified an actual Java interface for the physical object they
also wanted the implementation to be cross-castable to DataObject.
I think this ties into the service contract as this metadata should
be used to represent the parameters to the operation rather than a
simple collection of Class elements. Something like:
class DataTypeP, L {
ClassP physical;
L logical;
MapString, Object metadata;
}
class Operation {
String name;
DataType?,? returnType;
ListDataType?,? parameterTypes;
boolean nonBlocking;
}
class ServiceContract {
Class? interfaceClass; // optional, used if there is an actual
interface for this contract
Class? callbackClass; // optional, used if there is an actual
interface for the callback
ListOperation operations;
ListOperation callbackOperations;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
