[JBoss JIRA] (ELYWEB-7) Add JASPIC Integration
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELYWEB-7:
-------------------------------------
Summary: Add JASPIC Integration
Key: ELYWEB-7
URL: https://issues.jboss.org/browse/ELYWEB-7
Project: Elytron Web
Issue Type: Feature Request
Components: Undertow Servlet
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.2.1.CR1
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2749) DMN invoking and/or importing a bkm with a dot in name
by Matteo Mortari (JIRA)
Matteo Mortari created DROOLS-2749:
--------------------------------------
Summary: DMN invoking and/or importing a bkm with a dot in name
Key: DROOLS-2749
URL: https://issues.jboss.org/browse/DROOLS-2749
Project: Drools
Issue Type: Bug
Components: dmn engine
Reporter: Matteo Mortari
Assignee: Matteo Mortari
# Verify when a DMN model Invoke (decision logic) a BKM with a dot in the name
# Verify when a DMN model import and invoke Invoke (decision logic) a BKM with a dot in the name
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFCORE-3949) Cannot use server-file audit logger handler in JMX audit logging
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3949?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3949:
------------------------------------------
This shouldn't work. The file-handler=server-file resource is meant for use with the server-logger=audit-log resource. That resource has no Stage.RUNTIME logging effect on the HC; it only exists as a store of configuration that the HC uses when it creates a configuration for a server it will launch. So _on the HC process_ it never actually tries to use a logging handler that file-handler=server-file would configure
If you tried to point /host=master/core-service=management/access=audit/logger=audit-log at the server-file I believe you would get the same problem, as that resource actually tries to log on the HC.
The check of the jboss.server.data.dir capability reference passes basically because of a hack. The file-handler resource is dual use (HC and server) so we need to allow a config that will be useful for creating the server's config. But we want to validate the relative-to, so we hack in capabilities in the HC process for the well-known server paths. But those paths do not actually exist in the HC process. And they shouldn't; there is no single valid jboss.server.data.dir in an HC process as the HC can create multiple servers, each of which would have a different dir.
Perhaps this could be improved to fail in a better way. But I think it will be hard to do and this seems like a corner case not worth the effort.
Really in host.xml there should be a separate server-xxx-handler resources, and only those can be referenced from the server-logger=audit-log resource. And the logger=audit-log resource cannot reference those. But adding that kind of restriction to the server-logger=audit-log resource would be an incompatible change. There would also need to be a bunch of resource types added, as there are 5 different variants of handler.
> Cannot use server-file audit logger handler in JMX audit logging
> -----------------------------------------------------------------
>
> Key: WFCORE-3949
> URL: https://issues.jboss.org/browse/WFCORE-3949
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX, Logging
> Reporter: Yeray Borges
> Assignee: Yeray Borges
>
> When we are working in domain mode, we can register two kinds of audit logger handlers into JMX audit logging.
> Those predefined handlers are {{host-file}} handler, which has a log file relative to {{jboss.domain.data.dir}}, and {{server-file}} handler, which has a log file relative to {{jboss.server.data.dir}}.
> When we try to register {{server-file}} handler into JMX audit logging, its relative path cannot be resolved and when a log entry is written, we can see the following error log:
> {code:java}
> ERROR [org.jboss.as.controller.management-operation] (MSC service thread 1-1) WFLYCTL0037: Update of the management operation audit log failed in handler 'server-file': java.lang.IllegalArgumentException: WFLYCTL0256: Could not find a path called 'jboss.server.data.dir'
> [Host Controller] at org.jboss.as.controller.services.path.PathManagerService.resolveRelativePathEntry(PathManagerService.java:110)
> [Host Controller] at org.jboss.as.controller.audit.AbstractFileAuditLogHandler.initialize(AbstractFileAuditLogHandler.java:62)
> [Host Controller] at org.jboss.as.controller.audit.AuditLogHandler.writeLogItem(AuditLogHandler.java:82)
> [Host Controller] at org.jboss.as.controller.audit.ManagedAuditLoggerImpl.writeLogItem(ManagedAuditLoggerImpl.java:266)
> [Host Controller] at org.jboss.as.controller.audit.ManagedAuditLoggerImpl.storeLogItem(ManagedAuditLoggerImpl.java:248)
> [Host Controller] at org.jboss.as.controller.audit.ManagedAuditLoggerImpl.logJmxMethodAccess(ManagedAuditLoggerImpl.java:122)
> [Host Controller] at org.jboss.as.jmx.PluggableMBeanServerImpl$LogAction.doLog(PluggableMBeanServerImpl.java:1281)
> [Host Controller] at org.jboss.as.jmx.PluggableMBeanServerImpl.log(PluggableMBeanServerImpl.java:1184)
> [Host Controller] at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.log(MBeanServerAuditLogRecordFormatter.java:331)
> [Host Controller] at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.registerMBean(MBeanServerAuditLogRecordFormatter.java:147)
> [Host Controller] at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:880)
> [Host Controller] at org.jboss.threads.EnhancedQueueExecutor$1.run(EnhancedQueueExecutor.java:385)
> [Host Controller] at org.jboss.threads.EnhancedQueueExecutor$1.run(EnhancedQueueExecutor.java:379)
> [Host Controller] at java.security.AccessController.doPrivileged(Native Method)
> [Host Controller] at org.jboss.threads.EnhancedQueueExecutor.<init>(EnhancedQueueExecutor.java:379)
> [Host Controller] at org.jboss.threads.EnhancedQueueExecutor$Builder.build(EnhancedQueueExecutor.java:671)
> [Host Controller] at org.jboss.as.controller.remote.AbstractModelControllerOperationHandlerFactoryService.start(AbstractModelControllerOperationHandlerFactoryService.java:112)
> [Host Controller] at org.jboss.as.host.controller.mgmt.MasterDomainControllerOperationHandlerService.start(MasterDomainControllerOperationHandlerService.java:90)
> [Host Controller] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> [Host Controller] at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> [Host Controller] at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> [Host Controller] at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> [Host Controller] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> [Host Controller] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> [Host Controller] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> [Host Controller] at java.lang.Thread.run(Thread.java:748)
> {code}
> Registering a {{host-file}} does not throw any errors and work as expected. Althought there is a capability reference to jboss.server.data.dir in HostPathManagerService, when the handler is registered for JMX, jboss.server.data.dir cannot be resolved.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2744) [DMN Designer] Global diagram properties
by Roger Martínez (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2744?page=com.atlassian.jira.plugi... ]
Roger Martínez edited comment on DROOLS-2744 at 7/17/18 12:15 PM:
------------------------------------------------------------------
Hey [~manstis] [~jomarko]
The properties displayed on the panel are always bind to a node, it can be the diagram itself or whatever node is being selected.
This way we still don't have support for changing multiple nodes from a single property field, at least yet.
The way they work is:
* The forms are rendering the fields for the (selected) bean properties - but are not really bind to the "real" bean, are bind to a cloned nstance
* Once the value is changed on the form field, it gets validated and parsed by the forms engine
* The forms engine provides a callback, which Stunner consumes, and once a property has been changed, it fires a Stunner command in order to update the value for the "real" bean property (see [here|https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-common-...])
* Finally once the Stunner command, which updates the given property value, is being executed - it gets into the command history (stack), updates the bean and it forces to redraw the shape for the given bean
Tbh IDK yet why this is not working for visual related properties such as background, color, etc, could be a bug. I would start by debugging, on client side, if the stunner callback is being called with the right (serialized) value, and also check the stunner command is firing.
Hope this helps a bit. Lemme know whatever you need guys.
Thx!
was (Author: roger600):
Hey [~manstis] [~jomarko]
The properties displayed on the panel are always bind to a node, it can be the diagram itself or whatever node is being selected.
This way we still don't have support for changing multiple nodes from a single property field, at least yet.
The way they work is:
* The forms are rendering the fields for the (selected) bean properties - but are not really bind to the "real" bean, are bind to a cloned nstance
* Once the value is changed on the form field, it gets validated and parsed by the forms engine
* The forms engine provides a callback, which Stunner consumes, and once a property has been changed, it fires a Stunner command in order to update the value for the "real" bean property (see [here|https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-common-...])
* Finally once the Stunner command, which updates the given property value, is being executed - it gets into the command history (stack) and it forces to redraw the shape for the given bean
Tbh IDK yet why this is not working for visual related properties such as background, color, etc, could be a bug. I would start by debugging, on client side, if the stunner callback is being called with the right (serialized) value, and also check the stunner command is firing.
Hope this helps a bit. Lemme know whatever you need guys.
Thx!
> [DMN Designer] Global diagram properties
> ----------------------------------------
>
> Key: DROOLS-2744
> URL: https://issues.jboss.org/browse/DROOLS-2744
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.9.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
> Labels: drools-tools
>
> The global diagram properties for DMN diagram contains sections settings for:
> - dimensions
> - backround
> - font
> However change of any of them (globally, for the whole diagram) doesn't seem to affect particular nodes somehow. We should hide these settings or implement the logic that would affect all nodes in diagram by change on this place.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2744) [DMN Designer] Global diagram properties
by Roger Martínez (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2744?page=com.atlassian.jira.plugi... ]
Roger Martínez commented on DROOLS-2744:
----------------------------------------
Hey [~manstis] [~jomarko]
The properties displayed on the panel are always bind to a node, it can be the diagram itself or whatever node is being selected.
This way we still don't have support for changing multiple nodes from a single property field, at least yet.
The way they work is:
* The forms are rendering the fields for the (selected) bean properties - but are not really bind to the "real" bean, are bind to a cloned nstance
* Once the value is changed on the form field, it gets validated and parsed by the forms engine
* The forms engine provides a callback, which Stunner consumes, and once a property has been changed, it fires a Stunner command in order to update the value for the "real" bean property (see [here|https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-common-...])
* Finally once the Stunner command, which updates the given property value, is being executed - it gets into the command history (stack) and it forces to redraw the shape for the given bean
Tbh IDK yet why this is not working for visual related properties such as background, color, etc, could be a bug. I would start by debugging, on client side, if the stunner callback is being called with the right (serialized) value, and also check the stunner command is firing.
Hope this helps a bit. Lemme know whatever you need guys.
Thx!
> [DMN Designer] Global diagram properties
> ----------------------------------------
>
> Key: DROOLS-2744
> URL: https://issues.jboss.org/browse/DROOLS-2744
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.9.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
> Labels: drools-tools
>
> The global diagram properties for DMN diagram contains sections settings for:
> - dimensions
> - backround
> - font
> However change of any of them (globally, for the whole diagram) doesn't seem to affect particular nodes somehow. We should hide these settings or implement the logic that would affect all nodes in diagram by change on this place.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2734) [Guided Decision Table] - Zooming
by Roger Martínez (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2734?page=com.atlassian.jira.plugi... ]
Roger Martínez commented on DROOLS-2734:
----------------------------------------
Ok great [~manstis], it makes sense for me too. Thanks for the updates!
> [Guided Decision Table] - Zooming
> ---------------------------------
>
> Key: DROOLS-2734
> URL: https://issues.jboss.org/browse/DROOLS-2734
> Project: Drools
> Issue Type: Story
> Components: Guided Decision Table Editor
> Reporter: Matthew Stevens
> Assignee: Michael Anstis
> Labels: UX, UXTeam
>
> In order to improve zoom capabilities, a first priority is to better align current capabilities across the workbench, specifically GDT and Stunner.
> *For GDT*
> # Add support for Control click with mouse wheel or trackpad to zoom like Stunner.
> # Add keyboard support for Control click with +/- to allow users to cycle through the different zoom levels.
> A long term solution might move these controls to the canvas, add more zoom levels, and add a slider. But aligning things is a good start.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10701) Multi JSF Installer generate myfaces installer with old jars inside
by Erick de Oliveira Leal (JIRA)
[ https://issues.jboss.org/browse/WFLY-10701?page=com.atlassian.jira.plugin... ]
Erick de Oliveira Leal closed WFLY-10701.
-----------------------------------------
Resolution: Duplicate Issue
resolved in #WFLY-10475
> Multi JSF Installer generate myfaces installer with old jars inside
> -------------------------------------------------------------------
>
> Key: WFLY-10701
> URL: https://issues.jboss.org/browse/WFLY-10701
> Project: WildFly
> Issue Type: Component Upgrade
> Components: JSF
> Affects Versions: 13.0.0.Final
> Reporter: Erick de Oliveira Leal
> Assignee: Farah Juma
>
> running mvn -Djsf-version=2.3.1 -Pmyfaces clean assembly:single on multi-jsf-installer directory generates install-myfaces-2.3.1.zip with 2.2.11 jars inside.
> Another issue is after replace 2.2.11 jars and install it, wildfly prints:
> ~JSF version slot 'myfaces-2.3.1' is missing from module org.jboss.as.jsf-injection
> Activated the following JSF Implementations: [main]~
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years