Emanuele, Thanks! I have added the version updates to my pull request.
Something else, I need to also make a REST API available on the integrated geofence. Of course I only need the Rules API. Do you have any recommendations on how to do that? You reckon I should make a new one in geoserver and copy-paste or could I depend on a module and configure to publish it? What are your thoughts? Regards Niels On 08-04-15 13:47, Emanuele Tajariol wrote: > Hi Niels, > >> When the geofence 3.0 branch is there I will update > On master branch the version has been updated to 3.0-SNAPSHOT: > > https://github.com/geoserver/geofence/blob/master/src/pom.xml#L15 > > The refactor branch has already been merged into master. > > Cheers, > Emanuele > > > Alle 12:55:36 di Wednesday 8 April 2015, Niels Charlier ha scritto: >> 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:-GeoS >>>>>>>> er 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/s >>>>>>>>>> er 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/s >>>>>>>>>> er 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/s >>>>>>>>>> er vic >>>>>>>>>> >>>>>>>>>> es /core/services- >>>>>>>>>> impl/src/main/java/org/geoserver/geofence/services/DefaultUserReso >>>>>>>>>> lv 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
