[GitHub] camel pull request #1259: add prefix when initialize the s3endpoint and buck...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/camel/pull/1259


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Camel.2.18.x.notest - Build # 5 - Failure

[Apache Jenkins Server]

The Apache Jenkins build system has built Camel.2.18.x.notest (build #5)

Status: Failure

Check console output at https://builds.apache.org/job/Camel.2.18.x.notest/5/ to 
view the results.

[GitHub] camel pull request #1259: add prefix when initialize the s3endpoint and buck...

[darrenxyli]

GitHub user darrenxyli opened a pull request:

https://github.com/apache/camel/pull/1259

add prefix when initialize the s3endpoint and bucket check. 

Use Case:
When AWS access key only has permission to specific path under bucket, the 
bucket check will fail.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/darrenxyli/camel endpoint-prefix-verify

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/1259.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1259






---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Time for an overhaul of the patterns symbols?

[Tadayoshi Sato]

Hello,

Let me offer my thoughts. I think it's a good idea to somehow refresh the
EIP icons/diagrams and contribution is always great. However:

> the diagrams symbolize the essence of what Camel does.

Yes, but it also has a broader context: They actually symbolize the essence
of what most of the current competitive ESB or integration frameworks do in
common. They are symbols of our shared wisdom and best practices on systems
integration.

> However the graphics don't all seem to be in the same style, and some are
missing.

I haven't thought they aren't in the same style. Which one do you think
so?  Please note that in the original EIP book there are good reasons why
some icons are rectangles and some are not (and maybe why some are missing
originally as well). For example, in my understanding the Control Bus
pattern doesn't have a rectangle icon because in the context of the
original book it's rather an architectural pattern, while most rectangle
patterns are a component-level one.

Note also that some are missing just because they are devised (or
discovered) after the EIP book. So it might be a good idea to fill the gap
and devise a new icon for those new patterns, in the same style as in the
EIP book.

So, refreshing the icons is a good idea but I hope they won't diverge too
far from the original ones, because identity is the key for software
patterns in general.

Best regards,
Tadayoshi

On Tue, Nov 8, 2016 at 9:06 PM, Francis Vila  wrote:

> Hi,
>
> I am new to both Camel and to open-source contributing, so forgive any
> breaches of protocol...
>
> The page on  http://camel.apache.org/enterprise-integration-patterns.html
>    shows an
> impressive list of patterns. However the graphics don't all seem to be in
> the same style, and some are missing. To me (although I don't have an
> in-depth understanding of Camel), the diagrams symbolize the essence of
> what
> Camel does. Maybe a homogeneous, updated styleset would be a good idea?
> I think I can contribute to such an task. I've done some tests of different
> approaches for the /Message router /pattern. If this effort is deemed
> worthwhile by the community, I can go on with the rest. The graphics were
> done using Inkscape and are available in svg format.
>
> This is the simplest version:
> 
>
> This version has added endpoints symbolizing the input and output locations
> for the origin and destination of the messages :
> 
>
> This version encloses the pattern:
> 
>
> This version puts emphasis on the the most important part of the diagram,
> namely the currently active path:
> 
>
> This version targets the emphasis more closely, to just the "mobile" part
> of
> the diagram:
> 
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/Time-for-an-overhaul-of-the-patterns-symbols-tp5789901.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>

[GitHub] camel pull request #1255: Support CamelHttpUri inside netty4-http Producer s...

[derekbassett]

Github user derekbassett closed the pull request at:

https://github.com/apache/camel/pull/1255


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Help in testing a custom processor

[Quinn Stevenson]

I’ve never done this with Log4j2, so I don’t know how convoluted the appender 
is.

However, I wouldn’t make the appender actually write the data - I’d just 
validate the payload is what I wanted.  

I’d try and create the appender in the unit test, install the appender during 
the initialization of the test, and then call a method on the appender to 
validate the format inside a JUnit assert.  Hopefully that makes sense - I 
don’t have time to work up an example at the moment.

HTH

> On Nov 9, 2016, at 10:28 AM, idioma  wrote:
> 
> Hi, thanks for your reply. It is exactly what I am trying to do as my
> processor is calling a void method that if a certain condition is met prints
> out LOG.info("some text {}", arg1, arg2). The issue is that I can't really
> Unit test the format of the message because it is a void method. I have had
> a look around in terms of custom appenders and found out that with Log4j2
> (which I am currently using) requires a slightly more convoluted solution.
> Here an example:
> 
> import java.io.Serializable;
> import java.util.concurrent.locks.*;
> import org.apache.logging.log4j.core.*;
> import org.apache.logging.log4j.core.appender.AbstractAppender;
> import org.apache.logging.log4j.core.appender.AppenderLoggingException;
> import org.apache.logging.log4j.core.config.plugins.*;
> import org.apache.logging.log4j.core.layout.PatternLayout;
> 
> // note: class name need not match the @Plugin name.
> @Plugin(name="MyCustomAppender", category="Core", elementType="appender",
> printObject=true)
> public final class MyCustomAppenderImpl extends AbstractAppender {
> 
>private final ReadWriteLock rwLock = new ReentrantReadWriteLock();
>private final Lock readLock = rwLock.readLock();
> 
>protected MyCustomAppenderImpl(String name, Filter filter,
>Layout layout, final boolean
> ignoreExceptions) {
>super(name, filter, layout, ignoreExceptions);
>}
> 
>// The append method is where the appender does the work.
>// Given a log event, you are free to do with it what you want.
>// This example demonstrates:
>// 1. Concurrency: this method may be called by multiple threads
> concurrently
>// 2. How to use layouts
>// 3. Error handling
>@Override
>public void append(LogEvent event) {
>readLock.lock();
>try {
>final byte[] bytes = getLayout().toByteArray(event);
>System.out.write(bytes);
>} catch (Exception ex) {
>if (!ignoreExceptions()) {
>throw new AppenderLoggingException(ex);
>}
>} finally {
>readLock.unlock();
>}
>}
> 
>// Your custom appender needs to declare a factory method
>// annotated with `@PluginFactory`. Log4j will parse the configuration
>// and call this factory method to construct an appender instance with
>// the configured attributes.
>@PluginFactory
>public static MyCustomAppenderImpl createAppender(
>@PluginAttribute("name") String name,
>@PluginElement("Layout") Layout layout,
>@PluginElement("Filter") final Filter filter,
>@PluginAttribute("otherAttribute") String otherAttribute) {
>if (name == null) {
>LOGGER.error("No name provided for MyCustomAppenderImpl");
>return null;
>}
>if (layout == null) {
>layout = PatternLayout.createDefaultLayout();
>}
>return new MyCustomAppenderImpl(name, filter, layout, true);
>}
> }
> 
> I wonder whether I am going too far in order to test the log output. I have
> tried to have the log4j2 configurations for the file output working with the
> intent to read the content of the log file, but with no luck. I am not sure
> I can see how to use the above implementation in my test, any idea?
> 
> Thank you,
> 
> I. 
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Help-in-testing-a-custom-processor-tp5789934p5789963.html
> Sent from the Camel Development mailing list archive at Nabble.com.

[GitHub] camel pull request #1258: CAMEL-10426 - Added CuratorMultiMasterLeaderRouteP...

[paoloantinori]

Github user paoloantinori closed the pull request at:

https://github.com/apache/camel/pull/1258


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Help in testing a custom processor

[idioma]

Hi, thanks for your reply. It is exactly what I am trying to do as my
processor is calling a void method that if a certain condition is met prints
out LOG.info("some text {}", arg1, arg2). The issue is that I can't really
Unit test the format of the message because it is a void method. I have had
a look around in terms of custom appenders and found out that with Log4j2
(which I am currently using) requires a slightly more convoluted solution.
Here an example:

import java.io.Serializable;
import java.util.concurrent.locks.*;
import org.apache.logging.log4j.core.*;
import org.apache.logging.log4j.core.appender.AbstractAppender;
import org.apache.logging.log4j.core.appender.AppenderLoggingException;
import org.apache.logging.log4j.core.config.plugins.*;
import org.apache.logging.log4j.core.layout.PatternLayout;

// note: class name need not match the @Plugin name.
@Plugin(name="MyCustomAppender", category="Core", elementType="appender",
printObject=true)
public final class MyCustomAppenderImpl extends AbstractAppender {

private final ReadWriteLock rwLock = new ReentrantReadWriteLock();
private final Lock readLock = rwLock.readLock();

protected MyCustomAppenderImpl(String name, Filter filter,
Layout layout, final boolean
ignoreExceptions) {
super(name, filter, layout, ignoreExceptions);
}

// The append method is where the appender does the work.
// Given a log event, you are free to do with it what you want.
// This example demonstrates:
// 1. Concurrency: this method may be called by multiple threads
concurrently
// 2. How to use layouts
// 3. Error handling
@Override
public void append(LogEvent event) {
readLock.lock();
try {
final byte[] bytes = getLayout().toByteArray(event);
System.out.write(bytes);
} catch (Exception ex) {
if (!ignoreExceptions()) {
throw new AppenderLoggingException(ex);
}
} finally {
readLock.unlock();
}
}

// Your custom appender needs to declare a factory method
// annotated with `@PluginFactory`. Log4j will parse the configuration
// and call this factory method to construct an appender instance with
// the configured attributes.
@PluginFactory
public static MyCustomAppenderImpl createAppender(
@PluginAttribute("name") String name,
@PluginElement("Layout") Layout layout,
@PluginElement("Filter") final Filter filter,
@PluginAttribute("otherAttribute") String otherAttribute) {
if (name == null) {
LOGGER.error("No name provided for MyCustomAppenderImpl");
return null;
}
if (layout == null) {
layout = PatternLayout.createDefaultLayout();
}
return new MyCustomAppenderImpl(name, filter, layout, true);
}
}

I wonder whether I am going too far in order to test the log output. I have
tried to have the log4j2 configurations for the file output working with the
intent to read the content of the log file, but with no luck. I am not sure
I can see how to use the above implementation in my test, any idea?

Thank you,

I. 



--
View this message in context: 
http://camel.465427.n5.nabble.com/Help-in-testing-a-custom-processor-tp5789934p5789963.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: Help in testing a custom processor

[Quinn Stevenson]

If I’m understanding you correctly, you’re trying to test the content of a log 
message being sent to the logging subsystem.  If that’s the case, you could 
write a custom Appender (assuming you use Log4j) that verifies the log event 
has the correct content.

HTH


> On Nov 9, 2016, at 1:19 AM, idioma  wrote:
> 
> I have the following route:
> 
> http://camel.apache.org/schema/spring;>
>
>
>
>
>
> 
> 
> bean:myLogger is my custom processor for formatting the log messages I am
> getting. The process method in my custom processor simply calls a private
> method that appends the type of message (e.g. CC) and the recipients' email.
> I am struggling to see how to test the actual resulting logs. I am using
> CamelSpringTestSupportand I am OK when it comes to testing the myLogger
> endpoint:
> 
> @Produce(uri = "activemq:topic:inbox")
>protected ProducerTemplate template;
> 
>@Override
>protected AbstractApplicationContext createApplicationContext() {
>return new
> ClassPathXmlApplicationContext("file:src/main/resources/my-camel-context.xml");
>}
> 
>@Test
>public void testLogEndpoint() throws Exception {
>String body = "Hello World";
>template.sendBody("activemq:topic:inbox", body);
>LOG.info("This is the message body we sent {} ", body);
>}
> However, I am not really sure how to test the format of the returned logs.
> Do I send the email of the recipients in a similar fashion as the example
> above? But then how do I check whether the format is the correct one? I am
> really looking more for the approach than the actual solution.
> 
> Thank you so much for your help,
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Help-in-testing-a-custom-processor-tp5789934.html
> Sent from the Camel Development mailing list archive at Nabble.com.

Re: Suggestions for new set of integration pattern symbols

[Francis Vila]

Thanks for the feedback @whiskey  !
Not quite sure what you mean about the /need to ‘describe/name/reference’
major ‘conditions or logic predicates’ on message handling inside the box/
Is this the kind of thing you have in mind:
 
This is an example in PowerPoint (maybe not the most popular software among
members of this forum?) with an export to .wmf, ungrouped then with text
edited. 
About formats: I think if we provide .svg files then everyone can convert to
the format most suitable to their editing software.
About text: maybe we can provide 2 versions with / without text




--
View this message in context: 
http://camel.465427.n5.nabble.com/Suggestions-for-new-set-of-integration-pattern-symbols-tp5789901p5789957.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: how to change default namespace ns1 or ns2 added by Camel to custom namespace

[sandesh.naik]

Thanks for replying Zoran

I now think we have the NamespaceConfigurer registered as I can see a debug
message from the configure method appear at app startup and it is also
changing the behaviour of the web service call.

However, in terms of the changed behaviour, not only is the 'ns1' namespace
prefix still not being replaced with 'ser' but the payload of the web
service call appears to be being encoded/encrypted, i.e. -

...

https://domain>/">
PD94bWwgdmVyc2lvb
...
AgICAgICAgICA8L1BvbXNSZXF1ZXN0Pg==


...

Is there some config of CxfEndpointConfigurer/JAXBDataBinding that I need to
specify to stop this?

Also, does CxfEndpointConfigurer/JAXBDataBinding honour the config already
specified in the 'cxf://...' URI?

Thanks again




--
View this message in context: 
http://camel.465427.n5.nabble.com/how-to-change-default-namespace-ns1-or-ns2-added-by-Camel-to-custom-namespace-tp5789743p5789956.html
Sent from the Camel Development mailing list archive at Nabble.com.

[GitHub] camel pull request #1258: CAMEL-10426 - Added CuratorMultiMasterLeaderRouteP...

[paoloantinori]

GitHub user paoloantinori opened a pull request:

https://github.com/apache/camel/pull/1258

CAMEL-10426 - Added CuratorMultiMasterLeaderRoutePolicy



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/paoloantinori/camel CAMEL-10426

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/1258.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1258


commit c940a5cf782de32b1a86c7bbde3fce5e578c50e2
Author: Paolo Antinori 
Date:   2016-11-09T14:07:32Z

CAMEL-10426 - Added CuratorMultiMasterLeaderRoutePolicy




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] camel pull request #1257: CAMEL-9597 update tests to use Mockito instead of ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/camel/pull/1257


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] camel pull request #1257: CAMEL-9597 update tests to use Mockito instead of ...

[kevinearls]

GitHub user kevinearls opened a pull request:

https://github.com/apache/camel/pull/1257

CAMEL-9597 update tests to use Mockito instead of jsendnsca stub



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/kevinearls/camel CAMEL-9597

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/1257.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1257


commit cdef307d49720c65a32ff7169ecdb79596f2802e
Author: Kevin Earls 
Date:   2016-11-09T11:09:42Z

CAMEL-9597 update tests to use Mockito instead of jsendnsca stub




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Alarm system based on Raspberry PI 3, Groovy and Apache Camel

[Igor Suhorukov]

Thank you, Claus!
New Apache Camel example to control CNC machine are coming)



--
View this message in context: 
http://camel.465427.n5.nabble.com/Alarm-system-based-on-Raspberry-PI-3-Groovy-and-Apache-Camel-tp5789628p5789942.html
Sent from the Camel Development mailing list archive at Nabble.com.

[GitHub] camel pull request #1256: CAMEL-10451 camel-undertow - Add multipart request...

[igarashitm]

Github user igarashitm closed the pull request at:

https://github.com/apache/camel/pull/1256


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Suggestions for new set of integration pattern symbols

[Vincent Nonnenmacher]

I like the version 3 and 4 (with the nice round idea of the six version),
as there is always a need to name the box, so an outline is more often
quite mandatory.

The original lib (visio and omnigraffle) could benefit from a nice ‘design
refresh’.

One missing point however in using those blocks in diagrams, is the fact
that there is a need to ‘describe/name/reference’
major ‘conditions or logic predicates’ on message handling inside the box
(a route endpoint/node)

If you take your example, there is often a need to make an arrow pointing
inside
the ‘moving part of the switch’ to describe/reference/annotate what
destination will be chosen.

Having that in mind, will make the overall look and feel of the diagram
easier to grasp as there is no more ‘visual disparity’
in comprehension of the overall picture.



On Wed, Nov 9, 2016 at 8:26 AM, Francis Vila  wrote:

> This post contains an offer to contribute towards the diagrams symbolizing
> the Camel patters, with 6 different suggested formats
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/Suggestions-for-new-set-of-integration-pattern-
> symbols-tp5789901p5789932.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>

Help in testing a custom processor

[idioma]

I have the following route:

http://camel.apache.org/schema/spring;>







bean:myLogger is my custom processor for formatting the log messages I am
getting. The process method in my custom processor simply calls a private
method that appends the type of message (e.g. CC) and the recipients' email.
I am struggling to see how to test the actual resulting logs. I am using
CamelSpringTestSupportand I am OK when it comes to testing the myLogger
endpoint:

@Produce(uri = "activemq:topic:inbox")
protected ProducerTemplate template;

@Override
protected AbstractApplicationContext createApplicationContext() {
return new
ClassPathXmlApplicationContext("file:src/main/resources/my-camel-context.xml");
}

@Test
public void testLogEndpoint() throws Exception {
String body = "Hello World";
template.sendBody("activemq:topic:inbox", body);
LOG.info("This is the message body we sent {} ", body);
}
However, I am not really sure how to test the format of the returned logs.
Do I send the email of the recipients in a similar fashion as the example
above? But then how do I check whether the format is the correct one? I am
really looking more for the approach than the actual solution.

Thank you so much for your help,



--
View this message in context: 
http://camel.465427.n5.nabble.com/Help-in-testing-a-custom-processor-tp5789934.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: Suggestions for new set of integration pattern symbols

[Francis Vila]

This post contains an offer to contribute towards the diagrams symbolizing
the Camel patters, with 6 different suggested formats 



--
View this message in context: 
http://camel.465427.n5.nabble.com/Suggestions-for-new-set-of-integration-pattern-symbols-tp5789901p5789932.html
Sent from the Camel Development mailing list archive at Nabble.com.