SprinOne2008 - Adrian Colyerin OSGi sunumu notlarım

Bence Adrian Colyer SpringOne2008’in en iyi sunumlarına imza attı. İkinci gün yaptığı keynote sunumu da oldukça başarılıydı. Adrian’ın OSGi a giriş sunumunda aldığım kısa notları paylaşmaya çalışayım.
Sunumun temel hedefi OSGi servis platformunun temel özelliklerini anlamak ve enterprice uygulama geliştirmede kullanımı durumunda sağlayacağı faydaları ve getireceği güçlükleri açıkça belirtmek.
OSGi nedir? The dynamic module system for Java.
Sistem bundle adı verilen pek çok modülden oluşmakta. Modüller runtime da diğer modülleri etkilemeden install, start, stop, uninstall ve update edilebiliyorlar. Sistemin dinamik olmasını sağlayanda bu zaten. OSGi aynı zamanda servis oriented. Bundle lar servis olarak publish edilebiliyorlar. Service registry diğer bundle ların servisleri bulup kullanmasını sağlıyor.
Çok güzel görünen bu dinamizm aslında çok yeni bir teknoloji değil. 1999 da gömülü java sistemleri ve network cihazları için tasarlanmıştı. 2003 de mobil cihazlara genişletildi, 2004 de open source adaptasyonu sağlandı ve 2006 server-side java uygulamalarında kullanılmaya başlandı.
En çok bilinen implementasyonları Eclipse Equinox, Apache Felix, Makewawe Knopflerfish ve Prosyst mBedded Server Professional Edition.
OSGi teknolojisinin halihzırda kullanıldığı yerler:
• Otomativ (BMW, Siemens, Volvo, ...)
• Mobile (Nokia, Motorola, ...)
• SmartHome (Phlips, Bosch, Siemens, ...)
• Enterprice (IBM, BEA, Oracle, SpringSource, Paremus, ...)

OSGi tarihçesi ve kullanım alanlarından bahsedildikten sonra sunum daha teknik konularla devam etti.
Gerekli konseptler:
• Service Platform: Lightweight containerdır. Standalone veya gömülü
olabilir. Ve OSGi service platform core specification ı R4.1 dir.
• Bundle: OSGi da deploy edilen ve modülariteyi sağlayan temel birimdir.
Sadece bir jar dosyasıdır ama META-INF/MANIFEST.MF dosyasına sahip
olmalıdır. Bu dosyada Bundle-SymbolicName, Bundle-Version, Bundle-
Name, Bundle-ManifestVersion, Bundle-Vendor başlıklarıyla tanımlar
yapılabilir.
• Import-Package: Bundle da paket seviyesindeki bağımlılıkları ayarlamak
için kullanılır. Kullanımı:
Import-Package:com.xyz.foo;
Import-Package:com.xyz.foo;version=”1.0.3”
Import-Package:com.xyz.foo;version=”[1.0.3,1.1.0)”
• Versions and Version Ranges: Version syntax:
major.minor.micro.qualifier şeklindedir. [ ] dahil, ( ) hariç için
kullanılır. Örneğin, com.xyz.foo;version=”[1.0.3,1.1.0)” tanımında
1.0.3 versiyonu dahil ama 1.1.0 versiyonu hariçtir.
• Export Package: Diğer bundle ların import eebilmesi için tipi
tanımlar. Kullanımı:
Export-Package: com.xyz.foo
Export-Package: com.xyz.foo;version="1.0.5"
Export-Package: com.xyz.foo;version="1.0.5" com.xyz.bar;version="2.0.0"
Export-Package: com.xyz.foo; com.xyz.bar;version="1.4.1"
Export-Package: com.xyz.foo;version="1.0.3";uses:="org.bar"
• Service Registry: Bir servisin diğer bundle lar tarafından
kullanılabilmesi için publish edilmiş olması gerekir. Publish edilmiş
bir servisi kullanacak bundle bu servisi önce bulur (find) sonra
bind eder.
o Publish: ServiceRegistration reg = bundleContext.registerService
(Bar.class.getName(),null);
...
reg.unregister();
o Find: ServiceReference ref =
bundleContext.getServiceReference(Bar.class.getName());
o Bind: Bar bar = (Bar) bundleContext.getService(ref);
...
bundleContext.ungetService(ref);
// bar should no longer be used here

OSGi ın faydaları:
• Güçlü Modülerlik: Bundle test edilebilir bir black box tır. Bundle bir veya
daha fazla package a export edilebilir. Export edilen bundle ın dışından
bundle a erişim sadece export edildiği package lardandır. Bunun sonucu
olarak modüller arası istenmeden yapılan bağımlılıklar son bulur, bağımsız
geliştirmeye olanak sağlanır ve daha hızlı bir geliştirme döngüsü sağlanır.
• Operational Control: Bütün modüller ve modüllerin durumu görülebilir,
wiring hakkında bilgi alınabilir, bundle lar install, uninstall, activate,
deactivste, update ve stop edilebilir. Tüm bunlar yapılırken çalışan sistemi
durdurmaya veya yeniden başlatmaya gerek yoktur.
• Versioning: Aynı pakette bir bundle ın farklı versiyonları
kullanılabilmekte. Bununla ilgili kısa bir demo da sunum sırasında yapıldı.

Enterprice Uygulamalar için OSGi:

Server Platform olarak OSGi:


Embedded OSGi:



Nested OSGi:



Yukarıdaki grafikleri, OSGi ın enterprice bir uygulama nereye oturduğunu daha iyi kavrayabilmek için ekledim.

Design Kısıtları: Platform dinamik olduğu için kullanılan bir servis herhangi
bir zamanda kaybolabilir, servis bağımlılığının yönetimi gerekli. Test,
uyumluluk ve thread yönetimi de ayrı kısıtlar. OSGi altında enterprise
kütüphanelerin birlikte çalışması class ve resource-loading problemlerine sebep
olmakta.
Enterprise kütüphanelerin OSGi ile çalışabilmelerini sağlamak için SpringSource güzel işler yapmış. Öncelikle Spring 2.5 ve diğer spring projeleri OSGi a hazır durumda. Modüller bundle yapılabiliyor ve OSGi altındaki class loading problemleri çözülmüş durumda. SpringSource Enterprise Bundle Repository ile yüzlerce yaygın kütüphaneyi OSGi bundle olarak sunmuşlar.
SpringSource un son dönemlerde yaptığı işlere ve SpringOne2008 deki sunumlara bakılırsa geleceğin enterprise java dünyası OSGi üzerine dönecek.
Sunum aşağıdakilere dikkat çekerek tamamlandı.
• OSGi is a dynamic module system for Java
• Key concepts: bundles, import/export package, services
• Key benefits: modularity, operational control, versioning
• Key disadvantages: error-prone APIs, integration testing, working with
existing libraries not designed for OSGi
• See Spring Dynamic Modules & the SpringSource Application Platform!

SprinOne2008 Keynote

11,12 Haziran 2008 tarihlerinde Antwerp/Belçika da gerçekleşen SpringOne2008 konferansına katılma imkanım oldu. Sunumlarda aldığım notları kısaca sizlerle paylaşmaya çalışayım.

Seminerin açılışını Spring, SpringSource ve Siz adlı sunumnuyla Rod Johnson yaptı.
İlk olarak spring bilen eleman arayışının artışını aşağıdaki grafikle gösterirken, SpringSource’un verdiği sertifikaların ne kadar faydalı olacağını belirtti.




Daha sonra benim beklediğim şekilde genel hızlı bir bakış yerine sunumuna daha teknik konularda detaylara inerek devam etti. Sunumların hemen hepsinde dikkatimi çeken konfigürasyonların annotation lar yardımıyla yapılması üzerinde epey durdu. Sanırım çok moda olan xml konfigürasyon (en azından benim favorimdi) yerini yavaş yavaş annotation tabanlı konfigürasyona kaptırıyor.

Spring’in dependency injection için gerçekten oldukça iyi bir annotation desteği var. Biraz örneklemek gerekirse:

@Autowired
public void createTemplates(DataSource ds,ConnectionFactory cf) {
this.jdbcTemplate = new JdbcTemplate(ds);
this.jmsTemplate = new JmsTemplate(cf);
}

Annotation autowiring için daha kullanışlı bir yapı sağlıyor. @Autowired default by type wiring yapar. Tip autowiring bazen işimizi görmez, bu durumda @Qualifier annotation ını kullanarak by name wiring yapabiliriz. Annotation ile constructor, metod ve field seviyelerinde injection yapılabilmekte. Örneklerde metod seviyesinde injection var.

public class JdbcOrderRepositoryImpl implements OrderRepository {
@Autowired
public void init(
@Qualifier("myDS")
DataSource orderDataSource,
@Qualifier("otherDS")
DataSource inventoryDataSource,
MyHelper autowiredByType) {
// ...
}


Spring de aynı zamanda stereotype annotation lar da var. Bunlar @Sevice, @Repository, @Aspect ve @Controller, bunların haricinde kendi annotationlarımızı da tanımlayabiliyoruz. Xml’ de



Tanımını yapmak yerine sınıfın başına aşağıdaki gibi @Service yazmamız yeterli.

@Service
public class DefaultAccountService { ...

Annotationlar üzerinde epey durduktan sonra spring in diğer güzellikleriyle sunum devam etti. Sırada spring security vardı. Spring security basit ve güçlü olarak tanımlandı ve tabii ki acegi security ile karşılaştırıldı. Verilen acegi security konfigürasyon dosyası ile spring security konfigürasyon dosyası arasındaki boyut ve anlaşılabilirlik farkı güvenliğin ne kadar kolaylaştığına açık bir delildi.

Spring in temelinde yatan güzelliklerinden biride test edilebilir kod yazmaya yazılımcıları özendirmesi. Integration testing başlığı da sunumdaki yerini aldı haliyle. Spring 2.5 ile annotation tabanlı test framework yeniden gözden geçirilmiş, Junit 4.4 ve TestNG desteği sağlanmış ve JUnit 3.8 in annotation cehenneminden kurtulunmuş. Ayrıca Springin @Autowired ve @Transactional gibi core annotationlarının test sınıflarında kullanılabilmesi sağlanmış. Aşağıdaki örnek test sınıfı kodu bulunmaktadır.

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
// defaults to MyTests-context.xml in same package
public class MyTests {
@Autowired
private MyService myService;
@Test
public void myTest() {...}
@Test
@Transactional
public void myOtherTest() { ... }
}

Sıra geldi Spring’in web katmanında aldığı role. Spring 2.0 daki ve 2.5 daki iki ayrı kontroller örneği web katmanındaki annotation desteğini ortaya koyuyor.

Spring 2.0 controller örneği:

public class HotelsController extends
MultiActionController {public ModelAndView index(HttpServletRequest req,
HttpServletResponse res) {…}
public ModelAndView search(HttpServletRequest req,HttpServletResponse res) {…}
public ModelAndView show(HttpServletRequest req,HttpServletResponse res) {…}
}


Spring 2.5 controller örneği:

@Controller
public class HotelsController {
@RequestMapping
public void index() {…}
@RequestMapping
public void search(SearchCriteria criteria, BindingResult result) {…}
@RequestMapping
public void show(@RequestParam("id") Long id)
{…}
}

Spring Web Flow 2.0 da ise tanımlama dili sadeleştirilmiş bununla birlikte daha güçlü hale gelmiş. EL kullanımı genişletilmiş ve flow definition inheritance eklenmiş, ayrıca asenkron event lere ve parçalı update lere destek sağlanmış. Basit bir web flow örneği aşağıdaki gibidir.




JSF üzerine geliştirilen Spring Faces’a da kısaca değinildi.

Sunumun bu aşamadan sonraki kısmı SpringSource reklamı tadında geçti. SpringSource Tool Suite demosu yapıldı. Sunumun sonunda ise geleceğe dair 4 tahmin sıralandı. Bunlar:
• Asıl rekabet application server piyasasında olacak.
• Yarının application server ı daha lightweight ve modüler olacak.
• Application server ile ESB arasındaki boşluk bir köprüyle bağlanacak.
• EJB ölecek.

Hello OSGi

Eclipse plug in leri aslında birer OSGi bundle. Bu ilk OSGi Bundle örneğini de eclipse plug in i olarak yapmak istiyorum. Eclipsi açalım ve aşağıdaki adımları takip edelim.











Örnek projeyi oluşturduktan sonra aşağıdaki gibi eclipse içersinde var olan equinox üzerinde çalıştırabiliriz. Ama ben bu projeden export alıp dışardaki bir equinox üzerinde çalıştıracağım. Bunun bir OSGi implementasyonu olan Equinox u biraz daha iyi anlamamızı sağlayacağını düşünüyorum.



Şimdi, projemizi aşağıdaki gibi export edelim.





Benim dizin yapımda C:\Work\Development\eclipseWorkspaces\plugins dizini altında HelloWorldOsgi_1.0.0.jar dosyası oluştu. Bu bir bundle ve herhangi bir OSGi implementasyonunda çalışmasını bekliyoruz. Şimdi, ayrıca indirdiğim ve C:\Work\Download\tools\eclipse\eclipse-equinox-3.3.2 dizinine açtığım Equinox ile Hello World uygulamamızı çalıştıralım.

Bir command prompt açalım ve Equinox\eclipse\plugins dizinine girelim. ve java -jar org.eclipse.osgi_3.3.2.R33x_v20080105.jar -console komutunu çalıştıralım. jar adının son kısmı Equinox versiyonuna göre farklılık gösterecektir. Sizde olanı çalıştırınız. Karşımızda aşağıdaki gibi bir ekran oluşacak.





Görüldüğü gibi bundle ı install edip çalıştırdık. Stop ettiğimizde de beklediğimiz mesajı verip duracaktır.

OSGi

Son dönemde oldukça popüler olan OSGi teknolojisi üzerine biraz konuşmak istiyorum. Bu teknolojide söz sahibi kurum OSGi Alliance. OSGi Alliance, Mart 1999 yılında Ericsson,IBM, Oracle, Sun Microsystems ve başka bikaç ortaklık tarafından kar amacı gütmeyen bir ortaklık olarak kuruldu. Alliance'ın bir yönetim kurulu var ve oraganizasyon bu kurul tarafından yönetiliyor. OSGi Alliance spesifikasyonu ve
referans implementasyonunu sağlıyor.

OSGi specification'ı, geliştirilmiş servis-yönlü mimarinin temeli olan ağ servisleri için bileşen-yönlü (component-oriented) bir standart tanımlar.
Bir ağ cihazına OSGi Hizmet platformu eklendiğinde, ağın herhangi bir yerinden cihaza
ait yazılım bileşenlerinin yaşam döngüsünün yönetilebilmesi yeteneği eklenir.
Yazılım bileşenleri, cihazın işlemine engel olmadan çalışma anında,
yüklenebilir, güncellenebilir veya çıkarılabilir.

Yazılım bileşenleri kütüphaneler ve uygulamalardır, bunlar dinamik olarak diğer
bileşenleri bulup kullanabilirler. Yazılım bileşenleri standart olarak satın alınabilir veya evde geliştirilebilirler. OSGi Alliance, XML, kullanıcı yönetimi, güvenlik, günlüğe kaydetmek (logging), yapılandırma (configuration), HTTP sunucuları ve daha fazlası gibi ortak işlevler için kullanılabilir pek çok standart bileşen
arayüzleri geliştirdi. Bu bileşenlerin tümüyle-uyumlu (Plug-compatible) geliştirilimleri farklı pazarların gereksinimlerini sağlamaları ve en iyi duruma getirmeleri için farklı üreticilerden sağlanabilir.

OSGi spesifikasyonu başlangıçta ev otomasyon sistemleri ile internet erişimini hedefledi. Fakat, standartın özellikleri başka pazarlara uygulanabilir ve çekiciydi.
Örneğin, Nokia ve Motorola sonraki nesil akıllı telefonlar için bir OSGi teknoloji
standardı kullandı. Araç endüstrisi OSGi teknolojisine, pek çok araç üreticisinin
desteklediği GST spesifikasyonunun ana parçalarını yaparak adapte oldu.
OSGi hizmet platformu BMW nin son teknoloji telematik sistemlerinin standart bir
parçası haline geldi ve pek çok Volkswagenin içine girmenin yolunu buldu, ve
CVIS ve VII gibi standartlar OSGi teknolojisini dikkate alır hale geldi.

Son dönemde daha başka pazarlardan bahsetmek gerekiyor. Bu teknolojinin enterprise java uygulamalarında da kulanılabileceğinin ortaya çıkması üzerine enterprise java dünyasının merakı bir anda OSGi teknolojisine kaydı. Dünyada kabul gören önemli java konferanslarındaki seminerlerin büyük kısmını OSGi teknolojisinin
enterprise dünyaya nasıl adapte edilebileği ile ilgili sunumlar oluşturuyor.

Son yılların ön gözde middleware fromeworkü olan Spring'in de OSGi ile ilgili pek çok çalışması var. Son olarak SpringSource, "Spring Source Application Platorm" adında bir application server sürdü piyasaya. Spring, Tomcat ve OSGi teknolojisinin güçlerini birleştiren bir application server olarak tanımlıyorlar.
Şu anda beta versiyonu var, indirdim deniyorum (defect bile açtım :)), en kısa zamanda bu platformla ilgili deneyimerimi de sizlerle paylaşmayı umuyorum.

Basit bir OSGi örneği ile devam edeceğim...

EJB ve POJO

Yaklaşık 4 senedir enterprise java projelerinde görev almaktayım. Son 2 senedir içerisinde bulunduğum projede Spring, Hibernate ve JSF gibi teknolojiler kullanılarak büyük bir proje yapılmakta, daha önceki 2 senemde içerisinde bulunduğum yine büyük bir projede ise Swing ve EJB 2 kullanılmaktaydı. Bu blogda hem EJB hem de lightweight container lar kullanmış bir yazılım geliştirici olarak bu konulardaki gözlemlerimi paylaşacağım.

Mezun olduğum zamanlar (2002) inanılmaz bir EJB fırtınası esiyordu ortalıkta. Hangi arkadaşımla görüşsem J2EE öğrenmem gerektiğini zaten J2EE öğrenmenin yaklaşık olarak EJB öğrenmek olduğundan bahsediyorlardı bana. Ben o sıralar İstanbulda küçük bir firmada VB 6 da buttonlara onClick() falan yazıyorum. Sonuçta yönelimimi java olarak belirleyip askerlikten sonra kendimi büyük bir şirkette büyük bir projenin ortasında buldum. Projenin mimari yapısı genel olarak EJB kullanılan J2EE projelerine benzemekteydi. Yani, session bean -> DAO -> entity bean çağrıları yapılıp sunum için gerekli alanları barındıran getter ve setter ları olan DTO (Data Transfer Object) lar da client server arası gider gelir. Geliştirimde EJB kaynaklı bazı sıkıntılar yaşamadığımız gibi kafamızda bazı soru işaretleri vardı. Örneğin;
· Entity beanleri insert ve update için kullanıp sorgularda pure SQL kullanıyorduk. (daha sonra entity bean iyice çileden çıkarınca insert ve update ler de SQL le yapılır oldu)
· EJB deployment descriptor lar oldukça karmaşıktı ve karıştımı bir daha toparlaması çok zor oluyordu. Bu sebeple entity bean değişikliklerimizi takımdan bir kişi yapardı, bunun deployment ı da epey sürerdi zaten.
· Session beanler de, entity beanler de ilginç interface leri implement ettikleri için kullanmadığımız pek çok metoda sahiptiler. Ekleyeceğimiz her özellik için session bean de ve DAO da yeni bir metod yazıyorduk, iş kurallarıda session bean de metodun içinde tabii. Bu pratik asıl bakım aşamasında sıkıntı doğurmuştu. 5000 satırlık session beanler ve 500 satırlık metodlar bu şekilde doğuyor.
· Öğrendiğimiz Object Oriented konseptlerle javanın Object Oriented bir dil olmasına rağmen hiç karşılaşmadım. Ortada ne bir Domain Model ne de iş mantığını içinde barındıran özel amaçlı sınıflar vardı. Her şey kafanın içinde.
· DB de herhangibir değişikliğin nereyi patlatabileceği hakkında yorum yapmak oldukça zordu. Gözden kaçan SQL ler olabiliyor. Zaten persistent frameworklerin çıkış amaçlarından biri de SQL karmaşasına son vermek değil mi?
Bu saydıklarımın hiç biri bizim yanlışımızdan kaynaklı sorunlar değil. EJB ile geliştirilen projelerin hemen hepsinde benzer sıkıntılar yaşanmış.

Bu sebeple bazı yazılım geliştiriciler acaba J2EE uygulamaları daha basit bir şekilde yazılamaz mı diye kafa yormuş ki ortaya Spring gibi Hibernate gibi lightweight framework ler çıktı. Yazılım dünyası EJB den Spring, Hibernate ikilisine öyle hızlı kaçtı ki sonradan çıkan EJB 3 belki de hakettiği ilgiyi göremedi. EJB 3 ile yazılım geliştirmedim ama okuduğum kadarıyla geliştiricilerin serzenişleri dikkate alınmış ve daha kullanılabilir bişey çıkmış ortaya. Ama bence hala Spring, Hibernate ikilisinin gerisinde.

Önceki projem de Spring i, Hibernate i duyup biraz okudum. Sonra yönelimimi Spring olarak belirleyim şimdiki projeme geldim :).

Spring in ve Hibernate in bence en güzel yanları Domain Modelinize ve POJO larınıza hiç bir şekilde müdahele etmemeleri. Enterprise bir uygulama geliştirirken transaction management ve security gibi servislere ihtiyaç duyarsınız. Daha önce EJB Container tarafından sağlanan bu servisler Spring ile kolayca sağlanabiliyor. Örneğin bir iş servisinin transactional yapılması için belli bir interface i implement etmesi gerekmiyor, Spring ile bunu 2 satır xml yazarak sağlayabiliyorsunuz. Spring ve Hibernate ile POJO tabanlı yazılım geliştirirken iş mantığınız üzerine yoğunlaşıp gerekli diğer servisler için fazlaca vakit harcamanıza gerek kalmıyor. Aşağıdaki tabloda kalsik EJB tarzın ve POJO tabanlı yazılım geliştirmenin kısa bir karşılaştırması yapılmıştır.


Klasik EJB tarzı:
Organizasyon: Prosedural tarz kodlama
Implementation: EJB tabanlı
Database erişimi: JDBC/SQL veya Entity bean
Sunum katmanına dönülen veri: DTO lar
Transaction Management: EJB container managed transactions
Application Assembly: Explicit JNDI lookup

POJO tabanlı:
Organizasyon: Object Oriented dizayn
Implementation: POJO
Database erişimi: Persistence Framework
Sunum katmanına dönülen veri: Business Objects
Transaction Management: Spring Framework
Application Assembly: Dependency Injection

EJB, yazılım geliştiricileri prosedural tarzda kodlamaya zorlarken, POJO tabanlı geliştirim herahangi bir tarza zorlamaz. Eski alışkanlıklar sebebiyle pek çok POJO tabanlı geliştirilen yazılımda maalesef prosedural tarzda geliştirilmeye devam etmiştir. POJO lar birer DTO gibi sadece alanlar ve getter setter larıyla doldurulmuş iş mantığı yine servislere yığılmıştır. Aslında iş mantığının karmaşık olmadığı durumlarda bu tarz geliştirim daha mantıklı olabilir, fakat ortada karışık bir iş mantığı varsa bu mantığı POJO lara koymak ve Object Oriented konseptlerden faydalanmak daha akıllıca olur. Bu konu Martin Fowler ve Chris Richardson gibi ustaların bloglarında da yer almış ve literatüre Anemic Domain Model ve Rich Domain Model olarak geçmiştir.

Schema Export with Ant

After some difficulties I have run schema export with ant. We use a separate propeties file with the same content as the jdbc.properties file that is used in connecting applications to the DB, in order to run the schema export task. Actually schemaexport also have "properties" attribute but it throws an exception like this.

[schemaexport] java.lang.UnsupportedOperationException: The user must supply a JDBC connection
[schemaexport] at org.hibernate.connection.UserSuppliedConnectionProvider.getConnection(UserSuppliedConnectionProvider.java:30)
[schemaexport] at org.hibernate.tool.hbm2ddl.ManagedProviderConnectionHelper.prepare(ManagedProviderConnectionHelper.java:28)

hibernate.cfg.xml





build.xml





You can download here working copy of our sample project.

Adding Spring and Hibernate to Our Hello World JSF Application

In this section we will add Spring and Hibernate Capabilities to our sample web application So for this, we will have to add the spring and hibernate libraries and configuration files to the web application.
So, to integrate Hibernate and Spring frameworks with JSF framework we will have to make some changes and copy jar files related with the individual frameworks.

After downloading spring, hibernate and MySQL then installing MySQL we ready to start this section.

copy dom4j.jar from spring-framework-2.5.1\lib\dom4j directory into lib directory.
copy spring.jar from spring-framework-2.5.1\dist directory into lib directory.
copy jta.jar from spring-framework-2.5.1\lib\j2ee directory into lib directory.
copy servlet-api.jar from spring-framework-2.5.1\lib\j2ee directory into lib directory.
copy hibernate3.jar from hibernate-3.2 directory into lib directory of our application.

Finally here is the list of jar files in our application's lib directory:


In the figure below, you can see additional files and directory structure formed after adding spring and hibernate capabilities to our sample project.




Person.java


package pojo;
public class Person {
Integer id;
String name;
public Integer getId() {
return id;
}
public void setId(Integer id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}


As you see our sample pojo has two attribute id and name. Our aim is to add this pojo to the database triggered by a button in the jsp page. Everything is simple now, we will add other required attributes later.

Person.hbm.xml

Create a hibernate mapping for any pojo that must be persisted. This is defined in another XML file (one per persistent object) which has an hbm.xml extension.

jdbc.properties

jdbc.driverClassName=com.mysql.jdbc.Driver
jdbc.url=jdbc:mysql://localhost:3306/sampleproject
jdbc.username=sampleproject
jdbc.password=sampleproject
hibernate.dialect=org.hibernate.dialect.MySQLDialect

We use this property file for connecting database.

spring-context.xml

Welcome.java

faces-config.xml

add tags shown below to web.xml.

In this file;

• The contextConfigLocation parameter defines the Spring configurations files to load, as shown in the servlet context below. If we wanted to load multiple Spring configuration files, we could use a comma as a delimiter in a tag.
• ContextLoaderServlet will load the Spring configuration files when you start the Web application.

Starting Web Application Development 2

I have recorded the development phase of “Hello World" JSF application but as you see it's not readable. You may reach the readable version of this video from my colleague Mehmet Gürsul's personal web site.

Now I’ll try to identify the steps of the “Hello World" JSF application.
Step 1 - Setting the workspaces JRE: We have to set the JRE of the workspace with the downloaded SDK 6’s JRE. Of the record, now SDK 6 is open source and you can attach the source files to view the code behind the class implementations. In the developing process I will be giving all the necessary source files of the related open source API’s.

Step 2 - Creating dynamic web project: By using project wizard we crate a new dynamic web project with using the JSF1.2 capabilities. In the wizard we have to modify some of the default values.

We have to increase Java Server Faces 1.1 to 1.2 and Dynamic Web Module 2.4 to 2.5 as the version 2.4 doesn't support Java Server Faces 1.2.

Step 3 - Configuring classpaths: After project is created we must add required jar files to project lib folder. Now required jars are only MyFaces implementation jars and their dependencies. You can find these jars MyFaces lib folder. To run our application we need one more jar that name is jstl.jar and standart.jar, you can find these jars tomcat\webapps\examples\WEB-INF\lib folder.

I'm sure you could easily add a server and create sample jsp to run our application. I want to talk about little what happened backround. Our faces-config.xml is empty yet. web.xml has two significant attributes, one of them is <servlet> and the other one is <servlet-mapping> .

<servlet>

<servlet-name>Faces Servlet</servlet-name>

<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>

<load-on-startup>1&lt:/load-on-startup>

</servlet>

When an event occurs click a button for example, the event notification is sent via HTTP to the server. On the server is a special servlet called the FacesServlet. Each JSF application in the Web container has its own FacesServlet. For JSF requests to be processed, they must be directed to the FacesServlet.

<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/faces/*</url-pattern>

</servlet-mapping>



This means that the URL of every request must contain the /faces/ pattern, as specified in the url-pattern element under the element.

We will add many capabilies in our sample project step by step. Every steps may come additional elements web.xml and faces-config.xml or new configuration files. I try to explain every element shortly.

Next step is connecting database and add simple domain object to database.

Starting Web Application Development 1

In this blog, i will try to explain my experiences about building web applications that includes many populer frameworks and tools. I'm planning to introduce building pure web application and then i will tell adding populer tools to this web application like JSF, Spring, Hibernate etc. Whenever i add a tool or framework, i will explain why we did this and benefits of this. Also i will write all exceptions caused by jar incompatibles.
First, we will build Hello World application with Eclipse IDE, JSF Apache MyFaces implementation and Apache Tomcat. Required downloads for starting listed as below:

• Download Java EE + JDK then install default values.


• Download Eclipse IDE then extract (Eclipse doesnt come with a setup. You can just extract and run Eclipse).


• Download latest core - zip version Tomcat 6 then extract.


• Download MyFaces zip version then extract.
  

We will come to other tools but for now these are enough.

Note: JAVA_HOME variable must be added to environment variables to start Tomcat.