We currently have a JBI app running on Red Hat Fuse ESB 3.x and intend to transition to a supported version of Fuse ESB 7.4
I am looking for some type of document or guidance on converting our JBI app... as I understand JBI packaging has been deprecated in favor of OSGI ...I am just looking for some documents that may shed some light on the process required to transition the JBI app to OSGI... I am wondering if this is a matter of using straight up Camel for what we need or if there are deeper considerations.
Yes, the best practice is to refactor to Apache Camel for integration and Apache Karaf replaces the ServiceMix runtime.
Tons of sample code here: Apache Karaf Examples
Specifically, a Camel Example
Related
I'm a little bit con-fuse-d with Red Hats Fuse tooling.
Here's what I'd like to do: Design Camel Routes with Eclipse (2020-03) and then deploy them to a Wildfly server (16 or 18) with the wildfly-camel patch applied.
This generally works, BUT:
The version of Fuse in the tool is 7.6 (latest) with a highest available camel version of 2.21(!) which is very old. The wildfly-camel patch already supports camel 3.0. on wildfly 18. Question: Is it possible to "update" Fuse Tooling within Codeready to newer versions of camel?
Fuse itself supports lots of camel components / connectors as can be seen here. But not all of them are available in Codeready. Plus that some of the components state to be compatible for example with camel versions greater than 2.8. Question: How to add these components to the visual design UI of Fuse Tooling?
I fear that it all is a matter of the outdated version of camel, but I want to be sure that I didn't miss anything. To those who know: Are there any plans of updating the Tool for Eclipse?
Fuse Tools for Eclipse is primarily designed to work with Red Hat Fuse which, as you rightly point out, aligns to specific supported versions of Apache Camel.
But, you should be able to create your own Wildfly-Camel project (or use one of the examples) and still use the graphical route editor to add newer components. You'll need to drag a Generic component from the palette and then untick Show only palette components, which should show you all the components available, including ones from newer releases of Camel:
Just tested this with:
Fresh install of Eclipse 2020.03 with Fuse Tools installed
Latest clone of Wildfly-Camel-Examples repo
Opening camel-jms-spring project in Eclipse
Opening src/main/webapp/WEB-INF/camel-context.xml with the graphical route editor
Dragging a new Generic component, XSLT-Saxon, from the Palette.
I would like to know the steps to integrate OSGi with WildFly-8.2.0.Final.
I have followed https://docs.jboss.org/author/display/JBOSGI/Getting+Started?_sscc=t but it is for older version and thrown exceptions on startup.
Please share if you ave any idea.
Thanks!
OSGi is no longer part of WildFly distribution.
However, community member Arcadiy Ivanov picked up the projected and released compatible version for WildFly 8.2
see http://ivanov.biz/2015/jbosgi-for-wildfly-8-2-released/ for more
I am currently developing an application which has a server part based on JavaEE 6.0 on JBoss 7.1 and a client based on Eclipse RCP 3.7.
For a simple OSGi package for a shared API I already run into trouble due to some differences in versions and depdencenies. The API requires "org.osgi.framework." for the bundle activator and "org.slf4j." for the slf4j logging API.
Currently my client is working very well, but JBoss tells me that the expected version of the OSGi import and the also the imports for slf4j do not fit...
I there a best practice to share OSGi bundles between Eclipse and JBoss? Do I need to get back to simple import and export declarations or can I used Require-Bundle somehow? Do I need to create some compatibility bundles for JBoss to get it running? What is the best way to proceed here?
UPDATE
I solved the issue by using Import-Package exclusively. For the dependency like org.osgi.framework is use version="0.0" to explain it does not matter. :-( It is not very safe, but currently I do not see another option. Is there a better way?
UPDATE 2
One also needs to pay attention to implement the correct verion of the OSGi Framework. JBoss 7.1.x only has OSGi 4.2 implemented, which has no support for typesafe service retrieval.
The best practice would be to use an import package statement with a range from the minimum version which you're using to the next major increment.
For example, if RCP expects version 1.5 of a package and JBoss expects 1.3.6, import version="[1.3.6,2)".
The Semantic Versioning whitepaper (pdf) explains why this style of import is safe and wise.
is there a reference or book, maybe a tutorial that can get me started with ejb using the technologies that I have mentioned above?
thank you
You can take a look at the JBoss Tools if you're interested in developing Java EE applications in Eclipse.
If you already know EJB (and if you don't there is quite good Enterprise JavaBeans 3.1 book) you know you can develop your EJB's as plain POJO's just with annotations. No need for fancy plugins here.
You would, however, need a plugin to easily deploy your application to the server. In this case, take a look at these JBoss Tools and this topic.
I am working on AVOS to camunda migration project and getting issues while using existing XQuery files in JBoss AS 7. Which engine/version of XQuery, JBoss AS 7 supports?
As far as I know, JBoss EAP does not provide any XQuery processor. It however embeds Xalan which provides an XSLT processor.
RedHat would probably propose you to use their JBoss Fuse product to implement XQuery transformations. I've never used the product so I won't be able to give you any feedback on it.
Of course a viable alternative is adding an XQuery processor like Saxon to your application or platform yourself. If you want to deploy it to the platform instead of to each application, see the module mechanism.