Yes the Listener and Monitor concepts are really close. I always wondered what the distinctions were. I thought there's more flexability in the nature of delivery (sync vs. async potential) in the Listener based pattern.
Alex On Fri, Jul 11, 2008 at 10:16 AM, Les Hazlewood <[EMAIL PROTECTED]> wrote: > 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 ... > > > -- Microsoft gives you Windows, Linux gives you the whole house ...
