In our tomcat application, we catch a CommunicationsException. There are various config parameters which can lead to this, including the database config being set wrong, but also the tomcat config have TOMCAT5_SECURITY=yes
When we catch the exception we want to give a helpful error message to the user. So we want to ask tomcat whether TOMCAT5_SECURITY is set, but we can't work out where in the API this is available.
So what tomcat API call will tell us whether TOMCAT5_SECURITY is enabled?
(The full exception is com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure).
The only TOMCAT5_SECURITY flag I know of is the one supplied in the Ubuntu package file /etc/default/tomcat5(.5). This is Ubuntu-specific, so I wouldn't expect it to be part of the Tomcat API. Note that the flag sets whether a security manager is used or not, so maybe you should be looking at that.
How about calling some method that must throw a SecurityException when security is enabled? You could cache the result, assuming the setting doesn't change at runtime.
Related
I am seeing the following exception in my production WebSphere 8 server log:
WASSession E MTMBuffWrapper getBytes write object exception.
e= java.io.NotSerializableException: org.apache.commons.logging.impl.Jdk14Logger
However the only logging package used in deployed application is java.util.logging.Logger.
I am not seeing any serialization exception in my local RAD server, only in production environment.
Any idea?
You don't see exceptions in RAD because you dont have persistence session enabled or PMI counter collecting the session size (which is probably set on the production).
Although you don't use org.apache.commons.logging.impl.Jdk14Logger in your code there is very high probability that some kind of third party framework that you use in your app is using it.
You have to check what objects you put in the session (search for all session.setAttribute() method calls). You must be putting some third party object into session which is using that logger.
Try to remove commons-logging-1.1.jar from your application, if you have one there.
WebSphere internally uses the commons-logging library, so the conflict rises. We faced a similar problem, also using IBM provided solutions like https://www.ibm.com/support/pages/javaionotserializableexception-thrown-websphere-application-server-community-edition-when-applications-are-stopped did not help. In our case use, the jcl-over-slf4j library solved the problem.
Again, many excellent answers from the fine folks here on SO. I am still unable to connect. But I believe Gimby might have had a good suggestion that there may be something wrong with the server or the beans. According to the log file generated when JBoss started, my beans have been deployed. The administrator of the server is unable to run the admin console for vulnerabilities reasons so there is no way to see if the beans are running. Is there a command line tool that I could point him to for testing? Is there a simple test I could write that would check the beans? I have tried most everything I have found and others have suggested and keep getting various errors. most times being:
javax.naming.CommunicationException: Could not obtain connection to any of these urls: remote://:4647
I've encountered other errors as I have made changes to various files and code but this one is the most frequent. If the call I make to the bean is right, and that is questionable, then how do I tell if the bean is even running or not>
There seems to be some uncleared situations here.
Still I want to ask you, if your bean got a remote interface.
You could use lookup to find your bean on this server.
You also could deploy for example a RESTservice on your jboss server, which look for your bean locally, so you dont have to specify any connection properties, but you would need the jndi name.
Hope this helps a bit, greets Jerome.
I would like that my Spring-based web application were able to validate its configuration during startup.
This means for example:
check if the required folders exist and are readable/writable
check if the required configuration keys are set and consistent
...
check any other constraint that is required for the correct functioning
How can you perform these checks and notify the system administrator if something is wrong?
The goal is to reduce the risk that some critical error arises when the application is actually going to need those resources that are bound to the wrong configuration.
NOTE: my approach is to use a special EnvironmentValidation bean that checks if the configuration/folder structure is ok and if not it throws an exception
If you want notifications you could set up an email notifier for example using log4j that would send any exceptions on startup to the system administrator.
if a configuration key is not present spring will not start up anyway.
check the keys are consistent with what?
checking folders exist and are readable/writable isn't something I'd really do in my webapp - this belongs in your deployment infrastructure. Saying that you could write your own custom checks as spring beans, load these first and throw an exception if some of your configuration fails validation.
During startup all errors will be logged in to server logs. Logs can be checked and system administrator can be notified.
I have a server I made in Java that needs to use a database, I chose HSQLDB.
So I have a lot of entries in my server like:
Logger.getLogger(getClass().getName()). severe or info ("Some important information");
When I run my server it goes to System.out which I think its the default configuration of java.util.logging?, so far its ok for me, and later I will make it go to a file ...
But, the problem is, when I start hsqldb it messes up with the default configuration and I can´t read my log entries on System.out anymore..
I already tried to change hsqldb.log_data=false, but it still messes up the default configuration.
Can someone help me??
I dont want to log hsqldb events, just my server ones.
Thanks
This issue was reported and fixed in the latest version 2.2.0 released today.
Basically, you set a system property hsqldb.reconfig_logging to the
string value false.
A system property is normally set with the -D option in the Java startup command for your application:
java -Dhsqldb.reconfig_logging=false ....
See below for details of the change:
http://sourceforge.net/tracker/?func=detail&aid=3195462&group_id=23316&atid=378131
In addition, when you use a fremework logger for your application, you should configure it directly to choose which levels of log to accept and which ones to ignore.
The hsqldb.applog setting does not affect framework logging and only controls the file log.
The hsqldb.log_data=false is for turning off internal data change logging and should not be used for normal databases. Its usage for bulk imports is explained in the Guide.
Try setting hsqldb.applog to 0, that shuts off application logging to the *.app.log file.
Start your server with a property pointing to the location of a dedicated properties file:
-Djava.util.logging.config.file=/location/of/your/hsqldblog.properties"
Which contains the following line to change Java logging for Hsqldb.
# Change hsqldb logging level
org.hsqldb.persist = WARNING
Side note, you can choose from the following levels:
SEVERE WARNING INFO CONFIG FINE FINER FINEST
My webapp is part of a larger EAR that is deployed into a websphere server. The server hosts number of other apps on the same virtual server. My webapp has some initialisation/health checks in a servletContextListener->contextInitialized method. I want to make the webapp unavailable if initialisation/health checks fail. What is a realiable way of doing this? Will throwing a RuntimeException from within contextInitialized suffice? Is the rest of the EAR still expected to be available? Thank you.
I'd recommend throwing a RuntimeException from ServletContextListener.contextInitialized.
Servlet 2.3 wasn't very clear on this, but Servlet 2.4 added the following detail:
Some exceptions do not occur under the
call stack of another component in the
application. An example of this is a
… ServletContextListener that
throws an unhandled exception during a
notification of servlet context
initialization…. In this case,
the Developer has no opportunity to
handle the exception. The container
may respond to all subsequent requests
to the Web application with an HTTP
status code 500 to indicate an
application error.
Since it says that the servlet engine "may" disable access to application, you might find a server that does something else. However, Tomcat and WebLogic both disable the application, and the only other reasonable thing I can think of would be to ignore the exception. I can't see a container that did that being very popular—so you'd better test it in WebSphere yourself.
Throwing a RuntimeException will probably make only that servlet unavailable. A safer way might be to implement something like a Spring interceptor that will forward to an error page or something if the checks didn't pan out. That way, you don't need to prevent the app from loading, but can handle it more gracefully at run time.