The reason for this seam to be an misconfigured ProxyPass:
As I read here it's look like the
ProxyPassReverseCookiePath
config was missing.
Another way of solving the problem was to change the context.xml config
<Context sessionCookiePath="/">Mittwoch, 17. Juni 2015
Tomcat 6 Session expired
I have a web app written in JSF Spring Hibernate and I serve the webapp behind an apache http container trough ProxyPass. Everything was working ok, until recently I have a situation where the the users were not able to log in: the error message was "Your Session has expired".
The reason for this seam to be an misconfigured ProxyPass:
As I read here it's look like the
ProxyPassReverseCookiePath
config was missing.
Another way of solving the problem was to change the context.xml config
The reason for this seam to be an misconfigured ProxyPass:
As I read here it's look like the
ProxyPassReverseCookiePath
config was missing.
Another way of solving the problem was to change the context.xml config
Dienstag, 12. August 2014
JavaScript CI - The Next Generation
A few months back, I start working with JavaScript. Since I am full convinced about the benefits of the Continuous Integration (CI) methodology, I have start to get familiar with CI in the context of JavaScript.
CI is a methodology which can be adopt in any language, but because I am familiar with CI in the context of Java, i.e. I am working with Java for some years; I will present the tools for CI in Javascript as a parallel for the tools I use in Java.
Of course, it can be that there are better suited tools for the job, but the tools I will present are doing a great job for me and work great.
As a CI Server I will go also with Jenkins which is doing a great job.
In order to have CI we will need to have test that can be run automatically. Mostly for Test in Java I use TestNG as a library, but also in this area is a new player in town Spock. I have start using Spock in Grails and it's very expressive. You should give it a try ;).
For the JavaScript there are also plenty of testing framework. I have started with Jasmine and stick with it because it's more then just a testing framework, it's supports also BDD and in some how I find't expressive like Spock.
The second tool it will be Karma which is a test runner. Sorry if I go to far with the analogy, but I will say that Karma is the equivalent of the Surefire Plugin in Java, i.e. it also executes the test independent from the test library and generates, depending on the configuration, different reports e.g. coverage, unit-test.
After creating the test in Java, mostly we have a helper which, with regard to test, is putting all together: with only one command we have in a moment the tests run and different operating figures generated e.g. tests result, tests coverage, statical analysis etc. In Java, for me, those helper are Ant, Maven and also here as new player Gradle. In terms of JavaScript I will start the introduction with Grunt which is a task runner and in my analogy to Java context, I will say that Grunt is the Ant for JavaScript.
There is one more thing which is missing: a dependencies resolver. For Java Maven is doing a great job. For JavaScript at the moment are some more options, all of them with theirs pro's and con's. The tools that I use are Bower and Nmp as a part of Node.js.
That was just a short presentation of the tools I recommend you to use when you want to start to develop with joy awesome JavaScript application.
In other words as Spock will say code -"live long and prosper"
CI is a methodology which can be adopt in any language, but because I am familiar with CI in the context of Java, i.e. I am working with Java for some years; I will present the tools for CI in Javascript as a parallel for the tools I use in Java.
Of course, it can be that there are better suited tools for the job, but the tools I will present are doing a great job for me and work great.
As a CI Server I will go also with Jenkins which is doing a great job.
In order to have CI we will need to have test that can be run automatically. Mostly for Test in Java I use TestNG as a library, but also in this area is a new player in town Spock. I have start using Spock in Grails and it's very expressive. You should give it a try ;).
For the JavaScript there are also plenty of testing framework. I have started with Jasmine and stick with it because it's more then just a testing framework, it's supports also BDD and in some how I find't expressive like Spock.
The second tool it will be Karma which is a test runner. Sorry if I go to far with the analogy, but I will say that Karma is the equivalent of the Surefire Plugin in Java, i.e. it also executes the test independent from the test library and generates, depending on the configuration, different reports e.g. coverage, unit-test.
After creating the test in Java, mostly we have a helper which, with regard to test, is putting all together: with only one command we have in a moment the tests run and different operating figures generated e.g. tests result, tests coverage, statical analysis etc. In Java, for me, those helper are Ant, Maven and also here as new player Gradle. In terms of JavaScript I will start the introduction with Grunt which is a task runner and in my analogy to Java context, I will say that Grunt is the Ant for JavaScript.
There is one more thing which is missing: a dependencies resolver. For Java Maven is doing a great job. For JavaScript at the moment are some more options, all of them with theirs pro's and con's. The tools that I use are Bower and Nmp as a part of Node.js.
That was just a short presentation of the tools I recommend you to use when you want to start to develop with joy awesome JavaScript application.
In other words as Spock will say code -"live long and prosper"
Samstag, 29. März 2014
Jenkins Gerrit Trigger and Gerrit 2.8 /RTFM
Yesterday I upgrade my Gerrit from version 2.7 on 2.8. The reason for the upgrade was the improved possibility to search now also in the commit message.
For more details have a look at in the doc.
The update was ok and run without any problems.
The problem started first next day. After pushing changes to gerrit the the jenkins gerrit trigger was doing his job and a build was automatically started on jenkins. Till here everything was good.
First when I start to review some code I just notice that jenkins was not able to make any notification about the status of the change was it "approve" or not.
After a look at the logs I wasn't smarter :(
For more details have a look at in the doc.
The update was ok and run without any problems.
The problem started first next day. After pushing changes to gerrit the the jenkins gerrit trigger was doing his job and a build was automatically started on jenkins. Till here everything was good.
First when I start to review some code I just notice that jenkins was not able to make any notification about the status of the change was it "approve" or not.
After a look at the logs I wasn't smarter :(
- the Gerrit+Trigger Plugin was doing his work and was sending a message: INFO: Notifying BuildCompleted to gerrit: gerrit approve 438,4 --message 'Build Unstable https://jenkinsserver.my/jenkins/job/myJob/1088/ : UNSTABLE' --verified 0 --code-review -1
- unfortunately in gerrit nothing was logged :(
After a little research I land where I was at the begin of my update: namely on the the manual and release notes of Gerrit 2.8 and what do you know in the Schema Change which I have read and also done are also some WARNING's some of which I have already read. Unfortunately only some and/or not all paid enough attention :(. The third WARNING specify clearly that the deprecated approve alias was removed. Here a short cite from the
WARNING: The deprecated approve alias for the review SSH command has been removed. This is important for all users of the Jenkins Gerrit Trigger Plugin since this plugin by default uses the approve command to vote and comment on changes in Gerrit. If you use the Gerrit Trigger Plugin, go to its global configuration in Jenkins and adapt the Gerrit commands to use the review command instead of the approve command.
So the solution is obvious easy:
- login in jenkins and change under
- Manage Jenkins
- Gerrit Trigger
- Gerrit Servers
- Gerrit Reporting Values
- Advanced
- change the Gerrit Verified Commands as specified in the manual: review instead of approve
after update:
once again Did you read the F... Manual?else:
RTFM
Samstag, 15. Februar 2014
Jenkins integration test with ssl
A few days back, after a colleague has push his new integration test, our Jenkins has started be unstable. The test was implying to work with a https URL, on a local area network. The https was using self-signed certificate. Actually no big deal, but in the end that was part of the problem.
The curios part was that the test was passing on the developer machine, only on the CI Server, Jenkins was failing the test. After a closer look the problem was found: the JVM was not accepting the self-signed certificate. This means that we need add our certificate to the keystore of the JVM or to provide the JVM with a keystore that has our self-signed certificate.
to list the cretificate of the JVM do
keytool -list -keystore $JAVA_HOME/jre/lib/security/cacerts
you will be asked for a password. To just list the cacerts, you don't need to introduce any password.
If you want to add a new entry then you will need a password. It's looks like the default password is
changeit
in order to add a new entry do
keytool -import -alias <your server> -file myServer.crt -keystore $JAVA_HOME/jre/lib/security/cacerts
If you don't provide last argument -keytrore then it's gone import in users home/.keystore
The last problem that needs to be fix is to make those certificate available at the test time in Jenkins.
For this you can add the following arguments for jenkins:
-Djavax.net.ssl.trustStore=<the path to your keystore>
-Djavax.net.ssl.trustStorePassword=<your keystore password>
Freitag, 25. Oktober 2013
Maven Release Plugin
For some days i have done some updates of my CI environment and i was surprised that my maven release plugin was not working correctly anymore.
After long search in different mailing list and forums i find something that was close to my problem. My problem was that the maven-release-plugin was not committing the correct tag it was still committing *-SNAPSHOT in the "prepare" goal. Because of this in the "performe" goals it was checking the wright tag but this was having *-SNAPSHOT in the pom.xml and that's the "performe" goals was allways trying to deploy a SNAPSHOT to my nexus release repository.
During my search i also came across this bug MRELEASE-812 "prepare" does not commit before tagging and therefore deploys snapshot instead of release which is from my understanding exactly my problem.
The solution i found it in some mailing list of the mave-relese-plugin and unfortunatly I haven't bookmark the link so I can remember now. Lesson learned for next time ;)
Fortunately i was able to reproduce the error because i have commit the change directly in my git repo. The solution was to add the dependencies for the maven-release-pluing
<dependencies>
<dependency>
<groupId>org.apache.maven.scm</groupId>
<artifactId>maven-scm-api</artifactId>
<version>1.8.1</version>
</dependency>
<dependency>
<groupId>org.apache.maven.scm</groupId>
<artifactId>maven-scm-provider-gitexe</artifactId>
<version>1.8.1</version>
</dependency>
</dependencies>
On my system I have git in the version 1.8.2.1 In order to know which version of the maven-scm-api are aviable have a look on maven-repos or directly on scms-overview
You can test it on your own with the test configuration which i have upload on github Before testing on your site you will need to change the property of mypath to a value which exist on your system. It should be an absolute path to where you have cloned the project.
Then commit the pom and just run
mvn release:prepare -B release:perform
Depending on what is the configuration of your maven-release-plugin with the dependencies specified or not it should work or not.
After long search in different mailing list and forums i find something that was close to my problem. My problem was that the maven-release-plugin was not committing the correct tag it was still committing *-SNAPSHOT in the "prepare" goal. Because of this in the "performe" goals it was checking the wright tag but this was having *-SNAPSHOT in the pom.xml and that's the "performe" goals was allways trying to deploy a SNAPSHOT to my nexus release repository.
During my search i also came across this bug MRELEASE-812 "prepare" does not commit before tagging and therefore deploys snapshot instead of release which is from my understanding exactly my problem.
The solution i found it in some mailing list of the mave-relese-plugin and unfortunatly I haven't bookmark the link so I can remember now. Lesson learned for next time ;)
Fortunately i was able to reproduce the error because i have commit the change directly in my git repo. The solution was to add the dependencies for the maven-release-pluing
<dependencies>
<dependency>
<groupId>org.apache.maven.scm</groupId>
<artifactId>maven-scm-api</artifactId>
<version>1.8.1</version>
</dependency>
<dependency>
<groupId>org.apache.maven.scm</groupId>
<artifactId>maven-scm-provider-gitexe</artifactId>
<version>1.8.1</version>
</dependency>
</dependencies>
On my system I have git in the version 1.8.2.1 In order to know which version of the maven-scm-api are aviable have a look on maven-repos or directly on scms-overview
You can test it on your own with the test configuration which i have upload on github Before testing on your site you will need to change the property of mypath to a value which exist on your system. It should be an absolute path to where you have cloned the project.
Then commit the pom and just run
mvn release:prepare -B release:perform
Depending on what is the configuration of your maven-release-plugin with the dependencies specified or not it should work or not.
Sonntag, 22. September 2013
Jenkins Gerrit Trigger and Gerrit 2.7
Yesterday I just update my Gerrit server from version 2.6* to 2.7.
One of the risen why i update was a bug when i was trying to view commits of other users in the side by side diff. The bug is also known and you can watch it evolve under the issue 1893 Multiple errors, when trying to review differences. In the new version 2.7 the issue is fixed, at list in my environment it was not reproducible. More about the release notes you can find in the ReleaseNotes/ReleaseNotes-2.7.html.
Everything was good until i have pushed my first commit under the new version. Since on my Jenkis instance i use Gerrit Trigger plugin, i was expecting that gerrit will trigger Jenkis to check the new patch that was just submitted. This is how it worked with the old version of Jenkins. About how you set up the Gerrit Trigger plugin see the set up information on the plugin site.
On my configuration i have a jenkins_ci user registered on gerrit. jekins_ci is a member of the Non-Interactive Users group and was created using create-account.
When i sow that gerrit is not trigger jenkins anymore first thing was to make a short debug and inspect the log files. For my surprise i sow that bouth services, gerrit and jenkins, are polluting their log files with something like
[2013-09-20 13:57:16,146] WARN org.apache.sshd.server.session.ServerSession : Exception caught
java.io.IOException: Connection reset by peer....
in the geerrit error_log file and
22.09.2013 11:48:00 com.sonyericsson.hudson.plugins.gerrit.gerritevents.GerritHandler run
INFO: Ready to receive data from Gerrit
22.09.2013 11:48:01 com.sonyericsson.hudson.plugins.gerrit.gerritevents.GerritHandler run
INFO: Ready to receive data from Gerrit
22.09.2013 11:48:01 com.sonyericsson.hudson.plugins.gerrit.gerritevents.GerritHandler run
INFO: Ready to receive data from Gerrit
22.09.2013 11:48:01 com.sonyericsson.hudson.plugins.gerrit.gerritevents.GerritHandler run
INFO: Ready to receive data from Gerrit
in jenkins log file. Jenkis was also showing an err on the manage site:
After spending some time searching for the problem i found the solution somewhere on the project mailing list. Unfortunately i forgot to bookmark the site and that motivate my to start my blog and share with you this solution. The answer is that the non-interactive users group should have access to Stream Events. You can do this over
Projects -> List -> All Projects -> Access
Now you can edit the Global Capabilities and add permission Stream Events:
That's all folks! :)
One of the risen why i update was a bug when i was trying to view commits of other users in the side by side diff. The bug is also known and you can watch it evolve under the issue 1893 Multiple errors, when trying to review differences. In the new version 2.7 the issue is fixed, at list in my environment it was not reproducible. More about the release notes you can find in the ReleaseNotes/ReleaseNotes-2.7.html.
Everything was good until i have pushed my first commit under the new version. Since on my Jenkis instance i use Gerrit Trigger plugin, i was expecting that gerrit will trigger Jenkis to check the new patch that was just submitted. This is how it worked with the old version of Jenkins. About how you set up the Gerrit Trigger plugin see the set up information on the plugin site.
On my configuration i have a jenkins_ci user registered on gerrit. jekins_ci is a member of the Non-Interactive Users group and was created using create-account.
When i sow that gerrit is not trigger jenkins anymore first thing was to make a short debug and inspect the log files. For my surprise i sow that bouth services, gerrit and jenkins, are polluting their log files with something like
[2013-09-20 13:57:16,146] WARN org.apache.sshd.server.session.ServerSession : Exception caught
java.io.IOException: Connection reset by peer....
in the geerrit error_log file and
22.09.2013 11:48:00 com.sonyericsson.hudson.plugins.gerrit.gerritevents.GerritHandler run
INFO: Ready to receive data from Gerrit
22.09.2013 11:48:01 com.sonyericsson.hudson.plugins.gerrit.gerritevents.GerritHandler run
INFO: Ready to receive data from Gerrit
22.09.2013 11:48:01 com.sonyericsson.hudson.plugins.gerrit.gerritevents.GerritHandler run
INFO: Ready to receive data from Gerrit
22.09.2013 11:48:01 com.sonyericsson.hudson.plugins.gerrit.gerritevents.GerritHandler run
INFO: Ready to receive data from Gerrit
in jenkins log file. Jenkis was also showing an err on the manage site:
After spending some time searching for the problem i found the solution somewhere on the project mailing list. Unfortunately i forgot to bookmark the site and that motivate my to start my blog and share with you this solution. The answer is that the non-interactive users group should have access to Stream Events. You can do this over
Projects -> List -> All Projects -> Access
Now you can edit the Global Capabilities and add permission Stream Events:
That's all folks! :)
Abonnieren
Posts (Atom)