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? >
