> -----Original Message-----
> From: ixxus nexxus [mailto:[EMAIL PROTECTED]
> Sent: 02 December 2004 02:20
> To: Avalon framework users
> Subject: RE: classloaders?
>
> I think I'm using merlin-3.2.4-bis
>
> Are there any simple instructions for switching from
> Merlin to Metro? Is it complicated? I could try it but
> I'm not sure if adding another variable into the mix
> will be constructive.
Metro provides complete binary compatibility with Avalon components
(providing you use the -Xavalon cli switch). The actual overhead is the
fact that Metro is not released yet which means you would be building of
our svn version. Upside is that we have a bunch of tools in place for
things like automatic block generation - and all of the development
community are now active on Metro - which means you will get a lot of
support from other users. Downside is that we are somewhat 'brutal' is
sorting things before a release which means you really need to follow
both the support and dev list on DPML [1] and it pays to setup a
connection to @dplml-metro on irc.freenode.net.
In the medium term - it's a total plus proposition.
> This is the debug output:
<snip/>
> [DEBUG ] (xxx.classloader): classpath:
> file:/temp/xxx-1.2-src/repository/xxx/jars/server-impl-
>
1.2.jar;file:/ds/lib/ds.jar;file:${user.dir}/./repository/xxx/jars/serve
r-
> api-1.2.jar;
OK - so here we see that server-api-1.2.jar is added to the classloader.
But here we have a problem.
> [DEBUG ] (xxx.classloader.scanner): type:
> xxx.SubscriptionManagerImpl
> ---- exception report
<snip/>
> Exception:
> org.apache.avalon.composition.model.ModelException
> Message: Component type [a.b.ServiceImpl] contains a
> reference to the class [a/b/Service] which does not
> exist in the classloader.
So basically - a classloader is constructed based on the information
supplied in you block. When the block is mounted - each of the jar file
are scanned for component type descriptors (xinfo files). In your case
the [a.b.ServiceImpl] class is located and a xinfo loaded. The xinfo
states that the component is defined by the class a.b.ServiceImpl so the
loader attempts to load this class (simply to verify everything before
committing to the next stage). During the attempt to load the class an
exception has occurred indicating that a supporting class is not
available.
The typical reason for this is that the supporting class is referencing
another class that is not available in the classloader chain (the chain
from system classloader to your component classloader).
Could you post the source to the interface class? I'm rather interested
in seeing what the actual service dependencies are - because at the end
of the day - Merlin failed to load the service class and the real
question is why was there a service class loading failure - and why
don't you have something useful in the exception report about this. I.e.
there is something wrong with you api definition but there is also
something wrong with Merlin's reporting of the problem.
Cheers, Steve.
[1] http://www.dpml.net/central/about/resources/lists.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
