29029be31d
* !htt #18919 #19519 Align Java HTTP server DSL with Scala This commits replaces the Java HTTP server DSL with a Java-8 centric one which exposes all scala DSL concepts to be usable from Java, including custom directives, (un)marshallers, rejections, headers, and type safety for path and query parameters. * Add RequestContext and RouteResult to Java DSL fix websockets WIP bring java docs up to date. This applies some updates to the root-level documentation * [htp] Fix java documentation to correctly mention timeouts Timeouts are configured the same in Java and Scala. Hence, linking to the scala docs for timeouts from Java. * =htc fix optionalHeaderValueByType in Java * =htt #20200 fix java testkit always using NoLogging instead logger * +htt actually run new javadsl tests, allow overriding config * =htt improve javadsl test infra with more details when fails * =htt fix bug in wrong path matcher exposed * +htp add missing remaining path matcher * =htp Java DSL cookie tests fixed * =htt Java DSL ParameterDirectivesTest fixed Protect the tweets from scalariform Incorrect response expectations in cache condition directives spec fixed * =htt Path directives for Java DSL * +!htt PathMatchers rewritten, made uniform and tests passing * Bugfix in java reject and a little test-boyscouting * Revert "Incorrect response expectations in cache condition directives spec fixed" This reverts commit cd50e89d45db010309f8249b090ea654ebb11c7a. * +htc HttpAPIsTest is compile time only, not for running Also, moved from the client package since not strictly a client test. SecurityDirectives passing Two faulty tests and two actual bugs. Fix for cache condition spec not working * Not sending in Unit instad of the implicit magnet in the test * HeaderMagnet now works as expected * Java API added for - and + on DateTime PetStore example and test fixed * Annotations to make marshalling work without default constructor * Made model class immutable Incorrect tests fixed Some scaladoc boyscouting as bonus * =htt RequestValTest sprinkled out across multiple directive tests Client ip extraction test with incorrect header name fixed. * =htt Incorrect CodingDirectivesTest fixed. * =htt Bugfix for Java Unmarshaller.firstOf and fixes to JavaRouteTest * =htt MarshallerTest fixed * Missing seal signature added to JavaDSL * More consistent (with Scala) test kit setup for Java * missing Javadocs added * Thread.sleep in default exception handler removed * =htt copy directive docs, prepare for finishing it up * +htt SecurityDirectives.authorize variants and test coverage added * +htt Custom headers in Java DSL * =htt WIP on java docs * +htp add missing parameterOrDefault directive Fixed a lot of doc warnings * =htc intense progress on javadsl docs * =htc #20470 Link to issue about docs and fix compile error compile, migration guide don't mima check http-experimental * =htt Java DSL doc warnings fixed. Only `Could not lex literal_block` ones left now * =htc fix mima settings * =doc fix MethodDirectives doc test with custom method * =htc fix coding directives spec after bad merge * =htc fix concat being corresponding to route() in javadsl * =htt Disable consistency check for route/concat as it fails only on ci server * !htt Minor fixes to PathMatchers
63 lines
2.8 KiB
ReStructuredText
63 lines
2.8 KiB
ReStructuredText
.. _http-javadsl-migration-guide:
|
||
|
||
Migration Guide from "old" HTTP JavaDSL
|
||
=======================================
|
||
|
||
The so-called "old" JavaDSL for Akka HTTP was initially developed during the project's experimental phase,
|
||
and thanks to multiple user comments and contributions we were able to come up with a more Java 8 "feel",
|
||
which at the same time is also closer to the existing ScalaDSL.
|
||
|
||
The previous DSL has been entirely removed and replaced with the the so-called "new" one.
|
||
Upgrading to the new DSL is **highly encouraged** since the old one not only was rather hard to work with,
|
||
it actually was not possible to express many typical use-cases using it.
|
||
|
||
The most major changes include:
|
||
|
||
|
||
HttpApp is gone
|
||
---------------
|
||
``HttpApp`` (a helper class containing a ``main()`` implementation) is gone, as we would like to encourage understanding
|
||
how the various elements of the API fit together.
|
||
|
||
Instead developers should start applications "manually", by converting a ``Route`` to a ``Flow<HttpRequest, HttpResponse, ?>``
|
||
using the ``Route.flow`` method. For examples of full apps refer to :ref:`http-testkit-java`.
|
||
|
||
``RequestVal`` is gone
|
||
----------------------
|
||
The old API heavily relied on the concept of "request values" which could be used to extract a value from a request context.
|
||
|
||
Based on community feedback and our own experience we found them too hard to work with in more complex settings.
|
||
The concept of a request value has been completely removed, and replaced with proper "directives", exacly like in the ScalaDSL.
|
||
|
||
**Previously**::
|
||
|
||
RequestVal<Host> host = Headers.byClass(Host.class).instance();
|
||
|
||
final Route route =
|
||
route(
|
||
handleWith1(host, (ctx, h) ->
|
||
ctx.complete(String.format("Host header was: %s", h.host()))
|
||
)
|
||
);
|
||
|
||
|
||
**Now**::
|
||
|
||
final Route route =
|
||
headerValueByType(Host.class, host -> complete("Host was: " + host));
|
||
|
||
All of ScalaDSL routing has corresponding JavaDSL
|
||
-------------------------------------------------
|
||
Both ``Route``, ``RouteResult`` and other important core concepts such as ``Rejections`` are now modeled 1:1 with Scala,
|
||
making is much simpler to understand one API based on the other one – tremendously useful when learning about some nice
|
||
pattern from blogs which used Scala, yet need to apply it in Java and the other way around.
|
||
|
||
It is now possible to implement marshallers using Java. Refer to :ref:`marshalling-java` for details.
|
||
|
||
Migration help
|
||
--------------
|
||
As always, feel free to reach out via the `akka-user <https://groups.google.com/forum/#!searchin/akka-user/>`_ mailing list or gitter channels,
|
||
to seek help or guidance when migrating from the old APIs.
|
||
|
||
For Lightbend subscription owners it is possible to reach out to the core team for help in the migration by asking specific
|
||
questions via the `Lightbend customer portal <https://portal.lightbend.com/>`_.
|