OK, same error occurs in the release just *before* my update to JDOM2
(can see jdom instead of jdom2 in the error stack):
java.lang.IllegalStateException: Illegal class loader binding
at
org.apache.naming.resources.DirContextURLStreamHandler.get(DirContextURLStreamHandler.java:229)
at
org.apache.naming.resources.DirContextURLStreamHandler.openConnection(DirContextURLStreamHandler.java:91)
at java.net.URL.openConnection(URL.java:971)
at java.net.URL.openStream(URL.java:1037)
at
org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
at
org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:518)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:905)
at
org.apache.wiki.auth.authorize.WebContainerAuthorizer.getWebXml(WebContainerAuthorizer.java:394)
at
org.apache.wiki.auth.authorize.WebContainerAuthorizer.initialize(WebContainerAuthorizer.java:102)
at
org.apache.wiki.auth.AuthorizationManager.initialize(AuthorizationManager.java:478)
And still 90%+ failures (different errors though) when I tried with the
very first commit that had the Mavenized Selenium tests:
http://svn.apache.org/viewvc?view=revision&revision=1486481. This is
strange, because I thought I had seen the IT tests work fine with Maven
in the past, hmm....
Basically, reading the jspwiki-war/pom.xml revision page
(http://svn.apache.org/viewvc/jspwiki/trunk/jspwiki-war/pom.xml?view=log) I
just checked out various revisions ("svn co
https://svn.apache.org/repos/asf/jspwiki/trunk -r1486481 jsp1486481",
for example), to try to find a release in which the IT tests worked for
me (using mvn clean install -Pintegration-tests). I'm going to defer
the matter to Juan Pablo for him to replicate and see if he can find the
error, when he has the time to do so. If he can find a revision that
worked just before a commit of mine, I can look more into it from my end.
Thanks,
Glen
On 07/21/2013 10:22 PM, Glen Mazza wrote:
Uh oh...bug might be on my end,
jspwiki-it-test-container-jdbc/target/test-classes/jspwiki-jspwiki-it-test-container-jdbc.log
is reporting:
Caused by: java.lang.IllegalStateException: Illegal class loader binding
at
org.apache.naming.resources.DirContextURLStreamHandler.get(DirContextURLStreamHandler.java:229)
at
org.apache.naming.resources.DirContextURLStreamHandler.openConnection(DirContextURLStreamHandler.java:91)
at java.net.URL.openConnection(URL.java:971)
at java.net.URL.openStream(URL.java:1037)
at
org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown
Source)
at
org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at
org.jdom2.input.sax.SAXBuilderEngine.build(SAXBuilderEngine.java:217)
at
org.jdom2.input.sax.SAXBuilderEngine.build(SAXBuilderEngine.java:277)
at org.jdom2.input.SAXBuilder.build(SAXBuilder.java:1141)
at
org.apache.wiki.auth.authorize.WebContainerAuthorizer.getWebXml(WebContainerAuthorizer.java:394)
at
org.apache.wiki.auth.authorize.WebContainerAuthorizer.initialize(WebContainerAuthorizer.java:102)
at
org.apache.wiki.auth.AuthorizationManager.initialize(AuthorizationManager.java:478)
The "jdom2" part in the stack above is new--I updated from JDOM to
JDOM2 a few weeks back, and that might have introduced the bug
somewhere. I'll check out a few older versions and try to determine
what commit caused this problem to start occurring.
Glen
On 07/21/2013 07:25 PM, Glen Mazza wrote:
Hi JP, are you *sure* Selenium tests work, or mostly work, on your
machine?
If I do "mvn clean install -Pintegration-tests" from the jspwiki
trunk folder, I keep getting "port 8080" in use errors, halting
everything; if I run the same command from the jspwiki-it-tests
folder, I get Selenium errors on about 90% of the tests. Firefox *or*
Chrome. (I'm using Ubuntu Linux)
It may have been a change I had done--idk--and I might be able to
figure out what is wrong (I suspect it's just one or two things
missing causing a chain reaction of failures), but I need to know
whether this is just my machine or everybody else's. IIRC things were
once working fine from Maven.
Thanks,
Glen
On 07/03/2013 02:05 PM, Juan Pablo Santos RodrÃguez wrote:
Hi Glen,
regarding 3, yes, filtering is done in the main branch of IT tests,
although it doesn't use filter.properties at all:
- jspwiki-selenium-tests/src/main/resources contains a bare, unfiltered
./WEB-INF/jspwiki.properties
- each pom.xml of every jspwiki-it-* module under jspwiki-it-tests
contains
several properties which are used to "populate" a different
jspwiki.properties file.
- when the integration-tests profile is used,
+ every IT module uses jspwiki-war as a maven overlay (i.e.: is
unzipped
and used as a base war structure),
+ then the resources of each module are processed. This means
jspwiki-selenium-tests/src/main/resources/WEB-INF/jspwiki.properties
gets
filtering applied with the specific properties of each module so
finally,
+ as it is defined as a maven resource of a war module, it get's
copied
to WEB-INF/jspwiki.properties of the war used for IT testing, under
./target of each module, effectively overwritting the original
jspwiki.properties from jspwiki-war
as for IT execution: right now is locale-dependant, I haven't found
a way
to enforce default locale no tomcat7-plugin yet, that's why JSPWIKI-770
isn't marked as resolved. Probably the fastest way is to add a new test
which set user locale to english, but hadn't had the time.
Also, IT executions uses google chrome as the default test browser, as
tests execution is faster than firefox, and way faster than IE10. Other
than that, they should run fine. Maybe there's a failure here or
there b/c
selenium scripts haven't been kept up to date with trunk, but they
should
be mostly ok.
br,
juan pablo
On Wed, Jul 3, 2013 at 5:54 PM, Glen Mazza <[email protected]>
wrote:
Hi Team, some notes:
1.) I updated to JDOM2 (the older JDOM branch was retired) -- the
tests
are now all passing (except integration tests, see last comment). The
earlier problem I had brought up was solved via an override to one
of JDOMs
classes:
http://svn.apache.org/viewvc/**incubator/jspwiki/trunk/**
jspwiki-war/src/main/java/org/**apache/wiki/render/**
CustomXMLOutputProcessor.java?**view=markup<http://svn.apache.org/viewvc/incubator/jspwiki/trunk/jspwiki-war/src/main/java/org/apache/wiki/render/CustomXMLOutputProcessor.java?view=markup>
Otherwise, mainly a bunch of org.jdom -> org.jdom2 package renaming.
2.) I updated from JUnit 3.8.2 to the latest JUnit 4.11, with that
version
we now have the ability to test single test methods within a test
case:
mvn test -Dtest=**JSPWikiMarkupParserTest#**testHeadingHyperlinks3
(just
that single test)
or
mvn test -Dtest=JSPWikiMarkupParserTest (all tests in that class)
I add notes about this to http://svn.apache.org/viewvc/**
incubator/jspwiki/trunk/mvn_**cheat-sheet.txt?view=markup<http://svn.apache.org/viewvc/incubator/jspwiki/trunk/mvn_cheat-sheet.txt?view=markup>
Also, I added links in the above cheat sheet on how to debug/trace
test
cases in Eclipse and IDEA -- it's pretty simple to do.
3.) I moved the src/main/filters/filters.txt to
src/test/filters/filters.txt as up to now all filtering was being
done on
test resources.
However, maybe (?) resource filtering is being done in the main
branch for
the integration tests? JP -- is line #66 below necessary?
http://svn.apache.org/viewvc/**incubator/jspwiki/trunk/**
jspwiki-it-tests/pom.xml?**revision=1487137&view=markup#**l64<http://svn.apache.org/viewvc/incubator/jspwiki/trunk/jspwiki-it-tests/pom.xml?revision=1487137&view=markup#l64>
4.) For me, the integration tests are failing left and right (even
before
this change), I don't know if it's something I did in a recent commit
(prior to the change to JDOM2, same errors were occurring for me),
or if
it's just my machine. I'll look into this next but if JP or
someone else
can immediately spot (or at least confirm) the error it would be
appreciated.
Thanks,
Glen
