You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tika.apache.org by Josh Burchard <bu...@pnp-hcl.com> on 2022/04/04 18:06:44 UTC

spawned child log4j2 frustrations

I'm trying to pass through a JVM system variable from the command line to the
log4j2 instance being used by any Tika child process.  This variable
substitution works fine, of course, for the parent process where my log4j2.xml
line is like so:



<RollingFile name="RollingAppender" fileName="${sys:logpath}"
filePattern="${sys:logpath}.%i" append="false">



And that's fed by my command line:



java -Dlogpath="C:\tmp\logstore\foo.log" -jar tika-server.jar -c
C:\tmp\configs\tika-config.xml





So in my tika-config.xml I tried the following thing for the child processes
which doesn't work:

      <forkedJvmArgs>  
        <arg>-Xms1g</arg>  
        <arg>-Xmx1g</arg>  
        <arg>-Dlogpath="${sys:logpath}"</arg>  
        <arg>-Dlog4j.configurationFile="C:\tmp\configs\log4jTika.xml"</arg>  
       </forkedJvmArgs>





I do see that if I set the above logpath arg to a literal value, that works
but it's not what I'm going for.



Can anyone think of a workaround for this?





-Josh Burchard : HCL


Re: spawned child log4j2 frustrations

Posted by Tim Allison <ta...@apache.org>.
https://issues.apache.org/jira/browse/TIKA-3715

On Mon, Apr 4, 2022 at 5:14 PM Josh Burchard <bu...@pnp-hcl.com> wrote:
>
> Looks like you got the gist of what I was going for. Yes, it's the smelly part that I'm trying to replicate where the variables get transferred down to the forked process(es). In our case our customers can configure where they want their support/log files stored so I can't bank on there always being a pre-known, static path.  It would be excellent if we could pass those values through!
>
>
> ----- Original message -----
> From: "Tim Allison" <ta...@apache.org>
> To: user@tika.apache.org
> Cc:
> Subject: Re: spawned child log4j2 frustrations
> Date: Mon, Apr 4, 2022 5:02 PM
>
> In short, would there be any dangerous side effects if we copied all
> environment variables from the forking process into the forked
> processes?  Or is there a cleaner way to let users specify which to
> pass on.
>
> On Mon, Apr 4, 2022 at 4:44 PM Tim Allison <ta...@apache.org> wrote:
> >
> > I'm sorry.  I can't quite figure out what you're trying to do.
> >
> > I wanted separate logs for each pipesclient.  I did this:
> >
> >   <Appenders>
> >     <File name="file-appender" fileName="logs/client-${sys:pipesClientId}.log">
> >       <PatternLayout pattern="%-5p [%t] %d{HH:mm:ss,SSS} %c %m%n"/>
> >     </File>
> >     <File name="pdfbox-appender"
> > fileName="logs/pdfbox-${sys:pipesClientId}.log">
> >       <PatternLayout pattern="%-5p [%t] %d{HH:mm:ss,SSS} %c %m%n"/>
> >     </File>
> >   </Appenders>
> >
> > The diff is that I did a smelly, hard-coding of injecting that
> > variable into the forked process:
> > https://github.com/apache/tika/blob/3eaf766b323b2a3d804268ae0e2bba6bd8e08117/tika-server/tika-server-core/src/main/java/org/apache/tika/server/core/TikaServerWatchDog.java#L403
> >
> > Should we do a better job of inheriting or transferring the system
> > variables from the forking to the forked process, e.g. copy everything
> > starting with -D?
> >
> > On Mon, Apr 4, 2022 at 2:07 PM Josh Burchard <bu...@pnp-hcl.com> wrote:
> > >
> > > I'm trying to pass through a JVM system variable from the command line to the log4j2 instance being used by any Tika child process.  This variable substitution works fine, of course, for the parent process where my log4j2.xml line is like so:
> > >
> > > <RollingFile name="RollingAppender" fileName="${sys:logpath}" filePattern="${sys:logpath}.%i" append="false">
> > >
> > > And that's fed by my command line:
> > >
> > > java -Dlogpath="C:\tmp\logstore\foo.log" -jar tika-server.jar -c C:\tmp\configs\tika-config.xml
> > >
> > >
> > > So in my tika-config.xml I tried the following thing for the child processes which doesn't work:
> > >       <forkedJvmArgs>
> > >         <arg>-Xms1g</arg>
> > >         <arg>-Xmx1g</arg>
> > >         <arg>-Dlogpath="${sys:logpath}"</arg>
> > >         <arg>-Dlog4j.configurationFile="C:\tmp\configs\log4jTika.xml"</arg>
> > >        </forkedJvmArgs>
> > >
> > >
> > > I do see that if I set the above logpath arg to a literal value, that works but it's not what I'm going for.
> > >
> > > Can anyone think of a workaround for this?
> > >
> > >
> > > -Josh Burchard : HCL
>
>

Re: spawned child log4j2 frustrations

Posted by Josh Burchard <bu...@pnp-hcl.com>.
Looks like you got the gist of what I was going for. Yes, it's the smelly part
that I'm trying to replicate where the variables get transferred down to the
forked process(es). In our case our customers can configure where they want
their support/log files stored so I can't bank on there always being a pre-
known, static path.  It would be excellent if we could pass those values
through!



> \----- Original message -----  
>  From: "Tim Allison" <ta...@apache.org>  
>  To: user@tika.apache.org  
>  Cc:  
>  Subject: Re: spawned child log4j2 frustrations  
>  Date: Mon, Apr 4, 2022 5:02 PM  
>  
>
> In short, would there be any dangerous side effects if we copied all  
>  environment variables from the forking process into the forked  
>  processes?  Or is there a cleaner way to let users specify which to  
>  pass on.  
>  
>  On Mon, Apr 4, 2022 at 4:44 PM Tim Allison <ta...@apache.org> wrote:  
>  >  
>  > I'm sorry.  I can't quite figure out what you're trying to do.  
>  >  
>  > I wanted separate logs for each pipesclient.  I did this:  
>  >  
>  >   <Appenders>  
>  >     <File name="file-appender"
> fileName="logs/client-${sys:pipesClientId}.log">  
>  >       <PatternLayout pattern="%-5p [%t] %d{HH:mm:ss,SSS} %c %m%n"/>  
>  >     </File>  
>  >     <File name="pdfbox-appender"  
>  > fileName="logs/pdfbox-${sys:pipesClientId}.log">  
>  >       <PatternLayout pattern="%-5p [%t] %d{HH:mm:ss,SSS} %c %m%n"/>  
>  >     </File>  
>  >   </Appenders>  
>  >  
>  > The diff is that I did a smelly, hard-coding of injecting that  
>  > variable into the forked process:  
>  >
> <https://github.com/apache/tika/blob/3eaf766b323b2a3d804268ae0e2bba6bd8e08117/tika-
> server/tika-server-
> core/src/main/java/org/apache/tika/server/core/TikaServerWatchDog.java#L403>  
>  >  
>  > Should we do a better job of inheriting or transferring the system  
>  > variables from the forking to the forked process, e.g. copy everything  
>  > starting with -D?  
>  >  
>  > On Mon, Apr 4, 2022 at 2:07 PM Josh Burchard <bu...@pnp-hcl.com>
> wrote:  
>  > >  
>  > > I'm trying to pass through a JVM system variable from the command line
> to the log4j2 instance being used by any Tika child process.  This variable
> substitution works fine, of course, for the parent process where my
> log4j2.xml line is like so:  
>  > >  
>  > > <RollingFile name="RollingAppender" fileName="${sys:logpath}"
> filePattern="${sys:logpath}.%i" append="false">  
>  > >  
>  > > And that's fed by my command line:  
>  > >  
>  > > java -Dlogpath="C:\tmp\logstore\foo.log" -jar tika-server.jar -c
> C:\tmp\configs\tika-config.xml  
>  > >  
>  > >  
>  > > So in my tika-config.xml I tried the following thing for the child
> processes which doesn't work:  
>  > >       <forkedJvmArgs>  
>  > >         <arg>-Xms1g</arg>  
>  > >         <arg>-Xmx1g</arg>  
>  > >         <arg>-Dlogpath="${sys:logpath}"</arg>  
>  > >
> <arg>-Dlog4j.configurationFile="C:\tmp\configs\log4jTika.xml"</arg>  
>  > >        </forkedJvmArgs>  
>  > >  
>  > >  
>  > > I do see that if I set the above logpath arg to a literal value, that
> works but it's not what I'm going for.  
>  > >  
>  > > Can anyone think of a workaround for this?  
>  > >  
>  > >  
>  > > -Josh Burchard : HCL




Re: spawned child log4j2 frustrations

Posted by Tim Allison <ta...@apache.org>.
In short, would there be any dangerous side effects if we copied all
environment variables from the forking process into the forked
processes?  Or is there a cleaner way to let users specify which to
pass on.

On Mon, Apr 4, 2022 at 4:44 PM Tim Allison <ta...@apache.org> wrote:
>
> I'm sorry.  I can't quite figure out what you're trying to do.
>
> I wanted separate logs for each pipesclient.  I did this:
>
>   <Appenders>
>     <File name="file-appender" fileName="logs/client-${sys:pipesClientId}.log">
>       <PatternLayout pattern="%-5p [%t] %d{HH:mm:ss,SSS} %c %m%n"/>
>     </File>
>     <File name="pdfbox-appender"
> fileName="logs/pdfbox-${sys:pipesClientId}.log">
>       <PatternLayout pattern="%-5p [%t] %d{HH:mm:ss,SSS} %c %m%n"/>
>     </File>
>   </Appenders>
>
> The diff is that I did a smelly, hard-coding of injecting that
> variable into the forked process:
> https://github.com/apache/tika/blob/3eaf766b323b2a3d804268ae0e2bba6bd8e08117/tika-server/tika-server-core/src/main/java/org/apache/tika/server/core/TikaServerWatchDog.java#L403
>
> Should we do a better job of inheriting or transferring the system
> variables from the forking to the forked process, e.g. copy everything
> starting with -D?
>
> On Mon, Apr 4, 2022 at 2:07 PM Josh Burchard <bu...@pnp-hcl.com> wrote:
> >
> > I'm trying to pass through a JVM system variable from the command line to the log4j2 instance being used by any Tika child process.  This variable substitution works fine, of course, for the parent process where my log4j2.xml line is like so:
> >
> > <RollingFile name="RollingAppender" fileName="${sys:logpath}" filePattern="${sys:logpath}.%i" append="false">
> >
> > And that's fed by my command line:
> >
> > java -Dlogpath="C:\tmp\logstore\foo.log" -jar tika-server.jar -c C:\tmp\configs\tika-config.xml
> >
> >
> > So in my tika-config.xml I tried the following thing for the child processes which doesn't work:
> >       <forkedJvmArgs>
> >         <arg>-Xms1g</arg>
> >         <arg>-Xmx1g</arg>
> >         <arg>-Dlogpath="${sys:logpath}"</arg>
> >         <arg>-Dlog4j.configurationFile="C:\tmp\configs\log4jTika.xml"</arg>
> >        </forkedJvmArgs>
> >
> >
> > I do see that if I set the above logpath arg to a literal value, that works but it's not what I'm going for.
> >
> > Can anyone think of a workaround for this?
> >
> >
> > -Josh Burchard : HCL

Re: spawned child log4j2 frustrations

Posted by Tim Allison <ta...@apache.org>.
I'm sorry.  I can't quite figure out what you're trying to do.

I wanted separate logs for each pipesclient.  I did this:

  <Appenders>
    <File name="file-appender" fileName="logs/client-${sys:pipesClientId}.log">
      <PatternLayout pattern="%-5p [%t] %d{HH:mm:ss,SSS} %c %m%n"/>
    </File>
    <File name="pdfbox-appender"
fileName="logs/pdfbox-${sys:pipesClientId}.log">
      <PatternLayout pattern="%-5p [%t] %d{HH:mm:ss,SSS} %c %m%n"/>
    </File>
  </Appenders>

The diff is that I did a smelly, hard-coding of injecting that
variable into the forked process:
https://github.com/apache/tika/blob/3eaf766b323b2a3d804268ae0e2bba6bd8e08117/tika-server/tika-server-core/src/main/java/org/apache/tika/server/core/TikaServerWatchDog.java#L403

Should we do a better job of inheriting or transferring the system
variables from the forking to the forked process, e.g. copy everything
starting with -D?

On Mon, Apr 4, 2022 at 2:07 PM Josh Burchard <bu...@pnp-hcl.com> wrote:
>
> I'm trying to pass through a JVM system variable from the command line to the log4j2 instance being used by any Tika child process.  This variable substitution works fine, of course, for the parent process where my log4j2.xml line is like so:
>
> <RollingFile name="RollingAppender" fileName="${sys:logpath}" filePattern="${sys:logpath}.%i" append="false">
>
> And that's fed by my command line:
>
> java -Dlogpath="C:\tmp\logstore\foo.log" -jar tika-server.jar -c C:\tmp\configs\tika-config.xml
>
>
> So in my tika-config.xml I tried the following thing for the child processes which doesn't work:
>       <forkedJvmArgs>
>         <arg>-Xms1g</arg>
>         <arg>-Xmx1g</arg>
>         <arg>-Dlogpath="${sys:logpath}"</arg>
>         <arg>-Dlog4j.configurationFile="C:\tmp\configs\log4jTika.xml"</arg>
>        </forkedJvmArgs>
>
>
> I do see that if I set the above logpath arg to a literal value, that works but it's not what I'm going for.
>
> Can anyone think of a workaround for this?
>
>
> -Josh Burchard : HCL