I am looking at the release-2.x branch. I will set it to 1.0.0-SNAPSHOT
soon (AFK)
Gary
On Thu, Dec 10, 2020, 16:51 Ralph Goers wrote:
> Its version is currently 3.0.0-SNAPSHOT but I don’t know why. I think it
> should be set to 1.0.0. We aren’t going to do a release of log4j-tools
> very ofte
Its version is currently 3.0.0-SNAPSHOT but I don’t know why. I think it should
be set to 1.0.0. We aren’t going to do a release of log4j-tools very often.
Certainly not as frequently as log4j itself. It hardly ever changes. It needs
an independent versioning scheme.
Ralph
> On Dec 10, 2020,
I think the log4j-tools version should be set to 2.14.0 for a RC to match
the release of log4j. Thoughts?
Gary
On Thu, Dec 10, 2020, 15:45 Ralph Goers wrote:
> OK. Then I guess I forgot since it has been so long.
>
> Ralph
>
> > On Dec 10, 2020, at 1:09 PM, Gary Gregory
> wrote:
> >
> > But th
OK. Then I guess I forgot since it has been so long.
Ralph
> On Dec 10, 2020, at 1:09 PM, Gary Gregory wrote:
>
> But there *is* an allowed list of Java classes and packages configured
> in org.apache.logging.log4j.util.FilteredObjectInputStream which the
> log4j-server module's servers uses th
But there *is* an allowed list of Java classes and packages configured
in org.apache.logging.log4j.util.FilteredObjectInputStream which the
log4j-server module's servers uses through ObjectInputStreamLogEventBridge.
Gary
On Thu, Dec 3, 2020 at 10:33 AM Ralph Goers
wrote:
> There is a Jira issue
+1
On Wed, Dec 9, 2020 at 10:20 PM Ralph Goers
wrote:
> I started a discussion several days ago regarding moving Log4PHP to
> dormant status and have gotten no feedback. Given there has been no
> development activity in years and there is no one actively working on the
> project it seems it shou
