Re: [PR] Recycler API (logging-log4j2)

[via GitHub]

rgoers commented on PR #1401:
URL: https://github.com/apache/logging-log4j2/pull/1401#issuecomment-1550731405

   > But things have changed, in a positive way: we now have a powerful DI 
system. Let's put that into use!
   Unfortunately, the DI system as it is today is broken. I discovered this 
when working on context properties and Matt is aware of this. The problem is 
that we have a bunch of "Constants" that really just check a property when the 
"constant" is initialized. However, that makes it impossible to make those 
LoggerContext specific. In addition, if you don't happen to have the "correct" 
Injector instance you are kind of screwed. I'm not saying these can't be fixed, 
but the DI system is not going to solve every problem in Log4j.  Certainly not 
the items I am raising here.
   
   > Yes and with any other system run by a decent DI, you shouldn't need 
static access. JTL contains the most complicated DI usage out there and there 
is not a single call to static DI.* methods.
   Yes, the DI system doesn't have a static anchor. Instead we have many DI 
instances anchored in many places. Our DI system does have static methods 
(which I don't have a problem with). Again, the DI system really has nothing to 
do with what I am asking for.
   
   > I have provided several examples demonstrating why static registries are 
bad:
   > 
   > Hinders testing
   No they don't. So long as you can register mock objects it makes no 
difference whether the registry has a static anchor or not.
   > Hinders composition (e.g., one cannot provide a PropertiesUtil 
implementation, etc.)
   Huh? That would be a horrible mistake. That is like saying you cannot 
provide a DI implementation. Somethings shouldn't be replaceable.
   > It is a bad-practice in a DI-backed system
   If our DI system worked properly I might agree with you. It does not.
   
   Note - a "Registry" does not necessarily require to be anchored by a static. 
It could very well be anchored using the DI system, if that indeed was possible 
(it currently wouldn't be).
   
   > Scoped Values are indeed on the horizon and we should cater for that. We 
might indeed need to massage the current Recycler API to accommodate that. In 
particular, scoped values require a lambda (i.e., ScopedValue.where(var, 
val).run(Runnable)), whereas our current recycler requires explicit 
acquire/release calls. These ergonomics are pretty much orthongonal. I will try 
to flesh out some Recycler API support for this.
   
   Here you are pretty much repeating back to me what I said.
   
   > I have my reservations about this Ralph. Recycler is merely an efficient 
object pool. I think requesting thread-related functionality would break that 
assumption and sophisticate the design. Do you have a particular use case in 
mind that requires, e.g., thread inheritance?
   Well of course. I have two. 
   
   1. Scoped Values. "Scoped values are automatically inherited by all child 
threads created using the StructuredTaskScope." Given that is the default I am 
sure we will want a way to disable it for certain use cases. 
   2. I am using an InheritableThreadLocal in PropretiesUtil so that when 
configuration takes place any method called, even on a child thread, will get 
the correct property sources.
   
   > Do you have a [non-hypothetical] use case in mind for the recycler sharing 
you mention?
   Well, maybe. I simply haven't looked. But we use so many ThreadLocals that I 
have a suspicion that a few of them share the same lifecycle. In that case, in 
my mind it makes sense to share the recycler.  But again, without inspecting 
every use of ThreadLocal in Log4j, no I can't firmly give you an example.
   
   > Let me again share a similar example from Spring. Imagine a Tree bean 
implementing Lifecycle.
   I have to stop you right there. The problem in Log4j is that we have several 
Lifecycles:
   
   1. The entire JVM
   2. The application instance (there can be several in a web container or 
OSGi). Generally, this will correlate to a LoggerContext.
   3. The configuration. As you know these can start and stop many times during 
the lifetime of a LoggerContext.
   4. AppenderManagers - These may live as long as the LoggerContext does or as 
short as each Configuration they are part of, depending on how the 
configuration changed.
   5. Even a LogEvent has a lifecycle of sorts.
   
   Matt made a good attempt to make the DI system deal with all these different 
lifecycles in an appropriate manner, except it doesn't quite work (which 
probably isn't the fault of the DI code itself but other stuff that he didn't 
fix - like constants that shouldn't be constants.
   
   I will not that you also didn't address the idea of using a Spec object 
instead of a simple String that directly names the implementation.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

T

Re: [PR] Bump jackson-bom from 2.15.0 to 2.15.1 (logging-log4j-samples)

[via GitHub]

github-actions[bot] merged PR #37:
URL: https://github.com/apache/logging-log4j-samples/pull/37


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[PR] Bump jackson-bom from 2.15.0 to 2.15.1 (logging-log4j-samples)

[via GitHub]

dependabot[bot] opened a new pull request, #37:
URL: https://github.com/apache/logging-log4j-samples/pull/37

   Bumps [jackson-bom](https://github.com/FasterXML/jackson-bom) from 2.15.0 to 
2.15.1.
   
   Commits
   
   https://github.com/FasterXML/jackson-bom/commit/eaff8b270acec1c7815476ad5a005fad30627145";>eaff8b2
 [maven-release-plugin] prepare release jackson-bom-2.15.1
   https://github.com/FasterXML/jackson-bom/commit/19ddbeaa47c9fdd7db17a38ae5f5ff9fb11ee750";>19ddbea
 Prepare for 2.15.1 release
   https://github.com/FasterXML/jackson-bom/commit/1c2c2fc7c60b8bc49b83fd8b98fa0dc9f683e754";>1c2c2fc
 Add version.plugin.moditect override to 
1.0.0.Final
   https://github.com/FasterXML/jackson-bom/commit/ccd5a3ae3987b7853bdd60f0646a5725768d0426";>ccd5a3a
 Merge branch '2.14' into 2.15
   https://github.com/FasterXML/jackson-bom/commit/15b0965deda49cfaa5fc9ef2f72f1a40a2cfc05c";>15b0965
 Back to snapshot deps
   https://github.com/FasterXML/jackson-bom/commit/11c0403c2b2f59874d97a2327ba436acd859f24b";>11c0403
 [maven-release-plugin] prepare for next development iteration
   https://github.com/FasterXML/jackson-bom/commit/f20350e64e59fb6018d400fe38d8c4d29165e778";>f20350e
 [maven-release-plugin] prepare release jackson-bom-2.14.3
   https://github.com/FasterXML/jackson-bom/commit/ccff9e78afebdf1c355a69a8966eda9380634fbe";>ccff9e7
 Prepare for 2.14.3 release
   https://github.com/FasterXML/jackson-bom/commit/9fd5d93ef1137537753ec4d511c1d0a5673db2da";>9fd5d93
 Merge pull request https://redirect.github.com/FasterXML/jackson-bom/issues/64";>#64 from 
FasterXML/tatu/63-upgrade-gmm-plugin-version
   https://github.com/FasterXML/jackson-bom/commit/56e0314b9a901ce7cd3930b9aa398ddec96b7793";>56e0314
 Fix https://redirect.github.com/FasterXML/jackson-bom/issues/63";>#63: 
update GMM plugin version
   Additional commits viewable in https://github.com/FasterXML/jackson-bom/compare/jackson-bom-2.15.0...jackson-bom-2.15.1";>compare
 view
   
   
   
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=com.fasterxml.jackson:jackson-bom&package-manager=maven&previous-version=2.15.0&new-version=2.15.1)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
   
   Dependabot will resolve any conflicts with this PR as long as you don't 
alter it yourself. You can also trigger a rebase manually by commenting 
`@dependabot rebase`.
   
   [//]: # (dependabot-automerge-start)
   [//]: # (dependabot-automerge-end)
   
   ---
   
   
   Dependabot commands and options
   
   
   You can trigger Dependabot actions by commenting on this PR:
   - `@dependabot rebase` will rebase this PR
   - `@dependabot recreate` will recreate this PR, overwriting any edits that 
have been made to it
   - `@dependabot merge` will merge this PR after your CI passes on it
   - `@dependabot squash and merge` will squash and merge this PR after your CI 
passes on it
   - `@dependabot cancel merge` will cancel a previously requested merge and 
block automerging
   - `@dependabot reopen` will reopen this PR if it is closed
   - `@dependabot close` will close this PR and stop Dependabot recreating it. 
You can achieve the same result by closing it manually
   - `@dependabot ignore this major version` will close this PR and stop 
Dependabot creating any more for this major version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this minor version` will close this PR and stop 
Dependabot creating any more for this minor version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this dependency` will close this PR and stop 
Dependabot creating any more for this dependency (unless you reopen the PR or 
upgrade to it yourself)
   
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [PR] Recycler API (logging-log4j2)

[via GitHub]

vy commented on PR #1401:
URL: https://github.com/apache/logging-log4j2/pull/1401#issuecomment-1550194311

   ## Dependency Injection (DI) vs Static Registries
   
   > Also, saying static registries are a problem flies in the face that Log4j 
has a ServiceRegistry, PropertiesUtil (the PropertyRegistry), a Plugin 
registry, the LoggerContext is a registry of the application's Loggers, and the 
LoggerContextSelector is a registry of the LoggerContexts.
   
   There are several JIRA tickets and mailing list threads from users (and 
committers, PMC members!) complaining that they cannot test logging without 
forking a fresh JVM each time. Since we both like Spring, let me continue with 
an example from there. Why do we need to inject `Environment` every time we 
need to deal with it rather than using a static `PropertiesUtil` just like 
Log4j does?
   
   I think hardcoding the functionality in static registries was the right 
decision when it was first introduced to Log4j; it was (still is!) convenient 
to use, the core was small, and there weren't a DI system. But things have 
changed, in a positive way: we now have a powerful DI system. Let's put that 
into use!
   
   > The DI system is also essentially a registry much as Spring's IOC is. 
There are probably more but that is just what immediately came to mind.
   
   Yes and with any other system run by a decent DI, you shouldn't need static 
access. JTL contains the most complicated DI usage out there and there is not a 
single call to static `DI.*` methods.
   
   > You would have to provide some concrete evidence that registries are a 
problem for me to buy that argument.
   
   I have provided several examples demonstrating why static registries are bad:
   
   1. Hinders testing
   2. Hinders composition (e.g., one cannot provide a `PropertiesUtil` 
implementation, etc.)
   3. It is a bad-practice in a DI-backed system
   
   I am curious to know if there is a flaw in my line of thinking.
   
   > FWIW, it is quite easy to create an intelligently designed registry be 
able to generate and use Mock objects for testing. For example, this is quite 
easy to do with Spring.
   
   Definitely! But this is all possible since nothing is statically wired but 
glued together at runtime by DI.
   
   ## Scoped Values
   
   > I am thinking of when Scoped Values come into play.
   
   Scoped Values are indeed on the horizon and we should cater for that. We 
might indeed need to massage the current Recycler API to accommodate that. In 
particular, scoped values require a lambda (i.e., `ScopedValue.where(var, 
val).run(Runnable)`), whereas our current recycler requires explicit 
acquire/release calls. These ergonomics are pretty much orthongonal. I will try 
to flesh out some Recycler API support for this.
   
   ## Requesting thread-related functionality while creating a recycler
   
   > Or if thread inheritance is required.
   
   I have my reservations about this Ralph. Recycler is merely an efficient 
object pool. I think requesting thread-related functionality would break that 
assumption and sophisticate the design. Do you have a particular use case in 
mind that requires, e.g., thread inheritance?
   
   ## Having a recycler registry
   
   > `Recycler recycler = RecyclerRegistry.get("name", spec)`
   > ...
   > 1. Different use cases to potentially share the same ThreadLocal 
(depending on their spec declaration)
   
   Do you have a [non-hypothetical] use case in mind for the recycler sharing 
you mention?
   
   > 1. Intelligent cleanup of all Recycler instances. This could be handled 
through callbacks that are part of the interface or other mechanism as we 
desire.
   
   Let me again share a similar example from Spring. Imagine a `Tree` bean 
implementing `Lifecycle`. Other beans can inject this _shared_ `Tree` bean and 
they don't need to manage the lifecycle of the `Tree` – Spring will take care 
of it. But, if the bean is prototype-scoped, that is, every injection point 
gets a new instance, Spring will not manage the bean's lifecycle anymore. I 
think what we are dealing with is somewhat analogous. If recyclers will be 
shared (of which I still need to hear a use case for), I understand the 
sentiment for having a single registry to shut them down. Otherwise, we can 
delegate that responsibility to the component creating it.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [I] JsonTemplateLayout Docs with wrong keyname appender.console.json. (logging-log4j2)

[via GitHub]

ppkarwasz commented on issue #1479:
URL: 
https://github.com/apache/logging-log4j2/issues/1479#issuecomment-1550125323

   Complex properties such a `layout` are bound **by type**: if the value of 
`.type` is a plugin name extending 
[`Layout`](https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/Layout.html)
 it will be injected into the `layout` property.
   
   This rule is necessary, since the reference configuration format (XML) does 
not give a name to its subcomponents:
   
   ```xml
   
 
   
   ```
   
   We are working on an update to our website to document these rules. In the 
meantime I would keep examples such as the one you cite to show that 
identifiers are not set in stone.
   
   The properties configuration format is full of randomly chosen identifiers, 
while the other formats are **much more concise**. You might look at those 
identifiers as splinters that appear when we squeeze a square peg (hierarchical 
configuration) into a round hole (flat properties format).


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [I] JsonTemplateLayout Docs with wrong keyname appender.console.json. (logging-log4j2)

[via GitHub]

robert-gdv commented on issue #1479:
URL: 
https://github.com/apache/logging-log4j2/issues/1479#issuecomment-1549950617

   Hmm... reviewing the docs:
   In 
https://logging.apache.org/log4j/2.x/manual/appenders.html#consoleappender a 
parameter layout is described. How does the property parser know, that 
`appender.console.!@#$%^&*().type` describes a layout?
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [I] JsonTemplateLayout Docs with wrong keyname appender.console.json. (logging-log4j2)

[via GitHub]

robert-gdv commented on issue #1479:
URL: 
https://github.com/apache/logging-log4j2/issues/1479#issuecomment-1549932531

   @ppkarwasz : In my understanding, the layout property itself is already 
arbitrary.
   So `appender.@.!@#$%^&*().type = JsonTemplateLayout` would work?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [I] JsonTemplateLayout Docs with wrong keyname appender.console.json. (logging-log4j2)

[via GitHub]

robert-gdv closed issue #1479: JsonTemplateLayout Docs with wrong keyname 
appender.console.json.
URL: https://github.com/apache/logging-log4j2/issues/1479


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (LOG4J2-3662) Don't register JMX beans by default

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17723141#comment-17723141
 ] 

Gary D. Gregory commented on LOG4J2-3662:
-

Sounds reasonable to me.

> Don't register JMX beans by default
> ---
>
> Key: LOG4J2-3662
> URL: https://issues.apache.org/jira/browse/LOG4J2-3662
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: JMX
>Reporter: Arnout Engelen
>Priority: Minor
>
> Since modern java services tend not to use JMX as heavily as they did in 
> previous decades, we should probably not register JMX beans by default.
> Note that we previously disabled JMX in LOG4J2-1119 and implemented it in 
> 608406122883eb5f4b84c7b2b7a51c04aef07842, but back then the motivation turned 
> out to be invalid.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (LOG4J2-3662) Don't register JMX beans by default

[Arnout Engelen (Jira)]

Arnout Engelen created LOG4J2-3662:
--

 Summary: Don't register JMX beans by default
 Key: LOG4J2-3662
 URL: https://issues.apache.org/jira/browse/LOG4J2-3662
 Project: Log4j 2
  Issue Type: Improvement
  Components: JMX
Reporter: Arnout Engelen


Since modern java services tend not to use JMX as heavily as they did in 
previous decades, we should probably not register JMX beans by default.

Note that we previously disabled JMX in LOG4J2-1119 and implemented it in 
608406122883eb5f4b84c7b2b7a51c04aef07842, but back then the motivation turned 
out to be invalid.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [I] JsonTemplateLayout Docs with wrong keyname appender.console.json. (logging-log4j2)

[via GitHub]

ppkarwasz commented on issue #1479:
URL: 
https://github.com/apache/logging-log4j2/issues/1479#issuecomment-1549474786

   @robert-gdv,
   
   Thank you for your report. Actually the key used for a layout can be 
**arbitrary** (e.g. `!@#$%^&*()`) as long as it does not contain a dot `.` 
character.
   
   When binding configuration values to JavaBean properties, Log4j:
   
* binds simple properties (`int`, `String`, etc.) **by name**. Therefore 
you **need** to use the `target` key to specify the target of a console 
appender,
* binds complex properties **by type**. That is why 
`appender.console.!@#$%^&*().type = JsonTemplateLayout` will work without any 
problems.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [I] Fix locale-dependent `toLowerCase()/toUpperCase()` calls (logging-log4j2)

[via GitHub]

akashshirale14 commented on issue #1281:
URL: 
https://github.com/apache/logging-log4j2/issues/1281#issuecomment-1549466270

   Hi Ammar,
Yes, you can take it.
   
   Regards,
   Akash Shirale
   
   
   
   On Tue, May 16, 2023 at 2:08 AM Ammar Yasser ***@***.***>
   wrote:
   
   > Hello, @akashshirale14 
   > Are you still working on this issue?, I'm interested to work on it.
   >
   > —
   > Reply to this email directly, view it on GitHub
   > 
,
   > or unsubscribe
   > 

   > .
   > You are receiving this because you were mentioned.Message ID:
   > ***@***.***>
   >
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org