Skip to content
Oca 24 / E. Basri Kahveci

Dün gecenin şarkısı

Dün gece yatmak üzere tam bilgisayarı kapatacakken, şu şarkıya denk geldim. Sen kimsin be ablam, niye karşılaşmadık daha önce?

Jehan Barbur – Öylesine

Senle benden önce tanışan insanları kıskandım yemin ediyorum

Ara 25 / E. Basri Kahveci

Integration Testing with Maven, Jetty and Selenium 2

For the last few days, I was busy with preparing a integration test environment for our PrimeFaces showcase. Showcase project was already a Maven project, so I made a little research about maven phases, maven plugins, Selenium and Jetty and figured out how can I make things work. You can see similar blog posts on Google about the topic. I looked at most of them and they helped me on the way.

First of all, maven already has 3 phases for integration testing: pre-integration-test, integration-test, post-integration-test. So I thought that on the pre-integration-test I can start Jetty and deploy the showcase, on the integration-test phase I can run the Selenium tests and on the post-integration-test I can stop Jetty. These steps can be done with Maven Jetty Plugin quite easily.

Another issue I had to deal with was separating integration tests from unit tests and running them only once at their own phases. I used Failsafe Maven Plugin to run the integration tests. Failsafe plugin is just like the Surefire plugin but it’s designed for integration testing. They explain the Failsafe quite well:

If you use the Surefire Plugin for running tests, then when you have a test failure, the build will stop at the integration-test phase and your integration test environment will not have been torn down correctly.

The Failsafe Plugin is used during the integration-test and verify phases of the build lifecycle to execute the integration tests of an application. The Failsafe Plugin will not fail the build during the integration-test phase thus enabling the post-integration-test phase to execute.

I also separated unit tests and integration tests by placing integration tests into the package “integration”, excluding test in the “integration” package for Surefire, and including them for Failsafe. So Surefire will run only the unit tests, which are not in the “integration” package, and Failsafe will run the tests in the “integration” package only.

Here is part of the pom for the plugins:

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-surefire-plugin</artifactId>
   <version>2.11</version>
   <configuration>
      <excludes>
         <!-- Exclude integration tests within (unit) test phase. -->
         <exclude>**/integration/**/*.java</exclude>
      </excludes>
      <encoding>UTF-8</encoding>
   </configuration>
</plugin>
 
<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-failsafe-plugin</artifactId>
   <version>2.11</version>
   <configuration>
      <includes>
         <include>**/integration/**/IntegrationTest*.java</include>
         <include>**/integration/**/*IntegrationTest.java</include>
      </includes>
      <encoding>UTF-8</encoding>
   </configuration>
   <executions>
      <execution>
         <goals>
            <goal>integration-test</goal>
            <goal>verify</goal>
         </goals>
      </execution>
   </executions>
</plugin>
 
<plugin>
   <groupId>org.mortbay.jetty</groupId>
   <artifactId>maven-jetty-plugin</artifactId>
   <version>6.1.16</version>
   <configuration>
      <scanIntervalSeconds>10</scanIntervalSeconds>
      <stopPort>9966</stopPort>
      <stopKey>stop</stopKey>
      <webAppConfig>
         <contextPath>/prime-showcase</contextPath>
      </webAppConfig>
   </configuration>
   <executions>
      <execution>
         <id>start-jetty</id>
         <phase>pre-integration-test</phase>
         <goals>
            <goal>run</goal>
         </goals>
         <configuration>
            <daemon>true</daemon>
         </configuration>
      </execution>
      <execution>
         <id>stop-jetty</id>
         <phase>post-integration-test</phase>
         <goals>
            <goal>stop</goal>
         </goals>
      </execution>
   </executions>
</plugin>

- Within Surefire’s configuration, I excluded the test classes which are in “integration” package.
- Within Failsafe’s configuration, I included the test classes which are in “integration” package and starts / ends with IntegrationTest. integration-test and verify goals are defined for integration-test phase.
- Within Jetty Plugin’s configuration, run and stop goals of the plugin are defined for pre-integration and post-integration phases respectively.
I do not explain the other parts, you can find information about them in plugins’ web sites.

Here is a sample integration test class resides under src/test.

package com.prime.showcase.integration.ajaxengine;
 
import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.equalTo;
 
import java.util.concurrent.TimeUnit;
 
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.support.ui.ExpectedCondition;
import org.openqa.selenium.support.ui.FluentWait;
 
public class AjaxCounterIntegrationTest {
 
	protected WebDriver driver;
 
	private String testUrl = "http://localhost:8080/prime-showcase/ui/pprCounter.jsf";
 
	@Before
	public void before() {
		driver = new FirefoxDriver();
	}
 
	@After
	public void after() {
		driver.quit();
	}
 
	@Test
	public void shouldIncreaseCounter() {
 
		driver.get(testUrl);
 
		WebElement button = driver.findElement(By.id(("j_idt14:j_idt17")));
 
		button.click();
 
		new FluentWait<WebDriver>(driver).withTimeout(10, TimeUnit.SECONDS).pollingEvery(2, TimeUnit.SECONDS).until(new ExpectedCondition<Boolean>() {
			public Boolean apply(WebDriver wd) {
				WebElement element = wd.findElement(By.id("j_idt14:txt_count"));
				return element.getText().equals("1");
			}
		});
 
		WebElement numberText = driver.findElement(By.id(("j_idt14:txt_count")));
 
		assertThat(numberText.getText(), equalTo("1"));
 
		button.click();
 
	}
}

With this configuration, when I type the “mvn integration-test” command from the terminal, Maven builds the project, runs the unit tests, starts Jetty and deploys the application, runs integration tests and stops Jetty.

You can also look the the pom.xml of the showcase project when we update it on the SVN repository.

ps: Here are the dependencies for the example test class:

<dependency>
	<groupId>org.seleniumhq.selenium</groupId>
	<artifactId>selenium-java</artifactId>
	<version>2.15.0</version>
</dependency>
 
<dependency>
	<groupId>org.hamcrest</groupId>
	<artifactId>hamcrest-all</artifactId>
	<version>1.1</version>
	<scope>test</scope>
</dependency>
 
<dependency>
	<groupId>junit</groupId>
	<artifactId>junit</artifactId>
	<version>4.8.2</version>
	<scope>test</scope>
</dependency>
Kas 22 / E. Basri Kahveci

Basit yaşamak

gecenin şarkısı.

“basit yaşayacaksın. basit
mesela susayınca su içecek kadar basit…
dört çıkacak, ikiyi ikiyle çarptığında.
tek düğmesi olacak elindeki cihazın;
tek bir düğme, tek bir cümle gibi…
sevince lafı dolandırmadan söylediğin
‘seni seviyorum’ gibi.
basit bir öpücük yetecek sana…
basit, sıcak bir öpücük;
ve o öpücükle dolacak tüm günlerin,
tüm düşlerin.
o öpücük için yapacaksın hayatının kavgasını,
öpücük için yiyeceksin hayatının dayağını. ”

gecenin şiiri.

şarkı

şiir

iyi geceler. zor iş basit yaşamak

 

 

Kas 17 / E. Basri Kahveci

Adımla Nasıl Berabersem

hacet yok hatırlatmasına seni hatıraların
bir dakika bile çıkmıyorsun aklımdan
koşar gibi yürüyüşün
karanlıkta bir ışık gibi aydınlık gülüşün
hacet yok hatırlatmasına seni hatıraların
uzak uzak yıldızlarla çevrilmiş kainatın
karanlık boşluklarında akıp giderken zaman
adımla nasıl berabersem öylece beraberiz
seninle her saat seninle her dakika seninle her saniye
gönlümüz mutluluğa inanmış olmanın gururuyla rahat
koltuğumuzun altında birer dinamit gibi kellemiz
ve sonra her zaman her ölümlüye
aynı şartlar altında kısmet olmıyan
gerçekleri görmenin aydınlığı alınlarımızda
hacet yok hatırlatmasına seni hatıraların
sen bana kalbim kadar elim kadar yakınsın

Attila İLHAN

Kod yazarken şiir okuyunca çok feci aşka geliyorum yeminlen.

Kas 11 / E. Basri Kahveci

Ne zaman sorusuna cevaben

Dilimde sabah keyfiyle yeni bir umut türküsü
Kar yağmış dağlara, bozulmamış ütüsü
Rahvan atlar gibi ırgalanan gökyüzü
Gözlerimi kamaştırsa da geleceğim sana
Şimdilik bağlayıcı bir takvim sorma bana
Ihlamurlar çiçek açtığı zaman.

Ay, şafağa yakın bir mum gibi erimeden
Dağlar çivilendikleri yerde çürümeden
Bebekler hayta hayta yürümeden
Geleceğim diyorum, geleceğim sana
Ne olur kesin bir takvim sorma bana
Ihlamurlar çiçek açtığı zaman.

Beklesen de olur, beklemesen de
Ben bir gök kuruşum sırmalı kesende
Gecesi uzun süren karlar-buzlar ülkesinde
Hangi ses yürekten çağırır beni sana
Geleceğim diyorum, takvim sorma bana
Ihlamurlar çiçek açtığı zaman.

Bu şiir böyle doğarken dost elin elimdeydi
Sen bir zümrüd-ü ankaydın, elim tüylerine deydi
Sevda duvarını aştım, sendeki bu tılsım neydi?
Başka bir gezegende de olsan dönüşüm hep sana
Kesin bir gün belirtemem, n`olur takvim sorma bana
Ihlamurlar çiçek açtığı zaman.

Eski dikişler sökülür de kanama başlarsa yeniden
Yaralarıma en acı tütünleri basacağım ben
Yeter ki bir çağır beni çiçeklendiğin yerden
Gemileri yaksalar da geleceğim sana
On iki ayın birisinde, kesin takvim sorma bana
Ihlamurlar çiçek açtığı zaman.

Bak işte, notalar karıştı, ezgiler muhalif
Hava kurşun gibi ağır, yağmursa arsız
Ey benim alfabemdeki kadîm Elif
Ne güzellik, ne de tat var baharsız
Güzellikleri yaşamak için geleceğim sana
Geleceğim diyorum, biraz mühlet tanı bana
Ihlamurlar çiçek açtığı zaman.

Ihlamurlar çiçek açtığı zaman
Ben güneş gibi gireceğim her dar kapıdan
Kimseye uğramam ben sana uğramadan
Kavlime sâdıkım, sâdıkım sana
Takvim sorup hudut çizdirme bana
Ben sana çiçeklerle geleceğim
Ihlamurlar çiçek açtığı zaman.

Bahaeddin KARAKOÇ

Eki 22 / E. Basri Kahveci

Aşk Üzerine’den

Her aşık oluş (Oscar Wilde’a kulak verecek olursak) umudun kendini bilmişliğe karşı zaferidir. Kendimizde gördüklerimizi, onda görmemeyi umarak aşık oluruz – yani korkaklıklarımızı, zayıflıklarımızı, tembelliğimizi, sahtekarlıklarımızı, verdiğimiz ödünleri ve aşırı aptallıklarımızı. Sanırız ki seçtiğimiz kişinin çevresine aşk koridorunu sarınca içindeki tüm hatalardan arınacak ve tabii sevilesi olacak. Kendimizde göremediğimi mükemmelliğimizi buluruz ötekinde ve aşk yoluyla onunla birleşerek, (öyle olmayacağını bile bile) insanoğlunu olan şüpheli inancımızı korumaya çalışırız.

Alain de Botton abimin yalancısıyım, severek okuyorum şu an kendisini.

Eki 21 / E. Basri Kahveci

Configuring Spring Security to persist the SecurityContext to places other than session between requests

Yeah I agree, I suck at titles :) But, again and again, Spring guys are cool ass kickers :)

By default, Spring Security keeps the SecurityContext in session objects of user between requests. SecurityContextPersistenceFilter manages this task. When a request comes, it reads the SecurityContext from a security context repository (which I will mention now), puts it to SecurityContextHolder to be used by other filters and the application. And when request is completed, it clears the SecurityContextHolder and puts the SecurityContext to the repository. The repository I mentioned here is the HttpSessionSecurityContextRepository class which is an implementation of SecurityContextRepository interface. This interface is responsible for persisting SecurityContext objects between requests and used by SecurityContextPersistenceFilter.

For a requirement we get, we need to read the logged in user information from memcached, not the http session. With a little investigation, we saw the SecurityContextRepository interface and its default HttpSessionSecurityContextRepository implementation. We figured out that with a custom implementation of that interface, Spring Security will still work quite well for our situation. So we coded our implementation and tried to inject it into the SpringSecurityContextPersistenceFilter.

Configuring Spring Security to use the custom repository was a more challenging task than writing a custom implementation for us because we could not see a point for the configuration :) In the reference documentation, the bean definition below is given:

<bean id="securityContextPersistenceFilter" class="org.springframework.security.web.context.SecurityContextPersistenceFilter"> 
    <property name='securityContextRepository'>
        <bean class='org.springframework.security.web.context.HttpSessionSecurityContextRepository'>
            <property name='allowSessionCreation' value='false' /> 
       </bean>
    </property>
</bean>

And this explanation is given:

Alternatively you could provide a null implementation of the SecurityContextRepository interface, which will prevent the security context from being stored, even if a session has already been created during the request.

(Section 8.3)

So we copied the bean definition above and replaced the default repository with ours.

When we started the application, we traced the logs and saw that Spring Security was still using the default http session repository instead of our repository.

After a little bit more investigation, we understood that we had to use the “security-context-repository-ref” attribute of “http” namespace in configuration. Although a SecurityPersistenceContextFilter bean definition is provided, when “http” namespace is used, Spring Security creates its own SecurityPersistenceContextFilter with defaults. So to customize it, “security-context-repository” attribute must be used.

So here is the appropriate configuration:

<sec:http auto-config="false" security-context-repository-ref="memcachedSecurityContextRepository">
	<!-- ... -->
</sec:http>
 
<bean id="memcachedSecurityContextRepository" class="...MemcachedSecurityContextRepository" />

We could not understand why Section 8.3 of the Spring Security reference does not state this.

I also wrote a similar post on a related question on the stackoverflow which you can have a look with this link: http://stackoverflow.com/questions/2504590/how-can-i-use-spring-security-without-sessions/7653699#7653699

Also javadocs are quite useful:
http://static.springsource.org/spring-security/site/docs/3.0.x/apidocs/org/springframework/security/web/context/SecurityContextPersistenceFilter.html
http://static.springsource.org/spring-security/site/docs/3.0.x/apidocs/org/springframework/security/web/context/SecurityContextRepository.html

Eki 7 / E. Basri Kahveci

The “Java Life” Rap Music

In the cubicles representin’ for my JAVA homies…
In by nine, out when the deadlines are met, check it.

CHORUS:
We code hard in these cubicles
My style’s nerd-chic, I’m a programmin’ freak
We code hard in these cubicles
Only two hours to your deadline? Don’t sweat my technique.

Sippin’ morning coffee with that JAVA swirl.
Born to code; my first words were “Hello World”
Since 95, been JAVA codin’ stayin’ proud
Started on floppy disks, now we take it to the cloud.

On my desktop, JAVA’s what’s bobbin’ and weavin’
We got another winning app before I get to OddEven.
Blazin’ code like a forest fire, climbin’ a tree
Setting standards like I Triple E….

Boot it on up, I use the force like Luke,
Got so much love for my homeboy Duke.
GNU Public Licensed, it’s open source,
Stop by my desk when you need a crash course

Written once and my script runs anywhere,
Straight thuggin’, mean muggin’ in my Aeron chair.
All the best lines of code, you know I wrote ‘em
I’ll run you out of town on your dial-up modem.

CHORUS:
‘Cause…
We code hard in these cubicles
Me and my crew code hyphy hardcore
We code hard in these cubicles
It’s been more than 10 years since I’ve seen the 404.

Inheriting a project can make me go beeee-serk
Ain’t got four hours to transfer their Framework.
The cleaners killed the lights, Man, that ain’t nice,
Gonna knock this program out, just like Kimbo Slice

I program all night, just like a champ,
Look alive under this IKEA lamp.
I code HARDER in the midnight hour,
E7 on the vending machine fuels my power.

Ps3 to Smartphones, our code use never ends,
JAVA’s there when I beat you in “Words with Friends”.
My developing skills are so fresh please discuss,
You better step your game up on that C++.

We know better than to use Dot N-E-T,
Even Dan Brown can’t code as hard as me.
You know JAVA’s gettin’ bigger, that’s a promise not a threat,
Let me code it on your brain

WHISPERED:
so you’ll never forget.

CHORUS:
We code hard in these cubicles,
it’s the core component…of what we implement.
We code hard in these cubicles,
Straight to your JAVA Runtime Environment.

We code hard in these cubicles,
Keep the syntax light and the algorithm tight.
We code hard in these cubicles,
Gotta use JAVA if it’s gonna run right.

We code hard in these cubicles
JAVA keeps adapting, you know it’s built to last.
We code hard in these cubicles,
Robust and secure, so our swag’s on blast

CODE HARD!

Eki 3 / E. Basri Kahveci

Extending Spring’s OpenSessionInViewFilter to not open sessions for request to static resources

If you are using OpenSessionInViewFilter in your application, you may be opening sessions for requests which don’t actually do any session-related things, simply accessing to css, javascript or image files. When you get your requests like images, js files with static urls not from servlets, the case will not happen. But for example, if you use JSF and map your “*.jsf” urls to Faces Servlet and filter it with OpenSessionInView filter to avoid lazy loading exceptions in your facelets, JSF fill send requests to your Faces Servlet to load resources like images, css files, js files and you will open session for those request too although not necessary.

To avoid this, it’s an option to extend Spring’s OpenSessionInViewFilter and ignoring requests of that kind. Thank to Spring guys, it’s too much easy.

OpenSessionInViewFilter is extended from OncePerRequestFilter class. OncePerRequestFilter class is implemented the doFilter() method in a Template Method pattern way. It has shouldNotFilter(request) and doInternalFilter(request, response) methods. shouldNotFilter() method is put there to be implemented by subclasses and it simply returns false in OncePerRequestFilter class. In OpenSessionInViewFilter, doInternalFilter is implemented to handle to session-related stuff and shouldNotFilter method is not overrided to filter all the requests and open sessions for them.

So, to avoid not opening sessions for some kinds of requests, its is enough to extend OpenSessionInViewFilter and override the shouldNotFilter() method for the URLs that you don’t want to filter. For the JSF situation, you can write a method like this:

 
public class MobileMeOpenSessionInViewFilter extends OpenSessionInViewFilter {
 
	@Override
	public boolean shouldNotFilter(HttpServletRequest request) {
		return request.getRequestURI().contains("javax.faces.resource");
	}
 
}

If you put this filter to your web.xml instead of OpenSessionInViewFilter, you will not open sessions for the requests like “javax.faces.resource/jsf.js.jsf” no more.

Viva la resistance!

Eki 3 / E. Basri Kahveci

Writing a custom Facelet EL function makes authorization check using Spring Security

It’s common that you may want to show some part of your pages to the user with certain roles. Writing a custom Facelet EL function makes doing authorization checks for viewing parts of pages really easy. If you are using Spring Security in the background, you can use its SecurityContext object to get authorities of the user and use them in your EL function implementation.
read more…

Sayfalar: 1 2 3 4 5 6 7 8 9 10 ...12 13 14 Sonraki
Sayfalar: 1 2 3 4 5 6 7 8 9 10 ...12 13 14 Sonraki