[JBoss JIRA] (DROOLS-3818) Assign a complex type object to a property with modified label leads to NPE
by Yeser Amer (Jira)
[ https://issues.jboss.org/browse/DROOLS-3818?page=com.atlassian.jira.plugi... ]
Yeser Amer updated DROOLS-3818:
-------------------------------
Description:
Steps to reproduce it:
- Open a new scenario asset
- Assign a instance (eg . Author)
- Rename it (eg. Author_test)
- Try to assign a Complex type as a property (eg. a Collection)
- A NPE is thown.
> Assign a complex type object to a property with modified label leads to NPE
> ---------------------------------------------------------------------------
>
> Key: DROOLS-3818
> URL: https://issues.jboss.org/browse/DROOLS-3818
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Reporter: Yeser Amer
> Assignee: Yeser Amer
> Priority: Major
> Labels: ScenarioSimulation
>
> Steps to reproduce it:
> - Open a new scenario asset
> - Assign a instance (eg . Author)
> - Rename it (eg. Author_test)
> - Try to assign a Complex type as a property (eg. a Collection)
> - A NPE is thown.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 6 months
[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup
by Rakesh Cherukuri (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Rakesh Cherukuri commented on WFLY-11858:
-----------------------------------------
[~ochaloup][~manovotn][~ljnelson][~mkouba]
Thanks for all your timely contribution.
Tested WildFly16-with-the-fix and the server is starting up just fine. No failures out of 50 times.
What is the plan for the fix ? Will there be a WildFlyv16.0.1 ?
> [Wildfly16] CDI fails to inject InitialContext during startup
> -------------------------------------------------------------
>
> Key: WFLY-11858
> URL: https://issues.jboss.org/browse/WFLY-11858
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Transactions
> Affects Versions: 16.0.0.Final
> Reporter: Rakesh Cherukuri
> Assignee: Matěj Novotný
> Priority: Major
> Attachments: stacktrace.log
>
>
> We are in the process of upgrading from 14.0.1.Final. While Wildfly 15.0.1 works fine, 16.0.0.Final is intermittently (3 out of 5 times) failing to start with following error
> _WELD-001334: Unsatisfied dependencies for type InitialContext with qualifiers_
> In our application, a bootstrap servlet startsup services (Stateless EJBs) during server startup. During this process the server fails to start with above error.
> Basically CDI is not able to find the appropriate InitialContext bean *intermittently*. This is not failing in our application code but in the wildfly libraries itself.
> Any pointers on this will be helpful. Don't want to end up with startup issues in stage/production :)
> Unfortunately my efforts to come up with a simplified maven module to showcase the error didn't succeed. So, please let me know if any further information is required and i will be glad to fill it in.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 6 months
[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:
--------------------------------
Description:
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).
was:
The DMN editor should support keyboard shortcuts (similar for current GDT tables) for basic operations like editing of DRD elements. This support is crucial for integration selenium testing.
In integration test we are able to select node on canvas thanks to Navigation Dock (BAPL-966). Once element is selected we need shortcuts for:
- Appending element
- Morphing element
- Renaming element
Thanks to Navigation Dock (BAPL-966) we are also able to open Context Editor (where applicable). In Context editor we need shortcuts for:
- Navigation between cells
- Invoking inline context menu
- Navigate in inline context menu
- Select item in inline context menu
- Start Editing cell
- Finish editing Cell
- Cancel editing Cell
> [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)
6 years, 6 months
[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)
6 years, 6 months
[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)
6 years, 6 months
[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)
6 years, 6 months
[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)
6 years, 6 months