09 października 2011

Apache TomEE w NetBeans IDE 7.1 - 2:1 dla błędów

Nie trzeba wielkiego umysłu, żeby wiedzieć, że w życiu kilkudniowego dziecka wszystko, co robi, określane jest jako pierwsze. Pierwszy raz pojawił się grymas na twarzy, który przypominał uśmiech, pierwsza noc w domu (i nadzieja, że będzie ją przesypiał spokojnie z 3 przerwami na jedzenie - nota bene, mimo, że dzieciak mógłby spać całą noc, to i tak po 3h będzie wybudzany na jedzenie!), pierwsza kąpiel w domu, pierwsze coś jeszcze innego i tak lista rośnie. Jak na razie Maksym dostarcza nam całą masę wrażeń. Jest ich tyle, że przy nadchodzącej zimie żadne mrozy nie są nam straszne. Maksym śpi regularnie, je i nie wpływa specjalnie na domowników swoją obecnością, a mimo to wszyscy chodzą jak nakręceni, szczególnie podekscytowani. Cudo dzieciaczek.

W sobotę, a chyba już i w piątek, postanowiłem popróbować się z Apache TomEE i NetBeans IDE 7.1. Oba produkty wciąż w fazie aktywnego rozwoju, więc można spodziewać się kilku, może nawet kilkunastu czknięć. Tych zawirowań jest o tyle mniej w przypadku Apache TomEE, na ile pozwala certyfikacja Java EE 6 Web Profile. Dla zwrócenia uwagi napiszę, że pod względem zgodności z Java EE 6 nie ustępuje miejsca JBoss AS 7.0.1 (!), a to uważam za niemałe osiągnięcie.

NetBeans IDE wspiera Apache Tomcat jako środowisko uruchomieniowe dla Java EE 6, a więc i Apache TomEE - w końcu to wzbogacony Apache Tomcat. Przy odrobinie szczęścia można pozwolić sobie na zestawienie środowiska programistycznego z oboma produktami. I tak faktycznie jest.

Wystarczy postępować zgodnie z wytycznymi asystenta do konfiguracji Apache Tomcat z tą różnicą, że katalogi wskazują na Apache TomEE i wszystko gra! Szkoda tylko, że nie można zmienić nazwy serwera na wybraną przez użytkownika, np. Apache TomEE lub podobnie.

Nie wiem, co mnie podkusiło, ale postanowiłem spróbować się ze zmiennymi środowiskowymi (ang. environment entries) i ich dostępem z servletu. To chyba było z powodu tego zdania na stronie TomEE:

"Any Tomcat provided resources, say from a context.xml, can be looked up or injected."

Tak, na pewno to było to. Stworzenie servletu w NetBeans to chwila. W międzyczasie pytanie o rejestrację servletu w web.xml, na które odpowiedziałem stanowczym nie, tj. zatwierdziłem domyślne ustawienie "Add information to deployment descriptor (web.xml)". Od wersji Servlet 3.0 deskryptor web.xml jest opcjonalny, więc po co mi to?!


I tu się zaczęło.

Najpierw trafiłem na brak wsparcia przez TomEE dla aplikacji webowych bez deskryptora web.xml. Zgłosiłem błąd TOMEE-27 UnknownModuleTypeException thrown when no-web.xml webapp deployed. Nie dawało mi to jednak spokoju i w trakcie sobotniego przesiadywania przed kompem, poprawiłem go. Taa, sam jestem pod niemałym wrażeniem, że zebrałem się w sobie i zrobiłem to.

Z poprawką uruchomienie servletu z adnotacją @WebServlet i bez deskryptora web.xml stało się możliwe. Ciekawe, jak mogło się stać, że nie wyłapał tego zestaw certyfikacyjny Java EE 6 Web Profile TCK?!

Na tym jednak nie koniec, bo głównym celem było dostanie się do zmiennej z context.xml (plik konfiguracyjny Tomcata, a tym samym i TomEE). Tutaj niestety nie mam dobrych wieści, bo wciąż nie ma wsparcia dla niej i pracuję nad TOMEE-28 Support for global environment entries (defined as in server.xml). Tym samym wynik niekorzystny dla poprawek na rzecz 2 błędów. Na dzisiaj 2:1 w starciu błędy kontra poprawki.

Całkiem przy okazji, natrafiłem na możliwość edycji server.xml z poziomu NetBeans - menu kontekstowe Edit server.xml dla serwera.


Jak dla mnie całkiem użyteczna rzecz i przydała się już kilkakrotnie.

13 komentarzy:

  1. No nie wiem, czy test na obecność context.xml jest sensowny, jest to plik specyficzny dla Tomcata, więc nie każde archiwum WAR będzie go zawierać.

    OdpowiedzUsuń
  2. Słuszna uwaga z tym, że to jest dodatkowe sprawdzenie, które wskaże aplikację webową po istnieniu context.xml. Plik tworzony jest przez NetBeans IDE 7.1 podczas zakładania projektu i w ten sposób umożliwiam jego użytkownikom korzystanie z TomEE jak z Tomcata (bez dodatkowych ceregieli).

    OdpowiedzUsuń
  3. Patrząc tak na projekt to rozwiązałeś tylko swój specyficzny problem, co niestety nie jest dobrym podejściem w przypadku aplikacji służących ogółowi.

    Kod, który został dodany po twoim commicie jest już bardziej uniwerslany choć dalej nie rozumiem, czemu nie jest wykonywany pełny skan klas w celu wykrycia adnotacji @WebServlet czy podobnych. Może i jest to wolniejsze podejście ale w 100% pewne.

    OdpowiedzUsuń
  4. Nie uwierzysz, że podobną dyskusję prowadziłem na dev@openejb i podnoszono dokładnie te same argumenty, które rozumiem i w pełni akceptuję, ale...

    1/ NetBeans tak ma, że kiedy tworzony jest projekt dla Tomcata, tworzony jest plik context.xml i opcjonalnie web.xml. Ja wykluczyłem generowanie web.xml, więc aby oszczędzić trudu nowicjuszom, którym zwykle nie chce się zaglądać do dokumentacji, obniżyłem próg wejścia. W ten sposób, stworzenie i uruchomienie projektu bez web.xml w NetBeans z TomEE jest bezproblemowe. Całkowicie.

    2/ Projekt webowy nie musi zawierać klas. Nie musi zawierać WEB-INF. Może składać się wyłącznie z jsp, które mogą mieć inne mapowanie rozszerzeń na servlet, który je obsługuje. Sprawdzenie tego na poziomie konfiguracji serwera przerosło moje możliwości, a zysk byłby identyczny. Wybrałem krótszą drogę, licząc po cichu, że nie przyczyniłem się do zwiększenia długu programistycznego :)

    Co mnie w tej poprawce najbardziej zaniepokoiło, to fakt, że zmiana jest w module openejb-core, a nie openejb-tomee. Tutaj złamane są wszelkie zasady oddzielania odpowiedzialności. To jest największa bolączka i nad tym chciałbym w przyszłości usiąść, aby zmiany dotyczące TomEE nie miały wpływu na samego openejb.

    OdpowiedzUsuń
  5. Ad 1. I potem tak wyszkoleni specjaliści dziwią się, że nie działa na WebSpherze, WebLogicu, JBossie, etc. Bo przecież na TomEE z NetBeans działało ;-)

    Ad 2. Dodawanie wsparcia dla każdej opcji tylko zwiększa elastyczność rozwiązania, nie trzeba wspierać wszystkiego od razu, ale wyznaczyć kierunek ;-)
    Zysk był tylko dla ciebie, co niestety wypacza spojrzenie na problem.

    OdpowiedzUsuń
  6. Jak to "nie działa na..."?! To są jedynie zmiany dla Tomcata, bo bez niego nie ma TomEE. Po co nam wsparcie tych "olbrzymów"?! Nie przyjmuję tego argumentu (pewnie dlatego, że go nie rozumiem i tak wygodniej).

    Wsparcie dla pozostałych opcji w toku, aczkolwiek nie jestem nimi tak zainteresowany, jak przetarciem ścieżki dla wszystkich możliwych uproszczeń z punktu widzenia użytkownika. Świadomie idę na kompromis, w którym ważniejsze są dla mnie odczucia użytkownika, a nie utrzymującego kod. Too bad, too bad, Jacek.

    OdpowiedzUsuń
  7. Uogólniłem swoją wypowiedź, chodziło mi to, że wpajasz w użytkownika złe nawyki, a mianowicie idąc mu na rękę robisz mu krzywdę. Bo jak ktoś zdeplojuje WARa na TomEE, którego stworzył w NetBeansie dla Tomcata to wszystko zadziała (bo będzie plik context.xml, o którym nie wie, bo NetBeans tworzy go za niego). A jak teraz zrobi WARa w IntelliJ IDEA (i tam nie będzie ani context.xml ani web.xml) to jak zdeplojuje na TomEE to nic się nie zadziała. I nie będzie rozumiał, czemu tu działa a tu nie ;-)

    A co gorsze, nie będzie działać (bardzo możliwe) między TomEE a Tomcatem, bo jak sam zauważyłeś, zmiana dotyczyła openejb-core a nie Tomcata, więc powstało coś niekompatybilnego, choć w teorii wywodzące się z tego samego ;-)

    OdpowiedzUsuń
  8. Pół dnia się męczyłem z tym serwerem, żeby odpalić serwlet bez web.xml powtarzając sobie: "przecież dopiero co dostali certyfikat na webprofile, to na pewno ja coś przeoczyłem...". Potem szarpanina z uruchomieniem cdi, do tego format tomcat-users.xml się zmienił ale przykłady sa "po staremu" i po idkomentowaniu nie działają. Szkoda na razie nerwów:/

    OdpowiedzUsuń
  9. Łukasz, teraz pełna zgoda i bez komentarzy uzupełniających z mojej strony. Masz rację, ale co robić, żeby zrobić dobrze użytkownikowi? Edukacja - właśnie się dzieje, ale to potrwa, a konkurencja duża w obszarze serwerów.

    Krzysiek, wielkie, wielkie dzięki za tematy na kolejne wpisy. Zajmę się nimi i zaprezentuję rozwiązania podczas warsjawy. Zapraszam!

    Apropos, jak też zmienił się tomcat-users.xml?! To jest plik bez jakichkolwiek zmian ze strony TomEE. Nie rozumiem.

    OdpowiedzUsuń
  10. W pliku tomcat-users.xml mamy zakomentowany przykład:

    user username="tomcat" password="tomcat" roles="tomcat"

    tymczasem według dokumentacji powinno być

    user name="...."

    Chodzi mi o różnicę między "name" a "username".

    OdpowiedzUsuń
  11. @Jacek edukować, czyli wpisy jak twoje, a nie robienie dróg na skróty (vide twoja poprawka), czyli "... na razie nie działa, ale błąd zgłoszony i pracujemy nad tym ... "

    A co do konkurencji serwerów ... to JBoss używa Tomcata, Glassfish też ;-)

    OdpowiedzUsuń
  12. Krzysiek, uwaga do ludków od Tomcata, bo OpenEJB nie grzebie w nim w ogóle. Korzysta wyłącznie z niego i to (niepotwierdzone) przez API nie bezpośrednio na poziomie pliku (który może mieć inną nazwę i położenie).

    Łukasz, edukacja i skróty idą w parze, ale jak właśnie doświadczam, nie wszystkim pasują obie rzeczy na raz i w tym wcieleniu nie uda mi się tego poprawić :P

    Odnośnie korzystania z Tomcata, to jest różnica zanurzać w sobie Tomcata - vide JBoss, GlassFish, Geronimo, itp., a być zanurzonym w Tomcacie - vide Apache TomEE. To jest diametralna różnica. Ludzi znających Tomcata są całe rzesze, podczas gdy znajomość bogatszych serwerów już niekoniecznie. Stąd moje większe zainteresowanie promocją tego rozwiązania (pomijając inne kwestie, jak np. mój udział w projekcie). Może właśnie na to ludzie czekali?!

    OdpowiedzUsuń
  13. Poprawka do poprzedniego komentarza: s/OpenEJB/TomEE :)

    OdpowiedzUsuń