[JBoss JIRA] (DROOLS-3147) [DMN Designer] Keyboard shortcuts
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3147?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3147:
--------------------------------
Tester: (was: Jozef Marko)
> [DMN Designer] Keyboard shortcuts
> ---------------------------------
>
> Key: DROOLS-3147
> URL: https://issues.jboss.org/browse/DROOLS-3147
> Project: Drools
> Issue Type: Epic
> Reporter: Jozef Marko
> Assignee: Jozef Marko
> Priority: Minor
> Labels: drools-tools, reported-by-qe
>
> The DMN and Scenario Simulation editors should support keyboard shortcuts (similar for current GDT tables) for basic operations like:
> Navigation between cells
> Invoking inline context menu
> Start Editing cell
> Finish editing Cell
> This support is crucial for integration selenium testing. In the DMN the selenium testing wouldn't be possible without the Navigation Dock (BAPL-966).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3727) [DMN Designer] Quick Silver: Minimal standalone preparation
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3727?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-3727:
----------------------------------------
Hi [~roger600], I'll include [~jomarko] in this reply as he's been asking similar questions.
Firstly a summary:
My branch tidied up the dependencies for DMN without making too many changes elsewhere. There is more work to be done (primarily trying to reduce the dependencies needed for DMN's use of client-side only dynamic forms. At the moment way too many additional dependencies are needed by Forms - mainly to support the server side creation - and these drag in dependencies with AppFormer's plugins and Layout editor!) My branch also endeavours to make using the same _core_ editor in both 7.x and 8.x (Submarine) so we don't have to worry too much about maintaining two code bases. This works quite well at the moment however I need to complete more changes for the Submarine wrapper as things like {{Path}} and {{PlaceManager}} are no longer available.
Regarding _running_ the DMN editor in Submarine. I made the DMN editor _fit_ the requirements of Submarine ({{setContent(String)}} and {{String getContent()}} methods that accept and return a DMN XML String that converted to/from {{Diagram}} with a RPC). As far as Submarine is concerned all interactions with an Editor are via these two client-side methods. I don't run DMN in VSCode or Che. This is work that [~porcelli] did based on my branch. He made some revisions but these have been merged and (as of today) my local changes make the DMN editor _look_ almost 100% like [~porcelli] revisions.
We are coming to a point where we need to probably start running DMN in VSCode/Che ourselves and that will require deciding where to put Submarine work I've done.. at the moment it is in {{kiegroup/kie-wb-common}} however this uses the old AppFormer repository that lacks the work [~porcelli] has done in a new repository to support Submarine. WHEN [~porcelli] work is moved to the kie Submarine repositories then I think, once my Submarine specific work in {{kiegroup/kie-wb-common}} can move there too and we can begin to run in VSCode. [~porcelli] thoughts?
{quote}
How are we both going to work on this...
{quote}
Well, my branch is "work in progress" at the moment. I hope to complete the work today and submit a PR for {{kiegroup/kie-wb-common@master}} this week (the sooner the better). Then you can make BPMN work "as good as" the DMN standalone in {{kiegroup/kie-wb-comon}}. This would make it simple to then run from VSCode once the necessary repository is setup and any outstanding move/integration work completes.
{quote}
I see all editors being refactored, also the DMN webapp too
{quote}
Yes, my work covering all _Stunner_ editors (not all!) is to support using the same _core_ editor codebase ongoing in both 7.x and 8.x (Submarine). I think I've covered what I'd see as the next steps in my narrative above.. i.e. once my outstanding changes are complete and moved to {{kiegroup/kie-wb-common}} you can make similar changes to BPMN's standalone webapp (following those made to DMN) to make a VSCode compatible webapp.
{quote}
Also I cannot find yet where this branch is integrated with the {{EditorPresenter}}
{quote}
Me neither! This was [~porcelli] work and he needs to communicate where/how we run in VSCode. This ties in with other comments I've made here.
> [DMN Designer] Quick Silver: Minimal standalone preparation
> -----------------------------------------------------------
>
> Key: DROOLS-3727
> URL: https://issues.jboss.org/browse/DROOLS-3727
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Critical
> Labels: Stunner, drools-tools, submarine
> Fix For: 8.0.0.Final
>
>
> Prepare a minimal DMN Designer standalone WAR that only supports _standalone_ mode.
> No Home Page, no Library, No preferences, no other editors.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11930) Allow Java EE Subsystem to enable/disable descriptor based property replacement for descriptors managed by Wildfly Core
by Yeray Borges (Jira)
Yeray Borges created WFLY-11930:
-----------------------------------
Summary: Allow Java EE Subsystem to enable/disable descriptor based property replacement for descriptors managed by Wildfly Core
Key: WFLY-11930
URL: https://issues.jboss.org/browse/WFLY-11930
Project: WildFly
Issue Type: Feature Request
Components: Build System
Reporter: Yeray Borges
Assignee: Yeray Borges
The EE subsystem can be used to enable/disable property replacement and expansion for specific Wildfly descriptors using the following attributes:
*jboss-descriptor-property-replacement*: It is used to enable or disable property replacement in JBoss/WildFly (vendor specific) descriptors:
* jboss-ejb3.xml
* jboss-app.xml
* jboss-web.xml
*-jms.xml
*-ds.xml
*spec-descriptor-property-replacement*: It is used to enable or disable property replacement in spec descriptors:
* ejb-jar.xml
* persistence.xml
Due to WFCORE-2147, we are going to enable property replacement and expansion in descriptors parsed by Wildfly-core:
* permissions.xml (spec)
* jboss-permissions.xml (vendor specific)
* jboss-all.xml (vendor specific)
* jboss-deployment-structure.xml (vendor specific)
This feature request is opened to track the required changes in Java EE subsystem to expand this property replacements to Widfly-core specifc descriptors.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFCORE-4309) Value validator for 'host-context-map' attribute of 'server-ssl-sni-context' resource
by Diana Vilkolakova (Jira)
[ https://issues.jboss.org/browse/WFCORE-4309?page=com.atlassian.jira.plugi... ]
Diana Vilkolakova commented on WFCORE-4309:
-------------------------------------------
[~jstourac] Hello. Since hostnames cannot contain slashes, double backslash should not be allowed as an input. And in the description of this issue is written that "..example.com" should be invalid , however looking at the issues you linked, this should be valid as dot in this case means any character. But "\.\.example.com" should be invalid. However you are right that the merged changes must be updated. Thanks!
> Value validator for 'host-context-map' attribute of 'server-ssl-sni-context' resource
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-4309
> URL: https://issues.jboss.org/browse/WFCORE-4309
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Security
> Affects Versions: 7.0.0.Final
> Reporter: Jan Stourac
> Assignee: Diana Vilkolakova
> Priority: Minor
> Fix For: 9.0.0.Beta2
>
>
> There is not validation for 'host-context-map' property values on key side. There is validation for the values that represents 'server-ssl-contexts', although, there is no validation for host matching part. E.g. writing attribute of this value is possible:
> {code}
> /subsystem=elytron/server-ssl-sni-context=serverSslSniCtx:write-attribute(name=host-context-map,value={"\\?.example.com"=validSslContext,"..example.com"="validSslContext", "\\*\\*.example.com"=validSslContext})
> {code}
> {code}
> "\\?.example.com"
> "..example.com"
> "\\*\\*.example.com"
> {code}
> even though, these are invalid host name matchers IMHO. It would be nice to identify these and report those to user immediately during the configuration attempt.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2299:
--------------------------------
Hi David,
I don't know VMotions, do you have a link that provides technical insights?
> LockService does not work correctly if unlock/lock is called in immediate succession
> ------------------------------------------------------------------------------------
>
> Key: JGRP-2299
> URL: https://issues.jboss.org/browse/JGRP-2299
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Environment: Windows 10 Oracle JDK 1.8 131
> AIX IBM Java 8
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.1
>
> Attachments: JGroupsExample.java, udp+lock.xml
>
>
> In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected.
> This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded.
> If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock().
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month