December 2018
« Sep    
Your widget title

Posts Tagged ‘WAR’

PostHeaderIcon WebLogic: set a System property within a WAR


You would like to set a System property within an application packaged as a WAR.
Of course, you may modify the launching scripts of your servers, to add an option -DmyPropertyName=myPropertyValue. Sometimes, you would like to avoid such a solution, because updating the property would require an update of the setEnv.* files and therefore a action of the exploitation team.

In my case, I had to set the property tangosol.coherence.cacheconfig, which hints at the configuration file used my Oracle Coherence / Coherence*Web


The first solution is to set the property in a startup class. For more detials, consult this page: WebLogic: use a startup and/or a shutdown class in a WAR.

Another mean to handle this problematic is to create a servlet, with a code similar to:

public class JonathanBootServlet extends HttpServlet {
    private static final Logger LOGGER = Logger.getLogger(JonathanBootServlet.class);
    private static final String SVN_ID = "$Id$";

    public JonathanBootServlet() {
        if (LOGGER.isDebugEnabled()){

    public void init(ServletConfig config) throws ServletException {
        if (LOGGER.isDebugEnabled()){
            LOGGER.debug("in init()");
        System.setProperty("tangosol.coherence.cacheconfig", "jonathan-tangosol-coherence.xml");

Then add the following block in your web.xml:


Ensure this servlet is run before all others (1).

PostHeaderIcon WebLogic: use a startup and/or a shutdown class in a WAR


WebLogic offers you to specify a startup and/or a shutdown class for an application. Anyway, this feature is restrained to EARs, and is not available for applications deployed as WARs. For EARs, Oracle WebLogic Server’s documentation is complete and gives basic examples: Programming Application Life Cycle Events

Yet, sometimes you need such a class even for a WebApp. You have two ways to handle this case.


Full Weblogic!


The first solution is not elegant. Open WebLogic console, go to Startup And Shutdown Classes, then add the classes names of which main() methods will be run on startup and shutdown, let’s say JonathanWeblogicStartup. These classes must be available in WebLogic classpath, which is surely different from your application classpath, eg in a library $DOMAIN_HOME/lib/customized-weblogic.jar.
Advantage of this means: if your startup/shutdown class does not evoluate often, then write it once and forget, it will be OK. Unlike, you will have to manage different versions of the JAR on each release… I assume your exploitation team may get angry at playing with classpaths and lib folders 😀


To improve the basic solution (and avoid your exploitation guy burst in your office), I had the following idea, that I did not experiment, but that should work:

  • Keep JonathanWeblogicStartup
  • Create another class JonathanConcreteStartup, locate as a source in your application code.
  • In JonathanStartup.main(), call JonathanConcreteStartup

This way,

  1. You keep a unique JAR in classpath that you do not need to update and you can forget.
  2. You can add, update or remove features in your very source code.
  3. The exploitation teams does not become hateful at you.

Add a Listener

The second one requires a bit more work.

  • Create a class implementing javax.servlet.ServletContextListener interface, let’s say MyLifecycleListener.
  • Implement methods contextInitialized() and contextDestroyed().
  • Edit your web.xml, add the following block:
  • Rebuild and deploy. It should be OK