Re: [udig-devel] refresh a catalog item

[Andrea Antonello <andrea.antonello@xxxxxxxxx>]

I noticed one more thing by comparing the object ids that eclipse shows
when debugging. In fact the first time the DecoratingLabelProvider
getText is called, the JGrassService is a new one, created by the
drag&drop event (let's say id = 5966). Instead when I expand the three,
the getText is always (until I do not restart udig) called with a
JGrassService object of id = 5885, i.e. an old one.
So now I'm sure that the service is cached somewhere (I can imagine that
gives nice performance on services with large number of items and/or
connections to perform), but the question is: where?

Ciao,
Andrea



Andrea Antonello probaly wrote:
>> Hmmm.  I'm afraid I'm not sure what is happening.  There is some caching
>> of labels in the CatalogUIPlugin I think but I didn't think that would
>> affect the structure of the tree.
> 
> I'm also afraid I don't know exactly what happens. I'm just now
> debugging the CatalogTreeViewer and I'm getting mad.
> When I drag my location (with two mapsets in it, but udig remembers that
> it had three, I just removed one) into the view, when it comes to create
> the labels for the entry, when it comes to the method:
> getText(Object element) of the DecoratingLabelProvide the element is in
> fact a JGrassService and has 2 mapsets, which in this case it has to
> have. So I'm glad and happy.
> I click on the entry to expand the tree and what happens in the
> DecoratingLabelProvide? I get also the nonexisting mapset. So I check
> for the parent and get the JGrassService which was supposed to have 2
> mapsets... but at that point it has 3! And I can't understand where this
> happens.
> I hope I was able to explain myself a bit...
> 
> Any hint?
> 
> Andrea
> 
> 
> 
> 
> 
> 
>> Jesse
>> On Jul 23, 2007, at 9:34 AM, Andrea Antonello wrote:
>>
>>> Let me add something more: I debugged down the line and before returning
>>>  from the most top members(monitor) method (i.e. the IService method),
>>> the array contains all the needed resources, which means they are read.
>>> The problem is, they are then not visualized. It "remebers" the previous
>>> tree. How can that be?
>>>
>>> Andrea
>>>
>>>
>>>
>>> Andrea Antonello probaly wrote:
>>>> Yes, I also think the ResetService could work, I just have to struggle
>>>> with the fact that when I reload (i.e. remove and redrag into catalog)
>>>> the JGrass service, it doesn't call the members method of the nested
>>>> resources. Instead when udig restarts it goes indeep again. Is there
>>>> some memory somewhere or is it my fault?
>>>>
>>>> Andrea
>>>>
>>>>
>>>> Jesse Eichar probaly wrote:
>>>>> Hi,
>>>>>
>>>>> THe ServiceFactory.acquire() method creates a new instance of the
>>>>> service but does not affect the catalog.  It is just a factory.  You
>>>>> could probably do a find on the catalog for the service you want to
>>>>> replace.  Delete that service from the catalog and then put the new
>>>>> instance in the catalog.  I have used the ResetService and can verify
>>>>> that it does do something.  I think it even works :P.
>>>>>
>>>>> Jesse
>>>>>
>>>>>
>>>>> On Jul 23, 2007, at 8:30 AM, Andrea Antonello wrote:
>>>>>
>>>>>> Finally I got time to get into this and...it doesn't work.
>>>>>> I'm trying to understand if it all depends on a strange behaviour
>>>>>> that I
>>>>>> notice. Perhaps someone can explaint that:
>>>>>> I open udig drag a grass location into the catalog and it reads
>>>>>> everything properly. So for example I have a location with two mapsets
>>>>>> and nested inside the maps. Now I create a map in one mapset. I remove
>>>>>> the service from the catalog and then drag the location into the
>>>>>> catalog
>>>>>> again. i thought it would read the whole thin g again, but it
>>>>>> remembers
>>>>>> something and the new map is not seen.
>>>>>> If I reastart udig, the map appears. So what does it remember and
>>>>>> where?
>>>>>>
>>>>>>
>>>>>> For your info the part:
>>>>>>         IServiceFactory locator = CatalogPlugin.getDefault()
>>>>>>                 .getServiceFactory();
>>>>>>         List<IService> rereadService = locator.acquire(ID,
>>>>>> connectionParams);
>>>>>>
>>>>>> in fact creates a proper service, but without internal members. But by
>>>>>> triggering manually the members method on the members fills everything
>>>>>> down the tree, so that should work. (in fact it doesn't since it
>>>>>> remembers the old tree)
>>>>>>
>>>>>> Any hint?
>>>>>>
>>>>>> Andrea
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Jesse Eichar probaly wrote:
>>>>>>> Trying to remember.  Take a look at the ResetService class.  It
>>>>>>> essentially kicks the service so that the tree will be loaded again.
>>>>>>> Remember that there is a chance that there is a bug with regards to
>>>>>>> multi-level services since you are the trail-blazer here.
>>>>>>>
>>>>>>> Jesse
>>>>>>> On Jul 15, 2007, at 11:26 AM, Andrea Antonello wrote:
>>>>>>>
>>>>>>>> I need to add a created map to the catalog. That is easy with
>>>>>>>> shapefile
>>>>>>>> or so, but I can't figure out how to do that in a multilevel
>>>>>>>> service,
>>>>>>>> i.e. I want to add an entry to the JGrass location service, which is
>>>>>>>> something similar in the level management to the WMS service.
>>>>>>>> Do I have to re-read it and if yes how do I trigger the re-read of a
>>>>>>>> service? Is there a more performant way?
>>>>>>>>
>>>>>>>> Ciao
>>>>>>>> Andrea
>>>>>>>> _______________________________________________
>>>>>>>> User-friendly Desktop Internet GIS (uDig)
>>>>>>>> http://udig.refractions.net
>>>>>>>> http://lists.refractions.net/mailman/listinfo/udig-devel
>>>> _______________________________________________
>>>> User-friendly Desktop Internet GIS (uDig)
>>>> http://udig.refractions.net
>>>> http://lists.refractions.net/mailman/listinfo/udig-devel
>>>>
>>
>