I'm working on a beta release of an application. This is a Java app that runs on Glassfish. Obviously we are getting bug reports from time to time. I would like to provide my users with a simple one-click button to get the server log from /domains/domain1/logs . I am not sure if the application is sandboxed in such a way that it can get to this log file.
Does glassfish sandbox the application in such a way that I would be prevented from getting the file? Is there a standard method or library I can use to get the logs?
If the file permissions on the server are correct, can I just have my application read the file using an absolute path?
You application can read the server.log file directly. Note that the logs are rotated, so your application would have to reload the log file and maybe even provide access to the rotated logs.
If you are using a web server front end, such as Apache, you could just serve the log directory. I think you could just create a symbolic link to that directory in your webroot.
Be careful you are not logging any sensitive information as exposing a log file could be a security risk.
If you are using GlassFish 2.1, you should look at AMX. The AMX class Logging seems to have the data that you want.
If you are using GlassFish 3.1, you should use the RESTful interface to the admin data. If you have an instance of GlassFish 3.1 running locally, right now, you can click this link to see the log data: http://localhost:4848/management/domain/view-log...
If you are using a WebKit based
browser, like Chrome or Safari, you
probably need to view the source of
the 'empty' page....
If you are using GlassFish 3.0, you will need to open the file directly.
Related
Tomcat log location is :
/apache/apache-tomcat-8.0.15/logs
What is standard method of enabling access to these logs via browser ?
Is enabling Tomcat dir listing standard for this ?
I have seen similar setup done for one of the apps where I worked for an Australian telco whereby application logs are logged to a directory where Apache can serve them.
The pro is that it is really simple, just install Apache and most application developers are happy to download log files from their browser.
Just make sure the public does not access this directory.
The con being, if the log files are somewhat large that may take up quite a bit of bandwidth from your users.
I am using Weblogic Application server currently, i would like to know the type of files which definitely requires a restart to function as desired.
As part of enterprise application usage, i know for js and jsp it does not require restart. What else can be, please help me in knowing. Thanks.
All files flagged as resources: images, not dinamic web pages, CSS, javascripts, *.xsd etc.
All other files used by your enterprise application need a weblogic restart.
For example: you have some *.properties files read during the startup of the server to create a singleton. Those files, read ONLY during the startup, need a full weblogic restart in order to be refreshed by your E.Application.
Generally, all files read at the startup and maintained in the server memory, need a full restart of the server.
I wrote a RESTful web service using Jersey library and in order to respond to the request I have to read a text file in local file system. C:\data.txt. The servlet works fine when I run it with tomcat on my own laptop.
But when I deploy the war on another machine running windows server OS and place the data.txt again at C:\data.txt. The servlet can't locate the file correctly. Anyone has idea about why is this?
Thanks a lot!
Check whether the Tomcat server process has read-access rights to file C:\data.txt. Check which user is used for running the tomcat process and check the corresponding user file permissions.
I also suspect it is a security error. Applications are usually restricted to reading and writing within their own directory under $TOMCAT_HOME/webapps. If this is the case, you need to change $TOMCAT_HOME/conf/catalina.policy to allow you to access other directories.
If you don't need to write to the file, consider moving its location inside of the classpath by putting in into $TOMCAT_HOME/lib instead.
I think this approach is also better in regards to being cross-platform.
I have developed a simple application such as insertion, updation in jsp,servlet that is java web. What i want to do is: suppose i am inserting data into my oracle db then data is inserted and i got a message that data has been inserted successfully, same thing i want to show in a command prompt when my web app is running in tomcat server. Application will run in browser and simultaneously command prompt will show that :
this data is inserted into this table---transaction committed successfully----
How can i implement that? Any help is much appreciated
The vast majority of Java web applications use Log4j for logging.
To log messages to the server's console, use the Log4j ConsoleAppender class.
Normally you need to do little more than drop log4j.jar into your tomcat/lib directory, and configure logging with a log4j.xml or log4j.properties file, then have your servlets or jsps or controllers or services issue logging commands. There are many tutorials on the web that can get you started learning log4j with tomcat.
Oh and by the way, you can try plain old System.out.println() calls from a servlet, though this is only for learning. Professional applications should use a logger.
i am writing a standalone java app. the app's properties should be configurable from a webpage deployed with the app. how do i achieve this ?
Thanks in advance
note: the app has an embedded HTTP client/server module. it should only run from command prompt
I don't think that's a good idea. Webpage forms are designed to work with a server, not with a standalone client app. You could have the app run its own web server, but that would mean the app has to be running for the configuration page to work, and it's also a rather contrived setup just to do some configuration.
It might be possible for the webpage to contain JavaScript that writes to a local file - I don't know enough about the JavaScript security model to say.
But why not have the configuration dialog as part of the app's GUI? That's the normal and expected behaviour - you'd need a pretty compelling reason to deviate from it.
JMX might be the answer that you're looking for. If you expose all of your configurable properties through MBeans, then adding a web page on top of that exposing these properties is just configuration.
You can launch a standalone Java app using JNLP files (Java WebStart). If you want the user to be able to configure the application before its launched, you can have the JNLP file dynamically generated, then pass properties as environment variables through the JNLP file.
You can configure your standalone Java app to read configurable properties from a properties file (say conf.properties) on the server.
You may have a UI webpage (html/jsp) with all the field to be configured. When the page is submitted a JSP/Servlet may write/update the contents of conf.properties on the server.
UPDATE: The above solution will work assuming only an admin user wants to update the properties file.
In case anybody should be able to update it, then concurrency issue has to be taken into account.
In that scenario, you have to implement a mechanism similar to how weblogic10 updates config.xml using Admin Console.
i.e. You will have 2 conf.properties files confA & confB (initially in sync). The standalone app will always read from confB. The UI will have 2 buttons say Lock & Release configurations. When an edit is made (locked & released), it will be written to confA and at the same time changes of confA has to be replicated to confB.