Is it okay to place an oracle driver jar within the web application's /lib directory, or is it better practice to place it in tomcat's lib directory?
I'm wondering about this because on my local host, my web app runs fine with the jar in the web app's /lib directory, but when I move the web app to a real development server, I continue to receive null pointer exceptions when trying to close a connection pool object. I thought this issue may be why I'm unable to free the connection.
Thanks.
To answer the initial question, about placement of the .jar file, there are some things to consider:
Are there other apps on the same server that use this? If yes, and you want to ensure all of them use the same version, the placing on the server/lib folder would be better
If you want some flexibility in terms of what version of the .jar each app uses, then webapp/lib is better
If you are packaging your app as an ear or war, and there are size considerations, then the server/lib option has some advantages, given it makes sense considering the two points above.
If you run into classloader issues from dependencies, you may have to consider other jars when deciding on placement.
Whatever you decide, its best to make sure each jar exists only once in each apps classpath.
Related
I have created a GWT project which is successfully using an external jar file (see GWT - Using external jars / Java Projects by Lars Vogel‎ and Adding external jar in GWT).
When I use a library file like this, what happens when I compile the project and upload it to AppEngine? Does the jar file get uploaded as it is, or does it get compiled into something else first? And if the former, is it at any security risk of being downloaded without my control?
Let's drop the "google-app-engine" part, it doesn't matter here. You use the library in GWT, on client side. App Engine is server side, with no direct connection to GWT (but due to the volume restrictions it is quite useful to utilize some client side execution like GWT).
Everything you use in GWT will be compiled to JavaScript, transferred to the client and executed there. Obviously you have no control over the result and what the client does with it.
But it will be next to unreadable. Plus the client does not get the JAR per se and he does not get everything that is inside the JAR.
So what really matters is if the library's license allows this and if there are secrets in the library code that are only intended to be used on server side.
Actually, his's answer is not quite correct. The "google-app-engine"-part matters a lot here. Technically, GWT compiles and obfuscates all of the Java code it needs. And it strips out everything that it doesn't need. So, from the JavaScript generated by GWT, it should indeed be quite impossible to reconstruct or maybe even recognize the library. But it turns out that if you use the Eclipse plugin to deploy your app, appcfg uploads all sorts of random stuff to the AppEngine servers, sometimes including the entire Java source of the project (client side code included).
To see what exactly it uploads when you do a deploy, check in your system's temp-directory while the upload is running. You will find an AppEngine staging directory there that contains everything to be sent.
For suggestions for ways around this, you can refer to the answers to a question that I asked earlier: Removing unwanted uploads from AppEngine deployment
What I haven't checked is whether all the unwanted uploaded files end up in directories that are actually directly accessible from the internet.
My Java JSP application requires to store permanent files on the Tomcat web server. At the moment I save the files in the "/temp" folder of the System. But this folder gets cleared from time to time. Further, the current solution is hard-coded which makes it less flexible (e.g. when moving to another server).
I would like to now if there is a best practice for defining and accessing a permanent directory in this configuration. In detail, where is the best place to define the app file directory, and how would I access this from within my java application? The goal of this setup would be to cause the least effort when (a) updating the application (i.e. placing a new war file), and (b) moving from one server to another and OS (e.g. Unix, Windows, MacOS).
The research I have done on this topic so far revealed that the following would be solutions (possibly amongst others):
1.) Use of a custom subdirectory in the Tomcat installation directory.
What happens to the files if I deploy a new version on the tomcat via
war file?
Where do I define this directory to be accessed from
within my Java application?
2.) In a separate directory in the file system.
Which are good locations or ways to get the locations without knowing
the system?
Where do I define this directory to be accessed from
within my Java application?
Thank you for your advice!
Essentially, you are creating 'a database' in the form of some files. In the world of Java EE and servlet containers, the only really general approach to this is to configure such a resource via JNDI. Tomcat and other containers have no concept of 'a place for persistent storage for webapps'. If a webapp needs persistent storage, it needs to be configured via JNDI, or -D, or something you tell it by posting something to it. There's no convention or standard practice you can borrow.
You can pick file system pathname by convention and document that convention (e.g. /var/something on Linux, something similar on Windows). But you won't necessarily be aligned with what anyone else is doing.
can any one tell me if I could deploy an IPad application with its pre-initialized database?
I'm using IOS developer Enterprise program account
Include the database as a resource in the bundle and clone it into the users document folder at launch.
The reason to clone is that you dont get write privileges on bundle resources.
Alternatively since this is not code you could download it from the corporate server at launch but since you are asking this question you probably dont want to do that.
Yes you can do it.
You can use sqlite in your ios application. You can create locally an prefilled sqlite database, and at this one to your xcode project.
In your project you must copy the sqlitedatabase from your resourcesfolder to the app's documents folder.
Depends on who's the developer of the app. If it's you, you can easily do so. Else, you won't be able (since apps are stored in a security sandbox).
If you really need to, you could consider jailbreaking them (you won't need a Enterprise Program though) so you can enter those sandboxes and add custom property lists to them.
I'm configuring an installer for our product which, up until now, was distributed as a war file, usually on tomcat. Once tomcat has exploded the directory, the user has to open a properties file and set their database connection information. I'd like the installer to do this (we're using install4j) but there doesn't seem to be a built-in way to modify a text file inside a war file. I could just have the installer deploy the app as an exploded directory, which would save me the trouble here, but what do I lose by deploying like that instead of deploying the war?
It might work better to set up the database connection as a JNDI Datasource, rather than hand-editing a properties file inside the webapp/ directory. This is especially important if you want to allow users to re-deploy the application from the .WAR archive without overwriting their local configuration changes.
Of course, the JNDI setup isn't going to be trivially accomplished through the installer, either, since the mechanism used varies from app server to app server. However, any competent Java application server administrator should know how to configure a named datasource. Furthermore, by delegating responsibility to the app server, you allow your users to take advantage of connection pooling, clustering, and any other features provided by the datasource implementation bundled with their application server of choice.
Not much I would think - perhaps a bit of disk space, but if that's not a problem you'd be fine. Have you thought of having the installer generate the properties file and using a ZIP library (.WAR is really a .ZIP - rename it to a .ZIP and see what you get :) ) to replace or add it in?
Here's my requirement:
1. I want my installable to have a custom license agreement
2. run another package as part of the installation
3. let the user have an option of running the app on start-up
What should I use, create a dmg or use PackageMaker available with xcode? Are there any good web pages showing how to use PackageMaker?
Thanks.
They serve different purposes:
DMG (disk images) is just a container file format to solve age-old issues with multi-fork files and transfer protocols and intermediate hosts that can't handle them, by not relying on them in the first place. In addition, the disk images can use internal compression. Your users will thank you for not confusing them with file wrapped in file wrapped in file (although disk images themselves take some explaining initially).
PackageMaker is a full-fledged installer package builder. You can customize the installation process and locations, do sub-installations and pretty much anything else you could possibly need. If your installation entails more than just dragging and dropping an application bundle into place, this is the one to go with.
From your requirements, the choice seems obvious. Since an installer package is itself a bundle, I'd say: create an installer package with PackageMaker and put it in a compressed disk image. Distribute the disk image to your users. It just provides a nicer experience.