Ok, to answer my own question with Jeremy's help. This is just a case of
ambiguous resources in the classpath. The sample has a dependency on
services.databinding, which brings in its sca/default.scdl, apparently ahead
of the sample's default.scdl.
That being said, there does not seem to be a straightforward solution. The
simplest (and most naive) fix could be to make sure that there are no
ambiguous resources in the class path, but that does not seem reasonable.
Another option could be to look up scdls somewhere else other than the
classpath, but I'm going to take a wild guess that I am opening a pandora's
box here. Last but not least, it also seems like we really need an
integration test framework so that we don't have to resort to samples and
test cases to perform integration tests of the axis2/databinding kind.
Again, the pandora's box disclaimer applies here as well.
By the way, all I'm trying to do is to test ws/axis2 callbacks, and any but
the simplest solution becomes a case of having to take more (than two) steps
backwards to achieve one step forward. Needless to say, taking such steps
could lead us to a better place, but it seems it's always a case of the
urgent taking precedence over the important.
Thoughts?
----- Original Message -----
From: "Ignacio Silva-Lepe" <[EMAIL PROTECTED]>
To: "Tuscany Dev" <[email protected]>
Sent: Thursday, September 28, 2006 10:02 AM
Subject: Problem with application scdl URL in SCATestCase, class loader?
I am trying to run HelloWorldWSClientTestCase in the helloworldwsclient
sample. For some reason, when I print the application scdl URL, obtained by
"URL applicationScdlURL = cl.getResource(applicationSCDL);" in SCATestCase,
I get:
+++ application SCDL:
jar:file:/C:/Documents%20and%20Settings/Administrator/.m2/
repository/org/apache/tuscany/sca/services/databinding/databinding-sdo/1.0-incub
ator-M2-SNAPSHOT/databinding-sdo-1.0-incubator-M2-SNAPSHOT.jar!/META-INF/sca/def
ault.scdl
I am a bit a a loss trying to explain how the
services/databinding/databinding-sdo default.scdl is being resolved as
opposed to the default.scdl in the sample. Perhaps there is an issue with
the class loader? I tried looking in the pom.xml for clues but nothing jumps
at me.
Notice that currently the test case is disabled by not having the "TestCase"
suffix in the class and file names, so I created a new file and class with
the suffix in their names and that is what I am trying to run.
Any ideas?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
