[JBoss JIRA] (WFLY-13866) Several traces created in Jaeger for just one method call
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13866?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13866:
------------------------------------
Fix Version/s: 21.0.0.Final
(was: 21.0.0.Beta1)
> Several traces created in Jaeger for just one method call
> ---------------------------------------------------------
>
> Key: WFLY-13866
> URL: https://issues.redhat.com/browse/WFLY-13866
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 21.0.0.Beta1
> Reporter: Fabio Burzigotti
> Assignee: Emmanuel Hugonnet
> Priority: Critical
> Fix For: 21.0.0.Final
>
>
> I am migrating one opentracing/fault-tolerance test from Thorntail TS [1] and I noticed that Wildfly SNAPSHOT is behaving differently with respect to what in the subject.
> The test is pretty simple, deploying a REST app which makes use of injected service which in turn leverages microprofile opentracing (via API) and fault-tolerance (via annotations). The test executes the following 2 methods in the given order:
> - call {{hello}}, which is synchronous and is throwing an exception, hence failing and gets called again then ending up with the fallback. This generates 1 trace with 4 spans in Jaeger and the behavior is consistent between TT and WildFly
> - call {{helloAsync}}, which is asynchronous and is throwing an exception, hence failing and getting called again (asynchronously?) then ending up with the fallback. This generates the following traces in Jaeger:
> TT: 1 trace with 4 spans
> WildFly: 4 separate traces , i.e. the one for the REST endpoint GET method, two for the {{helloAsync}} calls and one for the fallback.
> [1]
> https://github.com/rhoar-qe/thorntail-test-suite/tree/master/microprofile...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13771) Create a Galleon layers for the messaging subsystem
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13771?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13771:
------------------------------------
Fix Version/s: (was: 21.0.0.Beta1)
> Create a Galleon layers for the messaging subsystem
> ---------------------------------------------------
>
> Key: WFLY-13771
> URL: https://issues.redhat.com/browse/WFLY-13771
> Project: WildFly
> Issue Type: Feature Request
> Components: Build System, JMS
> Reporter: Yeray Borges Santana
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> We have three possible messaging-activemq configuration options that should be supplied via Galleon layers:
> # messaging-activemq subsystem configuration ready to be used as an Embedded broker. This configuration is useful to run quick demos only, it should not be used in production environments or cloud environments.
> # messaging-activemq subsystem configuration ready to be used with an external broker.
> # An empty messaging-activemq subsystem configuration and capabilities to deploy a Resource Adapter file to connect to an external broker. This .rar file has to be deployed by the user.
> The existing jms-activemq layer was meant to allow client-side JMS, it is almost covering the third option, however, the user should be able to deploy .rar files. The analysis document should clarify whether these capabilities should be included in a Galleon layer itself or by contrast, users should add the resource-adapters Galleon layer to provide it.
> Another point to clear up is if the Galleon layers will supply capabilities to invoke remote objects configured in the WildFly JNDI tree, hence the need for remoting naming.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13412) Add Json Merge Patch support
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13412?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13412:
------------------------------------
Fix Version/s: 22.0.0.Beta1
(was: 21.0.0.Beta1)
> Add Json Merge Patch support
> ----------------------------
>
> Key: WFLY-13412
> URL: https://issues.redhat.com/browse/WFLY-13412
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Affects Versions: 19.0.0.Final
> Reporter: Jim Ma
> Assignee: Jim Ma
> Priority: Major
> Fix For: 22.0.0.Beta1
>
>
> This feature request for add json merge patch support and provide configuration to disable Resteasy PatchMethodFilter and allow user to configure customized PathMethodFilter to handle json patch request.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-8136) Allow JAX-RS annotations in CDI @Stereotype
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-8136?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-8136:
-----------------------------------
Fix Version/s: 22.0.0.Beta1
(was: 21.0.0.Beta1)
> Allow JAX-RS annotations in CDI @Stereotype
> -------------------------------------------
>
> Key: WFLY-8136
> URL: https://issues.redhat.com/browse/WFLY-8136
> Project: WildFly
> Issue Type: Feature Request
> Components: CDI / Weld, REST
> Affects Versions: 9.0.1.Final, 15.0.0.Final
> Environment: Windows 7, JDK 1.8.0_60
> Reporter: Andreas Klemp
> Assignee: Martin Stefanko
> Priority: Major
> Fix For: 22.0.0.Beta1
>
>
> A simple JAX-RS REST service can be annotated with @Produces to define the resulting mime-type. However, it is not working anymore, when the annotation is moved to a stereotype. The default application/octet-stream is used.
> {code}
> @Stereotype
> @Produces(MediaType.APPLICATION_JSON)
> @Target(ElementType.TYPE)
> @Retention(RetentionPolicy.RUNTIME)
> public @interface RestService {
> }
> @Path("/some")
> @RestService
> public class SomeRestService {
> @GET
> @Path("/")
> public Response getSome() {
> return Response.ok().entity("{\"x\" : 42, \"y\" : \"foo\"}").build();
> }
> }
> {code}
> Using the following dependencies in Gradle project.
> {noformat}
> providedCompile(
> [group: 'javax.enterprise', name: 'cdi-api', version: '1.2'],
> [group: 'org.jboss.spec.javax.ws.rs', name: 'jboss-jaxrs-api_2.0_spec', version: '1.0.0.Final'],
> [group: 'com.fasterxml.jackson.core', name: 'jackson-databind', version: '2.7.4']
> )
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-6892) Access logging for EJBs
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-6892?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-6892:
-----------------------------------
Fix Version/s: 22.0.0.Beta1
(was: 21.0.0.Beta1)
> Access logging for EJBs
> -----------------------
>
> Key: WFLY-6892
> URL: https://issues.redhat.com/browse/WFLY-6892
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Cheng Fang
> Priority: Major
> Labels: affects-model, affects_elytron
> Fix For: 22.0.0.Beta1
>
>
> Access logging for EJB requests similar to Web access logging would be very useful.
> Possibly something like:
> {code}
> [date-time] [host/IP of caller] [EJB Name] [EJB Method] [invocation id] Request Received ...
> [date-time] [host/IP of caller] [EJB Name] [EJB Method] invocation id] Starting Invocation ...
> [date-time] [host/IP of caller] [EJB Name] [EJB Method] invocation id] Finished Invocation ...
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-11943) Statistics of REST endpoints
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-11943?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-11943:
------------------------------------
Fix Version/s: 22.0.0.Beta1
(was: 21.0.0.Beta1)
> Statistics of REST endpoints
> ----------------------------
>
> Key: WFLY-11943
> URL: https://issues.redhat.com/browse/WFLY-11943
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Affects Versions: 17.0.0.Final
> Reporter: r searls
> Assignee: r searls
> Priority: Major
> Labels: affects-model
> Fix For: 22.0.0.Beta1
>
>
> Provide statistics on REST endpoints in the jaxrs subsystem.
> CLI support "read-resource" operation for jax-rs subsystem in deployment:
> /deployment=jaxrs-eap.war/subsystem=jaxrs:read-resource
> Statistics should be added to results of this operation in this RFE.
> There needs to be option to enable or disable collecting of these statistics, because collecting of statistics does probably some performance drop.
> The change of statistic settings should not require server reload or restart.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13150) Add a Galleon layer for the distributable web subsystem configured with a local web cache
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13150?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13150:
------------------------------------
Fix Version/s: 22.0.0.Beta1
(was: 21.0.0.Beta1)
> Add a Galleon layer for the distributable web subsystem configured with a local web cache
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-13150
> URL: https://issues.redhat.com/browse/WFLY-13150
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Web (Undertow)
> Reporter: Brian Stansberry
> Assignee: Yeray Borges Santana
> Priority: Major
> Fix For: 22.0.0.Beta1
>
>
> We have a web-clustering layer that provides the distributable-web subsystem and the related infinispan web session caching resources, configured for multi-server distributed sessions.
> We need a variant of this with infinispan configured for local caching.
> The WFLY-13099 standalone-microprofile.xml config should have this kind of setup; otherwise session sharing does not work . (A failure in org.jboss.as.test.clustering.cluster.web.shared.SharedSessionTestCase if the server uses a config without it shows this.) For WFLY-13099 I can work around this by adding the needed config stuff without a layer, but as everything else needed for those configs are from layers, it's better to use a layer in WF 20.
> Besides it's a good layer to have anyway. :)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (DROOLS-5650) UnsupportedOperationException when using enum in Java 11, works fine in Java 8
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5650?page=com.atlassian.jira.plug... ]
Mario Fusco resolved DROOLS-5650.
---------------------------------
Resolution: Rejected
> UnsupportedOperationException when using enum in Java 11, works fine in Java 8
> ------------------------------------------------------------------------------
>
> Key: DROOLS-5650
> URL: https://issues.redhat.com/browse/DROOLS-5650
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.43.1.Final
> Reporter: Abhi Vuyyuru
> Assignee: Mario Fusco
> Priority: Major
> Attachments: AuditVO.java, Driver.java, ExamplePolicyPricing.xls, Policy.java
>
>
> I am porting an existing application Java 7 to Java 11 (Drools 7.42.0). The application works as expected if I compile as Java 1.8 and deploy on Java 11 container (Weblogic 14). But if I compile the same code in Java 11, I get the following error. The only change between 1.8 and 11 is the java compiler level in Maven pom. I have ASM7 as a dependency in Maven.
> {{}}
>
> {{{{Caused by: java.lang.UnsupportedOperationException: This feature requires ASM7
> at org.mvel2.asm.ClassVisitor.visitNestMember(ClassVisitor.java:236)
> at org.mvel2.asm.ClassReader.accept(ClassReader.java:651)
> at org.mvel2.asm.ClassReader.accept(ClassReader.java:391)
> at org.drools.core.util.asm.ClassFieldInspector.processClassWithByteCode(ClassFieldInspector.java:107)
> at org.drools.core.util.asm.ClassFieldInspector.processClassWithByteCode(ClassFieldInspector.java:114)
> at org.drools.core.util.asm.ClassFieldInspector.<init>(ClassFieldInspector.java:86)
> at org.drools.core.util.asm.ClassFieldInspector.<init>(ClassFieldInspector.java:74)
> at org.drools.core.base.ClassFieldAccessorFactory.getClassFieldInspector(ClassFieldAccessorFactory.java:157)
> at org.drools.core.base.ClassFieldAccessorFactory.getFieldType(ClassFieldAccessorFactory.java:141)
> at org.drools.core.base.ClassFieldAccessorStore.getFieldType(ClassFieldAccessorStore.java:295)
> at org.drools.compiler.rule.builder.PatternBuilder.getValueType(PatternBuilder.java:1079)
> at org.drools.compiler.rule.builder.PatternBuilder.normalizeExpression(PatternBuilder.java:1047)
> at org.drools.compiler.rule.builder.PatternBuilder.buildExpression(PatternBuilder.java:965)
> at org.drools.compiler.rule.builder.PatternBuilder.buildCcdDescr(PatternBuilder.java:942)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:767)
> at org.drools.compiler.rule.builder.PatternBuilder.processConstraintsAndBinds(PatternBuilder.java:620)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:187)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:154)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:136)
> at org.drools.compiler.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:66)
> at org.drools.compiler.rule.builder.RuleBuilder.build(RuleBuilder.java:107)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.internalAddRule(KnowledgeBuilderImpl.java:1183)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addRule(KnowledgeBuilderImpl.java:1178)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.lambda$null$3(KnowledgeBuilderImpl.java:1134)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
> at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
> at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746)}}}}
>
> I noticed while debugging that this was caused by an "enum" in our code. Drools works fine if we remove the enum and use constants. The error seems to suggest that this could happen to any nested classes. Is there a better way to handle this other than changing our code to remove nested classes and enums?
> I see that in the class {{org.drools.core.util.asm.ClassFieldInspector}}, the API is set to ASM5, but MVEL is expecting ASM7. But not sure why it would work in Java 8 and not in Java 11. Any suggestions?
>
> {{ClassFieldVisitor(final Class< ? > cls,
> final boolean includeFinalMethods,
> final ClassFieldInspector inspector) \{
> super(Opcodes.ASM5);
> this.clazz = cls;
> this.includeFinalMethods = includeFinalMethods;
> this.inspector = inspector;
> }}}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (DROOLS-5650) UnsupportedOperationException when using enum in Java 11, works fine in Java 8
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5650?page=com.atlassian.jira.plug... ]
Mario Fusco commented on DROOLS-5650:
-------------------------------------
If the problem happens only inside weblogic I don't know what to do about it. We don't support it.
> UnsupportedOperationException when using enum in Java 11, works fine in Java 8
> ------------------------------------------------------------------------------
>
> Key: DROOLS-5650
> URL: https://issues.redhat.com/browse/DROOLS-5650
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.43.1.Final
> Reporter: Abhi Vuyyuru
> Assignee: Mario Fusco
> Priority: Major
> Attachments: AuditVO.java, Driver.java, ExamplePolicyPricing.xls, Policy.java
>
>
> I am porting an existing application Java 7 to Java 11 (Drools 7.42.0). The application works as expected if I compile as Java 1.8 and deploy on Java 11 container (Weblogic 14). But if I compile the same code in Java 11, I get the following error. The only change between 1.8 and 11 is the java compiler level in Maven pom. I have ASM7 as a dependency in Maven.
> {{}}
>
> {{{{Caused by: java.lang.UnsupportedOperationException: This feature requires ASM7
> at org.mvel2.asm.ClassVisitor.visitNestMember(ClassVisitor.java:236)
> at org.mvel2.asm.ClassReader.accept(ClassReader.java:651)
> at org.mvel2.asm.ClassReader.accept(ClassReader.java:391)
> at org.drools.core.util.asm.ClassFieldInspector.processClassWithByteCode(ClassFieldInspector.java:107)
> at org.drools.core.util.asm.ClassFieldInspector.processClassWithByteCode(ClassFieldInspector.java:114)
> at org.drools.core.util.asm.ClassFieldInspector.<init>(ClassFieldInspector.java:86)
> at org.drools.core.util.asm.ClassFieldInspector.<init>(ClassFieldInspector.java:74)
> at org.drools.core.base.ClassFieldAccessorFactory.getClassFieldInspector(ClassFieldAccessorFactory.java:157)
> at org.drools.core.base.ClassFieldAccessorFactory.getFieldType(ClassFieldAccessorFactory.java:141)
> at org.drools.core.base.ClassFieldAccessorStore.getFieldType(ClassFieldAccessorStore.java:295)
> at org.drools.compiler.rule.builder.PatternBuilder.getValueType(PatternBuilder.java:1079)
> at org.drools.compiler.rule.builder.PatternBuilder.normalizeExpression(PatternBuilder.java:1047)
> at org.drools.compiler.rule.builder.PatternBuilder.buildExpression(PatternBuilder.java:965)
> at org.drools.compiler.rule.builder.PatternBuilder.buildCcdDescr(PatternBuilder.java:942)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:767)
> at org.drools.compiler.rule.builder.PatternBuilder.processConstraintsAndBinds(PatternBuilder.java:620)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:187)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:154)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:136)
> at org.drools.compiler.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:66)
> at org.drools.compiler.rule.builder.RuleBuilder.build(RuleBuilder.java:107)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.internalAddRule(KnowledgeBuilderImpl.java:1183)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addRule(KnowledgeBuilderImpl.java:1178)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.lambda$null$3(KnowledgeBuilderImpl.java:1134)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
> at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
> at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746)}}}}
>
> I noticed while debugging that this was caused by an "enum" in our code. Drools works fine if we remove the enum and use constants. The error seems to suggest that this could happen to any nested classes. Is there a better way to handle this other than changing our code to remove nested classes and enums?
> I see that in the class {{org.drools.core.util.asm.ClassFieldInspector}}, the API is set to ASM5, but MVEL is expecting ASM7. But not sure why it would work in Java 8 and not in Java 11. Any suggestions?
>
> {{ClassFieldVisitor(final Class< ? > cls,
> final boolean includeFinalMethods,
> final ClassFieldInspector inspector) \{
> super(Opcodes.ASM5);
> this.clazz = cls;
> this.includeFinalMethods = includeFinalMethods;
> this.inspector = inspector;
> }}}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months