The storage configuration indeed allows you to specify "storages", that may be database or file system based, then bind item types and subtypes to a specific storage.
For file-system based storages you can indeed specify any path you want, as long as the deployer has enough permissions to write to and delete from that location.
Once you set up your ...
The override that expects a Component Presentation is just a wrapper for the one that expects the ids. For Instance this override expects a publicationId, componentId and componentTemplateId:
public void remove(int publicationId, int componentId, int componentTemplateId,
I will assume that what you mean with the Broker is the Tridion Broker database.
It is possible to publish everything to the file system, it includes, content, linking info, metadata and references, however this functionality is deprecated and will be removed in future releases, having said that, in future releases, linking, metadata and references will ...
Dynamic Linking is the big one as Rob mentions.
any DCPs embedded on Pages will render
Any code that queries CPs using Criteria/Query API will need to be gutted/replaced.
If you use P&P, then any personalized content will be rendered and filtered via User Controls/Tags, and this will need replacing
If you use UGC, same as #4.
When starting a ...
You can always try to access the package as described here using a deployer extension. Or if you want to stick to the Storage extension, you might be able to re-use the Utilities class provided in the link above and then use its getComponentPresentationsDocument method (or another method in such class) to access the package files and/or contents.
The point at which the storage of the item is committed is not at individual item level, but at DAOFactory level (JPADAOFactory or FSDAOFactory for DB/Filesystem). The reason for this is typically the publish transaction will store several items (page, metadata, binaries etc.) and the commit of the storage should be all items together. So in order to hook in ...
The ideal situation is to try to avoid having to invalidate items in Akamai and instead just rely on the normal expiration rules you have setup in your Akamai configuration to take care of content refresh.
For example, if you have static content that is going to change frequently, consider publishing it to a folder you can use as the basis of a customized ...
Your code looks really familiar ;) . If super.create() fails, then the super class throws an exception and the entire transaction is rolled back. If you throw an exception in your connectDB method, the entire transaction be rolled back as well. So, instead of doing an e.printStackTrace everywhere, you should throw the exception.
If that doesn't work, have a ...
Once you have added the "additional information" using Engine.PublishContext.RenderedItem.AddMetadata, you can use a Deployer Extension. Here is an example (framework) to deal with Deployer Extensions:
Custom Deployer Extensions Framework
On a side note, if what you need to do is to add more nodes to your xml, you can do it in the template as well, not ...
Indeed the com.tridion.storage.ComponentPresentation class was changed. The create, remove and update methods now receive the Component Presentation content as byte-array.
If you need the string contents, you can simple do:
public void create(
As you've realized, this cannot be achieved using templating. If you wish to do this this way, you will need to use a different extension point, namely ITransportPackageHandler.
See my TDS presentation for more information here.
But... why don't you do this on the CM side? Make use of the Event System and the SetPublishStateEventArgs class. This is only ...
The behavior is because of the way the storage layer function for Tridion Docs.
As we know in Tridion Docs only Publications can be published/unpublished. While publishing, the storage layer stores the Publication along with its items (Page => Topic + Template, Component Presentations => Topic + Template) individually so the create methods execute for ...
I assume your storage extension is called by the Deployer. Please specify.
When an existing DCP was re-published, the Deployer used to call a remove followed by a create. This was in an older version of Tridion (i.e. 2009 IIRC). I believe this is still the behaviour that you are seeing.
Could you check to see if instead of the update method, the methods ...
The best way to integrate with Akamai (or most CDNs in general) is to do absolutely nothing, and let Akamai crawl your "origin" servers on a regular basis.
If you really need the type of control that you seem to think you need, then a storage extension is the way to go. You could work on a deployer extension too, but then you'll have to deal with ...
Another approach would be to publish to two separate deployers, and to configure each differently.
My favourite approach is to use ASP.NET web applications as upload servers. If you configure these with suitably populated lib and config directories in the bin directory, you can have the each one treat its content totally differently.
Of course, if you ...
I would be vary wary of any approach that removes all Content Delivery functionality, or the ability to hook into it. Customers I have seen that take this approach due to whatever requirements, tend to become very dissatisfied in the long term. Usually they bought Tridion for the whole package of functionality, CM + CD.
Some typical issues are:
You might be able to achieve that using a CM Event handler for PublishTransaction Save (Initiated phase).
If the Publish Transaction state is set to Failed and you recognize your error/warning message in the deployment feedback XML (stored in PublishTransaction.Information), you could change the state to Warning.
JPA DOAs are used only for non-filesystem storage. If you want to extend the behaviour of storage on the filesystem you need to extend the corresponding FSDAO class.
Note that you can change the storage ID (and caching settings) per publication to use and thus switch between DB/filesystem but you cannot change the DAO to use per publication as your custom ...
If it is for ComponentPresentationDAO then I can confirm that it will always be the create (for publish and Re-publish) and remove (for unpublish ) which will be called.
The Update method will never be called.
It might be because the super class JPAComponentPresentationDAO have this update method but it is not in use by the Storage Layer.
I hope it helps
This sounds like an unusual implementation.
It might be worth blueprinting your website to allow you to localize the templates to render the json. The new child publication could be used with a new deployer for you to test if this gives you the output you need without any missing functionality.
I found a solution.
To ensure the DCP is also stored in the Broker Database, my class needed to extend JPAComponentPresentationDAO and call super.create() in my class's create() method
Also, all other methods of the ComponentPresentationDAO interface must call super.XXX() otherwise the DCP isn't removed from the Broker DB even if it is unpublished.
As far as my experience with Storage Extension (in SDL Tridion 2011) is concerned, the update method never got called. Whether you publish a dynamic component presentation or re-publish it, it is always be the create method that got called.
My wild guess is that the super class - JPAComponentPresentationDAO have this update method but it is not in use by ...
Unfortunately it is not possible to use a custom com.tridion.storage.persistence.JPADAOFactoryby design, this type is statically used by the storage layer and it will ignore a custom one avoiding adding new operations to the transaction.
My question: Why do you want to rollback transaction of custom DB if super.create has failed? As you have called the super.create as the first call, and if there is any exception, your code for custom DB and so the related transaction would have not get executed. Isn't it?
You should have written your create method (in the storage extension) with in the try-...