I am facing a problem while developing a standalone web application compiled with Maven.
I am using a third-party software (Tom Sawyer) inside the program that needs to be pointed to a file outside the JAR file. Besides, I am only able to feed it a File location (ie. C:path/to/file.json or /../../file.json) via a user interface.
However, whatever I feed the software I get an error FileNotFound :
java.io.FileNotFoundException: JAR entry project/..\..\..\..\modelData.json not found in C:\Users\victor\Desktop\ea-prototype\Workspace\3_WEB\CSM\webappCSM_v0.1\target\Model-1.0.6-SNAPSHOT.jar!/BOOT-INF/classes
at org.springframework.boot.loader.jar.JarURLConnection.throwFileNotFound(JarURLConnection.java:178) ~[Model-1.0.6-SNAPSHOT.jar:1.0.6-SNAPSHOT]
at org.springframework.boot.loader.jar.JarURLConnection.connect(JarURLConnection.java:101) ~[Model-1.0.6-SNAPSHOT.jar:1.0.6-SNAPSHOT]
at org.springframework.boot.loader.jar.JarURLConnection.getInputStream(JarURLConnection.java:165) ~[Model-1.0.6-SNAPSHOT.jar:1.0.6-SNAPSHOT]
at java.base/java.net.URL.openStream(URL.java:1152) ~[na:na]
I would like to know if the JarURLConnection is able to process a file from outside the Jar, and if yes, will /.. or /. allow the software to 'climb out' of the Jar ?
Thanks
I have found the solution to my problem. It is very specific to the related sofware I am using. Anyway here it goes :
I checked the option 'URL' instead of 'File Path' and wrote a file URL location ie.
file:///C:/path/to/my/file.json
Though, it will only work with absolute paths and not with relative paths.
Related
I am using Symfony2 framework for one of my project. In this one, I want to upload an image. This is really easy to do so while following the Symfony2's cookbook. It works very well on my local machine. But when I put the whole application on my remote server (Planethoster.net shared hosting), it doesn't work because of the Type-Mime extension guessers. In fact, they are not enable on their servers... (phpinfo shows --disable-fileinfo)
So, basically the idea is to know if there is a solution to do the same action (uploading an image) without any extension guessers?
Thanks
What do you think of filtering the filename ? With the last three characters, you'll know the extension. Check out UploadedFile, there is a getClientOriginalName() method. What I would do is to explode it by the ., fetch the second entry of the resulting array, and then parse it to do what you want to do.
Would you like an example of code ?
To fix exception while uploading file using framework Symfony 2
Unable to guess the mime type as no guessers are available.
enable PHP extension php_fileinfo, to do this find your php.ini file and uncomment following line
; windows
extension=php_fileinfo.dll
or
; linux
extension=php_fileinfo.so
I have used resource file(.resx) file in a class library project to store some error messages. When I set the "Build Action" to "Embedded Resource" for the resx file and deploy it works fine. But I would like to separate the resource file from the dll since I may need to change the error messages in resx file in future without the need to recompiling the class library project. I tried the other option in "Build Action" property Content,resource, etc but nothing seems to be working in the way I require. When I use these property I am getting the below error,
Could not find any resources appropriate for the specified culture or the neutral culture. Make sure was correctly embedded or linked into assembly at compile time, or that all the satellite assemblies required are loadable and fully signed.
Is there any way to resolve this error and make it work?
Resource files have to be set to embedded - that's how they work.
You can create another assembly containing the resources and reference it - this way you can redeploy the updated resources. It requires a bit more work in your code (loading the assembly in order to be able to get the embedded resources).
However, from your description (text messages that need to be editable after deployment), perhaps storing these in configuration is a better option (in particular if you are not localizing).
I am building my site with a web deployment project but the build fails with a number of errors all relating to the "#include virtual" directives in my master page.
The includes are necessary to import a set of centrally managed html template files.
Here is an example of the include directive and associated error:
<!-- #include virtual="/v3/sits/pdpdev/assets-templates/inc/head.html" -->
/PDPRegistration.csproj/Pages/ContentPage.Master(15):
error ASPPARSE: Failed to map the path
'/v3/sits/pdpdev/assets-templates/inc/head.html'.
The error for each included file actually appears multiple times. I'm not sure what is being mapped or why, but this was never a problem until I started using WDP (which I wanted to alter web.config depending on the build environment, among other things.)
The project is built locally on my PC and then copied to the web server via a mapped drive. I found a few solutions on the 'net involving IIS metabase - they weren't quite clear to me, and I'm not sure if they apply given how I build and deploy the project (that is, would I have to build on the same system as IIS in order to make use of the metabase?)
Can anyone suggest how I can get my project to build with WDP?
Although SSI's are available within the Framework, the preferred way of doing include is to wrap the content from the file into a User Control (.ascx) as per the MSDN documentation See also: support.microsoft.com/kb/306575
In my web application I have to send email to set of predefined users like finance#xyz.example, so I wish to add that to a .properties file and access it when required. Is this a correct procedure, if so then where should I place this file? I am using Netbeans IDE which is having two separate folders for source and JSP files.
It's your choice. There are basically three ways in a Java web application archive (WAR):
1. Put it in classpath
So that you can load it by ClassLoader#getResourceAsStream() with a classpath-relative path:
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
InputStream input = classLoader.getResourceAsStream("foo.properties");
// ...
Properties properties = new Properties();
properties.load(input);
Here foo.properties is supposed to be placed in one of the roots which are covered by the default classpath of a webapp, e.g. webapp's /WEB-INF/lib and /WEB-INF/classes, server's /lib, or JDK/JRE's /lib. If the propertiesfile is webapp-specific, best is to place it in /WEB-INF/classes. If you're developing a standard WAR project in an IDE, drop it in src folder (the project's source folder). If you're using a Maven project, drop it in /main/resources folder.
You can alternatively also put it somewhere outside the default classpath and add its path to the classpath of the appserver. In for example Tomcat you can configure it as shared.loader property of Tomcat/conf/catalina.properties.
If you have placed the foo.properties it in a Java package structure like com.example, then you need to load it as below
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
InputStream input = classLoader.getResourceAsStream("com/example/foo.properties");
// ...
Note that this path of a context class loader should not start with a /. Only when you're using a "relative" class loader such as SomeClass.class.getClassLoader(), then you indeed need to start it with a /.
ClassLoader classLoader = getClass().getClassLoader();
InputStream input = classLoader.getResourceAsStream("/com/example/foo.properties");
// ...
However, the visibility of the properties file depends then on the class loader in question. It's only visible to the same class loader as the one which loaded the class. So, if the class is loaded by e.g. server common classloader instead of webapp classloader, and the properties file is inside webapp itself, then it's invisible. The context class loader is your safest bet so you can place the properties file "everywhere" in the classpath and/or you intend to be able to override a server-provided one from the webapp on.
2. Put it in webcontent
So that you can load it by ServletContext#getResourceAsStream() with a webcontent-relative path:
InputStream input = getServletContext().getResourceAsStream("/WEB-INF/foo.properties");
// ...
Note that I have demonstrated to place the file in /WEB-INF folder, otherwise it would have been public accessible by any webbrowser. Also note that the ServletContext is in any HttpServlet class just accessible by the inherited GenericServlet#getServletContext() and in Filter by FilterConfig#getServletContext(). In case you're not in a servlet class, it's usually just injectable via #Inject.
3. Put it in local disk file system
So that you can load it the usual java.io way with an absolute local disk file system path:
InputStream input = new FileInputStream("/absolute/path/to/foo.properties");
// ...
Note the importance of using an absolute path. Relative local disk file system paths are an absolute no-go in a Java EE web application. See also the first "See also" link below.
Which to choose?
Just weigh the advantages/disadvantages in your own opinion of maintainability.
If the properties files are "static" and never needs to change during runtime, then you could keep them in the WAR.
If you prefer being able to edit properties files from outside the web application without the need to rebuild and redeploy the WAR every time, then put it in the classpath outside the project (if necessary add the directory to the classpath).
If you prefer being able to edit properties files programmatically from inside the web application using Properties#store() method, put it outside the web application. As the Properties#store() requires a Writer, you can't go around using a disk file system path. That path can in turn be passed to the web application as a VM argument or system property. As a precaution, never use getRealPath(). All changes in deploy folder will get lost on a redeploy for the simple reason that the changes are not reflected back in original WAR file.
See also:
getResourceAsStream() vs FileInputStream
Adding a directory to tomcat classpath
Accessing properties file in a JSF application programmatically
Word of warning: if you put config files in your WEB-INF/classes folder, and your IDE, say Eclipse, does a clean/rebuild, it will nuke your conf files unless they were in the Java source directory. BalusC's great answer alludes to that in option 1 but I wanted to add emphasis.
I learned the hard way that if you "copy" a web project in Eclipse, it does a clean/rebuild from any source folders. In my case I had added a "linked source dir" from our POJO java library, it would compile to the WEB-INF/classes folder. Doing a clean/rebuild in that project (not the web app project) caused the same problem.
I thought about putting my confs in the POJO src folder, but these confs are all for 3rd party libs (like Quartz or URLRewrite) that are in the WEB-INF/lib folder, so that didn't make sense. I plan to test putting it in the web projects "src" folder when i get around to it, but that folder is currently empty and having conf files in it seems inelegant.
So I vote for putting conf files in WEB-INF/commonConfFolder/filename.properties, next to the classes folder, which is Balus option 2.
Ex: In web.xml file the tag
<context-param>
<param-name>chatpropertyfile</param-name>
<!-- Name of the chat properties file. It contains the name and description of rooms.-->
<param-value>chat.properties</param-value>
</context-param>
And chat.properties you can declare your properties like this
For Ex :
Jsp = Discussion about JSP can be made here.
Java = Talk about java and related technologies like J2EE.
ASP = Discuss about Active Server Pages related technologies like VBScript and JScript etc.
Web_Designing = Any discussion related to HTML, JavaScript, DHTML etc.
StartUp = Startup chat room. Chatter is added to this after he logs in.
It just needs to be in the classpath (aka make sure it ends up under /WEB-INF/classes in the .war as part of the build).
You can you with your source folder so whenever you build, those files are automatically copied to the classes directory.
Instead of using properties file, use XML file.
If the data is too small, you can even use web.xml for accessing the properties.
Please note that any of these approach will require app server restart for changes to be reflected.
Assume your code is looking for the file say app.properties. Copy this file to any dir and add this dir to classpath, by creating a setenv.sh in the bin dir of tomcat.
In your setenv.sh of tomcat( if this file is not existing, create one , tomcat will load this setenv.sh file.
#!/bin/sh
CLASSPATH="$CLASSPATH:/home/user/config_my_prod/"
You should not have your properties files in ./webapps//WEB-INF/classes/app.properties
Tomcat class loader will override the with the one from WEB-INF/classes/
A good read:
https://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html
I've a simple, if not primitive, C++/CLI .NET 2.0 class library. It is used in order to wrap some C++ legacy code for the Web Service. The following facts appear to be true:
Primitive C# test program calls class library and it works.
If class library does not refer to any modules of our code base, it works as well as part of the web service. That is, I load the web service and invoke the methods and receive proper response.
The same moment I replace the copied and pasted code by the calls from our code base libraries, the Web Service stops to load. I get System.IO.FileNotFoundException message.
The problem: I cannot find any place where the file name that couldn't be found is written.
I googled it and gave some permissions to some ASP.NET user on my computer. I copied all the DLLs of our libraries into the same directory where web service is installed. I searched in IIS logs, event logs, etc - no where could I find the name of the module that prevents the web service from coming up.
Any help on the matter would be greatly appreciated.
Boris
Make sure all the dependent DLLs are in the path (Path meaning not the directory where your assembly is, because ASP.net copies your assembly away into a temporary folder, but rather a directory that's included in the System path environment variable).
What calls are you replacing? Could it be the original code gracefully handles missing files (which may not even be important) and yours does not?
Add same rights to the iusr-account that you did to the asp.net-account.