CODE_ARTICLE_TITLE: pmed.1000053, pmed.1000055

[npeterson]

CODE_ARTICLE_TITLE string shows in the browser header bar

two more code_article_titles on articles newly ingested on production, scheduled to pub today. Could you clear the browse cache keys for pmed.1000053 and pmed.1000055 asap.

is this indicative of some underlying issue that I am not noticing? or random (so far as we know)?

[wtoconnor]

My current theory:

in global_head.ftl

<#assign pgTitleOrig = freemarker_config.getTitle(templateFile, journalContext)> <#assign pgTitle = pgTitleOrig> <#if pgTitleOrig = "CODE_ARTICLE_TITLE" && articleInfoX??> <#--to get article title in w/o a new template for now-->

<#assign pgTitle = freemarker_config.getArticleTitlePrefix(journalContext) + " " + articleInfoX.unformattedTitle>

</#if>

<title>${pgTitle}</title>

NOTE: if articleInfoX does not exist then pgTitle remains page title.

Now articleInfoX is set by setCommonData() in FetchArticleAction? by invoking

articleInfoX = browseService.getArticleInfo(URI.create(articleURI));

From the following code this will return null if pep.checkAccess(ArticlePEP.READ_META_DATA, id); throws a security error.

@Transactional(readOnly = true) public ArticleInfo? getArticleInfo(final URI id) {

try {

pep.checkAccess(ArticlePEP.READ_META_DATA, id);

} catch (SecurityException? se) {

if (log.isDebugEnabled()) {

log.debug("Filtering URI " + id + " from Article list due to PEP SecurityException?", se);

} return null;

}

This will result in the bad title. My guess is that the page is accessed before the security model is updated?

So we need to look at the logs for log.debug("Filtering URI " + id + " from Article list due to PEP SecurityException?", se); by setting debug on.

Unfortunately this does not quite fit the report since the fix is to remove the browseCache entry for the article id. I need more info and a debug enabled log when the event occurs.

[wtoconnor]

(In [7617]) For some reason articleInfoX is being cached with a null value. It is not clear why. I have added a contructor and allowNulls boolean to the cache so that it will not allow nulls to be inserted into the cache. This can be set in the config and the default value is true.

Addresses #1267

[wtoconnor]

I checked in a change to the applicationContext.xml that initializes browseCache to not cache null lookups. This will force a mulgara query to occur whenever the article does no exist however but will prevent the necessity of Russ clearing the cache when the problem occurs.