Hello world!

Welcome to WordPress.com. After you read this, you should delete and write your own post, with a new title above. Or hit Add New on the left (of the admin dashboard) to start a fresh post.

Here are some suggestions for your first post.

  1. You can find new ideas for what to blog about by reading the Daily Post.
  2. Add PressThis to your browser. It creates a new blog post for you about any interesting  page you read on the web.
  3. Make some changes to this page, and then hit preview on the right. You can always preview any post or edit it before you share it to the world.

NetBeans 7.1

Netbeans 7.1 versiyonu ile beraber JavaFX 2.0 desteği eklendi.

Ayrıca masaüstü uygulamaları geliştirmede kullandığımız Swing GUI Builder geliştirildi. GridBagLayout’a Gap desteği eklendi. Javadoc kullanırken daha görsel hale getirebilmemizi sağlayan yeni formatlama özellikleri ile renklendirme özellikleri eklendi.

CSS 3 desteği eklendi. CSS yazarken kod tamamlama ve yeni CSS 3 elemanlarına destek geldi. Tarayıcılara özel özellikler eklendi.

Java EE tarafına da yeni özellikler eklenmiş durumda. Glassfish sunucusu üzerinde cluster ve instance deployment özelliği eklendi. WebLogic sunucusu için Java EE 6 ile geliştirilmiş uygulamalar geliştirilebiliyor. JSF bileşenlerine destek geldi. Ayrıca Java Persistence, Web Servisleri, EJB, WebLogic için yeni geliştirmeler yapılmış durumda.

PHP ile kod geliştiriciler için de bazı yenilikler var. Örneğin gelişmiş PHP debugging, PHPUnit test özellikleri, Smarty şablonları, FTP istemcileri için daha hızlı dosya yükleme özellikleri eklenmiş.

Eclipse’tekine benzer pencereleri görsel olarak yerleştirmek artık Netbeans’te de mümkün. Pencereler için Layout designer tasarlanmış. Güzel özelliklerden bir tanesi de versiyonlama ile ilgili geçmiş bilgilerine ulaşabildiğimiz History sekmesi.

Kaynak : Netbeans

EJB – Enterprise Java Beans

İki farklı kurumda ya da iki farklı yerde çalışan projeler olduğunu düşünelim. Bu farklı yerlerdeki projeleri birbirleri ile nasıl haberleştireceğiz? İşte uzakta çalışan uygulamaları birbirleri ile haberleştirmek için teknolojiler geliştirilmiştir. Bunlardan biri web servisleri, bir diğeri RMI’dır. EJB ise Java dünyasında kullanılan bir diğer haberleşme teknolojisinin ismidir.

EJB çalışma mantığı :

Öncelikle amacımız istemci tarafından, sunucudaki EJB sınıfına erişmek. Bunun için istemci tarafında bir nesne oluşturulması gerekiyor. Oluşturulan nesnenin aynı isimdeki metodunu çağırmalıyız. O da gidip sunucudaki aynı isimdeki metodu çağıracak. İstemci tarafındaki EJB’ymiş gibi kullanılan nesneye proxy objesi adı veriliyor. Bu proxy objesini biz kendisi EJB’ymiş gibi kullanıyoruz. Uzaktan kullanılabilecek metot listesini içerisinde barındırıyor. Dolayısıyla istemci tarafında Remote interface’e ihtiyacımız var. Oluşturulan proxy objesinin tipi de bu remote interface tipinde oluyor.

Üç tane EJB bileşeni vardır :

1-      Session Beans

  • Stateless Session Beans
  • Stateful Session Beans

2-      Entity Beans

3-      Message Driven Beans

Önemli : EJB kullanabilmek için uygulama sunucusunun mutlaka EJB Container’ı desteklemesi gerekir.

Stateless bean’ler, her istemci için yaratılan nesnenin bir havuzda saklanarak ihtiyaç duyulduğunda herhangi bir tanesini kullanmamızı sağlayan yapılardır. Stateful bean’lerde ise yapı tam ters şekildedir. Her bir istemcinin yaptığı her istek için bir instance oluşturulur. Dolayısıyla performans açısından sunucunun hafızası işgal edilmiş olur.

Stateless kullandığımızda sınıf değişkeni (global değişken) kullanmıyoruz. Çünkü istemci, her session bean istediğinde aynı bean instance’ına erişemeyebiliyor. Birden fazla istemciden gelen istekler aynı session bean tarafından yanıtlanabiliyor. Performans anlamında çok işimize yarıyor. Tüm istemciler için tek bir ejb instance’ı yaratılıyor. Herkes aynı nesneyi kullanıyor. Burada bean tek bir istemciye özel bilgi saklamıyor. Birçok istemcinin isteği aynı bean instance’ı tarafından cevaplanabiliyor. Bu da performans artırımı demek.

Bir session bean sınıfının stateless ya da stateful olduğunu annotation kullanarak söylüyoruz.

Genelde bir EJB çağırıyorsak peşinden de bir veri tabanı çağrımı yapılır. Çoğu projede bir veri tabanı kullanılıyor. Veri tabanı kullanmak, veri tabanına istek göndermek sıkıntılı bir işlem. SQL sorgularımızın yazıldığı katmanı, Connection’ın alındığı katmanı doğru yazmak, connection’ı açtıktan sonra kapatmayı unutmamak, aynı fonksiyonda iki farklı connection almamak gibi sıkıntılar var.

Bunun için EJB tarafında veri tabanına erişimi de kolay bir hale getirmek için frameworkler yazılmış. Bu frameworkler sayesinde veri tabanına connection açma, kapama işlemleri ile uğraşmadan erişip sorgu çekebiliyoruz. O kısımlar hazır kodlarla hallediliyor.

Entity bean’lerin çıkışı da yine bu amaçla olmuş. Veri tabanındaki her bir tablo için bir sınıf yaratıyoruz. Bu sınıflara entity bean deniyor.

5 tablomuz varsa, 5 tane bean yazılıyor. Tabloların özellikleri, ilişkileri bu sınıfların içerisinde tanımlanıyor.

Tablolarla uğraşırken tabloya karşılık gelen sınıfları istiyoruz. Muhattap olarak sadece sınıfları alıyoruz. Objelerle uğraşıyoruz. Bunun dışında veri tabanı ile ilgilenmiyoruz.

Entity bean’ler veri tabanına bağlanacak ama hangisi hangi connection bilgisi ile? Bunu da XML dosyasında tutuyoruz.

Message-driven bean’ler asenkron mesajlaşma için kullanılırlar. EJB’ler arasındaki haberleşmenin senkron olması gerekli değilse yani cevabını hemen beklemiyorsak asenkron haberleşmeyi kullanıyoruz. Mesajlarımızı bırakıyoruz bir ara okunuyor. Mesajların ne zaman okunacağı belli değil. Örneğin e-mail attık, karşı tarafın ne zaman okuyacağı bizi ilgilendirmiyor.

JMS API dediğimiz mesajlaşma servisi bir çok sınıf ve interface barındıran bir yapıdır.

Uygulama sunucusunun JMS’i desteklemesi için bazı ayarların yine sunucu tarafında yapılması gerekir.

Java Kodu ile Mail Gönderme Örnek Kod

Java Mail API sayesinde çok kolay bir şekilde elektronik posta atabiliyoruz. Tek yapmamız gereken http://www.oracle.com/technetwork/java/javamail/index-138643.html adresinden Java Mail API’nin son sürümünü indirerek uygulamamızın build path’ine eklemek.

Aşağıda gmail hesabından e-posta gönderen örnek bir kod yazıyorum.

[codesyntax lang=”java5″ lines=”no” blockstate=”expanded” doclinks=”0″]

package mail;

import java.util.Properties;

import javax.mail.Message;
import javax.mail.Session;
import javax.mail.Transport;
import javax.mail.internet.InternetAddress;
import javax.mail.internet.MimeMessage;

public class EPostaYolla {

	public static void main(String[] args) {
		try {
			// e-postayı göndereceğiniz adres
			String from = "erkin@javauzmani.com";
			// hesabınızın parolası
			String pass = "**********";
			// e-postanın gönderileceği adresler
			String[] to = { "erkin@infopark.com.tr" };
			// host
			String host = "smtp.gmail.com";

			Properties props = System.getProperties();
			props.put("mail.smtp.starttls.enable", "true");
			props.put("mail.smtp.host", host);
			props.put("mail.smtp.user", from);
			props.put("mail.smtp.password", pass);
			props.put("mail.smtp.port", "587");
			props.put("mail.smtp.auth", "true");

			Session session = Session.getDefaultInstance(props, null);
			MimeMessage message = new MimeMessage(session);
			message.setFrom(new InternetAddress(from));
			InternetAddress[] toAddress = new InternetAddress[to.length];
			for (int i = 0; i < to.length; i++) {
				toAddress[i] = new InternetAddress(to[i]);
			}

			for (int i = 0; i < toAddress.length; i++) {
				message.addRecipient(Message.RecipientType.TO, toAddress[i]);
			}
			// başlık
			message.setSubject("Merhaba Java Uzmanı!!!");
			// içerik
			message.setText("Bu Java kodu ile gönderilmiş bir elektronik postadır !!!");
			Transport transport = session.getTransport("smtp");
			transport.connect(host, from, pass);
			transport.sendMessage(message, message.getAllRecipients());
			transport.close();
		} catch (Exception e) {
			e.printStackTrace();
		}
	}
}

[/codesyntax]

[box type=”warning”] !!! Kodu test edebilmek için to isimli diziye kendi e-posta adresinizi giriniz !!![/box]

JUnit Örnek Uygulama

Özellikle yazımı devam büyük projelerde test işlemleri her zaman büyük bir problem olmuştur. Yeni eklenen bir özellik ya da değiştirilen bir metot hiç beklenmedik bir anda uygulamanın farklı yerlerini etkileyebilir.

JUnit, yazılan metotların döndürdüğü değerlerin kontrolü yani doğru çalışıp çalışmadığını anlayabilmek için tasarlanmış bir araçtır. Çoğu IDE (Integrated Development Environment) test araçlarına destek verir.

Lafı çok uzatmadan en basit haliyle JUnit kullanan bir proje yapalım.

Ben uygulamayı Eclipse 2.7 Indigo kullanarak yazacağım. Önce yeni bir proje yaratalım.

Sonra JUnit kütüphanelerini projemize ekleyelim.

Test edeceğimiz sınıfımızı yazıyoruz. Ben basit olsun diye dört işlem yapan bir sınıf yazdım.

package dortIslem;

public class Hesapla {

	double topla(int sayi1, int sayi2) {
		return sayi1 + sayi2;
	}

	double cikar(int sayi1, int sayi2) {
		return sayi1 - sayi2;
	}

	double carp(int sayi1, int sayi2) {
		return sayi1 * sayi2;
	}

	double bol(int sayi1, int sayi2) {
		return sayi1 / (double) sayi2;
	}
}

Kodu yazdıktan sonra yeni bir test case oluşturalım.

Test sınıfımıza dikkat edersek TestCase adındaki soyut bir sınıftan türüyor. Şimdi test edeceğimiz her bir metot için test sınıfında bir test metodu yazıyoruz.

package dortIslem;

import junit.framework.Assert;
import junit.framework.TestCase;

import org.junit.Before;
import org.junit.Test;

public class TestIslem extends TestCase {

	@Before
	public void setUp() throws Exception {
		System.out.println("Test metodu çağrılacak");
		super.setUp();
	}

	@Override
	protected void tearDown() throws Exception {
		System.out.println("Test metodu çalıştı bitti");
		super.tearDown();
	}

	@Test
	public void testTopla() {
		double sonuc = new Hesapla().topla(25, 2);
		Assert.assertEquals(27.0, sonuc);
	}

	@Test
	public void testCikar() {
		double sonuc = new Hesapla().cikar(25, 2);
		Assert.assertEquals(23.0, sonuc);
	}

	@Test
	public void testCarp() {
		double sonuc = new Hesapla().carp(25, 2);
		Assert.assertEquals(50.0, sonuc);
	}

	@Test
	public void testBol() {
		double sonuc = new Hesapla().bol(25, 2);
		Assert.assertEquals(12.6, sonuc);
	}
}

Buradaki setUp() metodu her bir test metodu çağrılmadan önce, tearDown() metodu ise sonra çalışacaktır.

Testi başlatmak için Run As -> JUnit Test dememiz yeterli.

Sonuçlara bakacak olursak ;

bol() metodu çalışmış ancak gönderilen parametrelerle istenilen cevap dönmemiştir.

Test metotları içerisinde kullandığımız assertEquals() gibi birçok hazır test metodu vardır. İhtiyaca göre bir tanesi seçilerek kullanılabilir.

JSP Sayfaları

JSP sayfaları, Servlet’ler gibi davranan text tabanlı dosyalardır.  JSP Engine adı verilen bir yapı ile JSP sayfasına istek geldiğinde aynı işi yapan bir Java sınıfı yaratılır. Bu sebeple JSP ve Servletleri aynı işi yapan yapılar olarak görebiliriz.

Application server’ın bulduğu dosya eğer bir JSP sayfası ise JSP_Engine adı verilen sınıf çalışarak bu sayfayı bir servlet class’ına çevirir. Oluşturulan bu sınıf derlenerek hafızaya yüklenir ve çalıştırılır. Bulunan dosya eğer bir Jsp sayfası değilse aynen geri döndürülür. Yani resimse resim, javascript ise javascript aynen geri döner.

JSP Engine tarafından yaratılan servlet sınıfı HttpJspPage interface’ini implement eder. HttpJspPage interface’i JspPage interface’inden, o da Servlet interface’inden extend ettiği için yaratılan sınıfın tüm bu interface’lerde tanımlanan metodları override etmesi gerekir.

JspPage arayüzünde jspInit() ve jspDestroy() metodları bulunur. jspInit() metodu servlet instance’ının yaratılması için kullanılır. Yaratılan sınıftaki herhangi bir metod çalışmadan önce bu metod çağrılır. jspDestroy() metodu container’ın instance’ı servis dışı bırakmaya karar verdiği anda çağrılır. Servlet instance’ında çağrılan son metodtur. jspInit() metodu ile yaratılan tüm kaynaklar bu metod çağrılarak yok edilir. Bu metod container tarafından çağrılır ancak kaynaklar yok edilirken yapılacak işler varsa bu metodu override etmek de mümkündür.

HttpJspPage arayüzünde _jspService() adı verilen bir metod tanımı bulunur. Bu metod o sınıfa yapılan her istekte çalıştırılır.

Bahsettiğimiz bu 3 metod servletlerdeki init(), destroy() ve service() metodlarına karşılık gelir.

Bir JSP sayfasına ilk kez erişildiğinde biraz yavaş çalışır. Daha sonrakilerde ise hızlanır. Bunun nedeni JSP sayfalarının servlet sınıflarına dönüştürülme işlemidir. Her istek için Jsp Engine, Jsp sayfası ile oluşturulmuş olan servlet sınıfı aynı mı diye kontrol eder. JSP değişmişse tekrar derleyerek yeni bir servlet sınıfı oluşturur.

                Bir JSP sayfasının yaşam döngüsü şu şekildedir :

  • Sayfa parse edilerek Java sınıfına dönüştürülür.
  • Compile edilir.
  • Hafızaya yüklenir.
  • instance yaratılır.
  • jspInit() metodu çağrılır.
  • _jspService() metodu çağrılır.
  • jspDestroy() metodu çağrılır.

İlk 4 adım JSP’nin servlete dönüşme adımlarıdır.

JSP’lerle servlet’lerde HTML kodu yazmaktan kurtuluruz. Jsp sayfaları HTML sayfalarına benzer yapıdadır. İçerisine bazı özel taglar ile Java kodu da yazılabilir. Bu sayede görsel bütünlük sağlanarak sayfalar tasarlanabilir. Ancak yine Java kodları ile HTML kodları birleşmiş ve aynı sayfada beraber kullanılmış olur. Ayrıca her sayfa için ayrı kod yazılmalıdır. Bundan kurtulmak için geliştirilmiş teknoloji JSTL (Java Standart Tag Library) JSTL ile hazır yazılmış Java kütüphaneleri hiç Java kodu yazmadan kullanılır.

HTML sayfaları ile JSP sayfaları arasındaki fark HTML sayfaları static içerikten oluşurken JSP sayfalarının içeriğinin değiştirilebilir olmasıdır.

Servlet’lerde kimlik denetimi

Servletlerde kimlik denetimi 4 yolla yapılabiliyor :

  1. HTTP BASIC AUTHENTICATION :

    Http 1.0’da tanımlandı. En kolay ve en çok kullanılan yöntem. Tarayıcı üzerinden korumalı bir kaynağa istek geldiği zaman, sunucu kullanıcı adı ve parola sorar. En başta tarayıcı korumalı bir kaynağa istek yaptığını bilmez. Normal HTTP isteği gönderir. Sunucu kaynağın korumalı olduğunu anlayınca “401 unauthorized” mesajını istemciye döndürür. Mesajın header bilgisinde basic authentication gerektiği bilgisi yazar. Hangi authentication’ın gerekli olduğu bilgisi realm’de yazar. (web.xml’deki bir bilgi)

Kullanımı:

  • İlk olarak url-pattern’da tanımlı olan kaynaklara erişim kısıtlaması olduğunu belirtiyoruz.
[codesyntax lang="php" lines="no"]
<web-resource-collection>
  <web-resource-name>SecurePages</web-resource-name>
  <description>Security constraint /secure</description>
  <url-pattern>/secure/*</url-pattern>
  <http-method>POST</http-method>
  <http-method>GET</http-method>
</web-resource-collection>
[/codesyntax]

Context path’de secure dizini altındaki kaynaklara GET ve POST methodları ile erişimin kısıtlı olduğunu tanımladık.

  • Sonra bu kaynaklara kimlerin erişebileceğini yani hangi role sahip kullanıcıların erişebileceğini tanımlıyoruz.
[codesyntax lang="xml" lines="no"]
<auth-constraint>
 <description>only let the admin users login</description>
 <role-name>admin</role-name>
</auth-constraint>
[/codesyntax]

Admin rolündeki tüm kullanıcıların bu sayfalara erişebileceği söylendi.

  • Daha sonra güvenli roller <security-role> taginde tanımlanır.
[codesyntax lang="xml" lines="no"]
<security-role>
  <description>The Only Secure Role</description>
  <role-name>admin</role-name>
</security-role>
[/codesyntax]

Son olarak da tomcat için tomcat-users.xml dosyasında roller ve bu rollere ait kullanıcılar belirlenir.

[box type=”info”] Her uygulama sunucusunda farklı şekilde belirtiliyor.[/box]

Avantajları : Kurması çok kolaydır ve tüm tarayıcılar tarafından desteklenir.

Dezavantajları : Kullanıcı adı ve parola şifrelenmemiştir. Kullanıcı adı ve parola soran dialog kutusunun görünümünü değiştiremeyiz.

2. HTTP DIGEST AUTHENTICATION :

Basic authentication ile aynı mantıkla çalışıyor. Bunda parola şifrelenerek gönderiliyor.

Avantajları : Basicten daha güvenli bir yöntemdir.

Dezavantajları : Sadece belli başlı tarayıcılar tarafından destekleniyor. Birçok servlet container tarafından desteklenmeyebilir.

3. HTTPS CLIENT AUTHENTICATION :

HTTP üzerinde SSL kullanılmış halidir. SSL (Secure Socket Layer) Netscape tarafından geliştirilmiş internette güvenli veri transferi yapmaya yarayan bir protokoldür.  Secure Sockets Layer (SSL) veri şifreleme, server authentication, mesaj bütünlüğü, TCP/IP bağlantılarında istemci authentication’ı destekler. Tarayıcı yani client ile server arasındaki bağlantı kurulduğunda authentication sağlanmış olur. Bütün veri public key yöntemiyle şifrelenir.

Avantajları : 4 yöntem arasındaki en güvenli olanıdır. Neredeyse tüm tarayıcılar tarafından desteklenir.

Dezavantajları : VeriSign gibi herhangi bir certification authority tarafından sertifika ister. Implemente etmek ve yürürlükte kalmasını sağlamak çok kolay değildir.

4. FORM-BASED AUTHENTICATION : 

Bu da Basic Authentication’a benzer. Yalnız tarayıcının pop-up dialog kutusunu kullanmak yerine html form kullanır.

Avantajları : Kurması çok kolay ve istediğimiz şekilde uyarı penceresi dizayn edebiliyoruz. Bütün tarayıcılar tarafından da destekleniyor.

Dezavantajları : Kullanıcı adı ve parola şifrelenmedği için pek de güvenli değil.

  • İlk önce web container’a Form Authentication’ı kullanmak istediğimizi söylüyoruz.
[codesyntax lang="xml" lines="no"]
<login-config>
  <auth-method>FORM</auth-method>
  <form-login-config>
    <form-login-page>/LoginForm.html</form-login-page>
    <form-error-page>/LoginError.html</form-error-page>
  </form-login-config>
</login-config>
[/codesyntax]

[box] Diğer yerler aynı.[/box]

İstersek

[codesyntax lang="xml" lines="no"]
<user-data-constraint>
  <description>SSL not required</description>
  <transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
[/codesyntax]

Tagini kullanarak veri transferinin nasıl yapılmasını istediğimizi belirtebiliriz.

3 seçeneğimiz var :

Transport Description
NONE Şifrelemeye gerek yok. HTTP yeterli.
CONFIDENTIAL Veri şifrelenmelidir. (SSL gibi)
INTEGRAL Verinin transferi sırasında değerinin korunması gerekir. Birçok sunucu SSL kullanır. Şifreleme gerekmediğinden bazı hashing algoritmaları kullanılabilir.

NONE’da veri transferinde bütünlük ve güvenilirlik garantisi verilmez. http üzerinden istek gönderilir.

INTEGRAL ve CONFIDENTAL’da ise bütünlük ve güvenilirlik garantisi verilir.

Örnek Filtre Uygulaması

Bir sınıfın filtre olduğunu container’a söylememiz gerekir. Bunun için ;

  1. Sınıf Filter arayüzünü implement etmelidir,
  2. web.xml dosyasında filtre tanımı ve mapping’i yapılmalıdır.

Eğer bir uygulamada birden fazla filtre varsa konfigurasyon dosyasında tanımlı oldukları sırayla çalışırlar.

[codesyntax lang="xml" lines="no"]
<filter>
    <filter-name>loginFilter</filter-name>
    <filter-class>com.javauzmani.filtreOrnekleri.filters.LoginFilter</filter-class> 
</filter> 
<filter-mapping> 
    <filter-name>loginFilter</filter-name> 
    <url-pattern>/*</url-pattern> 
</filter-mapping>
[/codesyntax]

<filter-class> filtre sınıfımızın proje içerisindeki yerini belirlediğimiz etikettir.

<url-pattern> ise hangi isteklerde filtrenin çalışacağını belirlediğimiz kısımdır. /* gibi bir ifadeyle gelen tüm isteklerin bizim filtremizden geçeceğini söylemiş oluruz.

Basit bir filtre sınıfının kodu da aşağıdaki gibi olacaktır.

[codesyntax lang="java" lines="no"]
package com.javauzmani.filtreOrnekleri.filters;

import java.io.IOException;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;

public class LoginFilter implements Filter {

	public void destroy() {
	}

	public void doFilter(ServletRequest req, ServletResponse response,
	        FilterChain chain) throws IOException, ServletException {
		System.out.println("filtre cagrildi.");
		HttpServletRequest request = (HttpServletRequest) req;
		HttpSession session = request.getSession();
		String url = request.getServletPath();
		if (url.equals("/index.jsp") || url.equals("/giris")) {
			chain.doFilter(request, response);
		} else if (session.getAttribute("login") != null) {
			chain.doFilter(request, response);
		} else {
			req.setAttribute("mesaj", "Önce giriş yapmalısınız.");
			request.getRequestDispatcher("/index.jsp").forward(request,response);
		}
	}

	public void init(FilterConfig filterConfig) throws ServletException {
	}
}
[/codesyntax]

Tüm filtrelerin Filter arayüzünü implement etmesi gerekir. Bu interface’de tanımlanan 3 metod vardır.

init() : Filtrenin yaşam evresi boyunca bir defa çağrılır. Bu metodun işi bitmeden container filtreye başka request göndermez. Servlet’in init() metodu gibi çalışıyor. Genellikle FilterConfig objesini implement etmek için kullanılır.

doFilter() : Servletteki service() metodu gibi. Filtreye gelen her istek için bu metod çalıştırılıyor. Bu metod içerisinden 3 iş yapılabiliyor. Request’i başka bir filtreye, başka bir kaynağa yönlendirebilir. Ya da kendisi cevap dönebilir. doFilter() metodunun parametresi olan request ve response, ServletRequest ve ServletResponse tipindedir. Yani sadece HTTP istekleri için geçerli değildir. Web uygulamasında HttpServletRequest ve HttpServletResponse objelerini ifade eder. Cast ederek bu tiplere ulaşırız.

        Bu metodun kullanımı filtreden filtreye değişir. Bazısında filtre URL’yi, parametreleri, başlıkları alıp bunları dosyaya yazabilir. (örneğin loglamak için) ya da güvenlik filtresi gelen isteği kaynağa yönlendirip yönlendirmeyeceğine karar verir. Bir başkası da ServletRequest ve ServletResponse parametre objelerini sarmalar, istek ve cevabı kısmen veya tamamen değiştirir. Ya da RequestDispatcher üzerinden include() ve forward() metodları ile yönlendirme yapar.

destroy() : Servletteki destroy() gibi. Filtrenin kaynakları bırakmak için kullandığı metod. Yaşam ömrü sona ermeden çalışır.

NOT : Filtreler her istek için iki defa çalışır.

  1. Request gönderilirken,
  2. Response dönerken.

Dolayısıyla yazmış olduğumuz kodda “filtre çağrıldı” konsola iki kez yazılacaktır.