We are using ColdFusion MX7.
The CFDOCUMENT tag uses iText for the PDF creation so the whole of the iText library is included in the standard CF deployment.
The problem I'm having is that I want to use a version of iText that is newer than the one included in CF7. I need to keep CFDOCUMENT functioning, so simply changing the jar file is not an option.
What I have done so far is to load the iText source into Eclipse and refactor it to a different name. That works fine and has been doing so for about a year.
However, I would like to upgraded to the newest iText release, and jumping through the hoops of refactoring again is a bit daunting.
Is there an easier way to load the jars and not have them conflict with the old version?
One option is to use the JavaLoader.cfc to load a newer version of the jar. Since it uses an external classloader it can be used without disturbing the existing version.
http://www.transfer-orm.com/?action=javaloader.index
http://javaloader.riaforge.org/
However, it would still require rewriting your createObject("java", "path.to.class") statements to use javaLoader.create("path.to.class") instead. But in the long run, that might be better than refactoring, because it would be easier to update the iText jar in the future.
Itext just released v5.0.0 and one of the significant changes to it is that the Package Name has been changed from "com.lowagie" to "com.itextpdf" allowing you to co-exist.
Simply download the new iText.jar file and rename to "iTextpdf.jar" and locate it in the proper LIB folder for CFMX.
When you do your createObject calls, simply use the new package name path.
JavaLoader is a great utility, but if you don't load it into server scope (the initial loader with paths to the iText jar) AND ensure it is only loaded ONCE, you can run into severe memory leak issues.
Using the latest refactoring of iText means you don't need to worry about it.
if what you want is the cf8 functionality of cfdocument, then there might be an easier way. remember that railo and openbd both have cfdocument functionality that is on par with cf8 and both are free engines. what you could do is download and install one of these engines onto the same server or a different one if desired. then write a webservice within railo or openbd that wraps the cfdocument functionality and returns the pdf to you.
it's not the prettiest solution, but neither is refactoring itext or hacking the itext version that came with cf.
Related
I need to update the OWASP AntiSamy jar file which is located at ColdFusion11\cfusion\lib
The file currently in there is antisamy-1.4.4.jar but I want to update this to the latest version which is antisamy-1.5.3.jar which I have downloaded from OWASP and placed in the cfusion\lib folder.
Does anyone know how I can tell ColdFusion to use the latest version of the file? Is the path to the file in some configuration file anywhere?
In CF Administrator I can see both the old file and new file under 'Settings Summary' but how do I know which one its using to power the GetSafeHTML function?
I want to update this to the latest version
AFAIK, there is no list of individual files. At least not for the "core" jar files used by the CF Server. It simply checks certain directories like {cf_root}\lib, web-inf\lib, etcetera and loads any *.jar files it finds.
If you want CF to use a different version for core tags and functions, you must replace the existing jar file with the new one. The actual jar file ame does not matter. What is important is having only a single version of the library in the CF class path. Otherwise, CF will simply use the first version it finds.
You can also try placing the new jar file in the jvm's lib/ext directory. IIRC, those jars should take precedence over the ones in {cf_root}\lib.
NB: Since you are replacing/overriding the version used by CF, you should do some testing to verify the new version of the library is backward compatible and that replacing it does not break anything. As noted in the comments below, there is always a risk of problems when messing with CF's built in jar files...
What is the best way to uninstall a package or a module in Sitecore?
I've seen suggestions to do it manually, but it is not very convenient way, especially when there were many templates, items, layouts, renderings and static files.
You can use Sitecore Rocks to create an "anti-package."
https://www.sitecore.net/nl-be/learn/blogs/technical-blogs/trevor-campbell/posts/2013/02/28-days-of-sitecore-rocks-package-management-part-1.aspx
I have never tested the Package History module that was mentioned, so I cannot comment as to whether that approach works.
Open the .zip file for the original package and look through the XML to figure out what files the package installed. Then back up your site and remove files and configuration nodes the package installed(assuming you are confident you understand what purpose the files and nodes have and what other components may rely on them). The Package History module may be taking this same approach, but you need to be certain that what you are deleting is not going to break anything.
Otherwise, I would recommend restoring to a backup made before you installed the package.
I have a package I want to install. I would like the files to end up in a different directory than the installation wizard choses for them.
For example, my Sitecore copy is running at C:\SiteCore\website
The module added files to C:\SiteCore\website\Console
I would like the files to ultimately live at C:\SiteCore\website\sitecore_modules\Console
I am using Sitecore 6.5 rev 111230, but we are planning to upgrade very soon. I would like for my installed packages to migrate seamlessly once we have upgraded. For reference, the package I want to install at the moment is the Sitecore Powershell Extensions. Although, I would prefer to apply a similar method to any future packages that I install.
Is there a secret switch in the package installation process to allow me to do this? Can I do it from the package installation wizard? Is there another way to install packages?
I'm assuming I can't just change the package path and expect everything to keep working. Do I have to update a configuration somewhere (a file or inside the Sitecore CMS GUI) to make the package recognize the new file locations?
The module creator defines where files exist. If you move them you run the risk of something not working. The best idea is to ask the creator on the Marketplace page of the module.
There is no turn-key way to change this.
I guess you cand take the code from MarketPlace and you can modify it.
I don't know how exactly is the licenses with MarketPlace modules, but I think people can modify others code.
Please check on code and also on items, maybe on some fields are values for folder path.
I discovered a way to accomplish this, but it can be quite involved or even impossible, depending on the complexity and size of the package.
First of all, I did take the question to the module creator and had a very helpful and informative conversation with the creator. So thanks for that suggestion - they may even move the install location in a future release, based on my request.
The workaround is to first install the package on a system as normal. Then you figure out everything that comes with the package. For files, this is easy if your Sitecore root is under source control. For items, this is really complicated. You can search for the installed items by owner, if you had the foresight to create & use a unique user for the package installation. Or you can check the untyped files in the package that are essentially xml based item manifests.
Once you have a detailed list, you make the desired modifications to the locations. Then you recreate the package yourself using the Sitecore package designer.
This works for simple packages - I did it to one small package that I hope to get up on the Sitecore marketplace as shared source soon. And by small, I mean it was 2 files and 3 items. The package that prompted me to ask this question would not cooperate with this workaround. The included .dll had some assumptions about the file structure hard-coded into it.
The workaround I took for the more complex package was really quite basic: I just created a new source-code external to the required path. That let me wrap everything up neatly without getting medieval on the package files.
Thanks for both your answers, a very fine +1 to you.
I do a fair amount of personal development on my computer and have used TortoiseSVN (I'm on windows) for web projects, but haven't used any version control for other languages. Anyways, soon I will be starting a decent sized C++ project and was going to try using SVN for it.
For web development, I normally just used notepad++ and it was really easy to manage it with SVN (just commit the whole source folder). However, for this project I will be using an IDE (most likely Eclipse CDT or Visual Studio) and was wondering what the best practice is to manage all of the IDE, project, and binary files. My guess was to make the IDE project outside of the version control, and just point to all of the source files into the SVN so all of the build and project files aren't committed. This way the only files in the SVN would be the .cpp and .h files.
However, if I wanted to switch to a new branch, then I would need to update the location of all of the source and headers to the new folder which seems like it would be a huge hassle.
Whats the best way to handle this?
Thanks
Ok, it seem I misgot the aim of the question in the first round. Now I'm assuming what is asked really to what to put under source control and what not.
Well, naturally everything but temporary/transient files.
If you install GitExtensions, it right away has a feature to populate the .gitignore file. Certainly depending on language you adjust it. Sure, solution, project, make files belong under control. .USER files storing some IDE preferences do not. As both IDEs and source control is ubiquitously used the content is fairly separated for many years, and should be pretty obvious as you do it.
External dependencies normally also shall be in a repo, though choice shall be made in which one. Some store everything together, others keep one dependency repo, others separate repos per component -- all depends on actual components and workflow. And you can replace physical storage of deps by an info file with stable links to the used version. It may also be covered later on the first change in dependencies.
For Visual Studio, there is a plugin that manages your files for you. As long as the files are part of the project, then they will be put into source control by the plugin. See ankhsvn for plugin info. Note that the express versions of Visual Studio are not supported.
I am sure eclipse has a plugin for SVN as well.
I use leiningen to manage my clojure project and I want to copy jar file along with some other files into a certain directory as a final part of a build process. Leiningen treats 'resources' as something which should be included into the jar file, and it is unacceptable for me. If I used maven, I could configure it for such task using maven-resource-plugin or fall back to Ant using maven-antrun-plugin, but leiningen is far more convenient tool for clojure projects.
Strangely, I couldn't manage to find anything about similar functionality in leiningen on the internet. This is curious, because one of major clojure applications is web sites, and web sites usually do not include their resources (js, css, etc) into the jar (or do they? That would be weird since slight css tweak will require rather lenghty recompilation). It comes naturally that we have to prepare site environment (copy static resources along with jar bundle into some directory layout), and this task should be done by the build tool.
Is there a plugin to copy files around the filesystem (or something which could substitute it, like running Ant), or I must write one myself? Right now I'm using shell scripts, but it is very inconvenient since I had to run several commands instead of one, and also it is unportable.
did you checkout lein-resource?
in any case. here is a long list of available plugins for lein, maybe you will fine some of them helpful