avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: LogKitManagement
Date Sun, 26 Aug 2001 15:07:45 GMT
On Sat, 25 Aug 2001, Mircea Toma wrote:

Mircea, hold on on the FileTargetFactory as I'm almost done with it as
I'm already integrating the LogKitManagement into the Cocoon 2.1 branch.

It would be cool if you can concentrate on the other Factories.

Thanks,

Giacomo

>
> ----- Original Message -----
> From: "giacomo" <giacomo@apache.org>
> To: "Avalon Development" <avalon-dev@jakarta.apache.org>
> Sent: Saturday, August 25, 2001 3:18 PM
> Subject: Re: LogKitManagement
>
>
> > On Sat, 25 Aug 2001, Mircea Toma wrote:
> >
> > >
> > > ----- Original Message -----
> > > From: "giacomo" <giacomo@apache.org>
> > > To: "Avalon Development" <avalon-dev@jakarta.apache.org>
> > > Sent: Saturday, August 25, 2001 1:32 PM
> > > Subject: Re: LogKitManagement
> > >
> > >
> > > > On Sat, 25 Aug 2001, Mircea Toma wrote:
> > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "giacomo" <giacomo@apache.org>
> > > > > To: "Avalon Development" <avalon-dev@jakarta.apache.org>
> > > > > 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>
>
> It is simpler, I tend to overuse attributes!
>
> >
> > 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?
>
> We can do something like:
>
> <rotation type="revolving" init="5" max="10">
>   <and>
>     <or>
>       <size>10m</size>
>       <time>24:00:00</time>
>     </or>
>     <other>xxx</other>
>   </and>
> </rotation>
>
> ... the OR/ANDRotateStrategy should be represented by an element too, this
> will allow XMLSchema validation and the construction of more complex
> rotation rules!
>
>
> Mircea
>
> >
> > 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: avalon-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> > >
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Mime
View raw message