Is it possible to use all camel components using HotSpot - quarkus

I noticed that there are only a few camel extensions available to use in native mode. I am wondering if it's still possible to use the other camel components if you don't compile to native? And if, is it usefull to go that way, or should we for example stick to spring boot?

Note that all Camel extensions might not need a Quarkus one. Basically, a Quarkus extension is needed if we need to tune the Camel extension for GraalVM (add reflection declarations for instance). The interesting thing is that you can even do the work manually to make your Camel extension work in GraalVM mode and then report back so that we create a proper extension for all future use.
In JVM mode, all Camel extensions should work flawlessly. If you encounter an issue, please open a GitHub issue and we will take a look at it.
About if using Quarkus in JVM mode is worth it, I'm obviously partial but I think the Quarkus approach is beneficial even in JVM mode. You still have some of the benefits of better boot time and reduced memory usage. Obviously, depending on your application, they might not be important to you.


What is the difference between Quarkus and Thorntail?

Quarkus looks pretty cool.
Could you please provide more detailed diff between Quarkus and Thorntail?
This would help when considering between these two when building a new "java cloud native app".
What Quarkus has over Thorntail:
Capability to create native executables, which gives you massive improvements in startup time and memory footprint. This can be critical for cloud deployments.
Even with the usual executable JAR, Quarkus is still going to have significantly smaller memory footprint (thanks to the dead code elimination), and faster startup time (because lot's of initialization work that's normally done on run-time was moved to built-time).
Live coding (akka hot swapping code) - best I've seen so far.
Better integration testing capabilities.
Advantages of Thorntail over Quarkus:
Thorntail is mature, while Quarkus only just released the first Beta. This is only issue in very short term obviously.
Compatibility with other Java libraries is going to be less of a problem in Thorntail, in a sense that:
there's a higher chance that a library will work out-of-the-box in Thorntail, than there's a chance that it will work out-of-the-box in Quarkus,
if it's not working out-of-the-box, it's gonna be easier to make it work with Thorntail than to make it work with Quarkus.
It should be said however that Quarkus team made an amazing job of preparing an impressive list of extensions which covers probably everything one could wish for(?)
Conceptually Quarkus may choose to stay "lighter" in some cases. E.g. the CDI implementation in Quarkus is a subset of the CDI spec, in order to remain leaner and faster.
Quarkus is a putting-all-together framework (resteasy, hibernate, and more) (comparable with spring boot and dropwizard).
Thorntail (known previously as wildly-swarm) is :
Enable deconstructing the WildFly AS and pasting just enough of it
back together with your application to create a self-contained
executable jar.

What are disadvantages of using Lombok in my Spring Boot RestApi?

I am using Lombok in my Spring Boot Rest Api. I searched a lot but could not found what I want to know about Lombok. My rest api is an enterprise level application which would be extend with more modules in future.
Should I use lombok? What are the major disadvantages of Lombok using in enterprise application?
My IDE is STS.
There are no special advantages or disadvantages of using Lombok in an enterprise application. Lombok itself and all its annotations are removed during compilation, so there will be no additional libraries at runtime.
Furthermore, if at any point later you'd decide against Lombok, you could remove it again by running delombok, which will give you the code that Lombok generates. So there is no real risk there (besides that it will of course take some time to delombok everything).
For a general (of course opinion-based) discussion on Lombok's (dis)advantages, see this answer.
You have to know what Lombok realy do. For example Lombok add #java.beans.ConstructorProperties before constructors. It may be important if you use jackson serialization. See

ConfigurationProperties outside of spring-boot

Is it possible to make us of #ConfigurationProperties behaviour for a non-Spring Boot application? To explain a bit clearer, I've a library module that in future I would like to use in a non-spring boot environment so I wondered if ConfigurationProperties could be utilised without bringing in a large bunch of spring-boot core dependencies.
It looks like you need spring-boot-stater to pull in the configuration, so I guess no is the answer :D

Clojure hot code swapping for uberjars/.classes

I want to have hot code swapping between project updates, but I haven't found any information about how to load .class files dynamically.
More specifically, I want something like that:
Make lein uberjar, obtain some-client-0.0.0-standalone.jar.
Run it with java -jar some-client-0.0.0-standalone.jar.
Make changes to project. Obtain new program version, some-client-0.0.1-standalone.jar, copy it to some-client-0.0.0-standalone.jar directory.
Client receive sequence of commands needed to update to new version.
(optional) Updates resources. Resources from old jar are no longer used.
(optional) some-client-0.0.0-standalone.jar can be deleted now.
Plug-in framework approach
You've stated you want to have hot code swapping, but what you actually need is loosely coupled modules and ability to do resolve in run-time. Frankly speaking any plug-in framework may help, including mature OSGi (will be covered below).
Since you are doing some kind of PoC I suggest to review the following example:
you have a meta application with some extension points (metaphor explanation) defined
functionality to be upgraded or replaced will be implemented as a loosely coupled modules (plug-ins)
meta application performs resolve by request or automatically in order to find updated "functionality" (according to defined extension points)
Having that define simlle upgrade scenario can be proposed:
user uses an application
user installs (copies) a JAR (other type of bundle) with new implementation of one or several extension points
user triggers global system resolve or system scans for new updates or system performs resolve every tine user tries to access some piece of functionality
In such a way meta application will be able to provide a new or updated functionality without restart. So you can:
try use some simple java plug-in framework (like, for example, Java Simple Plugin Framework. 5 minutes and it works. No XML. This approach seems to be a little bit ugly
use dynamic nature of clojure, as was suggested here
You can also review and adopt Waterfront (Clojure based editor for Clojure) findings (it might be needed to enhance lifecycle management, etc)
check the Modular composition/plugin architecture thread
look through the code waterfront on SourceForge
In terms of implementation, Waterfront is based on the context
pattern. It allows event handlers to communicate in a functional
(side-effect free) manner. On top of this there is a plugin-loader
mechanism which loads the plugins that are specified in Waterfront's
configuration file. This means that functionality can be easily added
or removed (extremely useful when debugging!).
OSGI approach
As was suggested OSGi seems to be a good way to solve your problem. Please also note OSGi is good, mature and provides a lot stuff out of the box, but it is also somewhat complex:
BTW, OSGi is a long-term goal for the clojure community. You can check Clojure Todo:
> better modularization for OSGi etc
> * names
> * no single namespace pool
> * namespaces found via classes, thus tracks classloader and modules
> * deal with import proxying a la Class.forName stack walk?
There are some solutions already available:
Second project provides Producer-Consumer example using clojure and OSGi:
producer service
consumer service
Happy coding.
For reloading at runtime strictly from jar files you may need to look into OSGi class loaders.
For Clojure code you could start nrepl in your client that listens on a local port and then when you want to reload the code you connect to that port and make a call to load-file

Migration patch from NServiceBus 2.6 to NServiceBus 3.0

I have an existing NServiceBus 2.6 application that I want to start moving to 3.0. I'm looking for the minimum change upgrade in the first instance. Is this as simple as replace the 2.6 DLLs with the 3.0 Nuget packages or are there other considerations?
For the most part the application migration is quite straight forward, but depending on your configuration and environment, you may need to make the following changes:
The new convention over configuration for endpoints may mean you will need to rename your endpoints to match your queue names (#andreasohlund has a good post about this).
persistence of saga, timeouts, subscriptions etc. now defaults to RavenDb, so if you use SQL Server to persist data, you need to make sure you have to correct profile and endpoint configuration. For SQL Server storage, make sure you add a reference to NServiceBus.NHibernate as it is no longer part of the core.
Error queues are now referenced differently using different configuration ie. use MessageForwardingInCaseOfFaultConfig instead of the regular MsmqTransportConfig error property. You should still be able to use it, but it will look for the MessageForwardingInCaseOfFaultConfig first.
Other than that, I don't think you need to do anything else to get you upgrade working. I modified some of my message definitions to take advantage of the new ICommand and IEvent interfaces as a way communicatinf intent more clearly.
Anyway, I'm sure there will be some cases that are specific to your environment that will require different changes but I hope this helps a bit.