Расширение веб-приложений Java с плагинами
List<String> list = new ArrayList<>();
list.add("One");
list.add("Two");
int counter = 0;
String str = new String("Iamstillquite/{Name0}/newtoJava/programm/ingandIam/{Name1}/tryingtoupdate/anexisting");
for (String s : list) {
str = str.replace("{Name" + counter + "}", s);
counter++;
}
Может оказаться полезным использовать счетчик для облегчения замены. Вот почему вам нужно назвать строки, которые вы хотите заменить, как {Name0}, {Name1}, {Name2} ... хотя это не составляет труда, поскольку вы можете сделать это в цикле, если это необходимо.
7 ответов
Я переделывал идею использовать OSGi для решения той же проблемы, которую Вы описываете. В особенности я смотрю на использование Spring Динамические Модули.
Смотрите на Портлеты Java - http://developers.sun.com/portalserver/reference/techart/jsr168/ - короче говоря спецификация, которая позволяет совместимость между тем, что является в других отношениях автономными j2ee веб-приложениями
Редактирование я забыл упоминать, что Портлеты являются в значительной степени агностиком платформы - таким образом, можно использовать, Кидается за родительским приложением, и отдельные разработчики могут использовать то, что они хотят на их Портлетах.
Вы посмотрели на использование знатока, чтобы выделить Ваши проекты и затем иметь его, разрешают зависимости между ВОЙНАМИ и БАНКАМИ? Вы закончите с дублированием библиотек между ВОЙНАМИ, но только там, где это необходимо (и это не должно быть проблемой, если Вы не входите в некоторую броскую classloader забаву).
Tomcat также позволяет Вам настраивать перекрестные приложения контекста, если необходимо добраться от одной ВОЙНЫ до другого относительно прозрачным способом...
Если Вы хотите сохранить вещи в соответствии с тем же единственным веб-приложением (скажите, что КОРЕНЬ) Вы могли создать веб-приложение прокси, что вперед до соответствующего другого веб-приложения негласно, чтобы пользователь сделал это относительно прозрачным?
Ваша основная проблема собирается центрироваться вокруг физических, статических активов системы - остальные - просто, эффективно, банки.
ВОЙНЫ разделяются, в Tomcat, с отдельным classloaders, но также и они разделяются на сеансовом уровне (каждая ВОЙНА является indvidual веб-приложением и имеет свое собственное состояние сеанса).
В Glassfish, если бы ВОЙНЫ были связаны в EAR, они совместно использовали бы classloaders (GF использует плоское пространство загрузчика класса в УШАХ), но все еще имел бы отдельное состояние сеанса.
Кроме того, я не уверен, можно ли сделать "вперед" к другой ВОЙНЕ в сервере. Проблема там состоит в том, которые вперед используют относительный URL для корня веб-приложения, и каждый WebApp имеет их собственный корень, таким образом, Вы просто "не можете добраться там отсюда". Можно перенаправить, но это не то же самое как вперед.
Таким образом, эти функции веб-приложения сговариваются против Вас пытающийся развернуть их однородно в контейнере.
Скорее я думаю, что горячая подсказка должна создать "ассемблерную" утилиту, которая берет Ваши отдельные модули и "объединяет" их в с единственным веб-приложением. Это может объединить их web.xml, их содержание, нормализовать банки и классы и т.д.
ВОЙНЫ являются функцией и ошибкой в мире Java. Я люблю их, потому что они действительно подают скомпилированные заявки развертывания "Перетаскивание" с точки зрения установки их, и это - функция, используется намного больше, чем, с чем Вы встречаетесь. Но я чувствую Вашу боль. У нас есть общая "базовая" платформа, которую мы совместно используем через приложения, и мы в основном должны непрерывно объединять ее для поддержания ее. Мы написали сценарий его, но это - все еще что-то вроде боли.
"Кроме того, я не уверен, можно ли сделать "вперед" к другой ВОЙНЕ в сервере. Проблема там состоит в том, которые вперед используют относительный URL для корня веб-приложения, и каждый WebApp имеет их собственный корень, таким образом, Вы просто "не можете добраться там отсюда". Можно перенаправить, но это не то же самое как вперед".
Можно передать другой ВОЙНЕ, пока та ВОЙНА позволяет кому-то сделать это.
glassfish и несколько ВОЙН EAR: это имеет смысл.
Если Вы помещаете ОСНОВНЫЕ классы в общий ПУТЬ К КЛАССУ кота, то можно поместить отдельные ПЛАГИНЫ в отдельные ВОЕННЫЕ файлы.
Главное приложение может также быть частью сервлета TOMCAT, который Вы определяете в server.xml. Это может быть ОСНОВНЫМ СЕРВЛЕТОМ, и всеми другими ВОЙНАМИ может управлять этот основной сервлет.
Это имеет смысл?
BR,
~A
В зависимости от сложности сменной функциональности я также рассмотрел бы веб-сервис, например, реализованный с Осью.
Ваше основное приложение затем настроено с URL к веб-приложению (плагин), который предоставляет услугу.
Преимущество, поскольку я вижу его, является двукратным:
- Вы получаете хороший, чистый, debuggable API между этими двумя войнами, а именно, МЫЛО/СООБЩЕНИЯ XML
- Вы можете обновить единственный плагин, не имея необходимость к регрессионному тесту Ваше целое приложение
disadvatages - то, что необходимо настроить некоторые проекты Оси, и что у Вас должна быть своего рода сменная конфигурация. Кроме того, Вы, возможно, должны были бы ограничить доступ к своим сервисным веб-приложениям, таким образом, немного конфигурации могло бы требоваться.
Если работа плагинов над той же базой данных, несомненно, или ограничит время кэша или настроит слой кэширования охвата войны.
Я также пытался разработать общую или абстрактную среду, где я могу добавлять плагины (или модули) во время выполнения и улучшать существующее работающее веб-приложение.
Теперь, как вы сказали, предпочтительный способ сделать это с помощью файла WAR или JAR. Проблема с файлом WAR в том, что вы не можете развернуть его как плагин в существующем приложении. Tomcat развернет его как отдельный веб-контекст. Не желательно
Другой вариант - это файл JAR и написать собственный код для копирования этого файла JAR в папку WEB-INF / lib и загрузки классов в существующий загрузчик классов. Проблема в том, как развернуть не-Java-файлы, такие как JSP или файлы конфигурации. Для этого существует два решения: Используйте шаблоны скорости вместо JSP (b.), Чтобы написать собственный код для чтения JSP из пути к классам вместо контекстного пути.
Модули OSGI или Spring Dynamic хороши, но в настоящее время они кажутся мне слишком сложными. Я еще раз посмотрю на это, если почувствую это.
Я ищу простой API, который может позаботиться о жизненном цикле плагина и все еще в состоянии использовать JSP в моем упакованном файле JAR.
Может быть,