[jira] Created: (TUSCANY-489) Add support for xsd:byte type to WS Entrypoint
Add support for xsd:byte type to WS Entrypoint -- Key: TUSCANY-489 URL: http://issues.apache.org/jira/browse/TUSCANY-489 Project: Tuscany Type: Improvement Components: C++ SCA Versions: Cpp-M1 Reporter: Andrew Borley Priority: Minor xsd:byte is not currently supported - add this with a mapping to C++ char type -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-489) Add support for xsd:byte type to WS Entrypoint
[ http://issues.apache.org/jira/browse/TUSCANY-489?page=all ] Andrew Borley updated TUSCANY-489: -- Attachment: TUSCANY-489.patch Adds xsd:byte support . This builds on the patch for xsd:any support (TUSCANY-480), so apply that first. Add support for xsd:byte type to WS Entrypoint -- Key: TUSCANY-489 URL: http://issues.apache.org/jira/browse/TUSCANY-489 Project: Tuscany Type: Improvement Components: C++ SCA Versions: Cpp-M1 Reporter: Andrew Borley Priority: Minor Attachments: TUSCANY-489.patch xsd:byte is not currently supported - add this with a mapping to C++ char type -- 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: 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]
[C++] Documentation patches for WS Entrypoint code
Hi All, Just drawing a little attention to a few patches doc I've put up over the last few days to improve the Axis2C WS Entrypoint stuff. Tuscany-486 has a text document that covers: - Defining an SCA Module with a WS EntryPoint - Deploying a new service in Axis2C - XML Schema type to C++ type mapping - Notes on supported WS styles message types Tuscany-480 has a patch to add support for services with xsd:any types (this gets mapped to a DataObjectPtr with OpenDataObjectType) and also upgrades the tests to Axis2C 0.92 Tuscany-489 has a patch that builds on Tuscany-480 and adds support for the xsd:byte type (which is mapped to a C++ char) I'm not sure what the etiquette is on drawing attention to these things - I personally find that specific Jira e-mail notifications get lost in the blizzard of all the other Jira things that are happening in Tuscany (of course, this wouldn't be a problem if I was a committer *cough*karmaforandy*cough* ;-) ) Cheers Andy
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: [C++] Documentation patches for WS Entrypoint code
Cheers Pete! On 6/23/06, Pete Robbins [EMAIL PROTECTED] wrote: Andy, I have noticed these and they are on my TODO list (together with your fixes to the scagen tool). I hope to check and apply these patches soon (next couple of days). Cheers, On 23/06/06, Andrew Borley [EMAIL PROTECTED] wrote: Hi All, Just drawing a little attention to a few patches doc I've put up over the last few days to improve the Axis2C WS Entrypoint stuff. Tuscany-486 has a text document that covers: - Defining an SCA Module with a WS EntryPoint - Deploying a new service in Axis2C - XML Schema type to C++ type mapping - Notes on supported WS styles message types Tuscany-480 has a patch to add support for services with xsd:any types (this gets mapped to a DataObjectPtr with OpenDataObjectType) and also upgrades the tests to Axis2C 0.92 Tuscany-489 has a patch that builds on Tuscany-480 and adds support for the xsd:byte type (which is mapped to a C++ char) I'm not sure what the etiquette is on drawing attention to these things - I personally find that specific Jira e-mail notifications get lost in the blizzard of all the other Jira things that are happening in Tuscany (of course, this wouldn't be a problem if I was a committer *cough*karmaforandy*cough* ;-) ) Cheers Andy -- Pete -- Cheers, Andrew Borley
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
Re: XML Comparison
It has a BSD style license so it would likely be fine even if we did want to redistribute it, but as you say, we'll only be using it for testing. If its sounds like it suits you're needs I'd say go for it. Its in ibiblio so just add it to your pom.xml: dependency artifactIdxmlunit/artifactId groupIdxmlunit/groupId version1.0/version scopetest/scope /dependency ...ant On 6/23/06, Simon Laws [EMAIL PROTECTED] wrote: 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
[jira] Created: (TUSCANY-490) DataObjectPtr::getByte returns incorrect data
DataObjectPtr::getByte returns incorrect data
-
Key: TUSCANY-490
URL: http://issues.apache.org/jira/browse/TUSCANY-490
Project: Tuscany
Type: Bug
Components: C++ SDO
Versions: Cpp-current
Reporter: Andrew Borley
Priority: Minor
Some xml like byte123/byte where the byte element contains an xsd:byte
type, is converted into a DataObject and then queried.
// returns the correct data: 123
const char* cs = myDataObjectPtr-getCString(byte);
// Returns incorrect data: '1' (Ox31) - looks like it's just taking the first
character, rather than converting 123 to the character '{' (Ox7B)
char c = myDataObjectPtr-getByte(byte);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-491) Incorrect namespaces support
Incorrect namespaces support Key: TUSCANY-491 URL: http://issues.apache.org/jira/browse/TUSCANY-491 Project: Tuscany Type: Bug Components: C++ SDO Versions: Cpp-current Reporter: Andrew Borley Priority: Minor A schema defined like the following means that rootElement has the namespace http://www.apache.org/tuscany/interop;, but stringData has no namespace. schema xmlns=http://www.w3.org/2001/XMLSchema; targetNamespace=http://www.apache.org/tuscany/interop; element name=rootElement complexType sequence element name=stringData type=string/ /sequence /complexType /element /schema So XML like the following is correct for this schema: tns:rootElement xmlns:tns=http://www.apache.org/tuscany/interop; stringDataSome string data/stringData /tns:RootElement51 However, SDO produces XML like the following, with the use of the xmlns attribute meaning that stringData inherits the http://www.apache.org/tuscany/interop; namespace from rootElement: rootElement xmlns=http://www.apache.org/tuscany/interop; stringDataSome string data/stringData /rootElement -- 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]
Introduction and deployment ideas...
Hi Folks, I wanted to introduce myself to the people on the list. I work for IBM Research in Hawthorne, NY in a group that has been working on component-oriented programming, Web services and SOA-related things for quite a few years now. I was one of the original co-authors of Apache SOAP (originally IBM SOAP), was the primary original author of WSDL4J, and various other related things. I'm currently a committer on Apache Woden (albeit, I am not heavily involved). I've been doing some preliminary work on a deployment tool for Tuscany. While it's not quite yet in a state worthy of contribution, I was hoping to go through some of the ideas here to get some feedback. I've talked quite a bit with Jean-Sebastien, and he pointed out that these ideas should really be evolved here on the list. Initial steps: - Replicate what we currently have Maven doing for us, but in a generic way. That is, create some code that can be executed from the command-line, run as a Maven plugin, embedded in Eclipse, etc... I have some code now that will build a WAR, and deploy it to the appropriate location within a local Tomcat. This code can be run from the command-line, and has been wrapped in a Maven plugin. The steps I am working on now: - Change the code to first check if the WAR has already been created (instead of always packaging a new WAR). - Tuscany-enable (that is, configure) Tomcat to accept and run WARs containing Tuscany modules. (The current code expects Tomcat to have already been Tuscany-enabled. I'm adding the capability to the deployment tool to, in effect, deploy Tuscany itself to a local instance of Tomcat.) This bit of code could evolve to intelligently install just the dependencies required of the modules being deployed. - Add support for additional target platforms (maybe Jetty?). - Add support for deploying Tuscany modules to remote Tomcat instances. This will require Tuscany to expose the sort of admin/management/reflection interfaces that have recently been discussed on the list. - Once the above items are completed, it should be straightforward to support wiring (and actually deploying) an entire subsystem. Also, it is clear that the various extensions will need to be able to contribute deployment behavior at some point. I'd like to add support for this capability, and I'm looking for concrete examples now. If people are interested, I'd be willing to check what I'm working on into a sandbox branch very shortly. Thanks, -Matt Duftler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SDO2XSD [EMAIL PROTECTED]
Hello Frank, Raymond and Jean I have attached a first cut of the XSD Generator under JIRA-120 and am looking for some comments on the approach therein. For the SDOs I have used the XSD2JavaGenerator from the sdo-tools project using the sequences.xsd as input. I am simply following what is laid out in the SDO Spec v 2.0.1 in the section Generation of XSD from SDO Type and Property from 107. Here are some issues that I have come across upto now with a part of the specs implemented. Issues -- 1) When a complex type allows mixed content i.e. has the attribute 'mixed=true' the SDO's type.sequenced is rightly set to true. However in addition to this, there is a property named 'mixed' that is added to the SDO Type. Issue : When the SDO is used to generate an XSD this property 'mixed' ends up as an element within a complex type. 2) On Pg 109 of the SDO spec. states that when SDOType.sequenced is true then add the attritbute mixed=true to the complex type and the element xsd:choice maxOccurs=unbounded. Why is this a choice and not a sequence? Issue: The MixedQuote complex type in sequences.xsd for which I generated the SDOs is of mixed content but the group within this complex type is a 'sequence' and not a choice. i.e. xsd:sequence. Question : Is this something that must be fixed in the specs or 3)For xsd:choice the generated SDO includes a property named 'group'. If there are more than on xsd:choice elements then, there are as many properties named as group1, group2 etc. Further the SDO.Type.isOpen is set to 'true' for the SDO that contains these properties Issue : As in the case of 'mixed' here also, having a property within the SDO results in an xsd with elememts named 'group', 'group1' etc. with the property.isMany = true; Issue: Since the SDO.Type.isOpen is set to true when the SDO is used to generate the xsd, there is an additional element xs:any processContents=lax maxOccurs=unbounded / that is generated since it is assumed to be open content. Issue: The elements within the xsd:choice also become properties of the SDO and hence the grouping information is lost. i.e. for the xsd xsd:choice maxOccurs=unbounded minOccurs=0 xsd:element name=a type=xsd:string / xsd:element name=b type=xsd:int / /xsd:choice there are three properties added to the SDO.Type namely group, a and b. When the SDO is used to generate the xsd again, there are three elements generated. Here is the final output. xs:sequence xs:any processContents=lax maxOccurs=unbounded / xs:element minOccurs=0 name=group maxOccurs=unbounded / xs:element minOccurs=0 type=xs:string name=a maxOccurs=unbounded / xs:element minOccurs=0 type=xs:int name=b maxOccurs=unbounded / /xs:sequence The information about what elements are under the xsd:choice is not available in the SDO. Question : Is the XSD2SDO generation right? Is this something that must be fixed in the specs. or is it wrong intepretation of the XSDGenerator that I have developed I shall go ahead and address the other items in the specs as well and shall probably get back with some more of these. Thanks. - Venkat
Re: SDO2XSD [EMAIL PROTECTED]
Hi Venkat, The main problem seems to be related to the fact that we currently include special properties like mixed, group, any, etc. We plan to change this in the next few weeks, so the problems you're having related to them should go away. The other problem is that the XSD generation described in the spec will generate a reasonable Schema for SDO types, but since SDO types don't capture all the necessary XSD metadata, types that are originally created from an XML Schema won't roundtrip back to the same schema. If we want them to, then we need to add annotations to the SDO metadata to modify the XSD generators output. Have you looked at how EMF's XSD generator supports schema-ecore-schema roundtripping? If we want to, we can try to support roundtripping in Tuscany with some implementation-specific apis and then look at proposing extensions to the spec in the future. Frank. Venkata Krishnan [EMAIL PROTECTED] wrote on 06/23/2006 09:52:34 AM: Hello Frank, Raymond and Jean I have attached a first cut of the XSD Generator under JIRA-120 and am looking for some comments on the approach therein. For the SDOs I have used the XSD2JavaGenerator from the sdo-tools project using the sequences.xsd as input. I am simply following what is laid out in the SDO Spec v 2.0.1 in the section Generation of XSD from SDO Type and Property from 107. Here are some issues that I have come across upto now with a part of the specs implemented. Issues -- 1) When a complex type allows mixed content i.e. has the attribute 'mixed=true' the SDO's type.sequenced is rightly set to true. However in addition to this, there is a property named 'mixed' that is added to the SDO Type. Issue : When the SDO is used to generate an XSD this property 'mixed' ends up as an element within a complex type. 2) On Pg 109 of the SDO spec. states that when SDOType.sequenced is true then add the attritbute mixed=true to the complex type and the element xsd:choice maxOccurs=unbounded. Why is this a choice and not a sequence? Issue: The MixedQuote complex type in sequences.xsd for which I generated the SDOs is of mixed content but the group within this complex type is a 'sequence' and not a choice. i.e. xsd:sequence. Question : Is this something that must be fixed in the specs or 3)For xsd:choice the generated SDO includes a property named 'group'. If there are more than on xsd:choice elements then, there are as many properties named as group1, group2 etc. Further the SDO.Type.isOpen is set to 'true' for the SDO that contains these properties Issue : As in the case of 'mixed' here also, having a property within the SDO results in an xsd with elememts named 'group', 'group1' etc. with the property.isMany = true; Issue: Since the SDO.Type.isOpen is set to true when the SDO is used to generate the xsd, there is an additional element xs:any processContents=lax maxOccurs=unbounded / that is generated since it is assumed to be open content. Issue: The elements within the xsd:choice also become properties of the SDO and hence the grouping information is lost. i.e. for the xsd xsd:choice maxOccurs=unbounded minOccurs=0 xsd:element name=a type=xsd:string / xsd:element name=b type=xsd:int / /xsd:choice there are three properties added to the SDO.Type namely group, a and b. When the SDO is used to generate the xsd again, there are three elements generated. Here is the final output. xs:sequence xs:any processContents=lax maxOccurs=unbounded / xs:element minOccurs=0 name=group maxOccurs=unbounded / xs:element minOccurs=0 type=xs:string name=a maxOccurs=unbounded / xs:element minOccurs=0 type=xs:int name=b maxOccurs=unbounded / /xs:sequence The information about what elements are under the xsd:choice is not available in the SDO. Question : Is the XSD2SDO generation right? Is this something that must be fixed in the specs. or is it wrong intepretation of the XSDGenerator that I have developed I shall go ahead and address the other items in the specs as well and shall probably get back with some more of these. Thanks. - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Introduction and deployment ideas...
Sounds great and really useful to me so yes please send us the code! ...ant On 6/23/06, Matthew Duftler [EMAIL PROTECTED] wrote: Hi Folks, I wanted to introduce myself to the people on the list. I work for IBM Research in Hawthorne, NY in a group that has been working on component-oriented programming, Web services and SOA-related things for quite a few years now. I was one of the original co-authors of Apache SOAP (originally IBM SOAP), was the primary original author of WSDL4J, and various other related things. I'm currently a committer on Apache Woden (albeit, I am not heavily involved). I've been doing some preliminary work on a deployment tool for Tuscany. While it's not quite yet in a state worthy of contribution, I was hoping to go through some of the ideas here to get some feedback. I've talked quite a bit with Jean-Sebastien, and he pointed out that these ideas should really be evolved here on the list. Initial steps: - Replicate what we currently have Maven doing for us, but in a generic way. That is, create some code that can be executed from the command-line, run as a Maven plugin, embedded in Eclipse, etc... I have some code now that will build a WAR, and deploy it to the appropriate location within a local Tomcat. This code can be run from the command-line, and has been wrapped in a Maven plugin. The steps I am working on now: - Change the code to first check if the WAR has already been created (instead of always packaging a new WAR). - Tuscany-enable (that is, configure) Tomcat to accept and run WARs containing Tuscany modules. (The current code expects Tomcat to have already been Tuscany-enabled. I'm adding the capability to the deployment tool to, in effect, deploy Tuscany itself to a local instance of Tomcat.) This bit of code could evolve to intelligently install just the dependencies required of the modules being deployed. - Add support for additional target platforms (maybe Jetty?). - Add support for deploying Tuscany modules to remote Tomcat instances. This will require Tuscany to expose the sort of admin/management/reflection interfaces that have recently been discussed on the list. - Once the above items are completed, it should be straightforward to support wiring (and actually deploying) an entire subsystem. Also, it is clear that the various extensions will need to be able to contribute deployment behavior at some point. I'd like to add support for this capability, and I'm looking for concrete examples now. If people are interested, I'd be willing to check what I'm working on into a sandbox branch very shortly. Thanks, -Matt Duftler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (TUSCANY-120) Axis2 WS binding support for entryPoint without pre-existing WSDL
Hi, With respect to submitting it as patch for the SDO XSDHelper.generate(Types), yes that is what I plan to do ultimately. Though my objective is to bring in SDO type support into the java2WSDL tool, I wish to be able to abstract this out in a way that it contributes to the SDO XSDHelper and also integrates with the tool. But then, in the generated xsds to not compare well with the ones that I originally used to generate the SDOs. So if I go ahead, then it must be with an assumption that the SDO code gen is going to be fixed or the specs itself is going to be updated. I will probably come up with a set of assumptions and get it validated by the community. With respect to the mapping of the simple data types, I have been able to manage it as you might observe from the outputs that I have attached in JIRA-120. The same goes with the annotations, I have been able to add annotations with the sdo and sdoJava namespaces as mentioned in the specs. I did not find any 'ecore' qualified annotations in the specs. So I seem to have the mechanisms for xsd generation in place (atleast to some extent). It is now a question of how the SDO metadata is interpretted. Thanks Venkat On 6/23/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Please see my comments below. Thanks, Raymond - Original Message - From: Venkatakrishnan (JIRA) tuscany-dev@ws.apache.org To: [EMAIL PROTECTED] Sent: Wednesday, June 21, 2006 7:04 PM Subject: [jira] Updated: (TUSCANY-120) Axis2 WS binding support for entryPoint without pre-existing WSDL [ http://issues.apache.org/jira/browse/TUSCANY-120?page=all ] Venkatakrishnan updated TUSCANY-120: Attachment: xsdgen.zip Hi, To address this, I have started with generation of XSDs from static SDOs for now. If this part is thro, I suppose integrating it with WSDL generation can be managed. Before I go futher I want to do a sanity check over what I have implemented here on whether it is the right approach, on whether I have done the right things upto now... hence I am attaching whatever I have done for inputs / comments from the community. Here is what I did ... - Firstly I have assumed that the user will be able to input the SDO Factory class and obviously the classnames of the static SDOs for which xsds are to be generated Ideally, we should be able to figure out the SDO factory from the generated SDO classes. If not, it could be a requirement for the SDO code-gen. - I followed the specifications the SDO v2.0.1 specs document - section titled Generation of XSD from SDO Type and Property (Page 107) - I have implemented for most basic rules specified therein but have quite some yet to be addressed. Why don't you submit them as patches to SDO XSDHelperImpl? I know there are some grey areas in the spec, for example, all simple XSD types are mapped into commonj.sdo namespace by SDO and a straght code-gen can produce a XSD as follows. xsd:complexType ecore:instanceClass=org.example.creditscore.doclit.Customer name=Customer xsd:sequence xsd:element name=ssn type=sdo:String/ xsd:element name=firstName type=sdo:String/ xsd:element name=lastName type=sdo:String/ /xsd:sequence /xsd:complexType How do we deal with SDO annotations here? Do we expect the following one instead? I'm not sure if XSD -- SDO -- XSD roundtrip is supported per SDO spec. xsd:complexType ecore:instanceClass=org.example.creditscore.doclit.Customer name=Customer xsd:sequence xsd:element name=ssn type=xsd:String/ xsd:element name=firstName type=xsd:String/ xsd:element name=lastName type=xsd:String/ /xsd:sequence /xsd:complexType - I have tested with two sets of SDOs 1) that Raymond had attached previous in this JIRA (CreditReport classes) and 2) SDOs generated using the Tuscany - XSD2JavaGenerator tool from the sequences.xsd (an xsd that I picked up from the sdo-tools project) Here are my findings with the outputs generated: - - the outputs generated for the CreditReport sample is ok. - the outputs generated for sequences.xsd has quite a few discrepencies when compared with the original one. I'd like to have comments on whether I have interpretted the specs properly or is it something we must start fixing with annotations (additional information) appended to the generated SDOs. I have attached my entire eclipse project directory with all relevant classes and outputs. I have also attached the .classpath and .project files just in case any of you would like to import this project into your eclipse IDEs and try. Thanks. Axis2 WS binding support for entryPoint without pre-existing WSDL -- Key: TUSCANY-120 URL: http://issues.apache.org/jira/browse/TUSCANY-120 Project: Tuscany Type: Bug Components: Java SCA Axis Binding Versions: Java-Mx Reporter: ant
Re: Introduction and deployment ideas...
Hi Matt, I would be really interested to see your code. I was also looking into something similar for the Tuscany Javascrip shell, which is discussed in this Jira : [1] http://issues.apache.org/jira/browse/TUSCANY-417 Thanks and regards, jojo. On 6/23/06, ant elder [EMAIL PROTECTED] wrote: Sounds great and really useful to me so yes please send us the code! ...ant On 6/23/06, Matthew Duftler [EMAIL PROTECTED] wrote: Hi Folks, I wanted to introduce myself to the people on the list. I work for IBM Research in Hawthorne, NY in a group that has been working on component-oriented programming, Web services and SOA-related things for quite a few years now. I was one of the original co-authors of Apache SOAP (originally IBM SOAP), was the primary original author of WSDL4J, and various other related things. I'm currently a committer on Apache Woden (albeit, I am not heavily involved). I've been doing some preliminary work on a deployment tool for Tuscany. While it's not quite yet in a state worthy of contribution, I was hoping to go through some of the ideas here to get some feedback. I've talked quite a bit with Jean-Sebastien, and he pointed out that these ideas should really be evolved here on the list. Initial steps: - Replicate what we currently have Maven doing for us, but in a generic way. That is, create some code that can be executed from the command-line, run as a Maven plugin, embedded in Eclipse, etc... I have some code now that will build a WAR, and deploy it to the appropriate location within a local Tomcat. This code can be run from the command-line, and has been wrapped in a Maven plugin. The steps I am working on now: - Change the code to first check if the WAR has already been created (instead of always packaging a new WAR). - Tuscany-enable (that is, configure) Tomcat to accept and run WARs containing Tuscany modules. (The current code expects Tomcat to have already been Tuscany-enabled. I'm adding the capability to the deployment tool to, in effect, deploy Tuscany itself to a local instance of Tomcat.) This bit of code could evolve to intelligently install just the dependencies required of the modules being deployed. - Add support for additional target platforms (maybe Jetty?). - Add support for deploying Tuscany modules to remote Tomcat instances. This will require Tuscany to expose the sort of admin/management/reflection interfaces that have recently been discussed on the list. - Once the above items are completed, it should be straightforward to support wiring (and actually deploying) an entire subsystem. Also, it is clear that the various extensions will need to be able to contribute deployment behavior at some point. I'd like to add support for this capability, and I'm looking for concrete examples now. If people are interested, I'd be willing to check what I'm working on into a sandbox branch very shortly. Thanks, -Matt Duftler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Warm regards, jojo.
[jira] Updated: (TUSCANY-250) Need better error message when config entered incorrectly
[ http://issues.apache.org/jira/browse/TUSCANY-250?page=all ] Darius S. DeJesus updated TUSCANY-250: -- Attachment: Tuscany-250 A more uptodate version, disregard the last file posted, this one is cleaner. Need better error message when config entered incorrectly - Key: TUSCANY-250 URL: http://issues.apache.org/jira/browse/TUSCANY-250 Project: Tuscany Type: Bug Components: Java DAS RDB Versions: Java-Mx Reporter: Kevin Williams Fix For: Java-Mx Attachments: Tuscany-250, Tuscany-250 Incorrect config innformation often results in EMF index out of bounds exceptions. We should prevent these errors if possible by recognizing invalid config and throwing an meaningful exception. ExceptionsTests.test_4() demonstrates this problem -- 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]
Tuscanys wiring model
Hi, I'm currently working on a presentation about tuscany's wiring and autowiring concepts for my studies. Up until now, I was staring at the java code and some of the javadoc... ;) I identified the mechanisms of the Interceptors, MessageHandlers and TargetInvokers, which are used on the source and target side of a wire. However, I still can't get behind the goal of all this stuff. By now, it seems to me that the wires are built up by the Runtime once the module is loaded and hided from the application developer who just uses tuscany. Is this right? But the usages of interceptors and handlers who come into my mind (e.g. logging, filtering, conversation) require access to the internal wire model by the application developer, if he for example wants to hook his own interceptor into the wirechain. Additionaly, I didn't found many classes implementing interceptor and messagehandler interfaces, i.e. only only MessageDispatcher extends MessageHandler and therefore I dont see something really using the messagechannels. ;) In http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg04104.html I read about the showcase features of SCA. I think, features like dynamic re-wiring would need sophisticated knowledge about tuscanys wiring by the application developer as he is the only one, who can decide whether to use this feature, didn't it? So my concrete question is: Why there is such a complex wirechain if it is almost not used (by now)? What are your goals with it, if wires are managed by the Tuscany Runtime, and not the application developer? As a last example, I could imagine using the MessageDispatcher to broadcast an invocation to more than one components (whyever). But this wouldn't be possible according to the spec because a wire is defined as the connection between two components. Greets, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
building java-M1-final - missing celtix jars
Most of the java-M1-final code release builds for me, but It fails with these errors. I don't see these jars in ibiblio, celtix, etc, Anyway, I don't need the celtix bindings so i will bypass them in the build. Just wanted to report the error. -Tom Missing: -- 1) javax.annotation:jsr250-api:jar:2.0-JAXWS-2.0-EA3 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId= javax.annotation-DartifactId=jsr250-api \ -Dversion=2.0-JAXWS-2.0-EA3 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sca.bindings:tuscany-binding-celtix:jar:incubating-M1 2) org.objectweb.celtix:celtix-rt:jar:1.0 3) org.objectweb.celtix:celtix-tools:jar:1.0 4) org.objectweb.celtix:celtix-common:jar:1.0 5) javax.annotation:jsr250-api:jar:2.0-JAXWS-2.0-EA3 2) javax.jws:jsr181-api:jar:2.0-JAXWS-2.0-EA3 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=javax.jws -DartifactId=jsr181-api \ -Dversion=2.0-JAXWS-2.0-EA3 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sca.bindings:tuscany-binding-celtix:jar:incubating-M1 2) org.objectweb.celtix:celtix-rt:jar:1.0 3) org.objectweb.celtix:celtix-tools:jar:1.0 4) javax.jws:jsr181-api:jar:2.0-JAXWS-2.0-EA3 3) javax.xml:saaj-api:jar:1.3 Try downloading the file manually from: https://jax-ws.dev.java.net/files/documents/4202/24765/JAXWS_SI_20051128.jar Then, install it using the command: mvn install:install-file -DgroupId=javax.xml -DartifactId=saaj-api \ -Dversion=1.3 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sca.bindings:tuscany-binding-celtix:jar:incubating-M1 2) org.objectweb.celtix:celtix-rt:jar:1.0 3) org.objectweb.celtix:celtix-tools:jar:1.0 4) javax.xml:saaj-api:jar:1.3 4) javax.xml:jaxws-api:jar:2.0-JAXWS-2.0-EA3 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=javax.xml -DartifactId=jaxws-api \ -Dversion=2.0-JAXWS-2.0-EA3 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sca.bindings:tuscany-binding-celtix:jar:incubating-M1 2) org.objectweb.celtix:celtix-rt:jar:1.0 3) org.objectweb.celtix:celtix-tools:jar:1.0 4) org.objectweb.celtix:celtix-common:jar:1.0 5) javax.xml:jaxws-api:jar:2.0-JAXWS-2.0-EA3 -- 4 required artifacts are missing. for artifact: org.apache.tuscany.sca.bindings:tuscany-binding-celtix:jar:incubating-M1 from the specified remote repositories: central (http://repo1.maven.org/maven2), objectweb (http://maven.objectweb.org/maven2), ibiblio ( http://www.ibiblio.org/maven2)
[jira] Created: (TUSCANY-492) recently added file XMLStreamHelperTestCase.java is not compatible with JDK 1.4
recently added file XMLStreamHelperTestCase.java is not compatible with JDK 1.4 --- Key: TUSCANY-492 URL: http://issues.apache.org/jira/browse/TUSCANY-492 Project: Tuscany Type: Bug Components: Java SDO Implementation Versions: Java-M2 Environment: Windows XP Reporter: Paul Golick In XMLStreamHelperTestCase.java there are two uses of a java.lang.String instance method contains(java.lang.String). This method was not added until Java 1.5; so, it is not found in the class library for Java 1.4 The attached patch changes x.contains(y) to the nearly equivalent x.indexOf(y)!=-1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-492) recently added file XMLStreamHelperTestCase.java is not compatible with JDK 1.4
[ http://issues.apache.org/jira/browse/TUSCANY-492?page=all ] Paul Golick updated TUSCANY-492: Attachment: XMLStreamHelperTestCase_patch.txt The contains method of the Java 1.5 String class is replaced with method present in both Java 1.4 and later. recently added file XMLStreamHelperTestCase.java is not compatible with JDK 1.4 --- Key: TUSCANY-492 URL: http://issues.apache.org/jira/browse/TUSCANY-492 Project: Tuscany Type: Bug Components: Java SDO Implementation Versions: Java-M2 Environment: Windows XP Reporter: Paul Golick Attachments: XMLStreamHelperTestCase_patch.txt In XMLStreamHelperTestCase.java there are two uses of a java.lang.String instance method contains(java.lang.String). This method was not added until Java 1.5; so, it is not found in the class library for Java 1.4 The attached patch changes x.contains(y) to the nearly equivalent x.indexOf(y)!=-1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-493) [DAS] Converter load needs to use appropriate classloader
[DAS] Converter load needs to use appropriate classloader - Key: TUSCANY-493 URL: http://issues.apache.org/jira/browse/TUSCANY-493 Project: Tuscany Type: Bug Components: Java DAS RDB Reporter: Brent Daniel Loading of converters by classname is currently using Class.forName(). This won't work if the converter is only available in the application classloader. -- 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: building java-M1-final - missing celtix jars
Tom Seelbach wrote: Most of the java-M1-final code release builds for me, but It fails with these errors. I don't see these jars in ibiblio, celtix, etc, Anyway, I don't need the celtix bindings so i will bypass them in the build. Just wanted to report the error. Thanks for the info. There's a module in the bulld (sunjars, part of the Celtix binding) that attempts to download a Celtix release and unpack these jars from it. I've sometimes seen that bit fail to work correctly. If it is still being a problem you might try cleaning and then removing the empty directories for those jars from your local maven repo. Or, just comment out Celtix if you don't need it :-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-487) Java 5.0 dependency in StAX2SAXAdapter.java
[ http://issues.apache.org/jira/browse/TUSCANY-487?page=all ] Frank Budinsky closed TUSCANY-487: -- Resolution: Fixed Java 5.0 dependency in StAX2SAXAdapter.java --- Key: TUSCANY-487 URL: http://issues.apache.org/jira/browse/TUSCANY-487 Project: Tuscany Type: Bug Components: Java SDO Implementation Reporter: John Colgrave Priority: Minor The first line of the getAttributes method in StAX2SAXAdapter.java is an assert which can only be compiled in Java 5.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-250) Need better error message when config entered incorrectly
[ http://issues.apache.org/jira/browse/TUSCANY-250?page=all ] Darius S. DeJesus updated TUSCANY-250: -- Attachment: Tuscany-250 The version of the patch that doesn't break something this time. Sorry for the spam, but I'm still getting used to this process... Need better error message when config entered incorrectly - Key: TUSCANY-250 URL: http://issues.apache.org/jira/browse/TUSCANY-250 Project: Tuscany Type: Bug Components: Java DAS RDB Versions: Java-Mx Reporter: Kevin Williams Fix For: Java-Mx Attachments: Tuscany-250, Tuscany-250, Tuscany-250 Incorrect config innformation often results in EMF index out of bounds exceptions. We should prevent these errors if possible by recognizing invalid config and throwing an meaningful exception. ExceptionsTests.test_4() demonstrates this problem -- 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: building java-M1-final - missing celtix jars
Just FYI: There is a proposal to move Celtix to apache and as part of that process, we are working on creating new spec jars for the geronimo-specs project to cover much of that functionality. Thus, when we move tuscany to the newer stuff, much of the issues should go away. Dan On Friday June 23 2006 3:24 pm, Jeremy Boynes wrote: Tom Seelbach wrote: Most of the java-M1-final code release builds for me, but It fails with these errors. I don't see these jars in ibiblio, celtix, etc, Anyway, I don't need the celtix bindings so i will bypass them in the build. Just wanted to report the error. Thanks for the info. There's a module in the bulld (sunjars, part of the Celtix binding) that attempts to download a Celtix release and unpack these jars from it. I've sometimes seen that bit fail to work correctly. If it is still being a problem you might try cleaning and then removing the empty directories for those jars from your local maven repo. Or, just comment out Celtix if you don't need it :-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 F:781-902-8001 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-468) IsContainment and getContainmentProperty do not work
[ http://issues.apache.org/jira/browse/TUSCANY-468?page=all ] Frank Budinsky resolved TUSCANY-468: Resolution: Cannot Reproduce Please provide a test case that illustrates the problem. This is pretty basic function that has been working for a long time, so it sounds like you're probably doing something wrong. IsContainment and getContainmentProperty do not work Key: TUSCANY-468 URL: http://issues.apache.org/jira/browse/TUSCANY-468 Project: Tuscany Type: Bug Components: Java SDO Implementation Versions: Java-M1 Reporter: Suraksha Vidyarthi The isContainment() returns false even for child complexTypes. getContainmentProperty() returns null even when the child object is contained within a parent object. If Customer-Address, so customer has an address child, is Containment() for property that maps to address should return true. Also if we do a getContainmentProperty() on address child it should return a reference to the property that holds address. -- 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: Tuscanys wiring model
Martin Beck wrote: Hi, I'm currently working on a presentation about tuscany's wiring and autowiring concepts for my studies. Up until now, I was staring at the java code and some of the javadoc... ;) I identified the mechanisms of the Interceptors, MessageHandlers and TargetInvokers, which are used on the source and target side of a wire. However, I still can't get behind the goal of all this stuff. By now, it seems to me that the wires are built up by the Runtime once the module is loaded and hided from the application developer who just uses tuscany. Is this right? Yes. The goal is to allow the application developer to write implementation code with all the wiring handled by the runtime - this is a fairly classic IoC architecture. Wires are actually built in two phases. In the first phase, the source and target side each build up outbound and inbound wires for just their part; in the seconds the runtime connects outbound and inbound sides together, potentially adding Interceptors and MessageHandlers as part of the process. But the usages of interceptors and handlers who come into my mind (e.g. logging, filtering, conversation) require access to the internal wire model by the application developer, if he for example wants to hook his own interceptor into the wirechain. If someone wants to hook directly to the wirechain then yes they will need to know the intricacies of with wire model. Although we will allow that, the intention is that they would define these things at a higher level. For example, system behaviour like security or transaction would be specified in terms of policy declarations in the standard SCA assembly model (the is spec activity defining some of this). We would expect a developer or application assembler to say something like I need a transaction here rather than having to deal with interceptors. For higher level function, we would like to support a set of aspect or mediation programming models that could be used to define business-oriented things like auditing, filtering, custom routing etc. They would write to that programming model and its integration would deal with the wiring. Hopefully this would be standardized in the SCA spec, but we could also support models from existing implementation such as Synapse. Additionaly, I didn't found many classes implementing interceptor and messagehandler interfaces, i.e. only only MessageDispatcher extends MessageHandler and therefore I dont see something really using the messagechannels. ;) Yeah - we started with the intention of supporting policies using this mechanism but didn't quite get to it. There is a small example where we started to use it in the async support. This should get some more attention in the next release. In http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg04104.html I read about the showcase features of SCA. I think, features like dynamic re-wiring would need sophisticated knowledge about tuscanys wiring by the application developer as he is the only one, who can decide whether to use this feature, didn't it? The intent behind SCA is that this really shouldn't be in the province of the application developer but in the hands of the people managing the SOA network. The goal is to let the application developer write business function without dependencies on infrastructure or wiring - hence the IoC nature. Then the people running the network (applications) can rewiring using the assembly model or other mechanism without impacting the code the developers wrote. For this to work, we need sophisticated wiring mechanisms to support the white magic. However, the goal is to hide that complexity from the users, developers, assemblers, adminsitrators. So my concrete question is: Why there is such a complex wirechain if it is almost not used (by now)? What are your goals with it, if wires are managed by the Tuscany Runtime, and not the application developer? I hope I covered the goals above. For what we're doing now it is perhaps overkill but expect it to be used as we add in async, policy, etc. As a last example, I could imagine using the MessageDispatcher to broadcast an invocation to more than one components (whyever). But this wouldn't be possible according to the spec because a wire is defined as the connection between two components. You're right in saying wires connect two components but the spec does support the concept of multiplicity at least at the reference level - the application is passed a collection of wires and is responsible for using them individually. Personally I'd like to see this expanded so that concepts like multicast vs. unicast were built into the wiring, or so that some form of wire identification was provided (Map rather than Collection style behaviour in Java terms). You've raised a whole bunch of real issues here that would be good to capture - would you be able to help us pull them together as scenarios on the wiki? Thanks -- Jeremy
[jira] Assigned: (TUSCANY-489) Add support for xsd:byte type to WS Entrypoint
[ http://issues.apache.org/jira/browse/TUSCANY-489?page=all ] Pete Robbins reassigned TUSCANY-489: Assign To: Pete Robbins Add support for xsd:byte type to WS Entrypoint -- Key: TUSCANY-489 URL: http://issues.apache.org/jira/browse/TUSCANY-489 Project: Tuscany Type: Improvement Components: C++ SCA Versions: Cpp-M1 Reporter: Andrew Borley Assignee: Pete Robbins Priority: Minor Attachments: TUSCANY-489.patch xsd:byte is not currently supported - add this with a mapping to C++ char type -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-486) Document deployment use of Axis2C WS EntryPoint
[ http://issues.apache.org/jira/browse/TUSCANY-486?page=all ] Pete Robbins reassigned TUSCANY-486: Assign To: Pete Robbins Document deployment use of Axis2C WS EntryPoint - Key: TUSCANY-486 URL: http://issues.apache.org/jira/browse/TUSCANY-486 Project: Tuscany Type: Task Components: C++ SCA Versions: Cpp-M1 Reporter: Andrew Borley Assignee: Pete Robbins Attachments: WS_ENTRYPOINT.txt Need documentation explaining how to expose an SCA component as a WS EntryPoint in Axis2C -- 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]
