I'm having trouble getting xmlunit to ignore whitespace in my XML using setIgnoreWhitespace... any idea what could be wrong or what I could check?
JVM: 1.6, XMLUnit 1.3, IDE: JDeveloper 11.1.1.6
For example the below returns "Expected number of child nodes '2' but was '1'". If I take out the extra space it passes.
#Test
public void testExample() {
String inputXML = "<test><innertest>data</innertest></test>";
String expectedResultXml = "<test> <innertest>data</innertest></test>";
XMLUnit.setIgnoreWhitespace(true);
XMLUnit.setIgnoreComments(true);
XMLUnit.setIgnoreDiffBetweenTextAndCDATA(true);
try {
assertXMLEqual("Did not match!!", expectedResultXml, inputXML);
} catch(Exception e) {}
}
I must have some incompatible XML library in my classpath. Overriding the JAXP libs as below resolved the issue (also added xerces and xalan jars).
XMLUnit.setControlParser("org.apache.xerces.jaxp.DocumentBuilderFactoryImpl");
XMLUnit.setTestParser("org.apache.xerces.jaxp.DocumentBuilderFactoryImpl");
XMLUnit.setSAXParserFactory("org.apache.xerces.jaxp.SAXParserFactoryImpl");
XMLUnit.setTransformerFactory("org.apache.xalan.processor.TransformerFactoryImpl");
It looks a bit you expected that any whitespace characters is to be ignored but that is just not the case for that setting.
See XMLUnit.setIgnoreWhitespace:
Whether to ignore whitespace when comparing node values.
[...]
Setting this parameter has no effect on whitespace inside texts.
This setting does not mean that whitespace-only text-nodes will be removed (and not checked for). It will only mean that the whitespace is ignored when comparing the node values of the <test> elements. But that test didn't cause the message. In your case a check for the count of child-nodes did raise the message.
See 3.8.1. Whitespace Handling for a more detailed description and more configuration options (e.g. XMLUnit.setNormalizeWhitespace).
Overriding the JAXP libs as #user392909 did, did not succeed for me.
But a conflict with another library in my project was the root cause. First I changed the import order of some libraries which finally fixed the test. So I was able to identify the conflicting library. It was j2ee.jar.
I removed it (and had to replace it by tomcat-catalina.jar, tomcat-juli.jar and javamail.jar to resolve upcoming compilation errors).
The import order doesn't matter any longer since j2ee.jar was removed / replaced and the xml diff is now working as expected.
Related
I've been searching around all over the internet to no avail. I am attempting to use Guava to get all the classes in a package of mine, but it is not behaving as intended. It always returns an empty set, making it impossible to do anything with the given results. Could there be a problem with System Variables, or some other road-block?
Here is some of my code.
String packageName = "me.travja.package";
ImmutableSet<ClassPath.ClassInfo> root = null;
try {
System.out.println(ClassPath.from(getClass().getClassLoader()));
root = ClassPath.from(getClass().getClassLoader()).getTopLevelClasses();//.getTopLevelClassesRecursive(packageName);
} catch (IOException e) {
e.printStackTrace();
}
for (ClassPath.ClassInfo info : root) {
System.out.println(info.getPackageName() + " -- " + info.getSimpleName());
}
It never hits the last sout because it's empty, but the one that prints the classpath prints 'com.google.common.reflect.ClassPath#33571c14' which isn't super useful. But to my knowledge, shouldn't that resemble more of my application's directory?
Thank you for your help with this. It's been bugging me for too long.
EDIT: I did some digging around. It seems that it works as intended if my file path doesn't contain a Space. I read a little that this used to be a problem with Guava in older versions, but I even tried using Maven and shading the latest version of Guava. Is there any way to fix this, or do I just have to be cautious that my file path never has a space in it?
After doing some more digging, one of the other dependencies that I was using had shaded an older version of Guava and that is what my code was using. As a result, it was broken. I used a decompiler so I could manually shade the ClassPath class from a newer Guava into my own code, and imported that. Works flawlessly now.
I'm attempting to use an online timestamp authority (rfc3161) with the Digital Signature Service Java library. However, the following snippet (from their test cases, and similar to the one from their Cookbook):
String tspServer = "http://tsa.belgium.be/connect";
OnlineTSPSource otsp = new OnlineTSPSource(tspServer);
/* tried setting otsp.setDataLoader(new TimestampDataLoader());
too, as it defaults to otsp.setDataLoader(new
NativeHTTPDataLoader()); the exception happens in both cases */
byte[] digest = DSSUtils.digest(DigestAlgorithm.SHA1, "Hello world".getBytes());
TimeStampToken timeStampResponse =
otsp.getTimeStampResponse(DigestAlgorithm.SHA1, digest);
always ends with the following exception:
eu.europa.esig.dss.DSSException:
java.util.concurrent.ExecutionException: java.lang.NoSuchMethodError:
org.apache.commons.io.IOUtils.closeQuietly(Ljava/io/Closeable;)V
Already tried many different public rfc3161 servers (some listed here). Sure there's something wrong going on there, but, as a beginner, I cannot understand what is wrong (what method should be there).
If anyone could put me in the right direction to get the snippet working (or even be kind enough to comment a reliable startup guide on cades/xades/pades with Java's bouncycastle) I would be really grateful.
As stated in the comments by Marteen Bodewes and Mark Rotteveel, there was something wrong with the version of Apache Commons-IO in the classpath. The project is set using Apache Maven and there was an old Commons-IO version declared there as a dependency. In this case, it was enough to remove that declaration, so Maven could download the appropriate version that was declared as an esig/DSS dependency.
esig/DSS version was 5.4 at the time.
I am having the following problem:
I have an Enum that was originally declared with 5 elements.
public enum GraphFormat {
DOT,
GML,
PUML,
JSON,
NEO4J,
TEXT {
#Override
public String getFileExtension() {
return ".txt";
}
};
Now I need to add an additional element to it (NEO4J). When I run my code or try to debug it I am getting an exception because the value can't be found in the enum.
I am using IntelliJ as my IDE, and have cleaned the cache, force a rebuild, etc.. and nothing happens. When I look at the .class file created on my target folder, it also has the new element.
Any ideas on what could be causing this issue ?
I found my problem and want to share here what was causing it. My code was actually for a Maven plug-in which I was pointing to another project of mine to run it as a goal. However the pom.xml of my target test project was pointing to the original version of the plug-in instead of the one I am working on, and that version of course is outdated and does not include the new value. Thank you.
I am working with Collapsed dependencies using Stanford CoreNLP.
I am getting
cannot find Symbol. Symbol:method getEdgeSet()
error while typing the following code:
Set<SemanticGraphEdge> edge_set1 = dependencies.getEdgeSet();
No other errors are found. I have already imported
edu.stanford.nlp.semgraph.SemanticGraphEdge;
Why does it happen so?
The type of dependencies is SemanticGraph which doesn't have the method getEdgeSet().
In the first paragraph in the documentation you can see:
There is no mechanism for returning all edges at once (eg edgeSet()). This is intentional. Use edgeIterable() to iterate over the edges if necessary.
See getAllEdges(IndexedWord gov, IndexedWord dep) and edgeIterable() instead.
UPDATE: Made a posting on the Gradle forum. Please star this issue so that it gets more attention http://gsfn.us/t/4jedo
I'm in the process of transitioning from a primarily Ant build environment into a Gradle one. One sticking point is injecting Google Analytics and Adsense code into the JavaDoc. This is done by putting java script code into the header or bottom panels. For an example of what I'm currently doing, look at this question CDATA.
The problem with Gradle is that it can't handle newline characters in the string which is to be inserted. If you filter out those characters you break the script. Here is a code sniplet:
task alljavadoc(type: Javadoc) {
source = javadocProjects.collect { project(it).sourceSets.main.allJava }
classpath = files(javadocProjects.collect { project(it).sourceSets.main.compileClasspath })
destinationDir = file("${buildDir}/docs/javadoc")
configure(options) {
header = "this is\na test which should fail"
}
}
The critical part is "header =". If you remove the '\n' character it will work just fine. Otherwise the call to javadoc, which Gradle makes, will fail with the following error:
Successfully started process 'command '/opt/jdk/jdk1.7.0_21/bin/javadoc''
javadoc: error - Illegal package name: ""
javadoc: warning - No source files for package a
javadoc: warning - No source files for package test
javadoc: warning - No source files for package which
javadoc: warning - No source files for package should
javadoc: warning - No source files for package fail
The actual java script that I wish to include is below. Note that I can't hack it by removing new line characters since that will break the script.
<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<!-- banner -->
<ins class="adsbygoogle"
style="display:inline-block;width:468px;height:60px"
data-ad-client="ca-pub-xxxxxxxxxxxxxxxxx"
data-ad-slot="xxxxxxxxx"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>
As a sanity check I also passed in a string with new line characters directly to javadoc (manual) on the command line and it works just fine.
javadoc foo.java -header "This is a test
and so is this"
The output HTML:
<div class="aboutLanguage"><em>This is a test
and so is this</em></div>
</div>
I have an explanation, but i don't have a solution except for creating a new feature request in Gradle JIRA.
To generate a javadoc Gradle first generates the so-called argfile at build\tmp\javadocTaskName\javadoc.options that contains all individual options and than executes javadoc #full\path\to\build\tmp\javadocTaskName\javadoc.options command.
It is actually quite useful as you can debug the contents of that file by simply invoking javadoc #javadoc.options yourself from the command line.
It is possible to define multi-line values in the argfile by using the \ character at the end of each line inside the multi-line value.
The example header = "this is\na test which should fail" results in
-header 'this is
a test which should fail'
but we need to get
-header 'this is\
a test which should fail'
to tell javadoc that the value continues on the next line.
Now the problem is how to output that \ on each line.
The obvious attempt at header = "this is\\\na test which should fail" does not work, it will result in
-header 'this is\\
a test which should fail'
And even Groovy multi-line or slashy strings will not work and will result in similar double back slashes.
Because Gradle just replaces all single backslashes in the option values. The JavadocOptionFileWriterContext.writeValue(String) method is the culprit, the replaceAll("\\\\", "\\\\\\\\") line in particular (a regex that matches single backslash and replaces it with double backslash ).
This escaping is required for backslashes inside a line, but it should not escape a single backslash followed by the new line character. My regex-fu is not strong enough to write such a pattern, but it is surely possible.
Or even better, the escaping mechanism inside that method should replace newline characters with a single backslash followed by the newline to hide all this stuff and allow users to declare multi-line javadoc options without the need to think or even know that feature.
I would appreciate if somebody can create an issue in Gradle tracker as i can't do so from my current location. This sentence should be replaced with the link to the issue so that people with similar problem can vote and track its progress.
I tried to implement it in Gradle but I couldn't get it to work reliably on windows. If the options file has this:
-header 'this is\
a test which should fail'
It works nicely on linux/mac but fails on windows (tried on win7/java7 and some other windows+java6). I've tried with vanilla javadoc executable (without Gradle).
I'll get the fix into Gradle and it will work out of the box for linux/mac but not quite for windows. If you want to help out with windows support catch us at http://issues.gradle.org/browse/GRADLE-3099