[JBoss JIRA] (DROOLS-5637) Hide definedKeySet of InputSet/OutputSet from Swagger/OpenApi
by Toshiya Kobayashi (Jira)
Toshiya Kobayashi created DROOLS-5637:
-----------------------------------------
Summary: Hide definedKeySet of InputSet/OutputSet from Swagger/OpenApi
Key: DROOLS-5637
URL: https://issues.redhat.com/browse/DROOLS-5637
Project: Drools
Issue Type: Bug
Components: dmn engine
Affects Versions: 7.44.0.Final
Reporter: Toshiya Kobayashi
Assignee: Matteo Mortari
definedKeySet is introduced to InputSet/OutputSet by DROOLS-5517 but users should not see it in Swagger/OpenAPI example payload.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13257) Improvements for MicroProfile Fault Tolerance quickstart
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13257?page=com.atlassian.jira.plugi... ]
Radoslav Husar commented on WFLY-13257:
---------------------------------------
The first two were already done by [~thofman]. The rest is up for taking.
> Improvements for MicroProfile Fault Tolerance quickstart
> --------------------------------------------------------
>
> Key: WFLY-13257
> URL: https://issues.redhat.com/browse/WFLY-13257
> Project: WildFly
> Issue Type: Task
> Components: MP Fault Tolerance, Quickstarts
> Affects Versions: 19.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Optional
> Fix For: Awaiting Volunteers
>
>
> Follow up on WFLY-12770 – the initial implementation:
> * Investigate/update OpenShift Support
> * Include a test case (I have a local unfinished branch)
> * Demonstrate @Bulkhead
> * Demonstrate @Asynchronous
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13666) Loss of Servlet Context Data when request canceled.
by Bartosz Baranowski (Jira)
[ https://issues.redhat.com/browse/WFLY-13666?page=com.atlassian.jira.plugi... ]
Bartosz Baranowski reassigned WFLY-13666:
-----------------------------------------
Assignee: Bartosz Baranowski (was: Flavia Rainone)
> Loss of Servlet Context Data when request canceled.
> ---------------------------------------------------
>
> Key: WFLY-13666
> URL: https://issues.redhat.com/browse/WFLY-13666
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 20.0.1.Final
> Reporter: Cody Lerum
> Assignee: Bartosz Baranowski
> Priority: Major
>
> NPE occasionally raised in Wildfly 20.0.1 when the response a view is requested repeatedly from the same tab by rapidly double clicking.
> This issue was found while trying to find a reproducer to WFLY-13662 so which could also be failing if some of the request context data is being lost.
> {code:java}
> 14:49:14,782 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /demo/list.xhtml: java.lang.NullPointerException14:49:14,782 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /demo/list.xhtml: java.lang.NullPointerException at deployment.demo.war//org.ocpsoft.rewrite.servlet.RewriteFilter.getFilterCount(RewriteFilter.java:316) at deployment.demo.war//org.ocpsoft.rewrite.servlet.RewriteFilter.doFilter(RewriteFilter.java:208) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at deployment.demo.war//demo.DemoFilter.doFilter(DemoFilter.java:30) at javax.servlet.api@2.0.0.Final//javax.servlet.http.HttpFilter.doFilter(HttpFilter.java:97) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.core@2.1.3.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.core@2.1.3.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.core@2.1.3.Final//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.core@2.1.3.Final//io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.core@2.1.3.Final//io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.core@2.1.3.Final//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.core@2.1.3.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.core@2.1.3.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68) at io.undertow.core@2.1.3.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99) at io.undertow.core@2.1.3.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:370) at io.undertow.core@2.1.3.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830) at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) at java.base/java.lang.Thread.run(Thread.java:832) {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13774) Difference in OpenTracing subsystem standard configuration leads to the tests failures
by Tomas Radej (Jira)
[ https://issues.redhat.com/browse/WFLY-13774?page=com.atlassian.jira.plugi... ]
Tomas Radej commented on WFLY-13774:
------------------------------------
[~baranowb] I'm no longer the DPM on EAP. Copying [~ncbaratta] and [~psargent].
> Difference in OpenTracing subsystem standard configuration leads to the tests failures
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-13774
> URL: https://issues.redhat.com/browse/WFLY-13774
> Project: WildFly
> Issue Type: Bug
> Components: Build System, MP OpenTracing
> Reporter: Sultan Zhantemirov
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> Since OpenTracing has been introduced, `standalone.xml` had the following OT SmallRye subsystem configuration:
> {noformat}
> <subsystem xmlns="urn:wildfly:microprofile-opentracing-smallrye:2.0" default-tracer="jaeger">
> <jaeger-tracer name="jaeger">
> <sampler-configuration sampler-type="const" sampler-param="1.0"/>
> </jaeger-tracer>
> </subsystem>
> {noformat}
> With WildFly 19 and later we also have `standalone-microprofile.xml` configuration file which is used by default in MicroProfile test suite [1]. It has the following configuration:
> {noformat}
> <subsystem xmlns="urn:wildfly:microprofile-opentracing-smallrye:2.0"/>
> {noformat}
> As it is recommended in documentation [2] it's better to define missing Jaeger properties (_sampler type _and _sampler param_) in order to sample every request. Sampling every request is needed by MicroProfile test suite OpenTracing basic tests.
> A question is: will `standalone-microprofile.xml` configuration file have the wider OT subsystem configuration? Or do the tests have to define additional attributes in subsystem by themselves?
> Thank you.
> [1] - https://github.com/jboss-eap-qe/eap-microprofile-test-suite#target-distri...
> [2] - https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13832) Bug in detecting the org.apache.cxf module
by Ivo Studensky (Jira)
[ https://issues.redhat.com/browse/WFLY-13832?page=com.atlassian.jira.plugi... ]
Ivo Studensky updated WFLY-13832:
---------------------------------
Labels: downstream_dependency (was: )
> Bug in detecting the org.apache.cxf module
> ------------------------------------------
>
> Key: WFLY-13832
> URL: https://issues.redhat.com/browse/WFLY-13832
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 20.0.1.Final
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
> Priority: Major
> Labels: downstream_dependency
>
> When deploying an EAR file which has a sub deployment that uses CXF annotation classes a warning is logged that looks like this:
> WFLYWS0065: Annotation '@org.apache.cxf.interceptor.OutInterceptors' found on class 'de.comdirect.application.mt.wsexample.server.SimpleWsServiceWS'. Perhaps you forgot to add a 'org.apache.cxf' module dependency to your deployment?
> If you declare a dependency on org.apache.cxf in the sub-deployment, the warning is not logged. However, if you declare the org.apache.cxf dependency at the EAR level with export=true you still get the message even though the CXF module should be visible.
> I tracked down the class org.jboss.as.webservices.deployers.WSClassVerificationProcessor located in the org/jboss/as/webservices/main/wildfly-webservices-server-integration-7.3.0.GA-redhat-00004.jar
> In this class there is a method which logs this message, plus an additional related method:
> private void verifyApacheCXFModuleDependencyRequirement(DeploymentUnit unit) {
> if (!hasCxfModuleDependency(unit)) {
>
> CompositeIndex index = (CompositeIndex)unit.getAttachment(Attachments.COMPOSITE_ANNOTATION_INDEX);
> DotName[] dotNames = \{ DotNames.WEB_SERVICE_ANNOTATION, DotNames.WEB_SERVICE_PROVIDER_ANNOTATION };
> for (DotName dotName : dotNames) {
> for (AnnotationInstance ai : index.getAnnotations(dotName)) {
> AnnotationTarget at = ai.target();
> if (at instanceof ClassInfo) {
> ClassInfo clazz = (ClassInfo)ai.target();
> for (DotName dn : clazz.annotations().keySet()) {
> if (dn.toString().startsWith("org.apache.cxf")) {
> WSLogger.ROOT_LOGGER.missingModuleDependency(dn.toString(), clazz.name().toString(), "org.apache.cxf");
> }
> }
> }
> }
> }
> }
> }
> private static boolean hasCxfModuleDependency(DeploymentUnit unit) {
> ModuleSpecification moduleSpec = (ModuleSpecification)unit.getAttachment(Attachments.MODULE_SPECIFICATION);
> for (ModuleDependency dep : moduleSpec.getUserDependencies()) {
> String id = dep.getIdentifier().getName();
> if (cxfExportingModules.contains(id)) {
> return true;
> }
> }
> return false;
> }
> The hasCxfModuleDependency() method checks a list of dependencies called userDependencies looking to see if there is an "org.apache.cxf" entry in the list.
> However, there is more than one list of module dependencies which are part of moduleSpec.
> private final List<ModuleDependency> systemDependencies = new ArrayList();
> private final List<ModuleDependency> localDependencies = new ArrayList();
> private final List<ModuleDependency> userDependencies = new ArrayList();
> I think when you have an exported dependency from the EAR level it may be part of one of the other dependency lists rather than in userDependencies, so what we have is well-meaning code that tries to check and make sure you have the right dependency to support your annotation (because normally missing annotation classes just fail silently so a check is useful to have), but I think it doesn't check everywhere that it should.
> Since the EAP 7.3.1 patch just came out, I installed that and repeated the test but there was no difference.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (DROOLS-5633) 【looking for help】I want to load class from string instead of from source, but it always failed
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5633?page=com.atlassian.jira.plug... ]
Mario Fusco resolved DROOLS-5633.
---------------------------------
Resolution: Explained
You're using quite old API. Conversely you could create a KieFileSystem, add both drl and java sources there and compile it. See an example here https://github.com/kiegroup/drools/blob/master/drools-compiler/src/test/j...
> 【looking for help】I want to load class from string instead of from source, but it always failed
> -----------------------------------------------------------------------------------------------
>
> Key: DROOLS-5633
> URL: https://issues.redhat.com/browse/DROOLS-5633
> Project: Drools
> Issue Type: Feature Request
> Reporter: SHUAI ZHANG
> Assignee: Mario Fusco
> Priority: Major
>
> I want to dynamically load rules(drl files) and java classes. And now I can load drl by the below way. But I dont know how to dynamically load java classes by String type.
> For example: I have a drl which is including class Person, so the Person must be existed in my project. However my service is running, I can not restart the serbice, and I have Person class in my database as String type. How can I load the String Person to kiebase?
> please help me, thank you very much!
> {code:java}
> public static void loadRulesFromStr(InternalKnowledgeBase kBase, List<String> drls) {
> KnowledgeBuilderConfiguration kbc = KnowledgeBuilderFactory.newKnowledgeBuilderConfiguration();
> KnowledgeBuilder kBuilder = KnowledgeBuilderFactory.newKnowledgeBuilder(kbc);
> for (String drl : drls) {
> kBuilder.add(ResourceFactory.newByteArrayResource(drl.getBytes()), ResourceType.DRL);
> }
> if (kBuilder.hasErrors()) {
> System.out.println(kBuilder.getErrors().toString());
> }
> kBase.addPackages(kBuilder.getKnowledgePackages());
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (DROOLS-5633) 【looking for help】I want to load class from string instead of from source, but it always failed
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5633?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-5633:
--------------------------------
Sprint: 2020 Week 37-39 (from Sep 7)
> 【looking for help】I want to load class from string instead of from source, but it always failed
> -----------------------------------------------------------------------------------------------
>
> Key: DROOLS-5633
> URL: https://issues.redhat.com/browse/DROOLS-5633
> Project: Drools
> Issue Type: Feature Request
> Reporter: SHUAI ZHANG
> Assignee: Mario Fusco
> Priority: Major
>
> I want to dynamically load rules(drl files) and java classes. And now I can load drl by the below way. But I dont know how to dynamically load java classes by String type.
> For example: I have a drl which is including class Person, so the Person must be existed in my project. However my service is running, I can not restart the serbice, and I have Person class in my database as String type. How can I load the String Person to kiebase?
> please help me, thank you very much!
> {code:java}
> public static void loadRulesFromStr(InternalKnowledgeBase kBase, List<String> drls) {
> KnowledgeBuilderConfiguration kbc = KnowledgeBuilderFactory.newKnowledgeBuilderConfiguration();
> KnowledgeBuilder kBuilder = KnowledgeBuilderFactory.newKnowledgeBuilder(kbc);
> for (String drl : drls) {
> kBuilder.add(ResourceFactory.newByteArrayResource(drl.getBytes()), ResourceType.DRL);
> }
> if (kBuilder.hasErrors()) {
> System.out.println(kBuilder.getErrors().toString());
> }
> kBase.addPackages(kBuilder.getKnowledgePackages());
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months