[
https://issues.apache.org/activemq/browse/CAMEL-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated CAMEL-1718:
---------------------------------------
Attachment: Main cluster after.png
camel-core.patch
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 cycles.
> Make management independent of impl
> -----------------------------------
>
> Key: CAMEL-1718
> URL: https://issues.apache.org/activemq/browse/CAMEL-1718
> 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.
