pixielark wrote

it will be much nicer if tplink can pack the jre as what's indicated in the release note so my container can be easier to build

I disagree.

Bundling binaries which come from other packages makes the controller package architecture-dependend and also version-dependend.

Exactly this was the reason I re-packed Omada controller as an architecture-independend community version, which uses the java / mongod binaries from the system's standard repository. Omada controller is not the only application which needs to use mongod and there is no reason to have two mongod binaries on the same system, especially as Omada controller also makes use of other binaries such as ps, netstat and curl, which never had been bundled with the controller.

By avoiding binaries Omada SDN controller now becomes portable and architecture-independend. Additionally, it allows to use latest versions of mongod and the JRE, which are both not maintained by TP-Link.

What should be the reason to use Java language for portability if the package is architecture-dependend b/c the java binary itself is included in the package? This is contradictory and highly inconsistent.

Installing Oracle's JRE is a matter of either installing the Oracle Java package from the repository or downloading a TAR archive from the Oracle website and extracting it (the latter needed only if the Linux distribution decided to not support Oracle's Java as a package for whatever reason – if this is the case with your distribution, please complain to the maintainers of this distribution for doing so).

Installing mongodb is also a matter of just downloading the package from the repository.

I'm glad that TP-Link finally removed the binaries from the Omada controller package. This greatly simplifies installing the controller on other architectures.

pixielark wrote

Unfortunately, the Omada package is very verion-dependend, so I would disagree them to remove the build in JRE binary unless they make their controller compatiable with latest LTS JDK, i.e. JDK 11 currently.

Yes, it's indeed version-dependend and architecture-dependend and that's bad. After all, Java should be portable, shouldn't it?

Anyway, I couldn't get it working with any other version than JRE8, which still is being patched when security issues turn up.

I am lucky enough that I am only messing with the controller in my docker container, imagine deploy this to an actual instance, now just because of the controller I need to push a mostly deperated JDK 8 into my system just to run this thing.

So you should be able to set things up for your isolated docker container. I have to provide actual instances on different platforms and that is why I can't use architecture-dependend packages.

also their mongod binary is clearly miss packaged, the controller is not using the system mongod service at all, instead is still trying to look for the mongod binary in /bin, so I have to install mongod server and create a softlink to the /bin in order for the controller software to start.

Right, TP-Link likes to do it the Windows way even on Linux and bundle everything into the package.

Except jsvc, curl and netstat – surprise, surprise!