Splatch’s devblog

Każdy z obiektów który jest konfigurowany w kontekście Springa ma szansę zweryfikować swój stan tuż po zainicjowaniu wszystkich wartości, które zostały mu przekazane. Wynika to z tego, że czasami obiekty potrafią działać na kilku różnych zasobach i można wstrzyknąć do nich tylko jeden rodzaj tegoż. Czasami po prostu potrzebujemy sprawdzić czy są przekazane wszystkie ustawienia konfiguracyjne bądź zainicjować połączenie do bazy danych na podstawie przekazanych parametrów.

Mamy wówczas do wyboru dwie metody. Pierwszą z nich jest implementacja interfejsu org.springframework.beans.factory.InitializingBean. Jeśli wyrzuci ona jakiś wyjątek to Spring wyrzuci wyjątek wyżej i wstrzyma powoływanie kontekstu. Oto przykład:

package org.code_house.samples.spring;

import java.util.Properties;

import org.springframework.beans.factory.BeanInitializationException;
import org.springframework.beans.factory.InitializingBean;

public class PropertiesConfiguration implements InitializingBean {

    /**
     * Ustawienia konfiguracyjne.
     */
    private Properties properties;

    public void setProperties(Properties props) {
        this.properties = props;
    }

    public void afterPropertiesSet() throws Exception {
        if (properties == null) {
            throw new BeanInitializationException("Nie przekazano ustawień "
                +"konfiguracyjnych. Pole properties jest wymagane.");
        }
    }
}

Spring nie wymusza jednak implementowania interfejsu. Jeśli nasz kod już istnieje i jest metoda która weryfikuje stan obiektu możemy użyć atrybutu init-method dla znacznika bean:

    <bean class="org.code_house.samples.xml.JaxbConfiguration"
        init-method="verify">
        <property name="source" value="classpath:data.xml" />
    </bean>

Jako, że nie zawsze mam czas pisać dłuższe noty, a nie wszyscy znają Springa postanowiłem publikować krótkie porady, które mogą kiedyś komuś się przydać.

Klasa java.util.Properties to jeden z najprostszych sposobów na odwołanie do prostych ustawień konfiguracyjnych. Składnia pliku properties jest zbliżona do ini i wygląda następująco:

nazwa.wlasnosci wartosc
inna.nazwa.wlasnosci=costam
# to jest komentarz
jeszcze.cos.nowego

Jeśli chcemy przekazać obiekt klasy Properties do jakiegoś innego obiektu możemy skorzystać z poniższej wstawki w kontekście springa:

<bean class="org.springframework.beans.factory.config.PropertiesFactoryBean">
    <property name="location" value="classpath:corba.properties" />
</bean>

Ostatnimi czasy odbyłem kilka spotkań w większych i mniejszych firmach. To co mnie zastanowiło po jednej z ostatniej rozmów to zdanie:

Korzystamy z profesjonalnych narzędzi takich jak Tibco, WebMethods, czasami Bea.

Co łączy wymienione produkty? Otóż wszystkie są rozwiązaniami z klasy EAI i … są płatne. Zdanie to usłyszałem w odniesieniu do Apache Service Mix, którym się interesuję. Wniosek z tej wypowiedzi jaki udało mi się wysnuć od razu stał się tematem tej noty, czyli jeśli coś nie jest komercyjne nie jest też profesjonalne. Tak jakby OSS był gorszym rozwiązaniem od kupienia licencji na pudełkowe rozwiązanie od jakiegoś producenta.

Trudno mi się z tym zgodzić ponieważ od początku swojej pracy obracam się w otwartym kodzie i niejeden raz korzystałem z wolnodostępnych narzędzi. Pamiętam jedną z sytuacji, gdzie w jednej z bardzo dużych międzynarodowych firm projekt przez pracowników był uważany za profesjonalny ponieważ był kupiony Oracle oraz licencja na jakiś przestarzały serwer. Kuriozalne, im więcej wydasz pieniędzy na licencję tym bardziej projekt jest profesjonalny. Klient dopiero wydając masę pieniędzy na licencję ma prawo powiedzieć, że kupił profesjonalny, będący na wysokim poziomie, produkt.

Zainspirowany tym wszystkim sięgnąłem do słownika języka polskiego PWN w poszukiwania hasła profesjonalny:

profesjonalny
1. będący specjalistą w jakiejś dziedzinie
2. uprawiany jako zawód
3. będący na wysokim poziomie w danej dziedzinie
4. spełniający wymagania profesjonalistów

Definicja słownikowa nie wspomina nic o pieniądzach, ale dodajmy ją w myśl pierwszego, zacytowanego zdania:
1. Jeśli chcesz być specjalistą w jakiejś dziedzinie musisz korzystać z komercyjnych rozwiązań.
3. Wysoki poziom w danej dziedzinie osiągniesz korzystając tylko z komercyjnych produktów.
4. Produkt jest profesjonalny jeśli spełnia wymagania profesjonalistów, a jednym z kryteriów doboru tego narzędzia zgodnie z punktem 1 jest płatność.

Czy zgadzacie się z takimi założeniami? Ja – w ogóle. Nie jestem maniakiem Open Source ani fanatykiem wolnego oprogramowania. Nie jestem też nadmiernym zwolennikiem komercyjnych rozwiązań, ale to co powinno być kluczowe dla każdego programisty a tym bardziej firmy świadczącej usługi programistyczne to szukanie skutecznego rozwiązania problemu a nie wydania pieniędzy.

Reasumując, moje zdanie to:

• Nie wszędzie pasuje OSS.
• Nie wszędzie konieczne są rozwiązania komercyjne.
• Nie zawsze nabycie produktu rozwiązuje wszystkie problemy. Czasami rodzi też nowe.

Warto zwrócić uwagę na to, że producenci oprogramowania czasami mamią i zarzucają nas całą masą marketingu, hasłami i wszelakimi buzzworld typu SOA, AJAX itp. podczas gdy rozwiązania oparte na OSS nie są reklamowane, a zdarza się sytuacje że mają funkcjonalność zbliżoną bądź nawet większą niż komercyjne.

Jakie jest, drodzy czytelnicy, wasze zdanie na temat – czy OSS może być profesjonalny? Co czyni produkt profesjonalnym?