Using a newer version of Apache POI in ColdFusion 10 - coldfusion

I would like to use newer version of Apache POI with ColdFusion 10 than the one with which it ships, as I need to access some of the newer functionality.
I have tried swapping ColdFusion's Apache POI JAR files for the newer versions but this causes some of the built in ColdFusion spreadsheet functionality to break.
Is it possible to load in the newer version for use in my code but leave ColdFusion's version untouched so that the built in spreadsheet functionality still works?
I know it is possible to specify a custom Java load path in CF10 but if I try and load in a newer version of a library which has already been loaded for use by ColdFusion will this cause a clash?

It is possible to use Mark Mandel's JavaLoader (https://github.com/markmandel/JavaLoader) to use a newer version of Apache POI with ColdFusion 10 without affecting CF's built in spreadsheet functionality.
I used version 3.11-beta2 of Apache POI because this does not depend on dom4j.jar which seems to be problematic.
I used JavaLoader instead of CF10's built-in ability to load JARs because this allows me to access ColdFusion's older version of Apache POI using createObject() whilst accessing the newer version stored in my webroot using the JavaLoader method server[application.JavaLoader].create().

Related

What is the openssl version used by aws_sdk for c++?

What is the openssl version used by aws_sdk for c++? And how can we make SDK to support particular version of openssl?
Currently the SDK targets 1.0.x. We need to update the SDK to handle 1.1.x and later. There is currently a pull request request for this. We'll evaluate it and get it merged in as soon as possible.

Is there an easy way to check library compatibility with Django versions?

I have inherited a Django application that is currently on 1.4 (so no longer officially supported). I am working my way through the Django versions, upgrading the application and obviously many of the libraries used in the application are quite old versions as well.
Is there an easy / standard way to know what versions of a certain library will be compatible with specific Django releases?

Getting error about Lucene version 3.0.3.0 while upgrading Sitecore version to 7.0

Earlier we were using Lucene version 2.3.1.3(Sitecore version 6.5) everything working fine but now we have upgraded to sitecore version 7.0(Initial release) and now we are using Lucene version 3.0.3.0 dll in project.
But now we are not able to compile project because of errors in code file.
Does that means Lucene version 3.0.3.0 dll doesn't support code written in Lucene version 2.3.1.3(Sitecore version 6.5)
Thanks
Upgrading from Sitecore 6.x to 7.0 needs some adjustments in code to get everything work again.
Which error do you get? I also had a specific error regarding lucene dll when compiling after the upgrade but this error was only caused by a wrong assembly redirect in the web.config.
In fact, the search API changed completely and if you made an upgrade to 7.0 it is recommended to update your search logic to the possibilities are now available in 7.0 like LINQ support and so on. Search is much more comfortable now in sitecore 7 and it is really worth taking a closer look at the changes. They took a lot of the advanced database crawler module like dynamic fields (they are now called computed fields) and much more and added it to the sitecore 7 standard search api.

GIS extension of Boost.Geometry

I am using Boost 1.50.0 and I need to use the GIS extension of Boost.Geometry. Where can I find this extension for Boost 1.50.0 or lower? (I haven't upgraded my application to newer version of Boost due to some compatibility issues.)
The extensions are a part of the development version of a library, they're not released. So in order to use them you should probably checkout/clone (and use) the development version of Boost.Geometry. You could also try to mix the released version and the extensions from the development version but I'm guessing this way it'd be easier to make some mistake which would e.g. result in unwanted incompatibilities.
Anyway, the most simple way of doing it would be to see which commit was the most recent one in the Boost.Geometry released in Boost 1.50 (boost-1.50.0 tag in Boost.Geometry repository on GitHub):
https://github.com/boostorg/geometry/commits/boost-1.50.0
and then try to find a corresponding one in the develop branch:
https://github.com/boostorg/geometry/commits/develop
Note that you can find some commits in both branches that can't be found in the other. I don't know if that's because SVN was used back then or the reason is different. In your case I'd try with this commit from boost-1.50.0:
https://github.com/boostorg/geometry/commit/443b01bc07b0fb329aee803ea1bef6a8f14e449b
which seems to correspond to this commit in develop:
https://github.com/boostorg/geometry/commit/d35eb8f2dff20e61655fcef5ee4a23ca4d9d9847
so this is the develop tree:
https://github.com/boostorg/geometry/tree/d35eb8f2dff20e61655fcef5ee4a23ca4d9d9847
which you should be able to download by clicking the "Download ZIP" button on the right side of the page. Then you could use it instead of the released version or just extract the extensions from it, etc. Just have in mind it's not officially released version and that no guarantees can be made.
Here you can see the extensions in that tree:
https://github.com/boostorg/geometry/tree/d35eb8f2dff20e61655fcef5ee4a23ca4d9d9847/include/boost/geometry/extensions

Fault tolerant DLL usage in Visual C++

Background:
I have an existing code that uses functionality provided by Microsoft, to post XML data over HTTP. Specifically, IServerXMLHTTPRequest (included in MSXML3 and up) from msxml4.dll (COM).
The Problem:
In the possible eventuality, were MSXML4.DLL is missing on the client workstation, the described POST operation will simply fail. More information about MSXML versions.
The current code:
#import "msxml4.dll"
using namespace MSXML2;
…
IServerXMLHTTPRequestPtr spIXMLHTTPRequest = NULL;
hr = spIXMLHTTPRequest.CreateInstance(__uuidof(ServerXMLHTTP40));
Alternatives:
Hard code to MSXML6 (instead of MSXML4). Not a good solution as we do not know what MSXML version is installed on the workstation. Also, the code will break again if Microsoft will release the next DLL version.
Dynamically load the latest from the registry:
Find MSXML version from registry and
Dynamically load a function from a DLL
Use the type library instead?
I would be happy to hear additional alternatives
The question:
What is the simplest and most robust way to change my code to be MSXML version agnostic? That is, use IServerXMLHTTPRequest regardless of the MSXML version actually installed on the client machine. If no version of MSXML is installed, prompt the user and exit gracefully.
Need additional information? Just let me know
Thank you!
From MSDN:
MSXML version 3.0 was the last version of MSXML to support version-independent GUIDs and ProgIDs. Starting with version 4.0, MSXML is installed on your computer in side-by-side mode. This means that, for example, installing MSXML 5.0 for Microsoft Office Applications does not replace any previously installed version of the MSXML parser on your computer. This is done to protect the quality of applications that are currently using earlier versions of MSXML. Side-by-side mode also allows you to decide which version of the parser to use in your code.
This means that there is no COM class installed which you can instantiate expecting that most recent installed version will be picked up, or otherwise someone else will decide for you whether to load MSXML 4 or 6 depending on availability or another criteria.
You are expected to use specific version and depend on respective runtime to be available or installed. Or you can switch between MSXML versions in your code as you already discovered.