I'm trying to run Selenium tests using Play's built-in testing framework (TestServer, FakeApp, running() method) and running it through SBT, but the logging level for HTMLUNIT seems to be set at debug; causing a very large stack of useless messages.
I've already tried this:
Setting com.gargoylesoftware.htmlunit=ERROR in application.conf
Setting <logger name="com.gargoylesoftware.htmlunit" level="ERROR"/> in application-logger.xml
Doing the same thing as above but in test/resources/logback-test.xml
None of these seem to work. Looking at the log messages, it seems that it does understand that there is a logback-test.xml yet it just ignores it when it comes to HTMLUNIT.
Thanks
Figured it out. My problem was a lack of understanding of how play loads up xml files for logback.
There are 3 files that configure logback in play: logback.xml, application-logger.xml and application.conf. My issue was that I was declaring the levels in logback.xml (which loads before application-logger) but those settings were being overloaded by application-logger.
Putting the log levels on application-logger fixed the issue.
Related
I work still view month on a project with RapidClipse 4.0
I deployed on the production server several versions of the project war files. Everything worked fine.
After the last deployment I got a blank screen after loading the application URL
For the server I use a docker container with following setting:
Apache Tomcat/8.5.43, JVM: 1.8.0_222-b10, 3.10.105, amd64
My first thought was: "ok you did something wrong in your code.. turn back and every thing is fine.... :-((
It wasn't !!
I used several versions which runs fine befor.
I stopped the application, redeployed it and deleted it.
Then I deployed an older version....and once again a version older..a.s.o
Non of the versions which worked fine befor did work again.
I got every time the same result: after loading the application a blank white screen.
So far so bad:
I tried to look into ../conf/server.xml if deployment parameter is set correctly:
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
looked fine!
I enhanced the cache by:
$CATALINA_BASE/conf/context.xml added following code:
<Resources cachingAllowed="true" cacheMaxSize="100000" />
also without success.
I tried to look in catalina.out: There is still nothing helpfull:
14-Aug-2019 20:29:21.087 INFO [http-nio-8080-exec-6] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/usr/local/tomcat/webapps/RC_07.war]
14-Aug-2019 20:29:31.190 INFO [http-nio-8080-exec-6] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/usr/local/tomcat/webapps/RC_07.war] has finished in [10,102] ms
after debug in browser I got following:
257ms Processing time was 134ms
257msReferenced paintables: 6
283msEstablishing push connection
300msCould not load theme from http://myIP:8888/RC_07/VAADIN/themes//styles.css?v=7.7.13
310msPush connection established using long-polling
I searched also in the history of the docker container an found that this problem (300ms....) still persists from beginning, over all versions I deployed before.
Out of this, I assume, that this could not be the reason, too.
Or am I wrong?
I searched around this VAADIN Problem and found a lot, but I was not able to solve it. The styles.css file are still in place on the server.
I am wondering on ..../VAADIN/themes//styles.css...
the double slash in error message.
But in my code I couldn't find similar.
Also the buildpath in eclipse includes the folder structure like expected.
Now I am at the end!
I am confused, how I should go ahead to figure out the reason for this behavior, or much better to fix it.
Any idea/ help would be welcome!!
Thank you in advance
rgds
OpaHeinz
After long research, togehter with RapidClipse support we found the solution.
I had two issues:
1) unknown how, we assume, that there was an error in the MainUI xml file.
After resetting with and high of view and layout, and turning back to setting before,
the page elements were visible again in design view.
2) there is a parameter for the theme under MainUI properties - misc -
This parameter was set, but without content. This results in a code line: this.setTheme("");
After resetting this, a deployment was possible like before.
Everything is fine now.
Thanks again to RapidClipse support.
After upgrading from 0.2.7 to 0.6.1, I am seeing a test failure when running from gradle.
The failing test is a simple:
And match response.dispositionInstructions == "Disposition Instructions"
When I run from intellij, the test passes.
Running from gradle, the following is logged:
15:11:22.840 [DEBUG] [TestEventLogger] com.intuit.karate.exception.KarateException: path: $.dispositionInstructions, actual: '{"dispositionInstructions":"Disposition Instructions", rest of document omitted}’ , expected: 'Disposition Instructions', reason: not equal
Not sure if it is relevant, but the JSON document is over 94k long.
However, if I paste the document (from the log) into a JSON validator (jsonlint.com), it shows it as being valid.
I am keen to exploit the new functionality and this is the only issue blocking me.
Any suggestions as to why this is failing on 0.6.1?
Dev of Karate here. Thanks for the clear explanation of the issue !
My guess is that this is related to this particular issue: https://github.com/intuit/karate/issues/144
Unfortunately, the person who logged that issue never reverted. I really hope that the suggested tweak to the surefire plugin to set the file.encoding does the trick.
Else do log an issue and cross-refer the above issue so that a notification goes out to the OP for that one. With your help I can hopefully finally replicate this issue, and I may need your help to create a fake large payload that can simulate this problem in my local environment.
i have a problem to run test. My model use extension Yii mail and then i run test its fail with wrong assert path. Another test runs finaly (model dont use any extensions). Preloading is only log.
I had a similar error and I explicitly set the basePath in config/test.php.
'components'=>array(
...
'assetManager'=>array(
'basePath'=>dirname(__FILE__).'/../../assets',
)
)
Im solved problem
public function setUp(){
Yii::app()->assetManager->basePath = '../../asserts';
}
Im dont know why this error throw only in one model...
PhpUnit runs primary in CLI mode and therefore some of environmental variables are missing. Yii's AssetManager uses one of such variable to determine webroot and since the variable does not exist, it will either throw error or set up invalid assets path on first attempt.
In my opinion, this issue is (indirectly) caused by PHPUnit because it only supports CLI testing mode, which makes some things really more difficult to test than it would be in HTTP request mode. Some guys therefore wrote tools to run unit tests via standard web GUI with whole native HTTP environment (e.g. https://github.com/NSinopoli/VisualPHPUnit). Eventually, you may use HTTP clients like Selenium to run your tests as if clicking over the page (see http://phpunit.de/manual/3.7/en/selenium.html).
Nevertheless, it's a matter of subjective opinion - somebody may argue, that testing in CLI mode has advantages, some guys will hate it. But the fact is, that one has to bear in mind differences between HTTP and CLI mode.
Trying my hand at CDI for the first time. I'm using Glassfish v3. When I deploy my app, I get the following failure:
java.io.IOException:
com.sun.enterprise.admin.cli.remote.RemoteFailureException:
Exception while loading the app :
org.glassfish.deployment.common.DeploymentException:
java.lang.IncompatibleClassChangeError:
com.example.arizona.client.ArizonaService
and
com.example.arizona.client.ArizonaService$App
disagree on InnerClasses attribute
at
com.fuhrer.idea.glassfish.server.GlassfishServer3.doParseResponse(GlassfishServer3.java:28)
at
com.fuhrer.idea.glassfish.server.GlassfishServer3Base.parseResponse(GlassfishServer3Base.java:156)
at
com.fuhrer.idea.glassfish.server.GlassfishServer3Base.invoke(GlassfishServer3Base.java:127)
at
com.fuhrer.idea.glassfish.server.GlassfishServer3Base.handleDeployment(GlassfishServer3Base.java:78)
at
com.fuhrer.idea.javaee.server.JavaeeServerInstance$2.run(JavaeeServerInstance.java:131)
I should mention that I'm not even actually using injection, or any other CDI features yet. This is just trying to get the dependencies straightened out.
I've had the same issue, but with Weld in Tomcat. Problem for me was caused by changing an inner class definition to a normal class. Resulted, in my case, in having the old innerclass still in the classes directory but with a new parent class.
Cleaning the classes directory worked for me.
Nearly a year later I'm sorry to say that I never solved this, and for various reasons moved on to another stack altogether: Tomcat, Wicket and Wicket-CDI, all of which have worked great for me.
i have a strange problem. I have an ICEFaces(1.8.2) + Facelets application im working on and every time i make a change to it and deploy i must restart Glassfish(2.1.1) else i get a "java.lang.ClassCastException" on my entities. The error message is :
java.lang.ClassCastException: za.co.africanpulse.rms.frontend.domain.Menuheader cannot be cast to za.co.africanpulse.rms.frontend.domain.Menuheader
If i restart Glassfish as said above all is ok... but this is getting kinda irratating. I dont quite know what exactly you would like me to post so that my problem is easier identified / understood. Anyways any help will be most appreciated.
Many many thanks
You should probably open an issue with the GlassFish project: https://glassfish.dev.java.net/servlets/ProjectIssues.
StackOverflow isn't really designed to be a bug reporting/analysis tool.
That said... someone might have run into this and you could 'Get Lucky'...
Edit 1:
For example, this query: http://www.google.com/search?q=glassfish+icefaces+facelet+classcastexception
Netted this hit: http://seamframework.org/Community/HelpOnSeam220ICEfaces181AndGlassfish21
which looks like it may be useful.
When the web.xml servlet version is below 2.5 and jsf is still at 1.1 specified in the faces-config.xml then strange persistence related issues will arise. In my case entities could not be cast to themselves..???
After changing servlet version and jsf version i could successfully inject EntityManagers into my DAOs...