[MAGNOLIA-999] custom namespaces Created: 11/Aug/06 Updated: 24/Jul/09 Resolved: 08/Feb/07 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | None |
| Affects Version/s: | 3.0 RC2 |
| Fix Version/s: | 3.1 M1 |
| Type: | Bug | Priority: | Major |
| Reporter: | Chris Miner | Assignee: | Philipp Bärfuss |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
linux |
||
| Issue Links: |
|
||||||||
| 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
|
||||||||
| Date of First Response: | |||||||||
| Description |
|
I set up a module with custom node types and found that my node types couldn't be registered because the name space prefix I used (also custom) was not known to the underlying repository. The exception is thrown from code called in AbstractModule.registerRepositories(ModuleDefinition). The problem is that at the time registerRepositories is called from AbstractModule.register(ModuleDefinition, Content, int), the module hasn't had a chance to register the namespaces potentially used in the custom node definitions. I wanted to fix this by overriding the register method, but it is final. I looked for another built in hook, and found I could only add code to my Module Constructor. I added: try { } catch (RepositoryException e) { registerRepositories itself would be another place to override the functionality but that is protected. While looking at the register code, I also thought it strange that bootstrapping (a step which may involve the newly defined data types) is done after the repositories are registered. |
| Comments |
| Comment by Chris Miner [ 29/Aug/06 ] |
|
Turns out my hack didn't work. It only appeared to work because I was not running against a fresh repository. Against a fresh repository this code in the constructor for my module executes too early. To get it closer to correct info.magnolia.cms.module.AbstractModule.register(ModuleDefinition, Content, int) would have to be changed. Currently it bootstraps before registering repositories, which I think precludes bootstrapping the contents of my modules repository. Even if the repository registration step preceeded the boostrapping it is still missing a step where the name spaces are registered. I think ModuleUtil.registerWorkspace or ModuleUtil.registerNodetypes might have the required info since it has access to the module specific nodetypes.xml file which contains xmlns statements regarding namespaces used. With my current hack, I can have namespaces, but no workspace boostrapping via the module. Another option would be to register my namespaces in onInit() and do the boostrappping there. But that seems also bad. Or I can do without boostrapped data. |
| Comment by Philipp Bracher [ 06/Sep/06 ] |
|
changed the title and scheduled for 3.1. There is currently no convinience way to do this. Never else I changed the order of registering repositories and the bootstrapping. So overriding registerRepositories() should solve the problem now. As we define the custom node type file we should allow the definition of the namespaces. This could get placed in the repositories.xml and should be configurable in the modules config file too. Until then you need to customize the module mechanism |
| Comment by Chris Miner [ 24/Oct/06 ] |
|
In case someone wants a workaround. Here's what I did: HierarchyManager hierarchyManager = ContentRepository.getHierarchyManager(ContentRepository.WEBSITE); Of course you need to add the error handling code. |
| Comment by Oliver Lietz [ 07/Feb/07 ] |
|
please see |
| Comment by Philipp Bracher [ 08/Feb/07 ] |
|
patches deliverd to the jira tasks mentioned before |