----- Original Message -----
From: "giacomo" <[EMAIL PROTECTED]>
To: "Avalon Development" <[EMAIL PROTECTED]>
Sent: Sunday, August 26, 2001 9:07 AM
Subject: Re: LogKitManagement


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

OK, I will do that! ... I attached what I did with FileTargetFactory, the
only thing I care is the protected methods that would allow to extend easily
the factory with new formatters and file strategies.

Mircea

>
> Thanks,
>
> Giacomo
>
> >
> > ----- Original Message -----
> > From: "giacomo" <[EMAIL PROTECTED]>
> > To: "Avalon Development" <[EMAIL PROTECTED]>
> > Sent: Saturday, August 25, 2001 3:18 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 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>
> >
> > 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: [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]
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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]
>

FileTargetFactory.java

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

Reply via email to