Как определить тип приложения в коде Java - PullRequest
1 голос
/ 21 сентября 2011

Представьте, что у нас есть пакет Java.Этот пакет можно использовать где угодно.Однако в этом пакете есть несколько кодов, которые зависят от контекста.Например, если приложение, которое использует этот пакет, является веб-приложением, нам нужно выполнить некоторые задачи, вызвав функцию при выполнении других задач, если приложение было консольным приложением, вызвав ту же самую функцию.

Вот мой вопрос:

Есть ли способ в java, который в коде мы можем определить, было ли приложение запущено как веб-приложение или консоль?Я ценю любую помощь:)

В качестве примера из реальной жизни способы загрузки файлов свойств различны для веб-приложений и консольных приложений.

Для веб-приложений мы, вероятно, используем this.getClass().getClassLoader().getResourceAsStream(url), а для консольных приложений - new FileInputStream(physical path).

Ответы [ 3 ]

2 голосов
/ 21 сентября 2011

Возможно, было бы лучше установить свойство сборки где-нибудь, а не пытаться определить тип вашего приложения, потому что я не думаю, что есть надежный способ сделать это.

Более того, вам не следует пытатьсяопределить тип приложения, потому что ваш уровень представления (веб, рабочий стол или консоль) должен быть легко взаимозаменяемым в соответствии с современными архитектурными принципами.


В ответ на ваш последний комментарий.

Как сказал пользователь 384706, DI - правильный выбор, IMO.Я приведу пример с пружиной.

В обеих частях вашей консоли и веб-приложения вы можете иметь:

public class WebOrConsoleServiceImpl {

    private PropertyProvider propertyProvider = new NullPropertyProvider();

    // and

    public void setPropertyProvider(PropertyProvider impl) {
        this.propertyProvider = impl;
    }

    // and in your service logic

    public void logic() {

        final Properties props = propertyProvider.loadProperties();
        // do stuff            
    }
}

Где ваш метод loadProperties() будет переопределен для различных реализаций вашего PropertyProvider.

И в вашем весеннем контексте вы можете иметь:

<bean id="consolePropertyProvider" class="com.company.ConsolePropertyProvider"/>

<bean id="myConsoleService" class="com.company.MyConsoleService">
    <property name="propertyProvider" ref="consolePropertyProvider" />
</bean>

И ту же пару определений бинов для ваших WebService и WebPropertyProvider.

1 голос
/ 21 сентября 2011

Просто используйте внедрение зависимости
Просто поместите все соответствующие параметры для настройки вашей библиотеки через сеттеры и позвольте контейнеру или приложению настроить ее соответствующим образом с помощью DI.
Так что вам не понадобятся какие-либо проверки, которые ИМХО плохой подход

0 голосов
/ 21 сентября 2011
  1. Способ J2EE. Если ваш пакет используется в веб-приложении, то, я предполагаю, что вы находитесь в контейнере J2EE, вы можете добавить Reference в именование во время развертывания. Вы также можете зарегистрировать MDB, который может прослушивать изменения этой ссылки и изменять поведение вашего кода во время выполнения. Сладкий, верно?

  2. Другой стандартный способ передачи контекста вызывающей стороны - через параметризованную фабрику или через свойства.

  3. Один нестандартный способ - для развлечения: получить трассировку стека и посмотреть, кто является вызывающим абонентом, или найти контекст j2ee и т. Д.

...