In fact, I don't think it has anything to do with not
being able to find classes Service is referencing. I
changed the interface to read:
package a.b;
import java.io.IOException;
/**
* @version 0.1
*/
public interface Service
{
public void send (String a String b
throws IOException;
}
and I still get the same exception. I would hope the
problem is not that it can't find String or
IOException. So what is going on???
--- ixxus nexxus <[EMAIL PROTECTED]> wrote:
> 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.
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
