Re: Thread context classloader: Location of implementation scripts
Sebastien, I did come across (2), but I assumed that (1) was deliberately using a script name rather than module/classnames etc. to keep the code consistent across all scripts. The original Tuscany code loaded scripts using threadContextClassLoader.getResource(scriptName). The changes I made replaced this with contributionClassLoader.getResource(scriptName), and the classloaders of all contributions with any matching import/export namespace are searched for the resource. This is where I came across (2) since I wasn't sure if the namespace in import/export should refer to the directory name of the resource. I didn't want to introduce a new import.script/ because that meant changing the externals. To implement (1), there should be an URLArtifactProcessor for each script type, associated with each script file extension (eg. .rb), so that the file is added to the list of deployable artifacts of the contribution. There should also be a ModelResolver for each script type which matches the module/classname etc. from your example using the list of deployable artifacts. I am not entirely sure where the implementation of (2) fits. The SCA spec says: Technologies that use naming schemes other than QNames must use a different import element from the same substitution group as the the SCA import element. The element used identifies the technology, and may use any value for the namespace that is appropriate for that technology. For example, import.java can be used can be used to import java definitions, in which case the namespace should be a fully qualified package name. From this I would expect import.rb/ to specify how Ruby imports are specified. At the moment import.java/ which is the only one supported apart from import, is implemented by contribution-java. Do we need a new contribution-script to support a list of new import.xxx/ statements in the contributions? Thank you... Regards, Rajini On 11/6/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Rajini Sivaram wrote: Hello, Implementation scripts are currently resolved by the thread context classloader. The code in org.apache.tuscany.sca.extension.helper.utils. ResourceUtil.readResource(String scriptName) is: ... //FIXME The classloader should be passed in ClassLoader cl = Thread.currentThread().getContextClassLoader(); URL scriptSrcUrl = cl.getResource(scriptName); I think scripts should be read from contributions, with contribution import/export semantics, using a model resolver which uses the contribution classloader. There is similar code in implementation.query/ as well which reads the xquery script using the thread context classloader, which also looks like it should use a contribution based model resolver. Thoughts? Thank you... Regards, Rajini Rajini, You're right, all of these should use a model resolver for finding script files. I'd like to raise two related issues: 1) Should we reference script implementation artifacts by script file path or by artifact logical name? a) implementation.script script=samples/calculator/calculator.rb/ or b) implementation.ruby module=calculator/ for modules and implementation.ruby class=calculator.Calculator for classes We're currently doing (a). I think that (b) will be better: - will better fit with the specifics of each scripting language (supporting modules, classes, functions etc.) - more in line with what is done for other languages in SCA (Java, BPEL, etc.) - will also allow you to use modules from a Ruby standard library for example (on the Ruby runtime path). 2) How does the application developer reference script artifacts in imported contributions when the only import mechanisms we have right now are import for XML namespaces and import.java for Java package names... huh looks like a hole in our import story :) Implementing model resolvers for the scripts is a good first step, my guess is that it'll lead you to have to resolve (1) and (2) :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (TUSCANY-1698) Changes in DAS Config to support authenticated connection using data source
[ https://issues.apache.org/jira/browse/TUSCANY-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar reopened TUSCANY-1698: -- changing database, JNDI provider. Changes in DAS Config to support authenticated connection using data source --- Key: TUSCANY-1698 URL: https://issues.apache.org/jira/browse/TUSCANY-1698 Project: Tuscany Issue Type: Improvement Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1698.patch in RDB-DAS, when we use external DataSource, we do not pass userName, password. But MySQL (which with InnoDB supports Txn and works well with JOTM) does need id, pwd in ds.getConnection(). This can be case with other DBs as well. So, it looks like DAS config.xsd needs to allow passing userName, password in ConnectionInfo too ( and not just for ConnectionProperties). Thus below will be the changed DAS config portion:- xsd:complexType name=ConnectionInfo xsd:sequence xsd:element maxOccurs=1 minOccurs=0 name=ConnectionProperties type=config:ConnectionProperties/ /xsd:sequence xsd:attribute name=dataSource type=xsd:string/ xsd:attribute name=managedtx type=xsd:boolean default=true/ xsd:attribute name=userName type=xsd:string default=/ xsd:attribute name=password type=xsd:string default=/ /xsd:complexType xsd:complexType name=ConnectionProperties xsd:attribute name=driverClass type=xsd:string/ xsd:attribute name=databaseURL type=xsd:string/ xsd:attribute name=loginTimeout type=xsd:int default=0/ /xsd:complexType -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1698) Changes in DAS Config to support authenticated connection using data source
[ https://issues.apache.org/jira/browse/TUSCANY-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1698: - Attachment: 1698.patch Changed files:- *rdb/pom.xml *distribution/binary/pom.xml *distribution/binary/src/main/assembly/das.xml *rdb/src/test/java/org/apache/tuscany/das/rdb/test/ConnectionTests.java *rdb/src/test/resources/connectionInfoDataSourceAuth.xml *samples/pom.xml *samples/Readme.htm *samples/dbconfig/readm.htm *deleted - sample-dataSource Changes in DAS Config to support authenticated connection using data source --- Key: TUSCANY-1698 URL: https://issues.apache.org/jira/browse/TUSCANY-1698 Project: Tuscany Issue Type: Improvement Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1698.patch in RDB-DAS, when we use external DataSource, we do not pass userName, password. But MySQL (which with InnoDB supports Txn and works well with JOTM) does need id, pwd in ds.getConnection(). This can be case with other DBs as well. So, it looks like DAS config.xsd needs to allow passing userName, password in ConnectionInfo too ( and not just for ConnectionProperties). Thus below will be the changed DAS config portion:- xsd:complexType name=ConnectionInfo xsd:sequence xsd:element maxOccurs=1 minOccurs=0 name=ConnectionProperties type=config:ConnectionProperties/ /xsd:sequence xsd:attribute name=dataSource type=xsd:string/ xsd:attribute name=managedtx type=xsd:boolean default=true/ xsd:attribute name=userName type=xsd:string default=/ xsd:attribute name=password type=xsd:string default=/ /xsd:complexType xsd:complexType name=ConnectionProperties xsd:attribute name=driverClass type=xsd:string/ xsd:attribute name=databaseURL type=xsd:string/ xsd:attribute name=loginTimeout type=xsd:int default=0/ /xsd:complexType -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] DAS samples
changes done - 1) cleaned readme files using eclipse IDE html editor - samples, dbconfig 2) replaced MySQL with Derby 3) replaced sun provided JNDI jars with jboss jar - because - these are available in mvn repos and only 3 are required in the build path (jboss-common 3.2.3, jnp-client 4.0.2 and jnpserver 3.2.3 - total 350 KB) 4) added more test cases in ConnectionTests.java and removed sample-dataSource 5) patch attached to JIRA-1698 Please see if there are any problems in the above, else I will commit the patch. The bin size increase due to jboss jars is 350 KB and so it may be OK to make it as test cases instead of sample. Regards, Amita On 11/5/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: On 11/5/07, Luciano Resende [EMAIL PROTECTED] wrote: I was trying to run the new DAS sample (dataSource) and I looks like it requires MySQL in order to run the sample, this might not be the best default configuration to require, as it requires lots of steps in order to just try the sample ( e.g install MySQL), and it also makes it difficult to test the sample during build. I'd like to suggest two things for our DAS Sample applications : - Use Derby as the default database in a sample application Agree, done changes for this - Have a simple unit test to quickly check if the sample is working (use htmlUnit for webapp) The jira has test cases for case which does not require external JNDI. Which JNDI jar is available as part of maven repo? I could not spot one and used sun's jars. As these can not get downloaded thru mvn build and need to be placed manually in the classpath, used sample instead of junit for testcase which requires JNDI. But if there is a maven repo based jar providing JNDI, the sample can be removed and instead junit cases can be added. Tried RootContext from Geronimo but it is read only. Also, I was wondering what we should use for demonstrating a specific feature... I guess we might not need a new sample for every new feature, this might increase the complexity of developing a new feature, I guess a test case might be good enough and a sample would be used more to demonstrate a bigger scenario or a how a set of features work together... Thoughts ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresendehttp://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SDO] validations in SDOUtil.createFromString()
Object convertedObj = org.apache.tuscany.sdo.util.SDOUtil.createFromString( TypeHelper.INSTANCE.getType(commonj.sdo, Month) , abcd); System.out.println(conv month +convertedObj+, +convertedObj.getClass().getName()); Is the above supposed to throw some sort of exception as abcd is not in following --mm zz? pattern? I tried it and it simply gives abcd String with no exceptions. Trying to understand what is the expected behavior. Regards, Amita
Re: [SDO] validations in SDOUtil.createFromString()
SDO doesn't require validation at any particular time, so it's up to the implementation. The primary use of the createFromString() and convertToString() methods is to support XML deserialization and serialization respectively. We don't want to slow down load performance if we don't need to, and since the SDO Month type's instanceClass is java.lang.String, we simply assume it's valid and return the same string in createFromString - see ModelFactoryImpl.createMonthFromString(). Frank Amita Vadhavkar [EMAIL PROTECTED] wrote on 11/06/2007 08:01:49 AM: Object convertedObj = org.apache.tuscany.sdo.util.SDOUtil.createFromString( TypeHelper.INSTANCE.getType(commonj.sdo, Month) , abcd); System.out.println(conv month +convertedObj+, +convertedObj.getClass().getName()); Is the above supposed to throw some sort of exception as abcd is not in following --mm zz? pattern? I tried it and it simply gives abcd String with no exceptions. Trying to understand what is the expected behavior. Regards, Amita - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A Chinese version of Tuscany's technical page
Yes, it looks like there is some kind of post-process on these pages that are transforming all the unicode/internation characters in ???. Let me fire a mail to infra guys... Luciano, Did you hear back from infra? Is there a solution? Haleh On 11/5/07, 王洪伟 [EMAIL PROTECTED] wrote: Yes, I had the same experience. it works well in time of editoring and saving, but goes wrong after some time. 2007/11/6, Junjie Guo [EMAIL PROTECTED]: I edited and changed the wrong Chinese page to right page,but it is wrong yet in this morning. I don't know what happened in the evening.For example,audited by others and autoexec tasks by wiki software, ect. I'm guessing that the question is in here possibly. On 11/6/07, Simon Nash [EMAIL PROTECTED] wrote: I am seeing all these strings as . I'm guessing that there was some difference between them when Raymond entered them in his post. Simon Raymond Feng wrote: Hi, I did a test following the instructions from confluence and it turned out that the Database cannot handle the roundtrip correctly. http://cwiki.apache.org/confluence/admin/encodingtestrun.action Test 2: Form submission This is the test string pasted by you into the web form and submitted back to Confluence Test 3: Database round-trip (select as lower-case) This is the string from Test 2 after being stored in the database and then retrieved as lower-case Test 4: Database round-trip (select as upper-case) This is the string from Test 2 after being stored in the database and then retrieved as upper-case Expected result (converting Java string to uppercase) Thanks, Raymond - Original Message - From: Luciano Resende [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, November 05, 2007 9:14 AM Subject: Re: A Chinese version of Tuscany's technical page Yes, it looks like there is some kind of post-process on these pages that are transforming all the unicode/internation characters in ???. Let me fire a mail to infra guys... On 11/5/07, Simon Nash [EMAIL PROTECTED] wrote: I see some characters ?? on [1], and I also see many ? characters on the Wiki pages that Junjie put up. Do other people see these ? characters as well? I think this is the problem that Junjie is describing. Simon haleh mahbod wrote: It looks fine to me, but I can't understand it :) Raymond can you please check it out before it is moved to the website? On 11/3/07, Luciano Resende [EMAIL PROTECTED] wrote: I made a quick test, and added a page [1] with some special characters, and Chinese characters, and it looks like confluence is handling it OK... Could you try copying one page again and let's see how it goes ? [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Test+lresende On 11/1/07, Junjie Guo [EMAIL PROTECTED] wrote: Hello: All the Chinese pages that I wrote in the wiki yestoday change to ?, it was OK yestoday,but now.. Why? http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Chinese+Website On 10/24/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi Junjie, I can help to move the page to the website. Let me know when you are done with your update. How are you planning to keep the pages in sync with the English version moving forward? Haleh On 10/23/07, Simon Nash [EMAIL PROTECTED] wrote: Junjie, That's great news. The easiest way to do this would be for you to put these pages on the Tuscany Wiki. It's at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home You can create a new child page under the top level home page and put the Chinese pages there. When the pages are there, the Tuscany community can take a look at them and someone who has read-write access to the Tuscany Web site can move them over to the Web site. We can handle later updates to these pages in the same way. Do you have a Contributor License Agreement on file with Apache? This is needed for licensing reasons before we can put the pages on the Tuscany Web site. The page http://www.apache.org/licenses/ explains what is needed. See the descriptions of the Individual Contributor License Agreement and the Corporate CLA in the section entitled Contributor License Agreements. Simon Junjie Guo wrote: Simon, I'm in Shangguang Geng's team, we would like to put the Chinese content to the Tuscany Web site. Which format or way we use send it to you? We want the better way is
Axis client settings was: Re: [jira] Assigned: (TUSCANY-1804) @OneWay repeted invocations doesn't work in web service binding
Hi Giorgio
Am just applying your patch to make repeated @OneWay invocations work to the
tunk and it's looking good as I'm getting a clean build and the new onway
itest now runs. (Am just updating your workpool demo to trunk level as well
- more in this later) In the mean time I'm interested in understanding what
was actually going wrong with the axis binding. Looking at the changes you
made there are two main things.
First, setting UseSeparateListener and AUTO_RELEASE_CONNECTION on the
operation client
Second, creating an HTTPClient if one doesn't already exist,
So, looking at this, it seems that Axis2 was not cleaning up connections
properly after a request and that the default HTTP client was not configured
correctly.. Did you specifically observe what was going on under the covers
to cause the problem?
Regards
Simon
On 11/1/07, Simon Laws (JIRA) tuscany-dev@ws.apache.org wrote:
[
https://issues.apache.org/jira/browse/TUSCANY-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
Simon Laws reassigned TUSCANY-1804:
---
Assignee: Simon Laws
@OneWay repeted invocations doesn't work in web service binding
---
Key: TUSCANY-1804
URL: https://issues.apache.org/jira/browse/TUSCANY-1804
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-0.99
Environment: Eclipse/JDK 1.5 / Ubuntu Linux 7.04
Reporter: Giorgio Zoppi
Assignee: Simon Laws
Fix For: Java-SCA-1.0.1
Attachments: patch.diff
i've found the bug that it doens't permit myself to use SCA Binding over
WebService modifying the distributed-calculator. I found it (on Tuscany
1.0 rc3) following the chain towards the wire, and i discovered that
it's an Axis Fault. If you modify in your distributed calculator sample
the SubtractionService in the following way:
@Remotable
public interface SubtractService {
@OneWay
void subtract(double n1, double n2);
}
public class SubtractServiceImpl implements SubtractService {
public void subtract(double n1, double n2) {
System.out.println(SubtractService - subtract + n1 + and
+ n2);
//return n1 - n2;
}
}
I know that it doesn't nothing...but it's a proof of concept.
And in the calculator node:
for (int k = 0; k 10; ++k)
calculatorService.subtract(2*k+3, k);
The nodeC with current Axis2OneWayBindingInvoker, even if it's called 10
times..the receiver gets two messages..
So in the nodeC terminal you can see only for example:
[java] SubtractService - subtract 15.0 and 6.0
[java] SubtractService - subtract 17.0 and 7.0
The reason is due to the Axis HTTP REUSE:
If you change in Axis2OneWayBindingInvoker
requestMC.getOptions().setProperty(HTTPConstants.REUSE_HTTP_CLIENT,
Boolean.TRUE);
to:
requestMC.getOptions().setProperty(HTTPConstants.REUSE_HTTP_CLIENT,
Boolean.FALSE);
It works! I suspect that there's a bug or a queue full in Axis because
it seems that if you send something too fast it doesn't work (I'll see
it tomorrow, because I don't know how the http client reuse works in
Axis).
The next test, I'll do it :
for (int k = 0; k 50; ++k)
calculatorService.subtract(2*k+3, k);
It seems to work, but in a strange way.
During the debugging i discovered your nice structure in order to invoke
methods over ws.
Mainly for the Remote SCA over Web Services your structure has the
following stages (correct me if i'm wrong):
1) JDKInvocationHandler, where you proxies the method call, create the
message, set the source, the target and the operation. Here still you do
some sort of initialization for handling callback.
2) DataTrasformationInterceptor, where you create the soap body of the
message given the operation and parameters, for example:
_ns_:add
xmlns:_ns_=http://calculator/xsd;_ns_:param03.0/_ns_:param0_ns_:p
aram12.0/_ns_:param1/_ns_:add
3) NonblockingInterceptor, where Tuscany schedules invocation in a
workpool (here with jdk 1.5 , you could remove dependency from commonj
package)
4) At time of scheduling, the next invoker is Axis2SCABindingInvoker,
which it's a wrapper for Axis2BindingInvoker if the invocation is
Request-response or for the Axis2BindingInvoker's child
(Axis2OneWayBindingInvoker) if the invocation is OneWay. In
Axis2*BindingInvoker you create the soap envelope, the Axis's
OperationClient, set the axis invocation options and Axis's
MessageContext and the you send all the stuff on the wire.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
[jira] Updated: (TUSCANY-1893) Axis timeout settings are hardcoded at 2 minutes
[ https://issues.apache.org/jira/browse/TUSCANY-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip updated TUSCANY-1893: -- Attachment: Axis2BindingInvoker.java Made GLOBAL_AXIS_TIMEOUT a public static so Axis timeout setting can be modified. Axis timeout settings are hardcoded at 2 minutes Key: TUSCANY-1893 URL: https://issues.apache.org/jira/browse/TUSCANY-1893 Project: Tuscany Issue Type: Improvement Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.0 Environment: Windows/Tomcat, Windows/Websphere, Solaris/Websphere Reporter: Sunny Ip Priority: Minor Attachments: Axis2BindingInvoker.java The Axis timeout settings should be configurable. A team member put in a quick hack to expose the timeout field as public static. Will attach the class to this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1893) Axis timeout settings are hardcoded at 2 minutes
Axis timeout settings are hardcoded at 2 minutes Key: TUSCANY-1893 URL: https://issues.apache.org/jira/browse/TUSCANY-1893 Project: Tuscany Issue Type: Improvement Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.0 Environment: Windows/Tomcat, Windows/Websphere, Solaris/Websphere Reporter: Sunny Ip Priority: Minor The Axis timeout settings should be configurable. A team member put in a quick hack to expose the timeout field as public static. Will attach the class to this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] DAS samples
Comments inline : On 11/6/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: changes done - 1) cleaned readme files using eclipse IDE html editor - samples, dbconfig Good, Thanks, please committ this, you don't have to wait anymore :) 2) replaced MySQL with Derby Just want to make sure you have all the functionality you need in Derby... 3) replaced sun provided JNDI jars with jboss jar - because - these are available in mvn repos and only 3 are required in the build path (jboss-common 3.2.3, jnp-client 4.0.2 and jnpserver 3.2.3 - total 350 KB) I downloaded the jars, but couldn't find any license files there. Also, JBOSS stuff tend to be LGPL and that is not ASF Friendly, so could you please point me to the proper license for these files ? 4) added more test cases in ConnectionTests.java and removed sample-dataSource 5) patch attached to JIRA-1698 Please see if there are any problems in the above, else I will commit the patch. The bin size increase due to jboss jars is 350 KB and so it may be OK to make it as test cases instead of sample. Well, in summary, it's lots of dependencies issues to demonstrate we now support authentication when retrieving the datasource connection... and based on the dependencies being dragged to DAS distro... I'm now inclined to have just a sample, or simpler, just document in the User Guide. BTW, I'll play with this over the weekend and try to make this working in TC with Companyweb... Maybe this is a simpler solution :) Regards, Amita On 11/5/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: On 11/5/07, Luciano Resende [EMAIL PROTECTED] wrote: I was trying to run the new DAS sample (dataSource) and I looks like it requires MySQL in order to run the sample, this might not be the best default configuration to require, as it requires lots of steps in order to just try the sample ( e.g install MySQL), and it also makes it difficult to test the sample during build. I'd like to suggest two things for our DAS Sample applications : - Use Derby as the default database in a sample application Agree, done changes for this - Have a simple unit test to quickly check if the sample is working (use htmlUnit for webapp) The jira has test cases for case which does not require external JNDI. Which JNDI jar is available as part of maven repo? I could not spot one and used sun's jars. As these can not get downloaded thru mvn build and need to be placed manually in the classpath, used sample instead of junit for testcase which requires JNDI. But if there is a maven repo based jar providing JNDI, the sample can be removed and instead junit cases can be added. Tried RootContext from Geronimo but it is read only. Also, I was wondering what we should use for demonstrating a specific feature... I guess we might not need a new sample for every new feature, this might increase the complexity of developing a new feature, I guess a test case might be good enough and a sample would be used more to demonstrate a bigger scenario or a how a set of features work together... Thoughts ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresendehttp://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1894) Details of any remote exceptions are lost during web service invocation
[ https://issues.apache.org/jira/browse/TUSCANY-1894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip updated TUSCANY-1894: -- Attachment: RemotableInterfaceTemplate.xsl Details of any remote exceptions are lost during web service invocation --- Key: TUSCANY-1894 URL: https://issues.apache.org/jira/browse/TUSCANY-1894 Project: Tuscany Issue Type: Improvement Components: Java SCA Tools Affects Versions: Java-SCA-1.0 Environment: Windows/Tomcat, Windows/Websphere, Solaris/Websphere Reporter: Sunny Ip Priority: Minor Attachments: RemotableInterfaceTemplate.xsl The service interfaces generated from the WSDL2Java generator do not throws RemoteExceptions, so any exceptions will cause an unknown exception with no details. The XSL used by WSDL2Java has been modified to include throws RemoteException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1894) Details of any remote exceptions are lost during web service invocation
Details of any remote exceptions are lost during web service invocation --- Key: TUSCANY-1894 URL: https://issues.apache.org/jira/browse/TUSCANY-1894 Project: Tuscany Issue Type: Improvement Components: Java SCA Tools Affects Versions: Java-SCA-1.0 Environment: Windows/Tomcat, Windows/Websphere, Solaris/Websphere Reporter: Sunny Ip Priority: Minor Attachments: RemotableInterfaceTemplate.xsl The service interfaces generated from the WSDL2Java generator do not throws RemoteExceptions, so any exceptions will cause an unknown exception with no details. The XSL used by WSDL2Java has been modified to include throws RemoteException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Native] VS build versus ant build
Here is my WoooH too :D Thanks a lot for that brady ; ) Have you checked how the .bat and .sh distro generator files work? Adriano Crestani On Nov 6, 2007 2:10 PM, Brady Johnson [EMAIL PROTECTED] wrote: The Automake and VSExpress build systems have been both removed from TuscanySCA Native with svn revision 592507. WoooH :) TuscanySCA Native now has a common, unified build system for all platforms: Apache ant. I'll get to work on doing the same for SDO now. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adriano Crestani Sent: Monday, November 05, 2007 10:52 PM To: tuscany-dev@ws.apache.org Subject: Re: [Native] VS build versus ant build Thanks for volunteering to get rid of .sh and .bat files brady :D And yes, I will work out on adding ant build to das sample, I expect to have it done till the weekend : ) About the documentation being updated with the new ant build system, I think it's really necessary before the next release, otherwise the docs will be useless, cause there will be no more automake build system :P...maybe Amita can help us with that, she is really good with documentation ; ) Regards, Adriano Crestani On Nov 5, 2007 12:42 PM, Pete Robbins [EMAIL PROTECTED] wrote: On 05/11/2007, Brady Johnson [EMAIL PROTECTED] wrote: I can get started removing all the automake files (this will be fun getting rid of automake! :) ). As for the DAS and SDO samples in ant, the README_ANT_INSTALL mentions that the samples are the only item remaining to complete the entire ant build system. The samples have been added to ant for SCA, Adriano: can you look into completing the samples for DAS? Do you have some sort of checklist for creating a distribution? If I had that, I could get started adding that to the ant build system. Not really. The distro was built on linux using make dist and on windows by the builddist.bat scripts. It should be simpler with ant. For the source distro we just need to zip up the source tree excluding anything we don't want in the distro (e.g. the PHP extension has never been build into a release). The binary release needs to include sample source as well as a zip of the deployed runtime. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Monday, November 05, 2007 2:11 AM To: tuscany-dev@ws.apache.org Subject: Re: [Native] VS build versus ant build I think we should be using ant for everything. The goal is to have a command line build and ant will give us that. We need to ensure that the samples can also be built/deployed using an ant script and that the documentation is updated to reflect this. While we are at it we should write some ant scripts to build and package a distribution. So, if ant build is working on all platforms we can get rid of the VSExpress stuff and the Automake stuff. Cheers, On 04/11/2007, Adriano Crestani [EMAIL PROTECTED] wrote: There are actually 3 build systems on native projects...make, ant and VSExpress. - Make is completely deprecated with the addition of the new ant build process. I think the make build system files (.sh and .bat) could already be removed. - Ant seems to be working for all 3 projects, but DAS and SDO samples - VSExpress seems to be working fine for DAS and SDO, but seems to be broken for SCA(at least the CppCalculator that is the only one I've tested on VSExpress). VSExpress is useful for debugging and development, however it uses .bat files to deploy the generated files, adding more files to the maintenance list :s. Is there a way for VSExpress to use ant to deploy its files? This way we would only need to maintain the ant files. Otherwise, here is +1 to remove VSExpress files too. Thoughts? Suggestions? Adriano Crestani -- Pete - 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] -- Pete - 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: [Native] VS build versus ant build
The Automake and VSExpress build systems have been both removed from TuscanySCA Native with svn revision 592507. WoooH :) TuscanySCA Native now has a common, unified build system for all platforms: Apache ant. I'll get to work on doing the same for SDO now. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adriano Crestani Sent: Monday, November 05, 2007 10:52 PM To: tuscany-dev@ws.apache.org Subject: Re: [Native] VS build versus ant build Thanks for volunteering to get rid of .sh and .bat files brady :D And yes, I will work out on adding ant build to das sample, I expect to have it done till the weekend : ) About the documentation being updated with the new ant build system, I think it's really necessary before the next release, otherwise the docs will be useless, cause there will be no more automake build system :P...maybe Amita can help us with that, she is really good with documentation ; ) Regards, Adriano Crestani On Nov 5, 2007 12:42 PM, Pete Robbins [EMAIL PROTECTED] wrote: On 05/11/2007, Brady Johnson [EMAIL PROTECTED] wrote: I can get started removing all the automake files (this will be fun getting rid of automake! :) ). As for the DAS and SDO samples in ant, the README_ANT_INSTALL mentions that the samples are the only item remaining to complete the entire ant build system. The samples have been added to ant for SCA, Adriano: can you look into completing the samples for DAS? Do you have some sort of checklist for creating a distribution? If I had that, I could get started adding that to the ant build system. Not really. The distro was built on linux using make dist and on windows by the builddist.bat scripts. It should be simpler with ant. For the source distro we just need to zip up the source tree excluding anything we don't want in the distro (e.g. the PHP extension has never been build into a release). The binary release needs to include sample source as well as a zip of the deployed runtime. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Monday, November 05, 2007 2:11 AM To: tuscany-dev@ws.apache.org Subject: Re: [Native] VS build versus ant build I think we should be using ant for everything. The goal is to have a command line build and ant will give us that. We need to ensure that the samples can also be built/deployed using an ant script and that the documentation is updated to reflect this. While we are at it we should write some ant scripts to build and package a distribution. So, if ant build is working on all platforms we can get rid of the VSExpress stuff and the Automake stuff. Cheers, On 04/11/2007, Adriano Crestani [EMAIL PROTECTED] wrote: There are actually 3 build systems on native projects...make, ant and VSExpress. - Make is completely deprecated with the addition of the new ant build process. I think the make build system files (.sh and .bat) could already be removed. - Ant seems to be working for all 3 projects, but DAS and SDO samples - VSExpress seems to be working fine for DAS and SDO, but seems to be broken for SCA(at least the CppCalculator that is the only one I've tested on VSExpress). VSExpress is useful for debugging and development, however it uses .bat files to deploy the generated files, adding more files to the maintenance list :s. Is there a way for VSExpress to use ant to deploy its files? This way we would only need to maintain the ant files. Otherwise, here is +1 to remove VSExpress files too. Thoughts? Suggestions? Adriano Crestani -- Pete - 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] -- Pete - 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: [DISCUSS] Evolving Implementation-data
What could be better? Should the modifications stream contain only the
modifications, or should it be the stream retrieved by the get method (DATA
interface) with the updates?
Other comments inline.
On 11/5/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
A few comments inline.
[snip]
Douglas Leite wrote:
With the data being manipulated like a XmlStreamReader, I suppose that a
good way to implement the update operator is use a stream that contains
the
modifications. Something like that:
int update(XmlStreamReader modifications);
Therefore, the 'modifications' stream will cotain all the modifications
made
in the stream retrieved from the get operator.
What's the int for? can't that method just be void?
However, in the scenary where we have a simple java developer, how is he
supposed to manipulate the stream reader ?
A Java developer developing a client component talking to your Data
component will probably want to do:
update(Customer customer)
with customer being a Java Object representation of the Customer
business object / resource to update.
So IMO implementation-data should support both modes:
- good integration with XML, useful for local and remote XML enabled
clients
- good integration with Java business objects for local Java clients,
and Java-friendly remote clients (e.g. Json clients)
What about a XmlStreamReader that allow some sets methods?
I think that a set can be represented as an update. Also, a set of
related sets can be batched in a single update.
On 10/12/07, Douglas Leite [EMAIL PROTECTED] wrote:
As suggested, I've made some improvements in the sample store. Now the
catalog data is accessed by JDBC instead of a hardcoded table in
memory. (https://issues.apache.org/jira/browse/TUSCANY-1844
)
After running the sample with the property currencyCode configured as
'EUR', in the store.composite, I got an float parse error in the
getTotal
method in the ShoppingCartImpl. Because of that, I've changed a little
the
way of get the price of each product.
This looks like a work around, do you know what the problem with the
Euro symbol is? is it a problem with the Atom binding not
reading/writing that symbol properly?
I'm not sure, but I think that it can be possible.
In the ShoppingCartImpl:
private String getTotal() {
[...]
String item =
((Content)cart.values().iterator().next().getContents().get(0)).getValue();
[...]
}
The String item contains the wrong symbol, and the cart map is filled with
the catalog data using the atom binding.
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 3rd try: Release Tuscany SCA Java 1.0.1-incubating (RC4)
Raymond Feng wrote: Hi, Please review and vote on the 1.0.1-incubating release artifacts of Tuscany SCA for Java. The RC4 contains a few fixes to issues discovered in RC3. Thank you for reporting and fixing the issues promptly. SVN Tag: http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.0.1-RC4/ Stage maven repo: http://people.apache.org/~rfeng/tuscany/maven/ RAT report: http://people.apache.org/~rfeng/tuscany/1.0.1-RC4/1.0.1-RC4.rat.txt Distros (zip/gz/asc/md5) : http://people.apache.org/~rfeng/tuscany/1.0.1-RC4/ Thanks, Raymond PS: I posted this message on Friday and it was only sent to myself :-( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I reviewed and tested the distro on Linux RHEL5. - Webapp samples worked OK on Tomcat. - All standalone samples with ant scripts worked except the binding-notification-* ones as I didn't know in which order I was supposed to start them. Just one minor issue: the nodes in calculator-distributed did not exit after pressing enter, but ctrl+C worked :) The WSDL at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.0.1-RC4/demos/xml-bigbank/src/main/resources/wsdl/StockQuotes.wsdl is missing a license header. What's its status and do we need that WSDL? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 3rd try: Release Tuscany SCA Java 1.0.1-incubating (RC4)
Hi JS, The binding-notification-* samples can be run in isolation via ant run. But also to run them from the command line, they assume that the ntm runs on port 8083 and so the sample that is started first needs to use that port. The sample command in the README for the producer does that, so if you use it you should run the producer first. Otherwise, just make sure that the first one you run uses -Dnotification.httpPort=8083. The sample overview in the READMEs tries to describe this. On 11/6/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Raymond Feng wrote: Hi, Please review and vote on the 1.0.1-incubating release artifacts of Tuscany SCA for Java. The RC4 contains a few fixes to issues discovered in RC3. Thank you for reporting and fixing the issues promptly. SVN Tag: http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.0.1-RC4/ Stage maven repo: http://people.apache.org/~rfeng/tuscany/maven/ RAT report: http://people.apache.org/~rfeng/tuscany/1.0.1-RC4/1.0.1-RC4.rat.txt Distros (zip/gz/asc/md5) : http://people.apache.org/~rfeng/tuscany/1.0.1-RC4/ Thanks, Raymond PS: I posted this message on Friday and it was only sent to myself :-( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I reviewed and tested the distro on Linux RHEL5. - Webapp samples worked OK on Tomcat. - All standalone samples with ant scripts worked except the binding-notification-* ones as I didn't know in which order I was supposed to start them. Just one minor issue: the nodes in calculator-distributed did not exit after pressing enter, but ctrl+C worked :) The WSDL at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.0.1-RC4/demos/xml-bigbank/src/main/resources/wsdl/StockQuotes.wsdl is missing a license header. What's its status and do we need that WSDL? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 3rd try: Release Tuscany SCA Java 1.0.1-incubating (RC4)
Ignacio Silva-Lepe wrote: Hi JS, The binding-notification-* samples can be run in isolation via ant run. But also to run them from the command line, they assume that the ntm runs on port 8083 and so the sample that is started first needs to use that port. The sample command in the README for the producer does that, so if you use it you should run the producer first. Otherwise, just make sure that the first one you run uses -Dnotification.httpPort=8083. The sample overview in the READMEs tries to describe this. [snip] - All standalone samples with ant scripts worked except the binding-notification-* ones as I didn't know in which order I was supposed to start them. Just one minor issue: the nodes in calculator-distributed did not exit after pressing enter, but ctrl+C worked :) OK, I got the binding-notification producer and consumer working, using the java... command lines described in the READMEs. However the ant scripts seem to just start + stop each sample without giving the opportunity to send messages. This is not a blocker though, they can be fixed in the next release. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 3rd try: Release Tuscany SCA Java 1.0.1-incubating (RC4)
The ant scripts were written to just start and stop. To send messages they would need to run concurrently and on different ports, which would then break if they were run in isolation. I tried to keep the whole simple enough so ant run does unit test and java command does system test. But we can 'fix' this in the next release if necessary. On 11/6/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Ignacio Silva-Lepe wrote: Hi JS, The binding-notification-* samples can be run in isolation via ant run. But also to run them from the command line, they assume that the ntm runs on port 8083 and so the sample that is started first needs to use that port. The sample command in the README for the producer does that, so if you use it you should run the producer first. Otherwise, just make sure that the first one you run uses -Dnotification.httpPort=8083. The sample overview in the READMEs tries to describe this. [snip] - All standalone samples with ant scripts worked except the binding-notification-* ones as I didn't know in which order I was supposed to start them. Just one minor issue: the nodes in calculator-distributed did not exit after pressing enter, but ctrl+C worked :) OK, I got the binding-notification producer and consumer working, using the java... command lines described in the READMEs. However the ant scripts seem to just start + stop each sample without giving the opportunity to send messages. This is not a blocker though, they can be fixed in the next release. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Set the default port number for embedded Tomcat/Jetty server?
On 11/6/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, The itest-conversations-ws breaks the continuum build as it uses port 8080. I tried to replace the port with 8085 but I realized that it's very annoying to add the explicit URIs to all the binding.ws including the services and callbacks. Should we have a way to customize the default HTTP port number for embedded Tomcat/Jetty server instead of polluting the composite/WSDL files everywhere? I'm thinking of a system property or an intent/policySet. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Raymond We will be able to do it through the node implemenation when we switch over to the new node implementati. The port from the uri of the node is used to dictate what the default port of the servlet container is. Sebastien did a load of changes in this area recently to make it work for his store sample. See here for an example from the launcher program ( http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/node-impl/src/main/java/org/apache/tuscany/sca/node/launch/SCANodeLauncher.java ) So whatever starts the node can provide the uri from a parameter, environment variable etc. Interestingly the thing that is problematic is existing web app containers rather than the embedded ones. In this case there doesn't seem to be an easy way to get at host/port info programmatically. Probably because you can never be too sure what host/port a servlet is going to be accessed on. So this info can be provided via the node uri again but you are then in the strange situation of configuring you web conatiner and then configuring an environment variable (which doesn't exist yet) to tell tuscany what host/port you have configured the webapp container on. Regards Simon
Re: A Chinese version of Tuscany's technical page
Unfortunately, I haven't heard back from infra@ yet, and the guys on Infra IRC weren't able to give much help this morning. I'm going to check if the confluence guys have a IRC chat or something similar... On 11/6/07, haleh mahbod [EMAIL PROTECTED] wrote: Yes, it looks like there is some kind of post-process on these pages that are transforming all the unicode/internation characters in ???. Let me fire a mail to infra guys... Luciano, Did you hear back from infra? Is there a solution? Haleh On 11/5/07, 王洪伟 [EMAIL PROTECTED] wrote: Yes, I had the same experience. it works well in time of editoring and saving, but goes wrong after some time. 2007/11/6, Junjie Guo [EMAIL PROTECTED]: I edited and changed the wrong Chinese page to right page,but it is wrong yet in this morning. I don't know what happened in the evening.For example,audited by others and autoexec tasks by wiki software, ect. I'm guessing that the question is in here possibly. On 11/6/07, Simon Nash [EMAIL PROTECTED] wrote: I am seeing all these strings as . I'm guessing that there was some difference between them when Raymond entered them in his post. Simon Raymond Feng wrote: Hi, I did a test following the instructions from confluence and it turned out that the Database cannot handle the roundtrip correctly. http://cwiki.apache.org/confluence/admin/encodingtestrun.action Test 2: Form submission This is the test string pasted by you into the web form and submitted back to Confluence Test 3: Database round-trip (select as lower-case) This is the string from Test 2 after being stored in the database and then retrieved as lower-case Test 4: Database round-trip (select as upper-case) This is the string from Test 2 after being stored in the database and then retrieved as upper-case Expected result (converting Java string to uppercase) Thanks, Raymond - Original Message - From: Luciano Resende [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, November 05, 2007 9:14 AM Subject: Re: A Chinese version of Tuscany's technical page Yes, it looks like there is some kind of post-process on these pages that are transforming all the unicode/internation characters in ???. Let me fire a mail to infra guys... On 11/5/07, Simon Nash [EMAIL PROTECTED] wrote: I see some characters ?? on [1], and I also see many ? characters on the Wiki pages that Junjie put up. Do other people see these ? characters as well? I think this is the problem that Junjie is describing. Simon haleh mahbod wrote: It looks fine to me, but I can't understand it :) Raymond can you please check it out before it is moved to the website? On 11/3/07, Luciano Resende [EMAIL PROTECTED] wrote: I made a quick test, and added a page [1] with some special characters, and Chinese characters, and it looks like confluence is handling it OK... Could you try copying one page again and let's see how it goes ? [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Test+lresende On 11/1/07, Junjie Guo [EMAIL PROTECTED] wrote: Hello: All the Chinese pages that I wrote in the wiki yestoday change to ?, it was OK yestoday,but now.. Why? http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Chinese+Website On 10/24/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi Junjie, I can help to move the page to the website. Let me know when you are done with your update. How are you planning to keep the pages in sync with the English version moving forward? Haleh On 10/23/07, Simon Nash [EMAIL PROTECTED] wrote: Junjie, That's great news. The easiest way to do this would be for you to put these pages on the Tuscany Wiki. It's at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home You can create a new child page under the top level home page and put the Chinese pages there. When the pages are there, the Tuscany community can take a look at them and someone who has read-write access to the Tuscany Web site can move them over to the Web site. We can handle later updates to these pages in the same way. Do you have a Contributor License Agreement on file with Apache? This is needed for licensing reasons before we can put the pages on the Tuscany Web site. The page http://www.apache.org/licenses/ explains what is needed.
Set the default port number for embedded Tomcat/Jetty server?
Hi, The itest-conversations-ws breaks the continuum build as it uses port 8080. I tried to replace the port with 8085 but I realized that it's very annoying to add the explicit URIs to all the binding.ws including the services and callbacks. Should we have a way to customize the default HTTP port number for embedded Tomcat/Jetty server instead of polluting the composite/WSDL files everywhere? I'm thinking of a system property or an intent/policySet. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1895) UpdateGenerator.getChangedFields() mistakenly returns exception
UpdateGenerator.getChangedFields() mistakenly returns exception --- Key: TUSCANY-1895 URL: https://issues.apache.org/jira/browse/TUSCANY-1895 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-beta1 Reporter: Florian Pinel UpdateGenerator.getChangedFields() should call a method similar to hasState() (as implemented in InsertGenerator) instead of ref.isMany() when looping thru the change summary settings. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 3rd try: Release Tuscany SCA Java 1.0.1-incubating (RC4)
Raymond Feng wrote: The WSDL is used to access a live StockQuote web service: http://www.xmethods.net/ve2/ViewListing.po?key=uuid:52A2D109-F37A-7DE1-E66B-C477BC8FF764. Unfortunately I cannot find any license information about the WSDL. We need to figure out a better way to handle these situtations (to access a live web service without shipping the WSDL/XSDs locally). Thanks, Raymond Yeah I checked that Web site too and couldn't find its license, that's why I asked. For this release, can we just remove it or replace it with another local WSDL that imports the remote WSDL? What do others think? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Set the default port number for embedded Tomcat/Jetty server?
[snip] Simon Laws wrote: On 11/6/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, The itest-conversations-ws breaks the continuum build as it uses port 8080. I tried to replace the port with 8085 but I realized that it's very annoying to add the explicit URIs to all the binding.ws including the services and callbacks. Should we have a way to customize the default HTTP port number for embedded Tomcat/Jetty server instead of polluting the composite/WSDL files everywhere? I'm thinking of a system property or an intent/policySet. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Raymond We will be able to do it through the node implemenation when we switch over to the new node implementati. The port from the uri of the node is used to dictate what the default port of the servlet container is. Sebastien did a load of changes in this area recently to make it work for his store sample. See here for an example from the launcher program ( http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/node-impl/src/main/java/org/apache/tuscany/sca/node/launch/SCANodeLauncher.java ) In your test case setUp(), do that: SCANodeFactory nodeFactory = SCANodeFactory.newInstance(); // to let the node pick a free port node = nodeFactory.createSCANode(null, null); // or to pick port 8123 yourself node = nodeFactory.createSCANode(http://localhost:8123;, null); The second parameter is the domain URI, I'm assuming that you don't want to deal with a domain in the test case in question, so just pass null. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 3rd try: Release Tuscany SCA Java 1.0.1-incubating (RC4)
Raymond Feng wrote: Hi, I have to fix a few classes to get the wsdl:import working (with some limitations) for remote URLs. I'm not sure if we should rush this into 1.0.1. Should we just remove the WSDL and document how to get it from the internet? Thanks, Raymond +1 to not rush and just remove the WSDL and document how to get it. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 3rd try: Release Tuscany SCA Java 1.0.1-incubating (RC4)
Let me try the wsdl:import to see if it works. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, November 06, 2007 12:54 PM Subject: Re: [VOTE] 3rd try: Release Tuscany SCA Java 1.0.1-incubating (RC4) Raymond Feng wrote: The WSDL is used to access a live StockQuote web service: http://www.xmethods.net/ve2/ViewListing.po?key=uuid:52A2D109-F37A-7DE1-E66B-C477BC8FF764. Unfortunately I cannot find any license information about the WSDL. We need to figure out a better way to handle these situtations (to access a live web service without shipping the WSDL/XSDs locally). Thanks, Raymond Yeah I checked that Web site too and couldn't find its license, that's why I asked. For this release, can we just remove it or replace it with another local WSDL that imports the remote WSDL? What do others think? -- Jean-Sebastien - 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: [VOTE] 3rd try: Release Tuscany SCA Java 1.0.1-incubating (RC4)
Hi, I have to fix a few classes to get the wsdl:import working (with some limitations) for remote URLs. I'm not sure if we should rush this into 1.0.1. Should we just remove the WSDL and document how to get it from the internet? Thanks, Raymond - Original Message - From: Raymond Feng [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, November 06, 2007 1:26 PM Subject: Re: [VOTE] 3rd try: Release Tuscany SCA Java 1.0.1-incubating (RC4) Let me try the wsdl:import to see if it works. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, November 06, 2007 12:54 PM Subject: Re: [VOTE] 3rd try: Release Tuscany SCA Java 1.0.1-incubating (RC4) Raymond Feng wrote: The WSDL is used to access a live StockQuote web service: http://www.xmethods.net/ve2/ViewListing.po?key=uuid:52A2D109-F37A-7DE1-E66B-C477BC8FF764. Unfortunately I cannot find any license information about the WSDL. We need to figure out a better way to handle these situtations (to access a live web service without shipping the WSDL/XSDs locally). Thanks, Raymond Yeah I checked that Web site too and couldn't find its license, that's why I asked. For this release, can we just remove it or replace it with another local WSDL that imports the remote WSDL? What do others think? -- Jean-Sebastien - 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: [VOTE] 3rd try: Release Tuscany SCA Java 1.0.1-incubating (RC4)
[snip] Simon Laws wrote: I just went through the samples that I had problems with before and they look good now. The only issue I have is that helloworld-ws-reference-jms is still in there but that's not a blocker as we can ask people to ignore it. I missed this one, +1 to remove it if we're going to respin a distro. I agree though that the WSDL license issue that's been found does need to be fixed and without an obvious license we'll have to remove it. Shall we fix some of the issues that Mark found at the same time? +1 -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 3rd try: Release Tuscany SCA Java 1.0.1-incubating (RC4)
On 11/6/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Raymond Feng wrote: Hi, I have to fix a few classes to get the wsdl:import working (with some limitations) for remote URLs. I'm not sure if we should rush this into 1.0.1. Should we just remove the WSDL and document how to get it from the internet? Thanks, Raymond +1 to not rush and just remove the WSDL and document how to get it. +1, and if we fix this, we should also fix the SDO license I mentioned before as well. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] DAS samples
1 readmes commit - I will wait and make it along with any other changes in JIRA-1698 as we are still deciding which sample to use to demo the feature of JIRA-1698 2 There are 3 test cases in ConnectionTests, please see if you find some other cases that can be included. 3 Using jboss jars - as these were available on mvn repo, I missed the point of license, if license is the issue, then these can not be used. TC has (default)BasicDataSource - which does not support getConnection(id, pwd) and PerUserPoolDataSource, SharedPoolDataSource - which support getConnection(id, pwd) When trying to configure PerUserPoolDataSource, SharedPoolDataSource with TC 6.0.14, was getting different errors, will see if can get this working. I am not doing any commits related to this JIRA, till 3 or some other sample is formed, so all changes will go together. Regards, Amita On Nov 6, 2007 11:06 PM, Luciano Resende [EMAIL PROTECTED] wrote: Comments inline : On 11/6/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: changes done - 1) cleaned readme files using eclipse IDE html editor - samples, dbconfig Good, Thanks, please committ this, you don't have to wait anymore :) 2) replaced MySQL with Derby Just want to make sure you have all the functionality you need in Derby... 3) replaced sun provided JNDI jars with jboss jar - because - these are available in mvn repos and only 3 are required in the build path (jboss-common 3.2.3, jnp-client 4.0.2 and jnpserver 3.2.3 - total 350 KB) I downloaded the jars, but couldn't find any license files there. Also, JBOSS stuff tend to be LGPL and that is not ASF Friendly, so could you please point me to the proper license for these files ? 4) added more test cases in ConnectionTests.java and removed sample-dataSource 5) patch attached to JIRA-1698 Please see if there are any problems in the above, else I will commit the patch. The bin size increase due to jboss jars is 350 KB and so it may be OK to make it as test cases instead of sample. Well, in summary, it's lots of dependencies issues to demonstrate we now support authentication when retrieving the datasource connection... and based on the dependencies being dragged to DAS distro... I'm now inclined to have just a sample, or simpler, just document in the User Guide. BTW, I'll play with this over the weekend and try to make this working in TC with Companyweb... Maybe this is a simpler solution :) Regards, Amita On 11/5/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: On 11/5/07, Luciano Resende [EMAIL PROTECTED] wrote: I was trying to run the new DAS sample (dataSource) and I looks like it requires MySQL in order to run the sample, this might not be the best default configuration to require, as it requires lots of steps in order to just try the sample ( e.g install MySQL), and it also makes it difficult to test the sample during build. I'd like to suggest two things for our DAS Sample applications : - Use Derby as the default database in a sample application Agree, done changes for this - Have a simple unit test to quickly check if the sample is working (use htmlUnit for webapp) The jira has test cases for case which does not require external JNDI. Which JNDI jar is available as part of maven repo? I could not spot one and used sun's jars. As these can not get downloaded thru mvn build and need to be placed manually in the classpath, used sample instead of junit for testcase which requires JNDI. But if there is a maven repo based jar providing JNDI, the sample can be removed and instead junit cases can be added. Tried RootContext from Geronimo but it is read only. Also, I was wondering what we should use for demonstrating a specific feature... I guess we might not need a new sample for every new feature, this might increase the complexity of developing a new feature, I guess a test case might be good enough and a sample would be used more to demonstrate a bigger scenario or a how a set of features work together... Thoughts ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresendehttp://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - 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]
[jira] Assigned: (TUSCANY-1895) UpdateGenerator.getChangedFields() mistakenly returns exception
[ https://issues.apache.org/jira/browse/TUSCANY-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar reassigned TUSCANY-1895: Assignee: Amita Vadhavkar UpdateGenerator.getChangedFields() mistakenly returns exception --- Key: TUSCANY-1895 URL: https://issues.apache.org/jira/browse/TUSCANY-1895 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-beta1 Reporter: Florian Pinel Assignee: Amita Vadhavkar UpdateGenerator.getChangedFields() should call a method similar to hasState() (as implemented in InsertGenerator) instead of ref.isMany() when looping thru the change summary settings. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1895) UpdateGenerator.getChangedFields() mistakenly returns exception
[ https://issues.apache.org/jira/browse/TUSCANY-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540685 ] Amita Vadhavkar commented on TUSCANY-1895: -- Will you please give here an example setup where you are getting the exception? UpdateGenerator.getChangedFields() mistakenly returns exception --- Key: TUSCANY-1895 URL: https://issues.apache.org/jira/browse/TUSCANY-1895 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-beta1 Reporter: Florian Pinel Assignee: Amita Vadhavkar UpdateGenerator.getChangedFields() should call a method similar to hasState() (as implemented in InsertGenerator) instead of ref.isMany() when looping thru the change summary settings. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with ant on building TuscanyMSVC8DevStudioCCompiler adaptor tool
The jar files are checked in to svn so should not be deleted I guess?? It will be re-built if the java src gets updated. Cheers, On 07/11/2007, Adriano Crestani [EMAIL PROTECTED] wrote: All 3 native projects have a tool called TuscanyMSVC8DevStudioCCompiler that is an adaptor that fixes a bug on cpp-tasks. However, when I try to build it from the source available on tools directory, I get the following error: BUILD FAILED E:\Adriano\cpp\sca\tools\ant_cpptasks\build.xml :24: The following error occurred while executing this line: E:\Adriano\cpp\sca\antscripts\system.xml:592: j ava.lang.ClassNotFoundException: tuscany.antCompilers.TuscanyMSVC8DevStudioCComp iler It occurs because build.xml located on \cpp\sca or sdo or das\antscripts\ imports the system.xml that tries to define the compiler using the TuscanyMSVC8DevStudioCCompiler class: compiler id=msvc8-Compiler extends=Tuscany-BaseCompiler classname=tuscany.antCompilers.TuscanyMSVC8DevStudioCCompiler defineset define=WIN32,_CRT_SECURE_NO_DEPRECATE,_CRT_NON_CONFORMING_SWPRINTFS/ /compiler But, the adaptor is not compiled yet when the system.xml tries to define the compiler. Is there a way to specify that ant should ignore this errors if the TuscanyMSVC8DevStudioCCompiler.jar does not exists? I havent found any : ( PS.: To see this bug, all three TuscanyMSVC8DevStudioCCompiler.jar files located on each project must be deleted. Adriano Crestani -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with ant on building TuscanyMSVC8DevStudioCCompiler adaptor tool
All 3 native projects have a tool called TuscanyMSVC8DevStudioCCompiler that is an adaptor that fixes a bug on cpp-tasks. However, when I try to build it from the source available on tools directory, I get the following error: BUILD FAILED E:\Adriano\cpp\sca\tools\ant_cpptasks\build.xml :24: The following error occurred while executing this line: E:\Adriano\cpp\sca\antscripts\system.xml:592: j ava.lang.ClassNotFoundException: tuscany.antCompilers.TuscanyMSVC8DevStudioCComp iler It occurs because build.xml located on \cpp\sca or sdo or das\antscripts\ imports the system.xml that tries to define the compiler using the TuscanyMSVC8DevStudioCCompiler class: compiler id=msvc8-Compiler extends=Tuscany-BaseCompiler classname=tuscany.antCompilers.TuscanyMSVC8DevStudioCCompiler defineset define=WIN32,_CRT_SECURE_NO_DEPRECATE,_CRT_NON_CONFORMING_SWPRINTFS/ /compiler But, the adaptor is not compiled yet when the system.xml tries to define the compiler. Is there a way to specify that ant should ignore this errors if the TuscanyMSVC8DevStudioCCompiler.jar does not exists? I havent found any : ( PS.: To see this bug, all three TuscanyMSVC8DevStudioCCompiler.jar files located on each project must be deleted. Adriano Crestani
Re: Problem with ant on building TuscanyMSVC8DevStudioCCompiler adaptor tool
I understand, but it's wrong, cause there is a circular dependency. But we may left as it is, cause it will probably be deleted soon when the cpp-tasks bug is fixed. Do you have any news about a fix for this bug Brady? Regards, Adriano Crestani On Nov 7, 2007 3:45 AM, Pete Robbins [EMAIL PROTECTED] wrote: The jar files are checked in to svn so should not be deleted I guess?? It will be re-built if the java src gets updated. Cheers, On 07/11/2007, Adriano Crestani [EMAIL PROTECTED] wrote: All 3 native projects have a tool called TuscanyMSVC8DevStudioCCompiler that is an adaptor that fixes a bug on cpp-tasks. However, when I try to build it from the source available on tools directory, I get the following error: BUILD FAILED E:\Adriano\cpp\sca\tools\ant_cpptasks\build.xml :24: The following error occurred while executing this line: E:\Adriano\cpp\sca\antscripts\system.xml:592: j ava.lang.ClassNotFoundException: tuscany.antCompilers.TuscanyMSVC8DevStudioCComp iler It occurs because build.xml located on \cpp\sca or sdo or das\antscripts\ imports the system.xml that tries to define the compiler using the TuscanyMSVC8DevStudioCCompiler class: compiler id=msvc8-Compiler extends=Tuscany-BaseCompiler classname= tuscany.antCompilers.TuscanyMSVC8DevStudioCCompiler defineset define=WIN32,_CRT_SECURE_NO_DEPRECATE,_CRT_NON_CONFORMING_SWPRINTFS/ /compiler But, the adaptor is not compiled yet when the system.xml tries to define the compiler. Is there a way to specify that ant should ignore this errors if the TuscanyMSVC8DevStudioCCompiler.jar does not exists? I havent found any : ( PS.: To see this bug, all three TuscanyMSVC8DevStudioCCompiler.jar files located on each project must be deleted. Adriano Crestani -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
