I'm in the habit of filling in the META-INF/MANIFEST.MF of every jar file I build with information related to the version of the component, build time, ...
I want my lambda to log that information and/or have it as a part of its output.
In most cases, I can access this with code similar to:
{code}GreatestClassNameEver.class.getPackage().getImplementationVersion(){code}
I tried this with my lambda, but {code}getImplementationVersion(){code} returns null.
After creating an AWS support ticket, it turns out that this isn't possible due to how Lambda extracts the Jar.
When the jar is disassembled it's files are extracted as follows:
class files in /var/task/
libraries in /var/task/lib
properties and other config files in /var/task/resources
but the META-INF directory is not extracted during this process.
The workaround they gave me was to use a plugin to copy the manifest to the Resources directory and read from the /var/task/resources/... to get the information you need.
Related
The issue:
We have a jetty web-app, and in the application-code, I am trying to access a zip within a jar in classpath. Here's the jar in the libs folder:
/path/to/app/x.x.0-SNAPSHOT/apps/libs/my-model.jar
where my-model.jar is really just an empty folder with model.zip file inside it. If I extract this jar, I get johnsnow/mymodel.zip
My application code tries to access this zip as:
getClass().getResourceAsStream("johnsnow/mymodel.zip")
but of course, I don't get a proper handle to this resource and wind up getting a nullpointer exception. What am I doing wrong? Shouldn't I be able to access a file within a jar file in classpath using the getClass().getResourceAsStream() method?
Footnote:
Because model.zip was too large, we decided against shipping it with the code base. Thus we pushed it into a nexus repository, and reference the jar via a gradle compile dependency as follows:
compile "com.company.group.nlp:my-model:1.0#jar"
The fact that building the distribution pulls this jar, and puts it in apps/libs tells me that gradle does its part (of downloading the dependency to a classpath). The issue remains that I can't seem to find a way to access mymodel.zip inside my-model.jar
Try adding a slash to the file path:
getClass().getResourceAsStream("/johnsnow/mymodel.zip");
It will tell java to start looking for the class from the root folder, not from the current class package.
I took the java implementation of the Factual API (reference http://developer.factual.com/) and made a JAR file for factual. I did this by opening a new project in eclipse with the factual java files and then exporting to a new jar file.
I put that jar file in my coldfusion installation's /WEB-INF/lib/ folder.
After restarting Coldfusion, I tried to create a new cfobject like so
<cfscript>
// Initialize the Java class.
factualClass=CreateObject("java", "src.main.java.com.factual.driver.Factual");
</cfscript>
I get an error indicating that it cannot find the Factual class.
Can anybody give me some guidance?
(Summary from comments)
It sounds like you may be exporting the source files ie *.java rather than the compiled class files, ie *.class. In the Jar Export wizard, be sure to select the "Export generated class files and resources" option. (To automatically compile the project sources before expi, enable the setting: JAR packaging > Build projects if not build automatically option). If you prefer you can also find pre-compiled jars in the MVN repository.
put that jar file in my coldfusion installation's /WEB-INF/lib/
folder.
CF10+ also supports dynamic class loading via a new application level setting THIS.javaSettings.
// Initialize the Java class.
factualClass=CreateObject("java", "src.main.java.com.factual.driver.Factual");
Just as a point of interest, src/main/java/ is not actually part of the libary class name. It is a standard directory structure used in Maven projects. It is probably included when exporting the sources, but not the compiled classes.
You can always verify the correct path and class name either by examining the API ie javadocs or by viewing one the source files. Package declarations are always at the top of the source file, such as on line 1 of src/main/java/com/factual/driver/Factual.java:
package com.factual.driver; // ie "com.factual.driver"
.. and the class declaration on line 39.
public class Factual { // ie "Factual"
Combined that gives you the exact (case-sensitive) path to use with createObject:
factualClass=CreateObject("java", "com.factual.driver.Factual");
I am developing maven plagin that obfuscates js files. It does the following -:
takes *.js files from target,
obfuscates them using google closure,
creates *.min.js files in target,
if it's necessary removes sources (unobfuscated files) from target.
In order to get point between package phase and prepare-package phase I use the following solution: https://stackoverflow.com/a/27566620/2022068
Everything is ok. Plugin is ready. However I have the following problem - if I remove source file, maven-war-plugin copies it again. Maybe it has some mechanism of checking - I don't know. The only thing that I can do now is to delete and create empty file. Than the source file exists but it's empty.
My qeustion - can I somehow remove files from target finally, forever...?
You probably need to teach this to the maven-war-plugin. I have no example that does the same thing but there are packageExcludes (see: http://maven.apache.org/plugins/maven-war-plugin/examples/including-excluding-files-from-war.html) which seems not exactly what you need but also warSourceExcludes: http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#warSourceExcludes
The war plugin has its own mechanism of copying files (aside from the resources plugin). That may be the issue here. There are some examples on filtering as well: http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-webresources.html
Maybe treating the files you don't want to see as excludes will work (if warSourceExcludes is something different than what you plan to do).
I have a library which is used by a program. This library loads a special directory in the resources folder.
in the library I have the method
public class DataRegistry{
public static File getSpecialDirectory(){
String resourceName = Thread.currentThread().getContextClassLoader().getResource("data").getFile().replace("%20", " ");
File file = new File(resourceName);
return file;
}
}
in my program I have the main method
public static void main(String args[]){
System.out.println(Data.getSpecialDirectory());
}
When I execute the getSpecialDirectory() in a junit test within the data program, the resource is fetched and all is well.
When I execute the getSpecialDirectory() in the main method outside the data program (imported jar) I get the jars data directory and not the directory the program executing the thread is expecting.
I figured getting the parent class loader would have solved this issue... I believe I may have a fundamental issue in my understanding here.
For clarity:
(library)
Line 15 of this file: https://gist.github.com/AnthonyClink/11275442
(Usage)
Line 31 of this file:
https://gist.github.com/AnthonyClink/11275661
My poms may have something to do with it, so sharing them is probably important:\
(Library)
https://github.com/Clinkworks/Neptical/blob/master/pom.xml
(Usage)
https://github.com/Clinkworks/Neptical-Maven-Plugin/blob/master/pom.xml
Maven uses the target/classes and target/test-classes directories to compose the classpath used to run unit tests. The content of your src/main/resources and src/test/resources gets copied to these locations together with the compiled java sources (the .class files).
java.lang.ClassLoader.getResource returns a java.net.URL.
In the unit test situation, ClassLoader.getResource returns a file:// schemed URL, and your code works as expected.
When your code is executed when packaged in a jar file, ClassLoader.getResource no longer returns a file:// schemed URL. It can't because the resource is no longer a separate entity in a file system - it's buried inside the jar file. What you actually get is a jar:file:// schemed URL.
jar: URLs cannot be accessed through a [java.io.File] object.
If you only need to read the content of the resource you should use java.lang.ClassLoader.getResourceAsStream(...) and read the content from that.
Note that it is not possible to update the content of class loader resources.
Do you want the directory where the Java program was loaded from ? Can try
File f = new File(".").getCanconicalFile();
Or if you want all the places could try parsing the classpath from System.env or use the default class loader
If you want a directory relative to the jar from where your classes were loaded: Quoting from http://www.nakov.com/blog/2008/06/11/finding-the-directory-where-your-java-class-file-is-loaded-from/
URL classesRootDir = getClass().getProtectionDomain().getCodeSource().getLocation();
The above returns the base directory used when loading your .class
files. It does not contain the package. It contains the classpath
directory only. For example, in a console application the above
returns someting like this:
file:/C:/Documents%20and%20Settings/Administrator/workspace/TestPrj/bin/
In a Web application it returns someting like this:
file:/C:/Tomcat/webapps/MyApp/WEB-INF/classes/
FYI This might apply if the user id running program cannot read all folders: http://docs.oracle.com/javase/7/docs/api/java/lang/Class.html#getProtectionDomain%28%29
or pass a .class object of the calling class as a parameter and get its classloader
There is no guarantee that you have a directory for your resources as far as I know. Java provide methods to get a resource as a InputStream, but nothing that can easily get the File for a resource, although it is possible to get the URL for a given resource.
If you need a special working directory in your application, I recommend having that passed as a system property, a program parameter, a web application parameter, or something else that lets you know where your application files are. You can even populate this directory with a ZIP file that you include as a resource in your application, as the ZIP libraries in Java do accept input streams as parameters.
While user #tgkprog is right and his answer correct, I can hardly imagine that you really want what you seem to have asked for and what he correctly answered in (3). Please edit your question and explain
what the output should look like if resourceName would be printed to the console,
if you really want the JAR file's location (in my test case that would be something like file:/C:/Users/Alexander/.m2/repository/com/clinkworks/neptical/0.0.1-SNAPSHOT/data, which does not make sense because you do not want to read from or even write to the local Maven cache),
or if you maybe rather want to read a resource directly from the JAR file or any other location such as the current working directory etc.
Otherwise I am afraid there is no good way to answer the question.
I am using one third party jar in my code. In the jar file , in one of the classes, when I opened the class using de-compiler, the code below is written:
java.net.URL fileURL = ClassLoader.getSystemResource("SOAPConfig.xml");
Now I am using this in my webapplication, where should I place this SOAPConfig.xml so that it will find the fileURL.
Note: I have tried putting this XML in WEB-INF/classes folder. But it is not working. Your help will be appreciated.
In Addition: In the explaination you have given, It is telling me not to use this code snippet inside the third party jar in this way...What is the exact usage of this statement
ClassLoader.getSystemResource will load the resource from the system classloader, which uses the classpath of the application as started from the command line. Any classloaders created by the application at runtime (i.e. the one that looks in WEB-INF/classes) are not on the system classpath.
You need to
Look through the script that starts your server, find out which directories are on the classpath there, and put your SOAPConfig.xml in one of those. If necessary, change the classpath in the script to look in a separate directory that's just used for your config file.
Track down the person who used ClassLoader.getSystemResource in the library, kick them squarely in the nuts, and tell them never to do that again.