Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] xml-import errors

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] xml-import errors

Chronological Thread 
  • From: graham <>
  • To: "GW Brown, Information Systems and Computing" <>
  • Cc: "" <>, "Pytel,G" <>
  • Subject: Re: [grouper-users] xml-import errors
  • Date: Thu, 22 May 2008 15:00:08 +0100

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?


GW Brown, Information Systems and Computing wrote:

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


--On 21 May 2008 17:42 +0100 graham

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.


GW Brown, Information Systems and Computing wrote:

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


--On 21 May 2008 16:11 +0100 graham

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);

You could try:

Object value =;

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
te s(Unknown Source)
no wn Source)
n. grouperExecute( at
ba ck(
.c allback(

and I think the issue is actually with getAttributes() trying to
retrieve an inappropriate value from a Map: the javadoc for Map says

"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).


GW Brown, Information Systems and Computing

Sponsor me from London to Brighton on

GW Brown, Information Systems and Computing

Archive powered by MHonArc 2.6.16.

Top of Page