Hello Emanuele, That sounds good. When the geofence 3.0 branch is there I will update the versions in the geoserver modules. Thanks! Let me know if you need anything else from me.
Regards Niels On 07-04-15 12:40, Emanuele Tajariol wrote: > Hi Niels, > > ok, some changes in the geofence branches and versions: > > - Current master has been branched to "2.2.x", > - The user-role refactoring branch is going to be merged into master, which > will be bumped to version 3.0. This major version change is due to the changes > in the base model that will make the previous version uncompatible. > > For the GeoFence community module in GeoServer 2.7 we'll have to use the > GeoFence 2.2.x branch, in order to have the DTOs matching, while GeoServer > master (2.8) will use GeoFence master (3.0). > > > Cheers, > Emanuele > > > > Alle 16:33:31 di Monday 6 April 2015, Niels Charlier ha scritto: >> I made a pull request for the changes on geoserver: >> https://github.com/geoserver/geoserver/pull/1005 >> >> I've put it there already mainly to get commenting and reviewing going. >> But I do hope we can sort out how to get these changes in the official >> branches of geofence and geoserver soon! >> >> Let me know what you think. >> >> Regards >> Niels >> >> On 06-04-15 11:55, Niels Charlier wrote: >>> Hi Emanuele, >>> >>> Are the geofence refactoring commits going to be pulled in the master >>> branch in the official repo? >>> Because I almost have a pull ready for gs-geofence-server but it >>> depends on those changes being there. >>> >>> >>> Also, I have found a work-around for my eclipse issue. While you can't >>> manipulate the dependency order of included projects from the GUI, >>> there is an order inside the config file behind it (.classpath file in >>> the project dir). The order of the pom doesn't seem to be respected, >>> but I can manually do it. After running maven eclipse:eclipse, I >>> manually edit the .classpath file and move the model-internal >>> dependency above the gs-geofence dependency. That is the best solution >>> for now, but still a bit annoying. There is another really annoying >>> thing in eclipse, there is an application-context.xml in test and it >>> reads it of course. >>> >>> Regards >>> Niels >>> >>> On 02-04-15 13:01, Emanuele Tajariol wrote: >>>> Hi Niels, >>>> >>>>> * Let gs-geofence also use model-internal, but it is probably not >>>>> desire >>>>> to have all that unnecessary hibernate stuff loaded. >>>> Exactly: the split model was created only because gs-geofence did >>>> import too >>>> much hibernate stuff inside geoserver. >>>> >>>>> * Make them different classes (or in different packages) but use >>>>> interfaces instead for compatibility? Probably would require lots of >>>>> refactoring inside geofence. >>>>> * Can we somehow force geofence-server to use the classes from >>>>> geofence-model-internal even if both are on the classpath? It seems >>>>> that >>>>> java will always use the _first_ on the classpath, but eclipse doesn't >>>>> recognise an order in project dependencies >>>> These solutions are quite complex, and would be a workaround for a >>>> workaround >>>> (the split model). >>>> I guess the simpler way would be to only have a single model module, >>>> and to >>>> remove the hibernate annotations using the hbm files instead. >>>> I tried to use the hibernate tools for automatically creating the hbm >>>> files out >>>> of the annotations, but they seemed quite bugged. Do you have any >>>> experience >>>> with them? >>>> >>>> Cheers, >>>> Emanuele >>>> >>>> Alle 12:17:37 di Thursday 2 April 2015, Niels Charlier ha scritto: >>>>> Hi, >>>>> >>>>> I have a practical problem regarding the difference between >>>>> geofence-model and geofence-model-internal. >>>>> They both contain the same classes, but geofence-model removes the >>>>> hibernate annotations from the build. >>>>> >>>>> gs-geofence uses geofence-model while gs-geofence-server needs >>>>> gs-geofence-model-internal. I solved this earlier by putting an >>>>> exclusion in the geofence-server profile of the web-app pom. The >>>>> problem >>>>> is however eclipse. When you do mvn eclipse:eclipse inside web-app, >>>>> this >>>>> works fine. However, eclipse doesn't add any of the geoserver >>>>> modules as >>>>> "required projects" in the build path, but rather as regular external >>>>> jar files, so you miss the relationship between the code and this >>>>> brings >>>>> inconveniences while programming and debugging. >>>>> >>>>> To solve that you have to do eclipse:eclipse from the geoserver source >>>>> root. But then eclipse doesn't recognise the exclusion... and keeps >>>>> loading the classes from model. And geofence-server doesn't work >>>>> without >>>>> the hibernate annotations. >>>>> >>>>> So, do you guys have any ideas for solutions? >>>>> * Let gs-geofence also use model-internal, but it is probably not >>>>> desire >>>>> to have all that unnecessary hibernate stuff loaded. >>>>> * Make them different classes (or in different packages) but use >>>>> interfaces instead for compatibility? Probably would require lots of >>>>> refactoring inside geofence. >>>>> * Can we somehow force geofence-server to use the classes from >>>>> geofence-model-internal even if both are on the classpath? It seems >>>>> that >>>>> java will always use the _first_ on the classpath, but eclipse doesn't >>>>> recognise an order in project dependencies >>>>> >>>>> Any suggestions? >>>>> >>>>> Regards >>>>> Niels >>>>> >>>>> On 27-03-15 17:16, Emanuele Tajariol wrote: >>>>>> Hi Niels, >>>>>> >>>>>>> What does this setting do: "Use GeoServer roles to get >>>>>>> authorizations"? >>>>>>> >>>>>> GeofencePage.useRolesToFilter=Use GeoServer roles to get >>>>>> authorizations >>>>>> >>>>>> it's related to this proposal: >>>>>> >>>>>> https://github.com/geosolutions-it/geofence/wiki/Proposal-%233:-GeoSer >>>>>> ver >>>>>> >>>>>> - Roles-to-GeoFence-groups-mapping#configuration >>>>>> >>>>>> It makes the AccessManager query geofence the authorization not for >>>>>> the >>>>>> accessing user, but by the role the user is assigned in GeoServer >>>>>> See also method setRuleFilterUserOrRole. >>>>>> >>>>>> If the roles in geoserver are exactly the same as in geofence (as the >>>>>> current integration work aims to) it should not matter, since the >>>>>> resulting auths will be the same. >>>>>> I mean: if the useRolesToFilter is set to true, the user-role matching >>>>>> will be done in setRuleFilterUserOrRole. If it's set to false, such >>>>>> matching will be performed inside geofence, using the metod >>>>>> UserResolver::getRoles >>>>>> >>>>>> Cheers, >>>>>> Emanuele >>>>>> >>>>>> Alle 16:50:58 di Friday 27 March 2015, Niels Charlier ha scritto: >>>>>>> Hi Emanuele, >>>>>>> >>>>>>> Excellent. What does this setting do: "Use GeoServer roles to get >>>>>>> authorizations"? >>>>>>> >>>>>>> Regards >>>>>>> Niels >>>>>>> >>>>>>> On 27-03-15 14:49, Emanuele Tajariol wrote: >>>>>>>> Hi Niels, >>>>>>>> >>>>>>>>> The user/group integration work is that ready or does it still need >>>>>>>>> work? >>>>>>>> It's ready. The rule engine needs info about the user, the role and >>>>>>>> their association. You can provide these info by implementing this >>>>>>>> interface >>>>>>>> >>>>>>>> https://github.com/etj/geofence/blob/201503_user_role_refact/src/ser >>>>>>>> vic >>>>>>>> >>>>>>>> es /core/services- >>>>>>>> api/src/main/java/org/geoserver/geofence/spi/UserResolver.java >>>>>>>> >>>>>>>> and aliasing this spring bean with the new implementation >>>>>>>> >>>>>>>> https://github.com/etj/geofence/blob/201503_user_role_refact/src/ser >>>>>>>> vic >>>>>>>> >>>>>>>> es /core/services- >>>>>>>> impl/src/main/resources/applicationContext.xml#L24 >>>>>>>> >>>>>>>> The default UserResolver uses the DAO toward the geofence DB >>>>>>>> >>>>>>>> https://github.com/etj/geofence/blob/201503_user_role_refact/src/ser >>>>>>>> vic >>>>>>>> >>>>>>>> es /core/services- >>>>>>>> impl/src/main/java/org/geoserver/geofence/services/DefaultUserResolv >>>>>>>> er. >>>>>>>> >>>>>>>> j ava >>>>>>>> >>>>>>>> but I guess you'll have to return the users and roles actually >>>>>>>> used in >>>>>>>> GeoServer. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Emanuele >>>>>>>> >>>>>>>> Alle 21:23:40 di Thursday 26 March 2015, Niels Charlier ha scritto: >>>>>>>>> On 26-03-15 16:49, Andrea Aime wrote: >>>>>>>>>> Speaking of hibernate, wondering what might happens if geofence >>>>>>>>>> and >>>>>>>>>> the monitoring hibernate extension are both loaded in GeoServer. >>>>>>>>> Yeah I haven't tested with the hibernate extension yet. That could >>>>>>>>> indeed cause more trouble >>>>>>>>> >>>>>>>>>> What if the GEOSERVER_DATA_DIR system variable is not defined? >>>>>>>>>> It's >>>>>>>>>> not mandatory. >>>>>>>>>> I guess you could create a subclass of PropertyOverrideConfigurer >>>>>>>>>> depending on GeoServerResourceLoader and >>>>>>>>>> get the base directory there. >>>>>>>>> think >>>>>>>>> You are right. Something similar has been done in the geofence >>>>>>>>> module >>>>>>>>> for the PropertyPlaceholderConfigurer, will use the same principle. >>>>>>>>> Consider the current version kind of a proof of concept, will still >>>>>>>>> need to fine-tune it. >>>>>>>>> >>>>>>>>>> The other thing that bother me a bit, but it's GeoFence own fault, >>>>>>>>>> it's this business of setting up the data source >>>>>>>>>> inside the Spring context instead of creating it programmatically, >>>>>>>>>> allowing the data source to be read from some >>>>>>>>>> config file, and allow its re-configuration at runtime. >>>>>>>>>> In the long run it would be best if the integrated GeoFence could >>>>>>>>>> start off H2, but allowed configuration >>>>>>>>>> to store the rules somewhere else at runtime, without need for >>>>>>>>>> restarts. >>>>>>>>> Yeah some of the client settings also require a restart for the >>>>>>>>> same >>>>>>>>> reason. The server URL anyway, but that doesn't apply with the >>>>>>>>> internal server. >>>>>>>>> >>>>>>>>> The user/group integration work is that ready or does it still need >>>>>>>>> work? >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Niels > ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel