[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: old admin servlets (was Re: [Handle-info] Failure to replicate mirror handle server 7.3.1 from primary handle 6.2.5 server)



Sounds good. I have checked our custom handle admin struts app against Handle server 7.3.1. 
I hope that will do for now. 

Looking forward to Handles 8 and the new web tools and full RESTful API. 

Ev


On Feb 10, 2014, at 12:53 PM, Robert R Tupelo-Schneck <schneck@cnri.reston.va.us> wrote:

> I finally took a look at the version-6-era admin servlets.  My actual advice to you is this.  The admin servlets are just a client, so you can successfully upgrade your *server* without changing your admin servlets.  The protocol is backward-compatible (and little-changed in any case) so the old client should have no trouble talking to the new server.
> 
> I think this is the best way for you to proceed.  (I was able to get the admin servlets limping along with version 7 code, so we could try that too if it ever seems necessary; I hope it doesn't.)
> 
> I also hope that in version 8 you will find that the new admin webapp suffices for your needs.
> 
> Best,
> Robert
> 
> On Dec 23, 2013, at 12:50 PM, Robert R Tupelo-Schneck <schneck@cnri.reston.va.us> wrote:
> 
>> That's right, first quarter of 2014.  
>> 
>> You should be able to migrate directly from 6.2.5 to 8.  At least, I don't expect any issues that haven't already come up with migrating to 7.3.1.
>> 
>> I'll look into the old web admin tool and see if I can easily diagnose and fix it.  
>> 
>> Robert
>> 
>> On Dec 23, 2013, at 12:36 PM, Evguenia Krylova <evguenia.krylova@doit.wisc.edu> wrote:
>> 
>>> Robert, 
>>> Thank you for working on the fix for version 7 custom storage mechanism. I do appreciate it.
>>> 
>>> 
>>> As for the web admin application, most shops have staff other than developers managing 
>>> handles, and for such cases a browser-based tool is ideal. Good to hear that version 8 is coming 
>>> out with a browser-based admin tool. You did mean the first quater of 2014, didn't you? 
>>> I will find more about the most important features of the web-admin tool and get back to you 
>>> when I am back. We cannot migrate to version 7 unless we have a web-based admin tool. 
>>> I did not look at it too much but speaking from memory, the servlet-based web app had some 
>>> variable names mismatch between configuration and code, did not have a build task, and smth else. 
>>> I will be able to say more come January. 
>>> 
>>> 
>>> What do you think about migrating from Handle 6.2.5 directly to 8? 
>>> 
>>> 
>>> Happy holidays!
>>> 
>>> 
>>> Ev
>>> 
>>> On 12/23/13, Robert R Tupelo-Schneck  wrote:
>>>> Okay, I will send a fix for version 7 custom storage mechanism so that it works with Hedgehog.
>>>> 
>>>> The web admin app has been effectively abandoned, though I will look and see if I can fix it for you... what error do you find?
>>>> 
>>>> Note that version 8 of the Handle software is expected to release in the first quarter of 2013, and will come with a new browser-based handle administration tool. I'd be interested to hear what features of the old web admin app are especially important for you.
>>>> 
>>>> Robert
>>>> 
>>>> On Dec 20, 2013, at 2:20 AM, Evguenia Krylova <evguenia.krylova@doit.wisc.edu> wrote:
>>>> 
>>>>> Robert,
>>>>> 
>>>>> The final decision has not been made on what the persistence layer would be. 
>>>>> For now, I am using the SQL storage that comes with the Handle code. 
>>>>> At the moment, I am working on investigating data migration strategies for 
>>>>> 6.2.5 to 7.3.1 upgrade. The big plus of Hedgehog for UW-Madison libraries is 
>>>>> it allows custom queries against structured SQL data. UW-Madison libraries 
>>>>> are planning on using handles as Fedora ids for our digital collections infrastructure.
>>>>> 
>>>>> 
>>>>> I will our of the country for the next two weeks, so no rush with the fix. 
>>>>> Migrating data via 6.2.5 mirror with SQL Handle storage against 6.2.5 primary with 
>>>>> custom storage worked for our test Handle service, which is not very representative 
>>>>> of the production Handle service. I hope that would go as smoothly. 
>>>>> 
>>>>> 
>>>>> My next step would be making web admin app working to replace the Struts version 
>>>>> that came with 6.2.5. The one bundled in the 7.3.1 source does not quite work, I extracted 
>>>>> it into a separate project for internal code archiving and Mavenized. Is there a deployable 
>>>>> distribution of the web admin Handle app?
>>>>> 
>>>>> 
>>>>> Thank you for your readiness to help out,
>>>>> Ev
>>>>> 
>>>>> On 12/19/13, Robert R Tupelo-Schneck wrote:
>>>>>> I think I see the issue with the custom storage and I have an idea of how to avoid it in the handle code. I might have a bugfix prerelease that you could try as early as Monday.
>>>>>> 
>>>>>> However, you might be equally well-served to create a 6.2.5 mirror using your new handle storage, and then upgrade that mirror to 7.3.1. When you said you are planning to use PostgreSQL for persistence, do you mean that you want to use the SQL handle storage that comes with the Handle code, or that you want to continue to use Hedgehog but backed by PostgreSQL? If you want to use the built-in SQL storage adapter, you should probably just create a 6.2.5 mirror using that storage, then upgrade to mirror to 7.3.1.
>>>>>> 
>>>>>> Robert
>>>>>> 
>>>>>> On 2013-12-19, at 17:08 , Evguenia Krylova <evguenia.krylova@doit.wisc.edu> wrote:
>>>>>> 
>>>>>>> Robert,
>>>>>>> 
>>>>>>> I would rather have 7.3.1 mirror against 6.2.5 (with custom storage) as a way of data migration. This would be 
>>>>>>> purely Handle 6.2.5 again Handle 7.3.1 API, but that fails. 
>>>>>>> 
>>>>>>> Here's the error on the client side when I run 7.3.1 server code against custom Hibernate storage of a site created under 
>>>>>>> 6.2.5. when I query for a handle:
>>>>>>> 
>>>>>>> sending HDL-TCP request (version=2.1; oc=1; rc=0; snId=0 caCrt noAuth expires:Fri Dec 20 04:04:48 CST 2013 1712/TEST [ ] [ ]) to 144.92.161.120:2645
>>>>>>> received HDL-TCP response: Error(2): ERROR: Internal Error
>>>>>>> sending HDL-HTTP request (version=2.1; oc=1; rc=0; snId=0 caCrt noAuth expires:Fri Dec 20 04:04:48 CST 2013 1712/TEST [ ] [ ]) to 144.92.161.120:2646
>>>>>>> received HDL-HTTP response: Error(2): ERROR: Internal Error
>>>>>>> HandleException (SERVER_ERROR) Internal Error
>>>>>>> at net.handle.hdllib.HandleResolver.sendRequestToInterface(HandleResolver.java:2277)
>>>>>>> at net.handle.hdllib.HandleResolver.sendRequestToServerByProtocol(HandleResolver.java:1943)
>>>>>>> at net.handle.hdllib.HandleResolver.sendRequestToServerByProtocol(HandleResolver.java:1818)
>>>>>>> at net.handle.hdllib.HandleResolver.sendRequestToServerInSiteByProtocol(HandleResolver.java:1649)
>>>>>>> at net.handle.hdllib.HandleResolver.sendRequestToSite(HandleResolver.java:1627)
>>>>>>> at net.handle.hdllib.HappyEyeballsResolver.sendRequestToSiteViaProtocol(HappyEyeballsResolver.java:205)
>>>>>>> at net.handle.hdllib.HappyEyeballsResolver.sendRequestToSites(HappyEyeballsResolver.java:173)
>>>>>>> at net.handle.hdllib.HappyEyeballsResolver.sendRequestAndSetResponseOrPublicException(HappyEyeballsResolver.java:151)
>>>>>>> at net.handle.hdllib.HappyEyeballsResolver.run(HappyEyeballsResolver.java:90)
>>>>>>> at net.handle.hdllib.HandleResolver.sendRequestToService(HandleResolver.java:1165)
>>>>>>> at net.handle.hdllib.HandleResolver.processRequestGlobally(HandleResolver.java:618)
>>>>>>> at net.handle.hdllib.HandleResolver.processRequest(HandleResolver.java:593)
>>>>>>> at net.handle.hdllib.HandleResolver.processRequest(HandleResolver.java:603)
>>>>>>> at net.handle.apps.gui.hadmin.HandleTool$ProcessRequest.run(HandleTool.java:538)
>>>>>>> at net.handle.awt.TaskIndicator.run(TaskIndicator.java:99)
>>>>>>> at java.lang.Thread.run(Thread.java:695)
>>>>>>> 
>>>>>>> 
>>>>>>> The server (7.3.1) side error is this:
>>>>>>> Starting UDP request handlers: Starting HTTP request handlers: ..Starting TCP request handlers: ...........................
>>>>>>> ..DONE
>>>>>>> ..............
>>>>>>> [ 2013-12-19 16:04:49,023 | DEBUG ] HedgehogHandleStorage.haveNA(): entered.
>>>>>>> [ 2013-12-19 16:04:49,023 | DEBUG ] HedgehogHandleStorage.checkHdlSyntax(): entered.
>>>>>>> [ 2013-12-19 16:04:49,034 | ERROR ] HedgehogHandleStorage.haveNA(): caught exception attempting to parse handle: rule "NAsegment" failed
>>>>>>> 1712
>>>>>>> ^
>>>>>>> rule stack:
>>>>>>> ABNFHedgehogHandle
>>>>>>> NamingAuthority
>>>>>>> NAsegment
>>>>>>> [ 2013-12-19 16:04:49,034 | ERROR ] HedgehogHandleStorage.haveNA(): throwing HandleException.INTERNAL_ERROR
>>>>>>> [ 2013-12-19 16:04:49,044 | DEBUG ] HedgehogHandleStorage.haveNA(): entered.
>>>>>>> [ 2013-12-19 16:04:49,044 | DEBUG ] HedgehogHandleStorage.checkHdlSyntax(): entered.
>>>>>>> [ 2013-12-19 16:04:49,045 | ERROR ] HedgehogHandleStorage.haveNA(): caught exception attempting to parse handle: rule "NAsegment" failed
>>>>>>> 1712
>>>>>>> ^
>>>>>>> rule stack:
>>>>>>> ABNFHedgehogHandle
>>>>>>> NamingAuthority
>>>>>>> NAsegment
>>>>>>> [ 2013-12-19 16:04:49,045 | ERROR ] HedgehogHandleStorage.haveNA(): throwing HandleException.INTERNAL_ERROR
>>>>>>> 
>>>>>>> 
>>>>>>> Ev
>>>>>>> 
>>>>>>> 
>>>>>>> On Dec 19, 2013, at 3:18 PM, Robert R Tupelo-Schneck <schneck@cnri.reston.va.us> wrote:
>>>>>>> 
>>>>>>>> Yes, custom storage that worked with 6.2.5 should still work with 7.3.1. Please send me the errors you received so that I can fix them. It may be that the problem is superficial and I can provide a fix quickly.
>>>>>>>> 
>>>>>>>> The path you suggest is not bad: create a 6.2.5 mirror with bdbje storage, and then restart that mirror with 7.3.1. It shouldn't be necessary, but if it works there's no reason not to do it.
>>>>>>>> 
>>>>>>>> Robert
>>>>>>>> 
>>>>>>>> On 2013-12-19, at 16:00 , Evguenia Krylova <evguenia.krylova@doit.wisc.edu> wrote:
>>>>>>>> 
>>>>>>>>> Robert,
>>>>>>>>> 
>>>>>>>>> Unfortunately, our current 1712 service uses custom Hibernate storage, which fails under the server 7.3.1 server. 
>>>>>>>>> I can bring the server up but every query fails at the Hibernate to Handle API point. So this is not going to work as a route 
>>>>>>>>> for data migration in our case. Should Handle API 7.3.1 be backward compatible with Handle API 6.2.5?
>>>>>>>>> 
>>>>>>>>> So at this point the only way around the direct 7.3.1 mirror for our 6.2.5 primary backed by custom Hibernate data storage, 
>>>>>>>>> is to mirror from 6.2.5 primary with custom storage above to 6.2.5 bdbje storage and bringing the resulting site with 7.3.1. server. 
>>>>>>>>> 
>>>>>>>>> Ev
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Dec 19, 2013, at 12:45 PM, Robert R Tupelo-Schneck <schneck@cnri.reston.va.us> wrote:
>>>>>>>>> 
>>>>>>>>>> If 7.3.1 does not like the full path for the logs folder it is a bug. Please send me the config.dct that fails and the associated error.
>>>>>>>>>> 
>>>>>>>>>> 7.3.1 will default to bdbje storage (in the absence of pre-existing storage using the version 6 default), but the old config entries should continue to work.
>>>>>>>>>> 
>>>>>>>>>> In trying to get the existing primary running with 7.3.1, the intention is that your existing configuration should work unchanged. If not (as in the case of the logs?) it is a bug, and let me know.
>>>>>>>>>> 
>>>>>>>>>> Robert
>>>>>>>>>> 
>>>>>>>>>> On 2013-12-19, at 13:32 , Evguenia Krylova <evguenia.krylova@doit.wisc.edu> wrote:
>>>>>>>>>> 
>>>>>>>>>>> I will try that next. I found by trial and error that 6.2.5 needs a config entry for the database location if Berkley db is used while 
>>>>>>>>>>> 7.3.1 does not, while 7.3.1 did not like the full path for logs folder. Is there a list of such minor discrepancies I could check 
>>>>>>>>>>> config.dct against beforehand?
>>>>>>>>>>> 
>>>>>>>>>>> Thank you,
>>>>>>>>>>> Ev
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Dec 19, 2013, at 11:35 AM, Robert R Tupelo-Schneck <schneck@cnri.reston.va.us> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> In my last message of 12/4 I suggested that you try running 7.3.1 on the primary. Is that possible?
>>>>>>>>>>>> 
>>>>>>>>>>>> Robert
>>>>>>>>>>>> 
>>>>>>>>>>>> On 2013-12-19, at 12:27 , Evguenia Krylova <evguenia.krylova@doit.wisc.edu> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Robert, 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I have checked things over and over. I do have the latest distribution of 7.3.1 and attempt to 
>>>>>>>>>>>>> use it agains the older handle server 6.2.5. Here's what I found. 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I can create a mirror handle server with 6.2.5 and then modify its config.dct by adding the following two lines:
>>>>>>>>>>>>> "storage_type" = "BDBJE"
>>>>>>>>>>>>> "db_directory" = "/handle-test/handle/hdl6.2.5_02/1712-mirror/bdbje"
>>>>>>>>>>>>> and they bring up this site with the 7.3.1 handle server code. I can query, add and modify handles.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> However, when I create a mirror handle server with 7.3.1 by running hdl-sertup-server and try to bring it up 
>>>>>>>>>>>>> with 7.3.1 server code, the replication fails with the following error, which is not quite what you see: 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> "2013-12-16 15:07:59.929-0600" 25 HANDLE.NET Server Software version 7.3.1
>>>>>>>>>>>>> Saving global values to: /home/handletsu/.handle/root_info
>>>>>>>>>>>>> Opening Berkeley database in /handle-test/handle/hsj-7.3.1/1712-mirror/bdbje
>>>>>>>>>>>>> starting replication thread
>>>>>>>>>>>>> "2013-12-16 15:08:00.470-0600" 50 unspecified max_handlers count, using default: 200
>>>>>>>>>>>>> "2013-12-16 15:08:00.470-0600" 50 unspecified max_handlers count, using default: 200
>>>>>>>>>>>>> "2013-12-16 15:08:00.471-0600" 50 unspecified max_handlers count, using default: 200
>>>>>>>>>>>>> "2013-12-16 15:08:00.483-0600" 100 class net.handle.server.HdlUdpInterface: Error setting up server socket: java.net.BindException: Cannot assign requested address
>>>>>>>>>>>>> "2013-12-16 15:08:00.483-0600" 100 class net.handle.server.HdlUdpInterface: Error setting up server socket: java.net.BindException: Cannot assign requested address
>>>>>>>>>>>>> "2013-12-16 15:08:00.484-0600" 100 class net.handle.server.HdlTcpInterface: Error setting up server socket: java.net.BindException: Cannot assign requested address
>>>>>>>>>>>>> "2013-12-16 15:08:00.484-0600" 100 class net.handle.server.HdlTcpInterface: Error setting up server socket: java.net.BindException: Cannot assign requested address
>>>>>>>>>>>>> "2013-12-16 15:08:00.511-0600" 100 class net.handle.server.HdlHttpInterface: Error setting up server socket: java.net.BindException: Cannot assign requested address
>>>>>>>>>>>>> "2013-12-16 15:08:00.511-0600" 100 class net.handle.server.HdlHttpInterface: Error setting up server socket: java.net.BindException: Cannot assign requested address
>>>>>>>>>>>>> "2013-12-16 15:08:00.710-0600" 50 Error doing replication at server: 1 144.92.161.120 (TCP/2645/adm+qry,UDP/2645/qry,HTTP/2646/adm+qry): HandleException (MISSING_OR_INVALID_SIGNATURE) Unable to verify signature for message: version=2.1; oc=1001; rc=402; snId=2 crt caCrt noAuth expires:Tue Dec 17 03:08:00 CST 2013
>>>>>>>>>>>>> HandleException (MISSING_OR_INVALID_SIGNATURE) Unable to verify signature for message: version=2.1; oc=1001; rc=402; snId=2 crt caCrt noAuth expires:Tue Dec 17 03:08:00 CST 2013
>>>>>>>>>>>>> at net.handle.hdllib.HandleResolver.verifyResponse(HandleResolver.java:2368)
>>>>>>>>>>>>> at net.handle.hdllib.HandleResolver.sendHttpRequest(HandleResolver.java:3077)
>>>>>>>>>>>>> at net.handle.hdllib.HandleResolver.sendRequestToInterface(HandleResolver.java:2268)
>>>>>>>>>>>>> at net.handle.hdllib.HandleResolver.sendRequestToServerByProtocol(HandleResolver.java:1943)
>>>>>>>>>>>>> at net.handle.hdllib.HandleResolver.sendRequestToServerByProtocol(HandleResolver.java:1818)
>>>>>>>>>>>>> at net.handle.hdllib.HandleResolver.sendRequestToServerInSiteByProtocol(HandleResolver.java:1649)
>>>>>>>>>>>>> at net.handle.hdllib.HandleResolver.sendRequestToServer(HandleResolver.java:1737)
>>>>>>>>>>>>> at net.handle.hdllib.HandleResolver.sendRequestToServer(HandleResolver.java:1688)
>>>>>>>>>>>>> at net.handle.server.replication.ReplicationDaemon.run(ReplicationDaemon.java:435)
>>>>>>>>>>>>> Caused by: HandleException (UNKNOWN_ALGORITHM_ID) Unknown signature type: HS_MAC
>>>>>>>>>>>>> at net.handle.hdllib.AbstractMessage.verifyMessage(AbstractMessage.java:503)
>>>>>>>>>>>>> at net.handle.hdllib.HandleResolver.verifyResponse(HandleResolver.java:2362)
>>>>>>>>>>>>> ... 8 more
>>>>>>>>>>>>> ~ 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I need to migrate the data from 6.2.5 to 7.3.1 since we are changing the persistence layer to PostgreSQL. 
>>>>>>>>>>>>> Please advise on what I could do next to successfully run 7.3.1 mirror against 6.2.5 primary handle server? 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>> Ev
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Dec 4, 2013, at 10:25 AM, Robert R Tupelo-Schneck <schneck@cnri.reston.va.us> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I can assure you that the DSA vs DSAwithSHA1 issue was a purely cosmetic issue in the code. 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> What's really happening here is that the mirror is initiating a session with the primary, but then can't validate the server's response within that session. I thought that somehow an incompatibility might have been introduced, but I tried this with a 6.2.5 server and a 7.3.1 server and didn't get the error.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I do not know what is causing your error. Would you be willing to upgrade your primary to 7.3.1 in order to see if that helps? This should be as easy as stopping the primary, and then restarting with the 7.3.1 software. No data migration will occur; it will simply run the 7.3.1 code with the existing data store.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 2013-12-03, at 17:46 , Evguenia Krylova <evguenia.krylova@doit.wisc.edu> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I have a mirror server setup with Handle 7.3.1 against the primary Handle 6.2.5 server. 
>>>>>>>>>>>>>>> Followed the instructions to configure the mirror "6.1 Setting up a Single Mirror Handle Server" 
>>>>>>>>>>>>>>> from http://www.handle.net/tech_manual/Handle_Tech_Manual_7_v1-1-22Dec10.pdf 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> The replication fails with the following error:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> starting replication thread
>>>>>>>>>>>>>>> "2013-12-03 15:25:14.286-0600" 50 unspecified max_handlers count, using default: 200
>>>>>>>>>>>>>>> "2013-12-03 15:25:14.287-0600" 50 unspecified max_handlers count, using default: 200
>>>>>>>>>>>>>>> "2013-12-03 15:25:14.287-0600" 50 unspecified max_handlers count, using default: 200
>>>>>>>>>>>>>>> "2013-12-03 15:25:14.690-0600" 50 Error doing replication at server: 1 144.92.161.120 (TCP/2645/adm+qry,UDP/2645/qry,HTTP/2646/adm+qry): HandleException (MISSING_OR_INVALID_SIGNATURE) Unable to verify signature for message: version=2.1; oc=1001; rc=402; snId=1 crt caCrt noAuth expires:Wed Dec 04 03:25:14 CST 2013
>>>>>>>>>>>>>>> HandleException (MISSING_OR_INVALID_SIGNATURE) Unable to verify signature for message: version=2.1; oc=1001; rc=402; snId=1 crt caCrt noAuth expires:Wed Dec 04 03:25:14 CST 2013
>>>>>>>>>>>>>>> at net.handle.hdllib.HandleResolver.verifyResponse(HandleResolver.java:2368)
>>>>>>>>>>>>>>> at net.handle.hdllib.HandleResolver.sendHttpRequest(HandleResolver.java:3077)
>>>>>>>>>>>>>>> at net.handle.hdllib.HandleResolver.sendRequestToInterface(HandleResolver.java:2268)
>>>>>>>>>>>>>>> at net.handle.hdllib.HandleResolver.sendRequestToServerByProtocol(HandleResolver.java:1943)
>>>>>>>>>>>>>>> at net.handle.hdllib.HandleResolver.sendRequestToServerByProtocol(HandleResolver.java:1818)
>>>>>>>>>>>>>>> at net.handle.hdllib.HandleResolver.sendRequestToServerInSiteByProtocol(HandleResolver.java:1649)
>>>>>>>>>>>>>>> at net.handle.hdllib.HandleResolver.sendRequestToServer(HandleResolver.java:1737)
>>>>>>>>>>>>>>> at net.handle.hdllib.HandleResolver.sendRequestToServer(HandleResolver.java:1688)
>>>>>>>>>>>>>>> at net.handle.server.replication.ReplicationDaemon.run(ReplicationDaemon.java:435)
>>>>>>>>>>>>>>> Caused by: HandleException (UNKNOWN_ALGORITHM_ID) Unknown signature type: HS_MAC
>>>>>>>>>>>>>>> at net.handle.hdllib.AbstractMessage.verifyMessage(AbstractMessage.java:503)
>>>>>>>>>>>>>>> at net.handle.hdllib.HandleResolver.verifyResponse(HandleResolver.java:2362)
>>>>>>>>>>>>>>> ... 8 more
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Has anybody successfully done this? 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I suspect that the error might be caused by this change from 7.3 release notes:
>>>>>>>>>>>>>>> "Signature code now uses algorithm DSAwithSHA1 instead of just DSA." 
>>>>>>>>>>>>>>> Any ideas how I can force 7.3.1 to use DSA instead of DSAwithSHA1?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Ev
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Handle-Info mailing list
>>>>>>>>>>>>>> Handle-Info@cnri.reston.va.us
>>>>>>>>>>>>>> http://www.handle.net/mailman/listinfo/handle-info
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Handle-Info mailing list
>>>>>>>>>>>> Handle-Info@cnri.reston.va.us
>>>>>>>>>>>> http://www.handle.net/mailman/listinfo/handle-info
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Handle-Info mailing list
>>>>>>>>>> Handle-Info@cnri.reston.va.us
>>>>>>>>>> http://www.handle.net/mailman/listinfo/handle-info
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> Handle-Info mailing list
>>>>>>>> Handle-Info@cnri.reston.va.us
>>>>>>>> http://www.handle.net/mailman/listinfo/handle-info
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Handle-Info mailing list
>>>>>> Handle-Info@cnri.reston.va.us
>>>>>> http://www.handle.net/mailman/listinfo/handle-info
>>>>> 
>>>>> --
>>>>> Evguenia Krylova
>>>>> 265 2844
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Handle-Info mailing list
>>>> Handle-Info@cnri.reston.va.us
>>>> http://www.handle.net/mailman/listinfo/handle-info
>>> 
>>> --
>>> Evguenia Krylova
>>> 265 2844
>>> 
>>> _______________________________________________
>>> Handle-Info mailing list
>>> Handle-Info@cnri.reston.va.us
>>> http://www.handle.net/mailman/listinfo/handle-info
>> 
> 
> 
> _______________________________________________
> Handle-Info mailing list
> Handle-Info@cnri.reston.va.us
> http://www.handle.net/mailman/listinfo/handle-info


_______________________________________________
Handle-Info mailing list
Handle-Info@cnri.reston.va.us
http://www.handle.net/mailman/listinfo/handle-info