Skip to content
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

Stubbing with multiple receivers gives only one stubbed receiver #1102

Closed
ricardovh opened this issue Sep 28, 2020 · 3 comments · Fixed by #1311
Closed

Stubbing with multiple receivers gives only one stubbed receiver #1102

ricardovh opened this issue Sep 28, 2020 · 3 comments · Fixed by #1311
Labels

Comments

@ricardovh
Copy link
Contributor

Describe the bug
When having an adapter with multiple receivers (for example multiple ApiListeners with different uriPattern-properties), only one receiver is stubbed. I would expect both to be stubbed.

Reporter
Ricardo

Category
Use following Tags to categorize your bug report

  • Frank Framework

To Reproduce
Steps to reproduce the behavior:

  1. Create an adapter with multiple receivers
  2. Set the property stub4testtool to true and start your server
  3. See only one stubbed receiver+original receivers

Expected behavior
All receivers to be stubbed

Screenshots
N/A

Environment:

  • Application server (f.e. Tomcat/WebSphere/JBOSS/Jetty): Tomcat
  • Browser [e.g. chrome, safari]: Chrome
  • IAF Version [e.g. 7.5 RC3, 7.6]: 7.6-20200925.120005

Additional context
N/A

@ricardovh ricardovh added the Bug label Sep 28, 2020
@jacodg
Copy link
Contributor

jacodg commented Oct 19, 2020

Can you experiment with stub4testtool.xsl to see whether you can get the desired situation?

@ricardovh
Copy link
Contributor Author

I'll see what I can do, but that will probably be next month.

@mhdirkse
Copy link
Contributor

mhdirkse commented Feb 1, 2022

In the Frank!Manual, section Getting Started, I have a picture that shows the receivers within an adapter. I saw more receivers than I expected. I wrote an issue about this in the Frank!Manual project: frankframework/frank-manual#60. It comes down to reverting the change that was proposed in the present issue. Ricardo van Holst has agreed in a phone call.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants