> -----Original Message-----
> From: ixxus nexxus [mailto:[EMAIL PROTECTED]
> Sent: 02 December 2004 05:27
> To: Avalon framework users
> Subject: RE: classloaders?
>
> 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;
> }
My fist impression is that the problem is related to the ds.DsException
class. Although this is listed in the classloader's classpath it is
declared as a file relative to ${user.dir} which is generally speaking a
bad thing because your deployment requires that these jars are present
at a relative location to wherever you run merlin from.
In particular I would suggest revising the following two entries to be
repository based:
file:/temp/xxx-1.2-src/repository/xxx/jars/server-impl-1.2.jar;
file:/ds/lib/ds.jar;file:
Steve.
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
