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 <ralph.go...@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 <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
>
>

Reply via email to