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.
Related
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 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.
Where does the application logic run in a Java Web Start deployment? I want to understand the intellectual property security risk of Java Web Start. On the client end does it merely start the application on a server and then proceed to process pixels (GUI objects) and mouse clicks at the client? or is my application logic executing at the client?
Implicit in my question is the assumption that I place no value on any aspects of the design that can be inferred by looking at the GUI buttons, text output and by being an experienced user of the application. The value is in the code and logic.
Java Web Start downloads code to the client, and executes it there. The application logic will execute at the client.
Basically JWS keeps local .jar in sync with that on a server to execute an application in local mode. Read about JNLP here.
So the risk for reverse engineering is the same as with any jar packet Java app.
Basically Java Web Start downloads the latest jars (Application Logic) from the server when u launch it with the help of JNLP. and then it installs this application in temporary internet files or cache.
Your whole application logic(cache) exists in cache at client side. and then your jnlp file use them (jars)
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.
I have a Java web application designed to be deployed on the internet. It needs a database connection. Depending upon hosting environments it may not be possible for the deployers of the web application to configure appropriate data sources so the application needs to store it's database connection information somewhere to be reloaded if the application is restarted.
I also need to give one user administrator privilileges. If this is just the first user account created there is the small possibility that the admin account could be hijacked in between the time that the application is deployed and the time that the installer logs in.
I need to do both of these tasks securely and in a way that is lowest common denominator for a web application.
Clarification: Upon first use I want the application to set up an admin user. That admin user will have all security access in the system. Somehow I need to determine what that user is called and what their password will be. If the application gets deployed on a shared web host the application will be live from the moment it is deployed. If I allow the site to be configured through a web interface there is the small possibility that an unauthorised person will do the web configuration before the site owner effectively hijacking the site. I am looking for an elegant way to avoid this.
Ok, to answer your revised question...
There isn't really that much you can do. If you don't want the admin to configure their account during installation on the server, then there will always be a small window where someone else might create it via the web before they do.
All the solutions involve modifying something on the server (as this is how they prove they are the real admin). Yes, that can mean a config file...
Upon first connect, give the user a
token. Basically a hash of some
salt+theirIP+theirUserAgent, etc.
Then ask them to log into the server
and feed this token to your app,
probably in a config file. If the
generated token next time matches the
one in the config, allow them to
proceed.
A simpler solution is to let them put
their IP address in the config from
the start, and just allow this IP. (Assumes they know what their IP address is)
Alternatively, allow account
creation, but refuse to do anything
else until some file is removed from
the server. Many PHP apps do this
with an install.php, but the file
could be anything you test for.
The most common way to do this is through a static configuration file, in some simple text format.
The file resides on the same system as the application, and should be just as secure as the code (eg. if someone has access to modify the configuration who shouldn't be able to, couldn't they just as easily modify the code?)
For one of our Java web apps, we're using Spring dependency injection to configure most of the app. If you create a "Configuration" class with all of the configurable properties exposed, you can wire up a bean in Java that is configured via Spring XML context file. You can then create different versions of the XML file for your different environments, and have them automatically built into specific packages, which can be deployed all-at-once. If you want to go all-out, you can basically configure every single class in your application using Spring, which is really useful.
There's a little bit of overhead to get Spring setup, but it's actually not too hard, there are plenty of tutorials out there.