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
