Classloading Issue with SM Ant tasks

[Peter Klotz <pe...@blue-elephant-systems.com>]

Hi,

I'm trying to call SM Ant tasks (e.g. Deploy SA Task) from within a SU.
The Ant-Jars are in the SU (because otherwise one could not call any other
custom Ant task from within the ant task when the corresponding classes are in
the SU).

The problem is that the SM Ant tasks are in the servicemix-core-3.0-*.jar, which
is required by SM of course. And because the classes of the tasks are already
loaded in the SM-Classloader even putting the jar into the SU classpath does not
solve the problem that the Ant Task-class is not found.

A potential solution, not sure though, would be to put the SM Ant tasks into a
separate jar file e.g. servicemix-ant-3.0-*.jar that one could put into the SM
and not into the lib dir.
I'll give this a try manually but would it be feasable in the next realease to
split the ant tasks out of core?

It seems that the ant tasks need servicemix-core (for the tasks itself),
servicemix-jbi and mx4j-*.


Thanks, Peter

Re: Classloading Issue with SM Ant tasks

[Guillaume Nodet <gn...@gmail.com>]

On 8/9/06, Peter Klotz <pe...@blue-elephant-systems.com> wrote:
>
> Hi Guillaume,
>
> Guillaume Nodet wrote:
> > I think the ant tasks could be completely independant of servicemix-core
> > and
> > servicemix-jbi.
> > They use JMX, but we currently use a JMX proxy, so we need the
> interface,
> > but we could easily
> > use plain JMX calls (though it's more difficult to maintain).
> > But source refactoring will not happen before 3.0, I' ve commented the
> JIRA
> > for that
>
> I have tested it, if I put the ant tasks
> org/apache/serviemix/management/jbi/task into a servicemix-ant jar ant
> remove it
> from these classes from the servicemix-core class my problems are solved.
> So you do not really need source refactoring just change the packaging a
> bit. If
> you place such a servicemix-ant jar into lib/optional we can easily remove
> it an
> d package it into the SU. But if it is part of servicemix-core we have to
> re-package th jar files with each release which is a bit ugly.


This problem will also be solved by using the coming xbean 2.6, once
http://issues.apache.org/jira/browse/XBEAN-19 has been commited.
You can even work around the problem by using self-first classloader
delegation is you use your own JBI component (you need to embed
the servicemix ant tasks in the component).
But i'm not sure in which CL the ant jar and ant tasks are, so ...

> (http://issues.apache.org/activemq/browse/SM-527)
> > Do you really need to use ant ? because you could easily bypass the ant
> > tasks as you are inside
> > the JBI container.
>
>
> P.S.: would it be possible to get the newest jetty into SM 3.0, this is
> very
> very critical for us and one cannot simply exchange the jar as there seem
> to
> imcompatibilities.


AFAIK, svn head already use the latest release version of jetty, the rc0.


Thanks, Peter
>
>


-- 
Cheers,
Guillaume Nodet

Re: Classloading Issue with SM Ant tasks

[Peter Klotz <pe...@blue-elephant-systems.com>]

Hi Guillaume,

Guillaume Nodet wrote:
> I think the ant tasks could be completely independant of servicemix-core
> and
> servicemix-jbi.
> They use JMX, but we currently use a JMX proxy, so we need the interface,
> but we could easily
> use plain JMX calls (though it's more difficult to maintain).
> But source refactoring will not happen before 3.0, I' ve commented the JIRA
> for that

I have tested it, if I put the ant tasks
org/apache/serviemix/management/jbi/task into a servicemix-ant jar ant remove it
from these classes from the servicemix-core class my problems are solved.
So you do not really need source refactoring just change the packaging a bit. If
you place such a servicemix-ant jar into lib/optional we can easily remove it an
d package it into the SU. But if it is part of servicemix-core we have to
re-package th jar files with each release which is a bit ugly.

> (http://issues.apache.org/activemq/browse/SM-527)
> Do you really need to use ant ? because you could easily bypass the ant
> tasks as you are inside
> the JBI container.


P.S.: would it be possible to get the newest jetty into SM 3.0, this is very
very critical for us and one cannot simply exchange the jar as there seem to
imcompatibilities.


Thanks, Peter

Re: Classloading Issue with SM Ant tasks

[Guillaume Nodet <gn...@gmail.com>]

I think the ant tasks could be completely independant of servicemix-core and
servicemix-jbi.
They use JMX, but we currently use a JMX proxy, so we need the interface,
but we could easily
use plain JMX calls (though it's more difficult to maintain).
But source refactoring will not happen before 3.0, I' ve commented the JIRA
for that
(http://issues.apache.org/activemq/browse/SM-527)
Do you really need to use ant ? because you could easily bypass the ant
tasks as you are inside
the JBI container.


On 8/9/06, Peter Klotz <pe...@blue-elephant-systems.com> wrote:
>
> Hi,
>
> I'm trying to call SM Ant tasks (e.g. Deploy SA Task) from within a SU.
> The Ant-Jars are in the SU (because otherwise one could not call any other
> custom Ant task from within the ant task when the corresponding classes
> are in
> the SU).
>
> The problem is that the SM Ant tasks are in the servicemix-core-3.0-*.jar,
> which
> is required by SM of course. And because the classes of the tasks are
> already
> loaded in the SM-Classloader even putting the jar into the SU classpath
> does not
> solve the problem that the Ant Task-class is not found.
>
> A potential solution, not sure though, would be to put the SM Ant tasks
> into a
> separate jar file e.g. servicemix-ant-3.0-*.jar that one could put into
> the SM
> and not into the lib dir.
> I'll give this a try manually but would it be feasable in the next
> realease to
> split the ant tasks out of core?
>
> It seems that the ant tasks need servicemix-core (for the tasks itself),
> servicemix-jbi and mx4j-*.
>
>
> Thanks, Peter
>
>


-- 
Cheers,
Guillaume Nodet