> -----Original Message-----
> From: ixxus nexxus [mailto:[EMAIL PROTECTED]
> Sent: 02 December 2004 20:27
> To: Avalon framework users
> Subject: RE: classloaders?
>
> 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???
I'm not sure.
However - you have narrowed things down substantially. We now know that
the reporting from Merlin was in fact spot-on - the issue is that the
Service class is not being found and that is not an issue with the
Service class itself. According to your earlier email the server api
class is in the file server-api-1.2.jar which is referenced in the
classloader as:
${user.dir}/./repository/xxx/jars/server-api-1.2.jar;
However it appears that the classloader is not finding the class. I've
checked into the 3.2.5 code and we have this:
if( getLocalLogger().isDebugEnabled() )
{
String str = "classpath: " + StringHelper.toString( m_classpath
);
getLocalLogger().debug( str );
}
m_packages = buildOptionalPackages(
m_classpath, context.getOptionalPackages() );
m_urls = buildQualifiedClassPath();
m_classLoader =
new URLClassLoader( m_urls, context.getClassLoader() );
>From your logging information we can see that the classpath contains the
jar file that contains the Service class. If any of the urls in the
classpath were badly formed we would have got an exception - however -
this does not guarantee that the url is actually pointing to a file that
exists and this compounded by the fact that a URLClassLoader will simply
swallow any errors related to urls that don't resolve to real content.
I know your going to answer yes to the next question - but I'll ask
anyway. Can you confirm that the file path
{user.dir}/repository/xxx/jars/server-api-1.2.jar is good?
Otherwise - I think we are going to have to move this over to Metro and
take it from there.
Stephen.
>
>
>
> --- 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
