Jersey-spring3 экземпляр Spring -установленный bean (null!)

Прежде всего хочу отметить, что это по большому счету самая большая проблема с точки зрения времени, которое я когда-либо занимался в своей карьере. (В течение двух дней прямо сейчас с существенным успехом 0). Каждое "работа вокруг" или "решение", которое я попытался, не сработало, поэтому я заблокирован и довольно отчаянно нуждаюсь в некоторой помощи.

Проблема в двух словах заключается в том, что Jersey/HK2, кажется, всегда создает экземпляр Spring -managed beans ПОСЛЕ того, как они были созданы экземпляром Spring, который говорит мне, что jersey-spring3 не выполняет свою работу или, по крайней мере, не с моей текущей настройкой (или с любой из ~ 50 перестановок настроек, которые я пробовал до сих пор.)

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

Конфигурация

Код

Вызов (клиент)

Ошибка (сервер)

Журнал API

Журнал Catalina

Ответы

Ответ 1

У нас есть пользовательский асинхронный ContextLoader, поэтому промежуточное решение потребовало размещения полного взлома в Jersey-Spring3, чтобы дождаться, когда приложение будет инициализировано, прежде чем инициализирует поставщик пользовательских компонентов.

P.S. Для любой бедной души, которая вынуждена делать что-то подобное, убедитесь, что параметры META-INF/содержат конфигурацию SpringComponentProvider.

(2014-04-18) Разработка для @Scott

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

Это сказало... вот что я сделал для решения моей проблемы:

Буквально скопировал исходный код spring -jersey3 в мое приложение/сервер, изменив заголовок каждого файла соответствующими тегами в соответствии с лицензией;
Создал следующий класс -

=== >

  /**
   * Hack class for RN-8979.
   *
   * @author ryan
   *
   */
  public class ContextLoadWaiter {

    private static final Logger logger = Logger.getLogger(ContextLoadWaiter.class);

    public void doWait() {

      try {
        while (ContextLoaderHttpInterceptor.isNotStarted()) {
          logger.info("Waiting for ContextLoader to start...");
          Thread.sleep(1000);
        }
      } catch (InterruptedException e) {
        logger.error("SpringComponentProvider was interrupted!");
      }
    }
  }

Обратите внимание, что это относится к * нашей * кодовой базе, поскольку ContextLoaderHttpInterceptor - это http-сервлет, где isNotStarted возвращает true, если еще не загружен наш пользовательский ContextLoader (который является асинхронным).

Пользовательский асинхронный ContextLoader был когда-то вставлен кем-то по какой-то причине в соответствии с тем, что позволяет пользовательскому интерфейсу отображать страницу загрузки при загрузке сервера. (Вероятно, это не правильный способ добавить этот "пользовательский интерфейс", но код был там, и пользовательский интерфейс зависел от него, поэтому мне пришлось иметь дело с ним...)

Поскольку эта часть не будет применяться непосредственно к вам, главное - отладить SpringComponentProvider (от здесь) и посмотреть на значение ClassPathXmlApplicationContext. Если это null, как и в нашем случае, тогда вам нужно выяснить, почему это null и ждать на любом ContextLoader, который вы используете для загрузки, прежде чем инициализировать этот компонент.

Разместил эту взломанную строку в SpringComponentProvider -

== >

  ...

  private final ContextLoadWaiter waiter = new ContextLoadWaiter();

  ...

  @Override
  public void initialize(ServiceLocator locator) {

    waiter.doWait(); // Wait on our asynchronous context loader.

    this.locator = locator;

    if (LOGGER.isLoggable(Level.FINE)) {
      LOGGER.fine("Context lookup started");
    }

    ...

Создал этот файл: META-INF/services/org.glassfish.jersey.server.spi.ComponentProvider с содержимым, являющимся полным классом пути к SpringComponentProvider, например. com.company.server.nbi.rest.internal.jspring.SpringComponentProvider
Добавлен специальный пакет Jersey-spring3 в качестве пакета для сканирования в приложении; см. ниже...

== >

/**
 * Application configuration.
 *
 * @author ryan
 *
 */
public class MyJerseyApplication extends ResourceConfig {

  private static final class Messages {
    static final String INF_STARTING_APPLICATION = "Starting %s!";
  }

  private static final Logger logger = Logger.getLogger(MyJerseyApplication.class);

  public MyJerseyApplication() {

    packages(
    /* Internal providers */
    "com.company.server.nbi.rest.providers",
    /* Internal filters */
    "com.company.server.nbi.rest.filters",
    /* Spring injection support */
    "com.company.server.nbi.rest.internal.jspring", // HERE!!!
    /* Json providers */
    "com.fasterxml.jackson.jaxrs.json",
    /* Jackson exception mappers */
    "com.fasterxml.jackson.jaxrs.base");

    /* Resources */
    register(ResourceA.class);
    register(ResourceB.class);
    register(ResourceC.class);

    /* Miscellaneous features */
    register(MultiPartFeature.class);
    register(LoggingFilter.class);

    logger.info(format(Messages.INF_STARTING_APPLICATION, this.getClass().getName()));
  }
}

Это "это". Определенно, это не решение, которым можно гордиться, но если вы находитесь в режиме отчаяния, как я, это, вероятно, не помешает ему сделать снимок.

Ответ 2

Какая загрузка сначала? Spring или Джерси? Возможно, ваш Spring контекст не инициализируется, когда SpringComponentProvider вызывает WebApplicationContextUtils.getWebApplicationContext(sc);. Попробуйте использовать Spring ContextLoaderListener, чтобы Spring выполнил свою инициализацию сразу после развертывания приложения.

Я столкнулся с множеством тех же проблем, которые вы испытываете в библиотеке jersey-spring3. У меня возникли проблемы с поиском моего приложения Spring ApplicationContext (похоже, что вы застряли), и он взорвал инъекционные сеттеры, которые в качестве аргумента использовали общий параметр.

Если вы столкнетесь с проблемой контекста приложения, я не думаю, что у вас все равно будет работать. Вы определили ViewResource и LocationResource beans в XML. Из того, что я могу сказать, Джерси получит экземпляр ресурса только из Spring, если класс ресурса аннотируется с @Component. Взгляните на org.glassfish.jersey.server.spring.SpringComponentProvider, в частности component.isAnnotationPresent(Component.class):

// detect JAX-RS classes that are also Spring @Components.
// register these with HK2 ServiceLocator to manage their lifecycle using Spring.
@Override
public boolean bind(Class<?> component, Set<Class<?>> providerContracts) {

    if (ctx == null) {
        return false;
    }

    if(component.isAnnotationPresent(Component.class)) {
        DynamicConfiguration c = Injections.getConfiguration(locator);
        String[] beanNames = ctx.getBeanNamesForType(component);
        if(beanNames == null || beanNames.length != 1) {
            LOGGER.severe(LocalizationMessages.NONE_OR_MULTIPLE_BEANS_AVAILABLE(component));
            return false;
        }
        String beanName = beanNames[0];

        ServiceBindingBuilder bb = Injections.newFactoryBinder(new SpringComponentProvider.SpringManagedBeanFactory(ctx, locator, beanName));
        bb.to(component);
        Injections.addBinding(bb, c);
        c.commit();

        LOGGER.config(LocalizationMessages.BEAN_REGISTERED(beanName));
        return true;
    }
    return false;
}

Не связанная с этим проблема заключалась в том, что мы также хотели перенести все наши аннотации JAX-RS на интерфейсы. Всякий раз, когда я его пробовал, я получил "Не удалось найти подходящий конструктор для com.foo.ResourceInterface".

В конце концов, я решил все свои проблемы, не используя jersey-spring3 и перевернув свой собственный Jersey на разъем Spring. Вот что я сделал:

Конфигурировал все мои ресурсы как обычные Spring beans. Вы можете использовать XML, если хотите.
В моем приложении я добавил привязки к контейнеру HK2 для использования factory всякий раз, когда ему нужен экземпляр одного из ресурсов. Мой класс factory просто возвращает управляемый экземпляр Spring ресурса.
Перед тем, как factory возвращает Spring -установленный bean, я использую службу Jersey/HK2 ServiceLocator для инъекций вещей, которые предоставляет Джерси. Например, все, что было аннотировано с помощью @Context.

My javax.ws.rs.Application выглядит следующим образом:

public class RestConfig extends ResourceConfig {
private static final Log log = LogFactory.getLog(RestConfig.class);


@Inject
public RestConfig(ServiceLocator locator) {
    super();
    // specific to my app. get your spring beans however you like
    Collection<Object> beans = BeanLocator.beansByAnnotation(RestResource.class);

    DynamicConfiguration c = Injections.getConfiguration(locator);


    for (Object bean : beans)
    {
                    // tell jersey to use a factory for any interface that the bean implements.  since your resources don't implement interfaces, 
                    // you'll want to do something a bit different here.
        for (Class<?> currentInterface : bean.getClass().getInterfaces())
        {
            if (log.isTraceEnabled())
                log.trace("binding " + currentInterface.getSimpleName() + " to Spring managed bean");

            ServiceBindingBuilder<Object> bb = Injections.newFactoryBinder(new StaticLookupFactory(locator, bean));
            bb.to(currentInterface);
                    Injections.addBinding(bb, c);
        }
    }

            // commit the changes to the HK2 container (don't skip this step!)
            c.commit();

    property("jersey.config.disableMoxyJson.server", true);
    packages("com.foo.web.rest");

    register(MoxyXmlFeature.class);
}


// a "factory" where the provide() method returns the spring managed bean
    // that was passed to the constructor.
private static class StaticLookupFactory implements Factory<Object> {

    private ServiceLocator locator;
    private Object bean;

    StaticLookupFactory(ServiceLocator locator, Object bean)
    {
        this.locator = locator;
        this.bean = bean;
    }

    @Override
    public Object provide() {
                    // inject this annotated with @Context, @Inject, etc
        locator.inject(bean);
        return bean;
    }

    @Override
    public void dispose(Object instance) {
    }

}
}

BeanLocator - это класс утилиты, который я написал, что позволяет легко захватывать экземпляры bean, используя статические методы, когда автоустановка недоступна. Например, при работе за пределами Spring beans. Не слишком много происходит там:

public static Collection<Object> beansByAnnotation(Class<? extends Annotation> annotation)
{
    return applicationContext.getBeansWithAnnotation(annotation).values();
}

RestResource также относится к нашему приложению. Это настраиваемый стереотип, который работает как @Component, @Service и т.д.:

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Component
public @interface RestResource {
    String value() default "";
}

Обратите внимание, что Джерси позволяет регистрировать пользовательские реализации org.glassfish.jersey.server.spring.ComponentProvider для управления жизненным циклом ресурсов самостоятельно. Я попробовал, но не смог понять, как это реализовать, независимо от того, что я сделал.

Еще одно примечание... вызов locator.inject(bean), который активирует механизм впрыскивания в Джерси, будет обрабатывать все, что помечено с помощью @Inject. Используйте @Autowired в своих классах или настройте beans с XML, чтобы избежать как Spring, так и попытки Джерси разрешить значения для вещей, аннотированных с помощью @Inject.

Ответ 3

Это сообщение, которое является ключевым для понимания проблемы. Это означает, что Spring неправильно инициализируется:

SEVERE: Spring context lookup failed, skipping spring component provider initialization.

(На стороне примечания: поскольку Spring не инициализируется, единственная реализация JSR-330 для попытки и разрешения @Inject - это HK2 - вот почему вы видите другую проблему).

Во всяком случае, проблема в том, что ваш контейнер не выполняет проверку аннотаций, которые делают все магии jersey-spring3.

Это поведение является частью спецификации Servlet 3.0 (JSR-33, раздел 1.6.2), поэтому вам следует дважды проверить, поддерживает ли ваш контейнер этот файл.

В случае Tomcat - если вы не используете Tomcat 7.0.29 или новее, вам действительно нужно убедиться, что версия Servlet указана в вашем web.xml.

http://tomcat.apache.org/tomcat-7.0-doc/changelog.html#Tomcat_7.0.29_ (markt)

Недавно я столкнулся с этой проблемой, и это заставило меня замочить, и исправление web.xml было проще, чем обновление с Ubuntu/Precise!

Надеюсь, это поможет!