tuscany-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Nash <n...@apache.org>
Subject Re: Contributions and Runtime Classpath
Date Wed, 21 Dec 2011 17:52:01 GMT
Millies, Sebastian wrote:
>> -----Original Message-----
>> From: Simon Nash [mailto:nash@apache.org]
>> Sent: Wednesday, December 21, 2011 3:26 PM
>> To: user@tuscany.apache.org
>> 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.


> -- 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

View raw message