[MAGNOLIA-1394] New paragraph don't "see" new dialogs without reloading the dialogs Created: 21/Feb/07  Updated: 23/Jan/13  Resolved: 10/Dec/07

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 3.0.1
Fix Version/s: 3.5

Type: Bug Priority: Major
Reporter: Giancarlo Berner Assignee: Magnolia International
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac OS X, Tomcat 5, Firefox 2


Attachments: JPEG File dialog_error.jpg    
Issue Links:
relation
is related to MAGNOLIA-1972 Can't have a dialog without an associ... Closed
supersession
is superseded by MAGNOLIA-1941 Simplify registration / retrieval of ... Closed
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   
  • Install two different Magnolia Instances
    It is a little annoying if you have to restart Tomcat whenever you add NEW dialogs.
  • Create a package with the Packager tool on one instance
  • The package must contain dialogs which are not in the other instance
  • Install package with new dialogs on other instance
  • Click New bar on other instance and select new paragraph with new dialog
  • ERROR: no dialog registered for name: {new dialog name}
  • Click Tools/Deploy and re-deploy
  • Click New bar on other instance and select new paragraph with new dialog
  • ERROR: same error again
  • Restart Tomcat
  • Click New bar on other instance and select new paragraph with new dialog
  • Everything is fine


 Comments   
Comment by Magnolia International [ 21/Feb/07 ]

so that's only the case when using the packager ?

Comment by Giancarlo Berner [ 21/Feb/07 ]

In earlier Magnolia EE RC I used to experience the same issue. I though don't know how it is today.
I wonder if there is a difference between COPYING a dialog and CREATING the dialog from scratch.

Comment by Philipp Bracher [ 06/Mar/07 ]

In case the dialogs node was existing during the startup, the newly defined dialogs should be reloaded.

Comment by Philipp Bracher [ 06/Mar/07 ]

Make sure that the dialogs node is not part of your package

Comment by Simon Goodchild [ 06/Mar/07 ]

I always get this behaviour when adding new dialogs, wherever I have defined them (including the main dialogs node that AdminCentral provides a shortcut link to), so the problem is not just limited to modules. I find that I always need to restart for them to become available which is a pain.

Is it the case then that these new dialogs should be picked up by the system? If so then there's definitely a bug somewhere. If not then a (hopefully) quick workaround would be if there was an option to force a reload of all the template and dialog definitions, basically calling whatever routine is used at start-up. Then we can achieve the same effect as restarting the servlet engine without impacting any other applications running in it.

Comment by Giancarlo Berner [ 07/Mar/07 ]

I noticed this issues only with packages. However, the packager is an important tool to move or backup development work.

If I add a dialog node-by-node, the dialog is recognized. If I copy an existing dialog, I often can not even rename the folder name anymore. If I test without renaming, the dialog is not recognized.

I agree with Simon, there must be something weird with dialogs.

Please re-evaluate this entry.

Thanks!

Comment by Simon Goodchild [ 07/Mar/07 ]

I think Giancarlo may have narrowed down where the problem is, as I normally create new dialogs by copying an existing node and then changing the entries. So maybe creating new dialogs from scratch triggers the reload behaviour, but copying does not. Not sure if it's to do with node IDs being duplicated and making Magnolia think the dialogs are already loaded?

Comment by Philipp Bracher [ 08/Mar/07 ]

needs to be checked

Comment by Karl Krukow [ 28/Mar/07 ]

Two comments:

  • I can reproduce this problem without any packages.
  • I get a similar but "reverse" problem: dialogs and paragraphs persist even if their ids/names are changed.

To reproduce bug: ( I am running Magnolia EE v. 3.0.2 on windows xp)

  • create a template, say MyHelloWorld, and a corresponding jsp-script which references a paragraph: myPageParagraph

(/Example:
<%@ taglib uri="cms-taglib" prefix="cms" %>
<html>
<head><title><cms:out nodeDataName="title" /></title></head>
<body>
<cms:mainBar
paragraph="myPageParagraph"
label="Label Page Properties"
adminButtonVisible="true"/>
Hello Magnolia World!
</body>
</html>
/Example)

  • Create a dialog: under myProject/myHelloWorldPageProperties
    (in my example this is just a copy of the sitedesigner "pageProperties")
  • Create a paragraph: under myProject/myPageParagraph including properties:
  • name=myPageParagraph
  • dialogPath=myProject/myHelloWorldPageProperties

Now in my setup, if I create a web-page using this template and I click the Properties button, I get the same problem:

info.magnolia.cms.beans.config.ConfigurationException: no dialog registered for name: myPageParagraph

However, there is more: If I restart, it works, BUT supposing that I now change the dialogPath from myProject/myHelloWorldPageProperties to myProject/InvalidReference (or any other that is not defined) it still works: If I refresh the browser and click the button I get the dialog. So it seems that the changes are not "flushed".

There is a workaround: if I 'Activate' the paragraph and the dialog, I (correctly) get the ConfigurationException.

Regards,

  • Karl
Comment by Magnolia International [ 17/May/07 ]

We should check this from 3.1
Apparently people have this issue with page templates etc...

Comment by Magnolia International [ 22/Nov/07 ]

Will try to check for rc2 ...

Comment by Magnolia International [ 10/Dec/07 ]

Could indeed reproduce the issue, for dialogs that don't have the same name as their paragraphs. One could work around the issue by forcing a reload of the dialogs (i.e editing any dialog). Fixed for 3.5.

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