camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Schneider (JIRA)" <>
Subject [jira] Updated: (CAMEL-1718) Make management independent of impl
Date Tue, 16 Jun 2009 21:36:35 GMT


Christian Schneider updated CAMEL-1718:

    Attachment: Main cluster after.png

I am not sure if this patch is already ready for inclusion but I post it to get some feedback.

Additional to the issue text I have removed the dependency from impl to management. This is
done by creating the instrumentation lifecycle in builder. So impl does not have to know anything
about the management package. This has the side effect that a simple call to new DefaultCamelContext()
will not activate the InstrumentationLifecycle. This could be a migration issue for some people.

I have also moved MainSupport into an own package main. This will remove some more dependencies
from impl to view. At the moment the new package only has one class but I think it could be
the starting point for factory classes that wire the parts of camel together. At the moment
camel does much of its wiring in the impl and model classes which is bad as it creates many

> Make management independent of impl
> -----------------------------------
>                 Key: CAMEL-1718
>                 URL:
>             Project: Apache Camel
>          Issue Type: Improvement
>          Components: camel-core
>    Affects Versions: 2.0-M2
>            Reporter: Christian Schneider
>             Fix For: 2.0.0
>         Attachments: camel-core.patch, Main cluster after.png
> Currently management and impl are tangled by a InstrumentationLifecycleStrategy and DefaultCamelContext.
For example the DefaultCamelContext decides if JMX should be used and falls back to the DefaultLifecycleStrategy.

> I think DefaultCamelContext should not know about JMX. So my proposal is to add a fallback
lifecycle strategy to IntrumentationLifecycle. So it can delegate to this strategy if jmx
does not work. So this logic can be removed from DefaultCamelContext.
> Another issue is with Service and ServiceSupport. ManagedService refrences ServiceSupport
instead of Service. I think this is only because it needs an isStarted method. So I suggest
to add this method to Service. Of course this means that several classes that implement Service
need one new method but I think this is ok as isStarted can be quite usefull anyway.
> Additionally I would move ServiceSupport to camel as many packages need it. 
> Together these changes make the dependencies much easier to understand and remove cycles.
> I will add a patch for this shortly and hope it can be included into 2.0 as it changes
the API.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message