Archiwum dla kategorii ‘JavaEE’

PRAKTYCZNY ENVERS

piątek, Sierpień 20, 2010

Envers jest dodatkiem do Hibernate’a pozwalającym na automatyczne zapisywanie historii zmian encji (audytu). Envers używa pojęcia rewizji – co oznacza, że każda zmiana dowolnej (audytowalnej) encji tworzy nową rewizję. Nowy rekord jest zapisany do tabeli, a na podstawie starego zostaje utworzona rewizja i zapisana do dodatkowej tabeli wraz z poprzednimi wartościami.

(więcej…)

Autor: Mateusz Mrozewski

Kategoria Bez kategorii, JBoss, Java, JavaEE | Brak Komentarzy »

JavaFX jako GUI do JBoss Seam? Nie ma problemu!

środa, Sierpień 18, 2010

Jakiś czas temu napisałem artykuł opisujący wstępne założenia JavyFX. Wtedy też obiecałem, że gdy uda mi się uruchomić aplikację FXową na serwerze aplikacyjnym, podzielę się doświadczeniem. Właśnie nadszedł ten czas.

(więcej…)

Autor: Adam Andrzejewski

Kategoria Interfejs, JavaEE, RIA | Brak Komentarzy »

OSGi bez irytacji

wtorek, Marzec 9, 2010

Niedawno, tworząc pluginy do JIRA, natknąłem się na dość irytujący problem, który objawiał się dziwnymi komunikatami o niemożności zaimportowania niektórych pakietów. Ponieważ pluginami tymi są moduły OSGi, postanowiłem nieco zgłębić to zagadnienie.

(więcej…)

Autor: Adam Andrzejewski

Kategoria JavaEE | Brak Komentarzy »

JSR-303 – przepis na fasolkę. Bardzo dobrą poniekąd. Cz. 1

czwartek, Luty 11, 2010

Finalna wersja specyfikacji JSR-303: Bean Validation ukazała się światu pod koniec ubiegłego roku (2009). Jest to kolejny przysmak a’la carte z renomowanej kuchni Gavin’a King’a i spółki, który doczekał się formalnej specyfikacji. Zatem – delektujmy się przez chwilę…

Dla osób niewtajemniczonych wyjaśniam, że mam na myśli produkt hibernate-validator, który jest protoplastą specyfikacji.
Wraz z nią otrzymaliśmy jej implementację referencyjną w postaci produktu hibernate-validator w wersji 4.
Świadomy tego, że bezapelacyjnie każdego ta historia urzekła przejdę do konkretów.
Dlaczego w ogóle o tym piszę? istnieje co najmniej kilka powodów:

  1. Jest to nowy standard w ramach Javy.
  2. Będzie wchodził w skład JEE 6.
  3. Bardzo łatwo się go używa – również na platformie SAP NetWeaver. :)
  4. Posiada nowe rozbudowane API oraz nowe możliwości rozszerzeń (np. tzw. “composite constraints”).
  5. W sposób przezroczysty integruje się z już posiadanym kodem.

Ponieważ jest to artykuł subiektywny, nie zamierzam w nim wymieniać wszystkich właściwości oraz różnic w specyfikacji JSR 303 w stosunku do starego hibernate-validator’a. Ze szczegółami można zawsze zapoznać się pobierając specyfikację ze stron Java Community Process.

Moim zdaniem bardzo istotna jest rozbudowa specyfikacji o możliwość definiowania mechanizmów walidacji za pomocą deskryptorów XML. Być może niektórzy czytelnicy posądzą mnie tutaj o herezję, ponieważ dziesiątki deskryptorów dostępnych w JEE to swoiste “małe piekiełko”. W przypadku walidatora jest to bardzo dobry pomysł o czym świadczą silne argumenty:

  1. Deskryptory pozwalają na zastosowanie walidacji w beanach dostarczanych w postaci bibliotek,
  2. Definicje w deskryptorach uniezależniają walidowane komponenty od API walidatora oraz własnych walidatorów w formie rozszerzeń.

Poniżej przedstawiam przykład kodu z zastosowaniem adnotacji oraz odpowiednika z zastosowaniem deskryptora xml.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
// Person.java
package test.beans;
import javax.validation.constraints.NotNull;
import javax.validation.Size;
import javax.validation.constraints.Past;
import java.util.List;
import java.util.Date;
import javax.validation.Valid;

public class Person {

    // wymuszenie wartości różnej niż null
    @NotNull(message="Imię nie może być puste")
    private String name;

    // wymuszenie wartości różnej niż null
    @NotNull(message="Nazwisko nie może być puste")
    private String surname;

    // wymuszamy datę przeszłą w stosunku do czasu systemowego
    @Past(message="Należy podać datę przeszłą")
    private Date birthDate;

    // oczekiwanie, że w kolekcji będzie co najmniej jeden element
    @Size(min=1,message="Należy podać co najmniej jeden adres")
    @Valid // wskazanie aby implementacja wykonała również walidację adresów
    private List<Address> adrList;
    (...)
}
----------------------------------------------------------
//  Address.java
package test.beans;
import javax.validation.constraints.NotNull;


public class Address {

    // wymuszenie wartości różnej niż null
    @NotNull(message="Miasto nie może być puste")
    private String city;

    (...)
}

Stan analogiczny do powyższego kodu możemy uzyskać za pomocą następujących definicji w deskryptorze xml:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
<?xml version="1.0" encoding="UTF-8"?>
<!-- sample-constraints.xml -->
<constraint-mappings
   xmlns="http://jboss.org/xml/ns/javax/validation/mapping"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/mapping validation-mapping-1.0.xsd">

    <default-package>test.beans</default-package>

    <bean class="Person" ignore-annotations="true">
        <field name="name">
            <constraint annotation="javax.validation.constraints.NotNull">
                <message>Imię nie może być puste</message>
            </constraint>
        </field>
        <field name="surname">
            <constraint annotation="javax.validation.constraints.NotNull">
                <message>Nazwisko nie może być puste</message>
            </constraint>
        </field>
        <field name="birthDate">
            <constraint annotation="javax.validation.constraints.Past">
                <message>Należy podać datę przeszłą</message>
            </constraint>
        </field>
        <field name="adrList">
            <constraint annotation="javax.validation.constraints.Size">
                <message>Należy podać co najmniej jeden adres</message>
                                <element name="min">1</element>
            </constraint>
            <valid/>
        </field>
    </bean>

    <bean class="Address" ignore-annotations="true">
        <field name="city">
            <constraint annotation="javax.validation.constraints.NotNull">
                <message>Miasto nie może być puste</message>
            </constraint>
        </field>
    </bean>

</constraint-mappings>

Nie jest trudno wywnioskować, że wszystkie ograniczenia zdefiniowane w kodzie źródłowym mają swoje odpowiedniki w deskryptorze. Aby powyższe przykłady uruchomić, konieczne jest jeszcze skonfigurowanie całego “silnika” walidacji.
Konfigurację realizuje się przez zamieszczenie w katalogu META-INF pliku o nazwie validation.xml, który jest deskryptorem konfiguracji JSR-303.
Oto przykład pliku:

1
2
3
4
5
6
7
8
9
<?xml version="1.0" encoding="UTF-8"?>
<validation-config
 xmlns="http://jboss.org/xml/ns/javax/validation/configuration"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/configuration validation-configuration-1.0.xsd">

    <default-provider>org.hibernate.validator.HibernateValidator</default-provider>
    <constraint-mapping>META-INF/sample-constraints.xml</constraint-mapping>
</validation-config>

W powyższym pliku określono następujące właściwości silnika:

  1. Default-provider wskazuje dostawcę implementacji JSR-303, którym jest oczywiście hibernate validator
  2. Constraint-mapping wskazuje na dodatkowy deskryptor xml z definicją ograniczeń, można zdefiniować wiele plików z definicją ograniczeń

Na deser pozostał mi jeszcze prościutki przykład uruchomienia walidacji w kodzie z zastosowaniem poprzednich przykładów.
Oto on:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// ValidationTest.java
package test.beans;
import javax.validation.ConstraintViolation;
import javax.validation.Validation;
import javax.validation.ValidatorFactory;

public class ValidationTest {

    public static void main(String[] argv) {
        ValidationTest vt = new ValidationTest();
        Person p = new Person();
        p.name= "John";
        t.validateBean(p);
        return;
    }

    public void validateBean(Person p) {
        ValidatorFactory vf = Validation.buildDefaultValidatorFactory();
        Set<ConstraintViolation> violationSet = vf.getValidator().validate(p);
        for(ConstraintViolation cv : violationSet ) {
             System.out.println(cv.getMessage());
        }
        return;
   }

}

Smacznej walidacji :)

Autor: Daniel Ramotowski

Kategoria JBoss, Java, JavaEE | Brak Komentarzy »

Hibernate i efektywne sekwencje

wtorek, Grudzień 15, 2009

Do napisania kilku słów na temat optymalizacji używania generatorów w Hibernate 3 natchnął mnie kolega z pracy Krzysiek – prawdziwy specjalista Oracle i tropiciel motocyklistów w białych pantoflach :) (użyłem określenia “tropiciel”, w celu podkreślenia swobodnego charakteru tej publikacji i zwiększenia percepcji treści merytorycznych wśród czytelników; ma to oczywiście związek z pewnym zabawnym wydarzeniem ale nie o tym będzie tutaj mowa).

(więcej…)

Autor: Daniel Ramotowski

Kategoria Java, JavaEE | Brak Komentarzy »

Zasoby na Websphere 7 – aktualizacja właściwości

wtorek, Listopad 17, 2009

Wedle powszechnie utartej opinii im więcej zasobów, tym lepiej. Poza tym od przybytku głowa nie boli, więc zająłem się tworzeniem zasobów na serwerze aplikacji IBM Websphere 7 (źródła danych aplikacji JEE i takie tam inne) . Oczywiście w ferworze twórczości wybrałem bardziej skomplikowaną ścieżkę, używając narzędzia wsadmin, które jest dostarczane z serwerem.

(więcej…)

Autor: Daniel Ramotowski

Kategoria JavaEE, Websphere | Brak Komentarzy »

Dobieramy się do JNDI

piątek, Wrzesień 18, 2009

Dość często w celach testowych muszę wywołać komponent EJB po interfejsie zdalnym i zawsze w takim momencie brakuje mi kompendium informacji na temat ustawiania właściwości kontekstu, specyficznych dla dostawcy serwera aplikacji.
To powód, dla którego piszę ten post, a Ty go zapewne czytasz :) .

(więcej…)

Autor: Daniel Ramotowski

Kategoria JavaEE | Brak Komentarzy »

JRuby, Script Engine i Java

środa, Maj 13, 2009

JRuby, „w 100% czysta implementacja Javy na bazie języka Ruby”, jak określają go twórcy, dostarcza zalety obydwu tych języków. W artykule tym skupię się jednak tylko na jednym ciekawym aspekcie JRubiego, czyli wykorzystania go bezpośrednio w aplikacjach stricte javowych poprzez Script Engine.

(więcej…)

Autor: Adam Andrzejewski

Tagi: , ,
Kategoria JavaEE | Brak Komentarzy »

Prevayler, czyli jak sobie radzić bez relacyjnej bazy danych…

piątek, Maj 8, 2009

Prevayler to biblioteka implementująca ideę systemu persystentnego w języku Java. Strona główna projektu dostępna jest pod adresem www.prevayler.org a plik jar jest do pobrania ze strony  http://sourceforge.net/project/showfiles.php?group_id=36113

A czym jest system persystentny? To po prostu idea przechowywania danych  wszystkich danych w pamięci operacyjnej w ich „naturalnej” postaci zamiast standardowych tabel relacyjnej bazy danych.

(więcej…)

Autor: Adam Andrzejewski

Kategoria JavaEE | 2 Komentarzy »

Porównanie narzędzi Continuous Integration

czwartek, Kwiecień 9, 2009
bamboo2 hudson1 anthillpro cc

Idea Continuous Integration jest odpowiedzią na ciągle rosnące koszty integracji systemów. Jest praktyką wytwarzania oprogramowania, która zakłada ciągły proces budowania i instalacji projektu. Pozwala to na minimalizację kosztów, związanych z wdrożeniem gotowego produktu.

W naszym artykule dowiesz się, co wyróżnia alternatywne narzędzia Continuous Integration oraz które z nich najlepiej wybrać.
(więcej…)

Autor: Dominik Kapusta

Kategoria JavaEE, Narzędzia | Brak Komentarzy »