Does liferay 6.2 allow using new Java 8 date classes such as LocalDate to be used as a datatype for entity column fields,in order to utilise more features on the same.We need to use
<column name="createDate" type="LocalDate" />
instead of<column name="createDate" type="Date" />
Is there some other means to achieve this?Does tweaking hibernate version,allow usage on the same,if so,is that valid?
Liferay 6.2 started with Java 7 compatibility and only got compatible with Java 8 later, mostly due to limitations of the supported application servers - this is a good indicator that there's nothing foreseen with regards to Java 8 classes. While they might work, you might run into untested territory. I'm neither saying it does nor it doesn't - although I suspect that you have tried already and ran into problems when you ask the question here.
As Guivani Grifante said, upgrading Hibernate within Liferay most likely will result in a huge mess, and if you are ready to do that, I'd rather ask to upgrade to Liferay 7 (though I didn't double-check its Hibernate version).
Another means to get to such an adoption is to use the old Date type and just add a converting getLocalDate() and setLocalDate() to the YourModelImpl and just implement the conversion yourself. Yes, a bit weird, but might be the quickest fix, without a lot of immediate upgrade hassle. However, if you use 6.2 CE, note that there won't be any more updates and you should move on to 7 sooner rather than later. If you're on EE, you'll have a while of support left.
This isn't the only problem if you deploy a portlet with Java 8 into Liferay. If your code was compiled with Java 8 and contains remote services generated by service builder, you will get an error while deploy such portlet. This is caused because Liferay uses a Jodd api to analyze bytecode and get the parameters names to show in /api/jsonws
Hibernate 5.x has support to new date api, however, there is little chance of upgrade without break Liferay 6.2.
Related
My system currently uses a gemfire cache and uses the io.pivotal.gemfire dependencies. Two of the dependencies, geode-core and geode-management both use org.jgroups (jgroups) as a runtime dependency. Currently I am using version 9.10.13 of the io.pivotal.gemfire dependencies (geode-core, geode-wan, geode-management etc. (see code snippet below)) and version 3.6.14.Final of jgroups.
Due to a vulnerability in the current version of jgroups, I want to upgrade to a newer version (any in version 4 would be sufficient but the newer the better (versions)). The problem I am having is that when I attempt to upgrade to a newer version (3.6.17 or newer), I get the following error when attempting to start-up the cache server:
java.lang.NoSuchMethodError: org.jgroups.View.<init>(Lorg/jgroups/ViewId;Ljava/util/List;)V
at org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.installView(JGroupsMessenger.java:459) ~[geode-membership-9.10.13.jar:?]
When I actually go to investigate the issue, it looks as though it is referencing a line where the View class constructor was changed to take in a "Collection" instead of a "List", which seemed like a strange error since a List is a Collection.
I have tried using different combinations of jgroups and gemfire going up to 4/5 and 9.10.17 respectively without success. If anyone has any recommendations on how to move past (solve) this jgroups vulnerability while using a gemfire cache it would be much appreciated. Also, is there a table that lists gemifre versions vs. supported versions of jgroups?
Was able to get in contact with VMware Tanzu. All 9.* versions of gemfire require jgroups 3.6.14.Final. The new version of gemfire (10.*) which is currently in beta, is supposed to remove all dependencies on jgroups.
why I have spend some extra effort to migrate my application if I'm not using new features of latest version
You don't have to upgrade, but I'd say it's worth it for 2 reasons:
Performance and security upgrades of Spring and other dependencies is always a worthwhile effort in my opinion. By skipping upgrades you could be using vulnerable packages.
What happens in a year if you do need a new feature or need to migrate to JDK 11 and beyond? It's typically easier to do the incremental updates multiple times per year rather than a big-bang upgrade every couple of years.
In my previous spring projects, I always use hibernate+postgresql to store the data. I rencently start to use spring-boot, and I am looking for a database system which allow me embed it in my project, without be required the installation of a external DBMS.
I try use SQLite, but in my searches I found some afirmations Hibernate isn't compatible with SQLite.
Anyone knows if this is possible and could point me a solution?
We've successfuly used HSQLDB with Hibernate for ages.
This is actually super cool for sales, you can demonstrate a working application on (potential) customers machine with the embedded HSQLDB database. And still be able to switch to "the real thing" later on.
See also this:
Does Hibernate Fully Support SQLite
and this:
https://code.google.com/p/hibernate-sqlite/
i'm at my new job and the projects at work are in spring 2.5 (some portlets). how hard is it to migrate to spring 3 ?
there is a customized portal 1.0 (don't know if this is relevant) and i was wondering if i could just ask to develop in spring 3.
never used spring before and want to learn some, but it would be nice if i could just go for the latest version. got spring in action 3rd edition and would like to make use of that
It principle, it should be a drop-in replacement. There's a bunch of stuff that was deprecated in Spring 3, and huge amount of new stuff added, but nothing was removed.
However, there were a bunch of minor bug fixes, and your code may be unwittingly relying on the buggy behaviour, so some minor adjustments may be necessary, but nothing any worse than that.
Other than that, the big difference is that Spring 3 requires Java5+. I'm assuming you're not stuck on 1.4 :)
I am just starting to learn about spring and was looking at the difference between Spring 3.0 and Spring 2.5.
Initially i was following this tutorial http://static.springsource.org/docs/Spring-MVC-step-by-step/index.html which is a step by step guide to developing a Spring MVC application. It is based on Spring 2.5 and i notice there are quite a few differences with Spring 3.0. I tried to find the equivalent tutorial that is based on 3.0 but couldnt find it.
The difference i notice with 3.0 is that there is a lot of use of annotations and a lot of things is done for you in the background. I am sure this is a good thing but i am wondering for the purpose of learning the framework should i continue with 2.5 so that i can understand what goes on behind the scenes before i use spring 3.0?
Please also if you can recommend a spring book that is suitable for a beginner i would appreciate it.
Thanks
I'd recommend to always use the latest version of a framework. Especially if you're starting on a new project. There are always (well usually) tons of improvements, and simplifications, and migrating to the latest version later may be a pain.
Spring has a great user manual (see http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/), and IMHO a book doesn't have an added value in this case. I found the Spring user manual always easy to read and understand, so don't get intimidated. I think this is definitely the best starting for beginners as well. You don't have to read it all. Only the sections of interest!
Note that Spring 3.x contains many other improvements such as SpEL (Spring Expression Language), improved web support (you already saw that), REST support, and more.
... should i continue with 2.5 so that i can understand what goes on behind the scenes before i use spring 3.0?
That's really up to you to decide, but if you are going down the Spring 3.x annotation-based route, it is not clear that you >>need<< to understand what is happening behind the scenes. Especially for run-of-the-mill applications.
I was not aware of the purchase of Spring by VMware. Do you think this might affect the open source aspect of Spring in that it might not be open source anymore?
First, the SpringFramework guys are thoroughly committed to open source (from what I can see). So a change would probably entail lots of developers leaving.
Second, most of the people who use Spring do so because it is open source, so a change would risk a major migration of (paying) customers away.
Third, turning Spring into a closed source product would be a politically awful move for VMware, and would likely have fallout for other VMware product lines.
Finally, and most importantly for people committed to using Spring: there is no way that the VMware could legally "undo" the open sourcing of current Spring releases. The best they could do would be say that Spring 4.0 etc was closed source. Anyone who wanted to would be free to continue distributing and using SpringFramework 1.0.x, 2.0.x, 2.5.x, 3.0.x and all associated open sourced technologies. And anyone would be free to create a "fork" of any of them to continue Spring open source development. The only possible issue would be the use of trademarks, and that is easily worked around.
Add that all up, and (IMO) there is nothing to worry about.
"Spring in Action", "Pro Spring", and "Spring Recipes" are the three that I'd recommend to anyone.
If you've never used Spring, I'd say that learning either one will suit your purposes. The majority of Spring 2.5 carries over to 3.0, so it's not wasted.
The books and tutorials haven't kept up with Spring 3.0. Another change between versions was the purchase of Spring by VMWare. They've separated paid support from open source, so it's hard to tell what the future will be for non-paying customers.