I have a Apache Camel route that is exported as a runnable jar file from eclipse. I use a simple bat file to run this route...
C:\PROGRA~1\Java\jre6\bin\java -jar C:\dev\_exports\mdt\cpnnectors_v1.jar
How can I run this as a window service instead with the output from the console to a log file?
I think there are some general windows tools you can use to turn Java apps into services. And I vaugely recall something added to the JDK6 or 7 to support that natively. Anyway try to google a bit.
Tanuki has been around for a long time and they offer such a tool
http://wrapper.tanukisoftware.com/doc/english/download.jsp
I know it is a bit of a late answer but I have managed to deploy my Camel Routes to Apache Karaf and Karaf comes with a service wrapper for both for windows and a deamon wrapper for linux. Basically I know have my Camel routes deployed to Karaf and it is running as a service on windows with really minor hassle.
Karaf is easy to install and the help file also show you how to install the wrapper.
Related
Yes I know, there are numerous questions and answers since JAXB was removed from JDK 11. But this one is specific.
I've a Wildfly Server (tested with 18.0.1 and 16.0.0) running with the wildfly-camel subsystem 11.0.1 patch applied. The patch installs Camel 2.25.0
Deploying and Hot-Deploying (while the server is up) Camel routes works fine!
Until I deploy Liferay on the same server :-(
Then the Hot-Deploy of a camel route gives me the annoying
[java.lang.ClassNotFoundException: com.sun.xml.bind.v2.ContextFactory from [Module "org.apache.camel.spring" version 2.25.0...
exeption.
No matter if I run the server on JDK 11 or JDK 8! Liferay 7.3.2 claims to be runnable on both JDK versions so I guess it has something to with the way Liferay was build.
Reading this article
http://www.descher.at/descher-vu/2019/01/java-11-jaxb-and-osgi/
that the JAXB topic is very complex and far from being resolved.
Question:
How can a deployed application destroy otherwise working classpath resolutions?
And more important:
How to fix it?
I tried removing the 2 jars in question jaxb-api.jar and jaxb-impl.jar from Liferay. But that didn't help.
Turns out that the root cause of the error is a missing dependency to com.sun.xml.bind in the org.apache.camel.spring module of the wildfly-camel patch.
I filed the issue in detail.
Looks like Liferay has nothing to do with it. Because in theory jboss-modules should separate the deployments.
I have a application running Spring Boot Camel which consume message from a ActiveMQ and write to a file:
#Override
public void configure() throws Exception {
from("activemq:queue:MyQueue").to("file:/tmp/somemessages/");
}
Very simple and works fine if run mvn spring-boot:run.
But now i need generate a bundle jar to install in my RedHat Fuse OSGi container. Everything was installed and started without error, see:
So, my camel-app is Active but after produce some messages in my ActiveMQ Queue nothing works as i expect, so the file was not generated.
How can i see if something is wrong ? Application Console Log or something like this ?
This is not a good practice. Spring Boot is intended for running Standalone. In an OSGi based runtime such as Red Hat Fuse or Apache Karaf/ServiceMix you should deploy OSGi apps, which with Camel is camel-blueprint (you can also use Java routes with blueprint). So take a look at examples how to do that, and there should be examples shipped with Red Hat Fuse you can look at.
How can i see if something is wrong ? Application Console Log or something like this ?
The simple answer is you can run diagnostic command on your bundle by running following command inside your shell console:
bundle:diag {your-bundle-id}
You may replace {your-bundle-id} by preferred bundle id that is 231 in the picture. There is also a complete list of Apache Karaf commands that may be useful for further requirements.
I have a problem with custom branding in Karaf 4.0.6.
I've put branding.properties file into $KARAF_HOME/etc directory but the welcome message and prompt are still default.
Should I set up something more?
Finally I found the solution. In my case I run karaf as server and then connect via ssh. Since karaf 4.0.6 you have to use file branding-ssh.properties for clients.
Here I found the answer
Here a link to the latest docs: http://karaf.apache.org/manual/latest/#_branding
Here a duplication of what the docs say (in case the link goes away):
I created a etc/branding.properties on a fresh installation of Karaf 4.0.6 and my branding changes, when I start it with karaf.bat (on Windows).
When starting with client.bat you need to change etc/branding-ssh.properties.
I have created a java-archetype project for Camel. It is a simple REST hello world to receive a get request and return a string body. When I run this as Java application from Eclipse it works as intended.
When I take the jar and deploy it the Fuse "deploy" folder I can see in the logs that the bundle has started. The state is active and green. However the Camel tab does not appear.
The same works if I use blueprint but does not seem to do so using the java dsl. Is there an extra magic code you need to add for Fuse to pick up the camel context? Thanks
Yes for OSGi to startup you can use a spring or blueprint with a <camelContext> that starts Camel. If you use pure Java code you have to fight with OSGi and use an OSGI activator and setup all kind of OSGi stuff that gets you tiresome.
So add a blueprint xml file and add the <camelContext> and then you can refer to Java route builders, just as you can when doing spring xml: http://camel.apache.org/spring.html
I have a servicemix module, which is basicly a camel based route.
It works fine during development and also when deploying in older version of FUSE. However, when deploying in a later version of FUSE, I get
Caused by: java.lang.NoSuchMethodError:
com.company.integration.MyRouteBuilder.errorHandler(Lorg/apache/camel/builder/ErrorHandlerBuilder;)Lorg/apache/camel/builder/RouteBuilder;
I do not quite get why :-)
The old version used camel 2.6, the new uses Camel 2.9. Both have RouteBuilder.errorHandler as far as i can tell..
br
I wouldn't spend too much time trying to figure that out myself...I'd just start testing with the same version of Camel that I'm going to deploy it under...otherwise even if you get around this issue, others will likely pop up, etc.
If you do have a requirement to run multiple apps that depend on different versions of Camel, then OSGi supports this as long as install the necessary camel bundle versions and setup your applicaiton bundle manifests correctly, etc.
Reinstalling (or rather, recreating the instance) helped.