[JBoss JIRA] (ISPN-11131) server-runtime should use log4j2
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11131?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11131:
--------------------------------
Status: Open (was: New)
> server-runtime should use log4j2
> --------------------------------
>
> Key: ISPN-11131
> URL: https://issues.redhat.com/browse/ISPN-11131
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 10.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.1.1.Final
>
>
> Currently the server uses JBoss LogManager, because that's what the WildFly server used.
> It works, but the properties-based configuration is kind of clunky: it uses almost the same format as {{java.util.logging}}, but there are differences. Also not many of our users are familiar with it: WildFly has its own logging configuration in the XML, and {{logging.properties}} is auto-generated.
> It would be better if we switched to log4j2 with a {{java.util.logging}} bridge.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-11131) server-runtime should use log4j2
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11131?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11131:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/7726
> server-runtime should use log4j2
> --------------------------------
>
> Key: ISPN-11131
> URL: https://issues.redhat.com/browse/ISPN-11131
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 10.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.1.1.Final
>
>
> Currently the server uses JBoss LogManager, because that's what the WildFly server used.
> It works, but the properties-based configuration is kind of clunky: it uses almost the same format as {{java.util.logging}}, but there are differences. Also not many of our users are familiar with it: WildFly has its own logging configuration in the XML, and {{logging.properties}} is auto-generated.
> It would be better if we switched to log4j2 with a {{java.util.logging}} bridge.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-11116) Invalidation commands should not load the previous value from the store
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11116?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11116:
-----------------------------------
Fix Version/s: 9.3.8.Final
(was: 9.3.7.Final)
> Invalidation commands should not load the previous value from the store
> -----------------------------------------------------------------------
>
> Key: ISPN-11116
> URL: https://issues.redhat.com/browse/ISPN-11116
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.3.6.Final, 9.4.17.Final, 10.0.1.Final, 10.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 9.3.8.Final, 11.0.0.Final, 9.4.18.Final, 10.1.1.Final
>
>
> {{CacheLoaderInterceptor.visitInvalidateCommand()}} loads the previous value from the store, just in case there is a {{CacheEntryInvalidated}} listener that needs the previous value. This makes invalidation mode with a shared store very costly: for every write, every node receives an invalidation command, every node reads the value from the store, and then discards it.
> But {{InvalidateCommand}} only removes entries from memory, it never removes entry from stores (either shared or private). If we don't load the previous value in the data container, there is nothing for the {{InvalidateCommand}} to do. No invalidated entry means no listener notifications, so we don't need to load the previous value or to change the behaviour of {{CacheEntryInvalidatedEvent}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-11115) Infinispan BOM should only have dependency management for its own artifacts
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11115?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11115:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Infinispan BOM should only have dependency management for its own artifacts
> ---------------------------------------------------------------------------
>
> Key: ISPN-11115
> URL: https://issues.redhat.com/browse/ISPN-11115
> Project: Infinispan
> Issue Type: Bug
> Components: Build
> Affects Versions: 10.1.0.Final
> Reporter: Stéphane Nicoll
> Assignee: Pedro Ruivo
> Priority: Major
> Fix For: 10.1.1.Final
>
>
> A BOM should usually have dependency management for the artifacts of the project. Any attempt to provide dependency management for third party artifacts can lead to clashes and warnings in Maven when two boms compete for the same artifact.
> Could you please consider removing dependency management for the transaction and cache API please?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months