Everyone who has spent more than 10 minutes with Alfresco is familiar with Alfresco’s Admin Console. The node browser is an invaluable tool for troubleshooting, but it is conspicuously located as a link on the Admin Console. There are a few other consoles that you can use to help troubleshoot or manage the repository, but you have to know where to look.
What: Workflow Console
Where: http://localhost:8080/alfresco/faces/jsp/admin/workflow-console.jsp
Use: Deploy, un-deploy, and delete workflows. Inspect workflow metadata. Complete a task that’s become stuck for some reason.
What: AVM Console
Where: http://localhost:8080/alfresco/faces/jsp/admin/avm-console.jsp
Use: List stores, create stores, delete stores, create directories and branches, create snapshots, create new nodes. Basically your one-stop shop for working with the AVM Store. If one model is ever chosen over the other, it is likely to be the AVM Store, so this is tool will become even more useful in the future.
2.9 Community adds a couple of new consoles…
What: Repository Admin Console
Where: http://localhost:8080/alfresco/faces/jsp/admin/repoadmin-console.jsp
Use: Deploy, activate, and de-activate content models. If you are using dynamic data models, you’ll need this. See http://wiki.alfresco.com/wiki/Dynamic_Models for more details.
What: Web Client Config Console
Where: http://localhost:8080/alfresco/faces/jsp/admin/webclientconfig-console.jsp
Use: Reload the web client configuration. Handy when placing web-client-config-custom.xml in the repository rather on the file system. See http://wiki.alfresco.com/wiki/Dynamic_Models for more details.
Consoles are certainly helpful, but log files and debuggers are also essential. Tweak log4j.properties by setting various loggers to “debug” depending on where it is you are having trouble. The log4j.properties file resides in <ALFRESCO WEB ROOT>/WEB-INF/classes. For JavaScript specifically, there’s a Rhino JavaScript Debugger you can enable, but I haven’t found much use for it. In any case, to turn it on, in log4j.properties, change this logger to “on”:
log4j.logger.org.alfresco.repo.jscript.AlfrescoRhinoScriptDebugger=off
Last, connecting the Eclipse debugger to your running instance of Tomcat is often very helpful. It allows you to step through Alfresco source code to your heart’s content. (Try that with Sharepoint!) There are a few ways to do this, but the way I do it is:
- Set an environment variable called JPDA_ADDRESS to 8000 and one called JPDA_TRANSPORT to dt_socket.
- Change the last line of Tomcat’s startup.sh to look like: exec “$PRGDIR”/”$EXECUTABLE” jpda start “$@”
- Create and start a new Remote Java Application configuration in the Eclipse Debug dialog.
- Set some breakpoints, hit the web client with a web browser and get to stepping.
With the help of the consoles, the logs, and the source, you’ll be successfully hacking Alfresco in no time.
The javascript debugger can also be enabled through one of the webscripts. I’m still trying to figure out what it’s useful for. I’d like to be able to debug my webscripts with a live debugger.
The JavaScript debugger is very useful. Rather than enable it through a web script, I enable it through log4j.properties:
https://ecmarchitect.com/archives/2008/12/09/871
You can use it to debug any server-side JavaScript running in Alfresco. That includes:
– Web Scripts (both repository tier and Surf tier)
– JavaScript inside a jBPM workflow
– JavaScript executed through an “execute script” action
– JavaScript-based actions
Being able to step back-and-forth through sometimes significant amounts of JavaScript is definitely a productivity booster.
Hi,
You mention the JavaScript debugger and how to enable it, but can you please go futher. Where does the output from the debugger go? How do you look at it?
Thanks
Francois
Francois,
Enabling the Rhino JavaScript debugger will cause a Java swing app to launch when the server starts up. Obviously, this will only work when you are running the app server on a box with a GUI (or are otherwise redirecting the graphical output to a terminal somewhere).
Once the GUI launches, it will look very familiar to you if you’ve ever used a stepping debugger of any kind. You can use it to set breakpoints, dump variable values, and step through code.
I should add that at the time I wrote that blog post, I hadn’t used the Rhino debugger very much, but as web scripts moved from Java to JavaScript and as I started doing more with Surf and Share, it became a really useful tool.
Jeff
For some reason, the JavaScript debugger shows all lines of code on one line. It makes it impossible to step into or step over.
Depends on what you’re doing. For example, in Share, if you do nothing else, Share will use the minified JavaScript files. However, you can turn on debug in the Share custom config and that will force the expanded JavsScript files to be used, which are much easier to debug.
I haven’t seen the everything-on-one-line problem with repository tier JavaScript except for maybe Alfresco JavaScript in jBPM actions. In that case, not only is it hard to step through but a line comment (“//”) will end up commenting out all of the JavaScript that follows.
Jeff
For anyone looking for an easier way to develop Javascript for Alfresco I can recommend my Javascript Console extension that can be found in Share-Extras: http://code.google.com/p/share-extras/wiki/JavascriptConsole