camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Crickenberger (JIRA)" <>
Subject [jira] Issue Comment Edited: (CAMEL-262) Remove Design Tangles in componts file and impl
Date Tue, 18 Dec 2007 02:56:27 GMT


acricken edited comment on CAMEL-262 at 12/17/07 6:55 PM:

This seems to have broken (at least) DeleteFileStrategy.  FileStrategySupport defines begin/commit
using Endpoint, but the subclasses then define separate methods that use FileEndpoint.  The
end result is that FileStrategySupport takes the begin/commit calls, regardless of the subclass
being used.  Attached is a patch that changes the interface to use FileEndpoint and adds @Override
annotations to ensure the compiler catches something like this next time.

      was (Author: acricken):
    This seems to have broken (at least) DeleteFileStrategy.  On my setup, only FileProcessStrategySupport.commit()
gets called, instead of DeleteFileStrategy.  I have no idea why, as all signs I've found point
to a DeleteFileStrategy being created/stored by the associated FileEndpoint.
> Remove Design Tangles in componts file and impl
> -----------------------------------------------
>                 Key: CAMEL-262
>                 URL:
>             Project: Apache Camel
>          Issue Type: Improvement
>          Components: camel-core
>            Reporter: Christian Schneider
>            Assignee: Guillaume Nodet
>             Fix For: 1.3.0
>         Attachments: FileDeleteRouteTest.patch, FileProcessStrategy.patch, new-no tangle
in impl Main cluster (30).png, new-only one dependency left in components file Main cluster
(2).png, patch2.txt, tangle in componts file Main cluster (13).png, tangle in impl Main cluster
> I have used structure101 on camel and found some design tangles that are quite easy to
> The first is in impl. Defaultcomponent contains a special case to handle ScheduledPollEndpoint.
As they reference each other there is a dependency tangle. I have attached a screenshot from
struture101 with current and suggested status.
> This is the current code:
> if (endpoint instanceof ScheduledPollEndpoint) {
>                 ScheduledPollEndpoint scheduledPollEndpoint = (ScheduledPollEndpoint)endpoint;
>                 scheduledPollEndpoint.configureProperties(parameters);
> }
> My suggestion is to add configureProperties to Endpoint and DefaultEndpoint. So any endpoint
offers this useful method. The code is then simpler and the tangle is resolved:
> endpoint.configureProperties(parameters);
> The second tangle is in components file. The package file and strategy reference each
other heavily. I have attached screenshots of the tangle.
> This is because The strategies are configured directly in Endpoint (package file). My
suggestion is to create a factory inside the package strategy. So there is only on dependency
from file to strategy.  Another reason is that the FileProcessStrategy interface is in the
strategy package. I think this interface belongs to the package file.  Using these two changes
I managed to reduce the dependencies between strategy and file from 12/17 to 8/1. This makes
the code much easier to grasp as you can understand the packages separately.
> I have attached a patch and screenshots for both issues. 
> What do you think?

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

View raw message