[JBoss JIRA] (WFLY-13099) Standard configuration files for MicroProfile use cases
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13099?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13099:
------------------------------------
Priority: Blocker (was: Major)
> Standard configuration files for MicroProfile use cases
> -------------------------------------------------------
>
> Key: WFLY-13099
> URL: https://issues.redhat.com/browse/WFLY-13099
> Project: WildFly
> Issue Type: Feature Request
> Components: Build System
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Blocker
> Fix For: 19.0.0.Beta3
>
>
> Provide standard configuration files 'standalone-microprofile.xml' and 'standalone-microprofile-ha.xml'. The HA variant will be equivalent to non-HA except that base features that have distributed variants (e.g. web session clustering and Hibernate second-level caching) will use the HA variants.
> Equivalent profiles in domain.xml are not required.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13161) CLIENT-CERT login does not work in intermediate elytron setup
by Ricardo Martin Camarero (Jira)
[ https://issues.redhat.com/browse/WFLY-13161?page=com.atlassian.jira.plugi... ]
Ricardo Martin Camarero moved JBEAP-18804 to WFLY-13161:
--------------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-13161 (was: JBEAP-18804)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 19.0.0.Beta2
(was: 7.2.4.GA)
> CLIENT-CERT login does not work in intermediate elytron setup
> -------------------------------------------------------------
>
> Key: WFLY-13161
> URL: https://issues.redhat.com/browse/WFLY-13161
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 19.0.0.Beta2
> Reporter: Ricardo Martin Camarero
> Assignee: Ricardo Martin Camarero
> Priority: Major
> Labels: elytron
>
> Authentication does not uses cache when use Picketbox by Elytron.
> With Picketbox only:
> {code:java}
> 2020-01-02 10:39:48,215 TRACE [org.jboss.security] (default task-1) PBOX00208: Inserted cache info: org.jboss.security.authentication.JBossCachedAuthenticationManager$DomainInfo@8ea6c5a
> 2020-01-02 10:39:48,215 TRACE [org.jboss.security] (default task-1) PBOX00201: End isValid, result = true
> 2020-01-02 10:39:48,401 TRACE [org.jboss.security] (default task-1) PBOX00354: Setting security roles ThreadLocal: null
> 2020-01-02 10:39:56,034 TRACE [org.jboss.security] (default task-1) PBOX00200: Begin isValid, principal: org.wildfly.extension.undertow.security.AccountImpl$AccountPrincipal@a518beed, cache entry:
> {code}
> With Picketbox by Elytron:
> {code:java}
> /2020-01-02 10:42:11,325 TRACE [org.jboss.security] (default task-1) PBOX00205: End validateCache, result = false
> 2020-01-02 10:42:11,325 TRACE [org.jboss.security] (default task-1) PBOX00209: defaultLogin, principal: MP VIU1
> 2020-01-02 10:42:11,325 TRACE [org.jboss.security] (default task-1) PBOX00221: Begin getAppConfigurationEntry(isone-jaas-cert), size: 4
> 2020-01-02 10:42:11,325 TRACE [org.jboss.security] (default task-1) PBOX00224: End getAppConfigurationEntry(isone-jaas-cert), AuthInfo: AppConfigurationEntry[]:
> {code}
> I'm attaching the configurations used and the application to test.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13127) NPE in OpenApiAnnotationScanner when OpenTracing TCK war is deployed
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13127?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFLY-13127:
--------------------------------
Priority: Blocker (was: Critical)
> NPE in OpenApiAnnotationScanner when OpenTracing TCK war is deployed
> --------------------------------------------------------------------
>
> Key: WFLY-13127
> URL: https://issues.redhat.com/browse/WFLY-13127
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenAPI, MP OpenTracing
> Affects Versions: 19.0.0.Beta2
> Reporter: Brian Stansberry
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 19.0.0.Beta3, 20.0.0.Beta1
>
>
> I tried running the microprofile-tck/opentracing tests against a config that included the OpenAPI subsystem. It failed with an NPE:
> {code}
> 2020-02-18 16:36:53,302 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /Users/bstansberry/dev/wildfly/wildfly/testsuite/integration/microprofile-tck/opentracing/target/wildfly/standalone/data/content/85/48e223eb8bfcd73f66458e14a0bbc425998a70/content
> 2020-02-18 16:36:53,313 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0027: Starting deployment of "opentracing.war" (runtime-name: "opentracing.war")
> 2020-02-18 16:36:54,020 INFO [org.jboss.weld.deployer] (MSC service thread 1-7) WFLYWELD0003: Processing weld deployment opentracing.war
> 2020-02-18 16:36:54,114 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-7) HV000001: Hibernate Validator 6.0.18.Final
> 2020-02-18 16:36:54,330 INFO [org.jboss.weld.Version] (MSC service thread 1-8) WELD-000900: 3.1.3 (Final)
> 2020-02-18 16:36:54,576 INFO [io.smallrye.metrics] (MSC service thread 1-5) MicroProfile: Metrics activated (SmallRye Metrics version: 2.4.0)
> 2020-02-18 16:36:54,992 WARN [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0101: Duplicate servlet mapping /rest/* found
> 2020-02-18 16:36:55,173 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.undertow.host.default-server.default-host./openapi: org.jboss.msc.service.StartException in service org.wildfly.undertow.host.default-server.default-host./openapi: java.lang.NullPointerException
> at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:66)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.createResponseFromJaxRsMethod(OpenApiAnnotationScanner.java:934)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsMethod(OpenApiAnnotationScanner.java:688)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.lambda$processJaxRsResourceClass$0(OpenApiAnnotationScanner.java:422)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1556)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsResourceClass(OpenApiAnnotationScanner.java:420)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.scan(OpenApiAnnotationScanner.java:221)
> at io.smallrye.openapi.runtime.OpenApiProcessor.modelFromAnnotations(OpenApiProcessor.java:72)
> at org.wildfly.extension.microprofile.openapi.deployment.OpenAPIModelServiceConfigurator.get(OpenAPIModelServiceConfigurator.java:173)
> at org.wildfly.extension.microprofile.openapi.deployment.OpenAPIModelServiceConfigurator.get(OpenAPIModelServiceConfigurator.java:94)
> at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:63)
> ... 8 more
> {code}
> I hit this when working on WFLY-13099. I was using a standalone.xml variant equivalent to what Galleon would generate using the cloud-server, h2-default-datasource, microprofile-fault-tolerance, microprofile-jwt and microprofile-openapi layers. It wasn't a slimmed server though.
> OpenApiAnnotationScanner L934 seems to assume 'schema' will not be null. But the 'SchemaFactory.typeToSchema' method seems like it's written such that returning null is a possibility; e.g. L362 in the final 'else' block is doing a null check on the 'schema' var whose value is ultimately returned. (I don't see how else the NPE would happen other than SchemaFactory.typeToSchema returning null.)
>
> I put Critical severity on this because I don't know anything about opentracing.war; i.e. whether it's written in a way that would be a real corner case for OpenAPI. I'm being conservative and assigning a high priority.
> [~ehugonnet] FYI.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-4991) Minor changes on Collection Editor UI
by Anna Dupliak (Jira)
[ https://issues.redhat.com/browse/DROOLS-4991?page=com.atlassian.jira.plug... ]
Anna Dupliak updated DROOLS-4991:
---------------------------------
Attachment: parent toggle.webm
> Minor changes on Collection Editor UI
> -------------------------------------
>
> Key: DROOLS-4991
> URL: https://issues.redhat.com/browse/DROOLS-4991
> Project: Drools
> Issue Type: Enhancement
> Components: Scenario Simulation and Testing
> Reporter: Yeser Amer
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
> Attachments: AddItem.webm, parent toggle.webm, unwrapped.webm
>
>
> - When it's not in "edit mode" consider moving the "Add new item" directly below the last item in the list.
> - Consider renaming the action to "Add list value" or whatever most closely describes the action.
> - Consider making the font sizes the same within the dialog. The Name field looks too small, while the Edit name looks too large, but the "Add new item" looks about right.
> https://issues.redhat.com/secure/thumbnail/12464511/_thumb_12464511.png
> - Also when the Edit form is open is it scrolled out of view by default. Maybe as a short term patch could the area auto scroll somehow to make sure the form area is in view? Would be best to just redesign this though in the long run imo.
> Thanks!
> Liz
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-4991) Minor changes on Collection Editor UI
by Anna Dupliak (Jira)
[ https://issues.redhat.com/browse/DROOLS-4991?page=com.atlassian.jira.plug... ]
Anna Dupliak updated DROOLS-4991:
---------------------------------
Attachment: unwrapped.webm
> Minor changes on Collection Editor UI
> -------------------------------------
>
> Key: DROOLS-4991
> URL: https://issues.redhat.com/browse/DROOLS-4991
> Project: Drools
> Issue Type: Enhancement
> Components: Scenario Simulation and Testing
> Reporter: Yeser Amer
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
> Attachments: AddItem.webm, unwrapped.webm
>
>
> - When it's not in "edit mode" consider moving the "Add new item" directly below the last item in the list.
> - Consider renaming the action to "Add list value" or whatever most closely describes the action.
> - Consider making the font sizes the same within the dialog. The Name field looks too small, while the Edit name looks too large, but the "Add new item" looks about right.
> https://issues.redhat.com/secure/thumbnail/12464511/_thumb_12464511.png
> - Also when the Edit form is open is it scrolled out of view by default. Maybe as a short term patch could the area auto scroll somehow to make sure the form area is in view? Would be best to just redesign this though in the long run imo.
> Thanks!
> Liz
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-4991) Minor changes on Collection Editor UI
by Anna Dupliak (Jira)
[ https://issues.redhat.com/browse/DROOLS-4991?page=com.atlassian.jira.plug... ]
Anna Dupliak updated DROOLS-4991:
---------------------------------
Attachment: AddItem.webm
> Minor changes on Collection Editor UI
> -------------------------------------
>
> Key: DROOLS-4991
> URL: https://issues.redhat.com/browse/DROOLS-4991
> Project: Drools
> Issue Type: Enhancement
> Components: Scenario Simulation and Testing
> Reporter: Yeser Amer
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
> Attachments: AddItem.webm
>
>
> - When it's not in "edit mode" consider moving the "Add new item" directly below the last item in the list.
> - Consider renaming the action to "Add list value" or whatever most closely describes the action.
> - Consider making the font sizes the same within the dialog. The Name field looks too small, while the Edit name looks too large, but the "Add new item" looks about right.
> https://issues.redhat.com/secure/thumbnail/12464511/_thumb_12464511.png
> - Also when the Edit form is open is it scrolled out of view by default. Maybe as a short term patch could the area auto scroll somehow to make sure the form area is in view? Would be best to just redesign this though in the long run imo.
> Thanks!
> Liz
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13159) Datasource resolution fails for application layer alias when using Hibernate bytecode enhancement
by Scott Marlow (Jira)
[ https://issues.redhat.com/browse/WFLY-13159?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on WFLY-13159:
-------------------------------------
Just to mention a (larger code change) alternative, we could move the internal (WildFly) DataSource service dependency from the first pu bootstrap phase (org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl) service to the second pu phase (org.jboss.as.jpa.service.PersistenceUnitServiceImpl) service and passing the DataSource via org.hibernate.jpa.boot.spi.EntityManagerFactoryBuilder#withDataSource(DataSource). This could be a change to consider in the future, to allow even later specifying of the DataSource.
> Datasource resolution fails for application layer alias when using Hibernate bytecode enhancement
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-13159
> URL: https://issues.redhat.com/browse/WFLY-13159
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 18.0.1.Final
> Reporter: Stephen Fikes
> Assignee: Scott Marlow
> Priority: Major
> Fix For: 20.0.0.Beta1
>
>
> {code}
> ... ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "jboss.eap-1.0-SNAPSHOT.ear")]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.app.ejb-application.env.testDS"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"jboss.eap-1.0-SNAPSHOT.ear/ejb.jar#jboss-eap-hibernate\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.ejb-application.env.testDS]"]
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5106) Local/Internal Maven Repos can not be accessed
by Steve Davidson (Jira)
[ https://issues.redhat.com/browse/DROOLS-5106?page=com.atlassian.jira.plug... ]
Steve Davidson updated DROOLS-5106:
-----------------------------------
Summary: Local/Internal Maven Repos can not be accessed (was: Local Maven Repos can not be accessed)
> Local/Internal Maven Repos can not be accessed
> ----------------------------------------------
>
> Key: DROOLS-5106
> URL: https://issues.redhat.com/browse/DROOLS-5106
> Project: Drools
> Issue Type: Bug
> Components: Artifact Repository
> Affects Versions: 7.33.0.Final
> Reporter: Steve Davidson
> Assignee: Alexandre Bakos
> Priority: Major
> Labels: Drools, drools-compiler, maven
>
> Attempting to use an internal Nexus Repository, unable to load Drools KIE Modules using Maven. This works with 7.29.Final. Changing to 7.33.Final fails with the following stack trace;
> {code:java}
> WARNING: Environment variable M2_HOME is not set
> Feb 24, 2020 5:12:30 PM org.kie.server.services.impl.KieServerImpl createContainer
> SEVERE: Error creating container 'JUnit Test: kie-server' for module 'com.j2eeguys.demo:KieIssueDemo:0.1.0-SNAPSHOT'
> java.lang.RuntimeException: Cannot find KieModule: com.j2eeguys.demo:KieIssueDemo:0.1.0-SNAPSHOT
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:186)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:176)
> at org.kie.server.services.impl.KieServerImpl.createContainer(KieServerImpl.java:281)
> at org.kie.server.remote.rest.common.resource.KieServerRestImpl.createContainer(KieServerRestImpl.java:157)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
> at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:443)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:233)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:139)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:142)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:219)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.eclipse.jetty.servlet.ServletHolder$NotAsyncServlet.service(ServletHolder.java:1401)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:760)
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1617)
> at org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:226)
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604)
> at org.kie.server.services.impl.security.web.CaptureHttpRequestFilter.doFilter(CaptureHttpRequestFilter.java:42)
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:501)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1592)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1296)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1562)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1211)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:386)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:562)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:378)
> at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:270)
> at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
> at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:388)
> at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
> at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
