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
>
>
