I can download the hibernate 3.6 offline reference from
https://docs.jboss.org/hibernate/orm/3.6/reference/en-US/pdf/
Recently l update my hibernate to 4.3.5.final. So, Iwant the corresponding doc. However while I try to access the URL(https://docs.jboss.org/hibernate/orm/4.3/), there is only the html version. How can I find the pdf version?
Related
I am currently working on liferay upgradation from 6.0 to 6.2.2 GA3. I tried upgrading the services portlet. The services portlet of 6.0 version is built using mvn services-portlet-archetype whereas for 6.2 version the archetype is liferay-servicebuilder-archetype. The difference is that in 6.2 liferay-servicebuilder-archetype there are two modules:
Module 1: is a portlet which has our code logic
Module 2: is the services-portlet which has the class files generated during liferay:build-service. These files are archived into jar file which is later used inside the portlet(Module 1) module for the creation of the WAR file.
Whereas in 6.0, there is no concept of modules. The services class files generated during liferay:build-service are generated inside services folder under src/.
This liferay-servicebuilder-archetype is available only from Liferay 6.1+ versions as seen in mvnrepository. My guesses for the need of this new archetype from 6.1 version are:
1. To avoid committing the auto generated services files by mistake to our version control repo.
2. To be more modular.
But with this new archetype I found out that the build process consumes lot of permgen space and heap space(I have to double the heap and permgen space everytime I run the mvn clean package liferay:build-service as observed through jvisualvm). I was able to create the same portlet with services-portlet-archetype successfully deployed and working in 6.2 GA3 server(without extra permgen space and heapspace). But did not find any memory issues during its build.
My questions are:
1. Which of these two archetypes(liferay-servicebuilder-archetype or services-portlet-archetype) is a good practice for liferay 6.2 GA3.
2. Going forward if I need to upgrade all the 20+ portlets which I am using in my project should I need to create from archetype? (Takes lot of time and effort).
3. How to fix this issue of extra memory consumption if using liferay-servicebuilder-archetype is the best practice. The target folder seems to produce more class files than in services-portlet-archetype target folder.
4. The need for this new archetype is for the two benefits mentioned above(which I guessed) or is there anything else?
After waiting for 2+ weeks for an answer to this question, I am assuming that my following guesses are the correct answer to this question.
The need for this new archetype from 6.1 version is:
1. To avoid committing the auto generated services files by mistake to our version control repo.
2. To be more modular.
If there is a more convincing answer, I will choose that to be the best answer.
EDIT::::
Found this link useful
https://www.liferay.com/community/forums/-/message_boards/message/51303796
I upgraded my Expression Engine installation to 2.7.3 (from 2.3.1). But after upgrading I get an error when trying to view the site.
Error
Unable to load requested field type file: ft.relationship.php.
Confirm the fieldtype file is located in the expressionengine/third_party/ directory
I can see that there is a expressionengine/fieldtypes/relationship/ft.relationship.php and if I go to the admin page I see a field type as being installed there (As “Relationships Version 1.0”).
Why is EE giving me an error at that point?
Per the EE 2.7.3 docs found here:
Changed in version 2.6: Relationships was completely rewritten for this version, adding the ability to create multiple relationships for each entry and introducing a friendly new tag syntax. The template tags described here are not compatible with previous versions.
The foundation of Relationships is very different in the new version, so I would guess that you need an update to which ever third party add-on you're using.
I have a XPage application where I use JavaMail in one of my managed beans. Currently I have added the jar-file C:\Programme\IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jarto the build-path of the manged bean. This works well. But now I want to use a newer version of JavaMail as the Domino server uses version 1.3 but I need version 1.4.x.
I have downloaded the new JavaMail jar-files from Oracle. In Domino Designer (version 9) I add this jar-file to the new design element "Code / Jars" and remove the old jar-files from the build path.
My managed bean is still compiling and running as desired, but if I check the version the bean is using it reports still version 1.3. To check the version number I use the debug property of JavaMail and it's reporting version 1.3 to the domino server console.
Is there a way to tell the domino server to use the jar-files in the application (i.e. the nsf) and not his own? Is there another approach to update the JavaMail version?
The reason I want to use a newer version of JavaMail is as follows: I want to read mails from an imap server with ssl. To avoid the problem of importing ssl-certificates I simply want to trust all hosts. This can be be done via MailSSLSocketFactory, but this is only available since version 1.4.2. Therefore I want to use a newer version of JavaMail.
Another reason I want to use a newer version is as follows: the method "getSortedMessages" of "IMAPFolder" is only available since version 1.4.4. (and so are some other features of JavaMail).
This may be a little too late for you... I think the right approach may be to include the jar file as an OSGi plugin.
I have spent some time to figure out how to do that - and recently succeeded :-) I have described the steps to perform to make this work in two articles. The first is about wrapping a JAR into a plug-in: http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/ - the second is about deployment (and there is a link in the first one).
/John
You can solve the problem by creating an OSGi plug-in that supersedes the one that sports the JavaMail library: com.ibm.designer.lib.javamail.
In order to do that do the following:
Create an OSGi plugin whose id is com.ibm.designer.lib.javamail (Dalsgaard's tutorial on how to do it)
Set its version to a higher number than the one the Domino server is shipped with (to know the version type tell http osgi ss com.ibm.designer.lib.javamail). As of now using 9.0.1.qualifier should be fine
Deploy the plugin either through an update site or by directly copying it under the domino\workspace\applications\eclipse\plugins folder.
Restart the HTTP service. The higher version - the one you created - will now be used
I've got the same problem here, but found a solution. Be warned, this is not the best answer but it will work. Simply download the latest javamail jar here and rename the jar file to 'mail.jar'. Just replace the current file in IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jar with this file. Quit the http task and restart it. The code will now work with the latest version.
I'm using the official nuget package of Windows Azure Storage Client Library to retrieve items of my Azure tables.
Recently I updated the package from version 2.0.2.0 to 2.0.5.0 and my app stopped working because the results returned by my storage query are different with the new version.
I'm looking for the library changelog in order to understand how to fix the issue.
Do you know where can I find it ?
The link provided on the nuget page seems to be outdated (it's a changelog between 1.x and 2.x, not between 2.0.2 and 2.0.5 !). Also, the Windows Azure Storage team's blog is not updated.
Please refer to the changelog.txt that is always updated with the respective source code changes.
The changelog is always up to date at https://github.com/Azure/azure-storage-net/blob/master/changelog.txt
I cant find a method since I upgraded the Azure storage dlls.
The static method I cant find is: CloudTableClient.CreateTablesFromModel
The old class:
http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.cloudtableclient_methods.aspx
This is the new class:
http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storage.table.cloudtableclient_methods.aspx
I did some searching but couldn't find a word about this being replaced or deleted.
Does anybody have an idea?
Storage client library 2.0 is quite different from the previous version and a number of methods have been removed in the newer version. This method is one of them. If you look under the remarks section on this page: http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.cloudtableclient.createtablesfrommodel.aspx, it is recommended that you not use this method.
Since these 2 versions are quite different, it is recommended that you read up the following blog posts from the storage team before upgrading your code to use the latest version:
http://blogs.msdn.com/b/windowsazurestorage/archive/2012/10/29/introducing-windows-azure-storage-client-library-2-0-for-net-and-windows-runtime.aspx
http://blogs.msdn.com/b/windowsazurestorage/archive/2012/10/29/windows-azure-storage-client-library-2-0-breaking-changes-amp-migration-guide.aspx
http://blogs.msdn.com/b/windowsazurestorage/archive/2012/11/06/windows-azure-storage-client-library-2-0-tables-deep-dive.aspx
I also wrote a blog post about migrating code from storage client library 1.7 to 2.0 which you can read here: http://gauravmantri.com/2012/11/17/storage-client-library-2-0-migrating-table-storage-code/