I have to create a java applet that needs to access static data which is around 600k in size. This data is exported from an sql database. What is the the best format for that data to be stored in (xml, json, java include file), to get fastest/easiest access to it. I am a complete java noob and this question might be stupid, but is there a way to 'compile' this data in to executable so there are no additional requests to server once the applet is loaded. Thanks in advance!
I do not know what do you mean when you mention 'java include file'.
All the rest is OK. You can use either XML or JSON. It depends on your needs and taste. Just remember that JDK has built-in tools to parse XML and does not have such tools for JSON, so you will have to add external dependency (e.g. GSON). Generally it is not a problem but sometimes code size may be important for applets that are expected to be downloaded from server to client.
The other problems with applets is that unsigned applet cannot write to client's disk. So, whatever format you choose you have to store the information somewhere. You can store it on server, but server has access to DB anyway, so why to create copy?
So, my suggestion is the following. Store data in database. Create server side component (web service) that allows your applet to access the data. Applet should store in browser cookies user id, so next time user runs the applet it enters automatically.
To access browser cookie from applet user live connect and remember that applet tag should have MAYSCRIPT attribute.
If the data is static, just copy in the source tree next to your .java files.
From there, you can access it (from a class in the same package) with:
getClass().getClassLoader().getResourceAsStream("name");
Related
I am developing an API in Java. It is basically a java servlet that returns content in json (application/json). Using a Tomcat server. One of the field in the response is supposed to be a link to a downloadable .txt file.
I wonder what is the best way to deliver this file:
Generating this file on every request seems to me killer, even having some cron to clean directories with files
Any way to give a temporary link only while that request for a period without saving to the file system?
Thank you.
If you say writing to the file system would kill your application, then I deduce from that that your IO performance is too weak for that, right? I mean, if you even would not have the storage capacity for that, then your infrastructure is not suitable for your application at all. I can only see four other ways for solving that problem (but maybe there are more, my list is not exclusive):
Store the text file in a database. The database should also store timeout information. Good if there are more than 1 application servers and there is a load balancer in front of them (but all application servers share the same database).
Store the text file in RAM, maybe using a cache library which does the cleanup tasks automatically for you - but be aware that a cache library will usually not guarantee a minimum storage time for each file.
Do not store the text file at all, but create it just when it is requested (no idea if that is possible in your application).
Do not provide a link to the text file, but directly include its content in the json answer (of course it would then be escaped as a JSon String), which means your server can directly forget about it when the answer has been sent, but the client _must_ download it without checking if it needs the file or not.
I am creating a series of websites that will share a common java code base but will each have a different look and feel, as well as make slightly different calls to a database. Each site will have a unique URL (www.siteA.com, www.siteB.com).
The necessary database information is stored in properties files that appear to be loaded when the applications are deployed (to a JBoss 4.2.3 server). The CSS and images are in static folders.
What I want:
The user enters www.siteA.com
The "unbranded" site is initialized
Java (or whatever needs to) checks the URL to see which files to load
siteA.properties and siteA.css are loaded from the siteA resources folder
siteA's customized site is served to the client
If www.siteB.com is entered, all of its info would be loaded. When I want to add a new Site C, I will just create a siteC resources folder, put the SiteC versions of properties and CSS in it, and the underlying common code should take care of noticing that www.siteC.com was entered and grab from the new folder. All of this should happen without having to redeploy any of the elements common to all the sites.
I think I've mostly figured out how to get the CSS/images side of this working, but I can't get the properties files loaded this way.
Is this even possible? I haven't even been able to find a high-level discussion of the process.
Why don't you look up the HOST http header and output the relevant information for each server using a PHP script. You can output common content using file from an HTML file stored somewhere on the server.
Requirement is to keep a copy of complete web page at server side same as it is rendered on client browser as past records.These records are revisited.
We are trying to store the html of rendered web page. The html is then rendered using resources like javascript, css and image present at server side. These resources keep on changing. Therefore old records are no longer rendered perfectly.
Is there any other way to solve above? We are also thinking converting it into pdf using IText or apache FOP api but they does not consider javascript effect on page while conversion. Is there any APIs available in java to achieve this?
Till now, no approach working perfectly. Please suggest.
Edit:
In summary,requirement is to create a exact copy of rendered web page at server side to store user activities on that page.
wkhtmltopdf should do this quite nicely for you. It will take a URL, and return a pdf.
code.google.com/p/wkhtmltopdf
Example:
wkhtmltopdf http://www.google.com google.pdf
Depending on just how sophisticated your javascript is, and depending on how faithfully you want to capture what the client saw, you may be undertaking an impossible task.
At a high level, you have the following options:
Keep a copy of everything you send to the client
Get the client to return back exactly whatever it has rendered
Build your system in such a way that you can actually fetch all historical versions of the constituent resources if/when you need to reproduce a browser's view.
You can do #1 using JSP filters etc, but it doesn't address issues like the javascript fetching dynamic html content during rendering on the client.
Getting the client to return what they are seeing (#2) is tricky, and bandwidth intensive.
So I would opt for #3. In order to turn a website that renders dynamic content versioned, you have to do several things. First, all datasources need to versioned too. So any queries would need to specify the version. "Version" can be a timestamp or some generation counter that you maintain. If you are taking this approach, you would also need to ensure that any javascript you feed to the client does not fetch external resources directly. Rather, it should ask for any resources from your system. Your system would in turn fetch the external content (or reuse from a cache).
The answer would depend on the server technology being used to write the HTML. Are you using Java/JSPs or Servlets or some sort of an HTTPResponse object to push the HTML/data to the browser?
If only the CSS/JS/HTML are changing, why don't you just take snapshots of your client-side codebase and store them as website versions?
If other data is involved (like XML/JSON) take a snapshot of those and version that as well. Then the snapshot of the client codebase as mentioned above with the contemporary snapshot of the data should together give you the exact rendering of your website as at that point of time.
A very resource-consuming requirement but...
You haven't written what application server you are using and what framework. If you're generating responces in your own code, you can just store it while generating.
Another possibility is to write a filter, that would wrap servlet's OutputStream and log everything that was written to it, you must just assure your filter is on the top of the hierarchy.
Another, very powerfull, easiest to manage and generic solution, however possibly the most resource-consuming: write transparent proxy server staying between user and application server, that would redirect each call to app server and return exact response, additionally saving each request and response.
If you're storing the html page, why not the references to the js, css, and images too?
I don't know what your implementation is now, but you should create a filesystem with all of the html pages and resources, and create references to the locations in a db. You should be backing up the resources in the filesystem every time you change them!
I use this implementation for an image archive. When a client passes us the url of an image we want to be able to go back and check out exactly what the image was at that time they sent it (since it's a url it can change at any time). I have a script that will download the image as soon as we receive the url, store it in the filesystem, and then store the path to the file in the db along with other various details. This is similar to what you need, just a couple more rows in your table for the js, css, images paths.
I have developed a command-line (read: no GUI) Java application which crunches through numbers based on a given dataset and a series of parameters; and spits out a series of HTML files as resultant reports. These reports hold a large amount of data in tables, so in order to give the users a easy and quick overview of the results, I utilized the JUNG2 library and created a nice graph.
Here's where it gets interesting; since I would like the graph to be interactive it should be deployed after the application has run and files are generated, whenever the user wants to view the reports. I decided to go with an applet based deployment, however I am not too happy with the current setup due to the following reasons:
I want to make the software as simple to use as possible (my users won't be tech-savvy, and even tech-intimidated in most cases). I would really like to distribute one JAR only, which forced me to put the applet with everything else it needs in a package in the same JAR as the main application.
The applet and the main application need to communicate the results, so I create a xML-based report which is used to hold information. As long as the files are on a local machine and are not moved around it all works fine. Unfortunately I also need the files to be moved around. A user should be able to take the "results" folder to a USB stick, go anywhere plug the stick to another computer and be able to use the report as he/she likes.
For the time being the applets are implemented with the following html code:
<applet code="package.myapp.visualization.GraphApplet.class"
codebase="file:/home/user/myApp"
archive="myApp-0.2.6-r28.jar"
width="750" height="750">
<param name=input value="results/test_name/results.fxml">
</applet>
As you can see this applet will not work if the parent folder is moved to another location.
As far as I know I have a couple of alternatives:
a) Change codebase to point to an URL on our webserver where I could put the jar file. This however creates the problem with permissions, as the applet will not be able to read the results file. Alternative is to upload the results file to the server when the user wants to visualize the graph, although I am not sure if that's a good option due to server security and also if it could be made so that upload happens automatically without bothering the user.
b) I can use a relative path on the codebase attribute, but then the whole folder hierarchy needs to be intact upon copy. This could be a last resort, if I cant come up with a better way to do it.
c) change the deployment method (would like to avoid this alternative to not spend more time on the development phase)
Any ideas? Am I missing something? How could I tackle this problem?
Thanks,
I'm not sure I entirely understand your use-case, but from what I do understand, I would suggest this:
Dump the applet for an application launched using Java Web Start. Have the JNLP file declare a file association for the fxml file type. When the user double clicks an fxml file, it will be passed as an argument to the main(String[]) of the JWS application.
A sand-boxed JWS application can gain access to resources on the local file system using the JNLP API. Here is my demo. of the JNLP API file services.
Okay I have a folder say... http://oldserver.net/file/index.jar
How would I be able to protect the file "index.jar" from being downloaded from regular web browsers?
I've seen this done before, I just want to protect it from being accessed from web browsers, and keep it strictly java download access only.
What I mean by java download access only is, I could simply use a java downloader to download index.jar. But I can't download it via web browser.
How would I protect the file "index.jar" ?
Thanks:)
You need to think about what this requirement means specifically - from the point of view of your server, how can it tell whether an incoming request is a "java download" or not?
In short, I don't think there's a way to do exactly what you're after. The classic way to secure resources would be by requiring authentication (i.e. you need a valid username and password to get the index.jar file) but it doesn't sound like that's what you want here.
Bear in mind that Java simply sends HTTP requests (or other protocols that it knows how to speak) down a connection. Any other program could send identical requests, so there's quite simply no way to enforce this limit in the way that you've specified.
One approach that might simulate what you're after is to not have the index.jar accessible via HTTP, so browsers wouldn't be able to get at it by default, and then access it via another protocol in Java (e.g. FTP, SFTP, whatever). Though as mentioned above, any tool that can speak this new protocol would be able to download the file.
Another approach would be to look for Java-specific headers, such as the User-Agent field (assuming this is populated with something recognisable). But again - this is not secure, as any tool could send through the same headers and impersonate a java download.
If you mean in your question that you only want your files to be downloaded by a specific Java application, then things get a bit more feasible. You can distribute an application that contains some authentication (e.g. public/private key pair) and have the server challenge for this when index.jar is requested. But even then this is dubious - by definition the Java app has to contain sufficient information to authenticate as itself; and by definition you have to distribute this information publically; so it wouldn't be difficult to extract the private keys and have some other application masquerade as your Java one.
Basically, I can't see any way around this issue given the confines you've stated. If there's a narrower scope you'd be willing to entertain you may be able to come up with a viable compromise, but right now the answer is simply "no".
Technically, you can't. Whatever request HTTP Java makes, another HTTP client program can be made that makes the same.
However, you can make it slightly more difficult. You can put the file behind HTTP digest authentication and include the password in the JAR of the Java program the password or can check the user agent server-side.
See e.g. get_browser() and Apache 2 authorization and authentication.
You can make your file read only so that no one can modify actual file but there comes a problem that even java cant modify the file.
So if you need to modify the file,you need to make a new file of same extension and copy entire data from main file to new file and delete the main file and modify the new file and change the name of new file to old file name.
There is a function in java to set read only:
File newTempFile=new File("mytext.txt");
newTempFile.setReadOnly();
You could create a web application that serves your file. Here you could check for the user agent string in the request and decide on that user agent string whether to serve the file or not. For this to work, your "java downloader" must have an identifiable user agent string and your application must "know" it.
Of course any bad guy who knows this, could make his browser send you the same user agent string, so this in not really secure :-/
If your index.jar is very important, do not make it available for download in any of the methods mentioned. As soon as it is available for download and ends up on the client computer, inside java or not, it will be hacked.
Some code should only run on the server.