Yep, I investigated this quite a bit before bringing up my suggestions. The problem with the Monitor pattern is one of granularity - you wouldn't want type-safe methods for many of our random trace and debug messages.
The Monitor pattern is good for the scenarios of "X thing occurred, and end-users very well may be interested in this". Loggers do this, but also act as a coding 'gut check' mechanism - "ok, the code has gotten this far. Trying the next thing...". If a Monitor was used in this manner, you'd quickly see the number of methods explode, and maintaining the Monitor interface, which would in turn force ad hoc changes on end users, makes that approach a dead end. So, a Log _and_ a Monitor is the appropriate solution due to granularity of information. Currently JSecurity supports both, but we use EventListeners instead of a Monitor interface directly. Actually our *EventManager interfaces _are_ monitors (AuthenticationEventManager, SessionEventManager, etc), that just so happen to trigger an event. Users can implement their own or just listen for events. Very flexible. In fact, I think I very well may refactor the name of *EventManager to *Monitor. That would be more in line with better recognized terminology. They would still trigger events, but would be easier to understand for people that would want to implement their own instead of listening for events. On Fri, Jul 11, 2008 at 3:10 AM, Alex Karasulu <[EMAIL PROTECTED]> wrote: > Note that this Monitor concept makes it so the logging framework used is > easy to swap out. Essentially instead of logging you make calls to the > Monitor interface. You can have any monitor installed for the component > swapping out which logging framework it uses if the monitor logs. > > I fell in love with this in the past. I quickly realized that it was more > trouble than it was worth. Maintaining the interface got to be a hassle > after a while. Then there were other issues I could go into but won't for > now unless others ask. Life was just easier sticking to a simple framework > like SLF4J which can be used to swap the logging implementation on. > > Alex > > On Fri, Jul 11, 2008 at 2:54 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> > wrote: > >> Les Hazlewood wrote: >> >>> Reason 1: What happens when the latest-n-greatest new logging >>> framework comes out in 2 years from now? Will we refactor again? >>> >> This is a possibility :) We don't live in a frozen world ... >> >>> I >>> suppose we could, but, why not just eliminate that possibility? >>> >> Well, it's not likely that our own logging system will also remain >> unchanged for years. >> >>> Or >>> what if there is some flaw in SLF4J that makes it undesirable, much as >>> happened to Commons Logging (I've seen the CL problems myself - they >>> are real, even if they are rare). >>> >> Then we switch to the 'next best framework'. So far, and it's now 2 >> years slf4j exists, it's pretty stable. And Slf4j has been designed to >> avoid the problems CL had. >> >>> Our own lightweight wrapper API >>> makes JSecurity more resilient. >>> >>> >> You will face users questions like : "why do I have to configure the logger >> in some way which is incompatible with the logger I already use?" ad >> nauseam. >> >>> Reason 3: I know you said something like "why would they even want to >>> do that [implement their own logging framework]"? The sad reality is >>> that there are many companies that have their own logging frameworks >>> that are used across the organization that are NOT built upon standard >>> OS frameworks like SLF4J or Commons Logging - they are proprietary, >>> integrate with centralized monitoring servers, JMS, etc, etc. My >>> current client is one such company. The people who contacted me >>> yesterday are another company. Allan's current company is another >>> such company. They exist in greater numbers than I'd like to see, but >>> they're out there. >>> >>> >> Sure, but is this a reason because some companies (and as there are >> millions out there :) are >> not using an existing framework to define a brand new logger system which >> will not be able >> to cover all the cases anyway ? >> >> Reason 4: our own trivial wrapper API prevents us from a forced >>> runtime dependency on another library. This caters to: >>> >>> a) deployment simplicity - just drop jsecurity.jar into the classpath >>> and you're done. Add more jars if you want customized features. >>> b) lightweight environments. People can use JSecurity in any java >>> environment, from web apps to cell phones, without worrying about >>> requiring an extra 50k to few megs of dependencies. This better >>> enables JSecurity as being known as a truly ubiquitous security >>> framework. >>> c) controlled environments - that a security framework does not >>> require other frameworks is a piece of mind security-conscientious >>> users and software standards groups will appreciate >>> >> This is an interesting point which may deserve another thread. >> At some point, if JSecurity is to be a standalone lib, that mean many >> libs won't be used (commons-xxx, and such), and it may be a real burden, >> or at least a real cost. What libs are currently used in JSecurity ? >> >>> Reason 5: this is a feature desired by an actual end-user - not >>> something I'm just dreaming up or over-engineering. This means there >>> is desire from an end-user that is representative of other companies >>> out there that might use JSecurity as well. If we do this now, we >>> don't have to worry about similar requests later (as Emmanuel pointed >>> out happens from time to time) as JSecurity becomes more heavily >>> adopted outside of just web applications. >>> >>> >> It depends. The problem is that if you have 100 companies using >> JSecurity, 99 using Log4j and 1 using another system, you will hear >> from the one company having problem with JSecurity, and not about the >> 99 others. If you switch, this is very likely that you will start having >> some of the 99 companies complaining :) >> >> And may be it's just because this one company has not been told >> how to correctly integrate jsecurity within their application... >> >> >> -- >> -- >> cordialement, regards, >> Emmanuel Lécharny >> www.iktek.com >> directory.apache.org >> >> >> > > > -- > Microsoft gives you Windows, Linux gives you the whole house ... >
