More comments inline.
Luciano Resende wrote:
Comments inline...
On 4/24/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Luciano Resende wrote:
>> I was thinking that Class loading would be the responsibility of the
>> ArtifactResolver. So, we wouldn't need a ClassLoader, we would call
>> ArtifactResolver.resolve() to get the Class, like for all other
>> artifacts resolved in an SCA contribution.
>
> I think that the packageProcessor should be the one creating the
> necessary
> contribution classLoader, but how does the resolver will get a
> reference to
> it ?
>
> I can have it done if you haven't started it yet....
>
I have started to put together a class that we can use as a key to
resolve classes, I'll commit it soon and then if you want I leave the
rest to you :)
With respect to passing a classloader to the DefaultArtifactResolver,
here's what I think: SimpleRuntimeImpl currently creates a single
DefaultArtifactResolver, independent of any SCA Contribution. This works
for now as SimpleRuntimeImpl only handles a single Contribution, but
what we really need is:
- one ArtifactResolver per Contribution
How are you going to resolve things external to the contribution then ?
Let's say on the case of import/exports ?
- one ClassLoader per Contribution
+1
Good question, the short answer is: it depends... :)
My first cut of this email was actually saying "or a ClassLoader per
contribution graph when/if we support contribution dependencies at some
point", but I removed that sentence before sending it for a number of
reasons, including:
- Imports/exports do not cover classes at the moment, they cover XML
namespaces, if we want to cover imports of Java artifacts we'll have to
introduce a new <import.java> for example, and clearly define what it means
- Imports/exports do not point to contributions, they point to location
URIs, which can take any form, can be resolved in a runtime specific
way, and point to other contributions, or not :)
- An obvious way to support Java imports and Contribution dependency
graphs for Java artifacts would be to use OSGI, but then maintaining a
graph of ClassLoaders ourselves would probably get in the way of OSGI,
and it may be much simpler to let OSGI maintain the ClassLoader graph
and have our runtime just point to the top bundle ClassLoader, or not :)
I guess we'll have to figure this out when we look at this integration
in details again.
- Finally, I think that the hosting environment has a role to play to
establish, select and maintain ClassLoaders. Different hosting
environments will probably come with very different ClassLoader
management schemes.
So I think that there are enough unknowns here to not try to boil the
ocean with our own homegrown ClassLoader hierarchy management scheme
right now... and suggest to start simple with one ClassLoader per SCA
Contribution. We can define the semantics of an <import.java> extension
to the spec later, assuming that we even need that, and worry about how
that maps to ClassLoaders in the various hosting environments then.
- and the ArtifactResolver can get the Contribution's ClassLoader passed
to its constructor.
+1
I'm not sure if having the PackageProcessor create the ClassLoader is
the best solution as the hosting environment needs to have a say with
respect to which ClassLoader is used for what, but I guess we can start
with that approach at least now to make progress, and change later when
we have a better idea of how this fits with the various hosting
environments.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
