6

I am trying to pass a JVM parameter for a variable configured in web.xml as a context-parameter using a -D notation when starting weblogic server. I have already tried this same configuration using Tomcat 7 and it works as expected, but it DOES NOT work in weblogic server 10.3.3. Any clues?

web.xml

<?xml version="1.0" encoding="UTF-8" ?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
id="WebApp_ID" version="2.5">
    <display-name>testeParWebXml</display-name>
    <context-param>
        <description>Habilita ou desabilita a configuração de debug do Facelets! Página de debug do Seam.</description>
        <param-name>facelets.DEVELOPMENT</param-name>
        <param-value>${habilitar.debug}</param-value>
    </context-param>
<welcome-file-list>

Then when starting the jvm I pass the parameter using: 

-Dhabilitar.debug=true

And I built a Servlet to test: 

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        PrintWriter pw = response.getWriter();
        String valorParametro = getServletContext().getInitParameter("facelets.DEVELOPMENT");
        pw.write("Param value from web.xml ==>> " + valorParametro);
}

As I mentioned using Tomcat if I change the value to false or true in the -Dhabilitar.debug flag it correctly prints the value in the servlet.

Param value from web.xml ==>>  true

In weblogic I get the output like:

Param value from web.xml ==>>  ${habilitar.debug}

As noticed weblogic DOES NOT parse the value of the variable set in web.xml.

Is it possible to make this work properly in weblogic 10.3.3?

Chuck
  • 998
  • 8
  • 17
  • 30
groo
  • 4,213
  • 6
  • 45
  • 69

2 Answers2

3

Looks like there is not a consistent behavior across different containers. IMHO you should not do it that way. I have always used (and have always seen people using) web.xml containing default values (rather than parameterized values) for stuff. Please see these additional resources (including some not-so-elegant but working approaches to your problem):

Community
  • 1
  • 1
Viccari
  • 9,029
  • 4
  • 43
  • 77
  • 1
    Hi, unfortunatelly that is not an option for the environment I work at. I already knew that approaches but none of this satisfies our requirenment which is to enable and disable the seam debug pages without any package modifications. The inconsistence between containers is what causes more problems as pple stuck to the one where it works(in this case tomcat) and want the same feature in weblogic for production environment. – groo Nov 01 '11 at 16:28
  • Yeah, I've already been a victim of container inconsistencies too. :) Good luck trying to solve your problem. – Viccari Nov 14 '11 at 16:08
0

First attempt: I believe that filtering crucial files such as web.xml is not a good practice. However you can use ant or maven to do that.

===

Second attempt: Ok If identical packages are mandatory, I would prefer changing doPost method. Instead of passing the value to there, it could be passed key and set by System.getProperty method at there. And also setting a default value such as development environment makes sense.

Cemo
  • 5,370
  • 10
  • 50
  • 82
  • Hi, first of all, thanks for your response. You are correct when you say it is not a good practice, but in this case it is a requirenment as using ant or maven will actually involve generating more than one package for Development and production environments, and is not an acceptable option in this specific case. I have discussed this in Oracle forums as well and the final answer is that this is not a specifiction request and weblogic DOES NOT support this approach. So I will assume that there is no correct answer for this question. Regards. – groo Nov 08 '11 at 13:44
  • Thank you for helping. Unfortunatelly my problem does not seem to have a direct solution. It envolves using differente approach what is not an option for me in this specific case. – groo Nov 09 '11 at 15:46