Re: [C++] A portable build system?
You can use cygwin to do gcc compiles for windows. It comes with automake (don't know what version) and can be integrated with Eclipse CDT. S On 8/9/06, Pete Robbins [EMAIL PROTECTED] wrote: 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: [C++] A portable build system?
On 10/08/06, Simon Laws [EMAIL PROTECTED] wrote: You can use cygwin to do gcc compiles for windows. It comes with automake (don't know what version) and can be integrated with Eclipse CDT. S That's the one! Does it produce dll's that run native on windows or does the output depend on other libraries? -- Pete
Re: [C++] A portable build system?
You can make native windows dll's and executables. The last time I was involved in this kind of build we actually used ant on windows and linux in top of gcc (in cygwin for windows) to drive the build for the large number of different systems we had to support (there were some strange HPC type ones). IMHO though the result was rather too complicated. I don't know automake but if you have it working well on linux it would be good to see how well it supports a windows build before doing anything more exotic. S On 8/10/06, Pete Robbins [EMAIL PROTECTED] wrote: On 10/08/06, Simon Laws [EMAIL PROTECTED] wrote: You can use cygwin to do gcc compiles for windows. It comes with automake (don't know what version) and can be integrated with Eclipse CDT. S That's the one! Does it produce dll's that run native on windows or does the output depend on other libraries? -- Pete
maven-assembly-plugin version?
Hi, The maven-assembly-plugin version we used (2.2-SNAPSHOT) caused a lot of problems in my build. Is there any reason why we cant use the stable version 2.1? I have tried 2.1, it works fine. Thanks, Jervis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven-assembly-plugin version?
Forgot to mention, this is used by distribution standalone module. -Original Message- From: Liu, Jervis Sent: Thursday, August 10, 2006 5:04 PM To: tuscany-dev@ws.apache.org Subject: maven-assembly-plugin version? Hi, The maven-assembly-plugin version we used (2.2-SNAPSHOT) caused a lot of problems in my build. Is there any reason why we cant use the stable version 2.1? I have tried 2.1, it works fine. Thanks, Jervis - 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: separate SDO Java distribution
Jeremy, I think that bin and lib directories should be fine. If you have the bandwidth to help with the assembly definition that would be great, thanks. Kelvin On 09/08/06, Jeremy Boynes [EMAIL PROTECTED] wrote: 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] -- Best Regards Kelvin Goodson
Re: A parsing bug of trunk?
For the JavaScript question the problem is the JavaScript container isn't
included by default in the standalone distribution. As a work around for now
you could either modify the assembly standalone.xml to include the
JavaScript container when its building the distribution or you can
manually copy the javascript-1.0-SNAPSHOT.jar to the launcher extension
directory and its dependency jars js.jar and xbean.jar to the launcher boot
directory.
...ant
On 8/10/06, Chiond Huang [EMAIL PROTECTED] wrote:
Hi, all.
We are faced to parsing exceptions in the loading phase on two
occasions.
I've changed a little of the run.bat of Supplychain into below to
run the javascript sample:
echo off
rem set java_debug_set=-Xdebug -Xnoagent
-Xrunjdwp:transport=dt_socket,address=3720,server=y,suspend=y
mkdir target\standalone
pushd target\standalone
jar -xf
%USERPROFILE%\.m2\repository\org\apache\tuscany\standalone\1.0-SNAPSHOT\standalone-
1.0-SNAPSHOT-bin.zip
popd
java %java_debug_set% -jar target\standalone\bin\launcher.jar --classpath
%USERPROFILE%\.m2\repository\org\apache\tuscany\samples\sca\sample-helloworld-javascript\1.0-SNAPSHOT\sample-
helloworld-javascript-1.0-SNAPSHOT.jar %*
But when I ran it, it returned exception:
C:\workspace\sandbox3\java\samples\sca\helloworldJavaScriptrun
C:\workspace\sandbox3\java\samples\sca\helloworldJavaScriptecho off
Exception in thread main
org.apache.tuscany.spi.loader.UnrecognizedElementExce
ption: {http://tuscany.apache.org/xmlns/js/1.0}implementation.js [{
http://tuscan
y.apache.org/xmlns/js/1.0}implementation.js]
Context stack trace: [HelloWorldComponent]
at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(
LoaderRegistryImpl.java:88)
at
org.apache.tuscany.core.loader.ComponentLoader.loadImplementation(Com
ponentLoader.java:128)
at org.apache.tuscany.core.loader.ComponentLoader.load(
ComponentLoader.java:82)
at org.apache.tuscany.core.loader.ComponentLoader.load(
ComponentLoader.java:55)
at org.apache.tuscany.core.loader.LoaderRegistryImpl.load
(LoaderRegistry
Impl.java:90)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load
(CompositeLoader.java:70)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load
(CompositeLoader.java:48)
at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(
LoaderRegistryImpl.java:90)
at org.apache.tuscany.core.loader.LoaderRegistryImpl.load
(LoaderRegistry
Impl.java:107)
at
org.apache.tuscany.core.implementation.system.loader.SystemCompositeComponentTypeLoader.loadFromSidefile
(SystemCompositeComponentTypeLoader.java:62)
at
org.apache.tuscany.core.implementation.system.loader.SystemCompositeC
omponentTypeLoader.load(SystemCompositeComponentTypeLoader.java:53)
at
org.apache.tuscany.core.implementation.system.loader.SystemCompositeC
omponentTypeLoader.load(SystemCompositeComponentTypeLoader.java:35)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(
LoaderRegistryImpl.java:157)
at org.apache.tuscany.core.deployer.DeployerImpl.load(
DeployerImpl.java:
111)
at org.apache.tuscany.core.deployer.DeployerImpl.deploy(
DeployerImpl.java:90)
at org.apache.tuscany.core.launcher.Launcher.bootApplication(
Launcher.ja
va:158)
at org.apache.tuscany.core.launcher.MainLauncher.boot(
MainLauncher.java:
138)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.tuscany.launcher.MainLauncherBooter.main
(MainLauncherBoote
r.java:67)
Moreover, I faced a similar exception in another situation. In sample
supplychain, which we can run the testcase successfully. Then we switched
then annotation injection of reference into definition injection of
reference in .componentType files. The details are below:
1. Remove the original annotations of reference in CustomerComponentImpl
2. Wrote a new CustomerComponentImpl.componentType and put it in the
same dir of CustomerComponentImpl.java
3. Run the testcase of supplychain.
The text of componentType is:
?xml version=1.0 encoding=ASCII?
componentType xmlns=http://www.osoa.org/xmlns/sca/1.0; xmlns:xsd=
http://www.w3.org/2001/XMLSchema;
service name=CustomerService
interface.java interface=supplychain.Customer/
/service
reference name=retailer
interface.java interface=supplychain.Retailer/
/reference
/componentType
And the exception is:
org.apache.tuscany.spi.loader.UnrecognizedElementException: {
http://www.osoa.org/xmlns/sca/1.0}componentType [{
http://www.osoa.org/xmlns/sca/1.0}componentType]
Context stack trace: [CustomerComponent]
at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(
[jira] Created: (TUSCANY-611) RMI Binding
RMI Binding --- Key: TUSCANY-611 URL: http://issues.apache.org/jira/browse/TUSCANY-611 Project: Tuscany Issue Type: Bug Reporter: Venkatakrishnan Attachments: Tuscany-RMI-Binding-Aug-10.diff, Tuscany-RMI-Binding-Reference-Sample-Aug-10.diff, Tuscany-RMI-Binding-Service-Sample-Aug-10.diff SCA RMI Binding with samples for SCA Reference and SCA Service using RMI Binding. Here is a first cut implementation for this. Could somebody please review and apply? Also I have had the following issues un-resolved: - - The samples can be tested thro the Testcases in them. These testcases work from eclipse as long as I have added the RMI-Binding Eclipse project to the classpath. Otherwise the binding does get picked up. The same is the issue when trying to execute the testcases from maven. Could somebody please help in fixing this? Thanks. Note :- I shall be working further with this binding to address the following : - - there is single attribute called 'uri' for the binding. I shall be splitting this to host, port and service name with defaults to each when not specified. - it is now required the that SCA Service require a component to implement the interface Remote. I imagine this to be intrusive. All that a developer should do is pick up an existing component with a 'non remote' interface and simply deploy it exposing the service as RMI. The binding should dynamically be able to generate a remote interface and a proxy and host it as a facade to this implementation. - will be glad to take forward any other inputs from the community as well. Thanks - Venkat -- 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] Assigned: (TUSCANY-611) RMI Binding
[ http://issues.apache.org/jira/browse/TUSCANY-611?page=all ] ant elder reassigned TUSCANY-611: - Assignee: ant elder RMI Binding --- Key: TUSCANY-611 URL: http://issues.apache.org/jira/browse/TUSCANY-611 Project: Tuscany Issue Type: Bug Reporter: Venkatakrishnan Assigned To: ant elder Attachments: Tuscany-RMI-Binding-Aug-10.diff, Tuscany-RMI-Binding-Reference-Sample-Aug-10.diff, Tuscany-RMI-Binding-Service-Sample-Aug-10.diff SCA RMI Binding with samples for SCA Reference and SCA Service using RMI Binding. Here is a first cut implementation for this. Could somebody please review and apply? Also I have had the following issues un-resolved: - - The samples can be tested thro the Testcases in them. These testcases work from eclipse as long as I have added the RMI-Binding Eclipse project to the classpath. Otherwise the binding does get picked up. The same is the issue when trying to execute the testcases from maven. Could somebody please help in fixing this? Thanks. Note :- I shall be working further with this binding to address the following : - - there is single attribute called 'uri' for the binding. I shall be splitting this to host, port and service name with defaults to each when not specified. - it is now required the that SCA Service require a component to implement the interface Remote. I imagine this to be intrusive. All that a developer should do is pick up an existing component with a 'non remote' interface and simply deploy it exposing the service as RMI. The binding should dynamically be able to generate a remote interface and a proxy and host it as a facade to this implementation. - will be glad to take forward any other inputs from the community as well. Thanks - Venkat -- 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: Binding extension example
Great stuff Jim, these changes look really good to me. Makes implementing a binding way easier. What do you think about having an abstract SPI class for the TargetInvoker which includes all the cachable, optimizable and invoke methods? ...ant On 8/10/06, Jim Marino [EMAIL PROTECTED] wrote: 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]
[jira] Updated: (TUSCANY-611) RMI Binding
[ http://issues.apache.org/jira/browse/TUSCANY-611?page=all ] Venkatakrishnan updated TUSCANY-611: Attachment: Tuscany-RMI-Binding-Aug-10-Updated.diff Hi... there is one addition that has been missed out in the prev. patch. My sincere apologies for that goof-up here is the updated patch. Thanks. RMI Binding --- Key: TUSCANY-611 URL: http://issues.apache.org/jira/browse/TUSCANY-611 Project: Tuscany Issue Type: Bug Reporter: Venkatakrishnan Assigned To: ant elder Attachments: Tuscany-RMI-Binding-Aug-10-Updated.diff, Tuscany-RMI-Binding-Aug-10.diff, Tuscany-RMI-Binding-Reference-Sample-Aug-10.diff, Tuscany-RMI-Binding-Service-Sample-Aug-10.diff SCA RMI Binding with samples for SCA Reference and SCA Service using RMI Binding. Here is a first cut implementation for this. Could somebody please review and apply? Also I have had the following issues un-resolved: - - The samples can be tested thro the Testcases in them. These testcases work from eclipse as long as I have added the RMI-Binding Eclipse project to the classpath. Otherwise the binding does get picked up. The same is the issue when trying to execute the testcases from maven. Could somebody please help in fixing this? Thanks. Note :- I shall be working further with this binding to address the following : - - there is single attribute called 'uri' for the binding. I shall be splitting this to host, port and service name with defaults to each when not specified. - it is now required the that SCA Service require a component to implement the interface Remote. I imagine this to be intrusive. All that a developer should do is pick up an existing component with a 'non remote' interface and simply deploy it exposing the service as RMI. The binding should dynamically be able to generate a remote interface and a proxy and host it as a facade to this implementation. - will be glad to take forward any other inputs from the community as well. Thanks - Venkat -- 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: maven-assembly-plugin version?
IIRC the 2.1 version caused the build to be run twice. We have been using the snapshot for a while - what problems did you see? -- Jeremy On Aug 10, 2006, at 2:04 AM, Liu, Jervis wrote: Hi, The maven-assembly-plugin version we used (2.2-SNAPSHOT) caused a lot of problems in my build. Is there any reason why we cant use the stable version 2.1? I have tried 2.1, it works fine. Thanks, Jervis - 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-612) Java SDO Overview doc doesnt address setting of M2_REPO variable
Java SDO Overview doc doesnt address setting of M2_REPO variable Key: TUSCANY-612 URL: http://issues.apache.org/jira/browse/TUSCANY-612 Project: Tuscany Issue Type: Bug Reporter: Kelvin Goodson when initializing a new eclipse environment as per the instructions in the java sdo overview, the eclipse projects generated by the mvn eclipse:eclipse commands don't build until the M2_REPO variable is set. This needs describing in the docvument (instruction outline -- right click a project, properties, build path, libraries, click a library with M2_REPO var referenced, edit, variable, folder, browse to repository (on windows this is c:\Documents and Settings\username\.m2\repository) and set the variable) -- 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: [C++] Initial support for new composite model, was: Switching C++ runtime to new composite model
Deployment question: Does the name of the .composite file HAVE to match the name of the composite? Previously we just loaded any sca.module file and the name= parameter gave the module name. There is still a name= parameter so we end up with a file called CalculatorComposite.composite with composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=CalculatorComposite Either the file naming convention or the name= is redundant? On 09/08/06, Pete Robbins [EMAIL PROTECTED] wrote: 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 -- Pete
Re: maven-assembly-plugin version?
If Jervis hit the same issue I did, the problem was that the 2.2-SNAPSHOT is now dependent on org.codehaus.plexus:plexus-archiver:1.0-alpha-7-SNAPSHOT which wasn't available in any of the configured repositories. I ended up pulling it from snapshots.repository.codehaus.org to resolve the dependency. Jeremy Boynes wrote: IIRC the 2.1 version caused the build to be run twice. We have been using the snapshot for a while - what problems did you see? -- Jeremy On Aug 10, 2006, at 2:04 AM, Liu, Jervis wrote: Hi, The maven-assembly-plugin version we used (2.2-SNAPSHOT) caused a lot of problems in my build. Is there any reason why we cant use the stable version 2.1? I have tried 2.1, it works fine. Thanks, Jervis - 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: [C++] Initial support for new composite model, was: Switching C++ runtime to new composite model
... also are we enforcing the directory containing the composite to also be named after the composite? On 10/08/06, Pete Robbins [EMAIL PROTECTED] wrote: Deployment question: Does the name of the .composite file HAVE to match the name of the composite? Previously we just loaded any sca.module file and the name= parameter gave the module name. There is still a name= parameter so we end up with a file called CalculatorComposite.compositewith composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=CalculatorComposite Either the file naming convention or the name= is redundant? On 09/08/06, Pete Robbins [EMAIL PROTECTED] wrote: 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 -- Pete -- Pete
RE: Inheriting Wiring infrastructure
Well, now I know the boundaries of the Apache/Eclipse cross-licensing agreement. :-) The code in question is straight-forward reflection code to find and invoke a method (3 lines of code + exception handling). I use it to pull the ClassLoader out of a bundle context. I'll submit a fix to get rid of the EPL dependency. Cheers, Joel -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Wed 8/9/2006 5:16 PM To: tuscany-dev@ws.apache.org Subject: 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] 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
I had an offline chat with lresende about a similar effort for DAS, so perhaps we could meet on IRC sometime soon, and go through what needs to be done? Cheers, Kelvin. On 09/08/06, Jeremy Boynes [EMAIL PROTECTED] wrote: 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] -- Best Regards Kelvin Goodson
RE: maven-assembly-plugin version?
well, not a big issue, but the snapshot version have to be downloaded everyday, and sometimes the snapshot version is not very stable. For example, today's assembly-plugin try to download org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7-SNAPSHOT, but I checked http://www.ibiblio.org/maven2/ repository, for some reasons, it is not available there yet. Missing: -- 1) org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.codehaus.plexus -DartifactId=plexus-archiver \ -Dversion=1.0-alpha-7-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.maven.plugins:maven-assembly-plugin:maven-plugin:2.2-20060809.234942-6 2) org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7-SNAPSHOT -- 1 required artifact is missing. Thanks, Jervis -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Thursday, August 10, 2006 9:09 PM To: tuscany-dev@ws.apache.org Subject: Re: maven-assembly-plugin version? IIRC the 2.1 version caused the build to be run twice. We have been using the snapshot for a while - what problems did you see? -- Jeremy On Aug 10, 2006, at 2:04 AM, Liu, Jervis wrote: Hi, The maven-assembly-plugin version we used (2.2-SNAPSHOT) caused a lot of problems in my build. Is there any reason why we cant use the stable version 2.1? I have tried 2.1, it works fine. Thanks, Jervis - 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: OSGI headers, was: Using osgi plugin to generate manifests
That's excately what I used. The one thing I'd add a version for the exported packages. It helps the package admin service avoid runtime incompatabilities when sewing up bundle dependencies. Export-Package: org.osoa.sca.annotations;version=1.0, org.osoa.sca;version=1.0 Cheers, Joel -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Wed 8/9/2006 7:32 PM To: tuscany-dev@ws.apache.org Subject: 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] 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: [C++] Initial support for new composite model, was: Switching C++ runtime to new composite model
Also, I get a NPE when running SCAGEN on the BigBank sample - everything seems to get happily generated though. The output is below - anyone else see this? Pete - are you still using VC++6 for windows development? I have a VC++7 SCA build working happily here if you want the patch. Andy On 8/10/06, Andrew Borley [EMAIL PROTECTED] wrote: Similar question from me - do similar things apply for the subsystem .composite file that replace sca.subsystem? Andy On 8/10/06, Pete Robbins [EMAIL PROTECTED] wrote: ... also are we enforcing the directory containing the composite to also be named after the composite? On 10/08/06, Pete Robbins [EMAIL PROTECTED] wrote: Deployment question: Does the name of the .composite file HAVE to match the name of the composite? Previously we just loaded any sca.modulefile and the name= parameter gave the module name. There is still a name= parameter so we end up with a file called CalculatorComposite.compositewith composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=CalculatorComposite Either the file naming convention or the name= is redundant? On 09/08/06, Pete Robbins [EMAIL PROTECTED] wrote: 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 -- Pete -- Pete $ java -jar $TUSCANY_SCACPP/bin/scagen.jar -dir . -output . -verbose Scagen processing SCA composite file d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\Accounts.composite Scagen processing C++ implementation header d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountServiceImpl.h Scagen processing SCA componentType file d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountServiceImpl.componentType Scagen processing C++ interface header d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountService.h Scagen creating SCA for C++ proxy implementation d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountServiceImpl_AccountService_Proxy.cpp Scagen creating SCA for C++ proxy header d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountServiceImpl_AccountService_Proxy.h Scagen creating SCA for C++ wrapper implementation d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountServiceImpl_AccountService_Wrapper.cpp Scagen creating SCA for C++ wrapper header d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountServiceImpl_AccountService_Wrapper.h Scagen processing C++ interface header d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountDataService.h Scagen creating SCA for C++ proxy implementation
Re: maven-assembly-plugin version?
I too ended up downloading an available version of the snapshot jar from the codehaus site and renamed it to 1.0-alpha-7-SNAPSHOT after which the build has gone thro - Venkat On 8/10/06, Liu, Jervis [EMAIL PROTECTED] wrote: well, not a big issue, but the snapshot version have to be downloaded everyday, and sometimes the snapshot version is not very stable. For example, today's assembly-plugin try to download org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7-SNAPSHOT, but I checked http://www.ibiblio.org/maven2/ repository, for some reasons, it is not available there yet. Missing: -- 1) org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.codehaus.plexus-DartifactId=plexus-archiver \ -Dversion=1.0-alpha-7-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.maven.plugins:maven-assembly-plugin:maven-plugin:2.2-20060809.234942-6 2) org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7-SNAPSHOT -- 1 required artifact is missing. Thanks, Jervis -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Thursday, August 10, 2006 9:09 PM To: tuscany-dev@ws.apache.org Subject: Re: maven-assembly-plugin version? IIRC the 2.1 version caused the build to be run twice. We have been using the snapshot for a while - what problems did you see? -- Jeremy On Aug 10, 2006, at 2:04 AM, Liu, Jervis wrote: Hi, The maven-assembly-plugin version we used (2.2-SNAPSHOT) caused a lot of problems in my build. Is there any reason why we cant use the stable version 2.1? I have tried 2.1, it works fine. Thanks, Jervis - 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: [C++] Initial support for new composite model, was: Switching C++ runtime to new composite model
I haven't seen the NPE. I'm currently trying to get the scatest program working on linux. I'm happy to leave VC6 broken for now until the changes settle down. If you are happy with the VC7 then please submit the patch. Were there many changes? Cheers, On 10/08/06, Andrew Borley [EMAIL PROTECTED] wrote: Also, I get a NPE when running SCAGEN on the BigBank sample - everything seems to get happily generated though. The output is below - anyone else see this? Pete - are you still using VC++6 for windows development? I have a VC++7 SCA build working happily here if you want the patch. Andy On 8/10/06, Andrew Borley [EMAIL PROTECTED] wrote: Similar question from me - do similar things apply for the subsystem .composite file that replace sca.subsystem? Andy On 8/10/06, Pete Robbins [EMAIL PROTECTED] wrote: ... also are we enforcing the directory containing the composite to also be named after the composite? On 10/08/06, Pete Robbins [EMAIL PROTECTED] wrote: Deployment question: Does the name of the .composite file HAVE to match the name of the composite? Previously we just loaded any sca.modulefile and the name= parameter gave the module name. There is still a name= parameter so we end up with a file called CalculatorComposite.compositewith composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=CalculatorComposite Either the file naming convention or the name= is redundant? On 09/08/06, Pete Robbins [EMAIL PROTECTED] wrote: 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 -- Pete -- Pete $ java -jar $TUSCANY_SCACPP/bin/scagen.jar -dir . -output . -verbose Scagen processing SCA composite file d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\Accounts.composite Scagen processing C++ implementation header d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountServiceImpl.h Scagen processing SCA componentType file d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountServiceImpl.componentType Scagen processing C++ interface header d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountService.h Scagen creating SCA for C++ proxy implementation d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountServiceImpl_AccountService_Proxy.cpp Scagen creating SCA for C++ proxy header d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountServiceImpl_AccountService_Proxy.h Scagen
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
Hi Jim, When you have some time to chat, I have a few questions about references. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding extension example
Yea we could do that. Probably the one invoke method that takes the payload from the message could be abstracted and if there is a special target type that needs access to message headers or something it could just override it. Do you want to create one as I'm out later today? Jim On Aug 10, 2006, at 5:35 AM, ant elder wrote: Great stuff Jim, these changes look really good to me. Makes implementing a binding way easier. What do you think about having an abstract SPI class for the TargetInvoker which includes all the cachable, optimizable and invoke methods? ...ant On 8/10/06, Jim Marino [EMAIL PROTECTED] wrote: 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] - 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
OK. I have the sca runtime building on vc6 fine. Calculator project builds fine too. Having some teething problems getting it running. On 10/08/06, Andrew Borley [EMAIL PROTECTED] wrote: Not many - it was mostly a case of putting the new files in and taking the old ones out. Saying that, I haven't actually got the samples going yet - BigBank falls over for some reason, currently getting Calculator going. When I've got stuff going I'll raise a Jira and put up a patch. Cheers On 8/10/06, Pete Robbins [EMAIL PROTECTED] wrote: I haven't seen the NPE. I'm currently trying to get the scatest program working on linux. I'm happy to leave VC6 broken for now until the changes settle down. If you are happy with the VC7 then please submit the patch. Were there many changes? Cheers, On 10/08/06, Andrew Borley [EMAIL PROTECTED] wrote: Also, I get a NPE when running SCAGEN on the BigBank sample - everything seems to get happily generated though. The output is below - anyone else see this? Pete - are you still using VC++6 for windows development? I have a VC++7 SCA build working happily here if you want the patch. Andy On 8/10/06, Andrew Borley [EMAIL PROTECTED] wrote: Similar question from me - do similar things apply for the subsystem .composite file that replace sca.subsystem? Andy On 8/10/06, Pete Robbins [EMAIL PROTECTED] wrote: ... also are we enforcing the directory containing the composite to also be named after the composite? On 10/08/06, Pete Robbins [EMAIL PROTECTED] wrote: Deployment question: Does the name of the .composite file HAVE to match the name of the composite? Previously we just loaded any sca.modulefile and the name= parameter gave the module name. There is still a name= parameter so we end up with a file called CalculatorComposite.compositewith composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=CalculatorComposite Either the file naming convention or the name= is redundant? On 09/08/06, Pete Robbins [EMAIL PROTECTED] wrote: 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: [jira] Commented: (TUSCANY-610) Initial OSGi support effort
Hi Thomas, I think we met at JavaOne briefly...I haven't had a chance to look closely at Joel's work yet (just waiting for the removal of the EPL licensed class) so I'll let him jump in with more details. I think one of the interesting areas is going to be with sharing services between the two environments. For example, being able to consume OSGi services from within SCA and having SCA able to export services to OSGi. Other frameworks like Spring are also building this type of bridge so OSGi will potentially allow us to access those as well. Longer term, I think it would be interesting to see if OSGi and SCA services could potentially converge as they share a lot of things in common. Thanks for the offer of help and as soon as Joel replaces the one class, we'll check in his patch so we can look at more specifics. Jim On Aug 10, 2006, at 7:01 AM, Thomas Watson (JIRA) wrote: [ http://issues.apache.org/jira/browse/TUSCANY-610? page=comments#action_12427224 ] Thomas Watson commented on TUSCANY-610: --- Joel, Is there some more documentation on this work? I do not know much about how SCA works but I would like to see how this fits into the OSGi environment. Can you provide some steps to get this running on Equinox? Any other information on how SCA and OSGi can interact with each other would also be interesting to me. Thanks. Tom. P.S. I'm a developer on the Equinox Framework team. Please let us know if you need any assistence from the Equinox team to advance this work (bug fixes, enhancements, questions etc.). 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
Hi Ignacio, I'm out today and tomorrow. Could you maybe post to he list and I'll try and respond as soon as I have a chance to pick up email? Jim On Aug 10, 2006, at 7:12 AM, Ignacio Silva-Lepe wrote: Hi Jim, When you have some time to chat, I have a few questions about references. Thanks - 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: using stdcxx in tuscany/C++
Hi again, Just following up on this thread to see if there's anything we can do from our side to help you all with the migration, or any concerns or questions I can answer. I have noticed that some people are still using MSVC 6 to compile Tuscany. I'm curious whether there are any plans to upgrade to a more recent and more conforming compiler. Stdcxx is being tested with 7.1, and 8.0 (i86, IA64, and EM64T) but the 6.0 port would likely need some work. Regards Martin Pete Robbins wrote: Hi Martin. Using stdcxx is certainly on our list of things to investigate. There are 2 ways in which we can use a C++ standard library: 1) Internally withing our own implementation code 2) Exposed on user APIs We currently use stl within our implementation and the use of stl classes on our interfaces is currently under discussion in the SCA C++ Specification group. Ed Slattery took a look at using stdcxx but I have to admit I have had little time to follw this up. I need to take a look at your project and see what the benefits are. I will set aside some time tomorrow to do this. Thanks for your interest. On 06/07/06, Martin Sebor [EMAIL PROTECTED] wrote: Hi, We have heard that the Tuscany developers have been exploring the option of using Apache stdcxx as the common implementation of the C++ Standard Library for Tuscany/C++. We are wondering whether this is in fact the case and, if so, what the stdcxx team can do in order to make it as smooth as possible. Martin - 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: separate SDO Java distribution
I have put a fairly rough collation of our IRC chat on the wiki at http://wiki.apache.org/ws/Tuscany/TuscanyJava/Building/SdoDistroChat and linked it through from http://wiki.apache.org/ws/Tuscany/TuscanyJava Regards, Kelvin. On 10/08/06, kelvin goodson [EMAIL PROTECTED] wrote: I had an offline chat with lresende about a similar effort for DAS, so perhaps we could meet on IRC sometime soon, and go through what needs to be done? Cheers, Kelvin. On 09/08/06, Jeremy Boynes [EMAIL PROTECTED] wrote: 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] -- Best Regards Kelvin Goodson -- Best Regards Kelvin Goodson
[jira] Created: (TUSCANY-613) Move to 0.95 spec Assembly model
Move to 0.95 spec Assembly model Key: TUSCANY-613 URL: http://issues.apache.org/jira/browse/TUSCANY-613 Project: Tuscany Issue Type: New Feature Components: C++ SCA Affects Versions: Cpp-current Reporter: Pete Robbins Assigned To: Pete Robbins To cover work for composites etc. -- 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: using stdcxx in tuscany/C++
Hi Martin, We are using VC6 but have also got VC7 projects. Our command line build for windows uses the VC6 generated makefiles. We don't think that's possible in VC7+. Of course the best solution will be to create a proper commnad line build. We are just starting to restructure the code so will be modifying build. How do you manage yours? We are using Automake for linux platforms. Do you have a handcrafted windows build? Anyho... to start with we will be looking at the SDO project to use stdcxx as SCA is going through a bit of a transformation at the moment. I have a couple of questions regarding compatibility. If I have a library function that say returns a std::string and this is built using stdcxx, would any client of that function (separate library) also have to built with stdcxx?? In other words by exposing stl interfaces that are built using stdcxx are we mandating that any clients also use stdcxx? Cheers, On 10/08/06, Martin Sebor [EMAIL PROTECTED] wrote: Hi again, Just following up on this thread to see if there's anything we can do from our side to help you all with the migration, or any concerns or questions I can answer. I have noticed that some people are still using MSVC 6 to compile Tuscany. I'm curious whether there are any plans to upgrade to a more recent and more conforming compiler. Stdcxx is being tested with 7.1, and 8.0 (i86, IA64, and EM64T) but the 6.0 port would likely need some work. Regards Martin Pete Robbins wrote: Hi Martin. Using stdcxx is certainly on our list of things to investigate. There are 2 ways in which we can use a C++ standard library: 1) Internally withing our own implementation code 2) Exposed on user APIs We currently use stl within our implementation and the use of stl classes on our interfaces is currently under discussion in the SCA C++ Specification group. Ed Slattery took a look at using stdcxx but I have to admit I have had little time to follw this up. I need to take a look at your project and see what the benefits are. I will set aside some time tomorrow to do this. Thanks for your interest. On 06/07/06, Martin Sebor [EMAIL PROTECTED] wrote: Hi, We have heard that the Tuscany developers have been exploring the option of using Apache stdcxx as the common implementation of the C++ Standard Library for Tuscany/C++. We are wondering whether this is in fact the case and, if so, what the stdcxx team can do in order to make it as smooth as possible. Martin - 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] -- Pete
Re: Booting an SCA app without creating an scdl file
I wasn't planning on defining a custom runtime, only setting up a runtime by passing the information currently contained in the defualt.scdl file directly to the loader, bypassing the file system. What I am trying to do is create all the classes and interfaces for the system in memory, and then pass those to the launcher in order to start the runtime. On 8/9/06, Jim Marino [EMAIL PROTECTED] wrote: 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]
Re: [C++] Initial support for new composite model, was: Switching C++ runtime to new composite model
I have checked in code for TUSCANY-613 to build the new sca code on windows MSVC6. Calculator also builds and runs. I had to make one change to ModelLoader where I have changed the logic to load all .composite files in the folder rather than just the one that matches the folder name. The filename comparison doesn't work on windows, probably to do with \ vs /. Cheers, On 10/08/06, Pete Robbins [EMAIL PROTECTED] wrote: OK. I have the sca runtime building on vc6 fine. Calculator project builds fine too. Having some teething problems getting it running. On 10/08/06, Andrew Borley [EMAIL PROTECTED] wrote: Not many - it was mostly a case of putting the new files in and taking the old ones out. Saying that, I haven't actually got the samples going yet - BigBank falls over for some reason, currently getting Calculator going. When I've got stuff going I'll raise a Jira and put up a patch. Cheers On 8/10/06, Pete Robbins [EMAIL PROTECTED] wrote: I haven't seen the NPE. I'm currently trying to get the scatest program working on linux. I'm happy to leave VC6 broken for now until the changes settle down. If you are happy with the VC7 then please submit the patch. Were there many changes? Cheers, On 10/08/06, Andrew Borley [EMAIL PROTECTED] wrote: Also, I get a NPE when running SCAGEN on the BigBank sample - everything seems to get happily generated though. The output is below - anyone else see this? Pete - are you still using VC++6 for windows development? I have a VC++7 SCA build working happily here if you want the patch. Andy On 8/10/06, Andrew Borley [EMAIL PROTECTED] wrote: Similar question from me - do similar things apply for the subsystem .composite file that replace sca.subsystem? Andy On 8/10/06, Pete Robbins [EMAIL PROTECTED] wrote: ... also are we enforcing the directory containing the composite to also be named after the composite? On 10/08/06, Pete Robbins [EMAIL PROTECTED] wrote: Deployment question: Does the name of the .composite file HAVE to match the name of the composite? Previously we just loaded any sca.modulefile and the name= parameter gave the module name. There is still a name= parameter so we end up with a file called CalculatorComposite.compositewith composite xmlns=http://www.osoa.org/xmlns/sca/1.0 name=CalculatorComposite Either the file naming convention or the name= is redundant? On 09/08/06, Pete Robbins [EMAIL PROTECTED] wrote: 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
Re: [C++] Initial support for new composite model
Andrew Borley wrote: Also, I get a NPE when running SCAGEN on the BigBank sample - everything seems to get happily generated though. The output is below - anyone else see this? Pete - are you still using VC++6 for windows development? I have a VC++7 SCA build working happily here if you want the patch. Andy $ java -jar $TUSCANY_SCACPP/bin/scagen.jar -dir . -output . -verbose Scagen processing SCA composite file d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\Accounts.composite Scagen processing C++ implementation header d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountServiceImpl.h Scagen processing SCA componentType file d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountServiceImpl.componentType Scagen processing C++ interface header d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountService.h Scagen creating SCA for C++ proxy implementation d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountServiceImpl_AccountService_Proxy.cpp Scagen creating SCA for C++ proxy header d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountServiceImpl_AccountService_Proxy.h Scagen creating SCA for C++ wrapper implementation d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountServiceImpl_AccountService_Wrapper.cpp Scagen creating SCA for C++ wrapper header d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountServiceImpl_AccountService_Wrapper.h Scagen processing C++ interface header d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountDataService.h Scagen creating SCA for C++ proxy implementation d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountServiceImpl_accountData_Proxy.cpp Scagen creating SCA for C++ proxy header d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountServiceImpl_accountData_Proxy.h Scagen processing C++ interface header d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\StockQuoteService.h Scagen creating SCA for C++ proxy implementation d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountServiceImpl_stockQuote_Proxy.cpp Scagen creating SCA for C++ proxy header d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountServiceImpl_stockQuote_Proxy.h Scagen processing C++ implementation header d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountDataServiceImpl.h Scagen processing SCA componentType file d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountDataServiceImpl.componentType Scagen processing C++ interface header d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountDataService.h Scagen creating SCA for C++ proxy implementation d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountDataServiceImpl_AccountDataService_Proxy.cpp Scagen creating SCA for C++ proxy header d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountDataServiceImpl_AccountDataService_Proxy.h Scagen creating SCA for C++ wrapper implementation d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountDataServiceImpl_AccountDataService_Wrapper.cpp Scagen creating SCA for C++ wrapper header d:\tuscany\cpp\sca\samples\BigBank\Accounts\.\AccountDataServiceImpl_AccountDataService_Wrapper.h java.lang.NullPointerException at org.apache.tuscany.sca.cpp.tools.common.Options.set(Unknown Source) at org.apache.tuscany.sca.cpp.tools.common.CParsingTool.init(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.ServicesGenerator.init(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.ServicesGenerator.handleInterfaceHeader(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.ReferenceDomNodeHandler.createProxyForReference(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.ReferenceDomNodeHandler.handleNode(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.mapNodeToHandlerAndHandle(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.handleChildElements(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.handleNode(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.ComponentDomNodeHandler.handleNode(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.mapNodeToHandlerAndHandle(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.handleChildElements(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.handleNode(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.mapNodeToHandlerAndHandle(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.DomHandler.handleDom(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.XMLFileActor.actOnFile(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.CompositeOrFragmentFileHandler.actOnFile(Unknown Source) at org.apache.tuscany.sca.cpp.tools.services.DirectoryScanner.walkTree(Unknown Source) at
[jira] Created: (TUSCANY-614) Add operator debug info for DataObjectPtr and others
Add operator debug info for DataObjectPtr and others -- Key: TUSCANY-614 URL: http://issues.apache.org/jira/browse/TUSCANY-614 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-current Reporter: Pete Robbins Assigned To: Pete Robbins There is an SDOUTils function to print out the contents of a DataObject. This proposal is to add ostream operator to RefCountingPointer that will call a virtual function printSelf() on RefCountingObject. Anything inheriting from RefCountingObject (e.g. DataObject) can overide this method to provide diagnostic info. User simply has to code e.g. DatObjectPtr myDO = someFucntionThatReturnsDO(); cout myDO; -- 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: [C++] Initial support for new composite model, was: Switching C++ runtime to new composite model
Pete Robbins wrote: [snip] I have checked in code for TUSCANY-613 to build the new sca code on windows MSVC6. Calculator also builds and runs. I had to make one change to ModelLoader where I have changed the logic to load all .composite files in the folder rather than just the one that matches the folder name. The filename comparison doesn't work on windows, probably to do with \ vs /. Cheers, Very cool! Yes the filename comparison issue probably has to do with the Windows '\' vs Linux '/'. Loading all composites will work for now as we don't support includes and the equivalent of 0.9 fragments yet... I've noticed a few questions from Andy and you on the folder structure and why the composite was named like the containing folder. I'll start a separate thread for this discussion. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Initial support for new composite model
I'm getting the same NPE, didn't notice it before. If I comment out AccountDataService in the .composite file I'm not getting the NPE so it must be specific to this particular service or AccountDataService.h maybe? I have no idea why Options.set(...) would throw an NPE on ly with AccountDataService... I started to look at the scagen but having trouble understanding what it does. Could one of you post to the dev list a brief description of how scagen works? Thanks. Look what I found! What scagen does The input directory passed to the scagen tools as the -dir parameter method is taken to be the SCA module root directory. All the sca.module and .fragment files in that directory are inspected to resolve all the component/ elements within them. Each component/ element found is inspected to see if it has a implementation.cpp/ element within it. Each implementation.cpp/ element should have a header attribute that represents a C++ header file that contains function prototypes for the C++ implementation of the service. An optional class attribute can be used to select one class if more than one that is present in the header file. The default class is the one with the same name as the header file. The tool will verify that the implementation header contains an appropriate class prototype. The directory that contains the implementation header should also contain a matching .componentType file for the equivalent SCA component. So for example, a MyServiceImpl.h file would have a corresponding MyServiceImpl.componentType file in the same directory. Each componentType file is inspected for service/ and reference/ elements. For each service/ element that is found that contains a interface.cpp/ element within it, the header attribute of the interface.cpp/ is taken as the filename of the C++ interface header for the SCA service. This C++ header file is opened and used as a means for specifying the SCA service resulting in an appropriate wrapper and proxy being generated for this service interface. Both method bodies and h eaders are generated in the given output directory. The processing of a reference/ element is the same except that only a proxy header and implementation re generated. Getting started with the code - The following is a list of tasks that are performed by the scagen tool for each task we will describe technically how it is accomplished and the location of the code that can be inspected/changed to alter the behaviour. Here are the tasks listed, below is a paragraph for each one: o (Overall structure of the code) o Walking the input directory o Scanning the .module and .fragment files o finding the C++ implementation headers o finding/checking the classname in the C++ implementation headers o find the matching .componentTemplate files o going into the componentTemplate files to extract the interface header filenames o going into the interface header files and parsing them to extract the method signatures into a network of objects we can inspect. o taking all the meta data stored as objects and building a DOM for XSLT processing o using XSLT to produce a proxy header o using XSLT to produce a proxy implementation o using XSLT to produce a wrapper header o using XSLT to produce a wrapper implementation Overall structure of the code - There are two packages org.apache.tuscany.sca.cpp.tools.common and org.apache.tuscany.sca.cpp.tools.services. The ...common package is taken from some existing code that was also contributed to axis that was used to parse C++ code and do various tasks like insert trace. This code was repackaged and shipped as a tuscany package but there has been a desire not to change it significantly from the equivalent org.apache.axis.tools.common package to leave the door open for future convergence. Where the ...common package has been amended (for example to cope with namespaces better or the provision of an Options.reset method to reset a static variable and enable the tuscany junit tests to run independently) these have been flagged with a Tuscany comment. The ...common package basically provides two functions - 1) the ability to go into a directory (see DirectoryTree.java) and process files that fit a particular filter (e.g. *.hpp) by passing them to implementer of the FileActor Interface (see the classes Headers for the actor that processes C++ headers and XMLFileActor for the file actor that processes the .componentType and sca.module/fragment files.) The ...services package contains the majority of code written afresh for the scagen tool including the subclasses of XMLFileActor (see ComponentTypeFileHandler.java and ModuleOrFragmentFileHandler.java) that are the classes that tie this package to the ...common package and which are called by the DirectoryTree walker. Walking the module root input directory --- The main
Re: [C++] Initial support for new composite model
I have to say I have never looked at the Java code but I have editted the stylesheets to fix problems. Cheers, -- Pete
Re: [VOTE] Andy Borley for Tuscany Committer
Passed with 7+1s from: Pete Robbins Jean-Sebastien Delfino Ant Elder Kevin Williams Daniel Kulp Kelvin Goodson Jim Marino Welcome to Tuscany Andy! I will start the process of getting your account created. Cheers, -- Pete
Re: using stdcxx in tuscany/C++
Pete Robbins wrote: Hi Martin, We are using VC6 but have also got VC7 projects. Our command line build for windows uses the VC6 generated makefiles. We don't think that's possible in VC7+. Of course the best solution will be to create a proper commnad line build. We are just starting to restructure the code so will be modifying build. How do you manage yours? We are using Automake for linux platforms. Do you have a handcrafted windows build? The stdcxx native build infrastructure on Windows uses the VisualStudio IDE. A script automatically generates a VisualStudio solution for the appropriate version of the IDE (.NET 2003 or 2005) and populates it with projects for each component of stdcxx (the library, the test driver, each test and example program, etc.), and with the full set of configurations (debug, release, archive, dll, etc.) There is also a special project to configure the library to the the underlying architecture, operating system, and compiler (the same infrastructure is used for both MSVC and Intel C++ on Windows). This approach was chosen on the assumption that Windows developers preferred the IDE to the command line. Stdcxx can also be configured and built under Cygwin as well as under Misrosoft Windows Services for UNIX (with gcc) using its UNIX (GNU-make based) build infrastructure. It should be possible to use the same infrastructure with MSVC but we're not set up for it at this time. The Rogue Wave proprietary build infrastructure (not part of Apache stdcxx) takes a different approach to building stdcxx and generates makefiles for the project, so we could implement something similar in Apache stdcxx pretty quickly. Anyho... to start with we will be looking at the SDO project to use stdcxx as SCA is going through a bit of a transformation at the moment. I have a couple of questions regarding compatibility. If I have a library function that say returns a std::string and this is built using stdcxx, would any client of that function (separate library) also have to built with stdcxx?? In other words by exposing stl interfaces that are built using stdcxx are we mandating that any clients also use stdcxx? Yes. Different implementations of the same API may not be (and typically aren't) binary compatible. Once a dependency on a specific implementation (and sometimes a specific version) of the C++ Standard Library (or most any other C++ or even C library) is compiled into a library binary all other objects (libraries as well as the executable program itself) that use a C++ Standard Library must be compiled and linked with a compatible C++ Standard library binary. But since all (compliant) implementations of the C++ Standard Library conform to the same (source) standard this is not an issue as long as you distribute your library in source form. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Initial support for new composite model
I've followed the code through - it basically walks the .composite and .componentType files and then the header files, converts this info into an xml doc and the runs a set of stylesheets to create the proxy and wrapper files. I can take a look at this when I get time - it doesn't seem to be hurting at the moment. Andy On 8/10/06, Pete Robbins [EMAIL PROTECTED] wrote: I have to say I have never looked at the Java code but I have editted the stylesheets to fix problems. Cheers, -- Pete
Account request - new Tuscany committer - Andrew Borley
Preferred userid: ajborley Full name: Andrew Borley Forwarding email address: [EMAIL PROTECTED] Requested Karma for: ws ws-tuscany ICLA has been submitted and appears on http://people.apache.org/~jim/committers.html Vote result 7+1 votes and no -1s: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200608.mbox/[EMAIL PROTECTED] Cheers, -- Pete
Re: [C++] Initial support for new composite model, was: Switching C++ runtime to new composite model
I've just put up a patch on TUSCANY-613 for MSVC7. Includes SCA, BigBank and Calculator projects. Cheers Andy On 8/10/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: [snip] I have checked in code for TUSCANY-613 to build the new sca code on windows MSVC6. Calculator also builds and runs. I had to make one change to ModelLoader where I have changed the logic to load all .composite files in the folder rather than just the one that matches the folder name. The filename comparison doesn't work on windows, probably to do with \ vs /. Cheers, Very cool! Yes the filename comparison issue probably has to do with the Windows '\' vs Linux '/'. Loading all composites will work for now as we don't support includes and the equivalent of 0.9 fragments yet... I've noticed a few questions from Andy and you on the folder structure and why the composite was named like the containing folder. I'll start a separate thread for this discussion. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Booting an SCA app without creating an scdl file
Hi Jeremy, (I will most certainly spend some effort looking up the code myself :-) but just wanted to validate some thoughts) Are there SCDL readers? For example I imagine that there is a scdl-file-reader that reads an scdl file and creates an scdl object model. So the deployer starts by invoking a set of readers to create scdl models. Then based on the content of the model appropriate loaders and builders are called for fine-grained processing of the scdl. If this was true then can we not have a specialized reader which will dynamically create a scdl model and return it. Then the usual flow of the deployer calling the loaders, builders .. will happen. Ofcourse I also imagine that we might have other flavours of 'loaders' that should be able to act on say scdl structures as a java object like the ones that process XMLStream. Infact variants of loaders is also something I remember being discussed. So in what David is asking, can it just not be that, a reader is implemented and registered with the deployer as we do for loaders and builders. This way the SCA framework continue to have control instead of we calling the Builder or adding the built runtime artifact as child and so on. If you have been able to stand this upto here... then thanks :-) - Venkat On 8/10/06, Jeremy Boynes [EMAIL PROTECTED] wrote: Setting up a runtime or an application? If it's just an application then you should be able to construct your configuration by hand and pass it to the Builder to create the runtime component then then add the built component as a child. One way to do this might be to subclass DeployerImpl and stub out the load () method. -- Jeremy On Aug 10, 2006, at 9:16 AM, David Wheeler wrote: I wasn't planning on defining a custom runtime, only setting up a runtime by passing the information currently contained in the defualt.scdl file directly to the loader, bypassing the file system. What I am trying to do is create all the classes and interfaces for the system in memory, and then pass those to the launcher in order to start the runtime. On 8/9/06, Jim Marino [EMAIL PROTECTED] wrote: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO Samples
Thanks for the feedback. I made the changes that you suggested.
There are two topics worthy of further discussion.
1. ( previously brought up) Having an initial println in SDO samples that
would provide a link for users to see the source code if running from an IDE
such as Eclipse.
+ nice to provide this easy link w/o the need for break points
- IDE specific, if runinng in command line env may be somewhat ugly
- user can setup break points in order to follow the code
- {my view} -- convienance factor outweighs negatives.
2. Instructions for dependancies. The javadoc for each of the samples
includes a list of jar files to be included on classpath in order to run the
samples. The versioning of these jar files create a bit of a maintanence
nightmare. Would like to provide an easy means for getting these
dependancies for intro level developers.
Currently I have changed one sample s.t it says :
*Usage:*
This sample can easily be run from within Eclipse as a Java Application if
tuscany or the sample-sdo project is imported into Eclipse as an existing
project.
If executing as a standalone application please do the following:
- Include the following jar files on your classpath :
- SDO API and Tuscany Implementation
- sdo-api-{version}.jar - SDO API
- tuscany-sdo-impl-{version}.jar - Tuscany SDO
implementation
- EMF dependencies.
- emf-common-{version}.jar - some common framework utility
and base classes
- emf-ecore-{version}.jar - the EMF core runtime
implementation classes (the Ecore metamodel)
- emf-ecore-change-{version}.jar - the EMF change recorder
and framework
- emf-ecore-xmi-{version}.jar - EMF's default XML (and
XMI) serializer and loader
- xsd-{version}.jar - the XML Schema model
These jar files can be obtained from directly from Tuscany and
EMF projects or from SDO Execution Dependancies
http://wiki.apache.org/ws-data/attachments/Tuscany%282f%29TuscanyJava%282f%29SDO_Java_Overview/attachments/SDO%20Execution%20Dependencies
- Execute:
java org.apache.tuscany.samples.sdo.ExecuteSamples
If people like this then I will make the change throughout the samples, if
people have a better suggestion then I can easily do that.
Thanks,
Robbie John.
On 8/9/06, kelvin goodson [EMAIL PROTECTED] wrote:
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 are
1) 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
Re: Big Bank Sample
AJAX interaction is always good for traction these days, just as a cool UI has always been attractive. The speration of presentation and application implementation is great and obviously nothing new or particular to SCA. Is fine grained service interaction with the UI a good thing from a performance perspective ? Reworking the Big Bank sample s.t it is cleanly broken up into service components, and providing a good tutorial for replacing service components with other provided implementations is where this should go. Another good tutorial that could go with the samples would be taking the service components of big bank and creating a new completely different application from scratch reusing the service components. This tutorial could/should discuss developing generalized non application specific services where possible which is where the potential benefits from SCA reside. I will think on this some more next week but would be really interested in more thoughts on this topic and would probably enjoy working on it. Enjoy, Robbie On 8/9/06, Jeremy Boynes [EMAIL PROTECTED] wrote: 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] -- * * * Charlie * * * Check out some pics of little Charlie at http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ * * * Addresss * * * 1914 Overland Drive Chapel Hill NC 27517 * * * Number * * * 919-225-1553
[jira] Updated: (TUSCANY-610) Initial OSGi support effort
[ http://issues.apache.org/jira/browse/TUSCANY-610?page=all ] Joel Hawkins updated TUSCANY-610: - Attachment: ClassloaderHook.java Hi Jim, You can remove the AbstractReflector class from org.apache.tuscany.osgi.core.impl and replace the old ClassLoaderHook class with this attachment. That should take care of the EPL issue. 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: ClassloaderHook.java, 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]
[jira] Commented: (TUSCANY-611) RMI Binding
[ http://issues.apache.org/jira/browse/TUSCANY-611?page=comments#action_12427326 ] ant elder commented on TUSCANY-611: --- Committed. Thanks Venkat! RMI Binding --- Key: TUSCANY-611 URL: http://issues.apache.org/jira/browse/TUSCANY-611 Project: Tuscany Issue Type: Bug Reporter: Venkatakrishnan Assigned To: ant elder Attachments: Tuscany-RMI-Binding-Aug-10-Updated.diff, Tuscany-RMI-Binding-Aug-10.diff, Tuscany-RMI-Binding-Reference-Sample-Aug-10.diff, Tuscany-RMI-Binding-Service-Sample-Aug-10.diff SCA RMI Binding with samples for SCA Reference and SCA Service using RMI Binding. Here is a first cut implementation for this. Could somebody please review and apply? Also I have had the following issues un-resolved: - - The samples can be tested thro the Testcases in them. These testcases work from eclipse as long as I have added the RMI-Binding Eclipse project to the classpath. Otherwise the binding does get picked up. The same is the issue when trying to execute the testcases from maven. Could somebody please help in fixing this? Thanks. Note :- I shall be working further with this binding to address the following : - - there is single attribute called 'uri' for the binding. I shall be splitting this to host, port and service name with defaults to each when not specified. - it is now required the that SCA Service require a component to implement the interface Remote. I imagine this to be intrusive. All that a developer should do is pick up an existing component with a 'non remote' interface and simply deploy it exposing the service as RMI. The binding should dynamically be able to generate a remote interface and a proxy and host it as a facade to this implementation. - will be glad to take forward any other inputs from the community as well. Thanks - Venkat -- 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: [jira] Updated: (TUSCANY-611) RMI Binding
Hi Venkat, I've committed this patch now. Had some problems getting the patch to apply cleanly so had to fiddle about a bit, could you check it looks ok to you? The code needs formatting so maybe you could send in another patch doing that? I've also not added the service and reference samples to the main samples pom.xml yet. As you've pointed out the testcases for them only work in eclipse so we'll need to figure out what to do about that. Looks great, really good to have a real binding working at last. ...ant On 8/10/06, Venkatakrishnan (JIRA) tuscany-dev@ws.apache.org wrote: [ http://issues.apache.org/jira/browse/TUSCANY-611?page=all ] Venkatakrishnan updated TUSCANY-611: Attachment: Tuscany-RMI-Binding-Aug-10-Updated.diff Hi... there is one addition that has been missed out in the prev. patch. My sincere apologies for that goof-up here is the updated patch. Thanks. RMI Binding --- Key: TUSCANY-611 URL: http://issues.apache.org/jira/browse/TUSCANY-611 Project: Tuscany Issue Type: Bug Reporter: Venkatakrishnan Assigned To: ant elder Attachments: Tuscany-RMI-Binding-Aug-10-Updated.diff , Tuscany-RMI-Binding-Aug-10.diff, Tuscany-RMI-Binding-Reference-Sample-Aug-10.diff, Tuscany-RMI-Binding-Service-Sample-Aug-10.diff SCA RMI Binding with samples for SCA Reference and SCA Service using RMI Binding. Here is a first cut implementation for this. Could somebody please review and apply? Also I have had the following issues un-resolved: - - The samples can be tested thro the Testcases in them. These testcases work from eclipse as long as I have added the RMI-Binding Eclipse project to the classpath. Otherwise the binding does get picked up. The same is the issue when trying to execute the testcases from maven. Could somebody please help in fixing this? Thanks. Note :- I shall be working further with this binding to address the following : - - there is single attribute called 'uri' for the binding. I shall be splitting this to host, port and service name with defaults to each when not specified. - it is now required the that SCA Service require a component to implement the interface Remote. I imagine this to be intrusive. All that a developer should do is pick up an existing component with a 'non remote' interface and simply deploy it exposing the service as RMI. The binding should dynamically be able to generate a remote interface and a proxy and host it as a facade to this implementation. - will be glad to take forward any other inputs from the community as well. Thanks - Venkat -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-610) Initial OSGi support effort
[ http://issues.apache.org/jira/browse/TUSCANY-610?page=comments#action_12427336 ] Joel Hawkins commented on TUSCANY-610: -- Hi Thomas. I'm trying to write up some documentation now. In short, however, the code breaks down into 2 parts: 1. The OSGi hosting of the SCA core. This is a bundle that bootstraps SCA instances for bundles that have SCA components (scdl files). The host makes a distinction between system extension and applications. For example, the OSGi binding code that supports interacting with the OSGi service framework is packaged as a system extension. The samples are packaged as applications. To me, these application instances feel like web apps. 2. The OSGi Services system extension, which in turn has two major parts: a. An OSGi Service binding, which allows SCA components to be exposed as OSGi services. This is pretty straightforward. The only tricky bit (assuming away the intricacies of SCA's wiring) is dealing with the need for a ServiceFactory during service registration. This is added to the target class using a dynamic proxy if required. b. An OSGi implementation, which wraps OSGi services as SCA components, allowing them to be wire in seamlessly (once I'm done :-) )into SCA applications. This binding allows the specification of a filter for aquiring an appropriate service reference, and acts as a service listener to clean up stale references. The code currently attempts to rebind the service if the service has changed (using the same reference) or gone away (using a different reference). Not sure if this is desirable in all cases, but it gives good demo. :-) Please remember this is an 'initial' implementation! There's enough code to get my simple scenarios working - but I'm sure there's plenty left to do. Also, the recent work that's been checked in to have some of the wiring handled by the wire service probably means some of this code can go away. Some of the things I like about the combination of SCA and OSGi is that OSGi services provide a really simple and efficient way to communicate between SCA applications running in a single OSGi instance, and OSGi's bundle isolation characteristics make dealing with multiple application deployments much more deterministic. From my perspective (having a toe dipped in both worlds), SCA and OSGi look really complementary. I'll also try and package the rest of my eclipse environment so that you can get this running. It's mostly bundle-izing the required Tuscany jars. 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: ClassloaderHook.java, 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: Adding an implementation processor
Hi, Do we plan to move the ImplementationProcessor framework to the SPI module? When I'm working on the databindings, it comes out some requirements for extensibility on annotion processing as well. Thanks, Raymond - Original Message - From: Ignacio Silva-Lepe [EMAIL PROTECTED] To: Tuscany Dev tuscany-dev@ws.apache.org Sent: Friday, July 28, 2006 12:35 PM Subject: Adding an implementation processor In the process of adding support for callbacks, I am adding a CallbackProcessor to pick up a callback name and member when visiting a field or a method. I added a call to register the CallbackProcessor from DefaultBoostrappers's createIntrospector, and I added the following entry to META-INF/tuscany/implementation.scdl: component name=implementation.Callback system:implementation.system class=org.apache.tuscany.core.implementation.processor.CallbackProcessor/ /component However, when testing, I see that the CallbackProcessor only seems to be called for system methods but not for application methods. For instance, I see that RefererenceProcessor gets called for setMyService but CallbackProcessor does not, whereas both processors get called for setMonitor. One thing that I am not sure about is what to do with the component name implementation.Callback in implementation.scdl, if that has any bearing at all. Any ideas as to what I may be missing to get CallbackProcessor to be called for methods like setMyService? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[C++] Folder structure under $Tuscany_scacpp_system_root
When I started to implement the new composite assembly model I felt a need to adjust a little the folder structure under the Tuscany system root, did half of it, which triggered some questions :) This is a new thread to discuss these changes. Here's what we had in M1: $TUSCANY_SCAPP_SYSTEM_ROOT/ -- your Tuscany-system-root subsystems/ CalculatorSubsystem/ sca.subsystem -- creates and configures the Calculator module component modules/ Calculator -- the Calculator module and code sca.module other artifacts, *.so, *.wsdl, *.xsd etc. Now that the spec has removed subsystem, module and fragment, and generalized the use of composites, here's what I'd like to propose: deploy/ -- your Tuscany-system-root configuration/ CalculatorApp.composite -- creates the Calculator component, we don't need sub-folders here since we can give meaningful name to composite files now packages/ Calculator -- the Calculator composite and code Calculator.composite other artifacts, *.so, *.wsdl, *.xsd etc. - Configuration contains the composites included in your system creating and configuring your top level components. - Packages contains all your other development artifacts (not necessarily just composites that's why I'm proposing packages/ instead of modules/ or composites/). - I think that the samples should use consistent naming convenvions, but you should also be able to pick the names you want for your folders and artifacts and have Foo/Bar.composite containing composite name=Abc/ for example. Any thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[C++] Do we need Tuscany-model.config?
It looks like Tuscany-model.config just lists the WSDLs and XSDs used in an application. Do we still need it? or could we just figure out ourselves what the WSDLs and XSDs are? Just trying to make it simpler for users to write SCA applications, and limit the number of things that they have to worry about... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Support for WSDL service contracts
We have some basic parsing code for WSDL service contracts right now but this needs to be finished. To put a stake in the ground I intend to make the following work: * support for parsing interface.wsdl elements * support for WSDL resolution based on the WSDL2.0 wsdlLocation mechanism. This will require the user to specify the location of the WSDL on each usage. An example would be: service name=foo interface.wsdl interface=http://example.com#wsdl.interface (FooService) wsdlLocation=http://example.com wsdl/ example.wsdl/ ... Relative location URIs will be resolved against the classpath for the composite. * To start with, I don't plan to cache WSDLs instances - we can optimize performance when necessary There are no dependencies on WSDL in the core so I plan to move all the WSDL processing to an extension module idl/wsdl. I will modify any bindings that specifically need WSDL (which I hope is just the webservice ones) to depend on this extension. I don't plan to do anything else at this time with bindings that use WSDL information - once the interface stuff is working we can take another look. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[C++] Recommendation for sample composite names
Here's a note from the SCA spec 0.95: Note: The Eclipse naming convention for plugins provides a good way to achieve unique names, e.g. com.mycompany.myvaluecomposite . This format is recommended but is not normative. I'd like to adjust our samples to follow that recommendation (e.g. bigbank.client, bigbank.account). What do you think? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
On Aug 10, 2006, at 8:37 AM, Ignacio Silva-Lepe wrote: Sure, I want to make sure I understand what local callbacks (or plain invocations for that matter) via references means. I was defining a local callback as being a bidirectional wire to a target component, which (by definition) is in the same composite. A wire whose target is a reference would be a remote callback since the invocation flows outside a composite. For local callbacks, we don't need to persist ids and have more control of things (lifecycle, thread dispatching, by-ref, etc.). For remote callbacks, I don't think we should allow direct wiring to a child component in another composite as that breaks visibility rules for composites. Rather, I was thinking we would need to design for a durable store to be able to map back to the callback wire and target instance (target instance id may be able to be calculated using an FQN of its component name in the composite hierarchy). On the outbound leg, the reference target invoker would persist the id to wire chain mapping. The binding would be responsible for flowing the ids. In this case, references act as services and services act as references during a callback and would have to re-associate the ids with invocation chains. A ReferenceExtension is built wrt a binding, e.g., Axis2Reference. So for 'local' we treat the binding as a (dummy) special case and wire directly to a component's or a composite's service, as in EchoReference but more fleshed out. Similarly, for service, which for local could be wired from a component's or a composite's reference. If this makes sense, then it means we need new JavaReference, JavaService and JavaBindingBuilder implementations that don't currently exist and that use a dummy JavaBinding similar to EchoBinding. I may be misunderstanding but for the local case, I think things are conceptually the same but there are some optimizations and implementation differences that do not require us to have JavaReference or JavaService. References on composites are just representations of some external service and are responsible for dispatching an invocation to it over a binding. Similarly, a reference on a Java component is just a representation of the target service and the binding can be considered something like pass-by- reference or vm. However, implementations vary with the composite reference being realized as a Reference and a Java component reference being just a proxy. I don't think we need the extra step of creating JavaService or JavaReference for local wires as they are never used (i.e. Java implementations always use the proxy representation). I may be missing your point though so let me know if this makes any sense. Jim I am working on this assumption. Let me know if I'm missing something, e.g., some currently existing classes that should be used. Thanks - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, August 10, 2006 11:13 AM Subject: Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks Hi Ignacio, I'm out today and tomorrow. Could you maybe post to he list and I'll try and respond as soon as I have a chance to pick up email? Jim On Aug 10, 2006, at 7:12 AM, Ignacio Silva-Lepe wrote: Hi Jim, When you have some time to chat, I have a few questions about references. Thanks - 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: [jira] Updated: (TUSCANY-611) RMI Binding
Thanks Venkat. Just a quick question: do you think it is best to have one Registry per service or could we have one Registry per runtime instance and have services register with that? If you think the latter may be something that works better, one thing that could be done is to create a separate system component that instantiates the registry. This system component would be like ServletHost (RMIHost?) and could be autowired to the builder which could then pass it to the service implementation which would in turn perform the bind operation. Jim On Aug 10, 2006, at 12:30 PM, ant elder wrote: Hi Venkat, I've committed this patch now. Had some problems getting the patch to apply cleanly so had to fiddle about a bit, could you check it looks ok to you? The code needs formatting so maybe you could send in another patch doing that? I've also not added the service and reference samples to the main samples pom.xml yet. As you've pointed out the testcases for them only work in eclipse so we'll need to figure out what to do about that. Looks great, really good to have a real binding working at last. ...ant On 8/10/06, Venkatakrishnan (JIRA) tuscany-dev@ws.apache.org wrote: [ http://issues.apache.org/jira/browse/TUSCANY-611?page=all ] Venkatakrishnan updated TUSCANY-611: Attachment: Tuscany-RMI-Binding-Aug-10-Updated.diff Hi... there is one addition that has been missed out in the prev. patch. My sincere apologies for that goof-up here is the updated patch. Thanks. RMI Binding --- Key: TUSCANY-611 URL: http://issues.apache.org/jira/browse/ TUSCANY-611 Project: Tuscany Issue Type: Bug Reporter: Venkatakrishnan Assigned To: ant elder Attachments: Tuscany-RMI-Binding-Aug-10-Updated.diff , Tuscany-RMI-Binding-Aug-10.diff, Tuscany-RMI-Binding-Reference-Sample-Aug-10.diff, Tuscany-RMI-Binding-Service-Sample-Aug-10.diff SCA RMI Binding with samples for SCA Reference and SCA Service using RMI Binding. Here is a first cut implementation for this. Could somebody please review and apply? Also I have had the following issues un- resolved: - - The samples can be tested thro the Testcases in them. These testcases work from eclipse as long as I have added the RMI-Binding Eclipse project to the classpath. Otherwise the binding does get picked up. The same is the issue when trying to execute the testcases from maven. Could somebody please help in fixing this? Thanks. Note :- I shall be working further with this binding to address the following : - - there is single attribute called 'uri' for the binding. I shall be splitting this to host, port and service name with defaults to each when not specified. - it is now required the that SCA Service require a component to implement the interface Remote. I imagine this to be intrusive. All that a developer should do is pick up an existing component with a 'non remote' interface and simply deploy it exposing the service as RMI. The binding should dynamically be able to generate a remote interface and a proxy and host it as a facade to this implementation. - will be glad to take forward any other inputs from the community as well. Thanks - Venkat -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
