Hmm. Why not just change the Country class to have the appropriate
getters/setters? The accidental complexity you create seem to be far, far,
greater than any gains you get? Especially doing this with runtime weaving
seems not to be the right technique for this problem as it creates ordering
issues, feature interaction with other potential weavers, and you basically not
have the convenience of a compiler doing the grunt work.
Or am I missing something?
Kind regards,
Peter Kriens
On 27 jun 2011, at 08:20, Alexander Shutyaev wrote:
> Hi all!
>
> Let me explain my problem with an example. Let's say I have bundle
> foo.model containing class Country:
>
> public class Country {
> private String code; // 2char ISO code
> private String name;
> // getters/setters omitted...
> }
>
> And I have bundle foo.bundle1 which uses this class as is. Next I have
> bundle foo.bundle2 which uses 3char ISO codes to communicate with some
> external system. As if it's not enough I have yet another bundle
> foo.bundle3 which uses 3digit ISO codes to communicate with some other
> external system.
>
> To satisfy their needs I develop some AspectJ aspects which can be
> woven to add the missing properties to my Country class.
>
> I've read about OSGi Weaving Hook Service in R4.3 spec, so my first
> decision was to put each aspect in different bundle and then make e.g.
> foo.bundle3 require the bundle which holds the aspect with 3digit code
> property. But this solution seems a little bit junky and incomplete to
> me:
>
> hell many bundles for each minor aspect
> a lot of runtime weaving
> it's unclear how do I specify which aspects should be woven and which
> shouldn't (e.g. if I have a 3char ISO code aspect but don't have
> foo.bundle2 in framework that aspect should not be woven)
> So I came here to search for a more elegant solution. The goal is clear:
>
> Domain model objects should have only commonly used functionality
> All specific functionality should be available as aspects
> It would be more convenient to have multiple aspects in the same
> bundle and have this bundle have entries in manifest that have a
> meaning like:
>
> Provide-Aspect: foo.model.Country.char3Code
> Provide-Aspect: foo.model.Country.digit3Code
>
> Bundles that require specific functionality should have some entries
> in manifest that have a meaning like:
>
> Require-Aspect: foo.model.Country.char3Code
>
> and only that "import" should trigger the weaving (ideally a new
> bundle with multiple Require-Aspect's should trigger simultaneous
> batch weaving of all the required aspects)
>
> It would be better if the solution would be OSGi-compliant and not
> implementation specific but this is not a must.
>
> P.S. Although I've mentioned AspectJ and OSGi here I would be thankful
> for links to any Java projects that use some other technologies to
> achieve the goals mentioned.
>
> P.P.S. This question at stackoverflow.com -
> http://stackoverflow.com/questions/6349157/dynamic-domain-model-in-java-osgi
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
