Aplikacja JSF 2.2 / CDI + Spring (business) + JPA2 (najlepiej EclipseLink)

0

Witam,
Jestem generalnie zadowolonym uzytkownikiem stosu JEE 5/6/7 i gdy moge to go wykorzystuje. Mam jednak potrzebe wdrozenia aplikacji w srodowisku Tomcat, ktore nie posiada kontenerow serwera aplikacyjnego, stad moje zainteresowanie Spingiem, ktory ma podobne mozliwosci.

Generalnie:

  1. Aplikacja ma zostac zabezpieczona z uzyciem Spring Security (tu akurat sie ciesze, bo jestem bardzo zadowolony z tego frameworka).
  2. Jako ORM chce uzyc EclipseLink, obslugiwany przez EntityManager, z tego co slyszalem Sping Data daje rade dzieki adnotacji @Transactional i jest prawie rownie fajnie jak w JEE (nie trzeba recznie zarzadzac transakcjami, nawet bez JTA). Jak trzeba bedzie uzyje Hibernate, bylem mial EntityManager.
  3. Do formuarzy i generalnie GUI chce uzyc JSF, bo wiem ze doskonale sie sprawdzi w tego typu aplikacji, w wersji 2.2. Oczywiscie z CDI, a nie legacy JSF Managed Beans.
  4. Do SOAP i REST chce uzyc standardowych frameworkow tzn. JAX-RS i JAX-WS: nie sadze, aby stanowilo to jakies zagadnienie.

Bardzo zalezy mi na nastepujacym efekcie:

  1. Jest sobie repozytorim Spring Data / JPA, dostepne za pomoca interfejsu IMojaEncjaDao.
  2. Chce je wstrzyknac jak CDI / EJB korzystajac ze standardowej adnotacji @Inject. Wiem, ze Spring wspiera taka adnotacje. Mam jednak watpliwosc czy bedzie wspolpracowac z CDI (punktem wstrzykniecia ma byc JSF).
  3. Nie chce, aby CDI Managed Beans byly rejestrowane w springu (chyba, ze nie powinienem sie tym przejmowac?). Po prostu chce zrobic @Inject na springowym repozytorium. Czy jest to w miare proste, czy lepiej sobie odposcic ten pomysl?
  4. Mam swiadomosc, ze musze zainstalowac kontener CDI na Tomcacie (np. Welda) na potrzeby JSF. Raczej uzycie TomEE nie wchodzi w gre. Czy stanowi to powazne zagadnienie?

Pytanie: czy jest jakis gotowy bootstrap czy cos w stylu rapid Spring aplikacja z JSF z obsluga JSF 2.2? Co polecacie?

Pozdrawiam,

0

Nie do końca rozumiem twoje pytanie. Bo musisz przeciez mieć jakiegoś dostawcę CDI. Może nim być Spring, ale wtedy oczywiście wszystkie zarządzane obiekty będą zarządzane przez Springa. Bo nie da sie wstrzykiwać do obiektów którymi sie nie zarządza ani obiektów którymi się nie zarządza. Więc jak Spring to Spring i tyle ;]

  1. Oznaczasz sobie DAO jako @Repository i wstrzykujesz gdzie chcesz
  2. jw. @Inject zadziała jeśli użyjesz go z obiektu zarządzanego przez Springa i do obiektu zarządzanego przez Springa. Ale Spring integruje się z JSFem.
  3. Nie rozumiem czemu nie chcesz.
  4. Ok, teraz rozumiem :) Tylko nie rozumiem czemu. Skoro masz juz Spring DI to co ci drugi kontener CDI?

Czemu, skoro tak bardzo nie chcesz springa, nie zainstalujesz na tym tomcacie wszystkiego co potrzebne? Przecież zarówno JPA jak i CDI możesz tam postawić po prostu ładując odpowiednie biblioteki...

0
  1. Chce, aby bylo jak najprosciej: skoro moge miec jeden kontener (np. Spring) nie tracac na mozliwosciach, zalozmy ze chce uzyc Springa. Zalezy mi jednak na dwoch rzeczach: @ViewScoped i @Inject.

  2. Czy Spring poradzi sobie z oznaczeniem beana JSF, ktory przechowuje stan w ramach widoku (w celu obslugi formularzy i pamietania stanu)? Czy jest to adnotacja @named czy springowy odpowiednik? Czy jesli jest to springowy odpowiednik czy ma odpowiedni scope, zgodny ze scopem CDI? Bo nie ufam custom scope.

  3. CDI w JSF 2.2 gwarantuje mi, ze mam taka adnotacje. Czy to dziala rowniez w Springu, na tyle dobrze, ze moge myslec o produkcyjnym uzyciu?

@Named
@ViewScoped
class MojaKlasa implements Serializable {
      @Inject
      private IMojeSpringoweRepository spingDao;

      // implementajcja beana
}
  1. Jak juz wspomnialem wiem, ze moge uzyc legacy beana JSF (ale nie chce). Widziałem tylko takie przykłady w sieci ze Springiem.
0

Korzystałem z tego miksu jakiś czas temu, więc nie mogę odpowiedzieć na 100%. Moja rada: sprawdź ;) Napisz na szybko stuba aplikacji i przetestuj czy spring to łyknie.
Z rzeczy które na 100% wiem: @Named jest obsługiwane, tak samo jak @Inject.

0

@Inject to akurat standard wprowadzony w JSR-330,więc tak Spring to wspiera, tak samo jak np: Guice. Twoje przechowywanie stanu w ramach widoku to może być na przykład @SessionAttributes i po prostu zwracanie odpowiednich danych do modelu (w springowej dokumentacji to chyba nawet jest wspomniane jako odpowiednik backing beanów)

@SessionAttributes - "blebleble... serving as form-backing beans between subsequent requests "

P.S nie wiem czy dobrze mi się wydaje, ale na siłę chcesz przenieść wszystkie praktyki z jee(tutaj jsf) do springowej codzienności ?

0

Potwierdzilem, ze moge recznie dodawac atrybuty do sesji, ale dla duzych formularzy to juz za duzo zabawy: takie rzeczy co najwyzej dla przechodzenia miedzy widokami stosuje jak chce np. warunkowo cos usunac z sesji: dodac (cos jak prymitywny flash scope w jsf 1.2). A SessionScope robi problemy zwiazane np. z otwarciem w dwoch zakladkach, zarzadzaniem race conditions, a @ViewScoped pieknie to rozwiazuje.

Czytam, ze ludzie generalnie walcza:
http://blog.primefaces.org/?p=702
http://acraviolatti.blogspot.com/2013/03/jsf2-view-scope-with-spring-core.html

Ale jakos nie ufam w 100% tym rozwiazaniom, moze dlatego ze w 100% nie rozumiem jak dziala @ViewScoped i nie moge zweryfikowac ich poprawnosci czy np. nie bedzie leakow.

Chyba bede sklonny isc w strone rozwiazania:

  • doinstalowuje Welda na potrzeby GUI JSF
  • kombinuje, aby do Welda udawalo sie wstrzykiwac biznes springowy

Jak znajde czas sprobuje zbudowac prototyp z uzyciem czegos takiego:
https://cwiki.apache.org/confluence/display/DeltaSpike/Spring+CDI+integration

0

Ale... jak ręcznie ? musisz mieć przecież jakiś form-object, data-transfer-object,encje, jak to nazywacie i na czymś pracujecie. Ale coś musisz mieć.

0

P.S nie wiem czy dobrze mi się wydaje, ale na siłę chcesz przenieść wszystkie praktyki z jee(tutaj jsf) do springowej codzienności ?

Czy na siłę uważam, ze jest to mocno dyskusyjne. W końcu Spring bardzo mocno bazuje na JEE o czym świadczy np. standaryzacja adnotacji wstrzykiwanie i generalnie bazowanie na servletach.

  1. Technologie Spring i JEE wydaja mi sie na 1 rzut oka b. podobne.
  2. Uzycie JPA uwazam zupelnie ok jak uzycie Hibernate przez Session zamiast EntityManager i nie widze w tym nic zlego, skoro to znam to czemu nie?
  3. JAX-RS czyli np. Jersey to jeden z wielu mozliwych frameworkowv jakie moge uzyc do REST. Nie widze w tym niz zlego, w koncu sam Spring jest ciezki i tak nie mam go zainstalowanego na serwerze aplikacyjnym. Wiem, ze sa inne drogi np. Spring MVC i @RestController, ale zadna nie jest jedyna sluszna, zwlaszcza ze kazda opcja oznacza instalacja kolejnych .jar (Spring to nie full serwer aplikacyjny).
  4. Co do JSF to sie zgadzam: chce przeniesc praktki z JEE, poniewaz odczulem ogromny przyrost produktywnosci po przerzuceniu sie z legacy beans na CDI. Przede wszystkim nie musze uzywac znienawidzonych setterow do wstrzykiiwania JSF managed beans za pomoca EL, ktore tylko zasmiecaly moj kod.
  5. JAX-WS w Springu tez raczej nie wydaje mi sie niczym zlym.

@vpiotr:
dzieki za linki

0

Netbeans coś tam marudzi że powinno się od któregoś JSF używać CDI więc to dobra droga, z tym że pewnie diabeł tkwi w szczegółach.
Sam mam podobny dylemat, więc jak znajdziesz jakieś ciekawe rozwiązanie (najlepiej bez Spring) to daj znać.

0

to trochę jakby napisać że spring bazuje na php bo jest w przeglądarce :D

W sumie to prawda jest jeszcze troche inna: JEE standaryzuje istniajace rozwiazania (pochodzace z tego co dziala i community uwaza, ze jest na tyle dobre / dojrzale, ze moze trafic do standardu). A rozszerzania niestandardowe i tak mozna do woli konfigurowac, wiec mozliwosci sa oczywiscie duze.

1 użytkowników online, w tym zalogowanych: 0, gości: 1