Re: [C++] Who is working on which SDO problems
Simon, I have also ben looking at a fix for 950 and although it is fairly
straightforward to fix the case in the Jira it gets rather complicated when
you consider properties that are not intended to be part of the sequence (
e.g. attributes but could be element properties that have been set without
using the sequence API).
On 03/12/06, Simon Laws [EMAIL PROTECTED] wrote:
On 12/3/06, Simon Laws [EMAIL PROTECTED] wrote:
I've been working on a fix for 950 which I managed to complete so that
you
could successfully copy a DO tree containing both mixed and open types.
I
then applied your fix for 963 and the resulting SDO fails. It happily
does
the copy still but won't print out elements in sequences or open typed
elements from the new DO that results from the copy.
... and this is exactly one of the issues I ran up against!!
Looking at the svn commit for 963 the main change seems to be to the
SDOXMLWriter.
// Do not write attributes as members of the
sequence
XSDPropertyInfo* pi =
getPropertyInfo(seqPropType,
seqProp);
PropertyDefinitionImpl propdef;
if (!pi ||
(pi-getPropertyDefinition().isElement))
{
continue;
}
I'm not au fait with how property info works but taking a tour round the
code it seems to be where the DAS keeps extra info derived from the
schema
that is only used when writing back out to XML. The change finds, from
the
property info, those elements that are really attributes and hence only
writes them as attributes.
1/ The first thing that looks a little fishy is if (!pi ||
(pi-getPropertyDefinition().isElement)) which looks like it breaks out
of
the loop if the property represents an element rather than when it's not
an
element. Is this right?
A better test here would be have we already written this property as an
attribute. The intent here is to only write properties that are explicitly
defined as elements.
Regardless of the correctness of this my copy doesn't work because !pi
is always true after I have copied the sequence. Can you explain to me
how
property information is intended to work. I need to know if I should
copy
anything more than just the instance information. I had thought
everything
else was in the model and hence I don't need to copy it.
The PropertyInformation is basically a collection of information we remember
from the schema to enable us to serialize it as a schema intended. I believe
we were going to add the ability to add this information programmatically
and this may even have made it into the spec... I need to check.
With the schema:
schema xmlns=http://www.w3.org/2001/XMLSchema;
xmlns:tns=http://www.example.org/test
targetNamespace=http://www.example.org/test;
complexType name=CloneType mixed=true
sequence
element name=test type=string/
any namespace=##any/
/sequence
/complexType
element name=Clone type=tns:CloneType/
/schema
And the XML document:
Clone xmlns=http://www.example.org/test;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation=http://www.example.org/test clone.xsd
abc
testtest/test
def
teststest/tests
ghi
/Clone
CloneType does have property info associated with it. But neither
commonj.sdo.String (the type of test) or commonj.sdo.OpenDataObject (the
type of tests) have property info associated with them once the schema
has
been read. Hence it is not present in the model after the copy and the
new
writer doesn't write out test or tests.
Types never have PropertyInformation on them... nor will ANY open property
as these, by definition, are not defined by a schema. So this is where my
fix for 963 fails as your test and tests properties will never have any pi
associated with them.
My changes (so far) are attached to
http://issues.apache.org/jira/browse/TUSCANY-950 so you can see them but
also as a backup.
I'll take a look and see how close these are to my intended fix ;-)
I'll also go back and revisit the 963 fix to cope with open types.
Cheers,
--
Pete
Re: Much ado about nothing (Re: WSCOMMONS-131 and options for Tuscany SCA Java M2 release)
I'm starting to wonder if the subject line is even more apt than we realize and we're just assuming this is a significant problem without investigating. AFAICT the only thing thats happening is what I originally reported - you see log messages about the AXIOM API SNAPSHOT when using the WS samples...but it doesn't look like that SNAPSHOT jar is actually getting used by anything. - If you delete if from your repository the samples run fine. You can run the samples in offline mode and not have that SNAPSHOT jar in your repository and the samples still run fine. - If you build the sample webapps with loadExtensionDependencies set to true then the SNAPSHOT jar is *not* included in the WAR repository and the samples still run fine even in offline mode. - If you make incompatible changes to classes in the SNAPSHOT jar in your local repository, eg change the OMElement interface to have no methods, the samples still run fine. Additionally debugging in the MavenHelper class you can see the SNAPSHOT messages are coming from the artifactResolver.resolveTransitively call on line 264 but the ArtifactResolutionResult thats returned from the call *does not* include the axiom-api SNAPSHOT artifact. Based on that it doesn't look like the SNAPSHOT jar is even added to the classpath used by the samples. Could anyone else confirm these observations? If this is true the I think we could safely cut the M2 release as-is, maybe just add a comment to the release notes about the SNAPSHOT messages. ...ant
[C++] Fix to TUSCANY-963, was: Who is working on which SDO problems
Pete Robbins wrote:
Simon, I have also ben looking at a fix for 950 and although it is fairly
straightforward to fix the case in the Jira it gets rather complicated
when
you consider properties that are not intended to be part of the
sequence (
e.g. attributes but could be element properties that have been set
without
using the sequence API).
On 03/12/06, Simon Laws [EMAIL PROTECTED] wrote:
On 12/3/06, Simon Laws [EMAIL PROTECTED] wrote:
I've been working on a fix for 950 which I managed to complete so that
you
could successfully copy a DO tree containing both mixed and open
types.
I
then applied your fix for 963 and the resulting SDO fails. It happily
does
the copy still but won't print out elements in sequences or open typed
elements from the new DO that results from the copy.
... and this is exactly one of the issues I ran up against!!
Looking at the svn commit for 963 the main change seems to be to the
SDOXMLWriter.
// Do not write attributes as members of the
sequence
XSDPropertyInfo* pi =
getPropertyInfo(seqPropType,
seqProp);
PropertyDefinitionImpl propdef;
if (!pi ||
(pi-getPropertyDefinition().isElement))
{
continue;
}
I'm not au fait with how property info works but taking a tour
round the
code it seems to be where the DAS keeps extra info derived from the
schema
that is only used when writing back out to XML. The change finds, from
the
property info, those elements that are really attributes and hence
only
writes them as attributes.
1/ The first thing that looks a little fishy is if (!pi ||
(pi-getPropertyDefinition().isElement)) which looks like it
breaks out
of
the loop if the property represents an element rather than when
it's not
an
element. Is this right?
A better test here would be have we already written this property as an
attribute. The intent here is to only write properties that are
explicitly
defined as elements.
Regardless of the correctness of this my copy doesn't work because !pi
is always true after I have copied the sequence. Can you explain to me
how
property information is intended to work. I need to know if I should
copy
anything more than just the instance information. I had thought
everything
else was in the model and hence I don't need to copy it.
The PropertyInformation is basically a collection of information we
remember
from the schema to enable us to serialize it as a schema intended. I
believe
we were going to add the ability to add this information programmatically
and this may even have made it into the spec... I need to check.
With the schema:
schema xmlns=http://www.w3.org/2001/XMLSchema;
xmlns:tns=http://www.example.org/test
targetNamespace=http://www.example.org/test;
complexType name=CloneType mixed=true
sequence
element name=test type=string/
any namespace=##any/
/sequence
/complexType
element name=Clone type=tns:CloneType/
/schema
And the XML document:
Clone xmlns=http://www.example.org/test;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation=http://www.example.org/test
clone.xsd
abc
testtest/test
def
teststest/tests
ghi
/Clone
CloneType does have property info associated with it. But neither
commonj.sdo.String (the type of test) or commonj.sdo.OpenDataObject
(the
type of tests) have property info associated with them once the schema
has
been read. Hence it is not present in the model after the copy and the
new
writer doesn't write out test or tests.
Types never have PropertyInformation on them... nor will ANY open
property
as these, by definition, are not defined by a schema. So this is where my
fix for 963 fails as your test and tests properties will never have
any pi
associated with them.
My changes (so far) are attached to
http://issues.apache.org/jira/browse/TUSCANY-950 so you can see them but
also as a backup.
I'll take a look and see how close these are to my intended fix ;-)
I'll also go back and revisit the 963 fix to cope with open types.
Cheers,
I think that the change to fix TUSCANY-963 also broke the HttpdBigBank
scenario. After some debugging it looks like elements under an open type
are not written anymore. What's strange is that they seem to be written
in some cases and not in some other cases. I am not completely sure
since the HttpdBigBank scenario is a little complex and only some of the
exchanges fail but it looks like simple elements are written and complex
type elements are not... again I'm not sure... Anyway, if I revert back
to revision r980964 of SDOWriter.cpp it works, with the head revision it
doesn't.
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
[C++] Renaming some of our build scripts?
I would like to propose the following improvements to our build scripts: Linux: Rename sca/makedist.sh and sdo/makedist.sh to builddist.sh to indicate that they are build scripts and avoid confusion with the makebindist.sh scripts which are used internally by the Makefiles Windows: Move build_tuscany_sca.bat to sca/builddist.bat and build_tuscany_sdo.bat to sdo/builddist.bat to be more consistent with Linux (we're already using the same names for the other build.sh and build.bat scripts). Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-949) Incorrect set of extensions published to the maven repo
[ http://issues.apache.org/jira/browse/TUSCANY-949?page=all ] ant elder reassigned TUSCANY-949: - Assignee: ant elder Incorrect set of extensions published to the maven repo --- Key: TUSCANY-949 URL: http://issues.apache.org/jira/browse/TUSCANY-949 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-M2 Environment: all Reporter: Simon Nash Assigned To: ant elder Attachments: jira949.diff mvn deploy publishes a number of extensions to the maven repo that should not be published there because they are not fully tested and endorsed parts of the Tuscany M2 release. Specifically, the following jars should not be published: groovy-1.0-incubator-M2.jar databinding-castor-1.0-incubator-M2.jar databinding-jaxb-1.0-incubator-M2.jar databinding-xmlbeans-1.0-incubator-M2.jar databinding-test-1.0-incubator-M2.jar celtix-1.0-incubator-M2.jar binding-jsonrpc-1.0-incubator-M2.jar An option should be provided on the build to selectively publish only those extensions that have been endorsed as part of the Tuscany M2 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-949) Incorrect set of extensions published to the maven repo
[ http://issues.apache.org/jira/browse/TUSCANY-949?page=all ] ant elder closed TUSCANY-949. - Resolution: Fixed Applied, thanks for the patch Simon. There was some mailing list discussion on this, but after 5 days the only comments were for applying it, see: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg11208.html. If anything else does come up such as specific things to test or tweaks to improve the function then they can be done as further incremental changes. Incorrect set of extensions published to the maven repo --- Key: TUSCANY-949 URL: http://issues.apache.org/jira/browse/TUSCANY-949 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-M2 Environment: all Reporter: Simon Nash Assigned To: ant elder Attachments: jira949.diff mvn deploy publishes a number of extensions to the maven repo that should not be published there because they are not fully tested and endorsed parts of the Tuscany M2 release. Specifically, the following jars should not be published: groovy-1.0-incubator-M2.jar databinding-castor-1.0-incubator-M2.jar databinding-jaxb-1.0-incubator-M2.jar databinding-xmlbeans-1.0-incubator-M2.jar databinding-test-1.0-incubator-M2.jar celtix-1.0-incubator-M2.jar binding-jsonrpc-1.0-incubator-M2.jar An option should be provided on the build to selectively publish only those extensions that have been endorsed as part of the Tuscany M2 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Renaming some of our build scripts?
On 04/12/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I would like to propose the following improvements to our build scripts: Linux: Rename sca/makedist.sh and sdo/makedist.sh to builddist.sh to indicate that they are build scripts and avoid confusion with the makebindist.sh scripts which are used internally by the Makefiles +1 Windows: Move build_tuscany_sca.bat to sca/builddist.bat and build_tuscany_sdo.bat to sdo/builddist.bat to be more consistent with Linux (we're already using the same names for the other build.sh and build.bat scripts). Thoughts? +1 ... I've been meaning to do that for some time! -- Pete
Re: [C++] Fix to TUSCANY-963, was: Who is working on which SDO problems
On 04/12/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Pete Robbins wrote:
Simon, I have also ben looking at a fix for 950 and although it is
fairly
straightforward to fix the case in the Jira it gets rather complicated
when
you consider properties that are not intended to be part of the
sequence (
e.g. attributes but could be element properties that have been set
without
using the sequence API).
On 03/12/06, Simon Laws [EMAIL PROTECTED] wrote:
On 12/3/06, Simon Laws [EMAIL PROTECTED] wrote:
I've been working on a fix for 950 which I managed to complete so
that
you
could successfully copy a DO tree containing both mixed and open
types.
I
then applied your fix for 963 and the resulting SDO fails. It happily
does
the copy still but won't print out elements in sequences or open
typed
elements from the new DO that results from the copy.
... and this is exactly one of the issues I ran up against!!
Looking at the svn commit for 963 the main change seems to be to the
SDOXMLWriter.
// Do not write attributes as members of the
sequence
XSDPropertyInfo* pi =
getPropertyInfo(seqPropType,
seqProp);
PropertyDefinitionImpl propdef;
if (!pi ||
(pi-getPropertyDefinition().isElement))
{
continue;
}
I'm not au fait with how property info works but taking a tour
round the
code it seems to be where the DAS keeps extra info derived from the
schema
that is only used when writing back out to XML. The change finds,
from
the
property info, those elements that are really attributes and hence
only
writes them as attributes.
1/ The first thing that looks a little fishy is if (!pi ||
(pi-getPropertyDefinition().isElement)) which looks like it
breaks out
of
the loop if the property represents an element rather than when
it's not
an
element. Is this right?
A better test here would be have we already written this property as an
attribute. The intent here is to only write properties that are
explicitly
defined as elements.
Regardless of the correctness of this my copy doesn't work because
!pi
is always true after I have copied the sequence. Can you explain to
me
how
property information is intended to work. I need to know if I should
copy
anything more than just the instance information. I had thought
everything
else was in the model and hence I don't need to copy it.
The PropertyInformation is basically a collection of information we
remember
from the schema to enable us to serialize it as a schema intended. I
believe
we were going to add the ability to add this information
programmatically
and this may even have made it into the spec... I need to check.
With the schema:
schema xmlns=http://www.w3.org/2001/XMLSchema;
xmlns:tns=http://www.example.org/test
targetNamespace=http://www.example.org/test;
complexType name=CloneType mixed=true
sequence
element name=test type=string/
any namespace=##any/
/sequence
/complexType
element name=Clone type=tns:CloneType/
/schema
And the XML document:
Clone xmlns=http://www.example.org/test;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation=http://www.example.org/test
clone.xsd
abc
testtest/test
def
teststest/tests
ghi
/Clone
CloneType does have property info associated with it. But neither
commonj.sdo.String (the type of test) or commonj.sdo.OpenDataObject
(the
type of tests) have property info associated with them once the
schema
has
been read. Hence it is not present in the model after the copy and
the
new
writer doesn't write out test or tests.
Types never have PropertyInformation on them... nor will ANY open
property
as these, by definition, are not defined by a schema. So this is where
my
fix for 963 fails as your test and tests properties will never have
any pi
associated with them.
My changes (so far) are attached to
http://issues.apache.org/jira/browse/TUSCANY-950 so you can see them
but
also as a backup.
I'll take a look and see how close these are to my intended fix ;-)
I'll also go back and revisit the 963 fix to cope with open types.
Cheers,
I think that the change to fix TUSCANY-963 also broke the HttpdBigBank
scenario. After some debugging it looks like elements under an open type
are not written anymore. What's strange is that they seem to be written
in some cases and not in some other cases. I am not completely sure
since the HttpdBigBank scenario is a little complex and only some of the
exchanges fail but it looks like simple elements are written and complex
type elements are not... again I'm not sure... Anyway, if I revert back
to revision r980964 of SDOWriter.cpp it works, with the head revision it
doesn't.
Re: [C++] Renaming some of our build scripts?
On 12/4/06, Pete Robbins [EMAIL PROTECTED] wrote: On 04/12/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I would like to propose the following improvements to our build scripts: Linux: Rename sca/makedist.sh and sdo/makedist.sh to builddist.sh to indicate that they are build scripts and avoid confusion with the makebindist.sh scripts which are used internally by the Makefiles +1 Windows: Move build_tuscany_sca.bat to sca/builddist.bat and build_tuscany_sdo.bat to sdo/builddist.bat to be more consistent with Linux (we're already using the same names for the other build.sh and build.bat scripts). Thoughts? +1 ... I've been meaning to do that for some time! +1 from me too. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO C++] Thread safety ?
On 01/12/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: OK, I was asking because it seems more interesting to support threaded MPMs on Windows (as a threaded MPM is the default) than on Linux/Unix where I think the majority of people use forking/multi-process MPMs. So I was initially thinking of having the default binary distribution be multi-threaded on Windows and mono-threaded on Linux, but I'm interested in your input and what you've seen in terms of actual usage on both platforms. We know that, as you said, pretty much all options are possible on all platforms, and people are expecting binary distributions on Windows but in general build from source on Linux, but I'm looking for the right defaults... I would agree with those defaults for the binaries, provided there's no negative effects for the non-threaded Windows user. Have you considered how to maintain the status of the thread-safe variant as new code is added? What do you mean by maintain the status of the thread-safe variant? document it? continue to make sure that it works when adding new code? anything else? I meant the latter - with quite a few different people contributing code and patches, there's a likelihood that new thread-unsafe code may be introduced. -- Caroline
Fwd: svn commit: r481914 - /incubator/tuscany/java/sca/services/bindings/binding.axis2/src/main/java/org/apache/tuscany/binding/axis2/Axis2BindingBuilder.java
extend scope annotations in interface of binding to service contract. But how do we do this for for wsdl interface ? Should these properties be allowed in the SCDL? Hi Rick, FYI in the specs scopes are moving to the component type and the interaction scope is going to change to conversational service vs. non-conversational service (boolean on ServiceContract). The latter will need to be noted through WSDL (also a TODO in the spec group). At some point this week, I was planning on making the necessary changes in trunk. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-935) SDO path accessors need to support names that contain .
[ http://issues.apache.org/jira/browse/TUSCANY-935?page=comments#action_12455266 ] Kelvin Goodson commented on TUSCANY-935: Working from Yang's patch I've deliberately committed a modified test case under a different name DotNameTest.java (so that maven wont pick it up) and I'm not yet committing the fix since there are a couple of issues. One is that with the fix applied XPathTestCase fails in testListIndexing with junit.framework.AssertionFailedError: bad indexing passed at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertFalse(Assert.java:34) at org.apache.tuscany.sdo.test.XPathTestCase.testListIndexing(XPathTestCase.java:106) The other issue is that there seems to be some inter-TestCase type scope interference. I have altered the new test case to use the HelperContext method of getting a type helper in setUp(), but the interference persists even with that change. In order to be able to explore this issue in eclipse I have added the test case to AllTests.java twice; once at the start of the sequence of tests and once at the end. When run at the start of the sequence the new test case runs perfectly, but when run at the end it fails. You can see that if you run the new test independently then the quote instance is an instance of DynamicDataObjectImpl, but if you ran the test as it was provided, in a maven build, then there is a failure, and it seems that the quote instance is now an instance of a generated Quote class. Yang, if you could investigate the XPathTestCase failure please, I will tyr to gain some insight into the type interference issue. SDO path accessors need to support names that contain . - Key: TUSCANY-935 URL: http://issues.apache.org/jira/browse/TUSCANY-935 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Frank Budinsky Attachments: DataObjectUtil.935, dotNames.xsd, DotNameTestCase.java This issue keeps coming up. The . character is commonly used in industrial schemas, so we need to make it work. I propose handling it as follows: Given a property name like foo.0: 1. first simply check if there is a property with the specified name. 2. if a property with that name isn't found, then find the last . character in the name. 3. if it is followed by digits, then use the substring from 0 to the . as the property name, and the number after the dot as an index. The only case this breaks is when there is both an isMany property named foo and another property named someting like foo.0 in the same type. I think this is an unlikely corner case, that we can live with. We'll also need to propose this behavior be clarified in the spec. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-935) SDO path accessors need to support names that contain .
[ http://issues.apache.org/jira/browse/TUSCANY-935?page=comments#action_12455275 ] Kelvin Goodson commented on TUSCANY-935: I have managed to assert that the cross scope type interference exhibited when the test cases are run together is due to the fact that we haven't completed the HelperContext work with respect to generated classes yet. Currently XSDHelperTestCase registers generated classes for the namespace http://www.example.com/simple; and the new DotNamesTestCase registers dynamic types in this namespace also. I will change the namespace in the test case. I have a test case locally to guard against this situation, which I will add when the HelperContext work for generated classes is done. SDO path accessors need to support names that contain . - Key: TUSCANY-935 URL: http://issues.apache.org/jira/browse/TUSCANY-935 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Frank Budinsky Attachments: DataObjectUtil.935, dotNames.xsd, DotNameTestCase.java This issue keeps coming up. The . character is commonly used in industrial schemas, so we need to make it work. I propose handling it as follows: Given a property name like foo.0: 1. first simply check if there is a property with the specified name. 2. if a property with that name isn't found, then find the last . character in the name. 3. if it is followed by digits, then use the substring from 0 to the . as the property name, and the number after the dot as an index. The only case this breaks is when there is both an isMany property named foo and another property named someting like foo.0 in the same type. I think this is an unlikely corner case, that we can live with. We'll also need to propose this behavior be clarified in the spec. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (TUSCANY-963) Spurious elements generated
[ http://issues.apache.org/jira/browse/TUSCANY-963?page=all ] Pete Robbins reopened TUSCANY-963: -- Spurious elements generated --- Key: TUSCANY-963 URL: http://issues.apache.org/jira/browse/TUSCANY-963 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Reporter: Caroline Maynard Assigned To: Pete Robbins Priority: Critical Fix For: Cpp-current I have a schema like so: ?xml version=1.0 encoding=utf-8 ? xs:schema targetNamespace=http://www.w3.org/2005/Atom; xmlns=http://www.w3.org/2005/Atom; xmlns:xs=http://www.w3.org/2001/XMLSchema; xs:import namespace=http://www.w3.org/XML/1998/namespace; schemaLocation=xml.xsd / xs:import namespace=http://www.w3.org/1999/xhtml; schemaLocation=xhtml1-strict.xsd / xs:element name=content type=contentType minOccurs=0 / xs:complexType name=contentType mixed=true xs:sequence xs:any namespace=##other processContents=lax minOccurs=0 maxOccurs=unbounded / /xs:sequence xs:attribute name=type type=xs:string default=text / xs:attribute name=src type=xs:string / !-- uriType -- xs:attributeGroup ref=commonAttributes/ /xs:complexType xs:attributeGroup name=commonAttributes xs:attribute ref=xml:base / xs:attribute ref=xml:lang / xs:anyAttribute/ /xs:attributeGroup /xs:schema and a document like so: ?xml version=1.0 encoding=UTF-8? content xmlns=http://www.w3.org/2005/Atom; xmlns:tns=http://www.w3.org/2005/Atom; xml:base=blah xml:lang=blah2 / I load the schema with XSDHelper::defineFile(), and then load the document with XMLHelper::loadFile(). Then I do a save() of the document. The output is: ?xml version=1.0 encoding=UTF-8? content xmlns=http://www.w3.org/2005/Atom; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:tns=http://www.w3.org/2005/Atom; base=blah lang=blah2 baseblah/base langblah2/lang /content So not only do I have the lang and base attributes on content, I get some elements thrown in for free, too. You'll notice that id is both sequenced and open. I'll find out if both these conditions are necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Python service wrapper returning data on the stack
On 12/1/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Andy, I think that the Python service wrapper sometimes returns data on the stack, the data allocated by PyValue appears to be valid inside the wrapper itself but gets out of scope after the wrapper has returned, causing memory violations or garbage to be returned. Could you please take a look at my change under revision r481279? I copied a char* into a new string to workaround the particular case I ran into, but there's probably a better way to fix this and make sure that strings returned by the wrapper in general are allocated on the heap instead of the stack. Thanks... -- Jean-Sebastien Hi Sebastien, This change looks good, thanks. It strikes me that we may need some kind of extension-builder's library that can be used to manage data and the conversion of data and other chunks of code that we are seeing repeated in various places in the extensions. With something like this, issues such as the one you found above should be found fixed earlier. What do people think? Cheers Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Who is working on which SDO problems
Simon, your patch fails to apply with some wierd error at line 416! I have
backed out the change for 963. Could you try making your patch again?
Cheers,
On 04/12/06, Pete Robbins [EMAIL PROTECTED] wrote:
Simon, I have also ben looking at a fix for 950 and although it is fairly
straightforward to fix the case in the Jira it gets rather complicated when
you consider properties that are not intended to be part of the sequence (
e.g. attributes but could be element properties that have been set without
using the sequence API).
On 03/12/06, Simon Laws [EMAIL PROTECTED] wrote:
On 12/3/06, Simon Laws [EMAIL PROTECTED] wrote:
I've been working on a fix for 950 which I managed to complete so that
you
could successfully copy a DO tree containing both mixed and open
types. I
then applied your fix for 963 and the resulting SDO fails. It happily
does
the copy still but won't print out elements in sequences or open typed
elements from the new DO that results from the copy.
... and this is exactly one of the issues I ran up against!!
Looking at the svn commit for 963 the main change seems to be to the
SDOXMLWriter.
// Do not write attributes as members of the
sequence
XSDPropertyInfo* pi =
getPropertyInfo(seqPropType,
seqProp);
PropertyDefinitionImpl propdef;
if (!pi ||
(pi-getPropertyDefinition().isElement))
{
continue;
}
I'm not au fait with how property info works but taking a tour round
the
code it seems to be where the DAS keeps extra info derived from the
schema
that is only used when writing back out to XML. The change finds, from
the
property info, those elements that are really attributes and hence
only
writes them as attributes.
1/ The first thing that looks a little fishy is if (!pi ||
(pi-getPropertyDefinition().isElement)) which looks like it breaks
out of
the loop if the property represents an element rather than when it's
not an
element. Is this right?
A better test here would be have we already written this property as an
attribute. The intent here is to only write properties that are explicitly
defined as elements.
Regardless of the correctness of this my copy doesn't work because !pi
is always true after I have copied the sequence. Can you explain to me
how
property information is intended to work. I need to know if I should
copy
anything more than just the instance information. I had thought
everything
else was in the model and hence I don't need to copy it.
The PropertyInformation is basically a collection of information we
remember from the schema to enable us to serialize it as a schema intended.
I believe we were going to add the ability to add this information
programmatically and this may even have made it into the spec... I need to
check.
With the schema:
schema xmlns=http://www.w3.org/2001/XMLSchema
xmlns:tns=http://www.example.org/test
targetNamespace=http://www.example.org/test;
complexType name=CloneType mixed=true
sequence
element name=test type=string/
any namespace=##any/
/sequence
/complexType
element name=Clone type=tns:CloneType/
/schema
And the XML document:
Clone xmlns=http://www.example.org/test;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation=http://www.example.org/test clone.xsd
abc
testtest/test
def
teststest/tests
ghi
/Clone
CloneType does have property info associated with it. But neither
commonj.sdo.String (the type of test) or commonj.sdo.OpenDataObject(the
type of tests) have property info associated with them once the schema
has
been read. Hence it is not present in the model after the copy and the
new
writer doesn't write out test or tests.
Types never have PropertyInformation on them... nor will ANY open property
as these, by definition, are not defined by a schema. So this is where my
fix for 963 fails as your test and tests properties will never have any pi
associated with them.
My changes (so far) are attached to
http://issues.apache.org/jira/browse/TUSCANY-950 so you can see them but
also as a backup.
I'll take a look and see how close these are to my intended fix ;-)
I'll also go back and revisit the 963 fix to cope with open types.
Cheers,
--
Pete
--
Pete
[jira] Updated: (TUSCANY-904) Expose DAS as SCA container
[ http://issues.apache.org/jira/browse/TUSCANY-904?page=all ] Amita Vadhavkar updated TUSCANY-904: Attachment: das-container-unittest-Dec04.jar This is a set of unit test cases to test individual DAS - SCA container classes. It assumes existance of the canned derby database(dastest) with table customer(ID, LASTNAME, ADDRESS). Expose DAS as SCA container --- Key: TUSCANY-904 URL: http://issues.apache.org/jira/browse/TUSCANY-904 Project: Tuscany Issue Type: Sub-task Affects Versions: Java-Mx Environment: N/A Reporter: Amita Vadhavkar Attachments: amita.11202006.zip, container-das-sample-client-Dec01.jar, das-container-unittest-Dec04.jar, das-Dec01.jar, dataaccess-container-staticPlusDynamic.jar, diffResultClient.txt, diffResultContainer.txt, SCAcontainerForDAS.doc, tuscany904.amitav.20061115.jar, tuscany904.lresende.20061113.zip This is linked to master JIRA -864 and is created to track work on developing SCA container for DAS -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Who is working on which SDO problems
On 12/4/06, Pete Robbins [EMAIL PROTECTED] wrote:
Simon, your patch fails to apply with some wierd error at line 416! I have
backed out the change for 963. Could you try making your patch again?
Cheers,
On 04/12/06, Pete Robbins [EMAIL PROTECTED] wrote:
Simon, I have also ben looking at a fix for 950 and although it is
fairly
straightforward to fix the case in the Jira it gets rather complicated
when
you consider properties that are not intended to be part of the sequence
(
e.g. attributes but could be element properties that have been set
without
using the sequence API).
On 03/12/06, Simon Laws [EMAIL PROTECTED] wrote:
On 12/3/06, Simon Laws [EMAIL PROTECTED] wrote:
I've been working on a fix for 950 which I managed to complete so
that
you
could successfully copy a DO tree containing both mixed and open
types. I
then applied your fix for 963 and the resulting SDO fails. It
happily
does
the copy still but won't print out elements in sequences or open
typed
elements from the new DO that results from the copy.
... and this is exactly one of the issues I ran up against!!
Looking at the svn commit for 963 the main change seems to be to the
SDOXMLWriter.
// Do not write attributes as members of the
sequence
XSDPropertyInfo* pi =
getPropertyInfo(seqPropType,
seqProp);
PropertyDefinitionImpl propdef;
if (!pi ||
(pi-getPropertyDefinition().isElement))
{
continue;
}
I'm not au fait with how property info works but taking a tour round
the
code it seems to be where the DAS keeps extra info derived from the
schema
that is only used when writing back out to XML. The change finds,
from
the
property info, those elements that are really attributes and hence
only
writes them as attributes.
1/ The first thing that looks a little fishy is if (!pi ||
(pi-getPropertyDefinition().isElement)) which looks like it breaks
out of
the loop if the property represents an element rather than when it's
not an
element. Is this right?
A better test here would be have we already written this property as an
attribute. The intent here is to only write properties that are
explicitly
defined as elements.
Regardless of the correctness of this my copy doesn't work because
!pi
is always true after I have copied the sequence. Can you explain to
me
how
property information is intended to work. I need to know if I should
copy
anything more than just the instance information. I had thought
everything
else was in the model and hence I don't need to copy it.
The PropertyInformation is basically a collection of information we
remember from the schema to enable us to serialize it as a schema
intended.
I believe we were going to add the ability to add this information
programmatically and this may even have made it into the spec... I need
to
check.
With the schema:
schema xmlns=http://www.w3.org/2001/XMLSchema
xmlns:tns=http://www.example.org/test
targetNamespace=http://www.example.org/test;
complexType name=CloneType mixed=true
sequence
element name=test type=string/
any namespace=##any/
/sequence
/complexType
element name=Clone type=tns:CloneType/
/schema
And the XML document:
Clone xmlns=http://www.example.org/test;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation=http://www.example.org/test clone.xsd
abc
testtest/test
def
teststest/tests
ghi
/Clone
CloneType does have property info associated with it. But neither
commonj.sdo.String (the type of test) or commonj.sdo.OpenDataObject
(the
type of tests) have property info associated with them once the
schema
has
been read. Hence it is not present in the model after the copy and
the
new
writer doesn't write out test or tests.
Types never have PropertyInformation on them... nor will ANY open
property
as these, by definition, are not defined by a schema. So this is where
my
fix for 963 fails as your test and tests properties will never have
any pi
associated with them.
My changes (so far) are attached to
http://issues.apache.org/jira/browse/TUSCANY-950 so you can see them
but
also as a backup.
I'll take a look and see how close these are to my intended fix ;-)
I'll also go back and revisit the 963 fix to cope with open types.
Cheers,
--
Pete
--
Pete
Oh dear. I actutally tested applying this patch as well this time:-( It
applies OK in Eclipse against a clean version of SDO. Can you shed any light
on what the error is. As it was suggested last time that I should manually
edit the patch to make it relative I did this to the satisfaction of the
Eclipse
Java SDO Question: Native support for commonj.sdo/xml data model
I found the current Java SDO runtime has natively registered and supported commonj.sdo and commonj.sdo/java data model but I didn't see commonj.sdo/xml was registered and supported. Shouldn't commonj.sdo/xml be part of SDO's core model? Thanks in advance.
Re: conversational infrastructure
As it turns out, there's a problem with 7 below. The key to a ConversationSequenceInterceptor is that the same instance is used for all conversational operations except the ones that end the conversation, with this instance maintaining a flag to determine whether the conversation is starting or not. However, since interceptors are part of a chain, if we try to use a single instance of a given interceptor for more than one operation, we are effectively merging the corresponding chains at the point the interceptor is inserted. In our case, the interceptor is being inserted at the head, so we basically bypass all other interceptors for all chains but the last one. In the sample, one of the operations happens to be one-way but its non-blocking interceptor is being bypassed and so we lose its async behavior. I am checking in a fix that moves the behavior provided by the conversational interceptors (as well as the wire post processor) to the AbstractOutboundInvocationHandler and that disables the wire post processor by removing its entry from core/implementation.scdl. On 11/27/06, Jim Marino [EMAIL PROTECTED] wrote: snip/ 7. I added two interceptors that will be inserted into invocation chains between conversational implementations. ConversationSequenceInterceptor will be inserted into all operations except ones marked @EndConversation. This interceptor tracks the conversation sequence the operation is invoked in (start or continue). This is necessary so the scope container knows whether to create a new instance or return an existing one (since conversation ids may be reused). Each operation for a wire receives the same instance of the ConversationSequenceInterceptor, which is inserted in the wire post-process phase by ConversationWirePostProcessor. For operations marked with @EndConversation, a ConversationEndInterceptor is inserted. snip/
[jira] Commented: (TUSCANY-935) SDO path accessors need to support names that contain .
[ http://issues.apache.org/jira/browse/TUSCANY-935?page=comments#action_12455337 ] Yang ZHONG commented on TUSCANY-935: Thanks to Kelvin. I'm looking into XPathTestCase. SDO path accessors need to support names that contain . - Key: TUSCANY-935 URL: http://issues.apache.org/jira/browse/TUSCANY-935 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Frank Budinsky Attachments: DataObjectUtil.935, dotNames.xsd, DotNameTestCase.java This issue keeps coming up. The . character is commonly used in industrial schemas, so we need to make it work. I propose handling it as follows: Given a property name like foo.0: 1. first simply check if there is a property with the specified name. 2. if a property with that name isn't found, then find the last . character in the name. 3. if it is followed by digits, then use the substring from 0 to the . as the property name, and the number after the dot as an index. The only case this breaks is when there is both an isMany property named foo and another property named someting like foo.0 in the same type. I think this is an unlikely corner case, that we can live with. We'll also need to propose this behavior be clarified in the spec. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Much ado about nothing (Re: WSCOMMONS-131 and options for Tuscany SCA Java M2 release)
This is a good set of observations and if we can figure out why this snapshot is not being used (or even returned despite the dependency onit) I think we'd be good to go. If we're going to do that though I think it's important to understand the cause of this behaviour and not just the effect. -- Jeremy On Dec 4, 2006, at 12:31 AM, ant elder wrote: I'm starting to wonder if the subject line is even more apt than we realize and we're just assuming this is a significant problem without investigating. AFAICT the only thing thats happening is what I originally reported - you see log messages about the AXIOM API SNAPSHOT when using the WS samples...but it doesn't look like that SNAPSHOT jar is actually getting used by anything. - If you delete if from your repository the samples run fine. You can run the samples in offline mode and not have that SNAPSHOT jar in your repository and the samples still run fine. - If you build the sample webapps with loadExtensionDependencies set to true then the SNAPSHOT jar is *not* included in the WAR repository and the samples still run fine even in offline mode. - If you make incompatible changes to classes in the SNAPSHOT jar in your local repository, eg change the OMElement interface to have no methods, the samples still run fine. Additionally debugging in the MavenHelper class you can see the SNAPSHOT messages are coming from the artifactResolver.resolveTransitively call on line 264 but the ArtifactResolutionResult thats returned from the call *does not* include the axiom-api SNAPSHOT artifact. Based on that it doesn't look like the SNAPSHOT jar is even added to the classpath used by the samples. Could anyone else confirm these observations? If this is true the I think we could safely cut the M2 release as- is, maybe just add a comment to the release notes about the SNAPSHOT messages. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-967) NPE when loading componentType side file with callbackInterface attribute defined
[
http://issues.apache.org/jira/browse/TUSCANY-967?page=comments#action_12455340
]
Lou Amodeo commented on TUSCANY-967:
I see the problem. I am using the integration test environment (itest) and it
looks like resource files are not being copied to the /target directory along
with the class files. I guess this JIRA should be redirected to the itest
component. I dont know how this is done though.
NPE when loading componentType side file with callbackInterface attribute
defined
-
Key: TUSCANY-967
URL: http://issues.apache.org/jira/browse/TUSCANY-967
Project: Tuscany
Issue Type: Bug
Reporter: Lou Amodeo
A Remote service that has a callback interface defined in a componentType
file receives a NPE when loading the componentType side file. .
[INFO] [tuscany-itest:start {execution: start}]
[INFO] Starting Tuscany...
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.tuscany.core.implementation.processor.ServiceProcessor.visitField(ServiceProcessor.java:149)
at
org.apache.tuscany.core.implementation.IntrospectionRegistryImpl.introspect(IntrospectionRegistryImpl.java:97)
at
org.apache.tuscany.core.implementation.java.JavaComponentTypeLoader.loadByIntrospection(JavaComponentTypeLoader.java:79)
at
org.apache.tuscany.core.implementation.java.JavaComponentTypeLoader.load(JavaComponentTypeLoader.java:66)
at
org.apache.tuscany.core.implementation.java.JavaComponentTypeLoader.load(JavaComponentTypeLoader.java:44)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:163)
at
org.apache.tuscany.core.implementation.java.JavaImplementationLoader.load(JavaImplementationLoader.java:58)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:94)
at
org.apache.tuscany.core.loader.ComponentLoader.loadImplementation(ComponentLoader.java:184)
at
org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.java:128)
at
org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.java:70)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:94)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:81)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:55)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:94)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:112)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile(CompositeComponentTypeLoader.java:65)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:57)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:39)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:163)
at
org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:101)
at
org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:76)
at
org.apache.tuscany.core.runtime.AbstractRuntime.deployApplicationScdl(AbstractRuntime.java:136)
at
org.apache.tuscany.sca.plugin.itest.MavenEmbeddedRuntime.initialize(MavenEmbeddedRuntime.java:85)
at
org.apache.tuscany.sca.plugin.itest.TuscanyStartMojo.execute(TuscanyStartMojo.java:102)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at
Re: Java SDO Question: Native support for commonj.sdo/xml data model
Hi Fuhwei, you are right that we should preregister commonj.sdo/xml. We haven't really needed it for anything before now ... that's the only reason we don't have it already. Frank. Fuhwei Lwo [EMAIL PROTECTED] wrote on 12/04/2006 09:15:58 AM: I found the current Java SDO runtime has natively registered and supported commonj.sdo and commonj.sdo/java data model but I didn't see commonj.sdo/xml was registered and supported. Shouldn't commonj.sdo/xml be part of SDO's core model? Thanks in advance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: conversational infrastructure
The problem with moving this into the invocation handler is that we
need a mechanism to track state for whether the client believes the
conversation has begun. For example:
interface ConverSationalService {
void operation1();
void operation2();
void end();
}
Calling operation1 or operation2 will start the conversation, and
subsequent calls to those two will continue the conversation. We will
need to come up with a mechanism for handling this. Are you proposing
to create a type of key class that contains the conversational key
value and a flag of its sequence? If we do this, we can continue to
use the interceptors as they become stateless.
Jim
On Dec 4, 2006, at 6:50 AM, Ignacio Silva-Lepe wrote:
As it turns out, there's a problem with 7 below. The key to a
ConversationSequenceInterceptor is that the same instance is
used for all conversational operations except the ones that end
the conversation, with this instance maintaining a flag to determine
whether the conversation is starting or not. However, since
interceptors are part of a chain, if we try to use a single instance
of a given interceptor for more than one operation, we are effectively
merging the corresponding chains at the point the interceptor is
inserted. In our case, the interceptor is being inserted at the head,
so we basically bypass all other interceptors for all chains but the
last one. In the sample, one of the operations happens to be one-way
but its non-blocking interceptor is being bypassed and so we lose
its async behavior.
I am checking in a fix that moves the behavior provided by the
conversational interceptors (as well as the wire post processor) to
the AbstractOutboundInvocationHandler and that disables the wire
post processor by removing its entry from core/implementation.scdl.
On 11/27/06, Jim Marino [EMAIL PROTECTED] wrote:
snip/
7. I added two interceptors that will be inserted into invocation
chains between conversational implementations.
ConversationSequenceInterceptor will be inserted into all operations
except ones marked @EndConversation. This interceptor tracks the
conversation sequence the operation is invoked in (start or
continue). This is necessary so the scope container knows whether to
create a new instance or return an existing one (since conversation
ids may be reused). Each operation for a wire receives the same
instance of the ConversationSequenceInterceptor, which is inserted in
the wire post-process phase by ConversationWirePostProcessor. For
operations marked with @EndConversation, a ConversationEndInterceptor
is inserted.
snip/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-859) ChangeSummary#isCreated cache is not updated while changes are still going on
[
http://issues.apache.org/jira/browse/TUSCANY-859?page=comments#action_12455346
]
Kelvin Goodson commented on TUSCANY-859:
Capturing some info on this.
I think Yang's patch fixes the specific test case, but there may be more to
this, and we should consider performance. EMFhas a method summarize which
calls consolidateChanges and this refreshes caches. There are 2 other caches
-- we need to check if these are similarly affected. I think we need to be
making judicious calls to summarize(), bearing performance in mind.
ChangeSummary#isCreated cache is not updated while changes are still going on
-
Key: TUSCANY-859
URL: http://issues.apache.org/jira/browse/TUSCANY-859
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-Mx
Reporter: Yang ZHONG
Attachments: 859.patch
This Test Case uses simple.xsd from tuscany/java/sdo/impl/src/test/resources,
however it's a *generic* issue, not specific to simple.xsd.
child = quote.createDataObject(quotes);
assertTrue(changeSummary.isCreated(child));
child = quote.createDataObject(quotes);
assertTrue(changeSummary.isCreated(child));
The last assertion fails.
ChangeSummary#isCreated delegates to *derived* getObjectsToDetach()
caching which improves performance.
However, the cache should be updated while changes are still going on.
I have browsed the spec 2.1draft and 2.01, they don't seem forbid users from
querying ChangeSummary before endLogging().
One of the possible solutions is to invalidate cache whevever there's a new
change, such as
public void SDOChangeRecorder#notifyChanged(Notification notification)
{
cachedObjectsToDetach = null;
super.notifyChanged( notification);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pass-by-value support for remotable interfaces
Mike Edwards wrote: Raymond, First point I need to make is that just because two components are in the same composite does not mean that they are automatically running in the same VM or even the same operating system process. Composites can span components running on different nodes (node = machine and/or o/s process). Consider a composite which had component A implemented in Java and component B implemented in C++. Not likely that they would run in the same runtime process (certainly not with the current Tuscany runtime). This is perfectly OK as long as any interface between them is remotable. Second, more general point to make, is that there may be implied semantics for the interface that depend on the binding used to connect the reference to the service. Consider the case where the interface involves an operation with a message having two references to the same object. When this is sent from consumer to provider (say), does the provider receive 2 separate copies of the object or just one - assuming the consumer started with only 1. The answer is it depends on the binding - RMI-IIOP says there is only 1 copy. Web Services says there are 2 copies... I don't think that SCA can hide these subtle differences, much though we may like to do so. However, what we must guarantee is that the behaviour matches the binding type - if the internal wire uses binding.ws, for example, then we provide Web services semantics. This must be true for any optimisations we may like to use in the case where both ends of the wire are in 1 process - since for a remotable interface this proximity is accidental and could be changed by a subtle change in deployment. That leaves open what to do in the case of binding.ws. We may need a way for the composition to indicate the type of semantics required - or we could default to one form (eg Web services...) Did you mean to say binding.sca in the paragraph above? I think allowing control over the semantics is the way to go. Perhaps the SCA notion of intents could be used for this. Yours, Mike. Raymond Feng wrote: Hi, I'm talking about the following: componentA.reference -- componentB.service1 non-SCA client -- componentB.service1 In the cases above, componentA and componentB are in the same composite (in the same VM). Both the service and reference are declared with a remotable interface. We need to have an interceptor to deal with the pass-by-value. For the following wirings: .. -- composite.reference composite.service -- ... I assume the binding implementation for the composite reference/service will handle the pass-by-value naturally over the transport. Thanks, Raymond snip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK [EMAIL PROTECTED] Tel. +44-1962-815156 Fax +44-1962-818999 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-935) SDO path accessors need to support names that contain .
[ http://issues.apache.org/jira/browse/TUSCANY-935?page=comments#action_12455349 ] Kelvin Goodson commented on TUSCANY-935: As a follow up to my comments about cross scope interference and generated classes, TUSCANY-684 will address this issue. Having made the changes to the DotNames test case so that it uses a unique namespace, this JIRA is now independent of that issue, so this is FYI only. SDO path accessors need to support names that contain . - Key: TUSCANY-935 URL: http://issues.apache.org/jira/browse/TUSCANY-935 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Frank Budinsky Attachments: DataObjectUtil.935, dotNames.xsd, DotNameTestCase.java This issue keeps coming up. The . character is commonly used in industrial schemas, so we need to make it work. I propose handling it as follows: Given a property name like foo.0: 1. first simply check if there is a property with the specified name. 2. if a property with that name isn't found, then find the last . character in the name. 3. if it is followed by digits, then use the substring from 0 to the . as the property name, and the number after the dot as an index. The only case this breaks is when there is both an isMany property named foo and another property named someting like foo.0 in the same type. I think this is an unlikely corner case, that we can live with. We'll also need to propose this behavior be clarified in the spec. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-967) NPE when loading componentType side file with callbackInterface attribute defined
[ http://issues.apache.org/jira/browse/TUSCANY-967?page=all ]
Raymond Feng updated TUSCANY-967:
-
Component/s: Java SCA Tools
Move to SCA Tools
NPE when loading componentType side file with callbackInterface attribute
defined
-
Key: TUSCANY-967
URL: http://issues.apache.org/jira/browse/TUSCANY-967
Project: Tuscany
Issue Type: Bug
Components: Java SCA Tools
Reporter: Lou Amodeo
A Remote service that has a callback interface defined in a componentType
file receives a NPE when loading the componentType side file. .
[INFO] [tuscany-itest:start {execution: start}]
[INFO] Starting Tuscany...
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.tuscany.core.implementation.processor.ServiceProcessor.visitField(ServiceProcessor.java:149)
at
org.apache.tuscany.core.implementation.IntrospectionRegistryImpl.introspect(IntrospectionRegistryImpl.java:97)
at
org.apache.tuscany.core.implementation.java.JavaComponentTypeLoader.loadByIntrospection(JavaComponentTypeLoader.java:79)
at
org.apache.tuscany.core.implementation.java.JavaComponentTypeLoader.load(JavaComponentTypeLoader.java:66)
at
org.apache.tuscany.core.implementation.java.JavaComponentTypeLoader.load(JavaComponentTypeLoader.java:44)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:163)
at
org.apache.tuscany.core.implementation.java.JavaImplementationLoader.load(JavaImplementationLoader.java:58)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:94)
at
org.apache.tuscany.core.loader.ComponentLoader.loadImplementation(ComponentLoader.java:184)
at
org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.java:128)
at
org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.java:70)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:94)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:81)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:55)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:94)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:112)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile(CompositeComponentTypeLoader.java:65)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:57)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:39)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:163)
at
org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:101)
at
org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:76)
at
org.apache.tuscany.core.runtime.AbstractRuntime.deployApplicationScdl(AbstractRuntime.java:136)
at
org.apache.tuscany.sca.plugin.itest.MavenEmbeddedRuntime.initialize(MavenEmbeddedRuntime.java:85)
at
org.apache.tuscany.sca.plugin.itest.TuscanyStartMojo.execute(TuscanyStartMojo.java:102)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
Re: [C++] Python service wrapper returning data on the stack
Andrew Borley wrote: On 12/1/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Andy, I think that the Python service wrapper sometimes returns data on the stack, the data allocated by PyValue appears to be valid inside the wrapper itself but gets out of scope after the wrapper has returned, causing memory violations or garbage to be returned. Could you please take a look at my change under revision r481279? I copied a char* into a new string to workaround the particular case I ran into, but there's probably a better way to fix this and make sure that strings returned by the wrapper in general are allocated on the heap instead of the stack. Thanks... -- Jean-Sebastien Hi Sebastien, This change looks good, thanks. It strikes me that we may need some kind of extension-builder's library that can be used to manage data and the conversion of data and other chunks of code that we are seeing repeated in various places in the extensions. With something like this, issues such as the one you found above should be found fixed earlier. What do people think? Cheers Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Andy, Yes, I completely agree. The following would help a lot: 1. A utility to navigate an SDO and get the parameters out, whatever form of SDO it is (open, not open, with lists, no lists, with a schema, with no schema at all) 2. A utility to put parameters of an invocation into an SDO, covering all these cases as well 3. Additions to our Operation object and/or additional utility classes to facilitate data handling: -in particular data type conversions, using pieces (1) and (2) above + any other data conversions we've identified, - memory allocations and any copies, - pass by reference vs pass by value semantics, - log and debugging code to help track what data flows from where to where, ... and make it clear to the extension developer who allocates / frees the data and when. I have started to tackle (1) with my Digging data out of an SDO earlier thread and should be able to contribute this in a day or two, part (2) may or may not build on (1) later I'm not sure... but you're right that we really need to sort out the bigger part (3), and it sounds like you're volunteering for it? :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: conversational infrastructure
Yep you're right - I had a brain spasm. InvocationHandler sounds like
the best option and we can deal with the expirations like we discussed.
Jim
On Dec 4, 2006, at 9:37 AM, Ignacio Silva-Lepe wrote:
Hmm, maybe I am missing something, but doesn't an
invocation handler get called for any operation and then it
decides what chain to follow?
On 12/4/06, Jim Marino [EMAIL PROTECTED] wrote:
Maybe I wasn't clear from this post...I don't think it can.
Invocation handlers are per operation as well so they can't share
state that is per client. The semantics of start/continue/stop are
that multiple operations could call start and the client needs to
track where it is in the conversation. So, we need a marker for if
the conversation has begun for the client instance. Right now,
invocation handlers don't have per-client state and this really seems
like a different concern than an invocation handler, which is to
create a message and fire it down the chain. Do you think it would be
better to have the start/continue interceptor per chain and have
interceptor instances share a marker per wire (I just sent another
note on that)?
Jim
On Dec 4, 2006, at 9:24 AM, Ignacio Silva-Lepe wrote:
Yeah, my current feeling is that the invocation handler can keep
track of the state of the conversation as well as the interceptor
does at the moment.
On 12/4/06, Jim Marino [EMAIL PROTECTED] wrote:
The problem with moving this into the invocation handler is
that we
need a mechanism to track state for whether the client believes
the
conversation has begun. For example:
interface ConverSationalService {
void operation1();
void operation2();
void end();
}
Calling operation1 or operation2 will start the conversation, and
subsequent calls to those two will continue the conversation.
We will
need to come up with a mechanism for handling this. Are you
proposing
to create a type of key class that contains the conversational key
value and a flag of its sequence? If we do this, we can
continue to
use the interceptors as they become stateless.
Jim
On Dec 4, 2006, at 6:50 AM, Ignacio Silva-Lepe wrote:
As it turns out, there's a problem with 7 below. The key to a
ConversationSequenceInterceptor is that the same instance is
used for all conversational operations except the ones that end
the conversation, with this instance maintaining a flag to
determine
whether the conversation is starting or not. However, since
interceptors are part of a chain, if we try to use a single
instance
of a given interceptor for more than one operation, we are
effectively
merging the corresponding chains at the point the interceptor is
inserted. In our case, the interceptor is being inserted at the
head,
so we basically bypass all other interceptors for all chains but
the
last one. In the sample, one of the operations happens to be
one-
way
but its non-blocking interceptor is being bypassed and so we
lose
its async behavior.
I am checking in a fix that moves the behavior provided by the
conversational interceptors (as well as the wire post
processor) to
the AbstractOutboundInvocationHandler and that disables the wire
post processor by removing its entry from core/
implementation.scdl.
On 11/27/06, Jim Marino [EMAIL PROTECTED] wrote:
snip/
7. I added two interceptors that will be inserted into
invocation
chains between conversational implementations.
ConversationSequenceInterceptor will be inserted into all
operations
except ones marked @EndConversation. This interceptor tracks
the
conversation sequence the operation is invoked in (start or
continue). This is necessary so the scope container knows
whether to
create a new instance or return an existing one (since
conversation
ids may be reused). Each operation for a wire receives the same
instance of the ConversationSequenceInterceptor, which is
inserted in
the wire post-process phase by
ConversationWirePostProcessor. For
operations marked with @EndConversation, a
ConversationEndInterceptor
is inserted.
snip/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build failure with databinding-jaxb ?
Hi, Luciano.
Can you refresh from SVN and try again? I hope 482335 will help even I'm not
seeing the problem without the change.
Thanks,
Raymond
- Original Message -
From: Luciano Resende [EMAIL PROTECTED]
To: tuscany-dev tuscany-dev@ws.apache.org
Sent: Monday, December 04, 2006 11:19 AM
Subject: Build failure with databinding-jaxb ?
I'm trying a clean build with a clean local maven repo and I'm not
being
able to build with the following error...
Ideas ?
Compiling 7 source files to
X:\java\sca\services\databinding\databinding-jaxb\target\classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
X:\java\sca\services\databinding\databinding-jaxb\src\main\java\org\apache\tuscany\databinding\jaxb\XMLStreamReader2JAXB.java:[24,24]
package javax.xml.stream does not exist
X:\java\sca\services\databinding\databinding-jaxb\src\main\java\org\apache\tuscany\databinding\jaxb\XMLStreamReader2JAXB.java:[34,63]
cannot find symbol
symbol: class XMLStreamReader
public class XMLStreamReader2JAXB extends
TransformerExtensionXMLStreamReader, Object implements
X:\java\sca\services\databinding\databinding-jaxb\src\main\java\org\apache\tuscany\databinding\jaxb\XMLStreamReader2JAXB.java:[35,20]
cannot find symbol
symbol: class XMLStreamReader
PullTransformerXMLStreamReader, Object {
X:\java\sca\services\databinding\databinding-jaxb\src\main\java\org\apache\tuscany\databinding\jaxb\XMLStreamReader2JAXB.java:[41,28]
cannot find symbol
symbol : class XMLStreamReader
location: class org.apache.tuscany.databinding.jaxb.XMLStreamReader2JAXB
X:\java\sca\services\databinding\databinding-jaxb\src\main\java\org\apache\tuscany\databinding\jaxb\Node2JAXB.java:[45,40]
cannot access javax.xml.stream.XMLEventReader
file javax\xml\stream\XMLEventReader.class not found
Object result = unmarshaller.unmarshal(source);
X:\java\sca\services\databinding\databinding-jaxb\src\main\java\org\apache\tuscany\databinding\jaxb\JAXB2Node.java:[47,22]
cannot access javax.xml.stream.XMLEventWriter
file javax\xml\stream\XMLEventWriter.class not found
marshaller.marshal(JAXBContextHelper.createJAXBElement(
tContext.getSourceDataType(), source),
X:\java\sca\services\databinding\databinding-jaxb\src\main\java\org\apache\tuscany\databinding\jaxb\XMLStreamReader2JAXB.java:[56,15]
cannot find symbol
symbol : class XMLStreamReader
location: class org.apache.tuscany.databinding.jaxb.XMLStreamReader2JAXB
--
Luciano Resende
http://people.apache.org/~lresende
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: New proposal to make DAS/SDO HOW TO
Hi Adriano and William Any progress with the HOW-TO ? Any blocking issues ? Any help, guidance needed ? - Luciano On 11/17/06, Katja [EMAIL PROTECTED] wrote: Hi Willian! Thanks for your test! Now I found my error and everything works! The problem was, that in the bigbank sample a mapping between the table and the SDO is used. The SDO classes are generated from WSDL with XSD2SDO. The mapping connects these classes to the tables. In the original bigbank sample the DASAccountConfiguration.xml looks like: Table tableName=STOCKS typeName=StockSummary Column columnName=ID propertyName=id / Column columnName=Symbol propertyName=symbol / Column columnName=quantity propertyName=quantity / Column columnName=purchasePrice propertyName=purchasePrice / Column columnName=PURCHASEDATE propertyName=purchaseDate converterClassName= bigbank.account.services.accountdata.AccountDataServiceDASImpl$DateConverter / /Table I had problems with the Timestamp-column PURCHASEDATE only because it was misspelled. The right spelling of the column name is purchaseDate. I changed it, and now it works. Maybe this should be changed in the repository to prevent others of this error. If you are interested, here is the code which is used to read from the database: //Reading mapping from DASAccountConfiguration.xml InputStream mapping = createConfigStream(); Connection conn = getConnection(); DAS das = DAS.FACTORY.createDAS(mapping, conn); Command select = das.createCommand(SELECT Symbol, quantity, purchasePrice, purchaseDate, purchaseLotNumber FROM stocks where id = ?); select.setParameter(1, customerID); DataObject root = select.executeQuery(); accountReport.getStockSummaries().addAll(root.getList(StockSummary)); Thanks, Katja Original-Nachricht Datum: Thu, 16 Nov 2006 18:00:26 + Von: Willian Maja [EMAIL PROTECTED] An: tuscany-dev@ws.apache.org Betreff: Re: New proposal to make DAS/SDO HOW TO I think I didn't understand what you want. But i tested using TimeStamp and DateTime: CREATE TABLE test (ID integer not null AUTO_INCREMENT, timestamp timestamp, datetime datetime, primary key (ID)); INSERT INTO test VALUES (); This will create the following row: | 1 | 2006-11-16 14:10:24.0|NULL Now I will read the timestamp: Command read = das.createCommand(select * from test); DataObject root = read.executeQuery(); DataObject node = root.getDataObject(test[1]); java.util.Date date = node.getDate(timestamp); // You must use java.util.Date, not java.sql.Date System.out.println(date.getHours()); // Print the hours System.out.println(date.getMonth()); // Print the month System.out.println(node.getDate(date)); // Print the TimeStamp ex:2006-11-16 14:12:23.0 To save DateTime I used the following code: //Continuing the last code, I'm going to save the TimeStamp in the DateTime column node.setDate(datetime, date); das.applyChanges(root); Now the row 1 from the test table will be: | 1 | 2006-11-16 14:10:24.0|2006-11-16 14:10:24.0 I read/updated the row with datetime and timestamp column. If this wasn't what you want, please send me the code you want to make work with SDO/Mysql. From: Katja [EMAIL PROTECTED] Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: New proposal to make DAS/SDO HOW TO Date: Thu, 16 Nov 2006 17:29:58 +0100 Hi Willian! Thank you for the example! You tested with a Date-Column, that worked in my application, too, because no conversion between the column and the data object value is necessary. With DateTime a converter is needed: SDO format: 2006-11-16T17:22 MySQL format: 2006-11-16 17:22 The bigbank sample has a DateConverter for this issue, but this does only work with Derby and not with MySQL. I don't know why. I posted the error last time: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg10725.html It would be great, if you could test again with a DateTime or Timestamp column and tell me your solution. Thanks, Katja Original-Nachricht Datum: Thu, 16 Nov 2006 16:08:48 + Von: Willian Maja [EMAIL PROTECTED] An: tuscany-dev@ws.apache.org Betreff: Re: New proposal to make DAS/SDO HOW TO Hi Katja, I've just tested to read Date column, and it works. I'm going to paste my code here for you: This will be the test table, it's just a simple table with a DateTime Column. CREATE TABLE test (ID integer not null AUTO_INCREMENT, date_column date); INSERT INTO test (date_column) VALUES (06-11-16); Now you should create your Das connection. In my code example I'll not use XML configuration. I'm going to create the Command: Command read = das.createCommand(select * from test); //Create the Command DataObject root = read.executeQuery();
MySQL Tuscany DAS in Tomcat
I was having some issues configuring a MySQL in Tomcat... after I finlay found the right way of fixing the issue, I posted bloged with the necessary steps on how to do it, and how to connect DAS to the datasource... If you find interesting, here it is : http://lresende.blogspot.com/ -- Luciano Resende http://people.apache.org/~lresende
Re: Build failure with databinding-jaxb ?
Thanks, looks like all set now.
On 12/4/06, Raymond Feng [EMAIL PROTECTED] wrote:
Hi, Luciano.
Can you refresh from SVN and try again? I hope 482335 will help even I'm
not
seeing the problem without the change.
Thanks,
Raymond
- Original Message -
From: Luciano Resende [EMAIL PROTECTED]
To: tuscany-dev tuscany-dev@ws.apache.org
Sent: Monday, December 04, 2006 11:19 AM
Subject: Build failure with databinding-jaxb ?
I'm trying a clean build with a clean local maven repo and I'm not
being
able to build with the following error...
Ideas ?
Compiling 7 source files to
X:\java\sca\services\databinding\databinding-jaxb\target\classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
X:\java\sca\services\databinding\databinding-jaxb\src\main\java\org\apache\tuscany\databinding\jaxb\XMLStreamReader2JAXB.java:[24,24]
package javax.xml.stream does not exist
X:\java\sca\services\databinding\databinding-jaxb\src\main\java\org\apache\tuscany\databinding\jaxb\XMLStreamReader2JAXB.java:[34,63]
cannot find symbol
symbol: class XMLStreamReader
public class XMLStreamReader2JAXB extends
TransformerExtensionXMLStreamReader, Object implements
X:\java\sca\services\databinding\databinding-jaxb\src\main\java\org\apache\tuscany\databinding\jaxb\XMLStreamReader2JAXB.java:[35,20]
cannot find symbol
symbol: class XMLStreamReader
PullTransformerXMLStreamReader, Object {
X:\java\sca\services\databinding\databinding-jaxb\src\main\java\org\apache\tuscany\databinding\jaxb\XMLStreamReader2JAXB.java:[41,28]
cannot find symbol
symbol : class XMLStreamReader
location: class org.apache.tuscany.databinding.jaxb.XMLStreamReader2JAXB
X:\java\sca\services\databinding\databinding-jaxb\src\main\java\org\apache\tuscany\databinding\jaxb\Node2JAXB.java:[45,40]
cannot access javax.xml.stream.XMLEventReader
file javax\xml\stream\XMLEventReader.class not found
Object result = unmarshaller.unmarshal(source);
X:\java\sca\services\databinding\databinding-jaxb\src\main\java\org\apache\tuscany\databinding\jaxb\JAXB2Node.java:[47,22]
cannot access javax.xml.stream.XMLEventWriter
file javax\xml\stream\XMLEventWriter.class not found
marshaller.marshal(JAXBContextHelper.createJAXBElement(
tContext.getSourceDataType(), source),
X:\java\sca\services\databinding\databinding-jaxb\src\main\java\org\apache\tuscany\databinding\jaxb\XMLStreamReader2JAXB.java:[56,15]
cannot find symbol
symbol : class XMLStreamReader
location: class org.apache.tuscany.databinding.jaxb.XMLStreamReader2JAXB
--
Luciano Resende
http://people.apache.org/~lresende
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Luciano Resende
http://people.apache.org/~lresende
Re: Pass-by-value support for remotable interfaces
Hi Raymond, Thanks. I have started with this and here are a couple of questions that I need help with. I believe the PassByValue Interceptor is good to be on the Inbound Invocation chain of the server component. Accordingly I looked up the DataBindingWirePostProcessor's method - public void process(OutboundWire source, InboundWire target) to do this. Over here I added the PassbyValue interceptor to the 'target'. But this did not invoke the interceptor. If I added it to the source then the interceptor gets invoked. So, am I missing something here? I understand that the interceptor that you have attached is for the default Java binding case. I will work on the databinding dependent case once I get this default stuff working. Thanks - Venkat On 12/4/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Venkat. Thank you for volunteering. I opened a JIRA http://issues.apache.org/jira/browse/TUSCANY-969 and attached some prototype code there. Hopefully it can get you started. Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Sunday, December 03, 2006 10:08 PM Subject: Re: Pass-by-value support for remotable interfaces Hi Raymond, I'm interested in helping with this. It will give me a chance to work with the service invocation paths of the core. Let me know if there is something that I help with. Thanks. - Venkat On 11/30/06, Raymond Feng [EMAIL PROTECTED] wrote: - Original Message - From: Mike Edwards [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, November 29, 2006 7:07 AM Subject: Re: Pass-by-value support for remotable interfaces Raymond, First point I need to make is that just because two components are in the same composite does not mean that they are automatically running in the same VM or even the same operating system process. Composites can span components running on different nodes (node = machine and/or o/s process). Good catch. Consider a composite which had component A implemented in Java and component B implemented in C++. Not likely that they would run in the same runtime process (certainly not with the current Tuscany runtime). This is perfectly OK as long as any interface between them is remotable. Second, more general point to make, is that there may be implied semantics for the interface that depend on the binding used to connect the reference to the service. Consider the case where the interface involves an operation with a message having two references to the same object. When this is sent from consumer to provider (say), does the provider receive 2 separate copies of the object or just one - assuming the consumer started with only 1. The answer is it depends on the binding - RMI-IIOP says there is only 1 copy. Web Services says there are 2 copies... I don't think that SCA can hide these subtle differences, much though we may like to do so. However, what we must guarantee is that the behaviour matches the binding type - if the internal wire uses binding.ws, for example, then we provide Web services semantics. This must be true for any optimisations we may like to use in the case where both ends of the wire are in 1 process - since for a remotable interface this proximity is accidental and could be changed by a subtle change in deployment. That leaves open what to do in the case of binding.ws. We may need a way for the composition to indicate the type of semantics required - or we could default to one form (eg Web services...) Should this be clarified by the SCA spec on pass-by-value? Yours, Mike. Raymond Feng wrote: Hi, I'm talking about the following: componentA.reference -- componentB.service1 non-SCA client -- componentB.service1 In the cases above, componentA and componentB are in the same composite (in the same VM). Both the service and reference are declared with a remotable interface. We need to have an interceptor to deal with the pass-by-value. For the following wirings: .. -- composite.reference composite.service -- ... I assume the binding implementation for the composite reference/service will handle the pass-by-value naturally over the transport. Thanks, Raymond snip - 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: Pass-by-value support for remotable interfaces
Hi, Can you debug to see how the interceptors are chained? It could be a bit tricky to make sure the new interceptor is added to the correct position. Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, December 04, 2006 4:16 PM Subject: Re: Pass-by-value support for remotable interfaces Hi Raymond, Thanks. I have started with this and here are a couple of questions that I need help with. I believe the PassByValue Interceptor is good to be on the Inbound Invocation chain of the server component. Accordingly I looked up the DataBindingWirePostProcessor's method - public void process(OutboundWire source, InboundWire target) to do this. Over here I added the PassbyValue interceptor to the 'target'. But this did not invoke the interceptor. If I added it to the source then the interceptor gets invoked. So, am I missing something here? I understand that the interceptor that you have attached is for the default Java binding case. I will work on the databinding dependent case once I get this default stuff working. Thanks - Venkat On 12/4/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Venkat. Thank you for volunteering. I opened a JIRA http://issues.apache.org/jira/browse/TUSCANY-969 and attached some prototype code there. Hopefully it can get you started. Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Sunday, December 03, 2006 10:08 PM Subject: Re: Pass-by-value support for remotable interfaces Hi Raymond, I'm interested in helping with this. It will give me a chance to work with the service invocation paths of the core. Let me know if there is something that I help with. Thanks. - Venkat On 11/30/06, Raymond Feng [EMAIL PROTECTED] wrote: - Original Message - From: Mike Edwards [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, November 29, 2006 7:07 AM Subject: Re: Pass-by-value support for remotable interfaces Raymond, First point I need to make is that just because two components are in the same composite does not mean that they are automatically running in the same VM or even the same operating system process. Composites can span components running on different nodes (node = machine and/or o/s process). Good catch. Consider a composite which had component A implemented in Java and component B implemented in C++. Not likely that they would run in the same runtime process (certainly not with the current Tuscany runtime). This is perfectly OK as long as any interface between them is remotable. Second, more general point to make, is that there may be implied semantics for the interface that depend on the binding used to connect the reference to the service. Consider the case where the interface involves an operation with a message having two references to the same object. When this is sent from consumer to provider (say), does the provider receive 2 separate copies of the object or just one - assuming the consumer started with only 1. The answer is it depends on the binding - RMI-IIOP says there is only 1 copy. Web Services says there are 2 copies... I don't think that SCA can hide these subtle differences, much though we may like to do so. However, what we must guarantee is that the behaviour matches the binding type - if the internal wire uses binding.ws, for example, then we provide Web services semantics. This must be true for any optimisations we may like to use in the case where both ends of the wire are in 1 process - since for a remotable interface this proximity is accidental and could be changed by a subtle change in deployment. That leaves open what to do in the case of binding.ws. We may need a way for the composition to indicate the type of semantics required - or we could default to one form (eg Web services...) Should this be clarified by the SCA spec on pass-by-value? Yours, Mike. Raymond Feng wrote: Hi, I'm talking about the following: componentA.reference -- componentB.service1 non-SCA client -- componentB.service1 In the cases above, componentA and componentB are in the same composite (in the same VM). Both the service and reference are declared with a remotable interface. We need to have an interceptor to deal with the pass-by-value. For the following wirings: .. -- composite.reference composite.service -- ... I assume the binding implementation for the composite reference/service will handle the pass-by-value naturally over the transport. Thanks, Raymond snip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java SDO Question: Native support for commonj.sdo/xml data model
Frank, Do you mind my opening a JIRA to track this requirement? I think the users may need commonj.sdo/xml namespace for defining SDO types programmatically to control the format of XML serialization. Fuhwei Frank Budinsky [EMAIL PROTECTED] wrote: Hi Fuhwei, you are right that we should preregister commonj.sdo/xml. We haven't really needed it for anything before now ... that's the only reason we don't have it already. Frank. Fuhwei Lwo wrote on 12/04/2006 09:15:58 AM: I found the current Java SDO runtime has natively registered and supported commonj.sdo and commonj.sdo/java data model but I didn't see commonj.sdo/xml was registered and supported. Shouldn't commonj.sdo/xml be part of SDO's core model? Thanks in advance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r482313
On Dec 4, 2006, at 2:32 PM, Raymond Feng wrote: Hi, The build is broken due to this check-in. Should AbstractConversationTestCase be fixed? I went ahead and fixed it with r482469, including the related testcases in core/integration/conversation. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New proposal to make DAS/SDO HOW TO
OK, I've finished the tests on the methods I created for the howto and
everything seems to be working fine. As Luciano suggested there is no need
to make a jsp for the howto, so I think it's time to start writing the
howto, right Willian? Below the .java, .xml and the tables I've created for
this webapp.
ShoppingCart.java
package org.apache.tuscany.samples.web;
import java.io.IOException;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.sql.Statement;
import java.util.Vector;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.tuscany.das.rdb.Command;
import org.apache.tuscany.das.rdb.DAS;
import commonj.sdo.DataObject;
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
public class CommandServlet extends HttpServlet {
private static final long serialVersionUID = 1922159305255311505L;
public CommandServlet() {}
@Override
protected void doGet(HttpServletRequest arg0, HttpServletResponse arg1)
throws ServletException, IOException {
Statement s = null;
CommandServlet shoppingCart = new CommandServlet();
try {
s = getConnection().createStatement();
s.executeUpdate(delete from cart_item;);
s.executeUpdate(delete from item;);
s.executeUpdate(delete from cart;);
s.execute(commit;);
s.close();
} catch (Exception e) {
e.printStackTrace();
}
shoppingCart.newCart();
shoppingCart.newItem(motherboard, 5);
shoppingCart.newItem(mouse, 90);
shoppingCart.newItem(processor, 23);
shoppingCart.newItem(keyboard, 68);
Vector allCarts = new Vector(getCarts());
DataObject cart = (DataObject) allCarts.firstElement();
int cartId = cart.getInt(ID);
ArrayList allItems = new ArrayList(getItems());
int c = 0;
int itemId = 0;
for (Iterator it = allItems.iterator(); it.hasNext();) {
c++;
DataObject item = (DataObject) it.next();
itemId = item.getInt(ID);
addCartItem(cartId, itemId, c);
}
removeCartItem(cartId, itemId);
confirmOrder(cartId);
shoppingCart.print();
}
public void print() {
ArrayList carts = new ArrayList(getCarts());
ArrayList items = new ArrayList(getItems());
for (Iterator it1 = carts.iterator(); it1.hasNext();) {
DataObject cart = (DataObject) it1.next();
ArrayList cartItems = new ArrayList(getCartItems(cart.getInt
(ID)));
System.out.println(Cart + cart.getInt(ID) + :);
System.out.println(Items:);
for (Iterator it2 = cartItems.iterator(); it2.hasNext();) {
DataObject itemCart = (DataObject) it2.next();
DataObject item = getItem(itemCart.getInt(ITEM_ID));
System.out.println( + item.getString(DESCR) +
- + itemCart.getInt(QUANTITY) + units);
}
System.out.println(Subtotal: + cart.getFloat
(SUB_TOTAL));
System.out.println(Tax: + cart.getFloat(TAX));
System.out.println(Total: + cart.getFloat(TOTAL) +
\n);
}
for (Iterator it = items.iterator(); it.hasNext();) {
DataObject item = (DataObject) it.next();
System.out.println(Item + item.getInt(ID) + :);
System.out.println(Description: + item.getString
(DESCR));
System.out.println(Units: + item.getInt(UNITS) + \n);
}
}
public DataObject getItem(int itemId) {
DAS das = DAS.FACTORY.createDAS
(getClass().getClassLoader().getResourceAsStream(ShoppingCartConfig.xml),
getConnection());
Command command = das.getCommand(get item);
command.setParameter(1, itemId);
DataObject item = command.executeQuery();
return item.getDataObject(ITEM[1]);
}
public void newCart() {
DAS das = DAS.FACTORY.createDAS
(getClass().getClassLoader().getResourceAsStream(ShoppingCartConfig.xml),
getConnection());
Command command = das.getCommand(all carts);
DataObject allCarts = command.executeQuery();
DataObject newCart = allCarts.createDataObject(CART);
newCart.setInt(CONFIRMED, 0);
allCarts.getList(CART).add(newCart);
das.applyChanges(allCarts);
}
public void newItem(String description, int units) {
DAS das = DAS.FACTORY.createDAS
(getClass().getClassLoader().getResourceAsStream(ShoppingCartConfig.xml),
getConnection());
Command command = das.getCommand(all items);
DataObject allItems = command.executeQuery();
DataObject newItem = allItems.createDataObject(ITEM);
newItem.setString(DESCR, description);
newItem.setInt(UNITS, units);
allItems.getList(ITEM).add(newItem);
Re: Java SDO Question: Native support for commonj.sdo/xml data model
Fuhwei, I agree we need to add support for the xmlElement global property. Actually, Yang has volunteered to do it soon. Go ahead and open the JIRA. Thanks, Frank. Fuhwei Lwo [EMAIL PROTECTED] wrote on 12/04/2006 08:24:35 PM: Frank, Do you mind my opening a JIRA to track this requirement? I think the users may need commonj.sdo/xml namespace for defining SDO types programmatically to control the format of XML serialization. Fuhwei Frank Budinsky [EMAIL PROTECTED] wrote: Hi Fuhwei, you are right that we should preregister commonj.sdo/xml. We haven't really needed it for anything before now ... that's the only reason we don't have it already. Frank. Fuhwei Lwo wrote on 12/04/2006 09:15:58 AM: I found the current Java SDO runtime has natively registered and supported commonj.sdo and commonj.sdo/java data model but I didn't see commonj.sdo/xml was registered and supported. Shouldn't commonj.sdo/xml be part of SDO's core model? Thanks in advance. - 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: How to make sub-project build/participation easier?
Hi Yang, Really not sure if you bulid SCA and DAS to get thro to SDO. There was a mail from Jeremy were he put down the order in which these things should be built will see if I can trace that. But I vividly remember having to build SDO for SCA and not viceversa. - Venkat On 12/5/06, Yang ZHONG [EMAIL PROTECTED] wrote: I was trying to build SDO stand-alone. It always complained parent-2-incubator-SNAPSHOT.pom can't be downloaded. Thanks to Raymond for pointing out parent-2-incubator-SNAPSHOT.pom is a generated artifact. In order to build at root to generate parent-2-incubator-SNAPSHOT.pom, I had to download and build too many sub-projects including SCA, DAS, spec/SCA, spec/DAS?, distribution/SCA, sampleapps and samples. Even if it's a one-time setup, is there any way to make sub-project build/participation easier please? If yes, can we document that please? -- Yang ZHONG
