In January, I wrote about setting up a dual-AMP project for developing an extension with both Share and repository AMPs for Alfresco. Back then, the integration test goals targeted deployment to a Jetty container. Now that the 1.1.0 Maven Alfresco SDK has been released with support for Alfresco 4.2, the integration-test goal has been retargeted to Tomcat 7. This makes it a bit heftier, but easier to set up. Follow the instructions as before, but replace the Jetty port configuration step for Share to a simple pom.xml update, adding the following property:
<properties> <maven.tomcat.port>8081</maven.tomcat.port> ... </properties>
This will allow you to run the Share app on 8081 and still start the repository server on the default 8080 port.
Originally published at craftersoftware.com.
Earlier this month I attended a training course for Crafter CMS, the open-source web content management system. In this post, I discuss my motivations for taking the training, highlights, and my impressions.
If you're using Alfresco Enterprise 4.0 and above, you're probably familiar with the Node Templates feature which allows you to place files in the Repository under "Data Dictionary/Node Templates" and have them appear as options in your "Create Content..." menu in Share.
Two clients have asked for this capability with respect to folders. For example, a templated folder would allow users to create a pre-defined set of content, rather than having to create the folder structure manually and then populate it with items from the Node Templates directory. After doing a bit of research, it appears it's been on the docket for inclusion in community but isn't high priority. I took a stab at getting this to work in Enterprise 4.1.5, and the solution appears to be relatively straightforward.
Alfresco Enterprise 4.1.4 was released on Thursday, bringing with it a slew of security and stability fixes. One such fix protects against cross-site request forgeries (CSRF). A CSRF attack is one in which malicious code pretends to be an authenticated user by piggy-backing on the trust granted to the user's browser, then performing requests as that user.
If you've built a custom application based on the Alfresco platform and are performing POST requests against either Share- or repository-tier webscripts, you may encounter problems after upgrading to 4.1.4 due to this fix. In this post, I will explain how to update your application to work with this fix.
Edit: Here is an official blog post on the new CSRFPolicy.
Laura, Michael and I have been banging our heads against this one for a few hours: The webpreview in Alfresco 4.1.2 Enterprise Share wasn't working, giving us an annoying error that read, "The preview could not be loaded from the server." On top of that, there were no exceptions in the Tomcat log.
On Wednesday I wrote about downsizing the monolithic project created from the Alfresco All-in-One Maven SDK archetype. My goal was to end up with a project that would only build and deploy the Alfresco repository AMP and Share JAR. After discussing with Gab Columbro, he suggested a more efficient solution of combining two AMP projects created from the AMP archetype. This ended up not only being easier to configure but the deployment process is faster and there is the added bonus of separating the repository and Share containers, which is a development best practice.
The all-in-one archetype generates a project with a buffet of extension projects for a repository AMP, a Share JAR, an Alfresco overlay, a Solr configuration, and a Web Quick Start deployment. I don't need all of these but none of the other archetypes offer what I consider the minimum projects: the repo AMP and the Share JAR. By using the all-in-one, I can pare it down to what I need and configure the resulting project for my system (Mac OS X Mountain Lion). I fully expect that this type of archetype will become available in the future, but in the meantime, here are the steps I'm taking to fit the project to my needs.
CMIS, which stands for Content Management Interoperability Services, is a standard that describes what you can do with items in a content management system. This includes actions like searching, querying metadata, updating or deleting content, and so on. It's an extension to AtomPub, meaning you perform these operations by posting XML-based requests to HTTP endpoints, which Alfresco provides via webscripts in versions 3.3 and higher.
Alfresco uses SWFTools -- specifically, "pdf2swf" -- to generate Shockwave renditions of PDF documents for document previews. If you're using HomeBrew to manage packages, and you run the following command, you might run into some problems:
$ brew install -v swftools
Namely, the "pdf2swf" command (among others) will not be installed due to some missing dependencies. This is most noticable when installing SWFTools on a clean system. To fix this, install the following packages prior to attempting the above command:
$ brew install freetype libjpeg giflib swftools
This should result in a clean build of SWFTools with the pdf2swf command available in your path and for use with Alfresco.
Last week I spent several hours automating the creation of an Alfresco development environment using bash scripts--copying sample project files, customizing Ant scripts and properties, creating databases, etc. While taking a break and surfing the web, I read several recommendations for Apache Maven. A few years have passed since I last touched Maven and I remembered it being pretty easy to use. I also remembered some chatter in Alfresco circles about an official Maven repository for Alfresco, so I decided to dig a little deeper to see if Maven could help me out. I was unprepared for just how slick--and fun!--it would end up being.