Siamak, two Country classes would mean that I would spent a lot of code and processor time converting between the two, so that is not the solution.
Peter, the problem is quite common I think. And moreover I think that solving it can give a start to a very interesting area: having an ability to select a subset of a generic domain model can give a start to building reusable domain models. There could be e.g. a de-facto standard model describing geographics (with the Country class), in all possible details, something like joda for date/time manipulations, and all other software would use the required subsets of this model, thus making model-to-model conversions obsolete (I think you'll agree that such conversions take up a lot of unnecessary "dull" code). And that is a great step to further simplifying the code, don't you think? On Mon, Jun 27, 2011 at 5:12 PM, Peter Kriens <[email protected]> wrote: > You've a relatively common problem though from what I hear you might have > given in too much to your customers. That would be ok if they also paid the > very steep cost that comes along with this leniency, which in my experience > is often not the case. The often think this should be free. > > However, to give anymore than this rather superficial judgement I'd have to > spent much more time analyzing the situation and that is hard to do on a > mailing list. You can of course always contact me for a quote to provide > consultancy. > > Kind regards, > > Peter Kriens > > > > > On 27 jun 2011, at 14:13, Alexander Shutyaev wrote: > >> 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 > > > _______________________________________________ > 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
