2015-10-18 51 views
6

Mamy starszą aplikację, która używa Struts 1.2.9. Aplikacja jest obecnie internacjonalizowana w standardowy sposób - .properties plików dla wszystkich etykiet interfejsu użytkownika, błędów, wiadomości itp .; <message-resouces> definicja dla każdego pliku .properties w struts-config.xml przy użyciu domyślnych definicji Factory & MessageResources; <bean:message> użycie we wszystkich JSP. Udało się to znakomicie do tej pory, ale fakt, że sama aplikacja stanowi szkielet usług używanych przez kilkaset (tak 100's!) Innych aplikacji wewnętrznie.Struts 1.2.9 - Pytania dotyczące niestandardowej internacjonalizacji

Mamy wymóg rozszerzenia funkcjonalności i18n następująco:

  1. Definiowanie katalogu niestandardowej .properties plików - tak to będzie poza zakresem ścieżce klasy; zasadniczo nie wewnątrz pakietu .war. Chodzi o to, aby wspierać tylko zmiany ciągu wiadomości bez konieczności ponownego wdrażania całej aplikacji.
  2. Ten niestandardowy katalog będzie również zawierał komunikaty dla obsługiwanych aplikacji - może to być tylko podzbiór istniejących lub cały zestaw zasobów specjalnie dostosowanych do tej aplikacji.
  3. Niestandardowy sposób wspierania za życzenie Locale ustawienie - wyjąwszy wszystkie inne względy (wyszukiwań domyślny stos, ścieżka klasy/opakowania, etc.) jest analogiczny do sposobu I18nInterceptor prace w Struts2 z atrybutem requestOnlyParameterName ustawiony true.

Tak, rozumiem, że kilka 100 pakietów załadowanych w tym samym czasie będzie intensywnie wykorzystywać pamięć, ale jest to dopuszczalne w naszym przypadku.

Każda pomoc jest mile widziana - może to być kierunek, przykładowy kod, itp

Uwaga: Całkowicie zgadzam się, że przejście na nowszą platformę UI jest chyba najlepszym rozwiązaniem. Ale nie możemy.

TIA.

+0

Wygląda na to, że można zaimplementować własne usługi MessageResources i MessageResourcesFactory. Myśli? – Ranga

Odpowiedz

0

Miałem podobny wymóg w projekcie wiosennym, nie tylko dla i18n, także punktów końcowych usług internetowych i innego rodzaju właściwości.

Osiągamy to wymaganie, dodając katalog, w którym umieszczamy pliki właściwości, do ścieżki klasy w pliku konfiguracyjnym uruchamiania serwera.

Testowane i działające w weblogic 11g (przygotowanie i produkcja) i na serwerze tomcat (środowisko programistyczne).

Nadzieja pomaga

+0

Dzięki za sugestię Francisco. Jeśli dobrze pamiętam, definiując , definiujesz nazwę pakietu, z którego wybierzesz pliki właściwości. Gdybym miał katalog główny z wieloma podkatalogami, z których każdy potencjalnie zawierał wiele pakietów, nie sądzę, aby to ustawienie klasy Classpath działało. Będziesz potrzebował mechanizmu, za pomocą którego dla każdego żądania, ustawienia narodowe, a następnie odpowiedni pakiet właściwości powinny zostać wybrane z odpowiedniego katalogu dla tej aplikacji pod katalogiem głównym. – Ranga