Introduction
Hi, my name is Simon Laws and I'm based in the UK. My recent background is web services in the data grid space and I've just started looking at the Tuscany C++ code. Apologies in advance for my newby questions. Regards Simon
MSVC build
I checked out the C++/SDO code this morning and I'm assuming I caught it mid change as the MSVC project doesn't build. To make it work I had to add: GroupEvent.cpp GroupDefinition.cpp to the sdo_runtime project utils.cpp main.cpp to the sdo_test project Simon
Cross language interop?
Has anyone in the team done any work in Tuscany looking at cross language interoperability? I'm initially interested in ensuring SDO serialization is compatible between PHP, C++ and Java. If there is existing work it gives me somewhere to start. If not I'll start something. Simon
Summer of code tuscany-das proposal
We would like to add the following to the list of Apache Summer Of Code proposals. A) does the team support this B) is it an appropriate task for summer of code Also, if there is anyone who would like to help out with mentoring and wants their name added to the list then that would be great. ** *= Subject ID* *tuscany-das* *Title*Alternative data access service implementations *ASF Project* Tuscany *Keywords*Service Data Objects (SDO) alternative Data Access Service (DAS) implementations *Description* *SDO relies on DAS in order to read and update the in memory SDO data graph from/to persistent store. Some DAS implementations exist, in particular XML (for PHP, C++ and Java) and in some cases relational database(for PHP). New implementations could target different data resources such as flat file (CSV), Microsoft Excel, LDAP or could be driven by different schema languages such as RelaxNG. *** *Possible Mentors* *Caroline Maynard, Simon Laws,* *Status* *-* =
Fwd: Summer of code tuscany-das proposal
I had two positive responses to the summer of code proposal. But none of the interested parties are Apache committers. The Apache summer of code wiki says Any Apache member and experienced committers can submit ideas Any committers out there interested in supporting this proposal? -- Forwarded message -- From: Simon Laws [EMAIL PROTECTED] Date: Apr 27, 2006 8:46 AM Subject: Summer of code tuscany-das proposal To: tuscany-dev tuscany-dev@ws.apache.org We would like to add the following to the list of Apache Summer Of Code proposals. A) does the team support this B) is it an appropriate task for summer of code Also, if there is anyone who would like to help out with mentoring and wants their name added to the list then that would be great. * * *= Subject ID* *tuscany-das* *Title*Alternative data access service implementations *ASF Project* Tuscany *Keywords*Service Data Objects (SDO) alternative Data Access Service (DAS) implementations *Description* *SDO relies on DAS in order to read and update the in memory SDO data graph from/to persistent store. Some DAS implementations exist, in particular XML (for PHP, C++ and Java) and in some cases relational database(for PHP). New implementations could target different data resources such as flat file (CSV), Microsoft Excel, LDAP or could be driven by different schema languages such as RelaxNG. *** *Possible Mentors* *Caroline Maynard, Simon Laws,* *Status* *-* =
Re: C++ release before ApacheCon Europe
+1 Following on from Ed's point. I'm working my way through doing some simple read/write interop test for PHP/C++/Java XML at the moment initially based on the company data example. However to make this a useful test it would seem sensible to make a schema that contains all of the simple and complex types and sequences that we expect to come across in SDO/XML. Has one been made already? On the SCA testing front. Can we use and modify an existing sample like Big Bank to pull in implementations other than Java? I will take a look at it and maybe we can start a separate thread on SCA/SDO interop testing. Regards Simon On 5/2/06, Edward Slattery [EMAIL PROTECTED] wrote: +1. From the SDO C++ point of view, the interop that could be done by then would be at the serialized level - I.E being able to load/save the same XML in both systems. In terms of Axis2C support, I am looking into providing a utility to write AXIOM from SDOs and SDO types. Ideally I would do that by creating AXIOM objects directly from SDO properties, but the quick solution would be to stream the SDO to XML, and then use axis2 to read the XML. cheers, Ed. On 01/05/06, Pete Robbins [EMAIL PROTECTED] wrote: I think it would be a good idea to have a release of the C++ subproject before ApacheCon Europe (Last week in June). I'll set up a wiki page along the lines of the Java Tasks page to set out what we need to do to get to a release. I'd like to have an IRC chat (Wednesday?) to discuss the functional content of this proposed release and how we get there. Current thoughts are to have webservice support using Axis2C and a sample to demonstrate interoperability with the Java release and ... Cheers, -- Pete
Big Bank status?
Hi
I just tried running the maven build (I checked out from svn a couple of
hours ago) for the big bank sample and the AccountService.java interface
that is generated from the AccountService.wsdl matches neither the wsdl nor
the checked in AccountServiceImpl.java and hence the build fails. The
signatures are all represented but they are incorrect, e.g.
WSDL
xsd:element name=deposit
xsd:complexType
xsd:sequence
xsd:element name=accountNumber
type=xsd:string /
xsd:element name=amount type=xsd:float /
/xsd:sequence
/xsd:complexType
/xsd:element
AccountServiceImpl.java
public float deposit(String account, float ammount) throws
RemoteException {
try{
Generated AccountService.java
public float deposit(
java.lang.String param0) throws java.rmi.RemoteException;
I had assumed this would work as Rick has been posting fixes to big bank. If
this is being caused by work in progress then not to worry I will wait. If
not I will raise JIRAs
Regards
Simon
Re: Big Bank status?
Rick
Thanks for looking, sorry to distrct you. Must be something wrong with my
check out. I'll start again.
Regards
Simon
On 5/2/06, Rick Rineholt [EMAIL PROTECTED] wrote:
Fresh build compiles for me
AccountService.java: snippet is below matches WSDL and AccountServiceImpl
/**
* Auto generated method signatures
* @param param6* @param param7
*/
public float deposit(
java.lang.String param6,float param7) throws
java.rmi.RemoteException;
Simon Laws wrote:
Hi
I just tried running the maven build (I checked out from svn a couple of
hours ago) for the big bank sample and the AccountService.java interface
that is generated from the AccountService.wsdl matches neither the
wsdl nor
the checked in AccountServiceImpl.java and hence the build fails. The
signatures are all represented but they are incorrect, e.g.
WSDL
xsd:element name=deposit
xsd:complexType
xsd:sequence
xsd:element name=accountNumber
type=xsd:string /
xsd:element name=amount type=xsd:float /
/xsd:sequence
/xsd:complexType
/xsd:element
AccountServiceImpl.java
public float deposit(String account, float ammount) throws
RemoteException {
try{
Generated AccountService.java
public float deposit(
java.lang.String param0) throws java.rmi.RemoteException;
I had assumed this would work as Rick has been posting fixes to big
bank. If
this is being caused by work in progress then not to worry I will
wait. If
not I will raise JIRAs
Regards
Simon
Re: Cross language interop
Hi Kevin When you suggest and example of reading data from a data source and shipping it to some remote engine for processing would this include, for example, an application that reads a data graph from a relational database and then forwards is in the form of and XML document to, say, an XFoms engine. Is this the kind of thing you were talking about? Once the XML form has been completed in this case the modified XML doc would have to be sent back to the SDO in some way and, as you say, be committed to the database. How is this done in SDO? Are interfaces provided that allow an existing SDO to be updated with a new graph (the modifieed XML document) while maintaining the original change history? Regards Simon On 5/3/06, Kevin Williams [EMAIL PROTECTED] wrote: kelvin goodson wrote: [snip] With regards to sharing change histories, I imagine the primary use case for change histories is when you give a give a modified graph back to the same DAS for writing back to the original source. So I in terms of cross language interoperability I would extrapolate that the scenario we would be supporting would be that of fairly tightly coupled DAS implementations, all accessing the same source. I may be wrong, but It doesn't sound like a frequently encountered scenario, so whilst it sounds like goodness, it wouldn't be at the top of my priority list. [snip] I have also not seen many interop scenarios requiring cooperation between two different DAS implementations. The only one that comes to mind is reading from one database and writing to another. This would be very cool, especially if the two DAS implementations were in different languages(C++, Java, PHP, Ruby), but I doubt that this scenario will be common. I think a more frequent interop scenario will involve reading data from a data source and shipping it to some remote engine for processing. The modified graph would be shipped back to the originating DAS and the changes reflected to the originating data source. The remote engine could be implemented in another language or, if it is the same language, it could be using a different implementation of SDO.
Re: Cross language interop
So are you thinking about a specific services interface for an SDO object, i.e. the SDO acts as a conduit between the data resource and the client (browser)? In this scenario what happens when data is changed. Does the SDO cache the change awaiting the request to update the data resource or does it pass the update directly through to the data resource. There are a number of examples of web services type implementations of access to relational and file data. Would you propose that we adopt and exisitng interface description or construct a service interface that wraps the SDO interface as currently specified? Regards Simon On 5/4/06, Edward Slattery [EMAIL PROTECTED] wrote: With regard to the interop scenario concerning moving data graphs from location to location, I am a bit concerned that we are not covering the other option. With the coming of AJAX, some people are looking more at leaving the data where it is, and using the API to modify it on the server. How does this fit with SDO? Currently (certainly in the C++ implementation), we load the data into objects in memory from the data storage, and can then serialize them to XML to be moved around. If we imagine a case where ajax is used to call get/set APIs on data objects, then perhaps we dont even need to load the data from the database until its used. I feel the need for an SDO implmentation which just wraps data access, and does nothing until a data object is actually requested, at which point it uses whatever mechanism is used by the data access service (stored procs etc) to load that individual data object, and send that to the client. Perhaps thats really a separate thread - what do you all think? On 03/05/06, Kevin Williams [EMAIL PROTECTED] wrote: kelvin goodson wrote: [snip] With regards to sharing change histories, I imagine the primary use case for change histories is when you give a give a modified graph back to the same DAS for writing back to the original source. So I in terms of cross language interoperability I would extrapolate that the scenario we would be supporting would be that of fairly tightly coupled DAS implementations, all accessing the same source. I may be wrong, but It doesn't sound like a frequently encountered scenario, so whilst it sounds like goodness, it wouldn't be at the top of my priority list. [snip] I have also not seen many interop scenarios requiring cooperation between two different DAS implementations. The only one that comes to mind is reading from one database and writing to another. This would be very cool, especially if the two DAS implementations were in different languages(C++, Java, PHP, Ruby), but I doubt that this scenario will be common. I think a more frequent interop scenario will involve reading data from a data source and shipping it to some remote engine for processing. The modified graph would be shipped back to the originating DAS and the changes reflected to the originating data source. The remote engine could be implemented in another language or, if it is the same language, it could be using a different implementation of SDO.
Re: [vote] Project structure - renaming java/samples
+1 [X] sample applications - java/sampleapps/bigbank/ On 5/10/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I'm not sure that we really have decided on a good name for our top level samples directory, currently java/samples/. This directory hosts samples. They are of a different nature than the technology samples under sca/samples, das/samples and sdo/samples. For M1 the only sample in this directory is BigBank (in the future we may want to add others like Petstore, the WS-I supply chain sample etc). We've all been using different terms to describe these samples, so far I've heard: samples, examples, sample applications, blueprints, business samples, business scenarios, sample scenarios, scenarios, demos. We need to pick a reasonable directory name for our M1 distribution asap as we're trying to put together the distribution build. Could you all please vote for one of the following? [ ] samples - java/samples/bigbank/ [ ] examples - java/examples/bigbank/ [ ] sample applications - java/sampleapps/bigbank/ [ ] blueprints - java/blueprints/bigbank/ [ ] business samples - java/businesssamples/bigbank/ [ ] business scenarios - java/businessscenarios/bigbank/ [ ] sample scenarios - java/samplescenarios/bigbank/ [ ] scenarios - java/scenarios/bigbank/ [ ] demos - java/demos/bigbank/ [ ] big bank - java/bigbank/ (with no parent samples directory if there is only sample like that in M1) [ ] any other creative idea :) Thanks, -- Jean-Sebastien
[PHP] PHP wish list?
Pete has recently followed the java team's lead and initiated a to do/wish list up on the Tuscany wiki for the C++ implementation effort. The PHP/SDO PECL project needs to do the same thing but we don't have a wiki over at PECL at the moment. It would seem sensible (to me at least) if we borrow a page of the project Tuscany wiki for this purpose as many of the same items will appear for PHP as for Java and C++. We would then link this wiki page from our PHP/SDO PECL project page ( http://pecl.php.net/package/sdo) and vice versa. Does anyone have any objections to me doing this? Regards Simon
Re: [C++] Options for string handling in SDO
Hi Geoff When you talk about string objects do you mean instances of the ANSI string class (basic_string) or is this a special SDO designed string class? Also why is this an either/or? It would seem like a useful thing to have an interface that allows string objects to be used but not sure I would want to loose the ability to use C strings as well. Simon On 5/12/06, Geoffrey Winn [EMAIL PROTECTED] wrote: Much of the string data in SDO for C++ is handled as C style, null-terminated arrays of characters. I'm trying to move that to a style where most string data is represented as true string objects. The painless (less painful) way to do that is to leave the externals alone and to introduce string objects internally, converting between string objects and C-style strings at the earliest convenient point when called and the last convenient point on return. The alternative is to extend the public interface with extra methods that take string objects as arguments rather than C-style strings. In this case we would have to publicise a new string class as well. Does anyone have any opinions on which of these is preferable (or any other alternatives)? We could of course make the internal only changes first and add an extended public interface later. Regards, Geoff.
Re: C++ Release
Pete +1 for release and IRC chat On 5/25/06, Pete Robbins [EMAIL PROTECTED] wrote: As mentioned previously we would be a like to have a binary release of the C++ code by ApacheCon Europe. I'd like to propose an IRC chat on Tuesday 6th June 17:00 BST (18:00 GMT) 12:00 (Eastern) 09:00 (Pacific) to finalize content and schedule to achieve this. As a starting point, and for discussion until then, there is a wiki page, http://wiki.apache.org/ws/Tuscany/TuscanyCpp/Tasks. I will be unavailable from 28th May - June 5th but I'd hope that there will be some discussion on this thread before I get back. Cheers, -- Pete
Cross language interop testing
A long time ago I posted about doing some interoperability testing. I've got back to this now and I've put some ideas about how we do this on the wiki, here (http://wiki.apache.org/ws/Tuscany/Interop). At a high level we have two products to consider for interoperability testing, SDO and SCA. This testing should be performed across all implementations, i.e. Java, C++ and PHP. As it stands the only available SCA implementation that can talk to anything else is Java (C++ is nearly there with Axis2 integration going on as we speak) so we can skip the SCA interoperability conversation for the time being. That brings us to SDO. SDO interoperability involves successfully moving SDO data (instance, model and/or change history data) from one implementation of SDO to another. The scenarios section gives a few ideas about why we might want to do this. This is not intended to be a complete list so any more SDO interoperability scenarios you can think of are gratefully accepted. We have Java, C++ and PHP implementations of SDO to date but the features available vary slightly across these implementations. From an interoperability point of view Kelvin and myself talked offline and listed the features that seemed important in the Features section. You will note that we marked which implementations currently support which features. Is this assessment correct? The order column simply indicates which order the tests could be constructed in, for example, to get my head round this process I have made a start on the test which involves reading an XML document and writing it out again via the XMLHelper/DAS (item 1.1). This seems like an obvious place to start while, for example, the Axiom serialization code is note done yet in C++ so it would be difficult to start with that. In general the approach to this testing can be fairly simple I believe. For each implementation we write a test program that performs the required test, e.g. read and write an XML file. Then we compare: A/ the input with the output to check that it works for an individual implantation B/ the output of all of the implementations to check interoperability. If all of the inputs and outputs in A match there should be no issue here. So if we lay these tests out in order I would expect to do the following in Java, C++ and PHP where the feature is supported 1.1. Read an XML file and write it out again 1.2. Read an XML file and write out an XSD file 2.1 Read and write Records from a database 3.1 Read XML and write Axiom 3.2 Read Axiom and write XML 4 Serialize XML from/To SDO – I'm not sure that this is different from 1.1at present as I seen documents mention it but haven't tried it 1.3 Read an XML file and make changes before writing it back out again. Changes to be made through both dynamic and generated interfaces 4.2 Read from a database and make changes before writing is back out again. Changes to be made through both dynamic and generated interfaces As I mentioned previously I've had a go at 1.1. This first involved creating XSD files to include all of the type mappings defined in the SDO 2.0.1specification. I have this now and am able to pass it in and out of SDO in Java and C++. PHP is still To Do. The results are included in the schema feature table and I will raise JIRA as I investigate what I have found in more detail. Now I have the XML schema the other XML tests become easier as, to a great extent, they are just variations on a theme. I will have to generate a relational schema to match of course. So, is this going to work and is it sufficient? Any thoughts you have on any of this are gratefully received on the mailing list. It may be useful for us to have an IRC chat based on feedback to discuss the best way forward. I will post with details depending on what feedback I get. An unresolved issue is what to do with the test code and files that this process will generate. The test code will happily live within each project somewhere (where is a good place in each project structure?), for example, it could be Java: tuscany/java/sdo/impl/src/test/org/apache/Tuscany/sdo/interop C++: tuscany/cpp/sdo/runtime/core/interop PHP: tuscanyphp/sdo-1.0.1/tests/interop The input files themselves are common across all projects as are the results of cross implementation file comparisons. So where should they live. Maybe the thing to do is just pick on project, C++ or Java, and put the common files there. We have a UK public holiday on Monday but I'll be back to this on Tuesday.
Re: Cross language interop testing
On 5/30/06, Geoffrey Winn [EMAIL PROTECTED] wrote: Simon, On 26/05/06, Simon Laws [EMAIL PROTECTED] wrote: A long time ago I posted about doing some interoperability testing. I've got back to this now and I've put some ideas about how we do this on the wiki, here (http://wiki.apache.org/ws/Tuscany/Interop). ... So if we lay these tests out in order I would expect to do the following in Java, C++ and PHP where the feature is supported 1.1. Read an XML file and write it out again 1.2. Read an XML file and write out an XSD file 2.1 Read and write Records from a database 3.1 Read XML and write Axiom 3.2 Read Axiom and write XML I see the sense in 1.1 However, I'm not so sure about 1.2. Presumably that is saying that we read an XML instance and in the process of creating an SDO for it we have also defined a variety of types, properties and so on to describe it. Then we use that information to generate an XSD. This is pretty much the same as inspecting an XML instance document and then writing an XSD for it. It isn't obvious to me that different implementations would necessarily generate the same XSD in these cases. I'm willing to be convinced; I'm just not sure that it's fair to expect that different implementations will generate the same XSD when what they were doing was populating a model with whatever they needed to read an XML instance. Regards Geoff. Yes, you have spotted a slip up here I think. This is an interesting test of schema free XML loading but I'm told this doesn't work in PHP so probably doesn't in C++. The spec implies that you can do this in Java although I have to admit to not having tried it yet. As its difficult to test interoperability with one implementation we could replace 1.2. Read an XML file and write out an XSD file with 1.2. Generate metadata statically in code and write out an XSD file and test the case where the type model comes from elsewhere prior to XSD generation. What we are testing here is each implementations' type model to XSD mapping to see if they are compatible.
Is there an example of using a DB Stored Procedure as part of an SCA module?
The SCA Assembly Model specification (0.9) gives database stored procedure as an example of a binding type. I've had a bit of a scout around the Tuscany site and in Google and there is discussion of interacting with stored procedures via SDO, i.e. using a relational DAS. Before I have a go does anyone know if there is an existing code example of the use of a stored procedure as the target of a SCA reference, for example, via an existing HTTP or web services binding. Regards Simon
Re: Tuscany website content updates
+1 for FAQ on the wiki. I raised a few JIRAs on potential FAQ entries that I could add directy if it were there. Simon On 6/1/06, haleh mahbod [EMAIL PROTECTED] wrote: Hi Venkata, InstallJava and projectJava pages were created with two different audience in mind. The assumption was that a person exploring Java SCA section (under which is installation) is a user who does not necessary want to get involved in development but wants to download the binaries and use SCA. This page needs to be updated with distribution information once we have M1 release in place. On the other hand, project java page was created for developers. It helps them setup their development environment and run samples. Maybe this flow is not working and should be fixed. You can find all existing website JIRA issues under website category. Please go ahead and create JIRAs with your suggestions and provide fixes if you can. Help is very welcomed :) I am also thinking that FAQ should be moved to Wiki and website should be linked to it. This way anyone can post their questions and answers. As is, only committers can update the website and one needs to go through patch submission to update FAQ. What does everyone think? Haleh On 5/31/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi A couple of others that I opine should be ironed out... 1) There is a discussion thread on JIRA-438 that quotes http://incubator.apache.org/tuscany/projectjava.html for installation instructions etc. Now there is another page http://incubator.apache.org/tuscany/installjava.html that contains a subset of the what you might find in http://incubator.apache.org/tuscany/projectjava.html. I found the contents of http://incubator.apache.org/tuscany/projectjava.htm more clean and complete and should probably be the only one. 2) In http://incubator.apache.org/tuscany/projectjava.html there is a section that talks about downloading and building tuscany. This build, in my opinion also includes building the samples. Now following this section is another section titled Running the Samples' where in one is asked to go to the distribution directory and build. Is this required if I have already built from the root? Is there a JIRA where we are tracking down 'things to do' with respect to - Venkat On 5/31/06, Simon Nash [EMAIL PROTECTED] wrote: I think these are good suggestions. Having an FAQ that is updated frequently based on real user questions on common newbie issues would be a great help in enabling new users to overcome initial obstacles to using Tuscany. The BigBank pdf document does a good job of describing the code and other source artifacts. Since it is a generic SCA document, it does not say anything about how to build, deploy and run the BigBank application in the Tuscany environment. As well as pointing to this document, it might be helpful to go slightly beyond this by also including some Tuscany-specific how to information. Simon Venkata Krishnan wrote: Hi, Can we update the page http://incubator.apache.org/tuscany/userguidejava.html with information for the Your First Tuscany Application and FAQ. These sections have been empty for a while now. To start with we could point to the pdf on Simplified Big Bank application on the 'documenation' page http://incubator.apache.org/tuscany/documentation.html . For trouble shooting we could divide the FAQ into sections, one of which can deal with TroubleShooting and then just keep updating the FAQ. If this sounds ok to everybody let me know how I could update these pages and I can do so. - Venkat -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK [EMAIL PROTECTED] Tel. +44-1962-815156 Fax +44-1962-818999 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[C++] C++ / PHP BOF at apache con
I believe Pete was thinking of trying for a C++ BOF at ApacheCon in a few weeks time. In the C++ release IRC on Tuesday ( http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg03746.html) there was discussion of trying to get a simple sample, based loosely on the big bank scenario, running in C++ and also possibly across the different implementations. Is there any appetite to use this during the BOF (assuming a slot is available of course) end extend the BOF scope to interoperatbility across implementations?
Re: [C++] C++ / PHP BOF at apache con
Oh Dear, that pretty much answers that then. Is this just a statement for this time or are them stopping BOFs in future events too. You could always retire to the pub! I still think we should do what we discussed and put a PHP front end on the demo that you are constructing for C++ SCA. So lets start thinking about what we can do in that direction. Currently only SDO is implemented in PHP. As I think we discussed on the IRC we could do a number of things, for example: 1/ Try the PHP SOAP extension and see if we can talk to C++ big bank services 2/ Use to PHP SDO to access details directly from the database being used by C++ big bank I guess we could also use a java service at the back end, but maybe that is another discussion. S On 6/8/06, Edward Slattery [EMAIL PROTECTED] wrote: I just got confirmation that there are not going to be any BOFs at ApacheCon Europe - so that may change our approach On 08/06/06, Edward Slattery [EMAIL PROTECTED] wrote: I am hoping to have a bigbank back-end coded by apachecon - it would be good to have another language as the front end to show WS interop On 08/06/06, Simon Laws [EMAIL PROTECTED] wrote: I believe Pete was thinking of trying for a C++ BOF at ApacheCon in a few weeks time. In the C++ release IRC on Tuesday ( http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg03746.html) there was discussion of trying to get a simple sample, based loosely on the big bank scenario, running in C++ and also possibly across the different implementations. Is there any appetite to use this during the BOF (assuming a slot is available of course) end extend the BOF scope to interoperatbility across implementations?
Re: Tuscany blog
Ant Happy to contribute. I think the uname/password will be problematic if you intend to distribute it and this is intended to be the blog voice of tuscany. Maybe it needs to stay a committer thing, or even have one person manage posts, and use the mail list as a submission vehicle for others? Alternatively we need to find some hosted community blogging service (although I did a quick google and didn't find anything obvious - was just a quick look though) or set up our own (would need some hosted LAMP service) and hand out unames/passwords as required. b.t.w jroller gave me an error saying they are not accepting new users. So blogger (i think blogspot is part of google also) vs bloglines? S On 6/8/06, ant elder [EMAIL PROTECTED] wrote: How about setting up a blog for the Tuscany project? We could use it to publicize interesting events for all the different Tuscany sub projects - new releases, use of Tuscany by another another project/company, upcoming conference talks or slides from presentations, new spec release etc. Other projects do this, for example the Dojo project has one at: http://blog.dojotoolkit.org/ I think I could sometimes find interesting things to comment on from the Java SCA perspective, but to be successful there would need to be more frequent posts, so buy in from others involved in Tuscany to make sure there are regular topical posts - would others be willing to participate? If so, the next question is how to do this. There's various free blog sites, http://www.jroller.com/, although thats specifically Java so may not fit our multi-language nature so http://www.bloglines.com/ maybe better, I know some other Apache WS people use that. Any other suggestions or which blog host to use? Then there's how to administer the blog userid and password, i guess the obvious thing is to share that with every Tuscany committer so all the committers can post when ever they want, although there are other Tuscany users and contributors who may want to post so should we consider distributing the uid/pswd more widely? ...ant
Re: [C++] Axis2C Web Service Entrypoint
Ok, ant. Thanks for pointing us at that. A couple of things come to mind 1/ Looking at the interop doc test we could extend this over time to include more comprehensive schema to test some of the dusty corners (as kelvin would put it). Looking at the client code it looks like the schema types in the WSDL get generated into in SDO type models so this is ideal for extending to run the interop schemas we are building and hence test the full range of SDO/XML(and hence AXIOM) mappings. 2/ I'm sure the client/service implementations can be extended to include Tuscany C++ implementations. I like the approach you have of being able to choose a Tuscany or external service. We could take this same approach between Java and C++ and implemente the services/clients in the appropriate projects. S On 6/9/06, ant elder [EMAIL PROTECTED] wrote: We've also some WS interop tests in the Java runtime: http://svn.apache.org/repos/asf/incubator/tuscany/java/testing/interop/ Right now there's not so much there yet, the clients use the SCA Java WS binding to invoke some remote WSs out on the Internet, the services are supposed to be SCA WS impls of the services those clients use, and and when you run the clients you set a property to say if you want to call the real remote services or the local impls. We've still a way to go to make this easy to setup and use and to get a good selection of services to test. Anyway, would be good to fit the Axis2C stuff in here somehow. ...ant On 6/9/06, Simon Laws [EMAIL PROTECTED] wrote: OK, that's great. Feel free to go in and modify the wiki page to suite ( http://wiki.apache.org/ws/Tuscany/Interop). I have also attached a preliminary schema here for testing xml types. I have used this to complete the series 1 feature table you see there. However I think that I might refactor this into a set of separate files to make the testing process a little easier. The contents will be pretty much the same just spread across more files. Let me know when you are ready to have a go at some of this and I can attach up to date files. S On 6/9/06, Andrew Borley [EMAIL PROTECTED] wrote: Hi Simon, I've done some rudimentary testing using an Axis2 (Java) client, but this is definately something I'd like to do more of. I'm currently tidying my code so I can put the patch and initial tests up, but further testing interop will be following that. Cheers Andy On 6/8/06, Simon Laws [EMAIL PROTECTED] wrote: Hi Andy Re. Axis2C support for C++ SCA. Are you also looking at testing against the Java SCA Axis2 WS binding? If so this ties in nicely with the series 4 tests here http://wiki.apache.org/ws/Tuscany/Interop;. I added some words, towards the end of this page, about what we might test here so would appreciate any input on the type of test that make sense. Regards Simon On 6/5/06, Andrew Borley [EMAIL PROTECTED] wrote: Hi All, I've been taking a look at Axis2C recently and I see that one of the items on the list for the ApacheCon C++ release ( http://wiki.apache.org/ws/Tuscany/TuscanyCpp/Tasks) is an Axis2C Web Service Entrypoint (jira# TUSCANY-429). I've had a quick hack around and got something going, so unless someone's already taken it, I'm happy to own this task and turn my hackings into something uselful! Cheers Andrew
Re: Update on cross language interop testing
Ok, Ant, that sounds like a good compromise. So we have two copies of the common resources 1/ tuscany/interop/resources 2/ tuscanyphp/sdo-1.0.1/tests/interop The test programs themselves live in test directories under the appropriate projects. I'm just refactoring the XSD/XML files a little so when they are done I'll raise a JIRA and attach patches. Anyone else have a view? On 6/19/06, ant elder [EMAIL PROTECTED] wrote: In the Java project we already have some interop tests in tuscany/java/testing/interop/ so for these SDO ones how about tuscany/java/testing/interop/sdo? How about a mix for options (2) and (3) - I can understand duplicating the resources across Apache and PECL, but at least within Apache Tuscany could all the language impls share a common resource folder, maybe tuscany/interop/resources? Note I don't really mind so if either of these suggestions make things more difficult I'm fine with the suggestions in your email. ...ant On 6/19/06, Simon Laws [EMAIL PROTECTED] wrote: I've done more work on this. The issues that have been raised so far Java None raised so far C++ JIRA444 - Causes crash JIRA445 JIRA447 JIRA448 - Causes crash - Pete has fixed JIRA449 JIRA450 JIRA451 JIRA452 JIRA453 Off the two that cause runtime crashes 444 remains unresolved. The others lead to output that doesn't match the input. PHP As C++ (as it is based on C++) plus PECL7878 PECL7879 PECL7880 Of these 7878 and 7879 as usability issues. I'm going to take a look a 7880 There is still more testing to do, particularly around Axis2 between Java and C++, but most things have been working so far so my confidence levels are building. From my previous mail on this subject I'm still undecided about where to put the code. There is not much code involved but it needs to live somewhere. I've been assuming to date that the test code will happily live within each project somewhere (where is a good place in each project structure?), for example, it could be Java: tuscany/java/sdo/impl/src/test/org/apache/Tuscany/sdo/interop C++: tuscany/cpp/sdo/runtime/core/interop PHP: tuscanyphp/sdo-1.0.1/tests/interop The input files (XSD, XML, DDL etc) themselves are common across all projects. So where should they live? 1/ Just pick on project, C++/Java/PHP, and put the common files there. You have to check the files out and move them around to set up for testing 2/ Duplicate the common files across all projects. Leads to maintenance problem but is convenient for running the tests 3/ Create some common interop directory somewhere. Don't know where this would be As the projects are spread across Apache and PECL I would go for option 2 and suffer the maintenance burden. I.e. to test PHP I don't really want to ask the developer to go and retrieve files from Apache. Thoughts? Simon
Re: Update on cross language interop testing
Mmmm. My fault. I mean that to be pecl/php... not tuscanyphp. On 6/20/06, Caroline Maynard [EMAIL PROTECTED] wrote: I'm confused about this proposal. Didn't you say earlier that the php tests would be added to the PECL repository? In which case the logical place would be pecl/sdo/tests/interop/. But (I'm guessing) your tuscanyphp directory is in the Apache repository. And why is it tuscanyphp/ and not tuscany/php/ like the other languages? Ok, Ant, that sounds like a good compromise. So we have two copies of the common resources 1/ tuscany/interop/resources 2/ tuscanyphp/sdo-1.0.1/tests/interop The test programs themselves live in test directories under the appropriate projects. I'm just refactoring the XSD/XML files a little so when they are done I'll raise a JIRA and attach patches. Anyone else have a view? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML Comparison
Thanks Oisin, I don't seen anything at [1] that specifically mentions canonicalization. Is the sample code you refer to the DocumentTracer.java? S On 6/22/06, Oisin Hurley [EMAIL PROTECTED] wrote: Hi Simon, However this test compares everything and I am hitting the problem which is touched on in http://issues.apache.org/jira/browse/TUSCANY-427, i.e. my input xml files have comments and my output XML files don't so the current equalXML... function always returns false. What might be useful here is some XML Canonicalization (c14n) code that will munge both XML sources to a canonical form and then compare those forms. This does things like elide extraneous whitespace in the elements, reorder attributes using a particular algorithm, optionally remove comments and that kind of thing. The Canonical XML spec is at [0], but you might be more interested in the example implementation which you can find in the Xerces samples at [1]. A candidate for that testutils jar that Dan was talking about, perhaps. regards Oisin [0] http://www.w3.org/TR/xml-c14n [1] http://svn.apache.org/viewvc/xerces/java/trunk/samples/sax/ Writer.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML Comparison
Doh, thanks Oisin. I was looking in the wrong file.
S
On 6/23/06, Oisin Hurley [EMAIL PROTECTED] wrote:
On 22 Jun 2006, at 22:24, Simon Laws wrote:
Thanks Oisin, I don't seen anything at [1] that specifically mentions
canonicalization. Is the sample code you refer to the
DocumentTracer.java?
The code itself is just a writer, but it has an option to have the
output canonicalized - if you look in the java src [0] you will
see
/** Sets whether output is canonical. */
public void setCanonical(boolean canonical) {
fCanonical = canonical;
} // setCanonical(boolean)
regards
Oisin
[0] http://svn.apache.org/viewvc/xerces/java/trunk/samples/sax/
Writer.java?view=markup
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: prerequisites
Hi Eric, welcome I'm relatively new to this myself and, as I'm not not focusing on the Java implementation, I can't help you with Java details much but I did read a good article by Martin Fowler about the inversion of control/dependency injection pattern [1]. There was also a recent telcon about the changes proposed to support the recursive assembly model in Java so this would be a place where you could look to find out how things might change going forward. Jim posted about this [2]. Also have a go with the current code base and ask questions here or on the IRC [3] [1] http://www.martinfowler.com/articles/injection.html [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg03853.html [3] http://incubator.apache.org/tuscany/getinvolved.html Regards Simon On 6/22/06, Eric Le Goff [EMAIL PROTECTED] wrote: Hi everyone, I am an average Java developer and my goal would be to get deeper understanding of the open source development process in general and I chose the Tuscany project architecture / implementation / tooling etc... as a starting point (since SOA sounds like an interesting concept). My question is about pre-requisite readings / knowledge / training before some newbie java developer like me is able to provide some help with code and document. There are indeed so many things for a newcomer to read : - this mailing list - the project wiki pages - the specs (0.9 already obsolete ?) - more (???) I know how to use Eclipse, maven, how to find JIRA issues ...but I would need some help when it comes to the project architecture (from 4 ft, not the details...), development concepts like dependency injection, or what do you mean by recursive model... I know the general answer is Read the f... Manual but all I need is the correct pointers and a global methodology. In other words I would like to know what shold be absolutely known before pretending contributing to the project. And if all this does not sound stupid ;) I promise to work hard and learn these prerequisite and maybe some day to contribute to the code :)... thanks for your help Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML Comparison
Hi ant, what is the process to determine whether the license for this piece of software is acceptable for use during Tuscany development. I assume, if we use it, we woudln't use it during runtime and hence wouldn't need to redistribute or reference it from released packages. S On 6/22/06, ant elder [EMAIL PROTECTED] wrote: What about using http://xmlunit.sourceforge.net/, i think some of the other Apache WS projects use that. ...ant On 6/22/06, Simon Laws [EMAIL PROTECTED] wrote: I want to add a little automated testing to the interop suite to compare input XML files with output XML files. I note that there is XML comparison function in org.apache.tuscany.sdo.test.TestUtil However this test compares everything and I am hitting the problem which is touched on in http://issues.apache.org/jira/browse/TUSCANY-427, i.e. my input xml files have comments and my output XML files don't so the current equalXML... function always returns false. For my local testing what I have done is edited the class to: 1/ Change all the static operations to non static operations 2/ Add a member variable to describe what should be ignored when testing for equality 3/ Add outputs in each failure case to record what causes XML files to be marked as not equal 4/ Added a string output stream member variable to capture all of this output 5/ Added a getReport method to return the contents of this output stream if you are interested in why the XMLs differ Now this is all very well and good but of course this breaks anything that relies on this class having static methods (it's used in about 50 places). So I can make a slight change to maintain the static interface. The question is would you rather I: A/ Make a special version for me and not patch the original (not ideal) B/ Create a patch for the original As an aside there already seems to be two copies of this file, in: tuscany\java\sdo\impl\src\test\java\org\apache\tuscany\sdo\test tuscany\java\sdo\tools\src\test\java\org\apache\tuscany\sdo\test Is there a good reason for this? If not, which one stays? Simon
Java SDO Date exception?
I need a little help interpreting an exception I'm getting from an SDO test I have. I'm porting some interop tests to HEAD so that I can create a patch and (having updated to use the new DAS) the relational SDO no longer works with date fields . All other types I'm testing are OK. The test basically creates a new data object by copying all the properties from an existing data object one by one. The offending line is newRow.setDate(ADATE, row.getDate(ADATE) ); The exception that is thrown is below. When I comment this line out everything works fine. I'm not sure where to start looking as there is lots of emf stuff here that I'm not familiar with. I took a look at the JIRAs for SDO and it doesn't appear that this is happening for anyone else so there may be something wrong with my setup. If this exception means anything to anyone who knows emf let me know. java.lang.ClassCastException: The value of type 'class org.eclipse.emf.ecore.xml .type.internal.XMLCalendar' must be of type 'class java.util.Date' at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDele gateSingleDataStatic.validate(EStructuralFeatureImpl.java:2046) at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDele gateSingleData.dynamicSet(EStructuralFeatureImpl.java:1942) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicSet (BasicEObjectI mpl.java:686) at org.apache.tuscany.sdo.impl.DynamicDataObjectImpl.eDynamicSet (Dynamic DataObjectImpl.java:147) at org.apache.tuscany.sdo.impl.DataObjectImpl.eSet( DataObjectImpl.java:1 439) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet( BasicEObjectImpl.jav a:642) at org.apache.tuscany.sdo.impl.DataObjectImpl.set( DataObjectImpl.java:14 0) at org.apache.tuscany.sdo.util.DataObjectUtil.setDate( DataObjectUtil.jav a:570) at org.apache.tuscany.sdo.impl.DataObjectImpl.setDate( DataObjectImpl.jav a:493) at org.apache.tuscany.test.interop.sdo.rdb.InteropTestReadWriteRDB.test5 ReadAndWriteRDB(InteropTestReadWriteRDB.java:178) at org.apache.tuscany.sdo.test.xml.InteropTestCase.testReadWriteRDB (Inte ropTestCase.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.junit.JUnitTestSet.execute( JUnitTestSet.jav a:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes tSet(AbstractDirectoryTestSuite.java:135) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab stractDirectoryTestSuite.java:122) at org.apache.maven.surefire.Surefire.run(Surefire.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su refireBooter.java:225) at org.apache.maven.surefire.booter.SurefireBooter.main( SurefireBooter.j ava:747) Thanks Simon
Re: [jira] Commented: (TUSCANY-495) Java Interop Testing
Ah, meant to comment that out. Sorry for making you do this twice Ant. For now if you could comment out the dependency for DB2 in the POM and it should run but you will see a class not found exception for the DB2 test. This is OK for now. I don't believe that these tests are patched into the main build yet. I need to write a Derby test case but haven't go round to it yet. I could also do with finding a way to get params into the code so that I can actually turn off the DB2 testing if the POM doesn't specify the jars (I guess I could trap the exception but a bit nasty) any ideas? S On 6/26/06, ant elder [EMAIL PROTECTED] wrote: In this patch the pom.xml in the sdo/rdb folder has a dependency on some IBM DB2 jars which aren't in any maven repository: 1) com.ibm.db2:db2jcc:jar:8.2 2) com.ibm.db2:db2jcc_license_cu:jar:8.2 There's a commented out dependency for derby, could I just uncomment that and delete thedb2 ones, or what? ...ant On 6/26/06, Simon Laws (JIRA) tuscany-dev@ws.apache.org wrote: [ http://issues.apache.org/jira/browse/TUSCANY-495?page=comments#action_12417802 ] Simon Laws commented on TUSCANY-495: I should have noted that the 2nd patch (patch-interopsdo-java.txt) includes a new project test dependency on XMLUnit ( http://xmlunit.sourceforge.net/). Java Interop Testing Key: TUSCANY-495 URL: http://issues.apache.org/jira/browse/TUSCANY-495 Project: Tuscany Type: New Feature Components: Java SDO Implementation Versions: Java-M1 Environment: Windows XP Reporter: Simon Laws Assignee: ant elder Priority: Minor Attachments: patch-interopresources.txt, patch-interopsdo-java.txt Patches to include first pass interop testing - /tuscany/interop - interop resources - /tuscany/java/testing/interop - simple java interop tests that use the resources above -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java SDO Date exception?
Hi Frank I checked out the java project again. The only updates I go were to do with DAS tests AliasTest.java ExceptionTest.java BooksConfigWithAlias.xml No new java code. I still get the exception. Is there one of the provided tests that I should run to try and tie it down a bit? Regards Simon On 6/26/06, Frank Budinsky [EMAIL PROTECTED] wrote: Hi Simon, We fixed some bugs related to Date types, late last week (Thursday or Friday). If you don't have the very latest SDO code, please try with the latest, and see if it fixes this problem. Otherwise, it looks like there still may be another bug. Thanks, Frank. Simon Laws [EMAIL PROTECTED] wrote on 06/26/2006 05:25:43 AM: I need a little help interpreting an exception I'm getting from an SDO test I have. I'm porting some interop tests to HEAD so that I can create a patch and (having updated to use the new DAS) the relational SDO no longer works with date fields . All other types I'm testing are OK. The test basically creates a new data object by copying all the properties from an existing data object one by one. The offending line is newRow.setDate(ADATE, row.getDate(ADATE) ); The exception that is thrown is below. When I comment this line out everything works fine. I'm not sure where to start looking as there is lots of emf stuff here that I'm not familiar with. I took a look at the JIRAs for SDO and it doesn't appear that this is happening for anyone else so there may be something wrong with my setup. If this exception means anything to anyone who knows emf let me know. java.lang.ClassCastException: The value of type 'class org.eclipse.emf.ecore.xml .type.internal.XMLCalendar' must be of type 'class java.util.Date' at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDele gateSingleDataStatic.validate(EStructuralFeatureImpl.java:2046) at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDele gateSingleData.dynamicSet(EStructuralFeatureImpl.java:1942) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicSet (BasicEObjectI mpl.java:686) at org.apache.tuscany.sdo.impl.DynamicDataObjectImpl.eDynamicSet (Dynamic DataObjectImpl.java:147) at org.apache.tuscany.sdo.impl.DataObjectImpl.eSet( DataObjectImpl.java:1 439) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet( BasicEObjectImpl.jav a:642) at org.apache.tuscany.sdo.impl.DataObjectImpl.set( DataObjectImpl.java:14 0) at org.apache.tuscany.sdo.util.DataObjectUtil.setDate( DataObjectUtil.jav a:570) at org.apache.tuscany.sdo.impl.DataObjectImpl.setDate( DataObjectImpl.jav a:493) at org.apache.tuscany.test.interop.sdo.rdb.InteropTestReadWriteRDB.test5 ReadAndWriteRDB(InteropTestReadWriteRDB.java:178) at org.apache.tuscany.sdo.test.xml.InteropTestCase.testReadWriteRDB (Inte ropTestCase.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.junit.JUnitTestSet.execute( JUnitTestSet.jav a:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes tSet(AbstractDirectoryTestSuite.java:135) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab stractDirectoryTestSuite.java:122) at org.apache.maven.surefire.Surefire.run(Surefire.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su refireBooter.java:225
[C++] SCA usability
I've spent a little time playing with the C++ SCA implementation. I want to replay my understanding to see if it is correct. When constructing a service that will have a web service binding you have to provide a number of things including myservice.h to define the class that is the service myservice.cpp to implement the class that is the service myservice.wsdl to describe the service interface Of course you have to provide the appropriate SCA configuration files also, e.g. sca.module, Tuscany-model.config etc, and you have to SCAGen the interface to generate proxies and wrappers. - At this point in time there is no WSDL - C++ or C++ - WSDL tooling Hence at present there is a requirement that you, as the developer of the service, ensure that the interface described in C++ matches the interface described in WSDL. - At this point in time there is no C++ SDO support for static types Hence interfaces to services that take SDOs will always descibe the interface in terms of DataObjects. - The web services interfaces adopt the doc/literal/wrapped pattern Hence the WSDL has to be constructed/used carefully in this respect to match the expectations of the runtime and the types that are used to describe WSDL message elements are not the types that find their way in and out of the C++ service implementation. It is the types that are themselves wrapped that find themselves presented to and returned from the service implementation. Is this understanding correct? Is there some way we can provide a helper function (or simple generator) that demonstrates how a service operation should handle the types it is presented with and produce a type for return based on the WSDL description of the interface? This could be as simple as providing a mechanism to print out a template C++ operation based on the model formed from the WSDL. Maybe this could be done with good documentation and samples but I'm not sure. I sense that there will be mistakes made in this area by new users;-) Regards Simon
Re: Java SDO Date exception?
OK, thanks Kevin. Have to admit that I haven't got round to trying what Fuhwei Lwo suggested. S On 6/27/06, Kevin Williams [EMAIL PROTECTED] wrote: I pulled the latest from the repository and the DAS test suite fails for me too with the same exception: java.lang.ClassCastException: The value of type 'class org.eclipse.emf.ecore.xml.type.internal.XMLCalendar' must be of type 'class java.util.Date' This appears to be an SDO regression and I will open a JIRA. I have also commented out the broken DAS test so that the build will complete. Thanks, --Kevin Simon Laws wrote: Hi Frank I checked out the java project again. The only updates I go were to do with DAS tests AliasTest.java ExceptionTest.java BooksConfigWithAlias.xml No new java code. I still get the exception. Is there one of the provided tests that I should run to try and tie it down a bit? Regards Simon On 6/26/06, Frank Budinsky [EMAIL PROTECTED] wrote: Hi Simon, We fixed some bugs related to Date types, late last week (Thursday or Friday). If you don't have the very latest SDO code, please try with the latest, and see if it fixes this problem. Otherwise, it looks like there still may be another bug. Thanks, Frank. Simon Laws [EMAIL PROTECTED] wrote on 06/26/2006 05:25:43 AM: I need a little help interpreting an exception I'm getting from an SDO test I have. I'm porting some interop tests to HEAD so that I can create a patch and (having updated to use the new DAS) the relational SDO no longer works with date fields . All other types I'm testing are OK. The test basically creates a new data object by copying all the properties from an existing data object one by one. The offending line is newRow.setDate(ADATE, row.getDate(ADATE) ); The exception that is thrown is below. When I comment this line out everything works fine. I'm not sure where to start looking as there is lots of emf stuff here that I'm not familiar with. I took a look at the JIRAs for SDO and it doesn't appear that this is happening for anyone else so there may be something wrong with my setup. If this exception means anything to anyone who knows emf let me know. java.lang.ClassCastException: The value of type 'class org.eclipse.emf.ecore.xml .type.internal.XMLCalendar' must be of type 'class java.util.Date' at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDele gateSingleDataStatic.validate(EStructuralFeatureImpl.java:2046) at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDele gateSingleData.dynamicSet(EStructuralFeatureImpl.java:1942) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicSet (BasicEObjectI mpl.java:686) at org.apache.tuscany.sdo.impl.DynamicDataObjectImpl.eDynamicSet (Dynamic DataObjectImpl.java:147) at org.apache.tuscany.sdo.impl.DataObjectImpl.eSet( DataObjectImpl.java:1 439) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet( BasicEObjectImpl.jav a:642) at org.apache.tuscany.sdo.impl.DataObjectImpl.set( DataObjectImpl.java:14 0) at org.apache.tuscany.sdo.util.DataObjectUtil.setDate( DataObjectUtil.jav a:570) at org.apache.tuscany.sdo.impl.DataObjectImpl.setDate( DataObjectImpl.jav a:493) at org.apache.tuscany.test.interop.sdo.rdb.InteropTestReadWriteRDB.test5 ReadAndWriteRDB(InteropTestReadWriteRDB.java:178) at org.apache.tuscany.sdo.test.xml.InteropTestCase.testReadWriteRDB (Inte ropTestCase.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.junit.JUnitTestSet.execute( JUnitTestSet.jav a:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes
[C++/SDO] can you turn off xsi:type generation?
The C++/SDO implementation generates an xsi:type attribute on the root element of documents written out via the XMLHelper. Is it possible to turn this feature off? Regards Simon
Re: [Java/SDO] is xsi:type on root element suported?
OK, thanks Frank, I tried that and the effect is the same regarless of whether the xsi:type reference to an extension or not. xsi:type does work with both extensions and base classes if it's used on an element that is not the root element. I have opened a jira (505) and added this information. Regards Simon On 6/28/06, Frank Budinsky [EMAIL PROTECTED] wrote: Hi Simon, I think it should work. Your example is a little strange in that the xsi:type is the same as the actual element type. Usually the xsi:type is used to identify a subtype, so maybe the implementation has a bug that only turns up in this case. Is there someone with more XML expertise then me that knows if xsi:type equal to the actual type is valid XML? Could you please try changing your example to include a subtype: complexType name=ExtendedComplexTypeRootType complexContent xsd:extension base=tns:ComplexTypeRootType/ /complexContent /complexType and then use it as the xsi:type in your instance. I think that should definitely work. Also, could you please open a JIRA for this issue. Thanks, Frank. Simon Laws [EMAIL PROTECTED] wrote on 06/28/2006 10:04:35 AM: If I read the following doc: tns:RootElement xmlns:p=commonj.sdo xmlns:tns=http://www.apache.org/tuscany/interop; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.apache.org/tuscany/interop interop01.xsd SimpleTypeWithNameSimpleTypeWithName/SimpleTypeWithName /tns:RootElement With the following schema schema xmlns=http://www.w3.org/2001/XMLSchema; targetNamespace=http://www.apache.org/tuscany/interop; xmlns:tns=http://www.apache.org/tuscany/interop; include schemaLocation=interop10.xsd/ !-- top level test type -- complexType name=ComplexTypeRootType sequence !-- simple types -- element name=SimpleTypeWithName type=tns:SimpleTypeWithNameType/ /sequence /complexType element name=RootElement type=tns:ComplexTypeRootType/ /schema The I get a valid document (doc) with some data objects in it out of the following code: FileInputStream inFileStream = new FileInputStream (inFileName); XMLDocument doc = XMLHelper.INSTANCE.load(inFileStream); If I try in read in (note I have added and xsi:type attribute): tns:RootElement xmlns:p=commonj.sdo xsi:type=tns:ComplexTypeRootType xmlns:tns=http://www.apache.org/tuscany/interop; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.apache.org/tuscany/interop interop01.xsd SimpleTypeWithNameSimpleTypeWithName/SimpleTypeWithName /tns:RootElement The XMLHelper silently makes an empty document, i.e. the root element is null. Is this by design? I.e. is xsi:type unsupported? Regards Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] SCA usability
The other thing that helps is turning logging on on ther server. I start the axis server with the following script... set TUSCANY_SCACPP_LOGGING=9 set PATH= ... axis2_http_server.exe -l 4 So in the first instance what we need to do is work up all of these hints and tips into a step by step service construction/debugging guide. I think pete/andy already have words in this area so we should review and extend if required. Secondly we need to think, post M1, what we add to make life easier, for example C++2WSDL WSDL2C++ Specific logging of the points that cause problems Debug helpers What else should be on this list? On 6/27/06, Edward Slattery [EMAIL PROTECTED] wrote: Having been working on the Windows build today, I agree with your summary. There might even be problems to less new users. My saviours this afternoon hav been: 1) Running the axis http server in the debugger - loading the extra sca_ws dll and setting breakpoints. 2) Checking very very carefully the env vars TUSCANY_SCACPP, TUSCANY_SDOCPP, TUSCANY_SCACPP_SYSTEM_ROOT. 3) Checking them again. 4) checking the logs in the axis logs directory - Calculator_blocking gives you what happens when the service is loaded. axis2.log tells you if the service didnt load. - I just asked the asix2c people to add some details to the log to say which dll in which path didnt load - then I think we have all bases covered. On 27/06/06, Simon Laws [EMAIL PROTECTED] wrote: I've spent a little time playing with the C++ SCA implementation. I want to replay my understanding to see if it is correct. When constructing a service that will have a web service binding you have to provide a number of things including myservice.h to define the class that is the service myservice.cpp to implement the class that is the service myservice.wsdl to describe the service interface Of course you have to provide the appropriate SCA configuration files also, e.g. sca.module, Tuscany-model.config etc, and you have to SCAGen the interface to generate proxies and wrappers. - At this point in time there is no WSDL - C++ or C++ - WSDL tooling Hence at present there is a requirement that you, as the developer of the service, ensure that the interface described in C++ matches the interface described in WSDL. - At this point in time there is no C++ SDO support for static types Hence interfaces to services that take SDOs will always descibe the interface in terms of DataObjects. - The web services interfaces adopt the doc/literal/wrapped pattern Hence the WSDL has to be constructed/used carefully in this respect to match the expectations of the runtime and the types that are used to describe WSDL message elements are not the types that find their way in and out of the C++ service implementation. It is the types that are themselves wrapped that find themselves presented to and returned from the service implementation. Is this understanding correct? Is there some way we can provide a helper function (or simple generator) that demonstrates how a service operation should handle the types it is presented with and produce a type for return based on the WSDL description of the interface? This could be as simple as providing a mechanism to print out a template C++ operation based on the model formed from the WSDL. Maybe this could be done with good documentation and samples but I'm not sure. I sense that there will be mistakes made in this area by new users;-) Regards Simon
[C++/Java] Interop update
Ok, I had some success over the last couple of days in getting C++ SCA to
talk to Java SCA. The executive summary is that we got a message from C++
client to C++ SCA service on to a Java SCA service and all the way back
again. Yippeee.
The scenario is based on the BigBank for C++ sample that Ed has been working
on. Here is what we had to do to make it work...
The sample is as follows.
C++ Client -- C++ AccountService/AccountDataService -- Java
StockQuoteService
The intention is to add a PHP client in the future but that is not there
yet. In theory we could also add the Java BB client to the front end but the
java interface to BB was more complex that we wanted to tackle in the first
instance so that is something else that could be done if we choose.
We chose to make a new Java StockQuoteService as the interface is so simple.
We took the external WSDL and implemented that, i.e. the float getQuote
(String) interface.
The current Java Big Bank sample does provide a local Java StockQuoteService
implementation but it seems that this has a slightly different interface,
i.e. it implements getQuotes which takes and returns arrays. Anyhow we made
a new external service which is in itself an SCA module with a java
implementation and exposing a service with the getQuote interface. We also
made a java client to test this with. There are no patches for these yet as
we are not sure where to put them. My vote is to put them in the
java/testing/interop dir but am open to suggestions.
The C++ BB sample is expecting an external service with the getQuote
interface so we changed the sca.module file to point to the new Java SCA
StockQuoteService running in the Java M1 configured tomcat container.
There were a few problems along the way to getting a complete end to end
run.
1/ The use of doc/lit/wrapped caused confusion in the first instance and
combined with the outstanding problem that C++/SDO cannot handle root
elements with only simple types in (
http://issues.apache.org/jira/browse/TUSCANY-488) there was some debate
about what the WSDL for the account service should look like. This is an
except of what we ended up with for the type descriptions...
xsd:complexType name=GetAccountReportType
xsd:sequence
xsd:element name=customerID
xsd:complexType
xsd:sequence
xsd:element name=customerID type=xsd:string /
/xsd:sequence
/xsd:complexType
/xsd:element
/xsd:sequence
/xsd:complexType
xsd:element name=getAccountReport type=tns:GetAccountReportType/
xsd:complexType name=AccountReport
xsd:sequence
xsd:element name=checking type=tns:CheckingAccount
maxOccurs=unbounded/
xsd:element name=savings type=tns:SavingsAccount
maxOccurs=unbounded/
xsd:element name=stocks type=tns:StockAccount
maxOccurs=unbounded/
/xsd:sequence
/xsd:complexType
xsd:element name=getAccountReportResponse
xsd:complexType
xsd:sequence
xsd:element name=accountReport type=tns:AccountReport/
/xsd:sequence
/xsd:complexType
/xsd:element
The odd extra level of CustomerId came from the confusion around 488 but I
believe could be removed (http://issues.apache.org/jira/browse/TUSCANY-507)
but the client has been coded this way currently so we didn't try and fix
it.
2/ Another thing to note about the WSDL is the use of anonymous types. My
preference is not to do this by default but of this doesn't work at present
(http://issues.apache.org/jira/browse/TUSCANY-500 ).
3/ Changed GetQuote to getQuote in
StockQuoteService_StockQuoteExternal_Proxy.cpp and associated
StockQuoteExternal files (http://issues.apache.org/jira/browse/TUSCANY-508)
4/ Axis2Client.cpp ln 282 LOGINFO_2 causes an edna in the case where the
server being called returns an error. I changed this to a LOGINFO, i.e.
no var args, and carried on. I didn't go back and try it with successful
responses. (http://issues.apache.org/jira/browse/TUSCANY-509)
5/ StockQuoteExternalService.h/StockQuoteServiceImpl.cpp has incorrect
return type for getQuote const char * should be float. (
http://issues.apache.org/jira/browse/TUSCANY-510)
6/ The C++ SDO implementation produces XML with an xsi:type attribute on the
root element. The java container doesn't like this (
http://issues.apache.org/jira/browse/TUSCANY-505). We changed the C++
implementation to take these out temporarily to see if we could progress.
SDOXMLWriter.cpp ln722 ish replace
rc = xmlTextWriterWriteAttributeNS(writer,
SDOXMLString(xsi), SDOXMLString(type),
NULL,
/*SDOXMLString(
http://www.w3.org/2001/XMLSchema-instance;),*/
SDOXMLString(dataObject-getType().getName()));
with
if (!isRoot)
{
rc = xmlTextWriterWriteAttributeNS(writer,
SDOXMLString(xsi), SDOXMLString(type),
NULL,
/*SDOXMLString(
Tuscany weekly IRC chat log (July-06-2006)
Here is the discussion from today's IRC chat (sorry about the slightly wonky format as I had to cut and paste from my client). The topics of discussion were content updates to the Tuscany web site and the process by which the web site is produced. In summary we are going to progress the following this week. jboyneslayout and nav, slaws what is SCA, kgoodson what is SDO kevinDAS cr22rc help with the web site production toolkit and site content as time allows dwheelerimage stuff Of course everyone is invited to help out here so don't be shy. Simon kgoodsonshall we pick up where we were on improving the website with a clickable picture before OSCon? kgoodsonwhat other topics? --|kevin (n= [EMAIL PROTECTED]) has joined #tuscany slawsi'm just back on line form leave and saw mail about the website, e.g. the nice clickable picture, but i'm confused about what the status is and who is doing what - can you give a quick update rfengThe OSCON is coming, I guess we need to improve the web site as we agreed last time, right? --|simonnash (n= [EMAIL PROTECTED] ) has joined #tuscany simonnashhi slawshi simon - kelivin is just kicking off a discussion on website progress jboyneshi, sorry, I'm back as well kgoodsonhi simon, it's a little quiet, but we are just about to take stock of where the website improvemnt is/is going -- there don't seem tyo be any other topics at the moment -- jeremy has had to disappear jboyneswe have a clckable on the wiki, yes? kgoodsoni liked raymonds picture, with the clickable links, there was aanother picture on the mailing list i think that I cant locate at the moment which was a higher level modular diagram kgoodsonhes, clickable http://wiki.apache.org/ws-data/attachments/Tuscany(2f)SCADiagram/attachments/sca.htm http://wiki.apache.org/ws-data/attachments/Tuscany%282f%29SCADiagram/attachments/sca.htm rfengthe other one is for tuscany architectural layers, I guess slawsyes - high level - was attached as a zip to a mail rfengcan somebody upload it to WIKI as well? kgoodsonyes, am i right in thinking that the one you, rfeng, have done would be linked to from the higher level one? slawshigh level one was on a mail from Venkata Krishnan rfengthe one I prototyped is for SCA composite PM --|jmarino ([EMAIL PROTECTED] ) has joined #tuscany slawscan;t find it in the dev archive for some reason kgoodsonhave found it, i will attach to wiki slawsok - great jboynesI checked the toolkit from the incubator site into my sandbox - has anyone had a chance to look at it? slawssorry jeremy - have been out - is this the toolkit for building the website? kgoodsonwiki seems not to want to create a new page, waiting .. jboynesslaws: yes, the toolkit I mentioned last time which has been picked up by a couple of projects (including the incubator) rfengjust point to the new URL you want to place the new page, then you'll see the option to create the new page slawsjboynes: ok - ta - haven't tried it yet but can give it a whirl jboynesok jboynesanyone else interested or does anyone have any alternatives? kgoodsonyes i'm intersted but i don't really know what it buys us jboynesit's simpler than mvn slawsso, coming back to my first question, who is doing what on the website? jboynesI set up the toolkit thing and was waiting for feedback cr22rcjust a command to run for mvn jboynes? cr22rcxdocs are a pain ... does it get us away from that ? rfengI'm stuck in something else this week jboynesyou can use xml or html slawsok - and rfeng made the clickable diagram and we also have a top level diagram contributed - anything else? dwheelerI believe I was going to try and come up with a prettier diagram(s) for the clickable diagram interface. cr22rcI need to look at the other TK too see what it buys us dwheelerbased on the ones we have kgoodsonfinally i have the architecture diag n the wiki ... kgoodson http://wiki.apache.org/ws/Tuscany/ClickableImages?action=show cr22rcto do the site now it's mvn site ... and then mvn site-deploy (which publishes it ) jboynesI think the big difference is that there's less going on than with mvn site jboyneseverything is in one place and not spread around different modules cr22rcmost of the site is just under site cr22rcthe one thing we don't get with mvn I think is tabs on the top... don't think you can do that. jboyneswith the toolkit you get raw html so can do anything jboynesbut you need to do everything .. kgoodsonjust to summarize, we were looking for the tabs of http://geronimo.apache.org/ with the image navigation style of http://incubator.apache.org/servicemix/
Re: Tuscany weekly IRC chat log (July-06-2006)
That of course should read July-17-06 On 7/17/06, Simon Laws [EMAIL PROTECTED] wrote: Here is the discussion from today's IRC chat (sorry about the slightly wonky format as I had to cut and paste from my client). The topics of discussion were content updates to the Tuscany web site and the process by which the web site is produced. In summary we are going to progress the following this week. jboyneslayout and nav, slaws what is SCA, kgoodson what is SDO kevinDAS cr22rc help with the web site production toolkit and site content as time allows dwheelerimage stuff Of course everyone is invited to help out here so don't be shy. Simon kgoodsonshall we pick up where we were on improving the website with a clickable picture before OSCon? kgoodsonwhat other topics? --|kevin (n= [EMAIL PROTECTED]) has joined #tuscany slawsi'm just back on line form leave and saw mail about the website, e.g. the nice clickable picture, but i'm confused about what the status is and who is doing what - can you give a quick update rfengThe OSCON is coming, I guess we need to improve the web site as we agreed last time, right? --|simonnash (n= [EMAIL PROTECTED] ) has joined #tuscany simonnashhi slawshi simon - kelivin is just kicking off a discussion on website progress jboyneshi, sorry, I'm back as well kgoodsonhi simon, it's a little quiet, but we are just about to take stock of where the website improvemnt is/is going -- there don't seem tyo be any other topics at the moment -- jeremy has had to disappear jboyneswe have a clckable on the wiki, yes? kgoodsoni liked raymonds picture, with the clickable links, there was aanother picture on the mailing list i think that I cant locate at the moment which was a higher level modular diagram kgoodsonhes, clickable http://wiki.apache.org/ws-data/attachments/Tuscany(2f)SCADiagram/attachments/sca.htm http://wiki.apache.org/ws-data/attachments/Tuscany%282f%29SCADiagram/attachments/sca.htm rfengthe other one is for tuscany architectural layers, I guess slawsyes - high level - was attached as a zip to a mail rfengcan somebody upload it to WIKI as well? kgoodsonyes, am i right in thinking that the one you, rfeng, have done would be linked to from the higher level one? slawshigh level one was on a mail from Venkata Krishnan rfengthe one I prototyped is for SCA composite PM --|jmarino (n= [EMAIL PROTECTED] ) has joined #tuscany slawscan;t find it in the dev archive for some reason kgoodsonhave found it, i will attach to wiki slawsok - great jboynesI checked the toolkit from the incubator site into my sandbox - has anyone had a chance to look at it? slawssorry jeremy - have been out - is this the toolkit for building the website? kgoodsonwiki seems not to want to create a new page, waiting .. jboynesslaws: yes, the toolkit I mentioned last time which has been picked up by a couple of projects (including the incubator) rfengjust point to the new URL you want to place the new page, then you'll see the option to create the new page slawsjboynes: ok - ta - haven't tried it yet but can give it a whirl jboynesok jboynesanyone else interested or does anyone have any alternatives? kgoodsonyes i'm intersted but i don't really know what it buys us jboynesit's simpler than mvn slawsso, coming back to my first question, who is doing what on the website? jboynesI set up the toolkit thing and was waiting for feedback cr22rcjust a command to run for mvn jboynes? cr22rcxdocs are a pain ... does it get us away from that ? rfengI'm stuck in something else this week jboynesyou can use xml or html slawsok - and rfeng made the clickable diagram and we also have a top level diagram contributed - anything else? dwheelerI believe I was going to try and come up with a prettier diagram(s) for the clickable diagram interface. cr22rcI need to look at the other TK too see what it buys us dwheelerbased on the ones we have kgoodsonfinally i have the architecture diag n the wiki ... kgoodson http://wiki.apache.org/ws/Tuscany/ClickableImages?action=show cr22rcto do the site now it's mvn site ... and then mvn site-deploy (which publishes it ) jboynesI think the big difference is that there's less going on than with mvn site jboyneseverything is in one place and not spread around different modules cr22rcmost of the site is just under site cr22rcthe one thing we don't get with mvn I think is tabs on the top... don't think you can do that. jboyneswith the toolkit you get raw html so can do anything jboynesbut you need to do everything .. kgoodson
Off Topic - Subclipse observation
I have just worked out why I have observed confusing behaviour with subclipse. I am playing with Jeremy's new web site layout in the sandbox so wanted to update to his latest files. I have the tuscany project checked out in my workspace so I navigated to sandbox/site, right clicked to team/synchronize with repository This poped up the team synchronize view with something like the following tree view on the left hand side tuscany sandbox/site sandbox/site/site-author some files sandbox/site/site-deploy some more files I wanted all this stuff so I clicked at the top level and selected update. What this appears to do is update to whole of the tuscany project not just the subset of files shown to be different in the synchronize view. This leads to a VERY long update which invariably fails. As it fails for me so often before it actually starts downloading anything this took me a few goes to work out what was going on. What I have to do is select each directory in this view and ask it to be updated individually. I have a slightly old version so I'm going to upgrade to see if that changes the behaviour.
Re: Tuscany Overview Block Diagram
Hi Venkata I'm just making some changes to the overview diagram so that it covers more than Java. Do you have the original source. What app did you use? Am just making changes in a bit editor at the mo so I remember what I want but would be good to do it properly. S On 7/11/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Luciano, My sincere apologies. I left that out since I don't know much of the DAS landscape in Tuscany. However, I have now included that. Please let me what I have stated there sounds ok. Finally, I wish to again reiterate that the diagram that I have put in is just to trigger some ideas to what we might ultimately host on the web-site. For example I want to be able to position blocks that represent databindings, transport bindings and various containers. Right now all of it is bundled up. Thanks - Venkat On 7/11/06, Luciano Resende [EMAIL PROTECTED] wrote: Hi Looking at this, we are missing DAS component, that would be well represented as a parallel box (to the left) of SDO box. Could you please add that to the diagram you created ? On 7/10/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, This is a vague mental map of Tuscany and not what I wish to put in the site. This is just to trigger some perspectives to the what we can present in the site. The level of aggregation is pretty high in this diagram. I am sure we can explode the blocks a little further or position them differently to provide a better picture of Tuscany. If not anything I hope to atleast correct what I am imagining of Tuscany :-) Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards Luciano Resende - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany Overview Block Diagram
Actually I got a little confused here as we now have Davids top level diagram also. I have the source for that so I'll fiddle there a bit. What I want to do is get the diagrams in some kind of possition in the new website layout so we can see where they fit and whether the diagrams are appropriate. The details of the diagrams can of course still be changed going forward. S On 7/20/06, Simon Laws [EMAIL PROTECTED] wrote: Hi Venkata I'm just making some changes to the overview diagram so that it covers more than Java. Do you have the original source. What app did you use? Am just making changes in a bit editor at the mo so I remember what I want but would be good to do it properly. S On 7/11/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Luciano, My sincere apologies. I left that out since I don't know much of the DAS landscape in Tuscany. However, I have now included that. Please let me what I have stated there sounds ok. Finally, I wish to again reiterate that the diagram that I have put in is just to trigger some ideas to what we might ultimately host on the web-site. For example I want to be able to position blocks that represent databindings, transport bindings and various containers. Right now all of it is bundled up. Thanks - Venkat On 7/11/06, Luciano Resende [EMAIL PROTECTED] wrote: Hi Looking at this, we are missing DAS component, that would be well represented as a parallel box (to the left) of SDO box. Could you please add that to the diagram you created ? On 7/10/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, This is a vague mental map of Tuscany and not what I wish to put in the site. This is just to trigger some perspectives to the what we can present in the site. The level of aggregation is pretty high in this diagram. I am sure we can explode the blocks a little further or position them differently to provide a better picture of Tuscany. If not anything I hope to atleast correct what I am imagining of Tuscany :-) Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards Luciano Resende - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New site layout
I'm getting a bit confused about the various diagrams and updates proposed for the new website layout so I collected them all together. Well the ones I know about at least. Apologies for any I have missed. The author files are attached to Kelvin's JIRA (https://issues.apache.org/jira/browse/TUSCANY-568). These files belong in sandbox/site. If you want a quick peek the publish files are also attached to the JIRA for information. The issue that we have to tackle convincingly is that we are more than a Java project. So on the one hand we want to dive into the details of SCA/SDO. On the other we want to explore what Java and C++ implementations provide. Difficult to do clearly through a single diagram. I have had a go at solving this by putting language specific links on the main page. Thoughts? We also have to get the content right of course so maybe people can comment on what they think the appropriate level of content in the various sections is now that we have some sections with something in. Regards Simon
Re: Diagram Drafts
Hi Rick I tried to put together all the diagrams I had seen and spin up a version of the new site layout. Unfortunately my mail describing this took 7 hours to either get out of our local systems or be reflected by the Apache mail list. So apologies if we have overlapped. The work is attached to this JIRA ( https://issues.apache.org/jira/browse/TUSCANY-568). I think Pete was applying it. Regards Simon On 7/20/06, Rick [EMAIL PROTECTED] wrote: Trying to get some of this stuff together. I'm moving in the DAS stuff from Luciano but that seemed very limited and a lot missing. It also has references to microsoft mso objects that need to go. I put in Venkata diagram that is clickable to the technologies. I'll try to replace that with David's work. Is this at a state where we are relatively happy with this? I rather not do the image map a zillion times if you get my drift. kelvin goodson wrote: I've added some embrionic SDO stuff as a patch in Tuscany 568. Would some kind committer like to put it up for me please? Are we all still aiming to get this replacement live before OSCon? If so I'll put some more focus into bringing across the fundamental bulk of SDO material from the existing site, and making things prettier, but I'm reluctant to spend all my time between now and travelling to OSCon on this if the likelihood is that we won't switch over in the near term. On 7/19/06, Luciano Resende [EMAIL PROTECTED] wrote: So, If i'm guessing right, the idea is to have this diagram on the main page, and once a user clicks on a link, let's say DAS, it would go to a DAS overview page ? So we could probably make each component that is listed on the tuscany web site outline to have an overview page and redirect the user to that page when a component is clicked...As long as that page is not a text only one :) I have a proposal for the DAS content on the attached DAS overview.zip I'd need some help on updating the diagram using the same tool David is using, as it looks like MAC only... And I'll build the object diagram for DAS to be part of the DAS Overview as well... Thanks - Luciano On 7/19/06, Jim Marino [EMAIL PROTECTED] wrote: Cool - thanks! On Jul 19, 2006, at 12:35 PM, David Wheeler wrote: oh, ok. Lets try this agian zipped. -David Wheeler On 7/19/06, Jim Marino [EMAIL PROTECTED] wrote:I found out yesterday the list strips PDFs but if you zip them it goes through. Jim On Jul 19, 2006, at 12:22 PM, David Wheeler wrote: Sure thing Jim. Should be attached On 7/19/06, Jim Marino [EMAIL PROTECTED] wrote: Hi David, Is there any chance you can pdf it? Jim On Jul 19, 2006, at 11:56 AM, David Wheeler wrote: The original format is an Omnigraffle document, but I have attached a zip that contains the graffle as well as copies in svg and visio. I modefied it to better reflect the seperation of the Core Runtime and SDO / Tools, as well as adding Spring to the list of extensions. On 7/19/06, Rick [EMAIL PROTECTED] wrote: Also what is the source format... anyway you can upload it ? send email attachment? David Wheeler wrote: Ah, I was under the impression that the other images posted so far were for brain storming more than final drafts, Intented to be replaced. On 7/19/06, Rick [EMAIL PROTECTED] wrote: David, I just checked in an overview that made it clickable with another image that was already posted. When you click on a section it takes you to one of the links on top. I'm not partial, I can easily switch out. David Wheeler wrote: I've come up with a couple possible diagrams for thw website navigation: Tuscany Block Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f) http://wiki.apache.org/ws-data/attachments/Tuscany%282f%29 ClickableImages/attachments/Tuscany-Block.png SCA Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f) http://wiki.apache.org/ws-data/attachments/Tuscany%282f%29 ClickableImages/attachments/Tusc-SCA-Diagram.png Let me know what you guys think. -David Wheeler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Tuscany-Block.zip - To unsubscribe, e-mail: [EMAIL
Re: [C++/Java] Interop update
I've got to that age where I've started replying to my own mails. Oh dear. Looking back at the JIRAs raised when doing the interop testing a couple of weeks ago I may have missed a detail. When trying to get round JIRA505, which describes the problem with having xsi:type in the wrapper element, I also inadvertently made a temporary change to stop C++ producing duplicate namespace definitions. This may be a problem in its own right. I have raised a separate JIRA (http://issues.apache.org/jira/browse/TUSCANY-570). Also, with JIRA505 itself, comments from the SDO team indicate that SCA/Java may be doing something slightly strange with the way it loads types in at configuration time ready for when SOAP messages are received. How do I reclassify this bug to associate it with Java/SCA also so that it doesn't fall between the SCA and SDO teams? I realize that this stuff is a little in flux at the moment due to the changes in head but we still need to make interop work when head settles down again. Regards Simon On 6/29/06, Simon Laws [EMAIL PROTECTED] wrote: Ok, I had some success over the last couple of days in getting C++ SCA to talk to Java SCA. The executive summary is that we got a message from C++ client to C++ SCA service on to a Java SCA service and all the way back again. Yippeee. The scenario is based on the BigBank for C++ sample that Ed has been working on. Here is what we had to do to make it work... The sample is as follows. C++ Client -- C++ AccountService/AccountDataService -- Java StockQuoteService The intention is to add a PHP client in the future but that is not there yet. In theory we could also add the Java BB client to the front end but the java interface to BB was more complex that we wanted to tackle in the first instance so that is something else that could be done if we choose. We chose to make a new Java StockQuoteService as the interface is so simple. We took the external WSDL and implemented that, i.e. the float getQuote (String) interface. The current Java Big Bank sample does provide a local Java StockQuoteService implementation but it seems that this has a slightly different interface, i.e. it implements getQuotes which takes and returns arrays. Anyhow we made a new external service which is in itself an SCA module with a java implementation and exposing a service with the getQuote interface. We also made a java client to test this with. There are no patches for these yet as we are not sure where to put them. My vote is to put them in the java/testing/interop dir but am open to suggestions. The C++ BB sample is expecting an external service with the getQuote interface so we changed the sca.module file to point to the new Java SCA StockQuoteService running in the Java M1 configured tomcat container. There were a few problems along the way to getting a complete end to end run. 1/ The use of doc/lit/wrapped caused confusion in the first instance and combined with the outstanding problem that C++/SDO cannot handle root elements with only simple types in ( http://issues.apache.org/jira/browse/TUSCANY-488) there was some debate about what the WSDL for the account service should look like. This is an except of what we ended up with for the type descriptions... xsd:complexType name=GetAccountReportType xsd:sequence xsd:element name=customerID xsd:complexType xsd:sequence xsd:element name=customerID type=xsd:string / /xsd:sequence /xsd:complexType /xsd:element /xsd:sequence /xsd:complexType xsd:element name=getAccountReport type=tns:GetAccountReportType/ xsd:complexType name=AccountReport xsd:sequence xsd:element name=checking type=tns:CheckingAccount maxOccurs=unbounded/ xsd:element name=savings type=tns:SavingsAccount maxOccurs=unbounded/ xsd:element name=stocks type=tns:StockAccount maxOccurs=unbounded/ /xsd:sequence /xsd:complexType xsd:element name=getAccountReportResponse xsd:complexType xsd:sequence xsd:element name=accountReport type=tns:AccountReport/ /xsd:sequence /xsd:complexType /xsd:element The odd extra level of CustomerId came from the confusion around 488 but I believe could be removed (http://issues.apache.org/jira/browse/TUSCANY-507) but the client has been coded this way currently so we didn't try and fix it. 2/ Another thing to note about the WSDL is the use of anonymous types. My preference is not to do this by default but of this doesn't work at present ( http://issues.apache.org/jira/browse/TUSCANY-500 ). 3/ Changed GetQuote to getQuote in StockQuoteService_StockQuoteExternal_Proxy.cpp and associated StockQuoteExternal files ( http://issues.apache.org/jira/browse/TUSCANY-508) 4/ Axis2Client.cpp ln 282 LOGINFO_2 causes an edna in the case where the server being called returns an error. I changed this to a LOGINFO, i.e. no var args, and carried on. I didn't go back
Re: [C++/Java] Interop update
Hi Frank, Thanks for that. How did you do it. I looked at the JIRA and I could see how you change the category like that? Is it a committer thing? Regards Simon On 7/21/06, Frank Budinsky [EMAIL PROTECTED] wrote: Simon, I reassigned TUSCANY-505 to the SCA component for further investigation. Frank. Simon Laws [EMAIL PROTECTED] wrote on 07/21/2006 07:44:35 AM: I've got to that age where I've started replying to my own mails. Oh dear. Looking back at the JIRAs raised when doing the interop testing a couple of weeks ago I may have missed a detail. When trying to get round JIRA505, which describes the problem with having xsi:type in the wrapper element, I also inadvertently made a temporary change to stop C++ producing duplicate namespace definitions. This may be a problem in its own right. I have raised a separate JIRA (http://issues.apache.org/jira/browse/TUSCANY-570). Also, with JIRA505 itself, comments from the SDO team indicate that SCA/Java may be doing something slightly strange with the way it loads types in at configuration time ready for when SOAP messages are received. How do I reclassify this bug to associate it with Java/SCA also so that it doesn't fall between the SCA and SDO teams? I realize that this stuff is a little in flux at the moment due to the changes in head but we still need to make interop work when head settles down again. Regards Simon On 6/29/06, Simon Laws [EMAIL PROTECTED] wrote: Ok, I had some success over the last couple of days in getting C++ SCA to talk to Java SCA. The executive summary is that we got a message from C++ client to C++ SCA service on to a Java SCA service and all the way back again. Yippeee. The scenario is based on the BigBank for C++ sample that Ed has been working on. Here is what we had to do to make it work... The sample is as follows. C++ Client -- C++ AccountService/AccountDataService -- Java StockQuoteService The intention is to add a PHP client in the future but that is not there yet. In theory we could also add the Java BB client to the front end but the java interface to BB was more complex that we wanted to tackle in the first instance so that is something else that could be done if we choose. We chose to make a new Java StockQuoteService as the interface is so simple. We took the external WSDL and implemented that, i.e. the float getQuote (String) interface. The current Java Big Bank sample does provide a local Java StockQuoteService implementation but it seems that this has a slightly different interface, i.e. it implements getQuotes which takes and returns arrays. Anyhow we made a new external service which is in itself an SCA module with a java implementation and exposing a service with the getQuote interface. We also made a java client to test this with. There are no patches for these yet as we are not sure where to put them. My vote is to put them in the java/testing/interop dir but am open to suggestions. The C++ BB sample is expecting an external service with the getQuote interface so we changed the sca.module file to point to the new Java SCA StockQuoteService running in the Java M1 configured tomcat container. There were a few problems along the way to getting a complete end to end run. 1/ The use of doc/lit/wrapped caused confusion in the first instance and combined with the outstanding problem that C++/SDO cannot handle root elements with only simple types in ( http://issues.apache.org/jira/browse/TUSCANY-488) there was some debate about what the WSDL for the account service should look like. This is an except of what we ended up with for the type descriptions... xsd:complexType name=GetAccountReportType xsd:sequence xsd:element name=customerID xsd:complexType xsd:sequence xsd:element name=customerID type=xsd:string / /xsd:sequence /xsd:complexType /xsd:element /xsd:sequence /xsd:complexType xsd:element name=getAccountReport type=tns:GetAccountReportType/ xsd:complexType name=AccountReport xsd:sequence xsd:element name=checking type=tns:CheckingAccount maxOccurs=unbounded/ xsd:element name=savings type=tns:SavingsAccount maxOccurs=unbounded/ xsd:element name=stocks type=tns:StockAccount maxOccurs=unbounded/ /xsd:sequence /xsd:complexType xsd:element name=getAccountReportResponse xsd:complexType xsd:sequence xsd:element name=accountReport type=tns:AccountReport/ /xsd:sequence /xsd:complexType /xsd:element The odd extra level of CustomerId came from the confusion around 488 but I believe could be removed (http://issues.apache.org/jira/browse/TUSCANY-507) but the client has been coded this way currently so we didn't try and fix it. 2/ Another thing to note about
Scenarios: was Using Scenarios
I believe there is some agreement about using scenarios so I've started a new thread as the old was getting a little long I got round to taking a look at the scenarios page on the wiki. Hope I'm looking at the right place ( http://wiki.apache.org/ws/Tuscany/TuscanyJava/Scenarios#preview). This may be a bit controversial but I'd like to have a few descriptions, scenarios, samples (call them what you will) that take more of a business problem view on the value of SCA. From there we can show the path to the individual technical use cases mentioned. For example, we may expect the technical reader to understand why JSON or Celtix are useful but we want the reader (either inside or outside the project) to understand why there is value in SCA in making these pluggable bindings. I.e. what role is SCA playing? Any how I've done some very brief sketches. I'm completely happy if these live on a separate page so they don't mess up the technical scenarios. I'm also happy to put some effort in to expand these thoughts if the team aren't dead set against them. Help and other thoughts most welcome of course.
Re: Tuscany Overview Block Diagram
Agreed. One thing I think we need is a higher level diagram that puts the single SCA runtime into the context of a SCA based system containing remote references. There is something like this in the spec that shows a system with composites and a reference to a remote web service. Maybe we can put that at the top of the first page. I'll have a play and see how it looks. Regards Simon On 7/20/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Right Simon, I guess David's picture is the one we must go forward with. Just that we must also give some thoughts to the 'distribution' and 'integration' aspects and see how we can express this. Chek my prev. mail on what I mean by this. Thanks - Venkat On 7/20/06, Simon Laws [EMAIL PROTECTED] wrote: Actually I got a little confused here as we now have Davids top level diagram also. I have the source for that so I'll fiddle there a bit. What I want to do is get the diagrams in some kind of possition in the new website layout so we can see where they fit and whether the diagrams are appropriate. The details of the diagrams can of course still be changed going forward. S On 7/20/06, Simon Laws [EMAIL PROTECTED] wrote: Hi Venkata I'm just making some changes to the overview diagram so that it covers more than Java. Do you have the original source. What app did you use? Am just making changes in a bit editor at the mo so I remember what I want but would be good to do it properly. S On 7/11/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Luciano, My sincere apologies. I left that out since I don't know much of the DAS landscape in Tuscany. However, I have now included that. Please let me what I have stated there sounds ok. Finally, I wish to again reiterate that the diagram that I have put in is just to trigger some ideas to what we might ultimately host on the web-site. For example I want to be able to position blocks that represent databindings, transport bindings and various containers. Right now all of it is bundled up. Thanks - Venkat On 7/11/06, Luciano Resende [EMAIL PROTECTED] wrote: Hi Looking at this, we are missing DAS component, that would be well represented as a parallel box (to the left) of SDO box. Could you please add that to the diagram you created ? On 7/10/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, This is a vague mental map of Tuscany and not what I wish to put in the site. This is just to trigger some perspectives to the what we can present in the site. The level of aggregation is pretty high in this diagram. I am sure we can explode the blocks a little further or position them differently to provide a better picture of Tuscany. If not anything I hope to atleast correct what I am imagining of Tuscany :-) Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards Luciano Resende - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparison between live tuscany website and what's being proposed as part of Tuscany-568
Starting to look good. I still have the source for the verview/cpp/java imagesI made tbased on David's diagram. Problem is they are visio diagrams. I feel that I should attach to the JIRA for safe keeping but haven't got rounf to try converting to another format. I will have a quick look over the next 30 mins and give the new site a once over also. Regards Simon On 7/26/06, Rick [EMAIL PROTECTED] wrote: I may be miss interpreting or reading too much in what you stated. But I kindly request that patches and updates be to the tuscany\sandbox\site\site-author files. That they've been run through the build tool ok using the tuscany\sandbox\site\build script. It's not needed to include in the patch/update the site-publish. Also I'd like to get the source for the images checked in so others can edit. And a few lines what tools (openoffice?) was or could be used to edit them maybe a readme in the images directory. Thanks kelvin goodson wrote: I'll try to get some more SDO content done in any spare moments while here at OSCon. I've reformatted the SDO Java overview that's currently on the WIKI so that its suitable for dropping in, but I haven't got time to fix up all the links riight now, so hopefully I'll put a patch up later today. On 26/07/06, Jim Marino [EMAIL PROTECTED] wrote: Rick, This is a major improvement over what we currently have and I really like how things have been cleaned up and streamlined. I'm sure I will have some suggestions in the furture but I agree this should be published ASAP assuming others agree. Some minor comments that we may want to consider at some point later on: 1. In the Java projects section, splitting things down a bit further among SCA, DAS and SDO. I think we should make it more apparent the technologies may be used as well as built independently. Within SCA, I think we may want to split this even further between extensions and core at some point. 2. On the Java graphic, we should list more hosting platforms at some point (e.g. J2EE app servers, OSGi, whatever) Jim On Jul 26, 2006, at 6:35 AM, Rick wrote: I've added in the news, and moved reporting bugs as suggested, added a link to the blog and fixed several bad links. I didn't want the left menu to become cluttered, so I didn't put in the runtime stuff since I was thinking that information would be added to the individual Java, C++, DAS etc content pages. I'm of a different opinion, I think we should now get this sandbox site up live and use the opportunity that the OSCON BOF gives us to get first hand feedback. What's the worse that can come of it ? People don't like this either? Well should that be the case its best to get that information now before we make it absolutely perfect. I'm really opposed to starting another effort of producing a hybrid of the two in a mad dash which is not where we wanted to go in the first place. Luciano Resende wrote: I took sometime today to evaluate what's available today on the live tuscany website and what's being proposed as part of Tuscany-568. Looks like couple page links on the Tuscany-568 are still not implemented ( e.g page not found), but I'm assuming these issues are going to be fixed, so I concentrate on areas that are available today and missing on the new site structure. Categories: Tuscany: Looks like the new proposed site gets rid of News and Documentation sections, and adds License, ASF, Javadoc and TCK SCA Runtime for Java : Missing on the new site structure SDO for Java : Missing on the new site structure Relational Data Access Service for Java : Missing on the new site structure Sca Runtime for C++ : Missing on the new site structure SDO for C++: Missing on the new site structure Community: Reporting bugs moved to development (altough i think comunity in general is interested on this as well), Requirements missing, Commiters and Documentation section added Development: Java project, C++ Project and Building the site sections are missing. Added Roadmap, Source code, Code standards (link to wiki), Issue tracking (moved from Comunity) and dependencies As I think the main idea was to incorporate user feedback that our website had too many text and very little images, diagrams, etc I have the following suggestion to get a new and improved version on-line for OSCON timeframe : - Maintain the current website outline navigation structure (the one available today on live tuscany website) - Replace the main page with the one proposed on Tuscany-568 - Add an overview page for each module (e.g DAS overview with DAS diagram and high level object diagram), and the main page diagram would link to this module overview page - On the SCA, SDO and DAS section on the left panel, remove the release link as they all point to same main download page. With this, i think we
Re: Comparison between live tuscany website and what's being proposed as part of Tuscany-568
I can't find an way to conver viso to open office that works. Tried most of the suggestions I can find on the web. However the diagrams are not so complicated that I can't redraw them by hand. If someone has already made the conversion save me some effort and speak up now while I go and get some food. Simon On 7/26/06, Simon Laws [EMAIL PROTECTED] wrote: Starting to look good. I still have the source for the verview/cpp/java imagesI made tbased on David's diagram. Problem is they are visio diagrams. I feel that I should attach to the JIRA for safe keeping but haven't got rounf to try converting to another format. I will have a quick look over the next 30 mins and give the new site a once over also. Regards Simon On 7/26/06, Rick [EMAIL PROTECTED] wrote: I may be miss interpreting or reading too much in what you stated. But I kindly request that patches and updates be to the tuscany\sandbox\site\site-author files. That they've been run through the build tool ok using the tuscany\sandbox\site\build script. It's not needed to include in the patch/update the site-publish. Also I'd like to get the source for the images checked in so others can edit. And a few lines what tools (openoffice?) was or could be used to edit them maybe a readme in the images directory. Thanks kelvin goodson wrote: I'll try to get some more SDO content done in any spare moments while here at OSCon. I've reformatted the SDO Java overview that's currently on the WIKI so that its suitable for dropping in, but I haven't got time to fix up all the links riight now, so hopefully I'll put a patch up later today. On 26/07/06, Jim Marino [EMAIL PROTECTED] wrote: Rick, This is a major improvement over what we currently have and I really like how things have been cleaned up and streamlined. I'm sure I will have some suggestions in the furture but I agree this should be published ASAP assuming others agree. Some minor comments that we may want to consider at some point later on: 1. In the Java projects section, splitting things down a bit further among SCA, DAS and SDO. I think we should make it more apparent the technologies may be used as well as built independently. Within SCA, I think we may want to split this even further between extensions and core at some point. 2. On the Java graphic, we should list more hosting platforms at some point (e.g. J2EE app servers, OSGi, whatever) Jim On Jul 26, 2006, at 6:35 AM, Rick wrote: I've added in the news, and moved reporting bugs as suggested, added a link to the blog and fixed several bad links. I didn't want the left menu to become cluttered, so I didn't put in the runtime stuff since I was thinking that information would be added to the individual Java, C++, DAS etc content pages. I'm of a different opinion, I think we should now get this sandbox site up live and use the opportunity that the OSCON BOF gives us to get first hand feedback. What's the worse that can come of it ? People don't like this either? Well should that be the case its best to get that information now before we make it absolutely perfect. I'm really opposed to starting another effort of producing a hybrid of the two in a mad dash which is not where we wanted to go in the first place. Luciano Resende wrote: I took sometime today to evaluate what's available today on the live tuscany website and what's being proposed as part of Tuscany-568. Looks like couple page links on the Tuscany-568 are still not implemented ( e.g page not found), but I'm assuming these issues are going to be fixed, so I concentrate on areas that are available today and missing on the new site structure. Categories: Tuscany: Looks like the new proposed site gets rid of News and Documentation sections, and adds License, ASF, Javadoc and TCK SCA Runtime for Java : Missing on the new site structure SDO for Java : Missing on the new site structure Relational Data Access Service for Java : Missing on the new site structure Sca Runtime for C++ : Missing on the new site structure SDO for C++: Missing on the new site structure Community: Reporting bugs moved to development (altough i think comunity in general is interested on this as well), Requirements missing, Commiters and Documentation section added Development: Java project, C++ Project and Building the site sections are missing. Added Roadmap, Source code, Code standards (link to wiki), Issue tracking (moved from Comunity) and dependencies As I think the main idea was to incorporate user feedback that our website had too many text and very little images, diagrams, etc I have the following suggestion to get a new and improved version on-line for OSCON timeframe : - Maintain the current website outline navigation
Re: [C++ SCA] Language bindings embedding the runtime
That's a great idea Pete. I would also like to add that we are just starting to think about SCA in PHP and is would seem sensible to reuse the work you have done in C++. So if we could also engineer the C++ implementation so that it is easy to concume as the basis for another implementation, as well as supporting different language bindings, that would be splendid. In particular I'd probably like to be able to take parts of the implementation because, for example, we may want the model but not all of the binding framework. So having some clean separation of concerns inside of the C++ implementation may be useful. I'm not saying it isn't nicely layed out at the moment of course as I've only just started looking at the code. On this point I've been making some notes (attached to the wiki here http://wiki.apache.org/ws/Tuscany/TuscanyCpp/InsideCppM1) about what I've been finding out about how the C++ implemenation works currently. Maybe we could extend this and then hatch a devious plan about how to refactor for recursive composition, add new language bindings and make it consumable. Regards Simon On 8/2/06, Pete Robbins [EMAIL PROTECTED] wrote: That sounds like an ineresting idea. I'll look into it. Now that the release is out of the way I want to open up discussion on here about restructuring the C++ runtime to enable it to support multiple language bindings (C++, PHP,...) and also to support the latest Assembly Specification for the recursive model. I'm getting some thoughts together to kick this off. Cheers, On 02/08/06, ant elder [EMAIL PROTECTED] wrote: How about a C++ JavaScript extension to match the one we have in Java/SCA? You can use SpiderMonkey [1] which also has E4X support and then we'd be able to switch SCA JavaScript components btw the Java and C++ runtimes. Using E4X would mean you don't have the databinding issues when using web services as the data stays as XML, and you could show us how much faster your C++ runtime is compared to the Java one ;) [1] http://www.mozilla.org/js/spidermonkey/ ...ant (sorry a bit late replying but I'm still catching up on mail) On 7/21/06, Andrew Borley [EMAIL PROTECTED] wrote: Hi, I've been loosely thinking about what it will take to provide extra language bindings to Tuscany SCA C++ and how that relates to providing the runtime as an extension within a language. I've put my early thoughts up on the wiki here: http://wiki.apache.org/ws/Tuscany/TuscanyCpp/LanguageBindingsAndRuntimes I guess with the new spec there will be quite a lot of changes, so this may all become redundant, but I was just thinking how I'd like to see Python or Ruby components running alongside C++ ones (and, of course, Java ones too!) :-) Cheers Andy -- Pete
Interop bug category
Not sure who manages these things but can we have a top level bug category for the Interop tests? I need to create a JIRA for additions to the tests. Regards Simon
Re: Interop bug category
Many thanks ant. S On 8/3/06, ant elder [EMAIL PROTECTED] wrote: Any committer can manage them. I've added you an 'Interop' component. ...ant On 8/3/06, Simon Laws [EMAIL PROTECTED] wrote: Not sure who manages these things but can we have a top level bug category for the Interop tests? I need to create a JIRA for additions to the tests. Regards Simon
[Interop] Categorization of interop bugs
Ant made an interop bug category for me so I would like to associate interop related bugs with that (as well as with the components to which they relate). Can a kindly committer oblige and categorize the following as interop bugs alongside their original categorizations. These bugs come from efforts to make C++ and Java interoperate in the context of the BigBank sample. Java === http://issues.apache.org/jira/browse/TUSCANY-505 http://issues.apache.org/jira/browse/TUSCANY-570 (B.t.w - who is working on the WS binding for the new Java SCA runtime? Would be useful to have a discussion about these two in the context of how SDO is used. I haven't had a look in detail about how SDO was used by Java SCA in M1 but there was something strange going on) C++ === http://issues.apache.org/jira/browse/TUSCANY-511 http://issues.apache.org/jira/browse/TUSCANY-510 http://issues.apache.org/jira/browse/TUSCANY-509 http://issues.apache.org/jira/browse/TUSCANY-508 http://issues.apache.org/jira/browse/TUSCANY-507 http://issues.apache.org/jira/browse/TUSCANY-500 http://issues.apache.org/jira/browse/TUSCANY-491 http://issues.apache.org/jira/browse/TUSCANY-488 The following bugs come from testing C++ SDO against the Interop test XML schema and files. C++ === http://issues.apache.org/jira/browse/TUSCANY-475 http://issues.apache.org/jira/browse/TUSCANY-453 http://issues.apache.org/jira/browse/TUSCANY-452 http://issues.apache.org/jira/browse/TUSCANY-451 http://issues.apache.org/jira/browse/TUSCANY-450 http://issues.apache.org/jira/browse/TUSCANY-449 http://issues.apache.org/jira/browse/TUSCANY-448 http://issues.apache.org/jira/browse/TUSCANY-447 http://issues.apache.org/jira/browse/TUSCANY-445 http://issues.apache.org/jira/browse/TUSCANY-444 Thanks Simon
Re: [C++] Debugging and printing SDO data structures
I think that would be a splendid idea. When I was playing with big bank (which I hope to get back to shortly) I ended up using the SDOUtils:printDataObject() method at strategic points in the code. As you say it's very difficult to tell what's going on in GDB. Regards Simon On 8/7/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I'm finding SDO DataObjects a little difficult to inspect with the GDB debugger. Is there anything that could be done to help debuggers display the contents of SDO DataObjects, properties and types? Just an idea... but would it make sense to add to SDO DataObject a string member containing its serialized contents, only when compiled with the debug option maybe... Would that help? Any thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Debugging and printing SDO data structures
Well you can construct expressions in gdb and have them execute but its not as convenient as having the code do it for you. Taking both points of view on board how about a function that you can call on the data object that prints its contents out that is only compiled in for debug, i.e. subject of a #define. Removes the need for the unitiated to go searching for the util method but doesn't rely on the data object keeping a string representation up to date on every change. S On 8/8/06, kelvin goodson [EMAIL PROTECTED] wrote: For a Java/Eclipse environment there is the Expressions view in the debug perspective which can be used to execute a set of run-time supplied code snippets each time the execution is paused , e.g. SDOUtil.printDataObject (dob) , so that pretty much gives the convenience of the embedded string representation without the performance overhead (or for less frequent update you can use the Display view). Do you have something similar in your development environment? On 07/08/06, Pete Robbins [EMAIL PROTECTED] wrote: I think the SDOUtils method is the way to go. Maintaining a serialized form in the DO would killl performance as it would have to be re-serialized on every change. I have a printDataObject and printTypes methods in SCA which I think are better than the ones in SDOUtil ;-) Maybe we should add the extra function into SDOUtils. Cheers, On 07/08/06, Simon Laws [EMAIL PROTECTED] wrote: I think that would be a splendid idea. When I was playing with big bank (which I hope to get back to shortly) I ended up using the SDOUtils:printDataObject() method at strategic points in the code. As you say it's very difficult to tell what's going on in GDB. Regards Simon On 8/7/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I'm finding SDO DataObjects a little difficult to inspect with the GDB debugger. Is there anything that could be done to help debuggers display the contents of SDO DataObjects, properties and types? Just an idea... but would it make sense to add to SDO DataObject a string member containing its serialized contents, only when compiled with the debug option maybe... Would that help? Any thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete -- Best Regards Kelvin Goodson
Re: [C++] A portable build system?
You can use cygwin to do gcc compiles for windows. It comes with automake (don't know what version) and can be integrated with Eclipse CDT. S On 8/9/06, Pete Robbins [EMAIL PROTECTED] wrote: I believe automake can run on Windows using some linux portability layer (I forget what it's called). I'll need to look into it some more. We should also see what other Apache c/C++ projects use. On 09/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I'm still in the process of (re)learning C++ and related GCC automake, configure etc. so maybe this is a dumb question.. but would there be any way to make our builds portable between Linux and Windows, instead of using completely different build systems, i.e. Automake on Linux and VC++ on Windows? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: [C++] A portable build system?
You can make native windows dll's and executables. The last time I was involved in this kind of build we actually used ant on windows and linux in top of gcc (in cygwin for windows) to drive the build for the large number of different systems we had to support (there were some strange HPC type ones). IMHO though the result was rather too complicated. I don't know automake but if you have it working well on linux it would be good to see how well it supports a windows build before doing anything more exotic. S On 8/10/06, Pete Robbins [EMAIL PROTECTED] wrote: On 10/08/06, Simon Laws [EMAIL PROTECTED] wrote: You can use cygwin to do gcc compiles for windows. It comes with automake (don't know what version) and can be integrated with Eclipse CDT. S That's the one! Does it produce dll's that run native on windows or does the output depend on other libraries? -- Pete
Re: [C++] SCA Extensions
On 8/16/06, Pete Robbins [EMAIL PROTECTED] wrote: This looks like a really good plan. I have two questions: 1. Do we really need another XML file to describe the extension, name the library and associate it with an implementation type? As a first step at least, I think it would be great to have a very simple scheme where you just drop a library named implementation.python in a Tuscany extensions or plugins directory, or just name the library how you want but have in it an extern public functtion that will return the XSD QNames that the library understands? Yeah, I was thinking a drop it in a directory approach would be good, but I couldn't think how to expose the information we need - specifically naming the library/xsd file and/or having a set of known public functions is a good way to go. I will do this first - possibly an xml config file would also be useful - we should be able to support both? Sebastien's suggestion is how I would do it. What we need is to define an extensions spi. We need a directory that contains the schema for the exensions. We will load all of these so the model loader can parse all the scdl into SDO. We need an extensions directory where we will load any library that is in it. We then call the spi function which will return a list of XSD QNames supported by the extension. When the model loader encounters an extension it passes the SDO to a method in the extension library to deal with. I'm about to hack about, I mean tidy up, the model loader code so I'd like to take on this part of the extesnion story if that's ok with everyone? I'll come up with a suggested SPI. Cheers, -- Pete Pete Not sure I've got the extent of what you are suggesting. So a couple of queations. You are suggesting 3 directories. 1/ Model schema 2/ Extensions, i.e. libraries implementing the extension scaffolding. 3/ Components that are implemented according to the extension (or do these just float around with the rest of the solution files) Can we also consider that the extension might be contributing to the model via annotations, over and above and information that is presented in XML side files. So in my case I might have a component defined with something like implementation.php class=MyComponent source=MyComponent.php/ And I want the model to be completed based on the information in MyComponent.php rather than MyComponent.componentType. So can we have whatever the mechanism that loads componentTypes have a plug point into the extension system so that annotation info can be loaded. I'm keen on this because most developers in languages like Perl and PHP won't take too kindly to having to write XML side files. Regards Simon
Re: [C++] SCA Extensions
On 8/16/06, Andrew Borley [EMAIL PROTECTED] wrote: On 8/16/06, Pete Robbins [EMAIL PROTECTED] wrote: This looks like a really good plan. I have two questions: 1. Do we really need another XML file to describe the extension, name the library and associate it with an implementation type? As a first step at least, I think it would be great to have a very simple scheme where you just drop a library named implementation.python in a Tuscany extensions or plugins directory, or just name the library how you want but have in it an extern public functtion that will return the XSD QNames that the library understands? Yeah, I was thinking a drop it in a directory approach would be good, but I couldn't think how to expose the information we need - specifically naming the library/xsd file and/or having a set of known public functions is a good way to go. I will do this first - possibly an xml config file would also be useful - we should be able to support both? Sebastien's suggestion is how I would do it. What we need is to define an extensions spi. We need a directory that contains the schema for the exensions. We will load all of these so the model loader can parse all the scdl into SDO. We need an extensions directory where we will load any library that is in it. We then call the spi function which will return a list of XSD QNames supported by the extension. When the model loader encounters an extension it passes the SDO to a method in the extension library to deal with. I'm about to hack about, I mean tidy up, the model loader code so I'd like to take on this part of the extesnion story if that's ok with everyone? I'll come up with a suggested SPI. Sounds good - I'll work on the component language extension ( implementation.xxx) side of things: 1) An SPI to allow Tuscany to invoke a method/function in the extension. Something like: void initialise(DataObjectPtr implXXXDO, mapstring, string initParameters); void invoke(Operation operation); 2) An example wrapper that loads and runs a function in a Python module Cheers Andy Don't you also need some way for the script engine, and particularly any extensions that have been written to get back to the SCA context information (i.e. the model) in the case the the script component makes subsequent calls to downstream components? Possibly part of the initialize although it looks like this is called on each invocation. Is that right? Don't we need some higher level initialization? S
Re: [C++] SCA Extensions architecture
On 8/17/06, Andrew Borley [EMAIL PROTECTED] wrote: Pete, Sounds good to me, I'll definately be interested in reviewing if you have something to show before tomorrow (Friday) afternoon (I'm on holiday for the week after that). The Python stuff I've been doing will need fitting in to the structure you've put together, so I'd be interested in seeing the interfaces you're making for the CPP extension. Once that's in place I guess we'll start looking at binding and interface extensions, and then there's wiring policies, data bindings, etc, etc to look at! Cheers Andy On 8/17/06, Pete Robbins [EMAIL PROTECTED] wrote: I've started playing around with loading extension libraries to support other language extensions and so a wee bit of re-architecture has cpp being an extension language. In other words I'm trying to make a core that is not tied to cpp implementation. This core will roughly be a model loader in line with the assembly model spec with extensions for stuff like implementation.cpp.. and a runtime for resolving wiring and locating services. This is nearly what we have now but without the cpp CI spec api implmentation code (anything under runtime/core/src/osoa...). This will involve a bit of refactoring to remove the unnecessary dependencies from the core to the cpp specific code. What I expect to end up with is libraries for: tuscany_sca - the core assembly model and internal message structure tuscany_sca_cpp - the cpp language extension (extension functions for loading cpp model etc.) tuscany_sca_cpp_osoa - the client side functions defined by the C++ CI spec (ComponentContext etc.) I'm not yet sure if the latter 2 should be the same library, that will depend on their interdependencies. This is not a trivial change and it's tricky to break it down into sensible small chunks so I may start a branch/sandbox to play in for the moment...or if it suddenly all works I'll get it checked in to the trunk asap ;-) It's nearly there but will probably take another day or maybe 2 and it would probably be good for anyone else interested in the cpp code to review it. It won't be near perfect but it will provide a good base for a more modular and extensible runtime. Cheers, Pete Count me in too. Very interested in reviewing the new layout. I'm particularly interested in how you represent the component implementation artifact like implementation.cpp as I want to understand how we mirror the reference representation in an extension. For example, in your restructuring exercise where is ServiceProxy going to end up? I would like some core representation of the proxy (reference) so that I can either use this natively or mirror it in user space in any extension I write. Anyhow I guess I need to wait to see the details of what you are proposing. Are you going to be able to talk us through it? Regards Simon
Re: Sample framework
On 8/18/06, ant elder [EMAIL PROTECTED] wrote: There are quite a few old threads where we've discussed samples, here's just one of them: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200604.mbox/[EMAIL PROTECTED] If we're moving towards multiple Tuscany distributions targeted at different areas then i think its fine (and even desirable) for one of those distributions to contain an entire host environment. One of the good things about the M1 release was that it really did make it easy for new users to get started, just unzip and click on startup. ...ant On 8/18/06, Jim Marino [EMAIL PROTECTED] wrote: On Aug 17, 2006, at 11:21 PM, ant elder wrote: I agree with Jervis, things just running out-of-box is much nicer for first time users than having to fiddle about editing config files. Would an alternative be to change the structure of the samples and move these technology specific samples into the extension that they use. For example, something like having a javascript folder that contained separate projects for the JavaScript container and each JavaScript sample. There would still be lots of helloworld samples, but not all in the one top level samples folder so wouldn't be quite so in your face. I like the idea of moving the samples into the extensions (except maybe the samples that use multiple extensions) and actually think it could correspond to Jeremy's proposal. This would allow us to compartmentalize things more which I think is going to be fundamental to scaling the project. I have several caveats for this though: - there is a clear distinction in the tree between the samples and runtime extension code. In other words, each sample project should not be a sibling to the project containing extension code but should go under a samples folder in separate projects - the extensions are individually built from the core projects and fairly autonomous per my previous email - samples are not built with the check-in build for extensions and are separately distributable In terms of end-user experience, I think things are going to vary greatly depending on the host environment. For example, in our standalone environment, things can be automated fairly easily: 1. User downloads core distribution 2. User downloads and drops in sample distribution and starts the standalone core 3. Core reads the dependencies from the sample SCDL and pulls down the required extensions via the ArtifactFactory from a Maven repository. This would resolve the transitive closure of all extension dependencies. This would allow us to track dependencies for extension libraries such as Spring for free since most projects publish POMs to a Maven repo. 4. If user chooses, they could avoid step 4 and just download the extension and plug it in Something similar to the above could be done for OSGi except the end user would just deploy a core bundle into an existing OSGi host such as Equinox they had installed. If we are deploying to a servlet container, things will likely be more complex but not too much: 1. User downloads sample application and builds it using Maven, which retrieves the core as a dependency and bundles everything into a war. 2 User deploys the sample war If we prepackaged every sample distribution so it could just be dropped in, I think we will wind up with a ton of packaging problems as core will need to be included in every one. I'm pretty firmly against distributions containing an entire host environment, such as Tomcat. I'd prefer we follow projects like Spring, Struts, WebWork, Hibernate (take your pick) and provide distributions which are simple to deploy into containers using some minimal configuration steps. My reason for this is partly practical. First, we should support deploying on a variety of host environments and having to rev versions would be a nightmare. Second, in most data centers I have come across, there is a standard image technologies must accommodate and they will not accept an bundle of stuff. Jim ...ant On 8/17/06, Liu, Jervis [EMAIL PROTECTED] wrote: One thing concerns me would be the out-of-box user experience. For a first time Tuscany user, don't you think it is more user friendly if users only need to follow the readme, go to a directory, run a common, then everything works out-of-box? Speaking in my experience, it does encourage me to explore a new product further if I can set up and run a typical helloworld sample successfully in 5 minutes without any coding. Well, maybe just me being too lazy... ;-) Cheers, Jervis -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 6:54 AM To: tuscany-dev@ws.apache.org Subject: Sample framework We have had a rapid increase in the number of samples recently many of which do essentially the same thing. Some feedback from M1 also
Re: [C++] SCA Extensions architecture
On 8/18/06, Pete Robbins [EMAIL PROTECTED] wrote: Still very much in experimental stage but I recognize your concerns. ServiceProxy is an interesting example. It really belongs with the implementation.cpp but is currently in the core. Do we need this at all for other extensions or is there some other representation of the service? more later... Cheers, On 18/08/06, Simon Laws [EMAIL PROTECTED] wrote: On 8/17/06, Andrew Borley [EMAIL PROTECTED] wrote: Pete, Sounds good to me, I'll definately be interested in reviewing if you have something to show before tomorrow (Friday) afternoon (I'm on holiday for the week after that). The Python stuff I've been doing will need fitting in to the structure you've put together, so I'd be interested in seeing the interfaces you're making for the CPP extension. Once that's in place I guess we'll start looking at binding and interface extensions, and then there's wiring policies, data bindings, etc, etc to look at! Cheers Andy On 8/17/06, Pete Robbins [EMAIL PROTECTED] wrote: I've started playing around with loading extension libraries to support other language extensions and so a wee bit of re-architecture has cpp being an extension language. In other words I'm trying to make a core that is not tied to cpp implementation. This core will roughly be a model loader in line with the assembly model spec with extensions for stuff like implementation.cpp.. and a runtime for resolving wiring and locating services. This is nearly what we have now but without the cpp CI spec api implmentation code (anything under runtime/core/src/osoa...). This will involve a bit of refactoring to remove the unnecessary dependencies from the core to the cpp specific code. What I expect to end up with is libraries for: tuscany_sca - the core assembly model and internal message structure tuscany_sca_cpp - the cpp language extension (extension functions for loading cpp model etc.) tuscany_sca_cpp_osoa - the client side functions defined by the C++ CI spec (ComponentContext etc.) I'm not yet sure if the latter 2 should be the same library, that will depend on their interdependencies. This is not a trivial change and it's tricky to break it down into sensible small chunks so I may start a branch/sandbox to play in for the moment...or if it suddenly all works I'll get it checked in to the trunk asap ;-) It's nearly there but will probably take another day or maybe 2 and it would probably be good for anyone else interested in the cpp code to review it. It won't be near perfect but it will provide a good base for a more modular and extensible runtime. Cheers, Pete Count me in too. Very interested in reviewing the new layout. I'm particularly interested in how you represent the component implementation artifact like implementation.cpp as I want to understand how we mirror the reference representation in an extension. For example, in your restructuring exercise where is ServiceProxy going to end up? I would like some core representation of the proxy (reference) so that I can either use this natively or mirror it in user space in any extension I write. Anyhow I guess I need to wait to see the details of what you are proposing. Are you going to be able to talk us through it? Regards Simon -- Pete Mmm, not sure. I was thinking that in the case of an extension that I would want the C++ SCA model to reflect all of the components and associated services and references that appear in the SCA configuration (whether that be through SCDL or annnontations). Some (or all now you are making C++ an extesnions) of the components are represented as extensions. Each extension has to have some way of interacting with the bindings that C++ SCA provides so needs to connect into the wrapper/proxy architecture provided. So I guess what I'm saying is that I anticipated the runtime interface between components implemented in extensions and the C++ SCA runtime, in particular the bindings, to be via the proxy/wrapper route. I some cases the extension may be able to use the core proxy/wrapper base system natively. In others they may want to override it to provide language specific proxies and wrappers. I may be talking complete twoddle here so correct me if tI'm going off on a tangent. As an aside I would like to have a mechanism whereby bindings can be implemented in either an extension or in C++ SCA. In this way faciliites of the extension environment can be used without recourse to C++ SCA if that is more appropriate (what more appropriate means is TBD in my mind at present). So I have anticiapted that this could be done by allowing the connection between extension and core proxy/wrapper representations to be broken. I have to admit that this is not a high priority for me just something that could be useful down the line
Re: [C++] Requirements for a pluggable C++ Tuscany implementation
On 8/22/06, Oisin Hurley [EMAIL PROTECTED] wrote:
[deletia]
js-d says:
I've been thinking about this and wondering what the architecture
of the runtime will be with many different plugins? Are you guys
envisioning one big process with different (maybe incompatible?)
libraries loaded in it? or a more distributed architecture with
multiple processes?
I must admit I've been toying with the idea of having multiple
processes handling the various component implementation types and
binding types, then it would be quite easy to bring them up/down...
What do you think?
[deletia]
pr says:
Not sure what the definition of incompatible is here. Is it, for
instance,
having two separate extension plugins that both provide a
binding.ws? I
think this is an interesting case and one we should try to support. Of
course there would need to be some config outside of the Assembly
specification to determine which one gets used. I see the jave folk
discussing this very issue.
It's probably the case that we can't define what 'incompatible' means
upfront
except to say that bitter experience will provide :) +1 on being
able to
resolve a choice from a number of binding providers what all can
support 'ws',
I think this is necessary right now, but I'm still a bit
uncomfortable with
binding.ws as being too general (not trying to start a new thread
here -
others are looking into this issue :)
[deletia]
9. Plugins have versions, and dependencies on other plugins too.
We may want to get there at some point, but I was not sure that we
really needed this to start with... Would it make sense to stage
this and start with a simple solution with no versions and no
dependencies, and get into the whole versioning / dependency /
coexistence of multiple versions etc. later?
Simple solution, followed by dependencies, followed by versioning
would work for me. We can learn from what OSGi does in terms of
its management of these things and maybe emulate it to some extent.
So: +1
Having tried to retro-fit versioning into many software products
over my
many years I would say this is one to think about up front even if
you don't
implement it. It is very easy to make it virtually impossible to
this later
without majot restructure!
I'm comfortable with starting off using something like a {namespace,
name,
version} triple as a unique identifier for a plugin - or even a {name,
version} pair with the proviso that the name is structure ala java
package
names, eclipse plugin names etc.
We can start off with the basic resolution approaches of exact-match and
latest-match on the version part and then later on develop at-least-
match
and range-match if they are really necessary.
I've seen lots of +1s on this thread, which is nice, and I've just found
out that I can edit the Tuscany wiki, so I'll summarize to there -- the
page will be http://wiki.apache.org/ws/Tuscany/TuscanyCpp/
PluggableCppRuntime
it'll be later today before I get to it.
cheers
--oh
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi guys
Had a long weekend so just picking up this thread. Looks like a really
useful discussion and I too like the requirement driven approach. I have a
few to add/comment on. It seems that a plugin resolves to a component type
or binding, i.e. what the assembly model refers to as extensions, so that is
what I have in my mind.
6. There will need to be some kind of manager thingie to keep
track of plugins and their state at runtime.
Extensions should be able to constribute information to the in memory model,
for example, via annotations. So we need an API that allows either the model
to be updated or the extension to he scanned for additional information on
load. Conversely we should be able to inject information into the extension
based on model configuration. It may be useful to instigate a model of
extensions in the C++ core/model (the manager thingie) as a place where this
system interface can be controlled.
I've been thinking about this and wondering what the architecture of the
runtime will be with many different plugins? Are you guys envisioning
one big process with different (maybe incompatible?) libraries loaded in
it? or a more distributed architecture with multiple processes?
I must admit I've been toying with the idea of having multiple processes
handling the various component implementation types and binding types,
then it would be quite easy to bring them up/down... What do you think?
I don't object to having multiple processes. It could be a real help with
extensions that assume different models of operations, for example, PHP
always assumes a one shot approach to processing requrests. Services/objects
are not maintained across calls. However having said that I'm not sure that
the infrastructure requirements differ a great deal as we switch from a
single
Re: [SDO for C++] Opinions Requested: Adopting stdcxx as C++ library
On 8/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/08/06, Andrew Borley [EMAIL PROTECTED] wrote: On 8/30/06, Geoffrey Winn [EMAIL PROTECTED] wrote: snip. Using the Apache stdcxx library instead would provide us with a number of benefits Agreed. +1 for this. yup! The one difficulty is that once SDO links against the stdcxx library then all users of SDO must also do so. I think this gives us two options 1. Just do it, and live with the consequences. In this case we will (one way or another) pre-req stdcxx on all platforms, and all users of SDO for C++ will be required to use stdcxx as their C++ standard library. 2. Create a build time switch that chooses between whatever the platform offers (ie the current arrangement) and stdcxx. Presumably defaulting to the current arrangement. I prefer option 2 but obviously it somewhat complicates our build process and perhaps more seriously adds another complication to our test cases. What does the team think? My preference is also for option 2 as it gives our users more choice. However, we may find ourselves #ifdef-ing chunks of code out to get around the aforementioned differences in libraries (see Pete's map problem on Windows yesterday..) which will make code less readable, etc. I think starting this with the SDO codebase is a good idea, as this is a relatively standalone set of code, and will give us a good idea what the issues are with this approach. Defintiely option 2! A side question - SDO has a couple of pre-reqs (libxml2, etc) - will these need to be rebuilt against stdcxx as well? libxml2 is C rather than c++ so I don't think this is an issue. Same for Axis2C for the sdo_axiom utility. Cheers, -- Pete Generall I +1 the move to stdcxx and specifically to option 2 because... In PHP SDO land, which of course uses Tuscany SDO, we tend to have faily autonomous builds, i.e. we expect our users to be able to download the SDO package and build it without having to download too much other stuff. At least other stuff that isn't already known to the PHP build system . We already depend on libxml2, iconv zlib but these are generally available in linux at stable versions. If we add a mandatory dependency on the apache incubator version of stdxx then we have added another barrier to entry as there is another packge to download that people may not be familiar with and may cause clashes with other extensions that use other solutions. We won't know until we try it. It may also cause problems for the automatic windows build that takes place on the PECL servers outside of our control. I don't really know the details of this though so would have to look into it. Simon
[C++] VC7 SCA project
Does anyone have a version of the VC7 project for SCA that matches the reorganized code? If not I'll make one Regards Simon
Re: REST bindings for Tuscany SCA runtime
On 9/1/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 8/31/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Oisin Hurley wrote: I am not sure I understand the issue with create/delete (except if PUT and DEL are disabled). Posting/putting to a URL that doesn't exist yet to create that resource can be troubling. Is that the issue? Are you looking for some kind of factory service pattern to create resources? Or am I completely mis-understanding the issue you're describing here? :) Apologies for not making the context clearer - however, you've got the point: there needs to be either a resource factory, or a generic resource holder to process create/delete of resources. I think I was attempting to say that a first cut would be ok to support just the GET/POST (as the most pressing scenarios) and then the PUT/DEL and factory approach could follow as a feature improvement. I will put up a wiki summary on this thread. cheers --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Yes, GET/POST first, PUT/DELETE later sounds reasonable to me. I've been struggling myself with the question on whether or not we need some kind of resource holder/factory to create resources, and I'm now starting to think that it really depends on how you view your resources. Just a wild thought here... If you view your resources as objects, you'll probably say that you need a factory to do customerFactory-create(http:///customer/1234;). Then you'll say customers-get(http:///customer/1234;) to retrieve your customer object. If on the other hand you view the Web as a giant distributed file system, then it's not so shocking to say: customers-createFile(http:///customer1234;); customers-getFile(http://./customer1234;); Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Sebastien It's not clear that there is a difference between customers and customerFactory in your example. You are saying that there is some resource that causes the correct interpretation of PUT type requrests w.r.tgenerating/recording new resources that represent customers. This resource itself may, for example, represent the list of customers it has created in response to GET type requests. The relationship between Customers and Customer is not a wired relationship in the SCA sense but a resource relationship as dictated by the URLs used to represent endpoints. Regards Simon Simon, I agree with what you're saying. I think that we've now closed a loop :) and that what you're saying is in line with the proposal at the bottom of http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06704.html Then we raised the question of whether or not the create verb in particular should be handled by a separate factory. And in this last email I was trying to say that somebody coming with an OO view would probably want that factory separate from the actual resources (and that I was initially in that camp some time ago), but that now I'm seeing these resources more like a file system (with no separate factory) where: customers.get(http://my.customer.database.com/customers/1234;); returns an instance of the Customer XSD complex type for customer 1234 customers.put/post(http://my.customer.database.com/customers/1234;, customerDataObject / or a diff) creates/updates customer 1234 with a Customer instance. customers.get(http://my.customer.database.com/customers/;) returns a list of URIs to the customers. Is that consistent with your view? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Yes, sorry, I wasn't very clear in my post. I'm not trying to go round the loop again:-) Your summary is consistent with my view. Assuming HTTP here I probably expect to get different results from GET - http://my.customer.database.com/customers/ (get me all the customer records?) GET - http://my.customer.database.com/customers/1234 (get me one customer record?) I'm also probably asking for different things when I say PUT - http://my.customer.database.com/customers/ (Create all the customer records?) PUT - http://my.customer.database.com/customers/1234 (Create one customer record?) In normal static HTTP land the semantics are the same in both cases as I'm just GETing or PUTing data. In our case what actually happens depends on both the verb and the identity. So in mapping resource orientation to service orientation we may want to give the service developer more help in organizing the operations. Using Oisin's proposed annotations we could
Re: [C++] Extension matters
On 8/31/06, Andrew Borley [EMAIL PROTECTED] wrote: Hi all, I'm inches away from getting an extension working that allows Python scripts to be used as components in SCA C++. I should be putting that up some time tomorrow - I'll start a thread about a few minor issues with the extension framework that I've come across, but it hasn't been too complex to get this going. At the moment the extension provides an implementation.python element to the .composite of the form: implementation.python module=PythonModuleName path=relative/path/to/module class=PythonClassName/ This allows other C++ components or C++ clients to call the service implemented by code inside the Python module. The service interface is currently described by a C++ header file, and uses the interface.cppinterface binding. Currently, references from the Python components are not enabled (see below). There are two further areas that are needed for full integration of Python into SCA (or SCA into Python): 1) A programming model for SCA in Python to allow Python components or Python clients to call SCA services. This will enable components with Python implementations to have references. We could either create a Python extension that will emulate the service lookup that we do in C++, e.g. a Python equivalent of the following C++ snippet: // First, get the current ComponentContext osoa::sca::ComponentContext myContext = osoa::sca::ComponentContext::getCurrent(); // Find the required service, as referenced in CalculatorImpl.componentType DivideService* divideService = (DivideService*)myContext.getService(divideService); // Finally, invoke the service result = divideService-divide(arg1, arg2); Alternatively, we could look at doing some kind of annotations within the Python component module - I'm not sure whether Python has annotation support (I don't believe so), or whether there is a way to 'fake' it to make comments/documentation act as annotations. 2) An interface.python extension so that python components do not have to have their interfaces converted to a C++ or WSDL description. Due to the loose typing that Python allows this isn't the easiest thing to do - most functions have signatures like: def myMethod(arg1, arg2) - and (as far as I can currently tell) there is no way to determine the types of the arguments or return values aside from at invocation time. At the moment the SCAGEN tool generates the C++ component proxy and wrapper classes based on the C++ header specified in the interface.cpp element in the .componentType file. If the .componentType file has an interface.pythonelement instead, and specifies the Python module, generating the correct C++ code neccessary to call the python service is hard. Alternatively, the interface.python could specify the function signatures itself, but that starts to stray into WSDL territory, e.g: interface.python function name=myMethod argument name=arg1 type=string/ argument name=arg2 type=int/ return type=string/ /function /interface.python There may well be a way to specify things a bit tighter in Python that i don't know about - I'll keep looking into this. What do people think about these various issues? Has anyone got any suggestions? Thanks! Andy Hi Andy Sounds like great progress. 1) I would favour whatever hides SCA from the Python programmer the most so I like annotations. However if annotations are hard then the first approach would be a stake in the ground until you have a better feel for how the extension framework operates. 2) PHP is loosly typed also but you can get at the comments in the source so you can describe function signatures there and look at them at run time (see http://www.osoa.org/display/Main/PHP+and+SCA+White+Paper). Can you do the same in Python? If you do use support in Python to get at types its likely to be a run time operation so we would need to rely on the generic proxies/wrappers in C++ and then call up into Python doing the apporpriate transformation as dictated by the runtime generated interface description. As this is likely to be a runtime thing I would go with WSDL to describe the interface. You then have the mechanism for describing the python script as a remote service ready to go. It would be good to have a component in C++ that is able to generate WSDL on the fly (this would be handy for PHP also) but we would have to agree how to describe the interface to the WSDL generator! Maybe you could say a little bit more about what you do now to help us envisage the development process and flow of control. - you write a python class/operation - you write your .componentType file including implementation.python - you hand craft a .h file to match the python class ? - you run SCA gen to generate the wrapper - you have some code that converts the wrapper call into a call into the Python engine targetted at the appropriate operation Is that correct? Regards Simon
Re: [C++] Requirements for a pluggable C++ Tuscany implementation
On 8/29/06, Oisin Hurley [EMAIL PROTECTED] wrote: Simon - apologies I've been away from this for the last week... [deletia] ...and this is why :) There are number of responsibilities of an extension - which you accurately describe - and there are a number of responsibilities of a plugin, related to configuration and lifecycle and I think it would be a Good Thing to keep them as separate development efforts. What do you think? Do you mean that a plugin may have responsibilities that are a sub- set or super-set of those of a particular extension? Actually I see that the plugins responsibilities are a disjoint set - meaning that the plugins are unconscious of the value of their content and are used only as a way to bang a bunch of libraries together in a predictable manner and correctly initialize/deinitialize them. Ah, OK, I see. I was getting a little confused because Pete has being doing work on refactoring the C++ implementation to separate core function from extensions from bindings. I had assumed (wrongly in the first instance) some overlap between that activity and this conversation. What you are advocating a more wide ranging approach review of C++ SCA deployment. We could probably have the same conversation re. deploying components and composites into the C++ SCA infrastructure as opposed to deploying parts of the C++ SCA infrastructure. +1 Maybe we need to be a bit more explicit about what we anticipate being in a plugin. For examle, 0..n Component type container implementations 0..n Binding implementations 0..n Host adapters [0..n Components 0..n Composite(s) should these be included as well? Seems unlikely that you want to deply at the same time but you will want to deploy at some time.] So there's two roads - one where one must be explicit about the content of the plugin in terms of architectural artifacts, this is the manifest style approach, and the other, where the plugin initialization code does the necessary registrations of architectural artifacts. These are not necessarily incompatible approaches either. OK, from above, with this list I was trying elicit that you thought a plugin was rather than necessarily manadate a plugin. Having said that, in the context of SCA we can expect a finite set of things in plugins, assuming that a component implementation is just classed as a component, and the list above still stands I think. What you are saying is that you envisage a deployment approach where the plugin may have one or more of these types of things as required to add some funtion or application to the runtime. Can we use exsiting technology for some of this, for example, there has been much discussion of OSGi on the java list, is OSGi wider that just Java now? AFAIK OSGi is still Java only and a Google search didn't turn up much that was useful. In terms of existing technology, I'm not familiar with any technologies along this line that are open. That being said, a C++ version of OSGi would be a beautiful thing :) Your right, Google doesn't turn up anything. I'm sure I read some mail on a mail list about it but there you go I must be dreaming. My gut feeling is that plugin/extension should be decoupled, but the only strong point I can see for it in the current architecture is the fact that databindings are not explicit as an extension - there is scope for say an interface.mumble that has databindings of say XMLBeans or JiBX. If the databinding can be an extension in its own right, then maybe the simplifying assumption of plugin == extension may be the way to go. From the point of view of deployment, there may be a greater need for a non-extension plugin to package application code to be 'deployed'. Maybe we should have that conversation about deployment now? cheers --oh Sebastien has used Pete's extension framewok to refactor the bindings. It's a good question you raise though about data bindings. The only options currently are SDO and native and assumtions are made depending on what interfaces/bindings you choose. More though required in the future! I can see it being useful to packagage individual extensions or groups of extensions for the runtime to consume. It's also to the case that we will want to package applications. Current when I build C++ SCA I get a deploy stucture that holds the SCA core and extensions framwork deploy bin extensions cpp bin include lib xsd ws reference bin lib service bin lib xsd include lib xsd And when I build a sample, BigBank for example, I get a separate deploy dir deploy bin configuration Composite Name top level.composite packages Composite Name everything required for the composite Now I should be able to zip this deploy up and move it to another runtime instance and assuming I have $TUSCANY_SCA/SDOCPP set up it should run OK. However this all depends on the
[C++] windows build system
Having just raised a patch to create a VC7 build for BigBank I'm taking a step back and thinking that we need a better position on Windows builds as we have too many variations. In particular I just tried to open the VC7 Calculator sample project and it's not compatible with my oldish verision of VC7. So we are faced with even more varieties of project files. This is not sensible. I have two proposals. 1/ For those who want to use MSVC lets agree a version that we support and try and stick with that. Can I suggest Microsoft Visual C++ 2005 Express Edition. I have to admit that I haven't tried this but I will move if we agree this is the right direction to be going in. Has anyone tried it? 2/ Implement a command line build for windows so that we can automate the build process. I am currently looking at a cygwin build based on the *nix project automake files. I haven't got it working just yet but will report back. Thoughts? Simon
Re: [C++] Cleaning up samples
On 9/5/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Hi, I checked in a copy of Calculator under http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/Calculator-new/ , with a number of changes trying to simplify the sample and improve the consistency of the names used in the sample: - the subprojects follow the naming convention suggested in the SCA spec and the various SCA white papers on osoa.org (sample.calculator, sample.calculator.client etc.) helping create unique project names - similar naming convention for the composite names - changed Calculator subsystem to calculator solution - the business interfaces are named Calculator and Divide instead of CalculatorService, DivideService - the components are named CalculatorComponent and DivideComponent instead of CalculatorServiceComponent, DivideServiceComponent - the services are named CalculatorService and DivideService - and a few other minor cleanup changes, renamed readme.txt to README, renamed the .cmd to .bat, changed the .bat to be consistent with the .sh, and use the same executable name on Windows and Linux. If there's no objection, I plan to replace the existing Calculator sample with this new form, and also check in an updated version of Bigbank following the same pattern tomorrow. This will make our implementation of the Bigbank sample much closer to what's described in the OSOA Recursive Assembly white paper at http://www.osoa.org/display/Main/Recursive+Assembly+Model. I'm not sure what we should put in the README for each sample. Right now the contents of the README is Windows specific and probably obsolete, I was thinking of maybe having another file besides the README called HOWTO-DEPLOY describing how to deploy the sample to Axis2C... Comments and thoughts welcome. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] All sounds good to me. The README should have a description of what the sample does, what it is trying to demonstrate, and a summary of the various different configurations and platforms on which it will run. I.e. you might want to run the local or web services client on windows or *nix. So there will necessarily be quite a number of deployment and runtime instructions for what is actually a relatively simple demo. Your idea of having separate DEPLOY files for the different configurations sounds like the way to go. It might also be useful to include screen shots of the command line showing the run commands and the expected output. Also it would be good to have some discussion of how to turn debug on and what it shows you. This shouldn't be done on a sample by sample basis but I find it quite instructive. I have come across a set of typical configuration errors when using the samples, e.g. the one that always catches me is http://issues.apache.org/jira/browse/TUSCANY-499. We should create a samples FAQ I guess. There is quite a number of environement variables and paths that need to be set before it all works. We should review the run scripts to see if we can add more checking as they already check that appropriate environment variables are set. If you want some help with these things let me know. S
[C++] First pass PHP extesion
Earlier I created a patch for a first pass at a PHP extension for C++ SCA ( http://issues.apache.org/jira/browse/TUSCANY-698) This follows the pattern layed down by Andy with the Python extension and has many limitations:: Services only. No references. Basic input types only. No arrays or SDOs Single valued return values only. No arrays or SDOs C++ .h interface Error handling is not properly tied into SCA I used this as an exercise to understand what Pete/Andy had done. As such I have taken the most basic approach to integrating with PHP possible. This is not the way I recommend doing it in the long term. In the future I would want to change at least the following. The embed API needs to be replaced with the PHP SAPI References should be supported using annotations and injection SDO should be supported as a databinding I would prefer to go to using WSDL interface descriptions I have currently followed the pattern and gone with the following implementation descriptions: When the script just has functions implementation.phpmodule=DivideServiceImpl/ When the script has classes and functions implementation.phpmodule=DivideServiceImpl class=DivideClass/ I wanted to go with module=DivideServiceImpl but the code at present adds .componentType to the end of the module name to get the component type information. I didn;t feel that DivideServiceImpl.php.componentType was right but I'm prepared to be convinced. In the longer term I think it may be sensible to ditch the function only approach as it makes the reference handling less obvious. I haven't included the build file at present because we need to sort out the windows build system and me adding yet another flavour of dev studio will not help. I have though included Calculator sample files that use the extension as per Andy's sample so you can look even if you can't run. Lots more work to do but it's a start. Simon
Re: [C++] Beginning of a Ruby extension available
On 9/6/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Hi all, I just checked in the beginning of a Ruby extension under http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/ruby/ . It is not complete but it allows you to declare an SCA component implemented by a Ruby class with for example: component implementation.ruby script=DivideImpl.rb class=DivideImpl/ /component Support for references, properties and scopes is not there yet but the basic mechanism for invoking a component implemented in Ruby is there. A version of the Calculator sample implementing the Divide component in Ruby is available there: http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/RubyCalculator/ . I have tested this on Linux, and can help test on Windows as well as soon as we get a good build of SDO and the SCA runtime with Visual Studio Express 2005. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Wow, extensions galore:-)
Re: [C++] SDO can't load an XML doc with no namespace
On 9/7/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Well, I can load it, but it's desperately empty :) Given the following XML: customerfirstNameJane/firstNamelastNameDoe/lastName/customer I have no XSD for this document, and don't want to have one or have to define specific SDO types for it. I just want to load this XML into an SDO DataObject. XMLDocumentPtr doc = XMLHelper::load(xml); gives me an XMLDocumentPtr with no root DataObject. char* xml = XMLHelper::save(doc); gives me this: ?xml version=1.0 encoding=UTF-8? Is this supported by our SDO/C++ implementation? or is it a bug? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] We don't have support for schema free loads in PHP SDO which is based directly on C++ SDO and I have assumed to date that that was because C++ SDO doesn't support it. I may be wrong and if C++ SDO does support it it would be really handy for us so I'll see if I can find out.
Re: Ruby for the Java runtime? (was: Re: [C++] Beginning of a Ruby extension available)
On 9/7/06, ant elder [EMAIL PROTECTED] wrote: Robbie, your help would be much appreciated so please feel free to jump in. Do you have specific samples or interop things you'd like to look at? Want me to suggest some things, or bounce some ideas around on IRC/mailing list? ...ant On 9/6/06, Robbie Minshall [EMAIL PROTECTED] wrote: Sounds great. When Venkat is done with his port I would be interested in helping. Perhaps a sample demonstrating interopt between services with different language implementations. If we are using SDO for our data model how will SDO support be provided in these container extensions ? Robbie On 9/6/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi... I am interested in taking a look at this. I hope to get a feel of implementing container extensions through this. I shall get started with this rightaway. Ant, I might need your help for this after I do some ground work. Thanks. - Venkat On 9/6/06, ant elder [EMAIL PROTECTED] wrote: Quite a while back we had a Ruby container contributed for the Java runtime, see TUSCANY-365. Is anyone interested in looking at porting that to the new Java runtime and getting it to match what the C++ guys are doing? ...ant On 9/6/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Hi all, I just checked in the beginning of a Ruby extension under http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/ruby/ . It is not complete but it allows you to declare an SCA component implemented by a Ruby class with for example: component implementation.ruby script=DivideImpl.rb class=DivideImpl/ /component Support for references, properties and scopes is not there yet but the basic mechanism for invoking a component implemented in Ruby is there. A version of the Calculator sample implementing the Divide component in Ruby is available there: http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/RubyCalculator/ . I have tested this on Linux, and can help test on Windows as well as soon as we get a good build of SDO and the SCA runtime with Visual Studio Express 2005. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- * * * Charlie * * * Check out some pics of little Charlie at http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ * * * Addresss * * * 1914 Overland Drive Chapel Hill NC 27517 * * * Number * * * 919-225-1553 In PHP we have an implementation of SDO that is fully based on the C++ SDO implementation. I'm not sure if it will be instructive in the java space but we have pretty much just wrapped the C++ SDO interfaces and exposed them as native PHP objects. I guess you would have to do a similar thing in Ruby or any other extension for that matter. The solution will depend on how you construct extensions to your scripting language. In PHP it just so happens you have to do it in C/C++ but I would hope you can do it in Java for JVM based environments. S
Re: [C++] First pass PHP extesion
On 9/8/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: Earlier I created a patch for a first pass at a PHP extension for C++ SCA ( http://issues.apache.org/jira/browse/TUSCANY-698) This follows the pattern layed down by Andy with the Python extension and has many limitations:: Services only. No references. Basic input types only. No arrays or SDOs Single valued return values only. No arrays or SDOs C++ .h interface Error handling is not properly tied into SCA I used this as an exercise to understand what Pete/Andy had done. As such I have taken the most basic approach to integrating with PHP possible. This is not the way I recommend doing it in the long term. In the future I would want to change at least the following. The embed API needs to be replaced with the PHP SAPI References should be supported using annotations and injection SDO should be supported as a databinding I would prefer to go to using WSDL interface descriptions I have currently followed the pattern and gone with the following implementation descriptions: When the script just has functions implementation.phpmodule=DivideServiceImpl/ When the script has classes and functions implementation.phpmodule=DivideServiceImpl class=DivideClass/ I wanted to go with module=DivideServiceImpl but the code at present adds .componentType to the end of the module name to get the component type information. I didn;t feel that DivideServiceImpl.php.componentType was right but I'm prepared to be convinced. In the longer term I think it may be sensible to ditch the function only approach as it makes the reference handling less obvious. I haven't included the build file at present because we need to sort out the windows build system and me adding yet another flavour of dev studio will not help. I have though included Calculator sample files that use the extension as per Andy's sample so you can look even if you can't run. Lots more work to do but it's a start. Simon Simon, I adjusted our Linux build to integrate your PHP extension, it builds OK for me on Linux using a php-devel-5.0.4-10.5.rpm after a few changes to Makefile.am (I also made a minor change to remove the dependency on CPPInterface like we did in the other extensions). The build requires the following environment variables: PHP_INCLUDE=/usr/include/php PHP_LIB=/usr/lib/httpd/modules Which version of PHP did you use on Windows? I tried PHP 5.1.6-2 first but I'm guessing that you used an older PHP level on Windows since your code uses php_embed.h, which does not seem to exist anymore on 5.1.6.2. I'm OK to stay on that older level if it's simpler for you on Windows for now, or help build and test on a newer level. Let me know... Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Sebastien Thanks for doing the linux build and for fixing up the dependency on the C++ extension. I really need to make a README describing how to build it. The detail is a little opaque as I haven't made a patch for the windows build files yet. I'm having a little difficulty in getting the right version of the Microsoft Developer Tools. Anyhow... I'm using PHP5.1.4 on Windows but 5.1.6 should be OK. On windows you will have to get the source to get the headers but php5embed.lib is provided. Strange huh. To run the calculator sample you need to do a couple of things 1/ make sure that the directory holding php5embed.lib is on the path, for example, create a version of runclient.bat with ... set PHP_HOME= where ever PHP is installed set PATH=%PHP_HOME%;%TUSCANY_SCACPP%\bin;%TUSCANY_SCACPP%\extensions\cpp\bin;%TUSCANY_SDOCPP%\bin;%AXIS2C_HOME%\lib;%PATH% Client.exe %* 2/ make sure that php.ini includes a reference to the directory which holds the .php file you are going to run as a component, for example, my php.iniis in the same directory as the php.exe and at the end of the file I have include_path=.;C:\simon\Projects\Eclipse3.2\cpp\sca\samples\Calculator\deploy\packages\CalculatorComposite you can use php -i to find where php is looking for you php.ini files. 4th or 5th line down should tell you. Apologies again for not yet providing a README that describes all this. I'll get to it shortly. Let me know if this doesn't help. Regards Simon
Re: [C++] First pass PHP extesion
On 9/8/06, Simon Laws [EMAIL PROTECTED] wrote: On 9/8/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: Earlier I created a patch for a first pass at a PHP extension for C++ SCA ( http://issues.apache.org/jira/browse/TUSCANY-698 ) This follows the pattern layed down by Andy with the Python extension and has many limitations:: Services only. No references. Basic input types only. No arrays or SDOs Single valued return values only. No arrays or SDOs C++ .h interface Error handling is not properly tied into SCA I used this as an exercise to understand what Pete/Andy had done. As such I have taken the most basic approach to integrating with PHP possible. This is not the way I recommend doing it in the long term. In the future I would want to change at least the following. The embed API needs to be replaced with the PHP SAPI References should be supported using annotations and injection SDO should be supported as a databinding I would prefer to go to using WSDL interface descriptions I have currently followed the pattern and gone with the following implementation descriptions: When the script just has functions implementation.phpmodule=DivideServiceImpl/ When the script has classes and functions implementation.phpmodule=DivideServiceImpl class=DivideClass/ I wanted to go with module=DivideServiceImpl but the code at present adds .componentType to the end of the module name to get the component type information. I didn;t feel that DivideServiceImpl.php.componentTypewas right but I'm prepared to be convinced. In the longer term I think it may be sensible to ditch the function only approach as it makes the reference handling less obvious. I haven't included the build file at present because we need to sort out the windows build system and me adding yet another flavour of dev studio will not help. I have though included Calculator sample files that use the extension as per Andy's sample so you can look even if you can't run. Lots more work to do but it's a start. Simon Simon, I adjusted our Linux build to integrate your PHP extension, it builds OK for me on Linux using a php-devel-5.0.4-10.5.rpm after a few changes to Makefile.am (I also made a minor change to remove the dependency on CPPInterface like we did in the other extensions). The build requires the following environment variables: PHP_INCLUDE=/usr/include/php PHP_LIB=/usr/lib/httpd/modules Which version of PHP did you use on Windows? I tried PHP 5.1.6-2 first but I'm guessing that you used an older PHP level on Windows since your code uses php_embed.h, which does not seem to exist anymore on 5.1.6.2. I'm OK to stay on that older level if it's simpler for you on Windows for now, or help build and test on a newer level. Let me know... Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Sebastien Thanks for doing the linux build and for fixing up the dependency on the C++ extension. I really need to make a README describing how to build it. The detail is a little opaque as I haven't made a patch for the windows build files yet. I'm having a little difficulty in getting the right version of the Microsoft Developer Tools. Anyhow... I'm using PHP5.1.4 on Windows but 5.1.6 should be OK. On windows you will have to get the source to get the headers but php5embed.lib is provided. Strange huh. To run the calculator sample you need to do a couple of things 1/ make sure that the directory holding php5embed.lib is on the path, for example, create a version of runclient.bat with ... set PHP_HOME= where ever PHP is installed set PATH=%PHP_HOME%;%TUSCANY_SCACPP%\bin;%TUSCANY_SCACPP%\extensions\cpp\bin;%TUSCANY_SDOCPP%\bin;%AXIS2C_HOME%\lib;%PATH% Client.exe %* 2/ make sure that php.ini includes a reference to the directory which holds the .php file you are going to run as a component, for example, my php.ini is in the same directory as the php.exe and at the end of the file I have include_path=.;C:\simon\Projects\Eclipse3.2\cpp\sca\samples\Calculator\deploy\packages\CalculatorComposite you can use php -i to find where php is looking for you php.ini files. 4th or 5th line down should tell you. Apologies again for not yet providing a README that describes all this. I'll get to it shortly. Let me know if this doesn't help. Regards Simon I should add to the wording of step 1/ make sure that the directory holding php5embed.lib is on the path a little more detail, i.e. because this is the place that you will also find php5ts.dll wich is the shared library that php5embed.lib provides a front end to and which actually implements the PHP engine S
Re: Ruby for the Java runtime? (was: Re: [C++] Beginning of a Ruby extension available)
On 9/8/06, ant elder [EMAIL PROTECTED] wrote: Yes we should be able to do the same type of thing with Java. Is the PHP SDO API the same as the C++ API or is it simplified? I think for most if not all the Java based scripting languages we can just expose the Java SDO API to the scripting language (at one point we had a JavaScript version of the Big Bank sample account module that did this), but there are probably ways to use the dynamic nature of the script languages to come up with a simplify SDO API. ...ant On 9/7/06, Simon Laws [EMAIL PROTECTED] wrote: In PHP we have an implementation of SDO that is fully based on the C++ SDO implementation. I'm not sure if it will be instructive in the java space but we have pretty much just wrapped the C++ SDO interfaces and exposed them as native PHP objects. I guess you would have to do a similar thing in Ruby or any other extension for that matter. The solution will depend on how you construct extensions to your scripting language. In PHP it just so happens you have to do it in C/C++ but I would hope you can do it in Java for JVM based environments. S The SDO API in PHP is fairly similar to the C++ SDO but is simplified and in particular it tries to take avantage of the features of PHP so that it is comfortable to use for the PHP programmer. For example, a typical user of the XML DAS might do $xmldas-addTypes(company.xsd); $document = $xmldas-loadFile(company.xml); $company = $document-getRootDataObject(); $company_name = $company-name; // property access style $company_name = $company['name']; // associative array access style $company_name = $company[0];// index array access style The trick is make the experience as natural for the script developer as possible so we have, for example, provided all the normal PHP object access styles. Also our user space implementation of the relational DAS is quite different from the current java implementation. Regards Simon
Re: Ruby for the Java runtime? (was: Re: [C++] Beginning of a Ruby extension available)
On 9/8/06, Venkata Krishnan [EMAIL PROTECTED] wrote:
Hi
The current implementation of Ruby in Java works only for scripts that
have
global methods. I am interested getting this work for methods inside
classes.. But then I am not able to figure out a way of doing this.
Can somebody help me with clues on the following... maybe even if the C++
guys are able to provide me some hints conceptually I can map it to the
JRuby stuff. Here is what I do...
1) I load the script into the Ruby engine and get a RubyObject out of it
2) call the invoke method on the Ruby object to invoke the Ruby functions
- in this invoke method there is no way I am able to specify the
RubyClass whos method I should invoke. All that it takes is the method
name
as a string. I tried using ruby classname.ruby methodname for the
method argument but failed.
So how do I specify the class?
Thanks
- Venkat
On 9/8/06, Simon Laws [EMAIL PROTECTED] wrote:
On 9/8/06, ant elder [EMAIL PROTECTED] wrote:
Yes we should be able to do the same type of thing with Java. Is the
PHP
SDO
API the same as the C++ API or is it simplified?
I think for most if not all the Java based scripting languages we can
just
expose the Java SDO API to the scripting language (at one point we had
a
JavaScript version of the Big Bank sample account module that did
this),
but
there are probably ways to use the dynamic nature of the script
languages
to
come up with a simplify SDO API.
...ant
On 9/7/06, Simon Laws [EMAIL PROTECTED] wrote:
In PHP we have an implementation of SDO that is fully based on the
C++
SDO
implementation. I'm not sure if it will be instructive in the java
space
but
we have pretty much just wrapped the C++ SDO interfaces and
exposed
them
as
native PHP objects. I guess you would have to do a similar thing
in
Ruby
or
any other extension for that matter. The solution will depend on
how
you
construct extensions to your scripting language. In PHP it just so
happens
you have to do it in C/C++ but I would hope you can do it in Java
for
JVM
based environments.
S
The SDO API in PHP is fairly similar to the C++ SDO but is simplified
and
in particular it tries to take avantage of the features of PHP so that
it
is
comfortable to use for the PHP programmer. For example, a typical user
of
the XML DAS might do
$xmldas-addTypes(company.xsd );
$document = $xmldas-loadFile(company.xml);
$company = $document-getRootDataObject();
$company_name = $company-name; // property access style
$company_name = $company['name']; // associative array access style
$company_name = $company[0];// index array access style
The trick is make the experience as natural for the script developer
as possible so we have, for example, provided all the normal PHP
object access styles.
Also our user space implementation of the relational DAS is quite
different from the current java implementation.
Regards
Simon
Hi Venkat
I'm not sure that this helps at all but I just took a look at what Sebastien
did in C++
string expr = impl-getClass() + .new;
VALUE instance = rb_eval_string(expr.c_str());
// Get the ID of the specified method
ID method = rb_intern(operation.getName().c_str());
When it comes time to actually call the method
// Invoke the specified method
VALUE value;
if (n == 0)
{
value = rb_funcall(instance, method, 0);
}
else
{
value = rb_funcall2(instance, method, n, args);
}
So he seems to be able to deal with the class instance in C++. This is the
script he used to test with in the C++ Calculator sample.
class DivideImpl
def initialize()
print Ruby - DivideImpl.initialize\n
end
def divide(arg1, arg2)
print Ruby - DivideImpl.divide\n
arg1 / arg2
end
end
Sebastien is the man to ask really as he build the Ruby extension. He will
be able to give you the gory details no doubt when he comes on line.
S
Re: [C++] Loading the PHP extension on Linux, was: [C++] First pass PHP extesion
On 9/12/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 9/8/06, Simon Laws [EMAIL PROTECTED] wrote: On 9/8/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: Earlier I created a patch for a first pass at a PHP extension for C++ SCA ( http://issues.apache.org/jira/browse/TUSCANY-698 ) This follows the pattern layed down by Andy with the Python extension and has many limitations:: Services only. No references. Basic input types only. No arrays or SDOs Single valued return values only. No arrays or SDOs C++ .h interface Error handling is not properly tied into SCA I used this as an exercise to understand what Pete/Andy had done. As such I have taken the most basic approach to integrating with PHP possible. This is not the way I recommend doing it in the long term. In the future I would want to change at least the following. The embed API needs to be replaced with the PHP SAPI References should be supported using annotations and injection SDO should be supported as a databinding I would prefer to go to using WSDL interface descriptions I have currently followed the pattern and gone with the following implementation descriptions: When the script just has functions implementation.phpmodule=DivideServiceImpl/ When the script has classes and functions implementation.phpmodule=DivideServiceImpl class=DivideClass/ I wanted to go with module=DivideServiceImpl but the code at present adds .componentType to the end of the module name to get the component type information. I didn;t feel that DivideServiceImpl.php.componentTypewas right but I'm prepared to be convinced. In the longer term I think it may be sensible to ditch the function only approach as it makes the reference handling less obvious. I haven't included the build file at present because we need to sort out the windows build system and me adding yet another flavour of dev studio will not help. I have though included Calculator sample files that use the extension as per Andy's sample so you can look even if you can't run. Lots more work to do but it's a start. Simon Simon, I adjusted our Linux build to integrate your PHP extension, it builds OK for me on Linux using a php-devel-5.0.4-10.5.rpm after a few changes to Makefile.am (I also made a minor change to remove the dependency on CPPInterface like we did in the other extensions). The build requires the following environment variables: PHP_INCLUDE=/usr/include/php PHP_LIB=/usr/lib/httpd/modules Which version of PHP did you use on Windows? I tried PHP 5.1.6-2first but I'm guessing that you used an older PHP level on Windows since your code uses php_embed.h, which does not seem to exist anymore on 5.1.6.2. I'm OK to stay on that older level if it's simpler for you on Windows for now, or help build and test on a newer level. Let me know... Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Sebastien Thanks for doing the linux build and for fixing up the dependency on the C++ extension. I really need to make a README describing how to build it. The detail is a little opaque as I haven't made a patch for the windows build files yet. I'm having a little difficulty in getting the right version of the Microsoft Developer Tools. Anyhow... I'm using PHP5.1.4 on Windows but 5.1.6 should be OK. On windows you will have to get the source to get the headers but php5embed.lib is provided. Strange huh. To run the calculator sample you need to do a couple of things 1/ make sure that the directory holding php5embed.lib is on the path, for example, create a version of runclient.bat with ... set PHP_HOME= where ever PHP is installed set PATH=%PHP_HOME%;%TUSCANY_SCACPP%\bin;%TUSCANY_SCACPP%\extensions\cpp\bin;%TUSCANY_SDOCPP%\bin;%AXIS2C_HOME%\lib;%PATH% Client.exe %* 2/ make sure that php.ini includes a reference to the directory which holds the .php file you are going to run as a component, for example, my php.ini is in the same directory as the php.exe and at the end of the file I have include_path=.;C:\simon\Projects\Eclipse3.2\cpp\sca\samples\Calculator\deploy\packages\CalculatorComposite you can use php -i to find where php is looking for you php.ini files. 4th or 5th line down should tell you. Apologies again for not yet providing a README that describes all this. I'll get to it shortly. Let me know if this doesn't help. Regards Simon I should add to the wording of step 1/ make sure that the directory holding php5embed.lib is on the path a little more detail, i.e. because this is the place that you will also
Re: [C++] Loading the PHP extension on Linux, was: [C++] First pass PHP extesion
On 9/13/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 9/12/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 9/8/06, Simon Laws [EMAIL PROTECTED] wrote: On 9/8/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: Earlier I created a patch for a first pass at a PHP extension for C++ SCA ( http://issues.apache.org/jira/browse/TUSCANY-698 ) This follows the pattern layed down by Andy with the Python extension and has many limitations:: Services only. No references. Basic input types only. No arrays or SDOs Single valued return values only. No arrays or SDOs C++ .h interface Error handling is not properly tied into SCA I used this as an exercise to understand what Pete/Andy had done. As such I have taken the most basic approach to integrating with PHP possible. This is not the way I recommend doing it in the long term. In the future I would want to change at least the following. The embed API needs to be replaced with the PHP SAPI References should be supported using annotations and injection SDO should be supported as a databinding I would prefer to go to using WSDL interface descriptions I have currently followed the pattern and gone with the following implementation descriptions: When the script just has functions implementation.phpmodule=DivideServiceImpl/ When the script has classes and functions implementation.phpmodule=DivideServiceImpl class=DivideClass/ I wanted to go with module=DivideServiceImpl but the code at present adds .componentType to the end of the module name to get the component type information. I didn;t feel that DivideServiceImpl.php.componentTypewas right but I'm prepared to be convinced. In the longer term I think it may be sensible to ditch the function only approach as it makes the reference handling less obvious. I haven't included the build file at present because we need to sort out the windows build system and me adding yet another flavour of dev studio will not help. I have though included Calculator sample files that use the extension as per Andy's sample so you can look even if you can't run. Lots more work to do but it's a start. Simon Simon, I adjusted our Linux build to integrate your PHP extension, it builds OK for me on Linux using a php-devel-5.0.4-10.5.rpm after a few changes to Makefile.am (I also made a minor change to remove the dependency on CPPInterface like we did in the other extensions). The build requires the following environment variables: PHP_INCLUDE=/usr/include/php PHP_LIB=/usr/lib/httpd/modules Which version of PHP did you use on Windows? I tried PHP 5.1.6-2first but I'm guessing that you used an older PHP level on Windows since your code uses php_embed.h, which does not seem to exist anymore on 5.1.6.2. I'm OK to stay on that older level if it's simpler for you on Windows for now, or help build and test on a newer level. Let me know... Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Sebastien Thanks for doing the linux build and for fixing up the dependency on the C++ extension. I really need to make a README describing how to build it. The detail is a little opaque as I haven't made a patch for the windows build files yet. I'm having a little difficulty in getting the right version of the Microsoft Developer Tools. Anyhow... I'm using PHP5.1.4 on Windows but 5.1.6 should be OK. On windows you will have to get the source to get the headers but php5embed.lib is provided. Strange huh. To run the calculator sample you need to do a couple of things 1/ make sure that the directory holding php5embed.lib is on the path, for example, create a version of runclient.bat with ... set PHP_HOME= where ever PHP is installed set PATH=%PHP_HOME%;%TUSCANY_SCACPP%\bin;%TUSCANY_SCACPP%\extensions\cpp\bin;%TUSCANY_SDOCPP%\bin;%AXIS2C_HOME%\lib;%PATH% Client.exe %* 2/ make sure that php.ini includes a reference to the directory which holds the .php file you are going to run as a component, for example, my php.ini is in the same directory as the php.exe and at the end of the file I have include_path=.;C:\simon\Projects\Eclipse3.2\cpp\sca\samples\Calculator\deploy\packages\CalculatorComposite you can use php -i to find where php is looking for you php.ini files. 4th or 5th line down should tell you. Apologies again for not yet providing a README that describes all this. I'll get
Re: [C++] Loading the PHP extension on Linux, was: [C++] First pass PHP extesion
On 9/13/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 9/13/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 9/12/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 9/8/06, Simon Laws [EMAIL PROTECTED] wrote: On 9/8/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: Earlier I created a patch for a first pass at a PHP extension for C++ SCA ( http://issues.apache.org/jira/browse/TUSCANY-698 ) This follows the pattern layed down by Andy with the Python extension and has many limitations:: Services only. No references. Basic input types only. No arrays or SDOs Single valued return values only. No arrays or SDOs C++ .h interface Error handling is not properly tied into SCA I used this as an exercise to understand what Pete/Andy had done. As such I have taken the most basic approach to integrating with PHP possible. This is not the way I recommend doing it in the long term. In the future I would want to change at least the following. The embed API needs to be replaced with the PHP SAPI References should be supported using annotations and injection SDO should be supported as a databinding I would prefer to go to using WSDL interface descriptions I have currently followed the pattern and gone with the following implementation descriptions: When the script just has functions implementation.phpmodule=DivideServiceImpl/ When the script has classes and functions implementation.phpmodule=DivideServiceImpl class=DivideClass/ I wanted to go with module=DivideServiceImpl but the code at present adds .componentType to the end of the module name to get the component type information. I didn;t feel that DivideServiceImpl.php.componentTypewas right but I'm prepared to be convinced. In the longer term I think it may be sensible to ditch the function only approach as it makes the reference handling less obvious. I haven't included the build file at present because we need to sort out the windows build system and me adding yet another flavour of dev studio will not help. I have though included Calculator sample files that use the extension as per Andy's sample so you can look even if you can't run. Lots more work to do but it's a start. Simon Simon, I adjusted our Linux build to integrate your PHP extension, it builds OK for me on Linux using a php-devel-5.0.4-10.5.rpm after a few changes to Makefile.am (I also made a minor change to remove the dependency on CPPInterface like we did in the other extensions). The build requires the following environment variables: PHP_INCLUDE=/usr/include/php PHP_LIB=/usr/lib/httpd/modules Which version of PHP did you use on Windows? I tried PHP 5.1.6-2first but I'm guessing that you used an older PHP level on Windows since your code uses php_embed.h, which does not seem to exist anymore on 5.1.6.2. I'm OK to stay on that older level if it's simpler for you on Windows for now, or help build and test on a newer level. Let me know... Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Sebastien Thanks for doing the linux build and for fixing up the dependency on the C++ extension. I really need to make a README describing how to build it. The detail is a little opaque as I haven't made a patch for the windows build files yet. I'm having a little difficulty in getting the right version of the Microsoft Developer Tools. Anyhow... I'm using PHP5.1.4 on Windows but 5.1.6 should be OK. On windows you will have to get the source to get the headers but php5embed.lib is provided. Strange huh. To run the calculator sample you need to do a couple of things 1/ make sure that the directory holding php5embed.lib is on the path, for example, create a version of runclient.bat with ... set PHP_HOME= where ever PHP is installed set PATH=%PHP_HOME%;%TUSCANY_SCACPP%\bin;%TUSCANY_SCACPP%\extensions\cpp\bin;%TUSCANY_SDOCPP%\bin;%AXIS2C_HOME%\lib;%PATH% Client.exe %* 2/ make sure that php.ini includes a reference to the directory which holds the .php file you are going to run as a component, for example, my php.ini is in the same directory as the php.exe and at the end of the file I have include_path=.;C:\simon\Projects\Eclipse3.2\cpp\sca\samples
[Interop] cross language interop test update
I was talking with Andy offline about re-running the cross language interop tests. I've recently made some updates to the schema while testing with PHP SDO so I copied the updates back to Tuscany/Interop. There is a patch attached to http://issues.apache.org/jira/browse/TUSCANY-730. There is also a WSDL file in there that exposes an operation for each interop schema taking that schema as input and returning it as output. I'm going to work with Andy to implement a client/service in C++ so that we can test the SDO binding for Axis. When Raymond is done with the new databindings code for M2 we could do the same for Java and between Java and C++. What we could do with in C++ is an XML comparison utility. Anyone come across one? Simon
Re: [Interop] cross language interop test update
On 9/20/06, ant elder [EMAIL PROTECTED] wrote: Is it worth also trying to do some interop testing of script language composites across the Java and C++ runtimes now that we have script languages supported by both? Something like having some Ruby/Python/JavaScript composites which can be used in either the C++ or Java runtimes? I'd help with the Java runtime side if others think this would be useful. ...ant On 9/18/06, Simon Laws [EMAIL PROTECTED] wrote: I was talking with Andy offline about re-running the cross language interop tests. I've recently made some updates to the schema while testing with PHP SDO so I copied the updates back to Tuscany/Interop. There is a patch attached to http://issues.apache.org/jira/browse/TUSCANY-730. There is also a WSDL file in there that exposes an operation for each interop schema taking that schema as input and returning it as output. I'm going to work with Andy to implement a client/service in C++ so that we can test the SDO binding for Axis. When Raymond is done with the new databindings code for M2 we could do the same for Java and between Java and C++. What we could do with in C++ is an XML comparison utility. Anyone come across one? Simon I think this would be a good idea. The cross language test we have done to date have been focused on the SDO support for XML so clearly that can work in Java, C++ and PHP components where we have SDO implementations. Sorting out tests for the other componente types that perhaps don't support SDO yet but would benefit from 1/ testing that the same script works in both Java and C++ runtimes 2/ testing that messages of various formats can be passed successfully from/to the component seems like an excellent idea. The last time I checked the Python C++ extension used a C++ interface definition style but I haven't looked closely enough to see how it handles complex types. I'm also assuming that this will change in the future if it hasn't laready changed. Andy? S
Re: [C++] SDO can't load an XML doc with no namespace
On 9/21/06, Geoffrey Winn [EMAIL PROTECTED] wrote: I won't be able to do anything about this until the week after next at the earliest (ie early October) - but even then I have other commitments. I'll try to find some time to look at it then. Regards, Geoff. On 21/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Geoffrey Winn wrote: I spoke to Ed about this and it seems that when there is no type information available, the XML parser makes a series of assumptions about the structure of the incoming data (for example all elements are assumed to be repeating). Of course, these assumptions are not always correct. It also means that, for example, things that you think of as single valued or simple can be represented as multi-valued or by a data object. The implementation _is_ flawed but it shouldn't be as bad as your example suggests. So yes it is a bug, although even when fixed it may not give quite what you want/expect. On 07/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Well, I can load it, but it's desperately empty :) Given the following XML: customerfirstNameJane/firstNamelastNameDoe/lastName/customer I have no XSD for this document, and don't want to have one or have to define specific SDO types for it. I just want to load this XML into an SDO DataObject. XMLDocumentPtr doc = XMLHelper::load(xml); gives me an XMLDocumentPtr with no root DataObject. char* xml = XMLHelper::save(doc); gives me this: ?xml version=1.0 encoding=UTF-8? Is this supported by our SDO/C++ implementation? or is it a bug? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Do you guys have any update on this one? What would it take to fix it? As Simon said earlier in this thread, getting open content to work would be really handy for script based applications where interfaces and operations are not always known in advance. Thanks, -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I forgot to come back on this one. Sorry about that. What I found was confirmed by Geoff so I cheated to get round it. For a sample I needed to do (Implementing a simple JSON DAS) I defined a single type in the model that had open content and then read in each element in the JSON tree in turn giving it this type in order to create an SDO. I didn't try reading in an XML file using this approach but it would be interesting to see if you can make it work somehow. Of course you end up with an SDO with no useful type information but for my purposes that was OK. I have to get on a train in a bit so I'll give it a go S
Re: [C++/Interop] WS-based interop test added
On 9/26/06, Andrew Borley [EMAIL PROTECTED] wrote: Hi all, I've just checked some code in at http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/test/ws.service.interop/ that does some interop testing as follows: - An Axis2 binding.ws service implementation component is deployed based on the WSDL that Simon put up at http://svn.apache.org/repos/asf/incubator/tuscany/interop/src/main/resources/interop.wsdl - The client code reads in all the schemas and then tests each operation defined in the WSDL by: 1) Reading in the XML file that corresponds to the operation as a DataObject 2) Converting the DataObject to an Axiom node 3) Sending the Axiom node across to the service via SOAP 4) At the service, the binding.ws implementation converts the received Axiom node to a DataObject supplies it to the component implementation. 5) The component implementation reads in the same XML file as was read at the client in step 1 and converts it to a DataObject 6) The component implementation compares the 2 DataObjects via a new compareDataObjects method in tuscany/sca/util/Utils.cpp. If they match, the received DataObject is returned to the client. If they do not match, an error message is printed at the server and NULL is returned. 7) The binding.ws implementation converts the returned DataObject into an Axiom node and returns it to the client via SOAP 8) At the client, the returned Axiom node is converted into a DataObject and is compared to the original DataObject. 9) If any of the loading, conversions or comparisons fail, the test has failed. So, in brief, this tests: XML - SDO - Axiom - SOAP - Axiom - SDO - Axiom - SOAP - Axiom -SDO Currently, the following operations/schemas had to be omitted from the tests because they cause the loading of the WSDL schemas at the server or client to fail (probably due to clashes of schema entities?): Interop05 Interop25 Interop27 Interop39 Due to this the WSDL used at the service is slighly altered (see http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/test/ws.service.interop/resources/interop.wsdl ) Also, the following operations/schemas fail: Interop04 - fails when loading XML file Interop28 - fails on return to client - the SimpleTypeWithName property is not set in the returned DataObject. Interop30 - fails at the service with an SDONullPointerException Interop33 - fails at the service - the property AttributeWithSDOName is not set in the received DataObject Interop40 - fails at the service - the property ElementSubstitutionGroupBase has a single element in the received DataObject but 2 in the loaded DataObject Interop50 - fails at the service - the property anyType is not set in the received DataObject These failures seem to match up with what Simon has already seen documented/raised Jiras for at http://wiki.apache.org/ws/Tuscany/Interop The next things to do are: - create the automake files to get this building/running on Linux - use this client/service for Java - C++ (or vice-versa) interop testing - create a composite with a binding.ws reference that calls the service to enable testing of our binding.ws reference implementation. Any thoughts or ideas on how to fix the issues? Cheers Andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Nice work Andy! Did you hang on to the schema loading errors you got with 05, 25 etc or should I just try and run it up and see? S
Re: [C++] M2 Release
On 10/2/06, Andrew Borley [EMAIL PROTECTED] wrote: Hi All, I think it would be good if we could get our first release candidate cut by or during ApacheCon (which is next week!) - do people think that is possible? With this in mind I propose we concentrate on the higher priority stuff, which to my mind is documentation, samples, build requirements (licencing, build files, etc), the PHP extension and the support for a particular spec level. Do people agree with this? Is there some particular functionality/bug fix that should go in? Cheers Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Andy, sounds like the right thing to do to me. A couple of points... I've haven't got back to making the PHP extension as functional as the Ruby and Python extensions yet. The PHP SCA/SDO releases got in the way. But now PHP SCA is out we can use that as the basis for the PHP extension programming model. In theory its not a big deal but to do it properly will take a little thinking. So I'm not sure we can get it done this week:-( I'm currently looking at the details of the PHP SCA implementation so I'll report back when I know how it works. How did the interop stuff go? I lost track of it a little. Did someone offer to repeat your interop tests on the java side. Getting Java/C++ SCA interop the web service level would be cool as we go into milestone 2. When we tried with M! java their binding implementation didn't work for us but now thats been rewritten so would be good to feed back to java about whether it's good this time. S
Re: [C++] SDO can't load an XML doc with no namespace
On 10/9/06, Pete Robbins [EMAIL PROTECTED] wrote: You are assuming the state of the DataFactory that is passed in when loading the xml. XMLHelperptr xmlH = HelperProvider::getXMLHelper(); // returns clean XML helper with virgin DataFactory XMLDocumentPtr xmlD = xmlH-load(mySchemaless.xml); // your fix would make this work BUT the DataFactory is now frozen XMLDocumentPtr xmlD = xmlH-load(anotherSchemaless.xml); // Bang! - can't add a new open type as DF is frozen I would look at always defining an open type e.g. commonj/sdo#AnyOpenType in a DataFactory. When loading the schemaless xml you create one of these then create the DO's from the xml with this as the root (pseudo-root). The XMLDocument returned would have the first DO defined from the xml as the rootDataObject, not the pseudo-root. Cheers, On 09/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: That is still a separate issue from the one Sebastian raised. Sebastian specifically stated that he did not have an xsd and didn't want one. Loading an XML instance without type information in that situation can be done, via a small xsd file immediately (as a workaround), and via small code change soon. The issue of frozen type systems affects other things besides this one. It needs to be fixed, but it's still a separate question. Geoff. On 09/10/06, Pete Robbins [EMAIL PROTECTED] wrote: Well it depends on which DataFactory you are using during the loading of the xml. I would usually create an XSDHelper and load a schema. I'd then create an XMLHelper using the DataFactory from the XSDHelper. I then load my xml. If I now load a schemaless xml using that XMLHelper how do you create the new Open Type? Cheers, On 09/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: That's a different question. As I understand it, Sebastian (and others) were asking about loading an XML instance document without a corresponding xsd (or any other type information) and as above there is a way to do that and I can hack it to make it a little easier. As you say, you cannot create any type at all after the first data object is created. I'm looking into relaxing that too, but it is a separate issue from processing XML without a schema. Regards, Geoff. On 09/10/06, Pete Robbins [EMAIL PROTECTED] wrote: Can you create an open type on the fly? Is the datafactory not locked once the first DO is created? Cheers, On 09/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: Sebastian, I looked into this a bit more and it may not be as bad as it appears. Currently, when the XML parser encounters an element for which there is no type defined, it ignores that element and all of its content, resuming the parse once that unknown element has ended. The exception to this is when the element is a member of a parent that is defined to have open content. In your example, the root element has no type definition and, of course, it can't have a parent with open content, so it and all of its contents are ignored, which explains the output that you see. I can see one possible workaround and one possible fix for this. The workaround is that you provide an xsd that defines just the root element giving it open content. In your case that would be something like xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema; xsd:element name=customer type=customerType/ xsd:complexType name=customerType xsd:sequence xsd:any namespace=##other processContents=lax/ /xsd:sequence /xsd:complexType /xsd:schema Then the root element has a type and will be processed normally, and everything it contains will be processed as open content. I tried this and it seems to work. The fix would be for me to hack the code so that when we find that a root element has no corresponding type (or possibly when there are no user defined types at all) then I could automagically create an open type for it. This would give the same behaviour as the previous case but spare you the need to provide the .xsd I'm inclined to just go ahead and do that since its not obviously any worse than the current behaviour but I'm open to other ideas. Regards, Geoff. On 07/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Well, I can load it, but it's desperately empty :) Given the following XML: customerfirstNameJane/firstNamelastNameDoe/lastName/customer I have no XSD for this document, and don't want to have one or have to define specific SDO types for it. I just want to load this XML into an SDO DataObject. XMLDocumentPtr doc =
[JAVA SCA] Samples status?
Can someone do a quick update on the status of the samples? I'm trying to run the HelloWorldWS sample from SVN. I got the server working I believe but had to drag in the SDO Jars and the SDO binding Jar into the webapp - they weren't in the sample jar. Interesting thing about this was I got a NPE rather than a class not found when SDO was missing. A little confusing. I haven't got the client (I'm guessing HelloWorldWSClient) to work. I get a NPE when it tries to use the current context. It's difficult to know what jars are required for the client so I put all of the jars that appear in the HelloWorldWS lib dir on the classpath. Now looking at the dev list the samples are undergoing a reorg at the moment so I expect this is all a result of that. It that's the case I'll go a way for a bit and come back and try again when the reorg is done. Regards Simon
Re: PHP with the Java SCA runtime
On 10/10/06, ant elder [EMAIL PROTECTED] wrote: Not for M2 but posting a mail so there's some record of the code...Was messing about in the weekend and got PHP going with the Java SCA runtime. Experimental sandbox code but could be interesting to use to get some interaction with the PHP SCA people and maybe from that help improve the other script language containers supported by the Java runtime. It uses the early access reference impl of JSR-223 and there's a very simple helloworld sample demonstrating an SCA component implemented in PHP. Ended up being quite a mission to get it working but its easy to use now. To run the sample you need to build container-jsr223 [1], build the sample.php[2], download the JSR-223 RI [3], from the RI copy php5ts.dll from jsr223-win32-i386\php5\bin to your JRE bin directory, and when running the sample set the java.library.path system property to the JSR-223 RI PHP install, i.e. - Djava.library.path=C:\Java\JSR-223ea\jsr223-win32-i386\php5\bin ...ant [1] https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/container.jsr223/ [2] https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/sample.php/ [3] http://www.jcp.org/aboutJava/communityprocess/edr/jsr223/ Hey ant, that's pretty cool. We have a similar, service only, i.e. no references in our case, implementation working in C++ and we need to push on and get the other half of it working. Have been waiting for the PHP implementation of SCA to go out which is done now. You can get it from http://www.osoa.org/display/PHP/SCA+with+PHP. In our case a PHP class it used to represent a service. We don't allow functions on their own to be used to implement services and we rely on annotations currently to define the component type, i.e. there are no side files. In the first instance we didn't want script writers to have to write sides files. As an integration point we will move toward side files and that is one of the challenges of taking the next step with the C++ implementation. We want to be able to populate the SCA model with information from the PHP annotations. Would be good to think about what the same level of integration in Java mena if we decide to support the PHP extension fully. Do you know if the php5ts.dll you are using is a standard php dll or has it been modified to work well with java? Regards Simon
Re: [C++] Showing PHP-SDO and PHP-SCA in our BigBank sample?
On 10/16/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Andrew Borley wrote: In the interests of getting a release out sooner rather than later, I think we should leave this for after M2. I've now added the missing makefiles so the PHP client as it currently is should be in RC2. Cheers Andy On 10/16/06, Pete Robbins [EMAIL PROTECTED] wrote: I'm assuming this does not require our Tuscany PHP language extension that we agreed would NOT be in this release? Cheers, On 16/10/06, haleh mahbod [EMAIL PROTECTED] wrote: This is good idea. This sample could also be published on osoa.org where SCA for PHP is posted. On 10/15/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Hi, Our current C++ Bigbank sample includes a nice PHP client that shows how to use the SDO for PHP extension (built on top of our SDO C++ implementation and available at http://pecl.php.net/package/SDO) and the PHP SOAP extensions to invoke the SCA BigBank app. There's now a new SCA for PHP extension available on www.osoa.org (see http://www.osoa.org/display/PHP/SOA+PHP+Homepage). Would it make sense to replace the call to the SOAP extensions by a call to that new SCA for PHP extension? I think it would give us a very nice integration scenario for our M2 release. Could this be added without destabiliziing the release? I just reviewed the RC1 and think we're almost there so I wouldn't want at all to break it by adding stuff at the last minute! On the other hand if it's really easy to modify the PHP part of the Bigbank sample to include that PHP-SCA package that would be really cool... P.S: a side note, that PHP client is pretty well documented, listed in the Readme etc, and looks good, but actually missing from the RC1 binary distro :) this is just a small bug in the build, I'll create a JIRA for this, independent of the question I'm asking here... Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] OK that's fine by me. Like I said earlier in the thread, I wouldn't want to break the release with last minute changes now that's it's stable and almost ready for a vote. After the M2 release is published it would be really cool if somebody in the group could post an article, Blog or add to our Website a description of how to do this on top of our M2... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I'd be more than happy to create a PHP SCA client for Big Bank to either sit alongside or replace the current PHP SDO client. Glad you don't want it for M2 though as I'm a bit bit snowed under this week. Regards Simon
[C++ SDO] Can't copy SDOs with open content
I have created a patch for this problem ( http://issues.apache.org/jira/browse/TUSCANY-873) which solves the immediate problem I have in PHP SDO and passes the PHP SDO tests that exist at the moment. However I'm not too comfortable with it because it is used by numerous parts of data object API function which looks complicated enough already. What I have done is create a internal version of the getPropertyIndex() method called getPropertyIndexInternal() which creates a new property in the data object if the property doesn't already exist and the data object type is open. I use this new method whenever is seems that getPropertyIndex was used during the setting of properties. Can an C++ SDO expert take a look at this and see if this looks OK. Happy to discuss alternative approaches. Regards Simon
Re: [C++ SDO] Can't copy SDOs with open content
On 10/19/06, Pete Robbins [EMAIL PROTECTED] wrote: OK... I've tested this and it works a treat. Is this an issue that you'd like to see fixed in M2 release? We are about to re-spin so it can be included. Cheers. On 19/10/06, Pete Robbins [EMAIL PROTECTED] wrote: forget that... I fixed up your patch On 19/10/06, Pete Robbins [EMAIL PROTECTED] wrote: Simon, what you have done there looks ok to me. However... the patch has hard-coded paths to yor c:\... eclipe directories in. Any chance you can create a friendly patch for me to apply and test? Cheers, On 19/10/06, Simon Laws [EMAIL PROTECTED] wrote: I have created a patch for this problem ( http://issues.apache.org/jira/browse/TUSCANY-873 ) which solves the immediate problem I have in PHP SDO and passes the PHP SDO tests that exist at the moment. However I'm not too comfortable with it because it is used by numerous parts of data object API function which looks complicated enough already. What I have done is create a internal version of the getPropertyIndex() method called getPropertyIndexInternal() which creates a new property in the data object if the property doesn't already exist and the data object type is open. I use this new method whenever is seems that getPropertyIndex was used during the setting of properties. Can an C++ SDO expert take a look at this and see if this looks OK. Happy to discuss alternative approaches. Regards Simon -- Pete -- Pete -- Pete Sorry about the paths in the patch. I can't see how to get rid of them from the Eclipse SVN patch builder. I'll look in a little more detail. I think we should leave it out of M2. I can pick up a revision from SVN with it in as required. Thanks Simon
SDO - dealing with CDATA
This is primarily a C++ question but I guess could apply to Java also. I'm
trying to read a document into C++ SDO that contains a CDATA section. The
corresponding CDATA doesn't make its way into the resulting SDO. I put the
C++ SDO implementation in the debugger and found the reason why:
sax2parser.cpp
void sdo_cdataBlock(void *ctx, const xmlChar *value, int len)
{
}
So the callback exists, gets called with the correct data during the parse,
i.e. LibXML2 is doing the right thing, but the callback is ignored. Is there
a good reason for this? I did a quick search of the C++ and Java specs and
they don't appear to discuss CDATA specifically. Can someone comment on
whether the Java implementation handles CDATA successfully?
Logically, from an SDO point of view, there is probably no need to treat
CDATA specially as the SDO model dictates precisely the difference between
data and structure. We may find that to make the XML DAS function work we
have to know that a property potentially contains markup but I'd have to
look closely at how the C++ SDO implementation of the XML DAS function
streams out SDOs to XML when requested to do so.
If CDATA hasn't been omitted for a good reason I'll come up with a proposal
for C++ SDO.
Regards
Simon
Using Tuscany samples in articles.
Raymond, Haleh and myself are putting together an article describing SCA. We want to submit this to the Java Developers Journal for possible publication when it's done. Raymond has put together a loan approval sample as part of Tuscany ( https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/samples/mortgage/) and we want to use some of the source code and configuration files in the article in order to describe the various features of SCA and how solutions can be implemented using Tsucany SCA. We want to make sure that the Tuscanyproject (and Apache) is happy for us to do this so advice from anyone who has crossed this bridge before is most welcome. Specifically what is the correct way to indicate in the article that we are using ASF Licensed code? Regards Simon
Re: Using Tuscany samples in articles.
On 11/3/06, ant elder [EMAIL PROTECTED] wrote: On 11/1/06, Simon Laws [EMAIL PROTECTED] wrote: Raymond, Haleh and myself are putting together an article describing SCA. We want to submit this to the Java Developers Journal for possible publication when it's done. Raymond has put together a loan approval sample as part of Tuscany ( https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/samples/mortgage/ ) and we want to use some of the source code and configuration files in the article in order to describe the various features of SCA and how solutions can be implemented using Tsucany SCA. We want to make sure that the Tuscanyproject (and Apache) is happy for us to do this so advice from anyone who has crossed this bridge before is most welcome. Specifically what is the correct way to indicate in the article that we are using ASF Licensed code? Regards Simon You can do what you want with the Tuscany code as long as you abide by the Apache license, section 4 sounds relevant - http://www.apache.org/licenses/LICENSE-2.0. I'd guess you need to be asking the publication what their requirements are as they may want to license any code they publish with their own terms and conditions, if so so it may end up being easier if you write a new sample specifically for the article. ...ant Thanks for the reply ant. Yes am wondering if it would be easier to do specific code because it strikes me as quite ungainly to reproduce the appropriate license text alongside the snippets of code that we enevitably want to reproduce. Judging by the flood of responses I guess that most people just write specific samples. Thanks Simon
Re: SDO - dealing with CDATA
On 11/3/06, Frank Budinsky [EMAIL PROTECTED] wrote:
Simon,
The Sequence entry returns a special property:
if (sequence.getProperty(i) == specialCDataProperty) {
String cDataValue = sequence.getValue(i);
}
The problem is that this special property is currently inherited from the
underlying EMF, so it's really not something we want clients to use. RIght
now, this works fine in terms of reading in CDATA and not losing it when
you reserialize, but there's really no proper way for an SDO client to
actually access it. Without using EMF apis, the only way a client can
decide that an entry is CDATA is by looking at the property name (and hope
there's no real property with that name). Longer term, I'm not sure that
even handling it this way is right. Maybe CDATA and other special XML
things should look like mixed text in the sequence (property == null), and
some XMLHelper method (or some Tuscany specific API for now) could be used
to check if it's actually something special like CDATA. Maybe you should
try to do something like that in the C++ impl, and if it looks promissing,
we'll switch the Java impl to do the same.
Frank
Simon Laws [EMAIL PROTECTED] wrote on 11/03/2006 10:18:04 AM:
On 11/3/06, Frank Budinsky [EMAIL PROTECTED] wrote:
In the Tuscany Java implementation we expose CDATA as sequence entries
(like mixed text) with a special CDATA property (we handle comments
in a
similar way). SDO doesn't define a special property for CDATA, so this
is
an implementation-specific feature. I'm not sure, long term, what
should
be the best (proper) way to do this.
Frank.
Simon Laws [EMAIL PROTECTED] wrote on 11/03/2006 09:41:25
AM:
On 10/26/06, Simon Laws [EMAIL PROTECTED] wrote:
This is primarily a C++ question but I guess could apply to Java
also.
I'm
trying to read a document into C++ SDO that contains a CDATA
section.
The
corresponding CDATA doesn't make its way into the resulting SDO. I
put
the
C++ SDO implementation in the debugger and found the reason why:
sax2parser.cpp
void sdo_cdataBlock(void *ctx, const xmlChar *value, int len)
{
}
So the callback exists, gets called with the correct data during
the
parse, i.e. LibXML2 is doing the right thing, but the callback is
ignored.
Is there a good reason for this? I did a quick search of the C++
and
Java
specs and they don't appear to discuss CDATA specifically. Can
someone
comment on whether the Java implementation handles CDATA
successfully?
Logically, from an SDO point of view, there is probably no need to
treat
CDATA specially as the SDO model dictates precisely the difference
between
data and structure. We may find that to make the XML DAS function
work
we
have to know that a property potentially contains markup but I'd
have
to
look closely at how the C++ SDO implementation of the XML DAS
function
streams out SDOs to XML when requested to do so.
If CDATA hasn't been omitted for a good reason I'll come up with a
proposal for C++ SDO.
Regards
Simon
I didn't get any response to this. Here are my further thoughts..
There are a number of options for representing CDATA in SDO, for
example
1) Duplicate the CDATA string as is, including the ![CDATA[ and
]]
markers, to the appropriate property in the data object hiearchy
2) Duplicate the CDATA string excluding the ![CDATA[ and ]]
markers
and instigate a special flag to indicate that CDATA is present.
CDATA is the specific concern of XML, i.e. the chracter entities
that
CDATA
protects an XML parser from are of no
concern to SDO because SDO is not intended to be tied directly to
XML.
So
given the example options above we
either expose the specifics of XML to the SDO core 2) or to the SDO
user
1).
Neither are particularly attractive.
1) appears to be the simplest approach to implement because it
provides
a
mechanism for the user to read, and
create CDATA without having to provide much special support in SDO.
2)
is
more involved particularly because
CDATA can appear mixed in with other text strings and so a sequence
may
need
to be used to represent properties
that have a mixture of text and CDATA marking those sequences
entries
that
are CDATA.
1) does require changes (at least in C++ SDO) because XML parsers
tend
to be
too helpful in this case for
processing CDATA. XML parsers, libxml2 in particular, recognize the
![CDATA[ and ]] sequence as a special
indicator and throw it away returning just the text it includes. We
would
have to reintroduce it and store it in
the parameter value in question. The C++ SDO implementation uses a
lot
of
XML string handling before the parameter
value is actually stored which URL encodes parts of the CDATA
markers so
this would have to be fixed. When writing out the CDATA strings any
Re: SDO - dealing with CDATA
On 11/3/06, Simon Laws [EMAIL PROTECTED] wrote:
On 11/3/06, Frank Budinsky [EMAIL PROTECTED] wrote:
Simon,
The Sequence entry returns a special property:
if (sequence.getProperty(i) == specialCDataProperty) {
String cDataValue = sequence.getValue(i);
}
The problem is that this special property is currently inherited from
the
underlying EMF, so it's really not something we want clients to use.
RIght
now, this works fine in terms of reading in CDATA and not losing it when
you reserialize, but there's really no proper way for an SDO client to
actually access it. Without using EMF apis, the only way a client can
decide that an entry is CDATA is by looking at the property name (and
hope
there's no real property with that name). Longer term, I'm not sure that
even handling it this way is right. Maybe CDATA and other special XML
things should look like mixed text in the sequence (property == null),
and
some XMLHelper method (or some Tuscany specific API for now) could be
used
to check if it's actually something special like CDATA. Maybe you should
try to do something like that in the C++ impl, and if it looks
promissing,
we'll switch the Java impl to do the same.
Frank
Simon Laws [EMAIL PROTECTED] wrote on 11/03/2006 10:18:04
AM:
On 11/3/06, Frank Budinsky [EMAIL PROTECTED] wrote:
In the Tuscany Java implementation we expose CDATA as sequence
entries
(like mixed text) with a special CDATA property (we handle
comments
in a
similar way). SDO doesn't define a special property for CDATA, so
this
is
an implementation-specific feature. I'm not sure, long term, what
should
be the best (proper) way to do this.
Frank.
Simon Laws [EMAIL PROTECTED] wrote on 11/03/2006
09:41:25
AM:
On 10/26/06, Simon Laws [EMAIL PROTECTED] wrote:
This is primarily a C++ question but I guess could apply to Java
also.
I'm
trying to read a document into C++ SDO that contains a CDATA
section.
The
corresponding CDATA doesn't make its way into the resulting SDO.
I
put
the
C++ SDO implementation in the debugger and found the reason why:
sax2parser.cpp
void sdo_cdataBlock(void *ctx, const xmlChar *value, int len)
{
}
So the callback exists, gets called with the correct data during
the
parse, i.e. LibXML2 is doing the right thing, but the callback
is
ignored.
Is there a good reason for this? I did a quick search of the C++
and
Java
specs and they don't appear to discuss CDATA specifically. Can
someone
comment on whether the Java implementation handles CDATA
successfully?
Logically, from an SDO point of view, there is probably no need
to
treat
CDATA specially as the SDO model dictates precisely the
difference
between
data and structure. We may find that to make the XML DAS
function
work
we
have to know that a property potentially contains markup but I'd
have
to
look closely at how the C++ SDO implementation of the XML DAS
function
streams out SDOs to XML when requested to do so.
If CDATA hasn't been omitted for a good reason I'll come up with
a
proposal for C++ SDO.
Regards
Simon
I didn't get any response to this. Here are my further thoughts..
There are a number of options for representing CDATA in SDO, for
example
1) Duplicate the CDATA string as is, including the ![CDATA[ and
]]
markers, to the appropriate property in the data object hiearchy
2) Duplicate the CDATA string excluding the ![CDATA[ and ]]
markers
and instigate a special flag to indicate that CDATA is present.
CDATA is the specific concern of XML, i.e. the chracter entities
that
CDATA
protects an XML parser from are of no
concern to SDO because SDO is not intended to be tied directly to
XML.
So
given the example options above we
either expose the specifics of XML to the SDO core 2) or to the
SDO
user
1).
Neither are particularly attractive.
1) appears to be the simplest approach to implement because it
provides
a
mechanism for the user to read, and
create CDATA without having to provide much special support in
SDO.
2)
is
more involved particularly because
CDATA can appear mixed in with other text strings and so a
sequence
may
need
to be used to represent properties
that have a mixture of text and CDATA marking those sequences
entries
that
are CDATA.
1) does require changes (at least in C++ SDO) because XML parsers
tend
to be
too helpful in this case for
processing CDATA. XML parsers, libxml2 in particular, recognize
the
![CDATA[ and ]] sequence as a special
indicator and throw it away returning just the text it includes.
We
would
have to reintroduce it and store it in
the parameter value in question. The C++ SDO
Re: [C++] Where next for Tuscany C++?
On 11/8/06, Andrew Borley [EMAIL PROTECTED] wrote: Hi everyone, Now M2 is finally available, we should start thinking about what we'd like to do next in Tuscany C++. There were quite a few items that were suggested for M2 that we ended up leaving out for time reasons and it would be good to progress the function we have in M2. Things I would like to do/see: - Add initial support for SDO handling in the Python extension (as an XML serialization) - Remove requirement for componentType side-files for Python components - Get the PHP extension up to the level of the Ruby/Python extensions - perhaps by using the SCA for PHP stuff (http://www.osoa.org/display/PHP/SCA+with+PHP ) - Improve the samples for the scripting languages (nebulous! does anyone have any good ideas?) - A sample showing the different languages working together. - A standalone REST binding - we can do a limited REST via the support in Axis2C, but I think it would be cool to have a real binding.rest that we can host in HTTPD. Please join in with your own thoughts/plans! Cheers Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Andy I like the idea of extending the PHP extension and it would be pretty interesting to see if we can make the PHP extension use the SCA for PHP work we have in the PECL SCA_PHP project (see the homepage at http://www.osoa.org/display/PHP/SOA+PHP+Homepage). I do of course have a vested interest here ;-) In PHP SCA we don't use component type files instead we rely on annotations and we also have SDO integration. The thing about this is that we have a set of APIs that are, to some extent, an interpretation of SCA and SDO as we thought they should be presented in a scripting language. Now it may very well be that our interpretation needs adjusting so this exercise of looking at PHP, Python, Ruby extensions to C++ SCA together will be really useful. Of particular interest is how we push down the model from the scripting language into the C++ model. So I imagine a set of APIs that allow us to extend/complete the SCA C++ model by adding components type, components, services, references, wires etc. as a result of parsing the information in a supplied script. There is an interesting crossover point when it comes to bindings, i.e. we have the oppotunity to leverage scripted or native bindings. From a samples point of view, the likes of PHP and Ruby get used a lot to implement web applications and particulary now as the service providers for AJAX applications. In particuar we now have JSON-RPC/SMD support in PHP SCA (just about to be checked into PECL). So we could do something there showing how SCA describes integration through multiple application tiers. The big question for me is how langauge specific do the sample have to be. It's useful to have a single sample that shows how you do SCA stuff in all of the different extensions. Calculator? But I think it would also be useful to show the extensions operating in some more systematic sample. I'm a little sceptical about just using the extensions arbitrarily in samples like big bank but would rather use them where they are appropriate. So using a PHP or Ruby component to provide the GUI experience for Big Bank makes perfect sense. Just implementing the account service in Ruby or PHP is less compelling. I don't have that much experience of Python. The one time I have come across it we were using it for infrastructure scripting I.e. we were using it in place of a shell script so it would be interesting to have some SCA components that play this role. In my particular case we we were providing a job execution service so we had a number of scripts, e.g. assess job, provision servers, provision data, run jobs, retrieve results etc. We could pick any process where scritps are often use, e,g, ETL/data processing pipelines or batch control. Perhaps we could invent some data/document processing pipeline that has various scripted components that can be wired in in different ways to change the end effect, for example, you can imagine todays application developers being familir with scripting in data integration scenarios where they have to build service which go and pull answers from lots of web sites and data resources. A script being required to handle the peculiarities of each web site's particluar API. Typically a problems in the tell me all the houses for sale in my area type of question. SCA script components would be good here because you can use the environment most appropriate for the peculiaries of the particular data source in question and then use SCA to stitch it together. Anyhow just some thoughts. In doing all this scripting stuff we need to think about how SCA is hosted. Currently we have Axis and local hosting IIRC. We need to think about more direct HTTPD hosting. This is not the same as, but fits alongside, the REST binding
Re: [SDO] Hello rfc for what could be useful
On 11/13/06, Andrew Borley [EMAIL PROTECTED] wrote: Hi Dan, The C++ interop test service I added is at http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/test/ws.service.interop/ This can be run on Linux via make check (after it's been built) or on Windows via the ws.service.interop.client/runclient.bat file - this uses the 50-odd SDO interop schemas copied from http://svn.apache.org/repos/asf/incubator/tuscany/interop/ and exposes each one as a web service operation, implemented by a C++ class. Each class method takes a DataObject, compares it with one loaded from some XML on the file system and returns it back to the client (where it is also compared with the original from the file system). See the following thread for more info: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08385.html Hope that's useful - I'm happy to help improve/expand on this Cheers Andy On 11/13/06, Dan Murphy [EMAIL PROTECTED] wrote: Hi Simon, Interop testing with PHP, C++, etc was certainly one of the things I was thinking of... The way I see it is that the tests could be run in a number of different modes: serialiseSDOs - serialise SDO object to file system so they could be loaded by different impl deserialiseSDOs - load SDO objects from serialised useDynamicSDOs - programatically generate SDO using APIs useGeneratedSDOs - generate SDOs from schema and use the generated ones to run tests I see serialise/deserialise option used to test interop between different implementations of SDO - esp interop between implimentation languages. The useGeneratedSDOs only makes sense with Java implementations (as I understand it Java is the only one to generate simple objects to represent SDOs). All the tests would need to cover the features descriped in the spec (or agreed subset), for the serialise/deserialise tests to work there would need to be shared SDO descriptions used - eg. C++ serialises a customer and Java deserialises it and checks the SDO is as expected). I'd be happy to work on the Java side, my C++ is rather poor so together I think we could make some progress together - if the interop is needed... as you say, would be a poor show if (complex) C++ serialised SDOs couldn't be read by the Java impl... Cheers, Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Dan Sounds like we are singing from the same hymn sheet as they say. We have concentrated on the serialize/deserialize SDOs for the cross language interop work we have done to date. This is the natural mode of operation when passing an SDO, i.e. it is serialized at one end and deserialised at the other. From Andy's descripition you can see how SDOs are bounced back and forth and compared with one another. What we need is a Java version of the same service so we can have java play opposite itself and C++ as both client and server. We should look at dynamic SDOs too (for the sample schemas?) but we haven't got round to that yet. We tried to summarize the various tests that need running in the README.txtassoicated with the interop test cases ( https://svn.apache.org/repos/asf/incubator/tuscany/interop/src/main/resources/README.txt). This could well do with a bit of review and updating now. Might be a good place to start. Regards Simon
