Grouper Developers Forum

[Chris Hyzer <>]

No problem, I moved the jars from ui to api (and ws), all api unit tests 
pass.  Note, with those jars you can use the smtpappender from log4j in 
anything that uses the api...  I could see hooks firing off emails also so it 
was only a matter of time.

Chris

> -----Original Message-----
> From: Tom Barton 
> [mailto:]
> Sent: Thursday, May 08, 2008 6:09 PM
> To: Chris Hyzer
> Cc: Cramton, James; 
> 
> Subject: Re: [grouper-dev] Strange grouper error on 1.3.0 rc1
>
> Chris, can these be added to the dist.lib target in time for 1.3.0? -
> Tom
>
> Cramton, James wrote:
> > 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.mbo
> > x/%%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>(Hi
> > b3DAO.java:71)
> >
> >         at
> >
> edu.internet2.middleware.grouper.internal.dao.hib3.Hib3DAOFactory.getG
> > roup(Hib3DAOFactory.java:57)
> >
> >         at
> >
> edu.internet2.middleware.grouper.GrouperSourceAdapter.getSubject(Group
> > erSourceAdapter.java:97)
> >
> >         at
> >
> edu.internet2.middleware.grouper.subj.SourcesXmlResolver.find(SourcesX
> > mlResolver.java:87)
> >
> >         at
> >
> edu.internet2.middleware.grouper.subj.CachingResolver.find(CachingReso
> > lver.java:67)
> >
> >         at
> >
> edu.internet2.middleware.grouper.subj.ValidatingResolver.find(Validati
> > ngResolver.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(C3P0Connecti
> > onProvider.java:154)
> >
> >         at
> >
> org.hibernate.connection.ConnectionProviderFactory.newConnectionProvid
> > er(ConnectionProviderFactory.java:124)
> >
> >         at
> >
> org.hibernate.connection.ConnectionProviderFactory.newConnectionProvid
> > er(ConnectionProviderFactory.java:56)
> >
> >         at
> >
> org.hibernate.cfg.SettingsFactory.createConnectionProvider(SettingsFac
> > tory.java:414)
> >
> >         at
> >
> org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:6
> > 2)
> >
> >         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>(Hi
> > b3DAO.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
> >
> >
> >