[MAGNOLIA-1000] Export (mgnl-export) from the root path (mgnlPath=/) fails Created: 14/Aug/06 Updated: 19/Apr/13 Resolved: 20/Sep/06 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | None |
| Affects Version/s: | 3.0 RC2 |
| Fix Version/s: | 3.0 RC3 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Anne-Marie Scheidegger | Assignee: | Sameer Charles |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| 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 |
|
When I try to export (with the mgnl-export servlet) from the root path (mgnlPath=/), it fails with the following exception: 2006-08-07 15:51:08 StandardWrapperValve[ImportExportServlet]: Servlet.service() for servlet ImportExportServlet threw exception [..., let me know if you think the rest of the stack might be interesting to look at] When I specify a directory for the mgnlPath argument, it works. It seems that it gets confused about where its root is, because the tomcat.log is also littered with the following error message: INFO | jvm 1 | 2006/07/15 20:42:50 | ERROR info.magnolia.context.MgnlContext MgnlContext.java(getInstance:291) 15.07.2006 20:42:50 Context is not set, defaulting to System Context |
| Comments |
| Comment by Anne-Marie Scheidegger [ 14/Aug/06 ] |
|
See |
| Comment by Philipp Bracher [ 17/Aug/06 ] |
|
I think this hasn't to do with the root, since such an export works for me. But we got this problem when we exported pages which contained binaries. Sometimes (not every binary is making such problems) We got exactely the same exception here. As a workaround we were able to download the binary, removed it from the page and upploaded it again. We need to do some investigations. The problem is that it is hard to debug, since we can not export such the content If someone has such a not exportable page I would like to get his repository as a tar gz so that we can debug it properly. |
| Comment by Sean McMains [ 17/Aug/06 ] |
|
We're also experiencing this issue, both on Mac OS X and on Fedora. It occurs with any of the repositories, not just the "website" repository. The export works beautifully (even with funky binary files) if you specify a deeper-level path, but using "/" inevitably triggers the error. |
| Comment by Philipp Bracher [ 18/Aug/06 ] |
|
The / is very special in the sense that it really exports everything (including jcr:system and version space). We filter that, but never else it is processed by the SAX event handler. Therefore I would say the export of the root is not the problem but the propability that you ran in such a scenario increases a lot. As I said, I'm able to export the root here without any problems. It is also wrong to say that binaries are producing this exception, but if it happens there was always a binary involved. Never else, I got such a page by Ralf and will have a look at it. |
| Comment by Sean McMains [ 07/Sep/06 ] |
|
Any word on this? I would argue that this should be a higher priority than "minor", since it prevents doing complete backups on a running Magnolia system. |
| Comment by Boris Kraft [ 07/Sep/06 ] |
|
Can you provide a reproducable data set that triggers that behaviour? Without that, raising the prio makes little sense. |
| Comment by Sean McMains [ 08/Sep/06 ] |
|
Sure thing; I just reproduced it on a clean install: 1. Download from http://superb-west.dl.sourceforge.net/sourceforge/magnolia/magnolia-3.0-rc2_with_tomcat.tar.gz |
| Comment by Sean McMains [ 08/Sep/06 ] |
|
Interestingly, I don't see this problem on our new system we're using BDB on instead of Derby, so it may have something to do with the persistence manager. |
| Comment by Boris Kraft [ 08/Sep/06 ] |
|
Thanks. So we have a workaround it seems. Good start. (I can leave the prio low then, I hope thats ok with you - you can always vote, too) |
| Comment by Sean McMains [ 19/Sep/06 ] |
|
We're seeing this with BDB now too, leaving our production system without a way to back it up. |
| Comment by Sameer Charles [ 20/Sep/06 ] |
|
Its a problem in magnolia versioning, we searialize some objects in to mgnlVersion store which creates problems on root export. |
| Comment by Sameer Charles [ 20/Sep/06 ] |
|
Changed the implementation to keep Rule as encoded (valid xml) string. Please note that if you already have old versions in your repository you need to clean those either by For freshly build magnolia instance you should be able to version and export root at any time. |
| Comment by Ralf Hirning [ 29/Sep/06 ] |
|
Did anyone of you ever tried to import a root-export? For me it did not work. So now you can export a repository from root, but is is worthless. On trying to import I get the following exception: ERROR info.magnolia.cms.servlets.MVCServletHandlerImpl 29.09.2006 09:09:57 – can't call command: importxml |
| Comment by Philipp Bracher [ 29/Sep/06 ] |
|
It was definitely working once. Can you import your file into a subnode? |