[JBoss JIRA] (WFLY-6935) CMTTxInterceptor transaction comparison
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-6935?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski commented on WFLY-6935:
--------------------------------------
In CMTTxInterceptor#endTransaction method:
{code}
if (tx != tm.getTransaction()) {
throw EjbLogger.ROOT_LOGGER.wrongTxOnThread(tx, tm.getTransaction());
}
{code}
We could not compare transaction objects using == opeator as there is no guarantee that the objects will be the same if they represent the same transaction. Specifically if the transaction is canceled because of timeout but it stays associated with the tread the transaction manager will create the new transaction object when the TransactionManager#getTransaction method is called. We should use equals operator instead.
> CMTTxInterceptor transaction comparison
> ---------------------------------------
>
> Key: WFLY-6935
> URL: https://issues.jboss.org/browse/WFLY-6935
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.CR1
> Reporter: Tomasz Adamski
> Assignee: Tomasz Adamski
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1164) Warning about private module use issued twice
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1164?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration updated WFCORE-1164:
--------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1365668
Bugzilla Update: Perform
> Warning about private module use issued twice
> ---------------------------------------------
>
> Key: WFCORE-1164
> URL: https://issues.jboss.org/browse/WFCORE-1164
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Frank Langelage
> Assignee: Stuart Douglas
> Priority: Minor
> Fix For: 2.0.4.Final
>
> Attachments: test.war
>
>
> My web app is using some modules of WildFly AS which are not public.
> The warning about using private modules is issued twice for every module:
> 09.11. 22:07:34,088 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.jboss.common-core:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,090 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.jboss.common-core:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,091 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,091 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,092 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,094 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1164) Warning about private module use issued twice
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1164?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1164:
-------------------------------------------------
Aaron Ogburn <aogburn(a)redhat.com> changed the Status of [bug 1365668|https://bugzilla.redhat.com/show_bug.cgi?id=1365668] from NEW to ASSIGNED
> Warning about private module use issued twice
> ---------------------------------------------
>
> Key: WFCORE-1164
> URL: https://issues.jboss.org/browse/WFCORE-1164
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Frank Langelage
> Assignee: Stuart Douglas
> Priority: Minor
> Fix For: 2.0.4.Final
>
> Attachments: test.war
>
>
> My web app is using some modules of WildFly AS which are not public.
> The warning about using private modules is issued twice for every module:
> 09.11. 22:07:34,088 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.jboss.common-core:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,090 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.jboss.common-core:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,091 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,091 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,092 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,094 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1686) Standalone server logs FATAL message on --help
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1686?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1686:
------------------------------------------
For a good fix for this we need to distinguish the true failure cases that cause determineEnvironment to return null from the non-failure cases like --help. That should probably be handled in determineEnvironment itself, which would mean changing its return type.
I wouldn't be surprised if a host controller has a similar problem, although I haven't investigated.
> Standalone server logs FATAL message on --help
> ----------------------------------------------
>
> Key: WFCORE-1686
> URL: https://issues.jboss.org/browse/WFCORE-1686
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 3.0.0.Alpha4
> Reporter: Petr Kremensky
> Assignee: Jason Greene
> Attachments: WFCORE-1686.patch
>
>
> {noformat}
> 15:07:56,793 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
> {noformat}
> appears at the end of help for standalone server.
> *reproduce*
> {noformat}
> bash standalone.sh --help
> {noformat}
> The issues is a regression against 7.0.0
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1686) Standalone server logs FATAL message on --help
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1686?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1686:
------------------------------------------
That doesn't look right. An ExitLogger should not be calling System.exit(), it should only do logging.
> Standalone server logs FATAL message on --help
> ----------------------------------------------
>
> Key: WFCORE-1686
> URL: https://issues.jboss.org/browse/WFCORE-1686
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 3.0.0.Alpha4
> Reporter: Petr Kremensky
> Assignee: Jason Greene
> Attachments: WFCORE-1686.patch
>
>
> {noformat}
> 15:07:56,793 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
> {noformat}
> appears at the end of help for standalone server.
> *reproduce*
> {noformat}
> bash standalone.sh --help
> {noformat}
> The issues is a regression against 7.0.0
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1703) It is not possible to set jboss.modules.system.pkgs per server in domain mode
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1703?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1703:
------------------------------------------
Both the domain.xml server-group and host.xml server elements have "system-properties" child elements, which are the intended mechanism for setting system properties on the servers. Does using that mechanism take care of your issue?
> It is not possible to set jboss.modules.system.pkgs per server in domain mode
> -----------------------------------------------------------------------------
>
> Key: WFCORE-1703
> URL: https://issues.jboss.org/browse/WFCORE-1703
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.2.0.Final
> Reporter: Bogdan Ilchyshyn
> Priority: Minor
>
> It is not possible to set {{jboss.modules.system.pkgs}} property per server / server group in domain configuration. Even when the following configuration is added to {{host.xml}}:
> {code:xml}
> <server name="server-one" group="main-server-group">
> <jvm name="default">
> <jvm-options>
> <option value="-Djboss.modules.system.pkgs=my.package"/>
> ...
> {code}
> It is overridden by configuration in {{domain.conf}}:
> {noformat}
> JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true"
> {noformat}
> This is an issue for configuring third-party java agents per-server. A problem described in WFLY-895 adds to this. One should either add a whole bunch of things to _all_ jvms in domain in order to make agent work, or remove config from {{domain.conf}} to avoid overrides.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-1235) MBean naming rework
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1235?page=com.atlassian.jira.plugi... ]
Matteo Mortari edited comment on DROOLS-1235 at 8/9/16 12:12 PM:
-----------------------------------------------------------------
To recap:
h6. droolsjbpm-knowledge
* Perform necessary Public KIE API changes for allowing API users to
specify an optional, unique, container ID.
h6. drools
* give KieContainer an optional user defined name
* KieContainer MBean and various refactorings.
* jargon: containerId
* jargon: configuredReleaseId, resolvedReleaseId
* unit testing
* assuming the containerId can be "recycled" on dispose.
* introducing test for KieServices API with containerId.
* avoid using lock and leverage ConcurrentMap without java8
* fixing objectname conventions
* there are a few call to internal api / manual call to the implementation
constructor new KieContainerImpl from kie-wb-common, optaplanner, etc.
Original constructor marked with deprecation flag and javadoc notice on all constructors.
h6. droolsjbpm-integration
* KieServer cascade containerId while creating via KieServices
h6. kie-docs
* Including an entry for this on the release notes, as requested.
was (Author: tari_manga):
To recap:
h6. droolsjbpm-knowledge
* Perform necessary Public KIE API changes for allowing API users to
specify an optional, unique, container ID.
h6. drools
* give KieContainer an optional user defined name
* KieContainer MBean and various refactorings.
* jargon: containerId
* jargon: configuredReleaseId, resolvedReleaseId
* unit testing
* assuming the containerId can be "recycled" on dispose.
* introducing test for KieServices API with containerId.
* fixing other tests.
* avoid using lock and leverage ConcurrentMap without java8
* fixing objectname conventions
h6. droolsjbpm-integration
* KieServer cascade containerId while creating via KieServices
h6. kie-docs
* Including an entry for this on the release notes, as requested.
h6. kie-wb-common
* reflecting internal api / implementation of KieContainerImpl constructor change, requiring a container Id (normally a new KieContainerImpl is called via KieServices so transparently, but in this case is explicitly required manual management).
> MBean naming rework
> -------------------
>
> Key: DROOLS-1235
> URL: https://issues.jboss.org/browse/DROOLS-1235
> Project: Drools
> Issue Type: Sub-task
> Components: core engine, kie server
> Affects Versions: 6.4.0.Final
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Fix For: 6.5.0.Final, 7.0.0.Final
>
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-1175) Accumulates: sum(Long), sum(BigDecimal), sum(Integer) and sum(BigInteger)
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1175?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet commented on DROOLS-1175:
------------------------------------------
Changes pushed on OptaPlanner (including all examples, upgrade recipe, training, docs) to take advantage of this and also the shorter accumulate syntax.
> Accumulates: sum(Long), sum(BigDecimal), sum(Integer) and sum(BigInteger)
> -------------------------------------------------------------------------
>
> Key: DROOLS-1175
> URL: https://issues.jboss.org/browse/DROOLS-1175
> Project: Drools
> Issue Type: Feature Request
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
> Fix For: 7.0.0.Beta2
>
>
> Currently, when summing longs in an accumulate, we get something like this:
> {code}
> when ...
> $t : Number(...) from accumulate(...,
> sum($p.getLongWeight()))
> then scoreHolder.addHard($t.longValue());
> {code}
> This has 3 problems:
> - *Loss of precision*: the long sum `1881617265586265321L` will incorrectly return `1.88161726558626534E18`, so `13` too much! The BigDecimal sum of `0.09` and `0.01` will also be incorrect.
> - *Loss of performance*: Summing with a Double total is significantly slower than summing with a Long total or an Integer total.
> - Example complexity (minor, not all of us agree on this argument): the use of `Number` is an abstraction that doesn't bring any value to the use case. It's worthless complexity.
> Solution proposal A) for 7.0 as discussed with Mario:
> Based on the argument type to the sum function, the compiler selects a different sum function implementation. This is similar to java overloading mechanism, where `System.out.println(1)` selects a different method implementation than `System.out.println(2.0)`.
> Support sum(Long):
> {code}
> when ...
> $t : Long(...) from accumulate(...,
> sum($p.getLongWeight()))
> then scoreHolder.addHard($t);
> {code}
> and sum(BigDecimal):
> {code}
> when ...
> $t : BigDecimal(...) from accumulate(...,
> sum($p.getBigDecimalWeight()))
> then scoreHolder.addHard($t);
> {code}
> and also support sum(Integer) and sum(BigInteger).
> If this works well, we can consider it for other functions as well in a different jira issue.
> Special case 1: sum(Number) should default to sum(Double) for backwards compatibility.
> {code}
> when ...
> $t : Number(...) from accumulate(...,
> sum($p.getNumberWeight()))
> then scoreHolder.addHard($t.doubleValue());
> {code}
> Not-so-special case 2: to sum integers into a long total, the user should just use:
> {code}
> $t : Long(...) from accumulate(...,
> sum((long) $p.getIntWeight()))
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months