I am using the following snippet to inject a title in the base-template:
<#-- Title -->
<!-- get title from document-bean --->
<#if hstRequest.requestContext.contentBean.title??>
<title>${hstRequest.requestContext.contentBean.title}</title>
<!-- get title from servlet-attribute (banner component) --->
<#elseif hstRequest.requestContext.getServletRequest().getAttribute("htmlTitle")??>
<title>${hstRequest.requestContext.getServletRequest().getAttribute("htmlTitle")}</title>
<!--otherwise set a default title -->
<#else>
<title>LIENAS GmbH</title>
</#if>
<!-- for the root-page, because servlet does not work here -->
<#if hstRequest.requestContext.baseURL.pathInfo = "" || hstRequest.requestContext.baseURL.pathInfo = "/">
<title>LIENAS GmbH</title>
</#if>
My questions are:
1.Why can I not access the Servlet-Attribute `htmlTitle on the root-page (I debugged the component- it should be there)
2. In case (1) the #else-Block is not executed (that is why I have the last #if Block
HST is component based framework, so page is composed from the output of different components (composing is done in aggregation valve, see link below).
If you don’t have a controller(component) assigned to your base layout page which sets some attributes onto request, there will be no attributes you can access.
You also cannot access attributes from other (child) components: each component has its own isolated request (this is a bit simplified explanation, see links below for more info).
You can however set attributes onto HstRequestContext object, HstRequestContext is shared among components and each component can set or read attributes from it.
Just remember that execution of the child components is not orderable and also not guaranteed (changing HST config might reorder components). So, before setting an attribute onto HstRequestContext you should check if it already exists (because it can already be set by other component). You can implement your own logic there and decide what to do if attribute is already set.
related documentation:
In addition, HstRequest object provide namespaced access to information such as the parameters and attributes for the component from the request, the HstRequestContext and lifecycle phase. The access is namespaced such that every HstComponent can read and write parameters and attributes from the HstRequest without needing to take into account other Components writing for example to the same attribute name.
That block needs additional if check hstRequest.requestContext.contentBean??
Other than that, it should work if you set things onto requestContext.
(RequestContextProvider.get().setAttribute(“contentBean”, someBean) etc…
unfortunately I do not see errors - althought there should be errors !!
I guess the reason for that is the following error I get on starting since I updated to Version 14.3.3!!!
ERROR StatusLogger Unable to access file://D/Developement/git-hippo/osde_4_1/conf/log4j2-dev.xml
...
ERROR StatusLogger Reconfiguration failed: No configuration found for 'Default' at 'null' in 'null'
Seems to be a version conflict with log4J! I think I shoulf fix that- to get the expected errors.
Do you know this error and can you tell me how I can fix that ??
Additional Info:
On my integration-server I get the following lines:
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/opt/cms/tomcat/shared/lib/log4j-slf4j-impl-
2.13.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/opt/cms/tomcat/shared/lib/log4j-slf4j-impl-2.11.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
If file://D/Developement/git-hippo/osde_4_1/conf/log4j2-dev.xml exists, check if your tomcat user has enough rights to access it…(file://D) smells like a windows (or a mac?) system… I haven’t touched either one for ages, so I can’t help you with that (user rights issue, if that is the case).
Log4j libraries should only be part of the tomcat shared folder, so if any of your war files contains those jars, that should be fixed (exclude them from war files).
It is a Windows System and I am quite sure that this is not a rights issue.
As already mentioned, that occurs since the Update to 14.3.3.
I tested with a fresh deployment of that version - everything is fine there!
I am also fighting with the maven configuration since that update. In my IDE (IntelliJ) the modules are not always recognized correctly. Especially when I check some changes into git and merge them on annother computer.
The error-message on dev appears while site.war is deployed! So I checked in site.war, if there is a slf4j*.jar in that file. There isn’t.
Where else could the 2nd-version (2.11.1) come from ??? I think it should onlx be 2.13.3 ! Correct?
and come back with the result.