Ucundan Java

equals() Metodu Nasıl Yazılmalı

2011-12-24T10:44:00.000+02:00

Yeni mezun meslektaşlarımızın List, Map, Set türevi veri yapılarında nesneleri konumlandırdıkları zaman nesnelerin equals ve hashCode metotlarını hazırlamamaları yaygın bir unutkanlıktır. List bileşenine koydukları nesne nedense contains() kontrolünde kaybolur. Sorunun çözümünü de benzer olayları önceden yaşamış ve kaynağını az çok tahmin eden tecrübeli yazılım geliştiricen gelir. equals ve hashCode metotlarının sınıf için gerçekleştirimi unutulmuştur. List ve Set sınıfları barındırdıkları nesnelerin eşitliğini bu iki metodu kullanarak kontrol ederler

Ne var ki equals ve hashCode metotları tecrübeli geliştiriciler tarafından bile olması gerektiği gibi hazırlanmıyor. Bu yazımda "Effective Java" kitabında yer alan "Item 8: Obey the general contract when overriding equals" bölümüne referans göstererek ideal bir equals metodunun nasıl olması gerektiğine değineceğim.

İlk uyulması gereken kural basit. "En iyi kod yazılmamış kodtur" ilkesini benimsemiş gibi: Eğer sınıfın her bir nesnesi sadece kendisiyle eşit olacak ise, yani sadece aynı bellek alanına referans gösteren değişkenler birbirleriyle eşit olacak ise sınıfta equals metodu yazmayın. Her Java sınıfının türediği Object sınıfının equals metodu bu bellek kontrolünü üstlenmiş durumda zaten. Böyle bir durumu oluşturabilecek senaryolar ise şu şekilde listeleniyor:

Sınıfın değerleri üzerinden işlevsel bir eşitlik gerektirmiyorsa: Örneğin java.util.Random sınıfının görevi rasgele sayılar üretmektir. İki Random sınıfının birbirine eşit olup olmaması işlevsel bir eşitlik kontrolü gerektirmez.
Atasınıfın (superclass) ihtiyacı karşılayacak şekilde gerçekleştirilmiş halihazırda bir equals metodu varsa: Çoğu Set gerçekleştirimi AbstractSet, List gerçekleştirimleri ise AbstractList atasınıfının equals metodunu kullanır.
Eğer sınıf private ve package-private ise ve sınıflar üzerinde eşitlik kontrolü yapılmayacağı kesinse
Sınıfın sadece yaratılmış tek bir olgusu olacak ise: Singleton sınıflar

Özetle sınıfımızın eşitliği, barındırdığı değişkenlerin değerleri üzerinden anlam ifade ediyorsa ve atasınıfta bu değerler üzerinden eşitlik kontrolünü sağlayacak metot yoksa sınıfımız için bir equals metodu yazmalıyız.

Peki ideal bir equals nasıl olmalı? Matematik derslerinden hatırlayacağımız aşağıdaki 5 kriteri de karşılamalı:

Dönüşlü: null olmayan her x değeri için x.equals(x)'in sonucu true olmalı.
Simetrik: null olmayan her x, y değerleri için x.equals(y) sadece y.equals(x) sonucu true ise true olmalı.
Geçişli: null olmayan her x, y, z değerleri için x.equals(y) ve y.equals(z) sonuçları true ise x.equals(z) sonucu da true olmalı.
Tutarlı: eşitlik kontrolünde kullanılan değişkenlerin değerleri değişmediği sürece x.equals(y) sonucu her zaman ya hep true ya da hep false olmalı.
null olmayan her x için x.equals(null) sonucu hep false olmalı

Bu eğlenceli matematiksel kriterleri sağlayamayan her equals metodu uygulamamızda sıkıntı yaratacak ve hatanın kaynağı bulmak da belki uzunca bir süre mümkün olmayacaktır. Bu kriterlere biraz yakından bakalım:

Dönüşlü

Basitçe, her bir nesne kendisine eşit olmalı. Bu kriteri bozacak bir gerçekleştirimde, List'e eklediğimiz nesnemizi contains metoduyla sorguladığımızda karşılaşacağımız sonuç olumsuz olacaktır.

Simetrik

Simetri kriterini aşağıdaki örnek kod kırıyor. (Örnek kodlar Effective Java kitabından alınmıştır):

// Broken - violates symmetry!

   public final class CaseInsensitiveString {
       private final String s;

       public CaseInsensitiveString(String s) {
           if (s == null)

               throw new NullPointerException();
           this.s = s;

}

       // Broken - violates symmetry!

       @Override public boolean equals(Object o) {
           if (o instanceof CaseInsensitiveString)

               return s.equalsIgnoreCase(
                   ((CaseInsensitiveString) o).s);

           if (o instanceof String)  // One-way interoperability!
               return s.equalsIgnoreCase((String) o);

           return false;
       }

       ...  // Remainder omitted
   }

CaseInsensitiveString cis = new CaseInsensitiveString("Polish");String s = "polish";

Burada cis.equals(s) kontrolü true dönerken s.equals(cis) kontrolü ise false değerini dönecektir. Problemin kaynağı CaseInsensitiveString sınıfının equals metodu, karşılaştırmayı büyük/küçük harf ayırtmaksızın yaparken, String sınıfının equals metodunun bu ayrımı yapmamasından kaynaklanmaktadır.

List list = new ArrayList();

list.add(cis);

Yukarıdaki gibi bir senaryoda yapılan list.contains(s) kontrolü kodun üzerinde çalıştığı Java gerçekleştirimine göre true ya da false dönebilir. "Benim bilgisayarımda çalışıyordu" dememek için hastalıklı kodu düzeltmeliyiz. Karşılaştırmada String sınıfı aradan çıkartılmalı:

@Override public boolean equals(Object o) {
       return o instanceof CaseInsensitiveString &&

           ((CaseInsensitiveString) o).s.equalsIgnoreCase(s);

}

Geçişli

Bu kriteri kırmak da çok zor değil. Point sınıfından türeyen bir ColorPoint sınıfında koordinatlara ek olarak getirilen renk değişkeni equals metoduna eklenince olanlar oluyor:

public class Point {
       private final int x;
       private final int y;
       public Point(int x, int y) {

this.x = x;
this.y = y;}

       @Override public boolean equals(Object o) {
           if (!(o instanceof Point))

               return false;
           Point p = (Point)o;
           return p.x == x && p.y == y;

}

       ...  // Remainder omitted
}



   public class ColorPoint extends Point {
       private final Color color;
       public ColorPoint(int x, int y, Color color) {
           super(x, y);
           this.color = color;
       }
       ...  // Remainder omitted
   }

// Broken - violates transitivity!

   @Override public boolean equals(Object o) {
       if (!(o instanceof Point))

           return false;

       // If o is a normal Point, do a color-blind comparison
       if (!(o instanceof ColorPoint))

           return o.equals(this);

       // o is a ColorPoint; do a full comparison

       return super.equals(o) && ((ColorPoint)o).color == color;
   }

  ColorPoint p1 = new ColorPoint(1, 2, Color.RED);
Point p2 = new Point(1, 2);
ColorPoint p3 = new ColorPoint(1, 2, Color.BLUE);

p1 ile p2, p2 ile p3 birbirlerine eşit iken p1 ile p3 birbirine eşit olmalıyken maalesef eşitlik kontrolü bize false değerini dönecektir. Java kütüphanesinde bu kriteri kıran sınıflar bulmak mümkün. Örneğin Date ve Timestamp sınıfları. Ayrıntılı değerlendirmeyi "Effective Java" kitabından edinebilirsiniz.

Bu sorun için çözüm ise gene bir Object Oriented tasarım ilkesini adres gösteriyor. "is-a ilişkisi yerine has-a" ilişkisi kullanmak. Point sınıfından ColorPoint sınıfı türetmek yerine ColorPoint sınıfı içerisinde Point sınıfının referansını barındırsın.

Tutarlılık

Eşitlik kontrolü yapılacak değişkenler her zaman tutarlı değerlere sahip olmalıdır. Örneğin java.net.URL sınıfının eşitlik kontrolü IP adresi ile ilişkilendirilen host name değişkeni üzerinden yapılıyor. Bu yüzden ağ erişiminin yanı sıra host name ile ilişkilendirilmiş IP adresi de değişebilir. Sağlıklı bir karşılaştırma her zaman yapılamayacaktır.

Equals metodu için bu olmazsa olmazların yanında sorguyu hızlandıracak ve kesirli değerler için equals yerine Float.compare() ya da Double.compare() kullanmanız gerektiğini söyleyen bir çok minik ipucunu "Effective Java" kitabında bulabilirsiniz. Kitabın Java ile geliştirim yaparken dikkat edilmesini önerdiği diğer konular da her Java geliştiricisi tarafından sindirilip kod yazarken uygulanmalı. Kitaptan bir tane edinin derim :)

JSF ve Spring Security ile Önceden Kimlik Kontrolü Yapılmış Kullanıcı için Login Sayfasının Tekrar Gösterilmemesi

2011-11-25T07:45:00.001+02:00

Başlık biraz uzun oldu ama anlatacağım konuyu başlıkta ancak bu kadar özetleyebildim. Özetin açıklamasını yapmaya çalışırsak: web uygulamasına giriş yapmış, yani kimliğini doğrulatmış bir kullanıcı, belirli sayfalara istekte bulunduğunda (örneğin login sayfası için tekrar istek gönderirse) zaten yetkilendirildiğini belirleyip isteği başka bir sayfaya yönlendirmek (örneğin login sayfasından sonra gösterilecek index sayfasına) istiyoruz.

Spring Security'de bu işin kolay yolu var mıdır diye küçük bir araştırma yaptık ama ya doğru kelimeleri yine bulamadık ki blog başlığı seçerken de yaşadım aynı sıkıntıyı ( :) ) ya da diğerler geliştiriciler böyle bir gereksinime ihtiyaç duymamışlar. İlki seçenek akla daha yatkın..

Çalışma arkadaşım Basri Kahveci'nin önerdiği ve bir projede uyguladığı yöntem de aklıma yatmayınca (Çalışıyor ama biraz kulağı tersten tutmak gibiydi :)) Küçük bir "Nasıl yapabiliriz?" düşünmesinin ardından aslında basit bir JSF PhaseListener kullanarak yapılabileceğini farkettim.

Bildiğiniz üzere JSF yaşam döngüsü temel olarak 6 adımdan oluşur (Yaşam döngüsünü detayıyla incelemek isterseniz BalusC bu konuda emek harcamış):

Kısaca hatırlamak gerekirse Request parametresi barındıran bir istek bu 6 adımdan geçerek kullanıcıya hedef sayfa döndürülür. Bir sayfaya yapılan ilk istek, yani parametre barındırmayan bir istek ise ilk adımdan sonra yaşam döngüsünü dolaşmak yerine Render Response adımına yönlendirilip kullanıcının istediği sayfa gösterilir. Her adımda gerçekleşen işlemleri isterseniz başka bir blog girdisinde bahsederiz.

JSF bize bu adımların arasına girebilmek için PhaseListener interface'ini kullanıma sunuyor. Görüldüğü gibi PhaseListener'da 3 metot mevcut. İkisi yaşam döngüsü adımlarının herbirine girerken ve herbirinden çıkarken işletilecek kodları barındırırken, üçüncü metot da hangi adımda bu listener'ın çalıştırılması gerektiğini belirtmemize olanak sağlıyor. Bu metotta PhaseId.ANY_PHASE gibi bir değer döndürerek her bir adım için listenerın tetiklenmesini sağlayabileceğimiz gibi PhaseId.RENDER_RESPONSE benzeri bir değerle belirli bir adımda tetiklenmesini de sağlayabiliyoruz.

Bizim senaryomuzda da login sayfamız render olmadan önce bir PhaseListenerın tetiklenmesini sağlayarak, kullanıcının önceden sisteme giriş yapıp yapmadığını belirleyip gerekiyorsa başka bir sayfaya yönlendirme işlemini yapmak mümkün:

public class AuthPhaseListener implements PhaseListener {

 @Override
 public void afterPhase(PhaseEvent event) {
 }

 @Override
 public void beforePhase(PhaseEvent event) {
  User user = (User)SecurityContextHolder.getContext().getAuthentication().getPrincipal();
  if(user != null){
   FacesContext.getCurrentInstance().getExternalContext().redirect("main");
  }

 }

 @Override
 public PhaseId getPhaseId() {
  return PhaseId.RENDER_RESPONSE;
 }

}

beforePhase() metodu içinde Spring Security'nin SecurityContextHolder'ı ile sessionda kayıtlı bir kullanıcı olup olmadığını kontrol ettik. Eğer bir kullanıcı nesnesi elde edebiliyorsak FacesContext ile de basitçe yönlendirme işlemini yapıyoruz.

Geriye yazdığımız bu listener sınıfını projemize entegre etmeye geldi. Eğer listener tanımını faces-config.xml içerisinde yaparsak her sayfa için işletilecek yaşam döngüsünde sınıfımız tetiklenecektir. Bizim istediğimiz sadece login sayfasında bunu tetiklemek. O yüzden tanımı listenerı kullanmak istediğimiz sayfa bazında yapmamız gerekli. JSF sayfamıza şu tag'i eklemek yeterli:

<f:phaseListener type="com.prime.dasgin.AuthPhaseListener"/>

JSF kullanılmayan projelerde benzer bir mantık web.xml'de tanımlanan Servlet Filter'lar ile de gerçekleştirmek mümkündür. Login sayfasına yapılacak olan bir istekte devreye girecek bir Filter tanımlamak ve benzer bir süreci içinde işletmek sorunu çözer.

MySQL'in String karşılaştırması

2011-10-16T18:22:00.000+03:00

Var olan bir projeye sonradan katıldıysanız ya da proje ekibinizde veritabanı işlerini yöneten bir takım arkadaşınız varsa MySQL'in string karşılaştırmasının nasıl çalıştığı ile ilgili bilginiz olmayabilir. Ve vakit gelip de yeni bir projenin veritabanını oluşturma ihtiyacı duyduğunuzda ve iş başa düştüyse MySQL karakter encoding ve string karşılaştırmayla ilgili anlatacağım bu konu size zaman kazandıracaktır.

MySQL'de nonbinary string tipleri (char, varchar, text) büyük küçük harf ayırmaksızın karşılaştırılır. Örneğin username like 'admin' gibi bir sorgu koşulunda dönen sonuçlar içinde username'i admin, ADmin, ADMIN, vb. olan kayıtlar da getirilecektir.

Böyle bir sonucu engellemek için ya veritabanı oluşturulurken schema tanımının collation tipini ya da sorunu yaşadığınız kolonun collation tipini binary olacak şekilde ayarlamanız gerekiyor:

CREATE DATABASE mobileme CHARACTER SET utf8 COLLATE utf8_bin;

ya da

ALTER TABLE table_name MODIFY username VARCHAR(25) CHARACTER SET utf8 COLLATE utf8_bin;

Varolan schema'da böyle bir sıkıntınız varsa tüm schema'nın collate tipini değiştirmek için aşağıdaki sorgunun ürettiği sorgucukları işletmeniz yeterli:

SELECT CONCAT('ALTER TABLE `', t.`TABLE_SCHEMA`, '`.`', t.`TABLE_NAME`, '` CONVERT TO CHARACTER SET utf8 COLLATE utf8_bin;') as stmt
FROM `information_schema`.`TABLES` t
WHERE 1
AND t.`TABLE_SCHEMA` = 'schema_name'
ORDER BY 1;

Türkçe Maven Rehberi

2011-04-25T10:25:00.000+03:00

"Kahvenin Hatırı" adlı blogta Sonatype'ın Maven belgelerinin Türkçe'ye çevrilmiş hallerine ulaşabilirsiniz. Son blog girdilerinde Maven ile ilgili örnekler de mevcut. Emeği geçen arkadaşa teşekkür ederiz:

http://kahveninhatiri.blogspot.com/2011/04/turkce-maven-rehberi.html

JSF 2.0 ve Composite Components

2011-04-17T12:39:00.002+03:00

JSF 1.2 ve Facelets ile halihazırdaki bileşenleri biraraya getirip yeni bir tag yaratarak tek bir bileşen olarak kullanabiliyorduk. Bunun için izlenen adımlar:

1) Biraraya getirilecek bileşenlerin .xhtml dosyasında <ui:composition> tagi altında yazılması.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
  xmlns:ui="http://java.sun.com/jsf/facelets"
  xmlns:h="http://java.sun.com/jsf/html">
  
 <ui:composition>
  <h:outputLabel value="#{label}" for="#{id}"/>
  <h:inputText id="#{id}" value="#{value}"/>
 </ui:composition>
  
</html>

2) Hazırlanan bu .xhtml dosyasının namespace'i belirtilmiş *.taglib.xml içerisinde ismi ve dosya adresini belirten bir tag olarak tanımlanması.

<?xml version="1.0" encoding="UTF-8"?>
<facelet-taglib xmlns="http://java.sun.com/xml/ns/javaee"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd"
                version="2.0">

    <namespace>http://mdasgin.blogspot.com/custom</namespace>
    
    <tag>
     <tag-name>myInput</tag-name>
     <source>tags/customTag.xhtml</source>
    </tag>
</facelet-taglib>

3) *.taglib.xml' in web.xml'de tanımının yapılması.

<context-param>
 <param-name>javax.faces.FACELETS_LIBRARIES</param-name>
 <param-value>
        /WEB-INF/taglibs/custom.taglib.xml;
    </param-value>
</context-param>

4) Yeni yaratılan tag'in kullanılmak istendiği yerde namespace ve tag ismi belirtilerek kullanılmasını içermekteydi.

<html xmlns:m="http://mdasgin.blogspot.com/custom">
..
<m:myInput id="myInput" label="Username" value="#{user.name}"/>
..
</html>

Ne var ki bu şekilde Facelets ile yapılan yeni bileşen yaratma işleminde yaratılan bileşene sadece Value Expression tanımları geçilebiliyordu. Örneğin h:inputText'in yanına h:commandButton bileşeni ekleyerek commandButton'un kullanımına <m:myInput action="#{user.save}"> gibi bir Method Expression parametresi veremiyorduk.

Neyseki JSF 2.0 ile gelen Composite Components özelliği ile geliştiriciyi yoran gereksiz adımlardan ve yeni bileşenimize method expression aktaramama gibi kısıtlardan kurtuluyoruz. WEB-INF/resources klasörü içinde namespace görevi gören bir dizin oluşturmak ve bu dizin altında bileşenIsmi.xhtml dosyası hazırlamamız yeterli:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
   xmlns:composite="http://java.sun.com/jsf/composite"
   xmlns:h="http://java.sun.com/jsf/html"
   xmlns:p="http://primefaces.prime.com.tr/ui">
 
 <composite:interface>
  <composite:attribute name="id" required="true"/>
  <composite:attribute name="label" required="true"/>
  <composite:attribute name="value"/>
  <composite:attribute name="action" method-signature="void action()"/>
 </composite:interface>
 
 <composite:implementation>
  <h:outputLabel value="#{cc.attrs.label}" for="#{cc.attrs.id}"/>
  <h:inputText id="#{cc.attrs.id}" value="${cc.attrs.value}"/>
  <h:commandButton value="Save" action="#{cc.attrs.action}"/> 
 </composite:implementation>
 
</html>

Yukarda /WEB-INF/resources/components dizini altına myInput.xhtml dosyasının içeriği mevcut. Ayrıntılara göz atarsak, JSF 2.0 ile gelen composite namespace'inin kullanımı hemen dikkat çekiyor. Dosya içeriği composite:interface ve composite:implementation olarak ikiye ayrılıyor. Implementation kısmında istenen yetenek gerçekleştirilirken interface kısmında yeni bileşenin ihtiyaç duyduğu değişkenler sıralanıyor. Değişkenleri detaylı incelersek value expression alan değişkenlerin yanında method expression alan action değişkeninin tanımlanması örneklemiştir. Ayrıca değişkenlere erişim de görüldüğü gibi #{cc.attrs.degiskenIsmi} şeklinde yapılıyor.

Yeni bileşenimizi bu şekilde hazırladıktan sonra hiçbir ek tanım yapmadan JSF sayfalarımızda kullanabiliriz:

<html xmlns:m="http://java.sun.com/jsf/composite/components">
 ...
  <m:myInput id="myInput" label="Username" value="#{user.name}" action="${user.save}"/>
 ...
</html>

Küçük bir not: Composite Components kullanırken tanımladığınız değişkenin ismi "rendered" olursa JSF'in hata fırlattığını da hatırlatayım. İlgili bug kaydı burada.

JSF2'de Flash Scope Sorunu

2011-03-17T21:49:00.001+02:00

Redirect işlemlerinde sunucuya ikinci bir istem gönderildiği için Request Scope içindeki değişkenler kayboluyor, bu yüzden aktarılacak değişkenler Session Scope'ta tutuluyordu. Session scope'un gereksiz meşgul edilmemesi için JSF2 ile birlikte Map gerçekleştirimi olan flash nesnesi kullanıma sunuldu. Böylelikle redirect işlemlerinde değişken aktarımı ve kullanımı Java sınıfı içerisinde:

ExternalContext.getFlash().put("message", "Your password is about to expire");

JSF sayfası içerisinde de:

#{flash.message}

şeklinde yapılabilir hale geldi. Ne var ki bu özellik Mojarra 2.0.3 impl'de (MyFaces ile denemedim) sadece aynı dizin ve altdizinlerde bulunan sayfalara redirect yapılırsa çalışıyor. Farklı dizin yapılarında bulunan sayfalar arasında yapılan redirect işleminde bir bug nedeniyle Flash scope'a konulan değişkene ulaşamıyorsunuz. Sorunun nerden kaynaklandığı ile ilgili bir bağlantı şurda.. Böyle bir gereksinimde gene eski usül, Session Scope'tan faydalanmak ve ilgili değişken redirect yapılan sayfada kullanıldıktan sonra Session Scope'tan değişkeni kaldırmayı unutmamak gerekiyor.

JSF'de SMTPAppender ile Gmail üzerinden Exception Bildirimi

2011-02-16T14:54:00.002+02:00

Geliştirdiğimiz uygulamaların kullanımı esnasında oluşabilecek kullanıcı kaynaklı ya da sistemsel hataları yakalayıp kullanıcıyı bilgilendirmek ya da yönlendirmek için yoğun çaba harcarız. Harcanan çabaya rağmen gözden kaçırılan bir hatanın oluşması durumunda ise hatanın sebebini bulmak için genelde loglar kurcalanır. Bir hata oluştuğunu anlamak için de ya kullanıcı geri bildirimi ya da rutin log kontrolleri yapılır. Bu geri bildirimin hata oluştuğu esnada bir ileti ile otomatik olarak yapılması da hataya müdahale için iyi bir yöntemdir. Bunun için popüler loglama kütüphanesi log4j'nin SMTPAppender sınıfı kullanılabilir. Örneğin yakalanan bir Exception'ın error seviyesinde loglanması ile log4j'nin bir ileti göndermesi sağlanabilir.

Bu iş için Gmail'i kullanabilir miyiz diye küçük bir arama yaptığımda şu blog girdisine rastladım. Örnek kodta Gmail ayarları barındıran bir Enum mevcut. Mail gönderimi için de Spring çatısının Email desteği kullanılmış. Spring Email kullanabilmek için ayrıca activation.jar ve mail.jar kütüphaneleri de gerekli. Madem Spring kullanacağız bağımlılık yönetimini Spring'e bırakalım. Enum sınıfı yerine öncelikle JavaMailSenderImpl yaratan bir bean tanımı yapalım:

<bean id="javaMailSender" class="org.springframework.mail.javamail.JavaMailSenderImpl">
        <property name="host" value="smtp.googlemail.com"/>
        <property name="port" value="587"/>
        <property name="username" value="gmailAccount@gmail.com"/>
        <property name="password" value="armut123"/>
        <property name="javaMailProperties">
            <props>
                <prop key="mail.smtp.auth">true</prop>                
                <prop key="mail.smtp.starttls.enable">true</prop>                
            </props>
        </property>
    </bean>

Yapmış olduğumuz bean tanımını ApplicationContext'ten alıp GMailAppender sınıfının kullanımına sunacak olan JavaMailSenderFactory sınıfını yazalım:

@Component
public class JavaMailSenderFactory implements ApplicationContextAware {

    private static ApplicationContext applicationContext;
    
    public static JavaMailSender createJavaMailSender(){
        return applicationContext.getBean("javaMailSender", JavaMailSender.class);
    }

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        this.applicationContext = applicationContext;
    }
}

JavaMailSenderFactory sınıfını da annotation yardımıyla Spring bean olarak tanımladık. Bean tanımını XML ile de yapabilirdik. Bu sınıf ApplicationContextAware arayüzünü gerçekleştirdiği için Spring application context'e erişerek JavaMailSender beanine ulaşabiliriz. Bunun için bean tanımını döndüren static bir metot yeterli olur. Log4j'nin SMTPAppender sınıfınından türetilen GMailAppender sınıfının bizim yaptığımız değişiklikler sonrasında aldığı hal şu şekilde:

public class GMailAppender extends SMTPAppender {
    private static final String NL = System.getProperty("line.separator");
    
    @Override
    public void append(LoggingEvent event){
        
        SimpleMailMessage msg = new SimpleMailMessage();
        StringBuilder builder = new StringBuilder();
        builder.append(getLayout().format(event));
        builder.append(event.getMessage().toString());
        if (event.getThrowableInformation() != null) {
            builder.append(NL);
            String[] stackTrace = event.getThrowableInformation().getThrowableStrRep();
            for(int i = 0; i < stackTrace.length; i++) {
                builder.append(stackTrace[i] + NL);
            }
        }
        String[] senders = getTo().trim().replace(" ", "").split(",");
        
        msg.setTo(senders);
        msg.setText(builder.toString());
        msg.setSubject(this.getSubject());
        
        try{
            JavaMailSender javaMail = JavaMailSenderFactory.createJavaMailSender();
            javaMail.send(msg);
        }catch (MailException e) {
            System.err.println("!!! HATA MAILI GONDERILEMEDI !!! : ");
            e.printStackTrace();
        }
    }
}

Referans aldığım sitedeki append()metodunu da az biraz değiştirdim. Değişikliğin nedeni append() metodunun super.append(event) ile akışı SMTPAppender sınıfına aktarmış olması. GMailAppender içinde gerekli biçimlendirme ve gönderim işlemi yapıldığı için buna gerek yok aslında. Şimdi de GMailAppender için Log4J ayarlarını yapılandıralım. Ben properties dosyası yerine log4j.xml kullanmayı tercih ettim:

<root>
        <priority value="info" />
        <appender-ref ref="GMailAppender" />
    </root>

    <appender name="GMailAppender" class="com.prime.mobileme.core.util.appender.GMailAppender">
        <param name="BufferSize" value="1" />
        <param name="SMTPDebug" value="false" />
        <param name="To" value="dasgin@gmail.com" />
        <param name="Subject" value="Ucundan Java ERROR" />
        <layout class="org.apache.log4j.PatternLayout">
            <param name="ConversionPattern"    value="[%d] [%t] %-5p %c %x" />
        </layout>
        <filter class="org.apache.log4j.varia.LevelRangeFilter">
            <param name="LevelMin" value="error" />
            <param name="LevelMax" value="fatal" />
        </filter>
    </appender>

Yukarıdaki ayarlardan da anlaşılacağı gibi yakaladığınız Exception'ları log4j ile error ya da fatal olarak loglarsanız loglanan hata mail olarak belirttiğiniz Gmail hesabı üzerinden gönderilecektir. Peki yakalayamadığımız hata durumlarında ne yapmalı? Eğer JSF 2 kullanıyorsanız şu blog girdisinden faydalanabiliriz. Gene buradaki örneği kendi ihtiyaçlarımıza göre yeniden düzenleyelim. Öncelikle oluşan hatayı ele alarak log4j'ye error olarak log düşen ExceptionHandler sınıfını hazırlayalım:

public class MyExceptionHandler extends ExceptionHandlerWrapper {

    private static Logger logger = LoggerFactory.getLogger(MyExceptionHandler.class);
    private ExceptionHandler wrappedExceptionHandler;
    
    public MyExceptionHandler(ExceptionHandler exceptionHandler){
        this.wrappedExceptionHandler = exceptionHandler;
    }
    
    @Override
    public ExceptionHandler getWrapped() {
        return wrappedExceptionHandler;
    }
    
    @Override
    public void handle(){
        
        for (ExceptionQueuedEvent event : getUnhandledExceptionQueuedEvents()) {
            ExceptionQueuedEventContext context = (ExceptionQueuedEventContext)event.getSource();
            Throwable t = context.getException();
            logger.error("Unhandled Exception: ", t);
        }
        getWrapped().handle();

    }

}

Ardından ExceptionHandler sınıfımızı JSF'in kullanabilmesi için ExceptionHandlerFactory sınımızı hazırlayalım:

public class MyExceptionHandlerFactory extends ExceptionHandlerFactory {

    private ExceptionHandlerFactory parent;
    
    public MyExceptionHandlerFactory(ExceptionHandlerFactory parent){
        this.parent = parent;
    }
    
    @Override
    public ExceptionHandler getExceptionHandler() {
        return new MyExceptionHandler(parent.getExceptionHandler());
    }

}

En son adımda da faces-config.xml'e yazdığımız factory sınıfını tanıtmak kalıyor:

<factory>
          <exception-handler-factory>
            ucundan.java.MyExceptionHandlerFactory
          </exception-handler-factory>
    </factory>

Kaynaklar:
* GMail and log4j e-mail appender - error STARTTLS
* JSF 2 Exception Handling

Spring ile Hibernate Annotation Kullanılan Entity Sınıfların Otomatik Algılanması

2010-12-30T14:53:00.000+02:00

Veri erişim katmanında JPA standartını kullanırken annotation ile tanımladığımız entity sınıflarımızın algılanması, proje ayağa kalkarken otomatik gerçekleştirilir. Araya JPA standartını sokmak yerine doğrudan Hibernate çatısını kullanmak istediğimizde annotationlarla tanımlanmış bu entity sınıflarının algılanabilmesi için kullanılagelen yaygın yöntem ya hibernate.cfg.xml içersinde bu sınıfları algılatmak ya da her bir entity sınıfını Spring'in Hibernate entegrasonu için kullanıma sunduğu AnnotationSessionFactoryBean tanımı içinde tek tek belirtmektir:

<bean id="sessionFactory"
 class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
 <property name="dataSource" ref="${dataSourceType}" />
 <property name="hibernateProperties">
  <props>
   <prop key="hibernate.dialect">${hibernate.dialect}</prop>
   <prop key="hibernate.show_sql">${hibernate.show_sql}</prop>
   <prop key="hibernate.format_sql">${hibernate.format_sql}</prop>
   <prop key="hibernate.hbm2ddl.auto">${hibernate.hbm2ddl.auto}</prop>
  </props>
 </property>
 <property name="annotatedClasses">
  <list>
   <value>com.prime.ExampleClass1</value>
   <value>com.prime.ExampleClass2</value>
  </list>
    </property>
</bean>

annotatedClasses'ın bu şekilde kullanımı entity sınıf sayısı arttıkça sıkıntı yaratmaya başlayabilir. Bunun yerine aynı Spring bean'in packagesToScan değişkeni uygun paket yapısıyla kurarak uzun uzadıya sınıf tanımları yapmaktan kurtulabilirsiniz:

<property name="packagesToScan" value="com.prime" />

ya da

<property name="packagesToScan">
 <list>
  <value>com.prime.package1.model</value>
  <value>com.prime.package2.model</value>
 </list>
</property>

Hibernate annotation kullanan entitylerinizin otomatik algılanması için yukardaki tüm kullanımlara ek olarak proje classpath'inde javassist.jar kütüphanesi de bulunmalıdır..

Spring - JSF Yeniden (JSF 2.0)

2010-12-21T16:38:00.000+02:00

Blogta ziyaret edilen girdilere göz attığımda "Spring - JSF Bütünleştirmesi" yazımın son zamanlarda tekrar ziyaret edildiğini farkettim. Hazır geçen hafta da JTPD'nin eğitim seminerlerinde bu konular üzerine eğilmişken iki çatının entegrasyonunu, değişen yeteneklerini de dikkate alarak tekrar gözden geçirelim istedim.

Eski girdide bu iki çatıyı birbirleriyle anlaşır hale getirebilmek için JSF'ye variable resolver olarak Spring'in bize sunduğu DelegatingVariableResolver sınıfını tanıtmıştık. Bu sınıf iki çatı arasında bean aktarımlarını gerçekleştirmek için aktarımı yapılacak beani öncelikle JSF beanlerinde, bulamazsa Spring beanlerinde arıyordu. Benzer şekilde, önce Spring bean tanımlarına sonra da JSF bean tanımlarına bakan SpringBeanVariableResolver Spring sınıfını da JSF 1.1 ve 1.2 sürümlerinde kullanabiliriz.

JSF 1.2+ sürümlerinde ise variable resolver kullanımı yerini ELResolver'a bırakıyor:

<faces-config>
  <application>
    <el-resolver>org.springframework.web.jsf.el.SpringBeanFacesELResolver</el-resolver>
  </application>
</faces-config>

Spring ile JSF'i bu şekilde ilişkilendirdikten sonra eski yazıdaki örneği bu sefer JSF 2.0'ın annotationlarını kullanarak Spring beanini JSF bean tanımı içine aktarımını yapalım:

@ManagedBean(name="member")
@RequestScoped
public class Member {

 @ManagedProperty(value="#{memberService}")
 private MemberService memberService;

 // memberService getter/setter
}

Spring bean tanımını da @Service("memberService") ya da @Component("memberService") annotationlarını kullanarak da xml'e bulaşmadan MemberService sınıfı içinde yapabiliriz:

@Service("memberService")
public class MemberServiceImpl implements MemberService {
    // ...
}

Spring annotationlarının çalışması içinse Spring context xml tanımınına ya <context:component-scan base-package="com.prime.packname"></context:component-scan> satırını eklemeli ya da web.xml içerisinde Spring bean tanımlarını xml yerine annotation kullanarak yapacağımızı belirten gerekli düzenlemeleri yapmalıyız:

<web-app>
      <context-param>
            <param-name>contextClass</param-name>
            <param-value>org.springframework.web.context.support.AnnotationConfigWebApplicationContext</param-value>
      </context-param>

      <context-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>com.prime.packageName</param-value>
      </context-param>
</web-app>

Bu işlemlerin ardından annotationlarla tanımladığımız Spring ve JSF beanlerini birbirine entegre olarak kullanabiliriz. Bol Javalar..

JTPD'de JSF, Spring ve JPA Sunumları

2010-12-12T21:10:00.004+02:00

Dün JTPD'nin düzenlediği Java eğitimlerinin 3. haftasında katılımcılara JSF, Spring ve JPA sunumları yapma fırsatım oldu. Sunumların ardından küçük örnekler yaparak da anlatılan konuları pekiştirmeye çalıştık. Her ne kadar bahsi geçen konuları detaylı incelemek için 4-5 saat gibi çok çok kısıtlı süremiz olsa da mümkün olduğunca bu çatılar (framework) bizlere neler vaat ediyor, yetenekleri neler ve birbirleriyle nasıl entegre edebiliriz konuları üzerinden hızlıca geçtik. Anlatılan konular katılımcılar için zaman zaman detaylı ve karmaşık olsa da beni sabırla dinledikleri için kendilerine çok teşekkür ederim. Umarım faydalı olabilmişimdir. Hazırladığım eğitim sunumlarına ve örnek projelere buradan erişebilirsiniz. Java kültürünü daha geniş kitlelere yaymaya çalışan JTPD derneğini de tebrik ediyorum..

Introduce Null Object

2010-11-06T15:10:00.000+02:00

Tasarım örüntüleri yazılımın yönetilebilirliği ve genişletilebilirliği için ulaşılmak istenen hedeftir. Sadece bu hedefi anlayıp uygulamaya çalışmak yerine, hedefe nasıl ulaşıldığını anlamak daha önemlidir. Refactoring yöntemleri, sizi ideal hedefe ulaştıran tasarımsal evrimi temsil eder[1]. Bu yöntemlerden bir tanesi de Null Objecttir.

Uygulama geliştirme esnasında bir metot sorgusu sonucu dönen nesnenin null olup olmadığının kontrolünü yapmak sıklıkla başvurduğumuz kontrollerden birisidir. Bu kontrolü unuttuğumuz da ise vay halimize, o ünlü NullPointerException hatasıyla uygulamamızın göçmesi kaçınılmaz olur.

İş mantığımızın gereksinimleri sebebiyle bir nesne için bu kontrolü sıklıkla tekrarlayarak null olma durumunda kodun alternatif davranışlar sergilemesi gerekebilir. Bu durum kaynak kodumuzun fazlaca tekrarlı kontrol deyimi içermesine ve Martin Fowler’ın Refactoring[2] kitabındaki deyimiyle kodun kötü kokular yaymasına sebep olacaktır. Böyle bir durumda uygulanması gereken refactoring (ben “kod adam etme” demeyi seviyorum) yöntemi Null Object olmalıdır.

Bir Null Object temel olarak gerçek nesneyle aynı metot imzalarına sahiptir. Metotları ise null olma durumunda varsayılan değerleri döndürecek, alternatif davranışları sergileyecek şekilde gerçekleştirilir.

Metot imzaları aynı olacağı için Null Object ya gerçek nesneden kalıtım (inheritance) yoluyla türetilecek ya da gerçek nesneyle ortak bir interfaceden geliştirilecek (implement) şekilde tasarlanabilir.

Kalıtım yoluyla yaratılan Null Object sınıfının, null olma durumunda alternatif davranışı sergileyecek metotları override etmesi gerekmektedir. Atasınıfa yeni eklenen metotların alternatif davranış için override edilmesinin unutulması hatalı işleyişe sebep olabilir. Interface gerçekleştirilerek yaratılan Null Object sınıfında bu risk söz konusu olmaz. Ama bu sefer yaratılan yeni sınıf içeriğinde alternatif davranış sergilemek zorunda olmayan diğer metotların gövdelerinin de barındırması gerekir.
Bir diğer sıkıntı da geliştirim aşamasında değişmeye meyilli interface tasarımlarıdır. Yeni metot eklendikçe, metot çıkartıldıkça ya da metot imzaları değiştikçe Null Object sınıfını da değiştirmek gerekir. Bu soruna Kenan Sevindik, blogunda yazdığı “Mockito ile Null Object”[3] yazısında ilginç bir çözüm getiriyor. Joshua Kerievsky “Refactoring to Patterns”[1] kitabında Null Object yönteminin temel amacının kodu basitleştirmenin yanında kaynak kod satır sayısını düşürmesi gerektiğini, en azından aynı düzeyde tutması gerektiğinin altını çiziyor. Kaynak kod satır sayısı artıyorsa uygulanmamasını tavsiye ediyor.

Null Object örüntüsünün varlığı null kontrollerinin yapılmayacağını garanti etmez. Null Object örüntüsünün kullanıldığından habersiz bir başka geliştirici null kontrolleri yapmaya devam edebilir dahası null olma durumunda işletilecek kod parçalarını iş mantığına ekleyebilir. Null Object nesnesini ve gerçek nesneyi davranış barındırmayan Nullable gibi boş bir interfaceten gerçekleştirmek geliştiricilerin dikkatini çekerek bu gibi problemlerin önüne bir nebze de olsa geçebilir. Boş bir interfaceten gerçekleştirmek yerine isNull() metotu içeren bir interface de ilerde ihtiyaç duyulabilecek olası bir null kontrolü için faydalı olur:

public interface Nullable {
 boolean isNull();
}

public class Customer implements Nullable {
 boolean isNull(){
  return false;
 }

   Plan getPlan(){
          doMoreThings();
  }
}

public class NullCustomer extends Customer {
 boolean isNull(){
  return true;
 }
 
  Plan getPlan(){
    return Plan.emptyPlan();
  }
}

Kaynak koda müdahale edemediğimiz durumlarda sadece Null Object davranışı olmayan bir interfaceten gerçekleştirilerek null kontrolü instanceof ile yapılabilir:

public interface Null { }

public class NullCustomer extends Customer implements Null{
//...
}

//...
if(customer instanceof Null) { }
//...

Null Object davranışı ve durumu değişmeyecek bir sınıf olduğu için çok fazla Null Object nesnesi yaratılma durumunda Singleton tasarım örüntüsü kullanılarak her yeni çağrıda yeni null sınıf yaratılmasının önüne de geçilebilir.

Artıları/Eksileri:
+ Null kontrolü tekrarları yapmadan, null hatalarının önüne geçer.
+ Null kontrollerinin sayısını en aza indirerek kodu basitleştirir.
- Sadece bir kaç null kontrolü kullanıldığı durumlarda kodu karmaşıklaştırır.
- Null Object gerçekleştirimi yapıldığından haberi olmayan bir geliştirici gereksiz null kontrolleri yazabilir.
- Yönetilebilirliği zorlaştırır. Gerçek sınıfa eklenen yeni metotlar için Null Object sınıfı içinde override işlemi yapılmalıdır.

Bir örnekle konuya açıklık getirelim:

class SecmenKutugu {
 Vatandas vatandas;
 Vatandas getVatandas(){
  return vatandas;
 }
}
class Vatandas{
 public long getTCNo() { 
  //..
  }
 public Adres getAdres() { 
  //.. 
  }
 public Muhtar setMuhtar { 
  //..
  }
}

class Adres {
 public int getSokakNo() { 
  //.. 
  }
 // ...
}

Vatandas vatandas = secmenKutugu.getVatandas();
if(vatandas != null) vatandas.setMuhtar(Muhtar.getInstance());
//...
long tcNo;
if(vatandas == null) tcNo = 0;
else tcNo = vatandas.getTCNo();
//...
int sokakNo;
if(vatandas == null) sokakNo = 0;
else sokakNo = vatandas.getAdres().getSokakNo();
//..

Yukardaki örnekteki gibi tekrarlı null kontrolleri yapan kodumuz olsun. Bu kodu adam etmeye null testi yapmaya imkan sağlayan Null Object yaratmakla başlayalım. Böylelikle bahsettiğimiz gibi diğer geliştiricilerin de Null Object kullanıldığına dair dikkatini çekebiliriz:

interface Nullable {
 boolean isNull();
}
class Vatandas implements Nullable{
 
 static Vatandas newNull() {
                return new NullVatandas();
        }
        boolean isNull(){
  return false;
 }
 //...
}
class NullVatandas extends Vatandas {
 boolean isNull(){
  return true;
 }
}

Null değer dönebilecek yerlerde yarattığımız yeni Null Object nesnesini döndürelim:

class SecmenKutugu {
 Vatandas vatandas;
 Vatandas getVatandas(){
  return (vatandas == null)? Vatandas.newNull(): vatandas;
 }
}

Null kontrollerinin yapıldığı her bir iş mantığı için Null Object sınıfına null olma durumunda işletilecek alternatif metot kodunu ekleyelim ve null kontrollerini kaldıralım. Ayrıca her değişiklikte kodun davranışının değişmediğini test etmekte yarar var. Tüm değişikliklerin sonunda kodumuz şu şekilde olacak:

class NullVatandas extends Vatandas {
 public long getTCNo() {
  return 0;
 }
 public Muhtar setMuhtar(Muhtar muhtar) { }
 public Adres getAdres() {
  return Adres.newNull();
 }
}
class NullAdres extends Adres {
 public int getSokakNo(){
  return 0;
 }
 //..
}

Vatandas vatandas = secmenKutugu.getVatandas();
vatandas.setMuhtar(Muhtar.getInstance());
//...
long tcNo = vatandas.getTCNo();
//...
int sokakNo = vatandas.getAdres().getSokakNo();
//..

Yukarıdaki örnekte Adres sınıfı için de bir Null Object yazma gerekliliğimiz dikkatinizi çekmiştir. Sınıfın başka bir sınıfa delege ettiği metotlar için null sınıfın da metotu delege edeceği yeni null sınıflar yazılır.

Null Object yöntemi nesnenin null davranışını modellemek için kullanılabileceği gibi aynı zamanda nesnenin varsayılan davranış sergileyecek farklı senaryoları için de (Örk: NullVatandas, UnknownVatandas, PrivateVatandas vb.) kullanılabileceğini belirterek konumuzu sonlandıralım.

Kaynaklar:
1. Joshua Kerievsky - Refactoring to Patterns
2. Martin Fowler - Refactoring: Improving the Design of Existing Code
3. Kenan Sevindik - http://ksevindik.blogspot.com/2010/01/mockito-ile-null-object.html

Popüler Programlama Dilleri

2010-08-14T17:23:00.000+03:00

Bu site programlama dillerini çeşitli kriterleri dikkate alarak populerliğine göre aylık olarak sıralıyor. Java uzunca bir süredir ilk sırada. Dünyadaki programlama dili akımlarını takip etmek için güzel bir kaynak. Örneğin Ağustos-2010 tarihinde son zamanların popüler programlama dili Python hafif bir düşüşe geçmişken Objective-C atakta. Google'ın geliştirdiği Go programlama dili sağlam bir çıkış yaparak ilk 20 içine girerken yılların Smalltalk dili 50. sıradan da aşağılara düşmüş:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

İyi Javalar..

Eşli Programlama

2010-07-04T02:39:00.000+03:00

Eşli programlama (Pair Programming) iletişimi, eşler arasında işbirliğini ve dolayısıyla öğrenmeyi temel alan program geliştirme yöntemidir. Eşlerden biri "Sürücü (Driver)" rolünü diğeri ise "Yönlendirici (Navigator)" rolünü üstlenir. Aynı bir yarış arabasındaki pilot/yardımcı pilot yardımlaşmasındaki gibi, Sürücü kodun yazımı, yazım hatalarının denetimi, API'lerin çağırımı gibi konularla ilgilenirken Yönlendirici de yapılan işin doğruluğu, gereksinimler, alternatif yöntemler, bir sonraki adım, vb. konulara yoğunlaşır. Eşler büyük resmi, birbirlerinin eksiklerini tamamlayarak daha iyi ele alırlar. Olası hatalar büyük oranda ortaya çıkma aşamasında ele alınır ve çözülür.

Niclas Nilsson ve Hans Brattberg eşli programlamayı, yapılması ve yapılmaması gerekenleri, eşli programlamanın avantajlarını küçük tiyatrolarla destekleyerek anlatmışlar. Hoş bir sunum tarzı olmuş: The Pair Programming Show

Java Dergisi..

2010-06-18T23:31:00.000+03:00

Java Dergisi'nin yayın hayatına başlaması Türkiye yazılım dünyası için güzel bir gelişme oldu... Kaliteli ve doyurucu bir içeriğe sahip olmasının yanında çok kaliteli bir baskıya da sahip olan dergiye emeği geçenlere içten bir teşekkürü borç bilirim. Özellikle de bu dergi için ön ayak olan Özcan Acar'a...

Gerçek bir yazılım içeriği sunması açısından Java'ya gönül verenlerin, Java'ya adım atmak isteyenlerin ellerinden düşürmeyecekleri bir dergi. Derginin önerilerimizle daha da iyi olacağını düşünüyorum. Alınası, bol bol okunası...

Tekrar teşekkürler.

Tekrar Yayında..

2010-06-18T23:21:00.001+03:00

Evet askerlik bitti...

17 Mayıs itibari ile askerliği bitirip özlediğim sivil hayata dönüş yaptım. Askerlik ile ilgili düşünceleri dost meclisinde dile getiriyoruz. Burada sivil hayatımdaki değişiklikleri paylaşayım.

Her şey değişti... İşim, evim, yaşadığım şehir... Bundan sonraki hayatımı paylaşacağım müstakbel eşimin isteği sebebiyle İstanbul'a taşındım. Bu nedenle 9 senelik arkadaşları, güzel anıları paylaştığım dostları üzülerek Ankara'da bıraktım. Ama her fırsatta bir araya geleceğimizden hiç şüpheleri olmasın. Bunun yanında bir çok şey öğrendiğim, aralarında bulunmaktan mutluluk duyduğum Innova Ankara ailesinden de ayrılmak zorunda kaldım. Prime Teknoloji ailesine katkı sağlamaya, yeni şeyler öğrenmeye, öğrendiklerimizi aktarmaya çalışacağım.

Askerlik ve askerlikten sonra tüm bu değişiklikleri yönetmek, bir yandan da evlilik hazırlıkları yapmak zamanımın çoğunu götürdüğü için özlediğim mesleğime, uğraşmayı sevdiğim Java dünyasına dönmemi geciktirdi. Belirsizliklerin yavaş yavaş ortadan kalkması, işlerin planlanması sonucu tekrar kendime ve Java'ya vakit ayırmaya başlıyorum.

Umarım bundan sonra da her şey güzel ve gönlümüzce olur...

Kelle Koltuk Programlama

2009-11-12T17:16:00.004+02:00

Takip ettiğim blogların birinde beni "Cargo Cult Programming" terimiyle tanıştıran çok hoş bir yazı okudum. Blog yazarı Cihat Altuntaş'ın "Çakma Programlama" diye çevirdiği terimi, bu tarz programlamanın olası sonuçları açısından ve de Cargo Cult terimine birazcık benzer söylenişinden dolayı "Kelle Koltuk Programlama" diye dilimize çevirmeyi daha hoş buldum :)

Terimin detaylı anlatımını wiki'den okuyabilirsiniz. Özetle neyin ne olduğunu bilmeden ezbere programlama, şu örnekte kodu şöyle yazmışlar ben de yazıp bi deneyeyim çalışacak mı programlama...

:)

SCWCD EE5

2009-11-05T14:03:00.002+02:00

Yaklaşık 3 saat önce SCWCD EE5 sınavını da başarıyla sonuçlandırıp sertifika almaya hak kazandım, darısı çalışanların başına :)

Önceden de belirttiğim gibi sınav için "Head First Servlet & JSP" kitabından faydalandım. Kitap sınav için tüm gerekli konu başlıklarını gayet iyi açıklıyor fakat hem konu anlatımlarında hem de kitabın sonundaki deneme sınavında küçük yanlışlıklar göze çarpıyor. Bu yüzden kitabın sitesinden kitapla ilgili düzeltmeler kısmına mutlaka bakılmalı.

Ayrıca JavaRanch sitesinden SCWCD ile ilgili forum ve sınav hakkında açıklayıcı, faydalı bilgilere de erişebilirsiniz.

Sırada ne mi var? Sırada bir aksilik çıkmazsa aralık ayında askerik var ;)

Bazen Mühendislik Sıradışı Çözümlerin Peşinden Gitmektir..

2009-10-22T10:15:00.007+03:00

Ya bir heyecan uğruna ya da sadece öylesine; sıradan çözümleri görmezden gelerek... :)

En Basit Tasarım Örüntüsü Singleton (mu?) -- 2

2009-09-25T10:26:00.002+03:00

Daha önceki bir blog girdimde Singleton sınıfın yazımında dikkat edilesi hususları yazmıştım. Singleton örüntüsünün Java Reflection ile kırıldığını da duymama rağmen "nasılı" üzerinde pek durmamıştım. Bir kaç gün önce karşılaştığım blog girdisinde "Yohan Liyanage" bu konudan ve alınabilecek önlemlerden bahsetmiş: Breaking Singleton

Bakalım Singleton'dan daha ne numaralar çıkacak :)

SpringSource Tool Suite 2.1.0

2009-08-19T16:50:00.001+03:00

Yaklaşık 2 hafta önce STS 2.1.0'nın kararlı sürümü yayınlandı. Yeni kurup hızlıca göz gezdirme fırsatı bulduğum STS 2.1.0'nin, Eclipse 3.5 üzerine kurulu olmasının yanı sıra ilk dikkatimi çeken güzelliği IzPack kullanarak hazırlanmış bir kurulum sihirbazı aracılığıyla kurulumunu gerçekleştirebilmeniz. IzPack ile kurulum sihirbazı hazırlama konusunda önceden benim de tecrübem olduğundan doğru ve hoş bir seçim diyebilirim. IzPack'i kurcalamanızı tavsiye ederim. STS kurulumunun yanında Spring tm Server, Spring dm Server ve Spring ROO paketlerini de kurabilmek için sihirbaz size seçim şansı tanıyor. Seçilen paketler kurulum esnasında belirlediğiniz dizin altına herbir paket kendi dizininde gruplanmış şekilde kopyalanıyor.

Ayrıca kararlı sürümün kurulum dosyası olarak dağıtılmasıyla önceki sürümlerde .zip dosyasını açarken karşılaşılan ve can sıkan uzun dosya isimlerinin yarattığı probleminin önüne geçilmiş.

Sorunsuz kurulumdan sonra hemen denemek istediğim, önceki sürümde bir türlü kullanamadığım "Roo Shell" penceresi oldu. Her nedense bir türlü STS üzerinden Roo Shell'i kullanarak Roo projesi yaratamamış, var olan bir Roo projesini de STS'ye aktaramamıştım. Kararlı sürümde gördüğüm kadarıyla Roo Shell penceresi çalışır durumda...

Diğer dikkatimi çeken ise, STS çalışıp Package Explorer penceresi görünür görünmez var olan Eclipse projelerini arayarak listelemesi oldu.

Alalacele kısaca paylaşmak istediğim ilk izlenimlerimin bunlar. Kullanıp keşfettikçe STS'yi buradan sizlere tecrübelerimi aktarmaya devam ederim..

SCJP, SCWCD, Spring Roo, STS, vs. vs.

2009-08-15T19:51:00.005+03:00

Uzunca sayılabilecek bir süre blogumla ilgilenemedim. Bunun başlıca sebebi SCJP 6.0 için çalışıyor olmam ve bu sebeple merak ettiğim, ilgilenmek istediğim Spring Roo gibi teknolojilerden uzak kalmamdı. Neyseki 2 hafta önce sınava girerek sertifika almaya hak kazandım ve ardından yıllık izne çıktım.

SCJP sınavına "SCJP Sun Certified Programmer for Java 6 Exam 310-065" kitabıyla hazırlandım. Uygulama geliştirirken ezbere ya da bilmeden yaptığımız birçok konuyu öğrenmek, "bu da bu şekildeymiş" demek, örnek soruları çözmek benim için hem eğitici hem de keyifliydi. Kitabı okumanızı tavsiye ederim. Ardından bol soru çözmek sınav için yeterli olacaktır.

Sırada SCWCD var. Sınava çalışmak için ilk başta "Sun Certified Web Component Developer Study Guide" kitabını düşünsem de kitabın okuyuculardan aldığı kötü yorumlar, beni "Head First Servlet & JSP" yönlendirdi. En kısa zamanda da ikinci sertifika için çalışmaya başlamayı düşünüyorum.

İlk sertifikaya çalışırken gösterdiğim tembelliği tekrarlamamaya; Refactoring, TDD ve merak ettiğim Spring Roo, OSGi gibi konulara da tekrar eğilmeye çalışıcam. Bu sırada Eclipse 3.5 tabanlı SpringSource Tool Suite 2.1.0'ı da kullanarak getirdiği kolaylıkları gözlemlemek de istiyorum.

CETURK Java Teknolojileri Etkinliği -7

2009-06-29T08:57:00.003+03:00

Geçtiğimiz haftalarda Ankara'da gerçekleştirdiğimiz Java Teknolojileri Etkinliğinin bir benzerini bu sefer İstanbul'da, IBM Türk binasında gerçekleştireceğiz. 04.07.2009 tarihinde Java ve Kurumsal uygulamalara gönül veren İstanbullularla buluşmak dileğiyle.

Etkinliğin ayrıntılı duyurusuna http://www.ceturk.com/etkinlikkayit.asp?id=75 adresinden erişebilirsiniz.

CETURK Java - Ankara Etkinliğinin Ardından..

2009-06-16T09:33:00.005+03:00

13 Haziranda ODTÜ - KKM'de gerçekleştirilen CETURK Java Teknoloji seminerlerinin kendi açımdan heyecanlı geçmesinin yanı sıra izleyicilerin de yeni teknolojilerle tanışması açısından başarılı geçtiğini düşünüyorum.

Benim de Mustafa Demir ile "Spring Web Service" sunumuyla katıldığım etkinlikte Hasan Türksoy'un GWT ve Mehmet Gürsul'un OSGi konularına giriş düzeyindeki sunumları en azından bu iki konuya olan açlığımı bir nepze gidererek bu iki alanda biraz oyalanmam için kapıları araladı. Ayrıca Ümit Vardar Hocamızın EJB 3.1'in getirdiği yenilikler konulu sunumuyla Kenan Sevindik'in Audit sunumu da etkinliğe renk kattı.

İlk sunumum olması sebebiyle heyecanlanmanın yanında keyif de aldığımı söyleyebilirim. Yeni sunumlarda birlikte olmak dileğiyle... :)

"Spring Web Service" sunumunun yansılarına ve örnek uygulamaya http://files.getdropbox.com/u/135887/presantations/springws.rar bağlantısından erişebilirsiniz.

CETURK Java Teknolojileri Ankara Etkinliği 2

2009-06-05T14:02:00.004+03:00

CETURK'ün katılım ücretsiz olarak düzenlediği teknoloji etkinliklerinin Ankara'da 2.si 13 Haziran 2009 Cumartesi günü ODTÜ Kültür ve Kongre Merkezi (KKM) A Salonunda gerçekleştirilecek. Alanında uzman kişilerin çeşitli sunumlarla bilgilerini paylaştıkları CETURK etkinliklerinin bu ayağına "Spring Web Service" sunumuyla Mustafa Demir ile birlikte biz de konuşmacı olarak katılıyoruz. Devamının gelmesini dilerim...

Ayrıca GWT, Spring AOP, EJB 3.1 ve OSGI sunumlarının da olacağı seminerin duyurusuna ve program akışına http://www.ceturk.com/etkinlikkayit.asp?id=74 adresinden ulaşabilirsiniz.

Hibernate Parameter Binding

2009-03-25T15:27:00.005+02:00

Hibernate kullananların sıkça karşılaştığı bir durum Hibernate’in ürettiği SQL cümleciklerine geçtiği parametreleri görememektir. Hibernate’in ayar kütüğü persistence.xml’e yazılan

...

...
</properties>

İfadesi bile üretilen SQL cümleciğinde parametre gelecek yerleri ‘?’ ile gösteriyor. Hal böyle olunca bazen debug esnasında akışı izlemek sıkıntılı olabiliyor. Bu sıkıntıyı aşmanın bir yolu ise Hibernate Type sınıfı için Log4j 1.2.12 sürümünden itibaren kullanılmaya başlanan TRACE düzey loglama yapmak:

</logger>

Her ne kadar ‘?’ yerine değerler gelmese de basılan loglardan soru işareti ile belirtilen yerlere atanan değerleri elde etmek mümkün. Dönen değerler de bonus olarak gösteriliyor 

Hibernate:
/* load deneme.DovizTipi */ select doviztipi0_.ID as ID52_0_, doviztipi0_.ACIKLAMA as ACIKLAMA52_0_, doviztipi0_.KISA_ACIKLAMA as KISA8_52_0_ from DOVIZ_TIPI doviztipi0_ where doviztipi0_.ID=?

25 Mar 2009 15:11:27,159 - TRACE - IP:127.0.0.1, ReqURI:/ips/spring/anasayfa-flow - /ips - org.hibernate.type.NullableType.nullSafeSet(151) | binding '949' to parameter: 1

25 Mar 2009 15:11:27,159 - TRACE - IP:127.0.0.1, ReqURI:/ips/spring/anasayfa-flow - /ips - org.hibernate.type.NullableType.nullSafeGet(193) | returning 'Yeni Türk Lirasi' as column: ACIKLAMA52_0_

25 Mar 2009 15:11:27,159 - TRACE - IP:127.0.0.1, ReqURI:/ips/spring/anasayfa-flow - /ips -
org.hibernate.type.NullableType.nullSafeGet(193) | returning 'TL' as column: KISA8_52_0_

Açıklama Satırı Yazmadan Kod Yazana 10 Puan Bonus

2009-02-18T17:04:00.004+02:00

Bilgisayar Mühendisini mezun olduktan sonra, yaşadığı sanal dünyadan gerçek dünyaya hazırlayan, okuduğu teorik bilgileri pratiğe dökmesini sağlayan yegane işlev, genelde ikişer haftalık periyotlarla geliştirdiği, üstüne bir de raporun yazdığı programlama ödevleridir.

Öğrencinin istenen programı hatasız geliştirmesinin yanı sıra yaptıklarını anlatan ödev raporu ve kodun içinde -alışkanlık olması ve asistanın okuyabilirliğini arttırmak için- kodun bakılabilirliğini kolaylaştırdığı düşünülen açıklama satırlarını yazması beklenir. Hatta kodu yazıp açıklama satırını yazmayı ihmal eden öğrencinin en az 10 puanın gideceği garanti edilir. Hal böyle olunca mühendis adayı ya kodu yazarken açıklama satırlarını da aynı anda yazmayı kendine ilke edinir ya da kod yazma işi bittikten sonra uygun gördüğü yere açıklama satırlarını serpiştirir.

İki hafta bir sürenin son 3-4 günü ödevini yapmaya başlayan öğrenci ise ödev yetiştirmeye çalışmaktan ne Martin Fowler'dan ne "Refactoring"den -kodu adam etme demeyi daha çok seviyorum- ne de o kadar çok açıklama satırı yazmaması gerektiğinden haberi vardır. İşin ilginci ödevi veren de bundan bi haberdir...

Benim de mezun olduktan sonra namını duyduğum Martin Fowler "Refactoring Improving the Design of Existing Code" kitabında güzel konulara değinirken bu açıklama satırları konusuna da değiniyor. "Açıklama satırı kötü kokan kodun üzerine sıkılmaya çalışan deodoranttır" diyor. Doğru :)

Kitapta sınıf, metot ve değişken isimlendirmelerinin üstlenilen görevi anlatacak nitelikte yapılması gerektiğinden bahsediliyor. Bir kod parçasının işlevi açıklanma gereği duyuluyorsa o kod parçasının ayrı bir metota taşınmasını ve yeni metotun isminin açıklayıcı nitelikte olması gerektiğini söylüyor. Yazılması gereken açıklama satırının "nasıl"ı değil diğer geliştiriciler için "neden" sorusuna cevap vermesi gerekliliği vurgulanıyor.

Bol açıklama satırsız kodlar...

Richfaces Editor Bileşeni

2009-01-09T15:36:00.005+02:00

Önceki girdimde belirtiğim projede ortaya çıkan richfaces:calendar ile TinyMCE'nin IE ortamında birbirlerine yaptığı uyuzluk beni Richfaces 3.3.0 ile gelecek olan editor bileşenini denemeye yöneltti. Richfaces 3.3.0.CR3 sürümünü indirerek gerekli ayarları yapmam ve bileşeni kullanmam çok kısa sürede sonuçlandı. TinyMCE'i kullanmak için sayfaya yüklememiz gereken tiny_mce.js işlemini yapmaya gerek duymadan sadece editorconfig.properties dosyasını classpath'te hazırlayarak bileşeni kullanabilir duruma geldim.

Detaylı bir editorconfig.properties içeriği şu şekilde oluşturabilinir:

http://dl.getdropbox.com/u/135887/editorconfig.properties

TinyMCE ayarları ile ilgili detaylı bilgiyi buradan bulabilirsiniz. Bileşeni kullanmak istediğiniz yerde şu kod parçasını yazmanız yeterli:

Yukardaki kodda da görüldüğü gibi ile ayar dosyasında olan bir niteliği ezebiliyor, olmayan niteliği de ekleyebiliyorum. Sonuç bence başarılı :)

Richfaces Calendar bileşeni ve TinyMCE

2009-01-08T20:07:00.007+02:00

Richfaces sunduğu zengin JSF bileşenleriyle JSF ile geliştirilen web uygulamalarında kullanımı sıkça tercih edilen bir kütüphane. bileşeni de Richfaces'ın işe yarar özellikleri olan güzel bir takvim gerçekleştirimi.

TinyMCE ise html girdileri yapabileceğiniz popüler bir "zengin metin editörü".

Geliştirdiğimiz web uygulamalarında TinyMCE'i bir Richfaces bileşeni olarak paketlemiştik. Böylece kolay ve tekrar kullanılabilir zengin metin editörümüz oldu. Bir adım daha ileri giderek Richfaces'in dosya yükleme bileşeni olan ve bu blogta gerçekleştirimi bir örnekle anlatılan ile zengin metin editör bileşenimizi birlikte çalışır hale getirdik.

Zengin metin editörümüzü mutlu mesut kullanırken, richfaces'ın dosya yükleme yeteneği ile kullanıcılara resimler yükletirken bugün gördüm ki rich:calendar ve tinyMCE ile birbirleriyle aynı sayfada geçinemiyor. Firefox iki bileşeni problemsiz çalıştırırken, bu uyumsuzluk bir şekilde IE'de ortaya çıkıyor ve can sıkıyor. (Uyumsuzluğu bulmak 2 saatimi alınca canlar sıkıldı elbet.)

Richfaces'in Jira'sında bununla ilgili bir hata kaydı girilmiş: https://jira.jboss.org/jira/browse/RF-3697

Kayıttan da anlaşıldığı gibi sorunu 3.3.0 ile birlikte gelecek olan ile çözmüşler. Richfaces'in TinyMCE gerçekleştirimi. TinyMCE'in var olan özelliklerinin yanısıra yeni özellikler barındırdığından da bahsediliyor. İncelediğim kadarıyla TinyMCE'in gerek duyduğu parametreleri .properties dosyasından temin ediyor. Biz bu parametreleri bileşenin .xhtml sayfasında veriyorduk.

TinyMCE bileşenini Richfaces'tan önce geliştirdiğimize mi sevineyim, var olan sorunlar nedeniyle Richfaces'ın yeni sürümünde gelecek olan gerçekleştirime geçmek zorunda kaldığımız için harcanan emeğe mi üzüleyim bilemedim :)

En Basit Tasarım Örüntüsü Singleton (mu?)

2008-11-14T10:51:00.004+02:00

Singleton örüntüsü bir sınıfın sadece tek bir nesnesi olması gerektiği durumlarda kullanılır ve sınıfın ihtiyaç duyulduğu zaman yaratıldığı en bilindik kullanım şekli şu şekildedir:

public class DateUtils {

private static DateUtils instance = null;

private DateUtils() {}

public static DateUtils getInstance() {

if(instance == null)

instance = new DateUtils();

return instance;

}

...

}

Böyle bir kullanım çoklu işletim dizilerinde (multithreads) sorunlara neden olabilmektedir. Aynı anda iki farklı işletim dizisinin instance niteliğini kontrol etmesi ve null görmesi sonucu iki farklı olgunun yaratılma olasılığı vardır. Bunun önüne iki şekilde geçilebilir. İlki sınıfın static niteliğinin uygulama ayağa kalkarken yaratılması:

public class DateUtils {

private static DateUtils instance = new DateUtils();

private DateUtils() {}

public static DateUtils getInstance() {

return instance;

}

...

}

İkincisi ise getInstance() yönteminin synchronize hale getirilmesi. Tüm yöntemin senkron hale getirilmesi, sadece nesnenin null durumunda kontrol edilmesi gereken, nesne yaratıldıktan sonra da performansa olumsuz etki yapan bir durum olduğu için kullanımından kaçınılmaktadır. Bunun yerine instance niteliği null ise senkronu başlatan bir yöntem tercih edilmiştir:

public class DateUtils {

private static DateUtils instance;

private DateUtils() {}

public static DateUtils getInstance () {

if(instance == null) {

synchronized(DateUtils.class)
{

if(instance == null)

instance = new DateUtils();

}

return instance;

}

Ne var ki “Double-Checked Locking” olarak bilinen bu yöntem JDK 5’ten önce çalışmıyor. Ayrıntılı bilgiye “The Double-Checked Locking is Broken Declaration” bağlantısından ulaşabilirsiniz. JDK 5 ile gelen volatile bu
sıkıntıya derman oluyor:

public class DateUtils {

private volatile static DateUtils instance;

private DateUtils() {}

public static DateUtils getInstance () {

if (instance == null) {

synchronized(DateUtils.class)
{

if (instance == null)

instance = new DateUtils();

}

return instance;

}

Singleton örüntüsünde dikkat edilmesi gereken bir başka husus ise sınıf Clonable arayüzünü gerçekleştiren bir başka sınıftan türetilmişse ortaya çıkıyor. Singleton sınıfımızın clone() yöntemi ile çoğaltılmasının önüne geçmek istiyorsak bu metodun üstüne yazmamız gerekiyor:

public Object clone() throws CloneNotSupportedException {

throw new CloneNotSupportedException();

}

Hibernate Data Filtering (Süzme)

2008-11-13T10:24:00.004+02:00

Verilerin tamamını değil de belirli kriterlerle süzülüp işimize yarayacakları veritabanından sorgulamak günlük hayatta çokça karşılaştığımız bir senaryo. Örneğin “Abone” nesnesinin belirli tarihten önceki ödenmemiş faturalarına erişmek istediğimiz zaman abone.getFaturalar()
şeklinde bir erişim, eğer bir süzme uygulanmazsa abonenin tüm faturalarını getireceği için Java kodlarıyla süzme işlemini yapmamızı gerektirecektir. Buna benzer ya da veri güvenliği (kullanıcıya sadece görmesi gereken verilerin gösterilmesi) gibi senaryolarda Hibernate Data Filtering, Java kodlarında gerçekleştirmemiz gereken süzme maliyetinden kurtulmamıza olanak sağlıyor.

Öncelikle süzme işleminde kullanacağımız süzgeci, biricik ismiyle tanımlamamız gerekiyor:

@org.hibernate.annotations.FilterDef(name="faturaOdemeFilter",

parameters={
@ParamDef(name="donem",type="integer"),
@ParamDef(name="kalanTutar",type="double"),
@ParamDef(name="durumConditions",type="long")

})

Tanımladığımız süzgecin ismi faturaOdemeFilter ve dinamik süzme işlemi yapabilmemiz için üç tane parametre alıyor. Parametrelerin kurulma işlemine birazdan değineceğiz. Bu tanım global nitelikli olduğu için herhangi bir sınıfta ya da package-info.java içerisinde yazılabilir. Yazıldığı sınıfın davranışında bir etkisi yoktur fakat uygun olan tanımın ilgili sınıfta yazılmasıdır. Süzgeç tanımımız olgusunu da süzme işleminin yapılacağı sınıfta ya da ilişkide yazılması gerekmektedir:

@Entity
@Table(name="FATURA")

@Filter(name="faturaOdemeFilter", condition="ODEME_DONEMI <= :donem and FATURA_DURUM in (:durumConditions) and KALAN_TUTAR >:kalanTutar")

public class Fatura {...}

Birden fazla süzgeç @org.hibernate.annotations.Filters ile gruplanabilir. Yukarıdaki gibi sınıf üzerine yazılmış süzgeç olgusu

List<Fatura> filteredItems = session.createQuery("from Fatura").list();

List<Fatura> filteredItems = session.createCriteria(Fatura.class).list();

Deyimlerinde çalışacaktır. Id ile sorgulamalarda (id'yi biliyorsak süzmeye de gerek yok) ve nesne niteliklerinin sorgulanmasında sınıf üzerine yapılan tanım çalışmayacaktır. abone.getFaturalar()deyimi gibi abonenin ilişkili olduğu faturaların süzülmesi için süzgeç olgusunun ilişki üzerinde tanımlanması gerekmektedir:

@Entity
@Table(name = "ABONE")

public class Abone {

@OneToMany(mappedBy="abone")
@Filter(name="faturaOdemeFilter", condition="ODEME_DONEMI <= :donem and FATURA_DURUM in (:durumConditions) and KALAN_TUTAR > :kalanTutar")

private Set<Fatura> faturalar = new HashSet<Fatura>();

...

}

Süzgeç tanımının kullanılması için Hibernate Session’ında süzgeç aktif hale getirilerek varsa aldığı parametreler kurulmalıdır. Veriler çekildikten sonra da süzgeç tekrar pasif hale getirilebilinir. (JPA API’sinde EntityManager filtrelemeye destek sağlamadığı için Hibernate arayüzü kullanılmalıdır.)

List<Long> durumConditions = new ArrayList<Long>();

durumConditions.add(FaturaDurumEnum.ODENMEMIS.getValue());
durumConditions.add(FaturaDurumEnum.PARCALI_ODENIYOR.getValue());

Filter filter = session.enableFilter("faturaNormalOdemeFilter");

filter.setParameter("donem",donem).setParameter("kalanTutar",new Double(0)).setParameterList("durumConditions", durumConditions);

Set<Fatura> faturalar = abone.getFaturalar();

session.disableFilter(("faturaNormalOdemeFilter");

Char Tipi ve Hibernate

2008-10-23T11:41:00.004+03:00

Bir veritabanına erişirken Char tipinde tanımlanmış bir kolona
rastladım. Birkaç ufak takla atma, alan nesnesinde kolona karşılık
gelen niteliği String tanımalama gibi girişimlerim sonuç vermeyince
Google başvurmak kaçınılmaz oldu. Hibernate'in sitesinde yer alan bir sayfada
UserType arayüzünden gerçekleştirilmiş bir sınıfın bu işi çözeceği
belirtilmiş. Sınıfı aşağıdaki annotationlar ile denediğimde artık Char
tipine sorunsuz ulaşabildim:

(Burada Char.class, UserType’tan gerçekleştirilmiş sınıfımız)

@Entity
@Table(name="ABONE_DURUM")
@TypeDef(name = "char", typeClass = Char.class)
public class AboneDurum{

@Id
@Column(name="ABONE_DURUM_KODU")
private Long id;

@Column(name="ACIKLAMA")
private String aciklama;

@Type(type="char")
@Column(name="KISA_ACIKLAMA", length=3)
private String kisaAciklama;

...

POJO vs. EJB 3.0

2008-08-13T21:28:00.007+03:00

POJO ve EJB, Java EE geliştiriminde tercih edilen iki ayrı programlama modeli. Bu iki teknoloji, EJB 3.0'ın öğrenilmesi zor ve karmışık programlama modelini terkederek POJO tabanlı bir model seçmesiyle aynı eksende ilerleyecek gibi duruyor. Ama hala göz ardı edilemeyecek farklılıklar mevcut. POJO programlama modelini temel alan Spring çatısını kendine örnek alan EJB ile POJO'yu kıyaslarken elde ettiğim sonuçları özetlemeye çalıştım:

	POJO	EJB 3
Basitlik	Mimarinin geliştiriminde göz önünde tutulan nesne yönelimli ilkeler sayesinde öğrenilmesi ve kullanılması kolay bir yapıya sahip. Basitlik ve tutarlılık ön planda.	Getirdiği mimari artılarına karşın EJB 1.0 sürümünden bu yana değişen programlama modeli ve öğrenim maliyeti projeler için dezavantaj oluşturuyor.
Test Edilebilirlik	POJO yapısı sayesinde Bağımlılık aktarımı (Dependency Injection) örüntüsü kullanılarak bileşenlerin kolay ve hızlı test edilebilirliğine imkan sağlıyor. Testler containerdan bağımsız yapılabiliyor.	Bağımlılık aktarımının sadece JNDI nesneleri ile yapılabilmesi, Session ve message-driven beanlerinin POJO olmalarına rağmen EJB Container’a ihtiyaç duymaları sebebiyle test edilebilirlik kısıtlanıyor. Bu da geliştirim sürecini olumsuz etkiliyor.
Geliştirim Ortamı	Tomcat gibi hafif (lightweight) containerlarla geliştirilen web uygulaması hızlıca çalıştırılabiliyor.	Geliştirilen uygulamanın çalıştırılabilmesi için ağır uygulama sunucularına ihtiyaç duyuyor. Projenin ihtiyaç duymadığı özellikler de uygulama sunucusu ile ayağa kaldırılıyor.
Collections Desteği	Hibernate çatısı ile persistence katmanında Set<String>, Set<Integer> gibi entity beanlerden oluşmayan collectionlara doğrudan destek sağlıyor.	Persistence katmanında sadece entity beanleri için collection desteği sağlıyor. Set<String>, Set<Integer> gibi collectionlara doğrudan destek sağlamıyor.
Konfigürasyon	Spring Bean configuration dosyalarına ihtiyaç duyuyor. Annotation desteği sunuyor.	Spring Bean configuration dosyalarından daha karmaşık bir yapıya sahip EJB descriptor dosyalarına ihtiyaç duyuyor. Annotation desteği sunuyor.
Persistence API	Kendine ait bir persistence api olmamasına karşın Template örüntüsü ile desteklenen; Hibernate, Ibatis, JPA gibi popüler çatılarla ve JDBC ile kolayca entegrasyona izin veren bir mimari sağlıyor.	EJB 3 ile Entity beanlerin yerini Hibernate, Toplink, JDO gibi persistence API’lerden devşirilen JPA belirtimi alıyor. Belirtim olması sebebiyle belirtimin yetersiz kaldığı yerlerde geliştirim sağlayıcısına bağımlı kalınabilmektedir.
Transactions	Dağıtık transaction mimarisini JTA ile destekliyor. Spring AOP çatısı ile annotationlar kullanılarak 7 farklı Propagation-bazlı transaction tanımlanabiliyor. Transactionlar XML konfigürasyon dosyalarında ya da aspect yaklaşım kullanılarak tanımlanıyor. Spring JDBX, Hibernate ve JTA ile entegre olabiliyor.	Dağıtık transaction mimari geliştirimine olanak sağlıyor. Session beanlerin tüm public metodlarına transaction mantığı otomatik olarak uygulanıyor. Annotation tabanlı bir transaction yönetimi bulunuyor. Sadece JTA’yı destekliyor. JTA Tomcat gibi hafif containerlarda çalışmıyor.
Güvenlik	ACEGI güvenlik çatısıyla hem nesne method çağrımı hem de HTTP istemlerinde doğrulama ve yetkilendirme yapılabiliyor. Rol-bazlının yanı sıra ACL-bazlı yetkilendirme de sağlıyor. Uygulama sunucusundan bağımsız standart bir güvenlik katmanı sağlıyor.	Tanımlı method-düzeyi rol-bazlı yetkilendirme, programatik rol belirleme özelliklerine sahip. EJB belirtiminin yeterli olmaması sebebiyle, güvenlik gerçekleştirimini uygulama sunucusuna bırakıyor. Böylece güvenlik katmanı uygulama sunucuna bağımlı hale geliyor.

Summation of Persistence Comparison Between Spring and EJB 3.0.

Feature	Spring	EJB 3.0
Simple ORM Persistence	√	√
Implementation	Hibernate, JPA, JDO, TopLink, iBatis	JPA (providers include Hibernate, Kodo and Toplink)
JDBC Support	√	--
Mapping	XML, Annotations	Annotations, XML
Cache Propagation	Thread local	Transaction
Extended cache scoping	Open session in view	Extended persistence context

Equivalent Transaction Management Functionality in Both Spring and EJB 3.0.

Feature	Spring	EJB 3.0
Declarative Transactions	√	√
Programmatic Transactions	√	√
Demarcation	AOP	Session bean methods
Supported Transaction Types	JDBC, Hibernate, JTA	JTA
Support for Distributed Transactions	√ (With JTA)	√
Configuration	XML	Transactional by default, override with annotations or XML

Teknolojilerin Google Trend’ten elde edilen yıllara göre arama sonuçlarının karşılaştırma tabloları:

ejb					1.00
pojo			0.16

ejb		1.00
hibernate			1.84
jpa	0.24

Sonuç olarak Java EE uygulamalarda EJB'nin tercih edilmesini gerektirecek tek durum dağıtık transaction yönetimi ihtiyacı. POJO (dolayısıyla Spring) bu ihtiyaca karşılık veremiyor. Bunun dışındaki senaryolarda değişen trendler de göz önüne alınarak POJO programlama modelini temel alan çözümlerin (Spring, Hibernate, vs.) (EJB 3.0 gibi kopyalarının yerine :) ) seçilmemesinde hiç bir neden yok.

Kaynaklar

Manning – POJOs In Action - http://www.manning.com/crichardson/
An Early Look at Spring vs. EJB 3.0 - http://www.techienuggets.com/Detail?tx=93
Spring and EJB 3 Compared - http://www.infoq.com/news/spring-ejb-3-compared
Make the Right Decision with Our Side-by-Side Comparison of Spring and EJB 3.0 - http://www.devx.com/Java/Article/32314/0/page/1
http://www.google.com/trends
Job Trends:EJB, Spring, and Hibernate - http://www.infoq.com/news/2006/11/job-trends-ejb3-spring

Spring 2.5.3 ve Apache CXF ile Anlaşma-Sonra(Contract-Last) Yaklaşımlı Web Service Geliştirme

2008-07-11T17:06:00.001+03:00

Bir önceki girdide Spring Web Service kullanarak anlaşma-önce web service geliştirme yaklaşımından ve bu yaklaşımının artılarından bahsetmiştik. WSDL belgesinin değişmesinin istemci ve sunucu kodlarını etkileyeceği için önce WSDL belgesinin oluşturulması gerektiğine değinmiştik. Bunun yanında anlaşma-önce yaklaşımın kullanılması geliştiriciyi Web Service geliştiriminin ayrıntılarından uzak tutacağı için küçük çaplı projelerde avantaj sağlayabilir. Bu girdide de Apache CXF kullanarak anlaşma-önce yaklaşımla basit bir web service geliştireceğiz.

Apache CXF’nin kullanacağı kütüphaneleri indirdikten sonra projemiz için gerekli olanları .zip kütüğünün lib dizininde yer alan WHICH_JARS kütüğünde bulabilirsiniz. Temel kullanım için gerekli olan kütüphanelerin listesi şu şekildedir:

- cxf.jar

- commons-logging.jar

- geronimo-activation.jar (Or the Sun equivalent) *

- geronimo-annotation.jar (Or the Sun equivalent) *

- geronimo-javamail.jar (Or the Sun equivalent) *

- geronimo-stax-api.jar (Or the Sun equivalent) *

- neethi.jar

- jaxb-api.jar *

- jaxb-impl.jar

- stax-utils.jar

- XmlSchema.jar

- wstx-asl.jar *

- wsdl4j.jar

- xml-resolver.jar

* Bu kütüphaneler Java 6 Update 4’den sonra JDK içinde mevcuttur.

Ayrıca Java sınıflarımızda Annotation kullanacağımız için Aegis ve JAX-WS kütüphalerine de ihtiyacımız var:

- jaxen.jar

- jdom.jar

- stax-utils.jar

- geronimo-ws-metadata.jar [6]

- jaxws-api.jar [6]

- saaj-api.jar [6]

- saaj-impl.jar [6]

- asm.jar

Örnek servis olarak kişi listesi döndüren bir servis yazalım:

package com.blogspot.mdasgin.examples.model;

import org.apache.cxf.aegis.type.java5.IgnoreProperty;

public class Kisi {

private String isim;

private String soyisim;

private Integer kimlikNo;

public Kisi() {

}

public Kisi(String isim, String soyisim, Integer kimlikNo) {

this.isim = isim;

this.soyisim = soyisim;

this.kimlikNo = kimlikNo;

}

public String getIsim() {

return isim;

}

public void setIsim(String isim) {

this.isim = isim;

}

public String getSoyisim() {

return soyisim;

}

public void setSoyisim(String soyisim) {

this.soyisim = soyisim;

}

* @IgnoreProperty tells Aegis that I don't want getTamIsim() to show up in the auto-generated WSDL.

* It's just a read-only convenience method.

@IgnoreProperty

public String getTamIsim() {

return soyisim + ", " + isim;

}

public Integer getKimlikNo() {

return kimlikNo;

}

public void setTamIsim(Integer kimlikNo) {

this.kimlikNo = kimlikNo;

}

@IgnoreProperty annotation’ı sayesinde Aegis, otomatik üretilen WSDL belgesinde bu niteliği göz ardı edecek. Web service arayüzü ve geliştirimi de şu şekilde olacaktır:

package com.blogspot.mdasgin.examples.contractlast.services;

import java.util.List;

import javax.jws.WebParam;

import javax.jws.WebService;

import com.blogspot.mdasgin.examples.model.Kisi;

* @WebService annotation bu arayuzun bir web service arayuzu oldugunu belirtir.

@WebService

public interface KisiService {

List<Kisi> getKisiList();

* @WebParam annotation allows us to use an HTTP parameter called "message" to reference the operation's argument

* instead of having to call it "arg0", which is the default.

void addKisi(@WebParam(name = "kisi")Kisi kisi);

}

---

package com.blogspot.mdasgin.examples.contractlast.services.impl;

import java.util.ArrayList;

import java.util.List;

import javax.jws.WebService;

import com.blogspot.mdasgin.examples.contractlast.services.KisiService;

import com.blogspot.mdasgin.examples.model.Kisi;

* @WebService annotation bu sinifi bir web service geliştirimi olarak isaretler. Ayrica kullandigi arayuzu de belirtir.

@WebService(endpointInterface="com.blogspot.mdasgin.examples.contractlast.services.KisiService")

public class KisiServiceImpl implements KisiService {

public List<Kisi> getKisiList() {

List<Kisi> kisiList = new ArrayList<Kisi>();

kisiList.add(new Kisi("Mustafa", "Dasgin", "11111111111"));

kisiList.add(new Kisi("Huzur", "Oncu", "22222222222"));

return kisiList;

}

public void addKisi(Kisi kisi) {

System.out.println(kisi.getTamIsim());

}

Bu aşamadan sonra web.xml’de gelen web service istemlerinin yönlendirilebilmesi için gerekli tanımları eklemeliyiz:

<servlet-name>CXFServlet</servlet-name>

<servlet-class>

org.apache.cxf.transport.servlet.CXFServlet

</servlet-class>

</servlet>

<servlet-mapping>

<servlet-name>CXFServlet</servlet-name>

<url-pattern>/webservices/*</url-pattern>

</servlet-mapping>

Tanımdan da anlaşılacağı gibi sunucumuza “/webservices/*” örüntüsünde gelen istemler CXFServlet’e yönlendirilecektir. Spring bean tanımlarımızı da yapalım:

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:context="http://www.springframework.org/schema/context"

xmlns:cxf="http://cxf.apache.org/core"

xmlns:jaxws="http://cxf.apache.org/jaxws"

xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-2.5.xsd

http://www.springframework.org/schema/context

http://www.springframework.org/schema/context/spring-context-2.5.xsd

http://cxf.apache.org/core

http://cxf.apache.org/schemas/core.xsd

http://cxf.apache.org/jaxws

http://cxf.apache.org/schemas/jaxws.xsd">

<!-- CXF'nin loglama ozelligi kullanilabilir fakat performans soz konusu ise kullanilmamasi onerilir.

-->

<cxf:bus>

<cxf:features>

<cxf:logging />

</cxf:features>

</cxf:bus>

<bean id="kisiService"

class="com.blogspot.mdasgin.examples.contractlast.services.impl.KisiServiceImpl" />

<bean id="aegisBean"

class="org.apache.cxf.aegis.databinding.AegisDatabinding"

scope="prototype" />

<bean id="jaxws-and-aegis-service-factory"

class="org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean"

scope="prototype">

<list>

<bean

class="org.apache.cxf.jaxws.support.JaxWsServiceConfiguration" />

<bean

class="org.apache.cxf.aegis.databinding.AegisServiceConfiguration" />

<bean

class="org.apache.cxf.service.factory.DefaultServiceConfiguration" />

</list>

</property>

</bean>

<jaxws:endpoint id="kisiServiceEndPoint"

implementorClass="com.blogspot.mdasgin.examples.contractlast.services.impl.KisiServiceImpl"

implementor="#kisiService" address="/kisiws">

<jaxws:serviceFactory>

</jaxws:serviceFactory>

</jaxws:endpoint>

</bean>

Sunucu tarafımız hazır. Aşağıdaki istemlerle deneme yapabilirsiniz:

http://localhost:8080/denemeWSProje/webservices (Hizmet veren web servis listesi)
http://localhost:8080/denemeWSProje /webservices/kisiws?wsdl (Üretilen wsdl belgesi)
http://localhost:8080/denemeWSProje /webservices/kisiws/getKisiList
http://localhost:8080/denemeWSProje /webservices/kisiws/addKisi?kisi=...

Sunucuya bağlanacak istemci tarafında tanımlanması gereken spring bean’leri de şu şekilde olmalıdır (Sunucu tarafında tanımlanan aegisBean ve jaxws-and-aegis-service-factory beanleri de istemci tarafında tanımlanmalıdır):

<bean id="client"

class="com.blospot.mdasgin.examples.contractlast.services.KisiService"

factory-bean="clientFactory" factory-method="create" />

<bean id="clientFactory"

class="org.apache.cxf.jaxws.JaxWsProxyFactoryBean">

<property name="serviceClass"

value=" com.blogspot.mdasgin.contractlast.services.KisiService" />

<property name="address"

value="http://localhost:8080/denemeWSProje/webservices/kisiws" />

<property name="serviceFactory"

ref="jaxws-and-aegis-service-factory" />

</bean>

Kaynaklar:

Cola: Gerçek Zamanlı, Paylaşımlı Programlama

2008-07-08T23:49:00.005+03:00

Cola: Real-Time Shared Editing from Mustafa K. Isik on Vimeo.

http://live.eclipse.org/node/543
http://wiki.eclipse.org/RT_Shared_Editing