"alesj" wrote : | I'm just asking, since after reading this | - http://www.osgi.org/blog/2008/02/research-challenges-for-osgi.html | I started thinking about the challenge | If you don't track references properly then you're bound to get that problem. Even when you do, e.g. the MC or declaritive services in OSGi, the user might still leak the type into somebody else's singleton (apache clogging, digester, etc. you are guilty here! ;-) anonymous wrote : | http://post-office.corp.redhat.com/mailman/private/jboss-osgi-dev-list/20... | Post it in public if you want others to be able to comment. anonymous wrote : | in more mathematical fashion, providing some concrete proof for the actual algorithm used, time usage wise. It boils down to graph theory, and finding some known problem to 'map' this usage to it. | It's not a graph, although it might look like one in the raw data. Like I said elsewhere, "I know how to do it". The trick is to actually to try to collapse it into a group of Sets of related classloader exports and when that is impossible (e.g. conflicting versions) you fail the one that wants to join. Like I also said elsewhere, there's some "Gotchas", More details: * hot deployment - merging/disjoining sets (if disjoining is a word? ;-) * recursion - resolving classloader references leads to deployment from the repository * circular references * etc. anonymous wrote : | A quick thought. | How does re-wiring stand against the actual ClassLoader usage. | e.g. we already have wired bundles, | We wires "ClassLoaderPolicy"s, but yes they are similar to what the OSGi spec calls wires. (Part of what they call wires is done by the RequirementDependencyItem). anonymous wrote : | and we want to add a new one. But with the current wiring that is not possible (possibly some 'uses' constraints in the way), but if we re-wire things, we might be able to wire the new bundle as well. | I guess that means uninstalling current deployments, and installing them back on after we 'discovered' that there is a wire configuration that makes everyone happy. :-) Correct. Although I doubt we would enable this by default. Undeploying an application (however temporarily) because some other related application wants to join the group with conflicting requirements isn't a very good semantic for a production machine. OSGi requires a seperate invocation on an "update classes" method. It could be a useful feature for developers who just want to drop a updated package into "deploy" and have everything re-adjust. i.e. try it, if it fails, see if it would work if you redeployed those that are conflicting and if so, do that by invoking the "udpate classes" automatically. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133254#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...