Develop Reference

Getting a specific version of an image with Jib (Maven, Docker, testcontainers)

I'm trying to understand a comment that a colleague made. We're using testcontainers to create a fixture:
import org.testcontainers.containers.GenericContainer;
import org.testcontainers.utility.DockerImageName;
public class SalesforceFixture extends GenericContainer<SalesforceFixture> {
private static final String APPLICATION_NAME = "salesforce-emulator";
public SalesforceFixture() {
// super(ImageResolver.resolve(APPLICATION_NAME));
super(DockerImageName.parse("gcr.io/ad-selfserve/salesforce-emulator:latest"));
...
}
...
The commented code is what it used to be. The next line is my colleague's suggestion. And on that line he commented:
This is the part I don't know. The [ImageResolver] gets the specific version of the emulator, rather than the latest. You need a docker-info file for that though, which jib doesn't automatically generate (but I think it can).
This is what I know or have figured so far:
SalesforceFixture is a class that will be used by other projects to write tests. It spins up a container in Docker, running a service that emulates the real service's API. It's like a local version of the service that behaves enough like the real thing that if one writes code and tests using the fixture, it should work the same in production. (This is where my knowledge ends.)
I looked into ImageResolver—it seems to be a class we wrote that searches a filesystem for something:
public static String resolve(String applicationName, File... roots) {
Stream<File> searchPaths = Arrays.stream(roots).flatMap((value) -> {
return Stream.of(new File(value, "../" + applicationName), new File(value, applicationName));
});
Optional<File> buildFile = searchPaths.flatMap((searchFile) -> {
if (searchFile.exists()) {
File imageFile = new File(searchFile + File.separator + "/target/docker/image-name");
if (imageFile.exists()) {
return Stream.of(imageFile);
}
}
return Stream.empty();
}).findAny();
InputStream build = (InputStream)buildFile.map(ImageResolver::fileStream).orElseGet(() -> {
return searchClasspath(applicationName);
});
if (build != null) {
try {
return IOUtils.toString(build, Charset.defaultCharset()).trim();
} catch (IOException var6) {
throw new RuntimeException("An exception has occurred while reading build file", var6);
}
} else {
throw new RuntimeException("Could not resolve target image for application: " + applicationName);
}
}
But I'm confused. What filesystem? Like, what is the present working directory? My local computer, wherever I ran the Java program from? Or is this from within some container? (I don't think so.) Or maybe the directory structure inside a .jar file? Or somewhere in gcr.io?
What does he mean about a "specific version number" vs. "latest"? I mean, when I build this project, whatever it built is all I have. Isn't that equivalent to "latest"? In what case would an older version of an image be present? (That's what made me think of gcr.io.)
Or, does he mean, that in the project using this project's image, one will not be able to specify a version via Maven/pom.xml—it will always spin up the latest.
Sorry this is long, just trying to "show my work." Any hints welcome. I'll keep looking.

I can't comment on specifics of your own internal implementations, but ImageResolver seems to work on your local filesystem, e.g. it looks into your target/ directory and also touches the classpath. I can imagine this code was just written for resolving an actual image name (not an image), since it also returns a String.
Regarding latest, using a latest tag for a Docker image is generally considered an anti-pattern, so likely your colleague is commenting about this. Here is a random article from the web explaining some of the issues with latest tag:
https://vsupalov.com/docker-latest-tag/
Besides, I don't understand why you ask these questions which are very specific to your project here on SO rather than asking your colleague.

Read the jar version for a class

For a webservice client I'd like to use Implementation-Title and Implementation-Version from the jar file as user-agent string. The question is how to read the jar's manifest.
This question has been asked multiple times, however the answer seems not applicable for me. (e.g. Reading my own Jar's Manifest)
The problem is that simply reading /META-INF/MANIFEST.MF almost always gives wrong results. In my case, it would almost always refer to JBoss.
The solution proposed in https://stackoverflow.com/a/1273196/4222206
is problematic for me as you'd have to hardcode the library name to stop the iteration, and then still it may mean two versions of the same library are on the classpath and you just return the first - not necessarily the right - hit.
The solution in https://stackoverflow.com/a/1273432/4222206
seems to work with jar:// urls only which completely fails within JBoss where the application classloader produces vfs:// urls.
Is there a way for code in a class to find it's own manifest?
I tried the abovementioned items which seem to run well in small applications run from the java command line but then I'd like to have a portable solution as I cannot predict where my library would be used later.
public static Manifest getManifest() {
log.debug("getManifest()");
synchronized(Version.class) {
if(manifest==null) {
try {
// this works wrongly in JBoss
//ClassLoader cl = Version.class.getProtectionDomain().getClassLoader();
//log.debug("found classloader={}", cl);
//URL manifesturl = cl.getResource("/META-INF/MANIFEST.MF");
URL jar = Version.class.getProtectionDomain().getCodeSource().getLocation();
log.debug("Class loaded from {}", jar);
URL manifesturl = null;
switch(jar.getProtocol()) {
case "file":
manifesturl = new URL(jar.toString()+"META-INF/MANIFEST.MF");
break;
default:
manifesturl = new URL(jar.toString()+"!/META-INF/MANIFEST.MF");
}
log.debug("Expecting manifest at {}", manifesturl);
manifest = new Manifest(manifesturl.openStream());
}
catch(Exception e) {
log.info("Could not read version", e);
}
}
}
The code will detect the correct jar path. I assumed by modifying the url to point to the manifest would give the required result however I get this:
Class loaded from vfs:/C:/Users/user/Documents/JavaLibs/wildfly-18.0.0.Final/bin/content/webapp.war/WEB-INF/lib/library-1.0-18.jar
Expecting manifest at vfs:/C:/Users/user/Documents/JavaLibs/wildfly-18.0.0.Final/bin/content/webapp.war/WEB-INF/lib/library-1.0-18.jar!/META-INF/MANIFEST.MF
Could not read version: java.io.FileNotFoundException: C:\Users\hiran\Documents\JavaLibs\wildfly-18.0.0.Final\standalone\tmp\vfs\temp\tempfc75b13f07296e98\content-e4d5ca96cbe6b35e\WEB-INF\lib\library-1.0-18.jar!\META-INF\MANIFEST.MF (The system cannot find the path specified)
I checked that path and it seems even the first URL to the jar (obtained via Version.class.getProtectionDomain().getCodeSource().getLocation() ) was wrong already. It should have been C:\Users\user\Documents\JavaLibs\wildfly-18.0.0.Final\standalone\tmp\vfs\temp\tempfc75b13f07296e98\content-e4d5ca96cbe6b35e\WEB-INF\lib\library-1.0.18.jar.
So this could even point to a problem in Wildfly?

It seems I found some suitable solution here:
https://stackoverflow.com/a/37325538/4222206
So in the end this code can display the correct version of the jar (at least) in JBoss:
this.getClass().getPackage().getImplementationTitle();
this.getClass().getPackage().getImplementationVersion();
Hopefully I will find this answer when I search next time...

Node JS Trireme include module

I'm running Node JS with https://github.com/apigee/trireme from Java, inside the JVM. I have a directory that looks as following:
node/
-test_file.js
-test_somemodule.js
-somemodule/
-somemodule/index.js
-somemodule/...
I have no problem running the test_file.js using this code:
#Test
public void shouldRunTestScript() {
try {
NodeEnvironment env = new NodeEnvironment();
// Pass in the script file name, a File pointing to the actual script, and an Object[] containg "argv"
NodeScript script = env.createScript("my-test-script.js",
new File(Settings.getInstance().getNodeDir() + "/my-test-script.js"), null);
// Wait for the script to complete
ScriptStatus status = script.execute().get();
// Check the exit code
assertTrue("Exit code was not 77.", status.getExitCode() == 77);
} catch (NodeException | InterruptedException | ExecutionException ex) {
Logger.getLogger(TriremeTest.class.getName()).log(Level.SEVERE, null, ex);
fail("Trireme triggered an exception: " + ex.getMessage());
}
}
In the file test_somemodule.js I include the index.js.
require('somemodule/index.js');
When I try to run that file, it can't find the file in the require.
I have no knowledge about Node JS, so I'm not familiar with the module loading. I already tried setting NODE_PATH, only to get
Error: Cannot find module 'request'
It seems like I can't obtain the NODE_PATH from Trireme, and if I overwrite it, Trireme fails to run. I'm out of ideas on how I could get an Node JS module loaded in Trimere. Any help appreciated.
Edit: I changed the require to ('./somemodule/index.js'), which works. So setting the NODE_PATH would have done the job too. I just found out the error came from an missing dependency.
"dependencies": {
"request": "^2.49.0",
"tough-cookie": "^0.12.1"
},
I figured out the best way to deal with it is installing Node JS + npm, and invoking npm install some_module in the node/ folder. It automatically downloads some_module and all of its dependencies into my node/ folder.
No more require errors.

I did not specify that the file was in the working directory.
require('./somemodule/index.js');
instead of
require('somemodule/index.js');
did the job. Another possiblity is to set the NODE_PATH environment variable to the node/ folder, so you can require without ./.
I also figured out that the best way to obtain modules is by installing them with npm instead of downloading them from git, because the latter does not download any dependencies.

Executions hangs up with no error after moving files to external jar

I have develop a simple java program to run APDU commands. It is working fine.
The file structure is
/moc
/omnikey
--Applet.java
--API.java
/omnikey.api
/omnikey.util
... another 3 more packages ...
Now, I want to extract all those extra packages to a new project and leave only the omnikey package (with Applet.java and API.java) to create a .jar with the needed functionality.
So I created a new project, copied all files, fixed the packages references and linked the external jars needed... and now it doesn't work...
The "new" file structure is like this
/apdu
/apduservice
/api
... files ...
/util
... files ...
/moc
/omnikey
Applet.java
API.java
For some reason, the execution hangs when I declare something from the apdu project. If I do
System.out.println("flag 1");
try {
apduservice.api.MocService ser = new apduservice.api.MocService(null);
} catch (CardServiceException e) {
e.printStackTrace();
}
System.out.println("flag 2");
I get no error trace and the output is flag 1. The execution doesn't stop until force it.
If I try the same thing with the previous configuration everything works.
System.out.println("flag 1");
try {
omnikey.api.MocService ser = new apduservice.api.MocService(null);
} catch (CardServiceException e) {
e.printStackTrace();
}
System.out.println("flag 2");
//output flag 1 and flag 2
I'm not sure where the error might be. I tried exporting the second project as jar, as runnable jar, reference it as a project inside Eclipse, and nothing, the same result. I've tried searching for a solution, but since I get no error, it's hard to know what to look for.
If someone could shed a light I'll be grateful.
PD: doesn't seem to be an Eclipse problem, I've referenced projects in other projects and it has work fine...
PD2: I'm not using Maven or anything like that to handle references. I rather not to, at least for now.

Decided to answer this since there's no logical reason for this to happen.
Solution:
change workspaces, open the two projects and link them. Eclipse was just having one of its days.

JGit/EGit Loading of translation bundle failed en_US

I am running the following code in a JUnit test to test fetching a git repository. I'm writing a test for each of the basic functionality i need from JGit so that then i can implement them in my application. The problem is that i keep getting the following error on the git.fetch() call below:
Loading of translation bundle failed for [org.eclipse.jgit.JGitText, en_US]
org.eclipse.jgit.errors.TranslationBundleLoadingException: Loading of translation bundle failed for [org.eclipse.jgit.JGitText, en_US]
The code sample is below. I verified that the repository paths and everything seems correct. If i put a breakpoint on the fetch call and then run the same command in MSysGit it works.
try {
String remoteName = "origin";
URIish uri = new URIish(repository.getRepositoryDirectory());
saveRemote(repository2.getRepository(), uri, remoteName);
Git git = repository.getGit();
FetchResult r = git.fetch().setRemote(remoteName).call();
assertNotNull("Did not get any result from fetch.", r);
} catch (JGitInternalException ex) {
fail("Failed to do fetch. " + ex.getMessage());
} catch (InvalidRemoteException ex) {
fail("Failed to do fetch. " + ex.getMessage());
} catch (URISyntaxException ex) {
fail("Failed to do fetch. " + ex.getMessage());
}
Thanks!

Okay I figured this out. I had to copy the file JGitText.properties from the binary distribution into the same package in the source code, rename it to JGitText_en_US.properties, and add a whole bunch of properties to it manually that the code used in JGitText.java but were not defined in JGitText.properties.
I searched through the entire source code and all binary files and related docs and found no reference to these new properties, or the properties file being created anywhere. I don't know why the devs don't have localization files in the source code or at least a way to generate then through a build file or something. I mean they must manually have to add them into their source code and just not commit it.
Anyway this was a very annoying issue, there was no documentation on it anywhere on the net (that google revealed anyway) so I thought i would share this as it might help others who ran into the same problem.

I had the same problem, but my fix was a little different. In my case, the problem was related to the OSGI classloader.
Here's a commit that fixes the issue:
https://github.com/diffplug/jgit/commit/3bcc69bde5567ec57ccd6bd065ded0db49f810fb
And here's the rationale behind it:
Loading a ResourceBundle within an OSGi bundle