[jira] Resolved: (TUSCANY-1204) Support for @requires annotation and requires attribute
[ https://issues.apache.org/jira/browse/TUSCANY-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-1204. - Resolution: Fixed Thanks for the patch... I was not able to apply it as-is to the latest code in the trunk, as the trunk has changed significantly since when this patch was developed, but I have checked in a PolicyProcessor that does the equivalent of what your patch was doing. Also some lines in the patch were wrapped around column 80, I had to hand edit and fix it to make the patch tool consume it. @Requires on the implementation class are added to the assembly Implementation model object. @Requires on service interfaces are added to the corresponding service model object. @Requires on callback interfaces are added to the corresponding callback model object. @Requires on operations are turned into Intents containing a corresponding Operation object. I ported the test case you had contributed to the latest code in trunk, and the test passes, even though I'm not sure if I adapted the test logic to the new policy model structure correctly. It would be great if you could take a look and let me know if I missed anything. Thanks. Support for @requires annotation and requires attribute --- Key: TUSCANY-1204 URL: https://issues.apache.org/jira/browse/TUSCANY-1204 Project: Tuscany Issue Type: New Feature Components: Java SCA Model Reporter: Mark I. Dinges Assigned To: Jean-Sebastien Delfino Fix For: Java-SCA-Next Attachments: policyworkdelta.txt The follow patch is to add annotation and attribute suppot to the model. For @Requires annotation on Service implementaion at the class level the intents will be added to the ComponentType model object. For @Requires annotation on the Service implementation at the operation/method level the intents are added to the Operation Model Object. For @Requires annotations on the Service interface at the class level the intents are added to the ServiceContract model object. For @Requires annotations on the Service interface at the operation/method level the intents are added to the Operation model object. For requires attribute that is on the Service in the scdl the intents are added to the ServiceDefinition model object. For requires attribute that is on the Reference in the scdl the intents are added to the ReferenceDefinition model object. For requires attribute that is on the implementation.java in the scdl the intents are added to the Implementation model object. I did not want to duplicate code that existed in ServiceProcessor.java so the PolicyProcessor class should be added after the ServiceProcessor in the implementation.scdl. component name=implementation.PolicyProcessor system:implementation.system class=org.apache.tuscany.core.implementation.processor.PolicyProcessor/ /component PolicyJavaInterfaceProcessor will need to be added as implementation.system Not sure of the most appropiate place to at it with changes that have been happening. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-982) WSDL Definitions need to be unregistered from Registry
[ https://issues.apache.org/jira/browse/TUSCANY-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-982. Resolution: Fixed This is now fixed, as there is no WSDLRegistry anymore :) WSDL files are not handled by the Contribution service. When you recycle a Contribution, the WSDLs that were loaded in it will be recycled as well. WSDL Definitions need to be unregistered from Registry -- Key: TUSCANY-982 URL: https://issues.apache.org/jira/browse/TUSCANY-982 Project: Tuscany Issue Type: Sub-task Components: Java SCA Kernel Affects Versions: Java-SCA-M2 Reporter: Kapish Aggarwal Assigned To: Jean-Sebastien Delfino Fix For: Java-SCA-Next When removing an application, the WSDL definitions that were loaded need to be unregistered from WSDLDefinitionRegistry. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-983) Schema Definitions need to be unregistered from Registry
[ https://issues.apache.org/jira/browse/TUSCANY-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-983. Resolution: Fixed This is resolved the same way as TUSCANY-982. Schema Definitions need to be unregistered from Registry Key: TUSCANY-983 URL: https://issues.apache.org/jira/browse/TUSCANY-983 Project: Tuscany Issue Type: Sub-task Affects Versions: Java-SCA-M2 Reporter: Kapish Aggarwal Assigned To: Jean-Sebastien Delfino Fix For: Java-SCA-Next -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-981) Capability to Remove / Undeploy Applications from Tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-981. Resolution: Fixed This is now resolved. See comments in TUSCANY-982. Capability to Remove / Undeploy Applications from Tuscany - Key: TUSCANY-981 URL: https://issues.apache.org/jira/browse/TUSCANY-981 Project: Tuscany Issue Type: New Feature Components: Java SCA Kernel Affects Versions: Java-SCA-M2 Reporter: Kapish Aggarwal Assigned To: Jean-Sebastien Delfino Fix For: Java-SCA-Next Attachments: JIRA981Patches.zip There is no capability to remove an application once it has been deployed into the Tuscany runtime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependency on Felix plugin snapshot in commonj and SDO API modules
Raymond Feng wrote: It was initially there to package the jars as OSGi bundles. I don't see any need at this point. So I suggest that we remove it. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, April 09, 2007 3:29 PM Subject: Dependency on Felix plugin snapshot in commonj and SDO API modules The following poms: ./spec/commonj/pom.xml ./spec/sdo-api/pom.xml depend on this plugin: groupIdorg.apache.felix.plugins/groupId artifactIdmaven-osgi-plugin/artifactId version0.8.0-SNAPSHOT/version Any idea what this is used for? If not, then could we remove this dependency on a SNAPSHOT? Thanks -- Jean-Sebastien Ok, I've removed that dependency for now. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DAS M3 Release
Recently we had couple inquires about a DAS Release [1] and [2], so it's probably time to start discussing what should be in the next DAS release.Wecould start by reviewing the discussion we had right after we released DAS M2 [3], and also get a list of things we already have done after our previous release. Couple things I would like to help for our next release: - Review MySQL Support Sample - Automate creation of Canned databases for DAS Samples (TUSCANY-863) Documentation - Continue to work on DAS User's guide - Migrate it to new wiki and investigate the possibility to add to the release package Infrastructure - Automate release distribution process Once we agree on a set of items for our next release, we then could start tracking the release progress on our wiki. Thoughts ? [1] - http://www.mail-archive.com/[EMAIL PROTECTED]/msg00798.html [2] - http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00589.html [3] - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg11017.html [4] - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Releases -- Luciano Resende http://people.apache.org/~lresende
Re: Project conventions
[snip] Simon Laws wrote: 3/ package names within the modules don't always match the module name which makes it trick to find classes sometimes. I don't have loads of examples here but the problem I have was trying to find o.a.t.api.SCARuntime This is in the host-embedded module. Is it practical to suggest that package names to at least contain the module name? Simon, I just fixed this API. The package name is now o.a.t.host.embedded, matching the module name. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Project conventions
On 4/16/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Simon Laws wrote: 3/ package names within the modules don't always match the module name which makes it trick to find classes sometimes. I don't have loads of examples here but the problem I have was trying to find o.a.t.api.SCARuntime This is in the host-embedded module. Is it practical to suggest that package names to at least contain the module name? Simon, I just fixed this API. The package name is now o.a.t.host.embedded, matching the module name. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Great, thanks for that.
Re: Build failures- Explanation and Proposed Solution
Yes, this looks fine for SDO. The parent artifact that we voted on recently http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/parent/2/pom.xml had already made this switch, and so my SDO M3 release candidates already reference the parent in the incubating style. I'll make the changes to SDO poms in the trunk to reflect the change. Regards, Kelvin. On 16/04/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Luciano Resende wrote: Hi All After couple complains about build failures, and couple hours investigating the multiple complains on the dev-list [1][2], looks like all the issues are being caused due to our artifacts having two set of artifact versions : version2-incubating-SNAPSHOT/version and version2-incubator-SNAPSHOT/version.After I changed everything locally to use the same version as the one defined in the java/pom/parent version2-incubating-SNAPSHOT/version, the whole build started to work and the issues reported are gone. So, in order to avoid future complains, I'd like to propose changes to remaining artifacts that are using version2-incubator-SNAPSHOT/version version. Note that I have already started changing the DAS artifact versions as described in [3]. And I have attached a file containing the remaining places that need changes. If people are OK with proposed changes, particularly the SDO team, I'd like to go ahead and commit my local changes asap. [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg16509.html [2] http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00822.html http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00822.html [3] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg16625.html -- Luciano Resende http://people.apache.org/~lresende http://people.apache.org/%7Elresende - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +1 from me. I think that the recommendation for artifacts from incubating projects is *-incubating-* (although I can't find the discussion thread right now I remember I had seen a discussion on this a while ago). The SCA artifacts are already *-incubating-*, looks like you're fixing the DAS artifacts, we need the folks working on SDO to say if they're OK with this change. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Loading XSD includes?
I'm having problems getting XSD includes to load in the databinding itest so am interested to know if we are using a different version of o.a.ws.common.XmlSchema than used to be the case. I'm getting an NPE in this package because the baseUri in the XmlSchemaCollection is not set up correctly. I'm going to dig into why this is the case but if anyone knows why things have changed or is alos getting this effect I would be interested to know. Simon
Re: Dependency on Felix plugin snapshot in commonj and SDO API modules
I took a look at the SDO side of this. The build still fails if you remove the 0.8.0 version request. I was trying to look back to understand this dependency, but it seems to have been done as part of TUSCANY-679 and its not at all clear there the reasons for the change. Can anyone help me with the context of this please? Regards, Kelvin. On 09/04/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: The following poms: ./spec/commonj/pom.xml ./spec/sdo-api/pom.xml depend on this plugin: groupIdorg.apache.felix.plugins/groupId artifactIdmaven-osgi-plugin/artifactId version0.8.0-SNAPSHOT/version Any idea what this is used for? If not, then could we remove this dependency on a SNAPSHOT? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Loading XSD includes?
On 4/16/07, Simon Laws [EMAIL PROTECTED] wrote:
I'm having problems getting XSD includes to load in the databinding itest
so am interested to know if we are using a different version of
o.a.ws.common.XmlSchema than used to be the case. I'm getting an NPE in
this package because the baseUri in the XmlSchemaCollection is not set up
correctly. I'm going to dig into why this is the case but if anyone knows
why things have changed or is alos getting this effect I would be interested
to know.
Simon
OK, so I have not solved this satisfactorily but I have put in a work around
on my machine. I added the following lines to WSDLDocumentProcessor.read()
(the two lines I added are the ones with the comment above them).
// Read inline schemas
Types types = definition.getTypes();
if (types != null) {
wsdlDefinition.getInlinedSchemas().setSchemaResolver(new
URIResolverImpl());
for (Object ext : types.getExtensibilityElements()) {
if (ext instanceof Schema) {
Element element = ((Schema)ext).getElement();
// TODO: temporary fix to make includes in imported
// schema work. The XmlSchema library was
crashing
// because the base uri was not set. This
doesn't
// affect imports.
XmlSchemaCollection schemaCollection =
wsdlDefinition.getInlinedSchemas();
schemaCollection.setBaseUri
(((Schema)ext).getDocumentBaseURI());
wsdlDefinition.getInlinedSchemas().read(element,
element.getBaseURI());
}
}
}
The scenario I have is:
WSDL import..--- XSD inlcude..--- XSD
The impact of this change is that the includes are processed BUT they are
processed relative to the base URI I set up, i.e. the URI of of the WSDL
document not the URI of the XML that includes them. I can work round this
for the time being as all the XSDs are in the same directory (and this lets
me get on and work through the rest of the test) but it's not a generic
solution. So this needs some more work to either work out how to configure
the XmlSchema library properly or take a look at the latest version to see
if this apparent problem is fixed.
Simon
Re: Dependency on Felix plugin snapshot in commonj and SDO API modules
Is that the correct JIRA, TUSCANY-679 is about InterfaceWSDLLoader and doesn't look relevant? ...ant On 4/16/07, kelvin goodson [EMAIL PROTECTED] wrote: I took a look at the SDO side of this. The build still fails if you remove the 0.8.0 version request. I was trying to look back to understand this dependency, but it seems to have been done as part of TUSCANY-679 and its not at all clear there the reasons for the change. Can anyone help me with the context of this please? Regards, Kelvin. On 09/04/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: The following poms: ./spec/commonj/pom.xml ./spec/sdo-api/pom.xml depend on this plugin: groupIdorg.apache.felix.plugins/groupId artifactIdmaven-osgi-plugin/artifactId version0.8.0-SNAPSHOT/version Any idea what this is used for? If not, then could we remove this dependency on a SNAPSHOT? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Java SDO] Running the CTS against the Tuscany impl
Hi Kelvin, Running mvn from the CTS root directory does run the tests against Tuscany for me. Here's the output I get. Thanks, Andy. --- C:\Development\apache-tuscany-java\ctsmvn [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Community Test Suite [INFO] Community Test Suite for SDO 2.1 [INFO] Tuscany SDO 2.1 CTS [INFO] [INFO] Building Community Test Suite [INFO]task-segment: [install] [INFO] [INFO] [site:attach-descriptor] [INFO] [install:install] [INFO] Installing C:\Development\apache-tuscany-java\cts\pom.xml to C:\Documents and Settings\grove\ .m2\repository\org\apache\tuscany\cts\1.0-SNAPSHOT\cts-1.0-SNAPSHOT.pom [INFO] [INFO] Building Community Test Suite for SDO 2.1 [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Nothing to compile - all classes are up to date [INFO] [surefire:test] [INFO] Tests are skipped. [INFO] [jar:jar] [INFO] Building jar: C:\Development\apache-tuscany-java\cts\sdo2.1\target\sdo2.1-cts-1.0-SNAP SHOT.ja r [INFO] [install:install] [INFO] Installing C:\Development\apache-tuscany-java\cts\sdo2.1\target\sdo2.1-cts-1.0-SNAP SHOT.jar t o C:\Documents and Settings\grove\.m2\repository\org\apache\tuscany\cts\sdo2.1-cts\1.0-SNAP SHOT\sdo2 .1-cts-1.0-SNAPSHOT.jar [INFO] [INFO] Building Tuscany SDO 2.1 CTS [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Nothing to compile - all classes are up to date [INFO] [surefire:test] [INFO] Surefire report directory: C:\Development\apache-tuscany-java\cts\sdo2.1-tuscany\target\suref ire-reports CTS_TEST_HELPER was not set - attempting Tuscany implementation : null Loaded test.sdo21.vendor.tuscany.testHelper.TuscanyTestHelper --- T E S T S --- Running test.sdo21.vendor.tuscany.tests.AdoptedCtsTestSuite default null Tests run: 26, Failures: 2, Errors: 1, Skipped: 1, Time elapsed: 1.186 sec FAILURE! Results : Failed tests: testDefineWithNoLocation(test.sdo21.tests.general.XSDSerializationTest) testDuplicateDefineWithLocation(test.sdo21.tests.general.XSDSerializatio nTest) Tests in error: testGetInstancePropertiesSize(test.sdo21.tests.api.DataObjectTest) Tests run: 26, Failures: 2, Errors: 1, Skipped: 1 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 4 seconds [INFO] Finished at: Mon Apr 16 14:10:56 BST 2007 [INFO] Final Memory: 6M/12M [INFO] -Original Message- From: kelvin goodson [mailto:[EMAIL PROTECTED] Sent: 12 April 2007 15:33 To: tuscany-dev Subject: [Java SDO] Running the CTS against the Tuscany impl I've been getting back up to speed with the CTS this morning, and it took me a little while to get things going. I came across a couple of significant issues one is that the current documentation ( http://cwiki.apache.org/TUSCANY/obtaining-the-sdo-21-cts.html) suggests that running maven against the source will run the CTS against Tuscany, which is not the case. In the end I found that I had to create eclipse projects, and run test.sdo21.vendor.tuscany.tests.AdopedtCtsTestSuite as a junit test in eclipse before I could see the results of execution of the tests, Once I had managed to run the tests I found that the tuscany test helper uses the default helper instances for each test in sequence, and therefore causes tests to fail which, when run separately, succeed. I may have missed discussions on this, but clearly it needs fixing. Does anyone have any context that's not
Re: [Java SDO] Running the CTS against the Tuscany impl
I get the same result as Kelvin. Seems to build, but then it runs 0 tests. Frank. [EMAIL PROTECTED] wrote on 04/16/2007 09:55:35 AM: Hmmm, a mystery ... For the record, here's my output, I can see nothing obvious C:\Development\JiraDev\CTSsvn up At revision 529243. C:\Development\JiraDev\CTSmvn clean [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Community Test Suite [INFO] Community Test Suite for SDO 2.1 [INFO] Tuscany SDO 2.1 CTS [INFO] [INFO] Building Community Test Suite [INFO]task-segment: [clean] [INFO] -- -- [INFO] [clean:clean] [INFO] Deleting directory C:\Development\JiraDev\CTS\target [INFO] Deleting directory C:\Development\JiraDev\CTS\target\classes [INFO] Deleting directory C:\Development\JiraDev\CTS\target\test-classes [INFO] [INFO] Building Community Test Suite for SDO 2.1 [INFO]task-segment: [clean] [INFO] [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking for updates from apache.incubator [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking for updates from codehaus-snapshot [INFO] [clean:clean] [INFO] Deleting directory C:\Development\JiraDev\CTS\sdo2.1\target [INFO] Deleting directory C:\Development\JiraDev\CTS\sdo2.1\target\classes [INFO] Deleting directory C:\Development\JiraDev\CTS\sdo2.1\target\test-classes [INFO] [INFO] Building Tuscany SDO 2.1 CTS [INFO]task-segment: [clean] [INFO] [INFO] [clean:clean] [INFO] Deleting directory C:\Development\JiraDev\CTS\sdo2.1-tuscany\target [INFO] Deleting directory C:\Development\JiraDev\CTS\sdo2.1-tuscany\target\classes [INFO] Deleting directory C:\Development\JiraDev\CTS\sdo2.1-tuscany\target\test-classes [INFO] [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] Community Test Suite .. SUCCESS [ 1.302s] [INFO] Community Test Suite for SDO 2.1 .. SUCCESS [ 17.586s] [INFO] Tuscany SDO 2.1 CTS ... SUCCESS [ 3.575s] [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 23 seconds [INFO] Finished at: Mon Apr 16 14:44:48 BST 2007 [INFO] Final Memory: 3M/7M [INFO] C:\Development\JiraDev\CTSmvn [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Community Test Suite [INFO] Community Test Suite for SDO 2.1 [INFO] Tuscany SDO 2.1 CTS [INFO] [INFO] Building Community Test Suite [INFO]task-segment: [install] [INFO] [INFO] [site:attach-descriptor] [INFO] [install:install] [INFO] Installing C:\Development\JiraDev\CTS\pom.xml to C:\Documents and Settings\ibm_user\.m2\repository\org\apache\tuscany\ cts\1.0-SNAPSHOT\cts-1.0-SNAPSHOT.pom [INFO] [INFO] Building Community Test Suite for SDO 2.1 [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] Compiling 32 source files to C:\Development\JiraDev\CTS\sdo2.1\target\classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Nothing to compile - all classes are up to date [INFO] [surefire:test] [INFO] Tests are skipped. [INFO] [jar:jar] [INFO] Building jar: C:\Development\JiraDev\CTS\sdo2.1\target\sdo2.1- cts-1.0-SNAPSHOT.jar [INFO] [install:install] [INFO] Installing C:\Development\JiraDev\CTS\sdo2.1\target\sdo2.1- cts-1.0-SNAPSHOT.jar to C:\Documents and Settings\ibm_user\ .m2\repository\org\apache\tuscany\cts\sdo2.1-cts\1.0-SNAPSHOT\sdo2.1- cts-1.0-SNAPSHOT.jar [INFO] [INFO] Building Tuscany SDO 2.1 CTS [INFO]task-segment:
RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase
I believe you just need to annotate the setUp method with @Before. This is described in the junit cookbook, here: http://junit.sourceforge.net/doc/cookbook/cookbook.htm I'm currently working on submitting some more XSD test cases in the CTS so I'll try this method out. Hopefully I can then remove the current dependency on TestCase in those tests. Thanks, Andy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of kelvin goodson Sent: 16 April 2007 14:42 To: tuscany-dev@ws.apache.org Cc: Robbie Minshall Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase Hi, I'm looking at doing some work in the CTS. I was looking back at Robbie's attached description about how to keep the tests harness agnostic. I'm assuming that this is still a goal of the CTS although I may have missed something in my catching up. In my quest to make the CTS better I note that a number of the test case classes still extend the junit TestCase class. This is true for all test classes that have a setUp() method. One that doesn't inherit from TestCase is XSDSerializationTest, and adding a setUp method to this class doesn't cause junit to invoke it in my eclipse environment. I'm trying to work out whether I should I expect a 4.1environment to discover and execute the setUp method when junit is used in this way. I seem to have Eclipse junit plugins for 3.8.1 and 4.1.0.1 and the preferences tab for Junit doesn't seem to offer much in the way of configuration, so I can't be sure I'm using 4.1 behaviour. I really would like to be XSDSerializationTests to execute setUp so that we can have a fresh HelperContext per test, and I guess the easy way out is to make the test class inherit from TestCase like the others, but I'd prefer not to introduce the explicit dependency on Junit if I can avoid it. Regards Kelvin. On 07/12/06, Robbie Minshall [EMAIL PROTECTED] wrote: This sounds quite good. I have written some test cases with Brian Murray which I would be happy to contribute to tuscany. Identifying duplication and differences in similar tests would probably be an intersting excercise right off the bat. One decision that we spent a little time mulling over was the framework to use for our test suite. Originally we used the much loved junit harness which worked well. Different runtimes ( command line, J2EE Application Server, a Service Container ) have different classloader hierarchies etc. Without many modifications to the junit code it was difficult and quite ugly testing SDO within the context of a variety of runtimes which the SDO APIs will be used. We took the approach of writing general test libraries which can then simply be called from a variety of test frameworks such as junit or a simple J2EE or SCA Application test harness. I like this approach for keeping the actual test code very simple, allowing for integration a variety of test frameworks, and providing ability to test directly within the different runtimes people care about. Any thoughts on this ? Robbie On 12/1/06, kelvin goodson [EMAIL PROTECTED] wrote: Andy, please attach them to the JIRA for this work and one of us can pick them up, thanks. Best Regards, Kelvin. On 01/12/06, Andy Grove (Contractor) [EMAIL PROTECTED] wrote: Hi Dan, I was previously working with Kelvin Goodson to donate some junit tests on behalf of Rogue Wave Software. These tests are written purely to the SDO API and I have validated that the tests do run against Tuscany as well as Rogue Wave's implementation. Should I send the tests to Kelvin? Thanks, Andy. -Original Message- From: Dan Murphy [mailto:[EMAIL PROTECTED] ] Sent: 30 November 2006 17:44 To: Tuscany Developers; Tuscany Users Subject: Proposal for a (Java) community test suite for SDO I would like to propose starting a community test suite for service data objects (SDO CTS) implementations written in Java. Based on feedback from an earlier post this seems to be the first logical step in getting interoperable SDO implementations in all languages. I can see this leading to an interoperability test suite to check serialisation between implementations also works (across languages and implementations). Proposal for Community Test Suite (CTS) for SDO Develop a test suite to validate an SDO implementation behaves as expected, according to the community's understanding of the SDO specification. Should the specification appear ambiguous or unclear then the community will decide what to do; it may decide to test the area with an agreed expected behaviour, or decide not to test this area. Ambiguities will be fed back to the specification group for clarification. Although we will run this against Tuscany, the test suite will only test things that
Re: Project conventions
I sync'd up content of [1] with the getInvolved link [2] except for a piece related to coding guideline and test which seem to have been changed. We now have two different views on this. I'll start a discuss thread later this week to get everyone feedback on what the guideline should be since everyone needs to be comfortable with it. I will then update the getInvolved page with the result. I have removed the developer guide from under Guides menu since it is covered in the getInvovled page under development section. I also moved the documentation that you mentioned to the Java SCA parent since it belongs to that. I'll take a look at what is there for user documentation and harvest whatever we can into the proper pages. Architecture guide is now updated with all the available information. A review of this guide for correctness would be good. [1] http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Developer+Guide [2] http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+Development On 4/16/07, Simon Laws [EMAIL PROTECTED] wrote: On 4/16/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Simon Laws wrote: 3/ package names within the modules don't always match the module name which makes it trick to find classes sometimes. I don't have loads of examples here but the problem I have was trying to find o.a.t.api.SCARuntime This is in the host-embedded module. Is it practical to suggest that package names to at least contain the module name? Simon, I just fixed this API. The package name is now o.a.t.host.embedded, matching the module name. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Great, thanks for that.
Re: Support for Servlets with Jetty and Tomcat
Perhaps I don't understand jetty as well as I thought or I am missing your idea here but why does the JettyServer create and start a new Jetty server every time a servlet mapping is added? IIRC, previously JettyServiceImpl used to start one Jetty server and register every new servlet that was added with this server. It seems to me that now we may be wasting resources, e.g., http ports. On 4/15/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I just made some changes to the tuscany-http-* modules to allow servlets to be registered with a Tomcat or Jetty server. I guess this is going to be useful in Servlet based bindings like the WebService or JSONRPC bindings. Here's how to use this capability. In a binding, do this: ExtensionPointRegistry extensionPointRegistry; -- passed to your ModuleActivator start method. ServletHostExtensionPoint servletHosts = extensionPointRegistry.getExtensionPoint(ServletHostExtensionPoint.class); servletHosts.addServletMapping(yourServlet); The ServletHost interface from module tuscany-http replaces the old ServletHost interface from tuscany-core-spi, which will have to be deleted. In a sample or integration test: - Add the tuscany-http-tomcat or tuscany-http-jetty to your dependencies, depending on which server you want to use. Here's how it works: - I have defined ServletHostExtensionPoint in tuscany-http. That module contributes the extension point in its ModuleActivator. - The tuscany-http-jetty and tuscany-http-tomcat respectively register in this extension point their ServletHost extensions. More to do later: - change the addServletMapping to take more configuration info (like the HTTPS port number for example). - add logic to the ServletHostExtensionPoint to handle multiple ServletHosts and select the best one from what's passed to addServletMapping. Hope this helps... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1209) Remove TestCase dependency from XSDChocieTest
Remove TestCase dependency from XSDChocieTest - Key: TUSCANY-1209 URL: https://issues.apache.org/jira/browse/TUSCANY-1209 Project: Tuscany Issue Type: Improvement Components: Java SDO Community Test Suite Reporter: Andy Grove Priority: Minor The attached patch file updates XSDBaseTestCase / XSDChoice to use junit 4.1 annotations and removes the dependency on TestCase. It also improves the setup method to request a new testHelper class on each run. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1209) Remove TestCase dependency from XSDChocieTest
[ https://issues.apache.org/jira/browse/TUSCANY-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1209: Attachment: patch.txt Remove TestCase dependency from XSDChocieTest - Key: TUSCANY-1209 URL: https://issues.apache.org/jira/browse/TUSCANY-1209 Project: Tuscany Issue Type: Improvement Components: Java SDO Community Test Suite Reporter: Andy Grove Priority: Minor Attachments: patch.txt The attached patch file updates XSDBaseTestCase / XSDChoice to use junit 4.1 annotations and removes the dependency on TestCase. It also improves the setup method to request a new testHelper class on each run. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1210) XSDComplexTypeTest
[ https://issues.apache.org/jira/browse/TUSCANY-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1210: Attachment: complexTypeXsdTests.zip ZIP file containing test case and xsd files. XSDComplexTypeTest -- Key: TUSCANY-1210 URL: https://issues.apache.org/jira/browse/TUSCANY-1210 Project: Tuscany Issue Type: Test Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: complexTypeXsdTests.zip New test case to test spec-compliance of SDO types created from XSD complex types. The patch for JIRA 1209 must be applied first as it adds a new method to XSDBaseTestCase that this new test requires. The attached patch is simply a zip of the new files and should be extracted from the root of the cts module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1210) XSDComplexTypeTest
XSDComplexTypeTest -- Key: TUSCANY-1210 URL: https://issues.apache.org/jira/browse/TUSCANY-1210 Project: Tuscany Issue Type: Test Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: complexTypeXsdTests.zip New test case to test spec-compliance of SDO types created from XSD complex types. The patch for JIRA 1209 must be applied first as it adds a new method to XSDBaseTestCase that this new test requires. The attached patch is simply a zip of the new files and should be extracted from the root of the cts module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for Servlets with Jetty and Tomcat
Ignacio Silva-Lepe wrote: Perhaps I don't understand jetty as well as I thought or I am missing your idea here but why does the JettyServer create and start a new Jetty server every time a servlet mapping is added? IIRC, previously JettyServiceImpl used to start one Jetty server and register every new servlet that was added with this server. It seems to me that now we may be wasting resources, e.g., http ports. On 4/15/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I just made some changes to the tuscany-http-* modules to allow servlets to be registered with a Tomcat or Jetty server. I guess this is going to be useful in Servlet based bindings like the WebService or JSONRPC bindings. Here's how to use this capability. In a binding, do this: ExtensionPointRegistry extensionPointRegistry; -- passed to your ModuleActivator start method. ServletHostExtensionPoint servletHosts = extensionPointRegistry.getExtensionPoint(ServletHostExtensionPoint.class); servletHosts.addServletMapping(yourServlet); The ServletHost interface from module tuscany-http replaces the old ServletHost interface from tuscany-core-spi, which will have to be deleted. In a sample or integration test: - Add the tuscany-http-tomcat or tuscany-http-jetty to your dependencies, depending on which server you want to use. Here's how it works: - I have defined ServletHostExtensionPoint in tuscany-http. That module contributes the extension point in its ModuleActivator. - The tuscany-http-jetty and tuscany-http-tomcat respectively register in this extension point their ServletHost extensions. More to do later: - change the addServletMapping to take more configuration info (like the HTTPS port number for example). - add logic to the ServletHostExtensionPoint to handle multiple ServletHosts and select the best one from what's passed to addServletMapping. Hope this helps... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Ignacio. Are you actually seeing a new server getting created each time a servlet mapping is added? The server should only start the first time you add a servlet mapping, not each time... or that would be a bug :) but I'm not sure how this could happen as the second start would fail anyway with a port already in use error... Do you have a test case that shows this problem? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Loading XSD includes?
Simon Laws wrote:
On 4/16/07, Simon Laws [EMAIL PROTECTED] wrote:
I'm having problems getting XSD includes to load in the databinding
itest
so am interested to know if we are using a different version of
o.a.ws.common.XmlSchema than used to be the case. I'm getting an NPE in
this package because the baseUri in the XmlSchemaCollection is not
set up
correctly. I'm going to dig into why this is the case but if anyone
knows
why things have changed or is alos getting this effect I would be
interested
to know.
Simon
OK, so I have not solved this satisfactorily but I have put in a work
around
on my machine. I added the following lines to
WSDLDocumentProcessor.read()
(the two lines I added are the ones with the comment above them).
// Read inline schemas
Types types = definition.getTypes();
if (types != null) {
wsdlDefinition.getInlinedSchemas().setSchemaResolver(new
URIResolverImpl());
for (Object ext : types.getExtensibilityElements()) {
if (ext instanceof Schema) {
Element element = ((Schema)ext).getElement();
// TODO: temporary fix to make includes in
imported
// schema work. The XmlSchema library was
crashing
// because the base uri was not set. This
doesn't
// affect imports.
XmlSchemaCollection schemaCollection =
wsdlDefinition.getInlinedSchemas();
schemaCollection.setBaseUri
(((Schema)ext).getDocumentBaseURI());
wsdlDefinition.getInlinedSchemas().read(element,
element.getBaseURI());
}
}
}
The scenario I have is:
WSDL import..--- XSD inlcude..--- XSD
The impact of this change is that the includes are processed BUT they are
processed relative to the base URI I set up, i.e. the URI of of the WSDL
document not the URI of the XML that includes them. I can work round this
for the time being as all the XSDs are in the same directory (and this
lets
me get on and work through the rest of the test) but it's not a generic
solution. So this needs some more work to either work out how to
configure
the XmlSchema library properly or take a look at the latest version to
see
if this apparent problem is fixed.
Simon
Simon, what you've done looks like the right fix to me as an XSD include
from an XML schema inlined in a WSDL document should be loaded relative
to the WSDL document.
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for Servlets with Jetty and Tomcat
Ah, my mistake. I was focusing on the port parm to addServletMapping and overlooked the if(state == STARTING) part. Wouldn't it be better to set the httpPort separately? On 4/16/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Ignacio Silva-Lepe wrote: Perhaps I don't understand jetty as well as I thought or I am missing your idea here but why does the JettyServer create and start a new Jetty server every time a servlet mapping is added? IIRC, previously JettyServiceImpl used to start one Jetty server and register every new servlet that was added with this server. It seems to me that now we may be wasting resources, e.g., http ports. On 4/15/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I just made some changes to the tuscany-http-* modules to allow servlets to be registered with a Tomcat or Jetty server. I guess this is going to be useful in Servlet based bindings like the WebService or JSONRPC bindings. Here's how to use this capability. In a binding, do this: ExtensionPointRegistry extensionPointRegistry; -- passed to your ModuleActivator start method. ServletHostExtensionPoint servletHosts = extensionPointRegistry.getExtensionPoint( ServletHostExtensionPoint.class); servletHosts.addServletMapping(yourServlet); The ServletHost interface from module tuscany-http replaces the old ServletHost interface from tuscany-core-spi, which will have to be deleted. In a sample or integration test: - Add the tuscany-http-tomcat or tuscany-http-jetty to your dependencies, depending on which server you want to use. Here's how it works: - I have defined ServletHostExtensionPoint in tuscany-http. That module contributes the extension point in its ModuleActivator. - The tuscany-http-jetty and tuscany-http-tomcat respectively register in this extension point their ServletHost extensions. More to do later: - change the addServletMapping to take more configuration info (like the HTTPS port number for example). - add logic to the ServletHostExtensionPoint to handle multiple ServletHosts and select the best one from what's passed to addServletMapping. Hope this helps... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Ignacio. Are you actually seeing a new server getting created each time a servlet mapping is added? The server should only start the first time you add a servlet mapping, not each time... or that would be a bug :) but I'm not sure how this could happen as the second start would fail anyway with a port already in use error... Do you have a test case that shows this problem? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Loading XSD includes?
On 4/16/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Simon Laws wrote:
On 4/16/07, Simon Laws [EMAIL PROTECTED] wrote:
I'm having problems getting XSD includes to load in the databinding
itest
so am interested to know if we are using a different version of
o.a.ws.common.XmlSchema than used to be the case. I'm getting an NPE in
this package because the baseUri in the XmlSchemaCollection is not
set up
correctly. I'm going to dig into why this is the case but if anyone
knows
why things have changed or is alos getting this effect I would be
interested
to know.
Simon
OK, so I have not solved this satisfactorily but I have put in a work
around
on my machine. I added the following lines to
WSDLDocumentProcessor.read()
(the two lines I added are the ones with the comment above them).
// Read inline schemas
Types types = definition.getTypes();
if (types != null) {
wsdlDefinition.getInlinedSchemas().setSchemaResolver(new
URIResolverImpl());
for (Object ext : types.getExtensibilityElements()) {
if (ext instanceof Schema) {
Element element = ((Schema)ext).getElement();
// TODO: temporary fix to make includes in
imported
// schema work. The XmlSchema library was
crashing
// because the base uri was not set. This
doesn't
// affect imports.
XmlSchemaCollection schemaCollection =
wsdlDefinition.getInlinedSchemas();
schemaCollection.setBaseUri
(((Schema)ext).getDocumentBaseURI());
wsdlDefinition.getInlinedSchemas().read(element,
element.getBaseURI());
}
}
}
The scenario I have is:
WSDL import..--- XSD inlcude..--- XSD
The impact of this change is that the includes are processed BUT they
are
processed relative to the base URI I set up, i.e. the URI of of the WSDL
document not the URI of the XML that includes them. I can work round
this
for the time being as all the XSDs are in the same directory (and this
lets
me get on and work through the rest of the test) but it's not a generic
solution. So this needs some more work to either work out how to
configure
the XmlSchema library properly or take a look at the latest version to
see
if this apparent problem is fixed.
Simon
Simon, what you've done looks like the right fix to me as an XSD include
from an XML schema inlined in a WSDL document should be loaded relative
to the WSDL document.
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
it works fine for XSDs include from the WSDL but I don't think it's
correct for an XSD included in an XML schema which is itself
included/imported into the inline XML schema of a WSDL, i.e. nested
includes. The reasone I am concerned is that the databinding schema don;t
now work in the way that they used to. I've not had a chance to chase the
documentation to find out what the correct behaviour is but I think the old
behaviour was correct.
When I say old behaviour here what I mean is that includes are assumed to be
relative to the file that is including them and not relative to some parent
of that file.
Simon
[jira] Created: (TUSCANY-1211) SDO 2.1 feature: On-the-fly creation of open content properties
SDO 2.1 feature: On-the-fly creation of open content properties --- Key: TUSCANY-1211 URL: https://issues.apache.org/jira/browse/TUSCANY-1211 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Reporter: Frank Budinsky -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1212) SDO 2.1 feature: Property.isNullable() and Property.isOpenContent()
SDO 2.1 feature: Property.isNullable() and Property.isOpenContent() --- Key: TUSCANY-1212 URL: https://issues.apache.org/jira/browse/TUSCANY-1212 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Reporter: Frank Budinsky -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1213) SDO 2.1 feature: DataHelper.convert()
SDO 2.1 feature: DataHelper.convert() - Key: TUSCANY-1213 URL: https://issues.apache.org/jira/browse/TUSCANY-1213 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Reporter: Frank Budinsky -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1214) SDO 2.1 feature: XMLHelper.load(Source) and XMLHelper.save(Result)
SDO 2.1 feature: XMLHelper.load(Source) and XMLHelper.save(Result) -- Key: TUSCANY-1214 URL: https://issues.apache.org/jira/browse/TUSCANY-1214 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Reporter: Frank Budinsky -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1215) Support of property override with recursive scdl files
Support of property override with recursive scdl files -- Key: TUSCANY-1215 URL: https://issues.apache.org/jira/browse/TUSCANY-1215 Project: Tuscany Issue Type: Improvement Affects Versions: Java-SCA-M2 Environment: All Reporter: Hasan Muhammad We were trying this scenario out where we have a section in the default scdl as follows: service name=MySimpleServiceAnother interface.java interface=mysca.test.myservice.MyService/ referenceMySimpleServiceInRecursiveAnother/MyServiceNew1/reference binding.sca uri=MySimpleServiceAnother/ /service component name=MySimpleServiceInRecursiveAnother implementation.composite scdlLocation=mySimpleService.scdl/ property name=newLocationDurham/property property name=newYear2009/property /component We have the two properties newLocation and newYear defined in mySimpleService.scdl as follows: service name=MyServiceNew1 interface.java interface=mysca.test.myservice.MyService/ referenceMyServiceComponentNew/MyService/reference /service property name=newLocation type=xs:anyURIRaleigh/property property name=newYear type=xs:anyURI2008/property component name=MyServiceComponentNew implementation.java class=mysca.test.myservice.impl.MyServiceImpl/ property name=location source=$newLocation/ property name=year source=$newYear/ /component When we try to get the property of location through MySimpleServiceAnother, it gives back the value Raleigh. It should give Durham, In other words during runtime, the original value must be overwritten with the new one that we provided in the default.scdl under the component MySimpleServiceInRecursiveAnother. This feature of property override needs to be supported. Hasan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1211) SDO 2.1 feature: On-the-fly creation of open content properties
[ https://issues.apache.org/jira/browse/TUSCANY-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky resolved TUSCANY-1211. - Resolution: Fixed Committed revision 529307. SDO 2.1 feature: On-the-fly creation of open content properties --- Key: TUSCANY-1211 URL: https://issues.apache.org/jira/browse/TUSCANY-1211 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Reporter: Frank Budinsky -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Build failure in Web Services Binding using Apache Axis2
Hi, I'm seeing a build problem with a clean maven repo. Any idea? Thanks, Raymond [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) incubator-woden:woden:jar:1.0.0M6 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=incubator-woden -DartifactId=woden \ -Dversion=1.0.0M6 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sca:tuscany-binding-ws-axis2:jar:1.0-incubating-SN APSHOT 2) incubator-woden:woden:jar:1.0.0M6 -- 1 required artifact is missing. for artifact: org.apache.tuscany.sca:tuscany-binding-ws-axis2:jar:1.0-incubating-SNAPSHOT from the specified remote repositories: apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), central (http://repo1.maven.org/maven2), apache.incubator (http://people.apache.org/repo/m2-incubating-repository) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 3 minutes 45 seconds [INFO] Finished at: Mon Apr 16 09:04:46 PDT 2007 [INFO] Final Memory: 13M/39M [INFO]
Re: Project conventions
Simon Laws wrote: On 4/16/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Simon Laws wrote: 3/ package names within the modules don't always match the module name which makes it trick to find classes sometimes. I don't have loads of examples here but the problem I have was trying to find o.a.t.api.SCARuntime This is in the host-embedded module. Is it practical to suggest that package names to at least contain the module name? Simon, I just fixed this API. The package name is now o.a.t.host.embedded, matching the module name. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Great, thanks for that. I found a few more places where the package name didn't match the module in modules/databinding, which I fixed under revision r529315. There's more packages like that in tuscany-core-spi, but fixing them will be more tricky as more modules depend on them. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase
Thanks for this Andy, I'll play with it tomorrow. Regards, Kelvin. On 16/04/07, Andy Grove [EMAIL PROTECTED] wrote: I believe you just need to annotate the setUp method with @Before. This is described in the junit cookbook, here: http://junit.sourceforge.net/doc/cookbook/cookbook.htm I'm currently working on submitting some more XSD test cases in the CTS so I'll try this method out. Hopefully I can then remove the current dependency on TestCase in those tests. Thanks, Andy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of kelvin goodson Sent: 16 April 2007 14:42 To: tuscany-dev@ws.apache.org Cc: Robbie Minshall Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase Hi, I'm looking at doing some work in the CTS. I was looking back at Robbie's attached description about how to keep the tests harness agnostic. I'm assuming that this is still a goal of the CTS although I may have missed something in my catching up. In my quest to make the CTS better I note that a number of the test case classes still extend the junit TestCase class. This is true for all test classes that have a setUp() method. One that doesn't inherit from TestCase is XSDSerializationTest, and adding a setUp method to this class doesn't cause junit to invoke it in my eclipse environment. I'm trying to work out whether I should I expect a 4.1environment to discover and execute the setUp method when junit is used in this way. I seem to have Eclipse junit plugins for 3.8.1 and 4.1.0.1 and the preferences tab for Junit doesn't seem to offer much in the way of configuration, so I can't be sure I'm using 4.1 behaviour. I really would like to be XSDSerializationTests to execute setUp so that we can have a fresh HelperContext per test, and I guess the easy way out is to make the test class inherit from TestCase like the others, but I'd prefer not to introduce the explicit dependency on Junit if I can avoid it. Regards Kelvin. On 07/12/06, Robbie Minshall [EMAIL PROTECTED] wrote: This sounds quite good. I have written some test cases with Brian Murray which I would be happy to contribute to tuscany. Identifying duplication and differences in similar tests would probably be an intersting excercise right off the bat. One decision that we spent a little time mulling over was the framework to use for our test suite. Originally we used the much loved junit harness which worked well. Different runtimes ( command line, J2EE Application Server, a Service Container ) have different classloader hierarchies etc. Without many modifications to the junit code it was difficult and quite ugly testing SDO within the context of a variety of runtimes which the SDO APIs will be used. We took the approach of writing general test libraries which can then simply be called from a variety of test frameworks such as junit or a simple J2EE or SCA Application test harness. I like this approach for keeping the actual test code very simple, allowing for integration a variety of test frameworks, and providing ability to test directly within the different runtimes people care about. Any thoughts on this ? Robbie On 12/1/06, kelvin goodson [EMAIL PROTECTED] wrote: Andy, please attach them to the JIRA for this work and one of us can pick them up, thanks. Best Regards, Kelvin. On 01/12/06, Andy Grove (Contractor) [EMAIL PROTECTED] wrote: Hi Dan, I was previously working with Kelvin Goodson to donate some junit tests on behalf of Rogue Wave Software. These tests are written purely to the SDO API and I have validated that the tests do run against Tuscany as well as Rogue Wave's implementation. Should I send the tests to Kelvin? Thanks, Andy. -Original Message- From: Dan Murphy [mailto:[EMAIL PROTECTED] ] Sent: 30 November 2006 17:44 To: Tuscany Developers; Tuscany Users Subject: Proposal for a (Java) community test suite for SDO I would like to propose starting a community test suite for service data objects (SDO CTS) implementations written in Java. Based on feedback from an earlier post this seems to be the first logical step in getting interoperable SDO implementations in all languages. I can see this leading to an interoperability test suite to check serialisation between implementations also works (across languages and implementations). Proposal for Community Test Suite (CTS) for SDO Develop a test suite to validate an SDO implementation behaves as expected, according to the community's understanding of the SDO specification. Should the specification appear ambiguous or unclear then the community will decide what to do; it may decide to test the area with an agreed expected behaviour, or decide not to test this area. Ambiguities will be fed back to the specification group for
[DAS] Re: DAS Factory
Hi Ole Great to hear you are already on your development phase !!! I'm copying the tuscany-dev list to share your progress and because i think some of the topics here are of interest of the great community. On 4/16/07, Ole Ersoy [EMAIL PROTECTED] wrote: Luciano Resende wrote: You got it right, from what is on my sandbox as of today. Looks like you want to understand how things work after you get the DAS instance, and then you probably want to take a look at the current DAS RDB implementation. Yes - I want to have a look at that too, so I can mimic the RDB behaviour. For the DASFactory I was looking for something like test cases that illustrate how it works? I'm still figuring out class loader stuff :-) I see, some simple testcases were available, but I forgot to commit them. They should be on my sandbox as of now. I also committed a small change on the pom version ids, this might affect your code if you are depending directly on the code in my sandbox. Also, do you know if we have some code for loading generated classes somewhere that a model factory would use to create instances defined by generated interfaces? What I have in mind is first loading the generator model. Then pulling some parameters that tell a class loader where the jar for the generated interfaces and corresponding implementations is. Then loading a generated factory for creating instances. And this is what the DAS would use to create instances, when it's supplied with generated code... I think what you are talking here is the usage of SDOUtil.registerStaticTypes, if this is the case, you can find some sample code in the following testcase : https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/test/java/org/apache/tuscany/das/rdb/test/typed/SimplestStaticCrud.java I haven't migrated DAS RDB for this new programming model that is on my sandbox, and I'm waiting to get a second implementation on the way, to then migrate the RDB. If you have specific questions, or doubts, please let me know and I can try helping... Terrific, I'm trying to get a prototype going that will use your sandbox work to create the DAS, so I'll let you know if I bumpt into any issues. BTW, do you already have some code available somewhere ? Yes - Just checked it in: https://svn.apache.org/repos/asf/directory/sandbox/oersoy/das.ldap.parent So far it has tested code for deriving the root DataObject entry DN and creating it, and some code for cleaning it up when the model instance is deleted. Let me know if you have any questions. I'm going to start experimenting with writing DataObjects now. Cheers, - Ole -- Luciano Resende http://people.apache.org/~lresende
Re: [DAS] Automatically Creating sample canned databases
I have not had a chance to investigate but there is OS utility named DBUnit (http://www.dbunit.org/) that is designed to create, preload and refresh databases for use in testing. Amita Vadhavkar wrote: Hi Luciano, Yes, I am making a util jar for that. Please check all the below details and let me know yout suggestions. Trying to reuse part of DAS config.xsd's (ConnectionInfo portion ) to supply the connection params and adding a new element to xsd to list database table names that need to be created. This way different samples can restrict the number of tables created based on their need. Also, making methods to do force/needBased refresh of tables and data. i.e. control table creation and data refresh. We can use same jar in web samples and standalone samples. The methods exposed to the clients of this jar will be dbInit.createDB (DBConfigFileName); dbInit.createSchema(boolean) - for force/need base table creation, dbInit.createData(boolean)- for force/need base data refresh. Can be more granular - like which table to create/data to refresh - but then the whole referntial integrity will need to be taken care, So to keep it simple - at present - its all tables/none , not selective. I am assuming that the table structure is internal knowledge of this util, i.e. not allowing externally defining table structures etc. (sim. to what we have at present in rdb). Only flexibility is - which are the tables required by the current client. Will that suffice for the current need? We can add that later if it is essential for some apps/samples. Pasting here the structure of DBConfig.xsd. See if this will meet the requirements. Can add database vendor name to support different databases like Derby, DB2, MySQL etc. One question here is - For DB2 database creation - from java, how to do this? There are ways for this in MySQL and Derby but could not find for DB2, any pointers? Below is the xsd. _ ?xml version=1.0 encoding=UTF-8? !-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- xsd:schema xmlns:DBConfig=http:///org.apache.tuscany.das.rdb/DBConfig.xsd; xmlns:xsd=http://www.w3.org/2001/XMLSchema; elementFormDefault=qualified targetNamespace=http:///org.apache.tuscany.das.rdb/DBConfig.xsd; xsd:element name=DBConfig type=DBConfig:DBConfig/ xsd:complexType name=DBConfig xsd:sequence xsd:element maxOccurs=1 minOccurs=1 name=ConnectionInfo type=DBConfig:ConnectionInfo/ xsd:element maxOccurs=1 minOccurs=1 name=TableList type=DBConfig:TableList/ /xsd:sequence xsd:attribute name=forceRecreate type=xsd:boolean/ xsd:attribute name=forceDataRefresh type=xsd:boolean/ /xsd:complexType xsd:complexType name=ConnectionProperties xsd:attribute name=driverClass type=xsd:string/ xsd:attribute name=databaseURL type=xsd:string/ xsd:attribute default= name=userName type=xsd:string/ xsd:attribute default= name=password type=xsd:string/ xsd:attribute default=0 name=loginTimeout type=xsd:int/ /xsd:complexType xsd:complexType name=ConnectionInfo xsd:sequence xsd:element maxOccurs=1 minOccurs=0 name=ConnectionProperties type=DBConfig:ConnectionProperties/ /xsd:sequence xsd:attribute name=dataSource type=xsd:string/ /xsd:complexType xsd:complexType name=TableList xsd:sequence xsd:element maxOccurs=unbounded minOccurs=0 name=TableName type=xsd:string/ /xsd:sequence /xsd:complexType /xsd:schema On 4/10/07, Luciano Resende [EMAIL PROTECTED] wrote: Hi Amita Today, we have couple of DAS sample applications (companyWeb, customer, das-service) and they mostly rely on same set of databases table and the solution we have today is to have the actual derby canned db checked in and copied when it need to be used. This per si is a problem, but also, if you want to use the sample with another db (e.g MySQL) you would have to create the canned DB yourself. There is also a small issue when performing automated integration testings using htmlUnit, that we need a way to refresh the data to it's initial status, to allow running the test again without having to re-copy the canned databases. The idea behind Tuscany-863
Re: [DAS] Automatically Creating sample canned databases
Well, DBUnit has a LGPL license [1], and I think this is not ASF friendly. I'd avoid looking further into this utility. [1] - http://dbunit.svn.sourceforge.net/svnroot/dbunit/trunk/LICENSE.txt On 4/16/07, Kevin Williams [EMAIL PROTECTED] wrote: I have not had a chance to investigate but there is OS utility named DBUnit (http://www.dbunit.org/) that is designed to create, preload and refresh databases for use in testing. Amita Vadhavkar wrote: Hi Luciano, Yes, I am making a util jar for that. Please check all the below details and let me know yout suggestions. Trying to reuse part of DAS config.xsd's (ConnectionInfo portion ) to supply the connection params and adding a new element to xsd to list database table names that need to be created. This way different samples can restrict the number of tables created based on their need. Also, making methods to do force/needBased refresh of tables and data. i.e. control table creation and data refresh. We can use same jar in web samples and standalone samples. The methods exposed to the clients of this jar will be dbInit.createDB (DBConfigFileName); dbInit.createSchema(boolean) - for force/need base table creation, dbInit.createData(boolean)- for force/need base data refresh. Can be more granular - like which table to create/data to refresh - but then the whole referntial integrity will need to be taken care, So to keep it simple - at present - its all tables/none , not selective. I am assuming that the table structure is internal knowledge of this util, i.e. not allowing externally defining table structures etc. (sim. to what we have at present in rdb). Only flexibility is - which are the tables required by the current client. Will that suffice for the current need? We can add that later if it is essential for some apps/samples. Pasting here the structure of DBConfig.xsd. See if this will meet the requirements. Can add database vendor name to support different databases like Derby, DB2, MySQL etc. One question here is - For DB2 database creation - from java, how to do this? There are ways for this in MySQL and Derby but could not find for DB2, any pointers? Below is the xsd. _ ?xml version=1.0 encoding=UTF-8? !-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- xsd:schema xmlns:DBConfig=http:///org.apache.tuscany.das.rdb/DBConfig.xsd; xmlns:xsd=http://www.w3.org/2001/XMLSchema; elementFormDefault=qualified targetNamespace=http:///org.apache.tuscany.das.rdb/DBConfig.xsd; xsd:element name=DBConfig type=DBConfig:DBConfig/ xsd:complexType name=DBConfig xsd:sequence xsd:element maxOccurs=1 minOccurs=1 name=ConnectionInfo type=DBConfig:ConnectionInfo/ xsd:element maxOccurs=1 minOccurs=1 name=TableList type=DBConfig:TableList/ /xsd:sequence xsd:attribute name=forceRecreate type=xsd:boolean/ xsd:attribute name=forceDataRefresh type=xsd:boolean/ /xsd:complexType xsd:complexType name=ConnectionProperties xsd:attribute name=driverClass type=xsd:string/ xsd:attribute name=databaseURL type=xsd:string/ xsd:attribute default= name=userName type=xsd:string/ xsd:attribute default= name=password type=xsd:string/ xsd:attribute default=0 name=loginTimeout type=xsd:int/ /xsd:complexType xsd:complexType name=ConnectionInfo xsd:sequence xsd:element maxOccurs=1 minOccurs=0 name=ConnectionProperties type=DBConfig:ConnectionProperties/ /xsd:sequence xsd:attribute name=dataSource type=xsd:string/ /xsd:complexType xsd:complexType name=TableList xsd:sequence xsd:element maxOccurs=unbounded minOccurs=0 name=TableName type=xsd:string/ /xsd:sequence /xsd:complexType /xsd:schema On 4/10/07, Luciano Resende [EMAIL PROTECTED] wrote: Hi Amita Today, we have couple of DAS sample applications (companyWeb, customer, das-service) and they mostly rely on same set of databases table and the solution we have today is to have the actual derby canned db checked in and copied when it need to be used. This per si is a problem, but also, if you want to use the sample with another
Re: DAS ApplyChanges Questions
Hello Christopher, Some comments in line ... Christopher Holtz wrote: Hello Tuscany, I am working on building a DAS implementation for an old hierarchical database and am looking at Tuscany as *the* DAS reference implementation. Several issues around applyChanges are troubling me and I'm hoping to start a dialog to address them (or even better get a really obvious answer that I'm missing) When a client returns a modified DataGraph back to a DAS instance, that DAS needs some basic information such as which Database, which Table, and which specific row(s) the now modified data originally came from before it can start comparing old values, etc. How does a DAS get this high level information from an incoming DataGraph? Is there a way to somehow tie the incoming DataGraph back to the initial Command that produced it? Holding state in the DAS sounds like cheating since it would break the fundamental SDO concepts, plus the SDO spec mentions being able to take a DataGraph produced by one DAS and return it to another for changes. The RDB DAS instance is configured with a database connection that it is to work with. Also, the DAS may be configured with metadata regarding the tables it is working with. In the absence of configuration metadata, the DAS can make some assumptions about the mapping of DataObjects to Tables/Columns ( http://wiki.apache.org/ws/ConventionOverConfiguration ). The DataObject graph change summary contains all the original state as well as any modifications made. The RDB DAS can use this change summary to generated the required database update statements without needing to know the original query. Assuming we know the database and table somehow, what happens in the case where the primary key(s) are not included in the DataObject? do we put them in the DataObject anyways during retrieval. And even so what about the case where the table has no unique primary key (is that even legal in the relational world)? The metadata the DAS instance is created with may include primary key definitions. If there is no key definitions then the DAS will make assumptions about the key (convention over config again). If there is no PK config info and there are no matching conventions then the DAS will throw an error since it requires a PK to generate the needed update statements. Thanks, Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Automatically Creating sample canned databases
Looking into the same direction as kevin, and trying to find existing utility libraries that would help, looks like Apache DB have one that can help with the database structure [1], and could be used programatically [2], and once the physical db is available, we could use DAS to populate it ? I'll let you guys know if I find anything else available, if anybody is familiar with any other utilities please let us know as well. [1] - http://db.apache.org/ddlutils/ [2] - http://db.apache.org/ddlutils/api-usage.html On 4/16/07, Luciano Resende [EMAIL PROTECTED] wrote: Well, DBUnit has a LGPL license [1], and I think this is not ASF friendly. I'd avoid looking further into this utility. [1] - http://dbunit.svn.sourceforge.net/svnroot/dbunit/trunk/LICENSE.txt On 4/16/07, Kevin Williams [EMAIL PROTECTED] wrote: I have not had a chance to investigate but there is OS utility named DBUnit (http://www.dbunit.org/) that is designed to create, preload and refresh databases for use in testing. Amita Vadhavkar wrote: Hi Luciano, Yes, I am making a util jar for that. Please check all the below details and let me know yout suggestions. Trying to reuse part of DAS config.xsd's (ConnectionInfo portion ) to supply the connection params and adding a new element to xsd to list database table names that need to be created. This way different samples can restrict the number of tables created based on their need. Also, making methods to do force/needBased refresh of tables and data. i.e. control table creation and data refresh. We can use same jar in web samples and standalone samples. The methods exposed to the clients of this jar will be dbInit.createDB (DBConfigFileName); dbInit.createSchema(boolean) - for force/need base table creation, dbInit.createData(boolean)- for force/need base data refresh. Can be more granular - like which table to create/data to refresh - but then the whole referntial integrity will need to be taken care, So to keep it simple - at present - its all tables/none , not selective. I am assuming that the table structure is internal knowledge of this util, i.e. not allowing externally defining table structures etc. (sim. to what we have at present in rdb). Only flexibility is - which are the tables required by the current client. Will that suffice for the current need? We can add that later if it is essential for some apps/samples. Pasting here the structure of DBConfig.xsd. See if this will meet the requirements. Can add database vendor name to support different databases like Derby, DB2, MySQL etc. One question here is - For DB2 database creation - from java, how to do this? There are ways for this in MySQL and Derby but could not find for DB2, any pointers? Below is the xsd. _ ?xml version=1.0 encoding=UTF-8? !-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- xsd:schema xmlns:DBConfig=http:///org.apache.tuscany.das.rdb/DBConfig.xsd; xmlns:xsd= http://www.w3.org/2001/XMLSchema; elementFormDefault=qualified targetNamespace= http:///org.apache.tuscany.das.rdb/DBConfig.xsd; xsd:element name=DBConfig type=DBConfig:DBConfig/ xsd:complexType name=DBConfig xsd:sequence xsd:element maxOccurs=1 minOccurs=1 name=ConnectionInfo type=DBConfig:ConnectionInfo/ xsd:element maxOccurs=1 minOccurs=1 name=TableList type=DBConfig:TableList/ /xsd:sequence xsd:attribute name=forceRecreate type=xsd:boolean/ xsd:attribute name=forceDataRefresh type=xsd:boolean/ /xsd:complexType xsd:complexType name=ConnectionProperties xsd:attribute name=driverClass type=xsd:string/ xsd:attribute name=databaseURL type=xsd:string/ xsd:attribute default= name=userName type=xsd:string/ xsd:attribute default= name=password type=xsd:string/ xsd:attribute default=0 name=loginTimeout type=xsd:int/ /xsd:complexType xsd:complexType name=ConnectionInfo xsd:sequence xsd:element maxOccurs=1 minOccurs=0 name=ConnectionProperties type=DBConfig:ConnectionProperties/
Use of HelperContext to indetify SDO databinding?
Static SDO used in the databinding tests with the Axis2 binding are not
being successfully identified as SDOs.
In SDODataBinding.introspect() one of the tests use to identify and SDO from
a Java type is as follows
HelperContext context = HelperProvider.getDefaultContext();
...
// FIXME: We need to access HelperContext
Type type = context.getTypeHelper().getType(javaType);
if (type == null) {
return false;
}
However when the ImportSDO functionality runs it associates the importer
with a HelperContext from the helperContextRegistry.
helperContext = helperContextRegistry.getHelperContext(id);
This doesn't look right to me as I expect different HelperContexts will be
used. I can't work out how to get to the helperContextRegistry from the
SDODataBinding (and it's getting late) but if someone who knows databindings
could take a look and confirm or not whether this is an issue I can take a
look tomorrow.
Regards
Simon
Re: Use of HelperContext to indetify SDO databinding?
Hi, Simon.
I think you hit the point. We still need to flush out the complete design on
how to scope SDO metadata and how to provide access to the SCA components.
At this moment, I register the SDO types with the default helper context too
(HelperProvider.getDefaultContext()). Please let me know which test case I
can use to further investigate.
Thanks,
Raymond
- Original Message -
From: Simon Laws [EMAIL PROTECTED]
To: tuscany-dev tuscany-dev@ws.apache.org
Sent: Monday, April 16, 2007 2:04 PM
Subject: Use of HelperContext to indetify SDO databinding?
Static SDO used in the databinding tests with the Axis2 binding are not
being successfully identified as SDOs.
In SDODataBinding.introspect() one of the tests use to identify and SDO
from
a Java type is as follows
HelperContext context = HelperProvider.getDefaultContext();
...
// FIXME: We need to access HelperContext
Type type = context.getTypeHelper().getType(javaType);
if (type == null) {
return false;
}
However when the ImportSDO functionality runs it associates the importer
with a HelperContext from the helperContextRegistry.
helperContext = helperContextRegistry.getHelperContext(id);
This doesn't look right to me as I expect different HelperContexts will be
used. I can't work out how to get to the helperContextRegistry from the
SDODataBinding (and it's getting late) but if someone who knows
databindings
could take a look and confirm or not whether this is an issue I can take a
look tomorrow.
Regards
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Require more context for URLArtifactProcessorExtension.read()
Hi, When I try to add a URLArtifactProcessorExtension to introspect java classes, I found it impossible to get the class name as only the URL of the class file is passed to the read() method. To provide such context, I suggest that we pass in the DeployedArtifact (which contains the URL) instead of URL to the read() method. Do you agree or do you have a better way? Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
