Greeting ,
I am enable to find out any method to implement SSL services with Qt 4.2.3 version .I am presently restricted to use 4.2.3 version , can't use 4.3 or later version . Please suggest me any way to come out from this problem .
There is a LGPLv2.1 licensed Qt add-on named QCA - Qt Cryptography Architecture. It supports SSL and TLS and other crypto-related technologies. It depends on Qt 4.2+ and is cross-platform in a typical Qt way.
Related
I'm writing an application that should be cross platform, so my idea is to write the full substrate in C then writing the user's interface related stuffs in Objective-C or other suitable language (i.e. C++ for linux).
For that application I have to use OpenSSL; as documented Apple dropped the support of this library since SDK 10.11; as I know OpenSSL should be available until SDK 10.10.
Now my question: I'd like to develop with XCode 7.3 but I'd like that my app should be also backward compatible with reasonably older version of OS X; my idea is that I have to install older SDK across the new XCode 7.3 then choose the right SDK to use under "Build settings" -> "Base SDK".
Can someone point me at a document describing how can I download and install older SDK on new XCode? On Apple Developer website I have found only older release of XCode but it will install a complete old release of XCode...
Thank you for your precious help.
Rather than building with an old SDK, you should build and link with OpenSSL yourself. From the documentation:
If your app depends on OpenSSL, you should compile OpenSSL yourself and statically link a known version of OpenSSL into your app.
The version of OpenSSL shipped with OS X is old and out of date, anyway. Apple dropped support for it precisely because they couldn't ship newer versions without breaking backwards compatibility (OpenSSL is not API stable between releases).
Yes the title is correct...we are going BACK to qt4. We recently built a decent size app with Qt5. We now been told that the app must support RH 6 and RH 5 distros.
Since RH6 ships with Qt 4.6.2 and Rh 5 ships with Qt 3.3.6, I'm concerned about having to make lots of modifications to port back to older versions of Qt.
Can the latest versionf of Qt 4.x and 3.x understand new syntax of Qt5 (eg: connect is slightly different)? If not, can someone suggest how best to undertake this? Are we looking at ifdef'ing our way out of this? (and if so, is there an easy reference for how to do this)
Consider building qt5 libraries and deploying them (only ones you actually use) together with your project. This link can help to build.
I actually built them today on my CentOS 6.5 64-bit with this configuration command:
./configure -prefix /opt/my_prod/Qt-5.2.1 -release -nomake examples -dbus -qt-xcb -no-c++11
However I did not built all libs listed on the link and did not apply patches.
Then I built a small test app and ran it on CentOS and then on Ubuntu 12.04 (to which Qt5 libs I copied manually).
I've installed worklight 6 into an existing juno 64 bit eclipse running in windows 7. Runs great. I then install the jazz RTC 4.0.2 plug in into that eclipse environment. After the plugin is installed, there is a noticeable loss of function. The following are examples:
On the create new Hybrid app page, the option for changing the dojo library used is gone. The dialog resembles the WL5 version.
after a dojo hybrid is created, the www folder is missing from the WL project
Some dojo widgets do not work (i.e., not presented on the mobile device emulator or in resulting adroid application) like dojo.mobile.Heading
The only way to resolve is to uninstall the RTC plugin. Any suggestion on how to make this work? Using WL5.0.6.1 and same Jazz RTC plugin has no problems. We want to move to newer WL and upgrading RTC is not an easy option.
Are you using Eclipse Java EE 4.2.2? That's the only supported version for Worklight Studio (i.e. make sure you are not using 4.2.1 or 4.2 alone).
Other things I would try:
1) Use RTC 4.0.3 plug-in instead 4.0.2, that could make some difference and usually these clients have backwards compatibility with the server.
2) Install RTC before Worklight Studio, and see if it makes any difference.
I have been using the dynamic code evaluation for dynamic loading of my changed classes in my Jboss server ,
I have found this tool very helpful and interesting , but it have a problem that it works with jdk 1.6 , but As i am trying to use java 7 in my project it fails .
Can anyone suggest similar type of tool with java7 support
I suggest using... the Dynamic Code Evolution VM for Java 7 :) The DCEVM web site is not up to date and the version available for download there doesn't work with the latest versions of Java 7. For some time the Mercurial repository contained a more recent version and it has been eventually forked on Github where binaries for Windows and Linux are provided. On Debian/Ubuntu DCEVM is also available after installing the openjdk-7-jre-dcevm package.
I heard that JBoss 7 is not certified for FreeBSD - is that correct?
Where can I find a list of supported platforms? (I spent some time googling, but was not successful)
Strictly speaking there is no certified OS for JBoss 7 as only JBoss EAP 6 is supported by Red Hat.
The supported configuration for JBoss EAP 6 (the supported version of community JBoss 7) can be found here: https://access.redhat.com/knowledge/articles/111663
As JBoss is pure java application, a compliant JDK is enough to have a supported system. So if you have the Oracle or IBM JDK running on FreeBSD is will be supported by Red Hat. But they haven't test them with JBoss.
Any way if you want Red Hat support for the EAP you better check with there representative to discus the extends of the support (if the FreeBSD JDK have some compliance bug, they will probably send you back to the JDK supplier. If you chose RHEL with OpenJDK you will have one supplier to blame for any software stack issue, no redirect to another suplier.)
For community JBoss as for other platform, you will be responsible to make it work with your stack. An good first test can be performed by running the standard compliance tests included in the JBoss sources, if it runs on your target platform and JDK it is a good sign that JBoss is working on it.
Certified Support as per Redhat only goes up to 6:
https://access.redhat.com/knowledge/articles/111663
However if you look back at the release docs they have not changed. OS's are the same.