2013-05-15 3 views
1

Мы разрабатываем веб-интерфейс с использованием JSF 2 и Weld Cdi на Tomcat.
Теперь у меня есть проблема с выполнением нескольких веб-сервисов параллельно, чтобы оптимизировать время запроса.
Пользователь может выбрать несколько элементов из списка.
Для каждого выбранного элемента процесс собирает информацию из одного веб-сервиса, используя ключ списка в качестве параметра.

В моем текущем подходе используется Producer, который возвращает интерфейс порта webservice, который вводится в bean-компонент. Боб вызывает это webservie в цикле для каждого выбранного ключа.Доступ к параллельным веб-сервисам в среде Weld CDI

@Inject 
private WSAnzeigeAssetsummen serviceAccess; 
: 

for (Integer pfNr : sessionKeys.getPfnrList()) { 
    summaryTable = serviceAccess.execute(snr, pfnr, requestType, "", desiredRows, userName); 
    processResult(summaryTable): 
} 

Чтобы получить быстрее, я пытался использовать ExecutorService и столько рабочих, сколько необходимо, которые возвращаются фьючерсы.

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

Также при тестировании невозможно ввести фиктивный служебный порт, который предоставляет предопределенные результирующие наборы.

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

Каков правильный подход к решению такой ситуации?

Edit: Для того, чтобы быть более ясным, что я пытался ...

public class DataCollector implements ISumRequest<Integer, Integer, String, FutureResult> { 

ExecutorService pool = Executors.newCachedThreadPool(); 
@Inject 
SessionBean sessionBean; 

public Future<FutureResult> collectInformation(Integer snr, Integer pfnr, String requestType) { 

    CollectWorker worker = new CollectWorker (snr,pfnr,requestType,sessionBean.getUserName());  
    return pool.submit(worker);   
} 

}

При выполнении, как это, работник не удалось.

+0

Определенно не хватает кода здесь, чтобы понять, что происходит. Почему рабочий не управляется? –

+0

Хорошо, я добавил код, чтобы объяснить, что я пытался сделать. Надеюсь, это станет более ясным. Я не знаю, как динамически создавать управляемые экземпляры. –

+0

Это то, что я перешел на OWB вместо сварки, потому что я мог использовать действительно гладкий CdiControl для этих проблем. http://struberg.wordpress.com/2012/03/17/controlling-cdi-containers-in-se-and-ee/ https://issues.apache.org/jira/browse/DELTASPIKE- 284 –

ответ

2

Вы можете обернуть созданный работник в КДИ созидательного контексте, что-то вроде этого:

@Inject 
private BeanManager beanManager; 

public <T extends Object> T performInjection(final T obj) { 
    if (this.beanManager != null) { // only do injection if the bean manager is present. 
     // Create a creational context from the BeanManager 
     final CreationalContext creationalContext = this.beanManager.createCreationalContext(null); 
     // Create an injection target with the Type of the instance we need to inject into 
     final InjectionTarget injectionTarget = this.beanManager.createInjectionTarget(this.beanManager.createAnnotatedType(obj.getClass())); 
     // Perform injection into the instance 
     injectionTarget.inject(obj, creationalContext); 
     // Call PostConstruct on instance 
     injectionTarget.postConstruct(obj); 
    } 
    return obj; 
} 
+0

Да, это, наверное, лучшее, что вы могли бы сделать. – LightGuard

+0

Не могли бы вы помочь объяснить контейнер возврата? Означает ли это 'return obj;'? –

+1

Исправлено: в конце была опечатка из локального примера, который у меня был. –

Смежные вопросы