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
