Alright, I think we got the problem (thanks Jesse).
In the ResolveContentProvider class and the getChildren(Object parent)
there is a check to see if the service is already cached:
IResolve resolve = (IResolve) parent;
if (structure.containsKey(resolve)) {
List<IResolve> members = structure.get(resolve);
return members != null ? members.toArray() : null;
} else {
update(resolve); // calculate
return new Object[] { Messages.ResolveContentProvider_searching };
}
The containsKey uses the "equals" method on the objects which if I
remind correctly doesn't check the subobjects. That is why the decorator
was sure to have the right service and gave back the cached one... i.e.
the wrong one.
I tried to force the update:
update(resolve); // calculate
List<? extends IResolve> members = null;
try {
members = resolve.members(null);
} catch (IOException e) {
e.printStackTrace();
}
return members.toArray();
and it works.
So now the ball is on you guys. Does this make sense? What to do here?
Andrea
Andrea Antonello probaly wrote:
> Hi Jesse,
> at the moment the whole JGrass code is at our local repository:
> https://dev.cocos.bz/plugins/scmsvn/viewcvs.php/jgrassudig/?root=jgrass
>
> I could also send you an archive with just the needed plugins...
>
> Thanks,
> Andrea
>
>
> Jesse Eichar probaly wrote:
>> Hmmm. Have you checked in your code. I can try to help you debug.
>>
>> Jesse
>>
>> On Jul 24, 2007, at 2:56 AM, Andrea Antonello wrote:
>>
>>> 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
>>>>>>>
>>
> _______________________________________________
> 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
