This is the interface for the service I am trying to write:
The ds class should be in ds.jar. It looks like that one is in the classpath.
Pres is an interface which is also in the server-api.jar
package a.b;
import xxx.Pres;
import java.io.IOException;
import ds.DsException;
/**
* @version 0.1
*/
public interface Service
{
public void send(Pres p, String s)
throws IOException, DsException;
}
What is strange to me is that all the code that is in the implementation of
Service I originally wrote in a class OriginalServiceImpl. This was also
contained in the server-api/server-impl jars. Everything ran fine. Then I
decided that it would make sense re-factor the code into two separate classes
so I moved some of it into ServiceImpl and tried to make OriginalServiceImpl
use Service and things stopped working. Does this have anything to do with
package names, maybe? OriginalService is in a different package than Service.
Thank you for your help.
Stephen McConnell <[EMAIL PROTECTED]> wrote:
> -----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:
> [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
> 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]
---------------------------------
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
