[JBoss JIRA] (WFLY-13216) /openapi throws 406 when Accept header is sufficiently complex
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13216?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13216:
------------------------------------
Description:
When accessing /openapi endpoint via Chrome, the following Accept header is sent:
{code}
Accept : text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
{code}
This should return a yaml document, as \*/\* is acceptable, though lower priority than, say, text/html.
This currently returns a 406 error.
was:
When accessing /openapi endpoint via Chrome, the following Accept header is sent:
Accept : text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
This should return a yaml document, as \*/\* is acceptable, though lower priority than, say, text/html.
This currently returns a 406 error.
> /openapi throws 406 when Accept header is sufficiently complex
> --------------------------------------------------------------
>
> Key: WFLY-13216
> URL: https://issues.redhat.com/browse/WFLY-13216
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenAPI
> Affects Versions: 19.0.0.Beta3
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Blocker
>
> When accessing /openapi endpoint via Chrome, the following Accept header is sent:
> {code}
> Accept : text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
> {code}
> This should return a yaml document, as \*/\* is acceptable, though lower priority than, say, text/html.
> This currently returns a 406 error.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13147) Deployment slowdown after WFLY upgrade (DeploymentArchive handling)
by Christoph Winter (Jira)
[ https://issues.redhat.com/browse/WFLY-13147?page=com.atlassian.jira.plugi... ]
Christoph Winter commented on WFLY-13147:
-----------------------------------------
Hi [~manovotn],
no problem! Yes exactly - both proposals try to avoid doing the very same work again and again; and you're also absolutely right about your assumptions concerning _ExternalBeanArchiveProcessor_. As you proposed, using a small local Set to store already processed Deployments might be a more clearer solution.
KR Christoph
> Deployment slowdown after WFLY upgrade (DeploymentArchive handling)
> -------------------------------------------------------------------
>
> Key: WFLY-13147
> URL: https://issues.redhat.com/browse/WFLY-13147
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 17.0.1.Final
> Reporter: Christoph Winter
> Assignee: Matěj Novotný
> Priority: Major
> Attachments: Screenshot from 2020-02-24 16-23-53.png, Screenshot from 2020-02-24 16-24-32.png
>
>
> Our team upgraded our application (>205 modules) from WFLY 8.2.1 to WFLY 17.0.1 we experienced a noticeable slowdown during the deployment process (3min vs. 6min)
> A colleague found out that the following classes seem to cause the lag during dependency resolution since dependencies are processed multiple times:
> * weld/subsystem/src/main/java/org/jboss/as/weld/deployment/BeanDeploymentArchiveImpl.java
> * weld/subsystem/src/main/java/org/jboss/as/weld/deployment/processors/ExternalBeanArchiveProcessor.java
> and came up with the following workarounds that should fix the issues
> {noformat}
> diff --git a/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/BeanDeploymentArchiveImpl.java b/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/BeanDeploymentArchiveImpl.java
> index 521f47cc7d..1b4d7e8b4c 100644
> --- a/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/BeanDeploymentArchiveImpl.java
> +++ b/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/BeanDeploymentArchiveImpl.java
> @@ -246,7 +246,12 @@ public class BeanDeploymentArchiveImpl implements WildFlyBeanDeploymentArchive {
> if (moduleDependency.getIdentifier().equals(that.getModule().getIdentifier())) {
> return true;
> }
> + }
> + }
> + for (DependencySpec dependency : module.getDependencies()) {
> + if (dependency instanceof ModuleDependencySpec) {
> + ModuleDependencySpec moduleDependency = (ModuleDependencySpec) dependency;
> // moduleDependency might be an alias - try to load it to get lined module
> Module module = loadModule(moduleDependency);
> if (module != null && module.getIdentifier().equals(that.getModule().getIdentifier())) {
> {noformat}
> as well as
> {noformat}
> diff --git a/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/processors/ExternalBeanArchiveProcessor.java b/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/processors/ExternalBeanArchiveProcessor.java
> index da6e0bfcaf..1b539bba4e 100644
> --- a/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/processors/ExternalBeanArchiveProcessor.java
> +++ b/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/processors/ExternalBeanArchiveProcessor.java
> @@ -162,6 +162,12 @@ public class ExternalBeanArchiveProcessor implements DeploymentUnitProcessor {
> return;
> }
> for (DependencySpec dep : module.getDependencies()) {
> + if (!(dep instanceof ModuleDependencySpec)) {
> + continue;
> + }
> + if (deploymentUnits.stream().anyMatch(d -> (((ModuleDependencySpec)dep).getName()).endsWith(d.getName()))) {
> + continue;
> + }
> final Module dependency = loadModuleDependency(dep);
> if (dependency == null) {
> continue;{noformat}
> The fixes should prevent dependencies from being processed multiple times, however, the latter should be improved.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months