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 <garydgreg...@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 <jul...@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 <garydgreg...@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.go...@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 <garydgreg...@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 <ralph.go...@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 <jul...@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*
>>>>>>> jul...@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 <garydgreg...@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 <
>> jul...@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-unsubscr...@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
