Session'daki attribute'lerin standart tag library ile okunabilmesi

Session içinde varolan attribute'leri standart tag library ile okuyabilmek gayet kolaydır.

<c:set var="test" value="${domain_test}"/> yaptığımızda bütün scope'lar içinden arayarak "domain_test" objesini bulur. Hatta bu attribute'un session da olduğunu bildiğimiz için <c:set var="test" value="${domain_test}" scope="session"/> diye verirsek de olur.

Fakat benim karşılaştığım sorun da olduğu gibi eğer session'a koyduğunuz objenin isminde "nokta" varsa "c:set" yukarıda örneklerde olduğu gibi davranmıyor.

Session'a koyduğumuz objenin ismi "domain.test" olsun. Bu durumda <c:set var="user" value="domain.test" scope="session"/> şeklinde tanımlarsak tag library session'daki domain objesinin test attribute'ünü set etmeye çalışacaktır. Eğer uyanık davranıp <c:set var="user" value="'domain.test'" scope="session"/> şeklinde değiştirirseniz zaten parse hatası alacaksınız :).

Gelelim çözümüne, <c:set var="test" value="${sessionScope['domain.test']}"/>
şeklinde tanımlamamız gerekiyor.

Bu durum JSTL 1.0 için sorun oluyor olabilir. 1.1 için denemedim.

JDK 1.4 ile Eclipse 3.3 sorunu

Eclipse 3.3 çıkalı kısa bir süre oldu. Tabi hemen yeni özelliklerini test etmek istedim. Her şey çok güzel fakat WTP kurdum çalışmadı. Spring IDE kurdum çalışmadı. Nasıl olur diye araştırırken Spring IDE'yi Eclipse 3.2'ye kurdum yine çalışmadı :). Sonuçta anlaşıldı. Eclipse 3.3 JDK 1.4 ile çalışıyor. Ama onun için geliştirilen plug-in'ler 1.5 istiyor.
Bu yüzden sizde eğer Eclipse 3.3 ve onunla beraber çıkan bütün platformları sorunsuz kullanmak istiyorsanız JDK 1.5 kullanın :).

Büyük projelerde kod organizasyon problemi

Büyük yazılım projelerinin en önemli sorunlarından biri çok uzun sürelerde geliştirildikleri veya istekler zamanla değiştiği için kod organizasyonlarının bozulmasıdır. Bir yerden sonra bu kodların refactor edilmesi gerekiyor. Juergen Hoeller(chief architect of the Spring Framework) bu konuda Spring Experience sempozyumunda yaptığı sunum ilgimi çekti. Sunun 88 dakika olduğu için bunun özeti daha çok işimi görecekti. Tabi özetini de buldum :). Bende özetin özetini yaparak özeti bir seviye daha ileriye götüreyim.

Yazılımlar geliştirilirken genellikle kod organizasyonu düşünülmez, zamanla kendiliğinde oluşur.
Paket bağımlığı ve modül bağımlığı konusunda "best practice" alınabilecek fazla kaynak bulunmuyor.
Kodlar mantıksal olarak organize edilmeli. "Code base" yıllar sonra tamamen yeni requirementlar olsa bile orjinal yapısına göre geliştirilmeye devam edilmeli.

Jurgen "Çoğu açık kaynak kodu yazılımları paket bağımlılığı konusunda kötü örnek oluşturuyor. JDK ve Hibernate gibi projeler örnek verilebilir." diyor.

Çift yönlü bağımlılık paketlerin yeniden kullanılabilirliğini azaltmaktadır. Zor olan kısmı tek yönlü bağımlılık yaparken kod duplication yapmamak. Çift yönlü bağımlılık için temel sebep aynı kod diğer pakette varken yeniden yazmamak. Bunun için gerekirse paketlerin yerlerini değiştirmek ama tek yönlü bağımlılık prensibini bozmamak gerekir.

Modülleri tanımlamak "challenging" olabilir. Modüller temel olarak deployment ihtiyaçlarına ve "conceptual boundaries"e göre oluşur. Bazıları modülleri "multi-tier" ayrımı göre yapıyor, fakat bu mantıksal modüllere uygun olmadığı için sorunlara sebep olur.

Temel olarak modüller "low coupling"- "high cohesion" prensibine göre düzenlenmelidir.

Her bir modülün bütün sistem içinde ayrı bir rolü olmalıdır ve bu rol herkes tarafından kolaylıkla anlaşılabilmelidir.

Spring geliştirilirken en önemli problem backward compatibility'miş. Küçükte olsa API farklılaşmasına izin verilmiş ama kod çiftlenmesine müsade etmemişler.

Eğer yeni bir modül ekleniyorsa bunun projenin neresinde olacağı üzerinden çok dikkatli olmuşlar. Kullanılan diğer frameworklerdeki değişiklikler bile spring kullanıcılarında aksettirilmemiş.

Bağımlılıkları düzenli olarak gözlemek ve yönetmek için araçları kullanmak gerekiyor.
Spring için JDepend ve SonarJ kullanılıyor.

http://www.infoq.com/presentations/code-organization-large-projects
http://mikenereson.blogspot.com/2007/06/spring-on-code-organization-for-large.html

Weblogic-Eclipse Türkçe Karakter Sorunu

Bütün gün benim için sorun olan Web sayfalarındaki Türkçe karakter problemimi şirkette çalışan arkadaşımın yardımıyla çözmüş bulunuyorum :).

Bunun için bu sorunla karşılaşılanlar için adım-adım yapılması gerekenler:

1. Eclipse'i çalıştıran shortcut target kısmınını sonuna " -Dfile.encoding=iso-8859-9" eklenir
2. Eclipse restart edilir.
3. Window->Preferences->Weblogic altında tanımlı olan weblogic "Edit" edilir. Runtime tabının altındaki VM Arguments kısmına "-Dfile.encoding=iso-8859-9" eklenir
4. Window->Preferences->General->Content Types Text->JSP seçilir ve Default Encoding "iso-8859-9" Text->Java Source File seçilir ve Default Encoding "iso-8859-9" yapılır.
5. JSP sayfasının başına
<%@ page contentType="text/html;charset=iso-8859-9"%>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-9">
satırları eklenir. Eğer dekoratör kullanılıyorsa bu satırlar dekoratöre eklenir.
Ama <%@ page contentType="text/html;charset=iso-8859-9"%> satırının bütün jsplere eklenmesi gerekir.

Sonunda bu işlemleri yapınca ve "karşılaşıldı" kelimesini sayfada görünce yaşanan mutluluk ile çekilen bütün yorgunluklar unutulur :).

Spring ile Remote Ejb erişimi

Daha önceden yazdığım ejblerin business interface'lerine doğrudan erişmemizi sağlayacak bir bean olup olmadığını araştırdım. Tabi ki bu genel bir ihtiyaç olduğu için spring içinde bunun çözümü varmış. "org.springframework.ejb.access.
SimpleRemoteStatelessSessionProxyFactoryBean" sınıfı ejb erişimi için gerekli bütün esnekliği sağlıyor. Olmasaydı ben de bunun gibi bir bean yazmak zorunda kalacaktım :).

Benim test için yaptığım konfigurasyonda aşağıdaki şekilde ayarladığımda diğer beanlerim business interface'ini doğrudan kullanmaya başlıyor.

<bean id="customerProductQuery"
class="org.springframework.ejb.access.
SimpleRemoteStatelessSessionProxyFactoryBean"
singleton="true">
<property name="jndiName" value="CustomerProductQueryEJB">
<property name="lookupHomeOnStartup" value="false">
<property name="homeInterface"
value="com.kemal.ejb.CustomerProductQueryHome"/>
<property name="businessInterface" value="com.kemal.ejb.CustomerProductQuery">
<property name="jndiTemplate">
<ref local="weblogicJndiTemplate">
</property>
</bean>

<bean id="weblogicJndiTemplate" class="org.springframework.jndi.JndiTemplate">
<property name="environment">
<props>
<prop key="java.naming.factory.initial">weblogic.jndi.WLInitialContextFactory</prop>
<prop key="java.naming.provider.url">t3://localhost:7999</prop>
<prop key="java.naming.factory.url.pkgs">weblogic.jndi.factories</prop> </props>
</property>
</bean>

Struts ve Spring MVC kullanımı

Struts ilk MVC framework'ü olduğu için yaygın bir şekilde kullanılıyor. Şimdi Struts 2 eksik yönlerine göre yazılmış olan webwork2 ile yeniden gündeme geldi.

Apache Struts 2 requires:

• Servlet API 2.4
• JSP API 2.0
• Java 5

Dependency olarak yüksek bir kabul yapmış bizim için.

Spring MVC'de struts'daki eksiklikleri görerek geliştirilmiş. Bu konuda güzel bir makale okudum.

12 BENEFITS of Spring MVC over Struts

Sonuçta struts 2 ile spring mvc arasında bir seçim yapmak gerekiyor. Bence application katmanndada spring kullanılacağına göre presentation katmanında da spring mvc kullanımı mimarinin bütünlüğü ve geliştirme kolaylığı açısından bize rahatlık sağlayacaktır. Ayrıca struts 2 yeni bir framework olduğu için gerekli dokümantasyon konusunda da bir eksikliği var.

Struts 2 ve spring mvc konusunda spring forumunda güzel bir thread'de buldum.

Spring MVC vs. Struts 2 (WebWork 2)

Spring-weblogic entegrasyonu (devam)

Geçen gün karşılaştığım "ClasscastException"'ın asıl kaynağının "org.springframework.remoting.rmi.JndiRmiClientInterceptor" sınıfındaki
stub = PortableRemoteObject.narrow(stub, getServiceInterface());
satırı olduğunu gördüm. Benim konfigurasyonumda ejb'nin service sınıfı cast edilecek şekilde ayarlı olduğu için ClassCastException alıyormuşum.
<property name="serviceInterface" value="com.kemal.ejb.CustomerProductQuery"/>
Çünkü ejb lookup sırasında home sınıfını dönüyormuş. Konfigurasyonu aşağıdaki şekilde değiştirince sorun çözülmüş oldu.
<property name="serviceInterface" value="com.kemal.ejb.CustomerProductQueryHome">
Sonuçta weblogic spring entegrasyonu konusu halledilmiş oldu, fakat bu seferde servislerin içinde
CustomerProductQuery customerProductQuery = customerProductQueryHome.create();
şeklinde kullanmak gerekiyor. Bunun engellemenin bir yolu var mı bilmiyorum.

Spring ve Weblogic entegrasyonu

Weblogic yeni öğrenmeye başladığım bir application server. Spring'i weblogic üzerinde ayağa kaldırmak sorun değil fakat weblogic üzerinde geliştirilmiş ejb'lerin spring tarafında kullanılabilmesi sorun olacağa benziyor.

Bu konuda güzel bir doküman buldum. Spring tarafında remote bean'lere ulaşmak için "org.springframework.remoting.rmi.JndiRmiProxyFactoryBean" proxy sınıfı yazılmış. Bu sınıf gerekli parametreleri ile verdiğinizde bağlanıp kullanabileceğini söylüyor.

Bean konfigurasyonu yaptığımda gerçekten bağlanmaya çalışıyor. Fakat "ClassCastException" alıyor. Aldığı bu hata konusunda biraz daha araştırma yapmam gerekecek.

Bu dokümanda ayrıca distributed-transaction,console support for spring beans,web services enablement,jmx konularında weblogic'e özel spring konfigurasyonlarının nasıl yapıldığından da bahsediyor.

Spring 1.2.x Integration with WebLogic Server

Kemal.

Teknolojik günlüğe başlarken

Merhaba,

Her gün teknolojik işler ile uğraşırken karşılaştığımız sorunları bir yerlere kaydetmediğimiz için daha sonra hem kendimiz hem de başkaları bu bilgilerden fayadalanamıyor.

Bu konuda genelde yurtdışındaki sitelerde insanların bu işi alışkanlık haline getirdiğini görüyoruz. Bugüne kadar bu bilgilerde çok yararlandım ve bir çok sorunumu çözdüm.

Ben de bundan sonra elimden geldiğince işimi yaparken karşılaştığım sorunlara bulduğum çözümleri ve çeşitli kaynaklardan edindiğim bilgileri burdan paylaşmaya çalışacağım.

Bu işin alışkanlık haline gelmesini istiyorum.