|
Prawdziwa Blondynka - 9 Sie 2004, 13:10 Witam, nie jest dla mnie jasne czy istnieje mozliwosc postawienia drzewa DOM z poziomu EJB. Tzn. czy np. jakis session bean jest w stanie sparsowac plik XML? Pozdrawiam, Artur Wronski - 9 Sie 2004, 13:31 Witam! nie jest dla mnie jasne czy istnieje mozliwosc postawienia drzewa DOM z poziomu EJB. Tzn. czy np. jakis session bean jest w stanie sparsowac plik XML? tak moze, nie wolno mu tylko tego drzewa odczytac z pliku. Pozdrawiam, Marcin Cenkier - 9 Sie 2004, 13:35 | Tzn. czy np. jakis session bean jest w stanie sparsowac plik XML? tak moze, nie wolno mu tylko tego drzewa odczytac z pliku. Czy w tej odpowiedzi nie ma takiej małej sprzeczności? Może chodziło o to, że bean nie powinien czytać z dysku? Artur Wronski - 9 Sie 2004, 14:15 Witam! Czy w tej odpowiedzi nie ma takiej małej sprzeczności? Może chodziło o to, że bean nie powinien czytać z dysku? nie ma sprzecznosci. Nie wolno uzywac nam java.io.* co nie znaczy ze nie mozemy pobrac danych do parsowania z bazy danych albo przez sokety, albo na inny z wielu mozliwych sposobow. Pozdrawiam, Artur Biesiadowski - 9 Sie 2004, 16:04 nie ma sprzecznosci. Nie wolno uzywac nam java.io.* co nie znaczy ze nie mozemy pobrac danych do parsowania z bazy danych albo przez sokety, albo na inny z wielu mozliwych sposobow. Ja tu pewnie wyskocze z niewiedza, ale mozesz wskazac jakis link to miejsca gdzie to jest zabronione ? Mi sie to wydaje bardzo dziwne. Implementacja JDBC moze przeciez rownie Artur Artur Biesiadowski - 9 Sie 2004, 16:29 Ja tu pewnie wyskocze z niewiedza, ale mozesz wskazac jakis link to miejsca gdzie to jest zabronione ? Sam sobie odpowiadam: http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html Dosyc niemadre ograniczenie - powody jakie podaja sa w wiekszosci Tak czy inaczej, wyglada na to, ze rzeczywisci w 'standardzie' nie wolno Artur Andrzej Dmoch - 10 Sie 2004, 03:10 Muchas gracias senores, No a ja wlasnie chce plik XML sparsowac z poziomu EJB. To znaczy ze musze sie z tym plikiem przez sockety polaczyc? Czy jak jeszcze inaczej mozna? Ograniczenie jest czysto akademickie. Jesli chcesz miec klastrowana aplikacje, to jedynym wymaganiem jest wspoldzielony system plikow. Poza tym powodem dla ktorego korzystanie z java.io.* nie jest zalecane jest brak transakcyjnosci systemu plikow (ale Twoja operacja to tylko czytanie). Jest jeszcze jeden sposob czytania plikow - a mianowicie jako Resource. Pozdrawiam, AnD Wojciech Jakóbczyk - 10 Sie 2004, 04:06 Tak czy inaczej, wyglada na to, ze rzeczywisci w 'standardzie' nie wolno tego robic. Jezeli ten xml jest statyczny to uzyj getResourceAsStream. Jezeli dynamiczny, to zamiast na dysk, pakuj do bazy. mozna tez olac przenosnosc i odczytac plik zgodnie z zaleceniem producenta danego serwera aplikacji. wojtek mike - 10 Sie 2004, 17:11 mozna tez olac przenosnosc i odczytac plik zgodnie z zaleceniem producenta danego serwera aplikacji. dokladnie, albo ladnie opakowac dostep do pliku, jesli kiedys aplikacja bedzie dzialac w srodowisku, w ktorym bezposredni dostep do FS jest nie wskazany latwo bedzie to zmienic/dostosowac... jest mnostwo mozliwosci... pozdr Prawdziwa Blondynka - 10 Sie 2004, 18:44 Ograniczenie jest czysto akademickie. Jesli chcesz miec klastrowana aplikacje, to jedynym wymaganiem jest wspoldzielony system plikow. Poza tym powodem dla ktorego korzystanie z java.io.* nie jest zalecane jest brak transakcyjnosci systemu plikow (ale Twoja operacja to tylko czytanie). Jest jeszcze jeden sposob czytania plikow - a mianowicie jako Resource. Aaaa jesli chce nie tylko czytac z pliku XML, ale rowniez eksportowac drzewo DOM do pliku xml? Pozdrawiam, Sun 1 Studio + Sun 1 AS + EJB + debugger EJB - locki i wywolania 'callback' Artykuł nt. Tomcata i EJB oraz Wa rszawska Grupa Miłośników Javy (WGMJ) Dostęp do wielu baz danych przez JPA w ramach EJB 3.0 |