Grouper Developers Forum

["Cramton, James" <>]

We’re not using smtpAppender in log4j; we use the ui’s email notification configuration options, but this provisioning process does not utilize the UI code. And our classpath just uses group.jar, grouper-lib.jar, and now activation.jar and mailapi.jar as well.  It’s a bit of a mystery we don’t have time right now to track down, but at least there’s a workable solution for our provisioning code. Thanks for the help!

 

From: Chris Hyzer [mailto:]
Sent: Thursday, May 08, 2008 11:09 AM
To: Cramton, James;
Subject: RE: [grouper-dev] Strange grouper error on 1.3.0 rc1

 

Are you using smtpAppender in log4j.properties?

 

http://mail-archives.apache.org/mod_mbox/logging-log4j-user/200608.mbox/%%3E

 

I think if you don’t use an smtpAppender, then I think you shouldn’t need these jars, but if you do, then you do.  Right?  Or is something else requiring it.  Your exception NoClassDefFoundError makes me think that Bert was right when he said you might have multiple of the same jar on classpath… since it wasn’t a ClassNotFoundException (or was there one of those somewhere else in the log?)  Anyways, I think we should support mail from logs, so I think we should add the jars to grouper api (it is already in ui), which will add to grouper-lib.jar, and it should be fine…  if we don’t want to do this before 1.4, the workaround is just to manually add the jars to grouper/lib, then run the “ant dist.lib”, and it  should add to grouper-lib.jar…

 

 

From: Cramton, James [mailto:]
Sent: Thursday, May 08, 2008 10:23 AM
To:
Subject: RE: [grouper-dev] Strange grouper error on 1.3.0 rc1

 

FYI…we tracked down the cause of this exception. It boiled down to a need to explicitly name  lib/activation.jar and lib/mailapi.jar in the classpath of our provisioning scripts. Once we did that, we had no problems. With Grouper 1.2.x, we just listed the grouper and grouper-lib jars, and the lib/ directory for good measure. It looks like we were getting by exclusively with the grouper and grouper-lib jars, then. Should we add these jars to the grouper-lib jar?

 

 

James Cramton

Lead Programmer/Analyst

Brown University

401 345 9795

 

 

 

From: Cramton, James [mailto:]
Sent: Wednesday, April 30, 2008 4:47 PM
To:
Subject: [grouper-dev] Strange grouper error on 1.3.0 rc1

 

I’m sure this is not a problem with Grouper, but with our provisioning scripts that call the Grouper API. But I’ve beat my head against this for a bit, and my brain cells are probably in mourning for Abby Hoffman, and therefore refuse to operate above par.  Any suggestions for resolving this would be welcome, and I’ll keep this as short as possible.

 

We provision our grouper from a separate Java process called from a perl script that sets up a reasonable classpath, along with other environment variables. The classpath includes the grouper.jar in our tomcat webapps directory, so we know it’s in sync with the webapp, which works fine.  When we create a GrouperSession, we get the following error, which has a null message.

 

 

 

Apr 30, 2008 4:44:15 PM edu.internet2.middleware.grouper.ErrorLog fatal

SEVERE: [edu.internet2.middleware.grouper.internal.dao.hib3.Hib3DAO] unable to initialize hibernate: null

Exception in thread "main" java.lang.ExceptionInInitializerError

        at edu.internet2.middleware.grouper.internal.dao.hib3.Hib3DAO.<clinit>(Hib3DAO.java:71)

        at edu.internet2.middleware.grouper.internal.dao.hib3.Hib3DAOFactory.getGroup(Hib3DAOFactory.java:57)

        at edu.internet2.middleware.grouper.GrouperSourceAdapter.getSubject(GrouperSourceAdapter.java:97)

        at edu.internet2.middleware.grouper.subj.SourcesXmlResolver.find(SourcesXmlResolver.java:87)

        at edu.internet2.middleware.grouper.subj.CachingResolver.find(CachingResolver.java:67)

        at edu.internet2.middleware.grouper.subj.ValidatingResolver.find(ValidatingResolver.java:61)

        at edu.internet2.middleware.grouper.SubjectFinder.findById(SubjectFinder.java:67)

        at edu.brown.grouper.GrouperUtils.newSession(Unknown Source)

        at StemInfo.main(Unknown Source)

Caused by: java.lang.NoClassDefFoundError

        at org.apache.log4j.Logger.getLogger(Logger.java:94)

        at com.mchange.v2.log.log4j.Log4jMLog.getMLogger(Log4jMLog.java:51)

        at com.mchange.v2.log.MLog.getLogger(MLog.java:145)

        at com.mchange.v2.log.MLog.<clinit>(MLog.java:72)

        at com.mchange.v2.c3p0.DataSources.<clinit>(DataSources.java:59)

        at org.hibernate.connection.C3P0ConnectionProvider.configure(C3P0ConnectionProvider.java:154)

        at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:124)

        at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:56)

        at org.hibernate.cfg.SettingsFactory.createConnectionProvider(SettingsFactory.java:414)

        at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:62)

        at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2073)

        at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1298)

        at edu.internet2.middleware.grouper.internal.dao.hib3.Hib3DAO.<clinit>(Hib3DAO.java:66)

        ... 8 more

 

 

Which I trace to the following lines of code in lines 46 – 57 of Hib3DAO.java:

 

abstract class Hib3DAO {

 

  // PRIVATE CLASS CONSTANTS //

  private static final Configuration  CFG;

  private static final SessionFactory FACTORY;

 

  // STATIC //

  static {

    try {

      // Find the custom configuration file

      if (Hib3DAO.class.getResource(GrouperConfig.HIBERNATE_CF) == null) {

        throw new RuntimeException("Cant find resource " + GrouperConfig.HIBERNATE_CF + ", make sure it is on the classpath.");

      }

// JFC: OK to here

      InputStream in  = Hib3DAO.class.getResourceAsStream(GrouperConfig.HIBERNATE_CF); 

      Properties  p   = new Properties();

      p.load(in);

      // And now load all configuration information

      CFG = new Configuration()

        .addProperties(p)

        .addClass(Hib3AttributeDAO.class)

        .addClass(Hib3CompositeDAO.class)

        .addClass(Hib3FieldDAO.class)

        .addClass(Hib3GroupDAO.class)

        .addClass(Hib3GroupTypeDAO.class)

        .addClass(Hib3GroupTypeTupleDAO.class)

        .addClass(Hib3GrouperSessionDAO.class)

        .addClass(Hib3MemberDAO.class)

        .addClass(Hib3MembershipDAO.class)

        .addClass(Hib3RegistrySubjectDAO.class)

        .addClass(Hib3RegistrySubjectAttributeDAO.class)

        .addClass(Hib3StemDAO.class)

        ;

      // And finally create our session factory

      FACTORY = CFG.buildSessionFactory();

// JFC: Throws an exception with a null message by here

    }

    catch (Throwable t) {

      String msg = "unable to initialize hibernate: " + t.getMessage();

      ErrorLog.fatal(Hib3DAO.class, msg);

      throw new ExceptionInInitializerError(t);

    }

  } // static

 

I’ve verified that all of the classed added in the Configuration constructor are present, as are their xml files. And again, the web interface does not have this problem, so it’s clearly something environmental about our provisioning script.

 

Thoughts on where to look next?

 

Thanks!

 

James Cramton

Lead Programmer/Analyst

401 345 9795