scripts, maven pom.xml and class to help to load libraries from a jar #3
Conversation
|
The Java class would need to be added to trunk (and 8.5.x and 7.0.x?) |
|
On 05/09/18 18:19, Mark Thomas wrote:
The Java class would need to be added to trunk (and 8.5.x and 7.0.x?)
The other files look like they belong in native/build/jar or a similar
location rather than the root of the repo.
Well apart pom.xml and copylibs_deps.sh nothing gets in the root repo.
What is the plan for ensuring these binaries are available on each of
those platforms?
First it allows packagers like rhel or ubuntu to use they own libraries.
How many committers have access to all four? (I have 3
and I could add a Solaris VM fairly easily.)
Same here I also have access to SPARC64 box too.
This is mostly for the cloud, that will allow to build an uberjar and
have tc-native, apr and openssl in it (openssl is often already in the
images but it is tricky for tomcat to find it)
Cheers
Jean-Frederic
|
|
The Java class would need to be added to trunk (and 8.5.x and 7.0.x?) the JarLoader needs to be in the same jar where the libraries are. Otherwise the logic can't find them and we don't want to list all the possible library name as the ldd or otool can give them at the build time. |
|
That might be problematic from a JPMS point of view that expects a package to appear in one and only one JAR. |
|
To check I understand this correctly, the plan is not for the Tomcat project to provide a single JAR for all platforms but to provide the hooks necessary for downstream packagers to package the native library (and dependencies) for their platform if they wish? |
|
On 05/09/18 19:38, Mark Thomas wrote:
To check I understand this correctly, the plan is not for the Tomcat
project to provide a single JAR for all platforms but to provide the
hooks necessary for downstream packagers to package the native library
(and dependencies) for their platform if they wish?
We can do windows and macosx and probably linux.
But I am sure the downstream packagers will use it to package the native
libraries they have.
…--
Cheers
Jean-Frederic
|
|
well for windows we already have one binary, we can put it in the jar ;-) |
|
Re-opening after auto-close due to repo changes made during migration from svn to git. |
Unable to complete build when build directory is outside of the source tree. Patch provided by Bob Huemmer.
Fix client certificate authentication when a certificate contains an AIA extension without an OCSP URI. Patch provided by Milind Takawale.
Correct reference to the X509_STORE being configured Remove calls to X509_STORE_free since a separate store is not allocated for CRLs. It simply re-uses the existing store for the server SSLContext. Trying to close it triggers a JVM crash.
If the environment variable SSLKEYLOGFILE is set then the TLS keys will be logged to that file. Patch provided by John Kelly.
I don't think CVE-2019-1559 applies to Tomcat Native but err on the side of caution.
Don't apply tricks and rely on OS behavior to resolve addresses. It is the caller's responsibility to properly process socket addresses if more than one exists. This mimics the behavior of HTTPd's listen.c for apr_sockaddr_info_get().
This reverts commit 420cd1c.
…d=55707 note it affects only the Apr connector it seems.
That requires a small add in tomcat-trunk load the class and call the method and loops loading the libraries list the method has returned.
If no one complains I will commit both later this week.