[JBoss JIRA] (WFLY-11629) Transaction service isn't available when dynamically adding transactional annotation
by Ondra Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-11629?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka commented on WFLY-11629:
----------------------------------------
[~juagonza] I see your point. First I would argue that by deploying to different containers you need to apply some of their habits. The class loading in WildFly is based on modules. If you mind changing the {{META-INF}} you can still use the descriptor {{jboss-deployment-structure.xml}} to get the same.
I understand the argument that same example works for Paraya. From the implementation perspective I don't like the need of adding the JTS modules to dependency even if it's not necessary.
By me the benefit of current behaviour is that the dependency is not forced up to time it's needed by the application (which declares {{@Transactional}} annotation). I think there are still some trade-offs which need to be done.
For sure this behaviour should be documented.
> Transaction service isn't available when dynamically adding transactional annotation
> ------------------------------------------------------------------------------------
>
> Key: WFLY-11629
> URL: https://issues.jboss.org/browse/WFLY-11629
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 15.0.1.Final
> Reporter: Juan Gonzalez
> Assignee: Ondra Chaloupka
> Priority: Major
> Attachments: wildfly_dynamic_tx_reproducer.zip
>
>
> When adding dynamically a transactional annotation, transactional module isn't loaded, so transactions aren't available and throws this error:
> {noformat}
> javax.persistence.TransactionRequiredException: WFLYJPA0060: Transaction is required to perform this operation (either use a transaction or extended persistence context)
> {noformat}
> I've attached a reproducer with a test in order to reproduce this. There you can see that there is a CDI producer that dynamically adds the annotation for transactions, that doesn't work.
> [~mkouba] found this could be an optimization for not loading JTS module: https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java...
> In order to execute tests:
> mvn clean test
> To execute test, passing in Payara:
> mvn clean test -Ppayara
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11629) Transaction service isn't available when dynamically adding transactional annotation
by Juan Gonzalez (Jira)
[ https://issues.jboss.org/browse/WFLY-11629?page=com.atlassian.jira.plugin... ]
Juan Gonzalez commented on WFLY-11629:
--------------------------------------
[~ochaloup] Payara server for example works perfectly fine. I know this behavior is on the edge of what should or not should be, but the workaround you said is very server-dependent and Java EE was made exactly to avoid these kind of things. I think users shouldn't be affected or even know this is an optimization and make this workaround themselves.
And about real world, yeah as I mentioned is not common use CDI to add dynamic annotations like this, but it is used in somehow "famous" Java EE 8 samples here: https://github.com/javaee-samples/javaee8-samples/tree/master/jpa/dynamic-tx, which is a repository gathering Java EE 8 examples to show new features.
> Transaction service isn't available when dynamically adding transactional annotation
> ------------------------------------------------------------------------------------
>
> Key: WFLY-11629
> URL: https://issues.jboss.org/browse/WFLY-11629
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 15.0.1.Final
> Reporter: Juan Gonzalez
> Assignee: Ondra Chaloupka
> Priority: Major
> Attachments: wildfly_dynamic_tx_reproducer.zip
>
>
> When adding dynamically a transactional annotation, transactional module isn't loaded, so transactions aren't available and throws this error:
> {noformat}
> javax.persistence.TransactionRequiredException: WFLYJPA0060: Transaction is required to perform this operation (either use a transaction or extended persistence context)
> {noformat}
> I've attached a reproducer with a test in order to reproduce this. There you can see that there is a CDI producer that dynamically adds the annotation for transactions, that doesn't work.
> [~mkouba] found this could be an optimization for not loading JTS module: https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java...
> In order to execute tests:
> mvn clean test
> To execute test, passing in Payara:
> mvn clean test -Ppayara
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11629) Transaction service isn't available when dynamically adding transactional annotation
by Ondra Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-11629?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka commented on WFLY-11629:
----------------------------------------
after follow-up discussion with [~mkouba] I think the current behaviour should be left as it is. I would say that if user wants to use the transactions and adding the annotations in fully programmatic way he is free to add the dependency to the {{org.jboss.jts}} module manually.
In your reproducer add this to the {{@Deployment}} (https://docs.jboss.org/author/display/WFLY/Class+Loading+in+WildFly)
{code}
.setManifest(new StringAsset("Manifest-Version: 1.0\nDependencies: org.jboss.jts export services"));
{code}
On top of that in real world application I think it's quite doubtful if there will be used only programmatic approach with no annotation involved in the code.
Is there some serious objection against closing this one?
> Transaction service isn't available when dynamically adding transactional annotation
> ------------------------------------------------------------------------------------
>
> Key: WFLY-11629
> URL: https://issues.jboss.org/browse/WFLY-11629
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 15.0.1.Final
> Reporter: Juan Gonzalez
> Assignee: Ondra Chaloupka
> Priority: Major
> Attachments: wildfly_dynamic_tx_reproducer.zip
>
>
> When adding dynamically a transactional annotation, transactional module isn't loaded, so transactions aren't available and throws this error:
> {noformat}
> javax.persistence.TransactionRequiredException: WFLYJPA0060: Transaction is required to perform this operation (either use a transaction or extended persistence context)
> {noformat}
> I've attached a reproducer with a test in order to reproduce this. There you can see that there is a CDI producer that dynamically adds the annotation for transactions, that doesn't work.
> [~mkouba] found this could be an optimization for not loading JTS module: https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java...
> In order to execute tests:
> mvn clean test
> To execute test, passing in Payara:
> mvn clean test -Ppayara
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11629) Transaction service isn't available when dynamically adding transactional annotation
by Ondra Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-11629?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka edited comment on WFLY-11629 at 2/5/19 3:23 AM:
----------------------------------------------------------------
Agree, it's because of the optimization for not loading JTS when {{@Transactional}} annotation is not defined.
was (Author: ochaloup):
Agree, it's because of the optimization for not loading JTS when {{@Transactional}} annotation is not defined.
[~juagonza] may I take your reproducer and use it as base for the test which will be added under WFLY integration testsuite? Or this code should not be used for that? Thanks.
> Transaction service isn't available when dynamically adding transactional annotation
> ------------------------------------------------------------------------------------
>
> Key: WFLY-11629
> URL: https://issues.jboss.org/browse/WFLY-11629
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 15.0.1.Final
> Reporter: Juan Gonzalez
> Assignee: Ondra Chaloupka
> Priority: Major
> Attachments: wildfly_dynamic_tx_reproducer.zip
>
>
> When adding dynamically a transactional annotation, transactional module isn't loaded, so transactions aren't available and throws this error:
> {noformat}
> javax.persistence.TransactionRequiredException: WFLYJPA0060: Transaction is required to perform this operation (either use a transaction or extended persistence context)
> {noformat}
> I've attached a reproducer with a test in order to reproduce this. There you can see that there is a CDI producer that dynamically adds the annotation for transactions, that doesn't work.
> [~mkouba] found this could be an optimization for not loading JTS module: https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java...
> In order to execute tests:
> mvn clean test
> To execute test, passing in Payara:
> mvn clean test -Ppayara
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11629) Transaction service isn't available when dynamically adding transactional annotation
by Ondra Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-11629?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka commented on WFLY-11629:
----------------------------------------
Agree, it's because of the optimization for not loading JTS when {{@Transactional}} annotation is not defined.
[~juagonza] may I take your reproducer and use it as base for the test which will be added under WFLY integration testsuite? Or this code should not be used for that? Thanks.
> Transaction service isn't available when dynamically adding transactional annotation
> ------------------------------------------------------------------------------------
>
> Key: WFLY-11629
> URL: https://issues.jboss.org/browse/WFLY-11629
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 15.0.1.Final
> Reporter: Juan Gonzalez
> Assignee: Ondra Chaloupka
> Priority: Major
> Attachments: wildfly_dynamic_tx_reproducer.zip
>
>
> When adding dynamically a transactional annotation, transactional module isn't loaded, so transactions aren't available and throws this error:
> {noformat}
> javax.persistence.TransactionRequiredException: WFLYJPA0060: Transaction is required to perform this operation (either use a transaction or extended persistence context)
> {noformat}
> I've attached a reproducer with a test in order to reproduce this. There you can see that there is a CDI producer that dynamically adds the annotation for transactions, that doesn't work.
> [~mkouba] found this could be an optimization for not loading JTS module: https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java...
> In order to execute tests:
> mvn clean test
> To execute test, passing in Payara:
> mvn clean test -Ppayara
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (DROOLS-3558) "NoSuchElementException: No value present" with executable-model, Map and binding
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-3558?page=com.atlassian.jira.plugi... ]
Mario Fusco reassigned DROOLS-3558:
-----------------------------------
Assignee: Luca Molteni (was: Mario Fusco)
> "NoSuchElementException: No value present" with executable-model, Map and binding
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-3558
> URL: https://issues.jboss.org/browse/DROOLS-3558
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.16.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Luca Molteni
> Priority: Major
> Labels: support
>
> When compiling a below rule with executable-model:
> {noformat}
> rule R1
> when
> $p : Person()
> $a : Address(number == $p.items[1])
> then
> end
> {noformat}
> it fails with the following error:
> {noformat}
> [ERROR] Tests run: 165, Failures: 0, Errors: 2, Skipped: 3, Time elapsed: 20.794 s <<< FAILURE! - in org.drools.modelcompiler.CompilerTest
> [ERROR] testMapWithBinding[FLOW_DSL](org.drools.modelcompiler.CompilerTest) Time elapsed: 0.02 s <<< ERROR!
> java.util.NoSuchElementException: No value present
> at java.util.Optional.get(Optional.java:135)
> at org.drools.modelcompiler.builder.generator.expressiontyper.ExpressionTyper.toTypedExpressionFromMethodCallOrField(ExpressionTyper.java:397)
> at org.drools.modelcompiler.builder.generator.expressiontyper.ExpressionTyper.toTypedExpressionRec(ExpressionTyper.java:211)
> at org.drools.modelcompiler.builder.generator.expressiontyper.ExpressionTyper.toTypedExpression(ExpressionTyper.java:108)
> at org.drools.modelcompiler.builder.generator.drlxparse.ConstraintParser.parseBinaryExpr(ConstraintParser.java:295)
> at org.drools.modelcompiler.builder.generator.drlxparse.ConstraintParser.getDrlxParseResult(ConstraintParser.java:111)
> at org.drools.modelcompiler.builder.generator.drlxparse.ConstraintParser.drlxParse(ConstraintParser.java:78)
> at org.drools.modelcompiler.builder.generator.visitor.pattern.PatternDSL.findAllConstraint(PatternDSL.java:124)
> at org.drools.modelcompiler.builder.generator.visitor.pattern.PatternDSL.buildPattern(PatternDSL.java:191)
> at org.drools.modelcompiler.builder.generator.visitor.ModelGeneratorVisitor.visit(ModelGeneratorVisitor.java:128)
> at org.drools.compiler.lang.descr.PatternDescr.accept(PatternDescr.java:267)
> at org.drools.modelcompiler.builder.generator.visitor.AndVisitor.visit(AndVisitor.java:29)
> at org.drools.modelcompiler.builder.generator.visitor.ModelGeneratorVisitor.visit(ModelGeneratorVisitor.java:69)
> at org.drools.modelcompiler.builder.generator.ModelGenerator.processRule(ModelGenerator.java:174)
> at org.drools.modelcompiler.builder.generator.ModelGenerator.generateModel(ModelGenerator.java:154)
> at org.drools.modelcompiler.builder.ModelBuilderImpl.compileKnowledgePackages(ModelBuilderImpl.java:144)
> at org.drools.modelcompiler.builder.ModelBuilderImpl.buildRules(ModelBuilderImpl.java:94)
> at org.drools.modelcompiler.builder.ModelBuilderImpl.buildPackages(ModelBuilderImpl.java:63)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:108)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:100)
> at org.drools.compiler.kie.builder.impl.AbstractKieProject.buildKnowledgePackages(AbstractKieProject.java:257)
> at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:74)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:267)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:235)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:204)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:192)
> at org.drools.modelcompiler.BaseModelTest.createKieBuilder(BaseModelTest.java:142)
> at org.drools.modelcompiler.BaseModelTest.createKieBuilder(BaseModelTest.java:125)
> at org.drools.modelcompiler.BaseModelTest.getKieContainer(BaseModelTest.java:114)
> at org.drools.modelcompiler.BaseModelTest.getKieContainer(BaseModelTest.java:107)
> at org.drools.modelcompiler.BaseModelTest.getKieSession(BaseModelTest.java:103)
> at org.drools.modelcompiler.BaseModelTest.getKieSession(BaseModelTest.java:99)
> at org.drools.modelcompiler.CompilerTest.testMapWithBinding(CompilerTest.java:1457)
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11671) java.lang.ArrayIndexOutOfBoundsException: 76 at org.jboss.logmanager.JDKSpecific.calculateCaller(JDKSpecific.java:112)
by Manuel Blechschmidt (Jira)
Manuel Blechschmidt created WFLY-11671:
------------------------------------------
Summary: java.lang.ArrayIndexOutOfBoundsException: 76 at org.jboss.logmanager.JDKSpecific.calculateCaller(JDKSpecific.java:112)
Key: WFLY-11671
URL: https://issues.jboss.org/browse/WFLY-11671
Project: WildFly
Issue Type: Bug
Components: Logging
Affects Versions: 15.0.1.Final, 14.0.1.Final
Environment: $ uname -ar
Linux manuel-XPS-13-9360 4.15.0-43-generic #46-Ubuntu SMP Thu Dec 6 14:45:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ java -version
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-8u191-b12-0ubuntu0.18.04.1-b12)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)
$ ./jboss-cli.sh --version
JBoss Admin Command-line Interface
JBOSS_HOME: /home/manuel/wildfly-15.0.1.Final
Release: <connect to the controller and re-run the version command to see the release info>
JAVA_HOME: null
java.version: 1.8.0_191
java.vm.vendor: Oracle Corporation
java.vm.version: 25.191-b12
os.name: Linux
os.version: 4.15.0-43-generic
Maybe another bug, the server was running in JBoss Developer Studio when I executed jboss-cli
Reporter: Manuel Blechschmidt
Assignee: James Perkins
We are collecting Logs in a CDI RequestScoped bean. Afterwards we have a JAX RS filter that attaches these logs in the HTTP Warnings Header. In wildfly 12 is works great in wildfly 14 & 15 the following error happens:
{code}
08:17:16,856 WARNING [de.example.logging.cdi.HttpWarningsHeaderFilter] (default task-1) Problem during formatting warning: java.lang.ArrayIndexOutOfBoundsException: 76
at org.jboss.logmanager.JDKSpecific.calculateCaller(JDKSpecific.java:112)
at org.jboss.logmanager.ExtLogRecord.calculateCaller(ExtLogRecord.java:335)
at org.jboss.logmanager.ExtLogRecord.getSourceClassName(ExtLogRecord.java:399)
at java.util.logging.SimpleFormatter.format(SimpleFormatter.java:143)
at de.example.logging.cdi.HttpWarningsHeaderFilter.lambda$1(HttpWarningsHeaderFilter.java:34)
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.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
at de.example.logging.cdi.HttpWarningsHeaderFilter.filter(HttpWarningsHeaderFilter.java:39)
at de.example.logging.cdi.HttpWarningsHeaderFilter$Proxy$_$$_WeldClientProxy.filter(Unknown Source)
at org.jboss.resteasy.core.interception.ContainerResponseContextImpl.filter(ContainerResponseContextImpl.java:356)
at org.jboss.resteasy.core.ServerResponseWriter.executeFilters(ServerResponseWriter.java:205)
at org.jboss.resteasy.core.ServerResponseWriter.writeNomapResponse(ServerResponseWriter.java:82)
at org.jboss.resteasy.core.ServerResponseWriter.writeNomapResponse(ServerResponseWriter.java:56)
at org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:528)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:459)
at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
{code}
{code}
package de.example.logging.cdi;
import java.io.IOException;
import java.util.List;
import java.util.logging.Formatter;
import java.util.logging.Level;
import java.util.logging.Logger;
import java.util.logging.SimpleFormatter;
import java.util.stream.Collectors;
import javax.inject.Inject;
import javax.ws.rs.container.ContainerRequestContext;
import javax.ws.rs.container.ContainerResponseContext;
import javax.ws.rs.container.ContainerResponseFilter;
import javax.ws.rs.ext.Provider;
@Provider
public class HttpWarningsHeaderFilter implements ContainerResponseFilter {
private static Logger log = Logger.getLogger(HttpWarningsHeaderFilter.class.getName());
private static final Formatter simpleFormatter = new SimpleFormatter();
@Inject
Logs logs;
@Override
public void filter(ContainerRequestContext requestContext, ContainerResponseContext responseContext)
throws IOException {
List<String> logStrings = logs.getLogRecords().stream()
// only output INFO or more important warnings (SERVERE, WARNING)
.filter(lr -> lr.getLevel().intValue() >= Level.INFO.intValue()).map(lr -> {
try {
return simpleFormatter.format(lr);
} catch (Exception e) {
log.log(Level.WARNING, "Problem during formatting warning", e);
return lr.getMessage();
}
}).collect(Collectors.toList());
responseContext.getHeaders().add("Warnings", logStrings);
}
}
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months