[MAGNOLIA-554] exception in Config/modules/templating/Templates Created: 22/Sep/05 Updated: 23/Jan/13 Resolved: 17/May/06 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | admininterface |
| Affects Version/s: | 2.1 Final |
| Fix Version/s: | 3.0 RC1 |
| Type: | Bug | Priority: | Major |
| Reporter: | Alexandru Popescu | Assignee: | Philipp Bärfuss |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Magnolia 2.1 with Tomcat bundle |
||
| Attachments: |
|
| 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 |
|
Trying to understand how I can create a new template (and more deeper how I can bind info to Scenario: 1/ login as superuser My env: Exception stacktrace: INFO info.magnolia.cms.beans.config.Template Template.java(update:95) 19.09.20 at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:16 By looking at the trace it seems like it has tryied to push the modification to the public instance, |
| Comments |
| Comment by Alexandru Popescu [ 22/Sep/05 ] |
|
More details can be found on the thread: http://thread.gmane.org/gmane.comp.cms.magnolia.devel/3889 |
| Comment by Alexandru Popescu [ 02/Oct/05 ] |
|
It seems that the correct behavior/implementation is done for "folders" created under /Config/modules/templating/dialogs. The above scenario repeated here doesn't result in an exception. From the log it seems that here the operation is "move" node from untitled to new_name; while in the exception case the operation is "remove" untitled node. |
| Comment by Alexandru Popescu [ 02/Oct/05 ] |
|
Same as above is true for Content Nodes. So the only failing scenario is the New Node Data + set Node Data name (an additional remove operation is done for the */untitled Node Data). |
| Comment by Alexandru Popescu [ 04/Oct/05 ] |
|
This patch is solving the issue and also is changing the behavior according to the previous mentioned discussion: 1/ a new "untitled" node is not immediately saved; it will be saved only when he is named (so on renameNode) |
| Comment by Alexandru Popescu [ 05/Oct/05 ] |
|
I was asked how the patch is behaving in the following scenario: 1/ a new page is created (=> page is "untitled") Considering that a save triggers a Session.save() any nodes in transient state are saved, the same happens to the untitle page. The author will not loose his work. In fact considering the above Session.save() any other action that will trigger the mentioned Session.save() will save also the "untitled" node. |
| Comment by Sameer Charles [ 05/Oct/05 ] |
|
updated on current trunk |
| Comment by Philipp Bracher [ 06/Oct/05 ] |
|
Warning: Is this realy the wanted solution for this problem. We discussed it here once and my favorite solutions was:
I think we should not start to add temporary nodes to the session. From where should a user know that this node will magically disappear after opening a new browser? This is confusing. If there are no other strong pros I would like to remove the patch. |
| Comment by Sameer Charles [ 06/Oct/05 ] |
|
When we will move to different gui this will change anyways, I prefer if we can have a separate dialog to create a page and persist it when for another issue where it raised an exception on rename - I overlooked the path because it did not really solve the problem |
| Comment by Alexandru Popescu [ 06/Oct/05 ] |
|
Philipp as described in the previous comments the patch is solving one problem and as an addition creates this behavior. I would strongly recommend at least the preservation of the part solving the issue. ./alex |
| Comment by Alexandru Popescu [ 06/Oct/05 ] |
|
About Sameer comment: indeed should check about the previous/source path (if the source path was ever activated). But it looks like there is no way to have this information. ./alex |
| Comment by Alexandru Popescu [ 06/Oct/05 ] |
|
What would probably solve this is my enhancement request for adding state (and maybe more) to ContentHandler. (see http://webmail.magnolia.info/Lists/dev-list/Message/4544.html) ./alex |
| Comment by Sameer Charles [ 06/Oct/05 ] |
|
This is a problem the way GUI handles creation of new nodes, we sould not try patch it in core The patch from Alex solved this problem by keeping a node in transient state upless something added to it or renamed. If we can do it that's perfect, if not. Lets keep the way it is at the moment.
|
| Comment by Alexandru Popescu [ 06/Oct/05 ] |
|
Sameer maybe you can change its state from Resolved to something else, just to be assured that we will revisit it later. my 2c, ./alex |
| Comment by Philipp Bracher [ 06/Oct/05 ] |
|
reopened |
| Comment by Philipp Bracher [ 20/Oct/05 ] |
|
I removed the patch since the patch for 582 solves this too. Still we have the following exceptions. WARN org.apache.jackrabbit.core.observation.ObservationManagerFactory Observat This is thrown because the reloading of the Templates fails |
| Comment by Philipp Bracher [ 17/May/06 ] |
|
The reloading in the ObservedManager should take care about missing (moved) nodes. |