paketo-buildpacks / apache-tomee Goto Github PK

Expected Behavior

Actions should run without failures.

Current Behavior

A few of the update actions are failing. See here and here and here.

They do not seem to be consistently failing, but it's happening frequently enough that we need to investigate and see what is happening.

When you run (e.g. on kubernetes) an image built with this buildback with a readonly filesystem (e.g. readOnlyRootFilesystem: true), the application crashes on startup with

cannot create unique file, please set java.io.tmpdir to a writable folder or create work folder

Even when you provide a writeable mount (e.g. /tmp) and point to it with JAVA_TOOL_OPTIONS=-Djava.io.tmpdir=/tmp this is overwritten and the application crashes.

This happens specifically for the tiny stack when the command is created to start tomee.

Expected Behavior

tomee uses the temp directory that user provides.

Current Behavior

When on a tiny stack (code), a start command is calculated instead of calling catalina.sh. This start script sets -Djava.io.tmpdir to $(CATALINA_HOME)/temp (code). This potentially overwrites the temp dir the user provided via JAVA_TOOL_OPTIONS.

It getting clear looking at the log

Picked up JAVA_TOOL_OPTIONS: -Djava.io.tmpdir=/tmp -Djava.security.properties=/layers/paketo-buildpacks_sap-machine/java-security-properties/java-security.properties -XX:+ExitOnOutOfMemoryError -XX:ActiveProcessorCount=8 -XX:MaxDirectMemorySize=10M -Xmx425549K -XX:MaxMetaspaceSize=62450K -XX:ReservedCodeCacheSize=240M -Xss1M -XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=summary -XX:+PrintNMTStatistics
11-Nov-2022 10:02:23.450 INFO [main] jdk.internal.reflect.NativeMethodAccessorImpl.invoke Command line argument: -Djava.io.tmpdir=/tmp
11-Nov-2022 10:02:23.455 INFO [main] jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke Command line argument: -Djava.io.tmpdir=/layers/paketo-buildpacks_apache-tomee/catalina-base/temp
	Caused by: org.apache.openejb.OpenEJBRuntimeException: cannot create unique file, please set java.io.tmpdir to a writable folder or create work folder

Possible Solution

• Checking for user input and only set this option if not specified yet
• Not setting java.io.tmpdir and relying on the default (/tmp)
• Taking additional user input (e.g. TMPDIR) into account

Steps to Reproduce

1. Build the example application from the integration tests with the tiny stack

pack build --builder paketobuildpacks/builder:tiny -e BP_JAVA_APP_SERVER=tomee -e BP_MAVEN_BUILT_ARTIFACT="test-jaxrs-tomee/target/*.war" -e test-jaxrs-tomee tomee-example

2. Run the container with a readonly file system

docker run --read-only -p 8080:8080 tomee-example

It crashes.

3. Provide a writeable temp dir

docker run -v /tmp:/tmp -e JAVA_TOOL_OPTIONS="-Djava.io.tmpdir=/tmp" -p 8080:8080 tomee-example

Note: You can omit the --read-only to not have it crashing. You can verify in the log that -Djava.io.tmpdir is set twice, so the later would win.

Motivations

Using the feature to use a readonly filesystem in kubernetes or docker should work as long as you provide a writeable temp directory. With that, the user has the control where files are written.

Expected Behavior

Integration test is failing, see here.

Current Behavior

It is failing because of the glibc issue. See this thread in Slack for background: https://paketobuildpacks.slack.com/archives/C011S6EL49L/p1680796577398119

Possible Solution

The integration test is building the buildpack from source, which requires CGO_ENABLED=0 to be set. We do this in the pipelines when we build and package the buildpack, but integration tests need to do this as well.

See how it's done in the pipeline here:
https://github.com/paketo-buildpacks/apache-tomee/blob/main/.github/workflows/pb-create-package.yml#L130-L136

I believe integration tests would just need to set that env variable during the test setup.

Steps to Reproduce

Run integration tests.

What happened?

The detect.go logic is this: https://github.com/paketo-buildpacks/apache-tomee/blob/main/tomee/detect.go#L49-L53

1. It fetches the app server or returns "" if one is not set.
2. It checks if the app server fetched is not equal to Tomee.
   3a. If not equal, the buildpack fails
   3b. If equal, the buildpack passes

This will work for most cases but fails if the Tomee buildpack is first in the builder/composite group and no app server has been set.

In this case:

1. App server is ""
2. The check fails, because "" != 'tomee'
3. The buildpack does not pass

It should pass though because in the case where it's listed first in the order group, it should run and contribute Tomee.

The workaround would be to request 'tomee' and then it'll get installed.

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

Expected Behavior

1. Integration tests should consistently pass
2. We should not have integration tests. It's difficult to mock out other buildpacks and external factors for a reliable integration test. If we can't make it reliable, then we should just remove it.

Current Behavior

See https://github.com/paketo-buildpacks/apache-tomee/actions/runs/7378265147/job/20073179955#step:9:99 as an example.

Possible Solution

• Make test reliable

OR

• Remove test

Steps to Reproduce

Pick one of the integration tests & re-run it. It seems to fail around 50% of the time.

Motivations

It causes hassles when evaluating PRs and wastes time. No one needs that.

Expected Behavior

Build without warnings.

Current Behavior

When building and syft runs, recent versions output a warning:

 Command "packages" is deprecated, use `syft scan` instead

Possible Solution

Make the suggested change.

Steps to Reproduce

Run a build from source. You'll see this logged multiple times. One of the times is from this buildpack.

Expected Behavior

Go modules should update automatically on a weekly basis through CI.

Current Behavior

Presently, the (Update Go Modules job is consistently failing)[https://github.com/paketo-buildpacks/apache-tomee/actions/runs/3672158285].

Possible Solution

I have tried to unwind the issue here with the Go module dependencies but there is an issue with a test dependency that I cannot work out.

> go get -u all
go: all: module github.com/docker/docker@upgrade found (v20.10.21+incompatible), but does not contain package github.com/docker/docker/builder/remotecontext/urlutil

I also tried go clean -modcache which is often suggested online as a fix for issues like this and it didn't help.

Steps to Reproduce

Repeat the steps from the failing action locally, which basically amounts to running go get -u all in the project directory.

Motivations

Until this is resolved, transitive go modules are not being updated. Dependabot will update direct dependencies, but it does not keep transitive dependencies up-to-date.

Expected Behavior

Tomee should log to the console. With Tomcat, there is a special handler that is added to accomplish this. It appears like Tomee has it's own handler that does this, so we don't need to add an additional handler.

Current Behavior

The Tomcat special handler is added by the Tomee buildpack. It does not appear to be necessary.

Possible Solution

If it's truly not needed, remove it. It's one less thing for the buildpack to install.

I think we should also review if the lifecycle helper and the access logging helper are required with Tomee.

The access logging helper simply writes access logs to System.out, so if there is a way to write access log entires to the Console in Tomee, then we don't need that either.

The lifecycle helper looks to see if there is an application failure while the server is starting. If there is one, then it fails the whole server. That way the container is not started in an inconsistent state. Again, if Tomee can do this out-of-the-box, then the helper can be removed too.

Motivations

Installing less is more.