[JBoss JIRA] (DROOLS-4043) inappropriate warning appear while bulding kjar
by Hiroko Miura (Jira)
[ https://issues.jboss.org/browse/DROOLS-4043?page=com.atlassian.jira.plugi... ]
Hiroko Miura updated DROOLS-4043:
---------------------------------
Description:
When bulding kjar, warning something like the following appears.
{noformat}
[WARNING] File 'src/main/resources//work/buildKjar/src/main/resources/com/sample/rules2' is in folder '.work.buildKjar.src.main.resources.com.sample.rules2' but declares package 'com.sample.rules2'. It is advised to have a correspondance between package and folder names.
[WARNING] File 'src/main/resources//work/buildKjar/src/main/resources/com/sample/rules' is in folder '.work.buildKjar.src.main.resources.com.sample.rules' but declares package 'com.sample.rules'. It is advised to have a correspondance between package and folder names.
[WARNING] File 'work/buildKjar/src/main/resources/com/sample/rules2' is in folder 'work.buildKjar.src.main.resources.com.sample.rules2' but declares package 'com.sample.rules2'. It is advised to have a correspondance between package and folder names.
[WARNING] File 'work/buildKjar/src/main/resources/com/sample/rules' is in folder 'work.buildKjar.src.main.resources.com.sample.rules' but declares package 'com.sample.rules'. It is advised to have a correspondance between package and folder names.
{noformat}
But drl are put under appropriate path which matches declared package.
{noformat}
src/main/resources/
├── com
│ └── sample
│ ├── rules
│ │ └── Sample.drl
│ └── rules2
│ └── Sample2.drl
{noformat}
This warning should not appear for this example.
In addition, path of File which is shown in this warning message looks wired.
e.g.
~~~
File 'src/main/resources//work/buildKjarTest2/src/main/resources/com/sample/rules2'
~~~
i.e. prefix ('src/main/resources/') is added to absolute path.
Therefore, it's hard to understand what is exactly wrong and warned.
was:
When bulding kjar, warning something like the following appears.
~~~
[WARNING] File 'src/main/resources//work/buildKjar/src/main/resources/com/sample/rules2' is in folder '.work.buildKjar.src.main.resources.com.sample.rules2' but declares package 'com.sample.rules2'. It is advised to have a correspondance between package and folder names.
[WARNING] File 'src/main/resources//work/buildKjar/src/main/resources/com/sample/rules' is in folder '.work.buildKjar.src.main.resources.com.sample.rules' but declares package 'com.sample.rules'. It is advised to have a correspondance between package and folder names.
[WARNING] File 'work/buildKjar/src/main/resources/com/sample/rules2' is in folder 'work.buildKjar.src.main.resources.com.sample.rules2' but declares package 'com.sample.rules2'. It is advised to have a correspondance between package and folder names.
[WARNING] File 'work/buildKjar/src/main/resources/com/sample/rules' is in folder 'work.buildKjar.src.main.resources.com.sample.rules' but declares package 'com.sample.rules'. It is advised to have a correspondance between package and folder names.
~~~
But drl are put under appropriate path which matches declared package.
~~~
src/main/resources/
├── com
│ └── sample
│ ├── rules
│ │ └── Sample.drl
│ └── rules2
│ └── Sample2.drl
~~~
This warning should not appear for this example.
In addition, path of File which is shown in this warning message looks wired.
e.g.
~~~
File 'src/main/resources//work/buildKjarTest2/src/main/resources/com/sample/rules2'
~~~
i.e. prefix ('src/main/resources/') is added to absolute path.
Therefore, it's hard to understand what is exactly wrong and warned.
> inappropriate warning appear while bulding kjar
> -----------------------------------------------
>
> Key: DROOLS-4043
> URL: https://issues.jboss.org/browse/DROOLS-4043
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.18.0.Final
> Reporter: Hiroko Miura
> Assignee: Mario Fusco
> Priority: Major
> Labels: support
> Attachments: buildKjar.zip
>
>
> When bulding kjar, warning something like the following appears.
> {noformat}
> [WARNING] File 'src/main/resources//work/buildKjar/src/main/resources/com/sample/rules2' is in folder '.work.buildKjar.src.main.resources.com.sample.rules2' but declares package 'com.sample.rules2'. It is advised to have a correspondance between package and folder names.
> [WARNING] File 'src/main/resources//work/buildKjar/src/main/resources/com/sample/rules' is in folder '.work.buildKjar.src.main.resources.com.sample.rules' but declares package 'com.sample.rules'. It is advised to have a correspondance between package and folder names.
> [WARNING] File 'work/buildKjar/src/main/resources/com/sample/rules2' is in folder 'work.buildKjar.src.main.resources.com.sample.rules2' but declares package 'com.sample.rules2'. It is advised to have a correspondance between package and folder names.
> [WARNING] File 'work/buildKjar/src/main/resources/com/sample/rules' is in folder 'work.buildKjar.src.main.resources.com.sample.rules' but declares package 'com.sample.rules'. It is advised to have a correspondance between package and folder names.
> {noformat}
> But drl are put under appropriate path which matches declared package.
> {noformat}
> src/main/resources/
> ├── com
> │ └── sample
> │ ├── rules
> │ │ └── Sample.drl
> │ └── rules2
> │ └── Sample2.drl
> {noformat}
> This warning should not appear for this example.
> In addition, path of File which is shown in this warning message looks wired.
> e.g.
> ~~~
> File 'src/main/resources//work/buildKjarTest2/src/main/resources/com/sample/rules2'
> ~~~
> i.e. prefix ('src/main/resources/') is added to absolute path.
> Therefore, it's hard to understand what is exactly wrong and warned.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-4043) inappropriate warning appear while bulding kjar
by Hiroko Miura (Jira)
[ https://issues.jboss.org/browse/DROOLS-4043?page=com.atlassian.jira.plugi... ]
Hiroko Miura updated DROOLS-4043:
---------------------------------
Description:
When bulding kjar, warning something like the following appear.
{noformat}
[WARNING] File 'src/main/resources//work/buildKjar/src/main/resources/com/sample/rules2' is in folder '.work.buildKjar.src.main.resources.com.sample.rules2' but declares package 'com.sample.rules2'. It is advised to have a correspondance between package and folder names.
[WARNING] File 'src/main/resources//work/buildKjar/src/main/resources/com/sample/rules' is in folder '.work.buildKjar.src.main.resources.com.sample.rules' but declares package 'com.sample.rules'. It is advised to have a correspondance between package and folder names.
[WARNING] File 'work/buildKjar/src/main/resources/com/sample/rules2' is in folder 'work.buildKjar.src.main.resources.com.sample.rules2' but declares package 'com.sample.rules2'. It is advised to have a correspondance between package and folder names.
[WARNING] File 'work/buildKjar/src/main/resources/com/sample/rules' is in folder 'work.buildKjar.src.main.resources.com.sample.rules' but declares package 'com.sample.rules'. It is advised to have a correspondance between package and folder names.
{noformat}
But drl are put under appropriate path which matches declared package.
{noformat}
src/main/resources/
├── com
│ └── sample
│ ├── rules
│ │ └── Sample.drl
│ └── rules2
│ └── Sample2.drl
{noformat}
This warning should not appear for this example.
In addition, path of File which is shown in this warning message looks wired.
e.g.
~~~
File 'src/main/resources//work/buildKjarTest2/src/main/resources/com/sample/rules2'
~~~
i.e. prefix ('src/main/resources/') is added to absolute path.
Therefore, it's hard to understand what is exactly wrong and warned.
was:
When bulding kjar, warning something like the following appears.
{noformat}
[WARNING] File 'src/main/resources//work/buildKjar/src/main/resources/com/sample/rules2' is in folder '.work.buildKjar.src.main.resources.com.sample.rules2' but declares package 'com.sample.rules2'. It is advised to have a correspondance between package and folder names.
[WARNING] File 'src/main/resources//work/buildKjar/src/main/resources/com/sample/rules' is in folder '.work.buildKjar.src.main.resources.com.sample.rules' but declares package 'com.sample.rules'. It is advised to have a correspondance between package and folder names.
[WARNING] File 'work/buildKjar/src/main/resources/com/sample/rules2' is in folder 'work.buildKjar.src.main.resources.com.sample.rules2' but declares package 'com.sample.rules2'. It is advised to have a correspondance between package and folder names.
[WARNING] File 'work/buildKjar/src/main/resources/com/sample/rules' is in folder 'work.buildKjar.src.main.resources.com.sample.rules' but declares package 'com.sample.rules'. It is advised to have a correspondance between package and folder names.
{noformat}
But drl are put under appropriate path which matches declared package.
{noformat}
src/main/resources/
├── com
│ └── sample
│ ├── rules
│ │ └── Sample.drl
│ └── rules2
│ └── Sample2.drl
{noformat}
This warning should not appear for this example.
In addition, path of File which is shown in this warning message looks wired.
e.g.
~~~
File 'src/main/resources//work/buildKjarTest2/src/main/resources/com/sample/rules2'
~~~
i.e. prefix ('src/main/resources/') is added to absolute path.
Therefore, it's hard to understand what is exactly wrong and warned.
> inappropriate warning appear while bulding kjar
> -----------------------------------------------
>
> Key: DROOLS-4043
> URL: https://issues.jboss.org/browse/DROOLS-4043
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.18.0.Final
> Reporter: Hiroko Miura
> Assignee: Mario Fusco
> Priority: Major
> Labels: support
> Attachments: buildKjar.zip
>
>
> When bulding kjar, warning something like the following appear.
> {noformat}
> [WARNING] File 'src/main/resources//work/buildKjar/src/main/resources/com/sample/rules2' is in folder '.work.buildKjar.src.main.resources.com.sample.rules2' but declares package 'com.sample.rules2'. It is advised to have a correspondance between package and folder names.
> [WARNING] File 'src/main/resources//work/buildKjar/src/main/resources/com/sample/rules' is in folder '.work.buildKjar.src.main.resources.com.sample.rules' but declares package 'com.sample.rules'. It is advised to have a correspondance between package and folder names.
> [WARNING] File 'work/buildKjar/src/main/resources/com/sample/rules2' is in folder 'work.buildKjar.src.main.resources.com.sample.rules2' but declares package 'com.sample.rules2'. It is advised to have a correspondance between package and folder names.
> [WARNING] File 'work/buildKjar/src/main/resources/com/sample/rules' is in folder 'work.buildKjar.src.main.resources.com.sample.rules' but declares package 'com.sample.rules'. It is advised to have a correspondance between package and folder names.
> {noformat}
> But drl are put under appropriate path which matches declared package.
> {noformat}
> src/main/resources/
> ├── com
> │ └── sample
> │ ├── rules
> │ │ └── Sample.drl
> │ └── rules2
> │ └── Sample2.drl
> {noformat}
> This warning should not appear for this example.
> In addition, path of File which is shown in this warning message looks wired.
> e.g.
> ~~~
> File 'src/main/resources//work/buildKjarTest2/src/main/resources/com/sample/rules2'
> ~~~
> i.e. prefix ('src/main/resources/') is added to absolute path.
> Therefore, it's hard to understand what is exactly wrong and warned.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-4043) inappropriate warning appear while bulding kjar
by Hiroko Miura (Jira)
Hiroko Miura created DROOLS-4043:
------------------------------------
Summary: inappropriate warning appear while bulding kjar
Key: DROOLS-4043
URL: https://issues.jboss.org/browse/DROOLS-4043
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.18.0.Final
Reporter: Hiroko Miura
Assignee: Mario Fusco
Attachments: buildKjar.zip
When bulding kjar, warning something like the following appears.
~~~
[WARNING] File 'src/main/resources//work/buildKjar/src/main/resources/com/sample/rules2' is in folder '.work.buildKjar.src.main.resources.com.sample.rules2' but declares package 'com.sample.rules2'. It is advised to have a correspondance between package and folder names.
[WARNING] File 'src/main/resources//work/buildKjar/src/main/resources/com/sample/rules' is in folder '.work.buildKjar.src.main.resources.com.sample.rules' but declares package 'com.sample.rules'. It is advised to have a correspondance between package and folder names.
[WARNING] File 'work/buildKjar/src/main/resources/com/sample/rules2' is in folder 'work.buildKjar.src.main.resources.com.sample.rules2' but declares package 'com.sample.rules2'. It is advised to have a correspondance between package and folder names.
[WARNING] File 'work/buildKjar/src/main/resources/com/sample/rules' is in folder 'work.buildKjar.src.main.resources.com.sample.rules' but declares package 'com.sample.rules'. It is advised to have a correspondance between package and folder names.
~~~
But drl are put under appropriate path which matches declared package.
~~~
src/main/resources/
├── com
│ └── sample
│ ├── rules
│ │ └── Sample.drl
│ └── rules2
│ └── Sample2.drl
~~~
This warning should not appear for this example.
In addition, path of File which is shown in this warning message looks wired.
e.g.
~~~
File 'src/main/resources//work/buildKjarTest2/src/main/resources/com/sample/rules2'
~~~
i.e. prefix ('src/main/resources/') is added to absolute path.
Therefore, it's hard to understand what is exactly wrong and warned.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12087) Upgrade CXF to 3.3.3
by Jim Ma (Jira)
[ https://issues.jboss.org/browse/WFLY-12087?page=com.atlassian.jira.plugin... ]
Jim Ma updated WFLY-12087:
--------------------------
Description:
We need to remove the getClassloader permission in these tests when upgrade CXF:
* testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/suspend/AbstractTestCase.java
* testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/suspend/wsat/AtomicTransactionSuspendTestCase.java
CXF issue for this permission problem: https://issues.apache.org/jira/browse/CXF-8042
was:
We need to remove the getClassloader permission in these tests fixed when upgrade CXF:
* testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/suspend/AbstractTestCase.java
* testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/suspend/wsat/AtomicTransactionSuspendTestCase.java
https://issues.apache.org/jira/browse/CXF-8042
> Upgrade CXF to 3.3.3
> ---------------------
>
> Key: WFLY-12087
> URL: https://issues.jboss.org/browse/WFLY-12087
> Project: WildFly
> Issue Type: Task
> Components: Test Suite
> Affects Versions: 17.0.0.Alpha1
> Reporter: Jim Ma
> Assignee: Jim Ma
> Priority: Major
>
> We need to remove the getClassloader permission in these tests when upgrade CXF:
> * testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/suspend/AbstractTestCase.java
> * testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/suspend/wsat/AtomicTransactionSuspendTestCase.java
> CXF issue for this permission problem: https://issues.apache.org/jira/browse/CXF-8042
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12087) Upgrade CXF to 3.3.3
by Jim Ma (Jira)
[ https://issues.jboss.org/browse/WFLY-12087?page=com.atlassian.jira.plugin... ]
Jim Ma updated WFLY-12087:
--------------------------
Description:
We need to remove the getClassloader permission in these tests fixed when upgrade CXF:
* testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/suspend/AbstractTestCase.java
* testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/suspend/wsat/AtomicTransactionSuspendTestCase.java
https://issues.apache.org/jira/browse/CXF-8042
was:
We need to remove the getClassloader permission in these tests after CXF-8042 is fixed:
* testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/suspend/AbstractTestCase.java
* testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/suspend/wsat/AtomicTransactionSuspendTestCase.java
> Upgrade CXF to 3.3.3
> ---------------------
>
> Key: WFLY-12087
> URL: https://issues.jboss.org/browse/WFLY-12087
> Project: WildFly
> Issue Type: Task
> Components: Test Suite
> Affects Versions: 17.0.0.Alpha1
> Reporter: Jim Ma
> Assignee: Jim Ma
> Priority: Major
>
> We need to remove the getClassloader permission in these tests fixed when upgrade CXF:
> * testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/suspend/AbstractTestCase.java
> * testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/suspend/wsat/AtomicTransactionSuspendTestCase.java
> https://issues.apache.org/jira/browse/CXF-8042
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12087) Upgrade CXF to 3.3.3
by Jim Ma (Jira)
[ https://issues.jboss.org/browse/WFLY-12087?page=com.atlassian.jira.plugin... ]
Jim Ma updated WFLY-12087:
--------------------------
Description:
We need to remove the getClassloader permission in these tests after CXF-8042 is fixed:
* testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/suspend/AbstractTestCase.java
* testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/suspend/wsat/AtomicTransactionSuspendTestCase.java
was:
We need to remove the getClassloader permission in these tests after CXF-8042 is fixed:
* testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/suspend/AbstractTestCase.java
*testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/suspend/wsat/AtomicTransactionSuspendTestCase.java
> Upgrade CXF to 3.3.3
> ---------------------
>
> Key: WFLY-12087
> URL: https://issues.jboss.org/browse/WFLY-12087
> Project: WildFly
> Issue Type: Task
> Components: Test Suite
> Affects Versions: 17.0.0.Alpha1
> Reporter: Jim Ma
> Assignee: Jim Ma
> Priority: Major
>
> We need to remove the getClassloader permission in these tests after CXF-8042 is fixed:
> * testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/suspend/AbstractTestCase.java
> * testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/suspend/wsat/AtomicTransactionSuspendTestCase.java
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12087) Upgrade CXF to 3.3.3
by Jim Ma (Jira)
Jim Ma created WFLY-12087:
-----------------------------
Summary: Upgrade CXF to 3.3.3
Key: WFLY-12087
URL: https://issues.jboss.org/browse/WFLY-12087
Project: WildFly
Issue Type: Task
Components: Test Suite
Affects Versions: 17.0.0.Alpha1
Reporter: Jim Ma
Assignee: Jim Ma
We need to remove the getClassloader permission in these tests after CXF-8042 is fixed:
* testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/suspend/AbstractTestCase.java
*testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/suspend/wsat/AtomicTransactionSuspendTestCase.java
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-3731) DMN UX - More info overlaid on models.
by Roger Martinez (Jira)
[ https://issues.jboss.org/browse/DROOLS-3731?page=com.atlassian.jira.plugi... ]
Roger Martinez edited comment on DROOLS-3731 at 5/16/19 8:49 PM:
-----------------------------------------------------------------
Hey [~uxdlc]
The proposed design looks good to me yes! Just another Q - when to clear the hover tooltip that appears in case of errors? I mean by default all shapes will look as usually, and as a result of some testing or validating or whatever, some shapes will change the visualization (border, etc) and also provide a hover tooltip, that's fine. But missing when we should get back to the normal visualization state, and so until next validation, no more hover tooltips etc. A solution could be just once clicking on an empty process area itself, or providing some "clear messages" button...
[~manstis] In general I see some parts of this work which Stunner, talking about generic, could benefit from, isn't it? At least on the BPMN validations too - when validating a process would be nice to see the nodes with any error, and also the tooltip etc. Still not sure yet who will own this task, but does that makes sense for you?
Thanks!
was (Author: roger600):
Hey [~uxdlc]
The proposed design looks good to me yes! Just another Q - when to clear the hover tooltip that appears in case of errors? I mean by default all shapes will look as usually, and as a result of some testing or validating or whatever, some shapes will change the visualization (border, etc) and also provide a hover tooltip, that's fine. But missing when we should get back to the normal visualization state, and so until next validation, no more hover tooltips etc
[~manstis] In general I see some parts of this work which Stunner, talking about generic, could benefit from, isn't it? At least on the BPMN validations too - when validating a process would be nice to see the nodes with any error, and also the tooltip etc. Still not sure yet who will own this task, but does that makes sense for you?
Thanks!
> DMN UX - More info overlaid on models.
> --------------------------------------
>
> Key: DROOLS-3731
> URL: https://issues.jboss.org/browse/DROOLS-3731
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: Test-error.png, Test-errorB.png, download (1).png, download.png, graph-test-click.png, graph-test-hover.png, with_some_callouts.png
>
>
> As a practitioner, there are situations where I need to show additional information about a model... for instance: test coverage report: I need to draw a model and color code the nodes to show which nodes were executed by tests, or which rows on a DT were a match. Or when I execute a single test, what was the actual value of a given node or expression.
> Note: Maybe in read-only mode with an "overlay" on top of the model the additional metadata information. See process instance diagram design examples.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-3731) DMN UX - More info overlaid on models.
by Roger Martinez (Jira)
[ https://issues.jboss.org/browse/DROOLS-3731?page=com.atlassian.jira.plugi... ]
Roger Martinez commented on DROOLS-3731:
----------------------------------------
Hey [~uxdlc]
The proposed design looks good to me yes! Just another Q - when to clear the hover tooltip that appears in case of errors? I mean by default all shapes will look as usually, and as a result of some testing or validating or whatever, some shapes will change the visualization (border, etc) and also provide a hover tooltip, that's fine. But missing when we should get back to the normal visualization state, and so until next validation, no more hover tooltips etc
[~manstis] In general I see some parts of this work which Stunner, talking about generic, could benefit from, isn't it? At least on the BPMN validations too - when validating a process would be nice to see the nodes with any error, and also the tooltip etc. Still not sure yet who will own this task, but does that makes sense for you?
Thanks!
> DMN UX - More info overlaid on models.
> --------------------------------------
>
> Key: DROOLS-3731
> URL: https://issues.jboss.org/browse/DROOLS-3731
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: Test-error.png, Test-errorB.png, download (1).png, download.png, graph-test-click.png, graph-test-hover.png, with_some_callouts.png
>
>
> As a practitioner, there are situations where I need to show additional information about a model... for instance: test coverage report: I need to draw a model and color code the nodes to show which nodes were executed by tests, or which rows on a DT were a match. Or when I execute a single test, what was the actual value of a given node or expression.
> Note: Maybe in read-only mode with an "overlay" on top of the model the additional metadata information. See process instance diagram design examples.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFCORE-606) Accessing attribute message from class LoggingEvent always returns class String
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFCORE-606?page=com.atlassian.jira.plugin... ]
James Perkins closed WFCORE-606.
--------------------------------
Resolution: Won't Fix
I'm closing this as won't fix, however if you feel this should be relooked at please feel free to reopen this.
> Accessing attribute message from class LoggingEvent always returns class String
> -------------------------------------------------------------------------------
>
> Key: WFCORE-606
> URL: https://issues.jboss.org/browse/WFCORE-606
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Logging
> Environment: Windows 7, JDK 1.7.0_51
> Reporter: Jörg Brück
> Assignee: James Perkins
> Priority: Minor
>
> After Changing from JBoss 5.1.0 to Wildfly the behaviour of my own written Log4j appenders
> have changed while accessing LoggingEvent in the function "append" of
> class ApppenderSkeleton.
> The reason of this behaviour is the implementation of org.apache.log4j.spi.LoggingEvent
> public LoggingEvent(String fqnOfCategoryClass, Category logger, long timeStamp, Priority level, Object message, Throwable throwable) {
> this.fqnOfCategoryClass = fqnOfCategoryClass;
> this.logger = logger;
> this.level = level;
> logRecord = new ExtLogRecord(JBossLevelMapping.getLevelFor(level), message == null ? null : message.toString(), ExtLogRecord.FormatStyle.NO_FORMAT, fqnOfCategoryClass);
> The Object message is converted to string and saved in Class ExtLogRecord.
> Here the implementation of getMessage:
> public Object getMessage() {
> return logRecord.getMessage();
> }
> Here the implementation of getMessage of ExtLogRecord
> public String getMessage() {
> return message;
> }
> Because of this String is always returned.
> If I understand this code right you can transfer every object to log4j, but you can not access this objects
> in an appender because of the LoggingEvent constructor where method toString is called.
> What is the reason of this change in contrast to jboss 5.1.0?
> Of course I can reconstruct my objects from the string if I overwrite the toString method.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months