Google Chrome ile neyi amaçlıyor?

Günlerdir Google’ın yeni tarayıcısı hakkında pek çok şey söyleniyor, diğer tarayıcılarla kıyaslamalar yapılıyor, hızından bahsediliyor. Yapılan pek çok yorumda yeni tarayıcının performansı üzerinde duruluyor, getirdiği yenilikler ve açık kaynak kodlu olması hasebiyle tarayıcı pazarından ne kadar pay alacağı değerlendiriliyordu.

Ürünleri açısından bakıldığında tamamen web üzerine kurulu, hatta web uygulamalarının tanımını kökten değiştiren bir şirketin tarayıcılarla ilgili hiç bir adım atmaması beklenemezdi. Aslında Firefox ile bu pazara belli bir oranda destekte veriyordu. Ancak Chrome doğrudan kendi içinden çıktı ve ortaya attığı fikirler, özellikler açısından değerlendirildiği vakit innovatif çözümler de ortaya koymaktadır.

Google’ın Chrome ile yapmaya çalıştığı şey yeni bir tarayıcı savaşları başlatmak olmasa gerek. Geçmişte bu konuda Internet Explorer ve Netscape kıyasıya çarpıştılar ve platform avantajı sayesinde de IE bu savaştan galip çıktı. Google’ın aynı senaryonun tekrarlanmasını istediğini zannetmiyorum. Zaten GWT, Gears gibi uygulama geliştirme platformları ve teknolojiler sayesinde tarayıcı bağımsız çalışan uygulamalar ortaya çıkarmakta gayet başarılılar. Ancak mevcut tarayıcıların ve web uygulama geliştirme teknolojilerinin kısıtları nedeniyle geliştirdikleri uygulamaların özelliklerini ve kabiliyetlerini zenginleştiremiyorlar, çalışırlıklarını daha güvenilir ve sağlam hale getiremiyorlar. Kısacası çalıştırma platformu yani tarayıcılar, web uygulamalarının gereksinimlerini karşılamaktan çok uzak kalıyor. Bu noktada da Chrome gibi yeni bir tarayıcı geliştirerek, platformun iyileşmesi için bir standartlaşmaya gidilmesini beklemek yerine kendileri mevcut çıtayı birkaç seviye daha yukarı taşımayı hedeflemişler.

Ne Chrome, ne Firefox, ne de IE pazara tek başına hakim olabilir. Ancak Google sahip olduğu popülarite ve uygulamalarının yaygınlığı vasıtası ile Chrome’u ve dolayısı ile ona has yenilikleri web dünyasının önüne koyup, tarayıcıların kabiliyetleri açısından istediği ortamı oluşturmayı hedefliyor.

 


Yukarıdaki resmi Chrome’u anlatan cizgi roman içinden aldım. Bu resimde de anlatılmak istenen tarayıcının kullanıcı ile uygulamalar arasında tamamen transparan bir ortam haline gelmesidir. “We don’t want to interruptanything the user is trying to do. If you can just IGNORE the browser,we’ve done a good job.” ifadesi de Google’ın hedefini gayet net biçimde ortaya koyuyor. Kullanıcı ile uygulamalar arasında tamamen transparan biçimde yer alacak bir tarayıcının Google için kendi veya Microsoft tarafından üretilmiş olmasının bir önemi olmasa gerek.

Scott Berkun’un bloğundaki bir yazıda da bu konu ile ilgili çok çarpıcı bir alıntı var: “Although I’m sure Google would be thrilled if Chrome grabbed a sizable chunk of market share, winning a “browser war” is not its real goal. Its real goal, embedded in Chrome’s open-source code, is to upgrade the capabilities of all browsers so that they can better support (and eventually disappear behind) the applications. The browser may be the medium, but the applications are the message.”

A Small Silly Reminder For Unclosed Session Warning of Hibernate

If you suddenly get a warning, saying that ?unclosed connection, forgot to call close() on your Session? from Hibernate and you employ OpenSessionInViewFilter to manage your Hibernate sessions, check that your OpenSessionInViewFilter?s filter mapping in web.xml comes before any other filter mappings, for example Acegi Security Filters, especially! Because, those other mappings may trigger some database operations depending on Hibernate session, and if there is no open one, they will probably open, and again most probably left open it, as normally it is the job of OpenSessionInViewFilter to close Hibernate sessions at the end of the response. Just a silly reminder!

Telegraph Road

I am a big fun of British music band Dire Straits. Their “Telegraph Road” song is among the ones I most like and listen over and over again. It tells the story of a lone man settling down in wilderness, and his followers coming one after the other. It traces development of a big city out of a small community, all the way down to the Telegraph Road.

It is hard to say that Java Specification groups have had enough lessons from history of development. A long time ago Servlet specification came with its own pack, then came JSP and then came Portlet specifications. Unfortunately, all those aim to be a brick on the wall, well integrated with each other, the reality is a big disappointment.

Take Servlet Filter mechanism as an example, although portlets are valid JEE web applications, there is no way for Filters, defined in the web.xml, to get applied to when a portlet request comes in. Hence, people all around the community started to develop “patches” to accomodate this necesssity. Spring Portlet MVC employs HandlerInterceptor, or Apache tries to simulate them with PortletFilters.

When JSF specification arrived into the town, it just appeared that nobody had cared enough to leave room for a healty growth. We need to employ “legacy” bridges to make our JSF enabled portlets to work within portals. Portlet specification assumed that content is not a full web page, but only a fragment of it, some JSF guys on the other hand developed codes that expect full page content to operate. Just look at those ExtensionsFilter and AddResource stuffs in MyFaces.

Portlet specification says that portal is a web application in addtion to being a portlet container, and individual portlets could also be separate web application as mentioned above. Bu that’s all, they didn’t go further, didn’t settled down enough rules for how communication between portlet container and its individual portlets will be performed, and leaved us in a fog.

I think, we wait for lawyers to arrive first, and then rules will come along.

Spring Security ile Aynı Kullanıcının Oturum Sayısını Yönetmek

Spring Security kurumsal web uygulamaları için kapsamlı bir güvenlik framework’üdür. Kurumsal web uygulamalarında karşımıza çıkan pek çok kimliklendirme ve yetkilendirme ihtiyacına hazır bir çözümü içermektedir. Bu ihtiyaçlardan birisi de aynı kullanıcı ile aynı zamanda fakat farklı yerlerden yapılabilecek login sayısının denetlenmesidir. Spring Security bunun için sunduğu hazır yapıda iki farklı opsiyon sunar.

  1. Aynı kullanıcı ile farklı bir yerden login olunduğu vakit, eğer izin verilen oturum sayısı aşılmış ise son login olunan yerde hata vermek,
  2. Diğerinde ise halihazırda açılmış en eski oturumu sonlandırmaktır.

Spring Security 2.x ile gelen şema desteği sayesinde framrework’ü konfigüre etmek oldukça kolaylaşmıştır. Birinci durumu gerçekleştirmek için yapmamız gereken http elemanı içerisine aşağıdaki xml bloğunu eklemekten ibarettir.

<sec:session-management> 
     <sec:concurrency-control max-sessions="1" error-if-maximum-exceeded="true"/> 
</sec:session-management>

concurrency-control elemanı oturum sayısını kontrol eden özelliği framework’de aktive eder. max-sessions attribute aynı kullanıcı adı ile farklı yerlerden en çok kaç tane login gerçekleştirilebileceğini belirler. Bu sayı aşıldığındaki davranış ise error-if-maximum-exceeded attribute ile belirlenir. Eğer ikinci durumdaki gibi en son login işlemine izin verip en eski oturumu sonlandırmak istersek o zaman error-if-maximum-exceeded attribute’unun değerini false yapmamız yeterlidir.

<sec:session-management> 
    <sec:concurrency-control max-sessions="1" error-if-maximum-exceeded="false" expired-url="/expired.html"/>
 </sec:session-management>

İstenirse eski oturum kapatıldığı vakit kullanıcının yönlendirileceği sayfada expired-url attribute ile belirtilebilir. Herkese bol spring’li günler…>Spring Security kurumsal web uygulamaları için kapsamlı bir güvenlik framework’üdür. Kurumsal web uygulamalarında karşımıza çıkan pek çok kimliklendirme ve yetkilendirme ihtiyacına hazır bir çözümü içermektedir. Bu ihtiyaçlardan birisi de aynı kullanıcı ile aynı zamanda fakat farklı yerlerden yapılabilecek login sayısının denetlenmesidir. Spring Security bunun için sunduğu hazır yapıda iki farklı opsiyon sunar.

  1. Aynı kullanıcı ile farklı bir yerden login olunduğu vakit, eğer izin verilen oturum sayısı aşılmış ise son login olunan yerde hata vermek,
  2. Diğerinde ise halihazırda açılmış en eski oturumu sonlandırmaktır.

Spring Security 2.x ile gelen şema desteği sayesinde framrework’ü konfigüre etmek oldukça kolaylaşmıştır. Birinci durumu gerçekleştirmek için yapmamız gereken http elemanı içerisine aşağıdaki xml bloğunu eklemekten ibarettir.

<sec:session-management>
  <sec:concurrency-control max-sessions="1" error-if-maximum-exceeded="true"/>
</sec:session-management>

concurrency-control elemanı oturum sayısını kontrol eden özelliği framework’de aktive eder. max-sessions attribute aynı kullanıcı adı ile farklı yerlerden en çok kaç tane login gerçekleştirilebileceğini belirler. Bu sayı aşıldığındaki davranış ise error-if-maximum-exceeded attribute ile belirlenir. Eğer ikinci durumdaki gibi en son login işlemine izin verip en eski oturumu sonlandırmak istersek o zaman error-if-maximum-exceeded attribute’unun değerini false yapmamız yeterlidir.

<sec:session-management>
  <sec:concurrency-control max-sessions="1" error-if-maximum-exceeded="false" expired-url="/expired.html"/>
</sec:session-management>

İstenirse eski oturum kapatıldığı vakit kullanıcının yönlendirileceği sayfada expired-url attribute ile belirtilebilir. Herkese bol spring’li günler…