Is there any way to limit the values for Accept: header for camel-atom and camel-rss?
I'm trying to tap into an atom feed that is requiring the Accept request header to either be application/xml or application/atom+xml. Is there a way to limit the atom feed definition in the uri to specify only those two values? Currently the default for the atom feed appears to be Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Which is way to loose for my requests. Looking at the code for AtomUtils it doesn't appear that parseDocument() allows that. -- View this message in context: http://camel.465427.n5.nabble.com/Is-there-any-way-to-limit-the-values-for-Accept-header-for-camel-atom-and-camel-rss-tp5796439.html Sent from the Camel - Users mailing list archive at Nabble.com.
If mqtt route cannot connect to broker, shutting down entire context
I am using camel 2.15 and am seeing the following: I've defined an mqtt route as follows: mqtt:UnittestInputSecure?host=ssl://172.30.228.23:8883=fred=derf=SecureUnitTestTopic When the mqtt broker is down at 172.30.228.23 and I try to start up my application, the ssl connection times out and the entire camel context executes the DefaultShutdownStrategy. I start several other routes with no ability to connect to the endpoint and they don't do this. Is there a simple way I can address this? If not, what class would I have to extend to prevent the timeout from shutting down the entire context? -- View this message in context: http://camel.465427.n5.nabble.com/If-mqtt-route-cannot-connect-to-broker-shutting-down-entire-context-tp5776207.html Sent from the Camel - Users mailing list archive at Nabble.com.
ConcurrentModificationException in camel-jetty DefaultHttpBinding.doWriteResponse
I'm running camel 2.15.2 and have been performing some load tests on a jetty
consumer component with some POST requests.
My endpoint uri looks like this
jetty:http://0.0.0.0:8080/pe-eh/v1/event?httpMethodRestrict=POST=200=5
I can consistently produce the stack trace seen below without putting much
load on the system (2 threads each sending a request about every 10ms).
Has anyone else seen this? I'm not seeing any real jetty uri options that I
can use to tune this further.
2015-11-11 11:21:04,550 WARN ServletHandler - /pe-eh/v1/event
java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:859)
at java.util.ArrayList$Itr.next(ArrayList.java:831)
at
org.apache.camel.component.http.DefaultHttpBinding.doWriteResponse(DefaultHttpBinding.java:286)
at
org.apache.camel.component.http.DefaultHttpBinding.writeResponse(DefaultHttpBinding.java:231)
at
org.apache.camel.component.jetty.CamelContinuationServlet.service(CamelContinuationServlet.java:198)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1496)
at
org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:45)
Here appears to be the offending code.
public void doWriteResponse(Message message, HttpServletResponse
response, Exchange exchange) throws IOException {
// set the status code in the response. Default is 200.
if (message.getHeader(Exchange.HTTP_RESPONSE_CODE) != null) {
int code = message.getHeader(Exchange.HTTP_RESPONSE_CODE,
Integer.class);
response.setStatus(code);
}
// set the content type in the response.
String contentType = MessageHelper.getContentType(message);
if (contentType != null) {
response.setContentType(contentType);
}
// append headers
// must use entrySet to ensure case of keys is preserved
for (Map.Entry entry :
message.getHeaders().entrySet()) {
String key = entry.getKey();
Object value = entry.getValue();
// use an iterator as there can be multiple values. (must not
use a delimiter)
final Iterator it = ObjectHelper.createIterator(value, null);
while (it.hasNext()) {
*String headerValue =
exchange.getContext().getTypeConverter().convertTo(String.class,
it.next());*
if (headerValue != null && headerFilterStrategy != null
&&
!headerFilterStrategy.applyFilterToCamelHeaders(key, headerValue, exchange))
{
response.addHeader(key, headerValue);
}
}
}
// write the body.
if (message.getBody() != null) {
if (GZIPHelper.isGzip(message)) {
doWriteGZIPResponse(message, response, exchange);
} else {
doWriteDirectResponse(message, response, exchange);
}
}
}
--
View this message in context:
http://camel.465427.n5.nabble.com/ConcurrentModificationException-in-camel-jetty-DefaultHttpBinding-doWriteResponse-tp5773653.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Getting javax.mail.AuthenticationFailedException when trying to consume a gmail.com account folder with imaps://
I am trying to consume email messages from a folder on a gmail.com account using the following URI. imaps://imap.gmail.com?consumer.delay=6delete=falsefolderName=camelmapMailMessage=truepassword=xxpeek=trueunseen=trueusername=myu...@gmail.com And I'm getting the following error: WARN MailConsumer - Consumer Consumer[imaps://imap.gmail.com?consumer.delay=6delete=falsefolderName=camelmapMailMessage=truepassword=xxpeek=trueunseen=trueusername=myu...@gmail.com failed polling endpoint: Endpoint[imaps://imap.gmail.com?consumer.delay=6delete=falsefolderName=camelmapMailMessage=truepassword=xxpeek=trueunseen=trueusername=myu...@gmail.com [^]]. Will try again at next poll. Caused by: [javax.mail.AuthenticationFailedException - [ALERT] Please log in via your web browser: https://support.google.com/mail/accounts/answer/78754 [^] (Failure)] javax.mail.AuthenticationFailedException: [ALERT] Please log in via your web browser: https://support.google.com/mail/accounts/answer/78754 [^] (Failure) at com.sun.mail.imap.IMAPStore.protocolConnect(IMAPStore.java:661) at javax.mail.Service.connect(Service.java:317) at org.apache.camel.component.mail.MailConsumer.ensureIsConnected(MailConsumer.java:497) at org.apache.camel.component.mail.MailConsumer.poll(MailConsumer.java:95) at org.apache.camel.impl.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:174) at org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:101) If I go into the Settings of the myu...@gmail.com account and change the security setting to allow less secure apps to read the emails it works fine. Obviously I really don't want to do that. I suspect it is possible to *programmatically* bump up the security for the consumer using the JSSE utility and the uri parameter sslContextParameters=, but I have no idea how. All the examples with JSSE and mail appear to be for producing emails, not consuming them. Has anyone else run into this issue? Is there a code snippet (not xml) you could point me at that works with consuming emails? -- View this message in context: http://camel.465427.n5.nabble.com/Getting-javax-mail-AuthenticationFailedException-when-trying-to-consume-a-gmail-com-account-folder-w-tp5770711.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: org.apache.camel.FailedToCreateRouteException: Failed to create route with SNMP component
That did the trick. Thanks loads. -- View this message in context: http://camel.465427.n5.nabble.com/org-apache-camel-FailedToCreateRouteException-Failed-to-create-route-with-SNMP-component-tp5768341p5770704.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: org.apache.camel.FailedToCreateRouteException: Failed to create route with SNMP component
It's actually weirder than first appeared. I do have camel-snmp included in the pom.xml file. I should have mentioned that in my original post. I'm beginning to think it's a classloader issue... Oh joy.. Because everything works fine when I run the application within IntelliJ. But when I make it an executable jar file using maven assembly module it can't find the converter. SNMP traps work fine in both cases. So I know the snmp component is being successfully included. It's just when I try to create the SNMP polling route. So my question seems to be more fundamental. How is camel locating classes with the @Converter annotation. Also, it seems to find other @Converters just fine. Example the one in camel-mail. -- View this message in context: http://camel.465427.n5.nabble.com/org-apache-camel-FailedToCreateRouteException-Failed-to-create-route-with-SNMP-component-tp5768341p5770615.html Sent from the Camel - Users mailing list archive at Nabble.com.
org.apache.camel.FailedToCreateRouteException: Failed to create route with SNMP component
I'm using Camel 2.15.2 and suddenly find that context.addRoutes() is throwing the following exception. org.apache.camel.FailedToCreateRouteException: Failed to create route SNMPPoll:udp:172.30.227.153:1.3.6.1.4.1.17491.1.1.2.1.2.201: Route(SNMPPoll:udp:172.30.227.153:1.3.6.1.4.1.17491.1.1.2.1 because of Failed to resolve endpoint: *snmp://172.30.227.153:161?delay=6oids=1.3.6.1.4.1.17491.1.1.2.1.2.201protocol=udpretries=2snmpCommunity=privatesnmpVersion=0type=POLL* due to: *Could not find a suitable setter for property: oids as there isn't a setter method with same type: java.lang.String nor type conversion possible:* No type converter available to convert from type: java.lang.String to the required type: org.apache.camel.component.snmp.OIDList with value 1.3.6.1.4.1.17491.1.1.2.1.2.201 The context is already running and looking at the documentation here http://camel.apache.org/snmp.html http://camel.apache.org/snmp.html and everything appears correct. I'm just using the DefaultCamelContext and trying to do a simple context.addRoutes() call. Any ideas? -- View this message in context: http://camel.465427.n5.nabble.com/org-apache-camel-FailedToCreateRouteException-Failed-to-create-route-with-SNMP-component-tp5768341.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: https4 2.15.2 not recognizing my httpClientConfigurer endpoint option
I think I finally have it working. Not certain it's the ideal solution. But it works and it took me a long time navigating through the debugger to figure things out. My route definition was then from(direct:start).transform(simple(FRED)).to(https4://172.30.228.23:8444/InformaCast/RESTServices/V1/Admin/System/ldap/isLdapConfigured?*sslContextParameters=mydumbtrustmanager*); The key is the implementation of X509TrustManager and when overriding the methods just make certain they don't throw the CertificateException. -- View this message in context: http://camel.465427.n5.nabble.com/https4-2-15-2-not-recognizing-my-httpClientConfigurer-endpoint-option-tp5767922p5768072.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: https4 2.15.2 not recognizing my httpClientConfigurer endpoint option
Spoke too soon. It should look something like this: -- View this message in context: http://camel.465427.n5.nabble.com/https4-2-15-2-not-recognizing-my-httpClientConfigurer-endpoint-option-tp5767922p5768073.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: https4 2.15.2 not recognizing my httpClientConfigurer endpoint option
My class that implements HttpClientConfigurer now looks like this from your suggestions: and it still doesn't work. My createRegistry() looks like this: @Override I added a jndi.properties file that looks like this: My uri now looks like this https4://172.30.228.23:8444/InformaCast/RESTServices/V1/Admin/System/ldap/isLdapConfigured?x509HostnameVerifier=*allHostnameVerifier*httpClientConfigurer=*monteTrustingConfigurer* So I thought I now have all of my ducks in a row. But my sslContext created in configureHttpClient() still isn't calling my isTrusted() method. There must be something I'm still missing for the HttpComponent that isn't matching the uri arguments for x509HostnameVerifier and httpClientConfigurer to my registry. I've done a deep dive into the source code of HttpComponent.java with a debugger. when coming out of createEndpoint() in the source code the endpoint variable appears to at least partially be configured correctly. endpoint.endpointUri=https4://172.30.228.23:8444/InformaCast/RESTServices/V1/Admin/System/ldap/isLdapConfigured?httpClientConfigurer=monteTrustingConfigurerx509HostnameVerifier=allHostnameVerifier endpoint.httpClientConfigurer is set to an instance of my class that implements the above configureHttpClient(), TrustingHttpClientConfigurer. endpoint.*component*.httpClientConfigurer is null (which might be OK if it's only used as the default) endpoint.*component*.x509HostnameVerifier is set to BROWSER_COMPATIBLE (this isn't what I want, but again, may just be a default). But I don't see my override value org.apache.http.conn.ssl.AllowAllHostnameVerifier() Now looking at endpoint.camelContext.registry endpoint.camelContext.registry.context.delegate.defaultInitCtx.bindings.0 monteTrustingConfigurer = instance of TrustingHttpClientConfigurer endpoint.camelContext.registry.context.delegate.defaultInitCtx.bindings.1 java.naming.factory.initial = org.apache.camel.util.jndi.CamelInitialContextFactory endpoint.camelContext.registry.context.delegate.defaultInitCtx.bindings.2 allHostnameVerifier = ALLOW_ALL Does anyone see what other little nuggets of knowledge I'm missing? -- View this message in context: http://camel.465427.n5.nabble.com/https4-2-15-2-not-recognizing-my-httpClientConfigurer-endpoint-option-tp5767922p5768038.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: https4 2.15.2 not recognizing my httpClientConfigurer endpoint option
This still isn't working. It is as though it isn't recognizing my registry
during runtime.
In my unit test I've overrided createRegistry() because I'm not using spring
as your example solution does.
@Override
protected JndiRegistry createRegistry() throws Exception {
JndiRegistry jndi = super.createRegistry();
log.info(createRegistry());
*jndi.bind(allHostname, new
org.apache.http.conn.ssl.AllowAllHostnameVerifier());*
return jndi;
}
Then it doesn't appear that the allHostname object is available during the
test in http4://.
Do you have any ideas why my object isn't available during runtime?
My jndi.properties file looks like this:
java.naming.factory.initial =
org.apache.camel.util.jndi.CamelInitialContextFactory
--
View this message in context:
http://camel.465427.n5.nabble.com/https4-2-15-2-not-recognizing-my-httpClientConfigurer-endpoint-option-tp5767922p5767991.html
Sent from the Camel - Users mailing list archive at Nabble.com.
https4 2.15.2 not recognizing my httpClientConfigurer endpoint option
Like several similar posts I've seen I need to allow self-signed certs for
https4 (2.15.2). Mine isn't working.
I've created an implementation of HttpClientConfigurer that allows any
host/cert. Below is the implementation of configureHttpClient().
@Override
public void configureHttpClient(HttpClientBuilder httpClientBuilder) {
log.debug(configureHttpClient());
try {
SSLContextBuilder builder = new SSLContextBuilder();
builder.loadTrustMaterial(null, new TrustSelfSignedStrategy() {
@Override
*public boolean isTrusted(X509Certificate[] a, String b)
throws CertificateException {
log.debug(isTrusted() returns true);
return true;
}*
});
SSLContext sslContext = builder.build();
SSLConnectionSocketFactory sslsf = new
SSLConnectionSocketFactory(sslContext, new
TrustEverythingHostnameVerifier());
} catch (Exception e) {
log.error(e,e);
throw new IllegalStateException(Unable to configure
TrustingHttpClientConfigurer, e);
}
}
Then in an implementation of CameltestSupport I've overridden
createRegistry().
@Override
protected JndiRegistry createRegistry() throws Exception {
JndiRegistry jndi = super.createRegistry();
log.info(createRegistry());
*jndi.bind(MyConfigurer, new TrustingHttpClientConfigurer());*
Object o =
jndi.lookup(TrustingHttpClientConfigurer.HTTP_CLIENT_CONFIGURER);
log.debug(object type: + o.getClass().getCanonicalName());
return jndi;
}
Then in my createRouteBuilder() it contains...
return new RouteBuilder() {
public void configure() {
log.debug(CONFIGURE);
*
HttpComponent httpComponent = context.getComponent(https4,
HttpComponent.class);
httpComponent.setHttpClientConfigurer(new
TrustingHttpClientConfigurer());
log.info(CCC +
context.getRegistry().lookupByName(MyConfigurer));
from(direct:start).transform(simple(FRED)).to(https4://172.30.253.94:8444/services?httpClientConfigurer=#MyConfigurer;*
}
};
public void testSimple() throws Exception {
HttpComponent comp =
template.getCamelContext().getComponent(https4, HttpComponent.class);
*log.info(DDD +
comp.getHttpClientConfigurer().getClass().getCanonicalName());*
template.sendBody(direct:start, FRED);
}
When the test runs I do get
*DDD com.singlewire.monte.eh.config.TrustingHttpClientConfigurer* which is
what I would expect.
However test is failing with the obligatory
javax.net.ssl.SSLHandshakeException. This is what I would expect given that
the component isn't calling my version of isTrusted(X509Certificate[] a,
String b) created during TrustingHttpClientConfigurer.configureHttpClient().
I know this because I never see the debug message indicating that it was
called.
So it's as if during execution of my route the configurator is being
ignored.
I've tried ?httpClientConfigurer=#MyConfigurer
I've tried ?httpClientConfigurer=MyConfigurer
I've tried forcing things like this.
HttpComponent httpComponent = context.getComponent(https4,
HttpComponent.class);
httpComponent.setHttpClientConfigurer(new TrustingHttpClientConfigurer());
Nothing seems to work. Any guidance would be greatly appreciated.
--
View this message in context:
http://camel.465427.n5.nabble.com/https4-2-15-2-not-recognizing-my-httpClientConfigurer-endpoint-option-tp5767922.html
Sent from the Camel - Users mailing list archive at Nabble.com.
