i ported based on Java 17

[realbrotha]

Hi maintainer. Are you there ?
winrm4j used java 11( older than) so i ported based on Java 17. I needed to use it in spring boot 3.x
Can I send you a merge request?

[knalli]

@realbrotha I've done this already as mentioned here. Confirming, that one is really working against several destinations.

However, it seems that this project won't get any updates anymore.

Meanwhile, I also did the update to CXF v4.1 so far, however, it looks like our GH remote branch is not in sync. Coming up in next days.

[valfirst]

@knalli does it make sense to proceed with your fork and start releasing new artifacts from it?

[knalli]

Do you want fork the project? We still don't have this done. I have to check what our current pushed state is, give me time to next week checking this.

We have a working impl for PSRP, but without any test coverage yet.

[knalli]

@valfirst At the moment, we are using our own "internal fork" (i.e. building and packaging internally). It is based on the already available branch jdk17_jakarta on our site: https://github.com/hlsolutions/winrm4j/tree/feature/jdk17_jakarta (97118e0).

At this stage, it adds enumerateAndPoll and runWql via 0465c55, keep-alive via cca0771, allow overriding code page via e526fe5 and improve its supportive usage. In some situations, also some resource-leaking issues were improved (mostly in case of starving connections), see also #166. Lastly, this migrates to Jakarta EE, CXF v4 and updates some of the maven plugins to a more recent version.

Based on that, we added an updated branch jdk17_jakarta_psrp at site https://github.com/hlsolutions/winrm4j/commits/feature/jdk17_jakarta_psrp (9cc9be9) which adds support for PSRP (910143f... aaa39f7). The last commits also updates to CXF v4.1, however this breaks at the moment because of some memory issues inside from CXF v4.1. This branch is pushed to GitHub right now.

As I said already, we do not fork this officially at this moment, although having made significant changes (i.e. as of PSRP support). We do use the features, but still do not have solid test cases for the new features (we test this manually or post-build IT). If you are willing to create the fork, we likely will contribute changes in the future if something comes to be relevant enough.

We use this solution right now because it's working. However, things like unknown support of Kerberos against more modern Windows Servers, the "CXF" kernel, and the lack of more integration tests made this a little bit „bloaty". Said this, we did not find a better solution which is capable of being in a daemon, handling multiple connections and is running in Java natively.