Thanks, Peter! I'll read it and see if this suits me. Anyway my original question is open - the problem is quite complex and I would be interested in any other POVs and solutions.
On Mon, Jun 27, 2011 at 2:15 PM, Peter Kriens <[email protected]> wrote: > I wrote a blog about this some time ago: > http://www.osgi.org/blog/2007/02/osgi-extender-model.html > > Basically it is a bundle watching other bundles and wiring them up in some > way. I.e. Spring DM has an extender bundle that reads the XML from the bundle > and then performs its magic. You could do something similar with your headers. > > Kind regards, > > Peter Kriens > > > > On 27 jun 2011, at 10:21, Alexander Shutyaev wrote: > >> Thanks for your answer, Peter. The term 'extender model' is unknown to >> me but I like it's name.. Could you please provide me with a start >> point to find out what this is and how should you cook it? =) >> >> On Mon, Jun 27, 2011 at 12:15 PM, Peter Kriens <[email protected]> >> wrote: >>> Well, the key issue is if you want to do this with dynamic weaving where an >>> unknown set of other weavers might be active and you get all kinds of >>> ordering dependencies. I haven't got a lot of experience with weaving but >>> anytime I see code moving out of Java into XML and other things like >>> weavers I can't help myself worrying about a lot of additional complexity >>> that must be managed. Especially if you use it with the other example where >>> there is no two-way mapping between the entities. I am also a bit surprised >>> because you still need the generated code to compile against? >>> >>> Anyway, I have no clear-cut solution as this architecture though I think >>> the extender model could be used here. However, the solution is too far >>> removed from my comfort zone. That said, I am looking forward to read how >>> others solve this problem :-) Good luck! >>> >>> Kind regards, >>> >>> Peter Kriens >>> >>> >>> >>> On 27 jun 2011, at 10:01, Alexander Shutyaev wrote: >>> >>>> Well, the thing that made me invent all this is that we have different >>>> projects (branches of our application) that have many common parts and >>>> some project-specific. Let me provide a real example. >>>> >>>> Currently our app is not OSGi based, but we also have a basic plugin >>>> framework. Now we have plugins that provide functionality to connect >>>> to some external systems A and B: >>>> >>>> org.foo.systema >>>> org.foo.systemb >>>> >>>> System A uses 2char country codes, System B uses 3char country codes. >>>> These plugins reference the same class org.foo.model.Country >>>> >>>> Next we have 2 branches of our app: Branch1, Branch2. >>>> >>>> Branch1 uses Systems A and B, Branch2 uses System A only. >>>> >>>> Currently we store all plugins in an SVN repo and include it in our >>>> projects as svn-externals. This means that all plugins are built for >>>> each project separately. Our plugins have an xml file called model.xml >>>> like this: >>>> >>>> model.xml in plugin org.foo.model: >>>> >>>> <entity id="org.foo.model.Country"> >>>> <field name="name" type="String"/> >>>> <entity/> >>>> >>>> model.xml in plugin org.foo.systema: >>>> >>>> <entity id="org.foo.model.Country"> >>>> <field name="iso2Code" type="String"/> >>>> <entity/> >>>> >>>> model.xml in plugin org.foo.systemb: >>>> >>>> <entity id="org.foo.model.Country"> >>>> <field name="iso3Code" type="String"/> >>>> <entity/> >>>> >>>> we use custom code generation that merge all these xml files that are >>>> available from plugins connected as svn-externals and build the final >>>> org.foo.model.Country class, so Branch2 doesn't have iso3Code field in >>>> Country class as it doesn't have plugin org.foo.systemb at codegen and >>>> compile time. And that is right, because Branch2 doesn't require this >>>> field at all. >>>> >>>> Maybe this seems a little bit wiredrawn for Country, but with things >>>> like Order or Customer it's the common case - one client wants to know >>>> everything about their customer in a structurized way (like phones, >>>> addresses and so on) while other are too lazy for so many fields and >>>> require just a free text field "Contact Info" etc. >>>> >>>> Now what I want is to use OSGi but can't find a way to correctly >>>> implement our domain model bundles. So I thought that there should be >>>> a base bundle that will provide Country class with "name" field only >>>> and something like aspects to weave fields required by other bundles >>>> (like org.foo.systema and org.foo.systemb) >>>> >>>> >>>> On Mon, Jun 27, 2011 at 11:20 AM, Peter Kriens <[email protected]> >>>> wrote: >>>>> 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 >>>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> _______________________________________________ >> 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 > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
