[JBoss JIRA] (WFCORE-4756) Upgrade jboss-logging-tools from 2.2.0.Final to 2.2.1.Final
by James Perkins (Jira)
James Perkins created WFCORE-4756:
-------------------------------------
Summary: Upgrade jboss-logging-tools from 2.2.0.Final to 2.2.1.Final
Key: WFCORE-4756
URL: https://issues.jboss.org/browse/WFCORE-4756
Project: WildFly Core
Issue Type: Component Upgrade
Components: Logging
Reporter: James Perkins
Assignee: James Perkins
Upgrade jboss-logging-tools to 2.2.1.Final. This includes two fixes one is for Java 13 and the other is for LOGTOOL-143 which adds the index to the generated skeleton file. This file is only used for submitting the strings to the translators and changes nothing at runtime.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (LOGTOOL-143) Add positional index to the generated skeleton files for all messages
by James Perkins (Jira)
[ https://issues.jboss.org/browse/LOGTOOL-143?page=com.atlassian.jira.plugi... ]
James Perkins updated LOGTOOL-143:
----------------------------------
Fix Version/s: 2.2.1.Final
> Add positional index to the generated skeleton files for all messages
> ----------------------------------------------------------------------
>
> Key: LOGTOOL-143
> URL: https://issues.jboss.org/browse/LOGTOOL-143
> Project: Log Tool
> Issue Type: Enhancement
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Critical
> Fix For: 2.2.1.Final
>
>
> Translated languages may reorder text resulting in parameters requiring to be in a different order. If the translator does not know the index format, i.e. {{%1$s}}, the message parameters may be inserted in the incorrect order.
> We should add this index to messages generated in the skeleton file that is generally sent to translators. This should fallback to the default message if an error occurs determining the index. There should also be a way to disable this in cases where this may not be wanted or is causing issues. A message such as {{Parameter %s has an invalid value %s}} should be printed to the properties file as {{Parameter %1$s has an invalid value %2$s}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (LOGTOOL-143) Add positional index to the generated skeleton files for all messages
by James Perkins (Jira)
James Perkins created LOGTOOL-143:
-------------------------------------
Summary: Add positional index to the generated skeleton files for all messages
Key: LOGTOOL-143
URL: https://issues.jboss.org/browse/LOGTOOL-143
Project: Log Tool
Issue Type: Enhancement
Reporter: James Perkins
Assignee: James Perkins
Translated languages may reorder text resulting in parameters requiring to be in a different order. If the translator does not know the index format, i.e. {{%1$s}}, the message parameters may be inserted in the incorrect order.
We should add this index to messages generated in the skeleton file that is generally sent to translators. This should fallback to the default message if an error occurs determining the index. There should also be a way to disable this in cases where this may not be wanted or is causing issues. A message such as {{Parameter %s has an invalid value %s}} should be printed to the properties file as {{Parameter %1$s has an invalid value %2$s}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (LOGTOOL-122) Add option to always add positional parameters to generated translation files
by James Perkins (Jira)
[ https://issues.jboss.org/browse/LOGTOOL-122?page=com.atlassian.jira.plugi... ]
James Perkins closed LOGTOOL-122.
---------------------------------
Resolution: Out of Date
> Add option to always add positional parameters to generated translation files
> -----------------------------------------------------------------------------
>
> Key: LOGTOOL-122
> URL: https://issues.jboss.org/browse/LOGTOOL-122
> Project: Log Tool
> Issue Type: Enhancement
> Reporter: James Perkins
> Priority: Minor
>
> Translated languages may reorder text resulting in parameters requiring to be in a different order. If the translator does not know the positional format, i.e. {{%1$s}}, the message parameters may be inserted in the incorrect order.
> There should be an option to allow parameters to be generated with the positional properties. A message such as {{Parameter %s has an invalid value %s}} should be printed to the properties file as {{Parameter %1$s has an invalid value %2$s}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12806) Upgrade to Wildfly 17, can't find persistence unit
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-12806?page=com.atlassian.jira.plugin... ]
Darran Lofthouse resolved WFLY-12806.
-------------------------------------
Resolution: Rejected
Please make use of the user forums for help requests https://wildfly.org/gethelp/
> Upgrade to Wildfly 17, can't find persistence unit
> --------------------------------------------------
>
> Key: WFLY-12806
> URL: https://issues.jboss.org/browse/WFLY-12806
> Project: WildFly
> Issue Type: Bug
> Reporter: Emilio Cuberos
> Assignee: Brian Stansberry
> Priority: Major
> Attachments: persistence.xml
>
>
> Hi,
> Could you give us some advice? We upgraded from Java 8 / Wildfly 10, to Java 11 and Wildfly 17.
> Now the persistence units (attached persistence.xml) are no longer found:
> {code:java}
> Caused by: java.lang.IllegalArgumentException: WFLYWELD0037: Error injecting persistence unit into CDI managed bean. Can't find a persistence unit named (persistene_unit_name_here) in (war_file_name_here).war for injection point private javax.persistence.EntityManager com.hemocue.cloud.repository.UserProfileRepository.em"}}
> {code}
> Here is an example of class where we inject a persistence-unit which is present in the persistence.xml:
> {code:java}
> @Dependent
> public class ProgramRepository extends AbstractRepository<Program> {
> @PersistenceContext(unitName = "persistene_unit_name_here")
> private EntityManager em;
> @Override
> EntityManager entityManager() {
> return em;
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12806) Upgrade to Wildfly 17, can't find persistence unit
by Emilio Cuberos (Jira)
[ https://issues.jboss.org/browse/WFLY-12806?page=com.atlassian.jira.plugin... ]
Emilio Cuberos edited comment on WFLY-12806 at 11/21/19 10:43 AM:
------------------------------------------------------------------
Hi!
We would appreciate any input or ideas (on) :)
It's hard for us to explore this error, because it doesn't point to something more specific that I could fix.
And because the persistence.xml, standalone.xml, etc, should be correct since they work well with Java8/Wildfly10
was (Author: emiliocuberos):
Hi!
We would appreciate any input or ideas (on) :)
It's hard for us to explore this error, because it doesn't point to something specific that I could fix.
And because the persistence.xml, standalone.xml, etc, should be correct since they work well with Java8/Wildfly10
> Upgrade to Wildfly 17, can't find persistence unit
> --------------------------------------------------
>
> Key: WFLY-12806
> URL: https://issues.jboss.org/browse/WFLY-12806
> Project: WildFly
> Issue Type: Bug
> Reporter: Emilio Cuberos
> Assignee: Brian Stansberry
> Priority: Major
> Attachments: persistence.xml
>
>
> Hi,
> Could you give us some advice? We upgraded from Java 8 / Wildfly 10, to Java 11 and Wildfly 17.
> Now the persistence units (attached persistence.xml) are no longer found:
> {code:java}
> Caused by: java.lang.IllegalArgumentException: WFLYWELD0037: Error injecting persistence unit into CDI managed bean. Can't find a persistence unit named (persistene_unit_name_here) in (war_file_name_here).war for injection point private javax.persistence.EntityManager com.hemocue.cloud.repository.UserProfileRepository.em"}}
> {code}
> Here is an example of class where we inject a persistence-unit which is present in the persistence.xml:
> {code:java}
> @Dependent
> public class ProgramRepository extends AbstractRepository<Program> {
> @PersistenceContext(unitName = "persistene_unit_name_here")
> private EntityManager em;
> @Override
> EntityManager entityManager() {
> return em;
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12806) Upgrade to Wildfly 17, can't find persistence unit
by Emilio Cuberos (Jira)
[ https://issues.jboss.org/browse/WFLY-12806?page=com.atlassian.jira.plugin... ]
Emilio Cuberos commented on WFLY-12806:
---------------------------------------
Hi!
We would appreciate any input or ideas (on) :)
It's hard for us to explore this error, because it doesn't point to something specific that I could fix.
And because the persistence.xml, standalone.xml, etc, should be correct since they work well with Java8/Wildfly10
> Upgrade to Wildfly 17, can't find persistence unit
> --------------------------------------------------
>
> Key: WFLY-12806
> URL: https://issues.jboss.org/browse/WFLY-12806
> Project: WildFly
> Issue Type: Bug
> Reporter: Emilio Cuberos
> Assignee: Brian Stansberry
> Priority: Major
> Attachments: persistence.xml
>
>
> Hi,
> Could you give us some advice? We upgraded from Java 8 / Wildfly 10, to Java 11 and Wildfly 17.
> Now the persistence units (attached persistence.xml) are no longer found:
> {code:java}
> Caused by: java.lang.IllegalArgumentException: WFLYWELD0037: Error injecting persistence unit into CDI managed bean. Can't find a persistence unit named (persistene_unit_name_here) in (war_file_name_here).war for injection point private javax.persistence.EntityManager com.hemocue.cloud.repository.UserProfileRepository.em"}}
> {code}
> Here is an example of class where we inject a persistence-unit which is present in the persistence.xml:
> {code:java}
> @Dependent
> public class ProgramRepository extends AbstractRepository<Program> {
> @PersistenceContext(unitName = "persistene_unit_name_here")
> private EntityManager em;
> @Override
> EntityManager entityManager() {
> return em;
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12817) Configuration of Rsyslog in wildfly server
by Meriem MOUNJI (Jira)
Meriem MOUNJI created WFLY-12817:
------------------------------------
Summary: Configuration of Rsyslog in wildfly server
Key: WFLY-12817
URL: https://issues.jboss.org/browse/WFLY-12817
Project: WildFly
Issue Type: Feature Request
Reporter: Meriem MOUNJI
Assignee: Brian Stansberry
Hi Guys
Any idea about how to redirect the server.log message to syslog (var/log/messages) in wildfly 10 without using log4j configuration ?!! There is Any other solution For doing That without using Log4j.xml configuration
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4724) [DMN Designer] Do not default to a LiteralExpression when no expression is defined
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4724?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-4724:
--------------------------------
Description:
Currently, the DMN Editor will default to a blank LiteralExpression on Save if the user did not provide an expression for an element.
However Error message is reported anyway to the user:
!image-2019-11-04-19-39-01-113.png|thumbnail!
This also as the (imho undesired) side-effect that if the user was to re-open later that file, instead of a empty element, it would be a blank LiteralExpression
!image-2019-11-04-19-40-27-201.png|thumbnail!
so the current behavior is not consistent across re-open of the editor.
Let's revert this default.
The DMN Editor on save should +not+ default to a blank LiteralExpression if the user did not provide an expression for the element.
Once this change is applied from the f/e side, I am happy to be involved in order to assess which of the messages reported by the Validator or the Compiler are causing issue to the WB (if any).
Currently, the DMN Compiler will throw 1 Warning.
Currently, the DMN Validator will throw 1 Error (I can align this to be a Warn too).
Currently, the DMN Validator schema check is not reporting any XSD violation.
h2. Manual acceptance test
Try to save default / empty
h3. Business Central
- Decision node (/)
- BKM node (/)
- Cleared Function (/)
- Context entry (x) [^error.log] [^save-context.webm]
- Invocation (/)
h3. Kogito
- Decision node (/)
- BKM node (/)
- Cleared Function (/)
- Context entry (/)
- Invocation (/)
was:
Currently, the DMN Editor will default to a blank LiteralExpression on Save if the user did not provide an expression for an element.
However Error message is reported anyway to the user:
!image-2019-11-04-19-39-01-113.png|thumbnail!
This also as the (imho undesired) side-effect that if the user was to re-open later that file, instead of a empty element, it would be a blank LiteralExpression
!image-2019-11-04-19-40-27-201.png|thumbnail!
so the current behavior is not consistent across re-open of the editor.
Let's revert this default.
The DMN Editor on save should +not+ default to a blank LiteralExpression if the user did not provide an expression for the element.
Once this change is applied from the f/e side, I am happy to be involved in order to assess which of the messages reported by the Validator or the Compiler are causing issue to the WB (if any).
Currently, the DMN Compiler will throw 1 Warning.
Currently, the DMN Validator will throw 1 Error (I can align this to be a Warn too).
Currently, the DMN Validator schema check is not reporting any XSD violation.
h2. Manual acceptance test
Try to save default / empty
h3. Business Central
- Decision node (/)
- BKM node (/)
- Cleared Function (/)
- Context entry (x)
- Invocation
h3. Kogito
- Decision node (/)
- BKM node (/)
- Cleared Function (/)
- Context entry (/)
- Invocation (/)
> [DMN Designer] Do not default to a LiteralExpression when no expression is defined
> ----------------------------------------------------------------------------------
>
> Key: DROOLS-4724
> URL: https://issues.jboss.org/browse/DROOLS-4724
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: error.log, image-2019-11-04-19-39-01-113.png, image-2019-11-04-19-40-27-201.png, save-context.webm
>
>
> Currently, the DMN Editor will default to a blank LiteralExpression on Save if the user did not provide an expression for an element.
> However Error message is reported anyway to the user:
> !image-2019-11-04-19-39-01-113.png|thumbnail!
> This also as the (imho undesired) side-effect that if the user was to re-open later that file, instead of a empty element, it would be a blank LiteralExpression
> !image-2019-11-04-19-40-27-201.png|thumbnail!
> so the current behavior is not consistent across re-open of the editor.
> Let's revert this default.
> The DMN Editor on save should +not+ default to a blank LiteralExpression if the user did not provide an expression for the element.
> Once this change is applied from the f/e side, I am happy to be involved in order to assess which of the messages reported by the Validator or the Compiler are causing issue to the WB (if any).
> Currently, the DMN Compiler will throw 1 Warning.
> Currently, the DMN Validator will throw 1 Error (I can align this to be a Warn too).
> Currently, the DMN Validator schema check is not reporting any XSD violation.
> h2. Manual acceptance test
> Try to save default / empty
> h3. Business Central
> - Decision node (/)
> - BKM node (/)
> - Cleared Function (/)
> - Context entry (x) [^error.log] [^save-context.webm]
> - Invocation (/)
> h3. Kogito
> - Decision node (/)
> - BKM node (/)
> - Cleared Function (/)
> - Context entry (/)
> - Invocation (/)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4724) [DMN Designer] Do not default to a LiteralExpression when no expression is defined
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4724?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-4724:
--------------------------------
Attachment: save-context.webm
> [DMN Designer] Do not default to a LiteralExpression when no expression is defined
> ----------------------------------------------------------------------------------
>
> Key: DROOLS-4724
> URL: https://issues.jboss.org/browse/DROOLS-4724
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: error.log, image-2019-11-04-19-39-01-113.png, image-2019-11-04-19-40-27-201.png, save-context.webm
>
>
> Currently, the DMN Editor will default to a blank LiteralExpression on Save if the user did not provide an expression for an element.
> However Error message is reported anyway to the user:
> !image-2019-11-04-19-39-01-113.png|thumbnail!
> This also as the (imho undesired) side-effect that if the user was to re-open later that file, instead of a empty element, it would be a blank LiteralExpression
> !image-2019-11-04-19-40-27-201.png|thumbnail!
> so the current behavior is not consistent across re-open of the editor.
> Let's revert this default.
> The DMN Editor on save should +not+ default to a blank LiteralExpression if the user did not provide an expression for the element.
> Once this change is applied from the f/e side, I am happy to be involved in order to assess which of the messages reported by the Validator or the Compiler are causing issue to the WB (if any).
> Currently, the DMN Compiler will throw 1 Warning.
> Currently, the DMN Validator will throw 1 Error (I can align this to be a Warn too).
> Currently, the DMN Validator schema check is not reporting any XSD violation.
> h2. Manual acceptance test
> Try to save default / empty
> h3. Business Central
> - Decision node (/)
> - BKM node (/)
> - Cleared Function (/)
> - Context entry (x)
> - Invocation
> h3. Kogito
> - Decision node (/)
> - BKM node (/)
> - Cleared Function (/)
> - Context entry (/)
> - Invocation (/)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months