Re: svn commit: r438000
Hi,
I faced the same problem and configured my eclipse. But then when you
reduce this you might also want to take care of how the line wrapping is
done. For example the method signatures get wrapped without any alignment
and looked a bit clumsy. I then set alignment of arguments and it looked a
little better after that.
- Venkat
On 8/30/06, Jim Marino [EMAIL PROTECTED] wrote:
I think it should be the checkstyle. The widest we ever went was 140
and we had a discussion on several occasions where some wanted it
smaller (e.g. 80), some larger, and some didn't care. 120 seems to be
a reasonable length. Do you want to update the Eclipse one?
Jim
On Aug 29, 2006, at 5:03 PM, Raymond Feng wrote:
Hi,
The rules from checkstlye are quite different than the IDE code
formatter templates we were recommending. For example, the template
for Eclipse sets the maximum characters per line to 150 while the
checkstyle complains at 120.
Which one should we follow? If it's the checkstyle, then we should
update the IDE templates so that we are not confused.
Thanks,
Raymond
- Original Message - From: Jim Marino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, August 29, 2006 1:12 AM
Subject: Fwd: svn commit: r438000
Hi Raymond,
Could you please make sure you format this code: mvn -
Psourcecheck? It breaks Checkstyle.
Thanks,
Jim
Begin forwarded message:
From: [EMAIL PROTECTED]
Date: August 29, 2006 1:00:16 AM PDT
To: tuscany-commits@ws.apache.org
Subject: svn commit: r438000 - in /incubator/tuscany/java/sca/
core/ src: main/java/org/apache/tuscany/core/loader/
ComponentLoader.java test/java/org/apache/tuscany/core/loader/
ComponentLoaderTestCase.java
Reply-To: tuscany-dev@ws.apache.org
Author: rfeng
Date: Tue Aug 29 01:00:16 2006
New Revision: 438000
URL: http://svn.apache.org/viewvc?rev=438000view=rev
Log:
Make sure the StAX loading only ends upon /component
Modified:
incubator/tuscany/java/sca/core/src/main/java/org/apache/
tuscany/core/loader/ComponentLoader.java
incubator/tuscany/java/sca/core/src/test/java/org/apache/
tuscany/core/loader/ComponentLoaderTestCase.java
Modified: incubator/tuscany/java/sca/core/src/main/java/org/
apache/ tuscany/core/loader/ComponentLoader.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/
core/ src/main/java/org/apache/tuscany/core/loader/
ComponentLoader.java? rev=438000r1=437999r2=438000view=diff
==
--- incubator/tuscany/java/sca/core/src/main/java/org/apache/
tuscany/core/loader/ComponentLoader.java (original)
+++ incubator/tuscany/java/sca/core/src/main/java/org/apache/
tuscany/core/loader/ComponentLoader.java Tue Aug 29 01:00:16 2006
@@ -113,7 +113,8 @@
reader.next();
break;
case END_ELEMENT:
-return componentDefinition;
+if(reader.getName().equals(COMPONENT))
+return componentDefinition;
}
}
} catch (LoaderException e) {
Modified: incubator/tuscany/java/sca/core/src/test/java/org/
apache/ tuscany/core/loader/ComponentLoaderTestCase.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/
core/ src/test/java/org/apache/tuscany/core/loader/
ComponentLoaderTestCase.java?
rev=438000r1=437999r2=438000view=diff
==
--- incubator/tuscany/java/sca/core/src/test/java/org/apache/
tuscany/core/loader/ComponentLoaderTestCase.java (original)
+++ incubator/tuscany/java/sca/core/src/test/java/org/apache/
tuscany/core/loader/ComponentLoaderTestCase.java Tue Aug 29
01:00:16 2006
@@ -57,7 +57,7 @@
private ComponentLoader loader;
public void testEmptyComponent() throws LoaderException,
XMLStreamException {
-mockReader.expects(once()).method(getName).will
(returnValue(COMPONENT));
+mockReader.expects(atLeastOnce()).method(getName).will
(returnValue(COMPONENT));
mockReader.expects(atLeastOnce()).method
(getAttributeValue)
.with(ANYTHING, ANYTHING)
.will(onConsecutiveCalls(returnValue(NAME),
returnValue (null)));
@@ -71,7 +71,7 @@
}
public void testInitValue20() throws LoaderException,
XMLStreamException {
-mockReader.expects(once()).method(getName).will
(returnValue(COMPONENT));
+mockReader.expects(atLeastOnce()).method(getName).will
(returnValue(COMPONENT));
mockReader.expects(atLeastOnce()).method
(getAttributeValue)
.with(ANYTHING, ANYTHING)
.will(onConsecutiveCalls(returnValue(NAME),
returnValue (20)));
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Extension mechanism for implementations and bindings
I'm going to restructure the source tree and deployment for the ws binding. I think it will be better as: extensions/ ws/ reference/ service/ xsd as the scema is common to both reference and service and deployed as root/extensions/ ws/ reference/ lib ... etc service/ xsd/ -- Pete
[SDO for C++] Opinions Requested: Adopting stdcxx as C++ library
There is an Apache incubator project to develop an implementation of the standard C++ library (their web site is here http://incubator.apache.org/stdcxxhttp://incubator.apache.org/stdcxx/#platforms). Currently, in SDO for C++, we use the library provided by whichever platform we happen to run on. Using the Apache stdcxx library instead would provide us with a number of benefits - It is available on a wide range of platforms - It is the same implementation on all of them (so avoids obscure bugs from slight differences in C++ libraries) - It is open source so we can contribute fixes rather than writing around problems. - We become better citizens of the Apache community 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? Geoff.
[jira] Assigned: (TUSCANY-671) Port JSON-RPC binding from M1
[ http://issues.apache.org/jira/browse/TUSCANY-671?page=all ] ant elder reassigned TUSCANY-671: - Assignee: ant elder Port JSON-RPC binding from M1 - Key: TUSCANY-671 URL: http://issues.apache.org/jira/browse/TUSCANY-671 Project: Tuscany Issue Type: Improvement Components: Java SCA JsonRpc Binding Affects Versions: Java-M2 Reporter: Bert Lamb Assigned To: ant elder Priority: Minor Attachments: json-rpc-binding.zip Port the JSON-RPC binding from M1 into the new binding format. I've been working on this, so I should be able to post a patch soon. -- 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: [SDO for C++] Opinions Requested: Adopting stdcxx as C++ library
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. 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. A side question - SDO has a couple of pre-reqs (libxml2, etc) - will these need to be rebuilt against stdcxx as well? Cheers Andy
Re: [SDO for C++] Opinions Requested: Adopting stdcxx as C++ library
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
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
[jira] Created: (TUSCANY-677) Registry API SPI
Registry API SPI -- Key: TUSCANY-677 URL: http://issues.apache.org/jira/browse/TUSCANY-677 Project: Tuscany Issue Type: New Feature Components: Java SCA Common Affects Versions: Java-M2 Reporter: Yang ZHONG Attachments: registry.zip Could you please review the registry API and SPI? Please start with ReadMe.txt, it describes content including API\src\main\java\overview.HTML for API overview and API\src\main\java\org\apache\tuscany\registry\package.html for API design and example They're also available as JavaDoc at API\doc\index.html The API usage can be as simple as MySymbol mySymbol = mySymbolSpace.resolve( javax_xml_namespace_QName); As for SPI, SPI\src\main\java\overview.HTML is for SPI overview and SPI\src\main\java\org\apache\tuscany\registry\spi\package.html is for SPI design and sample They're also available as JavaDoc at SPI\doc\index.html Thanks. (Neither tuscany-dev nor infra takes my email with attachment, so I attach file here, the history can be found at http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06781.html) -- 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: Proposed Final Site
Dave: It looks to me there are many links to index.php?page is this right? There are changes scattered about with respect to links that don't seem right Example site-author\get-involved.xml FAQ link Contribute to the a href=faq.htmlFAQ/a or to a href='http://wiki.apache.org/ws/Tuscany' ! Contribute to the a href=faqFAQ/a or to Also links changed from href=./java-projects.html to href=java-projects for the anakia processor it seems to make a difference. The zip file contains index.php is this needed now? Thanks David Wheeler wrote: Hi, I went ahead and re-made the site around Anakia, so that it can be built and published without php. Running build.bat will produce the files in site-publish for you. The zip is attached to JIRA issue here: http://issues.apache.org/jira/browse/TUSCANY-667 -David W On 8/25/06, David Wheeler [EMAIL PROTECTED] wrote: You don't build the website Simple changing the XML files changes the website. Deploying the website is simply putting all the files in the site folder into the root of the site on incubator.apache.org/tuscany I will try and clarify that in the readme. as well as post it under the development section. .svg files are Scalable Vector Graphics files (http://www.w3.org/Graphics/SVG/). Inkscape uses svg as its native file format. -David On 8/25/06, haleh mahbod [EMAIL PROTECTED] wrote: David, Thank you for your effort on this. Site prototype is much more user friendly and easier to follow. I looked through the readme. It is not clear to me how to deploy/build the site changes. Can you please add those steps to the read me? We used to have a link on the website that explained how to modify the website. It would be good to have that information under development box. What are the .svg files? Haleh On 8/25/06, David Wheeler [EMAIL PROTECTED] wrote: I think the new site is ready to go live. There are still a few pages tbd, but all the content that is on the current site is in the new one. I have created a JIRA issue with the site source attached. http://issues.apache.org/jira/browse/TUSCANY-667 The Zip also contains a readme with instuctions on how to modify the site and craete new pages. -David Wheeler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Delivery Status Notification (Failure)
Having this attached to a JIRA is fine, thats preferred over sending attachments to the dev list. Thanks for all this, I've only just started looking but it looks very comprehensive, a lot more than I was expecting 8-). I've a few questions so far. Firstly you didn't click the button granting license of the code to the ASF, was that an oversight? The readme talks about some test examples and samples showing how to use the registry but the test folders don't seem to be included in the zip? From the brief look it wasn't clear to me if the registry will require EMF, hopefully it doesn't? Thanks, ...ant On 8/30/06, Yang ZHONG [EMAIL PROTECTED] wrote: Neither tuscany-dev nor infra takes my email with attachment, so I've attached file for review into http://issues.apache.org/jira/browse/TUSCANY-677 Sorry for the inconvenience and thanks for any comment. On 8/30/06, Mail Delivery Subsystem [EMAIL PROTECTED] wrote: This is an automatically generated Delivery Status Notification Delivery to the following recipient failed permanently: [EMAIL PROTECTED] Technical details of permanent failure: PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it is spam (body) - Original message - Received: by 10.35.31.14 with SMTP id i14mr634348pyj; Wed, 30 Aug 2006 03:06:43 -0700 (PDT) Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41 -0700 (PDT) Message-ID: [EMAIL PROTECTED] Date: Wed, 30 Aug 2006 03:06:41 -0700 From: Yang ZHONG [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Subject: Re: Auto discovering WSDL Cc: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_Part_28704_31437365.1156932401933 References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] --=_Part_28704_31437365.1156932401933 Content-Type: multipart/alternative; boundary==_Part_28705_19724073.1156932401933 --=_Part_28705_19724073.1156932401933 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Could you please review the registry API and SPI? - Message truncated - -- Yang ZHONG
Re: Proposed Final Site
Something I noticed is with the flow. On all the images where I can click on something I get there and once I'm through with that page how do I get back to the initial diagram to explore something else? I know there is the browser back, but I don't think that's a good practice. BTW I know this was not part of your changes. David Wheeler wrote: Hi, I went ahead and re-made the site around Anakia, so that it can be built and published without php. Running build.bat will produce the files in site-publish for you. The zip is attached to JIRA issue here: http://issues.apache.org/jira/browse/TUSCANY-667 -David W On 8/25/06, David Wheeler [EMAIL PROTECTED] wrote: You don't build the website Simple changing the XML files changes the website. Deploying the website is simply putting all the files in the site folder into the root of the site on incubator.apache.org/tuscany I will try and clarify that in the readme. as well as post it under the development section. .svg files are Scalable Vector Graphics files (http://www.w3.org/Graphics/SVG/). Inkscape uses svg as its native file format. -David On 8/25/06, haleh mahbod [EMAIL PROTECTED] wrote: David, Thank you for your effort on this. Site prototype is much more user friendly and easier to follow. I looked through the readme. It is not clear to me how to deploy/build the site changes. Can you please add those steps to the read me? We used to have a link on the website that explained how to modify the website. It would be good to have that information under development box. What are the .svg files? Haleh On 8/25/06, David Wheeler [EMAIL PROTECTED] wrote: I think the new site is ready to go live. There are still a few pages tbd, but all the content that is on the current site is in the new one. I have created a JIRA issue with the site source attached. http://issues.apache.org/jira/browse/TUSCANY-667 The Zip also contains a readme with instuctions on how to modify the site and craete new pages. -David Wheeler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Extension mechanism for implementations and bindings
I've now finished this refactor. All checked in. Seems to work fine so I'm going to go on holiday for a couple of weeks ;-) Have fun folks! On 30/08/06, Pete Robbins [EMAIL PROTECTED] wrote: I'm going to restructure the source tree and deployment for the ws binding. I think it will be better as: extensions/ ws/ reference/ service/ xsd as the scema is common to both reference and service and deployed as root/extensions/ ws/ reference/ lib ... etc service/ xsd/ -- Pete -- Pete
Re: Proposed Final Site
Hi David, First thanks. Can we comment on this in the JIRA itself so that all things to be addressed can be tracked there? I've just started to look into it and am going to log my opinions in the JIRA unless you folks are going to ask me not to do so and instead use the ML. Thanks - Venkat On 8/30/06, Rick [EMAIL PROTECTED] wrote: Something I noticed is with the flow. On all the images where I can click on something I get there and once I'm through with that page how do I get back to the initial diagram to explore something else? I know there is the browser back, but I don't think that's a good practice. BTW I know this was not part of your changes. David Wheeler wrote: Hi, I went ahead and re-made the site around Anakia, so that it can be built and published without php. Running build.bat will produce the files in site-publish for you. The zip is attached to JIRA issue here: http://issues.apache.org/jira/browse/TUSCANY-667 -David W On 8/25/06, David Wheeler [EMAIL PROTECTED] wrote: You don't build the website Simple changing the XML files changes the website. Deploying the website is simply putting all the files in the site folder into the root of the site on incubator.apache.org/tuscany I will try and clarify that in the readme. as well as post it under the development section. .svg files are Scalable Vector Graphics files (http://www.w3.org/Graphics/SVG/). Inkscape uses svg as its native file format. -David On 8/25/06, haleh mahbod [EMAIL PROTECTED] wrote: David, Thank you for your effort on this. Site prototype is much more user friendly and easier to follow. I looked through the readme. It is not clear to me how to deploy/build the site changes. Can you please add those steps to the read me? We used to have a link on the website that explained how to modify the website. It would be good to have that information under development box. What are the .svg files? Haleh On 8/25/06, David Wheeler [EMAIL PROTECTED] wrote: I think the new site is ready to go live. There are still a few pages tbd, but all the content that is on the current site is in the new one. I have created a JIRA issue with the site source attached. http://issues.apache.org/jira/browse/TUSCANY-667 The Zip also contains a readme with instuctions on how to modify the site and craete new pages. -David Wheeler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-667) New website ready to publish
[ http://issues.apache.org/jira/browse/TUSCANY-667?page=comments#action_12431575 ] Venkatakrishnan commented on TUSCANY-667: - Dave, here are some comments with whatever I have managed to observe. General --- 1) Can the width of the tabs (SCA, SDO and DAS) be increased a bit. Also could we change the background color for the tabs to something dark so that it stands out and also when a tab is selected is it possible to show it in a different background. 2) In the page sdo_index.html, i) the caption for the second picture says... SDO is a natural format for representing data on the wire in an SOA environment. Could we add Here is a perspective of that in an SCA Assembly Model ii) There is a line about DAS at the end of that page. I find that out of place in the context of this page. Let this patch be committed for a baseline and I can help you with fixing up things with appropriate patches subsequently PROVIDED the community also feels the same as I have with these. - Venkat New website ready to publish Key: TUSCANY-667 URL: http://issues.apache.org/jira/browse/TUSCANY-667 Project: Tuscany Issue Type: New Feature Components: Website Reporter: David Wheeler Attachments: site(8-29-06).zip, Tuscany Site.zip The new website is ready to go live. There are still a few pages TBD, but all the content that is currently up is included in the new site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (TUSCANY-676) ImportSDOLoader: DataTypeImpl not found in XSDEcoreBuilder.typeToTypeObjectMap causes NPE (surfaced as IllegalArgumentException)
Chris, I can reproduce your problem in pure SDO env without going thru the ImportSDOLoader in SCA. Let me take a look and get back to you. Fuhwei Lwo Chris Wall (JIRA) tuscany-dev@ws.apache.org wrote: ImportSDOLoader: DataTypeImpl not found in XSDEcoreBuilder.typeToTypeObjectMap causes NPE (surfaced as IllegalArgumentException) Key: TUSCANY-676 URL: http://issues.apache.org/jira/browse/TUSCANY-676 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Chris Wall Attachments: medrec.zip, xsdecorebuilder_npe.zip During SDO import of WSDL, elements of the following complex type are not found when validated against available SDO datatypes within the XSD layer (XSDEcoreBuilder). Downstream this causes an NPE. It could be that the comparison between the type and the key is not properly implemented. See the attached zip containing debug screenshots. -- 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-642) Composite references and services - model and runtime representations
[ http://issues.apache.org/jira/browse/TUSCANY-642?page=all ] Ignacio Silva-Lepe updated TUSCANY-642: --- Attachment: InnerCompositeCallback2.patch This patch subsumes InnerCompositeCallback.patch. It incorporates local invocations and callbacks over composite services. The same approach is used to provide the callback invocation handler with the outbound wire that is connected to the composite service's inbound wire. In addition, since bound services do not need a target invoker, there is no method to set it (or a callback target invoker) in the spi. It seems like at least a callback target invoker will be needed for bound services and since both are needed for bindless services, we may want to define them in the spi. This can be done as part of a callbacks over ws (axis2) binding patch. Composite references and services - model and runtime representations - Key: TUSCANY-642 URL: http://issues.apache.org/jira/browse/TUSCANY-642 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Affects Versions: Java-Mx Reporter: Ignacio Silva-Lepe Assigned To: Ignacio Silva-Lepe Fix For: Java-Mx Attachments: CompositeRefsAndSvcs.txt, CompositeRefsAndSvcs2.txt, InnerComposite.patch, InnerCompositeCallback.patch, InnerCompositeCallback2.patch Support is added to represent composite references and services (those in a composite and without a binding) in the model and runtime. The CompositeBuilder is updated to build a composite component that includes composite references and services without bindings. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-675) XPATH doesnt support dots in names (treats them as indices) in Java Implementation
[ http://issues.apache.org/jira/browse/TUSCANY-675?page=comments#action_12431586 ] Frank Budinsky commented on TUSCANY-675: This is a well known, but unfortunate feature of SDO 2.01. The . character is a reserved character in SDO paths, so you can't access properties with names that include . in a path expression. For now, you would need to do something like this instead: DataObject comp = scaObj.getDataObject(component[1]); DataObject impJava = comp.getDataObject(comp.getInstanceProperty(implentation.java)); Another possiblity is that we could add alias names for properties with . in their name. For example implementation_java. Then clients could access it like this: DataObject impJava = scaObj.getDataObject(component[1]/implementation_java); Hopefully the SDO 2.1 spec , which is attempting to fix some of the problems in the 2.01 spec, will provide a good standard way to handle this relatively common problem when working with XSD based models. XPATH doesnt support dots in names (treats them as indices) in Java Implementation -- Key: TUSCANY-675 URL: http://issues.apache.org/jira/browse/TUSCANY-675 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2 Environment: All Reporter: Hasan Muhammad When you try to do the following: DataObject impJava = scaObj.getDataObject(component[1]/implementation.java); It results in the following exception: java.lang.NumberFormatException: For input string: java at java.lang.NumberFormatException.forInputString(NumberFormatException.java:63) at java.lang.Integer.parseInt(Integer.java:481) at java.lang.Integer.parseInt(Integer.java:531) at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.process(DataObjectUtil.java:2097) at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.init(DataObjectUtil.java:1918) at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.create(DataObjectUtil.java:1838) at org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:738) at org.apache.tuscany.sdo.impl.DataObjectImpl.get(DataObjectImpl.java:213) at org.apache.tuscany.sdo.impl.DataObjectImpl.getDataObject(DataObjectImpl.java:323) at com.ibm.ws.sca2.module.loader.test.SDOLoaderTest.main(SDOLoaderTest.java:60) It is clear that it is trying to treat the string after . as an index.. -- 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: How to invoke a web service with complex types? Java object / SDO conversion?
Hi folks, As Chris's previous mail, it seems like when sending SOAP message, Celtix binding delegates the java2xml conversion to SDO binding, and the SDO binding converts SDO object to xml using Object.toString() (to our surprise). Therefore, the resulting SOAP message is something like: SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; SOAP-ENV:Body p0:getPatient xmlns:p0=http://www.foo.com/bar; p0:patient [EMAIL PROTECTED] (Id: 0, Dob: null, FirstName: Li, Gender: null, LastName: Shen, MiddleName: null, Phone: null, Ssn: null) /p0:patient /p0:getPatient /SOAP-ENV:Body /SOAP-ENV:Envelope The content inside patient/ is the string generated from Patient.toString(), but the expected elements inside patient/ should conform to the schema in WSDL: xs:complexType name=Patient xs:sequence xs:element minOccurs=1 name=Id nillable=true type=xs:int/ xs:element minOccurs=1 name=Dob nillable=true type=xs:dateTime/ xs:element minOccurs=1 name=FirstName nillable=true type=xs:string/ xs:element minOccurs=1 name=Gender nillable=true type=xs:string/ xs:element minOccurs=1 name=LastName nillable=true type=xs:string/ xs:element minOccurs=1 name=MiddleName nillable=true type=xs:string/ xs:element minOccurs=1 name=Phone nillable=true type=xs:string/ xs:element minOccurs=1 name=Ssn nillable=true type=xs:string/ /xs:sequence /xs:complexType I found the toString conversion is done at SDOUtil. convertToString(Type dataType, Object value) which eventually calls into ModelFactoryImpl. convertToString(EDataType eDataType, Object instanceValue), and then object. toString() gets called. Finally the string is returned to DataObjectXMLStreamReader and Celtix binding gets the string using getText(). This might be caused by misusage of SDO binding, wrong SDO objects generated by tool, or something else? Sounds like in celtix/axis binding, the parameter of service method is added to DataObject using dataObject.set(i, methodParameters[i]), which means the parameter such as Patient object becomes a common object property of the DataObject and then is convert to xml simply using toString()? Could someone familiar with SDO binding provide help on this? Thanks! Regards, Li -Original Message- From: Liu, Jervis [mailto:[EMAIL PROTECTED] Sent: 2006年8月30日 12:12 To: tuscany-dev@ws.apache.org Subject: RE: How to invoke a web service with complex types? Java object / SDO conversion? Hi Chris, see comments in-line. Cheers, Jervis -Original Message- From: Chris Wall [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 6:01 AM To: tuscany-dev@ws.apache.org Subject: Re: How to invoke a web service with complex types? Java object / SDO conversion? Hi Raymond. In our case, the client is privy to the domain objects - Java objects (interfaces/classes) - used by the web service. For example, locally the client uses org.client.Patient throughout the application. Before invoking a web service the client converts org.client.Patient to org.service.Patient(provided by service provider), and then invokes the web service passing org.service.Patient. Migrating this code to Tuscany we're finding that SDO handles the outbound by converting the Patient object to a String (I think). The inbound doesn't convert at all, but instead sends back null. I am not sure whether or not you are talking about the Celtix binding. It looks like you are referring to the Celtix binding code from last week, I am afraid it was not complete at that stage. But the latest version should allow both inbound and outbound working, I have tested helloworldwsclient sample, it works fine. Please note there is a hack currently in Celtix binding NodeDataReader/NodeDataWriter code. I have to convert SDO object to stream first, then stream to XML Node. This is because Celtix 1.0 does not have a direct support to stax. Problem can be fixed once we move Celtix binding to be based on the latest CeltixFire code base. CeltixFire repository is already available from apache incubator. As Raymond has mentioned, a pluggable databinding framework is under construction at the moment. Before this happens, if you are keen to use other databindings such as JAXB or xmlbeans, you can do so by implementing your own NodeDataReader/NodeDataWriter. Let me know if you need any helps. It would be cool if the binding layer was able to dynamically convert a Java object to a schema type matching the package name and class name in the WSDL. This is the ultimate non-invasive approach. It sounds as if the WS binding layer for both Axis2 and Celtix support only SDO as of today. If this is true, what are the steps to communicate with a complex type web service? My
Re: [C++] Extension mechanism for implementations and bindings
Pete Robbins wrote: I've now finished this refactor. All checked in. Seems to work fine so I'm going to go on holiday for a couple of weeks ;-) Have fun folks! Pete, everything works fine for me on Linux with the SVN head. The new folder structure and the extensibility story now look very good IMO. Have a good vacation!! -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO for C++] Opinions Requested: Adopting stdcxx as C++ library
Simon Laws wrote: 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 +1 for option 2 as well. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-474) substitutionGroup is serialized as parent name. Should be substitute name.
[ http://issues.apache.org/jira/browse/TUSCANY-474?page=comments#action_12431589 ] Geoff Winn commented on TUSCANY-474: Looking at the example in the oriinal description it appears that the tag of the head element is being placed in the output document rather than the tag of the actual element from the input document. I created a small test to recreate this situation (see the attached patch file) and I think the problem is more serious. For example, given an input document like ?xml version=1.0? items substituteA head-a/ head-b/ /substituteA /items where substituteA is a substitute for an element with tag head, the result of serialising is ?xml version=1.0 encoding=UTF-8? items xsi:type=ItemsType xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; head/ /items So not only is the head of the substitution group being written out rather than the actual element, but the contents of the element have been lost too. Note to committers: The attached patch is not a fix. It just provides an easy way to recreate the problem. Please do not apply this, it is a convenience for anyone working on this issue. substitutionGroup is serialized as parent name. Should be substitute name. -- Key: TUSCANY-474 URL: http://issues.apache.org/jira/browse/TUSCANY-474 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Reporter: Pete Robbins Fix For: Cpp-current Attachments: TUSCANY-474-recreate.patch loading an instance document that uses substitution groups (such as sca.module) then saving the document results in an invalid document. For example this snippet: component name=MyValueServiceComponent implementation.cpp dll=libMyValue.so header=MyValueImpl.h/implementation.cpp implementation.cpp is a substitute for implementation. When serialised the result is: component name=MyValueServiceComponent implementation dll=libMyValue.so header=MyValueImpl.h/implementation -- 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-474) substitutionGroup is serialized as parent name. Should be substitute name.
[ http://issues.apache.org/jira/browse/TUSCANY-474?page=all ] Geoff Winn updated TUSCANY-474: --- Attachment: TUSCANY-474-recreate.patch substitutionGroup is serialized as parent name. Should be substitute name. -- Key: TUSCANY-474 URL: http://issues.apache.org/jira/browse/TUSCANY-474 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Reporter: Pete Robbins Fix For: Cpp-current Attachments: TUSCANY-474-recreate.patch loading an instance document that uses substitution groups (such as sca.module) then saving the document results in an invalid document. For example this snippet: component name=MyValueServiceComponent implementation.cpp dll=libMyValue.so header=MyValueImpl.h/implementation.cpp implementation.cpp is a substitute for implementation. When serialised the result is: component name=MyValueServiceComponent implementation dll=libMyValue.so header=MyValueImpl.h/implementation -- 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: svn commit: r438000
Then we shuld make sure the two are aligned. I believe other than
line length the two are aligned (no pun intended) since the IDEA
template works fine for me. The only other mismatch brought up was
the idents on cases, which was voted in favor of the current
checkstyle. Maybe there are some other mismatches I missed. Could you
please highlight them and we can discuss?
Jim
On Aug 30, 2006, at 1:37 AM, ant elder wrote:
From past discussions there may also be other mismatches and
Raymond said
the line length was just one example of a difference. I think the IDE
template should be the authority, its the 21st century, we should
be able to
use IDE code formatting.
...ant
On 8/30/06, Jim Marino [EMAIL PROTECTED] wrote:
I think it should be the checkstyle. The widest we ever went was 140
and we had a discussion on several occasions where some wanted it
smaller (e.g. 80), some larger, and some didn't care. 120 seems to be
a reasonable length. Do you want to update the Eclipse one?
Jim
On Aug 29, 2006, at 5:03 PM, Raymond Feng wrote:
Hi,
The rules from checkstlye are quite different than the IDE code
formatter templates we were recommending. For example, the template
for Eclipse sets the maximum characters per line to 150 while the
checkstyle complains at 120.
Which one should we follow? If it's the checkstyle, then we should
update the IDE templates so that we are not confused.
Thanks,
Raymond
- Original Message - From: Jim Marino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, August 29, 2006 1:12 AM
Subject: Fwd: svn commit: r438000
Hi Raymond,
Could you please make sure you format this code: mvn -
Psourcecheck? It breaks Checkstyle.
Thanks,
Jim
Begin forwarded message:
From: [EMAIL PROTECTED]
Date: August 29, 2006 1:00:16 AM PDT
To: tuscany-commits@ws.apache.org
Subject: svn commit: r438000 - in /incubator/tuscany/java/sca/
core/ src: main/java/org/apache/tuscany/core/loader/
ComponentLoader.java test/java/org/apache/tuscany/core/loader/
ComponentLoaderTestCase.java
Reply-To: tuscany-dev@ws.apache.org
Author: rfeng
Date: Tue Aug 29 01:00:16 2006
New Revision: 438000
URL: http://svn.apache.org/viewvc?rev=438000view=rev
Log:
Make sure the StAX loading only ends upon /component
Modified:
incubator/tuscany/java/sca/core/src/main/java/org/apache/
tuscany/core/loader/ComponentLoader.java
incubator/tuscany/java/sca/core/src/test/java/org/apache/
tuscany/core/loader/ComponentLoaderTestCase.java
Modified: incubator/tuscany/java/sca/core/src/main/java/org/
apache/ tuscany/core/loader/ComponentLoader.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/
core/ src/main/java/org/apache/tuscany/core/loader/
ComponentLoader.java? rev=438000r1=437999r2=438000view=diff
==
--- incubator/tuscany/java/sca/core/src/main/java/org/apache/
tuscany/core/loader/ComponentLoader.java (original)
+++ incubator/tuscany/java/sca/core/src/main/java/org/apache/
tuscany/core/loader/ComponentLoader.java Tue Aug 29 01:00:16 2006
@@ -113,7 +113,8 @@
reader.next();
break;
case END_ELEMENT:
-return componentDefinition;
+if(reader.getName().equals(COMPONENT))
+return componentDefinition;
}
}
} catch (LoaderException e) {
Modified: incubator/tuscany/java/sca/core/src/test/java/org/
apache/ tuscany/core/loader/ComponentLoaderTestCase.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/
core/ src/test/java/org/apache/tuscany/core/loader/
ComponentLoaderTestCase.java?
rev=438000r1=437999r2=438000view=diff
==
--- incubator/tuscany/java/sca/core/src/test/java/org/apache/
tuscany/core/loader/ComponentLoaderTestCase.java (original)
+++ incubator/tuscany/java/sca/core/src/test/java/org/apache/
tuscany/core/loader/ComponentLoaderTestCase.java Tue Aug 29
01:00:16 2006
@@ -57,7 +57,7 @@
private ComponentLoader loader;
public void testEmptyComponent() throws LoaderException,
XMLStreamException {
-mockReader.expects(once()).method(getName).will
(returnValue(COMPONENT));
+mockReader.expects(atLeastOnce()).method(getName).will
(returnValue(COMPONENT));
mockReader.expects(atLeastOnce()).method
(getAttributeValue)
.with(ANYTHING, ANYTHING)
.will(onConsecutiveCalls(returnValue(NAME),
returnValue (null)));
@@ -71,7 +71,7 @@
}
public void testInitValue20() throws LoaderException,
XMLStreamException {
-mockReader.expects(once()).method(getName).will
(returnValue(COMPONENT));
+mockReader.expects(atLeastOnce()).method(getName).will
Re: svn commit: r438000
One request I would have is to turn off automatic line wrapping in
Eclipse. Having nicely wrapped at meaningful places (in a checkstyle
compliwant way), I find it very frustrating that Eclipse rewraps
those lines based on first whitespace before the margin losing my
changes.
--
Jeremy
On Aug 30, 2006, at 7:54 AM, Jim Marino wrote:
Then we shuld make sure the two are aligned. I believe other than
line length the two are aligned (no pun intended) since the IDEA
template works fine for me. The only other mismatch brought up was
the idents on cases, which was voted in favor of the current
checkstyle. Maybe there are some other mismatches I missed. Could
you please highlight them and we can discuss?
Jim
On Aug 30, 2006, at 1:37 AM, ant elder wrote:
From past discussions there may also be other mismatches and
Raymond said
the line length was just one example of a difference. I think the IDE
template should be the authority, its the 21st century, we should
be able to
use IDE code formatting.
...ant
On 8/30/06, Jim Marino [EMAIL PROTECTED] wrote:
I think it should be the checkstyle. The widest we ever went was 140
and we had a discussion on several occasions where some wanted it
smaller (e.g. 80), some larger, and some didn't care. 120 seems
to be
a reasonable length. Do you want to update the Eclipse one?
Jim
On Aug 29, 2006, at 5:03 PM, Raymond Feng wrote:
Hi,
The rules from checkstlye are quite different than the IDE code
formatter templates we were recommending. For example, the
template
for Eclipse sets the maximum characters per line to 150 while the
checkstyle complains at 120.
Which one should we follow? If it's the checkstyle, then we should
update the IDE templates so that we are not confused.
Thanks,
Raymond
- Original Message - From: Jim Marino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, August 29, 2006 1:12 AM
Subject: Fwd: svn commit: r438000
Hi Raymond,
Could you please make sure you format this code: mvn -
Psourcecheck? It breaks Checkstyle.
Thanks,
Jim
Begin forwarded message:
From: [EMAIL PROTECTED]
Date: August 29, 2006 1:00:16 AM PDT
To: tuscany-commits@ws.apache.org
Subject: svn commit: r438000 - in /incubator/tuscany/java/sca/
core/ src: main/java/org/apache/tuscany/core/loader/
ComponentLoader.java test/java/org/apache/tuscany/core/loader/
ComponentLoaderTestCase.java
Reply-To: tuscany-dev@ws.apache.org
Author: rfeng
Date: Tue Aug 29 01:00:16 2006
New Revision: 438000
URL: http://svn.apache.org/viewvc?rev=438000view=rev
Log:
Make sure the StAX loading only ends upon /component
Modified:
incubator/tuscany/java/sca/core/src/main/java/org/apache/
tuscany/core/loader/ComponentLoader.java
incubator/tuscany/java/sca/core/src/test/java/org/apache/
tuscany/core/loader/ComponentLoaderTestCase.java
Modified: incubator/tuscany/java/sca/core/src/main/java/org/
apache/ tuscany/core/loader/ComponentLoader.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/
core/ src/main/java/org/apache/tuscany/core/loader/
ComponentLoader.java? rev=438000r1=437999r2=438000view=diff
==
--- incubator/tuscany/java/sca/core/src/main/java/org/apache/
tuscany/core/loader/ComponentLoader.java (original)
+++ incubator/tuscany/java/sca/core/src/main/java/org/apache/
tuscany/core/loader/ComponentLoader.java Tue Aug 29 01:00:16
2006
@@ -113,7 +113,8 @@
reader.next();
break;
case END_ELEMENT:
-return componentDefinition;
+if(reader.getName().equals(COMPONENT))
+return componentDefinition;
}
}
} catch (LoaderException e) {
Modified: incubator/tuscany/java/sca/core/src/test/java/org/
apache/ tuscany/core/loader/ComponentLoaderTestCase.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/
core/ src/test/java/org/apache/tuscany/core/loader/
ComponentLoaderTestCase.java?
rev=438000r1=437999r2=438000view=diff
==
--- incubator/tuscany/java/sca/core/src/test/java/org/apache/
tuscany/core/loader/ComponentLoaderTestCase.java (original)
+++ incubator/tuscany/java/sca/core/src/test/java/org/apache/
tuscany/core/loader/ComponentLoaderTestCase.java Tue Aug 29
01:00:16 2006
@@ -57,7 +57,7 @@
private ComponentLoader loader;
public void testEmptyComponent() throws LoaderException,
XMLStreamException {
-mockReader.expects(once()).method(getName).will
(returnValue(COMPONENT));
+mockReader.expects(atLeastOnce()).method
(getName).will
(returnValue(COMPONENT));
mockReader.expects(atLeastOnce()).method
(getAttributeValue)
.with(ANYTHING, ANYTHING)
Re: Process and content for next release?
We have had a rush of build problems recently which have stopped people from being able to contribute effectively. Some of those have come from the size of the build leading to Jim's proposal to go ahead with the build refactors we have been talking about. For those to work we need some way to publish unstable artifacts and that meshes nicely with this release thread. There have been no comments on this thread since the original burst so I plan to start pulling together a release based on the approach described here (factoring in those comments). -- Jeremy On Aug 16, 2006, at 1:58 PM, Jeremy Boynes wrote: Our discussions on modularity have gone quiet and Kelvin and Luciano have started to build distributions for SDO and DAS. I'd like to open the discussion up about what should be in our next release, how we should approach it and when we think it might be ready. As the person opening this thread, I guess I'm also volunteering to be Release Manager unless someone else would prefer to do it :-) One of the things we're achieved with the modularization is the ability to decompose what we have into separately releasable modules - we don't have to pull everything together at the same time. We also have the ability to release artifacts individually through various maven repositories, publishing specific jars rather than than entire distribution. This allows us to structure a release differently from what we did in M1. Instead of publishing one bundle and then pulling libraries from it to distribute through Maven, I suggest we focus on the individual components then group them together into bundled distributions. Taking SDO as an example, this would mean that we would decide at some point that we wanted to release the sdo-impl library (that being the executable part of SDO). We would cut and vote on a version of that jar and that could then be published through Maven. We could also bundle that jar in a distribution containing dependencies (e.g. EMF), samples, documentation, ... The two don't need to be in permanent lock-step (although alignment is good) - for example, we could release an updated impl jar with some bugfixes without respinning the bundle. SCA provides a much more complex picture as it contains not just libraries but also host environments, multiple extensions, potentially multiple extensions providing alternative implementations of the same function (e.g. the axis and celtix bindings). To handle this I think we should stage the release process, stabilizing the core first, then whatever set of extensions we define as a bundle, finally voting to release the bundle. During the stabilization process we can published dated unstable builds to the SNAPSHOT repo so that extensions can rely on those rather than trunk all the time. So, having said all that, I would like to propose we start working toward getting the next release out with the following stages: 1) Specs (sdo-api, sca-api, commonj) These should be stable now as the specifications have been published. 2) SCA Core (spi, core, hostutil, test, plus apis once that refactor is done) Features I would like to see complete before we consider this stable are: Class loading changes Integration of databinding framework Support for async callbacks Support for complex properties Transitive dependency support 3) Baseline extensions - ones we think are essential for users idl.wsdl binding.axis binding.celtix binding.rmi databinding.axiom databinding.sdo databinding.jaxb container.javascript container.spring 4) Optional extensions - nice to have but which may not be ready to bundle binding.jsonrpc binding.osgi databinding.xmlbeans databinding.castor container.groovy 5) Host distributions - host environments that each form the basis for each bundle Standalone (with axis, celtix, rmi, spring) Web-app (with axis, celtix, rmi, json, spring, javascript) 6) Sample applications Technology sample framework (subject of another mail) BigBank application if ready This is an initial strawman of how I think we can pull this together. We can certainly move things around depending on what's ready and what we think are essential modules. If this seems reasonable I will transfer it to the wiki. Cheers -- Jeremy - 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]
Meaningful subjects, was: Delivery Status Notification (Failure)
Can people please make sure that messages have subjects that have some relationship to their content. -- Jeremy On Aug 30, 2006, at 3:20 AM, Yang ZHONG wrote: Neither tuscany-dev nor infra takes my email with attachment, so I've attached file for review into http://issues.apache.org/jira/browse/TUSCANY-677 Sorry for the inconvenience and thanks for any comment. On 8/30/06, Mail Delivery Subsystem [EMAIL PROTECTED] wrote: This is an automatically generated Delivery Status Notification Delivery to the following recipient failed permanently: [EMAIL PROTECTED] Technical details of permanent failure: PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it is spam (body) - Original message - Received: by 10.35.31.14 with SMTP id i14mr634348pyj; Wed, 30 Aug 2006 03:06:43 -0700 (PDT) Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41 -0700 (PDT) Message-ID: [EMAIL PROTECTED] Date: Wed, 30 Aug 2006 03:06:41 -0700 From: Yang ZHONG [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Subject: Re: Auto discovering WSDL Cc: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_Part_28704_31437365.1156932401933 References: [EMAIL PROTECTED] ems2.IONAGLOBAL.COM [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] --=_Part_28704_31437365.1156932401933 Content-Type: multipart/alternative; boundary==_Part_28705_19724073.1156932401933 --=_Part_28705_19724073.1156932401933 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Could you please review the registry API and SPI? - Message truncated - -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Process and content for next release?
Jeremy, when is your target date for this next release? I hope to get back to the OSGi binding/hosting code within the next week and I'd really like to try and get something into the release. Thanks, Joel -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 11:04 AM To: tuscany-dev@ws.apache.org Subject: Re: Process and content for next release? We have had a rush of build problems recently which have stopped people from being able to contribute effectively. Some of those have come from the size of the build leading to Jim's proposal to go ahead with the build refactors we have been talking about. For those to work we need some way to publish unstable artifacts and that meshes nicely with this release thread. There have been no comments on this thread since the original burst so I plan to start pulling together a release based on the approach described here (factoring in those comments). -- Jeremy On Aug 16, 2006, at 1:58 PM, Jeremy Boynes wrote: Our discussions on modularity have gone quiet and Kelvin and Luciano have started to build distributions for SDO and DAS. I'd like to open the discussion up about what should be in our next release, how we should approach it and when we think it might be ready. As the person opening this thread, I guess I'm also volunteering to be Release Manager unless someone else would prefer to do it :-) One of the things we're achieved with the modularization is the ability to decompose what we have into separately releasable modules - we don't have to pull everything together at the same time. We also have the ability to release artifacts individually through various maven repositories, publishing specific jars rather than than entire distribution. This allows us to structure a release differently from what we did in M1. Instead of publishing one bundle and then pulling libraries from it to distribute through Maven, I suggest we focus on the individual components then group them together into bundled distributions. Taking SDO as an example, this would mean that we would decide at some point that we wanted to release the sdo-impl library (that being the executable part of SDO). We would cut and vote on a version of that jar and that could then be published through Maven. We could also bundle that jar in a distribution containing dependencies (e.g. EMF), samples, documentation, ... The two don't need to be in permanent lock-step (although alignment is good) - for example, we could release an updated impl jar with some bugfixes without respinning the bundle. SCA provides a much more complex picture as it contains not just libraries but also host environments, multiple extensions, potentially multiple extensions providing alternative implementations of the same function (e.g. the axis and celtix bindings). To handle this I think we should stage the release process, stabilizing the core first, then whatever set of extensions we define as a bundle, finally voting to release the bundle. During the stabilization process we can published dated unstable builds to the SNAPSHOT repo so that extensions can rely on those rather than trunk all the time. So, having said all that, I would like to propose we start working toward getting the next release out with the following stages: 1) Specs (sdo-api, sca-api, commonj) These should be stable now as the specifications have been published. 2) SCA Core (spi, core, hostutil, test, plus apis once that refactor is done) Features I would like to see complete before we consider this stable are: Class loading changes Integration of databinding framework Support for async callbacks Support for complex properties Transitive dependency support 3) Baseline extensions - ones we think are essential for users idl.wsdl binding.axis binding.celtix binding.rmi databinding.axiom databinding.sdo databinding.jaxb container.javascript container.spring 4) Optional extensions - nice to have but which may not be ready to bundle binding.jsonrpc binding.osgi databinding.xmlbeans databinding.castor container.groovy 5) Host distributions - host environments that each form the basis for each bundle Standalone (with axis, celtix, rmi, spring) Web-app (with axis, celtix, rmi, json, spring, javascript) 6) Sample applications Technology sample framework (subject of another mail) BigBank application if ready This is an initial strawman of how I think we can pull this together. We can certainly move things around depending on what's ready and what we think are essential modules. If this seems reasonable I will transfer it to the wiki. Cheers -- Jeremy - To unsubscribe,
Re: Process and content for next release?
Basically, when it's done :-) Having said that, see below for the estimates I would make for the separate stages. If they are anywhere near accurate then I think we're looking towards the end of September (which seems like a good time just before ApacheCon). By publish, I mean having a stable but unreleased artifact in the snapshot maven repo. -- Jeremy On Aug 30, 2006, at 8:23 AM, Hawkins, Joel wrote: Jeremy, when is your target date for this next release? I hope to get back to the OSGi binding/hosting code within the next week and I'd really like to try and get something into the release. ... snip ... 1) Specs (sdo-api, sca-api, commonj) These should be stable now as the specifications have been published. I think these are ready and we can publish a stable version now. 2) SCA Core (spi, core, hostutil, test, plus apis once that refactor is done) Features I would like to see complete before we consider this stable are: Class loading changes Integration of databinding framework Support for async callbacks Support for complex properties Transitive dependency support I hope that we can get this wrapped and published by 9/11 3) Baseline extensions - ones we think are essential for users idl.wsdl9/11 binding.axis9/18 (depends on Axis 1.1 release) binding.celtix 9/18 binding.rmi 9/11 databinding.axiom 9/11 databinding.sdo 9/11 (depends on a SDO release) databinding.jaxb9/11 container.javascript container.spring I am assuming the axiom, sdo and jaxb databindings sync with the framework as we need something there to test it out. I don't have a good feeling for how long it will take to get the containers working. 4) Optional extensions - nice to have but which may not be ready to bundle binding.jsonrpc binding.osgi databinding.xmlbeans databinding.castor container.groovy 5) Host distributions - host environments that each form the basis for each bundle Standalone (with axis, celtix, rmi, spring) Web-app (with axis, celtix, rmi, json, spring, javascript) Based on Jim's feedback I don't think we would be doing a Web-app distribution; instead there would be a web-app maven plugin to package a war with a suitably configured war inside it. See 7) for that. 6) Sample applications Technology sample framework (subject of another mail) BigBank application if ready 7) Tools Web-app maven plugin 9/4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Process and content for next release?
Thanks - that gives me some dates to shoot for. -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 11:48 AM To: tuscany-dev@ws.apache.org Subject: Re: Process and content for next release? Basically, when it's done :-) Having said that, see below for the estimates I would make for the separate stages. If they are anywhere near accurate then I think we're looking towards the end of September (which seems like a good time just before ApacheCon). By publish, I mean having a stable but unreleased artifact in the snapshot maven repo. -- Jeremy On Aug 30, 2006, at 8:23 AM, Hawkins, Joel wrote: Jeremy, when is your target date for this next release? I hope to get back to the OSGi binding/hosting code within the next week and I'd really like to try and get something into the release. ... snip ... 1) Specs (sdo-api, sca-api, commonj) These should be stable now as the specifications have been published. I think these are ready and we can publish a stable version now. 2) SCA Core (spi, core, hostutil, test, plus apis once that refactor is done) Features I would like to see complete before we consider this stable are: Class loading changes Integration of databinding framework Support for async callbacks Support for complex properties Transitive dependency support I hope that we can get this wrapped and published by 9/11 3) Baseline extensions - ones we think are essential for users idl.wsdl9/11 binding.axis9/18 (depends on Axis 1.1 release) binding.celtix 9/18 binding.rmi 9/11 databinding.axiom 9/11 databinding.sdo 9/11 (depends on a SDO release) databinding.jaxb9/11 container.javascript container.spring I am assuming the axiom, sdo and jaxb databindings sync with the framework as we need something there to test it out. I don't have a good feeling for how long it will take to get the containers working. 4) Optional extensions - nice to have but which may not be ready to bundle binding.jsonrpc binding.osgi databinding.xmlbeans databinding.castor container.groovy 5) Host distributions - host environments that each form the basis for each bundle Standalone (with axis, celtix, rmi, spring) Web-app (with axis, celtix, rmi, json, spring, javascript) Based on Jim's feedback I don't think we would be doing a Web-app distribution; instead there would be a web-app maven plugin to package a war with a suitably configured war inside it. See 7) for that. 6) Sample applications Technology sample framework (subject of another mail) BigBank application if ready 7) Tools Web-app maven plugin 9/4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Registry proposal, was: Delivery Status Notification (Failure)
Hi, Please see my comments in line. Thanks, Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, August 30, 2006 8:19 AM Subject: Registry proposal, was: Delivery Status Notification (Failure) I might be missing something as well but I didn't see any code under impl at all I guess it's for the API/SPI review first. I'm also with Ant in thinking we should not have a dependency on EMF. From the javadoc, I don't see the EMF dependencies. I'd also add that I found it difficult to grok the relationships between all the interfaces and inner-interfaces and how the behaviour would integrate with Map semantics - for example, how does this differ from just using strongly-typed Maps? I agree. If the interface is designed for public API/SPI, it should be first-class interface instead of being inner. I'm also seeing a lot of naming conflicts among API and SPI interfaces/classes/parameterized types. This seems to be very problematic to me. When we run out of names, it means to me we don't model it correctly. A class diagram would be of great help for us. I'm also not convinced that throwing everything (all types of stuff) into one central registry model is a good way to go. I can see a lot of benefit in having more specialized interfaces tailored for each type of stuff. I guess we can reuse the same infrastrcture backed by the generic registry but provide more specialized interfaces on top of it. And we can also choose to have separate instances of registries for specific domains. -- Jeremy On Aug 30, 2006, at 4:10 AM, ant elder wrote: Having this attached to a JIRA is fine, thats preferred over sending attachments to the dev list. Thanks for all this, I've only just started looking but it looks very comprehensive, a lot more than I was expecting 8-). I've a few questions so far. Firstly you didn't click the button granting license of the code to the ASF, was that an oversight? The readme talks about some test examples and samples showing how to use the registry but the test folders don't seem to be included in the zip? From the brief look it wasn't clear to me if the registry will require EMF, hopefully it doesn't? Thanks, ...ant On 8/30/06, Yang ZHONG [EMAIL PROTECTED] wrote: Neither tuscany-dev nor infra takes my email with attachment, so I've attached file for review into http://issues.apache.org/jira/browse/TUSCANY-677 Sorry for the inconvenience and thanks for any comment. On 8/30/06, Mail Delivery Subsystem [EMAIL PROTECTED] wrote: This is an automatically generated Delivery Status Notification Delivery to the following recipient failed permanently: [EMAIL PROTECTED] Technical details of permanent failure: PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it is spam (body) - Original message - Received: by 10.35.31.14 with SMTP id i14mr634348pyj; Wed, 30 Aug 2006 03:06:43 -0700 (PDT) Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41 -0700 (PDT) Message-ID: [EMAIL PROTECTED] Date: Wed, 30 Aug 2006 03:06:41 -0700 From: Yang ZHONG [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Subject: Re: Auto discovering WSDL Cc: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_Part_28704_31437365.1156932401933 References: [EMAIL PROTECTED] ems2.IONAGLOBAL.COM [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] --=_Part_28704_31437365.1156932401933 Content-Type: multipart/alternative; boundary==_Part_28705_19724073.1156932401933 --=_Part_28705_19724073.1156932401933 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Could you please review the registry API and SPI? - Message truncated - -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Registry proposal, was: Delivery Status Notification (Failure)
Raymond guessed right that it's an API/SPI review, so no impl/tests attached
yet although I have some impl already.
Ant guessed right too that I forgot to grant license, I must be not thinking
straight working late :-)
I don't see any link to post-grant, I'll remember to do that for following
attachments. Thank Ant.
There's neither* EMF *nor* Eclipse dependency. impl/EMF and impl/Eclipse
are just subproject targeting certain usage.
Please take a look at ReadMe.txt for more details, it also have info to find
Class Diagram and others.
I agree with Jeremy that strongly-typed Maps/interfaces are sometimes
preferred.
Actually, generalization and extensibility is exactly the selling point of
this generic registry.
Tailoring can be done based on the framework/infrastructure/fundation (as
Raymond commented).
There're at least two ways to provide strong interfaces over this registry.
2-1. Delegating
new StrongInterface()
{
public MySymbol getMySymbol (QName qName)
{
return mySymbolSpace.resolve( qName);
}
}
2-2. Extending
class StrongInterfaceImpl extends SymbolSpaceImpl implement
StrongInterface
Thank everyone for all comments.
On 8/30/06, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
Please see my comments in line.
Thanks,
Raymond
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 30, 2006 8:19 AM
Subject: Registry proposal, was: Delivery Status Notification (Failure)
I might be missing something as well but I didn't see any code
under impl
at all
I guess it's for the API/SPI review first.
I'm also with Ant in thinking we should not have a dependency on EMF.
From the javadoc, I don't see the EMF dependencies.
I'd also add that I found it difficult to grok the
relationships between
all the interfaces and inner-interfaces and how the behaviour would
integrate with Map semantics - for example, how does this differ from
just using strongly-typed Maps?
I agree. If the interface is designed for public API/SPI, it should be
first-class interface instead of being inner.
I'm also seeing a lot of naming conflicts among API and SPI
interfaces/classes/parameterized types. This seems to be very problematic
to
me. When we run out of names, it means to me we don't model it correctly.
A class diagram would be of great help for us.
I'm also not convinced that throwing everything (all types of
stuff) into
one central registry model is a good way to go. I can see a lot of
benefit in having more specialized interfaces tailored for each type of
stuff.
I guess we can reuse the same infrastrcture backed by the generic registry
but provide more specialized interfaces on top of it. And we can also
choose
to have separate instances of registries for specific domains.
--
Jeremy
On Aug 30, 2006, at 4:10 AM, ant elder wrote:
Having this attached to a JIRA is fine, thats preferred over sending
attachments to the dev list.
Thanks for all this, I've only just started looking but it looks very
comprehensive, a lot more than I was expecting 8-). I've a
few questions
so
far. Firstly you didn't click the button granting license of the code
to
the
ASF, was that an oversight? The readme talks about some test examples
and
samples showing how to use the registry but the test folders
don't seem
to
be included in the zip? From the brief look it wasn't clear to me if
the
registry will require EMF, hopefully it doesn't?
Thanks,
...ant
On 8/30/06, Yang ZHONG [EMAIL PROTECTED] wrote:
Neither tuscany-dev nor infra takes my email with attachment, so I've
attached file for review into
http://issues.apache.org/jira/browse/TUSCANY-677
Sorry for the inconvenience and thanks for any comment.
On 8/30/06, Mail Delivery Subsystem [EMAIL PROTECTED]
wrote:
This is an automatically generated Delivery Status Notification
Delivery to the following recipient failed permanently:
[EMAIL PROTECTED]
Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it
is spam
(body)
- Original message -
Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41
-0700
(PDT)
Message-ID:
[EMAIL PROTECTED]
Date: Wed, 30 Aug 2006 03:06:41 -0700
From: Yang ZHONG [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Subject: Re: Auto discovering WSDL
Cc: [EMAIL PROTECTED]
In-Reply-To:
[EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary==_Part_28704_31437365.1156932401933
References:
[EMAIL PROTECTED]
ems2.IONAGLOBAL.COM
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--=_Part_28704_31437365.1156932401933
Content-Type: multipart/alternative;
boundary==_Part_28705_19724073.1156932401933
--=_Part_28705_19724073.1156932401933
[jira] Commented: (TUSCANY-667) New website ready to publish
[ http://issues.apache.org/jira/browse/TUSCANY-667?page=comments#action_12431621 ] David Wheeler commented on TUSCANY-667: --- Posted by Rick (cr22rc) It looks to me there are many links to index.php?page is this right? There are changes scattered about with respect to links that don't seem right Example site-author\get-involved.xml FAQ link Contribute to the a href=faq.htmlFAQ/a or to a href='http://wiki.apache.org/ws/Tuscany' ! Contribute to the a href=faqFAQ/a or to Also links changed from href=./java-projects.html to href=java-projects for the anakia processor it seems to make a difference. The zip file contains index.php is this needed now? index.php is no longer needed and was only included in the zip for reference. All the links that go to index.php?page=pageTitle should have been changed to ./pageTitle.html. I went back and checked again, looks like I missed a couple links in news.xml and java-projects.xml I am posting a version without index.php and with the last of the links fixed. New website ready to publish Key: TUSCANY-667 URL: http://issues.apache.org/jira/browse/TUSCANY-667 Project: Tuscany Issue Type: New Feature Components: Website Reporter: David Wheeler Attachments: site(8-29-06).zip, Tuscany Site.zip The new website is ready to go live. There are still a few pages TBD, but all the content that is currently up is included in the new site. -- 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-667) New website ready to publish
[ http://issues.apache.org/jira/browse/TUSCANY-667?page=all ] David Wheeler updated TUSCANY-667: -- Attachment: site(8-30-06).zip Fixed some links that still pointed to index.php removed index.php from the archive. New website ready to publish Key: TUSCANY-667 URL: http://issues.apache.org/jira/browse/TUSCANY-667 Project: Tuscany Issue Type: New Feature Components: Website Reporter: David Wheeler Attachments: site(8-29-06).zip, site(8-30-06).zip, Tuscany Site.zip The new website is ready to go live. There are still a few pages TBD, but all the content that is currently up is included in the new site. -- 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: Registry proposal, was: Delivery Status Notification (Failure)
I had one additional comment: is there a reason we have to use the
.INSTANCE approach to locating the default Provider?
Jim
On Aug 30, 2006, at 9:39 AM, Yang ZHONG wrote:
Raymond guessed right that it's an API/SPI review, so no impl/tests
attached
yet although I have some impl already.
Ant guessed right too that I forgot to grant license, I must be not
thinking
straight working late :-)
I don't see any link to post-grant, I'll remember to do that for
following
attachments. Thank Ant.
There's neither* EMF *nor* Eclipse dependency. impl/EMF and impl/
Eclipse
are just subproject targeting certain usage.
Please take a look at ReadMe.txt for more details, it also have
info to find
Class Diagram and others.
I agree with Jeremy that strongly-typed Maps/interfaces are sometimes
preferred.
Actually, generalization and extensibility is exactly the selling
point of
this generic registry.
Tailoring can be done based on the framework/infrastructure/
fundation (as
Raymond commented).
There're at least two ways to provide strong interfaces over this
registry.
2-1. Delegating
new StrongInterface()
{
public MySymbol getMySymbol (QName qName)
{
return mySymbolSpace.resolve( qName);
}
}
2-2. Extending
class StrongInterfaceImpl extends SymbolSpaceImpl implement
StrongInterface
Thank everyone for all comments.
On 8/30/06, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
Please see my comments in line.
Thanks,
Raymond
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 30, 2006 8:19 AM
Subject: Registry proposal, was: Delivery Status Notification
(Failure)
I might be missing something as well but I didn't see any code
under impl
at all
I guess it's for the API/SPI review first.
I'm also with Ant in thinking we should not have a dependency on
EMF.
From the javadoc, I don't see the EMF dependencies.
I'd also add that I found it difficult to grok the
relationships between
all the interfaces and inner-interfaces and how the behaviour
would
integrate with Map semantics - for example, how does this
differ from
just using strongly-typed Maps?
I agree. If the interface is designed for public API/SPI, it
should be
first-class interface instead of being inner.
I'm also seeing a lot of naming conflicts among API and SPI
interfaces/classes/parameterized types. This seems to be very
problematic
to
me. When we run out of names, it means to me we don't model it
correctly.
A class diagram would be of great help for us.
I'm also not convinced that throwing everything (all types of
stuff) into
one central registry model is a good way to go. I can see a lot of
benefit in having more specialized interfaces tailored for each
type of
stuff.
I guess we can reuse the same infrastrcture backed by the generic
registry
but provide more specialized interfaces on top of it. And we can also
choose
to have separate instances of registries for specific domains.
--
Jeremy
On Aug 30, 2006, at 4:10 AM, ant elder wrote:
Having this attached to a JIRA is fine, thats preferred over
sending
attachments to the dev list.
Thanks for all this, I've only just started looking but it
looks very
comprehensive, a lot more than I was expecting 8-). I've a
few questions
so
far. Firstly you didn't click the button granting license of
the code
to
the
ASF, was that an oversight? The readme talks about some test
examples
and
samples showing how to use the registry but the test folders
don't seem
to
be included in the zip? From the brief look it wasn't clear to
me if
the
registry will require EMF, hopefully it doesn't?
Thanks,
...ant
On 8/30/06, Yang ZHONG [EMAIL PROTECTED] wrote:
Neither tuscany-dev nor infra takes my email with attachment,
so I've
attached file for review into
http://issues.apache.org/jira/browse/TUSCANY-677
Sorry for the inconvenience and thanks for any comment.
On 8/30/06, Mail Delivery Subsystem mailer-
[EMAIL PROTECTED]
wrote:
This is an automatically generated Delivery Status Notification
Delivery to the following recipient failed permanently:
[EMAIL PROTECTED]
Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it
is spam
(body)
- Original message -
Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41
-0700
(PDT)
Message-ID:
[EMAIL PROTECTED]
Date: Wed, 30 Aug 2006 03:06:41 -0700
From: Yang ZHONG [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Subject: Re: Auto discovering WSDL
Cc: [EMAIL PROTECTED]
In-Reply-To:
[EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary==_Part_28704_31437365.1156932401933
References:
[EMAIL PROTECTED]
ems2.IONAGLOBAL.COM
[EMAIL
Re: REST bindings for Tuscany SCA runtime
Oisin Hurley wrote: What do you think about the following approach: a) If you put no annotations in your code then you have to stick to the fixed pattern with fixed method names, and you write the side SCDL file that turns your code into a component and publishes the REST endpoint. b) If you want more flexibility to map state changes to nicer method names then you use annotations as your were proposing earlier in this thread. The annotations also allow you to completely avoid writing SCDL and specify the details of the binding like the base URI for the resources... Thoughts? These sound like good approaches to me - the one thing that I'm scratching my head about a bit is the create-resource and delete-resource support. The read-resource and update-resource ops are fine, because we have a resource (i.e. the thing that has just been coded). What's implicit here, though, is that there is always a fixed set of resources - the ones that you have just 'deployed'. So the create/delete ops can never be used because things are just set up that way. BTW, this is probably ok and it does match nicely with the accepted admin practice of disabling PUT and DEL in real webservers (as observed previously in this thread). I would be happy enough to leave off the create/delete support for the immediate future :) Oisin, 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? :) You have .put and .get in the client example, maybe the .post should be something like customers.post(uri, state-diff) Ah! interesting, I never thought about that before, looks like there could be a pretty good fit with SDO with the following: customers.post(uri, state-diff-in-an-SDO-change-summary-graph) ... This would be an interesting usage of SDO change summaries IMO, obviously just as an option as you should be able to format your state diff in any format you want as long as it's understood by your application. What do you think? This sounds like a nifty fit for sure. But now I have to go and read that SDO spec in more detail, because I know too little about it :) I like the general approach of going down the diff route because if you do it right then you can undo/redo changes to the data, which is neat feature, provided you are willing to store all of the diffs in a timeline. I'll go off and read that spec again. I just love reading specs ;) I don't think that we would mandate the use of SDO change summaries to implement this, support for diffs cannot be SDO specific (IMO the application developer decides what a diff looks like and what he does with it) but we would describe how application code could use SDO to simply implement that approach. Does that make sense? Are we close enough to condense a summary on the topic of REST and SCA? This would be good white paper material BTW. Yes I think it would be great if we could condense this and post it to our Wiki maybe. cheers --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Registry proposal, was: Delivery Status Notification (Failure)
I don't think we need Provider at all.
--
Jeremy
On Aug 30, 2006, at 9:59 AM, Jim Marino wrote:
I had one additional comment: is there a reason we have to use the
.INSTANCE approach to locating the default Provider?
Jim
On Aug 30, 2006, at 9:39 AM, Yang ZHONG wrote:
Raymond guessed right that it's an API/SPI review, so no impl/
tests attached
yet although I have some impl already.
Ant guessed right too that I forgot to grant license, I must be
not thinking
straight working late :-)
I don't see any link to post-grant, I'll remember to do that for
following
attachments. Thank Ant.
There's neither* EMF *nor* Eclipse dependency. impl/EMF and impl/
Eclipse
are just subproject targeting certain usage.
Please take a look at ReadMe.txt for more details, it also have
info to find
Class Diagram and others.
I agree with Jeremy that strongly-typed Maps/interfaces are sometimes
preferred.
Actually, generalization and extensibility is exactly the selling
point of
this generic registry.
Tailoring can be done based on the framework/infrastructure/
fundation (as
Raymond commented).
There're at least two ways to provide strong interfaces over this
registry.
2-1. Delegating
new StrongInterface()
{
public MySymbol getMySymbol (QName qName)
{
return mySymbolSpace.resolve( qName);
}
}
2-2. Extending
class StrongInterfaceImpl extends SymbolSpaceImpl implement
StrongInterface
Thank everyone for all comments.
On 8/30/06, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
Please see my comments in line.
Thanks,
Raymond
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 30, 2006 8:19 AM
Subject: Registry proposal, was: Delivery Status Notification
(Failure)
I might be missing something as well but I didn't see any code
under impl
at all
I guess it's for the API/SPI review first.
I'm also with Ant in thinking we should not have a dependency
on EMF.
From the javadoc, I don't see the EMF dependencies.
I'd also add that I found it difficult to grok the
relationships between
all the interfaces and inner-interfaces and how the behaviour
would
integrate with Map semantics - for example, how does this
differ from
just using strongly-typed Maps?
I agree. If the interface is designed for public API/SPI, it
should be
first-class interface instead of being inner.
I'm also seeing a lot of naming conflicts among API and SPI
interfaces/classes/parameterized types. This seems to be very
problematic
to
me. When we run out of names, it means to me we don't model it
correctly.
A class diagram would be of great help for us.
I'm also not convinced that throwing everything (all types of
stuff) into
one central registry model is a good way to go. I can see a
lot of
benefit in having more specialized interfaces tailored for
each type of
stuff.
I guess we can reuse the same infrastrcture backed by the generic
registry
but provide more specialized interfaces on top of it. And we can
also
choose
to have separate instances of registries for specific domains.
--
Jeremy
On Aug 30, 2006, at 4:10 AM, ant elder wrote:
Having this attached to a JIRA is fine, thats preferred over
sending
attachments to the dev list.
Thanks for all this, I've only just started looking but it
looks very
comprehensive, a lot more than I was expecting 8-). I've a
few questions
so
far. Firstly you didn't click the button granting license of
the code
to
the
ASF, was that an oversight? The readme talks about some test
examples
and
samples showing how to use the registry but the test folders
don't seem
to
be included in the zip? From the brief look it wasn't clear to
me if
the
registry will require EMF, hopefully it doesn't?
Thanks,
...ant
On 8/30/06, Yang ZHONG [EMAIL PROTECTED] wrote:
Neither tuscany-dev nor infra takes my email with attachment,
so I've
attached file for review into
http://issues.apache.org/jira/browse/TUSCANY-677
Sorry for the inconvenience and thanks for any comment.
On 8/30/06, Mail Delivery Subsystem mailer-
[EMAIL PROTECTED]
wrote:
This is an automatically generated Delivery Status
Notification
Delivery to the following recipient failed permanently:
[EMAIL PROTECTED]
Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 12): 552 Message rejected
as it
is spam
(body)
- Original message -
Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41
-0700
(PDT)
Message-ID:
[EMAIL PROTECTED]
Date: Wed, 30 Aug 2006 03:06:41 -0700
From: Yang ZHONG [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Subject: Re: Auto discovering WSDL
Cc: [EMAIL PROTECTED]
In-Reply-To:
[EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: multipart/mixed;
[jira] Updated: (TUSCANY-676) ImportSDOLoader: DataTypeImpl not found in XSDEcoreBuilder.typeToTypeObjectMap causes NPE (surfaced as IllegalArgumentException)
[ http://issues.apache.org/jira/browse/TUSCANY-676?page=all ] Fuhwei Lwo updated TUSCANY-676: --- Attachment: tuscany-676.patch MedRecWebServices.wsdl Hi Chris, Can you apply the patch and rebuild sdo/impl and test with the new wsdl file I attached? Your original wsdl file is not valid because you are trying to reference type from different namespace. I have added ws:import and verified the wsdl file is valid. Please let me know if this solves your null pointer exception. Thanks. Fuhwei Lwo ImportSDOLoader: DataTypeImpl not found in XSDEcoreBuilder.typeToTypeObjectMap causes NPE (surfaced as IllegalArgumentException) Key: TUSCANY-676 URL: http://issues.apache.org/jira/browse/TUSCANY-676 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Chris Wall Attachments: medrec.zip, MedRecWebServices.wsdl, tuscany-676.patch, xsdecorebuilder_npe.zip During SDO import of WSDL, elements of the following complex type are not found when validated against available SDO datatypes within the XSD layer (XSDEcoreBuilder). Downstream this causes an NPE. It could be that the comparison between the type and the key is not properly implemented. See the attached zip containing debug screenshots. xs:schema attributeFormDefault=unqualified elementFormDefault=qualified targetNamespace=java:com.bea.proto.webservice xmlns:xs= http://www.w3.org/2001/XMLSchema; xs:complexType name=Patient xs:sequence xs:element minOccurs=1 name=Id nillable=true type=xs:int/ xs:element minOccurs=1 name=Dob nillable=true type=xs:dateTime/ xs:element minOccurs=1 name=FirstName nillable=true type=xs:string/ xs:element minOccurs=1 name=Gender nillable=true type=xs:string/ xs:element minOccurs=1 name=LastName nillable=true type=xs:string/ xs:element minOccurs=1 name=MiddleName nillable=true type=xs:string/ xs:element minOccurs=1 name=Phone nillable=true type=xs:string/ xs:element minOccurs=1 name=Ssn nillable=true type=xs:string/ /xs:sequence /xs:complexType /xs:schema -- 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: Registry proposal, was: Delivery Status Notification (Failure)
I'm fine with other service locating mechanisms, please name one and I'll
update.
Please keep little dependency. If the other mechanism(s) has dependency more
than just J2SE such as SCA, JNDI repository,
may be we can have several mechanism coexisted target various requirement...
Thanks again for comments.
On 8/30/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
I don't think we need Provider at all.
--
Jeremy
On Aug 30, 2006, at 9:59 AM, Jim Marino wrote:
I had one additional comment: is there a reason we have to use the
.INSTANCE approach to locating the default Provider?
Jim
On Aug 30, 2006, at 9:39 AM, Yang ZHONG wrote:
Raymond guessed right that it's an API/SPI review, so no impl/
tests attached
yet although I have some impl already.
Ant guessed right too that I forgot to grant license, I must be
not thinking
straight working late :-)
I don't see any link to post-grant, I'll remember to do that for
following
attachments. Thank Ant.
There's neither* EMF *nor* Eclipse dependency. impl/EMF and impl/
Eclipse
are just subproject targeting certain usage.
Please take a look at ReadMe.txt for more details, it also have
info to find
Class Diagram and others.
I agree with Jeremy that strongly-typed Maps/interfaces are sometimes
preferred.
Actually, generalization and extensibility is exactly the selling
point of
this generic registry.
Tailoring can be done based on the framework/infrastructure/
fundation (as
Raymond commented).
There're at least two ways to provide strong interfaces over this
registry.
2-1. Delegating
new StrongInterface()
{
public MySymbol getMySymbol (QName qName)
{
return mySymbolSpace.resolve( qName);
}
}
2-2. Extending
class StrongInterfaceImpl extends SymbolSpaceImpl implement
StrongInterface
Thank everyone for all comments.
On 8/30/06, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
Please see my comments in line.
Thanks,
Raymond
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 30, 2006 8:19 AM
Subject: Registry proposal, was: Delivery Status Notification
(Failure)
I might be missing something as well but I didn't see any code
under impl
at all
I guess it's for the API/SPI review first.
I'm also with Ant in thinking we should not have a dependency
on EMF.
From the javadoc, I don't see the EMF dependencies.
I'd also add that I found it difficult to grok the
relationships between
all the interfaces and inner-interfaces and how the behaviour
would
integrate with Map semantics - for example, how does this
differ from
just using strongly-typed Maps?
I agree. If the interface is designed for public API/SPI, it
should be
first-class interface instead of being inner.
I'm also seeing a lot of naming conflicts among API and SPI
interfaces/classes/parameterized types. This seems to be very
problematic
to
me. When we run out of names, it means to me we don't model it
correctly.
A class diagram would be of great help for us.
I'm also not convinced that throwing everything (all types of
stuff) into
one central registry model is a good way to go. I can see a
lot of
benefit in having more specialized interfaces tailored for
each type of
stuff.
I guess we can reuse the same infrastrcture backed by the generic
registry
but provide more specialized interfaces on top of it. And we can
also
choose
to have separate instances of registries for specific domains.
--
Jeremy
On Aug 30, 2006, at 4:10 AM, ant elder wrote:
Having this attached to a JIRA is fine, thats preferred over
sending
attachments to the dev list.
Thanks for all this, I've only just started looking but it
looks very
comprehensive, a lot more than I was expecting 8-). I've a
few questions
so
far. Firstly you didn't click the button granting license of
the code
to
the
ASF, was that an oversight? The readme talks about some test
examples
and
samples showing how to use the registry but the test folders
don't seem
to
be included in the zip? From the brief look it wasn't clear to
me if
the
registry will require EMF, hopefully it doesn't?
Thanks,
...ant
On 8/30/06, Yang ZHONG [EMAIL PROTECTED] wrote:
Neither tuscany-dev nor infra takes my email with attachment,
so I've
attached file for review into
http://issues.apache.org/jira/browse/TUSCANY-677
Sorry for the inconvenience and thanks for any comment.
On 8/30/06, Mail Delivery Subsystem mailer-
[EMAIL PROTECTED]
wrote:
This is an automatically generated Delivery Status
Notification
Delivery to the following recipient failed permanently:
[EMAIL PROTECTED]
Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 12): 552 Message rejected
as it
is spam
(body)
- Original message -
Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
Re: Registry proposal, was: Delivery Status Notification (Failure)
As part of Tuscany there should not be any mechanism in a API for
service location - that is the responsibility of the IoC container.
--
Jeremy
On Aug 30, 2006, at 10:43 AM, Yang ZHONG wrote:
I'm fine with other service locating mechanisms, please name one
and I'll
update.
Please keep little dependency. If the other mechanism(s) has
dependency more
than just J2SE such as SCA, JNDI repository,
may be we can have several mechanism coexisted target various
requirement...
Thanks again for comments.
On 8/30/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
I don't think we need Provider at all.
--
Jeremy
On Aug 30, 2006, at 9:59 AM, Jim Marino wrote:
I had one additional comment: is there a reason we have to use the
.INSTANCE approach to locating the default Provider?
Jim
On Aug 30, 2006, at 9:39 AM, Yang ZHONG wrote:
Raymond guessed right that it's an API/SPI review, so no impl/
tests attached
yet although I have some impl already.
Ant guessed right too that I forgot to grant license, I must be
not thinking
straight working late :-)
I don't see any link to post-grant, I'll remember to do that for
following
attachments. Thank Ant.
There's neither* EMF *nor* Eclipse dependency. impl/EMF and impl/
Eclipse
are just subproject targeting certain usage.
Please take a look at ReadMe.txt for more details, it also have
info to find
Class Diagram and others.
I agree with Jeremy that strongly-typed Maps/interfaces are
sometimes
preferred.
Actually, generalization and extensibility is exactly the selling
point of
this generic registry.
Tailoring can be done based on the framework/infrastructure/
fundation (as
Raymond commented).
There're at least two ways to provide strong interfaces over this
registry.
2-1. Delegating
new StrongInterface()
{
public MySymbol getMySymbol (QName qName)
{
return mySymbolSpace.resolve( qName);
}
}
2-2. Extending
class StrongInterfaceImpl extends SymbolSpaceImpl implement
StrongInterface
Thank everyone for all comments.
On 8/30/06, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
Please see my comments in line.
Thanks,
Raymond
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 30, 2006 8:19 AM
Subject: Registry proposal, was: Delivery Status Notification
(Failure)
I might be missing something as well but I didn't see any code
under impl
at all
I guess it's for the API/SPI review first.
I'm also with Ant in thinking we should not have a dependency
on EMF.
From the javadoc, I don't see the EMF dependencies.
I'd also add that I found it difficult to grok the
relationships between
all the interfaces and inner-interfaces and how the behaviour
would
integrate with Map semantics - for example, how does this
differ from
just using strongly-typed Maps?
I agree. If the interface is designed for public API/SPI, it
should be
first-class interface instead of being inner.
I'm also seeing a lot of naming conflicts among API and SPI
interfaces/classes/parameterized types. This seems to be very
problematic
to
me. When we run out of names, it means to me we don't model it
correctly.
A class diagram would be of great help for us.
I'm also not convinced that throwing everything (all types of
stuff) into
one central registry model is a good way to go. I can see a
lot of
benefit in having more specialized interfaces tailored for
each type of
stuff.
I guess we can reuse the same infrastrcture backed by the generic
registry
but provide more specialized interfaces on top of it. And we can
also
choose
to have separate instances of registries for specific domains.
--
Jeremy
On Aug 30, 2006, at 4:10 AM, ant elder wrote:
Having this attached to a JIRA is fine, thats preferred over
sending
attachments to the dev list.
Thanks for all this, I've only just started looking but it
looks very
comprehensive, a lot more than I was expecting 8-). I've a
few questions
so
far. Firstly you didn't click the button granting license of
the code
to
the
ASF, was that an oversight? The readme talks about some test
examples
and
samples showing how to use the registry but the test folders
don't seem
to
be included in the zip? From the brief look it wasn't clear to
me if
the
registry will require EMF, hopefully it doesn't?
Thanks,
...ant
On 8/30/06, Yang ZHONG [EMAIL PROTECTED] wrote:
Neither tuscany-dev nor infra takes my email with attachment,
so I've
attached file for review into
http://issues.apache.org/jira/browse/TUSCANY-677
Sorry for the inconvenience and thanks for any comment.
On 8/30/06, Mail Delivery Subsystem mailer-
[EMAIL PROTECTED]
wrote:
This is an automatically generated Delivery Status
Notification
Delivery to the following recipient failed permanently:
[EMAIL PROTECTED]
Technical details of
Re: Registry proposal, was: Delivery Status Notification (Failure)
On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote: As part of Tuscany there should not be any mechanism in a API for service location - that is the responsibility of the IoC container. +1 (which nicely avoids external dependencies on some locator implementation and evil Singletons) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Registry proposal, was: Delivery Status Notification (Failure)
Can someone propose a SCA specific API mentioned by Jeremy please?
Something like
interface ScaRegistry
{
Definition getDefinition (String nameSpace);
Message getMessage (QName);
}
I don't know the SCA requirement much enough to make such proposal.
At the same time, we can practise IoC in ScaRegistry service locating.
I hope I can learn from that practice and update the registry generic API
accordingly.
Thanks for pointing out a nice mechanism.
On 8/30/06, Jim Marino [EMAIL PROTECTED] wrote:
On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:
As part of Tuscany there should not be any mechanism in a API for
service location - that is the responsibility of the IoC container.
+1 (which nicely avoids external dependencies on some locator
implementation and evil Singletons)
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
In case its not completely clear from Jeremy and Jim's emails what to do: you could define a client interface for the registry, write an implementation of that and define that impl class name in some scdl. We can then include the scdl in the runtime and things could use autowire to get hold of the registry instance. As and example of this you can look at our ServletHost, ServletHostImpl, how thats defined in the web app scdl, and then how thats used by the Axis2 binding: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/spi/src/main/java/org/apache/tuscany/spi/host/ServletHost.java http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/runtime/webapp-host/src/main/java/org/apache/tuscany/runtime/webapp/ServletHostImpl.java http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/runtime/webapp-host/src/main/resources/META-INF/sca/webapp.system.scdl http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/bindings/binding.axis2/src/main/java/org/apache/tuscany/binding/axis2/Axis2BindingBuilder.java ...ant On 8/30/06, Jim Marino [EMAIL PROTECTED] wrote: On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote: As part of Tuscany there should not be any mechanism in a API for service location - that is the responsibility of the IoC container. +1 (which nicely avoids external dependencies on some locator implementation and evil Singletons) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Registry proposal, was: Delivery Status Notification (Failure)
I'm having trouble parsing this. Are you talking about an SCA
registry, or a WSDL registry, or the mechanism for locating it (via
IoC as Ant described or something else)?
I was saying that in an IoC world there is /no/ provider part of the
API - a user never locates anything, they declare dependencies and
the container resolves them. The dependency would be on the actual
client interface (SymbolSpace.Registry I guess but I've already
admitted to not grokking the interfaces).
--
Jeremy
On Aug 30, 2006, at 11:28 AM, Yang ZHONG wrote:
Can someone propose a SCA specific API mentioned by Jeremy please?
Something like
interface ScaRegistry
{
Definition getDefinition (String nameSpace);
Message getMessage (QName);
}
I don't know the SCA requirement much enough to make such proposal.
At the same time, we can practise IoC in ScaRegistry service locating.
I hope I can learn from that practice and update the registry
generic API
accordingly.
Thanks for pointing out a nice mechanism.
On 8/30/06, Jim Marino [EMAIL PROTECTED] wrote:
On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:
As part of Tuscany there should not be any mechanism in a API for
service location - that is the responsibility of the IoC
container.
+1 (which nicely avoids external dependencies on some locator
implementation and evil Singletons)
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Registry proposal, was: Delivery Status Notification (Failure)
Thank Ant so much for details, that's very helpful!
I'll update the API:
2-1. remove INSTANCE
2-2. demonstrate the SCA way to get SymbolSpace.Registry implementation in
JavaDoc
SymbolSpace.Registry is the generic registry interface, it doesn't prevent
us from having SCA specific interface(s).
I can come up with a WSDL Registry interface proposal. Can someone tell me
which model is used by SCA: WST, WSDL4J, EMF, home grown or anything else?
On 8/30/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
I'm having trouble parsing this. Are you talking about an SCA
registry, or a WSDL registry, or the mechanism for locating it (via
IoC as Ant described or something else)?
I was saying that in an IoC world there is /no/ provider part of the
API - a user never locates anything, they declare dependencies and
the container resolves them. The dependency would be on the actual
client interface (SymbolSpace.Registry I guess but I've already
admitted to not grokking the interfaces).
--
Jeremy
On Aug 30, 2006, at 11:28 AM, Yang ZHONG wrote:
Can someone propose a SCA specific API mentioned by Jeremy please?
Something like
interface ScaRegistry
{
Definition getDefinition (String nameSpace);
Message getMessage (QName);
}
I don't know the SCA requirement much enough to make such proposal.
At the same time, we can practise IoC in ScaRegistry service locating.
I hope I can learn from that practice and update the registry
generic API
accordingly.
Thanks for pointing out a nice mechanism.
On 8/30/06, Jim Marino [EMAIL PROTECTED] wrote:
On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:
As part of Tuscany there should not be any mechanism in a API for
service location - that is the responsibility of the IoC
container.
+1 (which nicely avoids external dependencies on some locator
implementation and evil Singletons)
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
On Aug 30, 2006, at 11:59 AM, Yang ZHONG wrote:
Thank Ant so much for details, that's very helpful!
I'll update the API:
2-1. remove INSTANCE
2-2. demonstrate the SCA way to get SymbolSpace.Registry
implementation in
JavaDoc
Why do we have the inner interface? I agree with Jeremy that it
doesn't seem very intuitive.
SymbolSpace.Registry is the generic registry interface, it doesn't
prevent
us from having SCA specific interface(s).
I can come up with a WSDL Registry interface proposal. Can someone
tell me
which model is used by SCA: WST, WSDL4J, EMF, home grown or
anything else?
On 8/30/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
I'm having trouble parsing this. Are you talking about an SCA
registry, or a WSDL registry, or the mechanism for locating it (via
IoC as Ant described or something else)?
I was saying that in an IoC world there is /no/ provider part of the
API - a user never locates anything, they declare dependencies and
the container resolves them. The dependency would be on the actual
client interface (SymbolSpace.Registry I guess but I've already
admitted to not grokking the interfaces).
--
Jeremy
On Aug 30, 2006, at 11:28 AM, Yang ZHONG wrote:
Can someone propose a SCA specific API mentioned by Jeremy please?
Something like
interface ScaRegistry
{
Definition getDefinition (String nameSpace);
Message getMessage (QName);
}
I don't know the SCA requirement much enough to make such proposal.
At the same time, we can practise IoC in ScaRegistry service
locating.
I hope I can learn from that practice and update the registry
generic API
accordingly.
Thanks for pointing out a nice mechanism.
On 8/30/06, Jim Marino [EMAIL PROTECTED] wrote:
On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:
As part of Tuscany there should not be any mechanism in a API
for
service location - that is the responsibility of the IoC
container.
+1 (which nicely avoids external dependencies on some locator
implementation and evil Singletons)
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Registry proposal, was: Delivery Status Notification (Failure)
No problem, consider them removed in API.
Sorry, what's the WSDL model used in SCA again please?
On 8/30/06, Jim Marino [EMAIL PROTECTED] wrote:
On Aug 30, 2006, at 11:59 AM, Yang ZHONG wrote:
Thank Ant so much for details, that's very helpful!
I'll update the API:
2-1. remove INSTANCE
2-2. demonstrate the SCA way to get SymbolSpace.Registry
implementation in
JavaDoc
Why do we have the inner interface? I agree with Jeremy that it
doesn't seem very intuitive.
SymbolSpace.Registry is the generic registry interface, it doesn't
prevent
us from having SCA specific interface(s).
I can come up with a WSDL Registry interface proposal. Can someone
tell me
which model is used by SCA: WST, WSDL4J, EMF, home grown or
anything else?
On 8/30/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
I'm having trouble parsing this. Are you talking about an SCA
registry, or a WSDL registry, or the mechanism for locating it (via
IoC as Ant described or something else)?
I was saying that in an IoC world there is /no/ provider part of the
API - a user never locates anything, they declare dependencies and
the container resolves them. The dependency would be on the actual
client interface (SymbolSpace.Registry I guess but I've already
admitted to not grokking the interfaces).
--
Jeremy
On Aug 30, 2006, at 11:28 AM, Yang ZHONG wrote:
Can someone propose a SCA specific API mentioned by Jeremy please?
Something like
interface ScaRegistry
{
Definition getDefinition (String nameSpace);
Message getMessage (QName);
}
I don't know the SCA requirement much enough to make such proposal.
At the same time, we can practise IoC in ScaRegistry service
locating.
I hope I can learn from that practice and update the registry
generic API
accordingly.
Thanks for pointing out a nice mechanism.
On 8/30/06, Jim Marino [EMAIL PROTECTED] wrote:
On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:
As part of Tuscany there should not be any mechanism in a API
for
service location - that is the responsibility of the IoC
container.
+1 (which nicely avoids external dependencies on some locator
implementation and evil Singletons)
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
On Aug 30, 2006, at 12:20 PM, Yang ZHONG wrote: No problem, consider them removed in API. Sorry, what's the WSDL model used in SCA again please? We don't really model WSDL. We do parse it using WSDL4J for now but need something to support WSDL2.0 (probably Woden when it can support 1.1). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SPI changes to support ServiceContract and Operation
I plan on making changes to the SPI to move from the use of specifying service contracts with Java interfaces to the use of ServiceContract/Operation. If you have outstanding checkins, please get them in ASAP. I plan to start the conversion tonight (with a more detailed description of changes) unless there are objections. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Optiional Autowire
For webservices binding in the J2SE client case there is an autowire for ServletHost being called, but the jars for this deployment do not include an implementation for this so you receive the following org.apache.tuscany.spi.component.TargetNotFoundException: Autowire target not found [org.apache.tuscany.spi.host.ServletHost] Some discussion on the IRC seems to lead that that the preferred solution is required/optional option on the autowire annotation. I've looked into this and seen where to add it to (ReferenceDefinition) , but where the exception is invoked(SystemOutboundAutowire) I have not been able to pick up where that is passed along. Is this where we could just not throw this exception to have the autowired just ignored? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r438568 - /incubator/tuscany/java/spec/sca/pom.xml
Jeremy,
Careful with this Tuscany is an incubator project. Thus, releases
(like milestone releases) are not allowed to go the the rsync repositories
that are defined in the apache pom:
http://www.apache.org/dev/repository-faq.html
snapshot are OK to go to that repository (providing the Tuscany PMC's are OK
with them), but when you go to deploy a release, you'll NOT have happy PMC's
if they end up going to ibiblio.
Dan
On Wednesday August 30 2006 2:03 pm, [EMAIL PROTECTED] wrote:
Author: jboynes
Date: Wed Aug 30 11:03:19 2006
New Revision: 438568
URL: http://svn.apache.org/viewvc?rev=438568view=rev
Log:
inherit settings from Apache POM
centralize the spec version
Modified:
incubator/tuscany/java/spec/sca/pom.xml
Modified: incubator/tuscany/java/spec/sca/pom.xml
URL:
http://svn.apache.org/viewvc/incubator/tuscany/java/spec/sca/pom.xml?rev=43
8568r1=438567r2=438568view=diff
===
=== --- incubator/tuscany/java/spec/sca/pom.xml (original)
+++ incubator/tuscany/java/spec/sca/pom.xml Wed Aug 30 11:03:19 2006
@@ -19,46 +19,29 @@
--
project
modelVersion4.0.0/modelVersion
+parent
+groupIdorg.apache/groupId
+artifactIdapache/artifactId
+version3/version
+/parent
groupIdorg.osoa/groupId
-artifactIdsca-api-r0.95/artifactId
+artifactIdsca-api-r${specVersion}/artifactId
nameSCA API/name
descriptionAPI classes for the Service Component
Architecture/description version1.0-SNAPSHOT/version
-packagingjar/packaging
+packagingosgi-bundle/packaging
+properties
+specVersion0.95/specVersion
+/properties
prerequisites
maven2.0.4/maven
/prerequisites
-organization
-nameThe Apache Software Foundation/name
-urlhttp://www.apache.org/url
-/organization
-licenses
-license
-nameThe Apache Software License, Version 2.0/name
-urlhttp://www.apache.org/licenses/LICENSE-2.0.txt/url
-distributionrepo/distribution
-/license
-/licenses
-
-distributionManagement
-repository
-idapache-incubator-repository/id
-nameApache Incubator Repository/name
-
urlscp:///www/people.apache.org/repo/m2-snapshot-repository/url -
/repository
-snapshotRepository
-idapache-snapshot-repository/id
-nameApache SNAPSHOT Repository/name
-
urlscp:///www/people.apache.org/repo/m2-snapshot-repository/url -
/snapshotRepository
-/distributionManagement
-
scm
-
connectionscm:svn:http://svn.apache.org/repos/asf/incubator/tuscany/java/
spec/connection -
developerConnectionscm:svn:https://svn.apache.org/repos/asf/incubator/tus
cany/java/spec/developerConnection -
urlhttp://svn.apache.org/viewvc/incubator/tuscany/java/spec/url +
connectionscm:svn:http://svn.apache.org/repos/asf/incubator/tuscany/java/
spec/sca/connection +
developerConnectionscm:svn:https://svn.apache.org/repos/asf/incubator/tus
cany/java/spec/sca/developerConnection +
urlhttp://svn.apache.org/viewvc/incubator/tuscany/java/spec/sca/url
/scm
dependencies
@@ -98,7 +81,7 @@
bundleVendor${pom.organization.name}/bundleVendor
bundleLocalizationplugin/bundleLocalization
bundleSymbolicNameorg.osoa.sca/bundleSymbolicName -
exportPackageorg.osoa.sca;version=0.95,
org.osoa.sca.annotations;version=0.95/exportPackage +
exportPackageorg.osoa.sca;version=${specVersion},
org.osoa.sca.annotations;version=${specVersion}/exportPackage
/osgiManifest
/configuration
/plugin
-
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]
Re: Optiional Autowire
Yes. System outbound autowire needs to be configured to either throw or not throw an exception based on the resolution strategy. Since I am in the midst of the service contract and operation changes, can you let me make this change after my commit tonight so as not to cause conflicts? Jim On Aug 30, 2006, at 1:17 PM, Rick wrote: For webservices binding in the J2SE client case there is an autowire for ServletHost being called, but the jars for this deployment do not include an implementation for this so you receive the following org.apache.tuscany.spi.component.TargetNotFoundException: Autowire target not found [org.apache.tuscany.spi.host.ServletHost] Some discussion on the IRC seems to lead that that the preferred solution is required/optional option on the autowire annotation. I've looked into this and seen where to add it to (ReferenceDefinition) , but where the exception is invoked (SystemOutboundAutowire) I have not been able to pick up where that is passed along. Is this where we could just not throw this exception to have the autowired just ignored? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Auto-config for collision column
Currently, in the absence of otherwise conflicting, explicit configuration, we assume that any DO property named id will map to a primary key column in the database. Likewise a property name of the form x_id maps to a foreign key column that references some row in table x. I would like to add another auto configuration convention for the RDB DAS for collision properties. So, any DO property with the name occ_count will be assumed to map to an integer table column that is used for optimistic concurrency control. This column will then be used to overqualify any related UPDATE statements for that table. In the future, we may want to add support for occ_timestamp, etc. Any comments? Thanks, --Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Optiional Autowire
Sure why meddle with the master! :-) Seriously, the only request I would have is if convenient could you make it a separate svn checkin? Just like to review what you did for just this. The autowire information as far as I see is lost in the connection building phase, unless I missed it. Was wondering if it could not be added directly to the ServiceContract. Jim Marino wrote: Yes. System outbound autowire needs to be configured to either throw or not throw an exception based on the resolution strategy. Since I am in the midst of the service contract and operation changes, can you let me make this change after my commit tonight so as not to cause conflicts? Jim On Aug 30, 2006, at 1:17 PM, Rick wrote: For webservices binding in the J2SE client case there is an autowire for ServletHost being called, but the jars for this deployment do not include an implementation for this so you receive the following org.apache.tuscany.spi.component.TargetNotFoundException: Autowire target not found [org.apache.tuscany.spi.host.ServletHost] Some discussion on the IRC seems to lead that that the preferred solution is required/optional option on the autowire annotation. I've looked into this and seen where to add it to (ReferenceDefinition) , but where the exception is invoked(SystemOutboundAutowire) I have not been able to pick up where that is passed along. Is this where we could just not throw this exception to have the autowired just ignored? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Optiional Autowire
On Aug 30, 2006, at 1:41 PM, Rick wrote: Sure why meddle with the master! :-) I'd actually not mind avoiding doing it myself but I prefer that to having to reconcile changes Seriously, the only request I would have is if convenient could you make it a separate svn checkin? Just like to review what you did for just this. Yep. That's what I intend to do The autowire information as far as I see is lost in the connection building phase, unless I missed it. Was wondering if it could not be added directly to the ServiceContract. It shouldn't be on the service contract since it is part of the component type (autowire is really a type of reference). ReferenceDefinition already contains the information needed and can be accessed from the system component builder. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException
Hi. After a successful invocation of a web service, a TargetException occurs (Cannot evaulate $Proxy35.toString()) after body is returned from JDKOutboundInvocationHandler. This eventually leads to a ClassCastException: java.lang.ClassCastException: org.apache.tuscany.sdo.impl.DynamicDataObjectImpl at $Proxy35.getPatient(Unknown Source) at com.bea.proto.webservice.client.MedRecWebServicesServiceComponent.getPatient (MedRecWebServicesServiceComponent.java:26) Unfortunately I couldn't figure out how to get the full stacktrace from TargetException. Admittedly, this one has me confused. My first question is why is this happening? My second question is when, if ever, does the SDO layer convert the DynamicDataObjectImpl back to the intended return object (in this case a Patient object). Thanks. -Chris
Re: Process and content for next release?
Joel, If you need any help, ping me. Jim On Aug 30, 2006, at 8:51 AM, Hawkins, Joel wrote: Thanks - that gives me some dates to shoot for. -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 11:48 AM To: tuscany-dev@ws.apache.org Subject: Re: Process and content for next release? Basically, when it's done :-) Having said that, see below for the estimates I would make for the separate stages. If they are anywhere near accurate then I think we're looking towards the end of September (which seems like a good time just before ApacheCon). By publish, I mean having a stable but unreleased artifact in the snapshot maven repo. -- Jeremy On Aug 30, 2006, at 8:23 AM, Hawkins, Joel wrote: Jeremy, when is your target date for this next release? I hope to get back to the OSGi binding/hosting code within the next week and I'd really like to try and get something into the release. ... snip ... 1) Specs (sdo-api, sca-api, commonj) These should be stable now as the specifications have been published. I think these are ready and we can publish a stable version now. 2) SCA Core (spi, core, hostutil, test, plus apis once that refactor is done) Features I would like to see complete before we consider this stable are: Class loading changes Integration of databinding framework Support for async callbacks Support for complex properties Transitive dependency support I hope that we can get this wrapped and published by 9/11 3) Baseline extensions - ones we think are essential for users idl.wsdl9/11 binding.axis9/18 (depends on Axis 1.1 release) binding.celtix 9/18 binding.rmi 9/11 databinding.axiom 9/11 databinding.sdo 9/11 (depends on a SDO release) databinding.jaxb9/11 container.javascript container.spring I am assuming the axiom, sdo and jaxb databindings sync with the framework as we need something there to test it out. I don't have a good feeling for how long it will take to get the containers working. 4) Optional extensions - nice to have but which may not be ready to bundle binding.jsonrpc binding.osgi databinding.xmlbeans databinding.castor container.groovy 5) Host distributions - host environments that each form the basis for each bundle Standalone (with axis, celtix, rmi, spring) Web-app (with axis, celtix, rmi, json, spring, javascript) Based on Jim's feedback I don't think we would be doing a Web-app distribution; instead there would be a web-app maven plugin to package a war with a suitably configured war inside it. See 7) for that. 6) Sample applications Technology sample framework (subject of another mail) BigBank application if ready 7) Tools Web-app maven plugin 9/4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException
Can you send the Target exception stacktrace? It sounds as if something is getting swallowed. Jim On Aug 30, 2006, at 2:37 PM, Chris Wall wrote: Hi. After a successful invocation of a web service, a TargetException occurs (Cannot evaulate $Proxy35.toString()) after body is returned from JDKOutboundInvocationHandler. This eventually leads to a ClassCastException: java.lang.ClassCastException: org.apache.tuscany.sdo.impl.DynamicDataObjectImpl at $Proxy35.getPatient(Unknown Source) at com.bea.proto.webservice.client.MedRecWebServicesServiceComponent.getP atient (MedRecWebServicesServiceComponent.java:26) Unfortunately I couldn't figure out how to get the full stacktrace from TargetException. Admittedly, this one has me confused. My first question is why is this happening? My second question is when, if ever, does the SDO layer convert the DynamicDataObjectImpl back to the intended return object (in this case a Patient object). Thanks. -Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-676) ImportSDOLoader: DataTypeImpl not found in XSDEcoreBuilder.typeToTypeObjectMap causes NPE (surfaced as IllegalArgumentException)
[ http://issues.apache.org/jira/browse/TUSCANY-676?page=comments#action_12431717 ] Chris Wall commented on TUSCANY-676: Thank Fuhwei. You were right. I updated the WSDL and applied the patch locally. The WSDL was successfully loaded. Thanks!! ImportSDOLoader: DataTypeImpl not found in XSDEcoreBuilder.typeToTypeObjectMap causes NPE (surfaced as IllegalArgumentException) Key: TUSCANY-676 URL: http://issues.apache.org/jira/browse/TUSCANY-676 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Chris Wall Attachments: medrec.zip, MedRecWebServices.wsdl, tuscany-676.patch, xsdecorebuilder_npe.zip During SDO import of WSDL, elements of the following complex type are not found when validated against available SDO datatypes within the XSD layer (XSDEcoreBuilder). Downstream this causes an NPE. It could be that the comparison between the type and the key is not properly implemented. See the attached zip containing debug screenshots. xs:schema attributeFormDefault=unqualified elementFormDefault=qualified targetNamespace=java:com.bea.proto.webservice xmlns:xs= http://www.w3.org/2001/XMLSchema; xs:complexType name=Patient xs:sequence xs:element minOccurs=1 name=Id nillable=true type=xs:int/ xs:element minOccurs=1 name=Dob nillable=true type=xs:dateTime/ xs:element minOccurs=1 name=FirstName nillable=true type=xs:string/ xs:element minOccurs=1 name=Gender nillable=true type=xs:string/ xs:element minOccurs=1 name=LastName nillable=true type=xs:string/ xs:element minOccurs=1 name=MiddleName nillable=true type=xs:string/ xs:element minOccurs=1 name=Phone nillable=true type=xs:string/ xs:element minOccurs=1 name=Ssn nillable=true type=xs:string/ /xs:sequence /xs:complexType /xs:schema -- 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-678) Java XSD files cannot be used to validate SCA Model
Java XSD files cannot be used to validate SCA Model --- Key: TUSCANY-678 URL: http://issues.apache.org/jira/browse/TUSCANY-678 Project: Tuscany Issue Type: Task Reporter: Kapish Aggarwal Priority: Minor The XSD schema files that are packaged in the tuscany java project are out of date with the current SCA model and cannot be used to validate any SCDL files. It appears that the C++ is the one being worked on, but the dates of edit do not correspond with one C++ being more uptodate than Java. The two sets of XSD files need to be synchronized so that both sets reflect the current SCA Model. -- 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: Call for Eclipse tools work items
Oisin Hurley wrote: Hi all, Over at STP we are putting together work items for our next milestone and beyond. Obviously Tuscany and STP have (should have!) close links - so what do you Tuscany developers think we should provide in terms of tooling support for developing Tuscany-based services and assemblies? cheers --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Oisin, I recently spent some time developing SCA sample applications for Tuscany (working on the WS-I supply-chain scenario, plus some more changes to BigBank that I'll probably drop next week). I have been happily using the Eclipse WTP tools for XSDs and WSDLs but I could have used some good SCA tools to help me write all the SCA artifacts :) so here's my wish list for your STP SCA tooling: - Get the SCA XSDs registered in the Eclipse XML catalog to get XSD based validation of SCDL files and content assist in the XML editor. That's what I did by hand in my environment and I found it very useful. - Support for the SCA 0.96 assembly model in the STP core model. - Introspection of Java and C++ components and Web services to type properties, services and references. - An eclipse validator that provides further validation of my SCDLs (checks SCA wires for example) and provides nice error reporting. - An SCDL editor with more SCA content assist (which will list all interfaces available to you when you create a service or reference or potential targets of a reference for example). - An Eclipse project structure that will allow me to create SCA composites and assemble them... somehow. - A magic button that takes one or more of my projects to the Tuscany runtime, or something that does it in the background without me having to think about it. When is your next Milestone? When you have something that works with the latest SCA spec level I'll be interested in trying it for my SCA application development and helping test it. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tuscany-sdo-plugin produces NPE
Hi Chris,
This does look quite strange. My guess is that either the schema that this
is generated from is invalid, causing the generator to generate this weird
init method, or there's a subtle bug in the generator that the schema is
bringing out. Either way, it would be good if you could provide us with
the schema, or a test schema that has the same effect on the init method.
Thanks,
Frank.
Raymond Feng [EMAIL PROTECTED] wrote on 08/30/2006 05:40:13 PM:
Hi, Chris,
Usually MedRecWebServicesPackageImpl.eINSTANCE.eClass() should not be
called
in MedRecWebServicesPackageImpl.init() method. It seems to be a
code-generation issue. Frank, Fuwei or Yang, any idea?
Thanks,
Raymond
- Original Message -
From: Chris Wall [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 30, 2006 2:12 PM
Subject: tuscany-sdo-plugin produces NPE
Hi. Within the EPackageImpl implementing class generated by
tuscany-sdo-plugin, the init() method calls a method on an instance of
itself before the instance is initialized. For example:
snippet
public static MedRecWebServicesPackageImpl init()
{
if (isInited) return
(MedRecWebServicesPackageImpl)EPackage.Registry.INSTANCE.getEPackage(
MedRecWebServicesPackageImpl.eNS_URI);
// Obtain or create and register package
MedRecWebServicesPackageImpl theMedRecWebServicesPackageImpl =
(MedRecWebServicesPackageImpl)(EPackage.Registry.INSTANCE.
getEPackage(eNS_URI)
instanceof MedRecWebServicesPackageImpl ?
EPackage.Registry.INSTANCE.getEPackage(eNS_URI) : new
MedRecWebServicesPackageImpl());
isInited = true;
// Initialize simple dependencies
MedRecWebServicesPackageImpl.eINSTANCE.eClass(); P R O D U C
E
S N P E
SDOPackageImpl.eINSTANCE.eClass();
ModelPackageImpl.eINSTANCE.eClass();
/snippet
The eClass() method needs to be called on
theMedRecWebServicesPackageImpl,
called later in the process once eINSTANCE is initialized, or
eINSTANCE
needs to not be declared final.
Thanks.
-Chris
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException
Hi, It seems that the exception is thrown from the target component and it's related to the static/dynamic SDO (The incoming XML got deserialized into the dynamic SDO instead of the generated static class which your component implementation code expects). What does the import.sdo look like on the server side? Using import.sdo factory=.../? Thanks, Raymond - Original Message - From: Chris Wall To: tuscany-dev@ws.apache.org ; [EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 2:37 PM Subject: Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException Hi. After a successful invocation of a web service, a TargetException occurs (Cannot evaulate $Proxy35.toString()) after body is returned from JDKOutboundInvocationHandler. This eventually leads to a ClassCastException: java.lang.ClassCastException: org.apache.tuscany.sdo.impl.DynamicDataObjectImpl at $Proxy35.getPatient(Unknown Source) at com.bea.proto.webservice.client.MedRecWebServicesServiceComponent.getPatient( MedRecWebServicesServiceComponent.java:26) Unfortunately I couldn't figure out how to get the full stacktrace from TargetException. Admittedly, this one has me confused. My first question is why is this happening? My second question is when, if ever, does the SDO layer convert the DynamicDataObjectImpl back to the intended return object (in this case a Patient object). Thanks. -Chris
Re: Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException
Hi Chris, I can't answer the question of why it's happing (is it maybe related to the NPE problem in the init method?), but I can say that the SDO layer won't ever convert a DynamicDataObjectImpl back to a static instance. I would guess that you got the dynamic instance because something is wrong ... it didn't find the static class and instantiated a dynamic SDO instead. Frank. Chris Wall [EMAIL PROTECTED] wrote on 08/30/2006 05:37:37 PM: Hi. After a successful invocation of a web service, a TargetException occurs (Cannot evaulate $Proxy35.toString()) after body is returned from JDKOutboundInvocationHandler. This eventually leads to a ClassCastException: java.lang.ClassCastException: org.apache.tuscany.sdo.impl.DynamicDataObjectImpl at $Proxy35.getPatient(Unknown Source) at com.bea.proto.webservice.client.MedRecWebServicesServiceComponent.getPatient (MedRecWebServicesServiceComponent.java:26) Unfortunately I couldn't figure out how to get the full stacktrace from TargetException. Admittedly, this one has me confused. My first question is why is this happening? My second question is when, if ever, does the SDO layer convert the DynamicDataObjectImpl back to the intended return object (in this case a Patient object). Thanks. -Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r438568 - /incubator/tuscany/java/spec/sca/pom.xml
Agreed - on [EMAIL PROTECTED] I've proposed a POM that can be used
for podlings and if that is accepted I'll switch over.
--
Jeremy
On Aug 30, 2006, at 1:21 PM, Daniel Kulp wrote:
Jeremy,
Careful with this Tuscany is an incubator project. Thus,
releases
(like milestone releases) are not allowed to go the the rsync
repositories
that are defined in the apache pom:
http://www.apache.org/dev/repository-faq.html
snapshot are OK to go to that repository (providing the Tuscany
PMC's are OK
with them), but when you go to deploy a release, you'll NOT have
happy PMC's
if they end up going to ibiblio.
Dan
On Wednesday August 30 2006 2:03 pm, [EMAIL PROTECTED] wrote:
Author: jboynes
Date: Wed Aug 30 11:03:19 2006
New Revision: 438568
URL: http://svn.apache.org/viewvc?rev=438568view=rev
Log:
inherit settings from Apache POM
centralize the spec version
Modified:
incubator/tuscany/java/spec/sca/pom.xml
Modified: incubator/tuscany/java/spec/sca/pom.xml
URL:
http://svn.apache.org/viewvc/incubator/tuscany/java/spec/sca/
pom.xml?rev=43
8568r1=438567r2=438568view=diff
=
==
=== --- incubator/tuscany/java/spec/sca/pom.xml (original)
+++ incubator/tuscany/java/spec/sca/pom.xml Wed Aug 30 11:03:19 2006
@@ -19,46 +19,29 @@
--
project
modelVersion4.0.0/modelVersion
+parent
+groupIdorg.apache/groupId
+artifactIdapache/artifactId
+version3/version
+/parent
groupIdorg.osoa/groupId
-artifactIdsca-api-r0.95/artifactId
+artifactIdsca-api-r${specVersion}/artifactId
nameSCA API/name
descriptionAPI classes for the Service Component
Architecture/description version1.0-SNAPSHOT/version
-packagingjar/packaging
+packagingosgi-bundle/packaging
+properties
+specVersion0.95/specVersion
+/properties
prerequisites
maven2.0.4/maven
/prerequisites
-organization
-nameThe Apache Software Foundation/name
-urlhttp://www.apache.org/url
-/organization
-licenses
-license
-nameThe Apache Software License, Version 2.0/name
-urlhttp://www.apache.org/licenses/LICENSE-2.0.txt/
url
-distributionrepo/distribution
-/license
-/licenses
-
-distributionManagement
-repository
-idapache-incubator-repository/id
-nameApache Incubator Repository/name
-
urlscp:///www/people.apache.org/repo/m2-snapshot-repository/url -
/repository
-snapshotRepository
-idapache-snapshot-repository/id
-nameApache SNAPSHOT Repository/name
-
urlscp:///www/people.apache.org/repo/m2-snapshot-repository/url -
/snapshotRepository
-/distributionManagement
-
scm
-
connectionscm:svn:http://svn.apache.org/repos/asf/incubator/
tuscany/java/
spec/connection -
developerConnectionscm:svn:https://svn.apache.org/repos/asf/
incubator/tus
cany/java/spec/developerConnection -
urlhttp://svn.apache.org/viewvc/incubator/tuscany/java/spec/url +
connectionscm:svn:http://svn.apache.org/repos/asf/incubator/
tuscany/java/
spec/sca/connection +
developerConnectionscm:svn:https://svn.apache.org/repos/asf/
incubator/tus
cany/java/spec/sca/developerConnection +
urlhttp://svn.apache.org/viewvc/incubator/tuscany/java/spec/sca/
url
/scm
dependencies
@@ -98,7 +81,7 @@
bundleVendor${pom.organization.name}/bundleVendor
bundleLocalizationplugin/bundleLocalization
bundleSymbolicNameorg.osoa.sca/bundleSymbolicName -
exportPackageorg.osoa.sca;version=0.95,
org.osoa.sca.annotations;version=0.95/exportPackage +
exportPackageorg.osoa.sca;version=${specVersion},
org.osoa.sca.annotations;version=${specVersion}/exportPackage
/osgiManifest
/configuration
/plugin
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException
Hi Frank. I manually edited the init() method to bypass the NPE. So SDO doesn't default to creating a dynamic reference? Where within the SDO layer is the static lookup performed? What's interesting is that outbound SDO succesfully converts the Patient SDO object to XML. This makes me think that the SDO layer is aware of the static objects. Here's what the service received from Celtix (via SDO): ?xml version=1.0 encoding=utf-8 ?SOAP-ENV:Envelope xmlns:SOAP-ENV= http://schemas.xmlsoap.org/soap/envelope/; xmln s:xs=http://www.w3.org/2001/XMLSchema; xmlns:xsi= http://www.w3.org/2001/XMLSchema-instance;SOAP-ENV:Bodyp0:getPatie nt xmlns:p0=http://www.bea.com/medrec;p0:patientp1:FirstName xmlns:p1=java:com.bea.proto.webserviceLi/p1:FirstNa mep1:LastName xmlns:p1=java:com.bea.proto.webservice Shen/p1:LastName/p0:patient/p0:getPatient/SOAP-ENV:Body /SOAP-ENV:Envelope -Chris On 8/30/06, Frank Budinsky [EMAIL PROTECTED] wrote: Hi Chris, I can't answer the question of why it's happing (is it maybe related to the NPE problem in the init method?), but I can say that the SDO layer won't ever convert a DynamicDataObjectImpl back to a static instance. I would guess that you got the dynamic instance because something is wrong ... it didn't find the static class and instantiated a dynamic SDO instead. Frank. Chris Wall [EMAIL PROTECTED] wrote on 08/30/2006 05:37:37 PM: Hi. After a successful invocation of a web service, a TargetException occurs (Cannot evaulate $Proxy35.toString()) after body is returned from JDKOutboundInvocationHandler. This eventually leads to a ClassCastException: java.lang.ClassCastException: org.apache.tuscany.sdo.impl.DynamicDataObjectImpl at $Proxy35.getPatient(Unknown Source) at com.bea.proto.webservice.client.MedRecWebServicesServiceComponent.getPatient (MedRecWebServicesServiceComponent.java:26) Unfortunately I couldn't figure out how to get the full stacktrace from TargetException. Admittedly, this one has me confused. My first question is why is this happening? My second question is when, if ever, does the SDO layer convert the DynamicDataObjectImpl back to the intended return object (in this case a Patient object). Thanks. -Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException
Hi, Chris. If you have import.sdo location=wsdl/MedRecWebServices.wsdl/, it means that you prefer to use the dynamic SDO model derived from the WSDL/XSD. I have two questions: 1) Is the exception from client side or server side? 2) What's our business interface expecting? The strongly-typed java class/interface generated by SDO or the dynamic DataObject? Basically, the import.sdo needs to be consistent with your business interface signature. Thanks, Raymond - Original Message - From: Chris Wall To: Raymond Feng Sent: Wednesday, August 30, 2006 4:05 PM Subject: Re: Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException Hey Raymond. Our *client* scdl has: import.sdo location=wsdl/MedRecWebServices.wsdl/. Deserialized into the dynamic SDO makes sense. XMLStreamReader2XMLDocument parses the stream and creates a DynamicDataObjectImpl as it's root object. DynamicDataObjectImpl is aware of it's Patient context - name=getPatientResponse, package=java: com.bea.proto.webservice, and attributes. It's the root object that is returned from the binding. Shouldn't there be an intermediate step that generates a Patient object? -Chris On 8/30/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, It seems that the exception is thrown from the target component and it's related to the static/dynamic SDO (The incoming XML got deserialized into the dynamic SDO instead of the generated static class which your component implementation code expects). What does the import.sdo look like on the server side? Using import.sdo factory=.../? Thanks, Raymond - Original Message - From: Chris Wall To: tuscany-dev@ws.apache.org ; [EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 2:37 PM Subject: Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException Hi. After a successful invocation of a web service, a TargetException occurs (Cannot evaulate $Proxy35.toString()) after body is returned from JDKOutboundInvocationHandler. This eventually leads to a ClassCastException: java.lang.ClassCastException: org.apache.tuscany.sdo.impl.DynamicDataObjectImpl at $Proxy35.getPatient(Unknown Source) at com.bea.proto.webservice.client.MedRecWebServicesServiceComponent.getPatient( MedRecWebServicesServiceComponent.java:26) Unfortunately I couldn't figure out how to get the full stacktrace from TargetException. Admittedly, this one has me confused. My first question is why is this happening? My second question is when, if ever, does the SDO layer convert the DynamicDataObjectImpl back to the intended return object (in this case a Patient object). Thanks. -Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-676) ImportSDOLoader: DataTypeImpl not found in XSDEcoreBuilder.typeToTypeObjectMap causes NPE (surfaced as IllegalArgumentException)
[ http://issues.apache.org/jira/browse/TUSCANY-676?page=comments#action_12431744 ] Fuhwei Lwo commented on TUSCANY-676: Hi Frank B., Please review and consider committing the attached tuscany-676.patch. It seems to fix Chris' NPE. Thanks. Fuhwei Lwo ImportSDOLoader: DataTypeImpl not found in XSDEcoreBuilder.typeToTypeObjectMap causes NPE (surfaced as IllegalArgumentException) Key: TUSCANY-676 URL: http://issues.apache.org/jira/browse/TUSCANY-676 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Chris Wall Attachments: medrec.zip, MedRecWebServices.wsdl, tuscany-676.patch, xsdecorebuilder_npe.zip During SDO import of WSDL, elements of the following complex type are not found when validated against available SDO datatypes within the XSD layer (XSDEcoreBuilder). Downstream this causes an NPE. It could be that the comparison between the type and the key is not properly implemented. See the attached zip containing debug screenshots. xs:schema attributeFormDefault=unqualified elementFormDefault=qualified targetNamespace=java:com.bea.proto.webservice xmlns:xs= http://www.w3.org/2001/XMLSchema; xs:complexType name=Patient xs:sequence xs:element minOccurs=1 name=Id nillable=true type=xs:int/ xs:element minOccurs=1 name=Dob nillable=true type=xs:dateTime/ xs:element minOccurs=1 name=FirstName nillable=true type=xs:string/ xs:element minOccurs=1 name=Gender nillable=true type=xs:string/ xs:element minOccurs=1 name=LastName nillable=true type=xs:string/ xs:element minOccurs=1 name=MiddleName nillable=true type=xs:string/ xs:element minOccurs=1 name=Phone nillable=true type=xs:string/ xs:element minOccurs=1 name=Ssn nillable=true type=xs:string/ /xs:sequence /xs:complexType /xs:schema -- 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]
SDO spec jar manifest
This is currently located in the source tree and out of date - should I update to use the OSGi plugin like the SCA one does? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException
Hi, Chris.
You probably need to use the following import.sdo:
import.sdo factory=com.bea.proto.webservice.MedRecWebServicesFactory/
Thanks,
Raymond
- Original Message -
From: Chris Wall [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 30, 2006 4:24 PM
Subject: Re: Returning DynamicDataObjectImpl from web service call produces
TargetException leads to ClassCastException
Hey. Comments inline...
On 8/30/06, Raymond Feng [EMAIL PROTECTED] wrote:
Hi, Chris.
If you have import.sdo location=wsdl/MedRecWebServices.wsdl/, it
means
that you prefer to use the dynamic SDO model derived from the WSDL/XSD. I
have two questions:
CW: Ahh, I did not know. Yet, if I remove the import the following line
throws an exception:
[NodeDataWriter}
Property property = xsdHelper.getGlobalProperty(
elementQName.getNamespaceURI(), elementQName.getLocalPart(),
true);
org.apache.tuscany.spi.wire.InvocationRuntimeException: Type '{
http://www.bea.com/medrec}getString' not found in registered SDO types.
With import.sdo, this web service call returns successfully.
1) Is the exception from client side or server side?
CW: Client. Occurs within Proxy.getPatient(...).
2) What's our business interface expecting? The strongly-typed java
class/interface generated by SDO or the dynamic DataObject?
CW: Strongly-typed:
com.bea.proto.webservice.Patient
getPatient(com.bea.proto.webservice.PatientpPatient) throws Exception;
Basically, the import.sdo needs to be consistent with your business
interface signature.
Thanks,
Raymond
- Original Message -
From: Chris Wall
To: Raymond Feng
Sent: Wednesday, August 30, 2006 4:05 PM
Subject: Re: Returning DynamicDataObjectImpl from web service call
produces
TargetException leads to ClassCastException
Hey Raymond.
Our *client* scdl has:
import.sdolocation=wsdl/MedRecWebServices.wsdl/.
Deserialized into the dynamic SDO makes
sense. XMLStreamReader2XMLDocument
parses the stream and creates a DynamicDataObjectImpl as it's root
object.
DynamicDataObjectImpl is aware of it's Patient context -
name=getPatientResponse, package=java: com.bea.proto.webservice, and
attributes. It's the root object that is returned from the binding.
Shouldn't there be an intermediate step that generates a Patient object?
-Chris
On 8/30/06, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
It seems that the exception is thrown from the target component and it's
related to the static/dynamic SDO (The incoming XML got deserialized into
the dynamic SDO instead of the generated static class which your
component
implementation code expects).
What does the import.sdo look like on the server side? Using
import.sdo
factory=.../?
Thanks,
Raymond
- Original Message -
From: Chris Wall
To: tuscany-dev@ws.apache.org ; [EMAIL PROTECTED]
Sent: Wednesday, August 30, 2006 2:37 PM
Subject: Returning DynamicDataObjectImpl from web service call produces
TargetException leads to ClassCastException
Hi. After a successful invocation of a web service, a TargetException
occurs (Cannot evaulate $Proxy35.toString()) after body is returned
from
JDKOutboundInvocationHandler. This eventually leads to a
ClassCastException:
java.lang.ClassCastException:
org.apache.tuscany.sdo.impl.DynamicDataObjectImpl
at $Proxy35.getPatient(Unknown Source)
at
com.bea.proto.webservice.client.MedRecWebServicesServiceComponent.getPatient
(
MedRecWebServicesServiceComponent.java:26)
Unfortunately I couldn't figure out how to get the full stacktrace from
TargetException.
Admittedly, this one has me confused. My first question is why is this
happening? My second question is when, if ever, does the SDO layer
convert
the DynamicDataObjectImpl back to the intended return object (in this
case
a
Patient object).
Thanks.
-Chris
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException
Hi Raymond. Thanks for your patience.
With the factory declaraion I'm getting the same thing...
org.apache.tuscany.spi.wire.InvocationRuntimeException: Type '{
http://www.bea.com/medrec}getString' not found in registered SDO types.
at org.apache.tuscany.binding.celtix.io.NodeDataWriter.toXMLDocument(
NodeDataWriter.java:142)
at org.apache.tuscany.binding.celtix.io.NodeDataWriter.writeWrapper(
NodeDataWriter.java:84)
at org.apache.tuscany.binding.celtix.io.NodeDataWriter.writeWrapper(
NodeDataWriter.java:47)
at org.objectweb.celtix.bus.bindings.soap.SOAPBindingImpl.addParts(
SOAPBindingImpl.java:567)
at org.objectweb.celtix.bus.bindings.soap.SOAPBindingImpl.marshal(
SOAPBindingImpl.java:119)
at org.objectweb.celtix.bindings.Request.process(Request.java:91)
org.apache.tuscany.spi.wire.InvocationRuntimeException: Type '{
http://www.bea.com/medrec}getPatient' not found in registered SDO types.
Updated scdl:
E:/sca/tuscany/java/samples/sca/medrec 190$ cat
target/classes/META-INF/sca/default.scdl
?xml version=1.0 encoding=UTF-8?
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
xmlns:system=http://tuscany.apache.org/xmlns/system/1.0-SNAPSHOT
name=tuscanyWS2WLS
!--import.sdo location=wsdl/MedRecWebServices.wsdl/--
import.sdo factory=com.bea.proto.webservice.MedRecWebServicesFactory/
component name=MedRecWebServicesServiceComponent
implementation.java class=
com.bea.proto.webservice.client.MedRecWebServicesServiceComponent/
references
reference
name=medRecWebServicesServiceMedRecWebServicesService/reference
/references
/component
reference name=MedRecWebServicesService
interface.java interface=
com.bea.proto.webservice.client.MedRecWebServicesService/
binding.ws endpoint=
http://www.bea.com/medrec#wsdl.endpoint(MedRecWebServices/MedRecWebServicesPort)
location=wsdl/MedRecWebServices.wsdl /
/reference
/composite
On 8/30/06, Raymond Feng [EMAIL PROTECTED] wrote:
Hi, Chris.
You probably need to use the following import.sdo:
import.sdo factory=com.bea.proto.webservice.MedRecWebServicesFactory/
Thanks,
Raymond
- Original Message -
From: Chris Wall [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 30, 2006 4:24 PM
Subject: Re: Returning DynamicDataObjectImpl from web service call
produces
TargetException leads to ClassCastException
Hey. Comments inline...
On 8/30/06, Raymond Feng [EMAIL PROTECTED] wrote:
Hi, Chris.
If you have import.sdo location=wsdl/MedRecWebServices.wsdl/, it
means
that you prefer to use the dynamic SDO model derived from the WSDL/XSD.
I
have two questions:
CW: Ahh, I did not know. Yet, if I remove the import the following
line
throws an exception:
[NodeDataWriter}
Property property = xsdHelper.getGlobalProperty(
elementQName.getNamespaceURI(), elementQName.getLocalPart(),
true);
org.apache.tuscany.spi.wire.InvocationRuntimeException: Type '{
http://www.bea.com/medrec}getString' not found in registered SDO types.
With import.sdo, this web service call returns successfully.
1) Is the exception from client side or server side?
CW: Client. Occurs within Proxy.getPatient(...).
2) What's our business interface expecting? The strongly-typed java
class/interface generated by SDO or the dynamic DataObject?
CW: Strongly-typed:
com.bea.proto.webservice.Patient
getPatient(com.bea.proto.webservice.PatientpPatient) throws Exception;
Basically, the import.sdo needs to be consistent with your business
interface signature.
Thanks,
Raymond
- Original Message -
From: Chris Wall
To: Raymond Feng
Sent: Wednesday, August 30, 2006 4:05 PM
Subject: Re: Returning DynamicDataObjectImpl from web service call
produces
TargetException leads to ClassCastException
Hey Raymond.
Our *client* scdl has:
import.sdolocation=wsdl/MedRecWebServices.wsdl/.
Deserialized into the dynamic SDO makes
sense. XMLStreamReader2XMLDocument
parses the stream and creates a DynamicDataObjectImpl as it's root
object.
DynamicDataObjectImpl is aware of it's Patient context -
name=getPatientResponse, package=java: com.bea.proto.webservice, and
attributes. It's the root object that is returned from the binding.
Shouldn't there be an intermediate step that generates a Patient
object?
-Chris
On 8/30/06, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
It seems that the exception is thrown from the target component and
it's
related to the static/dynamic SDO (The incoming XML got deserialized
into
the dynamic SDO instead of the generated static class which your
component
implementation code expects).
What does the import.sdo look like on the server side? Using
import.sdo
factory=.../?
Thanks,
Raymond
- Original Message -
From: Chris Wall
To: tuscany-dev@ws.apache.org ; [EMAIL PROTECTED]
Sent: Wednesday, August 30, 2006 2:37 PM
Subject: Returning DynamicDataObjectImpl from web service call produces
TargetException
[jira] Created: (TUSCANY-679) InterfaceWSDLLoader mismatch btw. @Constructor annot. and actual Constructor parms
InterfaceWSDLLoader mismatch btw. @Constructor annot. and actual Constructor
parms
---
Key: TUSCANY-679
URL: http://issues.apache.org/jira/browse/TUSCANY-679
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding
Affects Versions: Java-M2
Reporter: Scott Kurz
PROBLEM:
Mismatch btw. annotation:
@Constructor({registry})
and Constructor:
public InterfaceWSDLLoader(@Autowire LoaderRegistry registry,
@Autowire WSDLDefinitionRegistry wsdlRegistry) {
SYMPTOM:
org.apache.tuscany.core.implementation.processor.InvalidAutowireException:
Names in @Constructor and autowire parameter do not match at 2 [public
org.apache.tuscany.idl.wsdl.InterfaceWSDLLoader(org.apache.tuscany.spi.loader.LoaderRegistry,org.apache.tuscany.idl.wsdl.WSDLDefinitionRegistry)]
Context stack trace: [tuscany.system][intf.wsdl.loader]
at
org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processAutowire(ImplementationProcessorServiceImpl.java:186)
at
org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processParam(ImplementationProcessorServiceImpl.java:113)
at
org.apache.tuscany.core.implementation.processor.ConstructorProcessor.visitConstructor(ConstructorProcessor.java:94)
at
org.apache.tuscany.core.implementation.IntrospectionRegistryImpl.introspect(IntrospectionRegistryImpl.java:83)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.loadByIntrospection(SystemComponentTypeLoader.java:85)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:69)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:42)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
--
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]
Including schemas in SCA API jar?
We currently include the SCA schema's in the sca-api jar in the location /schemas/* - two questions: 1) should we continue to do this? 2) if we do, should we move them to a better place e.g. org/osoa/sca/ schema ? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-679) InterfaceWSDLLoader mismatch btw. @Constructor annot. and actual Constructor parms
[ http://issues.apache.org/jira/browse/TUSCANY-679?page=all ]
Scott Kurz updated TUSCANY-679:
---
Attachment: InterfaceWSDLLoader.ConstructorFix.patch
Hopefully this is the right patch format (this is my first patch here)
InterfaceWSDLLoader mismatch btw. @Constructor annot. and actual Constructor
parms
---
Key: TUSCANY-679
URL: http://issues.apache.org/jira/browse/TUSCANY-679
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding
Affects Versions: Java-M2
Reporter: Scott Kurz
Attachments: InterfaceWSDLLoader.ConstructorFix.patch
PROBLEM:
Mismatch btw. annotation:
@Constructor({registry})
and Constructor:
public InterfaceWSDLLoader(@Autowire LoaderRegistry registry,
@Autowire WSDLDefinitionRegistry wsdlRegistry)
{
SYMPTOM:
org.apache.tuscany.core.implementation.processor.InvalidAutowireException:
Names in @Constructor and autowire parameter do not match at 2 [public
org.apache.tuscany.idl.wsdl.InterfaceWSDLLoader(org.apache.tuscany.spi.loader.LoaderRegistry,org.apache.tuscany.idl.wsdl.WSDLDefinitionRegistry)]
Context stack trace: [tuscany.system][intf.wsdl.loader]
at
org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processAutowire(ImplementationProcessorServiceImpl.java:186)
at
org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processParam(ImplementationProcessorServiceImpl.java:113)
at
org.apache.tuscany.core.implementation.processor.ConstructorProcessor.visitConstructor(ConstructorProcessor.java:94)
at
org.apache.tuscany.core.implementation.IntrospectionRegistryImpl.introspect(IntrospectionRegistryImpl.java:83)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.loadByIntrospection(SystemComponentTypeLoader.java:85)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:69)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:42)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-679) InterfaceWSDLLoader mismatch btw. @Constructor annot. and actual Constructor parms
[
http://issues.apache.org/jira/browse/TUSCANY-679?page=comments#action_12431763
]
Jim Marino commented on TUSCANY-679:
The issue is in the definition of InterfaceWSDLLoader. Either the @Constructor
annotation should include names for all constructor params, none, or just be
eliminated. I would just eliminate the @Constructor since the implementation
processor will deduce the constructor from the @Autowire annotations.
InterfaceWSDLLoader mismatch btw. @Constructor annot. and actual Constructor
parms
---
Key: TUSCANY-679
URL: http://issues.apache.org/jira/browse/TUSCANY-679
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding
Affects Versions: Java-M2
Reporter: Scott Kurz
Attachments: InterfaceWSDLLoader.ConstructorFix.patch
PROBLEM:
Mismatch btw. annotation:
@Constructor({registry})
and Constructor:
public InterfaceWSDLLoader(@Autowire LoaderRegistry registry,
@Autowire WSDLDefinitionRegistry wsdlRegistry)
{
SYMPTOM:
org.apache.tuscany.core.implementation.processor.InvalidAutowireException:
Names in @Constructor and autowire parameter do not match at 2 [public
org.apache.tuscany.idl.wsdl.InterfaceWSDLLoader(org.apache.tuscany.spi.loader.LoaderRegistry,org.apache.tuscany.idl.wsdl.WSDLDefinitionRegistry)]
Context stack trace: [tuscany.system][intf.wsdl.loader]
at
org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processAutowire(ImplementationProcessorServiceImpl.java:186)
at
org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processParam(ImplementationProcessorServiceImpl.java:113)
at
org.apache.tuscany.core.implementation.processor.ConstructorProcessor.visitConstructor(ConstructorProcessor.java:94)
at
org.apache.tuscany.core.implementation.IntrospectionRegistryImpl.introspect(IntrospectionRegistryImpl.java:83)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.loadByIntrospection(SystemComponentTypeLoader.java:85)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:69)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:42)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-679) InterfaceWSDLLoader mismatch btw. @Constructor annot. and actual Constructor parms
[
http://issues.apache.org/jira/browse/TUSCANY-679?page=comments#action_12431764
]
Jim Marino commented on TUSCANY-679:
oops didn't see the patch. Yes this will work or just delete the @Constructor
InterfaceWSDLLoader mismatch btw. @Constructor annot. and actual Constructor
parms
---
Key: TUSCANY-679
URL: http://issues.apache.org/jira/browse/TUSCANY-679
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding
Affects Versions: Java-M2
Reporter: Scott Kurz
Attachments: InterfaceWSDLLoader.ConstructorFix.patch
PROBLEM:
Mismatch btw. annotation:
@Constructor({registry})
and Constructor:
public InterfaceWSDLLoader(@Autowire LoaderRegistry registry,
@Autowire WSDLDefinitionRegistry wsdlRegistry)
{
SYMPTOM:
org.apache.tuscany.core.implementation.processor.InvalidAutowireException:
Names in @Constructor and autowire parameter do not match at 2 [public
org.apache.tuscany.idl.wsdl.InterfaceWSDLLoader(org.apache.tuscany.spi.loader.LoaderRegistry,org.apache.tuscany.idl.wsdl.WSDLDefinitionRegistry)]
Context stack trace: [tuscany.system][intf.wsdl.loader]
at
org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processAutowire(ImplementationProcessorServiceImpl.java:186)
at
org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processParam(ImplementationProcessorServiceImpl.java:113)
at
org.apache.tuscany.core.implementation.processor.ConstructorProcessor.visitConstructor(ConstructorProcessor.java:94)
at
org.apache.tuscany.core.implementation.IntrospectionRegistryImpl.introspect(IntrospectionRegistryImpl.java:83)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.loadByIntrospection(SystemComponentTypeLoader.java:85)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:69)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:42)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
--
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] Closed: (TUSCANY-679) InterfaceWSDLLoader mismatch btw. @Constructor annot. and actual Constructor parms
[ http://issues.apache.org/jira/browse/TUSCANY-679?page=all ]
Jeremy Boynes closed TUSCANY-679.
-
Resolution: Fixed
Patch applied fine - thanks
InterfaceWSDLLoader mismatch btw. @Constructor annot. and actual Constructor
parms
---
Key: TUSCANY-679
URL: http://issues.apache.org/jira/browse/TUSCANY-679
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding
Affects Versions: Java-M2
Reporter: Scott Kurz
Attachments: InterfaceWSDLLoader.ConstructorFix.patch
PROBLEM:
Mismatch btw. annotation:
@Constructor({registry})
and Constructor:
public InterfaceWSDLLoader(@Autowire LoaderRegistry registry,
@Autowire WSDLDefinitionRegistry wsdlRegistry)
{
SYMPTOM:
org.apache.tuscany.core.implementation.processor.InvalidAutowireException:
Names in @Constructor and autowire parameter do not match at 2 [public
org.apache.tuscany.idl.wsdl.InterfaceWSDLLoader(org.apache.tuscany.spi.loader.LoaderRegistry,org.apache.tuscany.idl.wsdl.WSDLDefinitionRegistry)]
Context stack trace: [tuscany.system][intf.wsdl.loader]
at
org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processAutowire(ImplementationProcessorServiceImpl.java:186)
at
org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processParam(ImplementationProcessorServiceImpl.java:113)
at
org.apache.tuscany.core.implementation.processor.ConstructorProcessor.visitConstructor(ConstructorProcessor.java:94)
at
org.apache.tuscany.core.implementation.IntrospectionRegistryImpl.introspect(IntrospectionRegistryImpl.java:83)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.loadByIntrospection(SystemComponentTypeLoader.java:85)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:69)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:42)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
--
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: SDO spec jar manifest
This includes the spec version number in the manifest as well - do we
want to do the same with the artifact id (as we do with sca)?
This would make the jar name:
sdo-api-r${specVersion}-${tuscanyVersion}.jar
e.g.
sdo-api-r2.01-1.0.jar
(you want to allow for multiple versions of the spec jar in case some
implementation in there changes).
--
Jeremy
On Aug 30, 2006, at 7:35 PM, Jeremy Boynes wrote:
I committed a version of this by accident in r438750 - rather than
back that out, I'm going to assume consensus and finish it up.
--
Jeremy
On Aug 30, 2006, at 4:39 PM, Jeremy Boynes wrote:
This is currently located in the source tree and out of date -
should I update to use the OSGi plugin like the SCA one does?
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: build breaks (and how to fix them)
I have updated the POMs for the spec projects and buildtools so that we are ready to publish snapshot builds for them. This will allow us to build and publish SCA and SDO as standalone projects. Once SDO is published, we should be able to build and publish DAS. To tackle 3), I will move the projects under a new subdirectory in sca called (for want of a better name as core is taken) kernel. -- Jeremy On Aug 29, 2006, at 5:24 PM, Jeremy Boynes wrote: Sounds good to me. I will start to publish unstable builds to the apache snapshot repo to help stabilize things. -- Jeremy On Aug 25, 2006, at 5:20 PM, Jim Marino wrote: Many of us have experienced build breaks over the past several weeks, particularly in the Java SCA project. I believe the root of the problem to be not having the correct level of modularity. I would like to start with a general approach on how to fix this and once we gain consensus, move to creating a proposal for changing the current build structure. 1. The source tree should be independently built from individual projects under /java, sca, sdo, and das. Currently it is not since buildtools is required. I would like to get to the point where people can check out individual sub projects only and build from there. 2. For SCA Java, as Ant proposed, the samples dealing with extensions would move to their appropriate extension projects. Samples that used multiple extensions (e.g. BigBank with Celtix and Axis) would stay under samples/sca 3. API, SPI, core, hostutil, host-api would be built independently under a subdirectory of /sca 4. Runtime host projects would be build independently under a subdirectory of /sca 5. Extensions would move into into a subdirectory of /sca (they could still be organized according to type) and be built individually against a particular version of the core jars. This would mean that extensions are not built together and are not built with the core. This would shield the entire build process from breaking when an extension breaks (e.g. Axis and Axiom not being in sync). It would also mean changes to the core could be vetted and not impact work being done on extensions. Thoughts? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Optiional Autowire
Rick, I realized I need to take a look at Ignacio's patch since I'm sure it won't apply cleanly with the SPI changes in place. So, if you don't mind, could you take a look at adding optional autowires? Here is what needs to be done: 1. Change the autowire annotation to default to required true (obvious) 2. The implementation processing framework needs to be updated to introspect autowire annotations and update ReferenceDefinition.setRequired(). ReferenceDefinition is used to represent references in general, and autowires in particular, which are treated as a type. There are several processors which may need updating. One is ImplementationProcessorServiceImpl. 3. SystemComponentBuilder needs to be modified to deal with ReferenceDefinition.isRequired() for autowires and pass that to the SystemOutboundAutowire constructor (which will need to be modified to add a required field) as it creates system wires. 4. SystemOutboundAutowire when it resolves the autowire will throw an exception if its required field is true. Let me know if I can help out. Jim On Aug 30, 2006, at 2:06 PM, Jim Marino wrote: On Aug 30, 2006, at 1:41 PM, Rick wrote: Sure why meddle with the master! :-) I'd actually not mind avoiding doing it myself but I prefer that to having to reconcile changes Seriously, the only request I would have is if convenient could you make it a separate svn checkin? Just like to review what you did for just this. Yep. That's what I intend to do The autowire information as far as I see is lost in the connection building phase, unless I missed it. Was wondering if it could not be added directly to the ServiceContract. It shouldn't be on the service contract since it is part of the component type (autowire is really a type of reference). ReferenceDefinition already contains the information needed and can be accessed from the system component builder. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
