You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by Glen Mazza <gl...@gmail.com> on 2013/07/03 17:54:27 UTC

Latest update notes...

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

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
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


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


Re: Problem with the integrated tests (Re: Latest update notes...)

Posted by Glen Mazza <gl...@gmail.com>.
We still don't have commit access for some reason.   Feel free to vote 
for INFRA-6574 <https://issues.apache.org/jira/browse/INFRA-6574> :)

Glen

On 07/23/2013 06:42 PM, Juan Pablo Santos Rodríguez wrote:
> Hi Glen,
>
> hmm this is strange, both userdatabase.xml and groupdatabase.xml appear
> under
> ./jspwiki/jspwiki-it-tests/jspwiki-it-test-custom/target/!jspwiki-it-test-custom.war/WEB-INF,
> which is the war launched by the module. However, looking at the
> jspwiki.properties file inside that war, specifically the entries
> jspwiki.xmlGroupDatabaseFile and jspwiki.xmlUserDatabaseFile:
>
> jspwiki.xmlGroupDatabaseFile = target/test-classes/groupdatabase.xml
> jspwiki.xmlUserDatabaseFile = target/test-classes/userdatabase.xml
>
> which is false. Moving both files from
> $svn/trunk/jspwiki-it-tests/jspwiki-selenium-tests/src/main/resources/WEB-INF
> to $svn/trunk/jspwiki-it-tests/jspwiki-selenium-tests/src/test/resources
> should fix it. Seems that they started under src/test/resources but I
> decided somewhere that they didn't belong there and moved then under
> src/main/resources/WEB-INF. Right now, I can't remember why or when did I
> did that :-/ but I should either updated the jspwiki.properties file
> accordingly or leaved them under src/test/resources..
>
> sorry for the annoyance
>
>
> br,
> juan pablo
>
> On Tue, Jul 23, 2013 at 4:58 AM, Glen Mazza <gl...@gmail.com> wrote:
>
>> I started working on this again and am getting closer. I commented out all
>> IT tests except one (jspwiki-it-test-custom), and then removed all Selenium
>> tests but one (login).  Looking at the jspwiki-it-test-custom/target/**
>> test-classes/jspwiki-jspwiki-**it-test-custom.log, the userdatabase.xml
>> and groupdatabase.xml does not exist at the location it is configured to be:
>>
>> 2013-07-22 22:11:11,571 [localhost-startStop-1] INFO org.apache.wiki.auth.
>> **authorize.GroupManager  - Attempting to load group database class
>> org.apache.wiki.auth.**authorize.XMLGroupDatabase
>> 2013-07-22 22:11:11,573 [localhost-startStop-1] INFO org.apache.wiki.auth.
>> **authorize.XMLGroupDatabase  - XML group database at
>> /media/work1/opensource/**jspwiki/jspwiki-it-tests/**groupdatabase.xml
>> 2013-07-22 22:11:11,587 [localhost-startStop-1] INFO org.apache.wiki.auth.
>> **authorize.XMLGroupDatabase  - Group database not found; creating from
>> scratch...
>>
>> 2013-07-22 22:11:11,645 [localhost-startStop-1] INFO
>> org.apache.wiki.auth.user.**AbstractUserDatabase  - XML user database at
>> /media/work1/opensource/**jspwiki/jspwiki-it-tests/**userdatabase.xml
>> 2013-07-22 22:11:11,646 [localhost-startStop-1] INFO
>> org.apache.wiki.auth.user.**AbstractUserDatabase  - User database not
>> found; creating from scratch...
>> 2013-07-22 22:11:11,647 [localhost-startStop-1] INFO org.apache.wiki.auth.
>> **UserManager  - UserDatabase initialized.
>>
>> Those two files are located elsewhere -- if I can reconfigure that, that
>> would probably fix the vast majority of the failures being reported.
>>
>> Regards,
>> Glen
>>
>>
>>
>> On 07/22/2013 12:47 PM, Glen Mazza wrote:
>>
>>> 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<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<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<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 <gl...@gmail.com>
>>>>>> 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/**<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<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/****<http://svn.apache.org/viewvc/**>
>>>>>>> incubator/jspwiki/trunk/mvn_****cheat-sheet.txt?view=markup<ht**
>>>>>>> tp://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/**<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<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
>>>>>>>
>>>>>>>
>>>>>>>


Re: Problem with the integrated tests (Re: Latest update notes...)

Posted by Glen Mazza <gl...@gmail.com>.
OK, I rearranged it a bit, that's got us from about 20% of the IT tests 
passing to around 50%, I'll look at it more, but as you understand this 
more than I, any immediate things you see wrong please fix them.

Also, over time I hope to be able to simplify our tests, instead of 
making the same long test for five scenarios, just have one long test 
(actually, make it longer as we can test more stuff) and four short 
tests testing *just* the specific security portions that are relevant 
for them.

Glen

On 07/23/2013 06:42 PM, Juan Pablo Santos Rodríguez wrote:
> Hi Glen,
>
> hmm this is strange, both userdatabase.xml and groupdatabase.xml appear
> under
> ./jspwiki/jspwiki-it-tests/jspwiki-it-test-custom/target/!jspwiki-it-test-custom.war/WEB-INF,
> which is the war launched by the module. However, looking at the
> jspwiki.properties file inside that war, specifically the entries
> jspwiki.xmlGroupDatabaseFile and jspwiki.xmlUserDatabaseFile:
>
> jspwiki.xmlGroupDatabaseFile = target/test-classes/groupdatabase.xml
> jspwiki.xmlUserDatabaseFile = target/test-classes/userdatabase.xml
>
> which is false. Moving both files from
> $svn/trunk/jspwiki-it-tests/jspwiki-selenium-tests/src/main/resources/WEB-INF
> to $svn/trunk/jspwiki-it-tests/jspwiki-selenium-tests/src/test/resources
> should fix it. Seems that they started under src/test/resources but I
> decided somewhere that they didn't belong there and moved then under
> src/main/resources/WEB-INF. Right now, I can't remember why or when did I
> did that :-/ but I should either updated the jspwiki.properties file
> accordingly or leaved them under src/test/resources..
>
> sorry for the annoyance
>
>
> br,
> juan pablo
>
> On Tue, Jul 23, 2013 at 4:58 AM, Glen Mazza <gl...@gmail.com> wrote:
>
>> I started working on this again and am getting closer. I commented out all
>> IT tests except one (jspwiki-it-test-custom), and then removed all Selenium
>> tests but one (login).  Looking at the jspwiki-it-test-custom/target/**
>> test-classes/jspwiki-jspwiki-**it-test-custom.log, the userdatabase.xml
>> and groupdatabase.xml does not exist at the location it is configured to be:
>>
>> 2013-07-22 22:11:11,571 [localhost-startStop-1] INFO org.apache.wiki.auth.
>> **authorize.GroupManager  - Attempting to load group database class
>> org.apache.wiki.auth.**authorize.XMLGroupDatabase
>> 2013-07-22 22:11:11,573 [localhost-startStop-1] INFO org.apache.wiki.auth.
>> **authorize.XMLGroupDatabase  - XML group database at
>> /media/work1/opensource/**jspwiki/jspwiki-it-tests/**groupdatabase.xml
>> 2013-07-22 22:11:11,587 [localhost-startStop-1] INFO org.apache.wiki.auth.
>> **authorize.XMLGroupDatabase  - Group database not found; creating from
>> scratch...
>>
>> 2013-07-22 22:11:11,645 [localhost-startStop-1] INFO
>> org.apache.wiki.auth.user.**AbstractUserDatabase  - XML user database at
>> /media/work1/opensource/**jspwiki/jspwiki-it-tests/**userdatabase.xml
>> 2013-07-22 22:11:11,646 [localhost-startStop-1] INFO
>> org.apache.wiki.auth.user.**AbstractUserDatabase  - User database not
>> found; creating from scratch...
>> 2013-07-22 22:11:11,647 [localhost-startStop-1] INFO org.apache.wiki.auth.
>> **UserManager  - UserDatabase initialized.
>>
>> Those two files are located elsewhere -- if I can reconfigure that, that
>> would probably fix the vast majority of the failures being reported.
>>
>> Regards,
>> Glen
>>
>>
>>
>> On 07/22/2013 12:47 PM, Glen Mazza wrote:
>>
>>> 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<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<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<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 <gl...@gmail.com>
>>>>>> 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/**<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<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/****<http://svn.apache.org/viewvc/**>
>>>>>>> incubator/jspwiki/trunk/mvn_****cheat-sheet.txt?view=markup<ht**
>>>>>>> tp://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/**<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<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
>>>>>>>
>>>>>>>
>>>>>>>


Re: Problem with the integrated tests (Re: Latest update notes...)

Posted by Juan Pablo Santos Rodríguez <ju...@gmail.com>.
Hi Glen,

hmm this is strange, both userdatabase.xml and groupdatabase.xml appear
under
./jspwiki/jspwiki-it-tests/jspwiki-it-test-custom/target/!jspwiki-it-test-custom.war/WEB-INF,
which is the war launched by the module. However, looking at the
jspwiki.properties file inside that war, specifically the entries
jspwiki.xmlGroupDatabaseFile and jspwiki.xmlUserDatabaseFile:

jspwiki.xmlGroupDatabaseFile = target/test-classes/groupdatabase.xml
jspwiki.xmlUserDatabaseFile = target/test-classes/userdatabase.xml

which is false. Moving both files from
$svn/trunk/jspwiki-it-tests/jspwiki-selenium-tests/src/main/resources/WEB-INF
to $svn/trunk/jspwiki-it-tests/jspwiki-selenium-tests/src/test/resources
should fix it. Seems that they started under src/test/resources but I
decided somewhere that they didn't belong there and moved then under
src/main/resources/WEB-INF. Right now, I can't remember why or when did I
did that :-/ but I should either updated the jspwiki.properties file
accordingly or leaved them under src/test/resources..

sorry for the annoyance


br,
juan pablo

On Tue, Jul 23, 2013 at 4:58 AM, Glen Mazza <gl...@gmail.com> wrote:

> I started working on this again and am getting closer. I commented out all
> IT tests except one (jspwiki-it-test-custom), and then removed all Selenium
> tests but one (login).  Looking at the jspwiki-it-test-custom/target/**
> test-classes/jspwiki-jspwiki-**it-test-custom.log, the userdatabase.xml
> and groupdatabase.xml does not exist at the location it is configured to be:
>
> 2013-07-22 22:11:11,571 [localhost-startStop-1] INFO org.apache.wiki.auth.
> **authorize.GroupManager  - Attempting to load group database class
> org.apache.wiki.auth.**authorize.XMLGroupDatabase
> 2013-07-22 22:11:11,573 [localhost-startStop-1] INFO org.apache.wiki.auth.
> **authorize.XMLGroupDatabase  - XML group database at
> /media/work1/opensource/**jspwiki/jspwiki-it-tests/**groupdatabase.xml
> 2013-07-22 22:11:11,587 [localhost-startStop-1] INFO org.apache.wiki.auth.
> **authorize.XMLGroupDatabase  - Group database not found; creating from
> scratch...
>
> 2013-07-22 22:11:11,645 [localhost-startStop-1] INFO
> org.apache.wiki.auth.user.**AbstractUserDatabase  - XML user database at
> /media/work1/opensource/**jspwiki/jspwiki-it-tests/**userdatabase.xml
> 2013-07-22 22:11:11,646 [localhost-startStop-1] INFO
> org.apache.wiki.auth.user.**AbstractUserDatabase  - User database not
> found; creating from scratch...
> 2013-07-22 22:11:11,647 [localhost-startStop-1] INFO org.apache.wiki.auth.
> **UserManager  - UserDatabase initialized.
>
> Those two files are located elsewhere -- if I can reconfigure that, that
> would probably fix the vast majority of the failures being reported.
>
> Regards,
> Glen
>
>
>
> On 07/22/2013 12:47 PM, Glen Mazza wrote:
>
>> 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<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<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<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 <gl...@gmail.com>
>>>>> 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/**<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<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/****<http://svn.apache.org/viewvc/**>
>>>>>> incubator/jspwiki/trunk/mvn_****cheat-sheet.txt?view=markup<ht**
>>>>>> tp://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/**<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<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
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>

Re: Problem with the integrated tests (Re: Latest update notes...)

Posted by Glen Mazza <gl...@gmail.com>.
I started working on this again and am getting closer. I commented out 
all IT tests except one (jspwiki-it-test-custom), and then removed all 
Selenium tests but one (login).  Looking at the 
jspwiki-it-test-custom/target/test-classes/jspwiki-jspwiki-it-test-custom.log, 
the userdatabase.xml and groupdatabase.xml does not exist at the 
location it is configured to be:

2013-07-22 22:11:11,571 [localhost-startStop-1] INFO 
org.apache.wiki.auth.authorize.GroupManager  - Attempting to load group 
database class org.apache.wiki.auth.authorize.XMLGroupDatabase
2013-07-22 22:11:11,573 [localhost-startStop-1] INFO 
org.apache.wiki.auth.authorize.XMLGroupDatabase  - XML group database at 
/media/work1/opensource/jspwiki/jspwiki-it-tests/groupdatabase.xml
2013-07-22 22:11:11,587 [localhost-startStop-1] INFO 
org.apache.wiki.auth.authorize.XMLGroupDatabase  - Group database not 
found; creating from scratch...

2013-07-22 22:11:11,645 [localhost-startStop-1] INFO 
org.apache.wiki.auth.user.AbstractUserDatabase  - XML user database at 
/media/work1/opensource/jspwiki/jspwiki-it-tests/userdatabase.xml
2013-07-22 22:11:11,646 [localhost-startStop-1] INFO 
org.apache.wiki.auth.user.AbstractUserDatabase  - User database not 
found; creating from scratch...
2013-07-22 22:11:11,647 [localhost-startStop-1] INFO 
org.apache.wiki.auth.UserManager  - UserDatabase initialized.

Those two files are located elsewhere -- if I can reconfigure that, that 
would probably fix the vast majority of the failures being reported.

Regards,
Glen


On 07/22/2013 12:47 PM, Glen Mazza wrote:
> 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 <gl...@gmail.com> 
>>>> 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
>>>>>
>>>>>
>>>
>>
>


Re: Problem with the integrated tests (Re: Latest update notes...)

Posted by Glen Mazza <gl...@gmail.com>.
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 <gl...@gmail.com> 
>>> 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
>>>>
>>>>
>>
>


Problem with the integrated tests (Re: Latest update notes...)

Posted by Glen Mazza <gl...@gmail.com>.
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 <gl...@gmail.com> 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
>>>
>>>
>


Re: Latest update notes...

Posted by Glen Mazza <gl...@gmail.com>.
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 <gl...@gmail.com> 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
>>
>>


Re: Latest update notes...

Posted by Juan Pablo Santos Rodríguez <ju...@gmail.com>.
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 <gl...@gmail.com> 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
>
>

Re: Latest update notes...

Posted by Matt Clark <ma...@gmail.com>.
unsubscribe


On Wed, Jul 3, 2013 at 11:54 AM, Glen Mazza <gl...@gmail.com> 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
>
>