[Geoserver-devel] Branching GeoFence 2.2.x -- Re: geofence geoserver integration

GeoServer GeoServer Developer
1

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

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
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

-------------------------------------------------------

2

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

3

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

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
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

-------------------------------------------------------

4

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

5

Hi Niels,

GeoFence used to provide a REST interface,
   https://github.com/geoserver/geofence/tree/master/src/services/modules/rest
but, after the last improvements and refactoring, it needs some review and
fixing.
You can find the (old) related doc here:
    http://goo.gl/NjkvGn
(it was partially ported into github wiki pages, but the paragraph formatting
is awful there).

REST services are implemented using CXF, so it is also to be seen if CXF (and
its transitive deps) will not present any conflict when running inside
GeoServer.

It's also to be checked/decided if the GeoServer dispatcher could/should be
used to route such REST calls.
I guess Andrea could give some hints about how to publish the API.

   Cheers,
   Emanuele

Alle 14:48:11 di Wednesday 8 April 2015, Niels Charlier ha scritto:

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:-Ge
>>>>>>>> oS 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/DefaultUserRe
>>>>>>>>>> so 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

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
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

-------------------------------------------------------

6

On Wed, Apr 8, 2015 at 3:40 PM, Emanuele Tajariol <etj@anonymised.com>
wrote:

Hi Niels,

GeoFence used to provide a REST interface,

https://github.com/geoserver/geofence/tree/master/src/services/modules/rest
but, after the last improvements and refactoring, it needs some review and
fixing.
You can find the (old) related doc here:
    http://goo.gl/NjkvGn
(it was partially ported into github wiki pages, but the paragraph
formatting
is awful there).

REST services are implemented using CXF, so it is also to be seen if CXF
(and
its transitive deps) will not present any conflict when running inside
GeoServer.

It's also to be checked/decided if the GeoServer dispatcher could/should be
used to route such REST calls.
I guess Andrea could give some hints about how to publish the API.

Hi,
I guess it depends on where you want to expose the REST api.

If we are talking about adding it below the geoserver/rest endpoint, then
I'm afraid you will have to re-code the geofence rest api using restlet.

If however it's ok to have them under geoserver/geofence/rest (a parallel
to geoserver/gwc/... urls) then there is a chance it can be done without
too much
effort, assuming CXF and its dependencies can be mixed in the GeoServer
classpath without problems.

The GeoWebCache own dispatcher is a Spring AbstractController, it's declared
as a bean in the GeoServer app context and then mapped to its own
url subset as follows:

<bean id="gwcUrlMapping"
class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
    <property name="alwaysUseFullPath" value="true"/>
    <property name="mappings">
      <props>
        <!-- prop key="/gwc/service/**">geowebcacheDispatcher</prop-->
        <prop key="/gwc/demo/**">geowebcacheDispatcher</prop>
    <prop key="/gwc/proxy/**">gwcProxyDispatcher</prop>
    <prop key="/gwc/**">geowebcacheDispatcher</prop>
      </props>
    </property>
  </bean>

Now, in GeoFence CXF is enabled using this declaration in web.xml:

<servlet-mapping>
<servlet-name>CXFServlet</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>

Spring provides a particular AbstractController subclass
called ServletForwardingController
that can forward to a servlet... it's not exactly what we need, but should
be close enough.
So, I guess one could create a special AbstractController wrapping the
CXFServlet, and
then binding it to /geofence/rest
That is hopefully going to do the trick

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

7

Andrea,

Thanks for this suggestion. I can't really find a straight-forward solution to call CXF without the use of a servlet that must be defined in web.xml. And there is only one of those, in web-app where I can't place it because geofence-server is only an extension and you can't force cxf dependencies on web/app. I'm sure there must be a way, but I'm leaning atm towards giving up on that idea, for other reasons as well. We only need the rule service, not any of the other services. CXF seems to always be configured globally over the whole webapp, so even if I did find a way to attach CXF to the /geofence/rest URL, no other libraries could ever use CXF in geoserver because all of it would be linked to that url. I am under the impression CXF is intended as a choice you make for your whole webapp, and in that scenario of course optional modules could add optional services.

So I'm thinking now I'm just going to copy-paste the bare code but reconfigure it with Restlet, or even using spring rest api would be possible, I think.

Regards
Niels

On 08-04-15 15:58, Andrea Aime wrote:

On Wed, Apr 8, 2015 at 3:40 PM, Emanuele Tajariol <etj@anonymised.com <mailto:etj@anonymised.com>> wrote:

    Hi Niels,

    GeoFence used to provide a REST interface,
    https://github.com/geoserver/geofence/tree/master/src/services/modules/rest
    but, after the last improvements and refactoring, it needs some
    review and
    fixing.
    You can find the (old) related doc here:
    http://goo.gl/NjkvGn
    (it was partially ported into github wiki pages, but the paragraph
    formatting
    is awful there).

    REST services are implemented using CXF, so it is also to be seen
    if CXF (and
    its transitive deps) will not present any conflict when running inside
    GeoServer.

    It's also to be checked/decided if the GeoServer dispatcher
    could/should be
    used to route such REST calls.
    I guess Andrea could give some hints about how to publish the API.

Hi,
I guess it depends on where you want to expose the REST api.

If we are talking about adding it below the geoserver/rest endpoint, then
I'm afraid you will have to re-code the geofence rest api using restlet.

If however it's ok to have them under geoserver/geofence/rest (a parallel
to geoserver/gwc/... urls) then there is a chance it can be done without too much
effort, assuming CXF and its dependencies can be mixed in the GeoServer
classpath without problems.

The GeoWebCache own dispatcher is a Spring AbstractController, it's declared
as a bean in the GeoServer app context and then mapped to its own
url subset as follows:

<bean id="gwcUrlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
    <property name="alwaysUseFullPath" value="true"/>
    <property name="mappings">
      <props>
        <!-- prop key="/gwc/service/**">geowebcacheDispatcher</prop-->
        <prop key="/gwc/demo/**">geowebcacheDispatcher</prop>
<prop key="/gwc/proxy/**">gwcProxyDispatcher</prop>
<prop key="/gwc/**">geowebcacheDispatcher</prop>
      </props>
    </property>
  </bean>

Now, in GeoFence CXF is enabled using this declaration in web.xml:

<servlet-mapping>
<servlet-name>CXFServlet</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>

Spring provides a particular AbstractController subclass called ServletForwardingController
that can forward to a servlet... it's not exactly what we need, but should be close enough.
So, I guess one could create a special AbstractController wrapping the CXFServlet, and
then binding it to /geofence/rest
That is hopefully going to do the trick

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

-------------------------------------------------------

8

On Thu, Apr 9, 2015 at 10:26 PM, Niels Charlier <niels@anonymised.com> wrote:

Andrea,

Thanks for this suggestion. I can't really find a straight-forward
solution to call CXF without the use of a servlet that must be defined in
web.xml.

What are the challenges? The path I suggested ends up instantiating the
servlet anyways, the servlet context should be available via the
app-context (which is a web application context).

And there is only one of those, in web-app where I can't place it because
geofence-server is only an extension and you can't force cxf dependencies
on web/app. I'm sure there must be a way, but I'm leaning atm towards
giving up on that idea, for other reasons as well. We only need the rule
service, not any of the other services. CXF seems to always be configured
globally over the whole webapp, so even if I did find a way to attach CXF
to the /geofence/rest URL, no other libraries could ever use CXF in
geoserver because all of it would be linked to that url. I am under the
impression CXF is intended as a choice you make for your whole webapp, and
in that scenario of course optional modules could add optional services.

I don't know CXF, so I cannot comment on this one. Emanuele?

So I'm thinking now I'm just going to copy-paste the bare code but
reconfigure it with Restlet, or even using spring rest api would be
possible, I think.

Both should be feasible, yep... it's just a shame to have to rewrite all
that code.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

9

Alle 14:15:02 di Friday 10 April 2015, Andrea Aime ha scritto:

On Thu, Apr 9, 2015 at 10:26 PM, Niels Charlier <niels@anonymised.com> wrote:
> Andrea,
>
> Thanks for this suggestion. I can't really find a straight-forward
> solution to call CXF without the use of a servlet that must be defined in
> web.xml.

What are the challenges? The path I suggested ends up instantiating the
servlet anyways, the servlet context should be available via the
app-context (which is a web application context).

What about using WebApplicationInitializer to programatically
instantiate the CXFServlet?

http://docs.spring.io/spring/docs/current/javadoc-
api/org/springframework/web/WebApplicationInitializer.html

> And there is only one of those, in web-app where I can't place it because
> geofence-server is only an extension and you can't force cxf dependencies
> on web/app. I'm sure there must be a way, but I'm leaning atm towards
> giving up on that idea, for other reasons as well. We only need the rule
> service, not any of the other services. CXF seems to always be configured
> globally over the whole webapp, so even if I did find a way to attach CXF
> to the /geofence/rest URL, no other libraries could ever use CXF in
> geoserver because all of it would be linked to that url. I am under the
> impression CXF is intended as a choice you make for your whole webapp,
> and in that scenario of course optional modules could add optional
> services.

I don't know CXF, so I cannot comment on this one. Emanuele?

Dunno: I never used two CXF servlet instances that expose different sets of
endpoints. I can't find any doc about such configuration.
Anyway, should we have different extensions that uses CXF and a single CXF
servlet instance, I guess this could be solved by choosing proper paths for
the calling URLs (e.g.: rest/cxf/geofence, rest/cxf/ext2, ...)

> So I'm thinking now I'm just going to copy-paste the bare code but
> reconfigure it with Restlet, or even using spring rest api would be
> possible, I think.

Both should be feasible, yep... it's just a shame to have to rewrite all
that code.

If we'll find that CXF can not be used, you could anyway write a wrapper that
receives calls from the geoserver dispatcher, and delegates to methods in
RESTRuleServiceImpl, without the need to duplicate any code.

   Cheers,
   Emanuele

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
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

-------------------------------------------------------

10

Hello Emanuele,

This is something new in servlet-api-3.0 which is still in alpha version.

So, yes, indeed, the challenge I was talking about Andrea is to initialize the servlet context programmatically. I do not see this possible in the current latest stable version of servlet-api. We would need to have the whole of geoserver dependant on CXF.

Regards
Niels

On 10-04-15 17:32, Emanuele Tajariol wrote:

Alle 14:15:02 di Friday 10 April 2015, Andrea Aime ha scritto:

On Thu, Apr 9, 2015 at 10:26 PM, Niels Charlier <niels@anonymised.com> wrote:

  Andrea,

Thanks for this suggestion. I can't really find a straight-forward
solution to call CXF without the use of a servlet that must be defined in
web.xml.

What are the challenges? The path I suggested ends up instantiating the
servlet anyways, the servlet context should be available via the
app-context (which is a web application context).

What about using WebApplicationInitializer to programatically
instantiate the CXFServlet?

http://docs.spring.io/spring/docs/current/javadoc-
api/org/springframework/web/WebApplicationInitializer.html

And there is only one of those, in web-app where I can't place it because
geofence-server is only an extension and you can't force cxf dependencies
on web/app. I'm sure there must be a way, but I'm leaning atm towards
giving up on that idea, for other reasons as well. We only need the rule
service, not any of the other services. CXF seems to always be configured
globally over the whole webapp, so even if I did find a way to attach CXF
to the /geofence/rest URL, no other libraries could ever use CXF in
geoserver because all of it would be linked to that url. I am under the
impression CXF is intended as a choice you make for your whole webapp,
and in that scenario of course optional modules could add optional
services.

I don't know CXF, so I cannot comment on this one. Emanuele?

Dunno: I never used two CXF servlet instances that expose different sets of
endpoints. I can't find any doc about such configuration.
Anyway, should we have different extensions that uses CXF and a single CXF
servlet instance, I guess this could be solved by choosing proper paths for
the calling URLs (e.g.: rest/cxf/geofence, rest/cxf/ext2, ...)

So I'm thinking now I'm just going to copy-paste the bare code but
reconfigure it with Restlet, or even using spring rest api would be
possible, I think.

Both should be feasible, yep... it's just a shame to have to rewrite all
that code.

If we'll find that CXF can not be used, you could anyway write a wrapper that
receives calls from the geoserver dispatcher, and delegates to methods in
RESTRuleServiceImpl, without the need to duplicate any code.

    Cheers,
    Emanuele

11

On Sun, Apr 12, 2015 at 9:57 PM, Niels Charlier <niels@anonymised.com> wrote:

Hello Emanuele,

This is something new in servlet-api-3.0 which is still in alpha version.

So, yes, indeed, the challenge I was talking about Andrea is to initialize
the servlet context programmatically. I do not see this possible in the
current latest stable version of servlet-api. We would need to have the
whole of geoserver dependant on CXF.

Did you check the possibility of making your wrapper a application context
aware, grab the app context,
which should be a WebApplicationContext, and call getServletContext on it ?

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

12

On 12-04-15 22:03, Andrea Aime wrote:

Did you check the possibility of making your wrapper a application context aware, grab the app context,
which should be a WebApplicationContext, and call getServletContext on it ?

How does that help you add a web servlet programmatically? That helps you retrieve existing servlets?

Regards
Niels

13

Hi Niels,

we can give a deeper look into instancing the CXF servlet programmatically
starting next week.
Is the pull req ready for building the whole stuff, apart from the REST
interface?

   Thanks,
   Emanuele

Alle 22:05:05 di Sunday 12 April 2015, Niels Charlier ha scritto:

On 12-04-15 22:03, Andrea Aime wrote:
> Did you check the possibility of making your wrapper a application
> context aware, grab the app context,
> which should be a WebApplicationContext, and call getServletContext on
> it ?

How does that help you add a web servlet programmatically? That helps
you retrieve existing servlets?

Regards
Niels

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
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

-------------------------------------------------------

14

Hello Emanuele,

I have decided for other reasons as well the best way forward is to make a new REST for geoserver and I've already been working on it.
I can still copy-paste some of the implementation. Spring API can be very easily plugged in, does not require any additional dependencies and it doesn't differ that much from the CXF system (it is also annotation based). It is less work than restlet. Thanks for your assistence though.

As far as the geofence-server module with GUI, it is ready for review. Everything works for me, I'm keen to have someone else test it. There should only be a warning that it doesn't work when running geoserver from eclipse unless you manipulate the .classpath file (because of the model/model-internal conflict).

Thanks!

Regards
Niels

On 14-04-15 14:23, Emanuele Tajariol wrote:

Hi Niels,

we can give a deeper look into instancing the CXF servlet programmatically
starting next week.
Is the pull req ready for building the whole stuff, apart from the REST
interface?

    Thanks,
    Emanuele

Alle 22:05:05 di Sunday 12 April 2015, Niels Charlier ha scritto:

On 12-04-15 22:03, Andrea Aime wrote:

Did you check the possibility of making your wrapper a application
context aware, grab the app context,
which should be a WebApplicationContext, and call getServletContext on
it ?

How does that help you add a web servlet programmatically? That helps
you retrieve existing servlets?

Regards
Niels

15

Hi all,

since GeoFence 2.2.x has been branched, I guess we need a new directory 2.2.x/
on
    http://ares.boundlessgeo.com/geofence/
where builds for this branch will be put.

Can anybody take care of this?

   Thanks,
   Emanuele

Alle 12:40:42 di Tuesday 7 April 2015, Emanuele Tajariol ha scritto:

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

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
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

-------------------------------------------------------