On 7/30/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> [snip]
> Luciano Resende wrote:
> > - Another issue I noticed is regarding resolving classReferences.
> > Because loading a given class would never fails (no class loader
> > isolation) there is never going to be delegation to the proper
> > modelResolver from a contribution that is exporting the package. Any
> > ideas here ? Or should we revisit this when we enhance classLoader
> > support?
> >
> >
> Right, SCA Java imports will only be effective in environments using a
> different classloader per SCA contribution, which we have not
> encountered yet. I'd suggest to revisit this when we encounter such an
> environment. For now adding support for Java import/export only helps
> validate the import/export extensibility mechanism.
How about we create such an environment? We seemed to be getting lots of new
function added these days - for things like starting and stopping,
incremental updates, this import/export stuff, etc - but nothing that
actually properly uses the function, and then issues like the above
mentioned class loader problem meaning its actually not at all easy to use
the function when you do try to. I don't think thats so good for the project
as it makes it hard to understand why things a getting so complicated, so
wouldn't it be better to have something 'real' that exercises that code? How
about we create an environment that properly demonstrates using multiple
contributions and all the code and function we're adding around that?
...ant
