> From: Gonzalo A. Diethelm [mailto:[EMAIL PROTECTED]] > > A couple more questions: > > * Does LogKit by itself (i.e. not as Excalibur Logger) allow > for plugging log4j or JDK 1.4 logging as "back-end"?
I think you mean Framework logger. The Excalibur package has to do with configuring the Logger. LogKit has a pluggable output system. You could write an output that forwards the events to Log4J or JDK 1.4--but why would you want to when you are using a fully functional logging package already. Commons logging package and Framework's logging abstraction are designed for the basic issue of letting you choose which logging package you want later on. I would suggest using either of those if what you want is a common API. > > * What is the appropriate BASIC component (analog to LogKit) > in Avalon to handle configuration information? We have two choices. Framework has a configuration package and a parameters package. Each represent a different type of information. The parameters package is used for very simple flat configuration information. It is similar to the Properties class in the JDK, except it provides typesafe accessor methods (i.e. getParameterAsLong) and can extract Parameters from the configuration object. The configuration package has a Configuration object that represents a hierarchical configuration. Included are utilities to create the Configuration object from XML files, and to serialize them back to XML. > > * Are there any BASIC components/abstractions in Avalon to deal > with security? By that I mean authentication and authorization > (as in role-based permission management). > Not at this time. The Avalon team chose to follow Sun's lead on authentication and authorization, or to defer those concerns to the container. There are projects that use JAAS, the Servlet's authorization/ role management, or a proprietary authorization service. The problem is that many applications have different needs. Some servers do not need to worry about authenticating users (like HTTP proxy servers), and others work fine with the standard mechanisms. The bottom line is none of us have gotten around to creating such an abstraction. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
