Grouper Users - Open Discussion List

[Chris Hyzer <>]

I think it means that commons-logging jar is not compatible with slf4j jar.  
Can you search and make sure there is only one of each of those jars in all 
the lib dirs?

Thanks,
Chris

-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Scott Koranda
Sent: Friday, October 01, 2010 5:08 PM
To: 

Subject: Re: [grouper-users] ldappc-ng jars, gsh, and memory

> Hi,
> 
> I have two Grouper 1.6.1 testbeds, one with 1 GB of RAM and
> one with 8 GB of RAM.
> 
> I was able to successfully build, deploy, and run ldappc-ng on
> the testbed with 8 GB of RAM.
> 
> On the testbed with 1 GB of RAM, when I try to start gsh.sh
> (for any reason, not just to run ldappc-ng) I see this:
> 
> Using GROUPER_HOME: /opt/grouper/grouper.api-1.6.1
> Using GROUPER_CONF: /opt/grouper/grouper.api-1.6.1/conf
> Using JAVA: java
> using MEMORY: 64m-512m
> Exception in thread "main" java.lang.NoSuchMethodError:
> org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;[Ljava/lang/Object;Ljava/lang/Throwable;)V
>         at 
> org.apache.commons.logging.impl.SLF4JLocationAwareLog.debug(SLF4JLocationAwareLog.java:133)
>         at 
> net.sf.ehcache.config.ConfigurationHelper.createCacheManagerEventListener(ConfigurationHelper.java:300)
>         at net.sf.ehcache.CacheManager.configure(CacheManager.java:283)
>         at net.sf.ehcache.CacheManager.init(CacheManager.java:225)
>         at net.sf.ehcache.CacheManager.<init>(CacheManager.java:186)
>         at 
> edu.internet2.middleware.grouper.cache.EhcacheController.initialize(EhcacheController.java:242)
>         at 
> edu.internet2.middleware.grouper.cache.EhcacheController.getCache(EhcacheController.java:175)
>         at 
> edu.internet2.middleware.grouper.cache.GrouperCache.<init>(GrouperCache.java:81)
>         at 
> edu.internet2.middleware.grouper.util.GrouperUtil.resourcePropertiesCache(GrouperUtil.java:2328)
>         at 
> edu.internet2.middleware.grouper.util.GrouperUtil.propertiesFromResourceName(GrouperUtil.java:6969)
>         at 
> edu.internet2.middleware.grouper.util.GrouperUtil.propertiesFromResourceName(GrouperUtil.java:6774)
>         at 
> edu.internet2.middleware.grouper.util.GrouperUtil.logDirsCreateIfNotDone(GrouperUtil.java:504)
>         at 
> edu.internet2.middleware.grouper.util.GrouperUtil.getLog(GrouperUtil.java:484)
>         at 
> edu.internet2.middleware.grouper.util.GrouperUtil.<clinit>(GrouperUtil.java:6174)
>         at 
> edu.internet2.middleware.grouper.app.gsh.GrouperShell.<clinit>(GrouperShell.java:409)
>         at 
> edu.internet2.middleware.grouper.app.gsh.GrouperShellWrapper.main(GrouperShellWrapper.java:16)
> 
> If I remove the long list of ldappc-ng jars from
> GROUPER_HOME/lib/custom then gsh.sh starts fine again.
> 
> Is there anything I can do to work around this problem? Are
> all of the jars (124 of them) necessary for ldappc-ng to run?
> 

Sorry, the memory difference between the two machines is a red
herring.

I swapped the set of ldappc-ng jars (both built with maven
from source) and the behavior swapped.

The two OS installations are the same.

The only difference is that one set of jars was built last
week and one set was built today.

Since maven is being used to build from source, is it possible
that today's build process downloaded some broken code that
was not downloaded last week?

Thanks,

Scott