No shims are needed for plugins. The plugin manager still recognizes and
handles the .dat files. The annotation processor just won’t generate them any
more.
Ralph
> On Aug 21, 2019, at 1:34 PM, Matt Sicker wrote:
>
> Depending on API changes, we might just need a 2.x API shim. Say for
> examp
Depending on API changes, we might just need a 2.x API shim. Say for
example I have a custom plugin written for 2.x; it would be great if
that still works fine in 3.x using said shim. I have some ideas
brewing about plugin ASTs and transformations between them that might
make this more manageable (
Hi Ralph,
thank you for your response, I'll be creating the issue shortly.
Il giorno mer 21 ago 2019 alle ore 13:37 Apache
ha scritto:
> It hasn’t been discussed. Feel free to create a Jira issue and a pull
> request. Please make sure you include a test for your change.
>
> Ralph
>
> > On Aug
That may be more of a documentation task. Although I had to remove revapi from
3.0 due to all the changes I doubt they will impact very many users. I know the
work I did on moving the plugin support is backward compatible.
Ralph
> On Aug 21, 2019, at 10:27 AM, Matt Sicker wrote:
>
> Plus the
Plus the story of how we approach backward compatibility with 2.x in
3.x (e.g., renamed package, compatibility shims, etc.)
On Wed, 21 Aug 2019 at 12:19, Ralph Goers wrote:
>
> The stability should be fine. We have continually port all bug fixes and
> enhancements on the release-2.x branch to ma
The stability should be fine. We have continually port all bug fixes and
enhancements on the release-2.x branch to master. The main goal of 3.0 is to
split up the core module and to make each module a valid Java Module. We have
not completely finished that work. Basically, that is the only thing
Thanks, Ralph, that makes sense as a way forward.
Do you have any estimates on when 3.0 might be GA and/or an estimate of the
stability of the current snapshot release? We'll likely stick with our fork
in production until 3.0 is GA.
On Wed, Aug 21, 2019 at 12:58 PM Ralph Goers
wrote:
> I think
I think you need to try with a SNAPSHOT of 3.0. As I mentioned in a previous
email 3.0 now longer generates a .dat file but generates a Java source file
that gets compiled with your source code instead. It also requires a .service
file for ServiceLoader but those should be handled out of the bo
In 3.x, isn't this replaced by code generation? I don't recall offhand
how it names the file, so it might not even need to be concatenated
there.
For changing the format of the cache in 2.x, besides the various
transformer workarounds, I'm not sure of the implications of
completely changing the fo
That makes sense to me. Since you already have a Jira issue for it,
feel free to open a PR referencing it.
On Wed, 21 Aug 2019 at 11:00, Антон Кореньков wrote:
>
> Hi,
>
> I have a small question described under
> https://issues.apache.org/jira/browse/LOG4J2-2674. The short summary:
> CompositeC
I had a similar problem to solve a while back. I used something like
https://github.com/edwgiz/maven-shaded-log4j-transformer
Gary
On Wed, Aug 21, 2019 at 12:20 PM Gregg Donovan wrote:
> Hello!
>
> I'm working on getting Etsy's custom StackdriverJsonLayout Log4J plugin to
> work with our Bazel-
Hello!
I'm working on getting Etsy's custom StackdriverJsonLayout Log4J plugin to
work with our Bazel-based build system and wanted to run a few ideas by you.
The first problem I ran into was stdout messages breaking the
PluginProcessor annotation processor when run by Bazel. My PR here[1] fixed
Hi,
I have a small question described under
https://issues.apache.org/jira/browse/LOG4J2-2674. The short summary:
CompositeConfiguration uses ConfigurationSource.NULL_SOURCE. It's a bit
confusing value for the source field, because it has multiple sources in
fact. Do you mind to change the value
It hasn’t been discussed. Feel free to create a Jira issue and a pull request.
Please make sure you include a test for your change.
Ralph
> On Aug 21, 2019, at 12:31 AM, Federico D'Ambrosio wrote:
>
> Hello everyone,
>
> I wanted to discuss with you if it's possible or if you would consider
Hello everyone,
I wanted to discuss with you if it's possible or if you would consider
useful adding the possibility to send the LogEvent time as a timestamp for
the record when using the log4j KafkaAppender. I think it could be very
useful for everyone using Kafka as a log aggregator having the p
15 matches
Mail list logo
