2015-11-04 6 views
2

Я очень новичок в Spray, поэтому я предполагаю, что это только я не правильно понимаю, как работает каркас. Тем не менее, я сталкиваюсь с тем, что кажется странным поведением при попытке обработать. Эта проблема относится конкретно к this documentation on directives, но может применяться и к другим настраиваемым директивам.Директива по распылению не работает должным образом?

Когда я пытаюсь использовать директиву authorize, с которой поставляется Spray, ответ HTTP отображается правильно в соответствии с возвращаемым значением. То есть, я получаю запрет 403, когда возвращаемое значение authorize равно false, и я получаю 200 OK, если вместо этого true. Тем не менее, кажется, что функция, переданная ей, все еще выполняется, хотя кажется, что она не должна.

Пожалуйста, см. this SBT project, который я создал для проверки этого. Это точно демонстрирует мою проблему, поэтому, надеюсь, это полезно для решения моей проблемы. Запуск с:

sbt test 

выходом вы должны увидеть по умолчанию должен быть очень похож на следующее:

[info] Test: 
[info] route 
[info] - should succeed and have side effects 
[info] - should fail and not have side effects *** FAILED *** 
[info] 1 did not equal 0 (Test.scala:28) 
[info] Run completed in 779 milliseconds. 
[info] Total number of tests run: 2 
[info] Suites: completed 1, aborted 0 
[info] Tests: succeeded 1, failed 1, canceled 0, ignored 0, pending 0 
[info] *** 1 TEST FAILED *** 

Опять же, мое беспокойство заключается в следующем: почему тело функции передается в Directive0authorized выполняется даже в случае отклонения запроса?

(Извиняюсь, если это дубликат. Я не смог найти подобный вопрос в другом месте здесь, но любезно закрыть этот вопрос, если вы можете найти один)

+0

Кроме того, для чего это стоит, я открыт идентичная проблема на странице GitHub Issues здесь: https://github.com/spray/spray/issues/1084 – rkoval

ответ

1

Семантика API маршрутизации объясняются в http://spray.io/documentation/1.2.3/spray-routing/advanced-topics/understanding-dsl-structure/ , Ключевой момент, который актуален здесь:

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

Два контрастных примера представлены на ссылочной странице. В этом примере Println происходит один раз (по маршруту времени создания):

val route: Route = get { 
    println("MARK") 
    complete("yeah") 
} 

И в этом примере, Println происходит с каждым запросом:

val route: Route = get { 
    complete { 
    println("MARK") 
    "yeah" 
    } 
} 
+0

Удивительно, это объясняет мою проблему отлично. Похоже, я должен ознакомиться с дополнительными темами, чтобы избежать большего количества этих ошибок. – rkoval

+0

Это похоже на довольно значительный недостаток в том, как работают распылители. Похоже, что как полные блоки, так и блоки onComplete запускают отклонения, которые нужно читать (на самом деле это актер, освобожденный для обработки сообщения об отклонениях). Представьте, что вы создаете будущее с эффектом sideeffect, и вам нужно использовать метод onComplete для спрея. Это будущее будет продолжать обрабатывать побочный эффект, пока метод onComplete не отменяет его, если он видит отклонения. – JBarber

+0

Чтобы расширить немного больше, учитывая [этот пример] (https://gist.github.com/Jacoby6000/250faa7068933ad3eca1), он всегда будет создавать объект, даже в случае отклонения. – JBarber