Open
Conversation
mostroverkhov
suggested changes
Jun 6, 2019
|
|
||
| dependency 'org.openjdk.jmh:jmh-core:0.9' | ||
| dependency 'org.openjdk.jmh:jmh-generator-annprocess:0.9' | ||
| dependency "com.github.davidmoten:rxjava2-jdbc:${rxjava2JdbcVersion}" |
| @@ -0,0 +1,35 @@ | |||
| # This is a Gradle generated file for dependency locking. | |||
Contributor
There was a problem hiding this comment.
This and other lockfiles reference 0.11.x RSocket and older netty/reactor-netty dependencies - should be latest
gradle.properties
Outdated
| typesafeConfigVersion=1.3.3 | ||
| zipkinSenderVersion=2.7.6 | ||
| springBootDependenciesVersion=2.1.5.RELEASE | ||
| springBootDependenciesVersion=2.2.0.BUILD-SNAPSHOT |
Contributor
There was a problem hiding this comment.
if there are substantial changes after 2.2.0.M3 I suggest to add todo / comment. Otherwise 1.6.5 release is blocked by respective spring milestone release
Member
Author
There was a problem hiding this comment.
I guess this should go to 1.7.0 I don't think we want to deliver that to 1.6.x since it brakes backward compatibility with elder springs (at least it should do that).
|
|
||
| @org.springframework.boot.test.context.TestConfiguration | ||
| @ComponentScan | ||
| // @ComponentScan |
| * Messaging. | ||
| * | ||
| * @author Oleh Dokuka | ||
| * @since 1.7.0 |
Contributor
There was a problem hiding this comment.
I think @since version and netifiVersion in gradle.properties should be same
Also tags should be added to new sources consistently.
# Conflicts: # netifi-broker-client/src/main/java/com/netifi/broker/DefaultBuilderConfig.java # netifi-spring-core/src/main/java/com/netifi/spring/core/DestinationAwareClientFactory.java # netifi-spring-core/src/main/java/com/netifi/spring/core/annotation/BrokerClientStaticFactory.java
# Conflicts: # netifi-broker-client/src/main/java/com/netifi/broker/DefaultBuilderConfig.java # netifi-spring-core/src/main/java/com/netifi/spring/core/DestinationAwareClientFactory.java # netifi-spring-core/src/main/java/com/netifi/spring/core/annotation/BrokerClientStaticFactory.java
OlegDokuka
force-pushed
the
spring-messaging-integration
branch
from
b822c83 to
a5e7612
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR provides refactoring of existing spring Netifi codebase and provides integration with spring messaging
For now, it is not final integration (because of spring-messaging) but it is in the state it will be (unless someone says that I have to rewrite it 😂) but in general
I added a generic way to create a client for autowiring -> https://github.com/netifi/netifi-java/pull/8/files#diff-5c8c78e46b5bde6051f16291ac142a00 so now we don't have to bring spring-messaging to our project. Integration with Spring-messaging sits in a separate project -> https://github.com/netifi/netifi-java/pull/8/files#diff-0068b1ccc3b8fb900c6b7e54604d93f5
For now, Spring Messaging is waiting for Composite Metadata so once it is there the RSocketRequester could send data mime-type with regards of the provided content type so the Responder could retrieve it on its side and decode it back (now it sticks to
text/plain)