I am working on a java web start application which needs to log some statements.
The clients running this app can be running on windows,mac or linux.
I am planning to use log4j for my logging utilities and each log file to be named as , meaning each run of the app should create a new log file.
As there is nothing actually getting installed, i am not sure which directory should i store these files to, as these need to be persisted for future debugging. Also, then the question arises as to find how to find out the directory structure of the client machine.
Could someone please suggest on these?
First of all you need to get access to the local machine. You can sign your application and require full access, or you can use the web start facilities to get access to various services including file access. See the web start documentation for details.
Then you need to determine where to put your log files.
A good place to start is the user.home system property which usually points to the home direcotry of the active user, so if you can use a convention like ".yourapp/debug.log" you can put it there.
More than that require deeper knowledge of the target machine.
Related
My problem is that after every code change I have to build and deploy my Java web application (or at least some parts of it), which takes too much time.
JRebel would do the trick, but my company doesn't have a license for it.
I heard that weblogic's nostage mode can save some time, but how can I configure it?
I've changed my Managed Server's staging mode in the Admin Console, but how can I provide the path to my .wars? Or how can I get this thing work?
Sorry for my lack of knowledge, but I'm pretty new to this topic.
You now configured the default staging mode for new deployments, it would probably be easier to just change this during the individual deployments. If you are using the admin console to deploy it is the section called "Source accessibility".
Basically, in nostage / "I will make the deployment accessible" you tell WebLogic where to find your deployment by passing it a file location - which should be accessible for every targeted server. In the default staging mode (aptly called "stage"), you tell the admin server where to find the files and the admin server copies your files to the managed servers.
Unless your limits are in your bandwidth, I don't think this will save you any time during deployments.
I have a java codebase in form a war hosted on Apache tomcat server(Production server). Now let us say i make changes in my class and i want the same to reflect on my hosted codebase. Do i have to re-start the server every time after updating the class, or is there some better way to do it
You can use auto-deploy feature of tomcat. Read the documentation here.
If it is a development testing server, you can enable debugging, and reload your changed classes without having to restart the server or redeploying your webapp.
You can enable debugging by setting the following and restarting tomcat. (you can use a desired port):
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8787
In your IDE, create a debug configuration specifying server ip and the debug port you specified.
After connecting debugger, your IDE will usually prompt you to reload changed classes whenever you compile a class.
There is also a menu item also if you want to manually reload changed classes. Once you reload classes, your changes will be immediately effective.
We have a Java web application running on JBoss and Linux. Production environment database connection parameters come from a configuration file that only exists on the production environment app servers. That config file is only readable by the user ID that also runs the application, (let's call that user appuser) and the only people who can log into production environment servers and sudo to appuser are members of our Operations team. The production environment itself is firewalled off from all other environments.
We would like to make this more secure. Specifically we would like to prevent the operations team from reading the database connection password and other keys that are currently in the configuration file.
Another factor to keep in mind is that the operations team is responsible for building and deploying the application.
What are our options? The solution needs to support manually restarting the application as well as automatically starting the application if the OS reboots.
Update
The solution I am investigating now (tip to Adamski for his suggestion, which roughly translates into step 1):
Write a wrapper executable that is setuid to a user that starts/stops the applications and owns the configuration files and everything in the JBoss directory tree.
Use jarsigner to sign the WAR after it is built. The building of the WAR will be done by development. The setuid wrapper will verify the signature, validating that the WAR has not been tampered with.
Change the deployment process to only deploy the signed WAR. The setuid wrapper can also move the WAR into place in the JBoss deploy directory.
Why not just create a second user for the Operations team to sudo to, which only has a subset of file permissions compared with your application's user ID?
No code changes necessary; nice and simple.
You might find it interesting to see how the Jetty folks have approached this problem:
http://wiki.eclipse.org/Jetty/Howto/Secure_Passwords
This at least ensures that you cannot just read the password directly but need to some serious effort to get a humanly readable version.
If the Jetty license is compatible with what you want to do, you can just lift their code.
The easy way is to use Unix permissions to control who can read these files. However, sensitive data like passwords should never be stored in plain. There are a few alternatives. They require some effort but, that's an approach followed by most commercial products.
Store the passwords encrypted on file system. You can use either Java cryptography or XML encryption to do so.
OR
Store sensitive information such as passwords in a database along with other configuration details and encrypt it using database tools. You will still need to store database password somewhere on the file system. Oracle provides a wallet to store the password. There are some third party wallets as well that can do this, if your database vendor does not provide one.
My application, when running on Tomcat, is not able to connect to my database when deployed as a .war in the webapps folder, but it can connect when I am running it through Eclipse directly. The code is exactly the same in both cases. In addition, other apps in the webapps folder, which originally could connect to the database, can no longer do so. The jdbc code is correct as I have tested it with offline applications or when running it through eclipse, but not when I access it on, say, Chrome, using localhost. What has happened to my tomcat server?
Note: the JDBC driver is the MS Access one.
The code is exactly the same in both cases.
No it's not; if it were exactly the same you'd be connecting properly.
but it can connect when I am running it through Eclipse directly
Does this mean that you have a main method that drives the code that connects properly? The way you do it is usually different from a web app - you know that, right?
If you could post an exception or log message it would help a great deal.
I'm guessing it could be any one of the following; guessing is necessary because you haven't provided enough information for a solid answer:
The JDBC driver JAR is not available when you run under one configuration; you'll see a ClassNotFoundException in that case.
You haven't configured a JNDI data source properly in Tomcat.
You didn't put the JDBC driver JAR in the Tomcat /lib directory.
Could be other possibilities.
UPDATE:
Since you're using Access, and providing no other information, I'm guessing that you're using a relative file path to get to the Access .mdb file. Your command line app that runs successfully in Eclipse works because you give a relative file path that is correct relative to the project root. When you deploy to Tomcat, that relative path is no longer correct, so your application can't find the database anymore.
Sounds like you aren't printing the stack trace for errors, so you're losing out on information that might help you figure this out.
Microsoft Access is not a multi-user database. A web based application running on Tomcat is certainly multi-threaded. You should not be using Access for a web application. I'd consider switching to another database.
First, you need to verify the path to your database file. In fact, I believe it has to be an absolute path for tomcat to work correctly. The simplest thing to do is to put your database file in C:\data or similar and then hard code the path in your code. Of course, the file will be outside of your war and thus not portable (i.e., deployable to a remote server).
Second, you do need to make sure that the JDBC driver is available. If you use Class.forName in your code to load the driver, you will only need to make sure that the jar containing the driver is in the tomcat classpath (which would include the lib directory of your webapp). If you use the -Djdbc.drivers JVM flag approach, you will need to add it to the tomcat startup scripts.
For a typical J2EE web application, the datasource connection settings are stored as part of the application server configuration.
Is there a way to version control these configuration details? I want more control on the datasource and other application server config changes.
What is the standard practice for doing this?
Tracking configuration changes to your application server through version control is a good thing to ask for. However, It does imply that all changes are done via scripting, instead of the administrative web interface. I recommend
http://www.ibm.com/developerworks/java/library/j-ap01139/index.html?ca=drs-
as a good background information article on this topic.
Update: Just recently, part 2 has been published here: http://www.ibm.com/developerworks/java/library/j-ap02109/index.html?ca=drs-
When working with WebSphere we found the best approach was to script the deployment and place the script under version control plus the response files for each of the target environments.
Websphere canbe tricky as the directory structure is a mess of files - often there appears to be duplicates and it's hard to figure which is the magic file you need to backup / restore . The question of how to go about this should not detract from the need to do it. - which is a definite yes.
Our (Spring) apps have a hardcoded jndi name in the spring config file. That way, the same ear can be deployed to dev, qa and prod environments, and you don't have to worry about database connection details.
The app server admins ensure that a datasource is registered against that jndi name, with the connection details as appropriate on each environment.
But how does this let me manage changes to datasource configurations in the application servers. Here's a scenario:
DBAs change the connection password of the database server.
Webspehere/Weblogic administrator makes corresponding changes to server configuration through administrator console.
The above change is not version controlled so there is no clean way of knowing the history of such changes.
The problem is not about how the application should be configured but about how the configuration changes should be version controlled. Perhaps it sounds like an overkill for simple projects but for some projects, controlling changes like these really becomes a problem.
Any time you ask yourself "should X be in version control" the default answer is "yes".
For a more refined answer, ask yourself this: is the file created by a person (like a source file or a document) or is it generated by another program (like an object file or a distribution PDF)?
File that are created, and/or maintained, by a human should be under configuration control.
We are always using version control for our app server settings. It's a tool called WLST (weblogic scripting tool) which is part of the weblogic server distribution. The domain configuration is stored within a Jython script, which can easily be executed via command line and therefore integrates superb with our build tool maven.
Creating a preconfigured running weblogic domain only needs to execute a maven goal. All those annoying problems of misconfigured jdbc connections or wrong jms destination parameters are gone. You will always have a appserver configuration which matches the source code at a given time. You will never need to remember which app server setting must be applied for this specific version of the project you are working on.
I really recommend this.
I also would like to know, if there are similar solutions for other application server available. As far as i know there is a way for glassfish via ant. How this can be achieved for JBoss?