나는 당신이 (재생 2.0.2) F.Promise.map
싶은 생각 :
/**
* Maps this promise to a promise of type <code>B</code>. The function <code>function</code> is applied as
* soon as the promise is redeemed.
*
* Exceptions thrown by <code>function</code> will be wrapped in {@link java.lang.RuntimeException}, unless
* they are <code>RuntimeException</code>'s themselves.
*
* @param function The function to map <code>A</code> to <code>B</code>.
* @return A wrapped promise that maps the type from <code>A</code> to <code>B</code>.
*/
public <B> Promise<B> map(final Function<A, B> function) {
return new Promise<B>(
promise.map(new scala.runtime.AbstractFunction1<A,B>() {
public B apply(A a) {
try {
return function.apply(a);
} catch (RuntimeException e) {
throw e;
} catch(Throwable t) {
throw new RuntimeException(t);
}
}
})
);
}
그것은 당신이 이전 버전의 재생을 사용하고있는 사용자 코드에서 보이는,하지만 당신은 여전히 callWhenReady
을 대체 할 수 있어야한다고 생각합니다 map
(그리고 Integer
유형 매개 변수를 콜백 함수에 추가).
다른 계산으로 WS 약속을 작성하고 새로운 미래로 구성을 반환하고 싶습니다. https://github.com/ripper234/BTCtoX/blob/d8af7fa07bfe7a0a33ce7e3899fde7ba4193ec2c/app/controllers/Application.java - 'tobtc()'는 두 개의 웹 API를 호출합니다. 단점은 각 API가 완전히 비동기 적이 지 않으며 WS HTTP 호출을 기다리는 동안 하나의 작업자 스레드를 낭비한다는 것입니다. – ripper234
WS HTTP 호출을 수신 대기해야하며 java에서는 차단 작업을 수행합니다. 나는 놀이가 이것을 해결하는 다른 메커니즘을 가지고 있다고 생각하지 않는다. 다른 것은 별도의 스레드에서 그것을 수행하는 것이다. 내가 본 것처럼, 이것은 동시에 심각한 일자리를 시작하는 경우에만 문제가 될 수 있습니다. – aaberg
Play에는 WS.url (url) .getAsync가 있으며,이 코드를 사용하여 코드를 실행하고 싶습니다. Play는 이미 설계자가 작업 스레드를 저장하기 위해이 작업을 수행합니다. – ripper234