You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by fordan <da...@main.se> on 2006/11/27 08:59:12 UTC
Classpath issue with SUs
Hello !
We are using SM 3.1 SNAPSHOT version and discovered a problem while running
a service which is located inside a SU. I read that there were other that
had similiar problem, but at least think this is unique. The application we
have are quite simple. An SA containing 2 SUs. The SUs have a lot of
dependicies in poms. And the jars are included in the SA. The problem is
that we must put the dependicies both inside SA and servicemix classpath
dir. I should'nt be like that i think. I should only
be necessery to include the dependicies in the SA or ? I mean the jbi.xml
for SUs does not contain any component classpath locations. Is'nt that
necessery. At least its not generated for us. There is maven-jar-plugin that
can be used also, to manipulate manifest information to incliude
lib\some.jar .
Or are there any settings for maven-jbi-plugin that we can use ? I read
about the serviceunitAnalyzer, i will test that this morning.
Can somone please help?
Thanks Daniel
--
View this message in context: http://www.nabble.com/Classpath-issue-with-SUs-tf2710306s12049.html#a7556143
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Classpath issue with SUs
Posted by Guillaume Nodet <gn...@gmail.com>.
You should be able to just write
<classpath inverse="true" />
If you don't add any <location/> tag, the default ones will be used.
On 11/27/06, fordan <da...@main.se> wrote:
>
> Hi !
> Yes of course i meant that. I have now read the classloader document again.
> We are running 3.1 so it shall work, but it does not. The only thing that
> may be
> changed is the delegation order because it searches in the container
> classpath
> appearantly. So i must add the to loaction explicitly lib/*jar and set
> inverse to true.
> Is that correct ?
>
> Thanks for help
> Daniel
>
>
> gnodet wrote:
> >
> > First, jars can only be included in a SU, not in the SA directly.
> > Starting from 3.1, the SU classpath will automatically contain
> > the root SU dir and any jar/zip inside the lib folder of the SU.
> > This information is not included in the jbi.xml, but is create at runtime
> > if not overriden by a <classpath/> tag inside the xbean.xml file
> > for the SU.
> > See http://servicemix.goopen.org/site/classloaders.html
> >
> > On 11/27/06, fordan <da...@main.se> wrote:
> >>
> >> Hello !
> >>
> >> We are using SM 3.1 SNAPSHOT version and discovered a problem while
> >> running
> >> a service which is located inside a SU. I read that there were other that
> >> had similiar problem, but at least think this is unique. The application
> >> we
> >> have are quite simple. An SA containing 2 SUs. The SUs have a lot of
> >> dependicies in poms. And the jars are included in the SA. The problem is
> >> that we must put the dependicies both inside SA and servicemix classpath
> >> dir. I should'nt be like that i think. I should only
> >> be necessery to include the dependicies in the SA or ? I mean the jbi.xml
> >> for SUs does not contain any component classpath locations. Is'nt that
> >> necessery. At least its not generated for us. There is maven-jar-plugin
> >> that
> >> can be used also, to manipulate manifest information to incliude
> >> lib\some.jar .
> >> Or are there any settings for maven-jbi-plugin that we can use ? I read
> >> about the serviceunitAnalyzer, i will test that this morning.
> >>
> >> Can somone please help?
> >>
> >> Thanks Daniel
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Classpath-issue-with-SUs-tf2710306s12049.html#a7556143
> >> Sent from the ServiceMix - User mailing list archive at Nabble.com.
> >>
> >>
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Classpath-issue-with-SUs-tf2710306s12049.html#a7557279
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
Re: Classpath issue with SUs
Posted by fordan <da...@main.se>.
Hi !
Yes of course i meant that. I have now read the classloader document again.
We are running 3.1 so it shall work, but it does not. The only thing that
may be
changed is the delegation order because it searches in the container
classpath
appearantly. So i must add the to loaction explicitly lib/*jar and set
inverse to true.
Is that correct ?
Thanks for help
Daniel
gnodet wrote:
>
> First, jars can only be included in a SU, not in the SA directly.
> Starting from 3.1, the SU classpath will automatically contain
> the root SU dir and any jar/zip inside the lib folder of the SU.
> This information is not included in the jbi.xml, but is create at runtime
> if not overriden by a <classpath/> tag inside the xbean.xml file
> for the SU.
> See http://servicemix.goopen.org/site/classloaders.html
>
> On 11/27/06, fordan <da...@main.se> wrote:
>>
>> Hello !
>>
>> We are using SM 3.1 SNAPSHOT version and discovered a problem while
>> running
>> a service which is located inside a SU. I read that there were other that
>> had similiar problem, but at least think this is unique. The application
>> we
>> have are quite simple. An SA containing 2 SUs. The SUs have a lot of
>> dependicies in poms. And the jars are included in the SA. The problem is
>> that we must put the dependicies both inside SA and servicemix classpath
>> dir. I should'nt be like that i think. I should only
>> be necessery to include the dependicies in the SA or ? I mean the jbi.xml
>> for SUs does not contain any component classpath locations. Is'nt that
>> necessery. At least its not generated for us. There is maven-jar-plugin
>> that
>> can be used also, to manipulate manifest information to incliude
>> lib\some.jar .
>> Or are there any settings for maven-jbi-plugin that we can use ? I read
>> about the serviceunitAnalyzer, i will test that this morning.
>>
>> Can somone please help?
>>
>> Thanks Daniel
>> --
>> View this message in context:
>> http://www.nabble.com/Classpath-issue-with-SUs-tf2710306s12049.html#a7556143
>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
>
>
--
View this message in context: http://www.nabble.com/Classpath-issue-with-SUs-tf2710306s12049.html#a7557279
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Classpath issue with SUs
Posted by Guillaume Nodet <gn...@gmail.com>.
First, jars can only be included in a SU, not in the SA directly.
Starting from 3.1, the SU classpath will automatically contain
the root SU dir and any jar/zip inside the lib folder of the SU.
This information is not included in the jbi.xml, but is create at runtime
if not overriden by a <classpath/> tag inside the xbean.xml file
for the SU.
See http://servicemix.goopen.org/site/classloaders.html
On 11/27/06, fordan <da...@main.se> wrote:
>
> Hello !
>
> We are using SM 3.1 SNAPSHOT version and discovered a problem while running
> a service which is located inside a SU. I read that there were other that
> had similiar problem, but at least think this is unique. The application we
> have are quite simple. An SA containing 2 SUs. The SUs have a lot of
> dependicies in poms. And the jars are included in the SA. The problem is
> that we must put the dependicies both inside SA and servicemix classpath
> dir. I should'nt be like that i think. I should only
> be necessery to include the dependicies in the SA or ? I mean the jbi.xml
> for SUs does not contain any component classpath locations. Is'nt that
> necessery. At least its not generated for us. There is maven-jar-plugin that
> can be used also, to manipulate manifest information to incliude
> lib\some.jar .
> Or are there any settings for maven-jbi-plugin that we can use ? I read
> about the serviceunitAnalyzer, i will test that this morning.
>
> Can somone please help?
>
> Thanks Daniel
> --
> View this message in context: http://www.nabble.com/Classpath-issue-with-SUs-tf2710306s12049.html#a7556143
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet