[MAGNOLIA-2960] Automatic cleanup of unwanted namespaces during export Created: 29/Nov/09  Updated: 01/Sep/17  Resolved: 03/Dec/09

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 4.1.2, 4.2, 4.2.1
Fix Version/s: 4.2.2

Type: Improvement Priority: Major
Reporter: Fabrizio Giustina Assignee: Fabrizio Giustina
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File unwanted_ns_definitive_fix.diff    
Issue Links:
Relates
relates to MAGNOLIA-7022 Restore filtering of unwanted namespa... Closed
dependency
relation
is related to MAGNOLIA-3875 Re-export config.server.filters.xml c... Closed
Template:
Patch included:
Yes
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)
Testcase included:
Yes
Date of First Response:

 Description   

See MAGNOLIA-2756 for a background.
We have several unwanted namespaces in the xml export, and the way jackrabbits handles the namespace registry makes really hard to remove them and avoiding to see them showing up again in future exports... looks like it's enough to import any kind of xml file with a namespace to definitively "infect" the instance and make that namespace show up everywhere.

While with MAGNOLIA-2756 now we have clean bootstrap file, it's still to easy for a single unwanted namespace to slip in and corrupt xml export, so I'd like a more definitive solution...

I've coded a patch for a Sax filter that cleanups namespaces on the fly during export and I've added this to MetadataUuidFilter (already used by default during export) so that it's enabled by default.
If for any reason the stripping of unwanted namespaces is not wanted, the user can just set the new "magnolia.export.keep_extra_namespaces" property.
The list of namespaces is taken from MAGNOLIA-2756. Last but not least, there is a new unit test added for this.

Since I'd like to see if other agree for adding this as a default, I'm attaching the patch here before committing. Please shout if you see reasons why this should not be on by default.



 Comments   
Comment by Philipp Bärfuss [ 01/Dec/09 ]

I totally agree that we should take action to prevent such exports or imports. There is only one thing I would like to see improved, if then possible, that the list of allowed namespaces is generated dynamically. One could probably examine the node types.

Comment by Fabrizio Giustina [ 02/Dec/09 ]

There is only one thing I would like to see improved, if then possible, that the list of allowed namespaces is generated dynamically. One could probably examine the node types

I just realized that this is not actually needed and that most of the namespaces we are already allowing are useless. Since we always use a system view for exporting (and the metadataUuid filter is tied to system view too) the only namespace used is "sv":

xmlns:sv="http://www.jcp.org/jcr/sv/1.0"

The system view format doesn't use anything else, so the list of namespaces is totally useless... probably Jackrabbit declares the same list of namespaces used in the document view (I haven't checked but I assume they can be needed there).

So I think we should only leave the "sv" namespace and filtering anything else, WDYT? Maybe we should also fill an enhancement request for jackrabbit to avoid useless namespaces declarations for system view...

Comment by Fabrizio Giustina [ 02/Dec/09 ]

More precise: also the "xsi" namespace could be needed, so this is the full declaration we should allow:

<sv:node xmlns:sv="http://www.jcp.org/jcr/sv/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
Comment by Fabrizio Giustina [ 03/Dec/09 ]

Since we discovered that the list of needed namespaces is fixed and limited to "sv" and "xsi" I assume there is no reason to not commit the patch.
I've changed the list of allowed namespaces and committed to svn for release 4.2.2.

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