Announcement

**vvab** · 10 Feb 2016, 13:08

I did notice the setXIncludeAware call in com.isomorphic.xml.XML.parseXML is not present in the 10.0 older build. The jar in the newer build has this call in XML.java and other changes. Kindly suggest a course of action asap.

setXIncludeAware is being set to false which is false by default. I am not sure why such not so trivial changes were made in a new build of a release.

**Isomorphic** · 10 Feb 2016, 17:10

This change is a bugfix to prevent "Billion Laughs" attacks for vulnerable XML parsers. Disabling a unused feature on an XML parser is about the safest possible change that could be imagined.

If you want to blame someone for this regression, blame whatever parser you're using - what developer throws an exception because you tried to disable a feature that was already off???

We will add code to work around your parser by ignoring this exception. We'll let you know when this is done.

**vvab** · 11 Feb 2016, 10:49

Thanks. I did not doubt that there would have been a valid reason, and your response helps understand that.

Point is that "setXIncludeAware" was not introduced until a later version of jaxp spec - and if an older implementation (like used by our project) does not provide implementation then an exception was thrown by the jaxp spec. The exception is thrown by the jaxp spec api. Hence, introducing (within the same smartclient revision, but just a newer build) the use of a method that is not compatible across specs is probably not good.

Please also check any other methods/features of jaxp api which may have been introduced in a newer build of 10.0.

Same issue of course exists in smartclient 10.1. We would ideally like to use Smartclient 10.1 itself if it can continue to be compliant with smartclient 10.0 for XML processing, if that is possible.

Thanks again for response and I hope we can get a fix asap (and recommendation on using 10.0 vs 10.1), as this unanticipated problem is jeopardizing our schedule.

**Isomorphic** · 11 Feb 2016, 17:34

We've wrapped the call in try..catch so we can throw away the exception. This change will be available in tomorrow's nightly builds of all affected versions.

Yes, we know this is JAXP. No matter where the code or spec came from, it is poor coding to throw an exception because a developer attempted to turn off a feature that was already off. The method call is successful so no exception should be thrown.

As far as who else this might impact - could you confirm your version of JBoss was released 11 years ago and is at least 6 years past end of full support? When we read this we thought you might have typo'd your version.

**Isomorphic** · 11 Feb 2016, 17:39

As far as 10 vs 10.1, we always recommend using the latest available release version.

**vvab** · 12 Feb 2016, 07:48

Yes, we are on a older version of Jboss and gradually working on removing application server dependencies and migrating out of it Tomcat. Its a large code base.

Just to confirm,
-the latest 10.1 build is available now with the fix?
-to avoid us spending the effort to migrate and discover other issues - isomorphic has verified that there was no other code introduced that is introduced in later jaxp specs (post 1.3 version) and can interfere with older libs who that might be implementing older version of the spec.

Thanks.

**vvab** · 12 Feb 2016, 08:56

Downloaded the latest 10.1 build. We see the following ERROR now, again old vs newer jaxp spec style issue:

java.lang.AbstractMethodError: javax.xml.parsers.DocumentBuilderFactory.setFeature(Ljava/lang/String;Z)V
at com.isomorphic.xml.XML.parseXML(XML.java:190)
at com.isomorphic.xml.XML.parseRestrictedXML(XML.java:122)
at com.isomorphic.xml.XML.toDSRecords(XML.java:408)
at com.isomorphic.xml.XML.toDSRecords(XML.java:404)
at com.isomorphic.rpc.RPCManager.parseRequest(RPCManager.jav

Its probably better to catch the Throwable instead of just the Exception. I appreciate your attention to this far as this issue is a blocker for us and I hope this issue can be fixed soon.

Thanks,

**Isomorphic** · 12 Feb 2016, 16:00

While we will go ahead and switch to Throwable, please understand that running an 11 year old out-of-support versions of JBoss is also something we consider an unsupported configuration. So as far as other possible JAXP usage, for both JAXP and other standard Java APIs, we don't know whether our server framework might be using a 10 year old version of an API as opposed to the 11+ year old version you have in your JBoss configuration, because if an API is 10 years old we freely assume we can use it in current releases of our product.

Also note, if you are looking to get around this problem only (and not doing new development at this time) then there is no particular reason to use 10.1 instead of 10.0.

**Isomorphic** · 13 Feb 2016, 05:54

We've made the change to address this issue. Please try the next nightly build, dated February 14.

Regards
Isomorphic Software

**vvab** · 15 Feb 2016, 10:17

Thanks for making the change. Regarding 10.1 vs 10.0, we are doing active development primarily to upgrade to the latest Smartclient library that can be best compatible with IE11 and its subtle aspects (and we are also fixing any of our functionalities that are breaking after we upgrade to latest Smartclient). We are also already (as of previous releases) using Smartclient's AutoTest api to automate our code base, which may also benefit from the latest Smartclient version w.r.t ensuring elements are located reliably on IE11.

Would isomorphic still say that we should use 10.0, or 10.1?

**Isomorphic** · 15 Feb 2016, 21:45

For active development we always recommend the most recent release.

**vvab** · 9 Mar 2016, 08:23

Hello, as part of this fix seems like the exception is being eaten by the code but logged via a printstacktrace - which makes it by pass the log4j filters (or any other logging framework filters) and directly logged to System.out and to the root log4j appenders. This causes a significant issue as the "INFO" mode exception is logged every time a smartclient page is accessed. This causes unnecessary and redundant stack traces in our logs (which we use to monitor for ERRORS and EXCEPTIONS)

Any reason this cannot be just passed to log.debug (<message>,<exception>) instead of a printstacktrace? This will make it much more controllable via a logging framework

This is causing a critical issue for us.

**Isomorphic** · 9 Mar 2016, 14:20

The printStackTrace() calls have been removed. Please try the next nightly build, dated March 10.

Regards,
Isomorphic Software

**vvab** · 11 Mar 2016, 11:27

Thank you for the prompt response. Sanity back into our logs now.

Announcement

Smartclient 10.0 latest build issues vs older build

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment