You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Julian Woodward <ju...@ldcvia.com> on 2020/11/30 15:17:11 UTC

log4j2 2.14.0 and the mongodb4 appender

When the mongodb4 appender was created for log4j2, the ability to specify a
factory class/method in the log4j2.xml file was removed, and the
configuration option was instead reverted to requiring a simple connection
string.

Was there a technical reason why that needed to happen, or was it just for
simplicity at dev time?

I've been relying on the factory approach, as the database credentials are
not known until run-time in my use-case. I was also looking forward to
having a mongodb4 version to upgrade to, but as it stands now this is
unfortunately not giving me what I need.

Thanks!

Julian Woodward

PS New to this forum, so please be forgiving of any breaches of etiquette!

Re: log4j2 2.14.0 and the mongodb4 appender

Posted by Julian Woodward <ju...@ldcvia.com>.
Hi Ralph - that's great, thank you, and it was exactly the steer I needed.
All now working. As so often, the fix is about 15 lines of code.... it's
just knowing *which* 15 lines of code to write that's the challenge. Thanks
again.
Julian



On Tue, 9 Mar 2021 at 15:37, Ralph Goers <ra...@dslextreme.com> wrote:

> If you create a custom Lookup, say CredentialsLookup, when it is called
> you can make the same query your factory method did. The result of that
> would then be merged into the connections string for Mongo. By the time the
> Appender would be resolving that string the Lookup would definitely be
> available.
>
> Ralph
>
> > On Mar 9, 2021, at 6:39 AM, Gary Gregory <ga...@gmail.com> wrote:
> >
> > Well, hot dog dang I don't see support for $$ in MongoDb4Provider.
> >
> > Ideally I think the provider should be fed a Configuration where the
> > StrSubstitutor can be accessed.
> >
> > If you want to provide a failing unit test in that component, I can take
> a
> > look at it.
> >
> > But, I am not sure if that will solve the problem because the resolving
> > might still happen too soon for you.
> >
> > Let's figure that out first.
> >
> > Gary
> >
> > On Tue, Mar 9, 2021, 02:39 Julian Woodward <ju...@ldcvia.com> wrote:
> >
> >> Perhaps it would help if I explain the scenario better. In this
> >> application, the MongoDB credentials are not known at design time, nor
> are
> >> they known immediately at start-up time. They're only known when the
> >> application has started and has had a chance to go and retrieve them
> from a
> >> secure credentials store. In the mongodb3 appender, the factory
> >> class/method allowed me to have code which went and retrieved the
> >> credentials and created the mongodb connection. I can't see how to use
> the
> >> $ or $$ mechanism to achieve the same thing.
> >>
> >> (If it makes any difference, the framework here is Spring Boot and
> Vaadin
> >> 14, and mongodb is on Atlas).
> >>
> >> I'd be really grateful for any pointers! Thanks.
> >>
> >> Julian Woodward
> >>
> >>
> >>
> >> On Mon, 8 Mar 2021 at 21:15, Gary Gregory <ga...@gmail.com>
> wrote:
> >>
> >>> Sure I know that, I just don't recall if I accounted for $$ in the
> >>> code for MongoDB...
> >>>
> >>> G ;-) I'll peek tonight.
> >>>
> >>> On Mon, Mar 8, 2021 at 2:40 PM Ralph Goers <ralph.goers@dslextreme.com
> >
> >>> wrote:
> >>>>
> >>>> Gary - the $$ form requires that the component call StrSubstitutor to
> >>> resolve the variables. If the application needs to do that for some
> >> reason
> >>> then the Appender would need to support it.
> >>>>
> >>>> Ralph
> >>>>
> >>>>> On Mar 8, 2021, at 9:46 AM, Gary Gregory <ga...@gmail.com>
> >>> wrote:
> >>>>>
> >>>>> What Ralph said :-)
> >>>>>
> >>>>> The tests in Log4j as well as the ones I have at work all use one $
> >> in
> >>>>> connection strings. I do not have tests that use $$.
> >>>>>
> >>>>> Gary
> >>>>>
> >>>>>
> >>>>> On Mon, Mar 8, 2021, 11:13 Ralph Goers <ra...@dslextreme.com>
> >>> wrote:
> >>>>>
> >>>>>> If I understand what Gary is saying correctly is that you would
> >>> configure
> >>>>>> your Log4j2.xml file with the connection string for MongoDB. In the
> >>>>>> connection string you would have variables. If the variable is of
> >> the
> >>> form
> >>>>>> ${varName} then it will be resolved when the configuration is
> >>> processed. If
> >>>>>> a variable is of the form $${varName} then the first ‘$’ is stripped
> >>> off
> >>>>>> when the configuration is processed and the internal component may
> >>> resolve
> >>>>>> variables when they are actually used.
> >>>>>>
> >>>>>> Variables in Log4j 2 are implemented as Lookups - see
> >>>>>> http://logging.apache.org/log4j/2.x/manual/lookups.html for the
> >> list
> >>> of
> >>>>>> Lookups that Log4j provides. You can add your own.
> >>>>>>
> >>>>>> Ralph
> >>>>>>
> >>>>>>> On Mar 8, 2021, at 7:01 AM, Julian Woodward <ju...@ldcvia.com>
> >>> wrote:
> >>>>>>>
> >>>>>>> Hi Gary
> >>>>>>>
> >>>>>>> It's been a while, but I'm trying this now. I don't understand
> >> where
> >>> the
> >>>>>>> opportunity is to inject values in the way you're describing (the
> >> $$
> >>>>>>> approach) when log4j2 is being instantiated at startup time by
> >>> Spring. By
> >>>>>>> the time we reach 'my' code, it's too late and the mongodb4 setup
> >> has
> >>>>>>> already failed. Have I misunderstood, or is there a code sample
> >> that
> >>> you
> >>>>>>> know of where this is actually in use?
> >>>>>>>
> >>>>>>> Many thanks,
> >>>>>>>
> >>>>>>> Julian Woodward
> >>>>>>>
> >>>>>>> *Liberate your Domino data with LDC Via*
> >>>>>>> julian@ldcvia.com
> >>>>>>> +44 (0) 7956 227546
> >>>>>>> +44 (0) 20 3633 3009
> >>>>>>> http://ldcvia.com
> >>>>>>>
> >>>>>>> *LDC Via Limited is a limited company registered 09209489 in
> >> England
> >>> &
> >>>>>>> Wales at 24 Ivymount Road, London, SE27 0NB. *
> >>>>>>> *Disclaimer: This message is intended only for the use of the
> >>> individual
> >>>>>> or
> >>>>>>> entity to which it is addressed and may contain information which
> >> is
> >>>>>>> privileged, confidential, proprietary, or exempt from disclosure
> >>> under
> >>>>>>> applicable law. If you are not the intended recipient or the person
> >>>>>>> responsible for delivering the message to the intended recipient,
> >>> you are
> >>>>>>> strictly prohibited from disclosing, distributing, copying, or in
> >>> any way
> >>>>>>> using this message. If you have received this communication in
> >> error,
> >>>>>>> please notify the sender and destroy and delete any copies you may
> >>> have
> >>>>>>> received. *
> >>>>>>>
> >>>>>>>
> >>>>>>> On Mon, 30 Nov 2020 at 23:29, Gary Gregory <garydgregory@gmail.com
> >>>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hello Julian,
> >>>>>>>>
> >>>>>>>> When I created the version 4 of the MongoDB appender, I realized
> >>> that
> >>>>>> for
> >>>>>>>> all the use cases I had and I felt were reasonable, I could use a
> >>>>>>>> connection string, a bit like you can in JDBC, which I could not
> >> do
> >>>>>> with a
> >>>>>>>> version 3 driver. There are two settings IIRC that I did not find
> >>>>>> mappings
> >>>>>>>> in a version 4 connection string: capped and collection size.
> >>>>>>>>
> >>>>>>>> Note that you can also parameterize the configuration with
> >>>>>> ${variables}, so
> >>>>>>>> you could parameterize the user and password in a connection
> >> string,
> >>>>>> see:
> >>>>>>>>
> >>>>>>>> -
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>
> >>
> https://logging.apache.org/log4j/2.x/manual/configuration.html#RuntimeLookup
> >>>>>>>> -
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>
> >>
> https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution
> >>>>>>>> -
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>
> >>
> https://logging.apache.org/log4j/2.x/manual/appenders.html#NoSQLAppenderMongoDB4
> >>>>>>>>
> >>>>>>>> If you feel like you still need the factory method as a mechanism
> >> to
> >>>>>> create
> >>>>>>>> a provider, then please feel free to provide a PR on GitHub here:
> >>>>>>>> https://github.com/apache/logging-log4j2
> >>>>>>>>
> >>>>>>>> Gary
> >>>>>>>>
> >>>>>>>> On Mon, Nov 30, 2020 at 10:17 AM Julian Woodward <
> >> julian@ldcvia.com
> >>>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> When the mongodb4 appender was created for log4j2, the ability to
> >>>>>>>> specify a
> >>>>>>>>> factory class/method in the log4j2.xml file was removed, and the
> >>>>>>>>> configuration option was instead reverted to requiring a simple
> >>>>>>>> connection
> >>>>>>>>> string.
> >>>>>>>>>
> >>>>>>>>> Was there a technical reason why that needed to happen, or was it
> >>> just
> >>>>>>>> for
> >>>>>>>>> simplicity at dev time?
> >>>>>>>>>
> >>>>>>>>> I've been relying on the factory approach, as the database
> >>> credentials
> >>>>>>>> are
> >>>>>>>>> not known until run-time in my use-case. I was also looking
> >>> forward to
> >>>>>>>>> having a mongodb4 version to upgrade to, but as it stands now
> >> this
> >>> is
> >>>>>>>>> unfortunately not giving me what I need.
> >>>>>>>>>
> >>>>>>>>> Thanks!
> >>>>>>>>>
> >>>>>>>>> Julian Woodward
> >>>>>>>>>
> >>>>>>>>> PS New to this forum, so please be forgiving of any breaches of
> >>>>>>>> etiquette!
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>
> >>>
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>

Re: log4j2 2.14.0 and the mongodb4 appender

Posted by Ralph Goers <ra...@dslextreme.com>.
If you create a custom Lookup, say CredentialsLookup, when it is called you can make the same query your factory method did. The result of that would then be merged into the connections string for Mongo. By the time the Appender would be resolving that string the Lookup would definitely be available.

Ralph

> On Mar 9, 2021, at 6:39 AM, Gary Gregory <ga...@gmail.com> wrote:
> 
> Well, hot dog dang I don't see support for $$ in MongoDb4Provider.
> 
> Ideally I think the provider should be fed a Configuration where the
> StrSubstitutor can be accessed.
> 
> If you want to provide a failing unit test in that component, I can take a
> look at it.
> 
> But, I am not sure if that will solve the problem because the resolving
> might still happen too soon for you.
> 
> Let's figure that out first.
> 
> Gary
> 
> On Tue, Mar 9, 2021, 02:39 Julian Woodward <ju...@ldcvia.com> wrote:
> 
>> Perhaps it would help if I explain the scenario better. In this
>> application, the MongoDB credentials are not known at design time, nor are
>> they known immediately at start-up time. They're only known when the
>> application has started and has had a chance to go and retrieve them from a
>> secure credentials store. In the mongodb3 appender, the factory
>> class/method allowed me to have code which went and retrieved the
>> credentials and created the mongodb connection. I can't see how to use the
>> $ or $$ mechanism to achieve the same thing.
>> 
>> (If it makes any difference, the framework here is Spring Boot and Vaadin
>> 14, and mongodb is on Atlas).
>> 
>> I'd be really grateful for any pointers! Thanks.
>> 
>> Julian Woodward
>> 
>> 
>> 
>> On Mon, 8 Mar 2021 at 21:15, Gary Gregory <ga...@gmail.com> wrote:
>> 
>>> Sure I know that, I just don't recall if I accounted for $$ in the
>>> code for MongoDB...
>>> 
>>> G ;-) I'll peek tonight.
>>> 
>>> On Mon, Mar 8, 2021 at 2:40 PM Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>>> 
>>>> Gary - the $$ form requires that the component call StrSubstitutor to
>>> resolve the variables. If the application needs to do that for some
>> reason
>>> then the Appender would need to support it.
>>>> 
>>>> Ralph
>>>> 
>>>>> On Mar 8, 2021, at 9:46 AM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>>> 
>>>>> What Ralph said :-)
>>>>> 
>>>>> The tests in Log4j as well as the ones I have at work all use one $
>> in
>>>>> connection strings. I do not have tests that use $$.
>>>>> 
>>>>> Gary
>>>>> 
>>>>> 
>>>>> On Mon, Mar 8, 2021, 11:13 Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>>>> 
>>>>>> If I understand what Gary is saying correctly is that you would
>>> configure
>>>>>> your Log4j2.xml file with the connection string for MongoDB. In the
>>>>>> connection string you would have variables. If the variable is of
>> the
>>> form
>>>>>> ${varName} then it will be resolved when the configuration is
>>> processed. If
>>>>>> a variable is of the form $${varName} then the first ‘$’ is stripped
>>> off
>>>>>> when the configuration is processed and the internal component may
>>> resolve
>>>>>> variables when they are actually used.
>>>>>> 
>>>>>> Variables in Log4j 2 are implemented as Lookups - see
>>>>>> http://logging.apache.org/log4j/2.x/manual/lookups.html for the
>> list
>>> of
>>>>>> Lookups that Log4j provides. You can add your own.
>>>>>> 
>>>>>> Ralph
>>>>>> 
>>>>>>> On Mar 8, 2021, at 7:01 AM, Julian Woodward <ju...@ldcvia.com>
>>> wrote:
>>>>>>> 
>>>>>>> Hi Gary
>>>>>>> 
>>>>>>> It's been a while, but I'm trying this now. I don't understand
>> where
>>> the
>>>>>>> opportunity is to inject values in the way you're describing (the
>> $$
>>>>>>> approach) when log4j2 is being instantiated at startup time by
>>> Spring. By
>>>>>>> the time we reach 'my' code, it's too late and the mongodb4 setup
>> has
>>>>>>> already failed. Have I misunderstood, or is there a code sample
>> that
>>> you
>>>>>>> know of where this is actually in use?
>>>>>>> 
>>>>>>> Many thanks,
>>>>>>> 
>>>>>>> Julian Woodward
>>>>>>> 
>>>>>>> *Liberate your Domino data with LDC Via*
>>>>>>> julian@ldcvia.com
>>>>>>> +44 (0) 7956 227546
>>>>>>> +44 (0) 20 3633 3009
>>>>>>> http://ldcvia.com
>>>>>>> 
>>>>>>> *LDC Via Limited is a limited company registered 09209489 in
>> England
>>> &
>>>>>>> Wales at 24 Ivymount Road, London, SE27 0NB. *
>>>>>>> *Disclaimer: This message is intended only for the use of the
>>> individual
>>>>>> or
>>>>>>> entity to which it is addressed and may contain information which
>> is
>>>>>>> privileged, confidential, proprietary, or exempt from disclosure
>>> under
>>>>>>> applicable law. If you are not the intended recipient or the person
>>>>>>> responsible for delivering the message to the intended recipient,
>>> you are
>>>>>>> strictly prohibited from disclosing, distributing, copying, or in
>>> any way
>>>>>>> using this message. If you have received this communication in
>> error,
>>>>>>> please notify the sender and destroy and delete any copies you may
>>> have
>>>>>>> received. *
>>>>>>> 
>>>>>>> 
>>>>>>> On Mon, 30 Nov 2020 at 23:29, Gary Gregory <garydgregory@gmail.com
>>> 
>>>>>> wrote:
>>>>>>> 
>>>>>>>> Hello Julian,
>>>>>>>> 
>>>>>>>> When I created the version 4 of the MongoDB appender, I realized
>>> that
>>>>>> for
>>>>>>>> all the use cases I had and I felt were reasonable, I could use a
>>>>>>>> connection string, a bit like you can in JDBC, which I could not
>> do
>>>>>> with a
>>>>>>>> version 3 driver. There are two settings IIRC that I did not find
>>>>>> mappings
>>>>>>>> in a version 4 connection string: capped and collection size.
>>>>>>>> 
>>>>>>>> Note that you can also parameterize the configuration with
>>>>>> ${variables}, so
>>>>>>>> you could parameterize the user and password in a connection
>> string,
>>>>>> see:
>>>>>>>> 
>>>>>>>> -
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>> 
>> https://logging.apache.org/log4j/2.x/manual/configuration.html#RuntimeLookup
>>>>>>>> -
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>> 
>> https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution
>>>>>>>> -
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>> 
>> https://logging.apache.org/log4j/2.x/manual/appenders.html#NoSQLAppenderMongoDB4
>>>>>>>> 
>>>>>>>> If you feel like you still need the factory method as a mechanism
>> to
>>>>>> create
>>>>>>>> a provider, then please feel free to provide a PR on GitHub here:
>>>>>>>> https://github.com/apache/logging-log4j2
>>>>>>>> 
>>>>>>>> Gary
>>>>>>>> 
>>>>>>>> On Mon, Nov 30, 2020 at 10:17 AM Julian Woodward <
>> julian@ldcvia.com
>>>> 
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> When the mongodb4 appender was created for log4j2, the ability to
>>>>>>>> specify a
>>>>>>>>> factory class/method in the log4j2.xml file was removed, and the
>>>>>>>>> configuration option was instead reverted to requiring a simple
>>>>>>>> connection
>>>>>>>>> string.
>>>>>>>>> 
>>>>>>>>> Was there a technical reason why that needed to happen, or was it
>>> just
>>>>>>>> for
>>>>>>>>> simplicity at dev time?
>>>>>>>>> 
>>>>>>>>> I've been relying on the factory approach, as the database
>>> credentials
>>>>>>>> are
>>>>>>>>> not known until run-time in my use-case. I was also looking
>>> forward to
>>>>>>>>> having a mongodb4 version to upgrade to, but as it stands now
>> this
>>> is
>>>>>>>>> unfortunately not giving me what I need.
>>>>>>>>> 
>>>>>>>>> Thanks!
>>>>>>>>> 
>>>>>>>>> Julian Woodward
>>>>>>>>> 
>>>>>>>>> PS New to this forum, so please be forgiving of any breaches of
>>>>>>>> etiquette!
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>> 
>>> 
>> 



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Re: log4j2 2.14.0 and the mongodb4 appender

Posted by Gary Gregory <ga...@gmail.com>.
Well, hot dog dang I don't see support for $$ in MongoDb4Provider.

Ideally I think the provider should be fed a Configuration where the
StrSubstitutor can be accessed.

If you want to provide a failing unit test in that component, I can take a
look at it.

But, I am not sure if that will solve the problem because the resolving
might still happen too soon for you.

Let's figure that out first.

Gary

On Tue, Mar 9, 2021, 02:39 Julian Woodward <ju...@ldcvia.com> wrote:

> Perhaps it would help if I explain the scenario better. In this
> application, the MongoDB credentials are not known at design time, nor are
> they known immediately at start-up time. They're only known when the
> application has started and has had a chance to go and retrieve them from a
> secure credentials store. In the mongodb3 appender, the factory
> class/method allowed me to have code which went and retrieved the
> credentials and created the mongodb connection. I can't see how to use the
> $ or $$ mechanism to achieve the same thing.
>
> (If it makes any difference, the framework here is Spring Boot and Vaadin
> 14, and mongodb is on Atlas).
>
> I'd be really grateful for any pointers! Thanks.
>
> Julian Woodward
>
>
>
> On Mon, 8 Mar 2021 at 21:15, Gary Gregory <ga...@gmail.com> wrote:
>
> > Sure I know that, I just don't recall if I accounted for $$ in the
> > code for MongoDB...
> >
> > G ;-) I'll peek tonight.
> >
> > On Mon, Mar 8, 2021 at 2:40 PM Ralph Goers <ra...@dslextreme.com>
> > wrote:
> > >
> > > Gary - the $$ form requires that the component call StrSubstitutor to
> > resolve the variables. If the application needs to do that for some
> reason
> > then the Appender would need to support it.
> > >
> > > Ralph
> > >
> > > > On Mar 8, 2021, at 9:46 AM, Gary Gregory <ga...@gmail.com>
> > wrote:
> > > >
> > > > What Ralph said :-)
> > > >
> > > > The tests in Log4j as well as the ones I have at work all use one $
> in
> > > > connection strings. I do not have tests that use $$.
> > > >
> > > > Gary
> > > >
> > > >
> > > > On Mon, Mar 8, 2021, 11:13 Ralph Goers <ra...@dslextreme.com>
> > wrote:
> > > >
> > > >> If I understand what Gary is saying correctly is that you would
> > configure
> > > >> your Log4j2.xml file with the connection string for MongoDB. In the
> > > >> connection string you would have variables. If the variable is of
> the
> > form
> > > >> ${varName} then it will be resolved when the configuration is
> > processed. If
> > > >> a variable is of the form $${varName} then the first ‘$’ is stripped
> > off
> > > >> when the configuration is processed and the internal component may
> > resolve
> > > >> variables when they are actually used.
> > > >>
> > > >> Variables in Log4j 2 are implemented as Lookups - see
> > > >> http://logging.apache.org/log4j/2.x/manual/lookups.html for the
> list
> > of
> > > >> Lookups that Log4j provides. You can add your own.
> > > >>
> > > >> Ralph
> > > >>
> > > >>> On Mar 8, 2021, at 7:01 AM, Julian Woodward <ju...@ldcvia.com>
> > wrote:
> > > >>>
> > > >>> Hi Gary
> > > >>>
> > > >>> It's been a while, but I'm trying this now. I don't understand
> where
> > the
> > > >>> opportunity is to inject values in the way you're describing (the
> $$
> > > >>> approach) when log4j2 is being instantiated at startup time by
> > Spring. By
> > > >>> the time we reach 'my' code, it's too late and the mongodb4 setup
> has
> > > >>> already failed. Have I misunderstood, or is there a code sample
> that
> > you
> > > >>> know of where this is actually in use?
> > > >>>
> > > >>> Many thanks,
> > > >>>
> > > >>> Julian Woodward
> > > >>>
> > > >>> *Liberate your Domino data with LDC Via*
> > > >>> julian@ldcvia.com
> > > >>> +44 (0) 7956 227546
> > > >>> +44 (0) 20 3633 3009
> > > >>> http://ldcvia.com
> > > >>>
> > > >>> *LDC Via Limited is a limited company registered 09209489 in
> England
> > &
> > > >>> Wales at 24 Ivymount Road, London, SE27 0NB. *
> > > >>> *Disclaimer: This message is intended only for the use of the
> > individual
> > > >> or
> > > >>> entity to which it is addressed and may contain information which
> is
> > > >>> privileged, confidential, proprietary, or exempt from disclosure
> > under
> > > >>> applicable law. If you are not the intended recipient or the person
> > > >>> responsible for delivering the message to the intended recipient,
> > you are
> > > >>> strictly prohibited from disclosing, distributing, copying, or in
> > any way
> > > >>> using this message. If you have received this communication in
> error,
> > > >>> please notify the sender and destroy and delete any copies you may
> > have
> > > >>> received. *
> > > >>>
> > > >>>
> > > >>> On Mon, 30 Nov 2020 at 23:29, Gary Gregory <garydgregory@gmail.com
> >
> > > >> wrote:
> > > >>>
> > > >>>> Hello Julian,
> > > >>>>
> > > >>>> When I created the version 4 of the MongoDB appender, I realized
> > that
> > > >> for
> > > >>>> all the use cases I had and I felt were reasonable, I could use a
> > > >>>> connection string, a bit like you can in JDBC, which I could not
> do
> > > >> with a
> > > >>>> version 3 driver. There are two settings IIRC that I did not find
> > > >> mappings
> > > >>>> in a version 4 connection string: capped and collection size.
> > > >>>>
> > > >>>> Note that you can also parameterize the configuration with
> > > >> ${variables}, so
> > > >>>> you could parameterize the user and password in a connection
> string,
> > > >> see:
> > > >>>>
> > > >>>> -
> > > >>>>
> > > >>>>
> > > >>
> >
> https://logging.apache.org/log4j/2.x/manual/configuration.html#RuntimeLookup
> > > >>>> -
> > > >>>>
> > > >>>>
> > > >>
> >
> https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution
> > > >>>> -
> > > >>>>
> > > >>>>
> > > >>
> >
> https://logging.apache.org/log4j/2.x/manual/appenders.html#NoSQLAppenderMongoDB4
> > > >>>>
> > > >>>> If you feel like you still need the factory method as a mechanism
> to
> > > >> create
> > > >>>> a provider, then please feel free to provide a PR on GitHub here:
> > > >>>> https://github.com/apache/logging-log4j2
> > > >>>>
> > > >>>> Gary
> > > >>>>
> > > >>>> On Mon, Nov 30, 2020 at 10:17 AM Julian Woodward <
> julian@ldcvia.com
> > >
> > > >>>> wrote:
> > > >>>>
> > > >>>>> When the mongodb4 appender was created for log4j2, the ability to
> > > >>>> specify a
> > > >>>>> factory class/method in the log4j2.xml file was removed, and the
> > > >>>>> configuration option was instead reverted to requiring a simple
> > > >>>> connection
> > > >>>>> string.
> > > >>>>>
> > > >>>>> Was there a technical reason why that needed to happen, or was it
> > just
> > > >>>> for
> > > >>>>> simplicity at dev time?
> > > >>>>>
> > > >>>>> I've been relying on the factory approach, as the database
> > credentials
> > > >>>> are
> > > >>>>> not known until run-time in my use-case. I was also looking
> > forward to
> > > >>>>> having a mongodb4 version to upgrade to, but as it stands now
> this
> > is
> > > >>>>> unfortunately not giving me what I need.
> > > >>>>>
> > > >>>>> Thanks!
> > > >>>>>
> > > >>>>> Julian Woodward
> > > >>>>>
> > > >>>>> PS New to this forum, so please be forgiving of any breaches of
> > > >>>> etiquette!
> > > >>>>>
> > > >>>>
> > > >>
> > > >>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> > > >>
> > > >>
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
>

Re: log4j2 2.14.0 and the mongodb4 appender

Posted by Julian Woodward <ju...@ldcvia.com>.
Perhaps it would help if I explain the scenario better. In this
application, the MongoDB credentials are not known at design time, nor are
they known immediately at start-up time. They're only known when the
application has started and has had a chance to go and retrieve them from a
secure credentials store. In the mongodb3 appender, the factory
class/method allowed me to have code which went and retrieved the
credentials and created the mongodb connection. I can't see how to use the
$ or $$ mechanism to achieve the same thing.

(If it makes any difference, the framework here is Spring Boot and Vaadin
14, and mongodb is on Atlas).

I'd be really grateful for any pointers! Thanks.

Julian Woodward



On Mon, 8 Mar 2021 at 21:15, Gary Gregory <ga...@gmail.com> wrote:

> Sure I know that, I just don't recall if I accounted for $$ in the
> code for MongoDB...
>
> G ;-) I'll peek tonight.
>
> On Mon, Mar 8, 2021 at 2:40 PM Ralph Goers <ra...@dslextreme.com>
> wrote:
> >
> > Gary - the $$ form requires that the component call StrSubstitutor to
> resolve the variables. If the application needs to do that for some reason
> then the Appender would need to support it.
> >
> > Ralph
> >
> > > On Mar 8, 2021, at 9:46 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> > >
> > > What Ralph said :-)
> > >
> > > The tests in Log4j as well as the ones I have at work all use one $ in
> > > connection strings. I do not have tests that use $$.
> > >
> > > Gary
> > >
> > >
> > > On Mon, Mar 8, 2021, 11:13 Ralph Goers <ra...@dslextreme.com>
> wrote:
> > >
> > >> If I understand what Gary is saying correctly is that you would
> configure
> > >> your Log4j2.xml file with the connection string for MongoDB. In the
> > >> connection string you would have variables. If the variable is of the
> form
> > >> ${varName} then it will be resolved when the configuration is
> processed. If
> > >> a variable is of the form $${varName} then the first ‘$’ is stripped
> off
> > >> when the configuration is processed and the internal component may
> resolve
> > >> variables when they are actually used.
> > >>
> > >> Variables in Log4j 2 are implemented as Lookups - see
> > >> http://logging.apache.org/log4j/2.x/manual/lookups.html for the list
> of
> > >> Lookups that Log4j provides. You can add your own.
> > >>
> > >> Ralph
> > >>
> > >>> On Mar 8, 2021, at 7:01 AM, Julian Woodward <ju...@ldcvia.com>
> wrote:
> > >>>
> > >>> Hi Gary
> > >>>
> > >>> It's been a while, but I'm trying this now. I don't understand where
> the
> > >>> opportunity is to inject values in the way you're describing (the $$
> > >>> approach) when log4j2 is being instantiated at startup time by
> Spring. By
> > >>> the time we reach 'my' code, it's too late and the mongodb4 setup has
> > >>> already failed. Have I misunderstood, or is there a code sample that
> you
> > >>> know of where this is actually in use?
> > >>>
> > >>> Many thanks,
> > >>>
> > >>> Julian Woodward
> > >>>
> > >>> *Liberate your Domino data with LDC Via*
> > >>> julian@ldcvia.com
> > >>> +44 (0) 7956 227546
> > >>> +44 (0) 20 3633 3009
> > >>> http://ldcvia.com
> > >>>
> > >>> *LDC Via Limited is a limited company registered 09209489 in England
> &
> > >>> Wales at 24 Ivymount Road, London, SE27 0NB. *
> > >>> *Disclaimer: This message is intended only for the use of the
> individual
> > >> or
> > >>> entity to which it is addressed and may contain information which is
> > >>> privileged, confidential, proprietary, or exempt from disclosure
> under
> > >>> applicable law. If you are not the intended recipient or the person
> > >>> responsible for delivering the message to the intended recipient,
> you are
> > >>> strictly prohibited from disclosing, distributing, copying, or in
> any way
> > >>> using this message. If you have received this communication in error,
> > >>> please notify the sender and destroy and delete any copies you may
> have
> > >>> received. *
> > >>>
> > >>>
> > >>> On Mon, 30 Nov 2020 at 23:29, Gary Gregory <ga...@gmail.com>
> > >> wrote:
> > >>>
> > >>>> Hello Julian,
> > >>>>
> > >>>> When I created the version 4 of the MongoDB appender, I realized
> that
> > >> for
> > >>>> all the use cases I had and I felt were reasonable, I could use a
> > >>>> connection string, a bit like you can in JDBC, which I could not do
> > >> with a
> > >>>> version 3 driver. There are two settings IIRC that I did not find
> > >> mappings
> > >>>> in a version 4 connection string: capped and collection size.
> > >>>>
> > >>>> Note that you can also parameterize the configuration with
> > >> ${variables}, so
> > >>>> you could parameterize the user and password in a connection string,
> > >> see:
> > >>>>
> > >>>> -
> > >>>>
> > >>>>
> > >>
> https://logging.apache.org/log4j/2.x/manual/configuration.html#RuntimeLookup
> > >>>> -
> > >>>>
> > >>>>
> > >>
> https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution
> > >>>> -
> > >>>>
> > >>>>
> > >>
> https://logging.apache.org/log4j/2.x/manual/appenders.html#NoSQLAppenderMongoDB4
> > >>>>
> > >>>> If you feel like you still need the factory method as a mechanism to
> > >> create
> > >>>> a provider, then please feel free to provide a PR on GitHub here:
> > >>>> https://github.com/apache/logging-log4j2
> > >>>>
> > >>>> Gary
> > >>>>
> > >>>> On Mon, Nov 30, 2020 at 10:17 AM Julian Woodward <julian@ldcvia.com
> >
> > >>>> wrote:
> > >>>>
> > >>>>> When the mongodb4 appender was created for log4j2, the ability to
> > >>>> specify a
> > >>>>> factory class/method in the log4j2.xml file was removed, and the
> > >>>>> configuration option was instead reverted to requiring a simple
> > >>>> connection
> > >>>>> string.
> > >>>>>
> > >>>>> Was there a technical reason why that needed to happen, or was it
> just
> > >>>> for
> > >>>>> simplicity at dev time?
> > >>>>>
> > >>>>> I've been relying on the factory approach, as the database
> credentials
> > >>>> are
> > >>>>> not known until run-time in my use-case. I was also looking
> forward to
> > >>>>> having a mongodb4 version to upgrade to, but as it stands now this
> is
> > >>>>> unfortunately not giving me what I need.
> > >>>>>
> > >>>>> Thanks!
> > >>>>>
> > >>>>> Julian Woodward
> > >>>>>
> > >>>>> PS New to this forum, so please be forgiving of any breaches of
> > >>>> etiquette!
> > >>>>>
> > >>>>
> > >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >>
> > >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>

Re: log4j2 2.14.0 and the mongodb4 appender

Posted by Gary Gregory <ga...@gmail.com>.
Sure I know that, I just don't recall if I accounted for $$ in the
code for MongoDB...

G ;-) I'll peek tonight.

On Mon, Mar 8, 2021 at 2:40 PM Ralph Goers <ra...@dslextreme.com> wrote:
>
> Gary - the $$ form requires that the component call StrSubstitutor to resolve the variables. If the application needs to do that for some reason then the Appender would need to support it.
>
> Ralph
>
> > On Mar 8, 2021, at 9:46 AM, Gary Gregory <ga...@gmail.com> wrote:
> >
> > What Ralph said :-)
> >
> > The tests in Log4j as well as the ones I have at work all use one $ in
> > connection strings. I do not have tests that use $$.
> >
> > Gary
> >
> >
> > On Mon, Mar 8, 2021, 11:13 Ralph Goers <ra...@dslextreme.com> wrote:
> >
> >> If I understand what Gary is saying correctly is that you would configure
> >> your Log4j2.xml file with the connection string for MongoDB. In the
> >> connection string you would have variables. If the variable is of the form
> >> ${varName} then it will be resolved when the configuration is processed. If
> >> a variable is of the form $${varName} then the first ‘$’ is stripped off
> >> when the configuration is processed and the internal component may resolve
> >> variables when they are actually used.
> >>
> >> Variables in Log4j 2 are implemented as Lookups - see
> >> http://logging.apache.org/log4j/2.x/manual/lookups.html for the list of
> >> Lookups that Log4j provides. You can add your own.
> >>
> >> Ralph
> >>
> >>> On Mar 8, 2021, at 7:01 AM, Julian Woodward <ju...@ldcvia.com> wrote:
> >>>
> >>> Hi Gary
> >>>
> >>> It's been a while, but I'm trying this now. I don't understand where the
> >>> opportunity is to inject values in the way you're describing (the $$
> >>> approach) when log4j2 is being instantiated at startup time by Spring. By
> >>> the time we reach 'my' code, it's too late and the mongodb4 setup has
> >>> already failed. Have I misunderstood, or is there a code sample that you
> >>> know of where this is actually in use?
> >>>
> >>> Many thanks,
> >>>
> >>> Julian Woodward
> >>>
> >>> *Liberate your Domino data with LDC Via*
> >>> julian@ldcvia.com
> >>> +44 (0) 7956 227546
> >>> +44 (0) 20 3633 3009
> >>> http://ldcvia.com
> >>>
> >>> *LDC Via Limited is a limited company registered 09209489 in England &
> >>> Wales at 24 Ivymount Road, London, SE27 0NB. *
> >>> *Disclaimer: This message is intended only for the use of the individual
> >> or
> >>> entity to which it is addressed and may contain information which is
> >>> privileged, confidential, proprietary, or exempt from disclosure under
> >>> applicable law. If you are not the intended recipient or the person
> >>> responsible for delivering the message to the intended recipient, you are
> >>> strictly prohibited from disclosing, distributing, copying, or in any way
> >>> using this message. If you have received this communication in error,
> >>> please notify the sender and destroy and delete any copies you may have
> >>> received. *
> >>>
> >>>
> >>> On Mon, 30 Nov 2020 at 23:29, Gary Gregory <ga...@gmail.com>
> >> wrote:
> >>>
> >>>> Hello Julian,
> >>>>
> >>>> When I created the version 4 of the MongoDB appender, I realized that
> >> for
> >>>> all the use cases I had and I felt were reasonable, I could use a
> >>>> connection string, a bit like you can in JDBC, which I could not do
> >> with a
> >>>> version 3 driver. There are two settings IIRC that I did not find
> >> mappings
> >>>> in a version 4 connection string: capped and collection size.
> >>>>
> >>>> Note that you can also parameterize the configuration with
> >> ${variables}, so
> >>>> you could parameterize the user and password in a connection string,
> >> see:
> >>>>
> >>>> -
> >>>>
> >>>>
> >> https://logging.apache.org/log4j/2.x/manual/configuration.html#RuntimeLookup
> >>>> -
> >>>>
> >>>>
> >> https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution
> >>>> -
> >>>>
> >>>>
> >> https://logging.apache.org/log4j/2.x/manual/appenders.html#NoSQLAppenderMongoDB4
> >>>>
> >>>> If you feel like you still need the factory method as a mechanism to
> >> create
> >>>> a provider, then please feel free to provide a PR on GitHub here:
> >>>> https://github.com/apache/logging-log4j2
> >>>>
> >>>> Gary
> >>>>
> >>>> On Mon, Nov 30, 2020 at 10:17 AM Julian Woodward <ju...@ldcvia.com>
> >>>> wrote:
> >>>>
> >>>>> When the mongodb4 appender was created for log4j2, the ability to
> >>>> specify a
> >>>>> factory class/method in the log4j2.xml file was removed, and the
> >>>>> configuration option was instead reverted to requiring a simple
> >>>> connection
> >>>>> string.
> >>>>>
> >>>>> Was there a technical reason why that needed to happen, or was it just
> >>>> for
> >>>>> simplicity at dev time?
> >>>>>
> >>>>> I've been relying on the factory approach, as the database credentials
> >>>> are
> >>>>> not known until run-time in my use-case. I was also looking forward to
> >>>>> having a mongodb4 version to upgrade to, but as it stands now this is
> >>>>> unfortunately not giving me what I need.
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> Julian Woodward
> >>>>>
> >>>>> PS New to this forum, so please be forgiving of any breaches of
> >>>> etiquette!
> >>>>>
> >>>>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Re: log4j2 2.14.0 and the mongodb4 appender

Posted by Ralph Goers <ra...@dslextreme.com>.
Gary - the $$ form requires that the component call StrSubstitutor to resolve the variables. If the application needs to do that for some reason then the Appender would need to support it.

Ralph

> On Mar 8, 2021, at 9:46 AM, Gary Gregory <ga...@gmail.com> wrote:
> 
> What Ralph said :-)
> 
> The tests in Log4j as well as the ones I have at work all use one $ in
> connection strings. I do not have tests that use $$.
> 
> Gary
> 
> 
> On Mon, Mar 8, 2021, 11:13 Ralph Goers <ra...@dslextreme.com> wrote:
> 
>> If I understand what Gary is saying correctly is that you would configure
>> your Log4j2.xml file with the connection string for MongoDB. In the
>> connection string you would have variables. If the variable is of the form
>> ${varName} then it will be resolved when the configuration is processed. If
>> a variable is of the form $${varName} then the first ‘$’ is stripped off
>> when the configuration is processed and the internal component may resolve
>> variables when they are actually used.
>> 
>> Variables in Log4j 2 are implemented as Lookups - see
>> http://logging.apache.org/log4j/2.x/manual/lookups.html for the list of
>> Lookups that Log4j provides. You can add your own.
>> 
>> Ralph
>> 
>>> On Mar 8, 2021, at 7:01 AM, Julian Woodward <ju...@ldcvia.com> wrote:
>>> 
>>> Hi Gary
>>> 
>>> It's been a while, but I'm trying this now. I don't understand where the
>>> opportunity is to inject values in the way you're describing (the $$
>>> approach) when log4j2 is being instantiated at startup time by Spring. By
>>> the time we reach 'my' code, it's too late and the mongodb4 setup has
>>> already failed. Have I misunderstood, or is there a code sample that you
>>> know of where this is actually in use?
>>> 
>>> Many thanks,
>>> 
>>> Julian Woodward
>>> 
>>> *Liberate your Domino data with LDC Via*
>>> julian@ldcvia.com
>>> +44 (0) 7956 227546
>>> +44 (0) 20 3633 3009
>>> http://ldcvia.com
>>> 
>>> *LDC Via Limited is a limited company registered 09209489 in England &
>>> Wales at 24 Ivymount Road, London, SE27 0NB. *
>>> *Disclaimer: This message is intended only for the use of the individual
>> or
>>> entity to which it is addressed and may contain information which is
>>> privileged, confidential, proprietary, or exempt from disclosure under
>>> applicable law. If you are not the intended recipient or the person
>>> responsible for delivering the message to the intended recipient, you are
>>> strictly prohibited from disclosing, distributing, copying, or in any way
>>> using this message. If you have received this communication in error,
>>> please notify the sender and destroy and delete any copies you may have
>>> received. *
>>> 
>>> 
>>> On Mon, 30 Nov 2020 at 23:29, Gary Gregory <ga...@gmail.com>
>> wrote:
>>> 
>>>> Hello Julian,
>>>> 
>>>> When I created the version 4 of the MongoDB appender, I realized that
>> for
>>>> all the use cases I had and I felt were reasonable, I could use a
>>>> connection string, a bit like you can in JDBC, which I could not do
>> with a
>>>> version 3 driver. There are two settings IIRC that I did not find
>> mappings
>>>> in a version 4 connection string: capped and collection size.
>>>> 
>>>> Note that you can also parameterize the configuration with
>> ${variables}, so
>>>> you could parameterize the user and password in a connection string,
>> see:
>>>> 
>>>> -
>>>> 
>>>> 
>> https://logging.apache.org/log4j/2.x/manual/configuration.html#RuntimeLookup
>>>> -
>>>> 
>>>> 
>> https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution
>>>> -
>>>> 
>>>> 
>> https://logging.apache.org/log4j/2.x/manual/appenders.html#NoSQLAppenderMongoDB4
>>>> 
>>>> If you feel like you still need the factory method as a mechanism to
>> create
>>>> a provider, then please feel free to provide a PR on GitHub here:
>>>> https://github.com/apache/logging-log4j2
>>>> 
>>>> Gary
>>>> 
>>>> On Mon, Nov 30, 2020 at 10:17 AM Julian Woodward <ju...@ldcvia.com>
>>>> wrote:
>>>> 
>>>>> When the mongodb4 appender was created for log4j2, the ability to
>>>> specify a
>>>>> factory class/method in the log4j2.xml file was removed, and the
>>>>> configuration option was instead reverted to requiring a simple
>>>> connection
>>>>> string.
>>>>> 
>>>>> Was there a technical reason why that needed to happen, or was it just
>>>> for
>>>>> simplicity at dev time?
>>>>> 
>>>>> I've been relying on the factory approach, as the database credentials
>>>> are
>>>>> not known until run-time in my use-case. I was also looking forward to
>>>>> having a mongodb4 version to upgrade to, but as it stands now this is
>>>>> unfortunately not giving me what I need.
>>>>> 
>>>>> Thanks!
>>>>> 
>>>>> Julian Woodward
>>>>> 
>>>>> PS New to this forum, so please be forgiving of any breaches of
>>>> etiquette!
>>>>> 
>>>> 
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>> 
>> 



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Re: log4j2 2.14.0 and the mongodb4 appender

Posted by Gary Gregory <ga...@gmail.com>.
What Ralph said :-)

The tests in Log4j as well as the ones I have at work all use one $ in
connection strings. I do not have tests that use $$.

Gary


On Mon, Mar 8, 2021, 11:13 Ralph Goers <ra...@dslextreme.com> wrote:

> If I understand what Gary is saying correctly is that you would configure
> your Log4j2.xml file with the connection string for MongoDB. In the
> connection string you would have variables. If the variable is of the form
> ${varName} then it will be resolved when the configuration is processed. If
> a variable is of the form $${varName} then the first ‘$’ is stripped off
> when the configuration is processed and the internal component may resolve
> variables when they are actually used.
>
> Variables in Log4j 2 are implemented as Lookups - see
> http://logging.apache.org/log4j/2.x/manual/lookups.html for the list of
> Lookups that Log4j provides. You can add your own.
>
> Ralph
>
> > On Mar 8, 2021, at 7:01 AM, Julian Woodward <ju...@ldcvia.com> wrote:
> >
> > Hi Gary
> >
> > It's been a while, but I'm trying this now. I don't understand where the
> > opportunity is to inject values in the way you're describing (the $$
> > approach) when log4j2 is being instantiated at startup time by Spring. By
> > the time we reach 'my' code, it's too late and the mongodb4 setup has
> > already failed. Have I misunderstood, or is there a code sample that you
> > know of where this is actually in use?
> >
> > Many thanks,
> >
> > Julian Woodward
> >
> > *Liberate your Domino data with LDC Via*
> > julian@ldcvia.com
> > +44 (0) 7956 227546
> > +44 (0) 20 3633 3009
> > http://ldcvia.com
> >
> > *LDC Via Limited is a limited company registered 09209489 in England &
> > Wales at 24 Ivymount Road, London, SE27 0NB. *
> > *Disclaimer: This message is intended only for the use of the individual
> or
> > entity to which it is addressed and may contain information which is
> > privileged, confidential, proprietary, or exempt from disclosure under
> > applicable law. If you are not the intended recipient or the person
> > responsible for delivering the message to the intended recipient, you are
> > strictly prohibited from disclosing, distributing, copying, or in any way
> > using this message. If you have received this communication in error,
> > please notify the sender and destroy and delete any copies you may have
> > received. *
> >
> >
> > On Mon, 30 Nov 2020 at 23:29, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> >> Hello Julian,
> >>
> >> When I created the version 4 of the MongoDB appender, I realized that
> for
> >> all the use cases I had and I felt were reasonable, I could use a
> >> connection string, a bit like you can in JDBC, which I could not do
> with a
> >> version 3 driver. There are two settings IIRC that I did not find
> mappings
> >> in a version 4 connection string: capped and collection size.
> >>
> >> Note that you can also parameterize the configuration with
> ${variables}, so
> >> you could parameterize the user and password in a connection string,
> see:
> >>
> >> -
> >>
> >>
> https://logging.apache.org/log4j/2.x/manual/configuration.html#RuntimeLookup
> >> -
> >>
> >>
> https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution
> >> -
> >>
> >>
> https://logging.apache.org/log4j/2.x/manual/appenders.html#NoSQLAppenderMongoDB4
> >>
> >> If you feel like you still need the factory method as a mechanism to
> create
> >> a provider, then please feel free to provide a PR on GitHub here:
> >> https://github.com/apache/logging-log4j2
> >>
> >> Gary
> >>
> >> On Mon, Nov 30, 2020 at 10:17 AM Julian Woodward <ju...@ldcvia.com>
> >> wrote:
> >>
> >>> When the mongodb4 appender was created for log4j2, the ability to
> >> specify a
> >>> factory class/method in the log4j2.xml file was removed, and the
> >>> configuration option was instead reverted to requiring a simple
> >> connection
> >>> string.
> >>>
> >>> Was there a technical reason why that needed to happen, or was it just
> >> for
> >>> simplicity at dev time?
> >>>
> >>> I've been relying on the factory approach, as the database credentials
> >> are
> >>> not known until run-time in my use-case. I was also looking forward to
> >>> having a mongodb4 version to upgrade to, but as it stands now this is
> >>> unfortunately not giving me what I need.
> >>>
> >>> Thanks!
> >>>
> >>> Julian Woodward
> >>>
> >>> PS New to this forum, so please be forgiving of any breaches of
> >> etiquette!
> >>>
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>

Re: log4j2 2.14.0 and the mongodb4 appender

Posted by Ralph Goers <ra...@dslextreme.com>.
If I understand what Gary is saying correctly is that you would configure your Log4j2.xml file with the connection string for MongoDB. In the connection string you would have variables. If the variable is of the form ${varName} then it will be resolved when the configuration is processed. If a variable is of the form $${varName} then the first ‘$’ is stripped off when the configuration is processed and the internal component may resolve variables when they are actually used. 

Variables in Log4j 2 are implemented as Lookups - see http://logging.apache.org/log4j/2.x/manual/lookups.html for the list of Lookups that Log4j provides. You can add your own.

Ralph

> On Mar 8, 2021, at 7:01 AM, Julian Woodward <ju...@ldcvia.com> wrote:
> 
> Hi Gary
> 
> It's been a while, but I'm trying this now. I don't understand where the
> opportunity is to inject values in the way you're describing (the $$
> approach) when log4j2 is being instantiated at startup time by Spring. By
> the time we reach 'my' code, it's too late and the mongodb4 setup has
> already failed. Have I misunderstood, or is there a code sample that you
> know of where this is actually in use?
> 
> Many thanks,
> 
> Julian Woodward
> 
> *Liberate your Domino data with LDC Via*
> julian@ldcvia.com
> +44 (0) 7956 227546
> +44 (0) 20 3633 3009
> http://ldcvia.com
> 
> *LDC Via Limited is a limited company registered 09209489 in England &
> Wales at 24 Ivymount Road, London, SE27 0NB. *
> *Disclaimer: This message is intended only for the use of the individual or
> entity to which it is addressed and may contain information which is
> privileged, confidential, proprietary, or exempt from disclosure under
> applicable law. If you are not the intended recipient or the person
> responsible for delivering the message to the intended recipient, you are
> strictly prohibited from disclosing, distributing, copying, or in any way
> using this message. If you have received this communication in error,
> please notify the sender and destroy and delete any copies you may have
> received. *
> 
> 
> On Mon, 30 Nov 2020 at 23:29, Gary Gregory <ga...@gmail.com> wrote:
> 
>> Hello Julian,
>> 
>> When I created the version 4 of the MongoDB appender, I realized that for
>> all the use cases I had and I felt were reasonable, I could use a
>> connection string, a bit like you can in JDBC, which I could not do with a
>> version 3 driver. There are two settings IIRC that I did not find mappings
>> in a version 4 connection string: capped and collection size.
>> 
>> Note that you can also parameterize the configuration with ${variables}, so
>> you could parameterize the user and password in a connection string, see:
>> 
>> -
>> 
>> https://logging.apache.org/log4j/2.x/manual/configuration.html#RuntimeLookup
>> -
>> 
>> https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution
>> -
>> 
>> https://logging.apache.org/log4j/2.x/manual/appenders.html#NoSQLAppenderMongoDB4
>> 
>> If you feel like you still need the factory method as a mechanism to create
>> a provider, then please feel free to provide a PR on GitHub here:
>> https://github.com/apache/logging-log4j2
>> 
>> Gary
>> 
>> On Mon, Nov 30, 2020 at 10:17 AM Julian Woodward <ju...@ldcvia.com>
>> wrote:
>> 
>>> When the mongodb4 appender was created for log4j2, the ability to
>> specify a
>>> factory class/method in the log4j2.xml file was removed, and the
>>> configuration option was instead reverted to requiring a simple
>> connection
>>> string.
>>> 
>>> Was there a technical reason why that needed to happen, or was it just
>> for
>>> simplicity at dev time?
>>> 
>>> I've been relying on the factory approach, as the database credentials
>> are
>>> not known until run-time in my use-case. I was also looking forward to
>>> having a mongodb4 version to upgrade to, but as it stands now this is
>>> unfortunately not giving me what I need.
>>> 
>>> Thanks!
>>> 
>>> Julian Woodward
>>> 
>>> PS New to this forum, so please be forgiving of any breaches of
>> etiquette!
>>> 
>> 



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Re: log4j2 2.14.0 and the mongodb4 appender

Posted by Julian Woodward <ju...@ldcvia.com>.
Hi Gary

It's been a while, but I'm trying this now. I don't understand where the
opportunity is to inject values in the way you're describing (the $$
approach) when log4j2 is being instantiated at startup time by Spring. By
the time we reach 'my' code, it's too late and the mongodb4 setup has
already failed. Have I misunderstood, or is there a code sample that you
know of where this is actually in use?

Many thanks,

Julian Woodward

*Liberate your Domino data with LDC Via*
julian@ldcvia.com
+44 (0) 7956 227546
+44 (0) 20 3633 3009
http://ldcvia.com

*LDC Via Limited is a limited company registered 09209489 in England &
Wales at 24 Ivymount Road, London, SE27 0NB. *
*Disclaimer: This message is intended only for the use of the individual or
entity to which it is addressed and may contain information which is
privileged, confidential, proprietary, or exempt from disclosure under
applicable law. If you are not the intended recipient or the person
responsible for delivering the message to the intended recipient, you are
strictly prohibited from disclosing, distributing, copying, or in any way
using this message. If you have received this communication in error,
please notify the sender and destroy and delete any copies you may have
received. *


On Mon, 30 Nov 2020 at 23:29, Gary Gregory <ga...@gmail.com> wrote:

> Hello Julian,
>
> When I created the version 4 of the MongoDB appender, I realized that for
> all the use cases I had and I felt were reasonable, I could use a
> connection string, a bit like you can in JDBC, which I could not do with a
> version 3 driver. There are two settings IIRC that I did not find mappings
> in a version 4 connection string: capped and collection size.
>
> Note that you can also parameterize the configuration with ${variables}, so
> you could parameterize the user and password in a connection string, see:
>
> -
>
> https://logging.apache.org/log4j/2.x/manual/configuration.html#RuntimeLookup
> -
>
> https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution
> -
>
> https://logging.apache.org/log4j/2.x/manual/appenders.html#NoSQLAppenderMongoDB4
>
> If you feel like you still need the factory method as a mechanism to create
> a provider, then please feel free to provide a PR on GitHub here:
> https://github.com/apache/logging-log4j2
>
> Gary
>
> On Mon, Nov 30, 2020 at 10:17 AM Julian Woodward <ju...@ldcvia.com>
> wrote:
>
> > When the mongodb4 appender was created for log4j2, the ability to
> specify a
> > factory class/method in the log4j2.xml file was removed, and the
> > configuration option was instead reverted to requiring a simple
> connection
> > string.
> >
> > Was there a technical reason why that needed to happen, or was it just
> for
> > simplicity at dev time?
> >
> > I've been relying on the factory approach, as the database credentials
> are
> > not known until run-time in my use-case. I was also looking forward to
> > having a mongodb4 version to upgrade to, but as it stands now this is
> > unfortunately not giving me what I need.
> >
> > Thanks!
> >
> > Julian Woodward
> >
> > PS New to this forum, so please be forgiving of any breaches of
> etiquette!
> >
>

Re: log4j2 2.14.0 and the mongodb4 appender

Posted by Gary Gregory <ga...@gmail.com>.
Hello Julian,

When I created the version 4 of the MongoDB appender, I realized that for
all the use cases I had and I felt were reasonable, I could use a
connection string, a bit like you can in JDBC, which I could not do with a
version 3 driver. There are two settings IIRC that I did not find mappings
in a version 4 connection string: capped and collection size.

Note that you can also parameterize the configuration with ${variables}, so
you could parameterize the user and password in a connection string, see:

-
https://logging.apache.org/log4j/2.x/manual/configuration.html#RuntimeLookup
-
https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution
-
https://logging.apache.org/log4j/2.x/manual/appenders.html#NoSQLAppenderMongoDB4

If you feel like you still need the factory method as a mechanism to create
a provider, then please feel free to provide a PR on GitHub here:
https://github.com/apache/logging-log4j2

Gary

On Mon, Nov 30, 2020 at 10:17 AM Julian Woodward <ju...@ldcvia.com> wrote:

> When the mongodb4 appender was created for log4j2, the ability to specify a
> factory class/method in the log4j2.xml file was removed, and the
> configuration option was instead reverted to requiring a simple connection
> string.
>
> Was there a technical reason why that needed to happen, or was it just for
> simplicity at dev time?
>
> I've been relying on the factory approach, as the database credentials are
> not known until run-time in my use-case. I was also looking forward to
> having a mongodb4 version to upgrade to, but as it stands now this is
> unfortunately not giving me what I need.
>
> Thanks!
>
> Julian Woodward
>
> PS New to this forum, so please be forgiving of any breaches of etiquette!
>