|
Main /
OSGiAndMoMLParserIf the MoMLParser is to be able to instantiate classes, it looks like we need to define the Eclipse buddy policy for ptolemy.moml so and then register other classes. So Eclipse-BuddyPolicy: registered and all the classes that want to be loaded by the MoMLParser need to have their Eclipse-RegisterBuddy: ptolemy.moml This is a serious downside, since it means that a bundle needs to register with all future users. So, if someone develops a new way to instantiate classes, say a replacement for MoMLParser, then all the currently existing bundles need to register with the new code. This totally prevents the new code from being written as an OSGi bundle from using the existing bundles in new ways. Comment from Aaron: If you were going to replace momlparser for ALL bundles then why not just leave the name of the new bundle as ptolemy.moml? Then there would be no need to update all the buddy bundles. What you are really talking about here are two different versions of the same bundle. So I think this is maybe not that serious of an issue... In November, 2011, erwin delay wrote: "4. MOML Parser : A very important one, to allow loading composites in an OSGi&server context, we've had to add a simple way to register known composites from outside of the "classpath"."
In October, 2011, Thomas Feng wrote: For the MoMLParser issue, several solutions are discussed in these slides: http://www.martinlippert.org/events/WJAX2008-ClassloadingTypeVisibilityOSGi.pdf
"Among those, the approach similar to Spring using CGLib looks clean. Besides, you can also write an automated tool to generate a fragment for each actor domain that adds package imports to MoMLParser's bundle. (This is what I usually do to fix existing bundles with missing imports.)"
|