I want to read a json file placed in resources/data/info.json in my webapp. Got to know that need to use Convertor.class.getResourceAsStream("\\WEB-INF\\classes\\data\\Address.json"); where Convertor is my util class for some reason am unable to read the file and i see the InputStream returning null and i see the below exception :
com.fasterxml.jackson.databind.exc.MismatchedInputException: No content to map due to end-of-input
at [Source: UNKNOWN; line: 1, column: 0]
at com.fasterxml.jackson.databind.exc.MismatchedInputException.from(MismatchedInputException.java:59)
at com.fasterxml.jackson.databind.ObjectMapper._initForReading(ObjectMapper.java:4133)
at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:3988)
at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3058)
at com.wf.hrca.util.Convertor.unMarshal(Convertor.java:84)
resources is a folder of your source project on your development machine. Tomcat doesn't care about how your source project looks like. And by the way, when you'll deploy the application in production, there won't be any source project on the machine.
All Tomcat cares about is the war file you deploy. Inside this war file, the WEB-INF/classes directory, along with all the jar files under WEB-INF/lib, constitute the classpath of the application.
Convertor.class.getResourceAsStream(), as the javadoc explains (but you really need to read it to know) expects a /-separated path. If the path starts with a /, then the path starts at one of the roots of the classpath (i.e. / refers to WEB-INF/classes, and to the root of each jar file of WEB-INF/lib).
So, find where the json file is located inside the war file. If it's under /WEB-INF/classes/data/info.json, then you should use
Convertor.class.getResourceAsStream("/data/info.json");
Related
I'm working on a spring-mvc project and was wondering if, like grails, I can create an external configuration file in tomcat with the appconfig folder. My project lives in /var/lib/tomcat7/webapps/<app> and was wondering if placing a configuration file in /var/lib/tomcat7/appconfigs/<config.xml> would work? If so, is it like grails and the application searches that location by default, or do I need to specify where that configuration lives? Thanks
What do you mean by "external configuration file"? Would this config file be separate from the war file? Or would it be packaged along with war file?
If packaged along with war file, you can put it under src/main/resources folder and it should be automatically packaged and placed in classpath.
If not packaged with war file, I usually put the configuration parameters under Tomcat's context.xml. Here's the documentation: http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Environment_Entries
I have a war file,. myapp.war (it happens to be a grails app, but this is not material)
I upload this to an s3 bucket, say myapp in us-west-2
I set up an OpsWorks using the S3 repository type:
Repository Type: S3
Repository URL: https://myapp.s3-us-west-2.amazonaws.com/myapp.war
Access key ID: A key with read permission on the above bucket
Secret access key: the secret for this key
Deploy to an instance in Java layer (Tomcat 7)
All lights are green, deployments succeeded
But the app isn't actually deployed
Shelling in to the instance and looking in /usr/share/tomcat7/webapps I find a directory called 'myapp'. Inside this directory is a file called 'archive'. 'archive' appears to be a war file, but it is not named 'archive.war', and it is in a subdirectory of webapps, so tomcat isn't going to deploy it anyway.
Now, the OpsWorks docs say the archive should be a 'zip' file. But:
zipping up myapp.war into a zip archive 'myapp.war.zip' and changing the path to this file results in 'myapp' containing 'myapp.war'. No deployment, since tomcat isn't looking for war files in 'webapps/myapp'
Changing the name of 'myapp.war' to 'myapp.zip' and changing the repository path results in 'myapp' containing the single file 'archive' again.
So. Can anyone describe how to properly provide a war file to OpsWorks from S3?
It appears that the problem has to do with how the zip archive is made.
Jars, war, and the like created with the java 'jar' tool do not work. Zip archives created with a zip tool, and then renamed to have a '.war' extension do.
This is explained here: https://forums.aws.amazon.com/thread.jspa?messageID=559582򈧞
Quoting that post's answer:
Our current extract script doesn't correctly identify WAR files. If
you unpack the WAR file and use zip to pack it, it should work until
we update our script.
So the procedure that works is to:
Explode the war made by your development environment (In the case of grails, the war build cleans up the staging directory for the war, so you don't have an exploded war directory laying around to zip up yourself, you have to unzip it first.)
Zip the contents of the directory created by exploding the war using a zip tool (or, if your build tool leaves the exploded war directory there, then just zip it directly)
Optionally, rename the new zip archive to have a '.war' extension.
Resume the procedure from the original question, step 3 -- that is, upload the war to the s3 bucket and
Specify the S3 path to the war file as the repository in the OpsWorks setup.
EDIT:
After answering this, I discovered that Grails can produce an exploded war directory after all.
// BuildConfig.groovy
...
grails.project.war.exploded.dir = "path/to/exploded/war-directory"
grails.war.exploded=true
...
That directory can be zipped or jarred or whatever you want by your builder/deployer.
From this wiki page you see that a WAR file is just a special JAR file. And if you check out what a JAR is here then you see it is just zipped up compiled java code.
This SuperUser question also touches on the .WAR vs .zip business. Basically, a WAR is just a special ZIP. So when you upload a WAR, you are uploading a ZIP.
Make sure it's a WAR file in the S3 bucket.
Provide the entire link to the S3 WAR file. To get this, right-click the WAR file in S3 and select Properties and then copy the link.
If I have multiple binaries whose sources are scattered in various subfolders of an overlaying folder, would windbg have access to them if only the topmost folder was included in Source Path? As opposed to having to reference each project folder of each relevant binary separately.
Assuming, of course, that the sources are unique in the mentioned folder structure, i.e. there are no multiple versions of one and the same project, source, etc.
If you specify the parent folder for the source files in source path then it should traverse through the subdirectories to find the source files.
Note that it will perform a signature match against your source files, in the same way that Visual studio will complain that the source files are different to the loaded dlls.
The relative locations of the source files must match the original locations so if your source files are located in a different structure then you will need to do a manual load/browse to specify the location of the source files.
Can’t answer exactly, but I often have 3 top (parent) directories, and each have approximately 4-5 levels of sub directories. No problems. However nothing beats using a source server
Short answer: NO.
From windbg's help:
For each directory in the symbol path, the debugger looks in three
directories. For example, if the symbol path includes the c:\MyDir
directory, and the debugger is looking for symbol information for a
DLL, the debugger first looks in c:\MyDir\symbols\dll, then in
c:\MyDir\dll, and finally in c:\MyDir. The debugger then repeats this
process for each directory in the symbol path. Finally, the debugger
looks in the current directory and then in the current directory with
\dll appended to it. (The debugger appends dll, exe, or sys, depending
on which binaries it is debugging.)
You can move all projects' .pdb files to one folder or change projects properties and setup the linker to create the .pdb file in a specific folder so you have to reference only one.
I've been doing a bit of debugging on this myself. From what I can tell, the relative path of the file found from the SourcePath needs to match part of the end path of the path embedded in the PDB. For example:
I have a file on disk at:
C:\Users\User\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\sys\windows\thread_local_key.rs
The path of the file embedded in the PDB is:
/rustc/c09a9529c51cde41c1101e56049d418edb07bf71\/library\std\src\sys\windows\thread_local_key.rs
✔ This SourcePath, and any below it, correctly finds the file:
C:\Users\User\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust
❌ This SourcePath, and any above it, does not find the file:
C:\Users\User\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src
Notice how with the failure case, the relative path to the file would begin with library\. The library path component is the first part of the path that is not found in the embedded path. I assume it does a path check for every relative address, recursively:
thread_local_key.rs
windows\thread_local_key.rs
sys\windows\thread_local_key.rs
src\sys\windows\thread_local_key.rs
std\src\sys\windows\thread_local_key.rs
library\std\src\sys\windows\thread_local_key.rs
etc.
I have a .jar file executing on a aws ec2 instance which contains the following code:
List<String> lines = FileUtils.readLines(new File("googlebooks-eng-all-1gram-20120701-k"));
the file exists in projectname/res and also in /projectname directly. I included /res in the build path. Also I see that the file exists inside the jar file at the root if I export the .java file in eclipse.
If I run the jar localy on my pc it works fine. But if I run it on a ec2 instance it says:
java.io.FileNotFoundException: File 'googlebooks-eng-all-1gram-20120701-k' does not exist
How can that be?
On your PC it is reading from the actual file on the filesystem - that is what new File means - a file on the filesystem.
To access a resource in a jar file you need to call getResourceAsStream or something similar instead.
I have a problem regarding exporting my Java project into a jar file.
I have this file (application.properties) which contains some database information and located under the project root directory.
There is no problem when running this project on Eclipse. But after exporting into a jar(Runnable Jar file) file, application.properties will not be included in the packaging and that cause the error.
Any suggestion how to fix this problem?
Do you want to have the application.properties reside outside the jar (for writing), or is it read-only? When outside you can have an initial template file in the jar, and copy it to some location.
//String applicationWorkingDir = System.getProperty("user.dir"); // The current constellation.
String userHomeDir = System.getProperty("user.home");
File myApplicationDataDir = new File(userHomeDir + "/.MyApplication");
myApplicationDataDir.mkdir();
File propertiesFile = new File(myApplicationDataDir, "application.properties");
Also using the Preferences API instead of a properties would be a solution.