Hi Kelvin,
I'm in the process of re-organizing our test suite to remove
dependencies on internal classes and I am trying to run the tests
against a current snapshot of Tuscany. I have hit a problem early on
that is causing many tests to fail.
I'm not sure of the correct process for getting questions like this
answered so I'm posting here but please let me know if I should be
posting a JIRA.
The following method is used to create a sample document that many of
the tests then use:
public static XMLDocument createProductCatalogDocument() {
// create a test document using the SDO API
String xml = "<catalog></catalog>";
XMLDocument doc = getXMLHelper().load(xml);
DataObject catalog = doc.getRootObject();
for (int i = 0; i < 10; i++) {
DataObject product = catalog.createDataObject("product",
"commonj.sdo", "DataObject");
product.setInt("identifier", i);
product.setString("theName", "Product #" + i);
product.setString("theDescription", "This is a description
of product #" + i);
product.setBigDecimal("thePrice", new BigDecimal(i * 1.5));
product.setDate("theDate", new Date());
}
return doc;
}
The code is failing on the line that attempts to create an open-content
property "product" with the error "Class 'AnyTypeDataObject' does not
have a feature named 'product'".
In the RW implementation this code works because the root DataObject
representing the "catalog" element is an open DataObject (of type
commonj.sdo#DataObject). However, Tuscany is creating the root object
with the type http://www.apache.org/tuscany/2005/SDO#AnyTypeDataObject.
This appears to be an open type e.g. getType().isOpen() returns true but
it is not letting me create the open content property "product".
Is this a bug in Tuscany or am I doing something incorrect in my use of
Tuscany?
Thanks,
Andy.
-----Original Message-----
From: kelvin goodson [mailto:[EMAIL PROTECTED]
Sent: 02 November 2006 10:12
To: [email protected]
Subject: Re: SDO Java: Getting Involved -- Tests/Samples
Having tried to respond to Andy's note a couple of times today in a way
that
was not open to misinterpretation I 'phoned Andy up. I made the point
that
what we need to be aiming at is open integration of the RogueWave source
into Tuscany, and that a process of making drops of code is not a good
fit, as we must cater for the possibility of other members of the
community
having made updates to the tests. So I would say that the ideal way
forward
is that RogueWave create patches for any updates for code that has been
put
into the repository and I or another committer will apply them. If in
this
startup phase you would prefer for a while to continue to attach drops
of
code to JIRAs then I can apply the updates, The code drop process would
have
to include the possibility of me sending you back the updated code if it
turned out that modifications had been made to the code between drops.
It
would be great to get you into the mode of creating patches and I'm
willing
to help you get set up for that if you would like. It would be really
good
to aim for having some RogueWave committers!
Best Reards, Kelvin.
On 01/11/06, Andy Grove (Contractor) <[EMAIL PROTECTED]> wrote:
>
>
> I've just become involved in the effort to make our test suite
available
> and we have an internal meeting later today to discuss the procedures
> around this. I would have thought that the first sensible step would
be
> for us to split out our current tests into two packages - those that
> have dependencies on RW internal classes and those that don't. That
way
> we can provide regular code drops of the generic tests (avoiding the
> need to provide diffs when we make changes) and we can gradually
migrate
> tests from the RW suite to the generic suite.
>
> Does that sound like a workable solution?
>
> Thanks,
>
> Andy.
>
>
> -----Original Message-----
> From: kelvin goodson [mailto: [EMAIL PROTECTED]
> Sent: 01 November 2006 10:05
> To: [email protected]
> Subject: Re: SDO Java: Getting Involved -- Tests/Samples
>
> Andy,
> that's great thanks. This begs the question of how we proceed with
> code
> edits. Would you able to supply any updates you make as patches
> attached to
> a JIRA. I can then apply them to the code in svn. If you need any
help
> with that I'm more than happy to help. (If you want interactive help
> I'm
> likely to be watching the IRC channel as "kgoodson" on the #Tuscany
> channel
> on irc.freenode.net.)
>
> It would be good to understand how you are currently working with this
> code
> in terms of source code control etc. and what your plans are as we
move
> forward with this effort.
>
> Best Regards, Kelvin.
>
> On 01/11/06, Andy Grove (Contractor) <[EMAIL PROTECTED] > wrote:
> >
> > Hi Kelvin,
> >
> > I agree with your edits to the createTestObjectTypes() test in
> > DataObjectListTest. This was clearly wrong. This has highlighted a
> > general issue on some of our tests which we are now rectifying.
> >
> > We are also investigating issues around INSTANCE variables and I
agree
> > that we should at least avoid using them in the test cases so that
we
> > can isolate the tests. I'll progress this here and get the tests
> > amended.
> >
> > I like the idea of having one vendor-specific TestHelperImpl
> abstracted
> > by an interface. I'll start the process of amending out tests to use
> > that.
> >
> > Thanks,
> >
> > Andy Grove.
> >
> > -----Original Message-----
> > From: Bryan Luoma [mailto: [EMAIL PROTECTED]
> > Sent: 31 October 2006 19:58
> > To: [email protected]
> > Subject: RE: SDO Java: Getting Involved -- Tests/Samples
> >
> > Thanks Kelvin,
> >
> >
> >
> > I attached the XML instance documents (testdata.zip) referenced from
> the
> > junit test XMLDataObjectTest.java
> >
> > https://issues.apache.org/jira/browse/TUSCANY-829
> >
> >
> >
> > The archive consists of the following documents:
> >
> > - catalog-10.xml
> >
> > - w3_sample.wsdl
> >
> > - lists.xml
> >
> > - simple.xml
> >
> >
> >
> > We are looking into the other questions/concerns and will be
addressed
> > shortly.
> >
> >
> >
> > Thanks,
> >
> > Bryan
> >
> >
> >
> >
> >
> > ________________________________
> >
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On
> Behalf
> > Of kelvin goodson
> > Sent: Monday, October 30, 2006 2:22 PM
> > To: [email protected]
> > Cc: Bryan Luoma
> > Subject: Re: SDO Java: Getting Involved -- Tests/Samples
> >
> >
> >
> > I added the tests that were attached to TUSCANY-829 to my sandbox
and
> > made some changes, see
> > http://svn.apache.org/viewvc?view=rev&revision=469239
> >
> > The exercise has turned up issues in a number of areas; Tuscany
> > specific, interoperability, ...
> >
> > Looking at DataObjectListTest, one specific thing I'd like to
> understand
> > is what was intended in the method createTestObjectTypes(). What it
> > seemed to be doing is creating a very open model by setting the type
> of
> > the product2 property to commonj.sdo.DataObject, i.e. a mixed,
> > sequenced, open type that can hold pretty much anything, whereas
what
> I
> > think was intended was that this property should be of type newType2
> > (i.e. the type with name "product2"). Frank began looking at this
> with
> > the view that what was intended was the former arrangement, and the
> > failures we were getting has highlit an issue with Tuscany that we
> don't
> > create global properties to accompany type definitions created with
> > TypeHelper.define(), and we think we probably should, so I have
> opened
> > TUSCANY-887 to cover this. This was a useful catch, but then I have
> > taken the view that what was intended was that the type of the
> product2
> > property should have been product2, and so I have changed the type
> > creation method, and I have altered the test to fit this, can you
> > please take a look to see if I am right. You can see the diff at
....
> >
>
http://svn.apache.org/viewvc/incubator/tuscany/sandbox/kgoodson/roguewav
> >
>
e-tests/src/test/java/com/roguewave/rwsf/sdo/DataObjectListTest.java?r1=
> > 469239&r2=469238&pathrev=469239
> >
> > We have one remaining test failure in this test case which is the
> > testSubList() test, which I think may have revealed another Tuscany
> > issue, but I haven't dug into that yet.
> >
> > I have altered the TestHelper to give implementations that I think
> will
> > work when used by the XMLDataObjectTest but I haven't got close to
> > running that one yet. All the XMLDocumentTestCase tests currently
> fail
> > because of the setUp method, which requires access to the test
data,
> > so if you could attach that data to TUSCANY-829 that would be great,
> > thanks.
> >
> > I've commented out some test cases that I didn't immediately know
what
> > to do with, and added TODO flags to remind me to deal with those.
> > In some places the assertions are for RogueWave specific
> implementation
> > details such as
> >
> > // ensure we default to caching on
> >
> > assertEquals(((XMLDocumentImpl)doc).getOption("xpath-caching"),
> > "true");
> >
> > assertEquals(3, docImpl.getXPathCacheSize());
> >
> >
> > As to the more general points that can be gleaned from this
exercise,
> > this is what I have so far ....
> >
> > My guess is that with the improvements in the 2.1 spec we can begin
to
> > move much of the function that is found in TestHelper back out to
the
> > tests themselves, or at least code them as support methods in terms
> of
> > the SDO 2.1 API. I have some half baked ideas about how in general
to
> > abstract away any required implementation specific behaviour, but
not
> > sufficiently well formed to be aired just yet.
> >
> > We have recently tried to remove as many references to the INSTANCE
> > fields in our Tuscany tests as possible, because they can cause
cross
> > test interference. Maven builds an uber-test from all the *
> > TestCase.java files, and runs that test as a single process, so
> > alterations to the state of say TypeHelper.INSTANCE in one test
class
> > can influence the execution of tests in another. So now we tend to
> > create local instances of the Helpers. The SDO spec group has a
> > proposal for deprecating the INSTANCE fields, which was intended to
> be
> > aimed at SDO 3, but there's a chance that it might come into SDO
> 2.1,
> > so we may be helped here with a new way of accessing helpers.
> >
> > An easy rule to create is that no test case in the shared set of
tests
> > can directly import a class from an org.apache.tuscany.* package,
nor
> > from a com.roguewave.* package. If the test requires some
> > implementation specific behaviour then that code must be housed in
> > something like a TestHelperImpl class.
> >
> > I've been making notes on the wiki at
> >
http://wiki.apache.org/ws/Tuscany/TuscanyJava/Tests/RogueWave/Samples ,
> > but these are the main points distilled from that raw dump. I'll
keep
> > looking at the remaining issues and post more here soon.
> >
> > Regards, Kelvin.
> >
> >
> >
> > On 18/10/06, Bryan Luoma < [EMAIL PROTECTED] > wrote:
> >
> > Hello,
> >
> > I am a member of the QA team at Rogue Wave Software. I work closely
> > with the HydraSDO Development Team on the HydraSDO for XML product
> (C++
> > and Java). I recently attached a couple of sample Java tests that
we
> > currently have in our junit test-suite which exercise HydraSDO for
> XML.
> >
> > The zip archive (sdo.zip) has been attached to the following JIRA:
> > http://issues.apache.org/jira/browse/TUSCANY-829
> >
> > The archive consists of two junit tests (XMLDataObjectTest.java and
> > DataObjectList.java) and a helper class (TestHelper.java).
> >
> > XMLDataObjectTest.java has 120 test-cases that test the DataObject
> > interface. This test uses several underlying RW implementation
> specific
> >
> > classes to perform some of the work. This is not a generic SDO API
> test
> > that is ready to integrate into Tuscany.
> >
> > DataObjectListTest.java has 23 test-cases that test "list"
> functionality
> > of DataObject. This test does not use RW implementation specific
> > classes and should be easier to integrate into Tuscany as is.
> >
> > TestHelper.java is used by XMLDataObjectTest.java to help create
> > DataGraphs and load input files. The TestHelper also uses RW
> > implementation specific classes.
> >
> > We are excited and willing to contribute SDO unit-tests to the
Tuscany
> > project. The purpose of this initial "drop" is to help identify
what
> > steps need to be taken in order to simplify/maximize our
contributions
> > and to benefit from additional SDO API tests authored by the Tuscany
> > project community.
> >
> > Sometime in the near future, RW will attempt to separate the RW
> > implementation specific tests from the generic SDO API tests as much
> as
> > possible. There has also been discussion of implementing an
> abstraction
> > layer that would allow Tuscany and RW to exchange tests to exercise
> the
> > respective products.
> >
> > We also have C++ unit tests (cxxTest Framework) that we use to
> exercise
> > HydraSDO. Sounds like this would be a separate JIRA all together?
> >
> > Thanks,
> > Bryan Luoma
> >
> >
> > -----Original Message-----
> > From: kelvin goodson [mailto: [EMAIL PROTECTED]
> > <mailto: [EMAIL PROTECTED]> ]
> > Sent: Thursday, October 12, 2006 1:46 AM
> > To: [email protected]
> > Subject: Re: SDO Java: Getting Involved -- Tests/Samples
> >
> > Tom,
> > Welcome to Tuscany! that's great! Thanks for offering to get
> > involved.
> > How should we proceed? I'd be most happy to assist you to integrate
> > what
> > you have to offer. We currently have a small collection of tests
> using
> > the
> > junit framework (see
> >
>
https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/impl/src/tes
> > t/java/org/apache/tuscany/sdo/)
> > but there's significant scope for enhancement. BTW I'm going to
make
> my
> > response Java centric as Andrew has offered to help look at the C++
> side
> >
> > of
> > things.
> >
> > How about this for a proposal for how to proceed? I have opened a
> JIRA
> > (this is our issue or bug tracking system if you are not familiar
with
> > these
> > things --- please tell me if you are already an expert). The JIRA
can
> > be
> > seen at http://issues.apache.org/jira/browse/TUSCANY-829 , and you
> can
> > upload attachments to the JIRA, so we could perhaps use that to
first
> > attach a typical RogueWave test or two. I guess it's likely that
> there
> > will
> > be some modifications that need to be made with regards to setting
up
> > the
> > test within our environment, but that way we could play and discuss
> how
> >
> > we
> > might proceed with more tests.
> >
> > How does that sound?
> >
> > Best Regards, Kelvin.
> >
> >
> > On 11/10/06, Andrew Borley < [EMAIL PROTECTED]
> > <mailto: [EMAIL PROTECTED]> > wrote:
> > >
> > > Hi Tom,
> > >
> > > Coming from the C++ side of Tuscany, I know we'd certainly be
> > > interested in those C++ SDO tests - please get involved!
> > >
> > > Cheers
> > > Andrew
> > >
> > > On 10/11/06, T Gould < [EMAIL PROTECTED]> wrote:
> > > > Kelvin -
> > > >
> > > > We at Rogue Wave have been developing an SDO product, HydraSDO,
> and
> > have
> > > a
> > > > seires of tests that might be easiliy modified so as to exercise
> > your
> > > Java
> > > > SDO product. We would be very interested in providing our tests
> as
> > well
> > > as
> > > > helping create a test environment (unless this has already been
> > done) to
> > > > futher test the SDO product. Additionally, we also have C++
> tests.
> > > >
> > > >
> > > > tom gould
> > > > -------------------------------
> > > >
> > > > As the Java M2 release is imminent it occured to me that it
would
> be
> > > really
> > > > useful if there are users out there who are putting our code
> through
> >
> > its
> > > > paces that you may be developing samples/tests which could
> usefully
> > be
> > > > contributed back to the Tuscany project and make it more robust.
> If
> > you
> > > are
> > > > in such a position it would be really great to hear from you.
> > > >
> > > > Regards, Kelvin.
> > > >
> > > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
