Millies, Sebastian wrote:
-----Original Message----- From: Simon Nash [mailto:[email protected]] Sent: Wednesday, December 21, 2011 3:26 PM To: [email protected] Subject: Re: Contributions and Runtime Classpath
>> (cut)
Thanks for the suggestion. In principle, that would work for me, except for one complication: In my application, I pass around data objects (defined by xsd). The backing xsd's are resource imports/exports, and I have my own helper classes for SDO manipulation. These helpers load the xsd's as resources, i. e. they must be accessible to contribution code, the helper classes and the customer code. Which means the xsd's and helper classes would also have to go on the application classpath.
Yes, they would need to be available there.
However, I think that's not going to be possible, because the SDOs of course also occur in service calls as parameters and return values, and the serialization via the SDO databinding will only work correctly when the defining types are declared with <dbsdo:import.sdo> elements in the composite files (where xmlns:dbsdo="http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0"; ). This, I think only works when they are exported/imported as resources of the contribution, and does not work when they just sit on the application classpath.
Could you try packaging duplicate copies of these XSDs and helper classes, with one copy packaged in a contribution jar and a separate copy packaged in a classpath jar? I think there's a chance that this approach might work. If it doesn't work, and if <dbsdo:import.sdo> can't pick things up from the application classpath, I don't have any other suggestions.
In any case I'd have some refactoring on my hands. So for the near future I'll probably prescribe an implementation package for the customer code, and revisit the situation later. If our project really abandons SDO (a possibility I mentioned in another thread), then this particular problem will vanish and your suggestion become immediately feasible.
Perhaps you could require the customer to provide a factory class implementation in a specified package but not require any other customer classes to be in specified packages. The factory class would have static methods to create any other customer classes that are needed. Simon
-- Sebastian IDS Scheer Consulting GmbH Geschäftsführer/Managing Directors: Kamyar Niroumand, Ivo Totev Sitz/Registered office: Altenkesseler Straße 17, 66115 Saarbrücken, Germany - Registergericht/Commercial register: Saarbrücken HRB 19681 http://www.softwareag.com
