|Re: State of the ContentDescriptionManager Cache [message #535426 is a reply to message #535389]
||Sun, 23 May 2010 12:25
| Ed Merks
Registered: July 2009
I'm not sure if this is an issue, but in the past it seems to me that
once a workspace has cached a content description, if I relaunch that
same workspace but with additional plugins that would compute a new
content description that logic just never kicks in. If you copy the
file you're having a problem with and paste it to a new name, does that
new file also have a problem, or does it work correctly for that one?
Alain Picard wrote:
> I have an utility application that is launched from a launch
> configuration. I am trying to access the IContentDescription of one of
> my files. When I do a: IContentDescription desc =
> file.getContentDescription(); it returns a null.
> After debugging I am realizing that the cacheState in
> getContentDescription is EMPTY_CACHE (1). But the code in
> getContentDescription goes to:
> if (getCacheState() != ABOUT_TO_FLUSH) and then returns nulls based on
> the following test:
> if (info.isSet(ICoreConstants.M_NO_CONTENT_DESCRIPTION))
> // presumably, this file has no known content type
> If I change the value of the cache state to be ABOUT_TO_FLUSH and to
> skip this block, then the it proceeds to the readDescription call and
> it finally finds the correct content description that I'm looking for.
> So, my questions are this:
> 1- Why is there an info of M_NO_CONTENT_DESCRIPTION if the test has
> never been done (I can see that my content describer is never invoked).
> 2- Why isn't the test also testing for the cache state to be not equal
> to EMPTY_CACHE?
> 3- It seems that there is a clearContentFlags that might fix my stored
> info, but it is package visible only and the only way to reach it is
> to invalidateCache, but that is unreachable if the cache is empty. So
> is there a way to reset the file ResourceInfo or to force
> getDescriptionFor to actually perform its job.
|Re: State of the ContentDescriptionManager Cache [message #535562 is a reply to message #535426]
||Mon, 24 May 2010 12:45
| Alain Picard
Registered: July 2009
I think you're right on. The resolution is normally done when you open a
folder (IContainer) and it covers the direct children.
So I opened the project in the UI with the content provider in place and
the files were recognized correctly (even saw the decorators being
Then when I restarted my launch configuration, it had saved the content
type and was able to retrieve it.
So there is obviously a bug when someone operates only outside of the UI
and some of its default jobs, but at least there is some form of workaround.
On 5/23/2010 8:25 AM, Ed Merks wrote:
> I'm not sure if this is an issue, but in the past it seems to me that
> once a workspace has cached a content description, if I relaunch that
> same workspace but with additional plugins that would compute a new
> content description that logic just never kicks in. If you copy the file
> you're having a problem with and paste it to a new name, does that new
> file also have a problem, or does it work correctly for that one?
Powered by FUDForum
. Page generated in 0.03419 seconds