camel-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [CONF] Apache Camel > Camel 2.9 - JMX and reducing Spring dependency
Date Thu, 14 Jul 2011 06:45:00 GMT
    <base href="">
            <link rel="stylesheet" href="/confluence/s/2042/9/1/_/styles/combined.css?spaceKey=CAMEL&amp;forWysiwyg=true"
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
    <h2><a href="">Camel
2.9 - JMX and reducing Spring dependency</a></h2>
    <h4>Page  <b>added</b> by             <a href="">Claus
    <div class="notificationGreySide">
         <h2><a name="Camel2.9-JMXandreducingSpringdependency-Camel2.9JMXandreducingSpringdependency"></a>Camel
2.9 - JMX and reducing Spring dependency</h2>

<p>This note covers the goal for Camel 2.9 to reduce Spring dependency in <tt>camel-core</tt>
and other <a href="/confluence/display/CAMEL/Components" title="Components">Components</a>
where Spring is not really needed.</p>

<h3><a name="Camel2.9-JMXandreducingSpringdependency-Background"></a>Background</h3>

<p>In <tt>camel-core</tt> we support Spring JMX annotations when we enlist
MBeans in JMX. In fact Spring JMX must be on the classpath to be able to use JMX with Camel
at all.<br/>
If Spring JARs is not on the classpath, Camel will automatic disable JMX. This puts a burden
on end users of Camel who may not use Spring to include 8+ Spring JARs to have support for
JMX. </p>

<p>Some Camel <a href="/confluence/display/CAMEL/Components" title="Components">Components</a>
such as <a href="/confluence/display/CAMEL/Velocity" title="Velocity">Velocity</a>,
<a href="/confluence/display/CAMEL/FreeMarker" title="FreeMarker">FreeMarker</a>,
<a href="/confluence/pages/createpage.action?spaceKey=CAMEL&amp;title=XSTL&amp;linkCreation=true&amp;fromPageId=27821715"
class="createlink">XSTL</a> uses Spring Resource API to load resources over the classpath
etc. This does not work in OSGi blueprint, etc. Instead we should rely on the <a href="/confluence/display/CAMEL/Pluggable+Class+Resolvers"
title="Pluggable Class Resolvers">Pluggable Class Resolvers</a> provided by Camel
that works with OSGi, JBoss and other containers. </p>

<h3><a name="Camel2.9-JMXandreducingSpringdependency-Design"></a>Design</h3>

<p>The Spring JMX annotation support code in <tt>camel-core</tt> should
be moved to <tt>camel-spring</tt>. This allows people to keep using Spring JMX
We should add a SPI plugin in <tt>camel-core</tt> so <tt>camel-spring</tt>
can hook in the Spring JMX annotation support it now provides. Likewise 3rd party can inject
their custom integration.</p>

<p>We should provide a basic set of Camel JMX annotations in <tt>camel-core</tt>
that the various Camel <a href="/confluence/display/CAMEL/Components" title="Components">Components</a>
should use. This ensures we its stil easy to have <a href="/confluence/display/CAMEL/Components"
title="Components">Components</a> enlist in JMX with custom attributes and operations.
For example Apache ActiveMQ has a set of JMX annotations as well.</p>

<p>This also allows Camel end users to use these new Camel JMX annotations in their
custom Camel components. Then they do not need to use Spring JMX annotations, and thus bring
in maybe unneeded dependency on Spring JARs in their code.</p>

<p>The <tt>ResourceEndpoint</tt> from <tt>camel-spring</tt>
should be moved to <tt>camel-core</tt> and rely on <tt>ClassResolver</tt>
API from Camel to load resources from the classpath.<br/>
We would need to add support for the http scheme, and the file scheme. But those are easy.
Then we can migrate the <a href="/confluence/display/CAMEL/FreeMarker" title="FreeMarker">FreeMarker</a>,
<a href="/confluence/display/CAMEL/Velocity" title="Velocity">Velocity</a>, <a
href="/confluence/display/CAMEL/XSLT" title="XSLT">XSLT</a> components to not depend
on Spring/camel-spring.</p>

<h3><a name="Camel2.9-JMXandreducingSpringdependency-ReducingruntimeJARs"></a>Reducing
runtime JARs</h3>

<p>Since Spring JARs will no longer be mandatory on the classpath for JMX support, we
can reduce the runtime JAR dependency for Camel end users. Most end users of Camel will need
to support JMX, so essentially we force them to add Spring JARs. That means they only need
slf4j logging and commons-management JARs.</p>

<h3><a name="Camel2.9-JMXandreducingSpringdependency-Portingcommonsmanagementtocamelcore"></a>Porting
commons-management to camel-core</h3>

<p>Currently <tt>camel-core</tt> rely on <a href=""
class="external-link" rel="nofollow">commons-management</a> for basic JMX support.
We should consider porting this code into the <tt>camel-core</tt> codebase.<br/>
This reduces the mandatory JARs for <tt>camel-core</tt> to only the sfl4j logging
API. This is as low as we can get.</p>

<h3><a name="Camel2.9-JMXandreducingSpringdependency-OthercomponentsusingSpring"></a>Other
components using Spring</h3>

<p>The <a href="/confluence/display/CAMEL/Mail" title="Mail">Mail</a> and
<a href="/confluence/display/CAMEL/JMS" title="JMS">JMS</a> component currently
depend on Spring JARs. There is a work in progress patch for the <a href="/confluence/display/CAMEL/Mail"
title="Mail">Mail</a> component to be able to run without Spring. The <a href="/confluence/display/CAMEL/JMS"
title="JMS">JMS</a> component is however heavily dependent on Spring, as it uses
spring-jms. We may in the future consider writing a new light weight JMS component that has
less features, but can work without Spring. However this is not the goal for Camel 2.9.</p>
    <div id="commentsSection" class="wiki-content pageSection">
       <div style="float: right;">
            <a href=""
class="grey">Change Notification Preferences</a>
       <a href="">View
       <a href=";showCommentArea=true#addcomment">Add

View raw message