You are viewing a plain text version of this content. The canonical link for it is here.

Posted to user@tuscany.apache.org by Mario Grotschar <ma...@gmail.com> on 2010/07/06 14:33:05 UTC

Re: Qpid functionality in Tuscany

Tanks for your reply.

One question to the tuscany frame work.

In the project the tuscany_sca_native-1.0-incubator-M3 ist used. There I can
find in the src a directory

-- src
    `-- tuscany
        `-- sca
            |-- core
            |-- extension
            |-- model
            `-- util


|-- core
|   |-- Exceptions.cpp
|   |-- Exceptions.h
|   |-- Operation.cpp
|   |-- Operation.h
|   |-- SCARuntime.cpp
|   |-- SCARuntime.h
|   |-- ServiceProxy.cpp
|   |-- ServiceProxy.h
|   |-- ServiceWrapper.cpp
|   `-- ServiceWrapper.h

|-- extension
|   |-- ImplementationExtension.cpp
|   |-- ImplementationExtension.h
|   |-- InterfaceExtension.cpp
|   |-- InterfaceExtension.h
|   |-- ReferenceBindingExtension.cpp
|   |-- ReferenceBindingExtension.h
|   |-- ServiceBindingExtension.cpp
|   `-- ServiceBindingExtension.h

In the newer version in the svn trunk i can only see a directory

|-- kernel
|   |-- Makefile.am
|   |-- config.hpp
|   |-- dynlib-test.cpp
|   |-- dynlib.hpp
|   |-- element.hpp
|   |-- fstream.hpp
|   |-- function.hpp
|   |-- gc.hpp
|   |-- hash-test.cpp
|   |-- hash.hpp
|   |-- kernel-test.cpp
|   |-- lambda-test.cpp
|   |-- list.hpp
|   |-- mem-test.cpp
|   |-- monad.hpp
|   |-- parallel-test.cpp
|   |-- parallel.hpp
|   |-- perf.hpp
|   |-- sstream.hpp
|   |-- stream.hpp
|   |-- string-test.cpp
|   |-- string.hpp
|   |-- tree.hpp
|   |-- value.hpp
|   |-- xml-test.cpp
|   |-- xml.hpp
|   `-- xsd-test.cpp

I cannot find the corresponding files that incorporate the logic. Am i
missing something?

BR and thanks in advance,

Mario

2010/6/15 Jean-Sebastien Delfino <js...@apache.org>

> Mario Grotschar wrote:
>
>> Thanks for this good explanation.
>>
>
> Hi, sorry for the delay responding, I'm on vacation, traveling with limited
> access to email.
>
>
>  In the course of an university project, I would like to write a queue
>> binding, most likely using qpid.
>>
>
> Great! I'll try to help you as much as possible.
>
>
> As I understand the advantage of a real
>
>> binding, is that its more transparent and you can use the interceptors for
>> formatting etc. Is there any other advantage?
>>
>
> It really depends on what you mean by transparent. A binding requires you
> to add a <binding.qpid> element to your service or reference. As shown in
> the .composite snippets below, a component allows you to push the Qpid
> configuration further away from your application component, in another
> component. So one could argue that a component is more 'transparent'.
>
> It would be interesting to hear opinions from other Tuscany developers and
> users on this.
>
> In terms of runtime complexity, a binding may allow you to save a hop
> through another component, at the expense of more runtime plumbing.
>
> For example, imagine you want to bind a particular service to SOAP /
> Axis2c, Apache Thrift and Qpidc. You'll probably have to create four
> processes (or threads):
> 1) HTTPD configured with Axis2C for SOAP
> 2) a Thrift server
> 3) a Qpidc listener
> 4) a process running your component implementation
> and some inter-process/thread communication between 1/2/3 and 4.
>
> Doesn't that look similar to four components? :)
>
>
>  For the java version there is some introduction on how to extend the
>> runtime. Is there something similar for the c++ version?
>>
>
> Yes, in this email :)
>
> Here are several ways to extend the runtime with a new binding:
>
> a) Read the .composite containing the binding configuration and translate
> it to an equivalent .composite containing a component configuration. I'd
> suggest that approach as a first step, as it'll allow you to experiment with
> the binding configuration (and refine the SCDL language extension for that
> binding) without requiring new runtime plumbing. You'll find code to read
> SCDL in modules/scdl [2].
>
> b) For a service binding, implement a server process that listens on the
> particular protocol you want to support in the binding (a Qpid listener
> here) and dispatches/relays messages to the application component providing
> the service (easy to do with the proxy functions in modules/http [3]).
>
> c) For a reference binding, make a small change to the mkrefProxy function
> in mod-eval.hpp [4] to create Qpid proxies in addition to HTTP proxies, or
> come up with a generic and extensible mkrefProxy function that looks at the
> binding configuration to create the proper proxy type.
>
>
>
>  2010/6/3 Jean-Sebastien Delfino <js...@apache.org>
>>
>>  Mario Grotschar wrote:
>>>
>>>  One more question :-). I have noticed that in the Java Framework of
>>>> Tuscany
>>>> there is a JMS binding. Does Tuscany Java come with an embedded
>>>> JMS-Provider?
>>>>
>>>>  The Tuscany 1.x Java distributions include Apache ActiveMQ.
>>>
>>> I couldn't find ActiveMQ in the Tuscany 2.x Java distributions, but
>>> that's
>>> what the 2.x test cases use as well.
>>>
>>>
>>> Is there a specific reason why qpid was implemented as a
>>>
>>>> component and not integrated as a binding in the Native Tuscany?
>>>>
>>>>  It was just simpler for me to write an application component than
>>> extend
>>> the runtime with plumbing code to define and support a specific binding.
>>>
>>> The syntax with a component is a little different. For example, say I
>>> have
>>> a component "Foo", with a reference "bar" used to send messages to Qpid
>>> with
>>> key "xyz".
>>>
>>> With a full blown Qpid binding I'd be able to write something like:
>>> <component name="Foo">
>>>  <t:implementation.python script="foo.py"/>
>>>  <reference name="bar">
>>>   <t:binding.qpid>
>>>       <key>xyz</key>
>>>   </t:binding.qpid>
>>>  </reference>
>>> </component>
>>>
>>> With a Qpid component, I have to write:
>>> <component name="Foo">
>>>  <t:implementation.python script="foo.py"/>
>>>  <reference name="bar" target="Bar"/>
>>> </component>
>>>
>>> <component name="Bar">
>>>  <implementation.cpp library="liqueue-sender"/>
>>>  <property name="key">xyz</property>
>>> </component>
>>>
>>> That approach has been working OK for me though. I even discovered some
>>> benefits after a while. For example Bar can be moved to another machine,
>>> or
>>> replaced with a completely different component implementation (say, using
>>> a
>>> database instead of a Qpid queue), without changing Foo's configuration
>>> at
>>> all.
>>>
>>> If anybody wants to go beyond the basic component approach and develop a
>>> real binding, please jump in and I will try to help you, in the very
>>> limited
>>> spare time I can spend on this.
>>>
>>>
>>>
>>>
>>  Is there also a high level overview of the Tuscany Native runtime such as
>>>> for the Java version?
>>>>
>>>>
>>>>  No, but there's not so much code to read :)
>>>
>>> In a nutshell, it's a thin C++ runtime that plugs into the Apache HTTPD
>>> server to dispatch HTTP requests and route them along SCA wires to SCA
>>> app
>>> components.
>>>
>>> Components can be written in C++, Python or a subset of Scheme (mostly
>>> used
>>> for self contained tests not requiring Python integration).
>>>
>>> There's experimental support for Java components, but it's too rough and
>>> limited to be really useful.
>>>
>>> A small subset of the SCA assembly model is supported, without policies
>>> or
>>> SCA contributions, but enough to run apps like the "Store" sample app
>>> available on the Tuscany Java runtime for example.
>>>
>>> SCA bindings are provided for the JSON-RPC and AtomPub protocols.
>>>
>>> In addition to the runtime, there's a few C++ components that can help
>>> integrate an SCA app with Qpid, Axis2, Vysper, Scribe logging servers
>>> etc.
>>> They bring dependencies on these various packages but they're optional,
>>> so
>>> don't build them if you don't need them.
>>>
>>> A little more info can be found in the README and INSTALL files in the
>>> sca-cpp trunk [1].
>>>
>>> That was three more questions :) Hope this helps.
>>>
>>>
>>> [1] http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/
>>> --
>>> Jean-Sebastien
>>>
>>>
>>
>>
>>
> [2] http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/modules/scdl
> [3] http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/modules/http
> [4]
> http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/modules/server/mod-eval.hpp
>
> Hope this helps
> --
> Jean-Sebastien
>



-- 
Mit freundlichen Grüßen,

Mario Grotschar

mario.grotschar@gmail.com

Re: Qpid functionality in Tuscany

Posted by Jean-Sebastien Delfino <js...@apache.org>.

Mario Grotschar wrote:
> Ah ok. I see that in M4 everything is a module to httpd server. So in M4
> there is no way to run the runtime without httpd server? What was the reason
> for changing to this different approach?
> The problem for the project we would like to use SCA for is a very limited
> host system, offering only 25 MB of disk storage.
> 
> As far as i can see in M3 the native SCA binding uses ws and therefore the
> AXIS2 server, so unless i use REST I dont need the HTTPD server. The runtime
> will load the modules directly. Is M3 completly obsolete or is there any
> interest in pursuing this architure?
> 

Hi Mario,

I'll respond in a new thread with a new subject as your question is not 
about Qpid anymore.

-- 
Jean-Sebastien

Re: Tuscany-cpp packaging options for minimal disk space, was: Qpid functionality in Tuscany

Posted by Jean-Sebastien Delfino <js...@apache.org>.

Mario Grotschar wrote:
> One questing regarding special data types defiend in M3. Can the be reused
> in M4?

I'm not sure what you mean by 'special data types defined in M3'. Can 
you give me a little more background? Are you talking about XMLSchema 
types? SDO types? code that you've written on M3?

> 
> And one question about Apache Axis2  Licences. As far as i can see also only
> the Apache License, Version 2.0 (current) applies to that, is that correct?

The Axis2/C license is there [1]. You may also want to check its NOTICE 
file [2], and confirm on the Axis2/C mailing list [3].

[1] http://svn.apache.org/repos/asf/axis/axis2/c/core/trunk/LICENSE
[2] http://svn.apache.org/repos/asf/axis/axis2/c/core/trunk/NOTICE
[3] http://ws.apache.org/axis2/c/lists_issues.html
-- 
Jean-Sebastien

Re: Tuscany-cpp packaging options for minimal disk space, was: Qpid functionality in Tuscany

Posted by Mario Grotschar <ma...@gmail.com>.

One questing regarding special data types defiend in M3. Can the be reused
in M4?

And one question about Apache Axis2  Licences. As far as i can see also only
the Apache License, Version 2.0 (current) applies to that, is that correct?

2010/8/5 Luciano Resende <lu...@gmail.com>

> On Thu, Aug 5, 2010 at 2:52 AM, Mario Grotschar
> <ma...@gmail.com> wrote:
> > Thanks for the informaton. Could there be any license poblems with Apache
> > when using it for commerical purposes?
> >
>
> The Apache License is a very permissible license and very commercial
> friendly license. More details about the license is available at [1].
> I'd always recommend checking with your lawyer to make sure things are
> ok on your specific case.
>
> [1] http://www.apache.org/licenses/
>
> --
>  Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>



-- 
Mit freundlichen Grüßen,

Mario Grotschar

mario.grotschar@gmail.com

Re: Tuscany-cpp packaging options for minimal disk space, was: Qpid functionality in Tuscany

Posted by Luciano Resende <lu...@gmail.com>.

On Thu, Aug 5, 2010 at 2:52 AM, Mario Grotschar
<ma...@gmail.com> wrote:
> Thanks for the informaton. Could there be any license poblems with Apache
> when using it for commerical purposes?
>

The Apache License is a very permissible license and very commercial
friendly license. More details about the license is available at [1].
I'd always recommend checking with your lawyer to make sure things are
ok on your specific case.

[1] http://www.apache.org/licenses/

-- 
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Re: Tuscany-cpp packaging options for minimal disk space, was: Qpid functionality in Tuscany

Posted by Mario Grotschar <ma...@gmail.com>.

Thanks for the informaton. Could there be any license poblems with Apache
when using it for commerical purposes?

2010/7/28 Jean-Sefbastien Delfino <js...@apache.org>

> Mario Grotschar wrote:
>
>> Ah ok. I see that in M4 everything is a module to httpd server. So in M4
>> there is no way to run the runtime without httpd server? What was the
>> reason
>> for changing to this different approach?
>>
>
> M3 supported HTTPD as well. Some of the limited SOAP-only samples used
> Axis2/C axis2_http_server, but the HTTPD integration was a more solid
> option.
>
> There were (and still are) issues with the axis2_http_server integration:
> - only worked for SOAP and no other bindings in the same app;
> - limited support for HTTP, no HTTPS or multipart requests for example;
> - caused memory leaks, and eventually crashes;
> - forced to run multithreaded (problematic with some libraries).
>
> See [1][2][3][4] for some of these issues. In [1][3] the Axis2/C folks
> themselves are recommending to use HTTPD instead in production.
>
> The latest code requires HTTPD, but with a little bit of work, it should be
> possible to not require a server at all in client-only apps. Let me know if
> you're interested in working on a few runtime changes to support that (but
> you'll see below that HTTPD is not that big...).
>
> The problem for the project we would like to use SCA for is a very limited
>> host system, offering only 25 MB of disk storage.
>>
>> As far as i can see in M3 the native SCA binding uses ws and therefore the
>> AXIS2 server, so unless i use REST I dont need the HTTPD server. The
>> runtime
>> will load the modules directly.
>>
>
> About the size of the binaries, here are a few numbers which I hope can
> help you (Ubuntu 9.10 build without debug symbols).
>
> Subset of Tuscany-cpp for C++ components, JSON-RPC and ATOM bindings:
> /tuscany-sca-cpp-bin$ du -c modules/server modules/http
> 24      modules/server/htdocs/js
> 28      modules/server/htdocs
> 708     modules/server
> 20      modules/http/conf
> 76      modules/http
> 784     total (0.8Mb)
>
> Subset of HTTPD needed by Tuscany-cpp (see the list of modules in [5]):
> /httpd-2.2.15-bin$ du -c bin lib modules
> 516     bin
> 748     lib
> 756     modules
> 2020    total (2Mb)
>
> With the latest code you can just use the JSON-RPC binding, which is
> lighter than the old SOAP binding. Let's add the library used for JSON:
> /tracemonkey-bin$ du -c lib/libmozjs.so
> 1704    lib/libmozjs.so
> 1704    total (1.7Mb)
>
> That gives us a total of 784 + 2020 + 1704 = 4508Kb (4.4Mb).
>
> That's all you need to run your SCA components, with robust support for
> HTTP, and JSON-RPC and ATOM/REST bindings.
>
>
> If you want SOAP, you need the Tuscany-cpp Web service component:
> /tuscany-sca-cpp-bin$ du -c components/webservice
> 656     components/webservice
> 656     total (0.6Mb)
>
> and Axis2/C:
> /axis2c-1.6.0-bin$ du -c axis2.xml bin lib modules
> 8       axis2.xml
> 268     bin
> 1864    lib
> 52      modules/addressing
> 24      modules/logging
> 80      modules
> 2220    total (2.2Mb)
>
> That's a total of: 784 + 2020 + 1704 + 2220 = 6728Kb (6.6Mb)
>
> Is M3 completly obsolete or is there any interest in pursuing this
>> architure?
>>
>
> M3 is more than 3 years old, that's getting old :)
>
> Here is an analysis of the M3 binaries.
>
> Subset of Tuscany-sca-cpp-M3 for C++ components, SOAP and REST bindings:
> /tuscany-sca-cpp-M3-bin $ du -c extensions lib
> 148     extensions/cpp
> 248     extensions/ws
> 108     extensions/sca
> 320     extensions/rest
> 828     extensions
> 532     lib
> 1360    total (1.3Mb)
>
> I'm including the SOAP binding here as I'm assuming that you need an
> RPC-type binding and won't do everything with REST, and there was no
> JSON-RPC binding in M3.
>
> You also needed Tuscany-sdo-M3:
> /tuscany-sdo-cpp-M3-bin $ du -c lib
> 1192    lib
> 1192    total (1.2Mb)
>
> So, including the recommended HTTPD and Axis2/C, M3 needed at minimum:
> 1360 + 1192 + 2020 + 2220 = 6792Kb (6.6Mb)
>
>
> We can discuss the various packaging options, but if you're really
> constrained by disk storage, I'd suggest the latest code with JSON-RPC
> instead of SOAP, 4.4Mb including HTTPD.
>
> Now, if you really want to use M3 or integrate the latest code with
> axis2_http_server again, that's OK too. I'll try to help as much as I can
> when I find some spare time.
>
> [1] http://wso2.org/forum/thread/8779
> [2] http://markmail.org/message/dfbbnnpnmlraxv2w
> [3] http://markmail.org/message/kz6gnorlrj3smjjs
> [4] https://issues.apache.org/jira/browse/AXIS2-4756
> [5]
> http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/modules/http/httpd-conf
>
> Hope this helps.
> --
> Jean-Sebastien
>



-- 
Mit freundlichen Grüßen,

Mario Grotschar

mario.grotschar@gmail.com

Tuscany-cpp packaging options for minimal disk space, was: Qpid functionality in Tuscany

Posted by Jean-Sebastien Delfino <js...@apache.org>.

Mario Grotschar wrote:
> Ah ok. I see that in M4 everything is a module to httpd server. So in M4
> there is no way to run the runtime without httpd server? What was the reason
> for changing to this different approach?

M3 supported HTTPD as well. Some of the limited SOAP-only samples used 
Axis2/C axis2_http_server, but the HTTPD integration was a more solid 
option.

There were (and still are) issues with the axis2_http_server integration:
- only worked for SOAP and no other bindings in the same app;
- limited support for HTTP, no HTTPS or multipart requests for example;
- caused memory leaks, and eventually crashes;
- forced to run multithreaded (problematic with some libraries).

See [1][2][3][4] for some of these issues. In [1][3] the Axis2/C folks 
themselves are recommending to use HTTPD instead in production.

The latest code requires HTTPD, but with a little bit of work, it should 
be possible to not require a server at all in client-only apps. Let me 
know if you're interested in working on a few runtime changes to support 
that (but you'll see below that HTTPD is not that big...).

> The problem for the project we would like to use SCA for is a very limited
> host system, offering only 25 MB of disk storage.
> 
> As far as i can see in M3 the native SCA binding uses ws and therefore the
> AXIS2 server, so unless i use REST I dont need the HTTPD server. The runtime
> will load the modules directly.

About the size of the binaries, here are a few numbers which I hope can 
help you (Ubuntu 9.10 build without debug symbols).

Subset of Tuscany-cpp for C++ components, JSON-RPC and ATOM bindings:
/tuscany-sca-cpp-bin$ du -c modules/server modules/http
24	modules/server/htdocs/js
28	modules/server/htdocs
708	modules/server
20	modules/http/conf
76	modules/http
784	total (0.8Mb)

Subset of HTTPD needed by Tuscany-cpp (see the list of modules in [5]):
/httpd-2.2.15-bin$ du -c bin lib modules
516	bin
748	lib
756	modules
2020	total (2Mb)

With the latest code you can just use the JSON-RPC binding, which is 
lighter than the old SOAP binding. Let's add the library used for JSON:
/tracemonkey-bin$ du -c lib/libmozjs.so
1704	lib/libmozjs.so
1704	total (1.7Mb)

That gives us a total of 784 + 2020 + 1704 = 4508Kb (4.4Mb).

That's all you need to run your SCA components, with robust support for 
HTTP, and JSON-RPC and ATOM/REST bindings.

If you want SOAP, you need the Tuscany-cpp Web service component:
/tuscany-sca-cpp-bin$ du -c components/webservice
656	components/webservice
656	total (0.6Mb)

and Axis2/C:
/axis2c-1.6.0-bin$ du -c axis2.xml bin lib modules
8	axis2.xml
268	bin
1864	lib
52	modules/addressing
24	modules/logging
80	modules
2220	total (2.2Mb)

That's a total of: 784 + 2020 + 1704 + 2220 = 6728Kb (6.6Mb)

> Is M3 completly obsolete or is there any interest in pursuing this architure?

M3 is more than 3 years old, that's getting old :)

Here is an analysis of the M3 binaries.

Subset of Tuscany-sca-cpp-M3 for C++ components, SOAP and REST bindings:
/tuscany-sca-cpp-M3-bin $ du -c extensions lib
148	extensions/cpp
248	extensions/ws
108	extensions/sca
320	extensions/rest
828	extensions
532	lib
1360	total (1.3Mb)

I'm including the SOAP binding here as I'm assuming that you need an 
RPC-type binding and won't do everything with REST, and there was no 
JSON-RPC binding in M3.

You also needed Tuscany-sdo-M3:
/tuscany-sdo-cpp-M3-bin $ du -c lib
1192	lib
1192	total (1.2Mb)

So, including the recommended HTTPD and Axis2/C, M3 needed at minimum:
1360 + 1192 + 2020 + 2220 = 6792Kb (6.6Mb)

We can discuss the various packaging options, but if you're really 
constrained by disk storage, I'd suggest the latest code with JSON-RPC 
instead of SOAP, 4.4Mb including HTTPD.

Now, if you really want to use M3 or integrate the latest code with 
axis2_http_server again, that's OK too. I'll try to help as much as I 
can when I find some spare time.

[1] http://wso2.org/forum/thread/8779
[2] http://markmail.org/message/dfbbnnpnmlraxv2w
[3] http://markmail.org/message/kz6gnorlrj3smjjs
[4] https://issues.apache.org/jira/browse/AXIS2-4756
[5] 
http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/modules/http/httpd-conf

Hope this helps.
-- 
Jean-Sebastien

Re: Qpid functionality in Tuscany

Posted by Mario Grotschar <ma...@gmail.com>.

Ah ok. I see that in M4 everything is a module to httpd server. So in M4
there is no way to run the runtime without httpd server? What was the reason
for changing to this different approach?
The problem for the project we would like to use SCA for is a very limited
host system, offering only 25 MB of disk storage.

As far as i can see in M3 the native SCA binding uses ws and therefore the
AXIS2 server, so unless i use REST I dont need the HTTPD server. The runtime
will load the modules directly. Is M3 completly obsolete or is there any
interest in pursuing this architure?



2010/7/8 Jean-Sebastien Delfino <js...@apache.org>

> Mario Grotschar wrote:
>
>> Tanks for your reply.
>>
>> One question to the tuscany frame work.
>>
>> In the project the tuscany_sca_native-1.0-incubator-M3 ist used. There I
>> can
>> find in the src a directory
>>
>> -- src
>>    `-- tuscany
>>        `-- sca
>>            |-- core
>>            |-- extension
>>            |-- model
>>            `-- util
>>
> ...
>
> Hi Mario,
>
> M3 is from May 2007. That code has changed quite a bit in 3 years, so I
> recommend to use the code in trunk instead.
>
>
>
>> In the newer version in the svn trunk i can only see a directory
>>
>> |-- kernel
>> |   |-- Makefile.am
>> |   |-- config.hpp
>> |   |-- dynlib-test.cpp
>> |   |-- dynlib.hpp
>> |   |-- element.hpp
>> |   |-- fstream.hpp
>> |   |-- function.hpp
>> |   |-- gc.hpp
>> |   |-- hash-test.cpp
>> |   |-- hash.hpp
>> |   |-- kernel-test.cpp
>> |   |-- lambda-test.cpp
>> |   |-- list.hpp
>> |   |-- mem-test.cpp
>> |   |-- monad.hpp
>> |   |-- parallel-test.cpp
>> |   |-- parallel.hpp
>> |   |-- perf.hpp
>> |   |-- sstream.hpp
>> |   |-- stream.hpp
>> |   |-- string-test.cpp
>> |   |-- string.hpp
>> |   |-- tree.hpp
>> |   |-- value.hpp
>> |   |-- xml-test.cpp
>> |   |-- xml.hpp
>> |   `-- xsd-test.cpp
>>
>> I cannot find the corresponding files that incorporate the logic. Am i
>> missing something?
>>
>
> Try cd .. [1] to see more :). The README [2] describes the trunk source
> tree layout. The Qpid support code is in components/queue [3].
>
>
> [1] http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/
> [2] http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/README
> [3]
> http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/components/queue/
>
>
> Hope this helps.
> --
> Jean-Sebastien
>



-- 
Mit freundlichen Grüßen,

Mario Grotschar

mario.grotschar@gmail.com

Re: Qpid functionality in Tuscany

Posted by Jean-Sebastien Delfino <js...@apache.org>.

Mario Grotschar wrote:
> Tanks for your reply.
> 
> One question to the tuscany frame work.
> 
> In the project the tuscany_sca_native-1.0-incubator-M3 ist used. There I can
> find in the src a directory
> 
> -- src
>     `-- tuscany
>         `-- sca
>             |-- core
>             |-- extension
>             |-- model
>             `-- util
...

Hi Mario,

M3 is from May 2007. That code has changed quite a bit in 3 years, so I 
recommend to use the code in trunk instead.

> 
> In the newer version in the svn trunk i can only see a directory
> 
> |-- kernel
> |   |-- Makefile.am
> |   |-- config.hpp
> |   |-- dynlib-test.cpp
> |   |-- dynlib.hpp
> |   |-- element.hpp
> |   |-- fstream.hpp
> |   |-- function.hpp
> |   |-- gc.hpp
> |   |-- hash-test.cpp
> |   |-- hash.hpp
> |   |-- kernel-test.cpp
> |   |-- lambda-test.cpp
> |   |-- list.hpp
> |   |-- mem-test.cpp
> |   |-- monad.hpp
> |   |-- parallel-test.cpp
> |   |-- parallel.hpp
> |   |-- perf.hpp
> |   |-- sstream.hpp
> |   |-- stream.hpp
> |   |-- string-test.cpp
> |   |-- string.hpp
> |   |-- tree.hpp
> |   |-- value.hpp
> |   |-- xml-test.cpp
> |   |-- xml.hpp
> |   `-- xsd-test.cpp
> 
> I cannot find the corresponding files that incorporate the logic. Am i
> missing something?

Try cd .. [1] to see more :). The README [2] describes the trunk source 
tree layout. The Qpid support code is in components/queue [3].

[1] http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/
[2] http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/README
[3] http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/components/queue/

Hope this helps.
-- 
Jean-Sebastien