Hello to anybody using the UserLookup/SSOClient libraries,
If you use the GroupService at the moment to look up information about
Webgroups, the behaviour when the Webgroups server is down is not very
helpful. It will return an empty Group (or empty list of groups, depending
on the query). In contrast, when a group is not found it will throw a
GroupNotFoundException to let you know.
My plan is to introduce a new exception that will be thrown when there is
a problem with the backend service. This would require only minor code
changes to your app if you make use of GroupService. However, it might make
upgrading difficult if for some reason you have deployed a number of
applications with a single copy of UserLookup. There’s no reason to do that
instead of including the library in each application but I wanted to check
before making these API changes.
Web Sign On
Web Sign On
Proposed changes to Webgroups querying library
You need to be logged in to post in this topic.
-
0 likes
-
Re: Proposed changes to Webgroups querying libraryHi Nick, Sounds like a good idea. Will we still be able to leave our old apps to work as they currently do with the old userlookup.jar? If not and we need to change all our old apps we would need to choreograph it which would take a bit more planning, so please don’t go ahead until we’ve got that in place. Otherwise the fact that all our apps are moving to VMs will probably be a help, as userlookup is in common/lib. Would you be free to come to the ACSS java group meeting on Thursday to answer any questions about the change? It’s at 10.30 in ITS4. Zoe0 likes
-
Re: Proposed changes to Webgroups querying libraryIf you are using one userlookup.jar then you can only upgrade them all at once – but similarly, you’re free to continue using the current userlookup.jar on your main server and upgrade it for each application as it is moved to a separate VM. More subtley, the change would only affect apps that directly use the GroupService methods, which might only be a couple. I think Paul is looking at which ones those might be. In that case you would be able to upgrade userlookup and deploy updated versions of just those apps. Whether that’s feasible depends on how many apps there are. A compromise would be for me to make the exception a RuntimeException, so that it gets thrown but it isn’t necessary to catch it in code. You would then be able to upgrade without having to change your code. The only difference would be that when there was a server problem, this exception would escape, instead of the service returning an empty Group object.0 likes
-
Re: Proposed changes to Webgroups querying librarySo just to clarify, are you saying that if apps continue to use the old userlookup.jar they will be unaffected? Or would that only be the case if you make the Exception a RuntimeException?0 likes
-
Re: Proposed changes to Webgroups querying libraryApps that use the old userlookup.jar will be unaffected. However, on xi you have many apps all using the same userlookup.jar, meaning that if we make it a checked exception, you will have to upgrade them all at the same time, which may be difficult to co-ordinate – hence the appeal of using a RuntimeException0 likes
-
Re: Proposed changes to Webgroups querying library> Apps that use the old userlookup.jar will be unaffected. Thanks for the clariification. > However, on xi you have many apps all using the same userlookup.jar, meaning that if we make it a checked exception, you will have to upgrade them all at the same time, which may be difficult to co-ordinate hence the appeal of using a RuntimeException We’re aware of how our apps are configured (see my first post), but thanks for making sure we didn’t overlook it.0 likes
-
Re: Proposed changes to Webgroups querying libraryForgot to say – can we get back to you after our meeting tomorrow morning?0 likes
-
Re: Proposed changes to Webgroups querying libraryYep, that’s fine.0 likes
-
Re: Proposed changes to Webgroups querying libraryOK, the ACSS java developers discussed this this morning and here’s the conclusion: Since you’ve reassured us that apps that continue to use the old userlookup.jar will be unaffected, we’re happy for you to go ahead and put this change into the latest version of the web signon jar without requiring backwards compatibility (i.e. the new exception needing to extend RuntimeException). We don’t plan to upgrade the shared userlookup.jar since apps are being migrated away from Xi in any case. We do need those apps on Xi to continue to work though (the migration will go on over many months), so we’re taking you at your word that no changes at the GroupService server end will affect them so long as we leave the existing jar intact. Let me know if I’ve misunderstood or that’s not clear. Thanks for keeping us posted Zoe0 likes
-
Re: Proposed changes to Webgroups querying libraryHi Zoe, You’re correct that this is purely a client-side change – if you keep using the userlookup.jar on Xi, it will continue to work exactly as it does now, indefinitely. So I’ll make the change then, and you can start to use the new version for migrated apps whenever is convenient (after I’ve released it of course). Thanks for your help.0 likes
-
Re: Proposed changes to Webgroups querying libraryBrilliant, thanks for letting us know.0 likes
-
Re: Proposed changes to Webgroups querying librarySSO Client 1.77 is available here: http://build.elab.warwick.ac.uk/artefacts/sso-client/0 likes