Hi, all. I seem to find some clues in the src. These NullPointerException is thrown because in the following code: On Thu, Apr 18, 2013 at 2:06 PM, 冯仁君 <fengrj1989@gmail.com> wrote: > Hi all, > > I'm new in TUSCANY and I try run BPEL on TUSCANY within shell. > > I put a helloworld.bpel, a helloworld.wsld, and a helloworld.composite in > a folder. Then start TUSCANY. > > There is no error when I start this composite in shell and I can see > detials of this composite with command SERVICES. > > However, when I invoke this service, I get following exception: > > default> invoke BPELHelloWorldComponent/helloPartnerLink hello asd > org.oasisopen.sca.ServiceRuntimeException: > org.apache.tuscany.sca.core.factory.ObjectCreationException: > java.lang.NullPointerException > at > org.apache.tuscany.sca.core.context.impl.ServiceReferenceImpl.getService(ServiceReferenceImpl.java:160) > at > org.apache.tuscany.sca.impl.ServiceHelper.getService(ServiceHelper.java:82) > at org.apache.tuscany.sca.impl.NodeImpl.getService(NodeImpl.java:470) > at org.apache.tuscany.sca.shell.commands.Invoke.invoke(Invoke.java:85) > at org.apache.tuscany.sca.shell.Shell$1.call(Shell.java:518) > at org.apache.tuscany.sca.shell.Shell$1.call(Shell.java:516) > at org.apache.tuscany.sca.shell.Shell.apply(Shell.java:628) > at org.apache.tuscany.sca.shell.Shell.run(Shell.java:642) > at org.apache.tuscany.sca.shell.Shell.main(Shell.java:112) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.tuscany.sca.launcher.LauncherMain.invokeMainMethod(LauncherMain.java:115) > at > org.apache.tuscany.sca.launcher.LauncherMain.main(LauncherMain.java:56) > Caused by: org.apache.tuscany.sca.core.factory.ObjectCreationException: > java.lang.NullPointerException > at > org.apache.tuscany.sca.core.context.impl.ServiceReferenceImpl.getProxy(ServiceReferenceImpl.java:143) > at > org.apache.tuscany.sca.core.context.impl.ServiceReferenceImpl.getService(ServiceReferenceImpl.java:158) > ... 14 more > Caused by: java.lang.NullPointerException > at > org.apache.tuscany.sca.core.invocation.ExtensibleProxyFactory.createProxy(ExtensibleProxyFactory.java:97) > at > org.apache.tuscany.sca.core.context.impl.ServiceReferenceImpl.createProxy(ServiceReferenceImpl.java:152) > at > org.apache.tuscany.sca.core.context.impl.ServiceReferenceImpl.getProxy(ServiceReferenceImpl.java:139) > ... 15 more > > > Any one knows this problem? > Or tell me how to run a BPEL on TUSCANY within shell( not just mvn test). > > plz, thank you! > > -- > > Best Regards, > Feng Renjun. > -- Best Regards, Feng Renjun.
Now that Apache have been officially accepted as a Mentoring organization for Google Summer of Code 2013, I have started creating couple jiras with project ideas and would like to encourage others to also think about volunteering as mentors and create new project ideas. Thanks -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
Luciano Resende created TUSCANY-4077:
----------------------------------------
Summary: Enhance Tuscany Widget support
Key: TUSCANY-4077
URL: https://issues.apache.org/jira/browse/TUSCANY-4077
Project: Tuscany
Issue Type: New Feature
Components: Java SCA Widget
Reporter: Luciano Resende
Enhance the current Tuscany Widget to support different javascript libraries (e.g. JQuery),
enable support for cross-domain services invocations using CORS when applicable, support gzip
compression, etc
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Luciano Resende created TUSCANY-4076:
----------------------------------------
Summary: Develop a distributed domain registry using Apache ZooKeeper
Key: TUSCANY-4076
URL: https://issues.apache.org/jira/browse/TUSCANY-4076
Project: Tuscany
Issue Type: New Feature
Components: SCA Java Runtime
Reporter: Luciano Resende
Add Support to a distributed SCA domain registry using Apache Zookeeper. An stretch goal would
be to provide a "persistence abstraction" that would enable plugin in different distributed
data services such as Apache ZooKeeper, Redis, or Memcache. BTW, there is an initial prototype
from Raymond Feng on this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Congrats and Welcome Sebastian! - Jean-Sebastien Sent from my DynaTAC 8000x On Apr 8, 2013, at 8:59 AM, Raymond Feng <enjoyjava@gmail.com> wrote: > Congratulations and welcome on board! > > Raymond > > On Apr 8, 2013, at 7:29 AM, Luciano Resende <luckbr1975@gmail.com> wrote: > >> The Tuscany PMC have voted to make Sebastian Millies a Tuscany committer. >> >> Congratulations and welcome Sebastian! >> >> -- >> Luciano Resende >> http://people.apache.org/~lresende >> http://twitter.com/lresende1975 >> http://lresende.blogspot.com/ >
Congratulations and welcome on board! Raymond On Apr 8, 2013, at 7:29 AM, Luciano Resende <luckbr1975@gmail.com> wrote: > The Tuscany PMC have voted to make Sebastian Millies a Tuscany committer. > > Congratulations and welcome Sebastian! > > -- > Luciano Resende > http://people.apache.org/~lresende > http://twitter.com/lresende1975 > http://lresende.blogspot.com/
Congratulations Sebastian, and welcome on board! Simon Luciano Resende wrote: > The Tuscany PMC have voted to make Sebastian Millies a Tuscany committer. > > Congratulations and welcome Sebastian! > > -- > Luciano Resende > http://people.apache.org/~lresende > http://twitter.com/lresende1975 > http://lresende.blogspot.com/
The Tuscany PMC have voted to make Sebastian Millies a Tuscany committer. Congratulations and welcome Sebastian! -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
I suppose, nobody really cares :-) but I entered a Jira anyway (TUSCANY-4075) I looked further into it for potential side effects and commented in Jira - was not sure about sequences and lists but that should be safe too (and at least not worse than today). I tested it and did not find any problems so far. Still, if there are comments, I'd be glad for opinions/...!! Rgds, tge On Tue, 2013-02-19 at 16:32 +0100, Thomas Gentsch wrote: > Hello all, > > we are using both C++ and Java SDO in a project and discovered some > misbehavior in the C++ components with XML data converted from/to SDO if > the XML contains either escaped chars of CDATA. Java seems to do it > mostly right (see below) > > When looking at the SDO (C++ M3) code and searching on the web (e.g. > [1]) it looks as if this topic seemed a bit, well, incomplete in the C++ > world. > > The problem (C++): > - loading an XML with CDATA inside works nicely, the CDATA remains > intact, therefore saving works nicely too. However, if I do a > DataObjectPtr->getCString(), I get the CDATA in the returned value - > means as a user I have to deal with that :-| > - loading an XML with escaped (e.g. <) works too, libxml2 converts > these chars. getCString() returns the real text (e.g. "<"), but > saving does not re-insert the escaping - i.e. the resulting XML is > not usable anymore (TUSCANY-1553) > In Java this looks much better and quite as I'd expect it to: > - loading XML with either constructs works > - using getCString() just returns the real text with the escaped > sections converted > - saving works too, CDATA are lost but are rather converted back to > escaped XML - this is not the *original* XML anymore but at least it > is valid and logically it is the same as the input > - Example: > Input XML: > <tns1:name>ü<>bla blub <![CDATA[ <<>> ]]></tns1:name> > getCString() in Java: > "ü<>bla blub <<>> " > Saving this as XML: > <tns1:name>ü<>bla blub <<>> </tns1:name> > The only questionable thing is the saved "ü" ... to be > converted back to ü or ü ? > > Anyway, now the question: As it seems there were discussions going on > when SDO C++ has been implemented - has the approach above (as in Java) > ever been considered and, if so, why has it not been followed? > I believe that this would have been also much simpler than it is today: > - while parsing > - the cdata handler function of the SAX2 handler just > appends the text returned by libxml2 > - escaped chars are converted by libxml2 anyway > - the property value now contains the real text > (e.g. "ü<>bla blub <<>> ") and returns it just as-is in getCString() > - setting that property also just sets the passed-in value > - saving the property just calls libxml2 xmlTextWriterWriteString() > which should escape the special chars > > Another advantage is that users don't need to worry about (un)escaping > special chars or CDATA as today. > > Any insight is very welcome! > Regards, > tge
[ https://issues.apache.org/jira/browse/TUSCANY-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583109#comment-13583109
]
Thomas Gentsch commented on TUSCANY-4075:
-----------------------------------------
This would make TUSCANY-1553 and TUSCANY-3715 unnecessary.
Discovered a few other things:
- reading in a sequence (as in letter example) works only if most-top-level XSD class is tagged
as mixed=true, not for embedded classes
- writing XML lists seems not to be implemented at all - DataObjectList works but does not
consider whether the original was/is a list
- line break recognition to separate sequence items while XML parsing questionable
> SDO C++ handling of XML CDATA and escaped chars inconsistent
> ------------------------------------------------------------
>
> Key: TUSCANY-4075
> URL: https://issues.apache.org/jira/browse/TUSCANY-4075
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SDO
> Affects Versions: Cpp-M3
> Reporter: Thomas Gentsch
>
> we are using both C++ and Java SDO in a project and discovered some
> misbehavior in the C++ components with XML data converted from/to SDO if
> the XML contains either escaped chars of CDATA. Java seems to do it
> mostly right (see below)
> When looking at the SDO (C++ M3) code and searching on the web (e.g.
> [1]) it looks as if this topic seemed a bit, well, incomplete in the C++
> world.
> The problem (C++):
> - loading an XML with CDATA inside works nicely, the CDATA remains
> intact, therefore saving works nicely too. However, if I do a
> DataObjectPtr->getCString(), I get the CDATA in the returned value -
> means as a user I have to deal with that :-|
> - loading an XML with escaped (e.g. <) works too, libxml2 converts
> these chars. getCString() returns the real text (e.g. "<"), but
> saving does not re-insert the escaping - i.e. the resulting XML is
> not usable anymore (TUSCANY-1553)
> In Java this looks much better and quite as I'd expect it to:
> - loading XML with either constructs works
> - using getCString() just returns the real text with the escaped
> sections converted
> - saving works too, CDATA are lost but are rather converted back to
> escaped XML - this is not the *original* XML anymore but at least it
> is valid and logically it is the same as the input
> - Example:
> Input XML:
> <tns1:name>ü<>bla blub <![CDATA[ <<>>
]]></tns1:name>
> getCString() in Java:
> "ü<>bla blub <<>> "
> Saving this as XML:
> <tns1:name>ü<>bla blub <<>> </tns1:name>
> The only questionable thing is the saved "ü" ... to be
> converted back to ü or ü ?
> Anyway, now the question: As it seems there were discussions going on
> when SDO C++ has been implemented - has the approach above (as in Java)
> ever been considered and, if so, why has it not been followed?
> I believe that this would have been also much simpler than it is today:
> - while parsing
> - the cdata handler function of the SAX2 handler just
> appends the text returned by libxml2
> - escaped chars are converted by libxml2 anyway
> - the property value now contains the real text
> (e.g. "ü<>bla blub <<>> ") and returns it just as-is in getCString()
> - setting that property also just sets the passed-in value
> - saving the property just calls libxml2 xmlTextWriterWriteString()
> which should escape the special chars
> Another advantage is that users don't need to worry about (un)escaping
> special chars or CDATA as today. Disadvantage: API behavior changes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Thomas Gentsch created TUSCANY-4075:
---------------------------------------
Summary: SDO C++ handling of XML CDATA and escaped chars inconsistent
Key: TUSCANY-4075
URL: https://issues.apache.org/jira/browse/TUSCANY-4075
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-M3
Reporter: Thomas Gentsch
we are using both C++ and Java SDO in a project and discovered some
misbehavior in the C++ components with XML data converted from/to SDO if
the XML contains either escaped chars of CDATA. Java seems to do it
mostly right (see below)
When looking at the SDO (C++ M3) code and searching on the web (e.g.
[1]) it looks as if this topic seemed a bit, well, incomplete in the C++
world.
The problem (C++):
- loading an XML with CDATA inside works nicely, the CDATA remains
intact, therefore saving works nicely too. However, if I do a
DataObjectPtr->getCString(), I get the CDATA in the returned value -
means as a user I have to deal with that :-|
- loading an XML with escaped (e.g. <) works too, libxml2 converts
these chars. getCString() returns the real text (e.g. "<"), but
saving does not re-insert the escaping - i.e. the resulting XML is
not usable anymore (TUSCANY-1553)
In Java this looks much better and quite as I'd expect it to:
- loading XML with either constructs works
- using getCString() just returns the real text with the escaped
sections converted
- saving works too, CDATA are lost but are rather converted back to
escaped XML - this is not the *original* XML anymore but at least it
is valid and logically it is the same as the input
- Example:
Input XML:
<tns1:name>ü<>bla blub <![CDATA[ <<>> ]]></tns1:name>
getCString() in Java:
"ü<>bla blub <<>> "
Saving this as XML:
<tns1:name>ü<>bla blub <<>> </tns1:name>
The only questionable thing is the saved "ü" ... to be
converted back to ü or ü ?
Anyway, now the question: As it seems there were discussions going on
when SDO C++ has been implemented - has the approach above (as in Java)
ever been considered and, if so, why has it not been followed?
I believe that this would have been also much simpler than it is today:
- while parsing
- the cdata handler function of the SAX2 handler just
appends the text returned by libxml2
- escaped chars are converted by libxml2 anyway
- the property value now contains the real text
(e.g. "ü<>bla blub <<>> ") and returns it just as-is in getCString()
- setting that property also just sets the passed-in value
- saving the property just calls libxml2 xmlTextWriterWriteString()
which should escape the special chars
Another advantage is that users don't need to worry about (un)escaping
special chars or CDATA as today. Disadvantage: API behavior changes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Hello all,
we are using both C++ and Java SDO in a project and discovered some
misbehavior in the C++ components with XML data converted from/to SDO if
the XML contains either escaped chars of CDATA. Java seems to do it
mostly right (see below)
When looking at the SDO (C++ M3) code and searching on the web (e.g.
[1]) it looks as if this topic seemed a bit, well, incomplete in the C++
world.
The problem (C++):
- loading an XML with CDATA inside works nicely, the CDATA remains
intact, therefore saving works nicely too. However, if I do a
DataObjectPtr->getCString(), I get the CDATA in the returned value -
means as a user I have to deal with that :-|
- loading an XML with escaped (e.g. <) works too, libxml2 converts
these chars. getCString() returns the real text (e.g. "<"), but
saving does not re-insert the escaping - i.e. the resulting XML is
not usable anymore (TUSCANY-1553)
In Java this looks much better and quite as I'd expect it to:
- loading XML with either constructs works
- using getCString() just returns the real text with the escaped
sections converted
- saving works too, CDATA are lost but are rather converted back to
escaped XML - this is not the *original* XML anymore but at least it
is valid and logically it is the same as the input
- Example:
Input XML:
<tns1:name>ü<>bla blub <![CDATA[ <<>> ]]></tns1:name>
getCString() in Java:
"ü<>bla blub <<>> "
Saving this as XML:
<tns1:name>ü<>bla blub <<>> </tns1:name>
The only questionable thing is the saved "ü" ... to be
converted back to ü or ü ?
Anyway, now the question: As it seems there were discussions going on
when SDO C++ has been implemented - has the approach above (as in Java)
ever been considered and, if so, why has it not been followed?
I believe that this would have been also much simpler than it is today:
- while parsing
- the cdata handler function of the SAX2 handler just
appends the text returned by libxml2
- escaped chars are converted by libxml2 anyway
- the property value now contains the real text
(e.g. "ü<>bla blub <<>> ") and returns it just as-is in getCString()
- setting that property also just sets the passed-in value
- saving the property just calls libxml2 xmlTextWriterWriteString()
which should escape the special chars
Another advantage is that users don't need to worry about (un)escaping
special chars or CDATA as today.
Any insight is very welcome!
Regards,
tge
On Sun, Feb 10, 2013 at 5:28 PM, Jean-Sebastien Delfino <jsdelfino@apache.org> wrote: > Hi all, > > Not much has happened since we discussed integrating Nuvem as a sub-project > [1][2], so to help move this thread forward I'm going to start integrating > the Python Nuvem components in the C++ SCA source tree under /components/ > [3]. They were written to run on that runtime's Python support so that seems > like an easy starting point, and I'm also interested in using them in a few > new Python samples that'll illustrate what you can do with them. > > HTH > > [1] http://marc.info/?l=tuscany-dev&m=135338851904749&w=2 > [2] http://marc.info/?l=incubator-general&m=135423982723185&w=2 > [3] http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/components/ > > - Jean-Sebastien +1, I'll hopefully have some time soon to start moving the java components. -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
Hi all, Not much has happened since we discussed integrating Nuvem as a sub-project [1][2], so to help move this thread forward I'm going to start integrating the Python Nuvem components in the C++ SCA source tree under /components/ [3]. They were written to run on that runtime's Python support so that seems like an easy starting point, and I'm also interested in using them in a few new Python samples that'll illustrate what you can do with them. HTH [1] http://marc.info/?l=tuscany-dev&m=135338851904749&w=2 [2] http://marc.info/?l=incubator-general&m=135423982723185&w=2 [3] http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/components/ - Jean-Sebastien
On Mon, Jan 14, 2013 at 1:03 PM, Thomas Gentsch <tg@e-tge.de> wrote: > On Sun, 2013-01-13 at 23:35 -0800, Jean-Sebastien Delfino wrote: > > On Mon, Jan 7, 2013 at 1:28 PM, Thomas Gentsch <tg@e-tge.de> wrote: > ... > > > > Q: Is there some kind of request routing? > > A: Local calls are resolved during OS-loader-time. One > > component calling > > another is written as regular C++ code which results in > > compiled code as > > unresolved reference that must be satisfied during runtime by > > the target > > component which in turn must be loaded as shared library > > > > > > > > No, if I remember correctly (as M3 was a long time ago,) > > :-) > > > wires were resolved by Composite::resolveWires, then invocation of a > > component involved CPPServiceWrapper::getServiceWrapper to load the > > component library, lookup a factory function named after the service > > name, create an instance of CPPServiceWrapper, and eventually > > executing generated code in CPPServiceWrapper::invokeService to > > dispatch the call to the target C++ component method. > > But then the wrapper and proxy must exist - either hand-written or > WSDL-generated. Yes > The CppCalculator example though has neither. I did not > verify all the others, most have WSDL as it seems. > Maybe as long everything happens within *one* lib ... ? > > Proxies and wrappers are generated at build time. That's why you can't find them in the source tree, as we usually don't commit generated build outputs to the Apache source repository. > Actually I was thinking that its even not a bad idea to let the OS > loader (or even the linker) resolve the calls as it is probably the > fastest way possible. > > That could be challenging in the following configurations: a) several components, say C1 and C2, implementing the same service WSDL interface 'I' + operation 'o' (as the linker wouldn't know which one to pick); b) dynamic wiring decided by a component's implementation logic (as the linking would happen too early); c) a composition of components written in different languages, in particular scripting languages (as linking would only apply to C and C++ components). ... but that's still an interesting idea to explore. I've not thought too much about it, but you may be able to come up with a generation scheme addressing some of these challenges. ... > > > I've worked on C++ M3, trunk and even the Java project so I can > > imagine why someone would prefer one or the other. The good thing is > > that they're here in the open and you can do what you want with the > > code, use the bits you prefer, mix them, or even contribute to > > maintain or change them to something you like, if you're interested. > > True, but the real power of open-source is if the "community" jointly > works on the same thing. Of course I cannot force anybody :-) > Also, I quite like the idea of following a standard (if it is any good, > which I cannot really tell yet). > > +1 > So, in theory, I could start a project, let's say "sca-oasis", based on > M3 ... originally I'd be the only one working on it, maybe others join, > maybe not. Would that then still be "Apache Tuscany"? > > For it to be 'Apache Tuscany' you'd have to discuss and contribute your ideas to the Apache Tuscany community here in the open -- which you are doing right now :) -- and contribute code changes or additions to the Apache Tuscany project repository. If you're interested, you can start with patches in JIRA issues (which allow you to grant license to Apache for your contributions) and at some point the community can even give you committership. We should discuss what you have in mind on this list (I'd suggest a different thread as this one is getting long) but for example 'adding support for the OASIS SCA assembly spec to the M3 code', 'integrating some of the M3 code and trunk', 'adding a code generator to trunk (the one from M3 or another)' or any other ideas you have, would all be valid ideas to discuss and evolve the project IMO. ... > > > I'm not sure if you're talking about validating the data exchanged > > with SCA components (which could be done with a validating proxy) or > > about generating static code from schema type definitions, but both > > approaches should work nicely along M3 or trunk (for the latter you'd > > need a generator like scagen on top of the runtime invocation > > mechanism.) > > Maybe here I'm in the SDO world again ... :-) All the schema/type stuff > is nicely integrated and I don't need to directly deal with libxml2 or > so ... > > If you like SDO, that could be an area where you could contribute too. For example (just thinking out loud) you could try to get SDO to work with JSON, as JSON is getting so much traction these days, or (going back to your code generation idea), first make sure that SDO still works with modern C++ compilers and the latest Libxml2 parser, re-activate its build etc, then generate C++ SCA component skeletons that use SDOs. - Jean-Sebastien
On Sun, 2013-01-13 at 23:35 -0800, Jean-Sebastien Delfino wrote: > On Mon, Jan 7, 2013 at 1:28 PM, Thomas Gentsch <tg@e-tge.de> wrote: > > Hello JS, > > > > Hi Thomas, Happy New Year! Many thx! Same back!! > now, I did some more reading etc and believe now that I mostly > understand what's going on :-) > > The main missing pieces were these (correct? Possibly my > terminology is > a bit fuzzy :-): > Q: When are SDOs used (in SCA M3) and when not? > A: If an interface of a service uses complex types as in/out > params or > return value, otherwise simple types (like int, bool, string) > are used. > Complex types (i.e. class instances) an XSD are passed in/out > as SDO > > > > Yes > > Q: Is there some kind of request routing? > A: Local calls are resolved during OS-loader-time. One > component calling > another is written as regular C++ code which results in > compiled code as > unresolved reference that must be satisfied during runtime by > the target > component which in turn must be loaded as shared library > > > > No, if I remember correctly (as M3 was a long time ago,) :-) > wires were resolved by Composite::resolveWires, then invocation of a > component involved CPPServiceWrapper::getServiceWrapper to load the > component library, lookup a factory function named after the service > name, create an instance of CPPServiceWrapper, and eventually > executing generated code in CPPServiceWrapper::invokeService to > dispatch the call to the target C++ component method. But then the wrapper and proxy must exist - either hand-written or WSDL-generated. The CppCalculator example though has neither. I did not verify all the others, most have WSDL as it seems. Maybe as long everything happens within *one* lib ... ? Actually I was thinking that its even not a bad idea to let the OS loader (or even the linker) resolve the calls as it is probably the fastest way possible. But, OK, will look again :-) > In trunk, the equivalent of invokeService is the apply function, and > currently needs to be written by hand as scagen has not been > maintained (but could be brought back if somebody was interested in > maintaining it). > > Q: What is the purpose of composite files with pure C++ > modules? > A: If a composite consists only of local components all calls > are > resolved by the OS loader. In that case basically the > composite > definition file mainly states which interfaces are in which > shared lib > and in which order are the libs to be loaded. > > > > See above, both M3 and trunk resolve wiring dynamically. > > Q: How are remote request handled? > A: Remote interfaces are described using WSDL, which must be > processed > using the tool scagen to generate a "ServiceWrapper" and a > "ServiceProxy" that act as client (proxy) and server (wrapper) > stubs. > > > In M3 ServiceWrapper and ServiceProxy were generated from WSDL by > scagen and were used for both local and remote invocations. > > > However, some things are still unclear: > Q: If there is nothing like request routing, how does the > "wiring" work > if the calls are actually hardcoded? > > > > See above. > > Besides of these questions a few non-technical ones: > Q: The trunk code stream looks to me like a complete re-write. > With even > the component interfaces changing and nobody complaining I > guess that > there is nobody actually really using Tuscany SCA C++? > > > I just checked M3 again and it looks that way now when we compare > trunk in 2013 and M3 from 2006/2007. The code has evolved slowly but > after 6 years I'm not really surprised. > > Q: Besides of people using it, is there anybody besides you > working on > it? > > > I'm not really sure. I've been the only one pushing changes to trunk > recently. I noticed a new lightweight-sca clone branch recently but > can't remember who created it. When I get tech questions here, in > email or IRC, and find time, I try to answer without bothering people > asking what they're doing with the code, so there may be more clone > branches here or on github for example, as the code is open to anyone > who wants to hack on it. > Q: To which extent are both the M3 and trunk versions > "stable"? M3 > probably in the sense that nobody works on it anymore but is > it mostly > complete/usable? > > > M3 has not changed since 2007. Trunk is moving slowly as I only spend > a little spare time on it on some weekends or holidays. Complete and > usable are subjective notions, as IMO an open-source project is not > 'complete' as long as people are still interested in evolving it, and > 'usable' depends on the use case. > > Q: What about interoperability with Tuscany Java? I suppose > both M3 and > trunk are OK as long as the binding is the same (and on the > wire it is > XML or whatever anyway). Which common binding types exist? > > > With M3, REST. With trunk, REST and SOAP. > > > Generally I have to admit that I liked the old implementation > more, > though this maybe caused by the new language features in trunk > I'm not > familiar with yet. > > > I've worked on C++ M3, trunk and even the Java project so I can > imagine why someone would prefer one or the other. The good thing is > that they're here in the open and you can do what you want with the > code, use the bits you prefer, mix them, or even contribute to > maintain or change them to something you like, if you're interested. True, but the real power of open-source is if the "community" jointly works on the same thing. Of course I cannot force anybody :-) Also, I quite like the idea of following a standard (if it is any good, which I cannot really tell yet). So, in theory, I could start a project, let's say "sca-oasis", based on M3 ... originally I'd be the only one working on it, maybe others join, maybe not. Would that then still be "Apache Tuscany"? Maybe I'll post something in tuscany-users like "anybody using it?" ... > > Q: With the new value/list types, if there is no relation with > XSD > anymore, can you also query information about object types, > e.g. which > properties a class shall have? This is probably not needed in > the SCA > code, but maybe in custom extensions ... > > > There isn't anything in the runtime to allow you to query the types, > but if you have an XML (or JSON) schema, and a schema library that > you'd like to use with your types, there's no reason why you couldn't > use that library along with SCA. > > Also, type enforcement is not necessarily a disadvantage > (admittedly > slower though) > > > I'm not sure if you're talking about validating the data exchanged > with SCA components (which could be done with a validating proxy) or > about generating static code from schema type definitions, but both > approaches should work nicely along M3 or trunk (for the latter you'd > need a generator like scagen on top of the runtime invocation > mechanism.) Maybe here I'm in the SDO world again ... :-) All the schema/type stuff is nicely integrated and I don't need to directly deal with libxml2 or so ... Many thx again!!! tge > > Many thx again + regards, > the > > On Wed, 2013-01-02 at 23:49 -0800, Jean-Sebastien Delfino > wrote: > > On Sat, Dec 29, 2012 at 6:20 PM, Jean-Sebastien Delfino > > <jsdelfino@apache.org> wrote: > > Hi all, > > > > > > I had a few more offline Q&A exchanges with Thomas, > and > > thought it'd be useful to share a summary here: > > > > > > Q: In the C++ trunk, is DataObject now replaced by > > tuscany::value and tuscany::list? > > > > > > A: Yes > > > > > > > > > > BTW I just committed a number of changes I made over the > holidays, > > including some improvements to tuscany::value and > tuscany::list, in > > particular to work with lists, nested lists and trees of > key/value > > pairs (aka associations) as well as some minor improvements > to handle > > comparisons of floating point number values. > > > > > > - Jean-Sebastien > > > > > -- ........................................................ Thomas Gentsch Römerstr. 76 70180 Stuttgart Tel : (+49) 0711 - 46915652 mobil : (+49) 0173 - 6620507 e-mail: tg@e-tge.de ........................................................
On Mon, Jan 7, 2013 at 1:28 PM, Thomas Gentsch <tg@e-tge.de> wrote: > > Hello JS, > > Hi Thomas, Happy New Year! > now, I did some more reading etc and believe now that I mostly > understand what's going on :-) > > The main missing pieces were these (correct? Possibly my terminology is > a bit fuzzy :-): > Q: When are SDOs used (in SCA M3) and when not? > A: If an interface of a service uses complex types as in/out params or > return value, otherwise simple types (like int, bool, string) are used. > Complex types (i.e. class instances) an XSD are passed in/out as SDO > > Yes > Q: Is there some kind of request routing? > A: Local calls are resolved during OS-loader-time. One component calling > another is written as regular C++ code which results in compiled code as > unresolved reference that must be satisfied during runtime by the target > component which in turn must be loaded as shared library > > No, if I remember correctly (as M3 was a long time ago,) wires were resolved by Composite::resolveWires, then invocation of a component involved CPPServiceWrapper::getServiceWrapper to load the component library, lookup a factory function named after the service name, create an instance of CPPServiceWrapper, and eventually executing generated code in CPPServiceWrapper::invokeService to dispatch the call to the target C++ component method. In trunk, the equivalent of invokeService is the apply function, and currently needs to be written by hand as scagen has not been maintained (but could be brought back if somebody was interested in maintaining it). > Q: What is the purpose of composite files with pure C++ modules? > A: If a composite consists only of local components all calls are > resolved by the OS loader. In that case basically the composite > definition file mainly states which interfaces are in which shared lib > and in which order are the libs to be loaded. > > See above, both M3 and trunk resolve wiring dynamically. > Q: How are remote request handled? > A: Remote interfaces are described using WSDL, which must be processed > using the tool scagen to generate a "ServiceWrapper" and a > "ServiceProxy" that act as client (proxy) and server (wrapper) stubs. > In M3 ServiceWrapper and ServiceProxy were generated from WSDL by scagen and were used for both local and remote invocations. > > However, some things are still unclear: > Q: If there is nothing like request routing, how does the "wiring" work > if the calls are actually hardcoded? > > See above. > Besides of these questions a few non-technical ones: > Q: The trunk code stream looks to me like a complete re-write. With even > the component interfaces changing and nobody complaining I guess that > there is nobody actually really using Tuscany SCA C++? > I just checked M3 again and it looks that way now when we compare trunk in 2013 and M3 from 2006/2007. The code has evolved slowly but after 6 years I'm not really surprised. > Q: Besides of people using it, is there anybody besides you working on > it? > I'm not really sure. I've been the only one pushing changes to trunk recently. I noticed a new lightweight-sca clone branch recently but can't remember who created it. When I get tech questions here, in email or IRC, and find time, I try to answer without bothering people asking what they're doing with the code, so there may be more clone branches here or on github for example, as the code is open to anyone who wants to hack on it. > Q: To which extent are both the M3 and trunk versions "stable"? M3 > probably in the sense that nobody works on it anymore but is it mostly > complete/usable? > M3 has not changed since 2007. Trunk is moving slowly as I only spend a little spare time on it on some weekends or holidays. Complete and usable are subjective notions, as IMO an open-source project is not 'complete' as long as people are still interested in evolving it, and 'usable' depends on the use case. > Q: What about interoperability with Tuscany Java? I suppose both M3 and > trunk are OK as long as the binding is the same (and on the wire it is > XML or whatever anyway). Which common binding types exist? > With M3, REST. With trunk, REST and SOAP. > > Generally I have to admit that I liked the old implementation more, > though this maybe caused by the new language features in trunk I'm not > familiar with yet. > I've worked on C++ M3, trunk and even the Java project so I can imagine why someone would prefer one or the other. The good thing is that they're here in the open and you can do what you want with the code, use the bits you prefer, mix them, or even contribute to maintain or change them to something you like, if you're interested. > > Q: With the new value/list types, if there is no relation with XSD > anymore, can you also query information about object types, e.g. which > properties a class shall have? This is probably not needed in the SCA > code, but maybe in custom extensions ... > There isn't anything in the runtime to allow you to query the types, but if you have an XML (or JSON) schema, and a schema library that you'd like to use with your types, there's no reason why you couldn't use that library along with SCA. > Also, type enforcement is not necessarily a disadvantage (admittedly > slower though) > I'm not sure if you're talking about validating the data exchanged with SCA components (which could be done with a validating proxy) or about generating static code from schema type definitions, but both approaches should work nicely along M3 or trunk (for the latter you'd need a generator like scagen on top of the runtime invocation mechanism.) > > Many thx again + regards, > the > > On Wed, 2013-01-02 at 23:49 -0800, Jean-Sebastien Delfino wrote: > > On Sat, Dec 29, 2012 at 6:20 PM, Jean-Sebastien Delfino > > <jsdelfino@apache.org> wrote: > > Hi all, > > > > > > I had a few more offline Q&A exchanges with Thomas, and > > thought it'd be useful to share a summary here: > > > > > > Q: In the C++ trunk, is DataObject now replaced by > > tuscany::value and tuscany::list? > > > > > > A: Yes > > > > > > > > > > BTW I just committed a number of changes I made over the holidays, > > including some improvements to tuscany::value and tuscany::list, in > > particular to work with lists, nested lists and trees of key/value > > pairs (aka associations) as well as some minor improvements to handle > > comparisons of floating point number values. > > > > > > - Jean-Sebastien > > > >
Hello JS, now, I did some more reading etc and believe now that I mostly understand what's going on :-) The main missing pieces were these (correct? Possibly my terminology is a bit fuzzy :-): Q: When are SDOs used (in SCA M3) and when not? A: If an interface of a service uses complex types as in/out params or return value, otherwise simple types (like int, bool, string) are used. Complex types (i.e. class instances) an XSD are passed in/out as SDO Q: Is there some kind of request routing? A: Local calls are resolved during OS-loader-time. One component calling another is written as regular C++ code which results in compiled code as unresolved reference that must be satisfied during runtime by the target component which in turn must be loaded as shared library Q: What is the purpose of composite files with pure C++ modules? A: If a composite consists only of local components all calls are resolved by the OS loader. In that case basically the composite definition file mainly states which interfaces are in which shared lib and in which order are the libs to be loaded. Q: How are remote request handled? A: Remote interfaces are described using WSDL, which must be processed using the tool scagen to generate a "ServiceWrapper" and a "ServiceProxy" that act as client (proxy) and server (wrapper) stubs. However, some things are still unclear: Q: If there is nothing like request routing, how does the "wiring" work if the calls are actually hardcoded? Besides of these questions a few non-technical ones: Q: The trunk code stream looks to me like a complete re-write. With even the component interfaces changing and nobody complaining I guess that there is nobody actually really using Tuscany SCA C++? Q: Besides of people using it, is there anybody besides you working on it? Q: To which extent are both the M3 and trunk versions "stable"? M3 probably in the sense that nobody works on it anymore but is it mostly complete/usable? Q: What about interoperability with Tuscany Java? I suppose both M3 and trunk are OK as long as the binding is the same (and on the wire it is XML or whatever anyway). Which common binding types exist? Generally I have to admit that I liked the old implementation more, though this maybe caused by the new language features in trunk I'm not familiar with yet. Q: With the new value/list types, if there is no relation with XSD anymore, can you also query information about object types, e.g. which properties a class shall have? This is probably not needed in the SCA code, but maybe in custom extensions ... Also, type enforcement is not necessarily a disadvantage (admittedly slower though) Many thx again + regards, tge On Wed, 2013-01-02 at 23:49 -0800, Jean-Sebastien Delfino wrote: > On Sat, Dec 29, 2012 at 6:20 PM, Jean-Sebastien Delfino > <jsdelfino@apache.org> wrote: > Hi all, > > > I had a few more offline Q&A exchanges with Thomas, and > thought it'd be useful to share a summary here: > > > Q: In the C++ trunk, is DataObject now replaced by > tuscany::value and tuscany::list? > > > A: Yes > > > > > BTW I just committed a number of changes I made over the holidays, > including some improvements to tuscany::value and tuscany::list, in > particular to work with lists, nested lists and trees of key/value > pairs (aka associations) as well as some minor improvements to handle > comparisons of floating point number values. > > > - Jean-Sebastien
On Sat, Dec 29, 2012 at 6:20 PM, Jean-Sebastien Delfino < jsdelfino@apache.org> wrote: > Hi all, > > > I had a few more offline Q&A exchanges with Thomas, and thought it'd be > useful to share a summary here: > > > Q: In the C++ trunk, is DataObject now replaced by tuscany::value > and tuscany::list? > > > A: Yes > > > BTW I just committed a number of changes I made over the holidays, including some improvements to tuscany::value and tuscany::list, in particular to work with lists, nested lists and trees of key/value pairs (aka associations) as well as some minor improvements to handle comparisons of floating point number values. - Jean-Sebastien
Hi all,
I had a few more offline Q&A exchanges with Thomas, and thought it'd be
useful to share a summary here:
Q: In the C++ trunk, is DataObject now replaced by tuscany::value
and tuscany::list?
A: Yes
Q: Why are most files in kernel/ C++ header files?
A: They’re C++ templates that you can just include, similar to what other
C++ frameworks like boost do for example.
Q: In M3 a C++ component implementation looked like this:
virtual commonj::sdo::DataObjectPtr /*AccountReport*/
getAccountReport(const string customerID) {
...
}
What does a C++ component implementation look like with the code in trunk?
A: With trunk, a C++ component implementation must contain this function:
const value apply(const list<value>& params) {
// implement your own dispatch code here, for example
// if first element of params is “getAccountReport” then
// call your own getAccountReport function, which could look like
// const value getAccountReport(const value customerID)
}
The apply() function is a component invocation dispatch mechanism. It
shouldn’t be too difficult to provide a tool to generate the body of
apply() from a WSDL+XSD to lift the programming model to a level of
abstraction close to M3.
I was initially planning to do that but then found that writing apply() by
hand was good enough for me. I'm not sure about the value of requiring an
app developer to write a WSDL+XSD, use a tool to generate code, link with
that code, understand the additional moving parts and data conversion etc,
just to avoid having to write that apply() function... but if somebody
wants to do it, I can try to help integrate that support.
Q: Is the runtime implemented as Apache HTTPD modules?
A: Yes, the runtime plugs into Apache HTTPD as a set of HTTPD modules but
it should be possible to integrate with other servers too.
Q: Are C++ component implementations packaged as dynamic libraries?
A: Yes, the runtime also supports other component implementation
technologies and languages incl. Python, OpenCL C99 (for GPU programming),
Java (experimental) and a subset of MIT Scheme (useful for self-contained
testing).
Q: Which communication protocols are supported?
A: REST Web services using XML, ATOM, RSS or JSON over HTTP, and JSON-RPC.
Communication with SOAP services is supported using a configurable SCA
component wrapping Axis2/C in components/webservice/.
Q: Which versions of SCA are implemented?
M3 implements a subset of the OSOA (pre-OASIS) SCA assembly spec and a
subset of the corresponding SCA C++ component implementation spec.
Trunk implements a subset of the OASIS SCA assembly spec. The C++ component
implementation model is different from the spec, but like I said above it
shouldn't be too difficult to generate C++ implementations as per the spec
on top of the current dispatch mechanism.
Hope that helps.
- Jean-Sebastien
On Wed, Dec 19, 2012 at 1:00 PM, Thomas Gentsch <tg@e-tge.de> wrote:
>
> Hi JS,
>
> I'm still looking through the docs, code, etc. I can find.
>
> One thing I discovered: it does not look to me as if SDO support has
> been removed from Java SCA, at least I found some related activity in
> 2011:
>
> http://www.mail-archive.com/user@tuscany.apache.org/msg03435.html
>
> http://www.mail-archive.com/dev@tuscany.apache.org/msg17116.html
>
> (the latter is quite funny because I actually submitted this against C++
> but seems as if the same problem occurred with Java? :-)
>
> More later ... :-)
> Rgds,
> tge
>
> On Thu, 2012-12-06 at 01:04 -0800, Jean-Sebastien Delfino wrote:
> > On Fri, Nov 30, 2012 at 9:43 AM, Thomas Gentsch <tg@e-tge.de> wrote:
> >
> > OK, many thx for this info!
> >
> > Regarding SDO - yes, I noticed that there was not a lot of
> > activity
> > during the last years.
> > Hello out there: Is there anybody else still using this?
> >
> > Rgd SDO as SCA-internal data-flow mechanism - what is being
> > used now?
> > I know about libxml2 (actually its being used in SCA/SDO :-),
> > nothing
> > yet about JSON, will read.
> >
> >
> > Hi Thomas,
> >
> >
> > Here's a short overview of what's used now.
> >
> >
> > Data read/write functions are provided for XML (using Libxml2 [1]),
> > JSON (using Mozilla SpiderMonkey but I've started to migrate to
> > Jansson [2]), and Lisp/Scheme S-expressions [3].
> >
> >
> > Here's how to read XML in a C++ component:
> > <customer
> > age="21"><name>johndoe</name><phone>(650)123-4567</phone><phone>
> (415)765-4321</phone></customer>
> >
> >
> > // A list of strings containing the above XML doc, obtained from an
> > input stream for example
> > const list<string> ls = ...;
> >
> >
> > // Read the XML doc (the failable<...> result type helps encapsulate
> > error handling)
> > // See below for a description of the 'value' data type
> > const failable<value> fe = xml::readElements(ls);
> >
> >
> > // Assuming no failure, get and print the result
> > const value e = content(fe);
> > cout << e << endl;
> >
> >
> > The result is a list like follows (using the S-expression syntax here
> > for conciseness: element, customer, attribute, age are symbols, 21 is
> > a number, "johndoe" is a string, (x y) is a list of x, y):
> > ((element customer (attribute age "21") (element name "johndoe")
> > (element phone "(650)123-4567") (element phone "(415)765-4321")))
> >
> >
> > The runtime is schema-less. You do not need an XML schema to
> > read/write any XML.
> >
> >
> > If you don't care about the XML element vs attribute representation
> > you can strip it like this:
> > const value v = elementsToValues(e);
> > to get this:
> > ((customer (@age "21") (name "johndoe") (phone ("(650)123-4567"
> > "(415)765-4321"))))
> >
> >
> > Note the @age attribute name, which follows the Badgerfish [4]
> > convention often used to name XML attributes in JSON documents for
> > example.
> >
> > The same data can be constructed and represented in the various
> > programming languages supported by the runtime, as follows:
> >
> >
> > C++:
> > list<value>(list<value>("customer", list<value>("@age", 21),
> > list<value>("name", string("johndoe")), list<value>("phone",
> > list<value>("(650)123-4567", "(415)765-4321"))));
> > using the following C++ types:
> > - string, similar to std::string but lighter and faster for small
> > strings, with builtin conversions from/to native char*;
> > - list<T>, a lightweight list/lazy-list type with useful
> > Lisp/Scheme-like [5] functions incl. cons, car, cdr, map, filter,
> > reduce, assoc, etc;
> > - lambda<R(P...)>, a function type similar to std::function but
> > lighter and faster;
> > - value, a dynamic value type (type can be number, boolean, symbol,
> > string, list<value>, lambda<value(list<value>)>, value*) with
builtin
> > conversions from/to native double, bool, char*, C++ lambdas and
> > pointers.
> >
> >
> > Python:
> > ((customer, ("'@age" 21), ("'name", "johndoe") (phone,
> > ("(650)123-4567" "(415)765-4321"))),)
> > using Python tuples [6] and native Python data types for strings,
> > numbers and booleans.
> >
> >
> > JavaScript / JSON:
> >
> {"customer":{"@age":"21","name":"johndoe","phone":["(650)123-4567","(415)765-4321"]}}
> > using JSON arrays and native Javascript types.
> >
> >
> > Scheme:
> > ((customer (@age "21") (name "johndoe") (phone ("(650)123-4567"
> > "(415)765-4321"))))
> > just an S-expression.
> >
> >
> > Java (there's experimental support for running Java components on the
> > C++ runtime):
> > list(list("'customer", list("'@age", 21), list("'name", "johndoe"),
> > list("'phone", list("(650)123-4567", "(415)765-4321"))));
> > using java.lang.Iterable [7] for lists and native Java data types for
> > strings, numbers and booleans (the list(...) function is a static
> > 'builder' function returning a java.lang.Iterable<?>.)
> >
> >
> > To summarize: fast and schemaless support for XML, JSON and
> > S-expressions, with lightweight representation using lists and simple
> > types in the supported programming languages.
> >
> >
> > Hope that helps.
> >
> >
> > [1] http://www.xmlsoft.org
> > [2] http://www.digip.org/jansson/
> > [3] http://en.wikipedia.org/wiki/S-expression
> > [4] http://badgerfish.ning.com
> > [5]
> http://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Lists.html#Lists
> > [6]
> http://docs.python.org/2/tutorial/datastructures.html#tuples-and-sequences
> > [7] http://docs.oracle.com/javase/6/docs/api/java/lang/Iterable.html
> >
> >
> > - Jean-Sebastien
>
>
>
Hi Nguyen, Tuscany is using JAXB as the databinding to map from Java to WSDL/XSD, and you've got a couple dimensions of complexity here... For one you're trying to use a generic 'java.lang.Object' type, and you're also using Map(s) which don't have an obvious mapping to XSD. I'd suggest researching the topic of JAXB's @XmlAdapter, which allows you to add your own custom marshalling/unmarshalling logic to some code like the Tuscany runtime's binding.ws which uses JAXB as a databinding. Just searching I hit on these articles, and there is the Javadoc as well: http://blog.bdoughan.com/2010/07/xmladapter-jaxbs-secret-weapon.html http://javaevangelist.blogspot.com/2011/12/java-tip-of-day-generic-jaxb-map-v.html The @XmlAdapter will definitely help you deal with the Map(s)... the way you might deal with java.lang.Object as the parameter type might depend on how much you know about the types that will be used (e.g. is it a few well known types but without a common superclass or are you trying to accept an indefinite set of types?). In taking this route, you might find it helpful to try to do some "meet in the middle" thinking... e.g. try to figure out what the XML would look like, define a schema, and then use @XmlAdapter to adapt this to your Java interface. Hope that helps, Scott On Thu, Dec 6, 2012 at 5:12 AM, makiet <Binhnt22@viettel.com.vn> wrote: > Hi, > > > > I have an interface with some functions return List<HashMap<String, Object>> > and Map<ArrayList<Object>> > > > > When I make the interface exposed as a service with binding.ws, the > generated wsdl contains a complex type HashMap or ArrayList without content > > > > Ie: <xs:complexType name="hashMap"> > > <xs:complexContent> > > <xs:extension base="tns:abstractMap"> > > <xs:sequence> > > </xs:sequence> > > </xs:extension> > > </xs:complexContent> > > </xs:complexType> > > <xs:complexType abstract="true" name="abstractMap"> > > <xs:sequence> > > > > Therefore, I have no way to get the expected result. May anyone help me out? > > > > Best regards, > > ------------------------------------------------------------------ > > Binh, Nguyen Thanh > > Software Architecture > > Product Department - BU BSS, Software Center, Viettel Group > >
Hi JS,
I'm still looking through the docs, code, etc. I can find.
One thing I discovered: it does not look to me as if SDO support has
been removed from Java SCA, at least I found some related activity in
2011:
http://www.mail-archive.com/user@tuscany.apache.org/msg03435.html
http://www.mail-archive.com/dev@tuscany.apache.org/msg17116.html
(the latter is quite funny because I actually submitted this against C++
but seems as if the same problem occurred with Java? :-)
More later ... :-)
Rgds,
tge
On Thu, 2012-12-06 at 01:04 -0800, Jean-Sebastien Delfino wrote:
> On Fri, Nov 30, 2012 at 9:43 AM, Thomas Gentsch <tg@e-tge.de> wrote:
>
> OK, many thx for this info!
>
> Regarding SDO - yes, I noticed that there was not a lot of
> activity
> during the last years.
> Hello out there: Is there anybody else still using this?
>
> Rgd SDO as SCA-internal data-flow mechanism - what is being
> used now?
> I know about libxml2 (actually its being used in SCA/SDO :-),
> nothing
> yet about JSON, will read.
>
>
> Hi Thomas,
>
>
> Here's a short overview of what's used now.
>
>
> Data read/write functions are provided for XML (using Libxml2 [1]),
> JSON (using Mozilla SpiderMonkey but I've started to migrate to
> Jansson [2]), and Lisp/Scheme S-expressions [3].
>
>
> Here's how to read XML in a C++ component:
> <customer
> age="21"><name>johndoe</name><phone>(650)123-4567</phone><phone>(415)765-4321</phone></customer>
>
>
> // A list of strings containing the above XML doc, obtained from an
> input stream for example
> const list<string> ls = ...;
>
>
> // Read the XML doc (the failable<...> result type helps encapsulate
> error handling)
> // See below for a description of the 'value' data type
> const failable<value> fe = xml::readElements(ls);
>
>
> // Assuming no failure, get and print the result
> const value e = content(fe);
> cout << e << endl;
>
>
> The result is a list like follows (using the S-expression syntax here
> for conciseness: element, customer, attribute, age are symbols, 21 is
> a number, "johndoe" is a string, (x y) is a list of x, y):
> ((element customer (attribute age "21") (element name "johndoe")
> (element phone "(650)123-4567") (element phone "(415)765-4321")))
>
>
> The runtime is schema-less. You do not need an XML schema to
> read/write any XML.
>
>
> If you don't care about the XML element vs attribute representation
> you can strip it like this:
> const value v = elementsToValues(e);
> to get this:
> ((customer (@age "21") (name "johndoe") (phone ("(650)123-4567"
> "(415)765-4321"))))
>
>
> Note the @age attribute name, which follows the Badgerfish [4]
> convention often used to name XML attributes in JSON documents for
> example.
>
> The same data can be constructed and represented in the various
> programming languages supported by the runtime, as follows:
>
>
> C++:
> list<value>(list<value>("customer", list<value>("@age", 21),
> list<value>("name", string("johndoe")), list<value>("phone",
> list<value>("(650)123-4567", "(415)765-4321"))));
> using the following C++ types:
> - string, similar to std::string but lighter and faster for small
> strings, with builtin conversions from/to native char*;
> - list<T>, a lightweight list/lazy-list type with useful
> Lisp/Scheme-like [5] functions incl. cons, car, cdr, map, filter,
> reduce, assoc, etc;
> - lambda<R(P...)>, a function type similar to std::function but
> lighter and faster;
> - value, a dynamic value type (type can be number, boolean, symbol,
> string, list<value>, lambda<value(list<value>)>, value*) with builtin
> conversions from/to native double, bool, char*, C++ lambdas and
> pointers.
>
>
> Python:
> ((customer, ("'@age" 21), ("'name", "johndoe") (phone,
> ("(650)123-4567" "(415)765-4321"))),)
> using Python tuples [6] and native Python data types for strings,
> numbers and booleans.
>
>
> JavaScript / JSON:
> {"customer":{"@age":"21","name":"johndoe","phone":["(650)123-4567","(415)765-4321"]}}
> using JSON arrays and native Javascript types.
>
>
> Scheme:
> ((customer (@age "21") (name "johndoe") (phone ("(650)123-4567"
> "(415)765-4321"))))
> just an S-expression.
>
>
> Java (there's experimental support for running Java components on the
> C++ runtime):
> list(list("'customer", list("'@age", 21), list("'name", "johndoe"),
> list("'phone", list("(650)123-4567", "(415)765-4321"))));
> using java.lang.Iterable [7] for lists and native Java data types for
> strings, numbers and booleans (the list(...) function is a static
> 'builder' function returning a java.lang.Iterable<?>.)
>
>
> To summarize: fast and schemaless support for XML, JSON and
> S-expressions, with lightweight representation using lists and simple
> types in the supported programming languages.
>
>
> Hope that helps.
>
>
> [1] http://www.xmlsoft.org
> [2] http://www.digip.org/jansson/
> [3] http://en.wikipedia.org/wiki/S-expression
> [4] http://badgerfish.ning.com
> [5] http://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Lists.html#Lists
> [6] http://docs.python.org/2/tutorial/datastructures.html#tuples-and-sequences
> [7] http://docs.oracle.com/javase/6/docs/api/java/lang/Iterable.html
>
>
> - Jean-Sebastien
I am out of the office until 12/20/2012. I will be out of office starting Wednesday (12/05) through Thursday (12/20), returning to work on Friday (12/21). During this absence, I may not have network connectivity. For those items that cannot wait until my return, please contact the following : Henry Aguillon ( Henry Aguillon/Dallas/IBM ) Regina Manuel ( Regina Manuel/Greensboro/IBM ) Note: This is an automated response to your message "Bringup build in mac os java7 environment, was Fwd: svn commit: r1418376 - in /tuscany/sca-java-2.x/trunk: modules/core-spi/pom.xml pom.xml" sent on 07/12/2012 21:50:16. This is the only notification you will receive while this person is away.
Just finished making some minor changes on the poms (mainly around
tools.jar and ant tasks related dependencies) to bring up the build in mac
os environment with Oracle JDK 7 (1.7.0_07). I also tried it in mac os and
unix with java 6, and things seems to be working fine, but don't hesitate
to reach out if you find issues.
Thanks
---------- Forwarded message ----------
From: <lresende@apache.org>
Date: Fri, Dec 7, 2012 at 8:14 AM
Subject: svn commit: r1418376 - in /tuscany/sca-java-2.x/trunk:
modules/core-spi/pom.xml pom.xml
To: commits@tuscany.apache.org
Author: lresende
Date: Fri Dec 7 16:14:49 2012
New Revision: 1418376
URL: http://svn.apache.org/viewvc?rev=1418376&view=rev
Log:
Bringup build in mac os java7 environment
Modified:
tuscany/sca-java-2.x/trunk/modules/core-spi/pom.xml
tuscany/sca-java-2.x/trunk/pom.xml
Modified: tuscany/sca-java-2.x/trunk/modules/core-spi/pom.xml
URL:
http://svn.apache.org/viewvc/tuscany/sca-java-2.x/trunk/modules/core-spi/pom.xml?rev=1418376&r1=1418375&r2=1418376&view=diff
==============================================================================
--- tuscany/sca-java-2.x/trunk/modules/core-spi/pom.xml (original)
+++ tuscany/sca-java-2.x/trunk/modules/core-spi/pom.xml Fri Dec 7 16:14:49
2012
@@ -80,7 +80,6 @@
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
- <version>1.6</version>
<executions>
<execution>
<id>process-resources</id>
Modified: tuscany/sca-java-2.x/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/tuscany/sca-java-2.x/trunk/pom.xml?rev=1418376&r1=1418375&r2=1418376&view=diff
==============================================================================
--- tuscany/sca-java-2.x/trunk/pom.xml (original)
+++ tuscany/sca-java-2.x/trunk/pom.xml Fri Dec 7 16:14:49 2012
@@ -145,6 +145,7 @@
<os>
<family>mac</family>
</os>
+ <jdk>[1.3,1.6)</jdk>
</activation>
<properties>
<tools.jar>${java.home}/../Classes/classes.jar</tools.jar>
@@ -826,7 +827,7 @@ org.apache.tuscany.sca.assembly:org.apac
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
- <version>1.3</version>
+ <version>1.7</version>
<dependencies>
<dependency>
@@ -835,6 +836,7 @@ org.apache.tuscany.sca.assembly:org.apac
<version>1.7.1</version>
</dependency>
<!-- this JDk dependency is a workaround for Maven
bug - http://jira.codehaus.org/browse/MNG-1323 -->
+ <!--
<dependency>
<groupId>sun.jdk</groupId>
<artifactId>tools</artifactId>
@@ -843,6 +845,7 @@ org.apache.tuscany.sca.assembly:org.apac
<systemPath>${tools.jar}</systemPath>
<optional>true</optional>
</dependency>
+ -->
</dependencies>
</plugin>
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Hi,
I have an interface with some functions return List<HashMap<String, Object>>
and Map<ArrayList<Object>>
When I make the interface exposed as a service with binding.ws, the
generated wsdl contains a complex type HashMap or ArrayList without content
Ie: <xs:complexType name="hashMap">
<xs:complexContent>
<xs:extension base="tns:abstractMap">
<xs:sequence>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType abstract="true" name="abstractMap">
<xs:sequence>
Therefore, I have no way to get the expected result. May anyone help me out?
Best regards,
------------------------------------------------------------------
Binh, Nguyen Thanh
Software Architecture
Product Department - BU BSS, Software Center, Viettel Group
On Fri, Nov 30, 2012 at 9:43 AM, Thomas Gentsch <tg@e-tge.de> wrote:
>
> OK, many thx for this info!
>
> Regarding SDO - yes, I noticed that there was not a lot of activity
> during the last years.
> Hello out there: Is there anybody else still using this?
>
> Rgd SDO as SCA-internal data-flow mechanism - what is being used now?
> I know about libxml2 (actually its being used in SCA/SDO :-), nothing
> yet about JSON, will read.
>
Hi Thomas,
Here's a short overview of what's used now.
Data read/write functions are provided for XML (using Libxml2 [1]), JSON
(using Mozilla SpiderMonkey but I've started to migrate to Jansson [2]),
and Lisp/Scheme S-expressions [3].
Here's how to read XML in a C++ component:
<customer
age="21"><name>johndoe</name><phone>(650)123-4567</phone><phone>(415)765-4321</phone></customer>
// A list of strings containing the above XML doc, obtained from an input
stream for example
const list<string> ls = ...;
// Read the XML doc (the failable<...> result type helps encapsulate error
handling)
// See below for a description of the 'value' data type
const failable<value> fe = xml::readElements(ls);
// Assuming no failure, get and print the result
const value e = content(fe);
cout << e << endl;
The result is a list like follows (using the S-expression syntax here for
conciseness: element, customer, attribute, age are symbols, 21 is a number,
"johndoe" is a string, (x y) is a list of x, y):
((element customer (attribute age "21") (element name "johndoe") (element
phone "(650)123-4567") (element phone "(415)765-4321")))
The runtime is schema-less. You do not need an XML schema to read/write any
XML.
If you don't care about the XML element vs attribute representation you can
strip it like this:
const value v = elementsToValues(e);
to get this:
((customer (@age "21") (name "johndoe") (phone ("(650)123-4567"
"(415)765-4321"))))
Note the @age attribute name, which follows the Badgerfish [4] convention
often used to name XML attributes in JSON documents for example.
The same data can be constructed and represented in the various programming
languages supported by the runtime, as follows:
C++:
list<value>(list<value>("customer", list<value>("@age", 21),
list<value>("name", string("johndoe")), list<value>("phone",
list<value>("(650)123-4567", "(415)765-4321"))));
using the following C++ types:
- string, similar to std::string but lighter and faster for small strings,
with builtin conversions from/to native char*;
- list<T>, a lightweight list/lazy-list type with useful Lisp/Scheme-like
[5] functions incl. cons, car, cdr, map, filter, reduce, assoc, etc;
- lambda<R(P...)>, a function type similar to std::function but lighter and
faster;
- value, a dynamic value type (type can be number, boolean, symbol, string,
list<value>, lambda<value(list<value>)>, value*) with builtin conversions
from/to native double, bool, char*, C++ lambdas and pointers.
Python:
((customer, ("'@age" 21), ("'name", "johndoe") (phone, ("(650)123-4567"
"(415)765-4321"))),)
using Python tuples [6] and native Python data types for strings, numbers
and booleans.
JavaScript / JSON:
{"customer":{"@age":"21","name":"johndoe","phone":["(650)123-4567","(415)765-4321"]}}
using JSON arrays and native Javascript types.
Scheme:
((customer (@age "21") (name "johndoe") (phone ("(650)123-4567"
"(415)765-4321"))))
just an S-expression.
Java (there's experimental support for running Java components on the C++
runtime):
list(list("'customer", list("'@age", 21), list("'name", "johndoe"),
list("'phone", list("(650)123-4567", "(415)765-4321"))));
using java.lang.Iterable [7] for lists and native Java data types for
strings, numbers and booleans (the list(...) function is a static 'builder'
function returning a java.lang.Iterable<?>.)
To summarize: fast and schemaless support for XML, JSON and S-expressions,
with lightweight representation using lists and simple types in the
supported programming languages.
Hope that helps.
[1] http://www.xmlsoft.org
[2] http://www.digip.org/jansson/
[3] http://en.wikipedia.org/wiki/S-expression
[4] http://badgerfish.ning.com
[5]
http://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Lists.html#Lists
[6]
http://docs.python.org/2/tutorial/datastructures.html#tuples-and-sequences
[7] http://docs.oracle.com/javase/6/docs/api/java/lang/Iterable.html
- Jean-Sebastien
OK, many thx for this info! Regarding SDO - yes, I noticed that there was not a lot of activity during the last years. Hello out there: Is there anybody else still using this? Rgd SDO as SCA-internal data-flow mechanism - what is being used now? I know about libxml2 (actually its being used in SCA/SDO :-), nothing yet about JSON, will read. Rgd updating SDO: If nobody else cares, then I'm happy with it for now, so lets let it rest in peace ... (except that I'll have to deal with it all by myself if I find any problems :-) Rgds + nice WE, tge On Mon, 2012-11-26 at 23:13 -0800, Jean-Sebastien Delfino wrote: > On Sun, Nov 25, 2012 at 1:31 PM, Thomas Gentsch <tg@e-tge.de> wrote: > On Sun, 2012-11-25 at 10:38 -0800, Jean-Sebastien Delfino > wrote: > > On Fri, Nov 23, 2012 at 9:02 AM, Thomas Gentsch > <tg@e-tge.de> wrote: > ... > > Great! Papers from the C++11 standard work groups are > available on > > open-std.org there [1]. The final ISO standard is not free > but the > > last draft [2] is free. If you just want a high level > overview > > there's one on Wikipedia [3]. Hope that helps. > > > Shortly looked through it, definitely interesting. Of course > that makes > me worry a bit how far compilers support this already ... > particularly > as partially maybe (as in our case) older OS versions are to > be > supported. > > > On Linux, GCC 4.3 and later, see [5]. On MacOS, CLang 3.1 and later, > see [6]. > Of course you don't need to worry about it if you're using SDO as I'm > not touching the M3 SDO code anyway :). > > ... > > > > > I quickly looked into Jira and found at least these: > > https://issues.apache.org/jira/browse/TUSCANY-3841 > https://issues.apache.org/jira/browse/TUSCANY-3715 > https://issues.apache.org/jira/browse/TUSCANY-3597 > > https://issues.apache.org/jira/browse/TUSCANY-1552 > > > > > Ah, I now realize that you're using SDO, and I was only looking for > SCA JIRAs. > > > > > > The C++ trunk has already gone through some refactoring and > quite a > > few changes over time since M3... There's no SDO anymore > > > Oh!!! Actually I always believed Tuscany is mainly about SDO! > Well, then I have to correct myself - we are using Tuscany C++ > SDO. I > wasn't aware of this at all (haven't looked into it for a > while though) > > > Tus-SCA-ny is mainly about SCA [7]. SCA is a programming model for > building apps with components that provide or use services, and > initially used SDO to represent (mostly XML) data flowing through > these services. > > > > > (like the Java trunk, which I believe dropped SDO as well), > the > > composite files use the new SCDL from OASIS, the runtime > integrates > > with Apache HTTPD, etc. There's still an integration with > Axis2C but > > I've not looked at it for a very long time. > > > > > > So, if you're still using SDO you'll probably want to stick > to the M3 > > level, but I can help apply your patch to a maintenance > branch off M3 > > at some point if that helps. > > > Well, if SDO is dead anyway then there will not be any release > anymore I > suppose, so maybe no need to bother. > > > ... > > > I'm not sure about the state of SDO. I've not seen any activity on it > for some time now, and I'm not planning to do anything with SDO at > this point, but can try to help on my spare time if you or others are > interested in maintaining or evolving the SDO code. > > > > > OK, then I should look into the alternatives? Is there any > replacement? > Many thx + regards, > > > > I personally like libxml2 [8] for XML and jansson [9] for JSON, and > there's several other good XML and JSON libraries out there too, but > if SDO works for you and you have a good handle on that code (and it > looks like it since you were able to create some good patches), then > why change? :) > > > > > [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/ > > [2] > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf > > [3] http://en.wikipedia.org/wiki/C%2B%2B11 > > [4] https://issues.apache.org/jira/browse/TUSCANY-3598 > > > [5] http://gcc.gnu.org/projects/cxx0x.html > [6] http://clang.llvm.org/cxx_status.html > [7] http://www.oasis-opencsa.org/committees > [8] http://www.xmlsoft.org > [9] http://www.digip.org/jansson/ > >
Sebastian Millies created TUSCANY-4074:
------------------------------------------
Summary: Registering a ContributionClassLoaderProvider has unpredictable result
Key: TUSCANY-4074
URL: https://issues.apache.org/jira/browse/TUSCANY-4074
Project: Tuscany
Issue Type: Bug
Components: Java SCA Misc Implementation Extensions
Affects Versions: Java-SCA-1.6.2
Environment: Oracle Java 7 on Windows 7 (64bit)
Reporter: Sebastian Millies
Priority: Minor
When one defines a class loader provider and registers it in the DefaultClassLoaderProviderExtensionPoint,
it is unpredictable which class loader will actually be used. Tuscany will look up ALL class
loader providers, then put the ServiceDeclaration's in a HashSet. The DefaultClassLoaderProviderExtensionPoint
will iterate over the set, and keep one provider per contribution type, whichever one it happens
to find last. It would be better if the result could be predicted, either on the basis of
the order in which the service declarations are found on the classpath (for that, the Set
would probably have to be changed to a List), or on the basis of some attribute in the service
declaration itself.
cf JIRA 4073 for an example and more technical detail.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/TUSCANY-4073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Millies updated TUSCANY-4073:
---------------------------------------
Attachment: example-code.zip
Example class loader, class loader provider, extension point and services files
> Change classloader to use different versions of third-party libraries than the Tuscany
runtime
> ----------------------------------------------------------------------------------------------
>
> Key: TUSCANY-4073
> URL: https://issues.apache.org/jira/browse/TUSCANY-4073
> Project: Tuscany
> Issue Type: Improvement
> Components: SCA Java Runtime
> Affects Versions: Java-SCA-1.6.2
> Environment: Java 7 on Windows 7 (64bit)
> Reporter: Sebastian Millies
> Fix For: Java-SCA-1.6.2
>
> Attachments: classloader.patch, example-code.zip
>
>
> I want to set up my contributions, so that they can use
> different versions of third-party libraries than the Tuscany runtime. My original example
> was using recent versions of EMF (hence the subject line), another example is using
> Tuscany with an Apache Solr 4.0 backend, which requires different Apache Http Components.
> The standard recommendation is [1], but I have had great trouble to get that to work.
(The
> reasons have to do with the use of SDOs in the application in question.)
> I have therefore decided to try the opposite approach of including any different versions
of components
> used by Tuscany in nested jars in the contribution itself. Nested jars in a zip contribution
get added into
> the contribution classpath.
> Here I am working under the assumption that the SCA contribution classloader would work
> somewhat like a webapp class loader in that it would not follow the delegation model,
> but would look for classes in the following order
> 1) inside the contribution
> 2) in the imports
> 3) in the parent classloader
> With this behavior, everything goes well. For example, I can make calls to Apache Solr
through
> the solr-solrj-4.0.0.jar and its dependents, including httpclient-4.1.3.jar and httpcore-4.1.4.jar,
> without impacting HTTP calls made by Tuscany-generated proxies elsewhere.
> Here's the snag: As it turned out, org.apache.tuscany.sca.contribution.java.impl.ContributionClassLoader
DID
> NOT work the way I expected, but rather looked in the parent classloader first, only
then inside the contribution.
> I had to change the coding (in module contribution-java) and the associated test. A patch
is attached.
> Would my change break anything, perhaps with respect to OSGi? Is there anything in the
SCA spec that mandates a
> certain class loading behavior? I do feel that the alternative behavior is more natural
than the one that is currently
> implemented. (There a very few resources on Tuscany classloading, and e. g. [2] does
not seem to mention
> this particular issue.)
> Unfortunately, I cannot get all the Tuscany 1.6 tests to compile and run with maven.
> Please, would anyone be willing to see if Tuscany 1.6 with my patch applied would still
pass all current tests?
> (unless my proposal is obviously wrong for other reasons, of course)
> Best,
> Sebastian
> [1] http://mail-archives.apache.org/mod_mbox/tuscany-user/201006.mbox/%3C4C164DD3.8090405@apache.org%3E
> [2] https://cwiki.apache.org/TUSCANYWIKI/classloading.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/TUSCANY-4073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506620#comment-13506620
]
Sebastian Millies commented on TUSCANY-4073:
--------------------------------------------
I have solution of sorts, and will attempt to summarize it here, working in some of Simon's
comments as well.
To re-iterate the problem: I want to set up my contributions, so that they can use
different versions of third-party libraries than the Tuscany 1.6 runtime. My original example
was using recent versions of EMF, another example is using Tuscany with an Apache Solr
4.0 backend, which requires different Apache Http Components.
Some approaches have turned out to be infeasible:
1) patching the built-in ContributionClassLoader to use a parent-last strategy leads to several
errors in Tuscany tests and samples. The fault may lie with the tests being based on wrong
assumptions
and bad-practices, but to correct them all is not a practical option. (Besides, it would be
contrary to the
OASIS specs.)
2) The approach outlined in [1] is quite complicated, and I have not been able to get it to
work.
Instead, I have chosen to exploit the Tuscany extension mechanism in order to provide a class
loader
of my choice as the contribution class loader. This solution will work when one follows the
recommended
best practice of keeping contribution classes separate from the system classpath. The new
class loader is
the delegation parent of the contribution class loader.
The approach has two limitations:
1) the contributions shouldn't pass any references to these overriding external libraries
to the Tuscany
runtime (e. g. in the form of service parameters)
2) the extension mechanism is a applied globally rather than to specific contributions.
(Both these points do not worry me. With regard to the second one, the overriding classes
could be
included in a nested jar in the contribution itself, so even if the mechanism is global, any
overriding
could be kept strictly local, if desired. After all, it's my own class loader doing the work.)
Finally, here's how it really works, without requiring any code changes in Tuscany itself.
1) Define a class loader, e. g. EndorsedLibsClassLoader extends URLClassLoader
2) Define a class loader provider, e. g. EndorsedLibsClassLoaderProvider implements ContributionClassLoaderProvider.
This is the core of the solution. We inject the new class loader between the standard contribution
class loader and
the app class loader:
public ClassLoader getClassLoader( Contribution contribution, ClassLoader parent )
{
EndorsedLibsClassLoader endorsedLoader = new EndorsedLibsClassLoader( parent );
return new ContributionClassLoader( contribution, endorsedLoader );
}
3) Define a class loader provider extension point, e. g.
PrioritizedContributionClassLoaderProviderExtensionPoint implements ContributionClassloaderProviderExtensionPoint
The reason for this is that Tuscany will look up ALL class loader providers, not just your
own, then put them in
a HashSet, iterate over the set, and keep one provider per contribution type, whichever one
it happens to find
last (clearly a bug, in my view). The PrioritizedContributionClassLoaderProviderExtensionPoint
allows
class loader providers to have a "priority" attribute, and keeps the one with the highest
priority.
4) Register the provider and the provider extension point in two files in a META-INF/services
directory. The file names
are:
org.apache.tuscany.sca.contribution.java.ContributionClassLoaderProvider
org.apache.tuscany.sca.contribution.java.ContributionClassloaderProviderExtensionPoint
The latter just contains the FQCN of the extension point implementation. The former contains
the FQCN of the class
loader provider, along with its attributes, e. g. like this:
example.contribution.java.EndorsedLibsClassLoaderProvider;type=application/x-compressed,priority=10
5) Put the META-INF directory on the system classpath. But not just anywhere: It must come
BEFORE the Tuscany
runtime, because the tuscany-sca-all.jar will contain an analogous directory, and the extension
point is loaded
only once, from the first text file with appropriate name that is found.
This is really quite simple, after all. It may not be the best of all possible solutions,
but it works for me.
-- Sebastian
PS: I'd like to share some example code (99,9% is original Tuscany code anyway...)
I have put the text of this mail plus a zip archive into the JIRA that has occasioned this
entire exchange:
https://issues.apache.org/jira/browse/TUSCANY-4073
[1] http://mail-archives.apache.org/mod_mbox/tuscany-user/201006.mbox/%3C4C164DD3.8090405@apache.org%3E
[2] https://cwiki.apache.org/TUSCANYWIKI/classloading.html
> Change classloader to use different versions of third-party libraries than the Tuscany
runtime
> ----------------------------------------------------------------------------------------------
>
> Key: TUSCANY-4073
> URL: https://issues.apache.org/jira/browse/TUSCANY-4073
> Project: Tuscany
> Issue Type: Improvement
> Components: SCA Java Runtime
> Affects Versions: Java-SCA-1.6.2
> Environment: Java 7 on Windows 7 (64bit)
> Reporter: Sebastian Millies
> Fix For: Java-SCA-1.6.2
>
> Attachments: classloader.patch
>
>
> I want to set up my contributions, so that they can use
> different versions of third-party libraries than the Tuscany runtime. My original example
> was using recent versions of EMF (hence the subject line), another example is using
> Tuscany with an Apache Solr 4.0 backend, which requires different Apache Http Components.
> The standard recommendation is [1], but I have had great trouble to get that to work.
(The
> reasons have to do with the use of SDOs in the application in question.)
> I have therefore decided to try the opposite approach of including any different versions
of components
> used by Tuscany in nested jars in the contribution itself. Nested jars in a zip contribution
get added into
> the contribution classpath.
> Here I am working under the assumption that the SCA contribution classloader would work
> somewhat like a webapp class loader in that it would not follow the delegation model,
> but would look for classes in the following order
> 1) inside the contribution
> 2) in the imports
> 3) in the parent classloader
> With this behavior, everything goes well. For example, I can make calls to Apache Solr
through
> the solr-solrj-4.0.0.jar and its dependents, including httpclient-4.1.3.jar and httpcore-4.1.4.jar,
> without impacting HTTP calls made by Tuscany-generated proxies elsewhere.
> Here's the snag: As it turned out, org.apache.tuscany.sca.contribution.java.impl.ContributionClassLoader
DID
> NOT work the way I expected, but rather looked in the parent classloader first, only
then inside the contribution.
> I had to change the coding (in module contribution-java) and the associated test. A patch
is attached.
> Would my change break anything, perhaps with respect to OSGi? Is there anything in the
SCA spec that mandates a
> certain class loading behavior? I do feel that the alternative behavior is more natural
than the one that is currently
> implemented. (There a very few resources on Tuscany classloading, and e. g. [2] does
not seem to mention
> this particular issue.)
> Unfortunately, I cannot get all the Tuscany 1.6 tests to compile and run with maven.
> Please, would anyone be willing to see if Tuscany 1.6 with my patch applied would still
pass all current tests?
> (unless my proposal is obviously wrong for other reasons, of course)
> Best,
> Sebastian
> [1] http://mail-archives.apache.org/mod_mbox/tuscany-user/201006.mbox/%3C4C164DD3.8090405@apache.org%3E
> [2] https://cwiki.apache.org/TUSCANYWIKI/classloading.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/TUSCANY-4073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505347#comment-13505347
]
Simon Nash commented on TUSCANY-4073:
-------------------------------------
I tried this and got the following failures in modules and samples:
modules/binding-rmi-runtime:
testRmiService(org.apache.tuscany.sca.binding.rmi.BindingTestCase)
modules/binding-ws-axis2:
testEchoFoo(org.apache.tuscany.sca.binding.ws.axis2.itests.HelloWorldNoWSDLTestCase)
testImageFileTransfer(org.apache.tuscany.sca.binding.ws.axis2.itests.mtom.FileTransferMTOMTestCase)
testSourceFileTransfer(org.apache.tuscany.sca.binding.ws.axis2.itests.mtom.FileTransferMTOMTestCase)
testDataHandlerFileTransfer(org.apache.tuscany.sca.binding.ws.axis2.itests.mtom.FileTransferMTOMTestCase)
testOMElementFileTransfer(org.apache.tuscany.sca.binding.ws.axis2.itests.mtom.FileTransferMTOMTestCase)
samples/callbacks-jms:
testOderClient(callbacks.CallbacksTestCase)
samples/helloworld-ws-reference-lean:
testWSClient(helloworld.HelloWorldClientTestCase)
samples/helloworld-ws-sdo:
testWSClient(helloworld.HelloWorldClientTestCase)
samples/implementation-composite:
test(composite.CompositeTestCase)
samples/quote-xquery:
testQuoteJoin(xquery.quote.XQueryQuoteClientTestCase)
samples/simple-bigbank:
test(bigbank.BigBankTestCase)
samples/spring-bigbank-stockquote:
testServer(bigbank.stockquote.StockQuoteServiceTestCase)
samples/simple-callback:
test(simplecallback.SimpleCallbackTestCase)
samples/simple-callback-ws:
test(simplecallback.SimpleCallbackTestCase)
I didn't go any further, as the above errors seem to indicate there are serious issues with
this change.
> Change classloader to use different versions of third-party libraries than the Tuscany
runtime
> ----------------------------------------------------------------------------------------------
>
> Key: TUSCANY-4073
> URL: https://issues.apache.org/jira/browse/TUSCANY-4073
> Project: Tuscany
> Issue Type: Improvement
> Components: SCA Java Runtime
> Affects Versions: Java-SCA-1.6.2
> Environment: Java 7 on Windows 7 (64bit)
> Reporter: Sebastian Millies
> Fix For: Java-SCA-1.6.2
>
> Attachments: classloader.patch
>
>
> I want to set up my contributions, so that they can use
> different versions of third-party libraries than the Tuscany runtime. My original example
> was using recent versions of EMF (hence the subject line), another example is using
> Tuscany with an Apache Solr 4.0 backend, which requires different Apache Http Components.
> The standard recommendation is [1], but I have had great trouble to get that to work.
(The
> reasons have to do with the use of SDOs in the application in question.)
> I have therefore decided to try the opposite approach of including any different versions
of components
> used by Tuscany in nested jars in the contribution itself. Nested jars in a zip contribution
get added into
> the contribution classpath.
> Here I am working under the assumption that the SCA contribution classloader would work
> somewhat like a webapp class loader in that it would not follow the delegation model,
> but would look for classes in the following order
> 1) inside the contribution
> 2) in the imports
> 3) in the parent classloader
> With this behavior, everything goes well. For example, I can make calls to Apache Solr
through
> the solr-solrj-4.0.0.jar and its dependents, including httpclient-4.1.3.jar and httpcore-4.1.4.jar,
> without impacting HTTP calls made by Tuscany-generated proxies elsewhere.
> Here's the snag: As it turned out, org.apache.tuscany.sca.contribution.java.impl.ContributionClassLoader
DID
> NOT work the way I expected, but rather looked in the parent classloader first, only
then inside the contribution.
> I had to change the coding (in module contribution-java) and the associated test. A patch
is attached.
> Would my change break anything, perhaps with respect to OSGi? Is there anything in the
SCA spec that mandates a
> certain class loading behavior? I do feel that the alternative behavior is more natural
than the one that is currently
> implemented. (There a very few resources on Tuscany classloading, and e. g. [2] does
not seem to mention
> this particular issue.)
> Unfortunately, I cannot get all the Tuscany 1.6 tests to compile and run with maven.
> Please, would anyone be willing to see if Tuscany 1.6 with my patch applied would still
pass all current tests?
> (unless my proposal is obviously wrong for other reasons, of course)
> Best,
> Sebastian
> [1] http://mail-archives.apache.org/mod_mbox/tuscany-user/201006.mbox/%3C4C164DD3.8090405@apache.org%3E
> [2] https://cwiki.apache.org/TUSCANYWIKI/classloading.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/TUSCANY-4073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504791#comment-13504791
]
Sebastian Millies commented on TUSCANY-4073:
--------------------------------------------
I hereby give permission to the Apache Software Foundation use the attached patch for any
purpose whatsoever. -- Sebastian Millies
> Change classloader to use different versions of third-party libraries than the Tuscany
runtime
> ----------------------------------------------------------------------------------------------
>
> Key: TUSCANY-4073
> URL: https://issues.apache.org/jira/browse/TUSCANY-4073
> Project: Tuscany
> Issue Type: Improvement
> Components: SCA Java Runtime
> Affects Versions: Java-SCA-1.6.2
> Environment: Java 7 on Windows 7 (64bit)
> Reporter: Sebastian Millies
> Fix For: Java-SCA-1.6.2
>
> Attachments: classloader.patch
>
>
> I want to set up my contributions, so that they can use
> different versions of third-party libraries than the Tuscany runtime. My original example
> was using recent versions of EMF (hence the subject line), another example is using
> Tuscany with an Apache Solr 4.0 backend, which requires different Apache Http Components.
> The standard recommendation is [1], but I have had great trouble to get that to work.
(The
> reasons have to do with the use of SDOs in the application in question.)
> I have therefore decided to try the opposite approach of including any different versions
of components
> used by Tuscany in nested jars in the contribution itself. Nested jars in a zip contribution
get added into
> the contribution classpath.
> Here I am working under the assumption that the SCA contribution classloader would work
> somewhat like a webapp class loader in that it would not follow the delegation model,
> but would look for classes in the following order
> 1) inside the contribution
> 2) in the imports
> 3) in the parent classloader
> With this behavior, everything goes well. For example, I can make calls to Apache Solr
through
> the solr-solrj-4.0.0.jar and its dependents, including httpclient-4.1.3.jar and httpcore-4.1.4.jar,
> without impacting HTTP calls made by Tuscany-generated proxies elsewhere.
> Here's the snag: As it turned out, org.apache.tuscany.sca.contribution.java.impl.ContributionClassLoader
DID
> NOT work the way I expected, but rather looked in the parent classloader first, only
then inside the contribution.
> I had to change the coding (in module contribution-java) and the associated test. A patch
is attached.
> Would my change break anything, perhaps with respect to OSGi? Is there anything in the
SCA spec that mandates a
> certain class loading behavior? I do feel that the alternative behavior is more natural
than the one that is currently
> implemented. (There a very few resources on Tuscany classloading, and e. g. [2] does
not seem to mention
> this particular issue.)
> Unfortunately, I cannot get all the Tuscany 1.6 tests to compile and run with maven.
> Please, would anyone be willing to see if Tuscany 1.6 with my patch applied would still
pass all current tests?
> (unless my proposal is obviously wrong for other reasons, of course)
> Best,
> Sebastian
> [1] http://mail-archives.apache.org/mod_mbox/tuscany-user/201006.mbox/%3C4C164DD3.8090405@apache.org%3E
> [2] https://cwiki.apache.org/TUSCANYWIKI/classloading.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/TUSCANY-4073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Millies updated TUSCANY-4073:
---------------------------------------
Attachment: classloader.patch
Patches for org.apache.tuscany.sca.contribution.java.impl.ContributionClassLoader and the
associated unit test
> Change classloader to use different versions of third-party libraries than the Tuscany
runtime
> ----------------------------------------------------------------------------------------------
>
> Key: TUSCANY-4073
> URL: https://issues.apache.org/jira/browse/TUSCANY-4073
> Project: Tuscany
> Issue Type: Improvement
> Components: SCA Java Runtime
> Affects Versions: Java-SCA-1.6.2
> Environment: Java 7 on Windows 7 (64bit)
> Reporter: Sebastian Millies
> Fix For: Java-SCA-1.6.2
>
> Attachments: classloader.patch
>
>
> I want to set up my contributions, so that they can use
> different versions of third-party libraries than the Tuscany runtime. My original example
> was using recent versions of EMF (hence the subject line), another example is using
> Tuscany with an Apache Solr 4.0 backend, which requires different Apache Http Components.
> The standard recommendation is [1], but I have had great trouble to get that to work.
(The
> reasons have to do with the use of SDOs in the application in question.)
> I have therefore decided to try the opposite approach of including any different versions
of components
> used by Tuscany in nested jars in the contribution itself. Nested jars in a zip contribution
get added into
> the contribution classpath.
> Here I am working under the assumption that the SCA contribution classloader would work
> somewhat like a webapp class loader in that it would not follow the delegation model,
> but would look for classes in the following order
> 1) inside the contribution
> 2) in the imports
> 3) in the parent classloader
> With this behavior, everything goes well. For example, I can make calls to Apache Solr
through
> the solr-solrj-4.0.0.jar and its dependents, including httpclient-4.1.3.jar and httpcore-4.1.4.jar,
> without impacting HTTP calls made by Tuscany-generated proxies elsewhere.
> Here's the snag: As it turned out, org.apache.tuscany.sca.contribution.java.impl.ContributionClassLoader
DID
> NOT work the way I expected, but rather looked in the parent classloader first, only
then inside the contribution.
> I had to change the coding (in module contribution-java) and the associated test. A patch
is attached.
> Would my change break anything, perhaps with respect to OSGi? Is there anything in the
SCA spec that mandates a
> certain class loading behavior? I do feel that the alternative behavior is more natural
than the one that is currently
> implemented. (There a very few resources on Tuscany classloading, and e. g. [2] does
not seem to mention
> this particular issue.)
> Unfortunately, I cannot get all the Tuscany 1.6 tests to compile and run with maven.
> Please, would anyone be willing to see if Tuscany 1.6 with my patch applied would still
pass all current tests?
> (unless my proposal is obviously wrong for other reasons, of course)
> Best,
> Sebastian
> [1] http://mail-archives.apache.org/mod_mbox/tuscany-user/201006.mbox/%3C4C164DD3.8090405@apache.org%3E
> [2] https://cwiki.apache.org/TUSCANYWIKI/classloading.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Sebastian Millies created TUSCANY-4073:
------------------------------------------
Summary: Change classloader to use different versions of third-party libraries
than the Tuscany runtime
Key: TUSCANY-4073
URL: https://issues.apache.org/jira/browse/TUSCANY-4073
Project: Tuscany
Issue Type: Improvement
Components: SCA Java Runtime
Affects Versions: Java-SCA-1.6.2
Environment: Java 7 on Windows 7 (64bit)
Reporter: Sebastian Millies
Fix For: Java-SCA-1.6.2
I want to set up my contributions, so that they can use
different versions of third-party libraries than the Tuscany runtime. My original example
was using recent versions of EMF (hence the subject line), another example is using
Tuscany with an Apache Solr 4.0 backend, which requires different Apache Http Components.
The standard recommendation is [1], but I have had great trouble to get that to work. (The
reasons have to do with the use of SDOs in the application in question.)
I have therefore decided to try the opposite approach of including any different versions
of components
used by Tuscany in nested jars in the contribution itself. Nested jars in a zip contribution
get added into
the contribution classpath.
Here I am working under the assumption that the SCA contribution classloader would work
somewhat like a webapp class loader in that it would not follow the delegation model,
but would look for classes in the following order
1) inside the contribution
2) in the imports
3) in the parent classloader
With this behavior, everything goes well. For example, I can make calls to Apache Solr through
the solr-solrj-4.0.0.jar and its dependents, including httpclient-4.1.3.jar and httpcore-4.1.4.jar,
without impacting HTTP calls made by Tuscany-generated proxies elsewhere.
Here's the snag: As it turned out, org.apache.tuscany.sca.contribution.java.impl.ContributionClassLoader
DID
NOT work the way I expected, but rather looked in the parent classloader first, only then
inside the contribution.
I had to change the coding (in module contribution-java) and the associated test. A patch
is attached.
Would my change break anything, perhaps with respect to OSGi? Is there anything in the SCA
spec that mandates a
certain class loading behavior? I do feel that the alternative behavior is more natural than
the one that is currently
implemented. (There a very few resources on Tuscany classloading, and e. g. [2] does not seem
to mention
this particular issue.)
Unfortunately, I cannot get all the Tuscany 1.6 tests to compile and run with maven.
Please, would anyone be willing to see if Tuscany 1.6 with my patch applied would still pass
all current tests?
(unless my proposal is obviously wrong for other reasons, of course)
Best,
Sebastian
[1] http://mail-archives.apache.org/mod_mbox/tuscany-user/201006.mbox/%3C4C164DD3.8090405@apache.org%3E
[2] https://cwiki.apache.org/TUSCANYWIKI/classloading.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
I am out of the office until 12/17/2012. Please direct personnel questions to Jayashree Subrahmonia/Watson/IBM. Direct technical questions to Raphael P Chancey/Austin/IBM, Sridhar Sudarsan/Austin/IBM, or Matthew Sanchez/Austin/IBM. Note: This is an automated response to your message "Re: Porting Tuscany C ++ to C++11 and some code cleanup" sent on 11/27/2012 12:13:40 AM. This is the only notification you will receive while this person is away.
On Sun, Nov 25, 2012 at 1:31 PM, Thomas Gentsch <tg@e-tge.de> wrote: > On Sun, 2012-11-25 at 10:38 -0800, Jean-Sebastien Delfino wrote: > > On Fri, Nov 23, 2012 at 9:02 AM, Thomas Gentsch <tg@e-tge.de> wrote: > ... > > Great! Papers from the C++11 standard work groups are available on > > open-std.org there [1]. The final ISO standard is not free but the > > last draft [2] is free. If you just want a high level overview > > there's one on Wikipedia [3]. Hope that helps. > > Shortly looked through it, definitely interesting. Of course that makes > me worry a bit how far compilers support this already ... particularly > as partially maybe (as in our case) older OS versions are to be > supported. > On Linux, GCC 4.3 and later, see [5]. On MacOS, CLang 3.1 and later, see [6]. Of course you don't need to worry about it if you're using SDO as I'm not touching the M3 SDO code anyway :). ... > I quickly looked into Jira and found at least these: > > https://issues.apache.org/jira/browse/TUSCANY-3841 > https://issues.apache.org/jira/browse/TUSCANY-3715 > https://issues.apache.org/jira/browse/TUSCANY-3597 > > https://issues.apache.org/jira/browse/TUSCANY-1552 > > Ah, I now realize that you're using SDO, and I was only looking for SCA JIRAs. > > > > > The C++ trunk has already gone through some refactoring and quite a > > few changes over time since M3... There's no SDO anymore > > Oh!!! Actually I always believed Tuscany is mainly about SDO! > Well, then I have to correct myself - we are using Tuscany C++ SDO. I > wasn't aware of this at all (haven't looked into it for a while though) > Tus-SCA-ny is mainly about SCA [7]. SCA is a programming model for building apps with components that provide or use services, and initially used SDO to represent (mostly XML) data flowing through these services. > > (like the Java trunk, which I believe dropped SDO as well), the > > composite files use the new SCDL from OASIS, the runtime integrates > > with Apache HTTPD, etc. There's still an integration with Axis2C but > > I've not looked at it for a very long time. > > > > > > So, if you're still using SDO you'll probably want to stick to the M3 > > level, but I can help apply your patch to a maintenance branch off M3 > > at some point if that helps. > > Well, if SDO is dead anyway then there will not be any release anymore I > suppose, so maybe no need to bother. > > ... I'm not sure about the state of SDO. I've not seen any activity on it for some time now, and I'm not planning to do anything with SDO at this point, but can try to help on my spare time if you or others are interested in maintaining or evolving the SDO code. > OK, then I should look into the alternatives? Is there any replacement? > Many thx + regards, > I personally like libxml2 [8] for XML and jansson [9] for JSON, and there's several other good XML and JSON libraries out there too, but if SDO works for you and you have a good handle on that code (and it looks like it since you were able to create some good patches), then why change? :) > > > > [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/ > > [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf > > [3] http://en.wikipedia.org/wiki/C%2B%2B11 > > [4] https://issues.apache.org/jira/browse/TUSCANY-3598 > > [5] http://gcc.gnu.org/projects/cxx0x.html [6] http://clang.llvm.org/cxx_status.html [7] http://www.oasis-opencsa.org/committees [8] http://www.xmlsoft.org [9] http://www.digip.org/jansson/
On Sun, 2012-11-25 at 10:38 -0800, Jean-Sebastien Delfino wrote: > On Fri, Nov 23, 2012 at 9:02 AM, Thomas Gentsch <tg@e-tge.de> wrote: > > Hi JS + all, > > we are using Tuscany C++ in one of our projects, hence we/I > have some > personal interest and also would like to contribute, if > possible. > > Tbh, I don't know details about C++11 (will read a bit) nor > the other > things you mention. > > > Great! Papers from the C++11 standard work groups are available on > open-std.org there [1]. The final ISO standard is not free but the > last draft [2] is free. If you just want a high level overview > there's one on Wikipedia [3]. Hope that helps. Shortly looked through it, definitely interesting. Of course that makes me worry a bit how far compilers support this already ... particularly as partially maybe (as in our case) older OS versions are to be supported. > One thing though which appears quite important to me is that > the various > patches we/I have done (most/all (?) submitted to Jira) and > other people > are incorporated into the general code so that they are in the > next > release if there will ever be one ... and of course this is > easier > before any refactorings. > > > I found one JIRA with a patch from you [4], which looks like a change > to the SDO + Axiom support in the SCA-Native-M3 release. I quickly looked into Jira and found at least these: https://issues.apache.org/jira/browse/TUSCANY-3841 https://issues.apache.org/jira/browse/TUSCANY-3715 https://issues.apache.org/jira/browse/TUSCANY-3597 https://issues.apache.org/jira/browse/TUSCANY-1552 > > The C++ trunk has already gone through some refactoring and quite a > few changes over time since M3... There's no SDO anymore Oh!!! Actually I always believed Tuscany is mainly about SDO! Well, then I have to correct myself - we are using Tuscany C++ SDO. I wasn't aware of this at all (haven't looked into it for a while though) > (like the Java trunk, which I believe dropped SDO as well), the > composite files use the new SCDL from OASIS, the runtime integrates > with Apache HTTPD, etc. There's still an integration with Axis2C but > I've not looked at it for a very long time. > > > So, if you're still using SDO you'll probably want to stick to the M3 > level, but I can help apply your patch to a maintenance branch off M3 > at some point if that helps. Well, if SDO is dead anyway then there will not be any release anymore I suppose, so maybe no need to bother. > > The other thing: Are the planned changes going to modify the > API > interface or is it just internally? > > > The C++11 changes only apply to the runtime internals, but again if > you're using the SDO-based API from M3, that already changed a long > time ago. OK, then I should look into the alternatives? Is there any replacement? Many thx + regards, tge > > Rgds, > tge > > > > > [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/ > [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf > [3] http://en.wikipedia.org/wiki/C%2B%2B11 > [4] https://issues.apache.org/jira/browse/TUSCANY-3598
On Fri, Nov 23, 2012 at 9:02 AM, Thomas Gentsch <tg@e-tge.de> wrote: > > Hi JS + all, > > we are using Tuscany C++ in one of our projects, hence we/I have some > personal interest and also would like to contribute, if possible. > Tbh, I don't know details about C++11 (will read a bit) nor the other > things you mention. > Great! Papers from the C++11 standard work groups are available on open-std.org there [1]. The final ISO standard is not free but the last draft [2] is free. If you just want a high level overview there's one on Wikipedia [3]. Hope that helps. > One thing though which appears quite important to me is that the various > patches we/I have done (most/all (?) submitted to Jira) and other people > are incorporated into the general code so that they are in the next > release if there will ever be one ... and of course this is easier > before any refactorings. > I found one JIRA with a patch from you [4], which looks like a change to the SDO + Axiom support in the SCA-Native-M3 release. The C++ trunk has already gone through some refactoring and quite a few changes over time since M3... There's no SDO anymore (like the Java trunk, which I believe dropped SDO as well), the composite files use the new SCDL from OASIS, the runtime integrates with Apache HTTPD, etc. There's still an integration with Axis2C but I've not looked at it for a very long time. So, if you're still using SDO you'll probably want to stick to the M3 level, but I can help apply your patch to a maintenance branch off M3 at some point if that helps. > > The other thing: Are the planned changes going to modify the API > interface or is it just internally? > The C++11 changes only apply to the runtime internals, but again if you're using the SDO-based API from M3, that already changed a long time ago. > > Rgds, > tge > > [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/ [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf [3] http://en.wikipedia.org/wiki/C%2B%2B11 [4] https://issues.apache.org/jira/browse/TUSCANY-3598
Hi JS + all, we are using Tuscany C++ in one of our projects, hence we/I have some personal interest and also would like to contribute, if possible. Tbh, I don't know details about C++11 (will read a bit) nor the other things you mention. One thing though which appears quite important to me is that the various patches we/I have done (most/all (?) submitted to Jira) and other people are incorporated into the general code so that they are in the next release if there will ever be one ... and of course this is easier before any refactorings. The other thing: Are the planned changes going to modify the API interface or is it just internally? Rgds, tge On Thu, 2012-11-22 at 11:31 -0800, Jean-Sebastien Delfino wrote: > Hi all, > > > Happy Thanksgiving :). I'm going to have a little bit of spare time on > the long weekend to do some cleanup of Tuscany C++. > > > I'm planning to do some code refactoring to start leveraging some of > the new C++11 standard constructs (replace the current functors with C > ++11 lambda expressions for example). I'll also try to do some more > general cleanup of the code base and improvements to a few areas like > the JSON support (which currently requires SpiderMonkey, that's > overkill) and the server hosting module. > > > These changes should simplify the code base a bit and bring > significant performance improvements as well. It'd be nice to have > another release at some point... perhaps on one of the next holiday > breaks if I get enough spare time again, or if others would like to > help... > > > HTH > > > - Jean-Sebastien
Hi all, Happy Thanksgiving :). I'm going to have a little bit of spare time on the long weekend to do some cleanup of Tuscany C++. I'm planning to do some code refactoring to start leveraging some of the new C++11 standard constructs (replace the current functors with C++11 lambda expressions for example). I'll also try to do some more general cleanup of the code base and improvements to a few areas like the JSON support (which currently requires SpiderMonkey, that's overkill) and the server hosting module. These changes should simplify the code base a bit and bring significant performance improvements as well. It'd be nice to have another release at some point... perhaps on one of the next holiday breaks if I get enough spare time again, or if others would like to help... HTH - Jean-Sebastien