ilure resulted in a
>> NoClassDefError...
>> So I reverted to System.getProperties.
>> I can take another look, or if someone else has time, please feel free to
>> replace this with PropertiesUtil.
>>
>> On Saturday, 20 February 2016, Ralph Goers >
>>
ted the new properties in the Configuration manual page.
>>>>>>>> Did I forget to commit that?
>>>>>>>>
>>>>>>>>
>>>>>>>> On Saturday, 20 February 2016, Remko Popma
>>>>>>>>
initially used PropertiesUtil but this failed somehow. Since this
>>>>>>>> is used while initializing s class constant, the failure resulted in a
>>>>>>>> NoClassDefError...
>>>>>>>> So I reverted to System.getProperties.
>>&
ass constant, the failure resulted in a
>>>>>>> NoClassDefError...
>>>>>>> So I reverted to System.getProperties.
>>>>>>> I can take another look, or if someone else has time, please feel
>>>>>>> free to replace thi
...
>>>>>> So I reverted to System.getProperties.
>>>>>> I can take another look, or if someone else has time, please feel
>>>>>> free to replace this with PropertiesUtil.
>>>>>>
>>>>>> On Saturd
erted to System.getProperties.
>>>>> I can take another look, or if someone else has time, please feel free
>>>>> to replace this with PropertiesUtil.
>>>>>
>>>>> On Saturday, 20 February 2016, Ralph Goers
>>>>> wrote:
>
or if someone else has time, please feel free
>>>> to replace this with PropertiesUtil.
>>>>
>>>> On Saturday, 20 February 2016, Ralph Goers
>>>> wrote:
>>>>
>>>>> I should have qualified this to say that the
>>>>> log4j
the PropertiesUtil class. Properties should be access through
> its methods.
>
> Ralph
>
>> On Feb 19, 2016, at 1:09 PM, Ralph Goers >
>> wrote:
>>
>> I see two new properties to allow users to override the default
>> MessageFactory and FlowMessageFac
On Saturday, 20 February 2016, Ralph Goers
>>> wrote:
>>>
>>>> I should have qualified this to say that the
>>>> log4j2.component.properties file is managed by the PropertiesUtil class.
>>>> Properties should be access through its methods.
>>>
n Feb 19, 2016, at 1:09 PM, Ralph Goers
>>> wrote:
>>>
>>> I see two new properties to allow users to override the default
>>> MessageFactory and FlowMessageFactory. It seems very unlikely they will
>>> ever get used, but they should NOT be calling System.getProperty() d
ualified this to say that the log4j2.component.properties
>> file is managed by the PropertiesUtil class. Properties should be access
>> through its methods.
>>
>> Ralph
>>
>> On Feb 19, 2016, at 1:09 PM, Ralph Goers
>> wrote:
>>
>> I see two new properties to a
Ralph Goers > wrote:
>
> I see two new properties to allow users to override the default
> MessageFactory and FlowMessageFactory. It seems very unlikely they will
> ever get used, but they should NOT be calling System.getProperty() directly.
>
> Please remember that wherever a
e default
> MessageFactory and FlowMessageFactory. It seems very unlikely they will ever
> get used, but they should NOT be calling System.getProperty() directly.
>
> Please remember that wherever adding something to the configuration won’t
> work you should acce
I see two new properties to allow users to override the default MessageFactory
and FlowMessageFactory. It seems very unlikely they will ever get used, but
they should NOT be calling System.getProperty() directly.
Please remember that wherever adding something to the configuration won’t work
On Fri, Feb 19, 2016 at 9:24 AM, Remko Popma wrote:
>
> FlowMessageFactory is now extracted. I'm quite happy with the result.
> Please take a look at https://issues.apache.org/jira/browse/LOG4J2-1255
for further follow-up.
OK, that seems fine. Thank you for doing the work.
The o
FlowMessageFactory is now extracted. I'm quite happy with the result.
Please take a look at https://issues.apache.org/jira/browse/LOG4J2-1255 for
further follow-up.
On Fri, Feb 19, 2016 at 2:40 PM, Remko Popma wrote:
> I see, so there actually is a use case to remove the need
;>
>> On Feb 18, 2016 5:38 PM, "Remko Popma" wrote:
>> >
>> > I would start with just a default FlowMessageFactory. Configurable with a
>> > system property, so users can swap in their own if they want.
>> >
>> > Only if the need a
t;
> On Feb 18, 2016 5:38 PM, "Remko Popma" <mailto:[email protected]>> wrote:
> >
> > I would start with just a default FlowMessageFactory. Configurable with a
> > system property, so users can swap in their own if they want.
> >
> > Only i
On Feb 18, 2016 5:38 PM, "Remko Popma" wrote:
>
> I would start with just a default FlowMessageFactory. Configurable with a
system property, so users can swap in their own if they want.
>
> Only if the need arises to configure FlowMessageFactories on a per-logger
basis, we c
I would start with just a default FlowMessageFactory. Configurable with a
system property, so users can swap in their own if they want.
Only if the need arises to configure FlowMessageFactories on a per-logger
basis, we can consider adding the methods to LogManager to support that.
So no need
On Thu, Feb 18, 2016 at 4:22 PM, Ralph Goers
wrote:
> Is it really necessary to have getLogger support FlowMessageFactory?
> These messages are really meant as wrappers for other messages. so I am not
> even sure what it would mean for getLogger() to support that. How would it
&g
Is it really necessary to have getLogger support FlowMessageFactory? These
messages are really meant as wrappers for other messages. so I am not even sure
what it would mean for getLogger() to support that. How would it know what
Message it is wrapping?
I am really getting sorry that I
rate instances so users can configure them
>> separately: lower coupling.
>>
>
> OK. So now we have:
>
> org.apache.logging.log4j.LogManager.getLogger(Class, MessageFactory)
> org.apache.logging.log4j.LogManager.getLogger(Object, MessageFactory)
> o
g4j.LogManager.getLogger(Class, MessageFactory)
org.apache.logging.log4j.LogManager.getLogger(Object, MessageFactory)
org.apache.logging.log4j.LogManager.getLogger(String, MessageFactory)
We would add:
org.apache.logging.log4j.LogManager.getLogger(Class, MessageFactory,
FlowMessageFactory)
org.apache.logging.log
, "Remko Popma" wrote:
>> Would anyone mind terribly if I factored out the FlowMessage creation
>> methods from MessageFactory to a new interface FlowMessageFactory?
>>
>> Concretely, this interface would contain the methods introduced in
>> LOG4J2-1255:
&g
Would anyone mind terribly if I factored out the FlowMessage creation
> methods from MessageFactory to a new interface FlowMessageFactory?
>
> Concretely, this interface would contain the methods introduced in
> LOG4J2-1255:
>
> EntryMessage newEntryMessage(Message message);
>
Would anyone mind terribly if I factored out the FlowMessage creation
methods from MessageFactory to a new interface FlowMessageFactory?
Concretely, this interface would contain the methods introduced in
LOG4J2-1255:
EntryMessage newEntryMessage(Message message);
ExitMessage newExitMessage
27 matches
Mail list logo
