Drew, I agree that while admin.uPortalTemplateUserName=admin does not seem right, it would have absolutely no effect if uPortal didn't think that admin didn't save its layout. Regardless, at least I have a test case to test the fix you have suggested. I created a JIRA (http://www.ja-sig.org/issues/browse/UP-2687) and will test the fix this morning. I'll post what happens when admin gets a new template layout. ;-)
Adam
Drew Wills wrote:
> Adam,
>
> Although I can't imagine admin.uPortalTemplateUserName=admin coming to
> a good end in any circumstances, the stack trace you posted still
> looks like a bug to me...
>
> #####
> insert =
> "INSERT INTO UP_USER_PROFILE (USER_ID, PROFILE_ID,
> PROFILE_FNAME, PROFILE_NAME, DESCRIPTION, LAYOUT_ID, STRUCTURE_SS_ID,
> THEME_SS_ID) " +
> "VALUES(?, ?, ?, ?, NULL, ?, ?)";
> insertStmt = con.prepareStatement(insert);
> while (rs.next()) {
> int id = getNextKey();
>
> String profileFname = rs.getString("PROFILE_FNAME");
> String profileName = rs.getString("PROFILE_NAME");
> String description = rs.getString("DESCRIPTION");
> int structure = rs.getInt("STRUCTURE_SS_ID");
> int theme = rs.getInt("THEME_SS_ID");
>
> insertStmt.setInt(1, userId);
> insertStmt.setInt(2, id);
> insertStmt.setString(3, profileFname);
> insertStmt.setString(4, profileName);
> insertStmt.setString(5, description);
> insertStmt.setInt(6, structure);
> insertStmt.setInt(7, theme);
>
> if (log.isDebugEnabled())
> log.debug("RDBMUserIdentityStore::updateUser(USER_ID=" +
> userId + ", PROFILE_FNAME=" + profileFname + ", PROFILE_NAME=" +
> profileName + ", DESCRIPTION=" + description + "): " + insert);
> insertStmt.executeUpdate();
> }
>
> #####
>
> It looks like the missing 8th paramater is LAYOUT_ID, which should
> appear between insertStmt.setString(5, description) and
> insertStmt.setInt(6, structure).
>
> drew
>
> Adam Rybicki wrote:
>> I have found another detail I didn't see before. As a side effect of
>> my having added the retrieval of person attributes from LDAP, the
>> portal now has the template user name for user "admin" as "admin."
>> Thinking that the admin user has not saved layout before, the
>> templating logic kicks in the RDBMUserIdentityStore.__getPortalUID()
>> method. Never mind that the templating would try to clone the layout
>> for user "admin" from the template user "admin." I think that the
>> issue may have nothing to do with the templating logic.
>>
>> Adam
>>
>> Adam Rybicki wrote:
>>> I think that I may have run into a bug, but being that I am not an
>>> expert in this area, I'd like to ask the developers.
>>>
>>> I've configured uPortal 3.2.1 to support simple, LDAP, and CAS
>>> authentication. When I try logging in as admin/admin, I get an
>>> exception, which looks like this:
>>>
>>> Caused by: org.apache.commons.dbcp.SQLNestedException: Borrow
>>> prepareStatement from pool failed
>>> at
>>> org.apache.commons.dbcp.PoolingConnection.prepareStatement(PoolingConnection.java:113)
>>>
>>>
>>> at
>>> org.apache.commons.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:281)
>>>
>>>
>>> at
>>> org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.prepareStatement(PoolingDataSource.java:313)
>>>
>>>
>>> at
>>> org.jasig.portal.RDBMUserIdentityStore.updateUser(RDBMUserIdentityStore.java:730)
>>>
>>>
>>> ... 37 more
>>> Caused by: java.sql.SQLException: Column count does not match in
>>> statement [INSERT INTO UP_USER_PROFILE (USER_ID, PROFILE_ID,
>>> PROFILE_FNAME, PROFILE_NAME, DESCRIPTION, LAYOUT_ID,
>>> STRUCTURE_SS_ID, THEME_SS_ID) VALUES(?, ?, ?, ?, NULL, ?, ?)]
>>> at org.hsqldb.jdbc.Util.throwError(Unknown Source)
>>> at org.hsqldb.jdbc.jdbcPreparedStatement.<init>(Unknown Source)
>>> at org.hsqldb.jdbc.jdbcConnection.prepareStatement(Unknown Source)
>>> at
>>> org.apache.commons.dbcp.PoolingConnection.makeObject(PoolingConnection.java:285)
>>>
>>>
>>> at
>>> org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1179)
>>>
>>>
>>> at
>>> org.apache.commons.dbcp.PoolingConnection.prepareStatement(PoolingConnection.java:107)
>>>
>>>
>>> ... 40 more
>>>
>>> The SQL statement in RDBMUserIdentityStore declared on line 727 does
>>> indeed look like the one reported in the exception, where the number
>>> of parameters does not match the number of columns being inserted.
>>>
>>> Am I mis-diagnosing this? If this is something new, I'll be happy
>>> to create a new JIRA issue.
>>>
>>> Thanks,
>>> Adam
>>>
>>>
>>
>
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev<<attachment: arybicki.vcf>>
