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
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.
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ń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ń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.
OdpowiedzUsuń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.
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...
OdpowiedzUsuń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.
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 ;-)
OdpowiedzUsuń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.
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).
OdpowiedzUsuń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.
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 ;-)
OdpowiedzUsuń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 ;-)
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ńŁ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.
OdpowiedzUsuń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.
W pliku tomcat-users.xml mamy zakomentowany przykład:
OdpowiedzUsuń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".
@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 ... "
OdpowiedzUsuńA co do konkurencji serwerów ... to JBoss używa Tomcata, Glassfish też ;-)
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).
OdpowiedzUsuńŁ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?!
Poprawka do poprzedniego komentarza: s/OpenEJB/TomEE :)
OdpowiedzUsuń