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
Related
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.
I have an old program original written for java 1.3 that trys to get resource bundle :
java.text.resources.LocaleElements
and if that fails trys :
sun.text.resources.LocaleElements
ResourceBundle r=null;
try {
r = ResourceBundle.getBundle("java.text.resources.LocaleElements", zomLocale);
}
catch (Exception ex) {
try {
r = ResourceBundle.getBundle("sun.text.resources.LocaleElements", zomLocale);
}
catch (Exception ex1) {
ex1.printStackTrace();
}
}
This worked fine in 1.3 but these bundles do not exist in java 1.4.
I don't now enough about java as to know:
Where these resources comes from or
How I install them or
How to list what resource bundles are now available in 1.4 or
If I can simply provide the new/replacement name for the resource I want/need
I don't even know how I came up with the original resource bundle names in the first place.
I suppose the simplest solution for me is to determine what are the replacements for these missing bundles.
I'm using netbeans 12.2 maven (Ubuntu 20.04) if that make any difference!
Edit:
looking at the jdk packages :
https://openjdk.binarydoc.org/net.java/openjdk/14.0/package?package=sun.text.resources
I can see that "LocaleElements" no longer exists. A general search doesn't find anything for LocaleElements. So maybe the technique I was employing isn't valid anymore.
If the only thing I need out of LocaleElements is "DateTimePatterns" are there any suggestions how I should instead be doing this?
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...
Currently, I'm facing an issue where I'm trying to get a WSDL resource from my bundle classpath and then call FileLocator.toFileURL to convert it from a bundle resource to a file resource. At runtime, the method throws a NullPointerException while trying to get an instance of the URLConverter, and I'm pretty baffled as to why this could happen. Below is the code that I'm using.
URL configURL = Preference.class.getResource("/META-INF/wsdl/Preference.wsdl");
if (configURL != null && configURL.getProtocol() != "file") {
System.out.println("URL is not a file. Trying to convert from non-standard to something reference-able.");
URL wsdlURL = null;
try {
wsdlURL = FileLocator.toFileURL(configURL);
} catch (IOException e1) {
System.out.println("IOException caught");
e1.printStackTrace();
} catch (NullPointerException e1) {
System.out.println("NullPointerException caught");
e1.printStackTrace();
} catch (RuntimeException e1) {
System.out.println("RuntimeException caught");
e1.printStackTrace();
} catch (Exception e1) {
System.out.println("generic Exception caught");
e1.printStackTrace();
}
PREFERENCE_WSDL_LOCATION = wsdlURL;
} else {
System.out.println("URL is a file.");
PREFERENCE_WSDL_LOCATION = configURL;
}
When I run the code locally in RAD, it works fine. However, as I think almost everyone who develops OSGi code in Eclipse finds with these kinds of things, it ends up crashing when it's deployed. For me specifically, it is packed into an OSGi Composite Bundle Archive (CBA) and deployed to a WebSphere v8.5.5 app server. Below is the error that I keep running into and its stack trace.
java.lang.NullPointerException
at org.eclipse.core.internal.runtime.Activator.getURLConverter(Activator.java:322)
at org.eclipse.core.runtime.FileLocator.toFileURL(FileLocator.java:205)
at Preference.<clinit>(Preference.java:37)
I did a few sanity checks to make sure I wasn't missing anything obvious. The configURL variable is returning a value (bundleresource://2.fwk685840929/META-INF/wsdl/Preference.wsdl), and all of the dependencies I know of that are necessary for this workflow are added in my classpath (mainly the equinox and eclipse.osgi libraries).
I've google'd all over the place, and found two main resources: the source code for FileLocator and Activator which are both "present at the scene of the crime", and this Eclipse bug report for the exact same line number I'm seeing in my stack trace. However, neither makes sense, because the bug report states that this error would come about from an OSGi plugin not being available - how could this be possible if I'm literally deploying an OSGi bundle to WebSphere's OSGi ecosystem? - and if the line number in grepcode is to be trusted, then the error is apparently the urlTrackers variable which seems like it would be different from a bundle issue and not really something I can control.
I need some help here because I feel like I'm overthinking this a bit. How can I get the FileConverter class to actually work at runtime?
I think the JavaDoc comment is referring to the availability of the org.eclipse.osgi plugin which contains the bundleentry URL converter needed by FileLocator.
I don't think FileLocator is really designed to work outside of the Eclipse RCP environment.
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.