Java SE support

[ikonkere]

• SE server implementation with Weld SE CDI support;
• updated BOM.

[MBJuric]

Thank you. We will have a look and let you know soon.

[ikonkere]

Created a PR with a sample: https://github.com/kumuluz/kumuluzee-samples/pull/25

[ikonkere]

Any progress on this?

[cen1]

@ikonkere can you rebase to current?

I was testing this a bit and it makes sense as a weld-se wrapper. Unfortunately the extension ecosystem support is very rough. I managed to load the config extension, that was about it.

• mp-config worked
• log4j2 wanted a Servlet present
• mp-rest-client wanted a JAX-RS implementation, unfortunately that one wants a Servlet.
• I haven't tested kumuluzee-streaming but that would be a good candidate

It looks like we have some more work to do for enablement in extensions which are not web specific when this is merged.

[ikonkere]

Well, obviously there's no servlet support under SE, so it doesn't make sense trying to start anything that depends on javax.servlet. If some extensions require it for some reason, then i suppose they must be run with kumuluzee-servlet family and not this one.

I'm surprised mp-rest-client didn't work because it does work for me with RESTEasy, but afair there was some tweaking involved. mp-reactive-messaging must also work, as i've specifically tested on it.

I will definitely have a look as soon as i'm out of isolation: unfortunately i have no useful working environment or remote access available right now.

[cen1]

I think the rest-client failure is mainly due to no distinction between jax-rs client and server side dependencies in our packaged components. log4j2 I am not sure why, I think just an overreaching check in the extension code. I do not think it is necessary to have extensions ready before the merge, but it is something to keep in mind. Without this compatibility, the SE server has limited usage with not much else benefit compared to just using stock weld-se.