Patches and Unit Tests, was Fwd: [jira] Commented: (TUSCANY-952) DAS must support queries that reference tables in different schemas
Thanks Adriano for helping reviewing some of the patches...
I also noticed that there was no unit tests on the patch (at least on the
latest one). I think we should really encourage the submission of unit tests
along with patches that are improvements to existing features or new
features.
-- Forwarded message --
From: Adriano Crestani (JIRA) tuscany-dev@ws.apache.org
Date: Apr 25, 2007 12:32 AM
Subject: [jira] Commented: (TUSCANY-952) DAS must support queries that
reference tables in different schemas
To: tuscany-dev@ws.apache.org
[
https://issues.apache.org/jira/browse/TUSCANY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491540]
Adriano Crestani commented on TUSCANY-952:
--
I don't know if I'm correct, but the condition in the method below shouldn't
be the inverse?
Actually:
public void addConverter(String name, String converter) {
QualifiedColumn column = new QualifiedColumn(name);
Table t = null;
if(this.config.isDatabaseSchemaNameSupported()){
t = findOrCreateTable(column);
}
else{
t = findOrCreateTable(column.getSchemaName(),
column.getTableName());//JIRA-952
}
Column c = findOrCreateColumn(t, column.getColumnName());
c.setConverterClassName(converter);
}
Suggested:
...
if(this.config.isDatabaseSchemaNameSupported()){
t = findOrCreateTable(column.getSchemaName(),
column.getTableName());//JIRA-952
}
else{
t = findOrCreateTable(column);
}
...
(Sorry for the indentation, but it's difficult to indent code on these
comments :s)
Cause there is only schema name if the database schema name is supported.
Adriano Crestani
DAS must support queries that reference tables in different schemas
-
Key: TUSCANY-952
URL: https://issues.apache.org/jira/browse/TUSCANY-952
Project: Tuscany
Issue Type: Bug
Components: Java DAS RDB
Reporter: Kevin Williams
Fix For: Java-DAS-Mx
Attachments: DAS-JIRA-952-Apr24-Amita.txt, JIRA-952-Details.doc,
JIRA-952-Feb16-Amita.jar, JIRA-952-Mar01-Amita.jar
The DAS is curently ignorant of database schema designations. This means
the DAS will generate incorrect write statements when it processes the
change summary from a data graph that originated from a query that uses
schema names that are different from the default schema.
--
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]
--
Luciano Resende
http://people.apache.org/~lresende
Re: Tomcat errors when trying to build the latest trunk
On 4/24/07, Kevin Williams [EMAIL PROTECTED] wrote: Hi Sebastien, The test runs fines from /http-tomcat. --Kevin On 4/24/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Kevin Williams wrote: Now, I am getting the Connection refused error: INFO: Stopping Coyote HTTP/1.1 on http-8586 Apr 24, 2007 12:31:07 PM org.apache.catalina.startup.Embedded start INFO: Starting tomcat server Apr 24, 2007 12:31:07 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.10 Apr 24, 2007 12:31:07 PM org.apache.catalina.startup.ContextConfigdefaultWebCon fig INFO: No default web.xml Apr 24, 2007 12:31:07 PM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-8586 Apr 24, 2007 12:31:07 PM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8586 Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.686sec FA ILURE! testRequestSession(org.apache.tuscany.http.tomcat.TomcatServerTestCase ) Time el apsed: 1.082 sec ERROR! java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:372) at java.net.PlainSocketImpl.connectToAddress( PlainSocketImpl.java :233) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:220) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:378) at java.net.Socket.connect(Socket.java:536) at java.net.Socket.connect(Socket.java:486) at java.net.Socket.init(Socket.java:394) at java.net.Socket.init(Socket.java:207) at org.apache.tuscany.http.tomcat.TomcatServerTestCase.testRequestSessio n(TomcatServerTestCase.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:43) Kevin, This one is interesting as it's an isolated Tomcat test case, not even involving integration with the Web Service binding. I suspect a timing issue, where Tomcat is returning from the start method before it's actually ready to accept requests. I'm going to investigate it but have question: Are you able to reproduce this problem when running mvn from the http-tomcat directory? or are you only running into it when building the whole trunk? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I checked out all of the java changes and my build doesn't work with the switch to the NioProtocol connector in http-tomcat. I get Connection Refused on the third test case, i.e. it seems to work twice and then fails. I backed out to the previous vanilla connection and it gets all the way through the test. Simon
[jira] Updated: (TUSCANY-1112) Incorrect namespaces in generated XML
[
https://issues.apache.org/jira/browse/TUSCANY-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caroline Maynard updated TUSCANY-1112:
--
Component/s: (was: C++ DAS)
C++ SDO
Incorrect namespaces in generated XML
-
Key: TUSCANY-1112
URL: https://issues.apache.org/jira/browse/TUSCANY-1112
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-current
Environment: WinXP
Reporter: Matthew Peters
Please excuse the fact that I have only a PHP testcase for this. The PHP is
however pretty trivial and it seems a simple thing to make in C. Also, I know
that the PHP layer is doing very little to interfere, so this is genuine
Tuscany behaviour.
Here is the bug report from the PHP bug tracking system:
Description:
I have been quite sceptical about the XML that SDO is producing when it
builds a SOAP request, especially w.r.t. the namespaces. So I tried
loading the XML that SDO is producing into Java XERCES with validation
on. There are several problems with the XML generated, I think.
Using the two xsds that are in the reproduce section below, and the
short PHP script also there, SDO generates:
?xml version=1.0 encoding=UTF-8?
BOGUS xmlns=http://Component; xmlns:tns=http://Component;
xmlns:tns2=http://www.test.com/info;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:type=add
person
tns2:name
firstWill/first
lastShakespeare/last
/tns2:name
/person
/BOGUS
There are three (!) things wrong with this.
1. XERCES will not accept the xsi:type=add. I do not really know why.
I assume this is because there is no type called add, it's only an
element. So I do not think this should be coming out.
2. name should not be in tns2=http://www.test.com/info, neither should
first and last be in the default namespace of http://Component. The
person.xsd has no elementFormDefault, so the elements below person
should all ne in the no name namespace.
3.You have to change the person.xsd to see the third thing: put
ElementNameDefault=qualified in
the person schema, then name, first and last should all now be
coming out in the http://www.test.com/info namespace, but it makes no
difference to the generated XML.
Reproduce code:
---
?php
$xmldas = SDO_DAS_XML::create('types.xsd');
$person =
$xmldas-createDataObject('http://www.test.com/info','personType');
$name = $person-createDataObject('name');
$name-first = Will;
$name-last = Shakespeare;
$add = $xmldas-createDataObject('http://Component','add');
$add-person = $person;
$xdoc = $xmldas-createDocument('', 'BOGUS', $add);
$xmlstr = $xmldas-saveString($xdoc, 2);
echo $xmlstr;
?
types.xsd:
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns:ns0=http://www.test.com/info;
targetNamespace=http://Component;
elementNameDefault=qualified
xs:import schemaLocation=person.xsd
namespace=http://www.test.com/info/
xs:element name=add
xs:complexType
xs:sequence
xs:element name=person type=ns0:personType
nillable=true/
/xs:sequence
/xs:complexType
/xs:element
/xs:schema
person.xsd:
?xml version=1.0 encoding=UTF-8?
schema xmlns=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://www.test.com/info;
xmlns:info=http://www.test.com/info;
complexType name=nameType
sequence
element name=first type=string/element
element name=last type=string/element
/sequence
/complexType
complexType name=personType
sequence
element name=name type=info:nameType/element
/sequence
/complexType
/schema
Expected result:
see above
Actual result:
--
see above
[2007-01-31 12:21 UTC] mfp at php dot net
I just came across what I think is another example of this. Now I
understand better how namespaces work, I suspect it is more common than
we realise.
Here's the example in a nutshell:
Catalog.xsd defines a catalog element in the catalogNS namespace, which
contains items defined in a different namespace in a different file,
Order.xsd:
schema xmlns=http://www.w3.org/2001/XMLSchema;
xmlns:cat=catalogNS xmlns:ord=orderNS targetNamespace=catalogNS
include schemaLocation=Order.xsd/
element name=catalog type=cat:CatalogType/
complexType name=CatalogType
sequence
element maxOccurs=unbounded ref=ord:item/
/sequence
/complexType
/schema
Order.xsd defines the item element as being in the OrderNS namespace:
.../...
schema xmlns=http://www.w3.org/2001/XMLSchema;
xmlns:ord=orderNS xmlns:cust=customerNS targetNamespace=orderNS
[jira] Updated: (TUSCANY-1231) Various incorrect namespaces in generated XML
[
https://issues.apache.org/jira/browse/TUSCANY-1231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caroline Maynard updated TUSCANY-1231:
--
Component/s: (was: C++ DAS)
C++ SDO
Various incorrect namespaces in generated XML
-
Key: TUSCANY-1231
URL: https://issues.apache.org/jira/browse/TUSCANY-1231
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-M3
Environment: WinXP
Reporter: Matthew Peters
Given the following two xsds, which define an add element in http://Component
and a PersonType in http://www.test.com/info...
?php
$xmldas = SDO_DAS_XML::create('types.xsd');
$person =
$xmldas-createDataObject('http://www.test.com/info','personType');
$name = $person-createDataObject('name');
$name-first = Will;
$name-last = Shakespeare;
$add = $xmldas-createDataObject('http://Component','add');
$add-person = $person;
$xdoc = $xmldas-createDocument('', 'BOGUS', $add);
$xmlstr = $xmldas-saveString($xdoc, 2);
echo $xmlstr;
?
types.xsd:
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns:ns0=http://www.test.com/info;
targetNamespace=http://Component;
elementNameDefault=qualified
xs:import schemaLocation=person.xsd
namespace=http://www.test.com/info/
xs:element name=add
xs:complexType
xs:sequence
xs:element name=person type=ns0:personType
nillable=true/
/xs:sequence
/xs:complexType
/xs:element
/xs:schema
person.xsd:
?xml version=1.0 encoding=UTF-8?
schema xmlns=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://www.test.com/info;
xmlns:info=http://www.test.com/info;
complexType name=nameType
sequence
element name=first type=string/element
element name=last type=string/element
/sequence
/complexType
complexType name=personType
sequence
element name=name type=info:nameType/element
/sequence
/complexType
/schema
... if you now create a document with an 'add' element, create a PersonType
object and assign meaningful first and last names, and serialise to XML, you
get:
?xml version=1.0 encoding=UTF-8?
add xmlns=http://Component; xmlns:tns=http://Component;
xmlns:tns2=http://www.test.com/info;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
person
tns2:name
firstWill/first
lastShakespeare/last
/tns2:name
/person
/add
There are several things wrong with this XML.
1. name should not be in tns2=http://www.test.com/info, and neither should
first and last be in the default namespace of http://Component. The
person.xsd has no elementFormDefault, so the elements below person should
all be in the no name namespace.
2.You have to change the person.xsd to see the next thing: put
ElementNameDefault=qualified in
the person schema, then name, first and last should all now be
coming out in the http://www.test.com/info namespace, but it makes no
difference to the generated XML.
--
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] Closed: (TUSCANY-1231) Various incorrect namespaces in generated XML
[
https://issues.apache.org/jira/browse/TUSCANY-1231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthew Peters closed TUSCANY-1231.
---
Resolution: Duplicate
Raised in error - I had mislaid the earlier TUSCANY-1112
Various incorrect namespaces in generated XML
-
Key: TUSCANY-1231
URL: https://issues.apache.org/jira/browse/TUSCANY-1231
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-M3
Environment: WinXP
Reporter: Matthew Peters
Given the following two xsds, which define an add element in http://Component
and a PersonType in http://www.test.com/info...
?php
$xmldas = SDO_DAS_XML::create('types.xsd');
$person =
$xmldas-createDataObject('http://www.test.com/info','personType');
$name = $person-createDataObject('name');
$name-first = Will;
$name-last = Shakespeare;
$add = $xmldas-createDataObject('http://Component','add');
$add-person = $person;
$xdoc = $xmldas-createDocument('', 'BOGUS', $add);
$xmlstr = $xmldas-saveString($xdoc, 2);
echo $xmlstr;
?
types.xsd:
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns:ns0=http://www.test.com/info;
targetNamespace=http://Component;
elementNameDefault=qualified
xs:import schemaLocation=person.xsd
namespace=http://www.test.com/info/
xs:element name=add
xs:complexType
xs:sequence
xs:element name=person type=ns0:personType
nillable=true/
/xs:sequence
/xs:complexType
/xs:element
/xs:schema
person.xsd:
?xml version=1.0 encoding=UTF-8?
schema xmlns=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://www.test.com/info;
xmlns:info=http://www.test.com/info;
complexType name=nameType
sequence
element name=first type=string/element
element name=last type=string/element
/sequence
/complexType
complexType name=personType
sequence
element name=name type=info:nameType/element
/sequence
/complexType
/schema
... if you now create a document with an 'add' element, create a PersonType
object and assign meaningful first and last names, and serialise to XML, you
get:
?xml version=1.0 encoding=UTF-8?
add xmlns=http://Component; xmlns:tns=http://Component;
xmlns:tns2=http://www.test.com/info;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
person
tns2:name
firstWill/first
lastShakespeare/last
/tns2:name
/person
/add
There are several things wrong with this XML.
1. name should not be in tns2=http://www.test.com/info, and neither should
first and last be in the default namespace of http://Component. The
person.xsd has no elementFormDefault, so the elements below person should
all be in the no name namespace.
2.You have to change the person.xsd to see the next thing: put
ElementNameDefault=qualified in
the person schema, then name, first and last should all now be
coming out in the http://www.test.com/info namespace, but it makes no
difference to the generated XML.
--
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-1171) SDO Java M3 Release
[ https://issues.apache.org/jira/browse/TUSCANY-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491575 ] Kelvin Goodson commented on TUSCANY-1171: - In the move to a beta1 version i created a 1.0-incubating-beta1 tag, changed the pom versions and ported TUSCANY-1211 to the tag, omitting to reference this JIRA in the commit SDO Java M3 Release --- Key: TUSCANY-1171 URL: https://issues.apache.org/jira/browse/TUSCANY-1171 Project: Tuscany Issue Type: Task Components: Java SDO Implementation, Java SDO Samples, Java SDO Tools Reporter: Kelvin Goodson Assigned To: Kelvin Goodson Fix For: Java-SDO-M3 Attachments: buildSDORelease.bat, rat_exceptions.txt, rat_report.zip, rat_report.zip -- 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-1211) SDO 2.1 feature: On-the-fly creation of open content properties
[ https://issues.apache.org/jira/browse/TUSCANY-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1211: Fix Version/s: Java-SDO-beta1 SDO 2.1 feature: On-the-fly creation of open content properties --- Key: TUSCANY-1211 URL: https://issues.apache.org/jira/browse/TUSCANY-1211 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Reporter: Frank Budinsky Fix For: Java-SDO-beta1 -- 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-1216) Sequence.add(index,value) is not working due to a type mismatch problem
[
https://issues.apache.org/jira/browse/TUSCANY-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson updated TUSCANY-1216:
Affects Version/s: (was: Java-SDO-beta1)
Java-SDO-M2
Sequence.add(index,value) is not working due to a type mismatch problem
---
Key: TUSCANY-1216
URL: https://issues.apache.org/jira/browse/TUSCANY-1216
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-M2
Environment: n/a
Reporter: David T. Adcox
Fix For: Java-SDO-beta1
The sample below demonstrates a problem found when adding properties into a
sequence object using the property index. The issue seems to be related to
how the property index is acquired and how that index is subsequently used by
the BasicSequence object. BasicSequence.add(int, Object) uses the EMF
eClass().getEstructuralFeature(int) method to retrieve the property, based on
the index. The list of properties kept in this array, includes both
'explicit' properties defined by the schema or inline code, and 'implicit'
properties defined by the Tuscany SDO framework (in this case, I believe it
is actually the underlying EMF that is creating the implicit property). Once
such implicit property is the 'multi' property, defined when a type is
identified as containing a sequence. The core issue here is that the code
used to identify the index to use is based on an array of SDO properties,
which do not include the implicit properties. So, the index is derived from
a different array than the one being used for updating, this is the root
cause of this problem. A change to how the BasicSequence object obtains the
indexed property is probably the correct remedy for this issue.
Sample code:
public static void main(String[] args)
{
String URI = http://example.com/test;;
HelperContext scope = SDOUtil.createHelperContext();
TypeHelper typeHelper = scope.getTypeHelper();
Type integerType = typeHelper.getType(commonj.sdo, Integer);
DataObject wrapperType = scope.getDataFactory().create(commonj.sdo,
Type);
wrapperType.set(uri, URI );
wrapperType.set(name, Wrapper);
wrapperType.setBoolean(sequenced, true);
// Create Property
DataObject intProperty = wrapperType.createDataObject(property);
intProperty.set(name, Value);
intProperty.set(type, integerType);
intProperty.setBoolean(many, true);
// register the wrapper
typeHelper.define(wrapperType);
// get registered type
Type testType = typeHelper.getType(URI,Wrapper);
// Create an instance of the Wrapper Type
DataObject testDO = scope.getDataFactory().create(testType);
// Update the sequence using the index
List properties = testType.getProperties();
int index = properties.indexOf(testDO.getInstanceProperty(Value));
Sequence sequence = testDO.getSequence();
Integer v = new Integer(10);
sequence.add(index,v);
}
--
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-826) Containment cycle should result in Exception
[ https://issues.apache.org/jira/browse/TUSCANY-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-826: --- Fix Version/s: (was: Java-SDO-Mx) Java-SDO-beta1 Affects Version/s: (was: Java-SDO-Mx) Java-SDO-M2 Containment cycle should result in Exception Key: TUSCANY-826 URL: https://issues.apache.org/jira/browse/TUSCANY-826 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-M2 Environment: Windows XP, both Sun and IBM JVMs Reporter: Brian Murray Fix For: Java-SDO-beta1 Attachments: 826.patch, 826.zip, ContainmentCycle.patch, ContainmentCycleError.java, ContainmentTest.zip, Updated826.zip, Updated826.zip, Updated826.zip Near the bottom of page 19 in the 2.0.1 specification it is stated that Containment cannot have cycles. If a set or add would create a containment cycle an exception is thrown. However, I have found that no such exception is thrown. I will attach a test case showing the creation of (and the potential to infinitely loop through) a containment cycle. -- 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-1232) XSDSimpleTypeTest (New CTS Test)
XSDSimpleTypeTest (New CTS Test) Key: TUSCANY-1232 URL: https://issues.apache.org/jira/browse/TUSCANY-1232 Project: Tuscany Issue Type: Test Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: XSDSimpleTypeTest.zip This test case checks for spec-compliance when creating SDO types derived from simple XSD types. The attached ZIP file contains the new test (XSDSimpleTypeTest.java) and the required XSD files. The ZIP file should be expanded in cts\sdo2.1\src. NOTE: the test will need to be added manually to the UnderReviewTestSuite or CTSGeneralSuite. All tests pass against Tuscany SDO apart from testDerived and testDerived2, which are currently excluded using the junit @Ignore annotation. -- 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-1232) XSDSimpleTypeTest (New CTS Test)
[ https://issues.apache.org/jira/browse/TUSCANY-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1232: Attachment: XSDSimpleTypeTest.zip ZIP file as described above. XSDSimpleTypeTest (New CTS Test) Key: TUSCANY-1232 URL: https://issues.apache.org/jira/browse/TUSCANY-1232 Project: Tuscany Issue Type: Test Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: XSDSimpleTypeTest.zip This test case checks for spec-compliance when creating SDO types derived from simple XSD types. The attached ZIP file contains the new test (XSDSimpleTypeTest.java) and the required XSD files. The ZIP file should be expanded in cts\sdo2.1\src. NOTE: the test will need to be added manually to the UnderReviewTestSuite or CTSGeneralSuite. All tests pass against Tuscany SDO apart from testDerived and testDerived2, which are currently excluded using the junit @Ignore annotation. -- 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: Tomcat errors when trying to build the latest trunk
Simon Laws wrote: On 4/24/07, Kevin Williams [EMAIL PROTECTED] wrote: Hi Sebastien, The test runs fines from /http-tomcat. --Kevin On 4/24/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Kevin Williams wrote: Now, I am getting the Connection refused error: INFO: Stopping Coyote HTTP/1.1 on http-8586 Apr 24, 2007 12:31:07 PM org.apache.catalina.startup.Embedded start INFO: Starting tomcat server Apr 24, 2007 12:31:07 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.10 Apr 24, 2007 12:31:07 PM org.apache.catalina.startup.ContextConfigdefaultWebCon fig INFO: No default web.xml Apr 24, 2007 12:31:07 PM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-8586 Apr 24, 2007 12:31:07 PM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8586 Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.686sec FA ILURE! testRequestSession(org.apache.tuscany.http.tomcat.TomcatServerTestCase ) Time el apsed: 1.082 sec ERROR! java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:372) at java.net.PlainSocketImpl.connectToAddress( PlainSocketImpl.java :233) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:220) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:378) at java.net.Socket.connect(Socket.java:536) at java.net.Socket.connect(Socket.java:486) at java.net.Socket.init(Socket.java:394) at java.net.Socket.init(Socket.java:207) at org.apache.tuscany.http.tomcat.TomcatServerTestCase.testRequestSessio n(TomcatServerTestCase.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:43) Kevin, This one is interesting as it's an isolated Tomcat test case, not even involving integration with the Web Service binding. I suspect a timing issue, where Tomcat is returning from the start method before it's actually ready to accept requests. I'm going to investigate it but have question: Are you able to reproduce this problem when running mvn from the http-tomcat directory? or are you only running into it when building the whole trunk? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I checked out all of the java changes and my build doesn't work with the switch to the NioProtocol connector in http-tomcat. I get Connection Refused on the third test case, i.e. it seems to work twice and then fails. I backed out to the previous vanilla connection and it gets all the way through the test. Simon Simon, could you please try revision r532289? The following changes: http://svn.apache.org/viewvc?view=revrevision=532289 should help with these problems. With these changes, I am able to build on both Linux and Windows. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat errors when trying to build the latest trunk
On 4/25/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 4/24/07, Kevin Williams [EMAIL PROTECTED] wrote: Hi Sebastien, The test runs fines from /http-tomcat. --Kevin On 4/24/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Kevin Williams wrote: Now, I am getting the Connection refused error: INFO: Stopping Coyote HTTP/1.1 on http-8586 Apr 24, 2007 12:31:07 PM org.apache.catalina.startup.Embedded start INFO: Starting tomcat server Apr 24, 2007 12:31:07 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.10 Apr 24, 2007 12:31:07 PM org.apache.catalina.startup.ContextConfigdefaultWebCon fig INFO: No default web.xml Apr 24, 2007 12:31:07 PM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-8586 Apr 24, 2007 12:31:07 PM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8586 Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.686sec FA ILURE! testRequestSession(org.apache.tuscany.http.tomcat.TomcatServerTestCase ) Time el apsed: 1.082 sec ERROR! java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:372) at java.net.PlainSocketImpl.connectToAddress( PlainSocketImpl.java :233) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java :220) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java :378) at java.net.Socket.connect(Socket.java:536) at java.net.Socket.connect(Socket.java:486) at java.net.Socket.init(Socket.java:394) at java.net.Socket.init(Socket.java:207) at org.apache.tuscany.http.tomcat.TomcatServerTestCase.testRequestSessio n(TomcatServerTestCase.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:43) Kevin, This one is interesting as it's an isolated Tomcat test case, not even involving integration with the Web Service binding. I suspect a timing issue, where Tomcat is returning from the start method before it's actually ready to accept requests. I'm going to investigate it but have question: Are you able to reproduce this problem when running mvn from the http-tomcat directory? or are you only running into it when building the whole trunk? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I checked out all of the java changes and my build doesn't work with the switch to the NioProtocol connector in http-tomcat. I get Connection Refused on the third test case, i.e. it seems to work twice and then fails. I backed out to the previous vanilla connection and it gets all the way through the test. Simon Simon, could you please try revision r532289? The following changes: http://svn.apache.org/viewvc?view=revrevision=532289 should help with these problems. With these changes, I am able to build on both Linux and Windows. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks Jean_Sebastien, will do. I also have a fix for lockup problems we've been seeing in the wsdl and databinding itests I'll check it in when I've tested against these latest change of yours. Regards Simon
Re: Tomcat errors when trying to build the latest trunk
On 4/25/07, Simon Laws [EMAIL PROTECTED] wrote: On 4/25/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 4/24/07, Kevin Williams [EMAIL PROTECTED] wrote: Hi Sebastien, The test runs fines from /http-tomcat. --Kevin On 4/24/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Kevin Williams wrote: Now, I am getting the Connection refused error: INFO: Stopping Coyote HTTP/1.1 on http-8586 Apr 24, 2007 12:31:07 PM org.apache.catalina.startup.Embeddedstart INFO: Starting tomcat server Apr 24, 2007 12:31:07 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.10 Apr 24, 2007 12:31:07 PM org.apache.catalina.startup.ContextConfigdefaultWebCon fig INFO: No default web.xml Apr 24, 2007 12:31:07 PM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-8586 Apr 24, 2007 12:31:07 PM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8586 Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.686sec FA ILURE! testRequestSession( org.apache.tuscany.http.tomcat.TomcatServerTestCase ) Time el apsed: 1.082 sec ERROR! java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java :372) at java.net.PlainSocketImpl.connectToAddress( PlainSocketImpl.java :233) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:220) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java :378) at java.net.Socket.connect(Socket.java:536) at java.net.Socket.connect (Socket.java:486) at java.net.Socket.init(Socket.java:394) at java.net.Socket.init(Socket.java:207) at org.apache.tuscany.http.tomcat.TomcatServerTestCase.testRequestSessio n(TomcatServerTestCase.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:43) Kevin, This one is interesting as it's an isolated Tomcat test case, not even involving integration with the Web Service binding. I suspect a timing issue, where Tomcat is returning from the start method before it's actually ready to accept requests. I'm going to investigate it but have question: Are you able to reproduce this problem when running mvn from the http-tomcat directory? or are you only running into it when building the whole trunk? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I checked out all of the java changes and my build doesn't work with the switch to the NioProtocol connector in http-tomcat. I get Connection Refused on the third test case, i.e. it seems to work twice and then fails. I backed out to the previous vanilla connection and it gets all the way through the test. Simon Simon, could you please try revision r532289? The following changes: http://svn.apache.org/viewvc?view=revrevision=532289 should help with these problems. With these changes, I am able to build on both Linux and Windows. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks Jean_Sebastien, will do. I also have a fix for lockup problems we've been seeing in the wsdl and databinding itests I'll check it in when I've tested against these latest change of yours. Regards Simon OK, I'm at r532305. I did a mvn clean and deleted sca from my local maven repository and I still get the exception I was seeing before with the NioProtocol piece in place. 25-Apr-2007 11:44:30 org.apache.coyote.http11.Http11NioProtocol init INFO: Initializing Coyote HTTP/1.1 on http-8586 25-Apr-2007 11:44:30 org.apache.coyote.http11.Http11NioProtocol start INFO: Starting Coyote HTTP/1.1 on http-8586 25-Apr-2007 11:44:32 org.apache.coyote.http11.Http11NioProtocol destroy INFO: Stopping Coyote HTTP/1.1 on http-8586 25-Apr-2007 11:44:32 org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.10 25-Apr-2007 11:44:32 org.apache.catalina.startup.ContextConfigdefaultWebConfig INFO: No default web.xml 25-Apr-2007 11:44:32 org.apache.coyote.http11.Http11NioProtocol init INFO: Initializing Coyote HTTP/1.1 on http-8586 25-Apr-2007 11:44:32 org.apache.coyote.http11.Http11NioProtocol start INFO:
Re: Tomcat errors when trying to build the latest trunk
On 4/25/07, Simon Laws [EMAIL PROTECTED] wrote: On 4/25/07, Simon Laws [EMAIL PROTECTED] wrote: On 4/25/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 4/24/07, Kevin Williams [EMAIL PROTECTED] wrote: Hi Sebastien, The test runs fines from /http-tomcat. --Kevin On 4/24/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Kevin Williams wrote: Now, I am getting the Connection refused error: INFO: Stopping Coyote HTTP/1.1 on http-8586 Apr 24, 2007 12:31:07 PM org.apache.catalina.startup.Embeddedstart INFO: Starting tomcat server Apr 24, 2007 12:31:07 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.10 Apr 24, 2007 12:31:07 PM org.apache.catalina.startup.ContextConfigdefaultWebCon fig INFO: No default web.xml Apr 24, 2007 12:31:07 PM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-8586 Apr 24, 2007 12:31:07 PM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8586 Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.686sec FA ILURE! testRequestSession( org.apache.tuscany.http.tomcat.TomcatServerTestCase ) Time el apsed: 1.082 sec ERROR! java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java :372) at java.net.PlainSocketImpl.connectToAddress( PlainSocketImpl.java :233) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java :220) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java :378) at java.net.Socket.connect(Socket.java:536) at java.net.Socket.connect (Socket.java:486) at java.net.Socket.init(Socket.java:394) at java.net.Socket.init(Socket.java:207) at org.apache.tuscany.http.tomcat.TomcatServerTestCase.testRequestSessio n(TomcatServerTestCase.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:43) Kevin, This one is interesting as it's an isolated Tomcat test case, not even involving integration with the Web Service binding. I suspect a timing issue, where Tomcat is returning from the start method before it's actually ready to accept requests. I'm going to investigate it but have question: Are you able to reproduce this problem when running mvn from the http-tomcat directory? or are you only running into it when building the whole trunk? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I checked out all of the java changes and my build doesn't work with the switch to the NioProtocol connector in http-tomcat. I get Connection Refused on the third test case, i.e. it seems to work twice and then fails. I backed out to the previous vanilla connection and it gets all the way through the test. Simon Simon, could you please try revision r532289? The following changes: http://svn.apache.org/viewvc?view=revrevision=532289 should help with these problems. With these changes, I am able to build on both Linux and Windows. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks Jean_Sebastien, will do. I also have a fix for lockup problems we've been seeing in the wsdl and databinding itests I'll check it in when I've tested against these latest change of yours. Regards Simon OK, I'm at r532305. I did a mvn clean and deleted sca from my local maven repository and I still get the exception I was seeing before with the NioProtocol piece in place. 25-Apr-2007 11:44:30 org.apache.coyote.http11.Http11NioProtocol init INFO: Initializing Coyote HTTP/1.1 on http-8586 25-Apr-2007 11:44:30 org.apache.coyote.http11.Http11NioProtocol start INFO: Starting Coyote HTTP/1.1 on http-8586 25-Apr-2007 11:44:32 org.apache.coyote.http11.Http11NioProtocol destroy INFO: Stopping Coyote HTTP/1.1 on http-8586 25-Apr-2007 11:44:32 org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.10 25-Apr-2007 11:44:32 org.apache.catalina.startup.ContextConfigdefaultWebConfig INFO: No default web.xml 25-Apr-2007
[jira] Resolved: (TUSCANY-625) [SDO for C++] XSDHelperImpl::defineFile is unhelpful when schemaLocation is omitted from an import
[ https://issues.apache.org/jira/browse/TUSCANY-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard resolved TUSCANY-625. -- Resolution: Fixed At some point a second (boolean) parameter was added to defineFile to control this behaviour. Works for me. [SDO for C++] XSDHelperImpl::defineFile is unhelpful when schemaLocation is omitted from an import -- Key: TUSCANY-625 URL: https://issues.apache.org/jira/browse/TUSCANY-625 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-M1 Reporter: Caroline Maynard Assigned To: Pete Robbins Priority: Minor Fix For: Cpp-M3 A PHP user is trying to work with a service defined by http://api.urbandictionary.com/soap However XSDHelperImpl::defineFile() fails with an SDOTypeNotFoundException: 'Type not found :http://schemas.xmlsoap.org/soap/encoding/ Array' I think this is because the required type is defined via an import: xsd:import namespace=http://schemas.xmlsoap.org/soap/encoding/; / which omits the schemaLocation. Arguably the wsdl in question is a bit defective, and the problem can be bypassed by hand-editing the wsdl to add the schemaLocation attribute. But Tuscany could be a bit more helpful, and try to use the namespace URI when schemaLocation is omitted. -- 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] Closed: (TUSCANY-625) [SDO for C++] XSDHelperImpl::defineFile is unhelpful when schemaLocation is omitted from an import
[ https://issues.apache.org/jira/browse/TUSCANY-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard closed TUSCANY-625. [SDO for C++] XSDHelperImpl::defineFile is unhelpful when schemaLocation is omitted from an import -- Key: TUSCANY-625 URL: https://issues.apache.org/jira/browse/TUSCANY-625 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-M1 Reporter: Caroline Maynard Assigned To: Pete Robbins Priority: Minor Fix For: Cpp-M3 A PHP user is trying to work with a service defined by http://api.urbandictionary.com/soap However XSDHelperImpl::defineFile() fails with an SDOTypeNotFoundException: 'Type not found :http://schemas.xmlsoap.org/soap/encoding/ Array' I think this is because the required type is defined via an import: xsd:import namespace=http://schemas.xmlsoap.org/soap/encoding/; / which omits the schemaLocation. Arguably the wsdl in question is a bit defective, and the problem can be bypassed by hand-editing the wsdl to add the schemaLocation attribute. But Tuscany could be a bit more helpful, and try to use the namespace URI when schemaLocation is omitted. -- 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]
How can I process this XML with Tuscany?
This is partly a Tuscany implementation question, and partly a CTS / specification question. I have the following XML document and there is no XSD defined. root xmlns=http://test/;name lang=en_USAdam/name/root If I use XMLHelper to load the document and then run this code ... Property nameProp = root.getInstanceProperty( name ); Object name = root.get( nameProp ); I get an org.eclipse.emf.ecore.util.FeatureMapUtil$FeatureEList object returned, which does not appear to implement any SDO interfaces. Does Tuscany provide a way to get the simple content of the name element as well as the lang attribute? From reading the 2.1 specification, my understanding is that name should be a DataObject with a lang property representing the attribute and a special value property representing the simple content. Will Tuscany be supporting this 2.1 feature? Thanks, Andy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Databinding itest locking up?
On 4/24/07, Simon Laws [EMAIL PROTECTED] wrote: Following Sebastiens post about the databinding test locking up (he went ahead and removed it from the itest pom to get the build to work) I tried the test and, once I had changed the poms to depend on http-jetty as they used to, I got the same effect of the test hanging. The process is sitting with port 8080 in the CLOSE_WAIT state which basically means that the client hasn't closed the socket correctly. I went in and commented out the line // requestMC.getOptions().setProperty( HTTPConstants.REUSE_HTTP_CLIENT, Boolean.TRUE); In Axis2TargetInvoker.invokeTarget which was instigated by TUSCANY-1218 [1] and it worked again. Now Sebastien did point out a fault/feature of the itest. The way the databinding itests work as checked in is that they only create one runtime for all the tests that are run. However it neglects to call SCARuntime.stop() at the end. I have put this change into my local copy and it still locks up when using REUSE_HTTP_CLIENT. Anyone else seeing this kind of behaviour. All of the basic web services tests work on my box and I don't see that the SDO databinding itest (the test I'm trying at the moment) is doing anything different. Also did the databinding itests run ok after the TUSCANY-1218 change was applied. We could be dealing with some combination of the effect of that change and the changes since then. I should note that, in the past, I have not experienced the connection refused error that originated 1218. Is there some kind of system setting that's being toggled off again by the code change (just a stab in the dark)? Simon [1] http://issues.apache.org/jira/browse/TUSCANY-1218 After more investigation I find that the SDO Databinding itest locks up on the third call (3 seems to be the magic number with these networking problems) to an operation from within a single JUnit test method. So this lock up is not to do with the way that the runtime is stopped. As I mention above I find that I don't get the problem if REUSE_HTTP_CLIENT is not set. The problem happens the third time the MultiThreadedHttpConnectionManager goes to get a connection from the connection pool. So I'm assuming that the connection in question is still marked as being in use in some way. I put a workround in the code on my machine. In Axis2TargetInvoker.invokeTarget I changed the code as follows (line 78); operationClient.execute(true); MessageContext responseMC = operationClient.getMessageContext( WSDLConstants.MESSAGE_LABEL_IN_VALUE); +operationClient.complete(requestMC); Now I'm not exactly sure what effect the call to complete has in the case where we are trying to REUSE_HTTP_CLIENT. It maybe that it kills the connection and hence the connection can't be resused. I'd be interested to know if others who were seeing the original connection Refused error that TUSCAY-1218 was targetting see it come back. I didn't see them in the fisrt place so it's difficult for me to say. If no one objects I'll check this in later. [1] http://issues.apache.org/jira/browse/TUSCANY-1218
[jira] Commented: (TUSCANY-952) DAS must support queries that reference tables in different schemas
[ https://issues.apache.org/jira/browse/TUSCANY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491618 ] Amita Vadhavkar commented on TUSCANY-952: - 1)For the first issue regarding QualifiedColumn constructor:- QualifiedColumn(String name, boolean isDatabaseSchemaNameSupported), below is the explaination:- In QualifiesColumn - what is expected in name parameter is tableName.columnName - at the least. When multiple schema support is ON, the name parameter is expected to have schemaName.tableName.columnName. So in both the cases tableName.columnName is the minimum requirement. Thus invoking the constructor like QualifiedColumn(table, false) does not follow the minimum requirement, because irrespective of multi-schema support, at least one '.' needs to be there in 'name'. With this the current logic in the code looks OK, if it throws RuntimeException for new QualifiedColumn(table, false) 2) For second issue regarding MappingWrapper.addRelationship(Vector, Vector) - work-in-progress 3) addConverter(String name, String converter) - the existing code will as such work correct, as findOrCreateTable(column) is using QualifiedColumn which has schemaName information as a member variable. Still, will clean code and will add more comments. 4) As mentioned during last patch submission, work-in-progress for a J2SE test client having the test cases mentioned in the documentation. It will be there in the next patch along with issue resolution for 2) and 3). The unit test cases are not added to the rdb core test suite as, the current unit tests' db , table creation - does not support the multi-schema condition, and instead of scattering many new tables,scema, classes in the unit tests, same test cases will be shown using a separate J2SE test client sample. For unit testing, this sample can be modified and tested. DAS must support queries that reference tables in different schemas - Key: TUSCANY-952 URL: https://issues.apache.org/jira/browse/TUSCANY-952 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Reporter: Kevin Williams Fix For: Java-DAS-Mx Attachments: DAS-JIRA-952-Apr24-Amita.txt, JIRA-952-Details.doc, JIRA-952-Feb16-Amita.jar, JIRA-952-Mar01-Amita.jar The DAS is curently ignorant of database schema designations. This means the DAS will generate incorrect write statements when it processes the change summary from a data graph that originated from a query that uses schema names that are different from the default schema. -- 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: Next release name? (was: Re: [DISCUSS] Next version - What should be in it)
On 4/24/07, Simon Nash [EMAIL PROTECTED] wrote: snip/ So I think it comes down to whether it is more important to put something out by JavaOne (in which case I'd be hesitant to call it beta) or whether it is more important to attain a true beta level of quality even if that takes a little bit longer. I guess a lot comes down to everyones slightly different perceptions as to what the name beta implies, what do others think about this? Should we: 1) continue aiming for a beta1 release around JavaOne timeframe 2) continue with a beta1 release but take a bit more time 3) aim for a release around JavaOne timeframe but change to a non-beta release name, alpha-x or maybe a numeric like 0.90? I probably favor (2) as looking at things people have said they'd like to get done it seems unlikely to me we'll be ready by JavaOne anyway. ...ant
Re: Next release name? (was: Re: [DISCUSS] Next version - What should be in it)
I've got to the point where I have packaged up a new beta1 SDO java release candidate in the style if the last one [1], but that's only part of the process now that I have to set up a remote maven repository as a staging post for the deployed release candidate artifacts (as per the recent discussion on incubator general). I'm just about to figure out how to create/configure the repo, but any tips on the process for making the maven repo are welcome; I'll post back my findings. [1] http://people.apache.org/~kelvingoodson/sdo_java/beta1/RC1/ Kelvin. On 24/04/07, kelvin goodson [EMAIL PROTECTED] wrote: Ant, your note is well timed as I've had a couple of off-line chats with people in the last week about release naming, particularly with regard to the effect that a milestone or alpha name can have on uptake of a release. In the IRC chat of 16th April [1] we reached a conclusion that given the fact that a new release candidate had just been posted for consideration, we would leave naming as it was. However, I got the impression that in general the community was giving me an implicit +0 vote to retaining the M3 release tag, but the ideal would be to move to a beta1 tag. At the time there was a handful of small SDO 2.1 spec features for which we didn't have a first cut implementation. Now this has reduced to just a couple, and it seemed that there was consensus from the discussion that a beta* tag was not incompatible with this state, so long as the omissions were documented. The SDO RC3 has been available for a little while for comment, but has not received much attention. I have a couple of small non-blocking issues with the candidate that I have spotted that I would like to tidy up. So I propose that I quickly cut a new 1.0-incubating-beta1 tag from the M3 tag, make my small fixes (including adopting the incubating name convention over the previous incubator convention) post a new candidate and start a vote on that candidate. I'd like to do this ASAP and I don't think this is contentious, but I guess I need to give a little time for reaction before proceeding, as my actions would not be in accordance with the outcome community discussions; I propose to do this at start of UK business tomorrow. Kelvin [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16772.html On 24/04/07, ant elder [EMAIL PROTECTED] wrote: What are we going to be calling this next SCA release? We've had M1 and M2 releases, some alpha kernel releases, DAS are talking about an M3 release and SDO is doing an M3 release although there was some discussion about renaming that to beta1. I think milestone and alpha release names may discourage people from trying a release as it makes it sound unstable. The spec defined SCA APIs are stable now and we're talking about making stable SPIs for this next release, so the Tuscany externals are becoming stable and that sounds better than alpha quality to me. So how about the next Tuscany SCA release is named beta1? and we could try to get DAS and SDO to also follow that naming? Any comments or alternative name suggestions? ...ant
Re: How can I process this XML with Tuscany?
Hi Andy, In Tuscany, I believe it currently works like this: The root object is an open, sequenced, mixed type. The name property is type String (I believe) but it isMany=true, that's why you get a List ( org.eclipse.emf.ecore.util.FeatureMapUtil$FeatureEList) back from get(). You should be able to get the name by calling: String name = (String)root.getList(name).get(0); The simple content would appear as mixed text: String textContent = root.getSequence().getValue(0); I'm not sure if this is quite right according to the spec. I'm not sure that the value property is the the right approach in this case, since we would need to parse the entire document to be sure that all instances have simple content. The Tuscany approach works the same in the more general case like this: root xmlns=http://test/; name lang=en_USAdam/name name lang=en_USAdamjunkabcjunkSmith/name /root Frank. Andy Grove [EMAIL PROTECTED] wrote on 04/25/2007 07:06:13 AM: This is partly a Tuscany implementation question, and partly a CTS / specification question. I have the following XML document and there is no XSD defined. root xmlns=http://test/;name lang=en_USAdam/name/root If I use XMLHelper to load the document and then run this code ... Property nameProp = root.getInstanceProperty( name ); Object name = root.get( nameProp ); I get an org.eclipse.emf.ecore.util.FeatureMapUtil$FeatureEList object returned, which does not appear to implement any SDO interfaces. Does Tuscany provide a way to get the simple content of the name element as well as the lang attribute? From reading the 2.1 specification, my understanding is that name should be a DataObject with a lang property representing the attribute and a special value property representing the simple content. Will Tuscany be supporting this 2.1 feature? Thanks, Andy. - 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]
SDO static codegen needs to support multiple namespaces in a single pass
The SDO static codegen tool (XSD2Java) is currently only able to process a single namespace per invocation. This limitation is problematic when the target schema contains multiple namespaces or includes other schemas with namespaces that are different from the target schema. The user of the tool is forced to invoke the tool multiple times, once for each namespace referenced. More troubling is the case where the javapackage option is used. In that case, the java package information is changed from the default naming scheme. This change will break any generated classes that point to the name-modified package. So, I'd like to suggest that we modify the SDO static codegen tool to handle multiple namespaces in a single pass. If possible, could we open a JIRA to address this work? Thanks, David
Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)
Hi, As a user and a consumer of Tuscany that has had to debug problems, I have a couple of comments. Raymond Feng wrote: It seems to me that we could use the EventManagement in the core to handle these in the event/listener pattern. If possible, I would like to see Tuscany focus on the higher level event model for component management, on enhancing the exception formatter framework for diagnostics, and improving the wiring, contribution, and assembly validation in a way that would surface errors and an error context to extensions that could be implemented by a consumer. I was referring to the fact that the apsectj-based tracing can be enabled or disabled simply by turning on/off the JVM agent. The annotation-based aspect doesn't require a compiler for the aspectj and it's not invasive. On using aspects for trace, I'm not a huge fan of performing any weaving at runtime during class loading nor in requiring consumers to install an instrumentation agent to turn on trace emission. Not only does dynamic instrumentation lengthen the class load time and effect the benefits of class sharing (in JVM's that support the technology), it assumes that the user has installed the agent because a problem is expected. If aspect weaving is used, I believe it should be an optional part of the build environment and not force fit into the instrumentation agent infrastructure. Thanks. -- Matthew Sykes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How can I process this XML with Tuscany?
Thanks Frank. So the simple/mixed content is accessed via the Sequence
API rather than by a special property. This makes sense to me now.
Here's a test case that passes against Tuscany for the example XML. This
actually seems to be spec-compliant. Would you agree? If so, I'll file a
JIRA to get this added to the CTS.
public void testComplexElementWithSimpleContent() {
String xml = root xmlns=\http://test/\;name
lang=\en_US\Adam/name/root;
XMLDocument doc = XMLHelper.INSTANCE.load( xml );
DataObject root = doc.getRootObject();
Property nameProperty = root.getProperty( name );
assertEquals( commonj.sdo, nameProperty.getType().getURI() );
assertEquals( DataObject, nameProperty.getType().getName() );
DataObject dobj = root.getDataObject( name.0 );
assertEquals( en_US, dobj.getString( lang ) );
assertEquals( Adam, dobj.getSequence().getValue(0) );
}
Thanks,
Andy.
-Original Message-
From: Frank Budinsky [mailto:[EMAIL PROTECTED]
Sent: 25 April 2007 15:00
To: tuscany-dev@ws.apache.org
Subject: Re: How can I process this XML with Tuscany?
Hi Andy,
In Tuscany, I believe it currently works like this:
The root object is an open, sequenced, mixed type. The name property is
type String (I believe) but it isMany=true, that's why you get a List (
org.eclipse.emf.ecore.util.FeatureMapUtil$FeatureEList) back from get().
You should be able to get the name by calling:
String name = (String)root.getList(name).get(0);
The simple content would appear as mixed text:
String textContent = root.getSequence().getValue(0);
I'm not sure if this is quite right according to the spec.
I'm not sure that the value property is the the right approach in this
case, since we would need to parse the entire document to be sure that
all instances have simple content. The Tuscany approach works the same
in the more general case like this:
root xmlns=http://test/;
name lang=en_USAdam/name
name lang=en_USAdamjunkabcjunkSmith/name
/root
Frank.
Andy Grove [EMAIL PROTECTED] wrote on 04/25/2007 07:06:13 AM:
This is partly a Tuscany implementation question, and partly a CTS /
specification question.
I have the following XML document and there is no XSD defined.
root xmlns=http://test/;name lang=en_USAdam/name/root
If I use XMLHelper to load the document and then run this code ...
Property nameProp = root.getInstanceProperty( name );
Object name = root.get( nameProp );
I get an org.eclipse.emf.ecore.util.FeatureMapUtil$FeatureEList
object returned, which does not appear to implement any SDO
interfaces.
Does Tuscany provide a way to get the simple content of the name
element as well as the lang attribute?
From reading the 2.1 specification, my understanding is that name
should be a DataObject with a lang property representing the
attribute and a special value property representing the simple
content. Will Tuscany be supporting this 2.1 feature?
Thanks,
Andy.
-
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: Next release name? (was: Re: [DISCUSS] Next version - What should be in it)
Ant, thanks for the pointers here. I am persisting with this, but I thought I'd just post an update as this doesn't seem to be working as it should. I have two main problems, one is when attempting to deploy the SDO tools jar by command -- see [1], the maven command removes the pom i'm trying to deploy in mid flow. The other is deploying the standalone pom corresponding to the SDO reactor build. There is guidance at [2] but neither way described there seems to work, for the straight file deploy route i get [3] I'll keep plugging on, but if anyone has any insights they are very welcome Kelvin [1] C:\Documents and Settings\ibm_user\.m2\repository\org\apache\tuscany\sdo\tuscany-sdo-tools\1.0-incubating-beta1ls tuscany-sdo-tools-1.0-incubating-beta1.jar tuscany-sdo-tools-1.0-incubating-beta1.pom C:\Documents and Settings\ibm_user\.m2\repository\org\apache\tuscany\sdo\tuscany-sdo-tools\1.0-incubating-beta1mvn deploy:de ploy-file -DrepositoryId=people.apache.org-Durl=scp://people.apache.org/home/kelvingoodson/public_html/repo -DgeneratePom=fa lse -DpomFile=tuscany-sdo-tools-1.0-incubating-beta1.pom -Dfile= tuscany-sdo-tools-1.0-incubating-beta1.jar -DgeneratePom=fals e -DgroupId=org.apache.tuscany.sdo -DartifactId=tuscany-sdo-tools -Dversion= 1.0-incubating-beta1 [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'deploy'. [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [deploy:deploy-file] (aggregator-style) [INFO] [INFO] [deploy:deploy-file] Password:: Uploading: scp://people.apache.org/home/kelvingoodson/public_html/repo/org/apache/tuscany/sdo/tuscany-sdo-tools/1.0-incubatin g-beta1/tuscany-sdo-tools-1.0-incubating-beta1.jar 108K uploaded [INFO] Retrieving previous metadata from people.apache.org Password:: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error installing artifact's metadata: Error installing metadata: Error copying POM to the local repository. File C:\Documents and Settings\ibm_user\.m2\repository\org\apache\tuscany\sdo\tuscany-sdo-tools\1.0-incubating-beta1\tuscany- sdo-tools-1.0-incubating-beta1.pom does not exist [2] http://docs.codehaus.org/display/MAVENUSER/Deploy+Plugin [3] C:\tempmvn deploy:deploy-file -DgroupId=org.apache.tuscany.sdo-DartifactId=tuscany-sdo -Dversion= 1.0-incubating-beta1 -Dpac kaging=pom -Dfile=tuscany-sdo-1.0-incubating-beta1.pom-Durl=scp://people.apache.org/home/kelvingoodson/public_html/repo -Dre positoryId=people.apache.org -DgeneratePom=false [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'deploy'. [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [deploy:deploy-file] (aggregator-style) [INFO] [INFO] [deploy:deploy-file] Password:: Uploading: scp://people.apache.org/home/kelvingoodson/public_html/repo/org/apache/tuscany/sdo/tuscany-sdo/1.0-incubating-beta 1/tuscany-sdo-1.0-incubating-beta1.pom 6K uploaded [INFO] Retrieving previous metadata from people.apache.org Password:: [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:795) at org.apache.maven.project.artifact.ProjectArtifactMetadata.storeInLocalRepository (ProjectArtifactMetadata.java:92) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.deploy (DefaultRepositoryMetadataMan ager.java:428) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy (DefaultArtifactDeployer.java:86) at org.apache.maven.plugin.deploy.DeployFileMojo.execute( DeployFileMojo.java:236) at org.apache.maven.plugin.DefaultPluginManager.executeMojo( DefaultPluginManager.java:420) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals( DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal( DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal( DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures (DefaultLifecycleExecutor.java:311 ) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(
RE: How can I process this XML with Tuscany?
Yes Andy, I agree it's compliant although I think that the spec does also
alow an implementation to optimize the handling of this. But, I'm not so
sure that's such a great idea and if it should be accomodated in the CTS.
For now, I'm fine with checking in the new test, below.
Thanks,
Frank.
Andy Grove [EMAIL PROTECTED] wrote on 04/25/2007 11:39:56 AM:
Thanks Frank. So the simple/mixed content is accessed via the Sequence
API rather than by a special property. This makes sense to me now.
Here's a test case that passes against Tuscany for the example XML. This
actually seems to be spec-compliant. Would you agree? If so, I'll file a
JIRA to get this added to the CTS.
public void testComplexElementWithSimpleContent() {
String xml = root xmlns=\http://test/\;name
lang=\en_US\Adam/name/root;
XMLDocument doc = XMLHelper.INSTANCE.load( xml );
DataObject root = doc.getRootObject();
Property nameProperty = root.getProperty( name );
assertEquals( commonj.sdo, nameProperty.getType().getURI() );
assertEquals( DataObject, nameProperty.getType().getName() );
DataObject dobj = root.getDataObject( name.0 );
assertEquals( en_US, dobj.getString( lang ) );
assertEquals( Adam, dobj.getSequence().getValue(0) );
}
Thanks,
Andy.
-Original Message-
From: Frank Budinsky [mailto:[EMAIL PROTECTED]
Sent: 25 April 2007 15:00
To: tuscany-dev@ws.apache.org
Subject: Re: How can I process this XML with Tuscany?
Hi Andy,
In Tuscany, I believe it currently works like this:
The root object is an open, sequenced, mixed type. The name property is
type String (I believe) but it isMany=true, that's why you get a List (
org.eclipse.emf.ecore.util.FeatureMapUtil$FeatureEList) back from get().
You should be able to get the name by calling:
String name = (String)root.getList(name).get(0);
The simple content would appear as mixed text:
String textContent = root.getSequence().getValue(0);
I'm not sure if this is quite right according to the spec.
I'm not sure that the value property is the the right approach in this
case, since we would need to parse the entire document to be sure that
all instances have simple content. The Tuscany approach works the same
in the more general case like this:
root xmlns=http://test/;
name lang=en_USAdam/name
name lang=en_USAdamjunkabcjunkSmith/name
/root
Frank.
Andy Grove [EMAIL PROTECTED] wrote on 04/25/2007 07:06:13 AM:
This is partly a Tuscany implementation question, and partly a CTS /
specification question.
I have the following XML document and there is no XSD defined.
root xmlns=http://test/;name lang=en_USAdam/name/root
If I use XMLHelper to load the document and then run this code ...
Property nameProp = root.getInstanceProperty( name );
Object name = root.get( nameProp );
I get an org.eclipse.emf.ecore.util.FeatureMapUtil$FeatureEList
object returned, which does not appear to implement any SDO
interfaces.
Does Tuscany provide a way to get the simple content of the name
element as well as the lang attribute?
From reading the 2.1 specification, my understanding is that name
should be a DataObject with a lang property representing the
attribute and a special value property representing the simple
content. Will Tuscany be supporting this 2.1 feature?
Thanks,
Andy.
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat errors when trying to build the latest trunk
ant elder wrote: On 4/25/07, Simon Laws [EMAIL PROTECTED] wrote: On 4/25/07, Simon Laws [EMAIL PROTECTED] wrote: On 4/25/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 4/24/07, Kevin Williams [EMAIL PROTECTED] wrote: Hi Sebastien, The test runs fines from /http-tomcat. --Kevin On 4/24/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Kevin Williams wrote: Now, I am getting the Connection refused error: INFO: Stopping Coyote HTTP/1.1 on http-8586 Apr 24, 2007 12:31:07 PM org.apache.catalina.startup.Embeddedstart INFO: Starting tomcat server Apr 24, 2007 12:31:07 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.10 Apr 24, 2007 12:31:07 PM org.apache.catalina.startup.ContextConfigdefaultWebCon fig INFO: No default web.xml Apr 24, 2007 12:31:07 PM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-8586 Apr 24, 2007 12:31:07 PM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8586 Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.686sec FA ILURE! testRequestSession( org.apache.tuscany.http.tomcat.TomcatServerTestCase ) Time el apsed: 1.082 sec ERROR! java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java :372) at java.net.PlainSocketImpl.connectToAddress( PlainSocketImpl.java :233) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java :220) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java :378) at java.net.Socket.connect(Socket.java:536) at java.net.Socket.connect (Socket.java:486) at java.net.Socket.init(Socket.java:394) at java.net.Socket.init(Socket.java:207) at org.apache.tuscany.http.tomcat.TomcatServerTestCase.testRequestSessio n(TomcatServerTestCase.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:43) Kevin, This one is interesting as it's an isolated Tomcat test case, not even involving integration with the Web Service binding. I suspect a timing issue, where Tomcat is returning from the start method before it's actually ready to accept requests. I'm going to investigate it but have question: Are you able to reproduce this problem when running mvn from the http-tomcat directory? or are you only running into it when building the whole trunk? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I checked out all of the java changes and my build doesn't work with the switch to the NioProtocol connector in http-tomcat. I get Connection Refused on the third test case, i.e. it seems to work twice and then fails. I backed out to the previous vanilla connection and it gets all the way through the test. Simon Simon, could you please try revision r532289? The following changes: http://svn.apache.org/viewvc?view=revrevision=532289 should help with these problems. With these changes, I am able to build on both Linux and Windows. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks Jean_Sebastien, will do. I also have a fix for lockup problems we've been seeing in the wsdl and databinding itests I'll check it in when I've tested against these latest change of yours. Regards Simon OK, I'm at r532305. I did a mvn clean and deleted sca from my local maven repository and I still get the exception I was seeing before with the NioProtocol piece in place. 25-Apr-2007 11:44:30 org.apache.coyote.http11.Http11NioProtocol init INFO: Initializing Coyote HTTP/1.1 on http-8586 25-Apr-2007 11:44:30 org.apache.coyote.http11.Http11NioProtocol start INFO: Starting Coyote HTTP/1.1 on http-8586 25-Apr-2007 11:44:32 org.apache.coyote.http11.Http11NioProtocol destroy INFO: Stopping Coyote HTTP/1.1 on http-8586 25-Apr-2007 11:44:32 org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.10 25-Apr-2007 11:44:32 org.apache.catalina.startup.ContextConfigdefaultWebConfig
Re: Build runtime wire/invocation chains for a composite hierarchy
Hi, Continueing on this path, I propose the following way to attach runtime context to the model so that the model can be used to drive the runtime behaviors. 1) How is a runtime context is attached to the model? Let's assume the interface for the runtime context is MyContext, then the model implementation can provide such a context in two ways: a) Implement MyContext interface directly, then the model object is an instance of MyContext and it can be cast to MyContext by the runtime. There is one thing not so nice is that we cannot have multiple inheritance and we can either use the base class for the model or the context, but not both. b) Implement a getter method to return MyContext, and the runtime can access it using reflection or a provider interface. This approach can take advantage of runtime context inheritance as MyContext is embedded. 2) How to build the invocation chain? Let's assume we have the wiring like this: ComponentA.reference1 w/ binding1 --- ComponentB.service1 w/ binding1 For the reference side, the invocation chain will look like: Binding interceptor for reference1 over binding1 -- (binding protocol layer) For the service side, the invocation chain will look like: (binding protocol layer)...--Binding interceptor for service1 over binding1-- Implementation interceptor for ComponentB If the binding is SCABinding, then for local interface or co-located remotable interface, the reference side can connect to the service side directly as: Binding interceptor for reference1 over binding1 --Binding interceptor for service1 over binding1-- Implementation interceptor for ComponentB 3) The interfaces for runtime context: Please see the bottom of the wiki page at http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Runtime+Component+Hierarchy. Thanks, Raymond - Original Message - From: Raymond Feng [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, April 24, 2007 11:58 AM Subject: Build runtime wire/invocation chains for a composite hierarchy Hi, I'm trying to indentify all the paths of SCA component interactions which require to have runtime wires/invocation chains. By the SCA spec, there are three cases for the wiring: 1) Component.Reference (A.ref1) --is wired to-- Component.Service (B.svc1) -- 1.1) If both the service and reference are defined by non-composite components, then the runtime wire is as simple as A.ref1--B.svc1. 1.2) If the service is defined on a composite component, then it can be further resolved to the orginal atomic component service following the service promotion chain. For example, A.ref1 -- B.svc1 (B is implemented by another composite and B.svc1 promotes C.svc1), then the runtime wire will be: A.ref1 -- C.svc1 1.3) If the reference is defined on a composite component, then it can be further resolved to the orginal atomic component reference following the reference promotion chain. For example, A.ref1 -- B.svc1 (A is implemented by another composite and A.ref1 promotes C.ref1), then the runtime wire will be: C.ref1 -- B.svc1 2) Composite.Reference (Composite1.ref1) --promotes-- Component.Reference (B.ref1) - If Composite1 is the top-level composite, and the B is a non-composite component, then the runtime wire will be: B.ref1 -- Composite1.ref1 If Composite1 is used to implement a component A in Composite2, then we need to futher check if A.ref1 is promoted or wired until we hit the end of the promotion chain. The final target will be either a composite reference or a component service that the out-most reference is wired to. For example, if A.ref1 is wired to D.svc1 in Composite2, then the runtime wire is B.ref1 -- D.svc1. If A.ref1 is promoted by Composite2.ref1, then the runtime wire is B.ref1 -- Composite2.ref1. If B is a composite component, then we need to find out the final component reference that B.ref1 promotes. For example, it promotes D.ref1, then the runtime wire is D.ref1 -- C.ref1 3) Composite.Service (Composite1.svc1) --promotes-- Component.Service (A.svc1) --- The source will be the outmost service on the promotion chain. For example, if Composite2.svc1 promotes B.svc1 and B is implemented by Composite1, then it is Composite2.svc1. The target will be the innermost service on the promotion chain. For example, if A is implemented by Composite3 and Composite3.svc1 promotes C.svc1, then it is C.svc1. * Please note, due to the spec limitation, the composite service cannot promote a composite reference directly. Based on the above scenarios, it seems that we can create runtime wires using the following algorithm (assuming
Re: Setting up a Tuscany runtime to run multiple applications
On 4/24/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: You'll need one instance of ArtifactResolver per application as well. Is the ArtifactResolver eventually intended to resolve artifacts within a single contribution (application) only or across contributions in the domain? The comments at the top of the interface make me think it is the latter. If instead it is the case that it resolves artifacts within a single contribution only, it isn't clear to me how to set this up since there seems to be a 1:1 relationship between the ContributionService and the ArtifactResolver. I'm also wondering about the code in DeployerImpl.deploy that connects objects. It starts as follows: // Connect components, services and references ListSCAObject scaObjects = componentManager.getSCAObjects(); Since there is one deployer, and the deployer has one component manager, this says to me that every time a composite is deployed, all registered SCA objects are going to be connected. If multiple contributions are deployed is that what should happen? Greg Dritschler
Re: Tomcat errors when trying to build the latest trunk
On 4/25/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 4/25/07, Simon Laws [EMAIL PROTECTED] wrote: On 4/25/07, Simon Laws [EMAIL PROTECTED] wrote: On 4/25/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 4/24/07, Kevin Williams [EMAIL PROTECTED] wrote: Hi Sebastien, The test runs fines from /http-tomcat. --Kevin On 4/24/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Kevin Williams wrote: Now, I am getting the Connection refused error: INFO: Stopping Coyote HTTP/1.1 on http-8586 Apr 24, 2007 12:31:07 PM org.apache.catalina.startup.Embeddedstart INFO: Starting tomcat server Apr 24, 2007 12:31:07 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.10 Apr 24, 2007 12:31:07 PM org.apache.catalina.startup.ContextConfigdefaultWebCon fig INFO: No default web.xml Apr 24, 2007 12:31:07 PM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-8586 Apr 24, 2007 12:31:07 PM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8586 Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.686sec FA ILURE! testRequestSession( org.apache.tuscany.http.tomcat.TomcatServerTestCase ) Time el apsed: 1.082 sec ERROR! java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java :372) at java.net.PlainSocketImpl.connectToAddress( PlainSocketImpl.java :233) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java :220) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java :378) at java.net.Socket.connect(Socket.java:536) at java.net.Socket.connect (Socket.java:486) at java.net.Socket.init(Socket.java:394) at java.net.Socket.init(Socket.java:207) at org.apache.tuscany.http.tomcat.TomcatServerTestCase.testRequestSessio n(TomcatServerTestCase.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:43) Kevin, This one is interesting as it's an isolated Tomcat test case, not even involving integration with the Web Service binding. I suspect a timing issue, where Tomcat is returning from the start method before it's actually ready to accept requests. I'm going to investigate it but have question: Are you able to reproduce this problem when running mvn from the http-tomcat directory? or are you only running into it when building the whole trunk? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I checked out all of the java changes and my build doesn't work with the switch to the NioProtocol connector in http-tomcat. I get Connection Refused on the third test case, i.e. it seems to work twice and then fails. I backed out to the previous vanilla connection and it gets all the way through the test. Simon Simon, could you please try revision r532289? The following changes: http://svn.apache.org/viewvc?view=revrevision=532289 should help with these problems. With these changes, I am able to build on both Linux and Windows. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks Jean_Sebastien, will do. I also have a fix for lockup problems we've been seeing in the wsdl and databinding itests I'll check it in when I've tested against these latest change of yours. Regards Simon OK, I'm at r532305. I did a mvn clean and deleted sca from my local maven repository and I still get the exception I was seeing before with the NioProtocol piece in place. 25-Apr-2007 11:44:30 org.apache.coyote.http11.Http11NioProtocol init INFO: Initializing Coyote HTTP/1.1 on http-8586 25-Apr-2007 11:44:30 org.apache.coyote.http11.Http11NioProtocol start INFO: Starting Coyote HTTP/1.1 on http-8586 25-Apr-2007 11:44:32 org.apache.coyote.http11.Http11NioProtocol destroy INFO: Stopping Coyote HTTP/1.1 on
Geronimo/Tuscany integration
Hi, Geronimo community. As you may know, Tuscany is an Apache project under incubation to provide an open source SOA infrastructure. For more information, you can visit http://cwiki.apache.org/TUSCANY/. Tuscany implements the SCA specification (http://www.osoa.org) and allows you to develop and run SCA components in various hosting environments. We currently integrate with Tomcat and Jetty and would like to try to integrate with Geronimo as well. I would like to start some discussions here to figure out the best way to do that. After some preliminary investigations of Geronimo, I feel that there are two options on the table so far. 1) Shallow integration: Package SCA applications together with the Tuscany runtime as WARs and deploy them Geronimo as Web applications. It's basically the integration with a Web container. We register a TuscanyContextListner (which implements javax.servlet.ServletContextListener) in web.xml to start/stop the Tuscany runtime when the web application is started/stopped. This will allow us to support the following use cases: * A Web application hosted by Geronimo with business logic written as SCA components * Expose one or more SCA components as Web services over HTTP as supported by the Web container. 2) Deep integration: We package the Tuscany runtime and its dependencies as Geronimo modules and deploy them to Geronimo (which is similar to how Tomcat is integrated as the Web container for Geronimo). We can then create a Tuscany plugin (a collection of modules) so that it can be added to Geronimo. The Tuscany container will then handle SCA-specific deployment plans to install SCA applications and provide runtime infrastructure for them. On top of Option 2, we could further integrate Geronimo's J2EE capabilities such as EJB, WS, JMS and JCA with Tuscany. Basically, SCA components will be able to access JEE services (using SCA composite references) and SCA components will be able to expose services (SCA composite services) over JEE protocols as well. This will allow us to support the following use cases: * Any J2EE application hosted by Geronimo would be able to take advantage of SCA programming model * Provide SCA services over various protocols such as RMI/IIOP, JMS and JCA * Invoke existing JEE applications (EJB, JMS backend, JCA-based EIS or Web Services) from SCA components Any thoughts? Thanks, Raymond Apache Tuscany committer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat errors when trying to build the latest trunk
I am now building cleanly with 532452. Thanks! On 4/25/07, Simon Laws [EMAIL PROTECTED] wrote: On 4/25/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 4/25/07, Simon Laws [EMAIL PROTECTED] wrote: On 4/25/07, Simon Laws [EMAIL PROTECTED] wrote: On 4/25/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 4/24/07, Kevin Williams [EMAIL PROTECTED] wrote: Hi Sebastien, The test runs fines from /http-tomcat. --Kevin On 4/24/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Kevin Williams wrote: Now, I am getting the Connection refused error: INFO: Stopping Coyote HTTP/1.1 on http-8586 Apr 24, 2007 12:31:07 PM org.apache.catalina.startup.Embeddedstart INFO: Starting tomcat server Apr 24, 2007 12:31:07 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.10 Apr 24, 2007 12:31:07 PM org.apache.catalina.startup.ContextConfigdefaultWebCon fig INFO: No default web.xml Apr 24, 2007 12:31:07 PM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-8586 Apr 24, 2007 12:31:07 PM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8586 Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.686sec FA ILURE! testRequestSession( org.apache.tuscany.http.tomcat.TomcatServerTestCase ) Time el apsed: 1.082 sec ERROR! java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java :372) at java.net.PlainSocketImpl.connectToAddress( PlainSocketImpl.java :233) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java :220) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java :378) at java.net.Socket.connect(Socket.java:536) at java.net.Socket.connect (Socket.java:486) at java.net.Socket.init(Socket.java:394) at java.net.Socket.init(Socket.java:207) at org.apache.tuscany.http.tomcat.TomcatServerTestCase.testRequestSessio n(TomcatServerTestCase.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:43) Kevin, This one is interesting as it's an isolated Tomcat test case, not even involving integration with the Web Service binding. I suspect a timing issue, where Tomcat is returning from the start method before it's actually ready to accept requests. I'm going to investigate it but have question: Are you able to reproduce this problem when running mvn from the http-tomcat directory? or are you only running into it when building the whole trunk? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I checked out all of the java changes and my build doesn't work with the switch to the NioProtocol connector in http-tomcat. I get Connection Refused on the third test case, i.e. it seems to work twice and then fails. I backed out to the previous vanilla connection and it gets all the way through the test. Simon Simon, could you please try revision r532289? The following changes: http://svn.apache.org/viewvc?view=revrevision=532289 should help with these problems. With these changes, I am able to build on both Linux and Windows. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks Jean_Sebastien, will do. I also have a fix for lockup problems we've been seeing in the wsdl and databinding itests I'll check it in when I've tested against these latest change of yours. Regards Simon OK, I'm at r532305. I did a mvn clean and deleted sca from my local maven repository and I still get the exception I was seeing before with the NioProtocol piece in place. 25-Apr-2007 11:44:30 org.apache.coyote.http11.Http11NioProtocol init INFO:
Re: Next release name? (was: Re: [DISCUSS] Next version - What should be in it)
A working release that is closer to 1.0 spec version sooner would be better than having more content and a later release. M2 is old now and has issues. Should IRC be used for a discussion on release or maybe we should update the Wiki page with (IN/Out) comment to help you? If an item has both IN and OUT, discussion can resolve it. Would it help if we put our name next to the idea that each of us are driving? I sign up for wiki and driving the documentation layout and some of the content like user guide. On 4/25/07, ant elder [EMAIL PROTECTED] wrote: On 4/25/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 4/24/07, Simon Nash [EMAIL PROTECTED] wrote: snip/ So I think it comes down to whether it is more important to put something out by JavaOne (in which case I'd be hesitant to call it beta) or whether it is more important to attain a true beta level of quality even if that takes a little bit longer. I guess a lot comes down to everyones slightly different perceptions as to what the name beta implies, what do others think about this? Should we: 1) continue aiming for a beta1 release around JavaOne timeframe 2) continue with a beta1 release but take a bit more time 3) aim for a release around JavaOne timeframe but change to a non-beta release name, alpha-x or maybe a numeric like 0.90? I probably favor (2) as looking at things people have said they'd like to get done it seems unlikely to me we'll be ready by JavaOne anyway. ...ant I think it would be good to Release early, release often :) and have a release around JavaOne for people to try our SCA 1.0 APIs and assembly support as well as our new SPIs, and after that have more frequent releases than we did in in the past, like a release every two months maybe, with smaller increments each time. I'm for a variation of your option (3)... refine the contents of the release first, then decide to call it alpha/beta/gamma/whatever based on what we've been able to put in that release. Thoughts? I've started a wiki page to track the next release contents: http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents . Very rough to start with - I've just tried to note all the things that have been suggested on the mailing list that we should put in the next release (sorry if i've missed something, please just add it). JavaOne is just 8 working days away so to make a release by then, or even just a release candidate, there is a lot to do if we want to finish everything on that wiki page. What is the absolute minimum we should include? What are must do's for you before I can tag or branch SVN for the release? What on that list do you think we could leave out? ...ant
[jira] Created: (TUSCANY-1233) Enhance SDO static codegen (XSD2Java) to support multiple namespaces in a single pass.
Enhance SDO static codegen (XSD2Java) to support multiple namespaces in a single pass. -- Key: TUSCANY-1233 URL: https://issues.apache.org/jira/browse/TUSCANY-1233 Project: Tuscany Issue Type: Improvement Components: Java SDO Tools Affects Versions: Java-SDO-M2 Environment: n/a Reporter: David T. Adcox Priority: Minor Fix For: Java-SDO-beta1 The SDO static codegen tool (XSD2Java) is currently only able to process a single namespace per invocation. This limitation is problematic when the target schema contains multiple namespaces or includes other schemas with namespaces that are different from the target schema. The user of the tool is forced to invoke the tool multiple times, once for each namespace referenced. More troubling is the case where the javapackage option is used. In that case, the java package information is changed from the default naming scheme. This change will break any generated classes that point to the name-modified package. Supporting this feature would include items such as these listed below: - Support the processing of multiple namespaces via a command-line option (this behavior should not be the default) - Provide support for multiple namespaces within a single schema or WSDL - Support processing of multiple namespaces imported by the target schema or WSDL. - Allow for all namespaces to be discovered through interrogation of the target and its dependencies. - Allow for user input to determine all namespaces to be processed (enhanced schemaNamespace option). - Provide support for javaPackage to namespace mapping. In effect, enhance the current javaPackage option to allow for multiple package-namespace pairs. - Provide support for prefix to namespace mapping. Again, much like the previous item, enhance the current prefix option to support multiple prefix-namespace pairs. -- 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: Build runtime wire/invocation chains for a composite hierarchy
This sounds like something I'm interested in, but I'm really struggling to understand what you're talking about in these two emails. What does attach runtime context to the model so that the model can be used to drive the runtime behaviors mean? What is MyContext? Could you describe this relating it to the existing classes and say which of those you want to change? ...ant On 4/25/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Continueing on this path, I propose the following way to attach runtime context to the model so that the model can be used to drive the runtime behaviors. 1) How is a runtime context is attached to the model? Let's assume the interface for the runtime context is MyContext, then the model implementation can provide such a context in two ways: a) Implement MyContext interface directly, then the model object is an instance of MyContext and it can be cast to MyContext by the runtime. There is one thing not so nice is that we cannot have multiple inheritance and we can either use the base class for the model or the context, but not both. b) Implement a getter method to return MyContext, and the runtime can access it using reflection or a provider interface. This approach can take advantage of runtime context inheritance as MyContext is embedded. 2) How to build the invocation chain? Let's assume we have the wiring like this: ComponentA.reference1 w/ binding1 --- ComponentB.service1 w/ binding1 For the reference side, the invocation chain will look like: Binding interceptor for reference1 over binding1 -- (binding protocol layer) For the service side, the invocation chain will look like: (binding protocol layer)...--Binding interceptor for service1 over binding1-- Implementation interceptor for ComponentB If the binding is SCABinding, then for local interface or co-located remotable interface, the reference side can connect to the service side directly as: Binding interceptor for reference1 over binding1 --Binding interceptor for service1 over binding1-- Implementation interceptor for ComponentB 3) The interfaces for runtime context: Please see the bottom of the wiki page at http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Runtime+Component+Hierarchy . Thanks, Raymond - Original Message - From: Raymond Feng [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, April 24, 2007 11:58 AM Subject: Build runtime wire/invocation chains for a composite hierarchy Hi, I'm trying to indentify all the paths of SCA component interactions which require to have runtime wires/invocation chains. By the SCA spec, there are three cases for the wiring: 1) Component.Reference (A.ref1) --is wired to-- Component.Service (B.svc1) -- 1.1) If both the service and reference are defined by non-composite components, then the runtime wire is as simple as A.ref1--B.svc1. 1.2) If the service is defined on a composite component, then it can be further resolved to the orginal atomic component service following the service promotion chain. For example, A.ref1 -- B.svc1 (B is implemented by another composite and B.svc1 promotes C.svc1), then the runtime wire will be: A.ref1 -- C.svc1 1.3) If the reference is defined on a composite component, then it can be further resolved to the orginal atomic component reference following the reference promotion chain. For example, A.ref1 -- B.svc1 (A is implemented by another composite and A.ref1 promotes C.ref1), then the runtime wire will be: C.ref1 -- B.svc1 2) Composite.Reference (Composite1.ref1) --promotes-- Component.Reference (B.ref1) - If Composite1 is the top-level composite, and the B is a non-composite component, then the runtime wire will be: B.ref1 -- Composite1.ref1 If Composite1 is used to implement a component A in Composite2, then we need to futher check if A.ref1 is promoted or wired until we hit the end of the promotion chain. The final target will be either a composite reference or a component service that the out-most reference is wired to. For example, if A.ref1 is wired to D.svc1 in Composite2, then the runtime wire is B.ref1 -- D.svc1. If A.ref1 is promoted by Composite2.ref1, then the runtime wire is B.ref1 -- Composite2.ref1. If B is a composite component, then we need to find out the final component reference that B.ref1 promotes. For example, it promotes D.ref1, then the runtime wire is D.ref1 -- C.ref1 3) Composite.Service (Composite1.svc1) --promotes-- Component.Service (A.svc1) --- The source will be the outmost service on the promotion chain. For example, if Composite2.svc1 promotes B.svc1 and B is implemented by Composite1, then it is
Re: Build runtime wire/invocation chains for a composite hierarchy
Raymond Feng wrote: Hi, I'm trying to indentify all the paths of SCA component interactions which require to have runtime wires/invocation chains. By the SCA spec, there are three cases for the wiring: 1) Component.Reference (A.ref1) --is wired to-- Component.Service (B.svc1) -- 1.1) If both the service and reference are defined by non-composite components, then the runtime wire is as simple as A.ref1--B.svc1. 1.2) If the service is defined on a composite component, then it can be further resolved to the orginal atomic component service following the service promotion chain. For example, A.ref1 -- B.svc1 (B is implemented by another composite and B.svc1 promotes C.svc1), then the runtime wire will be: A.ref1 -- C.svc1 1.3) If the reference is defined on a composite component, then it can be further resolved to the orginal atomic component reference following the reference promotion chain. For example, A.ref1 -- B.svc1 (A is implemented by another composite and A.ref1 promotes C.ref1), then the runtime wire will be: C.ref1 -- B.svc1 2) Composite.Reference (Composite1.ref1) --promotes-- Component.Reference (B.ref1) - If Composite1 is the top-level composite, and the B is a non-composite component, then the runtime wire will be: B.ref1 -- Composite1.ref1 If Composite1 is used to implement a component A in Composite2, then we need to futher check if A.ref1 is promoted or wired until we hit the end of the promotion chain. The final target will be either a composite reference or a component service that the out-most reference is wired to. For example, if A.ref1 is wired to D.svc1 in Composite2, then the runtime wire is B.ref1 -- D.svc1. If A.ref1 is promoted by Composite2.ref1, then the runtime wire is B.ref1 -- Composite2.ref1. If B is a composite component, then we need to find out the final component reference that B.ref1 promotes. For example, it promotes D.ref1, then the runtime wire is D.ref1 -- C.ref1 3) Composite.Service (Composite1.svc1) --promotes-- Component.Service (A.svc1) --- The source will be the outmost service on the promotion chain. For example, if Composite2.svc1 promotes B.svc1 and B is implemented by Composite1, then it is Composite2.svc1. The target will be the innermost service on the promotion chain. For example, if A is implemented by Composite3 and Composite3.svc1 promotes C.svc1, then it is C.svc1. * Please note, due to the spec limitation, the composite service cannot promote a composite reference directly. Based on the above scenarios, it seems that we can create runtime wires using the following algorithm (assuming multiplicity = 1..1). The key is to get a final list of targets and selected bindings. 1) Runtime wire for references: For each of the references (r1) on non-composite components, find the outmost reference (r0) on the reference promotion chain. Then get the targets and selected bindings from r0. If SCA binding is used for a target, it can be further optimized to use the orginally promoted component service. The runtime wire should be created between the r1 and a target (either a component service with SCA binding or a reference binding) from r0. 2) Runtime wire for service promotions: For each of the service1 (s1) on non-composite components, find the outmost service (s0, can be the same as s1) on the service promotion chain. Create a runtime wire between the selected binding of s0 and the component that defines s1. (Can we assume that s1 is always local to s0?) The service/reference promotions make the picture complicated. I hope my thought makes sense. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The paths you have identified and the algorithm that you describe make sense to me, but I'm not sure that we actually need to create runtime wires. My understanding is that references have bindings and target services are provided through bindings as well. To make a reference talk to a target service we just need to select the appropriate binding (assuming that the SCA binding can do a direct in-memory call when the target service is running in the same SCA contribution and runtime) and configure the reference with the endpoint of the target service (or /bindings/endpoints/targets when multiplicity 1). Target and binding configuration can be overriden at multiple levels of composition, so a simple way to handle that is to recursively walk the nested compositions and propagate the relevant configuration to the innermost component
Re: Build runtime wire/invocation chains for a composite hierarchy
ant elder wrote: This sounds like something I'm interested in, but I'm really struggling to understand what you're talking about in these two emails. What does attach runtime context to the model so that the model can be used to drive the runtime behaviors mean? What is MyContext? Could you describe this relating it to the existing classes and say which of those you want to change? ...ant On 4/25/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Continueing on this path, I propose the following way to attach runtime context to the model so that the model can be used to drive the runtime behaviors. 1) How is a runtime context is attached to the model? Let's assume the interface for the runtime context is MyContext, then the model implementation can provide such a context in two ways: a) Implement MyContext interface directly, then the model object is an instance of MyContext and it can be cast to MyContext by the runtime. There is one thing not so nice is that we cannot have multiple inheritance and we can either use the base class for the model or the context, but not both. b) Implement a getter method to return MyContext, and the runtime can access it using reflection or a provider interface. This approach can take advantage of runtime context inheritance as MyContext is embedded. 2) How to build the invocation chain? Let's assume we have the wiring like this: ComponentA.reference1 w/ binding1 --- ComponentB.service1 w/ binding1 For the reference side, the invocation chain will look like: Binding interceptor for reference1 over binding1 -- (binding protocol layer) For the service side, the invocation chain will look like: (binding protocol layer)...--Binding interceptor for service1 over binding1-- Implementation interceptor for ComponentB If the binding is SCABinding, then for local interface or co-located remotable interface, the reference side can connect to the service side directly as: Binding interceptor for reference1 over binding1 --Binding interceptor for service1 over binding1-- Implementation interceptor for ComponentB 3) The interfaces for runtime context: Please see the bottom of the wiki page at http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Runtime+Component+Hierarchy . Thanks, Raymond - Original Message - From: Raymond Feng [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, April 24, 2007 11:58 AM Subject: Build runtime wire/invocation chains for a composite hierarchy Hi, I'm trying to indentify all the paths of SCA component interactions which require to have runtime wires/invocation chains. By the SCA spec, there are three cases for the wiring: 1) Component.Reference (A.ref1) --is wired to-- Component.Service (B.svc1) -- 1.1) If both the service and reference are defined by non-composite components, then the runtime wire is as simple as A.ref1--B.svc1. 1.2) If the service is defined on a composite component, then it can be further resolved to the orginal atomic component service following the service promotion chain. For example, A.ref1 -- B.svc1 (B is implemented by another composite and B.svc1 promotes C.svc1), then the runtime wire will be: A.ref1 -- C.svc1 1.3) If the reference is defined on a composite component, then it can be further resolved to the orginal atomic component reference following the reference promotion chain. For example, A.ref1 -- B.svc1 (A is implemented by another composite and A.ref1 promotes C.ref1), then the runtime wire will be: C.ref1 -- B.svc1 2) Composite.Reference (Composite1.ref1) --promotes-- Component.Reference (B.ref1) - If Composite1 is the top-level composite, and the B is a non-composite component, then the runtime wire will be: B.ref1 -- Composite1.ref1 If Composite1 is used to implement a component A in Composite2, then we need to futher check if A.ref1 is promoted or wired until we hit the end of the promotion chain. The final target will be either a composite reference or a component service that the out-most reference is wired to. For example, if A.ref1 is wired to D.svc1 in Composite2, then the runtime wire is B.ref1 -- D.svc1. If A.ref1 is promoted by Composite2.ref1, then the runtime wire is B.ref1 -- Composite2.ref1. If B is a composite component, then we need to find out the final component reference that B.ref1 promotes. For example, it promotes D.ref1, then the runtime wire is D.ref1 -- C.ref1 3) Composite.Service (Composite1.svc1) --promotes-- Component.Service (A.svc1) --- The source will be the outmost service on the promotion chain. For example, if Composite2.svc1 promotes B.svc1 and B is
[jira] Closed: (TUSCANY-907) Schema Import is noisy when schemaLocation is an abolute URI
[ https://issues.apache.org/jira/browse/TUSCANY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard closed TUSCANY-907. Resolution: Fixed Warnings have been eliminated. Schema Import is noisy when schemaLocation is an abolute URI Key: TUSCANY-907 URL: https://issues.apache.org/jira/browse/TUSCANY-907 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Java-M1 Reporter: Caroline Maynard Fix For: Cpp-M3 Attachments: Tuscany-907.patch See http://pecl.php.net/bugs/bug.php?id=9243. SDO for PHP user is importing a schema with import statements like import namespace=http://ping.chip.org/xml/pid; schemaLocation=http://ping.chip.org/xml/pid.xsd/ These are unconventional, since the schemaLocation is not usually an absolute URI, but they are valid. They see a lot (I mean a lot) of warning messages like: SDO_DAS_XML::create(http://ping.chip.org/phr/xml/http://ping.chip.org/phr/xml/types.xsd) [function.SDO-DAS-XML-create]: failed to open stream:HTTP request failed! HTTP/1.1 404 Not Found where, as you can see, an invalid URI is being created and used. However the schema is read successfully. There are potentially quite a few issues here around the handling of libxml error messages, but I'll restrict myself to the behaviour of SDOSchemaSAX2Parser::startSecondaryParse This tries to deal with four different ways to combine the path to the current schema with the schemaLocation attribute of the import element. Eventually the imported schema is found, but only after URIs like the one in the message above are created and used. I wasn't too happy with this particular method, so I perhaps went to the other extreme with the patch I shall attach, where I let libxml combine the two values according to RFC 2396. It works for me, but you may well have testcases where it fails, and want to approach the problem some other way. Whether or not you like the patch, I think something should be done to avoid the flurry of warnings about ill-formed URIs like the above. -- 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-988) Xpath doesn't work with nested open properties
[
https://issues.apache.org/jira/browse/TUSCANY-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491857
]
Caroline Maynard commented on TUSCANY-988:
--
See http://pecl.php.net/bugs/bug.php?id=10842
Xpath doesn't work with nested open properties
--
Key: TUSCANY-988
URL: https://issues.apache.org/jira/browse/TUSCANY-988
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-current
Reporter: Caroline Maynard
Fix For: Cpp-M3
I'm using the same Jungle schema as before, but this time my bear type is
itself open. So the jungle is:
schema
xmlns=http://www.w3.org/2001/XMLSchema;
element name=jungle
complexType
sequence
any minOccurs=0 maxOccurs=unbounded/
/sequence
/complexType
/element
/schema
and the bear is:
schema xmlns=http://www.w3.org/2001/XMLSchema;
complexType name=bearType
sequence
any minOccurs=0 maxOccurs=unbounded/
element name= name type=string/
element name= weight type=positiveInteger /
/sequence
/complexType
/schema
I load the jungle and the animal schemas into the same data factory. Then
create an empty xml document, assign into it a bear, then assign into that
bear a second bear. The instance is created fine, and I can access the nested
bear or dump out the entire instance:
?xml version=1.0 encoding=UTF-8?
jungle xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
bear xsi:type=bearType
nameMummy Bear/name
weight700/weight
bear xsi:type=bearType
nameBaby Bear/name
weight100/weight
/bear
/bear
/jungle
The problem occurs when I try to use Xpath notation to reach the baby bear,
so I'm doing a getProperty(bear/bear) on the jungle object. This fails in
commonj::sdo::DataObjectImpl::getPropertyImpl(const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
{0x01131b69 bear/bear}) line 3228 + 42 bytes
commonj::sdo::DataObjectImpl::getProperty(const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
{0x01131b69 bear/bear}) line 3205 + 20 bytes
commonj::sdo::DataObjectImpl::getProperty(const char * 0x01a7e840) line 3200
+ 59 bytes
because it doesn't handle the name as a potential Xpath, and reaches the end
of the iteration without a match. An SDOPropertyNotFoundException is raised
with the message Cannot find property :bear/bear.
--
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] Closed: (TUSCANY-980) DataObject assigned into open property goes missing
[ https://issues.apache.org/jira/browse/TUSCANY-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard closed TUSCANY-980. DataObject assigned into open property goes missing --- Key: TUSCANY-980 URL: https://issues.apache.org/jira/browse/TUSCANY-980 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Reporter: Caroline Maynard Fix For: Cpp-M3 I have a schema like so: schema xmlns=http://www.w3.org/2001/XMLSchema; element name=jungle complexType sequence any minOccurs=0 maxOccurs=unbounded/ /sequence /complexType /element element name=mixedJungle complexType mixed=true sequence any minOccurs=0 maxOccurs=unbounded/ /sequence /complexType /element /schema and another one like so: schema xmlns=http://www.w3.org/2001/XMLSchema; complexType name=snakeType sequence element name= name type=string/ element name= length type=positiveInteger / /sequence /complexType complexType name=bearType sequence element name= name type=string/ element name= weight type=positiveInteger / /sequence /complexType complexType name=pantherType sequence element name= name type=string/ element name= colour type=string / /sequence /complexType /schema Now suppose I load BOTH schemas into the same DataFactory, create a document with root type jungle, create some animal types and then assign them into the jungle. When I save the document, I see: ?xml version=1.0 encoding=UTF-8? jungle xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; bear xsi:type=bearType nameBaloo/name weight700/weight /bear panther xsi:type=pantherType nameBagheera/name colourinky black/colour /panther snake xsi:type=snakeType nameKaa/name length25/length /snake /jungle This is good. Now I change the example so that the two schemas are loaded into DIFFERENT Data Factories, and run the same test. The saved document is now: ?xml version=1.0 encoding=UTF-8? jungle xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; bear xsi:type=bearType name=Baloo weight=700/ panther xsi:type=pantherType name=Bagheera colour=inky black/ snake xsi:type=snakeType name=Kaa length=25/ /jungle so the elements have turned into attributes. Finally, I change the test so that the document root is a mixedJungle instead of a jungle, that is, it is sequenced. No errors are reported, but my document comes out as: ?xml version=1.0 encoding=UTF-8? mixedJungle xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance/ Now the animals are completely missing. The outcome is the same regardless of whether I use one or two data factories, btw. I am at revision 483149, so should have all the latest fixes. -- 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] Closed: (TUSCANY-962) Incorrect namespace for open content
[
https://issues.apache.org/jira/browse/TUSCANY-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caroline Maynard closed TUSCANY-962.
Incorrect namespace for open content
Key: TUSCANY-962
URL: https://issues.apache.org/jira/browse/TUSCANY-962
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-current
Reporter: Caroline Maynard
Priority: Blocker
Fix For: Cpp-current
I use XSDHelper::defineFile() to load the two schemas at
http://schemas.xmlsoap.org/wsdl/ and http://schemas.xmlsoap.org/wsdl/soap/.
I then build up an XML Document using that factory. I create an empty
document and get the root data object. Then
- create a service child object (type
http://schemas.xmlsoap.org/wsdl/#tService) on the root
- create a port child object (type http://schemas.xmlsoap.org/wsdl/#tPort)
on the service
- create an address child object (type
http://schemas.xmlsoap.org/wsdl/soap/#tAddress) on the port, as an open type
At this point I can introspect my port object, and I see:
object(SDO_Model_ReflectionDataObject)#9 {
- Instance of {port}
- Type open dataObject http://schemas.xmlsoap.org/wsdl/:tPort
- Instance Properties[4] {
http://schemas.xmlsoap.org/wsdl/:tDocumentation $documentation {
}
commonj.sdo:String $name;
commonj.sdo:URI $binding;
http://schemas.xmlsoap.org/wsdl/soap/:tAddress $address {
commonj.sdo:Boolean $required;
commonj.sdo:URI $location;
}
}
}
This looks correct to me.
Now we get to the problem. I save the XML document to a string. and it comes
out like this:
?xml version=1.0 encoding=UTF-8?
definitions xmlns=http://schemas.xmlsoap.org/wsdl/;
xmlns:tns=http://schemas.xmlsoap.org/wsdl/;
xmlns:tns2=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
service
port
address xsi:type=tns2:tAddress location=http://example.com/
/port
/service
/definitions
You'll notice that address has no namespace, and so is in the wsdl namespace
by default, not the soap namespace where it belongs.
This is using revision 478193.
--
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: Setting up a Tuscany runtime to run multiple applications
On 4/25/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I'm not sure that there's a 1..1 relationship between application and contribution. No, there isn't. In trying to switch terminology from application to contribution, I mistakenly implied an equivalence which isn't true. But you caught the gist of my question anyway. Thanks. I'm still having difficulty with the cardinality of the ContributionService and related services (ComponentManager, Deployer) and have to think about it some more.
