[JBoss JIRA] (WFLY-9406) [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1)
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-9406?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-9406:
------------------------------------
I just checked to see which version of asm.asm is used by org.eclipse.persistence and EclipseLink repackaged the asm.asm source, so as part of this change, we can remove the EclipseLink dependency on asm.asm
I checked EclipseLink 2.6.3 + latest (2.7.0) versions and they both contain the following comment about asm.asm:
{quote}
The EclipseLink Project includes ASM for the purpose of byte code weaving. The AMS library is re-packaged within the source of the project org.persistence.eclipse.internal.libraries.asm.*) to avoid version collisions with other usage of ASM.
{quote}
I'll create a PR for removing asm.asm + javassist (also not needed) and mention this jira.
> [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1)
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-9406
> URL: https://issues.jboss.org/browse/WFLY-9406
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Build System, JPA / Hibernate, Web Services
> Affects Versions: 11.0.0.CR1
> Reporter: Tibor Digana
> Assignee: Alessio Soldano
> Priority: Minor
> Fix For: 12.0.0.Alpha1
>
>
> Reported in GitHub https://github.com/wildfly/wildfly/issues/10531
> Arquillian dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaCoCo uses ASM 5.2.
> The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1.
> Please upgrade it in POM:
> https://github.com/wildfly/wildfly/blob/master/pom.xml
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-9408) Wildfly 10 - The cost of creating the first eclipselink EntityManager during deployment is extremelly high due to MBeanServer.getMbeanCount() cost
by Nuno Godinho de Matos (JIRA)
Nuno Godinho de Matos created WFLY-9408:
-------------------------------------------
Summary: Wildfly 10 - The cost of creating the first eclipselink EntityManager during deployment is extremelly high due to MBeanServer.getMbeanCount() cost
Key: WFLY-9408
URL: https://issues.jboss.org/browse/WFLY-9408
Project: WildFly
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 10.1.0.Final
Reporter: Nuno Godinho de Matos
Assignee: Scott Marlow
Fix For: 11.0.0.Final
I have been trying to reduce the deployment of a WAR application.
One of the greate bottlenecks on the deployment is the cost of getting the first EntityManager instance of eclipselink.
To try to reduce cost of startup I found myself forced to during @Startup fire a CDI event observed by an @Asynchronous ejb whose only task is to do a dummy entityManager.flush().
The results I had for the execution time of this observer could go as high as 13 seconds.
On top of that, I had already noticed while writting an arquillian system test for eclipselink on:
https://issues.jboss.org/browse/WFLY-8954
that the cost of starting up elcipselink under wildfly was much much higher than that of Hibernate and OpenJPA.
With this introduction done let us go to the facts, and they are quite ridiculous.
I have sampled the deployment of an application from begging to end with a sampling script that took a thread dump every second to analyse where the app is spending deployment time generically.
Eventually, I reached the eclipselink deployment.
And I had entries on the log such as:
DatabaseEntityManagerStarter] - <- StartupDatabaseEntityManagerStarter.observeApplicationReadyLoadEntityManagerEvent {5948 ms} <EJB aync-ejb-thread-pool - 1>
While sampling why this was happening I got more than 7 straight thread dump samples (more than 7 seconds) where the following stack trace was present:
{panel}
at java.security.AccessController.getContext(Unknown Source)
at org.jboss.as.controller.SecurityActions.getCaller(SecurityActions.java:47)
at org.jboss.as.controller.AbstractOperationContext.getCaller(AbstractOperationContext.java:1138)
at org.jboss.as.controller.OperationContextImpl.authorizeResource(OperationContextImpl.java:1306)
at org.jboss.as.controller.OperationContextImpl.authorizeResource(OperationContextImpl.java:128)
at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler$CheckResourceAccessHandler.execute(ReadResourceDescriptionHandler.java:429)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1329)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:400)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:208)
at org.jboss.as.jmx.model.ResourceAccessControlUtil.getResourceAccess(ResourceAccessControlUtil.java:85)
at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:51)
at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61)
at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61)
at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61)
at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61)
at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61)
at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61)
at org.jboss.as.jmx.model.RootResourceIterator.iterate(RootResourceIterator.java:43)
at org.jboss.as.jmx.model.ModelControllerMBeanHelper.getMBeanCount(ModelControllerMBeanHelper.java:125)
at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.getMBeanCount(ModelControllerMBeanServerPlugin.java:161)
at org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanCount(PluggableMBeanServerImpl.java:545)
----- Because of the mBeanServer.getMBeanCount():
getAbstractSession().log(SessionLog.FINER, SessionLog.SERVER,
"jmx_mbean_runtime_services_registration_mbeanserver_print",
new Object[]{mBeanServer, mBeanServer.getMBeanCount(), mBeanServer.getDefaultDomain(), 0});
at org.eclipse.persistence.platform.server.JMXServerPlatformBase.getMBeanServer(JMXServerPlatformBase.java:271)
at org.eclipse.persistence.platform.server.JMXServerPlatformBase.serverSpecificRegisterMBean(JMXServerPlatformBase.java:297)
---- Will register Managed beans under the prefix: TopLink:Name="
at org.eclipse.persistence.platform.server.jboss.JBossPlatform.serverSpecificRegisterMBean(JBossPlatform.java:147)
at org.eclipse.persistence.platform.server.ServerPlatformBase.registerMBean(ServerPlatformBase.java:581)
------- this.serverSpecificRegisterMBean();
at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.postConnectDatasource(DatabaseSessionImpl.java:857)
at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.loginAndDetectDatasource(DatabaseSessionImpl.java:762)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider.login(EntityManagerFactoryProvider.java:265)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:731)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.getAbstractSession(EntityManagerFactoryDelegate.java:205)
- locked [0x00000000a90d1210] (a org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.createEntityManagerImpl(EntityManagerFactoryDelegate.java:305)
{panel}
After chekcing the eclipselink source code associated to line:
{panel}
at org.eclipse.persistence.platform.server.JMXServerPlatformBase.getMBeanServer(JMXServerPlatformBase.java:271)
{panel}
I found the following source code - which I could hardly believe would explain this deployment bottleneck:
{panel}
} else {
// Only a single MBeanServer instance was found
getAbstractSession().log(SessionLog.FINER, SessionLog.SERVER,
"jmx_mbean_runtime_services_registration_mbeanserver_print",
new Object[]{mBeanServer, mBeanServer.getMBeanCount(), mBeanServer.getDefaultDomain(), 0});
}
{panel}
In short, the first eclipselink entity manager cost of creation is a never ending task under wildfly because of how expensive the above log statement is:
{panel}
mBeanServer.getMBeanCount()
{panel}
I do not know how to interpret this.
Is the problem that the API should cost ms and it literally takes several seconds to calculate - and the problem is the cost of the API under wildfly.
Or is it that eclipselink should never have written such a log statement on the first place?
To address the issue, I have hacked up my local:
org.jipijapa.eclipselink.WildFlyServerPlatform
In this class, I have override the getMeabServer API from the base class.
I Have created a hacked constant:
{panel}
/**
* During deployment, when the first entity manager is created, the
* application deployment becomes extremelty slow due to the
* MbeanServer.getbeanCount() access done by eclipselink. This access is on
* top of all things done only for logging purposes. We completely kill the
* call to the api.
*/
private static final int MBEAN_SERVER_COUNT_DUMMY_VALUE = -999;
{panel}
And finally I added an overriden method:
{panel}
@Override
public MBeanServer getMBeanServer() {
/**
* This function will attempt to get the MBeanServer via the
* findMBeanServer spec call. 1) If the return list is null we attempt
* to retrieve the PlatformMBeanServer (if it exists or is enabled in
* this security context). 2) If the list of MBeanServers returned is
* more than one we get the lowest indexed MBeanServer that does not on
* a null default domain. 3) 333336: we need to wrap JMX calls in
* doPrivileged blocks 4) fail-fast: if there are any issues with JMX -
* continue - don't block the deploy()
*/
// lazy initialize the MBeanServer reference
if (null == mBeanServer) {
List<MBeanServer> mBeanServerList = null;
try {
if (PrivilegedAccessHelper.shouldUsePrivilegedAccess()) {
try {
mBeanServerList = (List<MBeanServer>) AccessController
.doPrivileged(new PrivilegedExceptionAction() {
@Override
public List<MBeanServer> run() {
return MBeanServerFactory.findMBeanServer(null);
}
});
} catch (PrivilegedActionException pae) {
getAbstractSession().log(SessionLog.WARNING, SessionLog.SERVER, "failed_to_find_mbean_server",
"null or empty List returned from privileged MBeanServerFactory.findMBeanServer(null)");
Context initialContext = null;
try {
initialContext = new InitialContext(); // the
// context
// should be
// cached
mBeanServer = (MBeanServer) initialContext.lookup(JMX_JNDI_RUNTIME_REGISTER);
} catch (NamingException ne) {
getAbstractSession().log(SessionLog.WARNING, SessionLog.SERVER,
"failed_to_find_mbean_server", ne);
}
}
} else {
mBeanServerList = MBeanServerFactory.findMBeanServer(null);
}
// Attempt to get the first MBeanServer we find - usually there
// is only one - when agentId == null we return a List of them
if (null == mBeanServer && (null == mBeanServerList || mBeanServerList.isEmpty())) {
// Unable to acquire a JMX specification List of MBeanServer
// instances
getAbstractSession().log(SessionLog.WARNING, SessionLog.SERVER, "failed_to_find_mbean_server",
"null or empty List returned from MBeanServerFactory.findMBeanServer(null)");
// Try alternate static method
if (!PrivilegedAccessHelper.shouldUsePrivilegedAccess()) {
mBeanServer = ManagementFactory.getPlatformMBeanServer();
if (null == mBeanServer) {
getAbstractSession().log(SessionLog.WARNING, SessionLog.SERVER,
"failed_to_find_mbean_server",
"null returned from ManagementFactory.getPlatformMBeanServer()");
} else {
getAbstractSession().log(SessionLog.FINER, SessionLog.SERVER,
"jmx_mbean_runtime_services_registration_mbeanserver_print",
new Object[] { mBeanServer, MBEAN_SERVER_COUNT_DUMMY_VALUE,
mBeanServer.getDefaultDomain(), 0 });
}
}
} else {
// Use the first MBeanServer by default - there may be
// multiple domains each with their own MBeanServer
mBeanServer = mBeanServerList.get(JMX_MBEANSERVER_INDEX_DEFAULT_FOR_MULTIPLE_SERVERS);
if (mBeanServerList.size() > 1) {
// There are multiple MBeanServerInstances (usually only
// JBoss)
// 328006: WebLogic may also return multiple instances
// (we need to register the one containing the com.bea
// tree)
getAbstractSession().log(SessionLog.WARNING, SessionLog.SERVER,
"jmx_mbean_runtime_services_registration_encountered_multiple_mbeanserver_instances",
mBeanServerList.size(), JMX_MBEANSERVER_INDEX_DEFAULT_FOR_MULTIPLE_SERVERS,
mBeanServer);
// IE: for JBoss we need to verify we are using the
// correct MBean server of the two (default, null)
// Check the domain if it is non-null - avoid using this
// server
int index = 0;
for (MBeanServer anMBeanServer : mBeanServerList) {
getAbstractSession().log(SessionLog.FINER, SessionLog.SERVER,
"jmx_mbean_runtime_services_registration_mbeanserver_print",
new Object[] { anMBeanServer, MBEAN_SERVER_COUNT_DUMMY_VALUE,
anMBeanServer.getDefaultDomain(), index });
if (null != anMBeanServer.getDefaultDomain()) {
mBeanServer = anMBeanServer;
getAbstractSession().log(SessionLog.WARNING, SessionLog.SERVER,
"jmx_mbean_runtime_services_switching_to_alternate_mbeanserver", mBeanServer,
index);
}
index++;
}
} else {
// Only a single MBeanServer instance was found
// mBeanServer.getMBeanCount() - This is very slow on
// wildfly
// we are disabling this statemnt
getAbstractSession().log(SessionLog.FINER, SessionLog.SERVER,
"jmx_mbean_runtime_services_registration_mbeanserver_print", new Object[] { mBeanServer,
MBEAN_SERVER_COUNT_DUMMY_VALUE, mBeanServer.getDefaultDomain(), 0 });
}
}
} catch (Exception e) {
// TODO: Warning required
e.printStackTrace();
}
}
return mBeanServer;
}
{panel}
The above code looks extremelly complex to me just to get a MBeanserver in an application server.
I find it hard to believe that this operation should ever have a code with this many lines of code behind it, but ok.
As you can see in the code I am pasting the only trick I am putting in place to address the deployment time on my machine is to replace every single mebanserver.getMbeanCoundt() by a "dumb" reference to the constant: MBEAN_SERVER_COUNT_DUMMY_VALUE.
Would it possible that the wildflt server platform be tuned to address this issue?
I think it would be a good Idea if you revise the getMbeanServer api to be as simple as possible for JBOSS/Wildfly - the base eclipselink code make slittle since in my oppinion.
But you will know best.
It is also interesting that now when i run the test suite project from wildfly eclipselink actualy manages to be few ms faster than hibernate:
{panel}
Running org.jboss.as.test.compat.jpa.eclipselink.EclipseLinkSharedModuleProviderTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.662 sec - in org.jboss.as.test.compat.jpa.eclipselink.EclipseLinkSharedModuleProviderTestCase
This eclipselink test is actually now faster than
Running org.jboss.as.test.compat.jpa.eclipselink.wildfly8954.PersistenceXmlHelperTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.354 sec - in org.jboss.as.test.compat.jpa.eclipselink.wildfly8954.PersistenceXmlHelperTest
Running org.jboss.as.test.compat.jpa.eclipselink.wildfly8954.WFLY8954BaseTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.685 sec - in org.jboss.as.test.compat.jpa.eclipselink.wildfly8954.WFLY8954BaseTest
Running org.jboss.as.test.compat.jpa.hibernate.HibernateJarsInDeploymentTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.714 sec - in
The hibernate test here loses to the eclipselink test above.
org.jboss.as.test.compat.jpa.hibernate.HibernateJarsInDeploymentTestCase
Running org.jboss.as.test.compat.jpa.openjpa.OpenJPASharedModuleProviderTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.218 sec - in org.jboss.as.test.compat.jpa.openjpa.OpenJPASharedModuleProviderTestCase
{panel}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (DROOLS-1663) Kie DMN doesn't support IMPORT decisions between DMN files
by Stylianos Koussouris (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1663?page=com.atlassian.jira.plugi... ]
Stylianos Koussouris commented on DROOLS-1663:
----------------------------------------------
If you have created a workaround can we please document it?
This is crucial as we currently don't have a release date for this and the
product no doubt will be out before this is implement it. Am I correct
Edson?
Please share with me the steps to resolve this and then we need to make a
contribution to the CoP as no doubt others soon will be asking the same
question.
Many Thanks,
Stelios
On Mon, Oct 2, 2017 at 5:13 PM, Alexandros Koufoudakis <akoufoud(a)redhat.com>
> Kie DMN doesn't support IMPORT decisions between DMN files
> ----------------------------------------------------------
>
> Key: DROOLS-1663
> URL: https://issues.jboss.org/browse/DROOLS-1663
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Reporter: Stylianos Koussouris
> Assignee: Edson Tirelli
> Attachments: IMG_2197.jpg, IMG_2198.jpg, IMG_2199.jpg
>
>
> DMN Spec 1.1
> Page 40.
> import: Import [*] This attribute is used to import externally defined elements and
> make them available for use by elements in this Definitions.
> Section 6.3.3 Import metamodel
> The aim here is to be able to import one Decision defined in a separate DMN into another where it is used as a supporting decision and is referenced (RequiredDecision)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-9285) Make IONA interoperability work with OpenJDK ORB
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-9285?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski commented on WFLY-9285:
--------------------------------------
I have brought forward the capability from the previous subsystem. IONA interoperability was implemented in IIOP subsystem interceptors and not JacORB directly so I decided that I have made a mistake removing it in the first place and restored the previous implementation. I'm preparing reproducing test for QE.
> Make IONA interoperability work with OpenJDK ORB
> ------------------------------------------------
>
> Key: WFLY-9285
> URL: https://issues.jboss.org/browse/WFLY-9285
> Project: WildFly
> Issue Type: Bug
> Reporter: Tomasz Adamski
> Assignee: Tomasz Adamski
> Labels: downstream_dependency
>
> IONA interoperability worked on JacORB, we would like the same functionality to be added to OpenJDK ORB.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-9406) [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1)
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9406?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-9406:
-----------------------------------
Component/s: JPA / Hibernate
This also needs an ok from [~smarlow] as the org.eclipse.persistence module has a dep on asm.asm.
{code}
$ git grep asm.asm
feature-pack/src/main/resources/modules/system/layers/base/asm/asm/main/module.xml:<module xmlns="urn:jboss:module:1.5" name="asm.asm">
feature-pack/src/main/resources/modules/system/layers/base/asm/asm/main/module.xml: <artifact name="${asm:asm}"/>
feature-pack/src/main/resources/modules/system/layers/base/org/apache/cxf/impl/main/module.xml: <module name="asm.asm" />
feature-pack/src/main/resources/modules/system/layers/base/org/apache/cxf/main/module.xml: <module name="asm.asm" />
feature-pack/src/main/resources/modules/system/layers/base/org/apache/cxf/services-sts/main/module.xml: <module name="asm.asm" />
feature-pack/src/main/resources/modules/system/layers/base/org/apache/cxf/ws-security/main/module.xml: <module name="asm.asm" />
feature-pack/src/main/resources/modules/system/layers/base/org/eclipse/persistence/main/module.xml: <module name="asm.asm"/>
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/server/integration/main/module.xml: <module name="asm.asm" export="true"/>
testsuite/compat/src/test/scripts/build-jars.xml:<module name="asm.asm"/>
{code}
> [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1)
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-9406
> URL: https://issues.jboss.org/browse/WFLY-9406
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Build System, JPA / Hibernate, Web Services
> Affects Versions: 11.0.0.CR1
> Reporter: Tibor Digana
> Assignee: Alessio Soldano
> Priority: Minor
> Fix For: 12.0.0.Alpha1
>
>
> Reported in GitHub https://github.com/wildfly/wildfly/issues/10531
> Arquillian dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaCoCo uses ASM 5.2.
> The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1.
> Please upgrade it in POM:
> https://github.com/wildfly/wildfly/blob/master/pom.xml
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos commented on WFLY-8954:
---------------------------------------------
Hi Are there any plans on assimilating the pull request for this issue?
NOTE:
I will now open another issue - related to extreme cost of creating the first entity manager - for which the core of the issue seems to be on eclipselink org.eclipse.persistence.platform.server.JMXServerPlatformBase but that can be addressed by tweaking org.jipijapa.eclipselink.WildFlyServerPlatform.
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (DROOLS-1663) Kie DMN doesn't support IMPORT decisions between DMN files
by Stylianos Koussouris (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1663?page=com.atlassian.jira.plugi... ]
Stylianos Koussouris commented on DROOLS-1663:
----------------------------------------------
Hey Alexandros,
How is that going to affect the guys in The Hague? Have we got a way to
mitigate this? How far from releasing are they? I am assuming you guys are
aware of the lack of this functionality and have found a workaround?
Regards,
Stelios
On Mon, Oct 2, 2017 at 1:43 PM, Edson Tirelli (JIRA) <issues(a)jboss.org>
> Kie DMN doesn't support IMPORT decisions between DMN files
> ----------------------------------------------------------
>
> Key: DROOLS-1663
> URL: https://issues.jboss.org/browse/DROOLS-1663
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Reporter: Stylianos Koussouris
> Assignee: Edson Tirelli
> Attachments: IMG_2197.jpg, IMG_2198.jpg, IMG_2199.jpg
>
>
> DMN Spec 1.1
> Page 40.
> import: Import [*] This attribute is used to import externally defined elements and
> make them available for use by elements in this Definitions.
> Section 6.3.3 Import metamodel
> The aim here is to be able to import one Decision defined in a separate DMN into another where it is used as a supporting decision and is referenced (RequiredDecision)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3323) Initial Elytron configuration includes mapping-mode="first" in simple-permission-mapper
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3323?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3323:
------------------------------------------
Just a note on requirements: if an item in the parsed configuration is not persisted when the xml is rewritten, that's a bug in the code not in the original configuration. IOW the fix isn't to change our standard configuration.
BTW, let's call the .xml files we ship our "standard configuration" not our "default configuration". The term "default configuration" is technically correct but using a different term helps avoid confusion about the word default. Attributes in our management model can have default values, and that is a different thing from the standard xml files we ship.
> Initial Elytron configuration includes mapping-mode="first" in simple-permission-mapper
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-3323
> URL: https://issues.jboss.org/browse/WFCORE-3323
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.3.Final
> Reporter: Ondrej Lukas
> Assignee: Ilia Vassilev
> Priority: Minor
>
> As part of fix JBEAP-12933 there was added attribute {{mapping-mode="first"}} into "default-permission-mapper" {{simple-permission-mapper}} in default configuration. Value {{first}} is default value of {{simple-permission-mapper.mapping-mode}} which means that this attribute disappears after first change in server configuration. It can be confusing since Elytron subsystem configuration in XML is changed even if there was no request for changing that configuration. Attribute {{mapping-mode="first"}} should be removed from default configuration.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-9405) NPE when trying to recursively remove the EJB subsystem
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9405?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-9405:
-----------------------------------
Workaround Description:
Put the server in admin-only mode before removing the subsystem.
{code}
[standalone@localhost:9990 /] reload --admin-only=true
[standalone@localhost:9990 /] /subsystem=ejb3:remove
{"outcome" => "success"}
{code}
Putting the server in admin-only before doing this kind of surgery is a good idea anyway.
was:
Put the server in admin-only mode before removing the subsystem.
{code}
[standalone@localhost:9990 /] reload --admin-only=true
[standalone@localhost:9990 /] /subsystem=ejb3:remove
{"outcome" => "success"}
{code}
Putting the server in admin-only before doing this kind of surgery is probably a good idea anyway.
> NPE when trying to recursively remove the EJB subsystem
> -------------------------------------------------------
>
> Key: WFLY-9405
> URL: https://issues.jboss.org/browse/WFLY-9405
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.CR1
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> This fails:
> {code}
> [standalone@localhost:9990 /] /subsystem=ejb3:remove
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
> "rolled-back" => true
> }
> {code}
> with this in the server log:
> {code}
> 15:53:42,572 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("remove") failed - address: ([
> ("subsystem" => "ejb3"),
> ("service" => "remote"),
> ("channel-creation-options" => "MAX_OUTBOUND_MESSAGES")
> ]): java.lang.NullPointerException
> at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:894)
> at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:884)
> at org.jboss.as.controller.RestartParentResourceHandlerBase.getModel(RestartParentResourceHandlerBase.java:216)
> at org.jboss.as.controller.RestartParentResourceHandlerBase.access$000(RestartParentResourceHandlerBase.java:39)
> at org.jboss.as.controller.RestartParentResourceHandlerBase$1.execute(RestartParentResourceHandlerBase.java:66)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:980)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1402)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:418)
> ...
> {code}
> I believe a post-boot add of this resource would fail as well.
> Problem is ChannelCreationOptionRemove and ChannelCreationOptionAdd in RemoteConnectorChannelCreationOptionResource use an incorrect parentKeyName. These handlers extend RestartParentResourceHandlerBase but are passing the *value* of the parent element as "parentKeyName" instead of its *key*; i.e. "remote" instead of "service".
> Even though this code has been like this since 2012, this is somewhat a regression since before the current version our standard configs did not include resources of this type. So users could hit this in previous releases but now they are more likely to.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months