Hi Niels, > 1) Switch to another framework, in which case spring data seems to be > the obvious choice to me. There are two sub-options
Since the DAO module shall work both inside the standalone GeoFence version and within GeoServer (when using the geofence-server plugin), I'd go with the full removal of the genericdao library, and use the same libs GeoServer is already using. If GeoServer is not using anything particular, we may just go and see if we can simply use the hibernate API to do most of the filtering work that is done using the genericdao lib. 1b) requires some more work that will eventually be dropped, and probably the work on the fixing needed to make the bridging API work will be comparable to the 1a) option. I wouldn't pick 2) or 3), since it means to become the maintainer of a quite unrelated project :) I guess that the 1a) option may be the cheaper in the long run. Cheers, Emanuele Alle 17:54:30 di Thursday 8 June 2017, Niels Charlier ha scritto: > Emanuele, > > I see three possible options: > > 1) Switch to another framework, in which case spring data seems to be > the obvious choice to me. There are two sub-options > (a) make a whole new DAO api and immediately modify all the services to > the work with it -> major! > (b) create a deprecated bridging API so that the services code do not > all need to be changed at once > > 2) Internalise the generic DAO, which would essentially mean copy-paste > a lot of code from the hibernate-generic-dao library and then I wonder > if we wouldn't just better go for option 3 > > 3) patch the existing library to work with the new hibernate. This could > potentially actually be the least work of all - possibly not much is > needed to make it work again, but I'd need more analysis. Then again, it > must be abandoned for a reason? > > DO you agree with my analysis? What do you think of these options? What > is your preference? > > Regards > Niels > > On 05-06-17 11:08, Emanuele Tajariol wrote: > > Hi all, > > > > please also note that, on top of hibernate, GeoFence relies heavily on > > the generic-dao library (com.googlecode.genericdao:dao version 1.1.0), > > so it should also be checked that it is compatible with the hibernate > > version we'll want to use. > > > > The lib seems to have been automatically migrated here: > > https://github.com/based2/hibernate-generic-dao > > > > but there's no recent activity on it. > > Replacing that library in GeoFence will require a major rework of the > > persistence and service modules. > > > > Cheers, > > Emanuele > > > > Alle 09:54:10 di Monday 5 June 2017, Nuno Oliveira ha scritto: > >> GeoFence uses GitHub issues: > >> https://github.com/geoserver/geofence/issues > >> > >> So at least JDBC 4.0 is required: > >> https://jdbc.postgresql.org/download.html#archived > >> http://www.oracle.com/technetwork/database/features/jdbc/index-091264.ht > >> ml > >> > >> On 02-06-2017 10:53, Niels Charlier wrote: > >>> question: is there a JIRA for work on geofence's own modules (not the > >>> ones in geoserver)? > >>> > >>> Regards > >>> Niels > >>> > >>> On 02-06-17 11:24, Niels Charlier wrote: > >>>> Hello Nuno, > >>>> > >>>> On 01-06-17 17:00, Nuno Oliveira wrote: > >>>>> Hi, > >>>>> > >>>>> What dependencies are conflicting with recent postgres/postgis stores > >>>>> and what are actually the issues ? > >>>> > >>>> I don't actually know... This is the only information that has been > >>>> given to me. I could find out though, but I understand you agree with > >>>> an upgrade in principle. > >>>> > >>>>> Anyway Hibernate 3.6.0.Final was release 7 years ago and has two > >>>>> major versions on top of it so upgrading to a more recent version is > >>>>> probably something that should be done: > >>>>> https://mvnrepository.com/artifact/org.hibernate/hibernate-core > >>>>> > >>>>> My main concern is the impact on existing installations of GeoFence, > >>>>> taking in account the commonly used databases (PostgreSQL, Oracle, > >>>>> ...) which versions will still compatible ? Hibernate rely on the > >>>>> JDBC driver of the database so the question can be rephrased, which > >>>>> JDBC versions are supported by 3.6.0.Final that are no supported by > >>>>> 5.x ? > >>>>> > >>>> From the hibernate website: > >>>> "Hibernate 5.2 and later versions require at least Java 1.8 and JDBC > >>>> 4.2. > >>>> > >>>> Hibernate 5.1 and older versions require at least Java 1.6 and JDBC > >>>> 4.0." > >>>> > >>>> > >>>> I found posts via google that suggest hibernate 3.6 supported JDBC3, > >>>> but I cannot find any official documentation that confirms this. > >>>> > >>>> > >>>> I think we could opt for hibernate 5.1 if that makes things more > >>>> backwards compatible, because I was asked 5.x > >>>> > >>>>> The spatial extension of Hibernate also suffered several changes, do > >>>>> you see possible incompatibility issues ? > >>>> > >>>> I cannot find documentation that lists migration issues. I am assuming > >>>> I will face quite a few issues, but that these can be resolved. I am > >>>> hoping that the test coverage is sufficient, so that if I can make > >>>> all the tests work again I can assume that it works... > >>>> > >>>> Regards > >>>> Niels > >>>> > >>>> > >>>> ---------------------------------------------------------------------- > >>>> -- ------ Check out the vibrant tech community on one of the world's > >>>> most engaging tech sites, Slashdot.org!http://sdm.link/slashdot > >>>> > >>>> > >>>> _______________________________________________ > >>>> Geoserver-devel mailing list > >>>> Geoserver-devel@lists.sourceforge.net > >>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel > >>> > >>> ----------------------------------------------------------------------- > >>> -- ----- Check out the vibrant tech community on one of the world's > >>> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot > >>> > >>> > >>> _______________________________________________ > >>> Geoserver-devel mailing list > >>> Geoserver-devel@lists.sourceforge.net > >>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Emanuele Tajariol Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 380 2116282 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
