Grouper Users - Open Discussion List

[graham <>]

Hi Gary,

Sorry - didn't go off-list intentionally. back on-list again...

Your new jar file worked - the search results are displayed without 
throwing an exception. The password is displayed too which is 
unfortunate but a separate issue. This is odd as as far as I can see 
your change is exactly the change I made myself, which didn't work. I 
must have bodged the compile/install somehow.

Anyway, thanks for that. Are you going to get that change fed back to 
the subject cvs?

Changing the subject a bit, my next task will be to get grouper to 
provision group information back to ldap using ldappc. I'm finding the 
documentation included with ldappc a little opaque; is there any 
documentation about incorporating ldappc into grouper, written more from 
the grouper point of view? And are there any problems in combining 
ldappc with the current grouper release-candidate?

Cheers
Graham

GW Brown, Information Systems and Computing wrote:
> Graham,
>
> I don’t think line 270 is the problem:
>
> Set attributeNameSet = this.getAttributes();
>
> simply calls
>
>    protected Set getAttributes() {
>        return this.attributes;
>    }
>
> in BaseSourceAdapter.
>
> It turns out I hadn’t saved the java change before building the JAR 
> yesterday (I’ve attached a corected JAR). The JAR should be ~40K rather 
> than ~20K because of debug info. If this JAR is in place you should 
> really be getting line numbers for Subject API code in the stack trace. 
> For the UI it is the WEB-INF/lib version that is important. You have to 
> build the UI not just the API.
>
> I’m sure we can figure this out if we get line numbers in the stack 
> trace...
>
> Gary
>
> --On 21 May 2008 17:42 +0100 graham 
> <>
>  wrote:
>
> > I've tried it, but unless I've somehow not used it right (did ant clean,
> > then used it to replace the old jar in grouper-api/lib, then rebuilt
> > everything), it's not changed anything at all. The log file shows the
> > same as before (below).
> >
> > But looking inside it I can't see how it would change anything - if as I
> > think the problem is at line 270 in JNDISourceAdapter, that isn't in a
> > try/catch block at all AFAICS.
> >
> > It's time for me to go home now, hope I'm not doing something really
> > dopey... will have another go tomorrow.
> >
> > Graham
> >
> >
> >
> > GW Brown, Information Systems and Computing wrote:
> > > Graham,
> > >
> > > Try the attached jar file. I've made the same change in it but also
> > > built it with debug info so you should get a line number for the
> > > exception.
> > >
> > > Gary
> > >
> > > --On 21 May 2008 16:11 +0100 graham 
> > > <>
> > >  wrote:
> > >
> > > > GW Brown, Information Systems and Computing wrote:
> > > > > Hi Graham,
> > > > >
> > > > > I think the password problem occurs because of the way loadAttributes
> > > > > works in JNDISourceAdapter:
> > > > >
> > > > > Set values = new HashSet();
> > > > >                for (NamingEnumeration en = attr.getAll(); 
> > > > > en.hasMore();
> > > > >                ) { String value = (String) en.next();
> > > > >                    values.add(value);
> > > > >                }
> > > > >
> > > > > You could try:
> > > > >
> > > > >  Object value = en.next();
> > > > >  values.add(value.toString());
> > > >
> > > > I've tried that with no joy. I believe the problem is coming from 
> > > > deeper
> > > > than that; grouper_ui.log now shows:
> > > >
> > > > 2008-05-21 15:09:50,778 ERROR actions.GrouperCapableAction: <
> > > > GrouperSystem 8EE00CF9611428E6F16E8E6AD76F3AA1-0008
> > > > 9b243998-d62a-4e7c-9e43-6bd37159fccb GrouperSystem g:isa >
> > > > java.lang.ClassCastException: [B
> > > >          at
> > > > edu.internet2.middleware.subject.provider.JNDISourceAdapter.loadAttribu
> > > > te s(Unknown Source)
> > > >          at
> > > > edu.internet2.middleware.subject.provider.JNDISubject.getAttributes(Unk
> > > > no wn Source)
> > > >          at
> > > > edu.internet2.middleware.grouper.ui.actions.PopulateSubjectSummaryActio
> > > > n. grouperExecute(PopulateSubjectSummaryAction.java:362) at
> > > > edu.internet2.middleware.grouper.ui.actions.GrouperCapableAction$1.call
> > > > ba ck(GrouperCapableAction.java:206)
> > > >          at
> > > > edu.internet2.middleware.grouper.internal.dao.hib3.Hib3TransactionDAO$1
> > > > .c allback(Hib3TransactionDAO.java:46)
> > > >
> > > >
> > > > and I think the issue is actually with getAttributes() trying to
> > > > retrieve an inappropriate value from a Map:  the javadoc for Map says
> > > > (unhelpfully):
> > > >
> > > > "Attempting to insert an ineligible key or value throws an unchecked
> > > > exception, typically NullPointerException or ClassCastException.
> > > > Attempting to query the presence of an ineligible key or value may 
> > > > throw
> > > > an exception, or it may simply return false; some implementations will
> > > > exhibit the former behavior and some will exhibit the latter."
> > > >
> > > > If that's what's generating my ClassCastException I need to block the
> > > > ineligible value from getting into the Map in the first place, rather
> > > > than tracking down the places where the value is extracted.
> > > >
> > > > But if that's so I can't see why no-one else would have run into this
> > > > problem before - surely everyone has passwords in their LDAP
> > > > directories? I'm inserting mine into Fedora-DS in an ldif file like so:
> > > >
> > > > userPassword: {SHA}Va8gQV6tDd1Bfzf6kaTHZ7dK7jQ=
> > > >
> > > > Other applications seem happy to accept this format (ldapsearch simply
> > > > does not display the password field, JXPlorer displays the password
> > > > field name with '(non string data)' in the value field. Shibboleth
> > > > works using the password).
> > > >
> > > > Graham
> > >
> > >
> > >
> > > ----------------------
> > > GW Brown, Information Systems and Computing
> >
> >
> > --
> > Sponsor me from London to Brighton on
> > http://www.justgiving.com/grahamseaman
>
>
>
> ----------------------
> GW Brown, Information Systems and Computing