New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WFLY-12190] EJB: EJB over HTTP discovery configuration #12887
Conversation
ejb3/src/main/resources/org/jboss/as/ejb3/subsystem/LocalDescriptions.properties
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The model description constants need defining.
However as on the analysis before we add a new server to server protocol we need to review the security implications.
@darranl I have updated the description. I have also added the possibility of HTTP discovery from standalone client (in attached PRs). Regarding security, EJB over HTTP protocol is integrated with Elytron and the invocations are secured. Specifically, I had to provide Elytron configuration for the tests to pass (discovery invocations to succeed). I agree that it has to be double-checked though. |
@tadamski I know the server side is already covered by Elytron security, the bit I am not sure about is the client side of these server to server connection. In this case there are a few scenarios that may need some integration: -
|
@darranl OK, I will try to investigate those but I would probably need some help. OTOH server->server invocations are already working in WildFly (with static discovery) so we may need to double-check that those are fine as well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change requires a model version bump, as well as transformers and transformation tests.
@tadamski we haven't really followed up on this together, it looks like it has a merge conflict anyway but do we want to set something up so we can look at the security implications in more detail? |
@darranl I have to update this PR but this is mostly config stuff. The key PR is wildfly/wildfly-http-client#29 on which this PR relies. I would be happy to discuss it. |
test, please ignore |
a45fab7
to
a79e3f9
Compare
I've removed the missing-reqs label as there was an agreement the test development can be late on this feature. |
This PR depends on #13305 |
d57f27d
to
dfeb23f
Compare
@jamezp merged; failing test seem unrelated; this should be ready to merge |
I see all checks passing, do anything else prevent this PR from merging? Thanks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've made some comments.
For this one to move forward we should get an approval from @darranl.
...-pack/common/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml
Outdated
Show resolved
Hide resolved
ee/src/main/java/org/jboss/as/ee/metadata/EJBClientDescriptorMetaData.java
Outdated
Show resolved
Hide resolved
ee/src/main/java/org/jboss/as/ee/metadata/EJBClientDescriptorMetaData.java
Outdated
Show resolved
Hide resolved
docs/src/main/asciidoc/_admin-guide/subsystem-configuration/EJB3.adoc
Outdated
Show resolved
Hide resolved
docs/src/main/asciidoc/_admin-guide/subsystem-configuration/EJB3.adoc
Outdated
Show resolved
Hide resolved
docs/src/main/asciidoc/_admin-guide/subsystem-configuration/EJB3.adoc
Outdated
Show resolved
Hide resolved
docs/src/main/asciidoc/_admin-guide/subsystem-configuration/EJB3.adoc
Outdated
Show resolved
Hide resolved
docs/src/main/asciidoc/_admin-guide/subsystem-configuration/EJB3.adoc
Outdated
Show resolved
Hide resolved
docs/src/main/asciidoc/_admin-guide/subsystem-configuration/EJB3.adoc
Outdated
Show resolved
Hide resolved
==== <remote-http-connection> | ||
|
||
`remote-http-connection` tag is used to define dynamic discovery based on | ||
HTTP procol: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/procol/protocol
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the main question I would like to ask is - is there sufficient test coverage of clients using authentication client configuration for a dynamically discovered destination?
As mentioned earlier we have aspects such as SSL and the credentials for authentication which should already be covered by the EJB client to verification that the behaviour is correct. In this case I believe it will be preferable for the resolved configuration to be based on the discovered destination.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The test coverage for the dynamically discovered destinations would require additional analysis. OTOH, dynamic discovery is main route of invocation also for remoting and this commit just adds this feature for HTTP. Currently EAP/WildFly already relies on dynamic invocation and if we decide that the testsuite have to be extended it should be done for a number of scenarios, possibly independently of this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, lets go with what we have here - if you are happy HTTP is just using the same pattern as the existing approaches we should be good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, but just to clarify cause I'm not sure if I understand correctly. Discovery provider and HttpEjbReceiver (which is used to perform invocation to discovered destination) (also other receivers) resolve their AuthenticationContexts independently:
https://github.com/wildfly/wildfly-http-client/blob/master/ejb/src/main/java/org/wildfly/httpclient/ejb/HttpEJBReceiver.java#L132
Should this be modified?
d9af418
to
a758a31
Compare
/retest |
The issues I've raised have all been addressed, but the discussion with Darran remains open. |
@@ -0,0 +1,85 @@ | |||
package org.jboss.as.test.multinode.ejb.http; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing header
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
I have one comment for testing that I don't think should hold up this PR so is something more general. At the moment our testsuite is becoming very slow to execute so the pattern of Configure -> Deploy -> Single Test -> Undeploy -> Revert Configuration adds a lot of steps for one test. Ideally if we can find ways a common deployment can be used for multiple scenarios we can execute multiple tests for a single pair or configure and pair of deploy tasks. Ideally finding ways to test the success and failure scenarios under the same test case. But in the case of this specific change I see we have some simple authentication client configuration where a single configuration is available but I would still like to see something where we test a configuration where the correct configuration is only resolved / resolvable after discovery. I don't necessarily have an issue with that being in a follow up PR if we can make sure it happens. The reason I am seeing this piece as important is because it will be an area of code we must maintain for backwards compatibility so once we release a Final version we will not be able to change the resolution logic without the risk of breaking something developed against the original behaviour. |
…pDescriptorTestCase
a758a31
to
8ea2b20
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tadamski This needs an update to the transformers to the previous management API version:
Ejb3SubsystemUnitTestCase and Ejb3TransformersTestCase should cover it as well.
@tadamski https://issues.redhat.com/browse/WFLY-13878 is to track my last request. |
@bstansberry I'll update the transformer to handle the new element |
https://issues.redhat.com/browse/EAP7-1236
https://issues.redhat.com/browse/WFLY-12190
Depends on:
#13305
Thanks for submitting your Pull Request!
Please make sure your PR meets the following requirements:
[WFLY-XYZ] Subject
orWFLY-XYZ Subject
For bigger changes, major and minor component upgrades make sure your PR also meets following requirements:
For new features ensure as well:
If you are not an active contributor of the WildFly project you can request sponsorship by one of the members to help guide you through the process.