[JBoss JIRA] (DROOLS-2184) UX design DRD logic table actions
by Amy Glass (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2184?page=com.atlassian.jira.plugi... ]
Amy Glass commented on DROOLS-2184:
-----------------------------------
[~uxdlc] Good points.
I was reading the article [~srambach] posted this morning about table design (https://uxdesign.cc/designing-tables-for-reusability-490a3760533 ) and I think that's what got me thinking about this particular rules table design. Might be worth researching other ways to approach making the interactions in the table more visible. Some of the examples in that article show a pencil in a cell when a cell can be edited, and a kabob menu on the row (right end) showing that the row has additional actions. That kind of approach would speak to your first question "where to kabob?"
Agree about the small click target and need to think about that. Perhaps using a combination of having the kabob while also making the area in which it appears to be clickable might be a compromise, providing the visual clue that actions exist but not limiting selection to just 16x16 px.
True that this rules table design is more complex than those shown in PF. Perhaps ultimately whatever solution we come up with here to address more complicated multilayered tables could be contributed back to PF.
> UX design DRD logic table actions
> ---------------------------------
>
> Key: DROOLS-2184
> URL: https://issues.jboss.org/browse/DROOLS-2184
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam
> Attachments: DMN Editor UX - Logic_ 2184 - Google Docs.pdf, Screen Shot 2018-01-19 at 3.22.15 PM.png, Screen Shot 2018-01-19 at 3.22.25 PM.png, Screen Shot 2018-01-19 at 3.23.31 PM.png, kebab-dmn.png, kebab-where.png
>
>
> Use case description:
As a business user (Citizen Developer…), I want to easily create, edit, and refine business decision logic (tables, expressions, boxed expression, etc.) Note: Using inline controls and employ autocomplete capabilities where possible.
> Verification Conditions
> * The user of this feature is able to easily/quickly perform key actions (Add, Remove, Edit) in logic tables, boxed expressions, and the like.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-2184) UX design DRD logic table actions
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2184?page=com.atlassian.jira.plugi... ]
Liz Clayton edited comment on DROOLS-2184 at 2/5/18 1:55 PM:
-------------------------------------------------------------
[~aglass] Responding to your comment/feedback added to the google doc:
_"...- since so many of our PF tables and lists use a kabob button to launch menus with actions, would you consider using that button to bring up the menu, rather on relying on the user to learn and discover that clicking produces a menu...." _
Some concerns with using the kebab, from my perspective:
* *Where to kebab menu?* Actions could be performed on a numbers of elements within the table (cell, row, table, nested table...) So the kebab needs to work universally well in a variety of possible presentations, and it needs to be in a consistent location so the user can expect where to find it.
- If it were placed in the left side of the item it might visually conflict with content. Even if labels were center-aligned, expressions and other cell content will most likely need to be left aligned. Probably less of a concern for right alignment, but then it might not be a very visible affordance on very large tables (say if your visual focus is on the left, such as adding a row, etc.) Center seems the less problematic, but then it might get visually lost unless you provide some highlight treatment to the selection area.
!kebab-where.png|thumbnail!
* If providing cell background highlight treatment to improve visibility of the kebab/selection, it can't be too dark or it might reduce the contrast of the underlying text making it less legible/readable. Equally undesirable imo would be too obscure the color coding provided on some cell types (input versus output or etc.).
!kebab-dmn.png|thumbnail!
* *Click target:* If the menu may only be initiated by using then kebab, then you're reducing the click target from being the entire area to that one button, which will most likely need to be fairly small to fit in every cell. Or if you don't require the user to click on the kebab itself but anywhere in the cell/row/table, then the menu should spawn next to the click rather than next to the kebab (which might be unusual.)
* *On PatternFly*: Originally PF recommended the kebab to be used in conjunction with action buttons. Instead of offering a lot of buttons, user would be presented with a Primary, maybe Secondary button/action, then the rest would be placed within the kebab menu. Seems like the use of the kebab has expanded beyond this, but I can't find usage guidelines to support it. I would argue that this type of table is unique to what's available through PF currently.
was (Author: uxdlc):
[~aglass] Responding to your comment/feedback added to the google doc:
_"...- since so many of our PF tables and lists use a kabob button to launch menus with actions, would you consider using that button to bring up the menu, rather on relying on the user to learn and discover that clicking produces a menu...." _
Some concerns with using the kebab, from my perspective:
* *Where to kebab menu?* Actions could be performed on a numbers of elements within the table (cell, row, table, nested table...) So the kebab needs to work universally well in a variety of possible presentations, and it needs to be in a consistent location so the user can expect where to find it.
- If it were placed in the left side of the item it might visually conflict with context. Even if labels were center-aligned, expressions and other cell content will most likely need to be left aligned. Probably less of a concern for right alignment, but then it might not be a very visible affordance on very large tables (say if your visual focus is on the left, such as adding a row, etc.) Center seems the less problematic, but then it might get visually lost unless you provide some highlight treatment to the selection area.
!kebab-where.png|thumbnail!
* If providing cell background highlight treatment to improve visibility of the kebab/selection, it can't be too dark or it might reduce the contrast of the underlying text making it less legible/readable. Equally undesirable imo would be too obscure the color coding provided on some cell types (input versus output or etc.).
!kebab-dmn.png|thumbnail!
* *Click target:* If the menu may only be initiated by using then kebab, then you're reducing the click target from being the entire area to that one button, which will most likely need to be fairly small to fit in every cell. Or if you don't require the user to click on the kebab itself but anywhere in the cell/row/table, then the menu should spawn next to the click rather than next to the kebab (which might be unusual.)
* *On PatternFly*: Originally PF recommended the kebab to be used in conjunction with action buttons. Instead of offering a lot of buttons, user would be presented with a Primary, maybe Secondary button/action, then the rest would be placed within the kebab menu. Seems like the use of the kebab has expanded beyond this, but I can't find usage guidelines to support it. I would argue that this type of table is unique to what's available through PF currently.
> UX design DRD logic table actions
> ---------------------------------
>
> Key: DROOLS-2184
> URL: https://issues.jboss.org/browse/DROOLS-2184
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam
> Attachments: DMN Editor UX - Logic_ 2184 - Google Docs.pdf, Screen Shot 2018-01-19 at 3.22.15 PM.png, Screen Shot 2018-01-19 at 3.22.25 PM.png, Screen Shot 2018-01-19 at 3.23.31 PM.png, kebab-dmn.png, kebab-where.png
>
>
> Use case description:
As a business user (Citizen Developer…), I want to easily create, edit, and refine business decision logic (tables, expressions, boxed expression, etc.) Note: Using inline controls and employ autocomplete capabilities where possible.
> Verification Conditions
> * The user of this feature is able to easily/quickly perform key actions (Add, Remove, Edit) in logic tables, boxed expressions, and the like.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-2184) UX design DRD logic table actions
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2184?page=com.atlassian.jira.plugi... ]
Liz Clayton edited comment on DROOLS-2184 at 2/5/18 1:45 PM:
-------------------------------------------------------------
[~aglass] Responding to your comment/feedback added to the google doc:
_"...- since so many of our PF tables and lists use a kabob button to launch menus with actions, would you consider using that button to bring up the menu, rather on relying on the user to learn and discover that clicking produces a menu...." _
Some concerns with using the kebab, from my perspective:
* *Where to kebab menu?* Actions could be performed on a numbers of elements within the table (cell, row, table, nested table...) So the kebab needs to work universally well in a variety of possible presentations, and it needs to be in a consistent location so the user can expect where to find it.
- If it were placed in the left side of the item it might visually conflict with context. Even if labels were center-aligned, expressions and other cell content will most likely need to be left aligned. Probably less of a concern for right alignment, but then it might not be a very visible affordance on very large tables (say if your visual focus is on the left, such as adding a row, etc.) Center seems the less problematic, but then it might get visually lost unless you provide some highlight treatment to the selection area.
!kebab-where.png|thumbnail!
* If providing cell background highlight treatment to improve visibility of the kebab/selection, it can't be too dark or it might reduce the contrast of the underlying text making it less legible/readable. Equally undesirable imo would be too obscure the color coding provided on some cell types (input versus output or etc.).
!kebab-dmn.png|thumbnail!
* *Click target:* If the menu may only be initiated by using then kebab, then you're reducing the click target from being the entire area to that one button, which will most likely need to be fairly small to fit in every cell. Or if you don't require the user to click on the kebab itself but anywhere in the cell/row/table, then the menu should spawn next to the click rather than next to the kebab (which might be unusual.)
* *On PatternFly*: Originally PF recommended the kebab to be used in conjunction with action buttons. Instead of offering a lot of buttons, user would be presented with a Primary, maybe Secondary button/action, then the rest would be placed within the kebab menu. Seems like the use of the kebab has expanded beyond this, but I can't find usage guidelines to support it. I would argue that this type of table is unique to what's available through PF currently.
was (Author: uxdlc):
[~aglass] Responding to your comment/feedback added to the google doc:
_"...- since so many of our PF tables and lists use a kabob button to launch menus with actions, would you consider using that button to bring up the menu, rather on relying on the user to learn and discover that clicking produces a menu...." _
Some concerns with using the kebab, from my perspective:
* *Where to kebab menu?* Actions could be performed on a numbers of elements within the table (cell, row, table, nested table...) So the kebab needs to work universally well in a variety of possible presentations, and it needs to be in a consistent location so the user can expect where to find it.
- If it were placed in the left side of the item it might visually conflict with context. Even if labels were center-aligned, expressions and other cell content will most likely need to be left aligned. Probably less of a concern for right alignment, but then it might not be a very visible affordance on very large tables (say if your visual focus is on the left, such as adding a row, etc.) Center seems the less problematic, but then it might get visually lost unless you provide some highlight treatment to the selection area.
!kebab-where.png|thumbnail!
* If providing cell background highlight treatment to improve visibility of the kebab/selection, it can't be too dark or it might reduce the contrast of the underlying text making it less legible/readable. Equally undesirable imo would be too obscure the color coding provided on some cell types (input versus output or etc.).
!kebab-dmn.png|thumbnail!
**Click target:* If the menu may only be initiated by using then kebab, then you're reducing the click target from being the entire area to that one button, which will most likely need to be fairly small to fit in every cell. Or if you don't require the user to click on the kebab itself but anywhere in the cell/row/table, then the menu should spawn next to the click rather than next to the kebab (which might be unusual.)
* *On PatternFly*: Originally PF recommended the kebab to be used in conjunction with action buttons. Instead of offering a lot of buttons, user would be presented with a Primary, maybe Secondary button/action, then the rest would be placed within the kebab menu. Seems like the use of the kebab has expanded beyond this, but I can't find usage guidelines to support it. I would argue that this type of table is unique to what's available through PF currently.
> UX design DRD logic table actions
> ---------------------------------
>
> Key: DROOLS-2184
> URL: https://issues.jboss.org/browse/DROOLS-2184
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam
> Attachments: DMN Editor UX - Logic_ 2184 - Google Docs.pdf, Screen Shot 2018-01-19 at 3.22.15 PM.png, Screen Shot 2018-01-19 at 3.22.25 PM.png, Screen Shot 2018-01-19 at 3.23.31 PM.png, kebab-dmn.png, kebab-where.png
>
>
> Use case description:
As a business user (Citizen Developer…), I want to easily create, edit, and refine business decision logic (tables, expressions, boxed expression, etc.) Note: Using inline controls and employ autocomplete capabilities where possible.
> Verification Conditions
> * The user of this feature is able to easily/quickly perform key actions (Add, Remove, Edit) in logic tables, boxed expressions, and the like.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-2184) UX design DRD logic table actions
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2184?page=com.atlassian.jira.plugi... ]
Liz Clayton edited comment on DROOLS-2184 at 2/5/18 1:44 PM:
-------------------------------------------------------------
[~aglass] Responding to your comment/feedback added to the google doc:
_"...- since so many of our PF tables and lists use a kabob button to launch menus with actions, would you consider using that button to bring up the menu, rather on relying on the user to learn and discover that clicking produces a menu...." _
Some concerns with using the kebab, from my perspective:
* *Where to kebab menu?* Actions could be performed on a numbers of elements within the table (cell, row, table, nested table...) So the kebab needs to work universally well in a variety of possible presentations, and it needs to be in a consistent location so the user can expect where to find it.
- If it were placed in the left side of the item it might visually conflict with context. Even if labels were center-aligned, expressions and other cell content will most likely need to be left aligned. Probably less of a concern for right alignment, but then it might not be a very visible affordance on very large tables (say if your visual focus is on the left, such as adding a row, etc.) Center seems the less problematic, but then it might get visually lost unless you provide some highlight treatment to the selection area.
!kebab-where.png|thumbnail!
* If providing cell background highlight treatment to improve visibility of the kebab/selection, it can't be too dark or it might reduce the contrast of the underlying text making it less legible/readable. Equally undesirable imo would be too obscure the color coding provided on some cell types (input versus output or etc.).
!kebab-dmn.png|thumbnail!
**Click target:* If the menu may only be initiated by using then kebab, then you're reducing the click target from being the entire area to that one button, which will most likely need to be fairly small to fit in every cell. Or if you don't require the user to click on the kebab itself but anywhere in the cell/row/table, then the menu should spawn next to the click rather than next to the kebab (which might be unusual.)
* *On PatternFly*: Originally PF recommended the kebab to be used in conjunction with action buttons. Instead of offering a lot of buttons, user would be presented with a Primary, maybe Secondary button/action, then the rest would be placed within the kebab menu. Seems like the use of the kebab has expanded beyond this, but I can't find usage guidelines to support it. I would argue that this type of table is unique to what's available through PF currently.
was (Author: uxdlc):
[~aglass] Responding to your comment/feedback added to the google doc:
_"...- since so many of our PF tables and lists use a kabob button to launch menus with actions, would you consider using that button to bring up the menu, rather on relying on the user to learn and discover that clicking produces a menu...." _
Some concerns with using the kebab, from my perspective:
* *Where to kebab menu?* Actions could be performed on a numbers of elements within the table (cell, row, table, nested table...) So the kebab needs to work universally well in a variety of possible presentations, and it needs to be in a consistent location so the user can expect where to find it.
- If it were placed in the left side of the item it might visually conflict with context. Even if labels were center-aligned, expressions and other cell content will most likely need to be left aligned. Probably less of a concern for right alignment, but then it might not be a very visible affordance on very large tables (say if your visual focus is on the left, such as adding a row, etc.) Center seems the less problematic, but then it might get visually lost unless you provide some highlight treatment to the selection area.
!kebab-where.png|thumbnail!
* If providing cell background highlight treatment to improve visibility of the kebab/selection, it can't be too dark or it might reduce the contrast of the underlying text making it less legible/readable. Equally undesirable imo would be too obscure the color coding provided on some cell types (input versus output or etc.).
!kebab-dmn.png|thumbnail!
*Click target: If the menu may only be initiated by using then kebab, then you're reducing the click target from being the entire area to that one button, which will most likely need to be fairly small to fit in every cell. Or if you don't require the user to click on the kebab itself but anywhere in the cell/row/table, then the menu should spawn next to the click rather than next to the kebab (which might be unusual.)
* On PatternFly: Originally PF recommended the kebab to be used in conjunction with action buttons. Instead of offering a lot of buttons, user would be presented with a Primary, maybe Secondary button/action, then the rest would be placed within the kebab menu. Seems like the use of the kebab has expanded beyond this, but I can't find usage guidelines to support it. I would argue that this type of table is unique to what's available through PF currently.
> UX design DRD logic table actions
> ---------------------------------
>
> Key: DROOLS-2184
> URL: https://issues.jboss.org/browse/DROOLS-2184
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam
> Attachments: DMN Editor UX - Logic_ 2184 - Google Docs.pdf, Screen Shot 2018-01-19 at 3.22.15 PM.png, Screen Shot 2018-01-19 at 3.22.25 PM.png, Screen Shot 2018-01-19 at 3.23.31 PM.png, kebab-dmn.png, kebab-where.png
>
>
> Use case description:
As a business user (Citizen Developer…), I want to easily create, edit, and refine business decision logic (tables, expressions, boxed expression, etc.) Note: Using inline controls and employ autocomplete capabilities where possible.
> Verification Conditions
> * The user of this feature is able to easily/quickly perform key actions (Add, Remove, Edit) in logic tables, boxed expressions, and the like.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-2184) UX design DRD logic table actions
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2184?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-2184:
-------------------------------------
[~aglass] Responding to your comment/feedback added to the google doc:
_"...- since so many of our PF tables and lists use a kabob button to launch menus with actions, would you consider using that button to bring up the menu, rather on relying on the user to learn and discover that clicking produces a menu...." _
Some concerns with using the kebab, from my perspective:
* *Where to kebab menu?* Actions could be performed on a numbers of elements within the table (cell, row, table, nested table...) So the kebab needs to work universally well in a variety of possible presentations, and it needs to be in a consistent location so the user can expect where to find it.
- If it were placed in the left side of the item it might visually conflict with context. Even if labels were center-aligned, expressions and other cell content will most likely need to be left aligned. Probably less of a concern for right alignment, but then it might not be a very visible affordance on very large tables (say if your visual focus is on the left, such as adding a row, etc.) Center seems the less problematic, but then it might get visually lost unless you provide some highlight treatment to the selection area.
!kebab-where.png|thumbnail!
* If providing cell background highlight treatment to improve visibility of the kebab/selection, it can't be too dark or it might reduce the contrast of the underlying text making it less legible/readable. Equally undesirable imo would be too obscure the color coding provided on some cell types (input versus output or etc.).
!kebab-dmn.png|thumbnail!
*Click target: If the menu may only be initiated by using then kebab, then you're reducing the click target from being the entire area to that one button, which will most likely need to be fairly small to fit in every cell. Or if you don't require the user to click on the kebab itself but anywhere in the cell/row/table, then the menu should spawn next to the click rather than next to the kebab (which might be unusual.)
* On PatternFly: Originally PF recommended the kebab to be used in conjunction with action buttons. Instead of offering a lot of buttons, user would be presented with a Primary, maybe Secondary button/action, then the rest would be placed within the kebab menu. Seems like the use of the kebab has expanded beyond this, but I can't find usage guidelines to support it. I would argue that this type of table is unique to what's available through PF currently.
> UX design DRD logic table actions
> ---------------------------------
>
> Key: DROOLS-2184
> URL: https://issues.jboss.org/browse/DROOLS-2184
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam
> Attachments: DMN Editor UX - Logic_ 2184 - Google Docs.pdf, Screen Shot 2018-01-19 at 3.22.15 PM.png, Screen Shot 2018-01-19 at 3.22.25 PM.png, Screen Shot 2018-01-19 at 3.23.31 PM.png, kebab-dmn.png, kebab-where.png
>
>
> Use case description:
As a business user (Citizen Developer…), I want to easily create, edit, and refine business decision logic (tables, expressions, boxed expression, etc.) Note: Using inline controls and employ autocomplete capabilities where possible.
> Verification Conditions
> * The user of this feature is able to easily/quickly perform key actions (Add, Remove, Edit) in logic tables, boxed expressions, and the like.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-2184) UX design DRD logic table actions
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2184?page=com.atlassian.jira.plugi... ]
Liz Clayton updated DROOLS-2184:
--------------------------------
Attachment: kebab-where.png
> UX design DRD logic table actions
> ---------------------------------
>
> Key: DROOLS-2184
> URL: https://issues.jboss.org/browse/DROOLS-2184
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam
> Attachments: DMN Editor UX - Logic_ 2184 - Google Docs.pdf, Screen Shot 2018-01-19 at 3.22.15 PM.png, Screen Shot 2018-01-19 at 3.22.25 PM.png, Screen Shot 2018-01-19 at 3.23.31 PM.png, kebab-dmn.png, kebab-where.png
>
>
> Use case description:
As a business user (Citizen Developer…), I want to easily create, edit, and refine business decision logic (tables, expressions, boxed expression, etc.) Note: Using inline controls and employ autocomplete capabilities where possible.
> Verification Conditions
> * The user of this feature is able to easily/quickly perform key actions (Add, Remove, Edit) in logic tables, boxed expressions, and the like.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-2184) UX design DRD logic table actions
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2184?page=com.atlassian.jira.plugi... ]
Liz Clayton updated DROOLS-2184:
--------------------------------
Attachment: kebab-dmn.png
> UX design DRD logic table actions
> ---------------------------------
>
> Key: DROOLS-2184
> URL: https://issues.jboss.org/browse/DROOLS-2184
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam
> Attachments: DMN Editor UX - Logic_ 2184 - Google Docs.pdf, Screen Shot 2018-01-19 at 3.22.15 PM.png, Screen Shot 2018-01-19 at 3.22.25 PM.png, Screen Shot 2018-01-19 at 3.23.31 PM.png, kebab-dmn.png, kebab-where.png
>
>
> Use case description:
As a business user (Citizen Developer…), I want to easily create, edit, and refine business decision logic (tables, expressions, boxed expression, etc.) Note: Using inline controls and employ autocomplete capabilities where possible.
> Verification Conditions
> * The user of this feature is able to easily/quickly perform key actions (Add, Remove, Edit) in logic tables, boxed expressions, and the like.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3019) The bin/product.conf and the org.jboss.as.product:wildfly-core module should come in via an FP
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3019?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-3019:
----------------------------------------
Assignee: Brian Stansberry (was: James Perkins)
> The bin/product.conf and the org.jboss.as.product:wildfly-core module should come in via an FP
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-3019
> URL: https://issues.jboss.org/browse/WFCORE-3019
> Project: WildFly Core
> Issue Type: Task
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 4.0.0.Beta1
>
>
> For WFLY-4692 we moved the "product" stuff out of core-feature-pack and into dist. But this means it doesn't end up in the skinny dist produced by the "build" module. Plus it makes the "dist" a kind of FP of its own.
> The stuff in dist/src/distribution should be its own FP. That one *perhaps* depends on core-feature-pack. Then build and dist use the new FP in addition to or instead of core-feature-pack.
> So, core-feature-pack is independently usable, in other dists, but our offiical build/dist, which has our official product module, picks up the new FP.
> Whether the new "product" FP depends on core-feature-pack depends on how we want to use it; i.e. can this bin/product.conf and module be used in some other flavor of dist.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9007) The bin/product.conf and the org.jboss.as.product:<xxx> module should come in via an FP
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9007?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-9007:
--------------------------------------
Assignee: Brian Stansberry
> The bin/product.conf and the org.jboss.as.product:<xxx> module should come in via an FP
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-9007
> URL: https://issues.jboss.org/browse/WFLY-9007
> Project: WildFly
> Issue Type: Task
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 12.0.0.Alpha1
>
>
> For WFLY-4692 we moved the "product" stuff out of [servlet-]feature-pack and into [servlet-]dist. But this means it doesn't end up in the skinny dist produced by the "[servlet-]build" module. Plus it makes the "dist" a kind of FP of its own.
> The stuff in [servlet-]dist/src/distribution should be its own FP. That one *perhaps* depends on the related normal feature-pack. Then build and dist use the new FP in addition to or instead of the regular feature-pack.
> So, the regular feature-pack is independently usable, in other dists, but our offiical build/dist, which has our official product module, picks up the new FP.
> Whether the new "product" FP depends on the regular feature-pack depends on how we want to use it; i.e. can this bin/product.conf and module be used in some other flavor of dist besides the official one.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9635) jdr throws IllegalArgumentException if server is not started
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFLY-9635?page=com.atlassian.jira.plugin.... ]
Jean-Francois Denise commented on WFLY-9635:
--------------------------------------------
[~bmaxwell], I found the root cause of the issue, it has been caused by: "Fix for WFCORE-2241. Memory leak in CLI class". It requires a fix in CLI class. You can assign it to me.
> jdr throws IllegalArgumentException if server is not started
> ------------------------------------------------------------
>
> Key: WFLY-9635
> URL: https://issues.jboss.org/browse/WFLY-9635
> Project: WildFly
> Issue Type: Bug
> Components: JDR
> Reporter: Marek Kopecký
> Assignee: Brad Maxwell
> Priority: Blocker
> Attachments: jboss-eap-7.1.0.log, wildfly-11.0.0.Final.log
>
>
> *Description of the issue:*
> jdr throws IllegalArgumentException if server is not started
> *Steps to reproduce:*
> # do *not* start the server
> # ./jdr.sh
> *Actual results:*
> {noformat}
> [mkopecky@dhcp-10-40-4-226 bin]$ ./jdr.sh
> Initializing JBoss Diagnostic Reporter...
> Trying to connect to http-remoting localhost:9990
> Starting embedded server
> Exception for embed-server --std-out=echo : Task java.util.concurrent.FutureTask@6631f5ca rejected from java.util.concurrent.ThreadPoolExecutor@5ace1ed4[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> Exception for stop-embedded-server: Task java.util.concurrent.FutureTask@31e5415e rejected from java.util.concurrent.ThreadPoolExecutor@5ace1ed4[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> Exception in thread "main" java.lang.IllegalArgumentException: Error handling command: /subsystem=jdr:generate-jdr-report()
> at org.jboss.as.cli.scriptsupport.CLI.cmd(CLI.java:248)
> at org.jboss.as.jdr.CommandLineMain.main(CommandLineMain.java:120)
> at org.jboss.modules.Module.run(Module.java:344)
> at org.jboss.modules.Main.main(Main.java:525)
> Caused by: org.jboss.as.cli.CommandLineException: The connection to the controller has not been established.
> at org.jboss.as.cli.impl.CommandContextImpl.execute(CommandContextImpl.java:804)
> at org.jboss.as.cli.impl.CommandContextImpl.execute(CommandContextImpl.java:823)
> at org.jboss.as.cli.scriptsupport.CLI.cmd(CLI.java:241)
> ... 3 more
> [mkopecky@dhcp-10-40-4-226 bin]$
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months