0

An application I maintain uses a third-party commercial EJB implementation. I do not have the ability to change the source code, but I can read it.

I have determined that the source code of the EJB is setting a specific implementation of javax.xml.parsers.DocumentBuilderFactory using:

System.setProperty("javax.xml.parsers.DocumentBuilderFactory", 
    "org.apache.xerces.jaxp.DocumentBuilderFactoryImpl");

I would like to prevent this -- but from a WAR file.

My EAR is:

EAR
  application.xml
  weblogic-application.xml
  3rd-party-ejb.jar
  my-web-app.war

There is the Detecting System.setProperty method invocations question about implementing a custom java.lang.SecurityManager which I am looking into now, but I don't still understand how the WAR file can influence the 3rd-party-ejb.jar behavior.

What's the proper solution?

Community
  • 1
  • 1
Brian
  • 13,412
  • 10
  • 56
  • 82
  • The EJB code in question - is it executed in a business method? – rdcrng Mar 17 '13 at 12:29
  • @rdcrng - No it isn't. It appears to be part of some initialization code (it's inside an init() method for what appears to be a POJO (Plain Old Java Object). – Brian Mar 18 '13 at 13:20
  • That's unfortunate. I was thinking that another solution could have been an interceptor for that particular business method that would just undo the setting. Of course, it wouldn't be a perfect solution, but depending on how the app is set up could have gotten the job done. – rdcrng Mar 18 '13 at 13:28

1 Answers1

1

Take a look at this SO answer. I believe it describes a very easy solution to your problem.

Update: In order to address the comment.

So, as in the link above, you implement your own Properties and replace the system properties with it. Here's how I would implement it in order to prevent changing the following

System.setProperty("javax.xml.parsers.DocumentBuilderFactory", "org.apache.xerces.jaxp.DocumentBuilderFactoryImpl");

from having any effect:

public class MyProperties extends Properties {

    public MyProperties(Properties properties) {
        super(properties);
    }

    @Override
    public Object setProperty(String key, String value) {
        if ("javax.xml.parsers.DocumentBuilderFactory".equals(key) && "org.apache.xerces.jaxp.DocumentBuilderFactoryImpl".equals(value)) {
            return null;
        } else {
            return super.setProperty(key, value);
        }
    }
}

Then just make sure that you run (say in a servlet life cycle listener):

MyProperties newProps = new MyProperties(System.getProperties());
System.setProperties(newProps);

before the code you're trying to prevent from having an effect gets a chance to run.

Paweł Chorążyk
  • 3,584
  • 3
  • 27
  • 33
rdcrng
  • 3,415
  • 2
  • 18
  • 36
  • I don't think it answers the question - the other question you link to refer to "How to detect if a Java System property has changed?" not "How to prevent a Java system property change? – Jacek Laskowski Mar 16 '13 at 20:51
  • @JacekLaskowski See my edit please. Wouldn't that solve the problem? – rdcrng Mar 16 '13 at 21:35
  • That's however not a proper answer - it's a workaround and should not be used in an application server as it pollutes its runtime environment with the application's specific classes. Hint: what happens when there're many threads? or what happens when your application gets undeployed? What (class) will handle system properties? I think it's now even worse. – Jacek Laskowski Mar 17 '13 at 06:22
  • @JacekLaskowski Properness is in the eye of the beholder and to me a question that asks for a proper answer calls for speculation. Btw, setting a custom security manager isn't any better. Same questions you ask apply in that case as well. That leads me to think that you'd have to mess with the app server anyhow and it's probably better to implement either of the proposed solutions in the app server space rather than the deployment space. – rdcrng Mar 17 '13 at 12:24
  • 1
    you'll have to configure an application server for a given enterprise application so the configuration won't affect other EARs. With the answer/suggestion of yours, it affects everything on the JVM. I'm working on a solution. – Jacek Laskowski Mar 17 '13 at 21:03
  • Thanks for the dialog on this; much appreciated. I have been playing with various entries in weblogic-application.xml but without success yet. https://forums.oracle.com/forums/thread.jspa?threadID=1032294 YourParserFactory weblogic.xml.jaxp.WebLogicDocumentBuilderFactory YourTransformerFactory – Brian Mar 18 '13 at 13:24