You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2018/11/05 21:01:22 UTC
[log4j] Toward 3.0
Considerations for 3.0:
- Currently targeting Java 8, seems OK to keep this for now.
- Remove deprecated code
- Make BC-breaking changes as we see fit to improve impl.
- ? Update root package to include "3" to allow Log4j 1, 2, and 3 to
co-exist peacefully on the claspath. Perhaps org.apache.logging.log4j3.
- Do we need a compatibility layer for 1.2 to 3.0 and 2.x to 3.0?
- Where can we use java.time?
- Is it a goal to have Maven modules with NO optional dependencies? I think
so.
- Play nice in the Java 9 module system
- Continue to break up current Maven modules
- How can we make Core smaller?
- Should we redo our config code to use something like Jackson or Commons
Configuration? We have a lot of config code... Not sure if everything you
can do in XML is doable in JSON and YAML. YAML is gross IMO but some people
like it.
What else?
Gary
Re: [log4j] Toward 3.0
Posted by Matt Sicker <bo...@gmail.com>.
Another API I've wanted to see is a proper async API. Since we're using
Java 8, this can be based on CompletableFuture. This would be mostly useful
for appenders that use networking (so mostly the database and message queue
appenders).
A nice to have would be a stable SPI for plugins with guarantees like the
API has for backwards compatibility and the like. Java 8 helps with this
once again with default methods on interfaces.
On Mon, 5 Nov 2018 at 15:12, Carter Kozak <c4...@gmail.com> wrote:
> I'd like to consider potential API breaking refactors around
> ThrowableProxy regarding LOG4J2-2391. The jar lookup is incredibly
> expensive and creates a great deal of additional complexity.
> On Mon, Nov 5, 2018 at 4:06 PM Matt Sicker <bo...@gmail.com> wrote:
> >
> > One of my biggest bikeshedding questions I've been thinking about here
> is:
> > do we call it Log4j2 3.x or Log4j3?
> >
> > On a more serious note, yes, I'd love to see the config parsing stuff
> > redone. I like using YAML over JSON or properties files, that's for sure,
> > though XML can be nicer when the XSD has enough information for editors
> to
> > discover everything. Whether we rely on dependencies,
> shading/repackaging,
> > or a custom API, however, is an interesting discussion.
> >
> > Perhaps if we also tackle autoformatting everything and enforcing a
> > checkstyle config or similar, that would make it easier to maintain
> > multiple branches in the future for backporting bugfixes or security
> fixes.
> >
> > On Mon, 5 Nov 2018 at 15:01, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > > Considerations for 3.0:
> > >
> > > - Currently targeting Java 8, seems OK to keep this for now.
> > > - Remove deprecated code
> > > - Make BC-breaking changes as we see fit to improve impl.
> > > - ? Update root package to include "3" to allow Log4j 1, 2, and 3 to
> > > co-exist peacefully on the claspath. Perhaps org.apache.logging.log4j3.
> > > - Do we need a compatibility layer for 1.2 to 3.0 and 2.x to 3.0?
> > > - Where can we use java.time?
> > > - Is it a goal to have Maven modules with NO optional dependencies? I
> think
> > > so.
> > > - Play nice in the Java 9 module system
> > > - Continue to break up current Maven modules
> > > - How can we make Core smaller?
> > > - Should we redo our config code to use something like Jackson or
> Commons
> > > Configuration? We have a lot of config code... Not sure if everything
> you
> > > can do in XML is doable in JSON and YAML. YAML is gross IMO but some
> people
> > > like it.
> > >
> > > What else?
> > >
> > > Gary
> > >
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
>
--
Matt Sicker <bo...@gmail.com>
Re: [log4j] Toward 3.0
Posted by Carter Kozak <c4...@gmail.com>.
I'd like to consider potential API breaking refactors around
ThrowableProxy regarding LOG4J2-2391. The jar lookup is incredibly
expensive and creates a great deal of additional complexity.
On Mon, Nov 5, 2018 at 4:06 PM Matt Sicker <bo...@gmail.com> wrote:
>
> One of my biggest bikeshedding questions I've been thinking about here is:
> do we call it Log4j2 3.x or Log4j3?
>
> On a more serious note, yes, I'd love to see the config parsing stuff
> redone. I like using YAML over JSON or properties files, that's for sure,
> though XML can be nicer when the XSD has enough information for editors to
> discover everything. Whether we rely on dependencies, shading/repackaging,
> or a custom API, however, is an interesting discussion.
>
> Perhaps if we also tackle autoformatting everything and enforcing a
> checkstyle config or similar, that would make it easier to maintain
> multiple branches in the future for backporting bugfixes or security fixes.
>
> On Mon, 5 Nov 2018 at 15:01, Gary Gregory <ga...@gmail.com> wrote:
>
> > Considerations for 3.0:
> >
> > - Currently targeting Java 8, seems OK to keep this for now.
> > - Remove deprecated code
> > - Make BC-breaking changes as we see fit to improve impl.
> > - ? Update root package to include "3" to allow Log4j 1, 2, and 3 to
> > co-exist peacefully on the claspath. Perhaps org.apache.logging.log4j3.
> > - Do we need a compatibility layer for 1.2 to 3.0 and 2.x to 3.0?
> > - Where can we use java.time?
> > - Is it a goal to have Maven modules with NO optional dependencies? I think
> > so.
> > - Play nice in the Java 9 module system
> > - Continue to break up current Maven modules
> > - How can we make Core smaller?
> > - Should we redo our config code to use something like Jackson or Commons
> > Configuration? We have a lot of config code... Not sure if everything you
> > can do in XML is doable in JSON and YAML. YAML is gross IMO but some people
> > like it.
> >
> > What else?
> >
> > Gary
> >
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: [log4j] Toward 3.0
Posted by Matt Sicker <bo...@gmail.com>.
One of my biggest bikeshedding questions I've been thinking about here is:
do we call it Log4j2 3.x or Log4j3?
On a more serious note, yes, I'd love to see the config parsing stuff
redone. I like using YAML over JSON or properties files, that's for sure,
though XML can be nicer when the XSD has enough information for editors to
discover everything. Whether we rely on dependencies, shading/repackaging,
or a custom API, however, is an interesting discussion.
Perhaps if we also tackle autoformatting everything and enforcing a
checkstyle config or similar, that would make it easier to maintain
multiple branches in the future for backporting bugfixes or security fixes.
On Mon, 5 Nov 2018 at 15:01, Gary Gregory <ga...@gmail.com> wrote:
> Considerations for 3.0:
>
> - Currently targeting Java 8, seems OK to keep this for now.
> - Remove deprecated code
> - Make BC-breaking changes as we see fit to improve impl.
> - ? Update root package to include "3" to allow Log4j 1, 2, and 3 to
> co-exist peacefully on the claspath. Perhaps org.apache.logging.log4j3.
> - Do we need a compatibility layer for 1.2 to 3.0 and 2.x to 3.0?
> - Where can we use java.time?
> - Is it a goal to have Maven modules with NO optional dependencies? I think
> so.
> - Play nice in the Java 9 module system
> - Continue to break up current Maven modules
> - How can we make Core smaller?
> - Should we redo our config code to use something like Jackson or Commons
> Configuration? We have a lot of config code... Not sure if everything you
> can do in XML is doable in JSON and YAML. YAML is gross IMO but some people
> like it.
>
> What else?
>
> Gary
>
--
Matt Sicker <bo...@gmail.com>
Re: [log4j] Toward 3.0
Posted by Ralph Goers <ra...@dslextreme.com>.
I’m not surprised. My plan for the socket appender is to look at leveraging Netty. I believe it handles all of what I want to do really well.
Ralph
> On Nov 6, 2018, at 4:38 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Tue, Nov 6, 2018 at 4:10 PM Remko Popma <re...@gmail.com> wrote:
>
>> It may be wise to always include some (configurable) backoff mechanism, to
>> prevent our failover/reconnect logic from essentially initiating a denial
>> of service attack when the service appears to be unavailable.
>>
>> Not sure if we currently have this anywhere, but if we’re thinking to
>> extract some reusable failover/reconnect API let’s make the backoff
>> mechanism a first-class citizen.
>>
>
> The Socket, JMS and JDBC appenders all have reconnect logic. All slightly
> different.
>
> Gary
>
>
>>
>> Remko.
>>
>> (Shameless plug) Every java main() method deserves http://picocli.info
>>
>>> On Nov 7, 2018, at 3:32, Carter Kozak <c4...@gmail.com> wrote:
>>>
>>> It would be helpful if we could implement failover and retrial in a
>>> way that is compatible with disabling immediate flush. The current
>>> implementations may surface a failure to the attempt to log an end of
>>> batch, but don't provide a mechanism to retry queued or buffered
>>> events.
>>>
>>>> On Tue, Nov 6, 2018 at 1:31 PM Gary Gregory <ga...@gmail.com>
>> wrote:
>>>>
>>>> On Tue, Nov 6, 2018 at 11:19 AM Ralph Goers <ralph.goers@dslextreme.com
>>>
>>>> wrote:
>>>>
>>>>> The socket appender already has the ability to reconnect. It just
>> needs to
>>>>> ability to load balance or send to an alternate host if the connection
>>>>> fails.
>>>>>
>>>>
>>>> Sure, I just would like reconnection and failover to be abstracted in
>> our
>>>> core framework so that each connector does not have to re-invent the
>> wheel.
>>>>
>>>> Gary
>>>>
>>>>>
>>>>> Ralph
>>>>>
>>>>>> On Nov 6, 2018, at 11:15 AM, Gary Gregory <ga...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Speaking of failover kind of things, the JMS Appender has a reconnect
>>>>>> feature and I am wrapping up a similar feature for the JDBC Appender.
>>>>> This
>>>>>> kind of feature is a MUST for services that need to stay up and
>> running
>>>>> for
>>>>>> longer periods of time.
>>>>>>
>>>>>> It would be nice to have a reconnect feature abstracted out so that
>> all
>>>>>> appenders/managers that depend on external resources can survive these
>>>>>> resources going up and down as well as internet connections going up
>> and
>>>>>> down. That would make it much easier to implement this in all
>> appenders
>>>>>> that need it. A start would be to abstract JMS and JDBC reconnect
>> code.
>>>>>> Testing this is quite tricky of course.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Mon, Nov 5, 2018 at 9:33 PM Ralph Goers <
>> ralph.goers@dslextreme.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Some other features I need/want to do:
>>>>>>>
>>>>>>> 1. LOG4J2-1137
>>>>>>> 2. Allow the SocketAppender to specify multiple IP addresses and
>> allow
>>>>>>> either round-robining through them or failing to the next if the
>> first
>>>>>>> fails. This will provide better high availability for applications.
>>>>>>> 3. Support a ContextSelector based on Module Layers.
>>>>>>> 4. LOG4J2-2170
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>>> On Nov 5, 2018, at 9:22 PM, Ralph Goers <ralph.goers@dslextreme.com
>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> How much are we impacting the API? I don’t know that package naming
>> is
>>>>>>> required if the API is compatible. I am hoping this doesn’t impact
>> the
>>>>> API
>>>>>>> much.
>>>>>>>>
>>>>>>>> I’d prefer this just be log4j 3.x. Log4j 2 3.x is just really weird.
>>>>>>>>
>>>>>>>> I wouldn’t say a module shouldn’t have any optional dependencies
>> but it
>>>>>>> should be as few as possible. That said, because java is now
>>>>> modularized
>>>>>>> and you only get java.base by default I think log4j-core should only
>>>>>>> require that. This would mean probably only the Properties
>> configuration
>>>>>>> can remain in core.
>>>>>>>>
>>>>>>>> I’m not completely sold on replacing the configuration with Jackson
>> or
>>>>>>> Commons Configuration. First, I really like that we convert the
>>>>>>> configuration to a node tree and then process the node tree the same
>> way
>>>>>>> regardless of the configuration syntax used to construct it. Since we
>>>>>>> already use Jackson for JSON and YAML I am not sure what it means to
>>>>> redo
>>>>>>> the configuration to use something we are already using.
>>>>>>>>
>>>>>>>> I would like to have every Maven module be a JPMS module, but this
>> may
>>>>>>> still be impossible to do as not all of our dependencies have
>> declared
>>>>>>> module names yet. For example,
>>>>>>> https://github.com/LMAX-Exchange/disruptor/issues/234 <
>>>>>>> https://github.com/LMAX-Exchange/disruptor/issues/234> shows the
>>>>>>> disruptor still hasn’t done anything.
>>>>>>>>
>>>>>>>> For me, the main goal would be just “cleaning up” so the modules
>> have
>>>>>>> fewer dependencies. This also should align nicely with generating
>> JPMS
>>>>>>> modules.
>>>>>>>>
>>>>>>>> I do have new features I want to add and they don’t really require
>> 3.0
>>>>>>> to do them, but I would really like to provide good reasons to
>> upgrade
>>>>> to
>>>>>>> log4j 3.x besides internal cleanup.
>>>>>>>>
>>>>>>>> One new feature that is a high priority for me is to make Log4j more
>>>>>>> “cloud friendly”. This means being able to read and dynamically
>> update
>>>>> the
>>>>>>> logging configuration from something like Spring Cloud Configuration.
>>>>>>> Essentially this just means being able to read and monitor a file via
>>>>> HTTP
>>>>>>> instead of using only the File API.
>>>>>>>>
>>>>>>>> Also, I’d like to make another pass at performance testing to see
>> where
>>>>>>> we still have room for improvement.
>>>>>>>>
>>>>>>>> I would really, like to figure out a way to include location
>>>>> information
>>>>>>> in the log events without the overhead we have now. The only sane way
>>>>> to do
>>>>>>> it is to somehow get the information at compile time, but I just
>> haven’t
>>>>>>> been able to figure out a clever hack to make it work.
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>>> On Nov 5, 2018, at 2:01 PM, Gary Gregory <ga...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Considerations for 3.0:
>>>>>>>>>
>>>>>>>>> - Currently targeting Java 8, seems OK to keep this for now.
>>>>>>>>> - Remove deprecated code
>>>>>>>>> - Make BC-breaking changes as we see fit to improve impl.
>>>>>>>>> - ? Update root package to include "3" to allow Log4j 1, 2, and 3
>> to
>>>>>>>>> co-exist peacefully on the claspath. Perhaps
>>>>> org.apache.logging.log4j3.
>>>>>>>>> - Do we need a compatibility layer for 1.2 to 3.0 and 2.x to 3.0?
>>>>>>>>> - Where can we use java.time?
>>>>>>>>> - Is it a goal to have Maven modules with NO optional
>> dependencies? I
>>>>>>> think
>>>>>>>>> so.
>>>>>>>>> - Play nice in the Java 9 module system
>>>>>>>>> - Continue to break up current Maven modules
>>>>>>>>> - How can we make Core smaller?
>>>>>>>>> - Should we redo our config code to use something like Jackson or
>>>>>>> Commons
>>>>>>>>> Configuration? We have a lot of config code... Not sure if
>> everything
>>>>>>> you
>>>>>>>>> can do in XML is doable in JSON and YAML. YAML is gross IMO but
>> some
>>>>>>> people
>>>>>>>>> like it.
>>>>>>>>>
>>>>>>>>> What else?
>>>>>>>>>
>>>>>>>>> Gary
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>
Re: [log4j] Toward 3.0
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Nov 6, 2018 at 4:10 PM Remko Popma <re...@gmail.com> wrote:
> It may be wise to always include some (configurable) backoff mechanism, to
> prevent our failover/reconnect logic from essentially initiating a denial
> of service attack when the service appears to be unavailable.
>
> Not sure if we currently have this anywhere, but if we’re thinking to
> extract some reusable failover/reconnect API let’s make the backoff
> mechanism a first-class citizen.
>
The Socket, JMS and JDBC appenders all have reconnect logic. All slightly
different.
Gary
>
> Remko.
>
> (Shameless plug) Every java main() method deserves http://picocli.info
>
> > On Nov 7, 2018, at 3:32, Carter Kozak <c4...@gmail.com> wrote:
> >
> > It would be helpful if we could implement failover and retrial in a
> > way that is compatible with disabling immediate flush. The current
> > implementations may surface a failure to the attempt to log an end of
> > batch, but don't provide a mechanism to retry queued or buffered
> > events.
> >
> >> On Tue, Nov 6, 2018 at 1:31 PM Gary Gregory <ga...@gmail.com>
> wrote:
> >>
> >> On Tue, Nov 6, 2018 at 11:19 AM Ralph Goers <ralph.goers@dslextreme.com
> >
> >> wrote:
> >>
> >>> The socket appender already has the ability to reconnect. It just
> needs to
> >>> ability to load balance or send to an alternate host if the connection
> >>> fails.
> >>>
> >>
> >> Sure, I just would like reconnection and failover to be abstracted in
> our
> >> core framework so that each connector does not have to re-invent the
> wheel.
> >>
> >> Gary
> >>
> >>>
> >>> Ralph
> >>>
> >>>> On Nov 6, 2018, at 11:15 AM, Gary Gregory <ga...@gmail.com>
> >>> wrote:
> >>>>
> >>>> Speaking of failover kind of things, the JMS Appender has a reconnect
> >>>> feature and I am wrapping up a similar feature for the JDBC Appender.
> >>> This
> >>>> kind of feature is a MUST for services that need to stay up and
> running
> >>> for
> >>>> longer periods of time.
> >>>>
> >>>> It would be nice to have a reconnect feature abstracted out so that
> all
> >>>> appenders/managers that depend on external resources can survive these
> >>>> resources going up and down as well as internet connections going up
> and
> >>>> down. That would make it much easier to implement this in all
> appenders
> >>>> that need it. A start would be to abstract JMS and JDBC reconnect
> code.
> >>>> Testing this is quite tricky of course.
> >>>>
> >>>> Gary
> >>>>
> >>>> On Mon, Nov 5, 2018 at 9:33 PM Ralph Goers <
> ralph.goers@dslextreme.com>
> >>>> wrote:
> >>>>
> >>>>> Some other features I need/want to do:
> >>>>>
> >>>>> 1. LOG4J2-1137
> >>>>> 2. Allow the SocketAppender to specify multiple IP addresses and
> allow
> >>>>> either round-robining through them or failing to the next if the
> first
> >>>>> fails. This will provide better high availability for applications.
> >>>>> 3. Support a ContextSelector based on Module Layers.
> >>>>> 4. LOG4J2-2170
> >>>>>
> >>>>> Ralph
> >>>>>
> >>>>>> On Nov 5, 2018, at 9:22 PM, Ralph Goers <ralph.goers@dslextreme.com
> >
> >>>>> wrote:
> >>>>>>
> >>>>>> How much are we impacting the API? I don’t know that package naming
> is
> >>>>> required if the API is compatible. I am hoping this doesn’t impact
> the
> >>> API
> >>>>> much.
> >>>>>>
> >>>>>> I’d prefer this just be log4j 3.x. Log4j 2 3.x is just really weird.
> >>>>>>
> >>>>>> I wouldn’t say a module shouldn’t have any optional dependencies
> but it
> >>>>> should be as few as possible. That said, because java is now
> >>> modularized
> >>>>> and you only get java.base by default I think log4j-core should only
> >>>>> require that. This would mean probably only the Properties
> configuration
> >>>>> can remain in core.
> >>>>>>
> >>>>>> I’m not completely sold on replacing the configuration with Jackson
> or
> >>>>> Commons Configuration. First, I really like that we convert the
> >>>>> configuration to a node tree and then process the node tree the same
> way
> >>>>> regardless of the configuration syntax used to construct it. Since we
> >>>>> already use Jackson for JSON and YAML I am not sure what it means to
> >>> redo
> >>>>> the configuration to use something we are already using.
> >>>>>>
> >>>>>> I would like to have every Maven module be a JPMS module, but this
> may
> >>>>> still be impossible to do as not all of our dependencies have
> declared
> >>>>> module names yet. For example,
> >>>>> https://github.com/LMAX-Exchange/disruptor/issues/234 <
> >>>>> https://github.com/LMAX-Exchange/disruptor/issues/234> shows the
> >>>>> disruptor still hasn’t done anything.
> >>>>>>
> >>>>>> For me, the main goal would be just “cleaning up” so the modules
> have
> >>>>> fewer dependencies. This also should align nicely with generating
> JPMS
> >>>>> modules.
> >>>>>>
> >>>>>> I do have new features I want to add and they don’t really require
> 3.0
> >>>>> to do them, but I would really like to provide good reasons to
> upgrade
> >>> to
> >>>>> log4j 3.x besides internal cleanup.
> >>>>>>
> >>>>>> One new feature that is a high priority for me is to make Log4j more
> >>>>> “cloud friendly”. This means being able to read and dynamically
> update
> >>> the
> >>>>> logging configuration from something like Spring Cloud Configuration.
> >>>>> Essentially this just means being able to read and monitor a file via
> >>> HTTP
> >>>>> instead of using only the File API.
> >>>>>>
> >>>>>> Also, I’d like to make another pass at performance testing to see
> where
> >>>>> we still have room for improvement.
> >>>>>>
> >>>>>> I would really, like to figure out a way to include location
> >>> information
> >>>>> in the log events without the overhead we have now. The only sane way
> >>> to do
> >>>>> it is to somehow get the information at compile time, but I just
> haven’t
> >>>>> been able to figure out a clever hack to make it work.
> >>>>>>
> >>>>>> Ralph
> >>>>>>
> >>>>>>> On Nov 5, 2018, at 2:01 PM, Gary Gregory <ga...@gmail.com>
> >>>>> wrote:
> >>>>>>>
> >>>>>>> Considerations for 3.0:
> >>>>>>>
> >>>>>>> - Currently targeting Java 8, seems OK to keep this for now.
> >>>>>>> - Remove deprecated code
> >>>>>>> - Make BC-breaking changes as we see fit to improve impl.
> >>>>>>> - ? Update root package to include "3" to allow Log4j 1, 2, and 3
> to
> >>>>>>> co-exist peacefully on the claspath. Perhaps
> >>> org.apache.logging.log4j3.
> >>>>>>> - Do we need a compatibility layer for 1.2 to 3.0 and 2.x to 3.0?
> >>>>>>> - Where can we use java.time?
> >>>>>>> - Is it a goal to have Maven modules with NO optional
> dependencies? I
> >>>>> think
> >>>>>>> so.
> >>>>>>> - Play nice in the Java 9 module system
> >>>>>>> - Continue to break up current Maven modules
> >>>>>>> - How can we make Core smaller?
> >>>>>>> - Should we redo our config code to use something like Jackson or
> >>>>> Commons
> >>>>>>> Configuration? We have a lot of config code... Not sure if
> everything
> >>>>> you
> >>>>>>> can do in XML is doable in JSON and YAML. YAML is gross IMO but
> some
> >>>>> people
> >>>>>>> like it.
> >>>>>>>
> >>>>>>> What else?
> >>>>>>>
> >>>>>>> Gary
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
>
Re: [log4j] Toward 3.0
Posted by Remko Popma <re...@gmail.com>.
It may be wise to always include some (configurable) backoff mechanism, to prevent our failover/reconnect logic from essentially initiating a denial of service attack when the service appears to be unavailable.
Not sure if we currently have this anywhere, but if we’re thinking to extract some reusable failover/reconnect API let’s make the backoff mechanism a first-class citizen.
Remko.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Nov 7, 2018, at 3:32, Carter Kozak <c4...@gmail.com> wrote:
>
> It would be helpful if we could implement failover and retrial in a
> way that is compatible with disabling immediate flush. The current
> implementations may surface a failure to the attempt to log an end of
> batch, but don't provide a mechanism to retry queued or buffered
> events.
>
>> On Tue, Nov 6, 2018 at 1:31 PM Gary Gregory <ga...@gmail.com> wrote:
>>
>> On Tue, Nov 6, 2018 at 11:19 AM Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>>> The socket appender already has the ability to reconnect. It just needs to
>>> ability to load balance or send to an alternate host if the connection
>>> fails.
>>>
>>
>> Sure, I just would like reconnection and failover to be abstracted in our
>> core framework so that each connector does not have to re-invent the wheel.
>>
>> Gary
>>
>>>
>>> Ralph
>>>
>>>> On Nov 6, 2018, at 11:15 AM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>>
>>>> Speaking of failover kind of things, the JMS Appender has a reconnect
>>>> feature and I am wrapping up a similar feature for the JDBC Appender.
>>> This
>>>> kind of feature is a MUST for services that need to stay up and running
>>> for
>>>> longer periods of time.
>>>>
>>>> It would be nice to have a reconnect feature abstracted out so that all
>>>> appenders/managers that depend on external resources can survive these
>>>> resources going up and down as well as internet connections going up and
>>>> down. That would make it much easier to implement this in all appenders
>>>> that need it. A start would be to abstract JMS and JDBC reconnect code.
>>>> Testing this is quite tricky of course.
>>>>
>>>> Gary
>>>>
>>>> On Mon, Nov 5, 2018 at 9:33 PM Ralph Goers <ra...@dslextreme.com>
>>>> wrote:
>>>>
>>>>> Some other features I need/want to do:
>>>>>
>>>>> 1. LOG4J2-1137
>>>>> 2. Allow the SocketAppender to specify multiple IP addresses and allow
>>>>> either round-robining through them or failing to the next if the first
>>>>> fails. This will provide better high availability for applications.
>>>>> 3. Support a ContextSelector based on Module Layers.
>>>>> 4. LOG4J2-2170
>>>>>
>>>>> Ralph
>>>>>
>>>>>> On Nov 5, 2018, at 9:22 PM, Ralph Goers <ra...@dslextreme.com>
>>>>> wrote:
>>>>>>
>>>>>> How much are we impacting the API? I don’t know that package naming is
>>>>> required if the API is compatible. I am hoping this doesn’t impact the
>>> API
>>>>> much.
>>>>>>
>>>>>> I’d prefer this just be log4j 3.x. Log4j 2 3.x is just really weird.
>>>>>>
>>>>>> I wouldn’t say a module shouldn’t have any optional dependencies but it
>>>>> should be as few as possible. That said, because java is now
>>> modularized
>>>>> and you only get java.base by default I think log4j-core should only
>>>>> require that. This would mean probably only the Properties configuration
>>>>> can remain in core.
>>>>>>
>>>>>> I’m not completely sold on replacing the configuration with Jackson or
>>>>> Commons Configuration. First, I really like that we convert the
>>>>> configuration to a node tree and then process the node tree the same way
>>>>> regardless of the configuration syntax used to construct it. Since we
>>>>> already use Jackson for JSON and YAML I am not sure what it means to
>>> redo
>>>>> the configuration to use something we are already using.
>>>>>>
>>>>>> I would like to have every Maven module be a JPMS module, but this may
>>>>> still be impossible to do as not all of our dependencies have declared
>>>>> module names yet. For example,
>>>>> https://github.com/LMAX-Exchange/disruptor/issues/234 <
>>>>> https://github.com/LMAX-Exchange/disruptor/issues/234> shows the
>>>>> disruptor still hasn’t done anything.
>>>>>>
>>>>>> For me, the main goal would be just “cleaning up” so the modules have
>>>>> fewer dependencies. This also should align nicely with generating JPMS
>>>>> modules.
>>>>>>
>>>>>> I do have new features I want to add and they don’t really require 3.0
>>>>> to do them, but I would really like to provide good reasons to upgrade
>>> to
>>>>> log4j 3.x besides internal cleanup.
>>>>>>
>>>>>> One new feature that is a high priority for me is to make Log4j more
>>>>> “cloud friendly”. This means being able to read and dynamically update
>>> the
>>>>> logging configuration from something like Spring Cloud Configuration.
>>>>> Essentially this just means being able to read and monitor a file via
>>> HTTP
>>>>> instead of using only the File API.
>>>>>>
>>>>>> Also, I’d like to make another pass at performance testing to see where
>>>>> we still have room for improvement.
>>>>>>
>>>>>> I would really, like to figure out a way to include location
>>> information
>>>>> in the log events without the overhead we have now. The only sane way
>>> to do
>>>>> it is to somehow get the information at compile time, but I just haven’t
>>>>> been able to figure out a clever hack to make it work.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>> On Nov 5, 2018, at 2:01 PM, Gary Gregory <ga...@gmail.com>
>>>>> wrote:
>>>>>>>
>>>>>>> Considerations for 3.0:
>>>>>>>
>>>>>>> - Currently targeting Java 8, seems OK to keep this for now.
>>>>>>> - Remove deprecated code
>>>>>>> - Make BC-breaking changes as we see fit to improve impl.
>>>>>>> - ? Update root package to include "3" to allow Log4j 1, 2, and 3 to
>>>>>>> co-exist peacefully on the claspath. Perhaps
>>> org.apache.logging.log4j3.
>>>>>>> - Do we need a compatibility layer for 1.2 to 3.0 and 2.x to 3.0?
>>>>>>> - Where can we use java.time?
>>>>>>> - Is it a goal to have Maven modules with NO optional dependencies? I
>>>>> think
>>>>>>> so.
>>>>>>> - Play nice in the Java 9 module system
>>>>>>> - Continue to break up current Maven modules
>>>>>>> - How can we make Core smaller?
>>>>>>> - Should we redo our config code to use something like Jackson or
>>>>> Commons
>>>>>>> Configuration? We have a lot of config code... Not sure if everything
>>>>> you
>>>>>>> can do in XML is doable in JSON and YAML. YAML is gross IMO but some
>>>>> people
>>>>>>> like it.
>>>>>>>
>>>>>>> What else?
>>>>>>>
>>>>>>> Gary
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
Re: [log4j] Toward 3.0
Posted by Carter Kozak <c4...@gmail.com>.
It would be helpful if we could implement failover and retrial in a
way that is compatible with disabling immediate flush. The current
implementations may surface a failure to the attempt to log an end of
batch, but don't provide a mechanism to retry queued or buffered
events.
On Tue, Nov 6, 2018 at 1:31 PM Gary Gregory <ga...@gmail.com> wrote:
>
> On Tue, Nov 6, 2018 at 11:19 AM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
> > The socket appender already has the ability to reconnect. It just needs to
> > ability to load balance or send to an alternate host if the connection
> > fails.
> >
>
> Sure, I just would like reconnection and failover to be abstracted in our
> core framework so that each connector does not have to re-invent the wheel.
>
> Gary
>
> >
> > Ralph
> >
> > > On Nov 6, 2018, at 11:15 AM, Gary Gregory <ga...@gmail.com>
> > wrote:
> > >
> > > Speaking of failover kind of things, the JMS Appender has a reconnect
> > > feature and I am wrapping up a similar feature for the JDBC Appender.
> > This
> > > kind of feature is a MUST for services that need to stay up and running
> > for
> > > longer periods of time.
> > >
> > > It would be nice to have a reconnect feature abstracted out so that all
> > > appenders/managers that depend on external resources can survive these
> > > resources going up and down as well as internet connections going up and
> > > down. That would make it much easier to implement this in all appenders
> > > that need it. A start would be to abstract JMS and JDBC reconnect code.
> > > Testing this is quite tricky of course.
> > >
> > > Gary
> > >
> > > On Mon, Nov 5, 2018 at 9:33 PM Ralph Goers <ra...@dslextreme.com>
> > > wrote:
> > >
> > >> Some other features I need/want to do:
> > >>
> > >> 1. LOG4J2-1137
> > >> 2. Allow the SocketAppender to specify multiple IP addresses and allow
> > >> either round-robining through them or failing to the next if the first
> > >> fails. This will provide better high availability for applications.
> > >> 3. Support a ContextSelector based on Module Layers.
> > >> 4. LOG4J2-2170
> > >>
> > >> Ralph
> > >>
> > >>> On Nov 5, 2018, at 9:22 PM, Ralph Goers <ra...@dslextreme.com>
> > >> wrote:
> > >>>
> > >>> How much are we impacting the API? I don’t know that package naming is
> > >> required if the API is compatible. I am hoping this doesn’t impact the
> > API
> > >> much.
> > >>>
> > >>> I’d prefer this just be log4j 3.x. Log4j 2 3.x is just really weird.
> > >>>
> > >>> I wouldn’t say a module shouldn’t have any optional dependencies but it
> > >> should be as few as possible. That said, because java is now
> > modularized
> > >> and you only get java.base by default I think log4j-core should only
> > >> require that. This would mean probably only the Properties configuration
> > >> can remain in core.
> > >>>
> > >>> I’m not completely sold on replacing the configuration with Jackson or
> > >> Commons Configuration. First, I really like that we convert the
> > >> configuration to a node tree and then process the node tree the same way
> > >> regardless of the configuration syntax used to construct it. Since we
> > >> already use Jackson for JSON and YAML I am not sure what it means to
> > redo
> > >> the configuration to use something we are already using.
> > >>>
> > >>> I would like to have every Maven module be a JPMS module, but this may
> > >> still be impossible to do as not all of our dependencies have declared
> > >> module names yet. For example,
> > >> https://github.com/LMAX-Exchange/disruptor/issues/234 <
> > >> https://github.com/LMAX-Exchange/disruptor/issues/234> shows the
> > >> disruptor still hasn’t done anything.
> > >>>
> > >>> For me, the main goal would be just “cleaning up” so the modules have
> > >> fewer dependencies. This also should align nicely with generating JPMS
> > >> modules.
> > >>>
> > >>> I do have new features I want to add and they don’t really require 3.0
> > >> to do them, but I would really like to provide good reasons to upgrade
> > to
> > >> log4j 3.x besides internal cleanup.
> > >>>
> > >>> One new feature that is a high priority for me is to make Log4j more
> > >> “cloud friendly”. This means being able to read and dynamically update
> > the
> > >> logging configuration from something like Spring Cloud Configuration.
> > >> Essentially this just means being able to read and monitor a file via
> > HTTP
> > >> instead of using only the File API.
> > >>>
> > >>> Also, I’d like to make another pass at performance testing to see where
> > >> we still have room for improvement.
> > >>>
> > >>> I would really, like to figure out a way to include location
> > information
> > >> in the log events without the overhead we have now. The only sane way
> > to do
> > >> it is to somehow get the information at compile time, but I just haven’t
> > >> been able to figure out a clever hack to make it work.
> > >>>
> > >>> Ralph
> > >>>
> > >>>> On Nov 5, 2018, at 2:01 PM, Gary Gregory <ga...@gmail.com>
> > >> wrote:
> > >>>>
> > >>>> Considerations for 3.0:
> > >>>>
> > >>>> - Currently targeting Java 8, seems OK to keep this for now.
> > >>>> - Remove deprecated code
> > >>>> - Make BC-breaking changes as we see fit to improve impl.
> > >>>> - ? Update root package to include "3" to allow Log4j 1, 2, and 3 to
> > >>>> co-exist peacefully on the claspath. Perhaps
> > org.apache.logging.log4j3.
> > >>>> - Do we need a compatibility layer for 1.2 to 3.0 and 2.x to 3.0?
> > >>>> - Where can we use java.time?
> > >>>> - Is it a goal to have Maven modules with NO optional dependencies? I
> > >> think
> > >>>> so.
> > >>>> - Play nice in the Java 9 module system
> > >>>> - Continue to break up current Maven modules
> > >>>> - How can we make Core smaller?
> > >>>> - Should we redo our config code to use something like Jackson or
> > >> Commons
> > >>>> Configuration? We have a lot of config code... Not sure if everything
> > >> you
> > >>>> can do in XML is doable in JSON and YAML. YAML is gross IMO but some
> > >> people
> > >>>> like it.
> > >>>>
> > >>>> What else?
> > >>>>
> > >>>> Gary
> > >>>
> > >>
> > >>
> > >>
> >
> >
> >
Re: [log4j] Toward 3.0
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Nov 6, 2018 at 11:19 AM Ralph Goers <ra...@dslextreme.com>
wrote:
> The socket appender already has the ability to reconnect. It just needs to
> ability to load balance or send to an alternate host if the connection
> fails.
>
Sure, I just would like reconnection and failover to be abstracted in our
core framework so that each connector does not have to re-invent the wheel.
Gary
>
> Ralph
>
> > On Nov 6, 2018, at 11:15 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > Speaking of failover kind of things, the JMS Appender has a reconnect
> > feature and I am wrapping up a similar feature for the JDBC Appender.
> This
> > kind of feature is a MUST for services that need to stay up and running
> for
> > longer periods of time.
> >
> > It would be nice to have a reconnect feature abstracted out so that all
> > appenders/managers that depend on external resources can survive these
> > resources going up and down as well as internet connections going up and
> > down. That would make it much easier to implement this in all appenders
> > that need it. A start would be to abstract JMS and JDBC reconnect code.
> > Testing this is quite tricky of course.
> >
> > Gary
> >
> > On Mon, Nov 5, 2018 at 9:33 PM Ralph Goers <ra...@dslextreme.com>
> > wrote:
> >
> >> Some other features I need/want to do:
> >>
> >> 1. LOG4J2-1137
> >> 2. Allow the SocketAppender to specify multiple IP addresses and allow
> >> either round-robining through them or failing to the next if the first
> >> fails. This will provide better high availability for applications.
> >> 3. Support a ContextSelector based on Module Layers.
> >> 4. LOG4J2-2170
> >>
> >> Ralph
> >>
> >>> On Nov 5, 2018, at 9:22 PM, Ralph Goers <ra...@dslextreme.com>
> >> wrote:
> >>>
> >>> How much are we impacting the API? I don’t know that package naming is
> >> required if the API is compatible. I am hoping this doesn’t impact the
> API
> >> much.
> >>>
> >>> I’d prefer this just be log4j 3.x. Log4j 2 3.x is just really weird.
> >>>
> >>> I wouldn’t say a module shouldn’t have any optional dependencies but it
> >> should be as few as possible. That said, because java is now
> modularized
> >> and you only get java.base by default I think log4j-core should only
> >> require that. This would mean probably only the Properties configuration
> >> can remain in core.
> >>>
> >>> I’m not completely sold on replacing the configuration with Jackson or
> >> Commons Configuration. First, I really like that we convert the
> >> configuration to a node tree and then process the node tree the same way
> >> regardless of the configuration syntax used to construct it. Since we
> >> already use Jackson for JSON and YAML I am not sure what it means to
> redo
> >> the configuration to use something we are already using.
> >>>
> >>> I would like to have every Maven module be a JPMS module, but this may
> >> still be impossible to do as not all of our dependencies have declared
> >> module names yet. For example,
> >> https://github.com/LMAX-Exchange/disruptor/issues/234 <
> >> https://github.com/LMAX-Exchange/disruptor/issues/234> shows the
> >> disruptor still hasn’t done anything.
> >>>
> >>> For me, the main goal would be just “cleaning up” so the modules have
> >> fewer dependencies. This also should align nicely with generating JPMS
> >> modules.
> >>>
> >>> I do have new features I want to add and they don’t really require 3.0
> >> to do them, but I would really like to provide good reasons to upgrade
> to
> >> log4j 3.x besides internal cleanup.
> >>>
> >>> One new feature that is a high priority for me is to make Log4j more
> >> “cloud friendly”. This means being able to read and dynamically update
> the
> >> logging configuration from something like Spring Cloud Configuration.
> >> Essentially this just means being able to read and monitor a file via
> HTTP
> >> instead of using only the File API.
> >>>
> >>> Also, I’d like to make another pass at performance testing to see where
> >> we still have room for improvement.
> >>>
> >>> I would really, like to figure out a way to include location
> information
> >> in the log events without the overhead we have now. The only sane way
> to do
> >> it is to somehow get the information at compile time, but I just haven’t
> >> been able to figure out a clever hack to make it work.
> >>>
> >>> Ralph
> >>>
> >>>> On Nov 5, 2018, at 2:01 PM, Gary Gregory <ga...@gmail.com>
> >> wrote:
> >>>>
> >>>> Considerations for 3.0:
> >>>>
> >>>> - Currently targeting Java 8, seems OK to keep this for now.
> >>>> - Remove deprecated code
> >>>> - Make BC-breaking changes as we see fit to improve impl.
> >>>> - ? Update root package to include "3" to allow Log4j 1, 2, and 3 to
> >>>> co-exist peacefully on the claspath. Perhaps
> org.apache.logging.log4j3.
> >>>> - Do we need a compatibility layer for 1.2 to 3.0 and 2.x to 3.0?
> >>>> - Where can we use java.time?
> >>>> - Is it a goal to have Maven modules with NO optional dependencies? I
> >> think
> >>>> so.
> >>>> - Play nice in the Java 9 module system
> >>>> - Continue to break up current Maven modules
> >>>> - How can we make Core smaller?
> >>>> - Should we redo our config code to use something like Jackson or
> >> Commons
> >>>> Configuration? We have a lot of config code... Not sure if everything
> >> you
> >>>> can do in XML is doable in JSON and YAML. YAML is gross IMO but some
> >> people
> >>>> like it.
> >>>>
> >>>> What else?
> >>>>
> >>>> Gary
> >>>
> >>
> >>
> >>
>
>
>
Re: [log4j] Toward 3.0
Posted by Ralph Goers <ra...@dslextreme.com>.
The socket appender already has the ability to reconnect. It just needs to ability to load balance or send to an alternate host if the connection fails.
Ralph
> On Nov 6, 2018, at 11:15 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> Speaking of failover kind of things, the JMS Appender has a reconnect
> feature and I am wrapping up a similar feature for the JDBC Appender. This
> kind of feature is a MUST for services that need to stay up and running for
> longer periods of time.
>
> It would be nice to have a reconnect feature abstracted out so that all
> appenders/managers that depend on external resources can survive these
> resources going up and down as well as internet connections going up and
> down. That would make it much easier to implement this in all appenders
> that need it. A start would be to abstract JMS and JDBC reconnect code.
> Testing this is quite tricky of course.
>
> Gary
>
> On Mon, Nov 5, 2018 at 9:33 PM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> Some other features I need/want to do:
>>
>> 1. LOG4J2-1137
>> 2. Allow the SocketAppender to specify multiple IP addresses and allow
>> either round-robining through them or failing to the next if the first
>> fails. This will provide better high availability for applications.
>> 3. Support a ContextSelector based on Module Layers.
>> 4. LOG4J2-2170
>>
>> Ralph
>>
>>> On Nov 5, 2018, at 9:22 PM, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>>
>>> How much are we impacting the API? I don’t know that package naming is
>> required if the API is compatible. I am hoping this doesn’t impact the API
>> much.
>>>
>>> I’d prefer this just be log4j 3.x. Log4j 2 3.x is just really weird.
>>>
>>> I wouldn’t say a module shouldn’t have any optional dependencies but it
>> should be as few as possible. That said, because java is now modularized
>> and you only get java.base by default I think log4j-core should only
>> require that. This would mean probably only the Properties configuration
>> can remain in core.
>>>
>>> I’m not completely sold on replacing the configuration with Jackson or
>> Commons Configuration. First, I really like that we convert the
>> configuration to a node tree and then process the node tree the same way
>> regardless of the configuration syntax used to construct it. Since we
>> already use Jackson for JSON and YAML I am not sure what it means to redo
>> the configuration to use something we are already using.
>>>
>>> I would like to have every Maven module be a JPMS module, but this may
>> still be impossible to do as not all of our dependencies have declared
>> module names yet. For example,
>> https://github.com/LMAX-Exchange/disruptor/issues/234 <
>> https://github.com/LMAX-Exchange/disruptor/issues/234> shows the
>> disruptor still hasn’t done anything.
>>>
>>> For me, the main goal would be just “cleaning up” so the modules have
>> fewer dependencies. This also should align nicely with generating JPMS
>> modules.
>>>
>>> I do have new features I want to add and they don’t really require 3.0
>> to do them, but I would really like to provide good reasons to upgrade to
>> log4j 3.x besides internal cleanup.
>>>
>>> One new feature that is a high priority for me is to make Log4j more
>> “cloud friendly”. This means being able to read and dynamically update the
>> logging configuration from something like Spring Cloud Configuration.
>> Essentially this just means being able to read and monitor a file via HTTP
>> instead of using only the File API.
>>>
>>> Also, I’d like to make another pass at performance testing to see where
>> we still have room for improvement.
>>>
>>> I would really, like to figure out a way to include location information
>> in the log events without the overhead we have now. The only sane way to do
>> it is to somehow get the information at compile time, but I just haven’t
>> been able to figure out a clever hack to make it work.
>>>
>>> Ralph
>>>
>>>> On Nov 5, 2018, at 2:01 PM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>>>
>>>> Considerations for 3.0:
>>>>
>>>> - Currently targeting Java 8, seems OK to keep this for now.
>>>> - Remove deprecated code
>>>> - Make BC-breaking changes as we see fit to improve impl.
>>>> - ? Update root package to include "3" to allow Log4j 1, 2, and 3 to
>>>> co-exist peacefully on the claspath. Perhaps org.apache.logging.log4j3.
>>>> - Do we need a compatibility layer for 1.2 to 3.0 and 2.x to 3.0?
>>>> - Where can we use java.time?
>>>> - Is it a goal to have Maven modules with NO optional dependencies? I
>> think
>>>> so.
>>>> - Play nice in the Java 9 module system
>>>> - Continue to break up current Maven modules
>>>> - How can we make Core smaller?
>>>> - Should we redo our config code to use something like Jackson or
>> Commons
>>>> Configuration? We have a lot of config code... Not sure if everything
>> you
>>>> can do in XML is doable in JSON and YAML. YAML is gross IMO but some
>> people
>>>> like it.
>>>>
>>>> What else?
>>>>
>>>> Gary
>>>
>>
>>
>>
Re: [log4j] Toward 3.0
Posted by Gary Gregory <ga...@gmail.com>.
Speaking of failover kind of things, the JMS Appender has a reconnect
feature and I am wrapping up a similar feature for the JDBC Appender. This
kind of feature is a MUST for services that need to stay up and running for
longer periods of time.
It would be nice to have a reconnect feature abstracted out so that all
appenders/managers that depend on external resources can survive these
resources going up and down as well as internet connections going up and
down. That would make it much easier to implement this in all appenders
that need it. A start would be to abstract JMS and JDBC reconnect code.
Testing this is quite tricky of course.
Gary
On Mon, Nov 5, 2018 at 9:33 PM Ralph Goers <ra...@dslextreme.com>
wrote:
> Some other features I need/want to do:
>
> 1. LOG4J2-1137
> 2. Allow the SocketAppender to specify multiple IP addresses and allow
> either round-robining through them or failing to the next if the first
> fails. This will provide better high availability for applications.
> 3. Support a ContextSelector based on Module Layers.
> 4. LOG4J2-2170
>
> Ralph
>
> > On Nov 5, 2018, at 9:22 PM, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >
> > How much are we impacting the API? I don’t know that package naming is
> required if the API is compatible. I am hoping this doesn’t impact the API
> much.
> >
> > I’d prefer this just be log4j 3.x. Log4j 2 3.x is just really weird.
> >
> > I wouldn’t say a module shouldn’t have any optional dependencies but it
> should be as few as possible. That said, because java is now modularized
> and you only get java.base by default I think log4j-core should only
> require that. This would mean probably only the Properties configuration
> can remain in core.
> >
> > I’m not completely sold on replacing the configuration with Jackson or
> Commons Configuration. First, I really like that we convert the
> configuration to a node tree and then process the node tree the same way
> regardless of the configuration syntax used to construct it. Since we
> already use Jackson for JSON and YAML I am not sure what it means to redo
> the configuration to use something we are already using.
> >
> > I would like to have every Maven module be a JPMS module, but this may
> still be impossible to do as not all of our dependencies have declared
> module names yet. For example,
> https://github.com/LMAX-Exchange/disruptor/issues/234 <
> https://github.com/LMAX-Exchange/disruptor/issues/234> shows the
> disruptor still hasn’t done anything.
> >
> > For me, the main goal would be just “cleaning up” so the modules have
> fewer dependencies. This also should align nicely with generating JPMS
> modules.
> >
> > I do have new features I want to add and they don’t really require 3.0
> to do them, but I would really like to provide good reasons to upgrade to
> log4j 3.x besides internal cleanup.
> >
> > One new feature that is a high priority for me is to make Log4j more
> “cloud friendly”. This means being able to read and dynamically update the
> logging configuration from something like Spring Cloud Configuration.
> Essentially this just means being able to read and monitor a file via HTTP
> instead of using only the File API.
> >
> > Also, I’d like to make another pass at performance testing to see where
> we still have room for improvement.
> >
> > I would really, like to figure out a way to include location information
> in the log events without the overhead we have now. The only sane way to do
> it is to somehow get the information at compile time, but I just haven’t
> been able to figure out a clever hack to make it work.
> >
> > Ralph
> >
> >> On Nov 5, 2018, at 2:01 PM, Gary Gregory <ga...@gmail.com>
> wrote:
> >>
> >> Considerations for 3.0:
> >>
> >> - Currently targeting Java 8, seems OK to keep this for now.
> >> - Remove deprecated code
> >> - Make BC-breaking changes as we see fit to improve impl.
> >> - ? Update root package to include "3" to allow Log4j 1, 2, and 3 to
> >> co-exist peacefully on the claspath. Perhaps org.apache.logging.log4j3.
> >> - Do we need a compatibility layer for 1.2 to 3.0 and 2.x to 3.0?
> >> - Where can we use java.time?
> >> - Is it a goal to have Maven modules with NO optional dependencies? I
> think
> >> so.
> >> - Play nice in the Java 9 module system
> >> - Continue to break up current Maven modules
> >> - How can we make Core smaller?
> >> - Should we redo our config code to use something like Jackson or
> Commons
> >> Configuration? We have a lot of config code... Not sure if everything
> you
> >> can do in XML is doable in JSON and YAML. YAML is gross IMO but some
> people
> >> like it.
> >>
> >> What else?
> >>
> >> Gary
> >
>
>
>
Re: [log4j] Toward 3.0
Posted by Ralph Goers <ra...@dslextreme.com>.
Some other features I need/want to do:
1. LOG4J2-1137
2. Allow the SocketAppender to specify multiple IP addresses and allow either round-robining through them or failing to the next if the first fails. This will provide better high availability for applications.
3. Support a ContextSelector based on Module Layers.
4. LOG4J2-2170
Ralph
> On Nov 5, 2018, at 9:22 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> How much are we impacting the API? I don’t know that package naming is required if the API is compatible. I am hoping this doesn’t impact the API much.
>
> I’d prefer this just be log4j 3.x. Log4j 2 3.x is just really weird.
>
> I wouldn’t say a module shouldn’t have any optional dependencies but it should be as few as possible. That said, because java is now modularized and you only get java.base by default I think log4j-core should only require that. This would mean probably only the Properties configuration can remain in core.
>
> I’m not completely sold on replacing the configuration with Jackson or Commons Configuration. First, I really like that we convert the configuration to a node tree and then process the node tree the same way regardless of the configuration syntax used to construct it. Since we already use Jackson for JSON and YAML I am not sure what it means to redo the configuration to use something we are already using.
>
> I would like to have every Maven module be a JPMS module, but this may still be impossible to do as not all of our dependencies have declared module names yet. For example, https://github.com/LMAX-Exchange/disruptor/issues/234 <https://github.com/LMAX-Exchange/disruptor/issues/234> shows the disruptor still hasn’t done anything.
>
> For me, the main goal would be just “cleaning up” so the modules have fewer dependencies. This also should align nicely with generating JPMS modules.
>
> I do have new features I want to add and they don’t really require 3.0 to do them, but I would really like to provide good reasons to upgrade to log4j 3.x besides internal cleanup.
>
> One new feature that is a high priority for me is to make Log4j more “cloud friendly”. This means being able to read and dynamically update the logging configuration from something like Spring Cloud Configuration. Essentially this just means being able to read and monitor a file via HTTP instead of using only the File API.
>
> Also, I’d like to make another pass at performance testing to see where we still have room for improvement.
>
> I would really, like to figure out a way to include location information in the log events without the overhead we have now. The only sane way to do it is to somehow get the information at compile time, but I just haven’t been able to figure out a clever hack to make it work.
>
> Ralph
>
>> On Nov 5, 2018, at 2:01 PM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> Considerations for 3.0:
>>
>> - Currently targeting Java 8, seems OK to keep this for now.
>> - Remove deprecated code
>> - Make BC-breaking changes as we see fit to improve impl.
>> - ? Update root package to include "3" to allow Log4j 1, 2, and 3 to
>> co-exist peacefully on the claspath. Perhaps org.apache.logging.log4j3.
>> - Do we need a compatibility layer for 1.2 to 3.0 and 2.x to 3.0?
>> - Where can we use java.time?
>> - Is it a goal to have Maven modules with NO optional dependencies? I think
>> so.
>> - Play nice in the Java 9 module system
>> - Continue to break up current Maven modules
>> - How can we make Core smaller?
>> - Should we redo our config code to use something like Jackson or Commons
>> Configuration? We have a lot of config code... Not sure if everything you
>> can do in XML is doable in JSON and YAML. YAML is gross IMO but some people
>> like it.
>>
>> What else?
>>
>> Gary
>
Re: [log4j] Toward 3.0
Posted by Ralph Goers <ra...@dslextreme.com>.
How much are we impacting the API? I don’t know that package naming is required if the API is compatible. I am hoping this doesn’t impact the API much.
I’d prefer this just be log4j 3.x. Log4j 2 3.x is just really weird.
I wouldn’t say a module shouldn’t have any optional dependencies but it should be as few as possible. That said, because java is now modularized and you only get java.base by default I think log4j-core should only require that. This would mean probably only the Properties configuration can remain in core.
I’m not completely sold on replacing the configuration with Jackson or Commons Configuration. First, I really like that we convert the configuration to a node tree and then process the node tree the same way regardless of the configuration syntax used to construct it. Since we already use Jackson for JSON and YAML I am not sure what it means to redo the configuration to use something we are already using.
I would like to have every Maven module be a JPMS module, but this may still be impossible to do as not all of our dependencies have declared module names yet. For example, https://github.com/LMAX-Exchange/disruptor/issues/234 <https://github.com/LMAX-Exchange/disruptor/issues/234> shows the disruptor still hasn’t done anything.
For me, the main goal would be just “cleaning up” so the modules have fewer dependencies. This also should align nicely with generating JPMS modules.
I do have new features I want to add and they don’t really require 3.0 to do them, but I would really like to provide good reasons to upgrade to log4j 3.x besides internal cleanup.
One new feature that is a high priority for me is to make Log4j more “cloud friendly”. This means being able to read and dynamically update the logging configuration from something like Spring Cloud Configuration. Essentially this just means being able to read and monitor a file via HTTP instead of using only the File API.
Also, I’d like to make another pass at performance testing to see where we still have room for improvement.
I would really, like to figure out a way to include location information in the log events without the overhead we have now. The only sane way to do it is to somehow get the information at compile time, but I just haven’t been able to figure out a clever hack to make it work.
Ralph
> On Nov 5, 2018, at 2:01 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> Considerations for 3.0:
>
> - Currently targeting Java 8, seems OK to keep this for now.
> - Remove deprecated code
> - Make BC-breaking changes as we see fit to improve impl.
> - ? Update root package to include "3" to allow Log4j 1, 2, and 3 to
> co-exist peacefully on the claspath. Perhaps org.apache.logging.log4j3.
> - Do we need a compatibility layer for 1.2 to 3.0 and 2.x to 3.0?
> - Where can we use java.time?
> - Is it a goal to have Maven modules with NO optional dependencies? I think
> so.
> - Play nice in the Java 9 module system
> - Continue to break up current Maven modules
> - How can we make Core smaller?
> - Should we redo our config code to use something like Jackson or Commons
> Configuration? We have a lot of config code... Not sure if everything you
> can do in XML is doable in JSON and YAML. YAML is gross IMO but some people
> like it.
>
> What else?
>
> Gary
Re: [log4j] Toward 3.0
Posted by Gary Gregory <ga...@gmail.com>.
Patches are welcome! :-)
Gary
On Sat, Nov 17, 2018, 12:26 Volkan Yazıcı <volkan.yazici@gmail.com wrote:
> One more feature request:
>
> *Garbage-free ThreadContext Map and Stack Accessors*
>
> I do not have the complete view of what it looks like under
> the hood, but to the best of my knowledge
>
> - ThreadContext.ContextStack does not provide any
> garbage-free iteration methods.
> - LogEvent#getContextData() returns a value of type
> ReadOnlyStringMap. This interface has implementations
> that do not provide garbage-free iteration methods
> as well.
>
> I would really appreciate if ThreadContext data and stack
> interfaces would enforce garbage-free accessors.
>
>
>
> On Fri, Nov 16, 2018 at 8:29 PM Volkan Yazıcı <vo...@gmail.com>
> wrote:
>
> > Hey Gary,
> >
> > *Package Name*
> >
> > Once every couple of months I found myself helping out people
> > for JAR Hell problems since they included wrong Log4j artifact.
> > The artifact and package names of Log4j 1 and Log4j 2 are
> > pretty similar looking. Hence I really encourage you to explicitly
> > state the version in artifact and package names. For instance,
> > log4j3-core and org.apache.logging.log4j3, etc. It goes without
> > saying, this will also aid SEO too, which is a pain right now.
> >
> > *Allowing Batches in Appender Interface*
> >
> > Is it also possible to extend the Appender interface such that in
> > addition to append(LogEvent), batched append(LogEvent[]),
> > append(LogEvent[], int offset, int length) are allowed as well?
> >
> > For instance, in log4j2-redis-appender I needed to implement
> > my own AsyncAppender logic to push the serialized LogEvent's
> > to Redis in batches.
> >
> > *Merging log4j2-redis-appender to master*
> >
> > Would you consider merging log4j2-redis-appender
> > <https://github.com/vy/log4j2-redis-appender> to master?
> >
> > *Merging log4j2-logstash-layout to master*
> >
> > Given its garbage-free superior performance and schema
> > customization support, would you consider merging
> > log4j2-logstash-layout
> > <https://github.com/vy/log4j2-logstash-layout/tree/json-generator> to
> > master? We can rebrand it as the
> > next JSONLayout and provide pre-cooked schemas for common
> > use cases, for instance, a schema of the old JSONLayout, a
> > schema for the pretty common Logstash event layout v1
> > <https://github.com/logstash/log4j-jsonevent-layout>, etc.
> >
> > Best.
> >
> >
> > On Mon, Nov 5, 2018 at 10:01 PM Gary Gregory <ga...@gmail.com>
> > wrote:
> >
> >> Considerations for 3.0:
> >>
> >> - Currently targeting Java 8, seems OK to keep this for now.
> >> - Remove deprecated code
> >> - Make BC-breaking changes as we see fit to improve impl.
> >> - ? Update root package to include "3" to allow Log4j 1, 2, and 3 to
> >> co-exist peacefully on the claspath. Perhaps org.apache.logging.log4j3.
> >> - Do we need a compatibility layer for 1.2 to 3.0 and 2.x to 3.0?
> >> - Where can we use java.time?
> >> - Is it a goal to have Maven modules with NO optional dependencies? I
> >> think
> >> so.
> >> - Play nice in the Java 9 module system
> >> - Continue to break up current Maven modules
> >> - How can we make Core smaller?
> >> - Should we redo our config code to use something like Jackson or
> Commons
> >> Configuration? We have a lot of config code... Not sure if everything
> you
> >> can do in XML is doable in JSON and YAML. YAML is gross IMO but some
> >> people
> >> like it.
> >>
> >> What else?
> >>
> >> Gary
> >>
> >
>
Re: [log4j] Toward 3.0
Posted by Remko Popma <re...@gmail.com>.
Yes that’d be interesting.
I’d like to understand whether they could not use the ContextMap instead.
Remko.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Nov 19, 2018, at 7:48, Ralph Goers <ra...@dslextreme.com> wrote:
>
> I asked about that once and someone did come up with a reason as to why they would use it. I’d have to hunt through the archives to find it though.
>
> Ralph
>
>> On Nov 18, 2018, at 9:17 AM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> Maybe we should deprecate it, but keep it in? The map version is still
>> useful, but the stack form has always confused me as to why you’d use it
>> somewhere.
>>
>>> On Sat, Nov 17, 2018 at 15:26, Remko Popma <re...@gmail.com> wrote:
>>>
>>> Would it be an idea to drop support for ThreadContext.ContextStack
>>> altogether in log4j 3?
>>>
>>> Remko.
>>> (Shameless plug) Every java main() method deserves http://picocli.info
>>>
>>>> On Nov 18, 2018, at 4:25, Volkan Yazıcı <vo...@gmail.com> wrote:
>>>>
>>>> ThreadContext.ContextStack
>>>
>> --
>> Matt Sicker <bo...@gmail.com>
>
>
Re: [log4j] Toward 3.0
Posted by Ralph Goers <ra...@dslextreme.com>.
I asked about that once and someone did come up with a reason as to why they would use it. I’d have to hunt through the archives to find it though.
Ralph
> On Nov 18, 2018, at 9:17 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> Maybe we should deprecate it, but keep it in? The map version is still
> useful, but the stack form has always confused me as to why you’d use it
> somewhere.
>
> On Sat, Nov 17, 2018 at 15:26, Remko Popma <re...@gmail.com> wrote:
>
>> Would it be an idea to drop support for ThreadContext.ContextStack
>> altogether in log4j 3?
>>
>> Remko.
>> (Shameless plug) Every java main() method deserves http://picocli.info
>>
>>> On Nov 18, 2018, at 4:25, Volkan Yazıcı <vo...@gmail.com> wrote:
>>>
>>> ThreadContext.ContextStack
>>
> --
> Matt Sicker <bo...@gmail.com>
Re: [log4j] Toward 3.0
Posted by Matt Sicker <bo...@gmail.com>.
Maybe we should deprecate it, but keep it in? The map version is still
useful, but the stack form has always confused me as to why you’d use it
somewhere.
On Sat, Nov 17, 2018 at 15:26, Remko Popma <re...@gmail.com> wrote:
> Would it be an idea to drop support for ThreadContext.ContextStack
> altogether in log4j 3?
>
> Remko.
> (Shameless plug) Every java main() method deserves http://picocli.info
>
> > On Nov 18, 2018, at 4:25, Volkan Yazıcı <vo...@gmail.com> wrote:
> >
> > ThreadContext.ContextStack
>
--
Matt Sicker <bo...@gmail.com>
Re: [log4j] Toward 3.0
Posted by Remko Popma <re...@gmail.com>.
Would it be an idea to drop support for ThreadContext.ContextStack altogether in log4j 3?
Remko.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Nov 18, 2018, at 4:25, Volkan Yazıcı <vo...@gmail.com> wrote:
>
> ThreadContext.ContextStack
Re: [log4j] Toward 3.0
Posted by Volkan Yazıcı <vo...@gmail.com>.
One more feature request:
*Garbage-free ThreadContext Map and Stack Accessors*
I do not have the complete view of what it looks like under
the hood, but to the best of my knowledge
- ThreadContext.ContextStack does not provide any
garbage-free iteration methods.
- LogEvent#getContextData() returns a value of type
ReadOnlyStringMap. This interface has implementations
that do not provide garbage-free iteration methods
as well.
I would really appreciate if ThreadContext data and stack
interfaces would enforce garbage-free accessors.
On Fri, Nov 16, 2018 at 8:29 PM Volkan Yazıcı <vo...@gmail.com>
wrote:
> Hey Gary,
>
> *Package Name*
>
> Once every couple of months I found myself helping out people
> for JAR Hell problems since they included wrong Log4j artifact.
> The artifact and package names of Log4j 1 and Log4j 2 are
> pretty similar looking. Hence I really encourage you to explicitly
> state the version in artifact and package names. For instance,
> log4j3-core and org.apache.logging.log4j3, etc. It goes without
> saying, this will also aid SEO too, which is a pain right now.
>
> *Allowing Batches in Appender Interface*
>
> Is it also possible to extend the Appender interface such that in
> addition to append(LogEvent), batched append(LogEvent[]),
> append(LogEvent[], int offset, int length) are allowed as well?
>
> For instance, in log4j2-redis-appender I needed to implement
> my own AsyncAppender logic to push the serialized LogEvent's
> to Redis in batches.
>
> *Merging log4j2-redis-appender to master*
>
> Would you consider merging log4j2-redis-appender
> <https://github.com/vy/log4j2-redis-appender> to master?
>
> *Merging log4j2-logstash-layout to master*
>
> Given its garbage-free superior performance and schema
> customization support, would you consider merging
> log4j2-logstash-layout
> <https://github.com/vy/log4j2-logstash-layout/tree/json-generator> to
> master? We can rebrand it as the
> next JSONLayout and provide pre-cooked schemas for common
> use cases, for instance, a schema of the old JSONLayout, a
> schema for the pretty common Logstash event layout v1
> <https://github.com/logstash/log4j-jsonevent-layout>, etc.
>
> Best.
>
>
> On Mon, Nov 5, 2018 at 10:01 PM Gary Gregory <ga...@gmail.com>
> wrote:
>
>> Considerations for 3.0:
>>
>> - Currently targeting Java 8, seems OK to keep this for now.
>> - Remove deprecated code
>> - Make BC-breaking changes as we see fit to improve impl.
>> - ? Update root package to include "3" to allow Log4j 1, 2, and 3 to
>> co-exist peacefully on the claspath. Perhaps org.apache.logging.log4j3.
>> - Do we need a compatibility layer for 1.2 to 3.0 and 2.x to 3.0?
>> - Where can we use java.time?
>> - Is it a goal to have Maven modules with NO optional dependencies? I
>> think
>> so.
>> - Play nice in the Java 9 module system
>> - Continue to break up current Maven modules
>> - How can we make Core smaller?
>> - Should we redo our config code to use something like Jackson or Commons
>> Configuration? We have a lot of config code... Not sure if everything you
>> can do in XML is doable in JSON and YAML. YAML is gross IMO but some
>> people
>> like it.
>>
>> What else?
>>
>> Gary
>>
>
Re: [log4j] Toward 3.0
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Nov 16, 2018 at 1:14 PM Gary Gregory <ga...@gmail.com> wrote:
>
>
> On Fri, Nov 16, 2018 at 12:30 PM Volkan Yazıcı <vo...@gmail.com>
> wrote:
>
>> Hey Gary,
>>
>> *Package Name*
>>
>> Once every couple of months I found myself helping out people
>> for JAR Hell problems since they included wrong Log4j artifact.
>> The artifact and package names of Log4j 1 and Log4j 2 are
>> pretty similar looking. Hence I really encourage you to explicitly
>> state the version in artifact and package names. For instance,
>> log4j3-core and org.apache.logging.log4j3, etc. It goes without
>> saying, this will also aid SEO too, which is a pain right now.
>>
>
> IMO, we should change the package names and artifact IDs to contains a "3"
> postfix, like we did in HttpComponents for version 5, so probably
> "log4j-core3", "log4j-api3" and so on. To be discussed...
>
I take it back "log4j3-..." is better, unless we go with something like
"log4j-r3-..." or "log4j-v3-..."
Gary
>
>
>>
>> *Allowing Batches in Appender Interface*
>>
>> Is it also possible to extend the Appender interface such that in
>> addition to append(LogEvent), batched append(LogEvent[]),
>> append(LogEvent[], int offset, int length) are allowed as well?
>>
>
> Sounds OK, PRs welcome. Ralph, any thoughts?
>
> Gary
>
>
>> For instance, in log4j2-redis-appender I needed to implement
>> my own AsyncAppender logic to push the serialized LogEvent's
>> to Redis in batches.
>>
>> *Merging log4j2-redis-appender to master*
>>
>> Would you consider merging log4j2-redis-appender
>> <https://github.com/vy/log4j2-redis-appender> to master?
>>
>
> The first step would be to change the license to the Apache License v2.
>
> Gary
>
>
>>
>> *Merging log4j2-logstash-layout to master*
>>
>> Given its garbage-free superior performance and schema
>> customization support, would you consider merging
>> log4j2-logstash-layout
>> <https://github.com/vy/log4j2-logstash-layout/tree/json-generator> to
>> master? We can rebrand it as the
>> next JSONLayout and provide pre-cooked schemas for common
>> use cases, for instance, a schema of the old JSONLayout, a
>> schema for the pretty common Logstash event layout v1
>> <https://github.com/logstash/log4j-jsonevent-layout>, etc.
>>
>> Best.
>>
>>
>> On Mon, Nov 5, 2018 at 10:01 PM Gary Gregory <ga...@gmail.com>
>> wrote:
>>
>> > Considerations for 3.0:
>> >
>> > - Currently targeting Java 8, seems OK to keep this for now.
>> > - Remove deprecated code
>> > - Make BC-breaking changes as we see fit to improve impl.
>> > - ? Update root package to include "3" to allow Log4j 1, 2, and 3 to
>> > co-exist peacefully on the claspath. Perhaps org.apache.logging.log4j3.
>> > - Do we need a compatibility layer for 1.2 to 3.0 and 2.x to 3.0?
>> > - Where can we use java.time?
>> > - Is it a goal to have Maven modules with NO optional dependencies? I
>> think
>> > so.
>> > - Play nice in the Java 9 module system
>> > - Continue to break up current Maven modules
>> > - How can we make Core smaller?
>> > - Should we redo our config code to use something like Jackson or
>> Commons
>> > Configuration? We have a lot of config code... Not sure if everything
>> you
>> > can do in XML is doable in JSON and YAML. YAML is gross IMO but some
>> people
>> > like it.
>> >
>> > What else?
>> >
>> > Gary
>> >
>>
>
Re: [log4j] Toward 3.0
Posted by Volkan Yazıcı <vo...@gmail.com>.
log4j2-logstash-layout was already using Apache License v2.
I have switched log4j2-redis-appender to it as well.
On Fri, Nov 16, 2018 at 9:15 PM Gary Gregory <ga...@gmail.com> wrote:
> On Fri, Nov 16, 2018 at 12:30 PM Volkan Yazıcı <vo...@gmail.com>
> wrote:
>
> > Hey Gary,
> >
> > *Package Name*
> >
> > Once every couple of months I found myself helping out people
> > for JAR Hell problems since they included wrong Log4j artifact.
> > The artifact and package names of Log4j 1 and Log4j 2 are
> > pretty similar looking. Hence I really encourage you to explicitly
> > state the version in artifact and package names. For instance,
> > log4j3-core and org.apache.logging.log4j3, etc. It goes without
> > saying, this will also aid SEO too, which is a pain right now.
> >
>
> IMO, we should change the package names and artifact IDs to contains a "3"
> postfix, like we did in HttpComponents for version 5, so probably
> "log4j-core3", "log4j-api3" and so on. To be discussed...
>
>
> >
> > *Allowing Batches in Appender Interface*
> >
> > Is it also possible to extend the Appender interface such that in
> > addition to append(LogEvent), batched append(LogEvent[]),
> > append(LogEvent[], int offset, int length) are allowed as well?
> >
>
> Sounds OK, PRs welcome. Ralph, any thoughts?
>
> Gary
>
>
> > For instance, in log4j2-redis-appender I needed to implement
> > my own AsyncAppender logic to push the serialized LogEvent's
> > to Redis in batches.
> >
> > *Merging log4j2-redis-appender to master*
> >
> > Would you consider merging log4j2-redis-appender
> > <https://github.com/vy/log4j2-redis-appender> to master?
> >
>
> The first step would be to change the license to the Apache License v2.
>
> Gary
>
>
> >
> > *Merging log4j2-logstash-layout to master*
> >
> > Given its garbage-free superior performance and schema
> > customization support, would you consider merging
> > log4j2-logstash-layout
> > <https://github.com/vy/log4j2-logstash-layout/tree/json-generator> to
> > master? We can rebrand it as the
> > next JSONLayout and provide pre-cooked schemas for common
> > use cases, for instance, a schema of the old JSONLayout, a
> > schema for the pretty common Logstash event layout v1
> > <https://github.com/logstash/log4j-jsonevent-layout>, etc.
> >
> > Best.
> >
> >
> > On Mon, Nov 5, 2018 at 10:01 PM Gary Gregory <ga...@gmail.com>
> > wrote:
> >
> > > Considerations for 3.0:
> > >
> > > - Currently targeting Java 8, seems OK to keep this for now.
> > > - Remove deprecated code
> > > - Make BC-breaking changes as we see fit to improve impl.
> > > - ? Update root package to include "3" to allow Log4j 1, 2, and 3 to
> > > co-exist peacefully on the claspath. Perhaps org.apache.logging.log4j3.
> > > - Do we need a compatibility layer for 1.2 to 3.0 and 2.x to 3.0?
> > > - Where can we use java.time?
> > > - Is it a goal to have Maven modules with NO optional dependencies? I
> > think
> > > so.
> > > - Play nice in the Java 9 module system
> > > - Continue to break up current Maven modules
> > > - How can we make Core smaller?
> > > - Should we redo our config code to use something like Jackson or
> Commons
> > > Configuration? We have a lot of config code... Not sure if everything
> you
> > > can do in XML is doable in JSON and YAML. YAML is gross IMO but some
> > people
> > > like it.
> > >
> > > What else?
> > >
> > > Gary
> > >
> >
>
Re: [log4j] Toward 3.0
Posted by Gary Gregory <ga...@gmail.com>.
The master branch is already on Java 8.
Gary
On Sat, Nov 17, 2018, 12:23 Volkan Yazıcı <volkan.yazici@gmail.com wrote:
> AsyncAppender can very well leverage this. Am I missing
> something? For the ones that do not implement these two
> methods, we can define a default interface method for
> them -- given log4j3 will target Java 8+.
>
> On Sat, Nov 17, 2018 at 1:27 AM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
> >
> >
> > > On Nov 16, 2018, at 1:14 PM, Gary Gregory <ga...@gmail.com>
> > wrote:
> > >
> > > On Fri, Nov 16, 2018 at 12:30 PM Volkan Yazıcı <
> volkan.yazici@gmail.com>
> > > wrote:
> > >
> > >> Hey Gary,
> > >>
> > >> *Package Name*
> > >>
> > >> Once every couple of months I found myself helping out people
> > >> for JAR Hell problems since they included wrong Log4j artifact.
> > >> The artifact and package names of Log4j 1 and Log4j 2 are
> > >> pretty similar looking. Hence I really encourage you to explicitly
> > >> state the version in artifact and package names. For instance,
> > >> log4j3-core and org.apache.logging.log4j3, etc. It goes without
> > >> saying, this will also aid SEO too, which is a pain right now.
> > >>
> > >
> > > IMO, we should change the package names and artifact IDs to contains a
> > "3"
> > > postfix, like we did in HttpComponents for version 5, so probably
> > > "log4j-core3", "log4j-api3" and so on. To be discussed...
> > >
> > >
> > >>
> > >> *Allowing Batches in Appender Interface*
> > >>
> > >> Is it also possible to extend the Appender interface such that in
> > >> addition to append(LogEvent), batched append(LogEvent[]),
> > >> append(LogEvent[], int offset, int length) are allowed as well?
> > >>
> > >
> > > Sounds OK, PRs welcome. Ralph, any thoughts?
> >
> > What would call the append(LogEvent[]) method? Nothing in the Logger
> > interface or implementation currently would. I suppose it could be
> useful
> > when one Appender is wrapped with another, but then wouldn’t every
> Appender
> > that can wrap other Appenders need to be modified to support this?
> >
> > Ralph
> >
> >
> >
>
Re: [log4j] Toward 3.0
Posted by Volkan Yazıcı <vo...@gmail.com>.
AsyncAppender can very well leverage this. Am I missing
something? For the ones that do not implement these two
methods, we can define a default interface method for
them -- given log4j3 will target Java 8+.
On Sat, Nov 17, 2018 at 1:27 AM Ralph Goers <ra...@dslextreme.com>
wrote:
>
>
> > On Nov 16, 2018, at 1:14 PM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > On Fri, Nov 16, 2018 at 12:30 PM Volkan Yazıcı <vo...@gmail.com>
> > wrote:
> >
> >> Hey Gary,
> >>
> >> *Package Name*
> >>
> >> Once every couple of months I found myself helping out people
> >> for JAR Hell problems since they included wrong Log4j artifact.
> >> The artifact and package names of Log4j 1 and Log4j 2 are
> >> pretty similar looking. Hence I really encourage you to explicitly
> >> state the version in artifact and package names. For instance,
> >> log4j3-core and org.apache.logging.log4j3, etc. It goes without
> >> saying, this will also aid SEO too, which is a pain right now.
> >>
> >
> > IMO, we should change the package names and artifact IDs to contains a
> "3"
> > postfix, like we did in HttpComponents for version 5, so probably
> > "log4j-core3", "log4j-api3" and so on. To be discussed...
> >
> >
> >>
> >> *Allowing Batches in Appender Interface*
> >>
> >> Is it also possible to extend the Appender interface such that in
> >> addition to append(LogEvent), batched append(LogEvent[]),
> >> append(LogEvent[], int offset, int length) are allowed as well?
> >>
> >
> > Sounds OK, PRs welcome. Ralph, any thoughts?
>
> What would call the append(LogEvent[]) method? Nothing in the Logger
> interface or implementation currently would. I suppose it could be useful
> when one Appender is wrapped with another, but then wouldn’t every Appender
> that can wrap other Appenders need to be modified to support this?
>
> Ralph
>
>
>
Re: [log4j] Toward 3.0
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Nov 16, 2018, at 1:14 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Fri, Nov 16, 2018 at 12:30 PM Volkan Yazıcı <vo...@gmail.com>
> wrote:
>
>> Hey Gary,
>>
>> *Package Name*
>>
>> Once every couple of months I found myself helping out people
>> for JAR Hell problems since they included wrong Log4j artifact.
>> The artifact and package names of Log4j 1 and Log4j 2 are
>> pretty similar looking. Hence I really encourage you to explicitly
>> state the version in artifact and package names. For instance,
>> log4j3-core and org.apache.logging.log4j3, etc. It goes without
>> saying, this will also aid SEO too, which is a pain right now.
>>
>
> IMO, we should change the package names and artifact IDs to contains a "3"
> postfix, like we did in HttpComponents for version 5, so probably
> "log4j-core3", "log4j-api3" and so on. To be discussed...
>
>
>>
>> *Allowing Batches in Appender Interface*
>>
>> Is it also possible to extend the Appender interface such that in
>> addition to append(LogEvent), batched append(LogEvent[]),
>> append(LogEvent[], int offset, int length) are allowed as well?
>>
>
> Sounds OK, PRs welcome. Ralph, any thoughts?
What would call the append(LogEvent[]) method? Nothing in the Logger interface or implementation currently would. I suppose it could be useful when one Appender is wrapped with another, but then wouldn’t every Appender that can wrap other Appenders need to be modified to support this?
Ralph
Re: [log4j] Toward 3.0
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Nov 16, 2018 at 12:30 PM Volkan Yazıcı <vo...@gmail.com>
wrote:
> Hey Gary,
>
> *Package Name*
>
> Once every couple of months I found myself helping out people
> for JAR Hell problems since they included wrong Log4j artifact.
> The artifact and package names of Log4j 1 and Log4j 2 are
> pretty similar looking. Hence I really encourage you to explicitly
> state the version in artifact and package names. For instance,
> log4j3-core and org.apache.logging.log4j3, etc. It goes without
> saying, this will also aid SEO too, which is a pain right now.
>
IMO, we should change the package names and artifact IDs to contains a "3"
postfix, like we did in HttpComponents for version 5, so probably
"log4j-core3", "log4j-api3" and so on. To be discussed...
>
> *Allowing Batches in Appender Interface*
>
> Is it also possible to extend the Appender interface such that in
> addition to append(LogEvent), batched append(LogEvent[]),
> append(LogEvent[], int offset, int length) are allowed as well?
>
Sounds OK, PRs welcome. Ralph, any thoughts?
Gary
> For instance, in log4j2-redis-appender I needed to implement
> my own AsyncAppender logic to push the serialized LogEvent's
> to Redis in batches.
>
> *Merging log4j2-redis-appender to master*
>
> Would you consider merging log4j2-redis-appender
> <https://github.com/vy/log4j2-redis-appender> to master?
>
The first step would be to change the license to the Apache License v2.
Gary
>
> *Merging log4j2-logstash-layout to master*
>
> Given its garbage-free superior performance and schema
> customization support, would you consider merging
> log4j2-logstash-layout
> <https://github.com/vy/log4j2-logstash-layout/tree/json-generator> to
> master? We can rebrand it as the
> next JSONLayout and provide pre-cooked schemas for common
> use cases, for instance, a schema of the old JSONLayout, a
> schema for the pretty common Logstash event layout v1
> <https://github.com/logstash/log4j-jsonevent-layout>, etc.
>
> Best.
>
>
> On Mon, Nov 5, 2018 at 10:01 PM Gary Gregory <ga...@gmail.com>
> wrote:
>
> > Considerations for 3.0:
> >
> > - Currently targeting Java 8, seems OK to keep this for now.
> > - Remove deprecated code
> > - Make BC-breaking changes as we see fit to improve impl.
> > - ? Update root package to include "3" to allow Log4j 1, 2, and 3 to
> > co-exist peacefully on the claspath. Perhaps org.apache.logging.log4j3.
> > - Do we need a compatibility layer for 1.2 to 3.0 and 2.x to 3.0?
> > - Where can we use java.time?
> > - Is it a goal to have Maven modules with NO optional dependencies? I
> think
> > so.
> > - Play nice in the Java 9 module system
> > - Continue to break up current Maven modules
> > - How can we make Core smaller?
> > - Should we redo our config code to use something like Jackson or Commons
> > Configuration? We have a lot of config code... Not sure if everything you
> > can do in XML is doable in JSON and YAML. YAML is gross IMO but some
> people
> > like it.
> >
> > What else?
> >
> > Gary
> >
>
Re: [log4j] Toward 3.0
Posted by Volkan Yazıcı <vo...@gmail.com>.
Hey Gary,
*Package Name*
Once every couple of months I found myself helping out people
for JAR Hell problems since they included wrong Log4j artifact.
The artifact and package names of Log4j 1 and Log4j 2 are
pretty similar looking. Hence I really encourage you to explicitly
state the version in artifact and package names. For instance,
log4j3-core and org.apache.logging.log4j3, etc. It goes without
saying, this will also aid SEO too, which is a pain right now.
*Allowing Batches in Appender Interface*
Is it also possible to extend the Appender interface such that in
addition to append(LogEvent), batched append(LogEvent[]),
append(LogEvent[], int offset, int length) are allowed as well?
For instance, in log4j2-redis-appender I needed to implement
my own AsyncAppender logic to push the serialized LogEvent's
to Redis in batches.
*Merging log4j2-redis-appender to master*
Would you consider merging log4j2-redis-appender
<https://github.com/vy/log4j2-redis-appender> to master?
*Merging log4j2-logstash-layout to master*
Given its garbage-free superior performance and schema
customization support, would you consider merging
log4j2-logstash-layout
<https://github.com/vy/log4j2-logstash-layout/tree/json-generator> to
master? We can rebrand it as the
next JSONLayout and provide pre-cooked schemas for common
use cases, for instance, a schema of the old JSONLayout, a
schema for the pretty common Logstash event layout v1
<https://github.com/logstash/log4j-jsonevent-layout>, etc.
Best.
On Mon, Nov 5, 2018 at 10:01 PM Gary Gregory <ga...@gmail.com> wrote:
> Considerations for 3.0:
>
> - Currently targeting Java 8, seems OK to keep this for now.
> - Remove deprecated code
> - Make BC-breaking changes as we see fit to improve impl.
> - ? Update root package to include "3" to allow Log4j 1, 2, and 3 to
> co-exist peacefully on the claspath. Perhaps org.apache.logging.log4j3.
> - Do we need a compatibility layer for 1.2 to 3.0 and 2.x to 3.0?
> - Where can we use java.time?
> - Is it a goal to have Maven modules with NO optional dependencies? I think
> so.
> - Play nice in the Java 9 module system
> - Continue to break up current Maven modules
> - How can we make Core smaller?
> - Should we redo our config code to use something like Jackson or Commons
> Configuration? We have a lot of config code... Not sure if everything you
> can do in XML is doable in JSON and YAML. YAML is gross IMO but some people
> like it.
>
> What else?
>
> Gary
>