I'm trying to do some "hello world" example with Apache Camel. Just a simple route, deployed as OSGi bundle to Apache Karaf. And it's crazy, too many things to learn at once, Camel itself, integration with spring, integration with OSGi and Karaf...ugh.
I'm trying to follow the idea from here: http://www.andrejkoelewijn.com/wp/2008/10/19/simple-camel-dsl-osgi-bundle-example/.
I've created the bundle, the package with FileRoute.java file, etc, but I can't produce valid manifest.mf file, it's generated by "bundle plugin for maven" - so the POM file is used to generate the manifest file.
What's the problem is this in the manifest file, line with import packages:
Import-Package: com.company.foo.bar.demo;version="0.1",org.apache.ca
mel.builder;version="2.10",org.apache.camel.model;version="2.10",org.
apache.commons.logging
With error: "No available bundle exports package 'org.apache.camel.builder'" (and .model package).
Well, I understand what is the problem, but…How to expose these packages for the bundle?
Next I have there another bundle with Apache Camel context, so I thought that good idea is to expose the packages from there, through "export package", but it doesn't work, the camel bundle can't be build then.
I'm quite lost :( I'd really appreciate help or hint.
Thanks!
If you use Apache Camel 2.10 or better then the Maven archetypes is a good place to start a new Camel project. We have archetypes that can create OSGi based project for either spring-dm or OSGi blueprint. You chose which one you want to use. The project is then ready for OSGi as it setup a maven plugin that generated the needed osgi stuff for you. Only in more advanced cases you would need to tweak this plugin.
See details at: http://camel.apache.org/camel-maven-archetypes.html
If you use Maven 3.0.x then its much easier as you can just type
mvn archetype:generate
Then it runs in interactive mode, then type camel to filter only camel archetypes.
And then select the number for the archetype. eg for example the spring-dm to use OSGi with Spring.
Related
I'm using a Gradle based-setup to build a REST web service (with Jax-Rs and glassfish.jersey dependencies). I'm using the Gradle-tomcat plugin (bmuschko-gradle-tomcat-plugin) to deploy it on tomcat during runtime. I'm pretty new to this, and I've read that tomcat doesn't support Jax-Rs features on its own. So how do I make my REST code work on tomcat? Should I bundle Jax-rs/jersey jars along with my war? I won't be able to copy-paste those jars anywhere (few tutorials have the jars pasted under web-inf/libs module), I want it to be automated during the build with Gradle.
PS: I'm using #ApplicationPath (mandated by my company) in my code, which overrides servlet-mapping in the web.xml, so I won't be able to modify that.
Can someone give me an understanding of what the Spring Boot Maven plugin actually does? I have been Googling, but most of what I find doesn't give a clear picture.
The impression I have so far is that it can create a "fully executable" jar that does not need to be run via java -jar, and that it's also possible to make a more traditional jar that you would run via java -jar. I'm sure there are other variations of what it can produce as well.
I'm also under the impression that it can package up dependencies and resources. It's not at all clear to me how the resources are "accessed" by the application when it's run.
In either of the outcomes described above do I need just the jar and nothing else (i.e. no resource files, dependency jars, etc.)? In other words, is the jar self-contained? When I've opened the jar up, it does seem that everything it needs is there. Is that really the case?
Now, let's go a little further towards what I'm trying to do. I am writing a set of Spring services with REST APIs. Each service will be run in its own VM (or container - future). The services are packaged into a single jar and the service to be used is selected via Spring profile (i.e. spring.profiles.active=a-profile).
The way I've done things like this before has been to use the Maven assembly plugin to produce an archive (zip) for each separate service and inlcude all of the necessities (dependency jars, resource files, etc.). I'd place it where needed, unpack it, tweak some configuration and run it via an included script.
I'm getting the impression that's not "how it's done" when the Spring Boot Maven plugin is involved.
The Spring Boot Maven Plugin provides Spring Boot support in Maven, letting you package executable jar or war archives and run an application “in-place”.
It builds the uber jar which bundles in Tomcat along with your app. If you inspect the contents of the jar with jar -tf <file_name> you will see that the format is a bit different. The Spring Boot classes look normal, but then your project's files are inside a BOOT-INF folder.
I am working on a Spring-MVC application which uses Maven. In the POM.xml I noticed that I can denote the file-type in which I can select if I want to deploy the project as a JAR or WAR.
Mostly I select a WAR file and then deploy it in Apache tomcat. My question is, If the application is Spring-MVC based, with Spring-Security, Hibernate and other libraries, can I package it as JAR by simply denoting it in POM.xml and deploy it in Apache webserver instead of using Apache tomcat? Or do I need to make some modifications somewhere for this to work. Kindly let me know. Thank you.
No, you can't. Apache httpd knows nothing about how to handle jar files.
What you can do though is to provided an embedded webserver (such as jetty) in your package and define in your MANIFEST.MF file a main class that will launch it and register your application to it.
That way you can package is a an auto-executable jar, or as a war that can be run on his own or deployed in a classical webserver.
I seem to be really struggling here. What I want to do (in this order) is:
1) Build a RESTful resource using a Jersey application and resource w/annotations (this is not the issue).
2) Package, install, and start that bundle into the Felix OSGi container, as an HTTP service, including dependencies.
3) Package, install, and start a WAR in the OSGi container that may incorporate #2 as a dependency.
And I would like to be able to do all of this using Maven.
I cannot seem to find a working example of even the individual steps, especially involving Maven, that work let alone the combination of those steps. I have tried cobbling together various q&a from across the web with varying levels of success but not an end-to-end working example yet.
Any pointers would be appreciated...
I do not have an example for Jersey but I have a tutorial for CXF with Apache Karaf (which uses Felix). It shows how to create a Rest service and build it with maven. Using Apache Karaf you can then deploy the bundle directly from the maven repo. Moving this to Jersey probably just means to exchange the lib and use another blueprint config to initialize the rest service.
Apache Karaf also allows to deploy wars and wabs but I have not yet tested them.
Apache Stanbol does most or all of this (not sure if the war packaging is included out of the box) to implement its RESTful services.
You'll have to dig through its codebase but searching for Jax-RS annotations in there should point you to the right places.
I also am really struggling with exactly what you are attempting to do. So far, I seem to be really close but alas not quite there, here's what I've been doing:
creating a War with Maven that defines my Jersey Resource's
bundling it with maven bundle plugin ( see section Adding OSGi metadata to existing projects without changing the packaging type ). Which allows me to run the restlets in Tomcat and test.
define a target in Eclipse that includes resources from my locally defined p2 site which I create with the p2-maven-plugin plugin. In this way I can gather up any of the dependencies from the WAR project into a p2 site, which I can deploy to an Eclipse defined target
Where I am stuck is trying to register the Jersey Resource's as services, for which I've tried:
using the JAX-RS OSGI connector, for which I eventually gave up on because it uses glassfish jersey which seems to export a version 2 API of Jersey when Jersey hasn't even defined a version 2 API yet. This caused package resolution problems when I wanted to use version 1.17 of Jersey libs.
registering the Resources using a Whiteboard a la Apache Felix HTTP Service, my current approach which doesn't seem to work yet.
And, finally, if the preceding doesn't work I'll try Amdatu
Another route I might try is from the Jersey project OSGI chapter
I tried this combination and made it up and running -
1- Modularity Specification-->OSGi specification
2- OSGi implementation-->Apache Felix 4.4.0
3- OSGi Runtime-->Apache Karaf 3.0.3
4- Software Architecture Specification of REST – JAX-RS
5- JAX-RX implementation-->Apache CXF – 2.7.5
You can refer this nice tutorial - http://java.dzone.com/articles/building-cxf-rest-service-osgi
Now, I am also planning to move to Jersey from CXF as the Jersey is the light wait reference implementation of JAX-RS. Now I am planning to use Jersey with Apache Felix/Apache Karaf. You can install Jersey in Karaf and deploy your Jersey Rest Web Services as Bundle. You can refer this tutorial - https://vzurczak.wordpress.com/2014/09/30/web-applications-with-osgi-working-with-jersey/
Here's a good example on github : https://github.com/ddragosd/jax-rs-on-karaf
Is it possible to have standard war deployment, which can be deployed on tomcat and also can be build as OSGi bundle and deployed with other bundles in OSGi container tomcat(i think virgo)?
Yes, there's a good deal of interoperability between WARs and WABs. Apache Aries and WebSphere Application Server will convert WARs to WABs on deployment. This is a good way to get up and running, but it's a better practice to use proper WABs in which you build in the OSGi metadata yourself. The extra OSGi headers won't interfere with the deployment in a normal Tomcat container, so the WAB has the greatest flexibility.
For your build, you have a number of options. For example, the maven bundle plugin can be configured to build WABs, or you can use Eclipse PDE's tooling support for OSGi metadata.
Pax-Url-War provides this functionality to containers like Apache Karaf. In brief, this allows you to import an URL like war:file:///path/to/myapp.war and Pax will wrap it as an OSGi bundle, optionally changing the URL root and other parameters on the fly.