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:-GeoServer >>>> >>>> - 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/servic >>>>>> >>>>>> 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/servic >>>>>> >>>>>> 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/servic >>>>>> >>>>>> es /core/services- >>>>>> impl/src/main/java/org/geoserver/geofence/services/DefaultUserResolver. >>>>>> >>>>>> 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 _______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
