Use of serialization feature of Quakus (includes Sql and Nitrite)

[JiriOndrusek]

fixes #2755
fixes #2255

In his change I propose registration for serialization of several basic classes. But because this is not required by the most of the extensions, I suppose that creating a buildItem and based registration on it, would be better. @ppalaga @jamesnetherton WDYT?
Another problem is BigInteger, which doesn't work - I have to find why.

[jamesnetherton]

I suppose that creating a buildItem and based registration on it

Yeah, that's how I would have implemented it. Otherwise every extension that wants serialization support has to duplicate the required steps.

I guess the registration of the basic Java types ideally belongs in Quarkus itself.

[JiriOndrusek]

I agree that basic stuff would be in quarkus - in the future. (I plan to create a PR there)
But some stuff like org.apache.camel.support.DefaultExchangeHolder would stay here.

Thanks for your response!

[lburgazzoli]

oh this is really nice.

btw we should really add a task to revisit DefaultExchangeHolder as it has been designed when serialization was cool but now it should be better to use json/avro/protobof

[zbendhiba]

btw we should really add a task to revisit DefaultExchangeHolder as it has been designed when serialization was cool but now it should be better to use json/avro/protobof

+1

[jamesnetherton]

@JiriOndrusek please rebase on main as Quarkus has been bumped to 2.1.0.CR1.

[JiriOndrusek]

I'll rebase
and here is an issue about DefaultExchangeHolder - https://issues.apache.org/jira/browse/CAMEL-16805

[ppalaga]

Nice work, thanks @JiriOndrusek! Some comments and questions inline.

[jamesnetherton]

Is there any work remaining on this one? It'd be good to get it merged ASAP as there's a few other things that depend on it.

[JiriOndrusek]

Please leave me about an hour to add changes pointed by @ppalaga

[JiriOndrusek]

@jamesnetherton All items are fixed. There is no more remaining work on this PR.