On Sat, 25 Aug 2001, Mircea Toma wrote:

>
> ----- Original Message -----
> From: "giacomo" <[EMAIL PROTECTED]>
> To: "Avalon Development" <[EMAIL PROTECTED]>
> Sent: Saturday, August 25, 2001 1:32 PM
> Subject: Re: LogKitManagement
>
>
> > On Sat, 25 Aug 2001, Mircea Toma wrote:
> >
> > >
> > > ----- Original Message -----
> > > From: "giacomo" <[EMAIL PROTECTED]>
> > > To: "Avalon Development" <[EMAIL PROTECTED]>
> > > Sent: Saturday, August 25, 2001 9:54 AM
> > > Subject: LogKitManagement
> > >
> > >
> > > >
> > > > Dear all
> > > >
> > > > I've committed the updated Component Management System in Excalibur
> that
> > > > work together with the recently written LogKitManagement System.
> > > >
> > > > The fact that the ExcaluburComponentManager is in the java directory
> > > > where as the LogKitManagement classes were still in the scratchpad
> > > > directory I had to move the LogKitManagment classes into the java area
> > > > because the build procedure does not work together when you have to
> mix
> > > > those areas.
> > > >
> > > > I have tested them quite alot (jswat and some batches) and there is a
> > > > test based on ExcaliburTestCase to see it working I propose to move
> the
> > > > LogKitManagement classes into the java tree.
> > > >
> > > > I don't know the release schedule for Excalibur but I would like to
> see
> > > > the LogKitManagement making it into the next release which can be
> > > > integrated into Cocoon 2 before the the next release will go live.
> > > >
> > > > Right now I'll write the xdocs for the LogKitManagement which I'll
> > > > commit soon.
> > > >
> > > > So, the hard part has just started. Some more LogTargetFactories have
> to
> > > > be written to make the system more handy ;)
> > >
> > > I would like to do that! I can start with RotatingFileFactory,
> > > JMSTopicTargetFactory, JDBCTargetFactory .... because I need then
> anyway!
> >
> > I think it's best to have one Factory for a media target (I/O, JMS,
> > JDBC). So, the FileTargetFactory should be able to be configured to
> > create rotating or not targets, if rotating then by size or time or
> > both, etc.
> >
> > What do you think?
>
> I think you're right! I can make FileTargetFactory configuration something
> like (2 examples):
>
>  <targets>
>   <file id="root">
>    <filename>logs/main.log</filename>
>    <strategy>
>     <file type="revolving" init="5" max="10"/>
>     <rotate by="or">
>      <rotate by="size"/>
>      <rotate by="time"/>
>     </rotate>
>    </strategy>
>    <format type="exteded">%7.7{priority} %5.5{time}   [%8.8{category}]
> (%{context}): %{message}\n%{throwable}</format>
>    <append>true</append>
>   </file>

how about simply:

  <targets>
   <file id="root">
    <filename>logs/main.log</filename>
    <rotation type="revolving" init="5" max="10">
     <size>10m</size>
     <time>24:00:00</time>
    <rotation>
    <format type="exteded">%7.7{priority} ... </format>
    <append>true</append>
   </file>
   <file id="classloader">
    <filename>logs/classloader.log</filename>
    <rotation type="unique"/>
     <size>10m</size>
    </rotation>
    <format type="raw"/>
   </file>
  </targets>

I think this will give sufficent information to the factory to decide
which LogTarget to create and whitch RotateStrategy and FileStrategy to
choose (if any).

Since every rotation need a single FileStrategy we can give it as an
attribute to the rotation element. Inside we can have a size and/or
time element denoting which RotateStrategy to choose (sure if there is
<size> _and_ <time> we need to put them into an OrRotateStrategy).

What do you think?

Giacomo

>   <file id="classloader">
>    <filename>logs/classloader.log</filename>
>    <strategy>
>     <file type="unique"/>
>     <rotate by="size"/>
>    </strategy>
>    <format type="raw"/>
>   </file>
>  </targets>
>
>
> ... something like this?!
>
>
> Mircea
>
> >
> > Giacomo
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to