nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Error: after changing tag in templating.cfg

John742

We are in the midst of an upgrade from 5.5.2 to 6.5.
I have recently replaced:
<templating> with <templating prune-missing-files="t">
This allows TeamSite to validate whether the template actually exists in the branch before displaying it as a choice.
I have tested that this works great for about 15 branches, but one branch gives the error below. changing templating.cfg back to the way it used to be, of course brings up all templates as choices, but it does not throw an error and I have also validated that the templates that should work for that branch do. Any Ideas?

Error:
An error occurred executing command com.interwoven.ui.formspub.CatTypeListCommand

java.lang.ClassCastException
at com.interwoven.ui.formspub.utils.TemplateManagerImpl$FileSystemFilter.filterTypes(TemplateManagerImpl.java:930)
at com.interwoven.ui.formspub.utils.TemplateManagerImpl.getTypes(TemplateManagerImpl.java:212)
at com.interwoven.ui.formspub.CatTypeListCommand.getDataTypeNodes(CatTypeListCommand.java:165)
at com.interwoven.ui.formspub.CatTypeListCommand.getCategoryNodes(CatTypeListCommand.java:153)
at com.interwoven.ui.formspub.CatTypeListCommand.execute(CatTypeListCommand.java:124)
at com.interwoven.ui.base.impl.command.CommandHandler.doExecuteCommand(CommandHandler.java:857)
at com.interwoven.ui.base.impl.command.CommandHandler.tryRunCommandDescriptor(CommandHandler.java:700)
at com.interwoven.ui.base.impl.command.CommandHandler.tryRunCommandID(CommandHandler.java:587)
at com.interwoven.ui.base.impl.command.CommandHandler.runCommand(CommandHandler.java:430)
at com.interwoven.ui.base.impl.command.CommandCallbackContextImpl.callback(CommandCallbackContextImpl.java:45)
at com.interwoven.ui.base.wizard.WizardCommand.execute(WizardCommand.java:114)
at com.interwoven.ui.base.impl.command.CommandHandler.doExecuteCommand(CommandHandler.java:857)
at com.interwoven.ui.base.impl.command.CommandHandler.tryRunCommandDescriptor(CommandHandler.java:700)
at com.interwoven.ui.base.impl.command.CommandHandler.tryRunCommandID(CommandHandler.java:587)
at com.interwoven.ui.base.impl.command.CommandHandler.runCommandLoop(CommandHandler.java:240)
at com.interwoven.ui.base.impl.command.CommandServlet.doGet(CommandServlet.java:256)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at com.interwoven.ui.base.impl.auth.AuthenticationFilter.doFilter(AuthenticationFilter.java:206)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at com.interwoven.ui.base.util.SetRequestEncodingFilter.doFilter(SetRequestEncodingFilter.java:105)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
at java.lang.Thread.run(Thread.java:534)

J Dagenhardt

Find more posts tagged with

Comments

iwovGraduate

This usually happens when you have some invalid character(s) in your templating.cfg or if it does not comply structurally with the DTD.
Verify that and/or post your templating.cfg

John742

Thanks for your response.
Let me be more clear in what does and does not work
With the old entry <templating> ALL branch templates work correctly (it just displays every template I have on every branch) but everything works, granted you pick a template that exist in templatedata

With the new entry <templating prune-missing-files="t"> ALL branches work(displays only templates that exist in that branch), except one let's call it PROBbranch. And choosing one works fine

**ALSO very important - the <category> in templating.cfg that should be available to PROBbranch is used in other branches and works perfectly.

This seems to me to validate the config file.

J Dagenhardt

John742

I have just made the same change on another 6.5 server(these servers were built from the same prodcution instance of 5.5.2) and received the same EXACT results.

J Dagenhardt

iwovGraduate

You might be hitting the bug (can't remember the #) with prune-missing-files.

Questions -
- Do you see the same error if you are in the root of the workarea and the data directory for the category/data-type for that branch ?
- Did you have any category/data-type directories for that branch in the past that you have deleted and submitted the deletions ?
- You are on 6.5 Correct ?
- You are getting this error when you use File -> New Form Entry ? Can you edit existing DCRs ?
- Using CCStd or CCPro ? (perhaps not relevant)

John742

- Do you see the same error if you are in the root of the workarea and the data directory for the category/data-type for that branch ?
Good point and as long as i stay within the data- type directory New form creates a new form using the datacapture.cfg for that data-type (in other words i don't get a choice it just grabs the one I am in)

- Did you have any category/data-type directories for that branch in the past that you have deleted and submitted the deletions ?
I cannot say for sure but it is possible. I have thought that my next step is to wipe templatedata from that branch and repopulate.

- You are on 6.5 Correct ?
Yes, version 6.5

- You are getting this error when you use File -> New Form Entry ? Can you edit existing DCRs ?
Yes we use New Form Entry and Yes I can edit existing DCR's

- Using CCStd or CCPro ? (perhaps not relevant)
CCPRO

J Dagenhardt

iwovGraduate

Check with support. Its a known issue.
Unfortunately, I don't recall the bug # and don't have enough time right now to hunt it down.

If I recall correctly this happens if you deleted the category/data-type/... folders and submitted the deletions. The workaround was to recreate those in your workarea or not use the prune-missing attribute.

John742

Great Thanks. I found it

Bug ID 56668
Address issue with creating new DCR when templating.cf uses prune-missing-file="t".
There seems to also be a patch. I will investigate further. Thanks again for the assist.

J Dagenhardt

iwovGraduate

The last time I checked this was not fixed in 6.5 but fixed in one of the SPs/Patches for 6.1.
Ofcourse there is a good chance that the information I have is outdated by now.

John742

This information still seems to be accurate. I have taken the other approach you suggested: recreating the category/data-type folders. This fixes a problem branch, but does not preserve version history. I am thinking there may be a CLT to copy files and preserve version history, but in my case most files only have at most 2 versions.
my steps:
Rename existing PROBbranch
create new branch with original PROBbranch name
do a "copy to" from old PROBbranch to new PROBbranch (I copied the folders inside the WA ,but copying the entire WA may preserve versions. I did not test this)
This has corrected the problem. Thanks again!!

J Dagenhardt