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.

   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
> 


Mime
View raw message