search

TWCable / grabbit

Grabbit - Fast Content Sync tool for AEM/CQ
Apache License 2.0
125 stars 64 forks source link

namespace sync conundrum #196

Open himmelmrm opened 6 years ago

himmelmrm commented 6 years ago

AEM 6.1 grabbit 7.1.1

I have two AEM 6.1 systems that unfortunately have a namespace conflict. The same URI is associated with different prefixes.

Does it make any sense to add an option to make namespace sync optional in the configuration file? Please be gentle - I'm not a developer :-)

Interesting note - I was expecting (hoping?) that package installation would fail due to the namespace conflict but it didn't. Installing a content package that contains this type of namespace conflict results in the prefix changing to the one already defined on the receiving system. Prior to using grabbit we were transferring content with packages. It wasn't until we started using grabbit that we noticed a namespace conflict.

jbornemann commented 6 years ago

It's an interesting scenario. It's likely the URIs provide the same definition for the time being. This is probably the only scenario where an optional namespace sync would bare fruit - typically, if there was a mismatch with mismatched definitions, or a missing namespace - nodes/properties would fail to write (in, and outside of Grabbit).

I would say, I'd probably look to keep the namespace prefix URIs consistent so that it doesn't bite later on.

himmelmrm commented 6 years ago

To clarify - in this scenario, the grabbit transfer DOES fail with error "OakName0001: Invalid namespace prefix".

In my opinion it would be much better if the package installation also failed, but it doesn't -- installing the same exact content via package succeeds. The namespace conflict seems to be automagically resolved during package installation by changing the conflicting prefix to the prefix with the same URI that already exists. Replication also behaves this same way.

Agree 100% about keeping namespace consistent -- unfortunately we are using grabbit to sync with a different service provider's AEM that we don't control.

sagarsane commented 6 years ago

Hi @himmelmrm - its weird that you are getting an exception when doing this. There is a bit in the code for this scenario to "ignore" those cases where "mapping for incoming prefix already exists".

https://github.com/TWCable/grabbit/blob/master/src/main/groovy/com/twcable/grabbit/client/batch/steps/namespace/NamespaceSyncTasklet.groovy#L88-L95

As you can see, Grabbit is explicitly checking for that case. Also, the NamespaceHelper that the code relies on is supposed to automatically do the same thing that the Package Manager does. I am wondering whether something has changed in Oak for AEM 6.1 that is may be throwing a different exception in this case.

If possible, could you provide some more information of the stacktrace you are getting? I am wondering whether the invalid namespace prefix error is due to a different issue.

Making the namespace sync optional is not too hard, I am wondering if its really necessary, or should we update the code to handle this scenario better.

cc @jbornemann

himmelmrm commented 6 years ago

The namespace sync occurs at the start of the job: 28.11.2017 11:38:35.624 INFO [clientJobLauncherTaskExecutor-3] com.twcable.grabbit.client.batch.steps.namespace.NamespaceSyncTasklet Start writing namespaces. 28.11.2017 11:38:35.635 INFO [clientJobLauncherTaskExecutor-3] com.twcable.grabbit.client.batch.steps.namespace.NamespaceSyncTasklet Finished writing namespaces.

... when the sync job reaches the first node that has the conflicting namespace, the attached stacktrace is logged and the job terminates with a status of FAILED. grabbit-stacktrace.txt