Domain resolve algorithm

[alesj]

What's the status of this:
- http://jira.jboss.com/jira/browse/JBMICROCONT-182

 protected Object resolve(Controller controller, Module module, Requirement requirement)
 {
 // TODO JBMICROCONT-182 include parent domains in requirements
 // TODO JBMICROCONT-182 check consistency of re-exports
 // TODO JBMICROCONT-182 check for self-dependency
 // TODO JBMICROCONT-182 test circularity

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
- http://post-office.corp.redhat.com/mailman/private/jboss-osgi-dev-list/2008-February/msg00000.html
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.

A quick thought.
How does re-wiring stand against the actual ClassLoader usage.
e.g. we already have wired bundles, 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. :-)

[adrian.brock]

"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! ;-)

http://post-office.corp.redhat.com/mailman/private/jboss-osgi-dev-list/2008-February/msg00000.html

Post it in public if you want others to be able to comment.

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.

A quick thought.
How does re-wiring stand against the actual ClassLoader usage.
e.g. we already have wired bundles,

We call 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).

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.

[adrian.brock]

"alesj" wrote:
What's the status of this:
- http://jira.jboss.com/jira/browse/JBMICROCONT-182

It's a "quality of implementation issue" required for OSGi.
It isn't required for JBoss5 (no OSGi dependencies defined yet) so its on the back burner.

I think most of the work will actually be in creating the test coverage.
I can think of complicated scenarios in OSGi and for example the scoped domains with
(parent first/last) or "importAll" are addtional features beyond what OSGi can do.

[alesj]

Like I said elsewhere, "I know how to do it".

OK, I'll leave it up to you then. :-)

I could see that you have things in place for straight fwd wire-ing.
I just wasn't sure if we wanted to handle the re-wire-ing atm.
Since it would probably require some more work on the algorithm impl.
That's where the hand for help came from. ;-)

And I'm a sucker for such open challenges. :-)

[alesj]

I think most of the work will actually be in creating the test coverage.

I'm working on getting the official RI OSGi testsuite/tck into place for our tests (it's gonna take me a while, since the instructions are useless :-)).
But this should take care of the OSGi specific usage tests, weather our impl is OSGi compliant.

I can think of complicated scenarios in OSGi and for example the scoped domains with (parent first/last) or "importAll" are addtional features beyond what OSGi can do.

Those 'complicated scenarios in OSGi' should already be a part of official testsuite (hopefully, otherwise that tck is rubbish).
But for our extensions, it's of course up to us to provide extensive testing.
And I would suggest we do that as part of our OSGi tck project.
Perhaps eventually putting some stuff back to OSGi, as a possible thoroughly tested extension.

[adrian.brock]

I'll bet the OSGi TCK is non-disclosure correct? So we need to make sure our
public tests are written "clean room", i.e. no copying of tests and
nobody that has seen the TCK tests writing similar public tests.

That's not to say that you can't raise a bug report describing the problem. :-)

I'd be happier porting the relevant eclipse or apache felix tests to our framework
before trying the TCK since those can be distributed under their relevant OS licenses.

[alesj]

I'll bet the OSGi TCK is non-disclosure correct? So we need to make sure our
public tests are written "clean room", i.e. no copying of tests and
nobody that has seen the TCK tests writing similar public tests.

Sure, it's like all TCKs, non-disclosure all the way.

Yup. Tests then become pita.
I guess there is no way of bumping into duplicate effort.
It should be the minimization of that duplication that we should work on.
Or how to we handle this wtr to other TCKs?

That's not to say that you can't raise a bug report describing the problem. :-)

That harsh? Ouch.
You can pretend that you didn't get that error info from tck. ;-)

I'd be happier porting the relevant eclipse or apache felix tests to our framework
before trying the TCK since those can be distributed under their relevant OS licenses.

John? :-)

[johnbailey]

I'd be happier porting the relevant eclipse or apache felix tests to our framework
before trying the TCK since those can be distributed under their relevant OS licenses.

"alesj" wrote:

John? :-)

I will take a look at the Felix test. I have read through the majority of the Felix core, but not much on the test side of things. I will see if there is anything we can use. Would we include these directly, with modifications to bootstrap the MC, or "create" similar tests?

[alesj]

"johnbailey" wrote:
I will see if there is anything we can use. Would we include these directly, with modifications to bootstrap the MC, or "create" similar tests?

I would use them directly.
It would be specially good if we were able to pull them out from some maven2 repo.

And then, like you suggested, just add small bootstrap/integration framework around them for the MC.