On Fri, Feb 23, 2018 at 7:02 PM, Jeffrey Shaw <shawj...@gmail.com> wrote:

> Hi All,
> I spent some more time on this tonight. I've brought my code up to date for
> log4j versions 2 and 3. version 2
> <https://github.com/shawjef3/logging-log4j2/tree/message-
> location-release-2.x>
> version
> 3 <https://github.com/shawjef3/logging-log4j2/tree/message-location>
> Per Ralph Goers and some others I removed SourceLocation and reverted back
> to StackTraceElement.
>

Hello,

Can you create pull requests so we can see better what you are proposing?

Thank you!
Gary



>
> In case this thread is lost in your email, the changes I worked on expose
> the location part of the Message to loggers, so that if the source location
> is known at compile time, it can be added to the log with no runtime cost.
> An example use is the scala loggers
> <https://github.com/shawjef3/logging-log4j-scala> which are implemented
> with macros, and therefore have that information available at no cost to
> the developer, either.
>
> On Sat, Dec 23, 2017 at 2:14 PM, Mikael Ståldal <mi...@apache.org> wrote:
>
> > Yes, StackTraceElement does not allow null methodName.
> >
> > But what about using the empty string, or a string like "<unknown>" if it
> > is not possible to get?
> >
> >
> > On 2017-12-22 20:26, Jeffrey Shaw wrote:
> >
> >> I didn't know about clirr, but I can try running that. I tried to not
> >> break
> >> any existing public methods.
> >>
> >> I created SourceLocation because I think for Scala macros, the method
> name
> >> can not exist, but StackTraceElement requires a method name. I'll double
> >> check this.
> >>
> >> On Thu, Dec 21, 2017 at 12:40 AM, Ralph Goers <
> ralph.go...@dslextreme.com
> >> >
> >> wrote:
> >>
> >> I’m not sure I would be comfortable applying the patch this way. Have
> you
> >>> run a clirr report on your changes? I am concerned that this could
> break
> >>> customizations that users might have made. What is the reason
> >>> SourceLocation had to be used instead of StackTraceElement?
> >>>
> >>> Ralph
> >>>
> >>> On Dec 20, 2017, at 9:58 PM, Jeffrey Shaw <shawj...@gmail.com> wrote:
> >>>>
> >>>> It looks like the location only ever gets the file name, because
> that's
> >>>> what StackTraceElement gives. So that's fine.
> >>>>
> >>>> I think I'm ready for a formal review. Should I create pull requests
> on
> >>>> github for https://github.com/shawjef3/logging-log4j2/tree/message-
> >>>>
> >>> location
> >>>
> >>>> and https://github.com/shawjef3/logging-log4j-scala/tree/
> >>>>
> >>> message-location,
> >>>
> >>>> or is there another process?
> >>>>
> >>>>
> >>>> On Wed, Dec 20, 2017 at 2:11 PM, Matt Sicker <boa...@gmail.com>
> wrote:
> >>>>
> >>>> I think that should be configurable in the layout options.
> >>>>>
> >>>>> On 20 December 2017 at 13:04, Dominik Psenner <dpsen...@gmail.com>
> >>>>>
> >>>> wrote:
> >>>
> >>>>
> >>>>> Could a compile time environment variable like SrcRootDirectory do
> the
> >>>>>>
> >>>>> job?
> >>>>>
> >>>>>>
> >>>>>> On 20 Dec 2017 7:49 p.m., "Jeffrey Shaw" <shawj...@gmail.com>
> wrote:
> >>>>>>
> >>>>>> I got it working using a custom ExtendedLogger instead of mocking.
> >>>>>>>
> >>>>>>> It looks like for file name, there are only two options. We can
> have
> >>>>>>>
> >>>>>> the
> >>>>>
> >>>>>> file name, or the full path to the file. The path relative to the
> >>>>>>>
> >>>>>> project
> >>>>>
> >>>>>> root looks impossible to get, unless we look for magic names like
> >>>>>>>
> >>>>>> "src".
> >>>>>
> >>>>>> Any opinion as to which to use? I'm tempted to use just the file
> name,
> >>>>>>> since the full path to the file seems intrusive, and is dependent
> on
> >>>>>>>
> >>>>>> the
> >>>>>
> >>>>>> build machine.
> >>>>>>>
> >>>>>>> On Wed, Dec 20, 2017 at 11:35 AM, Matt Sicker <boa...@gmail.com>
> >>>>>>>
> >>>>>> wrote:
> >>>>>
> >>>>>>
> >>>>>>> It's possible that macros and mocks don't work well together,
> though
> >>>>>>>>
> >>>>>>> that's
> >>>>>>>
> >>>>>>>> just a guess.
> >>>>>>>>
> >>>>>>>> On 20 December 2017 at 00:00, Jeff Shaw <shawj...@gmail.com>
> wrote:
> >>>>>>>>
> >>>>>>>> I should add that manually testing it works.
> >>>>>>>>>
> >>>>>>>>> Sent from my phone
> >>>>>>>>>
> >>>>>>>>> On Dec 20, 2017, at 12:45 AM, Jeffrey Shaw <shawj...@gmail.com>
> >>>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>> I added some tests for traced, but they don't pass. The mocks
> >>>>>>>>>>
> >>>>>>>>> say,
> >>>>>
> >>>>>> "Actually, there were zero interactions with this mock." I could
> >>>>>>>>>
> >>>>>>>> use
> >>>>>
> >>>>>> some
> >>>>>>>
> >>>>>>>> help getting these two tests to work.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> https://github.com/shawjef3/logging-log4j-scala/blob/
> >>>>>>>>>>
> >>>>>>>>> message-location/log4j-api-scala_2.12/src/test/scala/org/
> >>>>>>>>> apache/logging/log4j/scala/LoggerTest.scala#L574
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Sun, Dec 17, 2017 at 8:50 PM, Jeffrey Shaw <
> >>>>>>>>>>>
> >>>>>>>>>> shawj...@gmail.com
> >>>>>
> >>>>>>
> >>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Thanks for the encouragement everyone! I never worked on an
> >>>>>>>>>>>
> >>>>>>>>>> Apache
> >>>>>
> >>>>>> project before and had no idea what to expect from the community.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> I've made some progress. One cool thing I added was a `traced`
> >>>>>>>>>>>
> >>>>>>>>>> method
> >>>>>>>
> >>>>>>>> (source), which does the work you'd want for traceEntry,
> traceExit,
> >>>>>>>>>
> >>>>>>>> and
> >>>>>>
> >>>>>>> throwing. It would be cool to add catching as well, but that would
> >>>>>>>>>
> >>>>>>>> require
> >>>>>>>>
> >>>>>>>>> tree traversal, which is beyond me at the moment. I also haven't
> >>>>>>>>>
> >>>>>>>> figured
> >>>>>>>
> >>>>>>>> out how to add the parameter lists. Anyway, an example:
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> before:
> >>>>>>>>>>> def f() = {...}
> >>>>>>>>>>>
> >>>>>>>>>>> after:
> >>>>>>>>>>> def f() = logger.traced(Level.INFO) {...}
> >>>>>>>>>>>
> >>>>>>>>>>> On Mon, Dec 11, 2017 at 9:55 PM, Matt Sicker <boa...@gmail.com
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>>>  From the little I've worked with macros (worked more with
> >>>>>>>>>>>>
> >>>>>>>>>>> scalameta
> >>>>>>
> >>>>>>> and
> >>>>>>>>
> >>>>>>>>> shapeless), that looks good so far. If you can add some unit
> >>>>>>>>>>>>
> >>>>>>>>>>> tests,
> >>>>>>
> >>>>>>> then
> >>>>>>>>>
> >>>>>>>>>> we'd be happy to merge!
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 11 December 2017 at 20:41, Jeffrey Shaw <
> shawj...@gmail.com
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>> Great news! I'm able to run LoggingApp in the scala api repo
> >>>>>>>>>>>>>
> >>>>>>>>>>>> without
> >>>>>>>>
> >>>>>>>>> it
> >>>>>>>>>
> >>>>>>>>>> calling StackLocatorUtil.calcLocation, but it prints the same
> >>>>>>>>>>>>>
> >>>>>>>>>>>> messages as
> >>>>>>>>>
> >>>>>>>>>> before. I have to use my patch to log4j of course.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> See https://github.com/shawjef3/logging-log4j-scala/commits/
> >>>>>>>>>>>>> message-location
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Sun, Dec 10, 2017 at 3:56 PM, Matt Sicker <
> >>>>>>>>>>>>>
> >>>>>>>>>>>> boa...@gmail.com
> >>>>>
> >>>>>>
> >>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>> This sounds like it'd make a great addition to the Scala
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> API!
> >>>>>
> >>>>>>
> >>>>>>>>>>>>>> On 9 December 2017 at 15:36, Jeffrey Shaw <
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> shawj...@gmail.com>
> >>>>>>
> >>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>>> Ralph, I agree with you entirely. My intent for these new
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> log
> >>>>>>
> >>>>>>> methods
> >>>>>>>>>
> >>>>>>>>>> is
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> that they only be called from compile-time generated
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> code.
> >>>>>
> >>>>>>
> >>>>>>>>>>>>>>> On Sat, Dec 9, 2017 at 4:30 PM, Ralph Goers <
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> ralph.go...@dslextreme.com>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I don’t understand how this is a good idea. To use this
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> you
> >>>>>>
> >>>>>>> would
> >>>>>>>>>
> >>>>>>>>>> need
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> do something like:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Message msg = new StringMessage(getCaller(), “My
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Message”);
> >>>>>>
> >>>>>>> logger.debug(msg);
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Unfortunately the line number would point to the line
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> where
> >>>>>>
> >>>>>>> getCaller()
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> called not to the logger statement.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I had thought about modifying AbstractLogger to do
> >>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> message)
> >>>>>>>
> >>>>>>>> {
> >>>>>>>>
> >>>>>>>>>     logIfEnabled(getCaller(), Level.DEBUG, marker,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> message,
> >>>>>>
> >>>>>>> (Throwable)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> null);
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>> instead of the current
> >>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> message)
> >>>>>>>
> >>>>>>>> {
> >>>>>>>>
> >>>>>>>>>     logIfEnabled(FQCN, Level.DEBUG, marker, message,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> (Throwable)
> >>>>>>>>>
> >>>>>>>>>> null);
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>> But the amount of changes required to get it into the
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> LogEvent
> >>>>>>>>
> >>>>>>>>> was
> >>>>>>>>>
> >>>>>>>>>> large.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> OTOH, if we create a CallerLocationMessage that
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> contains
> >>>>>
> >>>>>> the
> >>>>>>>
> >>>>>>>> StackTraceElement and then have existing Messages
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> extend
> >>>>>
> >>>>>> that
> >>>>>>>
> >>>>>>>> then we
> >>>>>>>>>
> >>>>>>>>>> could
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> store the location in the Message if it is a
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> CallerLocationMessage.
> >>>>>>>>>
> >>>>>>>>>> Calling
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> getCaller() in this way would be much better since it
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> is
> >>>>>
> >>>>>> at a
> >>>>>>>
> >>>>>>>> fixed
> >>>>>>>>>
> >>>>>>>>>> depth
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> from the caller.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> With Java 9 this could become:
> >>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> message)
> >>>>>>>
> >>>>>>>> {
> >>>>>>>>
> >>>>>>>>>     logIfEnabled(stackWalker.walk(
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> s->s.skip(1).findFirst(),
> >>>>>>>
> >>>>>>>> Level.DEBUG,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> marker, message, (Throwable) null);
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>> although that would pass a StackFrame instead of a
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> StackTraceElement.
> >>>>>>>>>
> >>>>>>>>>> The
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> only problems with this is that there is still some
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> overhead
> >>>>>>>
> >>>>>>>> in
> >>>>>>>>
> >>>>>>>>> calling
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> StackWalker like this. Also, if this is called from a
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> facade,
> >>>>>>>
> >>>>>>>> such as
> >>>>>>>>>
> >>>>>>>>>> log4j-slf4j-impl then the number of levels that have to
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> be
> >>>>>>
> >>>>>>> skipped
> >>>>>>>>>
> >>>>>>>>>> would
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> different.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I would really prefer if there was some way to capture
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> the
> >>>>>>
> >>>>>>> line
> >>>>>>>>
> >>>>>>>>> number
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> information for the various loggers when the annotation
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> processor
> >>>>>>>>>
> >>>>>>>>>> runs
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> at
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> compile time.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Ralph
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Dec 9, 2017, at 1:22 PM, Jeffrey Shaw <
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> shawj...@gmail.com
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Thanks for the link, Mikael. I'll take a look at it.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I added some plumbing to core to allow clients to
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> pass
> >>>>>
> >>>>>> a
> >>>>>>
> >>>>>>> StackTraceElement
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> to loggers. I'd like a code review. I'm happy to try
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> other
> >>>>>>>
> >>>>>>>> methods.
> >>>>>>>>>
> >>>>>>>>>> See
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> following commit.
> >>>>>>>>>>>>>>>>> https://github.com/shawjef3/logging-log4j2/commit/
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 9c42073e9ca4f25a2f4075b1791eee2893534c54
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Sat, Dec 9, 2017 at 10:09 AM, Mikael Ståldal <
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> mi...@apache.org>
> >>>>>>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Have you tried the Log4j Scala API?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> http://logging.apache.org/
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> log4j/2.x/manual/scala-api.
> >>>>>
> >>>>>> html
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>>>>>>>>>> It does currently not support this, but it uses
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Scala
> >>>>>
> >>>>>> macros, and
> >>>>>>>>>
> >>>>>>>>>> this
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> could be added there. But log4j-api and/or
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> log4j-core
> >>>>>
> >>>>>> probably
> >>>>>>>>>
> >>>>>>>>>> needs
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> adapted as well.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 2017-12-09 07:30, Jeffrey Shaw wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Hello,
> >>>>>>>>>>>>>>>>>>> I've found that I am able to use Scala macros to
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> provide
> >>>>>>>
> >>>>>>>> compile-time
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> source information for log messages. However, I
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> don't
> >>>>>
> >>>>>> see
> >>>>>>>
> >>>>>>>> a way
> >>>>>>>>>
> >>>>>>>>>> to
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> inject
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> this into log4j's logging mechanism.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I'm wondering if there is something I'm missing, or
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> if
> >>>>>>
> >>>>>>> LogEvent's
> >>>>>>>>>
> >>>>>>>>>> getSource
> >>>>>>>>>>>>>>>>>>> method could be duplicated in Message.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> We could then have zero-overhead location
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> information
> >>>>>
> >>>>>> in
> >>>>>>>
> >>>>>>>> logs.
> >>>>>>>>>
> >>>>>>>>>> I'm
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> thinking
> >>>>>>>>>>>>>>>>>>> that tools other than Scala could also take
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> advantage
> >>>>>
> >>>>>> of
> >>>>>>>
> >>>>>>>> this.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> --
> >>>>>>>>>>>>>> Matt Sicker <boa...@gmail.com>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> Matt Sicker <boa...@gmail.com>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Matt Sicker <boa...@gmail.com>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Matt Sicker <boa...@gmail.com>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >>
> >
>

Reply via email to