Java SE support - Githubissues

kumuluz / kumuluzee

Lightweight open-source framework for developing microservices using standard Java EE technologies and migrating Java EE to cloud-native architecture.

https://ee.kumuluz.com

MIT License

291 stars 71 forks source link

Java SE support #150

Open ikonkere opened 5 years ago

ikonkere commented 5 years ago

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

MBJuric commented 5 years ago

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

ikonkere commented 5 years ago

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

ikonkere commented 5 years ago

Any progress on this?

cen1 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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.