...
If we want to implement 2a) and 2b) properly at some point, it might make sense to provide a solution that uses a utility library to implement all classloading (which can then do something different based on whether Tuscany is running inside an OSGi runtime or outside). But the changes required for this will be pervasive across Tuscany code.
| Note | ||
|---|---|---|
| ||
How about going step by step and:
1. try to bootstrap the tuscany runtime with two classloaders: CL1
application code, CL2 runtime
2. extend to CL1 application code, CL2 Tuscany and SCA APIs, CL3 runtime
3. split the runtime in multiple CLs
and on a separate path:
1. try to bootstrap the tuscany runtime with two classloaders: CL1
application code, CL2 runtime
2. split the application code in multiple CLs
We could create integration tests for these configurations (not
necessarily using OSGi, as these can be built with just plain
classloaders IMO), and it would help us identify bad classloader usages,
fix them, and detect+prevent classloader issues over time.
Thoughts?
–
Jean-Sebastien
| Note | ||
|---|---|---|
| ||
I think Raymond's graph of dependencies was helpful in laying out the
visbility relationships. There's also a counterpoint for what things
should NOT be visible. In the following, "see" means that it's
statically referenceable using the same classloader.
1. Application code shouldn't be able to see non-imported contributions,
Tuscany SPIs, or Tuscany runtime code.
2. Tuscany APIs shouldn't be able to see anything else.
3. Tuscany SPIs shouldn't be able to see Tuscany runtime code or
application code.
4. Tuscany runtime code shouldn't be able to see Tuscany runtime code
in other modules, or application code.
5. 3rd party code (not written with knowledge of Tuscany) shouldn't be
able to see Tuscany runtime code, Tuscany SPIs, Tuscany APIs, or
application code.