во избежании повторного наступления на грабли, разработчик, помни! при написании чего-либо типа:
RequestBuilder builder = new RequestBuilder(RequestBuilder.GET, URL.encode("http://google.com"));
try {
Request request = builder.sendRequest(null, new RequestCallback() {
public void onError(Request request, Throwable exception) {
// Couldn't connect to server (could be timeout, SOP violation, etc.)
}
public void onResponseReceived(Request request, Response response) {
if (200 == response.getStatusCode()) {
// обрабатываем response.getText()
} else {
//Handle the error. Can get the status text from response.getStatusText()
}
}
});
} catch (RequestException e) {
// Couldn't connect to server
}
ты всегда будешь ловить RequestException, а все потому, что доменное имя машины на которой выполняется приложение GWT не равно google.com и, следовательно, не совпадает с доменным именем машины к которой ты посылаешь GET запрос. кстати, ты совершенно прав если предположил, что порт и сервер приложений должны быть одними и теми же.
все это логично, в какой-то степени, и наверняка такие своего рода грабли лежат тут не спроста, но, блин, как же это усложняет разработку когда, например, GWT приложение крутится на development сервере поднятом еклипсом на 8888 порту, а xml мы хотим спросить с другого development сервера поднятого на 8000 порту, например джанго-фреймворком.
как бы отключить данную фичу =/.
Как я была невестой
10 лет назад

4 комментария:
Я бы во избежание таких проблем и для пущей чистоты тестирования поднимал виртуальную машину (в OpenVZ) с любыми хостнеймами ;), может и тебе что-нить такое попробовать?
З.Ы.: это Java? Вообще неочевидный код :/
Тут подумалось, что за все время работы программистом под железо ни разу не написал конструкции try/catch... Надо бы окстись и начать кодить, как белый человек...
это джава, да.
неочевидно тут только из-за класса
new RequestCallback() { ... }
который описывается прямо в теле оператора вызова функции, это копипаст с офф. руководства по построению http реквестов, вот только там про безопасность ни слова =(
я такие конструкции избегаю, почти всегда удобней вынести в отдельный класс и перегрузить явно два метода.
тут вопрос в нужности данного, по сути класс понадобится только единожды, ибо для каждого реквеста необходим свой уникальный хендлер ответа, но покрайней мере когда класс обособлен выглядит это по человечески.
а по поводу виртуалки.. тут такая штука, у фреймворочных девелопмент серверов есть свои фичи для дебага, а в случае с гвт, для того чтобы заценить результат ничего даже перекомпилировать ненужно, просто обновляешь страничку.
хост нейм в /etc/hosts прописан,не только в нем беда: порт должен быть одинаковым. апач можно и на локальном хосте поднять вот только каждый раз собирать приложение воедино сливая серверную и клиентскую часть(которую ещё компилить) ради 5-7 тестов.. как-то время жалко. хотя если оптимизировать попробовать например с помощью того же гита, то получиться примерно секунд на 15 дольше транзакия чем в случае с кучей девелопмент серверов.
Я это победил опцией -noserver
GWT запускает приложение в апаче, в апаче же и виртуальные папки сделал для серверной части. В итоге имя и порт сервера одинаковые.
Отправить комментарий