I personally don't like the idea of bundling any 3rd party library within our own jar. I don't see this as a best practice. It feels somewhat 'hacky' to me. I would much rather force them to explicitly deploy jsecurity.jar + slf4j-api.jar + binding jar than do that.
But that's beside the point. Do you really feel that the following isn't desirable: 1. jsecurity.jar - nothing else. It just works. 2. jsecurity.jar + slf4j-api.jar + binding implementation. That works perfectly too. What is not to love about that? On Tue, Jul 15, 2008 at 3:20 PM, Tim Veil <[EMAIL PROTECTED]> wrote: > seems reasonable to me... > > +1 > > On Tue, Jul 15, 2008 at 3:11 PM, Jeremy Haile <[EMAIL PROTECTED]> wrote: > >> For example, if they included jsecurity.jar (with our internal slf4j >>>>>> binding implementation) + some-other-framework.jar + slf4j-api.jar + >>>>>> slf4j-log4j14.jar + log4j.jar, and our Binding was picked up first by >>>>>> the classloader, then log4j would be disabled for the application - >>>>>> not desirable. >>>>>> >>>>> >>>>> If they wanted to use slf4j then they would not include the jsecurity >>>>> jar but, instead, use the jsecurity-core jar. This has been mentioned >>>>> many >>>>> times before on this and other threads. >>>>> >>>> >>>> I'm +1 for this proposal as well. >>>> >>>> However, I don't like calling the bundled jar jsecurity.jar. We >>>> currently have an uber jar called jsecurity.jar that contains all of our >>>> spring, web, etc. code. How about we call the jsecurity+logging framework >>>> jar "jsecurity-nodeps.jar"? This immediately lets users who need to use >>>> JSecurity in an environment without dependencies know which jar is >>>> appropriate. >>>> >>> >>> While "nodeps" does describe that it has no deps, I'm not sure that it's >>> clear that it also has am SLF4J implementation bundled inside as well. What >>> about jsecurity-selfcontained.jar? Just a thought. >>> >> >> Just throwing out other ideas. How about jsecurity-withlogging.jar? >> >
