The patch for addEntry method is available here: http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=830
As far as the remove problem is concerned, when I remove a portlet registry entry, am I not removing it from registry stored in memory? I can actually query the registry immediately after removal and entry is not there. However, when I restart, it comes back. It's been a while since I played with this. When I get some time, I'll try to verify whether the workaround I suggested even works. If you do it sooner, I wouldn't mind knowing the result. Best regards, Mark C. Orciuch Next Generation Solutions, Ltd. Voice: 219-365-0691 e-Mail: [EMAIL PROTECTED] web: http://www.ngsltd.com -----Original Message----- From: Meik Arends [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 18, 2001 8:36 AM To: Jetspeed Users List Subject: Re: Update portlets.xreg Mark Orciuch wrote: >Meik, > >Be aware of some outstanding problems with the current CastorRegistryService >when registry is changed programatically. I also have an application which >manipulates portlet registry entries at runtime. It was orignally developed >using 1.3a1 code but when ported to 1.3a2, I started experiencing some >problems. One of the problems has to do with adding new entries (see >Bugzilla Bug 5091). I sumbitted a patch but the fix seems to be a lower >priority right now. Another problem that I ran into has to do with removing >registry entries - they seem to mysteriously come back after the portal is >restarted. > OK. I'm not alone :-) Can you send me your patch ? I think your other problem is related to the things Paul Spencer explains in his reply to my question. He said: "Also Jetspeed will write the .xreg files at shutdown using the entries it has in memory. If you make a change that is not read by Jetspeed BEFORE shutdown, then the change will be overwritten at shutdown. " >I have inquired about registry refresh capability as well. If I remember >correctly, calling existing refresh method will make any programatic changes >disappear. Quick workaround to your problem would be to work with specific >fragments and explicitly call saveFragment and then refresh immediately. >However, this approach is not recommened by Raphael Luta since the >implementation may change and could become database-based. > I have to try it, because there is no time to wait for DB-support ;-) > > >I'd like to get involved in getting these problems or shortcomings resolved >but there's a lot of questions I have about how this stuff is intended to >work. > >Hope this is related to your issue. Otherwise, kindly disregard it. > >Best regards, > Regards Meik -- ---------------------------------------------------------------- Meik Arends [EMAIL PROTECTED] WAP-Mail: [EMAIL PROTECTED] ( f�r wirklich dringendes ;-) ICQ: 42486557 ---------------------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
