|
|
History
| Log In
|
|
|
|
I have posted a temporary workaround on the Confluence page for this plugin (here
 ). I'm working on a more permanent solution. Thank you for trying to find a workaround. I have attempted the work around, but it failed. I have upgraded to Confluence 2.5.2. I then followed the instructions for replacing WEB-INF/classes/xwork.xml, but Confluence fails to work at all after restarting. I have attached the java exception that displays. I can attach other logs if they are useful.
Java exception displayed when browsing to Confluence after attempting to replace xwork.xml.
I had the workaround xwork.xml applied by our hosting provider, Contegix. The workaround failed to load. After receiving their feedback, I re-enabled the Scaffolding plugin and the data entry edit mode now works (!!??) However other macros appear to be disabled and the themes for our spaces have been reset. Also, I did receive an error message after entering data in one page with a scaffolding macro, but haven't done further testing yet. Will have to sort all this out later today. The Contegix feedback is below:
Jim, Let me know if you have any questions. Thanks. > 2007-05-25 01:08:28.345637500 2007-05-24 23:08:28,334 INFO [main] Ok, haven't tested it, but from the error I'm guessing it doesn't like the <![CDATA[ ]]> sections I used to comment out the old code. I'll do an update tomorrow when I can, but in the meantime, search for 'SCAFFOLD' and remove the CDATA sections. Sorry about the hassle...
The change to xwork.xml, removing the CDATA sections, worked perfectly. I am now running on Java 5 with scaffolds working. I look forward to the permanent fix. Incidentally, I noticed that I don't have to disable and renable the scaffold plugin after restarting Confluence in order to have reporting of scaffold data working.
Glad to hear it's up and running. I'll keep you posted on progress with a permanent fix.
With regards to the disable/enable not being required, I got that one fixed in the last release of Reporting/Scaffolding this issue cropped up when we migrated from the standalong (tomcat) version of confluence (2.3.3) to run under websphere 6.1, (and therefore moving from Sun jdk to IBM JDK 1.5). we have version 2.3-dr4 of scaffolding installed.
We applied the workaround xwork.xml file, which solved the problem with the edit tab. however, we are now seeing the following in the log at startup: 2007-07-08 00:30:58,822 ERROR [server.startup : 0] [xwork.config.providers.XmlConfigurationProvider] addAction Action class [net.customware.confluence.plugin.scaffolding.actions.RedirectEditAction] not found, skipping action [editpage] <action name="editpage" class="net.customware.confluence.plugin.scaffolding.actions.RedirectEditAction" method="doDefault"> ...which is changed from the following in the old xwork.xml file: <action name="editpage" class="com.atlassian.confluence.pages.actions.EditPageAction" method="doDefault"> ...any updates on a permanent fix than "doesn't involve hacking Confluence"? thanks! With confluence 2.5.4 the xwork.xml modification works with Sun JDK 1.5.0_12 and Tomcat 5.5.23.
When starting confluence there is several errors due to scaffold classes not found in catalina.out, but the plugin and editing actually works. ERROR [main] [xwork.config.providers.XmlConfigurationProvider] addAction Action class [net.customware.confluence.plugin.scaffolding.actions.RedirectEditAction] not found, skipping action [editpage] java.lang.ClassNotFoundException: net.customware.confluence.plugin.scaffolding.actions.RedirectEditAction As per the note above, I got the workaround to work on 2.5.4, though I cheated and used the diffs in the note before that.
However, a problem arose that, due to production status of the server, I didn't get to diagnose fully before backing out the change. After a while of running with the workaround in, the logs started showing database connection errors, which seemed to be related to Tomcat having been thread-starved. At the time that we restarted Tomcat to fix it, there were 109 active threads belonging to Confluence that were much older than the current Confluence session. So, while the workaround works, we don't dare run it because of this problem, so we're waiting until the fix for this bug is available. Is there any way to get an estimate on this? About two weeks ago David Chui mentioned that he thought it would be "at least a couple of weeks" before it was done, but the report on the projected fix version looks much more pessimistic than that, even today. I've attempted this fix on my Confluence 2.5.4 instance. It works, however I (as confluence-administrator) seem to be the only person able to create and edit pages. None of the permissions have changed in any configuration however.
Anyone else is given a "Permission Denied" error and is not even given the Edit page screen. I've attached the diff between the "fix" xwork.xml, and the 2.5.4 standard xwork.xml. I have a scheduled an upgrade to 2.5.5 next tuesday night. If there are changes to the xwork.xml in that upgrade, I will post those as well. See same behavior on 2.5.4 as Jeff Heinen. Only "confluence-administrator" group members can add pages. Has anyone got this working on 2.5.4 and if so, could they provide the correct xwork.xml file?
This isn't a problem with the xwork configuration. It seems to be an unrelated issue, but one which I haven't been able to track down yet. Partly, I'm unsure exactly which action is denying permission.
We are still confirming the problem, but I believe the issue is that Atlassian changed one configuration in the xworks.xml file between 2.5.2 and 2.5.4, which is causing the failure if you simply substitute the xworks.xml file referenced at http://www.customware.net/repository/display/AtlassianPlugins/Scaffolding+Plugin
called xworks-.2.5.2.xml. Appears that the following line is being inadvertently replaced:
2.5.4: <action name="createpage" class="com.atlassian.confluence.pages.actions.CreatePageEntryAction" method="doDefault"> Hmm. Interesting. I hadn't actually checked if the xwork was changing in later versions of Confluence. Thanks for the tip - I'll work on confirming that and working it into the more permanent solution.
All will be glad to hear that a solution has been found to remove the need to manually modify xwork.xml any more. From 2.3-dr7 you will be able to simply install the plugin again.
If you have applied any xwork.xml changes manually, it would probably be best to revert them to their original state before installing 2.3-dr7. This is really good news!
Do you have any idea of when dr7 will be available? Hello. I'm seeing this issue with a fresh install of Confluence 2.7.2. Have you made any further headway with this issue?
What version of Scaffolding are you using Tony? As far as I know this issue has been resolved.
The error reported is 'CannotFindClass'. I can't think of any good reasons why that would be the error message, unless there is actually a different exception being triggered by something else, which then results in a 'cannot find' exception in the plugin class loader.
A possibility is that a bad jar was installed into the your copy of Confluence. Have you tried uninstalling, restarting Confluence and reinstalling? If the version from the plugin repository doesn't work, try downloading the jar manually and uploading it. The last thing is that I'm assuming you didn't install it by putting it in WEB-INF/lib. That definitely won't work - you need to install via the Plugin admin console or Plugin repository. It's a very odd error message... |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Blocker
Scaffold edit page no longer displays
I'm working on it and will update when I come up with something...