Issue 52855: Missing Servlet API when extracting remote pipeline resources

[labkey-jeckels]

Rationale

We have two places that extract JARs for remote pipeline scenarios. This one, used in our tests, and another used from the command line. They should be kept in sync.

Related Pull Requests

• Issue 52855: Missing Servlet API when extracting remote pipeline resources platform#6570

Changes

• Pointer to the other spot
• Stronger error checks
• Update to grab the new home for the servlet API classes

[labkey-adam]

I don't suppose we have a test that alerts us to issue like this...

[bbimber]

Hi @labkey-jeckels, I am looking at ways to add testing over this. If labkeyServer.jar exists, then it seems like it would be easy to have an integration that that either: 1) executes the extract command and verifies the results, or 2) maybe refactor this code to separate a method that inspects the JAR and returns a list of files to extract from the code that actually does the extraction. The former could be tested without actually extracting files.

However, unless someone actually runs the a gradle dist step, does labkeyServer.jar exist on a normal TeamCity and/or dev machine? It's possible I havent fully wrapped my head about all the uses here.

[labkey-tchad]

Just some error message changes

[labkey-jeckels]

Hi @labkey-jeckels, I am looking at ways to add testing over this. If labkeyServer.jar exists, then it seems like it would be easy to have an integration that that either: 1) executes the extract command and verifies the results, or 2) maybe refactor this code to separate a method that inspects the JAR and returns a list of files to extract from the code that actually does the extraction. The former could be tested without actually extracting files.

However, unless someone actually runs the a gradle dist step, does labkeyServer.jar exist on a normal TeamCity and/or dev machine? It's possible I havent fully wrapped my head about all the uses here.

It should exist on a TeamCity agent. On dev machines we have build/deploy/embedded/embedded-25.5-SNAPSHOT.jar which is a precursor to labkeyServer.jar which has a subset of files. The full JAR is bigger and slower to build than we want to do on a typical dev machine build.

I'm also pondering how to get better coverage on this, and whether it would give meaningful coverage or not. I mistakenly thought we had reasonable coverage from the PipelineServiceImpl variant here, but obviously it wasn't close enough. The other challenge is the class loader boundaries between the embedded/bootstrap code and the rest of the app.

[bbimber]

hi @labkey-jeckels: OK. What do you think about merging this PR to restore functionality, and then address testing / future-proofing of this in another PR? I have not had time to really dig into this myself, but would be willing to give it a try. I also did not really look in depth that the two different code paths that exist (PipelineServiceImpl and this), but obviously it would be nice if they were more formally synchronized.

My github-actions CI builds a distribution, and it would be relatively easy for this code to run '-extract' and inspect the results; however, i think it's better to put something into core labkey.