Success with JBoss AS + Struts + AOP

Tutorial how to set up JBoss, Struts and AOP together

It’ll be about JBoss Application Server and Aspect Oriented Programming and web applications.

As everyone who knows me know I develop simple, yet powerful web application. At least I try. There was time at the beginning of this adventure I’ve used Tomcat web container among with Struts Model-View-Controller framework.

After some time, Aspect Oriented Programming (thanks to Andrew) came into my developer’s life. It is JBoss AOP that I ‘play’ with.

I still need to develop web application. How to include AOP into web application? First of all I decided not to play with Tomcat any more. Main reason is I knew JBoss Application Server also has Tomcat embedded inside it. Also JBoss AS, as the JBoss company is the mother of JBoss AOP, has AOP included inside their product.

So I took the freshest JBoss 4.0.1 release of JBoss AS and unpacked it.

I use Ant for my application, so examples will use it. This “tutorial” is also valid for Java 1.4 version. I don’t know if there are any problems with 1.5.

I assume you know basics of JBoss AOP and how to deploy [Struts] web application on Tomcat.

Steps to successfully deploy AOP enabled web application on JBoss AS with Struts:

  1. download JBoss AS 4.0.1. Unpack. I use /usr/local/java/jboss/ directory.
  2. prepare your web applicationI mean get your *.war file that was running on Tomcat with Struts. I had to change nothing to the files.
  3. next step is to write your aspects and put them along with your plain Java source files
  4. next, write JBoss AOP configuration file. It is usually called jboss-aop.xml

    Multiple aspects’ configuration files *-aop.xml. Aspect library (libraries)

  5. now when we have all source files, configuration files, we need do compile sources
      AOP sources compilation process consists of four parts:

    • Get the libraries:Libraries needed to compile aspects are in these directories:
      • JBOSS_HOME/client/*.jar
      • JBOSS_HOME/server/default/deploy/jboss-aop.deployer/*.jar
      • qdox.jar
    • Compile your sources:compile all sources, including aspects with plain Java compiler (I use <javac>)
    • Compile JBoss AOP annotations (if you use them):



      classname="org.jboss.aop.ant.AnnotationC" classpathref="compile_classpath"/>
      classpathref="run_classpath"
      bytecode="true">




    • Compile all sources using AOP compiler:

  6. Ok. The next step is packaging all of it. So, basically, all we need is to pack all files related to web application into application.war file, and all files related to AOP into application.aop file. After doing this, put those two files into one file application.sar with one configuration file.So here is how the structure of my deploy/directory looks like:
        /application.sar/
            /META-INF:
                jboss-service.xml
            /application.aop/
                    /META-INF:
                        jboss-aop.xml
            /application.war/
                    /WEB-INF:
                        /classes:
                            /org:
                                /nthx/
                                /prevayler/:
                                    *.class, *MethodInvocation*.class
                        /lib:
                            ant.jar, log4j-1.2.8.jar, javax.servlet.jar, ...
                        /dtds/
                        /tlds/
                        struts-config.xml
                        tiles-defs.xml
                        validation.xml
                        validator-rules.xml
                        web.xml
                    /images:
                        book.png, ...
                    /includes:
                        inc-footer-links.jsp, ...
                    /pages:
                        index.jsp, ...

    As you also see I’ve unpacked contents of all archives into directories with the same name. Though I believe it’s not necessary.

    The contents of jboss-service.xml is simply:

        <?xml version="1.0" encoding="UTF-8"?>
        <server>
        </server>
  7. [optional step] edit AOP configuration file of default/ configuration of JBoss AS to enable weaving process:We have to choices here: if we precompile sources with <aopc>, <annotationc> (as it is in my situation) then we do nothing and go to the next stepOtherwise we may not precompile sources using those two tasks! Aspects may be hot deployed. But for this, one must adapt configuration:
    Change JBOSS_HOME/server/default/deploy/jboss-aop.deployer/META-INF/jboss-service.xml and set variable EnableTransformer to true
  8. deploy your application by putting it under JBOSS_HOME/server/default/deploy/ directory. I just expand the file contents into JBOSS_HOME/server/default/deploy/application.sar/ directory
  9. run JBoss AS: JBOSS_HOME/bin/run.sh -c default.For my needs I also update -Xmx value in run.conf file
  10. point your browser to http://localhost:8080/application/

That is all. Of course you may change the application name into some other value, it is just an example.

I hope it helped you :)

Any questions, feedback.. put below.

Share on Twitter

[Polish] About objects, core systems, AOP services, fault tolerance

[Polish] Few words about software..

Słowa kluczowe: XP, eXtreme Programming, SQL, persistence, fault tolerance, informatyka, AOP, JBossAOP, AOP libraries

Tak sobie pomyślałem, że może trochę za ostry byłem ostatnio. Niby SQL do kosza, ale jednak psiocząc na niego, psioczę również na Was – ludzi, którzy czasem zostają zmuszeni do jego używania (no i na siebie, bo w pracy muszę implementować na potrzeby firmy archaicznymi metodami, warstwę danych z użyciem SQL, twu :/ )
Jeśli jesteście zmuszeni: przez złego szefa, kolegów z pracy, dostaliście nową pracę i nie wolno nic złego powiedzieć, jesteście, jesteśmy w tym dziwnym świecie i czasem może niektórym lepiej jest po prostu “popłynąć” z wirem rzeki.. wtedy może i możnaby wybaczyć takie podejście do “persistence”.

No dobra, ale czas na nowinki! :)

Pierwsze: tu nie chodzi o SQL lub coś innego. Postarajmy się sobie wyobrazić po co to wszystko? Po co cała ta informatyka? Pomijając aspekty formalne i naukowe, zostaje nam rzeczywistość. A rzeczywistość jest taka, że mamy prawdziwego człowieka, który najczęściej miał pomysł jak rozkręcić interes i potrzebuje zinformatyzować własne procedury tzw. biznesowe. Potrzebuje tego, bo z komputerem będzie łatwiej zobaczyć statystyki, prowadzić konta użytkowników, wykonywać internetowe płatności, wykorzystać system w celu ogólnodostępności systemu informatycznego z różnych fizycznie lokalizacji. To są bardzo ważne cele, które my jako informatycy musimy spełnić naszemu klientowi.
(druga rzeczywistość trochę bardziej skomplikowana to taka, że zastajemy już gotowy system, który nie spełnia wymagań klienta, oraz najczęściej z tego powodu sfrustrowanego klienta. W takim przypadku jednak konsekwencja, spokój, refactoring, testy i IMHO dotrzemy do portu)

Jaki jest więc nasz cel w tym momencie. Pierwsza i fundamentalna sprawa, to zrozumieć czego potrzebuje nasz klient. Nie damy rady tego zrobić bez dyskusji z klientem, bez dziesiątek historyjek użytkownika, bez kontaktu z nim.
Jeśli zrealizujemy ten pierwszy postulat, połowa sukcesu jest za nami. Co dalej? A dalej to już nasze informatyczne procedury. Dalej musimy przedstawić produkt informatyczny, który:

  • realizuje wszystkie biznesowe potrzeby klienta, poprzez implementacje tzw. logiki biznesowej – core system
  • udostępnia mechanizmy do obsługi i dostępu do takiego systemu – poprzez tzw. GUI.
  • jest odporny na awarie, coś co nazwiemy tutaj fault tolerance

Popatrzmy teraz na każdą z tych części produktu informatycznego z osobna z perpektywy mojego doświadczenia.

Core logic
Ta część jest zdecydowanie najciekawsza i wcale nie najprostsza. Ale celem mym i osób mi bliskich jest zaimplementowanie takiego świata obiektowego, aby był zrozumiały dla czytelnieka (tak! czytelnika, nasz kod służy przecież do czytania, “piszemy go tylko raz”). Jeśli będzie prosty i zrozumiały, to łatwo go rozszerzymy, łatwiej znajdziemy dotkliwy błąd, łatwo zmienimy. Tego nie trzeba udowadniać. Jest to jedna z nielicznych rzeczy, które od dziś kategoryzuje w kategorii: obvious.
Bardzo dobrze by było, abyśmy także nie mieli żadnych ograniczeń w konstrukcji świata obiektowego. Myślę tu o strukturze “grafu” naszych obiektów: dowolne cykliczne referencje w grafie, dowolne struktury posiadające inny struktury (kolekcje), itp itd.. plus jeden główny korzeń całego grafu.Core logic, znaczy także całkowicie czysty (plain) kod. Żadnego zapamiętywania danych, żadnej obsługi zdalnych wywołań lub czegokolwiek innego. Powiedzielibyśmy, że jest to program, który po uruchomieniu może “cośtam” zrobić, ale po zakończeniu pracy nic nie pozostaje. To takie programy, które pisaliśmy na pierwszym roku studiów.. (po “bazy danych” proszę czytać dalej)A jak sobie poradziłem w życiu z przyjaciółmi w realizacji prostoty świata obiektowego. Najpierw dzięki uprzejmości Andrzeja dostaliśmy do ręki obiektową “in-memory” bazę danych. Skorzystaliśmy. Otrzymaliśmy główny kod, w miarę “czysty”, co znaczy, że odwołania do warstwy danych nie były widoczne, ponieważ były ściśle zintegrowane z naszym światem

Jak sobie poradzimy na przyszłość? Identycznie. Zamiast Prevaylera użyjemy jednak PATa :)

Gui
W praktyce zostają nam do wyboru: standalone application, tzw. aplikacja okienkowa (dwie możliwości: pracująca zdalnie, lub całkowicie lokalna dystrybucja) lub web application, czyli dostęp poprzez przeglądarkę.Web application – o ile ulubiona, to nie pozbawiona wad, m.in. skąpa ilość możliwych komponentów okienkowych w porównaniu z aplikacją okienkową, ale za to dająca “zdalny dostęp do aplikacji” stosunkowo za darmoPytanie, któro sobie stawiam, to czy GUI jako aspekt (concern, zagadnienie), da się zautomatyzować? Persistence już zrobiłem z PAT, ale co z GUI. Strzeżcie się, bo jest to w moich planach! ;)
Myślę o czymś takim jak NakedObjects, lub podobne.

Fault tolerance
Ta część jest ciekawa. Nic jeszcze nie mówiliśmy o żadnej bazie danych. Może nawet nie będzie takiej potrzeby. Proszę zauważyć, że wymieniłem jedynie trzy części produktu informatycznego: core logic, GUI, fault tolerance. Nic więcej. Core logic, to w zasadzie, na pierwszy rzut oka, bezwartościowy program, jako, że nie zapamiętuje swojego stanu. Nawet jeśli uda nam się dorobić interfejs użytkownika, to nic po takim programie, bo po “zamknięciu” nawet pyłek po nim nie zostanie.Fault tolerance: tolerancja na błędy. Tłumaczę sobie to w taki sposób. “Nie zachowanie stanu aplikacji”, to swego rodzaju błąd. Jak poradzić sobie z takim błędem? Wymienię kilka poziomów “tolerancji” na błędy:
Zapamiętanie stanu na żądanie
W momencie uruchomienia aplikacji wczytaj wszystkie dane (nie mówię skąd), a w momencie zakończenia aplikacji, lub komendy “Zapisz stan” zapisz stan aplikacji
Zapis każdej zmiany stanu aplikacji
To jest najpopularniejsza metoda na persistence. W momencie zmianu stanu aplikacji, np. poprzez złożenie nowego zamówienia w sklepie internetowym, wywołaj odpowiedni auaktualnienie bazy danych. W momencie potrzeby odczytu danych, odczytaj je z bazy danych.
Memory replication
A co jeśli zreplikujemy pamięć operacyjną i ktoś nam dostarczy przezroczysty dostęp do niej? Replikacja oznaczałaby, że nawet jeśli jakiś sposób nastąpi awaria komputera, na którym uruchomiona jest aplikacja, to aplikacja nadal będzie działała, dopóki będzie uruchomiony co najmniej jeden komputer.Jest to całkiem dziwaczne i najbardziej niestandardowe podejście do persistence, a nawet do fault tolerance jakie mogę sobie wyobrazić, ale to zadziała. Zero obsługi zapisu danych. Po prostu nasza pierwszoroczna aplikacja działa sobie w nieskończoność.(trzeba będzie jednak wprowadzić jakąś możliwość zapisu danych w trybie “zapisz wszystko”/”odczytaj wszystko”, bo potrzebujemy uaktualniać działający program)

Tak czy inaczej, mam nadzieję, że persistence wyjdzie mi jako praca magisterska.. :)


PAT: Co to jest i po co? Więc po czasie używania oprogramowania Prevayler, nadszedł czas na zaimplementowanie w nim transakcji, co wymagałoby strasznie dużo roboty, zburzenia struktury świata obiektowego i obsługi dodatkowego kodu, czego nikt nie lubi. Powstało więc narzędzie, któro dostarcza niewidocznej warstwy danych, do core logic. To o czym marzyłem, to jak sobie wyobrażałem prosty kod stało się rzeczywistością. Proszę popatrzeć na kod przykładowej aplikacjinapisanej z użyciem PAT. Czyś nie jest to ładne? :)

Z tego co wiem, PAT jest pierwszym na rynku, darmowym frameworkiem dostarczającym przezroczystą obsługę warstwy danych. Nazywam to póki co: AOP annotated library. Co z tego wyjdzie? Zobaczymy co czas przyniesie..

Miłym akcentem pozdrawiam

Share on Twitter

Live ‘Presentation layer’ modification on XP client meeting

Agile way and live modification of “presentation layer”
on meeting with client..

My problem is, I develop software for librarian client. It is a library system (books, readers, lendings, etc..).

I try to adopt many XP characteristics; that is:

  • frequent client meetings
  • live code

First of all, the core system is already made. Requirements are based on few user stories, live talks with librarians and former library system (that needs to be exchanged into some modern software).

Let’s talk in detail about how I make user interface and how do I adopt it to librarian needs.
First, the technology used is Struts. The presentation layer consists of web pages written in Struts jsp’s format.
Second; when the core business system is done, then the only thing to do is to write presentation layer.

So what I actually did today is:

  • went to the client’s office
  • presented solution
  • got feedback
  • modifed presentation layer (WWW pages) immediately after feedback (at the meeting)

The last point is most important. In two hours working together with client (at client’s office) I did more than I could do alone at home.

Share on Twitter