There might be a few SDK projects that still use TransactionUtil, but this checkin gets rid of
its use otherwise.
I took a glance over the areas of the code that use UserTransaction directly and didn't see any
transactionally wrapped code that desperately needed to be put into a retry loop (i.e. write
transactions in a concurrent scenario). If you spot any that you think might qualify, let me know.
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/alfresco/HEAD/root@6220 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
- fix to missing annotated service method (caused script command servlet to fail)
- spelling mistakes in annotated service method parameters
- cleanup in AbstractWebScript
Added ValueConverter concept to Template API - similar to JavaScript API ValueConverter, for a consistent mechanism to recursively convert Alfresco node properties to template accessable objects.
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/alfresco/HEAD/root@5535 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
Hightlights of check-in include:
- Introduction of script processor
- Neutralisation of script and template models
- The notion of a processor extension introduced
- Extensions applied to processor implementation rather than the services
- Auto selection of processor based on file extension of template or script
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/alfresco/HEAD/root@5519 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
Provides access to AVM stores and nodes within those stores. The majority of the standard template Node API is available (such as properties, children, content, icons etc.) and some additional AVM specific methods.
Root level helper object 'avm' provides lookup for AVM store object and AVM nodes objects by path in the OO style expected by template writers. Once retrieved, the store object provides store meta-data and access to the root Template AVM node for the store (or lookup of individual nodes by path) which exposes the standard template Node API.
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/alfresco/HEAD/root@5460 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
- similar pattern to existing script bean extension support
- new root model helper objects and custom methods can be added via spring configuration
Cleanup of script extension spring support
Fix to thread safety of configured script extension beans that use the Scopable interface
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/alfresco/HEAD/root@5369 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
svn merge svn://svn.alfresco.com:3691/alfresco/BRANCHES/V2.0@5141 svn://svn.alfresco.com:3691/alfresco/BRANCHES/V2.0@51352 .
- FLOSS
- Some files will need a follow-up
-root/projects/repository/source/java/org/alfresco/repo/avm/wf/AVMRemoveWFStoreHandler.java (not yet on HEAD: 5094)
-root/projects/repository/source/java/org/alfresco/filesys/server/state/FileStateLockManager.java (not yet on HEAD: 5093)
-onContentUpdateRecord (not on HEAD)
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/alfresco/HEAD/root@5167 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
- Runtime (txn breaking) exceptions that occurs during JavaScript execution now correctly bubble up and halt script execution
. Rhino JavaScript engine JAR updated to 1.6R4 (from 1.6R2)
- Bug fix release - executed all existing test scripts to ensure compatability
. Minor label change requested by PHH
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/alfresco/HEAD/root@5055 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
- Transparent support for inter-store copy added to JavaScript Node and AVMNode implementations
The existing API mechanisms for copy() now support passing of Node or AVMNode and visa-versa as the destination target
No changes to existing copy() semantics and no new services/APIs to learn
. Improvements to handling of missing input parameters in JavaScript Node APIs
. Added Workspace->Workspace support to CrossRepositoryCopyService
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/alfresco/HEAD/root@5047 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
this: mysite--guest--preview/HEAD/DATA/www/avm_webapps/ROOT/WEB-INF/...
and: mysite--guest--preview/VERSION/v1/DATA/www/avm_webapps/ROOT/WEB-INF/...
rather than: mysite--guest--preview/HEAD/DATA/appBase/avm_webapps/ROOT/WEB-INF/...
and: mysite--guest--preview/VERSION/v1/DATA/appBase/avm_webapps/ROOT/WEB-INF/...
The reason for this is that the actual "appliation base"
is and always has been "avm_webapps"; the original reason
for making the *parent* of this dir called appBase had do
do with the fact that you can have diffrent app bases
for different virtual hosts. However, in the end it causes
way more confusion than it was ever worth, so it's gone now.
The reason for all the modified files is that people were
hard-coding values in many different places, and/or defining
their own constants for something that was needed at a
higher level.
As a temporary measure (I hope), I've defined some rather ugly-looking
constants in JNDIConstants.java, and have used them everywhere:
DIR_DEFAULT_WWW = "www"
DIR_DEFAULT_APPBASE = "avm_webapps"
The reason for calling the parent of the new application base "www"
is that will be the default place that www-centric stuff happens
(therefore, it's also the level at which the overlays take place).
Ultimately, I'd like to turn these into spring configs,
and bring back support for multiple AVMHost nodes within
the same Tomcat... but it's not a priority at the moment.
Please don't hard-code any dirs named "appBase" as the
root level dir in a repo -- it's now "www", and will
change again to a function call later when/if virtual
AVMHosts come back. Keeping them as constants also
helps them to be easier to find when overhauling things.
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/alfresco/HEAD/root@4696 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
