[MAGNOLIA-2756] Cleanup namespaces in some of our bootstrap files Created: 02/Jun/09  Updated: 03/May/17  Resolved: 02/Jun/09

Status: Closed
Project: Magnolia
Component/s: cache, core
Affects Version/s: 4.1
Fix Version/s: 4.1

Type: Bug Priority: Critical
Reporter: Magnolia International Assignee: Magnolia International
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MAGNOLIA-7022 Restore filtering of unwanted namespa... Closed
duplicate
is duplicated by MGNLSTK-367 Cleanup namespaces in some of our boo... Closed
relation
is related to MAGNOLIA-2616 Provide a method to flush page based ... Closed
is related to MGNLFORM-37 cleanup bootstrap files: remove wrong... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled

 Description   

For instance, when exporting a file, we now have namespaces such as

  • xmlns:jcrutils="xalan://it.openmindonline.urmetdomus.assembler.utils.Path" ?
  • xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" ??
  • xmlns:stringutils="xalan://org.apache.commons.lang.StringUtils" StringUtils????
    and other just-as-suspicious ones, such as xmlns:x="urn:schemas-microsoft-com:office:excel".

Findings:

Jackrabbit has a centralized namespaces registry. It stores/caches the registered namespaces under repositories/magnolia/repository/namespaces/ns_idx.properties and repositories/magnolia/repository/namespaces/ns_reg.properties

When you start with a clean repo, it only has very basic NSs (jackrabbit, jcr, mgnl). As soon as you bootstrap one of the "infected" files, however, the "suspicious" NSs from that file are registered. Subsequently, any node that you will export from this repository will result in an exported file with these namespaces. That's why I used the word "infected" - because as soon as one has bootstrapped such a weird file, your system is basically "infected".

This was probably introduced by accident in ONE file (namely one bootstrap file of the cache, which is the first to register these NSs when installing a fresh instance) and subsequently spread to all the others.

The oldest revision I can find that introduced (some of) these namespaces is r24820 for magnolia-module-cache/src/main/resources/mgnl-bootstrap/cache/config.modules.cache.config.configurations.default.xml (MAGNOLIA-2616)

How or why these were introduced at that point is still a mystery (maybe a buggy Jackrabbit was used when this file was exported, or the file was tempered upon using some misbehaving tool)

To avoid having to start from a clean repo, I think (to be double-checked) that simply removing the ns_idx.properties and ns_reg.properties files could work.



 Comments   
Comment by Magnolia International [ 02/Jun/09 ]

As the comments from Hudson above suggest, I have cleaned up all our bootstrap files; even those which did not refer to those suspicious namespaces. As a result, they're all consistent with regards to namespace declaration.

I simply used the following regex subsitution:

<sv:node(.*?)(\s+xmlns:[a-z0-9_]+=".*?")+(.*?)>

replace by

<sv:node\1\3 xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:mgnl="http://www.magnolia.info/jcr/mgnl"\r
  xmlns:rep="internal" xmlns:mix="http://www.jcp.org/jcr/mix/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0"\r
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:fn="http://www.w3.org/2005/xpath-functions"\r
  xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:sv="http://www.jcp.org/jcr/sv/1.0"\r
  xmlns:fn_old="http://www.w3.org/2004/10/xpath-functions" xmlns:jcrfn="http://www.jcp.org/jcr/xpath-functions/1.0">

Hopefully, this will stay consistent from now on. If when (re)exporting a node for an existing bootstrap, please make sure that the NS declaration isn't modified.
(if the above declaration wasn't enough or different from the standard, I might re-run the script to fix all of them again - I'm not 100% sure I took the latest/cleanest example possible)

And most importantly, before committing any new or modified bootstrap file, make sure it doesn't introduce any extraneous namespace again !

Comment by Magnolia International [ 02/Jun/09 ]

A simple advice to developers: kill all your existing repositories/instances, or AT THE VERY LEAST, remove all ns_idx.properties and ns_reg.properties files.

Generated at Mon Feb 12 03:39:47 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.