[JBoss JIRA] (DROOLS-2232) Increase coverage org.kie.workbench.common.dmn.client.editors.expressions.types.literal
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2232?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2232:
--------------------------------
Description:
The actual coverage form the attachment should be increased.
- LiteralExpressionGrid
- LiteralExpressionColumnRenderer
- LiteralExpressionUIModelMapper
- -LiteralExpressionEditorDefinition- - just getters and setters
- -LiteralExpressionColumnHeaderMetaData- - just extends another class
- -LiteralExpressionGridRenderer- - just extends another class
was:
The actual coverage form the attachment should be increased.
- LiteralExpressionGrid
- LiteralExpressionColumnRenderer
- LiteralExpressionUIModelMapper
- LiteralExpressionEditorDefinition
- -LiteralExpressionColumnHeaderMetaData- - just extends another class
- -LiteralExpressionGridRenderer- - just extends another class
> Increase coverage org.kie.workbench.common.dmn.client.editors.expressions.types.literal
> ---------------------------------------------------------------------------------------
>
> Key: DROOLS-2232
> URL: https://issues.jboss.org/browse/DROOLS-2232
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Jozef Marko
> Assignee: Jozef Marko
> Attachments: index.html
>
>
> The actual coverage form the attachment should be increased.
> - LiteralExpressionGrid
> - LiteralExpressionColumnRenderer
> - LiteralExpressionUIModelMapper
> - -LiteralExpressionEditorDefinition- - just getters and setters
> - -LiteralExpressionColumnHeaderMetaData- - just extends another class
> - -LiteralExpressionGridRenderer- - just extends another class
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-2232) Increase coverage org.kie.workbench.common.dmn.client.editors.expressions.types.literal
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2232?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2232:
--------------------------------
Description:
The actual coverage form the attachment should be increased.
- LiteralExpressionGrid
- LiteralExpressionColumnRenderer
- LiteralExpressionUIModelMapper
- LiteralExpressionEditorDefinition
- -LiteralExpressionColumnHeaderMetaData- - just extends another class
- -LiteralExpressionGridRenderer- - just extends another class
was:
The actual coverage form the attachment should be increased.
- LiteralExpressionGrid
- LiteralExpressionColumnRenderer
- LiteralExpressionUIModelMapper
- LiteralExpressionEditorDefinition
- LiteralExpressionColumnHeaderMetaData
- -LiteralExpressionGridRenderer- - just extends another class
> Increase coverage org.kie.workbench.common.dmn.client.editors.expressions.types.literal
> ---------------------------------------------------------------------------------------
>
> Key: DROOLS-2232
> URL: https://issues.jboss.org/browse/DROOLS-2232
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Jozef Marko
> Assignee: Jozef Marko
> Attachments: index.html
>
>
> The actual coverage form the attachment should be increased.
> - LiteralExpressionGrid
> - LiteralExpressionColumnRenderer
> - LiteralExpressionUIModelMapper
> - LiteralExpressionEditorDefinition
> - -LiteralExpressionColumnHeaderMetaData- - just extends another class
> - -LiteralExpressionGridRenderer- - just extends another class
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-2232) Increase coverage org.kie.workbench.common.dmn.client.editors.expressions.types.literal
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2232?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2232:
--------------------------------
Description:
The actual coverage form the attachment should be increased.
- LiteralExpressionGrid
- LiteralExpressionColumnRenderer
- LiteralExpressionUIModelMapper
- LiteralExpressionEditorDefinition
- LiteralExpressionColumnHeaderMetaData
- -LiteralExpressionGridRenderer- - just extends another class
was:
The actual coverage form the attachment should be increased.
- LiteralExpressionGrid
- LiteralExpressionColumnRenderer
- LiteralExpressionUIModelMapper
- LiteralExpressionEditorDefinition
- LiteralExpressionColumnHeaderMetaData
- LiteralExpressionGridRenderer
> Increase coverage org.kie.workbench.common.dmn.client.editors.expressions.types.literal
> ---------------------------------------------------------------------------------------
>
> Key: DROOLS-2232
> URL: https://issues.jboss.org/browse/DROOLS-2232
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Jozef Marko
> Assignee: Jozef Marko
> Attachments: index.html
>
>
> The actual coverage form the attachment should be increased.
> - LiteralExpressionGrid
> - LiteralExpressionColumnRenderer
> - LiteralExpressionUIModelMapper
> - LiteralExpressionEditorDefinition
> - LiteralExpressionColumnHeaderMetaData
> - -LiteralExpressionGridRenderer- - just extends another class
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-2232) Increase coverage org.kie.workbench.common.dmn.client.editors.expressions.types.literal
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2232?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2232:
--------------------------------
Description:
The actual coverage form the attachment should be increased.
- LiteralExpressionGrid
- LiteralExpressionColumnRenderer
- LiteralExpressionUIModelMapper
- LiteralExpressionEditorDefinition
- LiteralExpressionColumnHeaderMetaData
- LiteralExpressionGridRenderer
was:The actual coverage form the attachment should be increased.
> Increase coverage org.kie.workbench.common.dmn.client.editors.expressions.types.literal
> ---------------------------------------------------------------------------------------
>
> Key: DROOLS-2232
> URL: https://issues.jboss.org/browse/DROOLS-2232
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Jozef Marko
> Assignee: Jozef Marko
> Attachments: index.html
>
>
> The actual coverage form the attachment should be increased.
> - LiteralExpressionGrid
> - LiteralExpressionColumnRenderer
> - LiteralExpressionUIModelMapper
> - LiteralExpressionEditorDefinition
> - LiteralExpressionColumnHeaderMetaData
> - LiteralExpressionGridRenderer
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9502) javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "null" when jms bridge is trying to do remote lookup on EAP6/HornetQ
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-9502?page=com.atlassian.jira.plugin.... ]
Lin Gao updated WFLY-9502:
--------------------------
Labels: downstream_dependency (was: )
> javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "null" when jms bridge is trying to do remote lookup on EAP6/HornetQ
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9502
> URL: https://issues.jboss.org/browse/WFLY-9502
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Naming
> Affects Versions: 11.0.0.Final
> Reporter: Martin Švehla
> Assignee: Martyn Taylor
> Priority: Critical
> Labels: downstream_dependency
>
> When I create jms bridge on EAP7 that tries to connect to EAP6, it throws following issue when trying to do remote lookup for connection factory or destination on EAP6.
> {code}
> 2017-10-31 09:44:18,769 WARN [org.apache.activemq.artemis.jms.bridge] (Thread-102) AMQ342010: Failed to connect JMS Bridge N/A: javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "null"
> at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:808)
> at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:140)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at org.apache.activemq.artemis.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:46)
> at org.apache.activemq.artemis.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:32)
> at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1072)
> at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1247)
> at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.access$2600(JMSBridgeImpl.java:75)
> at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:1747)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {\code}
> When debugging I noticed that WildFlyRootContext.getProviderContext there's no NamingProviderFactory available to resolve the name, so I think the error message is just a consequence of that.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-3858) Infinispan cache configuration is not always applied to security-domain
by Ууган Мэндбаяр (JIRA)
[ https://issues.jboss.org/browse/WFLY-3858?page=com.atlassian.jira.plugin.... ]
Ууган Мэндбаяр commented on WFLY-3858:
--------------------------------------
infinispan ver.: 9.1.4.Final
wildfly ver. : 10
But infinispan still doesn't fire expire event sometimes. It works normally when we cleared cache, but after few events it doesn't fire expire event only after cache.get or cache.size method. Any suggestions? How to avoid that situation?
> Infinispan cache configuration is not always applied to security-domain
> -----------------------------------------------------------------------
>
> Key: WFLY-3858
> URL: https://issues.jboss.org/browse/WFLY-3858
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.1.0.Final
> Reporter: Robert Tuck
> Assignee: Paul Ferraro
> Fix For: 11.0.0.Alpha1
>
> Attachments: debugger output.txt
>
>
> On Wildfly 8.1.0.Final, I have the following standalone-ha.xml:
> <subsystem xmlns="urn:jboss:domain:infinispan:2.0">
> ...
> <cache-container name="security" default-cache="auth-cache" start="EAGER">
> <transport cluster="${cluster.name}_SEC" lock-timeout="60000"/>
> <replicated-cache name="auth-cache" batching="true" mode="ASYNC">
> <eviction strategy="LRU" max-entries="10000"/>
> <expiration lifespan="60000"/>
> </replicated-cache>
> </cache-container>
> </subsystem>
> ...
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> ...
> <security-domain name="OAuth-Consumer" cache-type="infinispan">
> <authentication>
> <login-module code="com.idbs.ewb.server.auth.module.OAuthConsumerLoginModule" flag="sufficient"
> module="deployment.ewb-server-ear.ear">
> <module-option name="allowedConsumerAuthFailures" value="-1"/>
> <module-option name="consumerLoginFailureTimeoutMs" value="3000"/>
> </login-module>
> </authentication>
> </security-domain>
> </security-domains>
> </subsystem>
> After startup the OAuth-Consumer security domain cache "auth-cache" is not always configured with the specified settings (~50% of the time). This can be verified by monitoring the jboss.infinispan nodes with JConsole and retrieving the cache settings, and tracking the cache hits during logins. This shows that succesful logins are cached but do not expire after the expected 60s, and that the expiration lifespan is set to -1 rather than 60000, as are eviction max entries.
> After some debugging I have narrowed down the problem to some code that gets called from inside org.jboss.as.security.plugins.JNDIBasedSecurityManagement:
> public SecurityDomainContext createSecurityDomainContext(String securityDomain, Object cacheFactory) throws Exception {
> log.debugf("Creating SDC for domain=" + securityDomain);
> AuthenticationManager am = createAuthenticationManager(securityDomain);
> // create authentication cache
> if (cacheFactory instanceof EmbeddedCacheManager) {
> EmbeddedCacheManager cacheManager = EmbeddedCacheManager.class.cast(cacheFactory);
> @SuppressWarnings("rawtypes")
> Cache cache = null;
> if (cacheManager != null) {
> // TODO override global settings with security domain specific
> ConfigurationBuilder builder = new ConfigurationBuilder();
> Configuration baseCfg = cacheManager.getCacheConfiguration("auth-cache");
> ^^^^ This call here doesn’t always return the correct configuration, baseCfg is then null.
> if (baseCfg != null) {
> builder.read(baseCfg);
> }
> cacheManager.defineConfiguration(securityDomain, builder.build());
> cache = cacheManager.getCache(securityDomain);
> }
> if (cache != null && am instanceof CacheableManager) {
> @SuppressWarnings({ "unchecked", "rawtypes" })
> CacheableManager<Map, Principal> cm = (CacheableManager<Map, Principal>) am;
> cm.setCache(cache);
> }
> } else if (cacheFactory instanceof DefaultAuthenticationCacheFactory) {
> <…>
> }
> getCacheConfiguration(String) is implemented inside org.infinispan.manager.DefaultCacheManager:
> @Override
> public Configuration getCacheConfiguration(String name) {
> Configuration configuration = configurationOverrides.get(name);
> if (configuration == null && cacheExists(name)) {
> return defaultConfiguration;
> }
> return configuration;
> }
> Seems like the condition configuration == null occurs when the cache doesn’t exist, therefore it returns null. This appears to be a race condition between this code and where it gets registered in wireAndStartCache(String).
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-1937) [DMN Editor] Dynamic Form Properties with nested hierarchy binds to wrong object/widget
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1937?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-1937:
----------------------------------------
[~roger600] <3
> [DMN Editor] Dynamic Form Properties with nested hierarchy binds to wrong object/widget
> ---------------------------------------------------------------------------------------
>
> Key: DROOLS-1937
> URL: https://issues.jboss.org/browse/DROOLS-1937
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Roger Martínez
> Priority: Critical
> Labels: Stunner
>
> The Dynamic Form generated from a nested object hierarchy binds objects/widgets to the incorrect instances. For example; the below classes define an {{Id}} form field that is used in both {{InputData}} (through inheritance) and {{InformationItem}} (through sub-form reference and inheritance). When changing the {{Id}} field (for example) in the {{InputData}} form property the "Id" value of the nested "Information Item" is updated.
> {code}
> public abstract class DMNModelInstrumentedBase implements DMNDefinition {
>
> //No @FormFields etc
>
> }
>
> public abstract class DMNElement extends DMNModelInstrumentedBase {
>
> @Property
> @FormField
> protected Id id;
>
> @Property
> @FormField(afterElement = "id")
> protected Label label;
>
> @Property
> @FormField(afterElement = "label")
> protected Description description;
>
> ....
> }
>
> public abstract class NamedElement extends DMNElement {
>
> @Property
> @FormField(afterElement = "description")
> protected Name name;
>
> ....
> }
>
> @FormDefinition(policy = FieldPolicy.ONLY_MARKED)
> public class InformationItem extends NamedElement implements DMNPropertySet {
>
> @Property
> @FormField(afterElement = "name")
> protected QName typeRef;
>
> ....
> }
> public abstract class DRGElement extends NamedElement {}
> @FormDefinition(policy = FieldPolicy.ONLY_MARKED)
> public class InputData extends DRGElement {
> ...
> @PropertySet
> @FormField(afterElement = "name")
> protected InformationItem variable;
> ...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-1937) [DMN Editor] Dynamic Form Properties with nested hierarchy binds to wrong object/widget
by Roger Martínez (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1937?page=com.atlassian.jira.plugi... ]
Roger Martínez commented on DROOLS-1937:
----------------------------------------
[~manstis] Moving this ticket on top of backlog in order to address it ASAP, it now appears on the Stunner board.
> [DMN Editor] Dynamic Form Properties with nested hierarchy binds to wrong object/widget
> ---------------------------------------------------------------------------------------
>
> Key: DROOLS-1937
> URL: https://issues.jboss.org/browse/DROOLS-1937
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Roger Martínez
> Priority: Critical
> Labels: Stunner
>
> The Dynamic Form generated from a nested object hierarchy binds objects/widgets to the incorrect instances. For example; the below classes define an {{Id}} form field that is used in both {{InputData}} (through inheritance) and {{InformationItem}} (through sub-form reference and inheritance). When changing the {{Id}} field (for example) in the {{InputData}} form property the "Id" value of the nested "Information Item" is updated.
> {code}
> public abstract class DMNModelInstrumentedBase implements DMNDefinition {
>
> //No @FormFields etc
>
> }
>
> public abstract class DMNElement extends DMNModelInstrumentedBase {
>
> @Property
> @FormField
> protected Id id;
>
> @Property
> @FormField(afterElement = "id")
> protected Label label;
>
> @Property
> @FormField(afterElement = "label")
> protected Description description;
>
> ....
> }
>
> public abstract class NamedElement extends DMNElement {
>
> @Property
> @FormField(afterElement = "description")
> protected Name name;
>
> ....
> }
>
> @FormDefinition(policy = FieldPolicy.ONLY_MARKED)
> public class InformationItem extends NamedElement implements DMNPropertySet {
>
> @Property
> @FormField(afterElement = "name")
> protected QName typeRef;
>
> ....
> }
> public abstract class DRGElement extends NamedElement {}
> @FormDefinition(policy = FieldPolicy.ONLY_MARKED)
> public class InputData extends DRGElement {
> ...
> @PropertySet
> @FormField(afterElement = "name")
> protected InformationItem variable;
> ...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months