[MAGNOLIA-3189] "NoSuchNodetypeException" in RecieveFilter when activating already published nodes for a separate repository Created: 03/May/10  Updated: 23/Jan/13  Resolved: 03/May/10

Status: Closed
Project: Magnolia
Component/s: activation, core
Affects Version/s: 4.3.1
Fix Version/s: 4.3.2

Type: Bug Priority: Major
Reporter: Manuel Molaschi Assignee: Manuel Molaschi
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File ModuleManagerImpl.patch     Text File stacktrace.txt    
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   

We have two jcr repositories, the default one and a repository for media(with custom nodetypes). I am publishing some medias (custom nodetype) from the author instance of a staging env (in the separated jcr repository) to the author instance of a production env.
When i publish new contents everything goes fine, but when i publish modified contents i get an exception on the destination server:
[gest-srv] ERROR 03.05.2010 12:44:06 info.magnolia.module.exchangesimple.ReceiveFilter ReceiveFilter.java(importOnExisting:444) – Exception caught
{{javax.jcr.nodetype.NoSuchNodeTypeException:

{http://www.magnolia.info/jcr/mgnl}

media}}

Looking at source code, there is a temporary import to the mgnlSystem workspace that resides in the default repository which have not the custom nodetypes declarations (registered in the media repository).
Possible solutions?

  • getting the SystemContext hierarchyManager for the destination workspace instead of mgnlSystem
  • have a mgnlSystem ws in every repository mapped as mgnlSystem[repository name]
  • register custom nodetypes also on default repository


 Comments   
Comment by Jan Haderka [ 03/May/10 ]

When a node type is registered it is registered for all workspaces including the mgnlSystem. The problem is usually the fact that you did not register the nodetype on the receiving instance. This is typically done in data module by activating the type itself. In case your type is already properly registered and you can create manually items of given type on the receiving instance, please attach the complete stacktrace.

Comment by Manuel Molaschi [ 03/May/10 ]

Our module definition file declares repositories as follows

  <repositories>
    <repository>
      <name>magnolia</name>
      <workspaces>
        <workspace>media</workspace>
      </workspaces>
      <nodeTypeFile>/mgnl-nodetypes/media/magnolia-nodetypes.xml</nodeTypeFile>
    </repository>
    <repository>
      <name>magnolia</name>
      <workspaces>
        <workspace>playlists</workspace>
      </workspaces>
      <nodeTypeFile>/mgnl-nodetypes/media/magnolia-nodetypes-playlist.xml</nodeTypeFile>
    </repository>
  </repositories>

Repository mapping is overidden by custom repositories.xml in which:

<Repository name="shared" provider="info.magnolia.jackrabbit.ProviderImpl" loadOnStartup="true">
        <param name="configFile" value="${magnolia.repositories.jackrabbit.shared.config}" />
        <param name="repositoryHome" value="${magnolia.repositories.home}/shared" />
        <param name="contextFactoryClass" value="org.apache.jackrabbit.core.jndi.provider.DummyInitialContextFactory" />
        <param name="providerURL" value="localhost" />
        <param name="bindName" value="${magnolia.webapp}-shared" />
        <workspace name="media" />
        <workspace name="playlists" />
    </Repository>

In the class ModuleManagerImpl:

method loadModulesRepositories:

            for (final RepositoryDefinition repDef : def.getRepositories()) {
                final String repositoryName = repDef.getName();

                final String nodetypeFile = repDef.getNodeTypeFile();

                final List<String> wsList = repDef.getWorkspaces();
                String[] workSpaces = wsList.toArray(new String[wsList.size()]);

                loadRepository(repositoryName, nodetypeFile, workSpaces);
            }

calls loadRepository for each repository (media, playlists) in module definition xml.

method loadRepository:

        if (nodeTypeFile != null) {
            // register nodetypes
            Provider provider = ContentRepository.getRepositoryProvider(repositoryName);
            try {
                provider.registerNodeTypes(nodeTypeFile);
            }
            catch (RepositoryException e) {
                log.error(e.getMessage(), e);
            }
        }

registers nodetypes just for declared repositories (repository shared)

Comment by Jan Haderka [ 03/May/10 ]

Thanks for the detailed description. I've moved your stacktrace to the attachment to improve the readability of the issue.
Indeed the use case involving multiple repositories is not covered by activation. And actually same issue would occur if/when you try to version the content in question since that involves copy to mgnlVersion workspace that is not in your shared repository either.

Since we can't change the code to avoid usage of mgnl* workspaces in the short term, probably best solution would be to change the code related to registering the node types to make sure, types are always registered in the repository in which given workspace exists as well as in the default (magnolia) repository where system mgnl* workspaces exist.

Comment by Manuel Molaschi [ 03/May/10 ]

Here is a little patch that registers nodeType also on default repository

Comment by Jan Haderka [ 03/May/10 ]

Looks good to me. Why don't you apply it on the trunk? You guys have already svn credentials no?

Comment by Manuel Molaschi [ 03/May/10 ]

Yes i have. i'm going to commit it.

Comment by Manuel Molaschi [ 03/May/10 ]

Resolved by always registering nodeType for the default repository ("magnolia")

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