Gary,
That is excellent news that you will be contributing the multicast receiver
source code. Sounds like an efficient solution for listening on many servers
with many clients.
I have now added the 1.1 release of Chainsaw to get the ball rolling (so to
speak). The intention is to make changes to Chainsaw to make it a much more
flexible package. My personal preference is to do the simplest thing that can
possible work, rather than over engineering. I would also rather follow the
techniques used by Log4J core for consistency. (just explaining my intended
approach:-).
The rest of this email is a brain-dump of ideas that will set the path for
changing Chainsaw. I hope to encourage discussion on way to change Chainsaw.
In the future Chainsaw will need to support plugging in two types of
components:
- Receivers: these components receive LoggingEvents in the background, and
update the model. The current example is the LoggingReciever that comes with
Chainsaw. Another example would be the multicast receiver you are
developing.
- Loaders: these components are invoked to load LoggingEvents. The current
example is the LoadXMLAction that loads LoggingEvents from a file. In the
future I hope to add a loader to load events from a database.
Each type of component will have different set of requirements. A set of
interfaces will be defined for each type of component. For example, a receiver
component needs an interface(s) to notify it when:
- To start up
- To shutdown
- Change configuration
- Edit configuration - I feel that each component should provide a Swing UI
for editing their configuration. This UI can be activated through menus. I
do not believe that the existing ControlPanel should be modified.
A loader needs an inteface(s) to notify it when:
- To load events
- Edit configuration
A common theme between the receiver and loader components is
configuration. Chainsaw will need a technique loading, modifying and saving
configuration data. Off the top of my head, I would suggest using
java.util.Properties as the basis.
Chainsaw will need a mechanism to be configured with components that are
available. My recommendation would be to use a properties file to keep things
simple. A properties file may look like:
chainsaw.receiver.direct=org.log4j.chainsaw.LoggingReceiver
chainsaw.receiver.multi=org.log4j.chainsaw.MulticastLoggingReceiver
chainsaw.loader.xml=.......
When Chainsaw starts it could create instances of the components. I would
suggest that Chainsaw would have two menus that are dynamically populated. One
for receivers and, you guessed it, one for loaders.
Thoughts, comments, suggestions.
Regards,
Oliver
> -----Original Message-----
> From: Gary Udstrand [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, 27 March 2002 07:30
> To: Log4J Developers List
> Cc: Mark Womack
> Subject: Re: Some thoughts on Chainsaw
>
>
>
> Sorry for the delay in responding.
>
> Yes, I would like to contribute the new appender and the modifications
> to Chainsaw to log4j. I am still working through some of the enhancements
> to Chainsaw (on the gui) to make it easier to select and change ports and
> multicast addresses. Let me know what I need to do to submit the source and
> I will get it done.
>
> I like the idea of creating an interface for the loggingReceivers. The
> UDP receiver does require 2 parms (port and multicast address) and the
> original receiver does not. With this in mind it may take a little more
> architecture type work make an interface work. Simply moving the
> setupReceiver code into each receiver class and making it a part of the
> interface would do.
>
> Besides adding my own UDPReciever I am working on adding the ability to
> change the socket parms on the fly. Currently you can configure these
> options in a properties file but I would like the option to change them
> without a restart. To support this I have made my own version of the
> ControlPanel adding a couple of columns to allow for the port and multicast
> address combo boxes.
>
> The pluggable modules seems like the right direction to work towards.
> I would like to get my changes submitted and added as part of the
> distribution. Let me know what the next steps are. I would assume that we
> need to come to a more formal decision on the interfaces and the
> architecture changes to support the proposed changes.
>
> Thanks
> -Gary
>
>
> ----- Original Message -----
> From: "Mark Womack" <[EMAIL PROTECTED]>
> To: "'Log4J Developers List'" <[EMAIL PROTECTED]>
> Sent: Friday, March 22, 2002 1:14 PM
> Subject: RE: Some thoughts on Chainsaw
>
>
> > Gary,
> >
> > You have mentioned this appender earlier. If you want to, it would be
> > interesting to look at and maybe contribute to log4j? It sounds like a
> very
> > useful and interesting implementation.
> >
> > So, do you think the thoughts on Chainsaw would fit into how you
> implemented
> > your changes? If there were an architecture in place (ie LoggingReceiver
> > interface/base class), you could create classes to plug in your
> UDPMulitcast
> > stuff. What kind of changes did you need to make in Chainsaw to support
> > your code?
> >
> > One item I did not go into detail about is that these pluggable modules
> will
> > probably need some supporting gui. For example, to support receiving
> > messages from my SocketServerAppender in Chainsaw I had to add a dialog to
> > allow the user to enter the host and port to connect to. I imagine that
> > other appender types will need to have their own specific gui (JMS topic,
> > port/multicast address, etc).
> >
> > It seems to me there are 2 requirements for this:
> >
> > 1) The viewer tool needs to be configurable to define the set of logging
> > receivers it will bring into its gui. Or, it could implement some kind of
> > discovery mechanism that searches the classpath for classes that implement
> a
> > known interface. Either way it gets a list of logging receivers to
> > integrate into its gui.
> >
> > 2) When the user chooses the appropriate gui widget (a menu item?), the
> > viewer tool calls a predetermined method on the reciever class to display
> > the receiver's gui.
> >
> > just some more thoughts,
> > -Mark
> >
> > -----Original Message-----
> > From: Gary Udstrand [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, March 21, 2002 1:07 PM
> > To: Log4J Developers List
> > Subject: Re: Some thoughts on Chainsaw
> >
> >
> >
> > I have written a UDPMulticastAppender and integrated it into chainsaw
> > for just this purpose. We have our dev/qa/vend/prod servers all
> > broadcasting to separate multicast addresses. We are using nested
> > diagnostic contexts to tie the transactions back to a specific server
> (this
> > is in a multi-node WLS 6.1 environment).
> >
> > I have also modified Chainsaw to listen for UDP traffic. The port and
> > multicast address can be configured from the client allowing us to
> > selectively monitor different environments. The advantage to this
> > arrangement is that not only can multiple clients monitor the log traffic,
> > multiple clients can monitor traffic from multiple servers. Since it is
> > multicast it is also much less demanding on the network infrastructure,
> > which is important since bandwidth is always limited.
> >
> > -Gary
> >
> >
> > ----- Original Message -----
> > From: "Mark Womack" <[EMAIL PROTECTED]>
> > To: "Log4j-Dev (E-mail)" <[EMAIL PROTECTED]>
> > Sent: Thursday, March 21, 2002 12:18 PM
> > Subject: Some thoughts on Chainsaw
> > >
> > > 3) The viewer tool should support receiving logging events from multiple
> > > sources. Currently, Chainsaw only supports setting up one
> > LoggingReceiver,
> > > but (I believe) this is just a configuration limitation, not an actual
> > > limitation. If there were a way to specify it from the gui, it could
> > easily
> > > support multiple sources. The messages would be interleaved in the
> table
> > > listing of the events, so displaying the event source would be needed.
> > > Supporting this will allow the debugging of applications that span
> > multiple
> > > machines/processes, which are quite common in the world of web
> > applications
> > > nowadays. Parallel to this is the ability to add/delete sources
> > > dynamically, probably via some gui.
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
