We Keep Coding

Java inexplicably writes to file with good or wrong codepage depending on web API call URL

Good evening,
I am thoroughly baffled by a behaviour that happens with a Java application of mine.
The application is to be used to connect to a web API and download a table of data from there to be further used in academic research.
I was trying to set the export to correct encoding, to save time, I disabled iteration in calls to web API by disabling some methods and removing a variable from a URL string construction - placing an integer 42 in its place.
Upon this, I was surprised to see the correct encoding.
A bit down the road, and I can confirm - if I use this URL:
new URL("http://www.foo.bar/api/unit?id="+scraper.ujList[i]);
where ujList[] is an array of integers,
then the output has typical wrong encoded characters like this ÄŤasĹĄ RuĹľinov
meanwhile, if I use
new URL("http://www.foo.bar/api/unit?id="+42);
then the output is proper, like Ružinov.
I have also tried Integer.toString() as well as String.valueOf() on ujList member, but it didn't help.
FWIW it does not matter if I run a jar file, a class file, or from within Eclipse.
I have no idea how to continue.

Change working dir in Java Webstart

Is there a way to change working dir for JVM when running Java Webstart?
When i use system.setProperties("user.dir", newDir) it sets it(system.getProperties() shows it does) but ignores it.
Is this a limitation in Java Webstart to always use the working dir where i started the jnlp file?
I am using all permissions in the jnlp file.
Please help!
EDIT: Whatever i do now, my webstart always uses user.dir to save files. Frustrating!

I've had this question in the past myself, but I've always found that, in the end, I didn't need it. Why do I say this?
Because your java web start app is not like an executable run from Program Files. It doesn't even exist on your computer like most programs (it is broken up into a bunch of different files and reassembled by the JVM). Therefore, you cannot say that the program has its own directory to do what it needs.
But it doesn't need to. Here's why:
Java has the Preferences API to help when you need to store data. The under-workings of the Preferences API is as mysterious as JWS, thus they are really a perfect fit. Either way, if you need to write things to a file, you should check this API to see if it can meet your needs.
If you need to write files for the user, then prompting them and allowing them to choose the location obviously means you won't use your current working directory to read/write files.
If you need to serialize objects, you should just create a program directory using the user.home resource as #AndrewThompson suggested. This will be "your" directory and is as good (in fact, better) than a directory in Program Files (if you're running on Windows, as an example).
In conclusion, in all cases (that I've come across), there's no need to change your current working directory. If you need your own folder, create one in user.home (because you won't run into file permissions issues there).

..all my settings file i use is created in the user.dir.
There is the mistake. Put them in a sub-directory of user.home & the problem is solved.

In the hypothesis you really really need to divert user.dir property for Java WebStart execution, here is the only option I have found: set this system environment variable (so system wide):
_JAVA_OPTIONS="-Duser.dir=C:\Temp"
But care about it, this option is read and applied to any JVM executions.
Why was it required in my context ? Because Java WebStart ClassLoader was looking for any single resource (class, properties...) in user profile before getting it from jar files in cache. As the user profile has been moved to a network storage, application start up became terribly slow. I am still investigating Java sources to understand (and avoid) this behavior. So my applications work perfectly without setting user.dir but that was the only work-around for the performance issue we got at the moment.

The recommended way to pass runtime parameters or user specific setting is through the jnlp argument
<application-desc main-class=".....">
<argument>user.home</argument>
..............

NullPointerException with Owasp.CsrfGuard.Test

Why do I get:
java.lang.NullPointerException org.owasp.csrfguard.CsrfGuardFilter.doFilter(CsrfGuardFilter.java:53)
when trying to run the 0wasp.CsrfGuard.Test example app on Tomcat 5.5?
I'm using the example app exactly as it came in the download but with the following changes to get around listener errors:
I downloaded the CsrfGuard 3.0.0 package and copied the Owasp.CsrfGuard.jar to WEB-INF/lib to get around the listeners not being found.
I changed the web.xml file to use the listener that comes with the Owasp.CsrfGuard.jar rather than the two listeners in the original web.xml, which don't exist.
When I start the app there are no errors but when I point my browser to the /Owasp.CsrfGuard.Test/index.html page, I get the above error.
Any ideas to try?
Update...
Several hours later and I got it working without error. I don't understand why but the filter errors seem to stick around even after stopping and restarting a webapp (in Tomcat at least). I had to rename that webapp's directory, wait 10 seconds for Tomcat to auto-undeploy it, rename it back to its original directory name, and wait 10 seconds for Tomcat to recognize it as a new webapp. I also removed the "x-requested-with" init-param from the web.xml file since I don't use AJAX. Don't know if that really needed to come out but it works so I'm leaving it out.
Now, the "protect.html" file is indeed protected but it is protected too well. I can't get to it at all. If I try to go directly to the protect.html page, it should not allow that, which it doesn't. However, it should allow me to get there through the proper webpage flow with all the pages getting the proper token(s).
The question now is how can I get to the protect.html page?
Thanks.

Got it! In case someone else has problems, here is what I figured out to get JavaScript DOM Manipulation working.
All of the references in the .properties file MUST BE absolute with reference to the web container (Tomcat in my case). Even if you place the .js and .jar files in a specific webapp and modify that webapp's web.xml file with the proper settings for CSRFGuard (with relative references by the way), the entries in the .properties file must include references to the webapp name. For example, it must be something like:
org.owasp.csrfguard.unprotected.Index=/someapp/index.html
rather than just
org.owasp.csrfguard.unprotected.Index=index.html
This is not intuitive since unless you are dealing with the entire Tomcat container (i.e. the master web.xml file) you can generally drop the webapp name since it is implied for that webapp.
Now I'm going to look into the other CSRFGuard method of JSP Tag Injection since the JavaScript mechanism won't work if the user has JavaScript turned off in their browser.

How to edit HTML file's content dynamically

Up until now, when I needed to update the content of any pages, I have always had to update the source code directly and re-deploy the whole application. Right now, I want to implement a feature such that I can update the content of any HTML pages dynamically without having to re-deploy the application.
I tried to implement the feature with PrimeFaces's <p:editor> component but it does not work. To be more precise, my functions can correctly update the required page. When I goes to the source code folder, I can actually see my changes. However, subsequent requests for the page still render the old content.
I'd be very grateful if you could show me what I have done wrong. I'd also appreciate it very much if you could show me any other ways to achieve the same goal.

I think you are editing your work-space from your deployment. :)
You have 2 places with the code. One is deployed, and the other in your "working space".
First, it sounds to me like you want your working space to be the deployment. This way whenever you are editing something, you will be changing the deployment directly. For that, simply create a new project in your IDE and point it to the deployment folder.
I bet that :
C:\\Users\\James\\Documents\\NetBeansProjects\\MyProject\\MyProject-war\\web\\
points to your work-space and not the deployment. so effectively, your deployment is editing your work-space.

I think you are looking for this one:
FacesContext.getCurrentInstance().getExternalContext().getRealPath("/")
and if you want the location of the WEB-INF
use the following
String fullpath = FacesContext.getCurrentInstance().getExternalContext().getRealPath("/")+File.separator+"WEB-INF";
and so on...

My code actually was working perfectly. From the above answer of user1068746, I did some research and found this article. The solution is very simple: creating a virtual directory mapping to my hard-disk's directory. As a result, any updates to my files on the hard-disk will immediately be visible to future requests.

Java WS application ignoring arguments sporadically

I have recently put together a JWS application which gets it's argument from a dynamically created JNLP file (details can be found here). It's all good except the application ignores the argument (starts without loading the specified number) on my system (linux x86_64). It seems however that the JWS application exactly as intended on the win_64 machine of a colleague of mine. This is rather interesting as I couldn't replicate his success on another similar win_64.
To make things more exciting, the same JWS application works just fine (in other words, doesn't ignore the argument) when I download the JNLP file and run it by javaws on the terminal.
I have compared the java.policy and javaws.policy files and there are no differences. The JNLP file clearly gives all-permissions, and the jar files are signed all fine (which can't be the source of the problem otherwise the application wouldn't start, right?).
Question 1: So what could this problem depend on?
EDIT: I just managed to get proper response from a new (in this particular sense) win32 machine, without any obvious java update. Question 2 : Is there a log file for javaws on which I can check what happens, or alternatively, can I verbose the launch to a console so I can create my own custom logs?
Edit 2: By the way, I have forgotten to mention that I have also posted this question at the Oracle forums, which I should have perhaps mentioned initially as it was politely pointed out there. Anyways, there is more information on the JNLP file there on the thread, in case it might be relevant.
Edit 3: I came to think that the problem could be originating from the properties of the <jnlp> tag, upon generating the JNLP file. Originally the jnlp tag looked like this like this:
<jnlp spec="1.0+" codebase="http://mydomain/myapp/"
href="my.jnlp">
The problem with this is the fact that there is no my.jnlp in the the directory declared in the codebase, instead the JNLP code is created on the fly by a Perl script in the cgi-bin directory and returned as an output stream (I think). So I edited the script to generate the JNLP with the following tag:
<jnlp spec="1.0+" codebase="http://mydomain/myapp/"
href="http://mydomain/cgi-bin/my.jnlp">
The result of this experiment: not even the GUI started this time...
I have found a relevant thread on Oracle forums, where it was advised to define the href property in the following fashion:
href="script.jsp?<%=request.getQueryString()%>">
which unfortunately doesn't solve my problem.
Question 3: Could this modification be applicable to my situation as well? In that case how? If not any insights on what might be causing the problem would be seriously appreciated as I am really at a stalemate on my work right now

After two weeks of wrestling with the JNLP file syntax and my CGI script, I think I finally found the crux of the problem. I am noting this down here (at the risk of looking pretentious enough to answer my own question) in case somebody else runs into the same problem.
The href property of the <jnlp> tag, in my case was apparently unnecessary and when removed the application started working as intended on both linux and win systems. I am not 100% sure if this is the exact reason but my understanding is that as the jnlp syntax is generated from a script and directly returned to the user instead of a jnlp file somewhere in the filesystem, the href property was pointing to a wrong place and perhaps caused some sort of a clash that is handled differently in different OS.

Make sure the JNLP file is not cached. I.e., each time you try something new, have you renamed / relocated the JNLP file?
Regarding your updates,
The only ting that comes to my mind is that you need to make sure that your script responds with the correct mime type: application/x-java-jnlp-file
That is, from your cgi-script, you have to provide the HTTP header field
Content-Type: application/x-java-jnlp-file